Återhämtning och Modellering av Sensor- och Ställdons Arkitektur i Automotive Inbyggda System

Under det senaste årtiondet har mängden kod som används i fordon ökat exponentiellt. På grund av detta skiftar bilindustrin mot att vara software-intensive. Som i de flesta mjukvaruintensiva branscher, drivs systemets utveckling i snabbtakt av marknadens krav. Återanvändningen av värdefull legacy-code är en effektiv metod för att minska tiden till marknaden. Vid Scania är mjukvaruutveckling främst baserat på en omfattande legacy plattform. I detta sammanhang är det nödvändigt för systemförståelse, återanvändning, underhåll, systemverifiering och säkerhetsanalys att upprätthålla en omfattande beskrivning av mjukvaruarkitekturen. Men för att skapa en sådan beskrivning behövs ytterligare resurser, och det är svårt att upprätthålla följdriktighet med föränderliga implementationer. Ett sättet att lösa detta problem är Reverse Engineering. Mjukvaruarkitekturen kan hämtas automatiskt från inbäddad källkod och presenteras på ett sätt som ärspecifikt för domänen.Denna avhandling är en del av ESPRESSO-projektet. En del av ESPRESSOprojektetgår ut på att återvinna lastbilens mjukvaruarkitektur från källkoden.Syftet med detta arbete är att utöka täckningen av arkitektursåterhämtningengenom att lägga till kopplingar mellan hård- och mjukvara. För att uppnå detta haren hårdvarumodell, inspirerad av EAST-ADL hårdvaru-meta-modell, utvecklats och använts i den befintliga infrastrukturen. Hårdvarumodellen användes för att samla in och bearbeta information för att lagra den i Neo4J grafdatabas. Förslag på användargränssnitttillhandahölls för interaktion med databasen, men implementationen var inte en del av examensarbetet. Utmaningarna under arbetets gång uppstod främst på grund av det faktum attvarje Scania-avdelning använder sin egen partiella systemmodell av lastbilsarkitekturen.Flera vyer och begrepp från olika avdelningar skulle slås samman i en enda modell. För att uppnå validering till en viss grad, användes databasen i samband med användargränssnittet. Gränssnittet var medelvärdet med vilket några scenarier kontrollerades både mot intern teknisk dokumentation och ingenjörer som arbetar med dessa system.From the past decade onward, a trend has been seen in which the amount of code used in a vehicle is increasing exponentially. Because of this growing factor, the automotive industry is gradually shifting towards software-intensive. As in most software-intensive industries, the system’s evolution is driven at a fast pace by the market’s requirements. The re-usability of valuable legacy code is an effective method of reducing the time to market. In Scania, software development is predominantly based on an extensive legacy platform. In this context, maintaining a comprehensive software architecture description is necessary for system understanding, re-usability, maintenance, system verification and safety analysis. However, to develop such a description involves additional resources, and it is difficult to maintain consistency with evolving implementations. One way to solve this problem is Reverse Engineering. The software architecture can be retrieved automatically from embedded source code and presented in a manner specific to the domain. This thesis is part of the ESPRESSO project. One part of ESPRESSO is to recover the truck’s software architecture from source code. The objective of this work is to extend the coverage of the architecture recovery by adding connections between hardware and software. To achieve this, a hardware model, inspired by the EAST-ADL hardware meta-model, has been developed and employed in the existing infrastructure. The hardware model was used to gather and process information in order to store it to the Neo4J graph database. User interface suggestions were provided for querying, but the implementation was not part of the thesis. The challenges facing this work arose mainly due to the fact that each Scania department uses its own partial system model of the truck’s architecture. Multipleviews and concepts from different departments had to be merged in a single model. To achieve validation to a certain degree, the populated database was used in connection with the user interface. The interface was the mean by which a few scenarios were checked both against internal technical documentation and the engineers that are working with those systems