Model based development of a roll angle estimator for motorcycles.

av rollvinkeln för motorcyklar

Examensarbete utfört i Reglerteknik

vid Tekniska Högskolan i Linköping av

Soa Eriksson, Petter Isaksson Reg nr: LiTH-ISY-EX-3392-2003

av rollvinkeln för motorcyklar

Examensarbete utfört i Reglerteknik

vid Tekniska Högskolan i Linköping av

Soa Eriksson, Petter Isaksson Reg nr: LiTH-ISY-EX-3392-2003

Handledare: Jonas Nilsson Jonas Elbornsson Examinator: Fredrik Gustafsson Linköping 16 maj 2003.

Språk Language 2Svenska/Swedish 2Engelska/English Rapporttyp Report category 2Licentiatavhandling 2Examensarbete 2C-uppsats 2D-uppsats 2Övrig rapport

URL för elektronisk version

ISBN ISRN

Serietitel och serienummer

Title of series, numbering ISSN

Titel Title Författare Author Sammanfattning Abstract Nyckelord Keywords

This report compares the development tools Ascet and Matlab with regard to their suitability as tools for model based development of signal processing software for embedded systems. We derive appro-priate metrics of quality and perform an implementation of a signal processing algorithm called RAI, Roll Angle Indicator, in both tools. RAI is an algorithm that with an Extended Kalman Filter estimates the roll angle, that is how much a motorcycle is leaning. From the models implemented in Ascet and Matlab we then generate C-code for a embedded system. This code is then run on an embedded target containing a Inneon C167 microprocessor. Information from the implementation and the performance of the generated C-code is then used to compare the two model based development tools.

Institutionen för Systemteknik

581 83 Linköping 2003-05-16

LITH-ISY-EX-3392-2003

http://www.ep.liu.se/exjobb/isy/2003/3392

Model based development of a roll angle estimator for motorcycles Modellbaserad utveckling av en skattare av rollvinkeln för motorcyklar

Soa Eriksson, Petter Isaksson

× ×

Modellbaserad utveckling, utvecklingsverktyg, programvarukvalitet, ut-värdering av programvara, Kalmanlter, inbyggda system, Matlab, Ascet.

Sammanfattning

Den här rapporten jämför utvecklingsverktygen Ascet och Matlab med avseende på lämplighet att använda dem för modellbaserad utveckling av signalbehandlande applikationer för inbyggda system. Vi ställer upp för ändamålet relevanta kvali-tetsmått och genomför en implementation av en signalbehandlande algoritm kallad RAI, Roll Angle Indicator, i bägge verktygen. RAI är en algoritm som med hjälp av ett Extended Kalman Filter skattar rollvinkeln, det vill säga lutningen på en motorcykel. Information från implementationen används för att jämföra verktygen. This report compares the development-tools Ascet and Matlab with regard to their suitability as tools for model-based development of signal processing software for embedded systems. We derive appropriate metrics of quality and perform an im-plementation of a signal processing algorithm called RAI, Roll Angle Indicator, in both tools. RAI is an algorithm that with an Extended Kalman Filter estimates the roll-angle, in other words how much a motorcycle is leaning. Information from the implementation is used to compare the tools.

Keywords: Modellbaserad utveckling, utvecklingsverktyg, programvarukvalitet, utvärdering av programvara, Kalmanlter, inbyggda system, Matlab, Ascet.

Tackord

Först och främst vill vi tacka NIRA Dynamics AB för att de givit oss möjlighe-ten att utföra ett intressant och lärorikt projekt på deras företag. Ett stort tack till alla anställda på NIRA för kadisciplin och insikt i tårtateoremet. På konto-ret i Linköping vill vi speciellt tacka vår handledare Jonas Nilsson för stöd och hjälp under utvecklingen, Peter Lindskog, som varit vår Latex- och Matlabguru samt Markus Drevö, som varit till stor hjälp under arbetet med RAI-algoritmen. Göteborgskontoret får sina tack genom våra motorcykelknuttar Fredrik Assarsson och Greger Cronquist. Dessutom vill vi tacka Harald Lemcke på ETAS Gmbh i Tyskland samt Hossein Mousavi på Comsol AB, som gett oss den support vi har behövt för utvecklingen i Ascet respektive Matlab.

Från universitetet vill vi tacka vår andra handledare Jonas Elbornsson, vår ex-aminator Fredrik Gustafsson samt våra opponenter Mattias Backman och Andreas Adner. Ni höjde nivån på vår rapport.

Sist men inte minst vill vi tacka våra respektive sambos som stått ut med oss under detta arbete och dessutom kommit med glada tillrop och bra idéer.

Notation

Här beskrivs beteckningar och förkortningar som används i rapporten.

Symboler

x, X Denna notation används för vektorer, matriser och mängder.

Ordförklaringar och förkortningar

accelerometer Mätinstrument som mäter accelerationen.

CAN Controller Area Network

CVS Concurrent Versions System

DLL Dynamic Linked Library

DSP Digital Signal Processing

ESDL Java-liknande programspråk som används i Ascet.

Hardware-in-the-loop Koncept inom modellbaserad utveckling som arbetar med kodgenerering. Begreppet innebär att genererad kod kan köras direkt på målsystemet från modelleringsverktyget. Inga mellanliggande datorer eller verktyg behövs.

hjulslip När däcket på ett fordon glider i sidled.

ISO International Standard Organisation

mappning Logiska kopplingar mellan element i olika mängder.

MDC Measurement Data Converter

NVP NIRA Vehicle Platform, vårt målsystem i detta projekt.

PVCS Namn på program som används av Ascet

RAI Roll Angle Indicator

RS232 En standard för seriell kommunikation.

stack En lista som är så organiserad att det som sist matades in i listan tas ut först (sist-in-först-ut). Används av processorn bland annat för att hålla reda på subrutinreturer och avbrottshantering.

TIP Target Integration Package

toolbox Namn som i Matlab betecknar grupper av funktionalitet, som kan läggas till i verktyget.

UML Unied Modeling Language

Innehåll

1 Inledning 1 1.1 Uppdragsgivare . . . 1 1.2 Bakgrund . . . 1 1.3 Mål och syfte . . . 2 1.4 Målgrupp . . . 3 1.5 Läsanvisningar . . . 3 2 Teori 5 2.1 Algoritmbeskrivning . . . 5 2.1.1 Modellering . . . 6

2.1.2 Extended Kalman Filter . . . 8

2.2 Modellbaserad utveckling . . . 9

2.2.1 Bakgrund . . . 10

2.2.2 Denition av modellbaserad utveckling . . . 11

2.2.3 Ascet . . . 11 2.2.4 Matlab . . . 14 2.3 Programvarukvalitet . . . 16 2.3.1 Jämförelsekriterier . . . 19 3 Metod 23 3.1 Utvecklingsplan . . . 23 3.1.1 Två verktyg parallellt . . . 23 3.1.2 Två olika algoritmer . . . 23 3.1.3 Aktiviteter . . . 24 3.2 Jämförelsekriterier . . . 26 3.2.1 Funktionalitet . . . 26 3.2.2 Tillförlitlighet . . . 28 3.2.3 Eektivitet . . . 28 3.2.4 Användbarhet . . . 29 3.2.5 Underhållsmässighet . . . 30 3.2.6 Portabilitet . . . 30 vii

4 Utvärdering av Ascet 33 4.1 Verktyget . . . 33 4.1.1 Funktionalitet . . . 33 4.1.2 Tillförlitlighet . . . 42 4.1.3 Eektivitet . . . 43 4.1.4 Användbarhet . . . 43 4.2 Genererad kod . . . 48 4.2.1 Funktionalitet . . . 48 4.2.2 Eektivitet . . . 49 4.3 Sammanfattning . . . 51 5 Utvärdering av Matlab 53 5.1 Verktyget . . . 53 5.1.1 Funktionalitet . . . 53 5.1.2 Tillförlitlighet . . . 59 5.1.3 Eektivitet . . . 60 5.1.4 Användbarhet . . . 60 5.2 Genererad kod . . . 63 5.2.1 Funktionalitet . . . 63 5.2.2 Eektivitet . . . 64 5.3 Sammanfattning . . . 66 6 Jämförelse 69 6.1 Verktygen . . . 69 6.1.1 Funktionalitet . . . 69 6.1.2 Tillförlitlighet . . . 74 6.1.3 Eektivitet . . . 75 6.1.4 Användbarhet . . . 75 6.2 Genererad kod . . . 77 6.2.1 Funktionalitet . . . 77 6.2.2 Eektivitet . . . 77 6.3 Utvecklingsprocess . . . 79

7 Slutsatser och rekommendationer 81 7.1 Rekommendationer . . . 81

Kapitel 1

Inledning

Detta kapitel ger en introduktion till examensarbetet, dess syfte och mål, samt läsanvisningar för rapporten.

1.1 Uppdragsgivare

