Arkitekturdokument for Cruise Control

Arkitekturdokument for Cruise Control Cruise International

Revisions historie Dato Version Forfatter Beskrivelse 2.10.2001 0.91 FOH Første version 17/03/09 1.0 KG Afs. 1 og 2 indsat (- 2.1) 15/05/09 1.1 TW Tilføjet afs. 5, 6, 7, 8, 9, 10 15/05/09 1.2 KG afs 2.1, 3.1, 5.2.3, 6.6.2, 10, 11.4 22/05/09 1.3 TW/CM Opdatering og finpudsning af diagrammer Version 1.3/03.06.2009 Side 2 af 22

Indholdsfortegnelse 1. INTRODUKTION... 5 1.1 Formål og omfang... 5 1.2 Referencer... 5 1.3 Definitioner og forkortelser... 5 1.4 Dokumentstruktur og læsevejledning... 5 1.5 Dokumentets rolle i en iterativ udviklingsproces... 5 2. SYSTEM OVERSIGT... 6 2.1 System kontekst... 6 2.2 System introduktion... 7 3. SYSTEMETS GRÆNSEFLADER... 7 3.1 Grænseflader til person aktører... 7 3.2 Grænseflader til hardware aktører... 8 4. USE CASE VIEW... 9 4.1 Oversigt over arkitektursignifikante Use Cases... 9 4.2 Use Case 1- I: Hold Hastighed. Scenarier... 9 4.2.1 Use Case mål... 9 4.2.2 Use Case scenarier... 9 4.3 Use Case 6- Accelerer midlertidigt. Scenarier... 10 4.3.1 Use Case mål... 10 4.3.2 Use Case scenarier... 10 4.4 Use Case 8- Genoptag Cruisehastighed. Scenarier... 10 4.4.1 Use Case mål... 10 4.4.2 Use Case scenarier... 11 5. LOGISK VIEW... 11 5.1 Oversigt... 11 5.2 Arkitektursignifikante designpakker... 12 5.2.1 Hardwaregrænseflade... 12 5.2.2 Styring... 13 5.2.3 Brugergrænseflade... 14 5.3 Use Case realiseringer... 16 5.3.1 Use Case 1 Hold Hastighed Realisering... 16 6. TASK VIEW... 17 6.1 Oversigt over task... 17 6.2 Proces/task kommunikation og synkronisering... 17 6.3 Datahåndtering.... 18 6.3.1 Taskkommunikation i Datahåndtering... 18 6.3.2 AnalogInterpreter... 18 6.3.3 DigitalInterpreter... 18 6.3.4 CalibrateInterpreter... 18 6.3.5 Impulses... 18 6.3.6 Distance... 19 Version 1.3/03.06.2009 Side 3 af 22

6.4 Fysisk funktionalitet... 19 6.4.1 Proceskommunikation i Fysisk funktionalitet... 19 6.4.2 KeepSpeed... 19 6.5 Grafisk funktionalitet... 19 6.5.1 Proceskommunikation i Grafisk funktionalitet... 19 6.5.2 WidgetManager... 20 7. GENERELLE DESIGNBESLUTNINGER... 20 7.1 Arkitektur mål og begrænsninger... 20 7.2 Arkitektur mønstre... 20 7.3 Exception og fejlhåndtering... 20 7.4 Implementeringssprog og værktøjer... 21 7.5 Implementeringsbiblioteker... Fejl! Bogmærke er ikke defineret. 8. STØRRELSE OG YDELSE... 21 9. KVALITET... 21 10. OVERSÆTTELSE... 21 10.1 Oversættelses-hardware... 21 10.2 Oversættelses-software... 21 10.3 Oversættelse og linkning... 21 10.4 Installation... 21 11. KØRSEL... 21 11.1 Kørsels-hardware... 21 11.2 Kørsels-software... 22 11.3 Start, genstart og stop... 22 11.4 Fejludskrifter... 22 Version 1.3/03.06.2009 Side 4 af 22

