Funktionsutveckling

1. Introduktion

På följande sidor finns ett exempel på hur modellbaserad utveckling för funktionsutveckling kan se ut, från specification till verifierad slutprodukt. Genom att arbeta modellbaserat så ges möjlighet till snabba iterationer, tidig verifiering och hög återanvändningsgrad genom processen.

Utvecklingen börjar med simulering på en dator och går sedan vidare till verifiering av algoritmerna på ett prototypsystem med inkoppling mot det system som ska kontrolleras. När det efter ett antal iterationer resulterat i ett välfungerande system så anpassas koden för det målsystemet. För att kunna verifiera att kraven uppfylls med kontrollerade och repeterbara tester kopplas målsystemet sedan in en simulator som simulerar det system som skall kontrolleras.

2. Simulering

Ett första steg är att skapa en modell av den funktionalitet som skall implementeras.

För kunna bedöma ifall funktionen har ett önskat beteende är det fördelaktigt att göra en simulering av modellen. För att kunna göra det krävs stimuli till modellen. Är det t ex en logikfunktion så kan det räcka gott med att koppla in ett antal signalgeneratorer i modellen men är det exempelvis en reglering så behövs ett återkopplat system. Det behövs då en modell av det som ska styras, en så kallad omvärldsmodell.

Omvärldsmodellen bör vara tillräckligt detaljerad för att återskapa beteendet och detaljnivån är väldigt olika beroende på vad som implementeras.

Med en omvärldsmodell det så går det att skapa ett återkopplat system där det går att simulera beteendet av både den utvecklade funktionen och omvärlden och därmed verifiera att modellen uppfyller önskad funktionalitet redan under designfasen.

3. Implementering på realtidssystem

När funktionaliteten är verifierad i en simuleringsmiljö så är det lämpligt att  verifiera att algoritmen man tagit fram fungerar i praktiken med de sensorer och ställdon som finns tillgängliga.

Testet vill man helst göra på ett högpresterande system där begränsningar i beräkningskapacitet inte begränsar beteendet och där det finns utrymme att köra icke-optimerad kod där man har möjlighet att läsa av varje enskild signal i modellen för en analys av beteendet.

Innan det tas fram ny produktionshårdvara så är det också en fördel ifall först verifiera behovet av elektriskt interface så att det inte behöver tas fram flera versioner.

I regel så fungerar aldrig allting som det är tänkt på första försöket men med en bra verktygskedja för att snabbt kunna ändra i modellen, kompilera den och ladda ner den på realtidsplatformen så går det att snabbt ta sig mot ett fungerande system som beter sig som det är tänkt.

4. Mätning och kalibrering

När applikationen körs på ett realtidssystem med en fysisk koppling mot det som ska styras så är nästa steg att optimera prestandan. För att kunna göra det behöver man dels kunna styra parametrar men också ha en möjlighet att se och logga signaler.

Med ett bra mät- och kalibreringsverktyg kopplat mot realtidssystemet så kan man snabbt göra en intuitiv layout med visualisering av signaler. Man kan då t ex jämföra stegsvar för att trimma in en reglering eller enklare saker som att simulera input från ett användarinterface och se att allt tolkas på ett korrekt sätt.

5. Kodgenerering för målsystem

När modellen efter ett antal iterationer återskapar det önskade beteendet är det dags att implementera den på målsystemet.

Målsystemet har oftast av kostnadsmässiga skäl en hel del begränsningar i beräkningskapacitet och koden skapad för den måste vara optimerad. Finns t ex endast stöd för heltal så måste in- och ut-signaler skalas med en viss faktor och dessa skalningar måste ärvas och anpassas genom beräkningar.

Med en modellbaserad utveckling kan man låta en produktionskodsgenerator skapa c-koden utifrån vad som specifierats i modellen. Kodgeneratorn håller t ex koll på hur olika skalningar ska tolkas och man behöver bara verifiera beteendet. Produktionskodsgeneratorn optimerar också koden så att ingenting beräknas ifall det inte används.

För att analysera att den optimerade produktionskod som skapats av modellen verkligen motsvarar det önskade beteendet vill man simulera koden (Software-In-the-Loop) och jämföra denna med den simulerade modelle (Model-In-the-Loop). Kodgeneratorn introducerar inte i sig några fel men eftersom man som användare har möjlighet att påverka koden, med t ex heltalsimplementation så behöver det verifieras att skalningen inte leder till kvantifieringseffekter.

Genom att ha modellen som grund för koden går det enkelt att byta från heltalsimplementation till flyttal eller från stardard c-kod till AUTOSAR.

 

6. Integration i mjukvaruprojekt

Vanligtvis implementerar man inte hela kodbasen modellbaserat utan skriver drivrutiner och andra hårdvarunära anrop i en klassisk kod-miljö. Det är sedan enkelt att exportera de generade c-filerna för att integrera dem i övriga projektet.

I större projekt skall koden intergras i en mjukvaruarktitektur, exempelvis AUTOSAR. Genom att göra integrationssimuleringar mot en virtuell hårdvara så kan man identifiera eventuella problem och verifiera beteendet i ett tidigt skede. Mer om den interaktionen finns att läsa i processexemplet för mjukvaruarktitektur.

 

 

7. Verifiering i HIL-miljö

När den slutgiltiga styrenheten är klar måste den verifieras. Detta kan göras i den maskin där den slutligen ska monteras men det finns många fördelar med att utföra testen i labbmiljö där övriga delar av maskinen simuleras. Här återanvänds den omvärldsmodell som används vid modellutvecklingen. Detta öppnar för möjligheten att skapa automatiserade tester som går att återskapa över olika mjuk- och hårdvaruversioner. Här går det att testa både funktionalitet och elektriskt interface men också diagnostik.

Koppling av den färdiga styrenheten till en simulator kallas Hardware-In-the-Loop (HIL) och det finns mer att läsa om det under processen för verifiering.

Meny