Examensarbetet är utfört på NIRA Dynamics AB i Linköping. Företaget utvecklar mjukvara som används i bland annat personbilar, lastbilar och motorcyklar. Genom att använda sig av signalbehandling, modellering och reglerteknik skapar de nya högteknologiska produkter för att öka säkerheten i framtidens fordon. Bland deras produkter nns däcktryckssystem, antispinnsystem och halkvarnare.

Mer information om NIRA Dynamics AB och deras produkter nns på företa-gets hemsida http://www.niradynamics.se.

1.2 Bakgrund

Under de senaste åren har det kommit ut antispinnsystem för bilar på marknaden. Detta system används för att motverka att bilens däck spinner loss då det till exempel är halt eller om bilen kör på grusväg, och därmed får bilen bättre fäste. Idén bakom spinndetektion är jämförelse av rullradie hos olika hjul.

Nu är denna typ av system även på gång hos motorcyklar. Det nns dock ett problem med antispinnsystem hos motorcyklar. På grund av att fram- och bakdäck inte ser likadana ut ändras rullradien olika på däcken när motorcykeln lutar. Detta gör att antispinnsystemet felaktigt kan tro att däcken spinner, trots att föraren bara svänger. Detta är en klart oönskad eekt. Av denna anledning har utveck-lingsingenjörer på NIRA Dynamics AB tagit fram en algoritm för skattning av en motorcykels rollvinkel. Projektet för skattning av rollvinkeln går under namnet RAI, Roll Angle Indicator.

Idag sker utveckling på företaget i tre steg. Först implementeras och testas algoritmen i Matlab. Därefter implementeras algoritmen i C-kod för PC. C-kod

för PC är kod skriven i C som kan kompileras och köras på en PC men som inte på något vis är optimerad eller designad för att fungera i en verklig produkt. C-koden testas via ett så kallat online-test, vilket innebär att en PC kopplas till ett fordon och information om fordonet läses under körning av via CAN-bussen, Controller Area Network, och körs sedan genom algoritmen. På CAN-bussen transporteras all elektronisk information som nns om fordonet.

När C-koden för PC anses vara tillräckligt robust och har tillräckligt med funk-tionalitet inleds det sista utvecklingssteget, optimeringen. C-koden optimeras nu till att endast använda heltal istället för yttal, att ej använda för mycket ROM och RAM samt att ej använda operationer som tar mycket processorkraft. Detta är mycket viktigt eftersom inbyggda system ställer höga krav på just dessa saker. Resultatet blir levererbar C-kod som fungerar på ett verkligt målsystem, typiskt en microprocessor.

Utvecklingsarbetet på NIRA sker idag alltså i tre steg med manuell konvertering mellan de olika stegen. Detta resulterar i en mycket eektiv kod i slutprodukten men kräver också en relativt lång utvecklingstid. Därför vill företaget undersöka hur modellbaserad utveckling fungerar i deras utvecklingsprocess.

Fler och er företag börjar använda sig av modellbaserad utveckling, denition nns i avsnitt 2.2. Ett välkänt modellspråk är UML, Unied Modelling Language. Dock är Matlab, se avsnitt 2.2.4, ett språk som oftast används inom signalbehand-lingsområdet och Ascet, se avsnitt 2.2.3, används mycket i bilindustrin. Därför ville uppdragsgivaren testa dessa två modellbaserade verktyg mot varandra.

Utvecklingsverktygen som utvärderats är alltså Etas Ascet samt Matlab med tilläggsverktygen Simulink och Real-Time Workshop Embedded Coder. Detta har gjorts genom att RAI-algoritmen implementerats i båda verktygen.

1.3 Mål och syfte

Projektets mål är att från en algoritmbeskrivning implementera två modeller av RAI, Roll Angle Indicator, genom modellbaserad utveckling. Implementationen ska ske i två modellbaserade utvecklingsverktyg: Ascet och Matlab med tilläggs-verktygen Simulink och Real-Time Embedded Coder. Från båda tilläggs-verktygen ska sedan körbar C-kod för ett målsystem kunna genereras. Utifrån de erfarenheter som dragits under utvecklingen ska rekommendationer för förbättringar av NIRA:s utvecklingsmodell tas fram.

Syftet med projektet är:

• Att utvärdera Ascets och Matlabs lämplighet som verktyg för modellbaserad utveckling.

• Att implementera RAI-algoritmen i Ascet och Matlab, från grundläggande modellering till generering av körbar C-kod på ett målsystem.

• Att utreda om modellbaserad utveckling kan förbättra NIRA:s process för utveckling av produkter.

1.4 Målgrupp

Läsaren av denna rapport förväntas ha en grundläggande förståelse för program-varuutveckling, kunskap om signalbehandling samt förståelse för de krav som ut-veckling för inbyggda system innebär.

1.5 Läsanvisningar

Denna rapport är indelad i följande kapitel:

Kapitel 1 - Inledning Kapitlet ger bakgrunden till och målet med arbetet. Kapitel 2 - Teori Kapitlet ger den teoretiska bakgrunden till rapporten. Här

de-nieras den algoritm som implementerades. Vidare förklaras vad modellba-serad utveckling innebär och en härledning av kvalitetsmåtten vi använder presenteras.

Kapitel 3 - Metod Här läggs grunden till hur projektet var upplagt och planerat samt hur utvärderingen skedde. Kapitlet innehåller även uppställning och denition av jämförelsekriterierna.

Kapitel 4 - Utvärdering av ASCET Kapitlet presenterar resultaten av utvär-deringen av Ascet med avseende på verktygen och den genererade koden. Kapitel 5 - Utvärdering av Matlab Kapitlet presenterar resultaten av

utvär-deringen av Matlab med avseende på verktygen och den genererade koden. Kapitel 6 - Jämförelse Här jämförs de två utvecklingsverktygen med avseende

på utvecklingsprocessen och den genererade koden.

Kapitel 7 - Slutsatser och rekommendationer Här presenteras rekommenda-tioner till företaget. Kapitlet innehåller även de slutsatser och erfarenheter vi dragit av projektet.

Kapitel 2

Teori

Safe upon solid rock the ugly house stands: Come and see my shining palace built upon the sand!  Edna St. Vincent Millay

Det här kapitlet beskriver den teori som ligger till grund för examensarbetet. En beskrivning av teorin bakom programvarukvalité genomförs. Kapitlet ger också en översiktlig bild av hur RAI-algoritmen fungerar, hur den är modellerad och hur uppdelningen i moduler har gjorts.

RAI-algoritmen och härledningen av den underliggande modellen är ursprung-ligen framtagen av utvecklingsingenjörer vid Nira Dynamics AB. Vårt arbete med algoritmen har varit att dokumentera, förna och implementera det arbete som redan utförts.

2.1 Algoritmbeskrivning

I det här avsnittet beskrivs den algoritm som skall implementeras med hjälp av utvecklingsverktygen. Algoritmen grundas på en fysisk modell, vilken används i ett Extended Kalman Filter. Beskrivningen är något summarisk, då syftet i första hand är att ge läsaren en uppfattning om vilken typ av operationer som är vanliga i applikationen, och en ngervisning om hur den fungerar.

Den principiella moduluppdelningen för hela systemet visas i gur 2.1. Mätsig-naler i form av accelerometervärden och motorcykelns hastighet, tas in från omgiv-ningen och förltreras. De ltrerade signalerna går genom skattaren av rollvinkeln och den senaste skattningen får passera en efterbehandlingsmodul. Efterbehand-lingsmodulen gör inte mer än konverterar resultatet från skattaren till den enhet som eventuella kringsystem vill ha dem i. Själva algoritmen som härleds i detta avsnitt implementeras i modulen i mitten.

Figur 2.1. Modulindelning av RAI-systemet, Kalmanltret som utför skattningen av rollvinkeln är blocket i mitten.

2.1.1 Modellering

För att kunna skatta rollvinkeln krävs någon form av modell som beskriver hur motorcykeln uppför sig och hur mätvärden från omvärlden hör ihop med den sökta rollvinkeln. Detta avsnitt beskriver hur modellen är framtagen.

Figur 2.2. Det kroppsxa koordinatsystemet för motorcykeln.

Ett koordinatsystem på motorcykeln denieras enligt gur 2.2. Vi kallar det-ta koordinatsystem för det kroppsxa koordinatsystemet. Detdet-ta koordinatsystem benner sig i ett yttre, xt koordinatsystem. Detta kallas för det xa koordinatsy-stemet.

Axlarna i det kroppsxa koordinatsystemet betecknas ˆx, ˆy och ˆz. Vinkelhastig-heterna runt axlarna betecknas ˙ϕ, ˙θ och ˙ψ runt respektive axel.

Två accelerometrar fästs på motorcykeln och sätts i ˆy respektive ˆz-led i det kroppsxa koordinatsystemet. Observera att ˆz pekar uppåt genom motorcykeln, och att origo ligger på en linje mellan hjulen. Anledningen till denna position är att det förenklar vissa ekvationer. Accelerometrarna fästs naturligtvis inte i origo, utan en bit upp på motorcykeln, så att deras z-koordinat är större än 0.

Det xa koordinatsystemet har en axel som är parallell med gravitationsfältets riktning.