1. INTRODUKTION 1.1 Formål og omfang Formålet med dette dokument er at give en beskrivelse af systemets arkitektur og design. Dokumentet bliver til sideløbende med at systemet designes og udvikles og ved en ændring i systemets design skal dette dokument opdateres med ændringer. Formålet med dette dokument er ikke at lave en udtømmende beskrivelse af systemet, men at beskrive alt hvad der er nødvendigt for at forstå systemet og dets funktionalitet. 1.2 Referencer Dette dokument bygger på den kravspecifikation, der ligger til grund for systemet. Designet tager derfor også sit udgangspunkt i den analyse, der er blevet lavet i kravspecifikationen. 1.3 Definitioner og forkortelser CC = Cruise Control 1.4 Dokumentstruktur og læsevejledning Views: Use Case View: Beskriver de forskellige scenarier for systemet v.h.a. sekvensdiagrammer. Logisk View: Beskrivelse af systemets klasser. Processview: Beskriver systemet, opdelt i processor og hvorledes disse kommunikerer og synkroniserer med hinanden. 1.5 Dokumentets rolle i en iterativ udviklingsproces Dette dokument er en vigtig del af den dokumentation, der beskriver udviklingen af systemet. Derfor vil hele dokumentet heller ikke være fastlagt eller færdiggjort før implementeringen begynder på systemet og dele af dokumentet vil bliver færdiggjort undervejs. Overordnet for iterationerne vil fokus på de forskellige afsnit være: Construction 1: Her implementeres use cases 1, 2 og 3 som der fokuseres på i første iteration i use vase view. Der beskrives pakker og klasser i det logiske view. Systemoversigten er beskrevet Grænsefladerne er beskrevet Construction 2: Her fokuseres på use cases 4, 5, 6, 7, 8, 9, som indføres i use case view. Yderligere klasser tilføjes det logiske view. Taskview påbegyndes. Version 1.3/03.06.2009 Side 5 af 22

kument Construction 3: Her fokuseres på use cases 10, 11, som udgør det resterende af use case viewet. De sidste klasser tilføjes det logiske view. Taskview færdiggøres Design af systemet er færdigt. 2. SYSTEM OVERSIGT 2.1 System kontekst Figur 1: Aktør-kontekst kontekst diagram for Cruise Control systemet Version 1.3/03.06.2009 Side 6 af 22

2.2 System introduktion Systemet har til formål at tillade en bruger under kørslen at fastholde en aktuel fart. Det vigtige i systemet at sikkerheden i bilen ikke kompromitteres og derfor skal systemet overvåge input fra brugeren, således at brug af speeder og bremse deaktiverer systemet. Derudover skal systemet også fungere som hastighedsmåler for brugeren samt give et overblik over benzinforbrug under kørslen, således at det er muligt at køre økonomisk. 3. SYSTEMETS GRÆNSEFLADER 3.1 Grænseflader til person aktører Der er to grænseflader til personaktørerne: - Den grafiske brugergrænseflade Figur 2: Screenshot af den grafiske brugergrænseflade Version 1.3/03.06.2009 Side 7 af 22

- Betjeningspanel bestående af 8 trykknapper Figur 3: Layout af betjeningspanelets knapper Betjeningspanelet tillader brugeren at styre Cruise Controlleren. Brugeren kan ved tryk på: Activate: aktivere CC Deactivate: deaktivere CC Increase: forøge hastighed med en km/t ad gangen Decrease: mindske hastighed med en km/t ad gangen Resume: genoptage cruise fra senest gemte hastighed Reset: nulstille triptæller. Administrator kan, ved tryk på Calibrate, indstille bilens hjulstørrelse, for korrekt hastighedsgengivelse. 3.2 Grænseflader til hardware aktører Systemet monteres i en bil, til en række sensorer der er nødvendige for systemets funktionalitet. Disse er: Omdrejningssensor, motor Denne sensor er monteret på motoren og måler motoromdrejninger. Input fra sensoren fås som pulser i intervallet 0-3kHz på Timer 2. Omdrejningssensor, hjul Denne sensor er monteret så der dannes en impuls for hver halve hjulomdrejning. Sensorinput opfanges via IRQ5 Flowmåler, brændstof Flowmåleren måler brændstofforbruget og giver et analogt sensorinput i intervallet 0-10V Aktuator Aktuatoren styrer brændstoftilførslen og udsender et analogt signal i intervallet 0-10V Potmeter, speeder Speedersensoren giver et signal i intervallet 0-10V proportionalt med speedertryk Switch, bremse Bremsesensoren leverer et digitalt signal som er høj hvis der er trykket, lav ellers. Version 1.3/03.06.2009 Side 8 af 22

