Mjukvaruarkitektur

Intro

Mjukvaruarkitektur är ofta något som arbetas fram internt i ett företag och varje företag har sitt specifika tillvägagångssätt. Det finns dock många anledningar till att vilja standardisera mjukvaruarkitekturen. En anledning är att underleverantörer ska leverera funktioner som enkelt kan integreras i befintliga arkitekturer, helt utan anpassningar. Detsamma gäller självklart även inom ett företag, där det blir lättare att återanvända funktioner mellan olika projekt. Ytterligare en anledning är verktygsstödet, med en större användarbas sjunker den relativa kostnaden underhåll och fokus kan istället ligga förbättrad funktionalitet.

Det här processexemplet tar upp hur en process kan se ut när man jobbar med standarden AUTOSAR, en standard utvecklad inom fordonsindustrin men som kan implementeras även inom andra områden. Även om man inte arbetar med AUTOSAR idag så finns möjlighet att dra nytta av simuleringsmöjligheterna i AUTOSAR för att göra tidiga funktionella integrationstester.

På följande sidor beskrives hur arkitekturen designas, hur implementationer kopplas till den och vilka steg som behöver tas för att nå en färdig mjukvara.

AUTOSAR

AUTOSAR är utvecklat av ett konsortium av fordonstillverkare, underleverantörer och verktygsleverantörer.

En frikoppling av funktionerna från hårdvaran görs genom att all kommunikation sker via anrop till ett mellanlager (RTE). Om det görs ett internt anrop på samma plattform eller om det går över nätverket, görs via en mappning.

En av styrkorna med AUTOSAR är att det är konstruerat för tidig verifikation via simulering. Genom konceptet med Virtual Function Bus (VFB) så kan funktioner kopplas ihop på en funktionell nivå utan hänsyn till eventuell senare fysisk separering mellan olika noder.

Modellering

Design av mjukvaruarkitekturen görs med fördel i en grafisk miljö där man enkelt kan se hur komponenter kopplar till varandra. Då all kommunikation sker mot operativsystemet inom AUTOSAR blir strukturen platt och det är då viktigt att kunna lyfta ut relevanta delar i en egen vy.

Vad som behöver specificeras i ett första skede är i huvudsak:

  • Vilka mjukvarukomponenter som skall finnas (Application Software Components inom AUTOSAR).
  • Vilka funktioner som skall finnas (Runnables inom AUTOSAR).
  • Hur funktioner och mjukvarukompenter skall kommunicera med varandra (Portar, interfaces).
  • Vilka events som skall trigga funktionerna (cykliska, händelsestyrda, etc).

Implementation

När hela eller delar av arkitekturen är komplett så måste den distribueras till de som ansvarar för implementationen. Med komplett menas inte färdigställd, då ändringar troligtvis dyker upp med tiden, utan med tillräckligt mycket definierat för att en funktionsutvecklare skall kunna integrera sin funktion.

I exportskedet så delas exporten lämpligen upp så att funktionsutvecklare endast får de delar som är relevanta. En funktionsutvecklare kan då importera den arkitektur som ska följas och infoga sin implementation i denna. Funktionsutvecklaren exporterar sedan en uppdaterad version av arkitekturen som nu även innehåller implementationen.

Arkitekturmodellen brukar i regel delas upp i några olika filer för att hålla isär specifika delar från generella delar som återanvänds genom hela arkitekturen. Till det kommer filer med implementationen (koden) och alla filer kommer med tiden att finnas i olika versioner med beroenden mellan filerna. För att hålla komplexiteten nere så är det en fördel om det finns verktygsstöd för att hålla koll på vilka filer som hör ihop.

Integration

När en implementation är klar skall den integreras i projektet. Genom en import så får man då en uppdaterad arkitektur med referenser till implementationen och själva koden.

När alla mjukvarukomponenter kopplats till en implementation så finns all funktionell kod tillgänglig. Detta kan man utnyttja genom att göra funktionella integrationstester. Man kan då testa hela den funktionella koden med en frikoppling från hårdvaruimplementationer såsom drivrutiner och elektriskt interface. Det går att läsa mer om detta i processexemplet för verifiering.

Integrationen är en iterativ process med uppdaterade implementationer.

Hårdvarudistrubution

Ett system kan vara en ensam styrenhet eller distribuerat på flera fysiska styrenheter (Electronic Control Units – ECU:er). Dessa ECU:er måste skapas och representeras i systembeskrivningen.  Systemet beskrivs också av nätverkstopologin som möjliggör kommunikation mellan mjukvarukomponenter på de olika ECU:erna.

 

Färdigställande

När konfigurationen är komplett och implementation finns för samtliga mjukvarukomponenter så återstår det att generera kod för konfigurationen och koppla ihop detta med operativsystemet.

Efter detta återstår saker som kompilering och nedladdning av applikation och parameterset, men koden är nu komplett.

Meny