Modellens syfte

Syftet med modelleringen är att härleda de ekvationer som behövs för att få en koppling mellan de uppmätta värdena från accelerometrarna och motorcykelns has-tighet och rollvinkeln.

Den sökta vinkeln, rollvinkeln, är ϕ. Denna fås som vinkeln mellan det xa koor-dinatsystemet, det vill säga gravitationsfältets riktningsvektor, och det kroppsxa koordinatsystemets ˆz-vektor.

Införda beteckningar

I tabell 2.1 införs de övriga beteckningar som används i ekvationerna.

Accelerometrarnas osetfel är ett additivt fel som kommer ur komponenternas temperaturberoende o dyl. Hastigheten u relativt ett xt koordinatsystem är inget annat än det vi normalt anser vara motorcykelns hastighet. De uppmätta värdena från accelerometrarna är de värden som vi på något sätt vill relatera till rollvinkeln.

Beteckning Beskrivning

δy yˆ-accelerometerns osetfel

δz zˆ-accelerometerns osetfel

g gravitationskonstanten

eay uppmätt värde från ˆy-accelerometern

eaz uppmätt värde från ˆz-accelerometern

zy yˆ-accelerometerns z-koordinat

zz zˆ-accelerometerns z-koordinat

u Hastighet i ˆx-led relativt ett xt koordinatsystem

Tabell 2.1. Beteckningar i ekvationerna som beskriver vår modell.

Antaganden

Tre antaganden som särskilt förenklar ekvationerna kan nämnas. Det ena är att mo-torcykeln åker på plan mark, θ = 0, det andra är att det inte nns något hjulslip1 i ˆy-led. Det tredje är att vi har försumbara hastigheter i ˆz-led. Detta medför att modellen inte hanterar akrobatkonster som hopp eller stegring till bakhjulskör-ning, samt att rollvinkeln denieras som vinkeln mellan den kroppsxa ˆz-axeln och gravitationsfältet.

Det nns naturligtvis er implicita antaganden. Vi bortser exempelvis från fjädringen, så att z-koordinaten för accelerometrarna kan betraktas som konstant i det kroppsxa koordinatsystemet.

Ekvationer

Ekvationerna bygger på transformation mellan koordinater i koordinatsystemet på motorcykeln och det xa koordinatsystemet. En fullständig härledning av dessa

transformationer åternns exempelvis i Wells [12, ss 139167]. Givet detta sätt att beskriva en koordinat på motorcykeln och de antaganden som beskrivits ovan erhålls följande uttryck för en partikels acceleration i ˆy- respektive ˆz-led.

ay = u ˙ψ − zyϕ + z¨ yψ˙2tan(ϕ) + g sin(ϕ) (2.1)

az = −u ˙ψ tan(ϕ) − zz( ˙ϕ2+ ˙ψ2tan(ϕ)2) + g cos(ϕ) (2.2)

Dessa uttryck utgör alltså kopplingen mellan uppmätta värden från accelero-metrarna och storheterna i modellen.

Två ekvationer räcker tyvärr inte, vi måste införa ytterligare en ekvation, som vi får som ett balansvillkor.

ay = C1ϕ + C¨ 2ψ˙2tan(ϕ) − C3u ˙ψ (2.3)

Ci är konstanter som beror på var på motorcykeln accelerometrarna är placerade.

Tyvärr är inte accelerometrarna ideala, varför vi får utöka modellen med två felkällor.

e

ay = ay+ δy (2.4)

e

az = az+ δz (2.5)

Där eaiär de mätvärden vi får tillgång till i verkligheten, och δi är ett

tidsvari-abelt fel. Diskussion

Modellen har följande karaktärsdrag:

• Ekvationerna är olinjära, vilket försvårar implementationen.

• Balansvillkoret gör att modellen inte fungerar om föraren exempelvis sätter ner foten.

• Modellen tar ingen hänsyn till vägens lutning så algoritmen mäter egentligen vinkeln mot gravitationsfältet.

2.1.2 Extended Kalman Filter

I detta avsnitt beskrivs Extended Kalman Filter (EKF) på operationsnivå. Syf-tet är att ge läsaren en god uppfattning om vilka operationer, och storleken på dem, som behövs för att implementera modellen som beskrivs i avsnitt 2.1.1. Ett Kalmanlter är ett optimalt linjärt lter för att skilja ut signaler ur brus. Filtret beskriver de ingående komponenterna på tillståndsform, vilket gör att mätsignal, intressanta signalkomponenter, brus och deras relationer beskrivs som vektor- och matrisekvationer.

Intresserade läsare åternner en grundligare beskrivning av teorin för Kalman-lter i bland annat böckerna Signalbehandling [4, ss 289336] och Linear Estima-tion [6]. EKF är en påbyggnad för icke-linjära problem och denna teori beskrivs utförligt i Linear Estimation [6, ss 310350].

Filtermodell och tillstånd

Tillståndsmodellen för ltret blir enligt nedan.

x(k + 1) = f (x(k)) + g(x(k))w(k) (2.6)

y(k) = h(x(k)) + e(k) (2.7)

Q = Cov(w) (2.8)

R = Cov(e) (2.9) Matriser i ltret

I ltret införs matriserna F , G, Q, R och P som i ett vanligt Kalmanlter, se Gustafssons bok Signalbehandling [4]. Den olinearitet vi har att ta hänsyn till är funktionen h(x) i ekvation 2.7.

Vektorn y är i detta specika fall det vi mäter från våra accelerometrar, och

h(x)blir följaktligen enligt ekvationerna 2.1, 2.2 och 2.3. Vi inför nu även matrisen

H(x), som på plats (i, j) är derivatan av funktionen yi = hi(x1, x2, . . . , xN) med

avseende på xj. Om vektorn y är M × 1 och vi har N tillstånd blir H alltså en

M × N matris med funktioner av x. H(x) måste därför uppdateras i varje iteration av algoritmen.

Operationer

Givet de införda matriserna ovan utförs nu följande operationer:

x = F x (2.10) P = F P FT + GQGT (2.11) Ω = HP HT _{+ R (2.12)} L = P HTΩ−1 (2.13) x = x + L(y − h(x)) (2.14) P = P − LHP (2.15) P = 0, 5(P + PT) (2.16)

Algoritmen innehåller matrisoperationerna multiplikation, addition, subtrak-tion, invertering och transponering. I varje steg av algoritmen måste också ett antal olinjära ekvationer evalueras, så att vektorn h(x) och matrisen H(x) är baserad på den nya skattningen av x.

2.2 Modellbaserad utveckling

Denitionen av modellbaserad utveckling lyser med sin frånvaro i litteraturen. Det här avsnittet ger, i väntan på en accepterad denition, en sammanställning över vad olika källor har att säga om detta sätt att utveckla programvara. Utgående från källorna presenterar vi en egen denition. Därefter presenterar vi hur Matlab och Ascet stödjer modellbaserad utveckling.

2.2.1 Bakgrund

Det är nästan omöjligt att beskriva modellbaserad utveckling utan att nämna verk-tygens graska gränssnitt. Man får intuitivt känslan av att modellbaserad utveck-ling är synonymt med diagramritande, som motsats till kodskrivande. Klassdiagram och tillståndsmaskiner ger en abstrakt beskrivning över det tänkta systemets data och beteende och verktygen ses som graska domänspecika programmeringsspråk. Att använda modeller som utgångspunkt för programvaruutveckling innebär mer än att välja att rita diagram istället för att skriva programkod. Att välja utvecklingsparadigm innebär att utvecklingsprocessen, och därmed slutprodukten, påverkas. Schätz et al. [9] skriver om möjligheterna att rita tillståndsmaskiner och liknande graskt:

That these abstractions have intuitive graphical descriptions is helpful for acceptance, but not essential for the model concept.

De vill alltså tona ner den graska miljön och istället betona andra koncept i den modellbaserade utvecklingen:

• Modellbaserad utveckling tillåter en explicit beskrivning av utvecklingsakti-viteter. Aktiviteterna är, eller kan göras, repeterbara och spårbara.

• Modellbaserad utveckling begränsar utvecklarens frihetsgrader jämfört med handknackad kod, på samma sätt som programmering i C begränsar ut-vecklarens frihetsgrader jämfört med programmering i assembler.

• Produkten modelleras som entiteter, relationer mellan dessa entiteter och mellan entiteter och omgivningen. De aktiviteter som denierar utvecklings-processen (processmodellen) har en stark koppling till dessa entiteter. Kopp-lingen mellan produktmodellen och utvecklingsarbetet är följaktligen en grund-bult i modellbaserad utveckling.

På nätet [10] hittar vi ett citat av Dr. Roger Schultz från Rockwell Collins' Advanced Technologies Center:

Model-based development [MBD] uses an abstract model of a product or system to allow rigorous analysis and testing to verify and valida-te, at dierent levels, system performance under diverse conditions and stimuli. . . . MBD is an object-oriented, non-code approach to produ-cing and testing system entities, associations, interface denitions, and system states and transitions. It's simply more cost eective to build models to evaluate system capabilities, performance, and appropriate-ness than to build the system, or even part of the system, to make the same determinations.