Switch, kobling Koblingssensoren leverer et digitalt signal som er høj hvis der er trykket, lav ellers. Switches, gear Gearsensorerne leverer et digitalt signal som er lav hvis der er trykket, høj ellers. 4. USE CASE VIEW 4.1 Oversigt over arkitektursignifikante Use Cases 4.2 Use Case 1- I: Hold Hastighed. Scenarier Figur 4: Use case diagram for use case 1 - Hold Hastighed 4.2.1 Use Case mål Systemet skal opretholde den hastighed brugeren har angivet. 4.2.2 Use Case scenarier Hvis den aktuelle hastighed er mindre end den ønskede hastighed som specificeret af bruger, øger brændstoftilførslen, hvorefter det gentager processen. Version 1.3/03.06.2009 Side 9 af 22

Når systemet kommer i en situation hvor brændstoftilførslen ikke kan forøges yderligere og bilens hastighed stadig er mindre end ønsket, deaktiveres cruise controlleren. Desuden informeres brugeren om undtagelsen, beskrevet i use case - Informer bruger Det er vigtigt at alle accelerationer/decelerationer foregår jævnt og uden mærkbare trinjusteringer. Desuden skal systemet hurtigt bringe bilen op på den ønskede hastighed. 4.3 Use Case 6- Accelerer midlertidigt. Scenarier Figur 5: Use case diagram for use case 6 - Accelerer midlertidigt 4.3.1 Use Case mål Use casen beskriver processen ved midlertidig acceleration, når CC er slået til. 4.3.2 Use Case scenarier Use casen træder i kraft når brugeren påfører speederen tryk som forøger hastigheden til mere end den specificerede cruisehastighed. I det tilfælde vil cruise controlleren ophøre med at justere hastigheden, indtil speedertrykket igen er så lavt at hastigheden ville komme under den specificerede cruisehastighed. I denne use case er det vigtigt at systemet fuldstændig afgiver kontrol over bilen til brugeren. 4.4 Use Case 8- Genoptag Cruisehastighed. Scenarier 4.4.1 Use Case mål Use casen beskriver forløbet hvor brugeren vælger resume Version 1.3/03.06.2009 Side 10 af 22

4.4.2 Use Case scenarier Use casen træder i kraft hvis cruise controlleren har været slået til, men nu er deaktiveret, og brugeren trykker på knappen resume på betjeningspanelet. Idet brugeren trykker på resume vil use case Hold Hastighed blive iværksat og bilen vil dermed accelerere indtil den igen når cruisehastighed. 5. LOGISK VIEW 5.1 Oversigt Figur 6: Oversigt over systemets opbygning I tre lag; Brugergrænseflade, styring og Hardwaregrænseflade Version 1.3/03.06.2009 Side 11 af 22

5.2 Arkitektursignifikante designpakker 5.2.1 Hardwaregrænseflade Figur 7: UML klassediagram over hardwaregrænsefladen Hardwaregrænsefladen er den hardwarenære pakke. Den er implementeret med et facadepattern. Version 1.3/03.06.2009 Side 12 af 22