Dr. Schultz lägger alltså vikten på produktmodellens förmåga att stödja analys och testning på alla nivåer, samt kostnadseektiviteten i att producera modeller istället för kod.

2.2.2 Denition av modellbaserad utveckling

Med ovanstående som bakgrund presenteras vårt förslag till denition av modell-baserad utveckling.

Modellbaserad utveckling är när utvecklingsprocessen utgår från ska-pandet av en abstrakt, tidigt testbar, modell av slutprodukten. Model-len består av tydligt avgränsade entiteter, med inbördes relationer och relationer till omgivningen. Modellen är exekverbar. Utvecklingsproces-sens aktiviteter drivs av modellen och modellens entiteter. Slutproduk-ten kan genereras ur modellen.

Ett verktyg som grundar sig på vår denition har följaktligen krav på sig att:

• Ge möjlighet att skapa modeller och att deniera entiteter och deras relatio-ner till andra entiteter och till omgivningen.

• Ge utvecklaren av modellen en rimlig abstraktionsnivå.

• Ge möjlighet att simulera modellens funktionalitet och prestanda under ut-vecklingen.

• Ge möjlighet att generera en slutprodukt ur modellen.

Syftet med att använda modellbaserad utveckling bör vara kostnadseektivitet.

2.2.3 Ascet

Ascet är ett modellbaserat utvecklingsverktyg framtaget av det tyska företaget Etas Gmbh. Den tänkta användningen av Ascet är framförallt utveckling av ECU (Engine Control Unit) inom bilindustrin. Etas har också ett egenutvecklat real-tidsoperativsystem kallat Ercos. Programvara framtagen i Ascet skall vara ex-tra lätt att integrera mot Ercos. Mer information om Etas och Ascet nns på http://www.etas.de.

Modellering

Modelleringen av funktionalitet sker på tre sätt. Graskt, då lägger utvecklaren till variabler och operatorer i ett diagram och tilldelar varje operation ett sekvensnum-mer. Det andra alternativet är att programmera i ett språk som kallas ESDL. ESDL är till syntaxen likt Java, men är mycket begränsat i övrigt. Det går till exempel inte att ärva funktionalitet eller att överlagra metoder. Skillnaden mellan ESDL och det graska sättet att deniera funktionalitet är att ESDL stödjer er kraft-fulla ödesbeskrivande programkonstruktioner, till exempel for-loopar. Det sista alternativet är att integrera C-kod direkt i modellen, vilket kan vara användbart för drivrutiner för speciell hårdvara eller för riktigt optimerad funktionalitet. Den graska miljön visas i gur 2.3.

Ascet låter användaren gruppera sin funktionalitet i form av komponenter. En komponent kan vara en klass eller en modul, bägge går att deniera graskt, i ESDL

Figur 2.3. Ascets graska modelleringsmiljö.

eller som integrerad C-kod. Detta ger sex olika kombinationer för utvecklaren att välja bland. Vad utvecklaren väljer beror på hur komponenten skall användas, och hur den skall integreras mot omgivningen. Moduler utför sin funktionalitet i form av en eller era processer, kommunicerar via meddelanden och kan bara instantieras en gång. Klasser å andra sidan har en eller era metoder, kommunicerar via argument till (och returvärden från) metoderna samt kan ha era instanser.

Graska beskrivningar av moduler och klasser går att gruppera hierarkiskt, något som möjliggör god överblick över systemet. Uppdelning i hierarkier är rent kosmetisk, det påverkar inte kodgenereringen på något sätt.

Funktionaliteten, i form av de relativt fristående komponenterna, instantieras i ett projekt. Projektet håller ihop komponenterna och där låter Ascet utvecklaren deniera den information som komponenterna inte kan eller bör veta något om. Exempel på sådan information är denition av kommunikation mellan komponenter och schemaläggning av processerna.

Operationer

I grundutförande erbjuder Ascet inga komplexa operationer, utan är istället mo-dulärt uppbyggt. Som utvecklare går det att specicera funktionalitet med hjälp av variabler, parametrar, vektorer och matriser. Till dessa databehållare nns de grundläggande aritmetiska operationerna addition, subtraktion, multiplikation och division. Operationerna arbetar enbart på skalärer. Programödet styrs genom jäm-förelseoperatorer, if- och while-satser i kombination med tilldelning av sekvensnum-mer. Sekvensnumren beskriver i vilken ordning den uppritade funktionaliteten ska utföras. Vidare nns en- och tvådimensionella uppslagstabeller för att modellera

y = f (x)och y = f(x, z).

Med programpaketet följer en mängd fördenierade block med standardfunktio-nalitet, till exempel lågpasslter, multiplexrar, räknare, signumfunktion etc. Dessa är tänkta att snabba på utvecklingsarbetet.

Kodgenerering

Koncepten som Ascet använder för att generera kod presenteras i gur 2.4. Mo-dellen denieras i den fysiska världen. För att Ascet ska kunna generera körbar C-kod får utvecklaren deniera en så kallad implementation, också kallad imple-mentationsspecikation, för modellen. Detta innebär att man som utvecklare får tala om för verktyget hur varje variabels fysiska värde ska representeras i datorn, till exempel om variabeln representeras som xed-point med tio bitars decimaler, eller som 64-bitars yttal. Kodgenereringen använder sedan denna information för att generera kod som undviker spill2 _{och andra problem.}

Figur 2.4. Beskrivning av hur utvecklaren går från modell till genererad kod i Ascet.

2_{Spill denieras som att resultatet av en beräkning överskrider eller underskrider det tillåtna} talområdet. Termerna over- och underow används på engelska

Modellen och implementationsspecikationen är i sig oberoende av målsyste-met. Vilket målsystem som kod ska genereras för denieras separat, samma modell och implementation kan därför användas för att generera kod för olika målsystem.

2.2.4 Matlab

Matlab är ett verktyg som används för matematiska beräkningar, analys, virtuali-sering och utveckling av algoritmer och tillverkas av det amerikanska företaget The MathWorks. En av programmets stora fördelar är att det enkelt går att represente-ra och görepresente-ra beräkningar med matriser och vektorer, som oftast är en nödvändighet under arbete med matematiska funktioner. Programmet har många olika tilläggs-verktyg för olika typer av utveckling. Vi har endast varit intresserade av möjligheten att utveckla modellbaserat och för att sedan kunna generera kod. För att kunna utföra denna utvecklingsmetodik i Matlab användes tilläggsverktyget Simulink där all modellering och simulering utfördes. Utifrån modellen skulle vi sedan generera kod till ett inbyggt system och för att kunna göra detta användes tilläggsverktyget Real-Time Workshop Embedded Coder.

Modellering

Simulink är det påbyggnadsverktyg som gör det möjligt att arbeta med modellbase-rad utveckling i Matlab. Utvecklaren kan representera sina matematiska beräkning-ar graskt, genom att dra signaler mellan blocken som i sin tur utför operationer på signalen. Simulink ger utvecklaren möjligheten att graskt modellera, analyse-ra och simuleanalyse-ra sina matematiska formler. Modelleringen görs genom att danalyse-ra valt block från biblioteksutforskaren ut på arbetsytan där modellen ska implementeras. I gur 2.5 ges en bild över hur en enkel modell kan se ut.

Figur 2.5. Utvecklingsmiljön i Simulink [7].

Även Simulink har användbara påbyggnadsverktyg. Dels extra blockset innehål-lande er funktioner så som Aerospace- och Fixed Point-blockset som beskrivs ne-dan, men även mer omfattande verktyg som Stateow som möjliggör

tillståndsimple-mentering. För att förenkla själva modelleringen kan modellen delas in i subsystem. Detta görs enkelt genom att välja de block som ska ingå och sedan välja Create subsystem i menyn. Genom att skapa subsystem får utvecklaren en betydligt bättre överblick över modellen och den blir lättare att felsöka. Skapandet av subsystem påverkar bara modellen graskt och har ingen inverkan på varken funktionalitet eller senare kodgenerering.

Operationer

De operationer som stöds i Matlab och därmed i Simulink är de esta, både enkla och mycket avancerade. Verktyget har stöd för såväl matris- som skaläroperationer. Så klart nns de grundläggande aritmetiska operationerna men också specialfunk-tioner som diverse ltreringar, signalkvantisering, transformaspecialfunk-tioner etc. Alla ope-rationer, i Simulink kallade block, är samlade i en så kallad biblioteksutforskare, se gur 2.6.

Figur 2.6. Biblioteksutforskaren i Simulink [7].

I utforskaren är blocken grupperade i så kallade blockset som är specialiserade på olika användningsområden. Ett exempel är Aerospace-blockset som innehåller operationer som används ofta bland utvecklare inom ygindustrin, ett annat är Fixed Point-blockset som möjliggör heltalssimulering i Simulink. Det mest använda är dock Simulinks standardbibliotek där de vanligaste blocken, så som matematiska

operationer, källor och sänkor, nns samlade.

Simulink innehåller även ett block kallat system-function builder, även kallat s-function builder. Detta block förser utvecklaren med en gränssnitt för att kunna integrera egenskriven kod med Simulink-modellen. Tack vare detta kan utvecklaren integrera i princip vilken funktionalitet han vill, vilket ökar Simulinks användbarhet mycket.

Kodgenerering

Det tredje betydelsefulla verktyget i detta sammanhang bredvid Matlab och Simu-link är Real-Time Workshop Embedded Coder. Detta verktyg gör det möjligt att generera kod från en Simulink-modell till ett inbyggt system. Kraven på koden till ett inbyggt system är mycket höga med tanke på det lilla lagrings- och beräknings-utrymme som nns tillgängligt. Oftast nns det krav på att alla operationer ska vara heltalsoperationer och så är de allmänna kraven på minneseektivitet höga. I Real-Time Workshop Embedded Coder ställer utvecklaren in mot vilken typ av målsystem som koden ska anpassas. Verktyget innehåller några fördenierade mål-system så som Texas Instruments C6000- och Motorolas MPC555-processor. För de målsystem som inte nns fördenierade får utvecklaren själv deniera de krav som processorn ställer så som ordlängden på datatyper, datalagring och så vidare. Till hjälp för novisen nns även en så kallad Modellassistent som ger ett använ-darvänligt gränssnitt för att ändra och föreslå ändringar till kodgenereringen med hjälp av utvecklarens önskemål. Till exempel om utvecklaren väljer att minimera användning av RAM så återanvänds burar vid lagring av data. Hur bra Real-Time Workshop Embedded Coder är, är avgörande för hur Matlab kommer att klara sig i utvärderingen mot ASCET.

I gur 2.7 presenteras en översiktsbild över hur Matlab, Simulink och Real-Time Workshop Embedded Coder relaterar till varandra för att generera kod.

2.3 Programvarukvalitet

Programvarukvalitet kan betyda många olika saker. Allt från kostnaden per kodrad till användarvänlighet hos programmet som utvecklats. Området som ämnet täcker är enormt och ibland även svårt att deniera. Hur mäts egentligen återanvändbar-het eller vad är det som bestämmer att en viss produkt har bättre kvalitet än en annan? Det uppenbara är att det ena programmet fungerar bättre än det andra, men om de fungerar likvärdigt, hur bedöms kvaliteten då? Kvalitet betyder förstås olika saker beroende på vem som tillfrågas. Företagsledningen anser antagligen att kvalitet beror på hur mycket varje projekt kostar, hur produktiva de anställda är eller om kunden blir nöjd. En programvaruutvecklare å andra sidan bedömer för-modligen kvalitet genom att se om kraven är testbara, om alla fel är hittade eller om projektets mål har uppfyllts. [2]

Mätningar på programvarukvalitet kan göras objektivt eller subjektivt. Den ob-jektiva mätningen innebär att ingen personlig bedömning är med i resultatet utan att det endast beror på objektet som mäts. En objektiv mätning ska kunna göras

Figur 2.7. En beskrivning av hur verktygen i Matlab interagerar för att gå från modell till genererad kod.

om era gånger och resultatet ska vara samma vid varje mätning, inom mätnings-felets gränser. Exempel på denna typ av mått är rader kod och leveransdatum.

Den subjektiva mätningen är motsatsen till den objektiva. Personen som utför mätningen är den som gör själva bedömningen som resulterar i mätningens resultat. Mätningen beror både på vem som utför mätningen och från vilken synvinkel den görs. Exempel på vad som mäts subjektivt är kompetensen hos personalen eller användbarheten hos programmet.

Vår utvärdering kommer till största delen att grunda sig på subjektiva mätning-ar så som användmätning-arvänlighet och inlärning, men även objektiva mätningmätning-ar kommer att göras inom till exempel funktionalitetsområdet. [13]

Områden där mjukvara kan utvärderas kan enligt Fenton [2] delas in i följande tio områden:

• Projektets kostnad och personalens arbetsinsats.

• Personalens produktivitet.

• Insamling av data som ska utvärderas.

• Kvalitet på mjukvaran.

• Pålitlighet hos mjukvaran.

• Prestanda hos mjukvaran.

• Struktur och komplexitet hos mjukvaran.

• Företagets kapacitet att utveckla bra mjukvara.

• Projektstyrning.

Utvärderingen snuddar vid de esta av dessa områden men fokus ligger på de delar som ligger närmast utvecklingen av och kvaliteten på produkten. Vi har valt att bygga vår utvärdering på standarden ISO 9126 [5]. Den är en interna-tionell standard för utvärdering av mjukvarukvalitet. Detta innebär att metoden är välbeprövad och strukturerad, vilket gjorde att vi valde att använda den i vår utvärdering. ISO står för International Organization for Standardization och de ansvarar för att skapa och sprida standarder världen över. Denna standard bygger ursprungligen på en modell av McCall från 1977, se gur 2.8, som åternns i boken Software metrics, a practical approach [2, gur 9.2]. McCalls modell är något större än ISO 9126 men ger en bra helhetsbild över standarden och det som den är tänkt att mäta. Rutorna markerade med grått är fem av de sex kriterierna som ingår i ISO-standarden. Den som saknas är funktionalitet. En mer ingående beskrivning av ISO 9126 nner du i avsnitt 2.3.1, Jämförelsekriterier.

Figur 2.8. McCalls modell som denierar kvalitetsmått. Rutor markerade med grått ingår i ISO 9126. [2, gur 9.2]

faktorn underhåll och sedan visat hur den skulle kunna delas in i mindre delar genom kriterier, mätningar och så småningom relaterade mätvariabler, se gur 2.9.

Figur 2.9. En detaljerad beskrivning av kvalitetsmåttet underhåll. [2, gur 9.3]

Denitionen av mjukvarukvalitet i ISO 9126 delas upp enligt följande:

• Funktionalitet • Tillförlitlighet • Eektivitet • Användbarhet • Underhåll • Portabilitet

Enligt standarden ska alla delar inom mjukvarukvalitet kunna beskrivas med hjälp av en eller era av dessa sex faktorer.

2.3.1 Jämförelsekriterier

De sex områdena som mjukvarukvalitet kan delas upp i och som denierats ovan kan i sin tur delas upp i underområden som mer specikt denierar det de är tänkta att mäta. Dessa underrubriker nns specicerade i en bilaga till standarden ISO 9126 men de tillhör inte ociellt den internationella standarden [2]. Nedan be-skrivs underrubrikerna mer ingående enligt en översättning från EAGLES, Expert Advisory Group on Language Engineering Standards, hemsida [1] som grundar sig i denitionerna av underrubrikerna i bilagan till ISO 9126.

Funktionalitet

Lämplighet Beskriver hur lämpliga de bentliga funktionerna är för de uppgifter de ska utföra.

Noggrannhet Beskriver hur bra mjukvaran producerar rätt resultat. Kompatibilitet Avser förmågan hos mjukvaran att följa

applikationsrela-terade standarder, konventioner och liknande föreskrifter. Interoperabilitet Avser förmågan att interagera med specicerade system. Säkerhet Beskriver förmågan att förebygga otillåten access till

pro-gram och data. Tillförlitlighet

Mognad Avser avbrottsfrekvensen orsakade av fel i mjukvaran. Feltolerans Beskriver mjukvarans förmåga att hålla en viss

prestanda-nivå då fel under körning uppstår.

Återhämtning Mjukvarans förmåga att återgå till sin normala prestanda-nivå efter ett avbrott och att reparera påverkad data. Eektivitet

Tidsanvändning Avser mjukvarans förmåga att tillgodose krav på svarstid, processtid, överföringshastigheter etc.

Resursanvändning Avser mjukvarans eektivitet att utnyttja resurser, så som I/O- och lagringsenheter.

Användbarhet

Förståelighet Till vilken grad användaren kan känna igen och ta till sig de logiska koncept som mjukvaran presenterar.

Inlärning Beskriver hur svårt användaren har att lära sig använda mjukvaran.

Manövrerbarhet Beskriver graden av arbete som krävs för att hantera ope-rationella kontrollaspekter hos mjukvaran, till exempel sä-kerhetskopiering och lhantering.

Underhåll

Analyserbarhet Beskriver graden av arbete som behövs för att hitta och diagnostisera körningsfel i mjukvaran.

Modierbarhet Beskriver graden av arbete som behövs för att modiera, ta bort fel eller anpassa mjukvaran till omgivningen. Stabilitet Beskriver risken för oväntade fel vid modieringar. Testbarhet Beskriver graden av arbete för att validera/testa den

Portabilitet

Anpassningsbarhet Mjukvarans förmåga att anpassa sig till olika miljöer. Installerbarhet Beskriver graden av arbete som behövs för att installera

mjukvaran i en specik miljö.

Överensstämmelse Beskriver mjukvarans förmåga att följa de standarder och konventioner som avser portabilitet.

Ersättningsbarhet Mjukvarans förmåga att ersätta annan specicerad mjuk-vara i dess egen miljö.