Desuden er der lagt op til et strategypattern således at man senere kan implementere en io686 stub og en pv2019 stub som gøres udskiftelige med io686-driveren og pv2019-driveren. Klasser i denne pakke: HardwareFacade HardwareFacade har ansvar for at forbinde systemet med drivere, således at hardware og/eller drivere kan skiftes/omskrives uden at det nødvendiggør omskrivning af kode ud over det i HardwareFacade. Klassen består af funktionerne: turnonled( unsigned char LED): tænder led nummer LED tunroffled( unsigned char LED): slukker led nummer LED portpattern(ppi::portid id): returnerer status for de otte bit på port nummer id readflow(): returnerer brændstofflowet, en analog værdi i intervallet 0-4095 readspeeder(): returnerer speederposition, en analog værdi i intervallet 0-4095 writeactuator(int value): skriver en værdi til aktuatoren, en analog værdi i intervallet 0-4095 readrevolutions(): returnerer en analog værdi i intervallet 0-4095 proportionel med et omdrejningstal i intervallet 0-8000 ISRHandler ISRHandler 5.2.2 Styring Figur 8: UML klassediagram over Styring De vigtigste klasser i denne pakke er: KeepSpeed KeepSpeed implementerer en state maskine Operationer: - adjustspeed: indeholder algoritmen til at opretholde en konstant cruisehastighed Cruise Operationer: - Activate: skifter systemets state til aktiv - Deactivate: skifter systemets state til inaktiv - Adjust: afhængig af parameter øger eller sænker funktionen den ønskede hastighed - Reset: nulstiller triptælleren - Calibrate: hvis systemet state er inaktiv, skifter state til calibrate. Hvis systemets state er calibrate gemmer funktionen den nye hjuldiameter i en fil. Version 1.3/03.06.2009 Side 13 af 22

Figur 9: State diagram over state machine i KeepSpeed 5.2.3 Brugergrænseflade For at lave det grafiske element i projektet valgte vi at dele grafikken op i forskellige widgets og benytte et observer pattern. Da alle widgets tilgår den samme skærm blev den sat op som en singleton. WidgetManager og Widget er henholdsvis publisher og subscriber i vores model. Dog er det en simplificeret udgave af observer patternet, da det kun er publisheren, der er bevidst om de forskellige subscribers og ikke omvendt. Vi skønte at dette var den bedste model, da vi aldrig kan havne i en situation hvor en subscriber kunne tænkes at bryde forbindelsen til publisheren. I den forbindelse er der vel nærmere tale om et master/slave forhold klasserne imellem. Screen objektet forsøger at oprette forbindelse til monitor 0, bemærk at denne værdi er hard coded! Derudover sættes også 16 skærmfarver op og to skrifttyper. Lykkedes dette smides en exception. Smides en FatalException betegner det en fejl som, der ikke kan rettes op på. Smides en NonFatalException er der grafikmuligheder, men der kunne ikke rettes forbindelse til Font APIet. For at tegne på skærmen benyttes Media Library 5.1, på en kerne som er specielt compilet til til testsystemet. Ønskes det at benytte grafikken på et andet target laves der en ny kerne specielt til hardwaren med media library 5.1 kompatabilitet. Eftersom screen objektet er en singleton benyttes SmartPointer patternet til at holde styr på Version 1.3/03.06.2009 Side 14 af 22

hvor mange pointere, der er givet til objektet. Det er vigtigt for systemets integritet at screen objektet nedlægges når programmet er færdig med at blive kørt og SmartPointer patternet sikrer at screen bliver rigtig nedlagt når den sidste SmartPointer deallokeres. Som en ekstra krølle er der tilføjet at SmartPointeren sætter adressen på instance pointeren tilbage til 0, så der ikke returneres en pointer til et nedlagt objekt. Figur 10: UML klassediagram over den grafiske brugergrænseflade Liste over patterns brugt til denne pakke: Observer (simplificeret) //Strategy/Iterator SmartPointer Singleton De vigtigste klasser i denne pakke er: WidgetManager Widget Screen Version 1.3/03.06.2009 Side 15 af 22