Kapitel 3

Metod

A fool-proof method for sculpting an elephant: rst, get a huge block of marble; then you chip away everything that doesn't look like an elephant.  From the fortune database

Det här kapitlet beskriver metoden som använts för att uppnå målet. Först be-skrivs hur utvecklingsarbetet lagts upp, därefter vad vi har valt att använda för jämförelsekriterier.

3.1 Utvecklingsplan

Det här avsnittet ger en översiktlig bild av hur projektet lagts upp. Dels hur vi arbetar men också med vad vi har arbetat och vad dessa aktiviteter innebär.

3.1.1 Två verktyg parallellt

Vi valde att implementera i verktygen parallellt, en implementation i Matlab med tilläggsverktyget Simulink och den andra i Ascet. Motivet till detta var att vi inte skulle ge något av verktygen fördelen av att vi behärskade problemen innan imple-mentationen. Nackdelen med detta sätt är att vissa av mätningarna, till exempel utvecklingstid, riskerar att bli beroende av skillnader i vår individuella skicklighet som programvaruutvecklare.

3.1.2 Två olika algoritmer

Utgående från den modell som tagits fram i avsnitt 2.1.1 kunde vi välja att imple-mentera många olika algoritmer. Detta baserades på att vi kunde välja olika till-ståndsvariabler, där avvägningen blivit mellan noggrannhet och eektivitet. Valdes färre tillstånd blev matriserna mindre, och därmed minskade beräkningsbördan.

Implementationen lades upp så att två algoritmer implementerades, den ena har sju tillstånd och den andra har fyra tillstånd. Anledningarna till detta upplägg var

två. Algoritmerna är av naturliga skäl snarlika och genom att implementera den ena algoritmen först kunde vi testa hur bra verktygen är på att hantera förändringar av existerande block. Den andra anledningen var att vi räknade med att ha lärt oss verktygen så bra efter implementationen av algoritmen med sju tillstånd, att en mätning av utvecklingstiden för algoritmen med fyra tillstånd var relevant.

3.1.3 Aktiviteter

Det här avsnittet ger en översikt över de aktiviteter som utförts. Vi ger både en översiktlig beskrivning i kronologisk ordning och en mer detaljerad beskrivning och motiv för de större aktiviteterna och hur vi lagt upp genomförandet.

Kronologisk ordning 1. Planering

Projektplan och kravspecikation skrevs. Litteraturstudier och val av metod gjordes.

2. Implementation av algoritmen med sju tillstånd

Algoritmen med sju tillstånd implementerades i båda verktygen parallellt. Under implementationen dokumenterades erfarenheter som behövdes till mät-ningen enligt avsnitt 3.2.

3. Implementation av testmiljö

Implementationsarbete för att kunna funktionstesta algoritmerna. Målsyste-met sätts upp och kopplas in. Testmiljön återanvändes senare för att testa algoritmen med fyra tillstånd.

4. Test av algoritmen med sju tillstånd

Den kod som genererats av verktygen testades i testmiljön. 5. Implementation av algoritmen med fyra tillstånd

Utgående från den färdiga implementationen av den ursprungliga algoritmen med sju tillstånd implementerade vi den optimerade algoritmen. Denna al-goritm har endast fyra tillstånd. Under implementationen dokumenterades erfarenheter som behövdes till mätningen enligt avsnitt 3.2.

6. Test av algoritmen med fyra tillstånd

Den kod som genererats av verktygen testades i testmiljön. 7. Utvärdering

Vi sammanställde erfarenheterna från utvecklingen och gjorde kvalitativa mätningar på den kod som verktygen genererat.

Implementation

Implementationen genomfördes på ett sådant sätt att verktygens stöd för den mo-dellbaserade paradigmen testades. Utgångspunkten var en specikation i form av en matematisk formel och specicerade yttre gränssnitt.

Arbetet innefattade kontinuerliga simuleringar av delar av modellen för att inkrementellt utvärdera prestanda och funktion.

Testarbete

Testarbetet syftade till att skapa en testmiljö där algoritmerna kunde matas med tidigare insamlad mätdata. Vi kunde i testmiljön veriera att den genererade koden överhuvudtaget fungerade. Testmiljön bestod av en bärbar dator, en stationär dator och NVP:n som var vårt målsystem och som kopplades till båda dessa datorer. NVP:n var vårt målsystem som innehöll vår processor Inneon C167, de program och hårdvara vi behövde för att köra den samt serieportar för kommunikation med omvärlden.

På den bärbara datorn hade vi en kompilator kallad Tasking som skötte kompi-leringen och ett program kallat WinNap som kontrollerade kommunikationen med NVP:n. Den bärbara datorn kopplade vi sedan ihop med NVP:n via en RS232-kabel för att kunna kompilera och ladda ner kod till målsystemet. Ytterligare en seriekabel sattes upp mellan NVP:n och den stationära datorn.

Genom ett egenskrivet program i Matlab kunde vi sedan skicka indata från den stationära datorn via seriekabeln till NVP:n som sedan skickade tillbaka resultatet till den stationära datorn för fortsatt analys, se gur 3.1. Detta gjorde att algo-ritmernas skattningar av rollvinkeln kunde jämföras med en referenssignal och vi kunde se hur heltalsimplementationen påverkade noggrannheten.

3.2 Jämförelsekriterier

I detta kapitel redovisas de konkreta kriterier vi använde oss av för att jämföra verktygen och en beskrivning av hur vi mätte data. Kriterierna baseras på den teori som redovisats i avsnitt 2.3.

Vi skiljer på två saker, mått på verktyget i sig, samt på det som verktyget levererar, alltså den genererade koden. I tabellerna nedan markeras vad vi mätt i de fall det inte framgår av mätvariabeln.

Majoriteten av jämförelserna är subjektiva, endast tids- och resursanvändningar under rubriken Eektivitet kan mätas objektivt. Detta bör läsaren ha i åtanke under studien av resultatet, som presenteras i kapitel 4 och 5.

3.2.1 Funktionalitet

Området funktionalitet är ett mått på programvarans funktion. Om den gör vad den är tänkt att göra, helt enkelt. Funktionalitet mäts enligt tabellerna nedan. Lämplighet

Lämplighet avser hur väl verktyget är lämpat för användning i signalbehandlingsap-plikationer för inbyggda system i fordon. Vilka områden som undersöktes inom lämplighet och vad som utvärderades presenteras i tabell 3.1.

Benämning Beskrivning kontext

Modellinformation Vilken information om modellen klarar

verktyget av att visa? verktyg

Operationer Vilka operationer stödjer verktyget? verktyg Simulering Hur väl klarar verktyget av att simulera

och debugga modellen? verktyg

Utvecklingstid Hur snabbt går det att utveckla en

appli-kation i verktyget? verktyg

Fleranvändarstöd Hur väl stödjer verktyget kraven på att e-ra personer ska kunna arbeta i samma pro-jekt?

verktyg Heltalskonvertering Hur smidigt går det att konvertera en

mo-dell i yttal till heltal? verktyg

Heltalsimplementation Hur fungerar det att generera heltalskod

från modellen? verktyg

Noggrannhet

Noggrannhet avser hur väl verktyget möter kraven på att resultatet är rätt. Vilka områden som undersöktes inom noggrannhet och vad som utvärderades presenteras i tabell 3.2.

Benämning Beskrivning kontext

Simulering Hur väl stämmer simulering i verktyget överens med resultatet från den genererade koden? Är verktyget konsekvent?

verktyg Läsbar kod1 _{Hur läsbar är den genererade koden? kod} Optimeringsmöjlighet Vilka möjligheter ger verktyget till att

op-timera den genererade koden? verktyg

Tabell 3.2. Mått på funktionalitetnoggrannhet

Kompatibilitet

Kompatibilitet avser hur väl verktyget följer konventioner, standarder och liknan-de föreskrifter. Vilka områliknan-den som unliknan-dersöktes inom kompatibilitet och vad som utvärderades presenteras i tabell 3.3.

Benämning Beskrivning kontext

Gränssnitt Följer verktygets gränssnitt standard för

windowsgränssnitt? verktyg

Tabell 3.3. Mått på funktionalitetkompatibilitet

Interoperabilitet

Interoperabilitet avser förmågan hos verktyget att interagera med andra specice-rade system. Vilka områden som undersöktes inom interoperabilitet och vad som utvärderades presenteras i tabell 3.4.

Benämning Beskrivning kontext

Versionshantering Hur väl stödjer verktyget användning av externa versionshanteringssystem såsom CVS och Sourcesafe?

verktyg Import/export av

da-ta Vilka möjligheter nns att föra data in ochut ur verktyget för extern behandling? verktyg

Tabell 3.4. Mått på funktionalitetinteroperabilitet

3.2.2 Tillförlitlighet

Tillförlitlighet är ett mått på hur programvara beter sig vid fel, hur ofta det blir fel med mera. Det är svårt och tidsödande att provocera fram fel, vilket gjorde att vi innan genomförandet inte var säkra på att få någon mätdata alls. Tillförlitlighet mäts enligt tabellerna nedan.