kument 5.3 Use Case realiseringer 5.3.1 Use Case 1 Hold Hastighed Realisering Hold hastighed er den essentielle tilstand i tilstandsmaskinen i Cruise Controlleren. Den justerer løbende aktuatorværdien i forhold til den ønskede hastighed. Nedenstående sekvensdiagram viser interaktionen mellem klasser der er involveret i Use case 1 Hold Hastighed. Figur 11: Sekvensdiagram for delscenarie af use case 1 Hold Hastighed Version 1.3/03.06.2009 Side 16 af 22

6. TASK VIEW 6.1 Oversigt over task Figur 12: Systemets tasks opdelt efter ansvarsområder. De tre taskgrupper beskrives udførligt i resten af kapitlet Systemet kan opdeles i tre taskgrupper med tre forskellige ansvarsområder. Den fysiske funktionalitet behandles i taskgruppen Fysisk funktionalitet, den grafiske i taskgruppen Grafisk funktionalitet, og datahåndtering klares i taskgruppen Datahåndtering. 6.2 Proces/task kommunikation og synkronisering Kommunikation mellem taskgrupper foregår via monitorer. Hvor en monitor optræder i flere klassediagrammer over taskgruppekommunikation betyder det at kommunikationen mellem de to taskgrupper foregår via disse monitorer. Version 1.3/03.06.2009 Side 17 af 22

6.3 Datahåndtering. Datahåndtering er den mest omfattende taskgruppe og behandler al input fra ekstern hardware. En del af ansvaret består i at omregne inputtet til fysiske enheder som så kan bruges til beregninger. 6.3.1 Taskkommunikation i Datahåndtering Figur 13: Klassediagram over tråde og trådkommunikation for datahåndtering Størstedelen af den interne kommunikation i Datahåndtering er passiv og foregår via monitorer. Desuden kommunikerer trådene DigitalInterpreter og CalibrateInterpreter vha en mutex, således at der altid er en af de to tråde der sover. 6.3.2 AnalogInterpreter AnalogInterpreter henter input fra bilens analoge sensorer. Desuden beregner den bilens hastighed baseret på et tidsinterval beregnet af tråden Impulses. Data lægges i relevante monitorer. 6.3.3 DigitalInterpreter DigitalInterpreter henter input fra bilens digitale sensorer og cruise controller betjeningspanelet. Input behandles og lægges i relevante monitorer. DigitalInterpreter lægger sig til at sove ved tryk på knappen calibrate. 6.3.4 CalibrateInterpreter CalibrateInterpreter vågner når DigitalInterpreter registrerer tryk på knappen calibrate. Den overvåger kun input fra 3 knapper: calibrate, increase og decrease. Når calibrate trykkes igen lægger tråden sig til at sove igen. 6.3.5 Impulses Impulses tager en semaphor som frigives ved interrupts. Tråden gemmer antal impulser siden opstart i én monitor, og tiden mellem de to foregående impulser i en anden. Version 1.3/03.06.2009 Side 18 af 22

6.3.6 Distance Distance henter antal impulser siden opstart, fra en monitor og beregner den kørte afstand siden reset af triptæller og den samlede afstand kørt. Disse værdier gemmes i to monitorer. 6.4 Fysisk funktionalitet 6.4.1 Proceskommunikation i Fysisk funktionalitet Figur 14: Klassediagram over tråde og trådkommunikation for Fysisk funktionalitet Da gruppen kun består af en enkelt tråd er der ingen intern kommunikation. 6.4.2 KeepSpeed KeepSpeed er en del af en statemaskine som bevæger sig mellem seks states: Active, Inactive, Suspended, Cruise, Resume og Calibrate. Systemet kan bevæge sig mellem disse states under kørsel. 6.5 Grafisk funktionalitet 6.5.1 Proceskommunikation i Grafisk funktionalitet Figur 15: Klassediagram over tråde og trådkommunikation for den grafiske funktionalitet Version 1.3/03.06.2009 Side 19 af 22

6.5.2 WidgetManager WidgetManageren er publisher delen af observer patternet. Der registreres en en masse widget objekter til den, som WidgetManageren efterfølgende kalder update på. De enkelte widget objekter har hver især ansvaret for at opdatere grafikken på et område af displayet. Tilsammen udgør widgets og widgetmanageren hele den dynamiske display del. Opsætningen af displayet foregår gennem et screen singleton objekt. 7. GENERELLE DESIGNBESLUTNINGER 7.1 Arkitektur mål og begrænsninger Systemet skal køre på en SBC 686. Udviklingsarbejdet foregår som Rational Unified Proces, med løbende udvikling, i 3 constructions. 7.2 Arkitektur mønstre Der er anvendt Singleton-pattern til objektet Screen, der opretter forbindelse til skærmen for brugeroutput. Til at holde styr på singletonen anvendes en smartpointer. Denne Iterator-pattern er, sammen med Observer-pattern, anvendt til det grafiske output til skærmen. Alle elementer på skærmen er lavet som enkeltstående widgets. Disse køres igennem, eller itereres, af tråden Widgetmanager og udskrives løbende til skærmen. 7.3 Exception og fejlhåndtering Introduktionen af exceptions til designet skete sent i udviklingsforløbet og er defor ikke en del af helhedsdesignet for systemt. Vi har dog valgt at introducere exceptions i det grafiske design, dels for at gøre opmærksom på dem, og for at gøre en udvidelse af exception hierakiet nemmere i en senere videreudvikling af systemet. Figur 16: Exceptionhieraki For enkelthed har vi valgt at inddele vores exceptions i to overordnede exceptions, som begge nedarver fra STL exception klassen exception. En fatal (FatalException) og ikkefatal (NonFatalException). De kan begge optræde under initialisering af grafik og begge Version 1.3/03.06.2009 Side 20 af 22

udskriver de deres fejl på output stream før de terminerer. Forskellen er at systemet terminerer med en fejlværdi (1) når der kastes en FatalException og at systemet lukker pænt ned på en NonFatalException. 7.4 Implementeringssprog og værktøjer Al kode er skrevet i C++. Til software er VxWorks Workbench 3.0 brugt som udviklingsværktøj. Alle diagrammer er lavet i Visual Paradigm for UML Standard Edition, version 6.4 8. STØRRELSE OG YDELSE Systemet skal fungere i realtid. Da der bruges en SBC 686 som hardwareplatform, er der ingen eksplicitte krav til performance. 9. KVALITET Systemet skal have maksimal oppetid. Eventuelle opgraderinger og lignende skal foretages af en mekaniker på et autoriseret værksted, og det er således ikke noget brugeren kommer i kontakt med. 10. OVERSÆTTELSE 10.1 Oversættelses-hardware Ingen. 10.2 Oversættelses-software Det er nødvendigt at benytte Wind Rivers IDE VxWorksbench for at compile og downloade programmet til target. Derudover er det nødvendig at inkludere middleware komponentet Media Library (ML) i projektet ud over projektfilerne. Den almindelige brug af VxWorkbench og opsætning af target kan findes i Wind Rivers egen dokumentation. Testsystemet er dog sat op med en fast ip. For inkludere ML rigtigt til testsystemet gøres følgende: Benyttes et andet target end testsystemet skal de nærmere deltaljer om opsætningen af ML findes i dens dokumentation. 10.3 Oversættelse og linkning Ingen. 10.4 Installation Når programmet er downloadet til target kan det køres uden yderligere konfiguration. 11. KØRSEL Systemet kan kalibreres 11.1 Kørsels-hardware Systemet kører på en SBC686 Version 1.3/03.06.2009 Side 21 af 22

11.2 Kørsels-software Softwaren kører på VxWorks 11.3 Start, genstart og stop Systemet startes ved at indtaste navnet på test-funktionen i 11.4 Fejludskrifter Da skærmen benyttes af grafikbiblioteket er der ikke mulighed for at systemet udskriver nogen fejlmeddelelser. Dog kan systemt lukke ned hvis der bliver smidt en exception fra Screen klassen. Version 1.3/03.06.2009 Side 22 af 22