Mognad

Mognad mäter hur ofta fel i programvaran uppstår. Vilka områden som undersöktes inom mognad och vad som utvärderades presenteras i tabell 3.5.

Benämning Beskrivning kontext

Antal krascher Hur många gånger under projektet

kra-schade eller låste sig verktygen? verktyg Fel i kod Under vilka omständigheter är den

genere-rade koden felaktig? verktyg

Tabell 3.5. Mått på tillförlitlighetmognad

Feltolerans

Feltolerans avser hur väl programvaran fungerar när ett fel väl uppstår. Vilka om-råden som undersöktes inom feltolerans och vad som utvärderades presenteras i tabell 3.6.

Benämning Beskrivning kontext

Skademinimering Hur väl klarar verktyget att begränsa

ska-dorna av en krasch? verktyg

Felinformation Hur väl informerar verktyget användaren om vad som har hänt, och vilka åtgärder som kan vidtas?

verktyg

Tabell 3.6. Mått på tillförlitlighetfeltolerans

Återhämtning

Återhämtning avser hur väl programvaran fungerar efter att ett fel uppstått. Vilka områden som undersöktes inom återhämtning och vad som utvärderades presente-ras i tabell 3.7.

3.2.3 Eektivitet

Eektivitet mäter hur väl programvara möter tids- och resurskrav. Vi var mest intresserade av att mäta eektivitet på den genererade koden, då det fanns farhågor om att detta var verktygens akilleshäl.

Benämning Beskrivning kontext Reparation Hur väl klarar verktyget att reparera

ska-dorna av en krasch? verktyg

Tabell 3.7. Mått på tillförlitlighetåterhämtning

Tidsanvändning

Tidsanvändning avser hur väl programvaran möter krav på snabb exekvering. Vilka områden som undersöktes inom tidsanvändning och vad som utvärderades presen-teras i tabell 3.8.

Benämning Beskrivning kontext

Kodeektivitet Hur många instruktioner behöver den ge-nererade koden för en iteration i kalman-ltret?

kod

Tabell 3.8. Mått på Eektivitettidsanvändning

Resursanvändning

Resursanvändning avser hur eektivt programvaran utnyttjar resurser. Vilka områ-den som undersöktes inom resursanvändning och vad som utvärderades presenteras i tabell 3.9.

Benämning Beskrivning kontext

Kodeektivitet Hur stor plats upptar programmet i

ROM/RAM? kod

Verktygseektivitet Vad är systemkraven för att kunna

använ-da verktyget? verktyg

Tabell 3.9. Mått på Eektivitetresursanvändning

3.2.4 Användbarhet

Användbarhet är ett mått på hur väl programvaran möter kraven på användning av människor med relevant kompetens. I det här projektet har dessa mått tagits med utgångspunkt i någon med datavetenskaplig eller datateknisk kompetens eller annan erfarenhet av programmering och handhavande av datorer. Fokus ligger på de vanligast förekommande användningsområdena.

Förståelighet

Förståelighet mäter till vilken grad användaren kan känna igen och ta till sig de logiska koncept och dess tillämpbarhet som mjukvaran presenterar. Vilka områ-den som undersöktes inom förståelighet och vad som utvärderades presenteras i tabell 3.10.

Benämning Beskrivning kontext

Struktur Är det lätt för en användare att hitta sökt

funktion i programmet? verktyg

Relevanta koncept Är koncepten som används relevanta, och stämmer de väl överens med de allmänt ve-dertagna denitionerna?

verktyg

Tabell 3.10. Mått på användbarhetförståelighet

Inlärning

Inlärning mäter hur svår programvaran är att lära sig att använda. Vilka områden som undersöktes inom inlärning och vad som utvärderades presenteras i tabell 3.11.

Benämning Beskrivning kontext

Hjälpfunktion Finns det en hjälpfunktion och är den i

så-dant fall ett bra stöd för inlärning? verktyg Manualer Är manualerna användbara vid inlärning? verktyg

Komplexitet Är abstraktionsnivån bra? verktyg

Tabell 3.11. Mått på användbarhetinlärning

Manövrerbarhet

Manövrerbarhet mäter graden av arbete som krävs för att administrera och kon-trollera programvaran. Vilka områden som undersöktes inom manövrerbarhet och vad som utvärderades presenteras i tabell 3.12.

3.2.5 Underhållsmässighet

Underhållsmässighet mäter hur svårt det är att underhålla en installation av pro-gramvaran. Detta är ett mindre prioriterat område i projektet, varför vi har valt att inte mäta dessa delar.

3.2.6 Portabilitet

Portabilitet mäter bland annat hur lätt programvaran är att anpassa till olika yttre miljöer, exempelvis olika operativsystem. Det mäter också svårigheter att installera

Benämning Beskrivning kontext Inställningar Är verktygets inställningar lätta att

anpas-sa till olika målsystem när det gäller kod-generering?

verktyg Säkerhetskopiering Hur väl möter verktyget krav på

sä-kerhetskopiering, återställning av säker-hetskopior etc?

verktyg Skriptning Hur väl möter verktyget krav på att kunna

skriptas, det vill säga styras från externa program?

verktyg

Tabell 3.12. Mått på användbarhetmanövrerbarhet

och ersätta programvaran. Detta är ett mindre prioriterat område i projektet, varför vi har valt att inte mäta dessa delar.

Kapitel 4

Utvärdering av Ascet

Detta avsnitt beskriver resultatet av utvärderingen av Ascet som gjorts med grund i de jämförelsekriterier som ställdes upp i avsnitt 3.2. De mått som åternns i tabellerna skrivs med kursiv stil så att läsaren får en återkoppling till underrubri-kerna till jämförelsekriterierna. Vi diskuterar även vad vi har gjort samt eventuella lösningar där vi funnit det lämpligt.

4.1 Verktyget

Utvärderingen av verktyget rör användningen av det modellbaserade verktyget Ascet. Ascet är framtaget av det tyska företaget Etas, som även har tagit fram realtidsoperativsystemet Ercos. I första hand är Ascets tänkta användningsområde att ta fram reglersystem och liknande tillämpningar inom bilindustrin. Integratio-nen mot Ercos är central, men det ska inte vara nödvändigt att ha Ercos för att kunna köra den genererade koden.

4.1.1 Funktionalitet

Lämplighet

Modellinformation

Ascet presenterar mycket och detaljerad information om modellen, behändigt pla-cerad bakom olika ikar. Det nns information om implementationsspecikationen1 bakom en ik och information om initialiseringsvärden för data bakom en annan. Beroende på vad som editeras visas relevant information. I Projekteditorn nns ikar för schemaläggning av processer, kommunikation, formler som används i im-plementationsspecikationen och andra projektspecika data. Om det är en klass som editeras nns information om metoder, om argument och om olika implemen-tationer för olika instanser av klassen.

1_{Detta är ett mycket centralt begrepp i Ascet, noggrant beskrivet i avsnitt 2.2.3 på sidan 11}

Operationer

Ascet stödjer i grundutförande inga komplexa operationer alls, utan förlitar sig till fullo på sin modulära uppbyggnad. Bara de mest grundläggande operationer nns tillgängliga. Det nns variabler, konstanter, arrayer (vektorer) och matriser. De-ras värden kan vara kontinuerliga, logiska, diskreta utan tecken eller diskreta med tecken. Addition, subtraktion, multiplikation och division stöds enbart på skalärer. Det nns alltså inga operatorer som arbetar på matriser eller arrayer. Matematiska funktioner av typen sinus, moduloberäkningar med er stöds inte av den graska miljön i sig. Dock nns möjligheten att skriva funktioner i det inbyggda program-meringsspråket ESDL och då använda sig av det inbyggda matematikbiblioteket. I detta bibliotek nns till exempel trigonometriska funktioner, återigen arbetar dock dessa enbart på skalära datatyper.

Att alla operationer sker på skalärer gör att matriser och arrayer blir dum-ma databehållare. Varje operation på dessa datatyper kräver tidsödande arbete med indexering av elementen i en while-loop. Detta lämpar sig dåligt för grask modellering, då den visuella metaforen på inget sätt tydliggör funktionaliteten.

Utvecklaren har också möjlighet att integrera C-kod i Ascet, vilket kan vara an-vändbart om det nns gammal vältestad funktionalitet. Nackdelen med detta är att abstraktionen mellan modellvärlden och implementationen får hanteras manuellt.

Med programvaran följer ett bibliotek med ett antal klasser som utvecklaren kan använda sig av. Dessa klasser är till exempel jämförelseoperatorer av något krångligare slag (exempelvis ingår x i intervallet?), räknare, parametriserade låg-passlter, integratorer och så vidare. En beskrivning av samtliga klasser i detta bibliotek åternns i den medföljande klassreferensen [3]. Ascet ger också ett myc-ket gott stöd för att återanvända egenskrivna operatorer i form av klasser, i pro-jektet har vi exempelvis utvecklat funktionalitet för matrismultiplikation, addition och invertering. Dessa kan tilldelas en lämplig ikon och sparas undan för senare användning.

Simulering

Simuleringsmöjligheterna i Ascet lämnar ett blandat intryck. Utvecklaren av mo-dellen kan göra oine-experiment2_{. Simuleringen sker direkt på den genererade} koden (på PC:n), i vad vi antar är ett försök att garantera att simulerad funktio-nalitet är den funktiofunktio-nalitet som slutprodukten kommer ha. Utvecklaren kan välja att utföra olika sorters simuleringar beroende på inställningarna för kodgenerering. Här kan utvecklaren välja på era olika sorters experiment:

• Fysiskt experiment

• Kvantiserat fysiskt experiment

• Implementationsexperiment

2_{Oine innebär att simuleringen sker på PC. Motsatsen är online-experiment, då} simulerings-miljön kopplas upp mot det tänkta målsystemet

Fysiskt och kvantiserat fysiskt experiment genererar yttalskod för PC:n ut-vecklaren arbetar vid, oavsett val av implementation. Här har utut-vecklaren möj-lighet att se till så att funktionaliteten är korrekt utan att behöva bry sig om den underliggande implementationen. Det kvantiserade experimentet ger möjlig-het att studera kvantiseringseekterna i den valda implementationsspecikationen utan övriga bekymmer som heltalsaritmetik skapar. Aritmetiska operationer utförs alltså fortfarande i yttalsform, även för det kvantiserade experimentet.

Implementationsexperiment genererar kod helt enligt den valda implementa-tionsspecikationen. Anta till exempel en kontinuerlig variabel som i den fysiska världen kan ha ett värde mellan minus ett och ett, med kvantiseringen 0, 125. Om vald implementation är åttabitars heltal, kommer variabeln verkligen att simuleras som ett åttabitarstal med tre bitar avsatta för decimaler. Dock sker simuleringen fortfarande på kod genererad för PC.

Väl i simuleringen ger Ascet möjlighet att generera stimuli till variablerna i mo-dellen. Till detta nns ett par fördenierade funktioner, exempelvis sinusfunktion eller konstant värde. Det går också att läsa in stimuli från externa ler. Tyvärr klarar inte Ascet av att läsa in data utifrån till arrayer och matriser, vilket orsakar merarbete. Vidare får utvecklaren deniera vilka processer som skall köras, hur ofta och med vilken prioritet. Data kan loggas till l, från start eller om något logiskt villkor är uppfyllt. När alla inställningar är gjorda kan de sparas, vilket underlättar om utvecklaren behöver upprepa samma simulering.

När inställningarna för simuleringsmiljön är gjord körs simuleringen stegvis eller kontinuerligt. Varje steg i simuleringen är ett anrop till en process. Det nns ingen möjlighet att stega sig igenom modellen på en lägre nivå än så, vilket kan göra det svårt att felsöka större processer. Nivån är för grovkornig och en ordentlig debugger saknas. Inte heller går det att stoppa simuleringen med automatik. Om till exempel modellen matas med data från en extern l så stannar inte simuleringen när datan är slut, utan utvecklaren får själv stoppa den.

Under simuleringen kan utvecklaren titta på värden i variabler i modellen på ett par olika sätt. Det går att titta på variabler i diagrammen, i ett numeriskt snapshot och i ett oscilloskop. Oscilloskopet är intressantast att diskutera. Det klarar av upp till trettio separata kanaler. Det går att titta på enstaka element i matriser och arrayer genom att deniera vilken position i matrisen/arrayen som är intressant. Tidsaxeln är gemensam för alla kanaler, men värdeaxeln går att skala separat för varje kanal. Det går att för varje kanal få ut max- och minvärde, skillnaden mellan två tidpunkter eller specikt värde vid en given tidpunkt. En bra funktion är att det går att spara simulerad data till l.

Tyvärr stannar funktionaliteten för oscilloskopet där. Det går till exempel inte att zooma in ett intressant område i grafen. Det går inte heller att gömma kana-ler, att simulera mer än en eller två kanaler blir därför i allmänhet oöverskådligt. Utvecklaren måste i princip spara datan från kanalerna och konvertera dem till Matlab-format för att kunna göra noggrannare undersökningar. Detta är sympto-matiskt för simuleringsmiljön. Vi får uppfattningen att idén bakom funktionerna och funktionaliteten i sig inte stämmer överens. Det var en bra ansats med ett oscilloskop, men resultatet känns taigt och halvfärdigt. Miljön är klumpig att

arbeta i och funktionaliteten saknar det där lilla extra som gör att det går att koncentrera sig på att lösa uppgiften. Istället tvingas utvecklaren manövrera runt begränsningarna i programmet med frustrerande och onödiga handgrepp. En bild av Ascets simuleringsmiljö åternns i gur 4.1, nederst är oscilloskopet och ovanför det syns ett av diagrammen i modellen.

Figur 4.1. Ascets simuleringsmiljö, uppe till höger syns en del av den simulerade model-len, nedanför är oscilloskopet.

Utvecklingstid

Tiden det tar att utveckla i Ascet är förstås beroende av många parametrar, inte minst vilken typ av applikation som skall modelleras. Generellt kan vi dra slut-satsen att det går relativt fort att deniera en modell och få den att fungera som fysiskt experiment. Som relativt vana C-programmerare tror vi inte att vi kunde ha åstadkommit lika mycket på så kort tid om vi hade arbetat för hand. Framförallt hade inte funktionaliteten varit lika vältestad efter så kort utvecklingstid.

Det som framförallt tar tid att få ordning på är implementationsspecikationen, särskilt om problemet är svårt numeriskt. RAI-algoritmen, och kanske Kalmanlter i allmänhet, är ofta svåra numeriskt. Matriserna för det drivande bruset har ett dy-namiskt område på uppåt tjugo bitar3_{. Andra intermediära matriser i ltret kräver} 3_{Med detta menas att det krävs minst tjugo bitar för att beskriva variabelns denitionsmängd} med tillräcklig precision

er bitar än så. Ascet genererar tyvärr inte bra kod ur ett numeriskt perspektiv, i princip klarar den inte av större noggrannhet än sexton bitar utan att utveck-laren får ta särskild hänsyn till detta. Detta leder till en för låg abstraktionsnivå där utvecklaren måste känna till varje variabels noggrannhetskrav och maximala absolutbelopp i hela modellen. I princip är det samma detaljkunskap som krävs vid manuell C-programmering. Skillnaden mot ren C-programmering blir tvåfald. Till Ascets fördel är att det är lättare att testa de ändringar som införs, till den gräns som simuleringsmiljön tillåter. Negativt är det frustrerande dåliga gränssnittet som används för att specicera implementationen. Det tar lång tid och är krångligt att ändra i implementationsspecikationen. Så länge problemet är enkelt och begrän-sat går det utmärkt, men så fort svårigheten går över en viss nivå blir verktyget ett hinder snarare än en hjälp.

Den låga abstraktionsnivån är ett återkommande problem som får inverkningar även på andra delar än utvecklingstid, se avsnittet om noggrannhet nedan.

Totalt tog utvecklingsarbetet med 7-tillståndsalgoritmen c:a 8 veckor. Absolu-ta merparten av utvecklingstiden var arbete med implemenAbsolu-tationsspecikationen. Modellen simulerar då som heltalsimplementation på PC, men fungerar inte alls på målsystemet. Förändringen till 4-tillståndsalgoritmen tog c:a 2 dagar, vilket visar att det är lätt att förändra existerande modeller.

Fleranvändarstöd

Ascet sparar all information i en databas. Databasen innehåller moduler, klasser, signaler (stimuli till simuleringar), implementationsspecikation och projektinställ-ningar. Den ligger sparad lokalt i ett lträd som bestäms vid installationen. Inget stöd nns i grundutförandet för att många ska kunna arbeta mot samma databas. Istället nns det funktionalitet för att importera och exportera block av informa-tion (exempelvis en klass eller ett diagram) från databasen. Funkinforma-tionalitet för att jämföra databaser nns också implementerad. Denna funktionalitet känns närmast fånig, ingen detaljnivå nns. Ett exempel ges nedan:

Different Blockdiagrams in c:\etasdata\ascet4.1\database\States4-2\DB: BlockDiagram for: - RAI/Classes/Linearization

BlockDiagram for: - RAI/Classes/MeasureUpdate BlockDiagram for: - RAI/Classes/Mtrx_multiply BlockDiagram for: - RAI/Classes/StateCalc BlockDiagram for: - RAI/Classes/TimeUpdate BlockDiagram for: - RAI/Modules/RAI_main BlockDiagram for: - RAI/RAI_project

Som synes talar den bara om att det skiljer, på diagramnivå, vilket utvecklaren förmodligen redan visste. Vad som skiljer presenteras överhuvudtaget inte. Det är i exemplet ovan allt ifrån att en variabel har bytt namn till att funktionaliteten är totalt förändrad.

Vi kan dra slutsatsen att det går bra att arbeta på helt separata block parallellt. Problemen kommer att uppstå först vid integration av era utvecklares arbete, på