Prototyp av informationssystem f or milit arfordon · Abstract Computer based information systems...

Prototyp avinformationssystem for

militarfordon

Oskar Lindgren, John Talling

14 april 2010Examensarbete i Teknisk Datavetenskap, 2× 30 hp

Handledare pa CS-UmU: Fredrik GeorgssonHandledare pa BAE Systems Hagglunds AB: Erik Essegard

Examinator: Per Lindstrom

Umea UniversitetInstitutionen for Datavetenskap

901 87 UMEASverige

Sammanfattning

Datorbaserade informationssystem blir en allt viktigare del i moderna militarastridsfordon. Besattningen maste snabbt kunna fa information om bade fordonetsjalvt och den yttre miljon for att snabbt kunna fatta ratt beslut. Vi redovisar irapporten hur vi tagit fram en prototyp till ett nytt informationssystem for band-vagnen BvS10, vilken tillverkas av BAE System Hagglunds AB i Ornskoldsvik.

En viktig aspekt av systemet ar den tid det tar fran att informationen gener-eras av givare i fordonet till dess att den presenteras for anvandaren. Systemetmaste kunna kontrollera det aldrig visar information som blivit inaktuell. Vi hardarfor lagt stor vikt vid att ta fram en lager- och komponentbaserad arkitek-tur for losningen som mojliggor kontroll av informationens alder nar den ror siggenom systemet. I samband med detta gors ocksa en djupare studie i kompo-nentbaserad design i allmanhet och for .NET i synnerhet. Vi redogor aven forde timingrelaterade problem som kan uppsta pa plattformar med garbage col-lection (dit .NET hor) och visar pa nagra av de losningar som foreslagits i denvetenskapliga litteraturen.

Abstract

Computer based information systems play an important role in modern mili-tary combat vehicles. The crew needs to be able to quickly get information aboutboth the vehicle and its outer surroundings in order to quickly make the correctdecisions. In the report, we describe the development of a prototype new infor-mation system for the BvS10 vehicle, developed by BAE System Hagglunds ABin Ornskoldsvik.

An important aspect of the system is the time it takes from that the infor-mation is generated by the vehicle sensors until it is presented to the user. Thesystem must be able to ensure that it never displays information that is out ofdate. Thus, great importance has been attached to creating a layer and componentbased architecture for the solution, making detailed control of the information ageas it moves through the system possible . In connection to this, we also performa deeper study of component based design in general and for .NET in particular.We also discuss the timing related problems that can occur on garbage collec-tion programming platforms (such as .NET) and show some of their solutionsproposed in the scientific literature.

Innehall

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Bandvagn BvS10 . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 VIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3 CAN-standarden . . . . . . . . . . . . . . . . . . . . . . . . 31.1.4 Microsoft .NET . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Rapportens struktur . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Problemstallning 72.1 Implementation av J1939-protokollet . . . . . . . . . . . . . . . . . 82.2 Grafiskt stod for design . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Sakerstallande av tidsgarantier for signaler . . . . . . . . . . . . . . 82.4 Stod for olika sprak och mattenheter . . . . . . . . . . . . . . . . . 92.5 Tredimensionell grafik som ett visuellt hjalpmedel . . . . . . . . . . 92.6 Examensarbetets mal . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Antaganden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7.1 Kravspecifikation . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Metod 133.1 Oversattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Tredimensionell grafik . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Komponentbaserad design 194.1 Komponentens framvaxt . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Vad ar en mjukvarukomponent? . . . . . . . . . . . . . . . . . . . . 204.3 Komponentbaserad design . . . . . . . . . . . . . . . . . . . . . . . 204.4 Komponentbaserad utveckling . . . . . . . . . . . . . . . . . . . . . 204.5 Microsoft .NET och komponenter . . . . . . . . . . . . . . . . . . . 214.6 Komponentinitiering . . . . . . . . . . . . . . . . . . . . . . . . . . 224.7 Komponentramverk . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.7.1 Dependency injection . . . . . . . . . . . . . . . . . . . . . 24

i

ii INNEHALL

4.7.2 Komponentinitiering med en fabrik . . . . . . . . . . . . . . 244.7.3 Initieringsordning . . . . . . . . . . . . . . . . . . . . . . . . 26

4.8 Service-orienterad programmering . . . . . . . . . . . . . . . . . . . 284.9 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Realtidsaspekter pa Garbage Collection 295.1 En kort introduktion till minneshantering . . . . . . . . . . . . . . 295.2 Allmant om Garbage Collection . . . . . . . . . . . . . . . . . . . . 30

5.2.1 Nabarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Tekniker for okad prestanda . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1 Inkrementell nabarhetsanalys med trefargning . . . . . . . . 325.3.2 Komprimerande vs. icke-komprimerande . . . . . . . . . . . 345.3.3 Generationer . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3.4 Interoperabilitet med sprak utan Garbage Collection . . . . 36

5.4 Realtidsaspekter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.1 Kort om realtidsbegreppet . . . . . . . . . . . . . . . . . . . 375.4.2 Realtidssystem med garbage collection . . . . . . . . . . . . 375.4.3 Minimum Mutator Utilization . . . . . . . . . . . . . . . . . 38

5.5 Existerande losningar . . . . . . . . . . . . . . . . . . . . . . . . . 395.5.1 Cheng och Blelloch . . . . . . . . . . . . . . . . . . . . . . . 395.5.2 Bacon, Cheng och Rajan . . . . . . . . . . . . . . . . . . . 405.5.3 Pizlo, Hosking och Vitek . . . . . . . . . . . . . . . . . . . . 41

5.6 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Systembeskrivning 436.1 Anvandning av komponenter . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 Tjanster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.2 Systemets uppstart . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Kommunikationslagret . . . . . . . . . . . . . . . . . . . . . . . . . 456.2.1 Signaltyper . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.2 CAN-hardvara . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.3 CAN-hantering . . . . . . . . . . . . . . . . . . . . . . . . . 476.2.4 J1939-hantering . . . . . . . . . . . . . . . . . . . . . . . . . 476.2.5 Signalkonverterare . . . . . . . . . . . . . . . . . . . . . . . 476.2.6 Signaldatabas . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2.7 CanLayerComponent . . . . . . . . . . . . . . . . . . . . . . 50

6.3 Datalagret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.3.1 Databindning i .NET . . . . . . . . . . . . . . . . . . . . . 516.3.2 Signalko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.3.3 Signallogik . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.3.4 Larmhantering . . . . . . . . . . . . . . . . . . . . . . . . . 526.3.5 Databindningskallor . . . . . . . . . . . . . . . . . . . . . . 53

INNEHALL iii

6.4 Presentationslagret . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.4.1 Uppdateringskomponent . . . . . . . . . . . . . . . . . . . . 536.4.2 Vyer och vykomponent . . . . . . . . . . . . . . . . . . . . 576.4.3 Sprakhantering . . . . . . . . . . . . . . . . . . . . . . . . . 576.4.4 Piktogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.5 Manualvyn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7 Slutsats 597.1 Begransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2 Framtida arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A Systemoversikt 67A.1 Huvudvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.2 Installningsvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.3 Manualvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.4 Forarvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.5 Larmvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.6 Design av vyer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Specifikation av examensarbete 77

iv INNEHALL

Figurer

1.1 Bandvagn BvS10[1]. . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 Oversattning av forarvyn i Resourcer. . . . . . . . . . . . . . . . . 14

3.2 Oversattning av forarvyn i Globalizer. . . . . . . . . . . . . . . . . 15

3.3 Oversattning av installningsvyn i Sisulizer. . . . . . . . . . . . . . . 16

4.1 Ett exempel pa objektorienterad design. Pilarna visar anropsflodetmellan klasserna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Pseudokod for ett system med tre komponenter. . . . . . . . . . . 22

4.3 Pseudokod som visar systemet i 4.2 med en utokning for att hanteraflera versioner av motorn. . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Pseudokod for en statisk fabrik. Fabriken kan instansiera och kon-figurera tva objekt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Beroendegraf for en statisk komponentfabrik. . . . . . . . . . . . . 25

4.6 Exempel pa en konfigurationsfil for en dynamisk fabrik (jfr 4.4). . 26

4.7 Beroendegraf for en dynamisk komponentfabrik. . . . . . . . . . . 26

4.8 Beroendegraf for systemet. . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Felaktigt resultat med referensraknande GC. Objekten D, E ochF refererar till varandra cirkulart, vilket gor att GC:n felaktigtidentifierar dem som nabara. . . . . . . . . . . . . . . . . . . . . . 31

5.2 Genom att folja referenskedjan fran rotobjekten (A och C), kan D,E och F korrekt identifieras som onabara. . . . . . . . . . . . . . . 32

5.3 Bilden visar hur trefargningsstrategin anvands for att berakna nabarheteni objektgrafen. Notera att ett svart objekt inte vid nagot tillfalledirekt refererar till ett vitt, vilket skulle bryta mot invarianten. Isista bilden sa ar mangden av gra objekt tom, och det vita objektetF kan nu identifieras som onabart. . . . . . . . . . . . . . . . . . . 33

v

vi FIGURER

5.4 Bilden visar hur pekarna i to-space forandras under korning avCheneys algoritm for samma exempel som i figur 5.3. Algoritmenterminerar nar SCAN och FREE pekar mot samma adress, vilketsvarar mot att mangden av gra objekt ar tom. . . . . . . . . . . . 35

5.5 Ett exempel pa hur MMU:n kan okas, medan den totala mangdenarbete for mutator och GC forblir konstant. A: GC-pauserna arlanga och oregelbundna, vilket paverkar MMU:n negativt badem.a.p. langa och korta intervall. B: GC-pauserna har gjorts regel-bundna, vilket okar MMU for det langre intervallet. Det kortareintervallet ar dock fortfarande begransat av paustidens storlek. C:Genom att bryta upp GC:ns arbete i mindre delar kan MMU:nokas aven for det mindre intervallet. . . . . . . . . . . . . . . . . . 39

6.1 En oversikt av de olika delar som ingar i losningen. . . . . . . . . . 44

6.2 De tre metoder som varje komponent implementerar. . . . . . . . . 45

6.3 Figuren illustrerar hur en CAN-signal ror sig genom kommunika-tionslagret. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Designmonstret Publish/Subscribe. 1. Prenumeranten startar enprenumeration hos CanDispatch genom att skicka en referens tillsitt Event-objekt. 2. Prenumeranten vantar pa att Event.Wait()returnerar. 3. CAN-signalen inkommer till CanDispatch och denanropar Event.Set(). 4. Event.Wait() returnerar for prenumerantenoch den kan lasa ut signaldatan fran CanDispatch. . . . . . . . . . 49

6.5 Den grafiska kontrollen for vaxelvaljaren, GearboxControl, visaratt vaxeln star i neutrallage. . . . . . . . . . . . . . . . . . . . . . . 54

6.6 Samtliga kontroller i forarvyn tar emot signalvarden. . . . . . . . . 55

6.7 Endast signalen fordonshastighet tas emot. Ovriga visare slacks utfor att indikera att deras data nu ar foraldrad. . . . . . . . . . . . 56

7.1 Tankbar framtida anpassning av lagerarkitekturen for WLAN (jfr.figur 6.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.1 Huvudvyn med ett larm som gor personalen uppmarksam pa attden bakre luckan ar oppen under korning. Nederst syns naviger-ingsknapparna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.2 Anvandaren kan snabbt byta kulturinstallning i installningsvynutan att starta om systemet. . . . . . . . . . . . . . . . . . . . . . 69

A.3 Manualvyn ger anvandaren tillgang till hjalptexter. . . . . . . . . . 70

A.4 Forarvyn med visare for olika sensorvarden fran motor och vaxellada. 71

A.5 Forarvyn nar kulturinstallningen har andrats till brittiskt. Noteraandringen i skalorna for kylarvatsketemperaturen och hastigheten. 72

FIGURER vii

A.6 En matare blir gra och visaren forsvinner nar det inte finns nagotvarde att visa. I detta fall har endast hastighetsmataren ett giltigtvarde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.7 Larmvyn visar tva aktiva larm och ett utganget larm i loggen. . . 73A.8 Forarvyn oppnad i designlaget. . . . . . . . . . . . . . . . . . . . . 74A.9 Signalvarden fran fordonet kan bindas till grafiska kontroller via

enkla menyer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.10 Oversattning av installningsvyn i Sisulizer. . . . . . . . . . . . . . . 75

viii FIGURER

Kapitel 1

Inledning

Datorbaserade informationssystem blir en allt viktigare del av moderna stridsfor-

don. Besattningen maste snabbt kunna fa information om bade fordonet sjalvt och

den yttre miljon for att kunna fatta ratt beslut. Da olika besattningsmedlemmar

fyller olika roller i ett stridsfordon ar det ocksa onskvart att informationen som

presenteras for dem ar anpassade till rollen. Med dessa okade krav pa informa-

tionssystemet foljer parallellt okade krav pa utvecklingsprocessen for att ta fram

dem.

BAE Systems Hagglunds AB har idag ett befintligt informationssystem for

nyare varianter av sin tyngre stridsfordonsmodell CV90. Man har planer pa att

infora ett liknande system for en av sina bandvagnsmodeller, BvS10. Inom ramen

for projektet ar man aven intresserad av att se vilka fordelar som gar att fa

genom att anvanda modern teknik. Man vill darfor utvardera ett anvandande

av Microsofts .NET-plattform for detta andamal. Man hoppas att det ska ge

en kortare utvecklingstid och ett system som ar lattare att anpassa till kundens

onskemal.

Detta examensarbete syftar till att undersoka detta genom att ta fram en

prototyp av ett informationssystem for BvS10. Sarskild vikt har lagts vid hanter-

ing och tidskontroll av signaler fran fordonet, komponentbaserad arkitektur av

mjukvaran, samt oversattning av granssnittet for olika lander och kulturer.

1

2 Kapitel 1. Inledning

1.1 Bakgrund

BAE Systems Hagglunds AB tillverkar militara fordon for bade inhemsk anvandning

och export och anstaller vid borjan av 2009 ca. 1100 personer. Foretaget ar baser-

at i Ornskoldsvik och ar en del av den globala forsvarskoncernen BAE Systems

med huvudkontor i Maryland, USA.

Bland foretagets produkter marks bandvagnen Bv206 som aven fatt viss civ-

il anvandning inom bl.a. raddningstjansten, stridsfordonet CV90 (inom svens-

ka forsvaret kallad Stridsfordon 90) och den bepansrade transportbandvagnen

BvS10.

1.1.1 Bandvagn BvS10

BvS10 ar en bepansrad bandvagnsmodell bestaende av tva hopkopplade vagnar

med s.k. midjestyrning, vilket innebar att leden mellan vagnarna vinklas via hy-

draulik for att svanga. Figur 1.1 visar en bandvagn sett fran sidan. Den har god

framkomlighet aven i svar terrang, och kan ta sig uppfor backar med upp till

45◦ lutning. Den maximala hastigheten pa vag ar 65 km/h och fordonet ar aven

amfibiskt, dvs. det flyter och kan ta sig fram over vatten i ca 5 km/h.

Bepansringen ger skydd mot granatsplitter, handburna automatkarbiner och

lattare kulsprutor. For ytterligare skydd finns totalt atta rokgranatskastare mon-

terade i grupper om fyra pa den framre vagnen. Vid takluckan i den framre vagnen

finns aven fasten for montering av en kulspruta. Den forhallandevis latta bepan-

sringen och bevapningen gor att fordonet inte primart ar avsedd for strid, utan

anvands i forsta hand for transport av trupper och materiel. Varianter finns ocksa

for anvandning som ambulans- och bargningsfordon inom det militara. BvS10 har

plats for totalt 12 soldater och kan ta en last pa 3850kg[1].

1.1.2 VIS

For personalen i ett stridsfordon ar det av storsta vikt att ha en god uppfattning

om situationen i och utanfor fordonet. For att uppna detta ar moderna strids-

fordon utrustade med ett stort antal inre och yttre sensorer. De inre sensorerna

mater teknisk data om fordonet som exempelvis hastighet, lutning och oljetryck,

medan yttre sensorer till exempel kan upptacka att fordonet belysts med laser

1.1. Bakgrund 3

Figur 1.1: Bandvagn BvS10[1].

och darmed loper risk att bli beskjutet. For att informationen fran sensorerna

ska vara latt att ta till sig for besattningen behover den sammanstallas och pre-

senteras. Det system som utfor detta kallas Vehicle Information System (VIS).

Granssnittet till VIS ar normalt en eller flera fasta skarmar i fordonet, med an-

passad information for den roll som den aktuella besattningsmedlemmen har i

fordonet.

1.1.3 CAN-standarden

CAN (Controller Area Network) ar en internationell standard for kommunika-

tion mellan olika delar i ett fordon[2, 3]. Genom att folja CAN-standarden sa

kan alla delar i fordonet kommunicera over samma buss. Utan en gemensam buss

sa skulle alla delar som behover kommunicera med varandra ha en egen kop-

pling, vilket skulle innebara en mycket stor mangd kablage. Detta skulle vara

bade utrymmeskravande och kostsamt. Olika signaler i ett fordon har ofta oli-

ka prioritet; t.ex. ar det normalt sett viktigare att bromsljuset tands an att

vindrutetorkaren startar. CAN-bussen anvander sig darfor av en “forhandling”

mellan de komponenter som vill sanda data innan sjalva sandningen ager rum.

Forhandlingen garanterar att den signal som har hogst prioritet far sanda forst.


Externa fordonssystem som VIS kan ocksa lyssna pa trafiken over CAN-bussen

for att fa information om fordonets status.

1.1.4 Microsoft .NET

Microsoft .NET ar en plattform for att skapa mjukvara under Windows-plattformen.

.NET bestar av ett antal komponenter:

– En uppsattning av maskin-oberoende instruktioner och ett binarformat for

dessa, kallat Microsoft Intermediate Language (MSIL).

– En virtuell maskin som kan exekvera MSIL-instruktioner genom att oversatta

dem till instruktioner for den aktuella processorn.

– Ett lagnivasprak for instruktionsuppsattningen, vilket fyller samma funk-

tion som Assembler for vanliga processorinstruktioner.

– En gemensam modell for hognivasprak som anvander .NET, kallad Common

Language Interface (CLI). Modellen beskriver bl.a. hur klasser och metoder

lagras och anvands, vilket gor det mojligt for olika hognivaprogramsprak

inom .NET att dela kompilerade bibliotek med varandra.

– Microsoft stoder i dagslaget ett antal hognivaprogramsprak, bland annat:

C#, C++/CLI och Visual Basic .NET.

1.2 Rapportens struktur

En kort beskrivning av varje kapitel i rapporten foljer nedan. Kapitlen Kompo-

nentbaserad utveckling och Realtidsaspekter pa garbage collection ar forfattarnas

litteraturstudier, och kan lasas separat fran ovriga rapporten.

Problemstallning

Kapitlet Problemstallning redogor for den nuvarande losningen for VIS och gar

sedan igenom de problem som vart arbete ar tankt att adressera.

1.2. Rapportens struktur 5

Metod

Kapitlet Metod visar det tillvagagangssatt vi valt for arbetet och dokumenterar

de val som vi gjort.

Komponentbaserad utveckling

I detta kapitel gors en genomgang av den designprincip som ligger till grund for

implementationen.

Realtidsaspekter pa garbage collection

Det finns en inneboende problematik i att anvanda sprak som bl.a. .NET-familjen

eller Java for att skriva tidskansliga system, som t.ex. VIS. Kapitlet redogor for

problematiken och de framsteg som gjorts inom omradet for att ta fram en losning.

Systembeskrivning

Kapitlet redovisar systemets arkitektur och uppbyggnad.

Slutsats

Vi redogor for det vi kommit fram till efter avslutat arbete och tar upp be-

gransningar och forslag pa framtida forbattringar av systemet.


Kapitel 2

Problemstallning

Bandvagnen BvS10 har tidigare helt saknat ett informationssystem, daremot har

ett annat av Hagglunds stridsfordon, CV90, varit utrustat med ett sadant system

under flera ars tid. Denna VIS-losning ar utvecklad i C++ med Hagglunds eg-

na mjukvarubibliotek VisBas som grund. Det grafiska granssnittet ritas upp via

Windows inbyggda bibliotek Windows GDI(Graphics Device Interface)[4]. GDI

tillhandahaller funktioner for utritning av enklare geometriska former, sasom cirk-

lar och rektanglar, samt text och bilder.

Da VisBas ritar upp sin grafik direkt och alltsa inte anvander sig av Windows

normala kontroller och granssnittselement har det inte funnits nagot grafiskt stod

for design av granssnittet, utan detta har skett helt via programmering i GDI.

Att skapa en sammansatt grafisk kontroll som till exempel en hastighetsmatare

har darfor varit forenat med en stor arbetsinsats fran utvecklarnas sida. Man

har ocksa manuellt fatt aterskapa manga av de standardkontroller som finns i

operativsystemet sasom tradvyer och listor.

En annan oonskad effekt ar ocksa att designavdelningens arbete med granssnittet

har varit i form av bilder och skisser, vilka sedan har behovts aterskapas i kod

av utvecklarna for att kunna anvandas i den slutliga VIS-applikationen. Ett mer

onskvart arbetsflode skulle sjalvfallet vara att material som framstallts pa desig-

navdelningen latt skulle kunna anvandas direkt i den slutgiltiga produkten.

Pa grund av dessa begransningar i den nuvarande tekniska losningen for VIS

sa har man pa Hagglunds darfor intresserat sig for att flytta utvecklingen till

7

8 Kapitel 2. Problemstallning

.NET, vilket man hoppas ska ge en snabbare och enklare utvecklingsprocess.

2.1 Implementation av J1939-protokollet

Ett ramverk for signalkommunikation via CAN skrivet i C# for .NET-plattformen

finns tillgangligt, men behover utokas med en modul for att stodja en CANCase-

hardvaruenhet. Signalerna fran motor och vaxellada foljer en protokollstandard

ovanpa CAN kallad J1939, varfor ett sadant lager ocksa maste implementeras

i ramverket. Da J1939 ar en forhallandevis omfattande standard kommer en-

dast de delar som ar relevanta for var anvandning att implementeras. Exem-

pelvis utelamnas stod for J1939-meddelanden uppdelade pa flera separata CAN-

meddelanden.

2.2 Grafiskt stod for design

For att underlatta for bade designers och programmerare ska vyer i VIS kunna

framstallas genom “dra-och-slapp” i Visual Studios designlage, utan att behova

programmera. Aven kopplingen mellan en grafisk kontroll och vilket varde den

visar ska kunna anges pa detta satt.

2.3 Sakerstallande av tidsgarantier for signaler

For ett system som anvands i en sa kritisk miljo som ett stridsfordon ar det viktigt

att den information som visas for anvandaren ar korrekt och aktuell. Da .NET-

plattformen inte ar en realtidsplattform sa finns risken att en operation i systemet

kan komma att ta sa lang tid att informationen i en signal ar gammal nar den

kommer fram. For att minska risken for detta maste signalens alder kontrolleras

sa nara som mojligt till den punkt dar den ska visas pa skarmen. Vissa signaler

kan ocksa vara viktigare an andra, sa ett system for att ge signaler olika prioritet

behovs.

En ytterligare komplikation inom detta omrade ar att programspraken pa

.NET-plattformen anvander sig av s.k. garbage collection, vilket inverkar negativt

pa systemets mojlighet att garantera tidskrav. Med anledning av detta undersoker

2.4. Stod for olika sprak och mattenheter 9

vi ocksa de framsteg som gjorts for att anpassa system med garbage collection

till tidskansliga system.

2.4 Stod for olika sprak och mattenheter

Programmet ska kunna oversattas till olika sprak, och det ska aven vara mojligt

att byta sprak medan programmet kors. Utover detta ska det kunna hantera

andra kulturspecifika installningar som mattenheter. Till exempel ska hastighet

kunna visas i km/h for en svensk anvandare och som mph for en amerikansk.

2.5 Tredimensionell grafik som ett visuellt hjalpmedel

Det finns onskemal inom BAE Systems Hagglunds AB att undersoka om tredi-

mensionell grafik kan anvandas for att forbattra VIS. Vi undersoker darfor vilka

losningar som finns for 3D-grafik i .NET inom ramen for VIS.

2.6 Examensarbetets mal

Uppgiften bestar i att med utgangspunkt fran BvS10-bandvagnen implementera

en prototyp av en ny VIS skriven med Microsofts .NET-bibliotek, och genom

detta utvardera vilka mojligheter och problem som den nya tekniken innebar.

Den ursprungliga specifikationen for examensarbetet aterfinns i bilaga B. Efter

samrad med vara interna och externa handledare beslutade vi att ta bort punk-

terna om simuleringsmodell och fordjupning inom GUI-design och usability och

ersatta dem med en fordjupning inom realtidsaspekter pa garbage collection

Arbetet innefattar analys av problemstallningen, framtagning av en design for

applikationen samt implementation.

2.7 Antaganden

Motor och vaxellada ar de enda delar i BvS10 som har sensorer tillgangliga for

avlasning via CAN-bussen i BvS10. Da en del av arbetet innefattar att undersoka

ny funktionalitet for VIS, sa har vi arbetat med antagandet att ytterligare sensorer


finns tillgangliga. Dessa virtuella sensorer har simulerats via signalramverket (se

avsnitt 6.2 Kommunikationslagret) pa samma satt som de verkliga signalerna sa

att de latt skulle kunna anvandas om de infordes i det fysiska fordonet.

De virtuella sensorerna ar tre till antalet och indikerar vinkeln i hojd- resp.

sidled mellan de tva vagnsdelarna, samt huruvida den bakre luckan ar oppen eller

stangd.

2.7.1 Kravspecifikation

Den ursprungliga specifikation for examensarbetet(Se bilaga B) innehaller endast

generella och overgripande krav, darfor har vi tillsammans med BAE System

Hagglunds AB tagit fram denna detaljerade kravspecifikation.

1. Definitioner

(a) Logisk signal: En struktur med ett varde och ett ID-nummer, unikt for

signaltypen.

(b) Hardvarusignal: Data bestaende av varde och ID-nummer som tas

emot fran externa enheter.

(c) Vy: En uppsattning av grafiska kontroller som visas samtidigt pa skarmen.

Endast en vy at gangen kan visas pa skarmen.

2. Teknik

Programmet ska:

(a) utvecklas i Visual Studio 2008.

(b) vara skrivet for .NET-platformen.

(c) ga att kora under Windows XP.

(d) anvanda XNA for 3D-visualisering.

(e) anvanda Dundas Gauges-komponenter[5] for grafiska matare

(f) utvecklat i C++/CLI for de delar som kraver samverkan med kod

utanfor .NET och C# for ovriga delar.

(g) visa manualtexter med hjalp av en webblasarkomponent.

3. Generellt

2.7. Antaganden 11

(a) Programmet ska anvanda sig av data binding mellan presentationsla-

gret och presentationskomponenter.

(b) Varje signals tidsstampel skall bevaras sa lange som dess varde be-

handlas i systemet.

(c) En grafisk komponent som visar ett signalvarde inaktiveras om vardets

alder overstiger en given tid.

4. Allmant om vyer

(a) I varje vy (forutom hemvyn) ska det finnas en hemknapp som tar

anvandaren till hemvyn.

(b) Hemknappen ska indikera nar det finns ett aktivt larm.

(c) Programmet ska ha foljande vyer; Hem, Forare, Installningar, Larm

och Manual.

5. Hemvy

(a) Ska innehalla en meny som tar anvandaren till andra vyer.

(b) Innehaller ett tredimensionellt piktogram av vagnen, som indikerar:

i. vinkeln pa mittleden, i bade sid- och hojdled.

ii. status pa luckor.

iii. vid ett larm: fran vilken del av vagnen som larmet harstammar

(c) Visar fordonets hastighet.

6. Installningsvy

(a) Det ska ga att andra systemets sprak (nationella installningar).

(b) Det ska ga att se systemets versionsnummer.

7. Larmvy

(a) Ska innehalla en lista med aktiva larm i systemet.

(b) Larm som ej langre ar aktiva ska visas separat.

(c) Nar man trycker pa ett larm ska en beskrivning visas.

8. Manualvy


(a) Manualsidorna finns ordnade efter amnesomrade i en tradstruktur (reg-

istret).

(b) Registret och manualsidans innehall delar plats pa skarmen.

(c) Storleksforhallandet mellan registret och manualsidan kan andras steglost.

(d) Manualsidor ska kunna innehalla lankar till andra sidor.

9. Forarvy Innehaller matare som visar foljande information:

(a) Fordonshastighet

(b) Motortemperatur

(c) Motorns varvtal

(d) Nuvarande vaxel

(e) Batteristatus

(f) Oljetryck

Kapitel 3

Metod

Vi redogor har for de val som gjorts gallande de tekniska losningar som anvandes

i arbetet.

3.1 Oversattning

Vid oversattning av en applikation mellan olika landers sprak ar det onskvart

att kunna separera de delar som visas for en anvandare fran den bakomliggande

logiken. Dessa delar benamns vanligen resurser och lagras i en s.k. resursfil. En

egen version av resursfilen skapas for varje sprak/kultur som applikationen ska

stodja. En resursfil bestar av en tabell dar varje oversattningsbart objekt utgor

en rad. Varje rad har tre kolumner; objektets ID, objektets datatyp (textstrang,

bild, etc.) samt dess varde. Resursfilerna kompileras sedan till en .NET-assembly

som antingen kan infogas direkt i .exe-filen eller lagras i en extern DLL-fil. Detta

innebar flera fordelar for utvecklingsteamet:

– Personen som gor oversattningen kan vara specialiserad inom det omradet

och behover inte ha kunskaper i programmering.

– Flera personer kan arbeta med olika oversattningar parallellt.

Metoden kan ocksa medfora vissa problem:

– Det kan vara svart for en oversattare att se vilket sammanhang som oversattningen

tillhor. Exempelvis kan det engelska ordet “gear” betyda bade “kugghjul”

13

14 Kapitel 3. Metod

och “vaxel”.

– Langden pa ett ord eller en fras kan variera betydligt mellan olika sprak,

vilket kan medfora att texten inte langre ryms pa det tilltankta utrymmet.

Vi har jamfort tre verktyg for oversattning av .NET-applikationer for att se

hur de hanterar problemen ovan.

– Resourcer 4.1.0.0 [7]

– Globalizer .NET 1.6.1.0 [8]

– Sisulizer 2008 [9]

Resourcer

Resourcer (se figur 3.1) ar det enklaste och samtidigt mest begransade verktyget.

Det visar oversattningsbara objekt som rader i en tabell, pa liknande satt som Vi-

sual Studios inbyggda resurseditor. Den kompilerar inte de oversatta resursfilerna

till .NET-assemblies, utan detta maste hanteras av utvecklarna sjalva.

Figur 3.1: Oversattning av forarvyn i Resourcer.

3.1. Oversattning 15

Globalizer

Globalizer (se figur 3.2) visar pa samma satt som Resourcer oversattningsbara

objekt i en tabellstruktur. Till skillnad fran Resources kompilerar det de skapade

resursfilerna direkt till .NET-assemblies. Globalizer erbjuder aven mojligheten att

forhandsgranska utseendet pa ett formular utan att behova starta huvudapplika-

tionen.

Figur 3.2: Oversattning av forarvyn i Globalizer.

Sisulizer

Sisulizer (se figur 3.3) erbjuder en delad vy dar oversattaren kan se formularet som

han/hon for tillfallet arbetar med tillsammans med tabellen av oversattningsbara

objekt. Sisulizer gor det ocksa mojligt for oversattaren att justera positionen och

storleken pa formularets kontroller for ett specifikt sprak. Dock visas bara .NETs

inbyggda kontroller sa som de ser ut i verkligheten. Ovriga kontroller visas istallet

som fyrkantiga platshallare. Likt Globalizer kompilerar Sisulizer ocksa de skapade

resursfilerna till .NET-assemblies.

16 Kapitel 3. Metod

Figur 3.3: Oversattning av installningsvyn i Sisulizer.

Slutsats

Baserat pa jamforelsen drar vi slutsatsen att Sisulizer ar det verktyg som passar

bast for att losa de problem som identifierats. Vi valjer alltsa att anvanda Sisulizer

for att hantera oversattning av den prototyp som vi implementerar.

3.2 Tredimensionell grafik

For hardvaruaccelererad 3D-grafik pa Windows-plattformen finns i huvudsak tva

olika tekniska losningar: OpenGL och Direct3D. OpenGL ar ett oppet standard-

bibliotek for 3D-accelerering med ett API mot C/C++. Direct3D ar utvecklat av

Microsoft och har ett API mot C++. Microsoft paborjade ett arbete med att ska-

pa ett API for Direct3D mot .NET-plattformen, men API:t plockades sedan bort

fran utvecklingskitet[6]. I samband med nedlaggningen presenterade de XNA-

plattformen som ar ett .NET-API i forsta hand inriktat mot spelutveckling.

Sin inriktning till trots ser vi XNA som det lampligaste alternativet for ar-

betet, da det ar det enda .NET-API:t for 3D som officiellt stods och aktivt utveck-

las. XNA erbjuder ocksa flera inbyggda komponenter, som klasser for inlasning

och uppritning av modeller. Da 3D-grafik endast ar en mindre del av vad som

3.2. Tredimensionell grafik 17

utgor VIS, bedomer vi forenklad utveckling som betydligt mer vardefullt an den

eventuellt minskade prestanda som .NET kan medfora.

18 Kapitel 3. Metod

Kapitel 4

Komponentbaserad design

Vid utveckling av stora applikationer brukar man strava efter att dela upp pro-

grammet i flera delar som tar hand om olika funktioner. Hur man gor denna

uppdelning beror pa utvecklarnas mal; i de flesta fall ar det viktigt att delarna

gar att ateranvanda separat men aven att dessa delar gar att utveckla och testa

for sig. Dessa delar brukar man kalla for moduler eller komponenter.

4.1 Komponentens framvaxt

Nar de forsta datorerna kom sa gjordes all programmering i mycket maskinnara

programsprak. Datorerna hade mycket sma mangder minne vilket gjorde att pro-

grammens storlek begransades. Funktioner och funktioner med parametrar intro-

ducerades man da for att spara minnesutrymme.

I takt med att maskinoberoende programmeringssprak utvecklades sa blev det

allt vanligare att man ateranvande funktioner fran program i ett annat program.

I samband med detta borjade man skapa samlingar av anvandbara funktioner i

mjukvarubibliotek. I takt med detta vaxte det fram en marknad for mjukvarubib-

liotek sa kunde programmerare valja att kopa in delar till sina program istallet

for att utveckla allt sjalv[16]. Att kopa en fardig komponent kan i manga fall

vara billigare an att utveckla den sjalv. Den totala konstaden for att anvanda en

komponent i ett program bestar av inkopspriset och kostnaden for att integrera

den.

19

20 Kapitel 4. Komponentbaserad design

4.2 Vad ar en mjukvarukomponent?

Det finns ett flertal definitioner pa vad en mjukvarukomponent ar, men Szyper-

skis definition har emellertid blivit allmant accepterad[17]. Szyperskis definition

sager bland annat att en mjukvarukomponent ar en separat enhet, som har ett

granssnitt och kan anvands av en tredje part[18]. Vart att notera ar att definitio-

nen inte staller nagra krav pa programmet som anvander komponenten, eller pa

andra komponenter i samma system. Det ar darfor inte mojligt att endast utifran

denna definition att skapa komponenter som kan samverka med andra komponen-

ter. Utvecklaren kan sjalv avgora vilka designmonster och datatyper som denna

vill anvanda.

4.3 Komponentbaserad design

Komponentbaserad design flyttar utvecklarens fokus fran mjukvaruprogrammer-

ing till mjukvarukonstruktion[16]. Istallet for att skriva stora mangder kallkod

kan programmeraren koncentera sig pa att koppla ihop fardiga komponenter. Det-

ta forutsatter givetvis att det finns lampliga komponenter att tillga, vilket inte

alltid ar fallet. Aven om det finns lampliga komponenter sa kan det vara svart

att samverka med varandra[17], detta kallas att limma ihop dem fran engelskans

glue code. Dels sa kan man behova konvertera mellan komponenternas datatyper

men aven mellan fysikaliska enheter[19], darav sa ar det mycket svart att pa ett

generellt satt binda ihop olika komponenter. Darfor ar det fordelaktigt att defin-

era upp en modell for hur en komponent ska se ut och hur den kommunicerar med

andra delar av systemet. I [19] forslas en losning baserad pa formell semantik for

att avgora hurvida tva komponenter ar kompatibla och att automatiskt generera

lim-koden.

4.4 Komponentbaserad utveckling

I objektorienterad programmering stravar man efter att kapsla in sin kod sa att

varje objekt har en given roll som den ansvarar for. Det finns ett antal principer

som styr vad som ar god objektorienterad sed, en av dessa ar The Single Re-

sponsibility Principle som sager att ett objekt endast ska ha en roll, ett ansvar-

4.5. Microsoft .NET och komponenter 21

somrade[15]. Detsamma kan sagas om komponenter. En komponent skiljer sig

dock pa ett omrade, att den alltid ar byggd for att ateranvandas[17]. Detta staller

andra krav pa utvecklingsprocessen.

Som ett exempel, betrakta ett objektorienterat program som behandlar in-

formation som kommer in fran en hardvaruenhet. Enheten ar ansluten till en

signal-buss dar andra enheter kommunicerar med varandra. Varje gang enheten

far in en signal sa anropas en callback-funktion. Varje gang det kommer in en

signal sa ska den avkodas och konverteras till ratt fysikalisk enhet varpa vardet

ska visas pa en matare.

Figur 4.1: Ett exempel pa objektorienterad design. Pilarna visar anropsflodetmellan klasserna.

I figur 4.1 visas en enkel skiss pa hur ett sadant system skulle kunna delas

upp, med tre klasser for varsin roll. En ansats att anvanda samma uppdelning for

komponenter medfor att det uppstar ett cirkelberoende mellan komponenterna.

Detta ar inget problem for komponenter i sig, men blir problematiskt pa .NET-

plattformen vilket diskuteras nedan.

4.5 Microsoft .NET och komponenter

Den minsta fristaende enheten i .NET kallas for en assembly, det ar en fil med

filandelsen .DLL eller .EXE som innehaller en samlig av klasser och resurser sa

som bilder, stangar etc. En assembly har ett eget versionsnummer och en kul-

turinstallning[14]. En assembly med minst en klass med publik konstruktor upp-

fyller alltsa Szyperskis definition av en mjukvarukomponent. En .EXE-fil maste


man ha en programstartpunkt. Darfor placerar man vanligtvis man ett bibliotek i

en .DLL-fil som man sedan anvander sig av i en annan assembly. En assembly som

beror pa en annan assembly sag ha en en referens till denna. Nar man kompilerar

en assembly maste man ha tillgang till alla assemblies som den refererar till. I

figur 4.1 beskrivs ett objektorienterat system dar olika klasser anropar varandra;

om man skulle placera dessa tre klasser i varsin assembly skulle det inte ga att

kompilera systemet pa grund av cirkelberoendet av refererenser.

Till skillnad fran Java dar varje klass kompileras separat sa kan en assembly

innehalla flera klasser. Det finns inte heller nagot satt att enbart ladda in delar av

en assembly [20]. En assembly kan antingen laddas in vid start av applikationen

eller dynamiskt laddas in under korning.

Enligt .NET-ramverket ar en komponent en klass som implementerar granssnittet

IComponent [13]. Detta granssnitt beskriver varken hur en komponent ska ak-

tiveras eller samverka med andra komponenter. I .NET arver alla grafiska kon-

troller ifran klassen Control som i sin tur implementerar granssnittet IComponent,

vilket gor dem till komponenter enligt .NET.

4.6 Komponentinitiering

Betrakta ett systemet som innehaller tre komponenter; en hardvaruenhet, en sig-

nalhanterare och en databas. Hardvaruenhet ar kopplad till en motor som den

kan skicka meddelade till, motorn sender regelbundet ut information fran interna

matare till hardvaruenheten. Databasen innehaller information om hur om hur

man avkodar dessa. Varje gang signalhanterare far in en signal och har avkodat

den sa skriver den ut informationen pa skarmen. Ett sadanat system skulle kunna

limmas ihop som i figur 4.2.

Databas d = new Database("V12 motor");

SignalHandler sh = new SignalHandler(d);

EngineHardware e = new EngineHardware();

while(running) {

Signals[] signals = e.FetchSignals();

Sting metadata = sh.parse(signals);

print(metadata);

}

Figur 4.2: Pseudokod for ett system med tre komponenter.

4.6. Komponentinitiering 23

I figur 4.2 binds alla komponenter ihop genom dess konstruktorer, men det

finns inget i Szyperskis definition av en komponent som sager att komponent

maste initeras pa detta satt. Det ar alltsa upp till programmeraren att design sin

komponents granssnitt.

Anta att systemet maste modifieras for att i en senare version sa behover

databaskomponenten information om vilken arsmodell som motorn har for att

kunna avkoda signaler, och att det enda sattet att ta reda pa den informationen

ar att underkorning forst fraga motorn om detta. Det finns att flertal satt att losa

detta pa, exempelvis kan systemet vid uppstart anropa hardvarukomponenten

som fragar motorn efter arsmodell och skicka vidare informationen till databaskom-

ponenten.

Databas d = new Database("V12 motor");

SignalHandler sh = new SignalHandler(d);

EngineHardware e = new EngineHardware();

int version = e.getEngineVersion();

d.setEngineVersion(version);

while(running) {

Signals[] signals = e.FetchSignals();

Sting metadata = sh.parse(signals);

print(metadata);

}

Figur 4.3: Pseudokod som visar systemet i 4.2 med en utokning for att hanteraflera versioner av motorn.

I figur 4.3 visas hur man anpassa systemet for hantera flera arsmodeller,

dessvarre kraver detta att tva komponenters grannssnitt modifieras, vilket man

bor undvika da detta kan paverka andra systemen som anvander samma kompo-

nent. Dessutom har limkoden forandrats.

Detta visar just hur svart att kan vara att designa ett komponentbaserat

system som klarar av forandingar. Det basta hade varit ifall endast en komponent

kunde utokas och sedan kunde installeras i systemet, vilket Szyperskis definition

sager att mjukvarukomponent ska klara av.


4.7 Komponentramverk

Det finns ett flertal definitioner pa vad ett ramverk ar, vissa anser att det ar ett

designmonster medans andra anser att det ar en typ av komponent. Ett ramverk

bestar av oftas av ett antal granssnitt och en definition av hur instanser av dessa

granssnitt samverkar med varandra. Ett ramverk ger en komponent en miljo, en

kan sedan gora antagade om denna miljo[23]. Nagot forenklat kan man saga att

ett ramverk ar ateranvandbar limkod.

I avsnitt 4.6 visas ett komponentbaserat system med en startpunkt dar utveck-

laren bestamde nar komponenterna skulle anropas, programflodet utgick alltsa

ifran komponenterna. I ett ramverk ateranvander man startpunkten och designar

komponenterna sa de passar in i ramverket, bade systemet struktur och program-

flodet utgar da ifran ramverket. Detta kallas inversion of control [23].

4.7.1 Dependency injection

Nar ett system vaxer i storlek och blir mer komplext sa uppstar fler och fler

beroenden mellan komponenter. En komponent kan beror pa en annan komponent

som i sin tur kan anvanda en annan komponent och sa vidare. For att beroenden

mellan objekt i olika komponenter sa later man det objekt som ska instansiera ett

annat objekt bestamma med vilka andra objekt den ska interagera. Det vanligaste

sattet att implemtera detta ar att anvanda sig av en designmonstret abstrakt fabrik

som kan instansiera och konfigurera objekt i komponenter[22].

4.7.2 Komponentinitiering med en fabrik

En fabrik ar i sig en egen komponent som kan starta upp hela systemet. Detta gor

den genom att anropa alla komponenter och formedla kontakt mellan dom. Nar

programmet sedan ska avslutas sa ser fabriken till att alla komponenter stangs

ner pa ett korrekt satt. Man skulle kunna se fabriken som ett register dar varje

post innehaller ett komponent-namn med tillhorande referens.

Det det finns tva typer av fabriker, statiska och dynamiska. I en statisk fabrik

far man manuellt instansiera komponenter, och definiera upp get-funktioner for

dessa(se figure 4.4). For att det inte ska uppsta ett cirkelberoende mellan en kom-

ponent och den statiska fabriken sa maste komponent-registret ligga i separata

4.7. Komponentramverk 25

public class Factory {

public static ICANHardware getCan() {

CanCase can = new CanCase();

can.setBandWidth(250000);

can.busID(0);

return can;

}

public static IDatabase getDatabase() {

return new XMLDatabase("signals.xml");

}

}

Figur 4.4: Pseudokod for en statisk fabrik. Fabriken kan instansiera och konfig-urera tva objekt.

assemblies. Med en dynamisk fabrik sa anvander man sig av meta-programmering

for att instansiera komponenterna.

For att dynamiskt kunna instansiera en klass sa behover man veta dess namn

och i vilken assembly den ar placerad. Denna information kan man exempelvis

placera i en extern konfigurationsfil. Den dynamiska fabriken har alltsa inget

beroende pa de komponent som den skapar. Detta beroende har en statisk fabrik

vilket medfor att man maste kompilera om varje gang man lagger till en kompo-

nent.

Figur 4.5: Beroendegraf for en statisk komponentfabrik.

En dynamisk fabrik behover till skillnad fran en statisk fabrik inte bero pa

de klassen som den ska instansiera, dock finns beroendet mellan registret och

komponenterna kvar. Detta beroende gar inte att ta bort men det gar att sla

ihop fabriken med registret utan att det uppstar ett cirkelberoende. I bada fallen

av fabriker sa kommer de komponenter som anvander sig av andra komponenter


att bero pa dem.

<components>

<component name="Can" classname="CanCase">

<property name="bandwidth">250000</property>

<property name="busid">0</property>

</component>

<component name="Database" classname="XMLDatabase">

<property name="filename">signals.xml</property>

</component>

</components>

Figur 4.6: Exempel pa en konfigurationsfil for en dynamisk fabrik (jfr 4.4).

Med en statisk fabrik har man full kontroll pa vad som behovs goras for

att starta och avsluta systemet. I ett system med en dynamisk fabrik kan man

lagga denna information i en konfigurationsfil(se figur 4.6) for varje komponent

eller lata varje komponent implementera ett granssnitt som tillater fabriken att

anropa komponentens initieringskod.

Figur 4.7: Beroendegraf for en dynamisk komponentfabrik.

4.7.3 Initieringsordning

Betrakta ett system som bestar av tre komponenter, systemet startas upp med en

dynamisk fabrik. Den forsta komponenten ar en motorkomponent som behandlar

signaler som kommer in pa CAN-bussen fran fordonet motor. Signalerna tas emot

av en CAN-komponent som skickar vidare de signaler till andra komponenter. For

att man ska fa ett anrop av CAN-komponenten maste man registrera sitt intresse

for en viss signal hos den. Den sista komponenten ar en databas-komponent som

motor-komponenten behover for att kunna sla upp vilket CAN-Id som motsvarar

en vilken given motorsignal, med detta CAN-Id kan motorn registrera sig hos

CAN-komponenten.

4.7. Komponentramverk 27

Figur 4.8: Beroendegraf for systemet.

Nar motorkomponent initieras kommer den behova fraga komponent-registret

efter bade databas- och CAN-komponenten. Darfor maste bada startas upp fore

motorkomponenten, annars kommer den inte startas korrekt. For att losa prob-

lemet kan vi helt enkelt bara specificera att fabriken ska starta databas- och

CAN-komponenterna forst. En initieringsordning loser tyvarr inte det generella

problemet.

Om vi ger registret mojlighet att initiera oinitierade komponenter nar dom

efterfragas skulle vi slippa att definiera upp en initieringsordning. Det skulle losa

problemet i detta system men inte generellt, exempelvis kan man aldrig starta

ett system nar det finns ett cirkelberoende i initieringsordningen.

Betrakta ett system dar vi vill brygga signaler fran en hardvara till en annan.

Bada hardvarorna ar en egen komponent, for att ta emot signaler far man gora

pa samma satt som i forra systemet. I bada hardvarornas komponenter gors det

ett anrop till varandra och sager att signaler ska skickas till dem. Har har vi ett

cirkelberoende i initieringsordningen som gor att systemet inte gar att starta,

men om vi istallet delar uppstarten i tre faser sa kan vi i de flesta fall ga runt

problemet:


– Instansering

– Binding

– Start

I denna uppdelade start sa instanserar fabriken forst alla komponenter och

satter in dem i registret, i nasta steg kan komponenterna anropa registret och

darmed varandra. I vart fall kommer vara hardvaror att kunna anropa varandra

och be om signaler. Nar bindningssteget har korts for alla komponenterna kommer

fabriken att anropa varje komponents start-metod.

4.8 Service-orienterad programmering

Service-orienterad programmering [21, 12] ar en programmeringsparadigm som

foresprakar att man modellerar sina problem och losningar som ett satt av tjanster.

En tjanst ar ett kontrakt som beskriver ett beteende som tillhanda halls av en

komponent och konsumeras av andra komponenter. En komponent behover inte

vara medveten om vem som tillhanda haller en tjanst utan endast dess semantik.

Detta resulterar i att en komponent aldrig beror pa en annan, utan endast pa ett

antal tjanster. Detta brukar man oftast astadkomma med ett tjanste-register[12].

4.9 Slutsats

Det ar tydligt att komponent ar har for att stanna, det faller sig vara ett naturlig

steg vidare fran funktionsbibliotek. Aven om det finns flera uppfattningar om vad

som ar en komponent och vad ett ramverk bestar av sa ar det tydligt att detta

ar ett viktigt paradigmskifte.

Kapitel 5

Realtidsaspekter pa

Garbage Collection

Garbage Collection ar en teknik for att automatiskt hantera avallokering av minne

for att underlatta for programmeraren och reducera risken for fel. Det anvands i

flera av dagens mest anvanda programsprak; bland dem marks framst Java och

spraken pa .NET-plattformen (C#, Visual Basic.NET, C++/CLI, m.fl.).

Pa grund av de pauser i programexekveringen som garbage collection medfor,

har tekniken lange varit olamplig for anvandning i system med hoga krav pa

responstid. En avsevard mangd forskning har dock pa senare ar riktats mot att

ta fram nya algoritmer for att mojliggora detta. Vi redogor for de vanligaste

teknikerna som anvands for att anpassa garbage collection till realtidssystem och

ser pa hur de anvands i nagra foreslagna losningar.

5.1 En kort introduktion till minneshantering

Datorprogram anvander i regel tva skilda strategier for att allokera minne: stack-

allokering och heapallokering. Stackallokering sker fran en mindre del av minnet

(normalt nagon eller nagra MB i storlek pa en typisk persondator[24, 25]) som

foljdaktligen benamns stacken. Nar ett funktionsanrop gors skapas en s.k. stack

frame, vilket ar en minnesarea pa stacken som innehaller de parametrar som

skickats till funktionen (dessa kan aven skickas direkt via processorns register),

29

30 Kapitel 5. Realtidsaspekter pa Garbage Collection

en aterhoppsadress som anger vilken instruktion som ska koras efter att funktio-

nen avslutas, samt de lokala variabler som funktionen anvander sig av. En stack

frame ar direkt knuten till livslangden for ett funktionsanrop; nar anropet avs-

lutats frigors dess minne automatiskt. Da varje trad i ett flertradat program har

sin egen kedja av anropade funktioner sa anvands en stack per trad.

Ovrigt internminne som en process har tillgangligt benamns heap och anvands

for att allokera data som behover finnas kvar efter att funktionen som gjorde

allokeringen slutforts, eller for data som ar for stor for att rymmas pa stacken.

Till skillnad fran stacken finns det endast en heap per process, vilken kan anvanda

hela mangden minne som ar tillgangligt for processen. Heapen delas foljdaktligen

av alla processens tradar. Eftersom avallokeringen av data pa heapen inte ar

knutet till slutet pa ett funktionsanrop sa maste detta minne explicit avallokeras

nar det inte langre behovs.

5.2 Allmant om Garbage Collection

Avallokeringen av minnet pa heapen i ett programsprak kan delas upp i tva

huvudsakliga kategorier: manuell och automatisk. Vid manuell minneshantering,

vilken varit traditionellt dominerande, ar programmeraren sjalv ansvarig for att

explicit frigora det minne som dynamiskt allokerats pa heapen. Detta gors normalt

genom anrop till funktioner som free() i C eller inbyggda operatorer som delete i

C++.

Automatisk minneshantering, kallad Garbage Collection (nedan: GC), avlas-

tar programmeraren genom att skota denna avallokering automatiskt. Objekt som

inte langre behovs avallokeras automatiskt av en process i sprakets kortidsbibliotek,

garbage collectorn.

Vid diskussion av garbage collection benamns huvudtraden i programmet nor-

malt mutator, da det enda den utfor fran garbage collectorns synvinkel ar att

mutera (forandra) heapen. Mutatorn hanterar alltsa programmets logik och delar

pa tillgangliga minnes- och processorresurser tillsammans med GC:n.

5.2. Allmant om Garbage Collection 31

5.2.1 Nabarhet

For att avgora vilka objekt i minnet som kan frigoras behover man berakna

huruvida de ar nabara eller inte. Ett icke nabart objekt kan inte langre anvandas

och kan darmed tas bort av GC:n. En samling minnesobjekt, rot-objekten, ar

initialt nabara (markeras med tjock ram i figurerna nedan). Rot-objekten ar de

objekt som det existerar referenser till pa programstacken, i processorns register,

eller som globala variabler.

En strategi for att avgora nabarhet som forst kan verka lockande ar referen-

srakning, dvs. att varje objekt lagrar hur manga referenser som pekar pa det. Nar

ett objekt inte har nagra referenser kvar ar det onabart och kan tas bort. Den-

na strategi ar korrekt, men ej fullstandig i den meningen att den aldrig leder till

borttagning av ett refererat objekt, men den misslyckas med att identifiera objek-

tstrukturer med cirkelreferenser som icke nabara. Figur 5.1 visar problematiken:

Rotobjekten A och C refererar enbart till B, men D, E och F har alla inkom-

mande referenser, sa de kommer inte att tas bort, trots att de ar onabara fran

programmet.

Figur 5.1: Felaktigt resultat med referensraknande GC. Objekten D, E och Frefererar till varandra cirkulart, vilket gor att GC:n felaktigt identifierar demsom nabara.

For att undkomma detta problem beraknar man istallet nabarhet pa foljande

satt: om ett nabart objekt A innehaller en referens till ett objekt B, sa ar aven

B nabart. De nabara objekten i systemet ar alltsa dem till vilka man kan folja

en kedja av referenser fran ett rot-objekt. Garbage Collectorn utfor regelbundet


en nabarhetsanalys pa programmet och frigor minne for de icke nabara objekten.

Figur 5.2 illustrerar resultatet av nabarhetsanalysen med denna metod pa samma

exempel som ovan.

Figur 5.2: Genom att folja referenskedjan fran rotobjekten (A och C), kan D, Eoch F korrekt identifieras som onabara.

Det enklaste sattet att utfora en nabarhetsanalys ar vad som brukar kallas

mark & sweep. GC:n traversererar nabarhetsgrafen uttommande med start fran

rotobjekten och markerar de objekt den traverserat. I nasta steg gar den igenom

samtliga objekt i minnet och avallokerar minnet for de objekt som inte markerats

i det foregaende steget.

5.3 Tekniker for okad prestanda

Ett flertal tekniker finns for att oka GC:ns (och som det visar sig, ibland aven

mutatorns) prestanda. Utan att gora nagra ansprak pa att vara en uttommande

forteckning beskriver vi nagra av de vanligast forekommande.

5.3.1 Inkrementell nabarhetsanalys med trefargning

Den naiva mark & sweep-algoritmen beskriven ovan har en stor nackdel som gor

den olamplig att anvanda i praktiken: mutatorn maste pausas under hela GC-

cykeln. For att losa detta problem behovs ett satt att kunna dela upp en GC-

cykel i bitar sa att mutatorn kan exekvera daremellan. Ett satt att gora detta ar

genom att anvanda sig av en trefargad markeringsstrategi for nabarhetsgrafen[26].

5.3. Tekniker for okad prestanda 33

I borjan av markeringsfasen ar rotobjekten gra, medan alla ovriga objekt ar vita.

GC:n foljer sedan alla referenser fran de gra objekten och om referensen pekar

pa ett vitt objekt fargas det gratt. Nar samtliga referenser fran ett gratt objekt

besokts fargas det svart. Detta fortgar till dess att mangden av gra objekt ar tom.

Trefargningsstrategin uppratthaller en viktig invariant: ett svart objekt kan

aldrig ha en direkt referens till ett vitt. En direkt foljd av detta ar att nar mangden

av gra objekt ar tom sa kan vita objekt bara ha referenser fran andra vita objekt.

Detta innebar att de vita objekten nu utan risk kan tas bort av GC:n.

Genom att spara en lista over vilka objekt som for tillfallet ar gra, sa kan GC:n

avbryta markeringsfasen, lata mutatorn exekvera och sedan ateruppta arbetet. En

ytterligare komplikation installer sig dock, eftersom mutatorn da kan skapa nya

referenser mellan objekten och darmed bryta invarianten. GC:n maste alltsa se

till att om en referens laggs till fran ett svart objekt till ett vitt, sa maste det vita

objektet grafargas.

Figur 5.3: Bilden visar hur trefargningsstrategin anvands for att beraknanabarheten i objektgrafen. Notera att ett svart objekt inte vid nagot tillfalledirekt refererar till ett vitt, vilket skulle bryta mot invarianten. I sista bilden saar mangden av gra objekt tom, och det vita objektet F kan nu identifieras somonabart.


5.3.2 Komprimerande vs. icke-komprimerande

Nar GC:n avgjort vilka objekt som ar nabara kan den avallokera minnet for alla

icke nabara objekt. De objekt som ar kvar kan antingen lamnas pa den plats i

minnet dar de ar, eller flyttas ihop till en sammanhangande minnesyta. Om GC:n

flyttar objekten kallas den komprimerande (ibland anvands uttrycket kopierande).

Att flytta ihop objekten gor att det lediga minnet blir sammanhangande och

minnesforlust pga. fragmentering undviks. Detta kan bli ett problem for program

som exekverar under en langre tid och allokerarar och avallokerar mycket minne,

och for system som behover kunna garantera att programmet aldrig ska kunna

fa slut pa minne[33]. Ihopflyttning kan ocksa oka minneslokaliteten for de nabara

objekten, vilket gor att de kan rymmas i samma cache-rad och oka prestandan

vid minnesatkomst. En tredje fordel ar att det gar att utfora nya allokeringar

mycket snabbt, da systemet bara behover uppratthalla en pekare till borjan av det

lediga minnesomradet. I kontrast sa behover system som saknar, eller har en icke-

komprimerande garbage collector uppratthalla och soka i listor over vilka platser

i minnet som ar lediga, vilket komplicerar minnesallokeringen. Nackdelarna med

att flytta ihop objekt ar dels att det kan ta lang tid att utfora om objekten ar

stora och/eller manga, och dels att samtliga referenser som pekar till ett flyttat

objekt maste uppdateras med den nya minnespositionen.

Omflyttningen av objekt implementeras vanligen genom att tva separata min-

nesareor uppratthalls, kallade to-space och from-space[28, 27]. Nya objekt allok-

eras alltid i from-space. Nar en GC-cykel exekverar kopieras de objekt som fort-

farande refereras till to-space. Nar traverseringen ar klar avallokeras hela from-

space i ett svep och de bada minnesareorna byter roller, sa att gamla to-space

blir nya from-space och vice versa.

Denna metod for omflyttning kan ocksa goras inkrementell genom att objekten

kopieras i samband med att de traverseras i nabarhetsanalysen. For att GC:n

ska kunna ateruppta arbetet efter att den avbrutits behover den ett satt att

spara vilket tillstand den for tillfallet befinner sig i. Den naiva metoden med

att marka varje objekt med dess farg innebar en forhallandevis stor okning av

mangden lagrad data (i ordningen O(n) for n objekt). En vasentlig forbattring

introducerades av Cheney i [30], genom att infora tva separata pekare i to-space,

kallade SCAN och FREE. Svarta objekt befinner sig nedanfor SCAN och gra

5.3. Tekniker for okad prestanda 35

befinner sig mellan SCAN och FREE. FREE indikerar minnespositionen dar

overlevande objekt kopieras. Genom denna sinnrika konstruktion kan GC:ns hela

tillstand lagras enbart genom de tva pekarna. Figur 5.4 illustrerar metoden.

Figur 5.4: Bilden visar hur pekarna i to-space forandras under korning av Cheneysalgoritm for samma exempel som i figur 5.3. Algoritmen terminerar nar SCANoch FREE pekar mot samma adress, vilket svarar mot att mangden av gra objektar tom.

Att dela upp arbetet i delar kraver ocksa ytterligare atgarder fran GC:n om

mutatorn andrar i eller laser ifran ett objekt som redan har kopierats. Man kan

losa detta genom att som i [28] skapa en pekare fran det ursprungliga objektet

till dess kopia i to-space och for varje avlasning av en referens i mutatorn vi-

darebefordra den till kopian. Detta medfor dock extra arbete for varje lasning

som mutatorn gor. En annan losning [27] ar att lata mutatorn lasa objekten i

from-space och infora en barriar vid skrivning som utfor samma skrivning i dess


kopia. Detta gor att inget extra arbete behovs vid lasningar, utan endast vid

skrivningar.

5.3.3 Generationer

Ytterligare ett satt att minska GC:ns paverkan pa systemets prestanda ar att dela

in objekten i generationer. Nar objekt skapas tillhor de den lagsta generationen,

0. Ett objekt som “overlever” en GC, dvs. fortfarande refereras av programmet

och darfor inte kan tas bort, flyttas en generation uppat. Man har empiriskt visat

att nyligen skapade objekt ocksa ofta ar de som forst tas bort [31]. Genom att lata

GC:n endast utfora nabarhetsanalys pa objekt i generation 0 far man en mindre

paus i applikationen.

Naturligtvis forekommer det ocksa att objekt i aldre generationer upphor att

refereras till, vilket kraver en s.k. full GC som arbetar over samtliga generationer.

Tidsatgangen for en full GC blir storre, men detta uppvags normalt av att den

kan ske betydligt mer sallan (i storleksordningen 1:100 [34]) an GC for lagre

generationer.

5.3.4 Interoperabilitet med sprak utan Garbage Collection

Problem kan ocksa uppsta om en applikation skriven i ett programsprak med

GC behover dela minne med en extern komponent eller bibliotek. Da denna kod

befinner sig utanfor GC:ns rackvidd, kommer referenser till minnesadresser som

flyttas vid komprimering inte att uppdateras. Detta gor att den externa kompo-

nenten da kan skriva eller lasa fran en felaktig minnesadress. For att losa detta

problem kan ett sprak tillhandahalla en mekanism for att lasa (pin) minnet for

de objekt som delas. GC:n garanterar att lasta objekt inte kommer att flyttas

vid komprimering. Da detta kan ge samma problem med fragmentering som om

en icke-komprimerande garbage collector anvands, bor antalet lasta objekt hallas

nere, och om mojligt bor lasta objekt finnas i aldre generationer.

5.4. Realtidsaspekter 37

5.4 Realtidsaspekter

5.4.1 Kort om realtidsbegreppet

Med begreppet realtidssystem menas att systemet forutom att utfora en kor-

rekt funktion ocksa maste utfora denna inom en viss tid (ofta kallad responstid).

Tidpunkten nar systemet maste kunna returnera resultatet av funktionen kallas

deadline.

Man kan urskilja tva olika nivaer pa realtidskrav: harda och mjuka. For ett

system med harda realtidskrav sa innebar en missad deadline en katastrofal och

oacceptabel handelse. For ett system med mjuka realtidskrav ar en missad dead-

line en starkt oonskad handelse, men systemet kan fortsatta med forsamrad ser-

vice. Ett exempel pa ett hart realtidssystem ar en pacemaker, dar en fordrojning

i varsta fall kan orsaka forlust av manniskoliv. Mjuka realtidssystem innefattar

exempelvis video- och ljuduppspelning, dar en fordrojning ar oonskad men inte

helt fatal.

Vid studier av icke-realtidssystem agnas normalt storst uppmarksamhet at

snitt-tiden for att utfora en viss funktion. Forutsatt att funktionen upprepas

tillrackligt manga ganger ger detta en god bas for att uppskatta den totala ex-

ekveringstiden. For realtidssystem skiftar fokus istallet till tiden for varsta-fallet

(worst-case), da det ar den som bestammer systemets garanterade responstid.

Vilka tidsintervall som ar intressanta ar i hog grad beroende pa applikationen.

Styrsystem for fordon behover ofta responstider runt 20-50 ms, medan en synthe-

sizer for musikproduktion bor ligga under 6 ms[32].

5.4.2 Realtidssystem med garbage collection

Vid explicit minneshantering ar kostnaden for att allokera och avallokera minne

tydlig och latt atkomlig for analys pa samma satt som ovrig programkod. Om

istallet garbage collection anvands introducerar det ytterligare komplikationer da

tidpunkten for avallokering av minne inte langre ar tydligt definierad. Ett sadant

realtidssystem maste alltsa forutom de normala kraven pa programmets logik

ocksa kunna garantera att de pauser som introduceras av GC:n inte aventyrar

programmets formaga att halla sina deadlines.


5.4.3 Minimum Mutator Utilization

Ett vanligt matt pa GC:ns prestanda har traditionellt varit den maximala pausti-

den, Tgc. Det ar den maximala tid som GC:n kan exekvera utan avbrott. Som

Cheng & Blelloch visar i [27] ar detta matt otillrackligt for att ge nagra garantier

gallande systemets responstid. Anledningen ar att maximal paustid inte sager

nagot om hur ofta pauserna intraffar. Flera tatt pa varandra foljande pauser kan

begransa mutatorns exekveringstid sa mycket att deadlinen missas.

Cheng & Blelloch foreslar istallet ett annat prestandamatt som lampar sig

battre for realtid, Minimum Mutator Utilization (MMU ) [27]. Ett systems MMU,

m(∆t), dar 0 ≤ m(∆t) ≤ 1, ar en funktion av storleken pa tidsintervallet, ∆t,

och sager hur stor del av varje tidsintervall som garanterat tilldelas mutatorn.

Detta innebar att ett och samma system har olika MMU beroende pa vilken

intervallstorlek man valjer att mata over. Vi kan beskriva programmets exekvering

med avseende pa tiden t, som en styckvis definierad funktion:

f(t) =

1 om mutatorn kor vid tiden t

0 om GC:n kor vid tiden t

(5.1)

Vi kan nu definiera ett uttryck for m(∆t) enligt:

m(∆t) =1

∆t·min

t0

∫ t0+∆t

t0

f(t)dt (5.2)

Om ett realtidssystem behover maximalt T sekunders korning av mutatorn

for att generera en respons, och vi vill garantera en responstid pa R sekunder sa

behover systemet en MMU enligt:

R ·m(R) ≥ T ⇐⇒ m(R) ≥ T

R(5.3)

Som en direkt foljd av detta sa ger den maximala paustiden Tgc en nedre

grans for responstiden, da m(∆t) = 0 for alla ∆t ≤ Tgc (lat t0 vara tiden da den

maximala GC-pausen borjar).

Figur 5.5 visar ett exempel pa hur MMU:n paverkas av regelbundenhet och

storlek pa GC:ns pauser.

5.5. Existerande losningar 39

Figur 5.5: Ett exempel pa hur MMU:n kan okas, medan den totala mangden arbetefor mutator och GC forblir konstant. A: GC-pauserna ar langa och oregelbundna,vilket paverkar MMU:n negativt bade m.a.p. langa och korta intervall. B: GC-pauserna har gjorts regelbundna, vilket okar MMU for det langre intervallet. Detkortare intervallet ar dock fortfarande begransat av paustidens storlek. C: Genomatt bryta upp GC:ns arbete i mindre delar kan MMU:n okas aven for det mindreintervallet.

5.5 Existerande losningar

5.5.1 Cheng och Blelloch

Cheng och Blellochs losning ar en GC implementerad for SML-kompilatorn TILT,

som ar parallell bade i avseendet att GC:n kan exekvera samtidigt som mutatorn

och att GC:ns arbete kan delas upp pa flera processorer. Processorerna anvander

sig av ett tva-nivaers system med stackar for att dela upp arbetet: en lokal stack


for varje processor och en stack som delas mellan samtliga processorer. Stackarna

innehaller de gra objekt (se avsnittet om inkrementell nabarhetsanalys ovan) som

for tillfallet behandlas. Den delade stacken anvands for att dela arbete mellan

processorerna och darmed gora systemet skalbart vid okat antal processorer.

GC:n ar kopierande och mutatorns lasningar sker i from-space, for att undvika

behovet av skrivbarriarer, vilket forfattarna menar introducerar en oacceptabelt

hog kostnad. Istallet anvands en skrivbarriar som uppdaterar kopian i to-space,

och lasningar fran mutatorn kan ske helt utan extra kostnad i tid.

Parallellismen medfor dock flera komplikationer for att undvika s.k. race con-

ditions mellan processorerna, t.ex. sa att ett objekt inte kopieras till to-space

flera ganger av olika GC-tradar. De loser dessa problem genom att introducera

synkroniseringsmekanismer, vilka har nackdelen att de for med sig en betydande

extra kostnad i tid, ca 40% enligt forfattarnas egna matningar.

5.5.2 Bacon, Cheng och Rajan

Bacon, Cheng och Rajan beskriver i [28] en realtids-GC for Java, vilken senare

fick namnet Metronome. Metronome ar en hybrid mellan kopierande och icke-

kopierande, vilket innebar att den normalt sett inte flyttar objekt som overlevt

en GC-cykel. Detta ar huvudsakligen for att undvika det extra utrymme som en

kopierande GC kraver, vilket forfattarna menar ar problematiskt.

Deras strategi for att halla nere fragmentering ar istallet att dela upp det

lediga minnet i separata “pages” pa 16 KB, vilka i sin tur indelas i block av en

viss storlek. Samtliga block i en viss page ar av samma storlek, och nya objekt

allokeras fran den minsta blockstorlek som de ryms i. Pa detta satt undviker

man att stora och sma objektstorlekar blandas, och fragmenteringen minskar

(forfattarna rapporterar en maximal fragmentering pa 2% vid testkorningar).

I de fall fragmentering anda intraffar utfors defragmentering genom att ob-

jekt kopieras fran glest befolkade pages till tatt befolkade. I motsats till Cheng

och Blelloch omdirigerar man mutatorns lasning till kopian i to-space genom

att anvanda en lasningsbarriar. Genom att bl.a. kombinera lasningsbarriarens

kontroll av huruvida omdirigeringspekaren ar null med Java-VM:ens kontroll av

nullreferenser kan de visa resultat dar extrakostnaden i tid for lasningsbarriaren

endast ligger kring 4%.

5.5. Existerande losningar 41

Metronome ar inte parallell, utan anvander sig istallet av tidsbaserad up-

pdelning av processorresurser mellan mutator och GC. Forfattarna visar experi-

mentellt att en tidsbaserad uppdelning ger betydligt battre MMU an en arbets-

baserad, trots att den i medeltal ger langre paustider. Ytterligare experimentell

data ges i [32], dar Metronome anvands for att implementera en mjukvarusynth

med en uppmatt maximal responstid pa under 6 ms.

5.5.3 Pizlo, Hosking och Vitek

Pizlo, Hosking och Viteks GC ar en vidareutveckling av Metronome kallad HRT-

GC (Hierarchical Real-Time Garbage Collector) [29]. HRTGC tillater olika delar

av applikationen att exekvera med olika realtidskrav genom att dela upp min-

nesutrymmet i separata delar, s.k. heaplets. Forfattarna argumenterar for att

manga realtidssystem innehaller komponenter som inte ar kritiskt tidskansliga,

och att man genom att separera dem gor det lattare att skriva och visa korrekthet

for realtidskomponenterna.

Det hierarkiska systemet innebar att varje heaplet har sin egen GC, vilken kan

anpassas till minnesanvandningen for den aktuella delen av systemet. Referenser

som stracker sig mellan objekt i olika heaplets delas in i tva kategorier: upp-

och korsreferenser. En uppreferens pekar till ett objekt uppat i hierarkin, medan

ovriga referenser ar korsreferenser. Vid nabarhetsanalysen soker GC:n igenom inte

bara sin egen heaplet, utan aven de som finns under den i hierarkin. Detta gor

att en uppreferens inte kraver nagon extra kostnad att etablera.

Korsreferenserna hanteras istallet genom ett s.k. cross-set, vilken ar gemen-

sam for alla heaplets. Den lagrar vilka objekt som innehaller korsreferenser, vilket

systemet utfor genom anvandandet av en skrivbarriar. Eftersom en GC bara kan

avallokera objekt i sin egen heap kravs ocksa en speciell GC, kallad cycle collec-

tor, for att hantera de fall dar det finns cykliska korsreferenser mellan heaplets.

Cycle collectorn:n utfor sjalv ingen avallokering, utan nollstaller endast korsrefer-

enser hos “doda” objekt som refererar cykliskt till varandra. Objekten kan sedan

avallokeras av sin respektive GC.

Forfattarna visar pa en forbattring i responstid pa 15% for HRTGC gentemot

Metronome, medan den totala exekveringstiden forsamras med i medeltal 30%.


5.6 Slutsats

Det ar uppenbart att realtidsgarantier for garbage collection inte langre bara

ar en teoretisk konstruktion, utan i sjalva verket ar mojligt att implementera i

praktiken. Da realtidssystem naturligtvis ocksa i hogsta grad ar beroende av sta-

bilitet sa torde den minskade risken for minnesrelaterade programfel vara ytterst

valkommen. Dock sa innebar realtids-GC a andra sidan nya utmaningar for pro-

grammeraren, i form av behovet att uppskatta hur snabbt programmet allokerar

minne. Aven den snabbaste GC har en grans for hur mycket den kan hantera.

Problematiken med att addera den komplexitet som garbage collection be-

visligen innebar till ett system som kan krava omfattande formell verifiering av

korrekthet ska heller inte underskattas. Det man vinner i utvecklingstid far inte ga

forlorat i okad tid for verifiering. Problematiken skulle naturligtvis kunna mildras

genom att anvanda en GC som i sig redan verifierats formellt.

Utanfor den begransade sfar av implementationer dar harda realtidskrav rader

maste ocksa fordelarna med tidsgarantier extra noga vagas mot nackdelarna i

form av i medeltal forsamrad prestanda. I manga fall torde risken for en missad

deadline vara acceptabel om den innebar en snabbare programkorning i ovrigt. I

dessa fall ter sig den hierarkiska modellen med latt utbytbara realtidskrav vara

ett attraktivt alternativ, da programmeraren latt kan anpassa sitt programs re-

altidsbeteende.

Kapitel 6

Systembeskrivning

Losningen ar uppdelad i tre olika lager; kommunikation-, data- och presenta-

tionslager, vilka askadliggors i Figur 6.1. Kommunikations- och datalagret bestar

av ett antal mjukvarukomponenter som behandlar signaler som kommer in fran

CAN-bussen och skickar dem vidare upp till presentationslagret. Presentationsla-

gret bestar av grafiska kontroller som visar signalvarden och logik som styr nar

kontrollerna ska uppdateras.

Programmet ar utvecklat for Microsoft Windows XP och Microsoft .NET 3.5

med Visual Studio 2008. For en grafisk overblick av systemets olika delar hanvisas

till bilaga A, Systemoversikt.

6.1 Anvandning av komponenter

Losningen ar uppbyggd av ett antal komponenter (se aven kapitel 4, Kompo-

nentbaserad utveckling), och ett ramverk for att hantera dessa. En komponent i

systemet ar en klass som implementerar ett granssnitt kallat IBvS10Component,

och kan konsumera och tillhandahalla tjanster. Komponenterna ar implementer-

ade genom .NET assemblies som ligger i en sarskild komponentkatalog pa disk.

Ramverket ar ansvarigt for att skapa komponenterna via en s.k. komponentfabrik

som implementeras i klassen ComponentFactory, och att avsluta dem nar sys-

temet stangs av. Ramverket tillhandahaller ocksa ett register som en komponent

kan anvanda for att hitta andra komponenter i systemet.

43

44 Kapitel 6. Systembeskrivning

CAN-hårdvarugränssnitt

CAN-hantering

J1939-hantering

Signalkö

Signallogik:översättning enligtspråk samt larm

Grafiska kontroller

Grafikuppdatering ochvalidering av värden

Presentationslager

Datalager

Kommunikationslager

Signal-avkodning

Figur 6.1: En oversikt av de olika delar som ingar i losningen.

6.1.1 Tjanster

En komponent kan erbjuda tjanster (services) till andra komponenter genom

att implementera ett granssnitt (se figur 6.2) och registrera det hos Compo-

nentFactory-klassen. Registreringen sker med ett anrop till funktionen AddSer-

vice med granssnittet som argument. Exempelvis tillhandahaller signaldatabas-

komponenten en tjanst for att ta reda pa i vilken hardvarusignal som en logisk

signal finns. Nar en annan komponent behover denna information kan den soka

efter tjansten hos ComponentFactory via metoden GetService, notera att med det-

ta upplagg behover komponenten endast referera till en assembly som innehaller

granssnittet. Pa detta satt minskas beroendet mellan olika komponenter och det

blir lattare att byta ut delar i systemet.

6.1.2 Systemets uppstart

Nar systemet ska startas upp installer sig fragan i vilken ordning komponen-

terna ska startas. Da en komponent kan vara beroende av andra komponenter

for att kunna utfora sina egna tjanster, sa maste systemet tillse att dessa finns

6.2. Kommunikationslagret 45

+PerformComponentBinding() : bool+DestroyComponent() : void+StartComponent() : void

«gränssnitt»IBvS10Component

Figur 6.2: De tre metoder som varje komponent implementerar.

tillgangliga nar en komponent initieras. En losning som vi forst overvagde var

att lata varje komponent registrera vilka andra komponenter den beror pa och

anvanda denna information for att bygga en riktad beroendegraf. Denna skulle

sedan kunna anvandas for att garantera att en komponent initieras efter alla de

komponenter som den beror pa.

Detta visade sig dock snabbt vara en otillracklig losning, da cirkelberoenden

forekom. Vi valde istallet att losa problemet genom att dela in uppstarten i tva

separata faser: konstruktion och bindning. I konstruktionsfasen skapar kompo-

nentfabriken komponentobjekten. Den gor detta genom att iterera igenom de

.NET assemblies som finns i komponentkatalogen och skapa en instans av de

klasser som hittats vilka implementerar granssnittet IBvS10Component.

I bindningsfasen anropar komponentfabriken metoden PerformComponent-

Binding pa varje komponent, som da anvander registret for att hitta kompo-

nenter som tillhandahaller de tjanster som den sjalv behover. Notera att denna

sokning med nodvandighet maste ske efter att konstruktionsfasen ar helt slutford,

sa att samtliga komponenter ar garanterade att ha skapats. Notera vidare att in-

ga tjanster annu kan anropas under bindningsfasen, eftersom alla komponenter

inte ar garanterade att ha slutfort sin bindning. Nar bindningsfasen ar slutford

ar komponenterna redo att kunna utfora de tjanster som de registrerade i kon-

struktionsfasen och systemet kan borja att anvandas.

6.2 Kommunikationslagret

Kommunikationslagrets uppgift ar ta emot de hardvarusignaler som kommer in

fran CAN-bussen, extrahera de logiska signaler som de innehaller och sedan

lagga de logiska signalerna i signalkon. For de hardvarusignaler som foljer J1939-

standarden tillkommer ett extra oversattningssteg fore extraheringen av logiska


signaler. Figur 6.3 illustrerar signalvagen oversiktligt.

BAE Systems Hagglunds har sedan tidigare ett ramverk for hantering av CAN-

signaler, som innefattar de tva nedersta delarna i lagerstacken (se figur 1 ovan).

Varje CAN-hardvara har ett hardvarugranssnitt som kommunicerar med den och

skickar signalerna vidare upp till CAN-hanteringen i ett standardiserat format.

Detta gor att CAN-hanteringen ar oberoende av vilken hardvara som anvands.

CAN-hanteringen (klassen CanDispatch) skoter en prenumerationsservice dar

de delar i systemet som ar intresserade av en viss CAN-signal registrerar detta

hos CAN-hanteringen. Nar signalen inkommer ser CAN-hanteringen till att den

nar ratt avsandare.

Vart arbete innefattar att utoka det befintliga ramverket med J1939-hantering,

samt att implementera stod for ytterligare en CAN-hardvara.

6.2.1 Signaltyper

Systemet sarskiljer tva olika typer av signaler: hardvarusignaler och logiska sig-

naler. En hardvarusignal ar en signal pa CAN-bussen som kan vara antingen ett

vanligt CAN-meddelande eller ett J1939-meddelande. Varje hardvarusignal in-

nehaller en eller flera logiska signaler, dar en logisk signal ar ett visst varde som

ar av intresse for systemet, exempelvis motortemperatur. Information om vilka

logiska signaler som en viss hardvarusignal innehaller finns i en signaldatabas som

lases in vid uppstart av systemet.

6.2.2 CAN-hardvara

Signalramverket innehaller sedan tidigare stod for tva olika CAN-hardvaror: Kvas-

er USB-CAN och den virtuella debug-hardvaran RemoteCan. RemoteCan simuler-

ar CAN-meddelanden over standard TCP/IP och mojliggor darmed testning utan

att ha en fysisk CAN-enhet tillganglig.

Vi har implementerat stod for ytterligare en CAN-hardvara: Vector CANCa-

seXL. Da vi paborjade arbetet hade vi endast tillgang till ett C++ API som

Vector tillhandaholl darfor vi anvant oss av C++/CLI for att enklare kunna

anropa dess funktioner. Klassen CanCaseHardware finns i projektet Can Case

Hardware, och implementerar precis som de befintliga Kvaser och RemoteCan


granssnitten ICanHardware och ICanHardwareConfiguration.

6.2.3 CAN-hantering

CAN-hanteringen ar implementerad i klassen CanDispatcher, och tillhandahaller

mojligheten for andra komponenter att kunna ta emot och skicka CAN-signaler.

Kommunikationen mellan CanDispatcher och ovriga delar av systemet foljer de-

signmonstret Publish/Subscribe (kallas aven Observer). Nar nagon del i systemet

vill ha information om en viss CAN-signal skapar den en prenumeration hos Can-

Dispatcher och skickar med en referens till ett objekt av typen AutoResetEvent.

AutoResetEvent ar en standardklass i .NET som har tva metoder: Wait och Set.

Nar Wait anropas blockerar anropet anda tills att en annan trad anropat Set.

Nar en signal inkommer anropar CanDispatcher metoden Set och prenumeranten

som vantar pa Wait kan da fortsatta med att lasa ut och hantera signalen (se

figur 6.4).

6.2.4 J1939-hantering

J1939-hanteringen ar implementerad i klassen J1939Dispatcher och oversatter

CAN-signaler till J1939-signaler. Pa samma satt som CanDispatcher anvander

den Publish/Subscribe for att skicka signalerna vidare. Nar en prenumeration pa

en J1939-signal skapas registrerar den en egen prenumeration pa motsvarande

CAN-signal hos CanDispatcher.

6.2.5 Signalkonverterare

Signalkonverteraren SignalConverter har som uppgift att ta in en CAN- eller

J1939-signal och extrahera de logiska signaler som den innehaller. Inhamtning av

signaler sker genom en prenumeration hos CanDispatcher resp. J1939Dispatcher.

Efter att signalen delats upp i logiska signaler (se avsnittet SignalDatabas nedan)

avkodas deras data enligt den specifikation som galler for respektive signal (aven

har med hjalp av signaldatabasen). Slutligen lagger SignalConverter in de avko-

dade signalerna i signalkon.


CAN-ID Data

J1939-ID DataKälla

Signal-databas

Logiskt ID Rådata Logiskt ID Rådata...

Signal-databas

Signal-databas

Signal-databas

Logiskt ID Normaliserad data

Till signalkö

Figur 6.3: Figuren illustrerar hur en CAN-signal ror sig genom kommunikation-slagret.


CAN-Data

Event

CAN-Data

Event

Event.Set() GetQueue()

CanDispatch

Prenumerant

Event

CreateSubscription(CanID, Event)

1. 3. 4.

CanDispatch

Prenumerant

Event

2.

Event.Wait()

CanDispatch

Prenumerant Prenumerant

CanDispatch

Figur 6.4: Designmonstret Publish/Subscribe. 1. Prenumeranten startar en prenu-meration hos CanDispatch genom att skicka en referens till sitt Event-objekt. 2.Prenumeranten vantar pa att Event.Wait() returnerar. 3. CAN-signalen inkom-mer till CanDispatch och den anropar Event.Set(). 4. Event.Wait() returnerar forprenumeranten och den kan lasa ut signaldatan fran CanDispatch.

6.2.6 Signaldatabas

Signaldatabasen har till uppgift att oversatta mellan CAN-ID, J1939-ID och ett

logiskt ID. Notera att mappningen mellan dem inte alltid ar ett till ett. Exem-

pelvis kan ett CAN-paket innehalla varden fran flera givare och darmed flera

logiska ID. Databasen innehaller all information som behovs for att avkoda och

konvertera ett CAN-paket till signaler och varden. Efter konverteringen kommer

signalens varde fa en datatyp. Denna konvertering kallas for datatypkonvertering.

Komponenten jobbar mot XML-filen SignalDefs.xml som maste ligga i samma

katalog. Filen kan alltsa andras utan att man behover kompilera om komponen-

ten. XML-filen bestar av ett antal element av typen HardwareSignal som rep-

resenterar en hardvarusignal. Varje HardwareSignal innehaller i sin tur en eller

flera LogicalSignal som representerar de logiska signaler som hardvarusignalen

innehaller. I varje LogicalSignal finns ocksa information om signalen sasom bl.a.

livslangd , prioritet och den formel som anvands vid datatypkonvertering. Konver-

teringsformeln ar angiven som en strang av C#-kod, vilken kompileras dynamiskt

nar systemet startar. Den kompilerade formeln kan sedan anropas for att utfora

konverteringen.

Till XML-filen hor ocksa dess schema, angivet i standardformatet XSD. Schemat

anger vilka taggar som far forekomma och dess struktur. Visual Studio innehaller


verktyg for att automatiskt utifran XSD-filen generera en datastruktur i C# som

kan anvandas for att representera XML-datan i minnet.

For att gora uppslagningar i den inlasta datan anvands LINQ (Language In-

tegrated Query) som ar en komponent i Microsofts .NET-ramverk. LINQ ger

tillgang till en SQL-liknande syntax direkt i programmeringsspraket, sa att sam-

ma kod kan anvandas oavsett vilken underliggande datakalla som anvands. Ex-

empel pa mojliga datakallor ar XML-filer och relationella databaser.

Fordelen med denna losning ar att programmeraren frigors fran bordan att

skriva kod for inlasning av XML-filen, da den istallet kan automatgenereras. Aven

koden for sjalva utlasningen av data blir betydligt kortare an att manuellt iterera

genom datastrukturen.

6.2.7 CanLayerComponent

Komponenten CanLayerComponent fungerar som en brygga mellan Hagglunds

signalramverk och komponentsystemet. Komponenten innehaller en instans av

CanDispatcher, J1939Dispatcher och det aktuella hardvarugranssnittet. CanLay-

erComponent har en tillhorande konfigurationsfil dar det gar att stalla in vilken

CAN-hardvara och buss-hastighet som ska anvandas.

6.3 Datalagret

Datalagret har till uppgift att behandla signaler som kommer fran kommunika-

tionslagret och skicka vidare dem till presentationslagret. Alla signaler som kom-

mer fran kommunikationslagret kommer in till komponenten Signal Management

som i sin tur anropar de komponenter som lyssnar efter signaler. Alla komponen-

ter i datalagret kan anropa signalkon och registrera sitt intresse for en eller flera

signaler.

I datalagret finns det en komponent som hanterar larm. Med larm menas

att nagon signal har ett extremt varde. Det kan ocksa vara en kombination av

signaler som ger upphov till ett larm. Exempelvis sa visas ett larm for foraren om

bakluckan ar oppen under fard, i just detta fallet sa beror larmet pa om vardet for

hastigheten ar hogre an ett visst varde och att signalen fran givaren till bakluckan

anger att den ar oppen.

6.3. Datalagret 51

6.3.1 Databindning i .NET

.NET innehaller en mekanism som kallas databindning (eng. Data binding) och

bestar av tre delar:

• Datakalla: Ett objekt med publika properties som innehaller den data som

ska propageras till en mottagare.

• Mottagare: En grafisk kontroll som presenterar datakallans data

• Bindningskalla: Kopplar ihop tva properties, en hos datakallan och en hos

mottagaren, sa att mottagarens property andras nar kallans gor det.

For alla properties hos grafiska kontroller kan man i Visual Studios designlage

valja att binda den till en property hos en datakalla. Nar tva properties kopplats

ihop uppdateras mottagaren automatiskt nar datakallan andras. Tillgangliga

datakallor visas i en meny, vilket gor att ingen programmering kravs. En datakalla

blir tillganglig for ett formular genom att dess motsvarande bindningskalla adderas

till formularet.

6.3.2 Signalko

Signalkon ligger i projektet Signal Management, denna komponent bestar tekniskt

sett av tva komponenter men bara en ar synlig utifran. Den osynliga komponenten

ligger i klassen SignalDecoder. Denna klass ar en brygga mellan kommunikation-

slagret och presentationslagret.

Den andra komponenten ar representerar signalkon. Komponenten bestar en-

dast av en klass, SignalQueue, klassen innehaller ett register over vad vilka funk-

tioner som ska anropas nar det kommer in nya signaler. Om en funktionen beror

pa flera signaler sa kommer den att anropas forst nar en ny kopia pa alla signaler

har inkommit. For att prenumerera pa en signal behover man endast anropa

funktionen RegisterForSignal i granssnittet RegisterForSignalInterface.

6.3.3 Signallogik

Datalagret innehaller sa kallade logikkomponenter, dessa skiljer sig till viss del

fran vanliga komponenter. Logikkomponenter kan skicka vidare signaler till pre-

sentationslagret, dessa varden kan sedan bindas direkt till grafiska kontroller. En


logikkomponent maste arva fran klassen LogicComponent, som i sin tur imple-

menterar komponentengranssnittet IBvS10Component.

Systemet innehaller fyra stycken logikkomponenter; Engine, Gearbox, Hatches

och Joint. Dessa fyra komponenter tar hand om signalerna fran respektive fysisk

motsvarighet. I enlighet med komponent-designmonstret sa registrerar de sitt

intresse for signaler i sin startfunktion. I detta anrop anger de aven vilken funktion

som skall anropas av nar dessa signaler inkommer.

I presentationslagret sa binds logikkomponenterna ihop med de grafiska kon-

trollerna med hjalp av databinding (se avsnittet 6.3.1). For att detta ska fungerar

behovs en klass som registrerar komponenten som en datakalla. Varje logikkom-

ponent behover en datakalla. Alla datakallor ska arva fran klassen Component-

Connection och anropa dess konstruktor med vilken logikkomponent den repre-

senterar som argument.

6.3.4 Larmhantering

Ett larm ar en ovantad handelse som det ar extra viktigt att personalen i fordonet

uppfattar som t.ex. att motorns oljetryck ar for hogt.

Varje enskilt larm definieras som en funktion med ett antal signaler som

sin indata. Funktionen utvarderar signalvardena och returnerar huruvida larmet

skall sandas eller inte. Nar ett signalvarde uppdateras sa anropar larmkomponen-

ten alla larmfunktioner som beror pa den aktuella signalen och larmets status

utvarderas pa nytt.

En komplikation uppstar om en signal slutar sandas fran fordonet, sa att

signalvardet blir foraldrat. Detta kommer i den nuvarande losningen inte att

registreras som en forandring i signalvardet, sa larmfunktionen kommer da inte

att koras pa nytt. Se aven kapitel 7.1.

Varje komponent som kan avge ett larm implementerar granssnittet EmitA-

larmInterface vilket innehaller metoden EmitAlarm. Varje larm har ett unikt ID i

form av ett heltal, vilket anges som argument till EmitAlarm nar ett alarm sands

ut. Detta ID gor det mojligt for de komponenter som tar emot larm att indenti-

fiera vilket larm det ror sig om och aven komma at kulturspecifika installningar

for larmet, sasom oversattningar.

6.4. Presentationslagret 53

6.3.5 Databindningskallor

Varje logikkomponent behover en datakalla for att den ska ga att binda ihop

med en kontroll i presentationslagret. Datakallan bor innehalla installningar som

exempelvis specificerar i vilken enhet som varje varde ska presenteras i.

6.4 Presentationslagret

Presentationslagret bestar av ett formular, ett antal grafik-kontroller och tva kom-

ponenter. Den forsta komponenten hanterar vyerna och den andra skoter om

sprakhanteringen. Utover standardkontrollerna i .NET har vi skapat fyra extra;

Dundas Wrapper, GearboxControl, Home Button och Pictogram.

Kontrollen Dundas Wrapper ar en kontroll som inkapslar Dundas Gauge,

vilket ar det bibliotek som anvands for systemets grafiska matare. Dundas Wrap-

per innehaller funktionalitet for att inaktivera mataren nar den far ett medde-

lande om att signalen inte langre ar giltig. Den innehaller aven funktionalitet for

att kunna andra matarens matomfang och forklaringstext beroende pa systemets

kulturinstallning. Kontrollen GearboxControl ar en specialbyggd kontroll for att

visa i vilket lage som vaxeln star (se figur 6.5).

Kontrollen Home Button ar den knapp som visas langst upp i hogra hornet i

varje vy. Om anvandaren trycker pa den sa flyttas denne till Home-vyn.

6.4.1 Uppdateringskomponent

Komponenten UpdateControls schemalagger nar grafiska kontroller i presenta-

tionslagret ska uppdateras. Den haller aven redan pa nar den information som

kontrollen visar blir for gamla, da kommer komponenten att inaktivera kontrollen

for att indikera att data saknas. Komponenten behovs eftersom att hela program

drivs av signaler, komponenterna i logiklagret anropas aldrig annars. Figur 6.6

visar forarvyn nar alla kontroller har giltiga signalvarden; figur 6.7 visar vyn nar

endast hastigheten ar giltig.


Figur 6.5: Den grafiska kontrollen for vaxelvaljaren, GearboxControl, visar attvaxeln star i neutrallage.


Figur 6.6: Samtliga kontroller i forarvyn tar emot signalvarden. Matarnas olikautseende har valts for att demonstrera mojligheterna med Dundas Gauge, seavsnitt 2.7.1.


Figur 6.7: Endast signalen fordonshastighet tas emot. Ovriga visare slacks utoch matnalarna plockas bort (jfr. figur 6.6) for att indikera att deras data nu arforaldrad.


6.4.2 Vyer och vykomponent

Det grafiska granssnittet ar upp byggt av ett antal vyer som anvandaren kan

vaxla emellan. I systemet har vi valt att lata en vy representeras av en pan-

el(UserControl). Nar anvandaren vaxlar vy sa visas den motsvarande panel. Vyer-

na arver av klassen ViewBase, den tillhandahaller handelsehantering for sprakbyte

och larm. Logiken for vy-hanteringen ligger i komponenten View Management.

6.4.3 Sprakhantering

Programmet ar oversatt till svenska och engelska med verktyget Sisulizer, som

finns beskrivet i avsnitt 3.1. Forutom att man kan anvanda Sisulizer for att forma

kontroller sa kan man aven andra installningar pa bindningskallor, sa som att

stalla in pa bindningskallan for motorn att den ska konvertera hastigheten till

mph istallet for km/h.

6.4.4 Piktogram

Piktogrammet ar implementerat som en extern kontroll som kan dras in i design-

ern, precis som ovriga grafiska element. For 3D-renderingen anvands Microsofts

spelutvecklingsbibliotek XNA.

For att framstalla 3D-modellen som anvands i piktogrammet ha vi utgatt

ifran en CAD-ritning av karossen for BvS10. Det ursprungliga malet var att ha

en fullstandig modell av vagnen med alla yttre detaljer sasom lampor och luckor

inkluderade, men detta overgavs pga. tidsbrist. Den modell som anvands visar

chassit for fram- och bakvagn samt den bakre luckan.

Nar ett larm intraffar i systemet visar piktogrammet en varningssymbol med

en pil till den del i vagnen dar felet intraffat. Varje larm har en kalla som bestar

av ett namn pa en del i vagnen, t.ex. ”Engine”. Dessa namn oversatts sedan till

positioner i modellen via en XML-fil som innehaller delarnas namn och positioner.

Denna struktur ar ocksa hierarkiskt uppbyggd sa att en del kan ha flera ”barn”-

delar vars positioner anges relativt till dess foralder. Detta ar nodvandigt for att

exempelvis kunna ange bakdorrens position aven fast bakvagnen svangt.


Konvertering av modeller

Eftersom XNA har inbyggt stod for modeller i Microsofts egna .X-format, behovde

Catia-modellerna konverteras. Catia[10] innehaller ingen exporterare till .X, men

daremot finns en till VRML-formatet tillganglig. Det externa programmet PolyTrans[11]

kunde sedan anvandas for att omvandla VRML-filen till .X.

For att gora modellen mindre kravande att rendera minskades polygonantalet

genom att ta bort manga mindre detaljer, sasom skruvar och nitar. Detta kunde

goras genom att manga av de sma detaljerna anvanda sig av andra material

an ovriga vagnen. Genom att filtrera bort polygoner med dessa material kunde

antalet polygoner minskas med 20 - 30%.

6.5 Manualvyn

Manualvyn anvander sig av hjalpfiler i HTML-format, vilka ligger i en virtuell kat-

alogstruktur beskriven via en XML-fil. For att visa filerna i programmet anvands

den standardkontroll for att visa HTML-sidor som ingar i .NET, vilken i sin tur

anvander sig av Internet Explorers renderingsmotor.

Kapitel 7

Slutsats

Malet med detta arbete var ett implementera i en prototyp av ett information-

ssystem pa .NET platformen. Under arbetet har vi visat hur man konstruerar en

lagerbaserad komponentarkitektur. Vi har aven undersokt hur ett realtidssystem

paverkas av garbage collection.

7.1 Begransningar

3D-grafiken i kombination med det bibliotek som anvands for grafiska matare gor

systemet forhallandevis kravande. Ett problem som uppstod var att nar systemet

inte lyckats halla tidskravet for en signal sa att mataren slacks, orsakar omritnin-

gen av mataren i sin tur en fordrojning sa att andra signalvarden ocksa hinner bli

for gamla. Det kan orsaka en sorts “lavin”-effekt av inaktiveringar bland matarna.

Effekten kan motverkas genom att oka livslangden pa en signal, alternativt att

kora systemet pa mer kraftfull hardvara.

Logiken for att avgora om ett alarm bor skickas ut finns i samma metod

som omvandlar signalvardet innan det skickas till presentationslagret. Detta in-

nebar att om det inte finns nagon grafisk kontroll som visar ett visst signalvarde

sa kommer heller inte nagra larm att skickas for det. For att losa detta skulle

larmkoden behova vara helt frankopplad presentationslagret, sa att logiken kors

nar en signal inkommer istallet for nar den visas. En mojlig arkitektur kan vara

att registrera larmhanterare som prenumererar pa signaler pa samma satt som

59

60 Kapitel 7. Slutsats

logikkomponenterna gor i den nuvarande losningen.

Forfarandet vid konvertering av modeller ar arbetsamt och forstor ocksa my-

cket av den metadata som den ursprungliga modellen inneholl, sasom ID:n for de

olika delar som vagnen bestar av. Denna data skulle kunna anvandas for att med

automatik kunna polygonreducera modellen, och ocksa kunna anvandas for att

generera informationen om hur delarna i vagnen ar sammankopplade.

7.2 Framtida arbete

Ett attraktivt satt att losa problematiken med utritningshastigheten skulle vara

att anvanda hardvaruacceleration via grafikkortet. Detta skulle dock krava ett

annat mjukvarubibliotek an det som anvants, da Dundas Gauge arbetar enbart

via processorn. Via hardvaruaccelererad grafik blir ocksa rotation och skalning av

kontroller sett till prestanda mycket “billiga” operationer.

I den nuvarande prototypen kan personalen bara se information om sitt eget

fordon i VIS. En framtida utveckling skulle kunna innehalla mojligheten att se

information om andra fordon i samma trupp. Ytterligare en mojlighet ar att

integrera en karta i systemet for att latt kunna fa en battre overblick av slagfaltet.

For kommunikation mellan fordon lampar sig naturligtvis inte CAN-bussen, utan

en tradlos overforing maste till.

Den lagerbaserade designen i prototypen gor det forhallandevis enkelt att infor

en ny signalkalla, exempelvis en hardvara for att ta emot radiosand information.

For att infora stod for tradlosa enheter kan man infora tva nya komponenter(se

figur 7.1), en hardvaru-komponent som kommunicerar med hardvaransdrivrutin

och en komponent som avkodar det protokoll som de tradlosa enheterna anvander.

Denna design mojliggor stod for flera tradlosa enheter, sa lange de anvander

samma protokoll. Om man installet vill lagga till stod for en tradlos CAN-

hardvaruenhet behover man endast implementera stod for en ny hardvara da

denna anvander CAN-protokollet, som redan stods.

7.2. Framtida arbete 61

Figur 7.1: Tankbar framtida anpassning av lagerarkitekturen for WLAN (jfr. figur6.1)

62 Kapitel 7. Slutsats

Referenser

[1] BvS10 Produktbroschyr. BAE Systems plc 2007. http://www.baesystems.

com/BAEProd/groups/public/@businesses/@landarmaments/documents/

bae_publication/la_hagg_brochure_bvs10.pdf. Hamtad 2008-11-09.

[2] ISO Standard 15765-1:2004: “Road vehicles – Diagnostics on Controller Area

Networks (CAN) – Part 1: General information”

[3] ISO Standard 15765-2:2004: “Road vehicles – Diagnostics on Controller Area

Networks (CAN) – Part 2: Network layer services”

[4] Windows GDI. Microsoft Corporation. http://msdn.microsoft.com/

en-us/library/dd145203%28VS.85%29.aspx. Hamtad 2010-03-13.

[5] Dundas Gauge for .NET. Dundas Data Visualization, Inc. http://

www.dundas.com/Components/Products/Gauge/NET/index.aspx. Hamtad

2010-03-13.

[6] DirectX Software Development Kit. Microsoft Corporation.

http://www.microsoft.com/downloads/details.aspx?FamilyID=

519aae99-b701-4ca1-8495-39ddde9d7030&displaylang=en Hamtad

2010-03-13.

[7] Lutz Roeder, http://www.lutzroeder.com/dotnet/. Hamtad 2010-03-13.

[8] Infralution, http://www.infralution.com/globalizer.html. Hamtad

2010-03-13.

[9] Sisulizer Ltd & Co KG, http://www.sisulizer.com/. Hamtad 2010-03-13.

63

http://www.baesystems.com/BAEProd/groups/public/@businesses/@landarmaments/documents/bae_publication/la_hagg_brochure_bvs10.pdf



http://msdn.microsoft.com/en-us/library/dd145203%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/dd145203%28VS.85%29.aspx

http://www.dundas.com/Components/Products/Gauge/NET/index.aspx

http://www.dundas.com/Components/Products/Gauge/NET/index.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=519aae99-b701-4ca1-8495-39ddde9d7030&displaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=519aae99-b701-4ca1-8495-39ddde9d7030&displaylang=en

http://www.lutzroeder.com/dotnet/

http://www.infralution.com/globalizer.html

http://www.sisulizer.com/

64 REFERENSER

[10] Catia version 5. IMB Corp. http://www-2000.ibm.com/software/

applications/plm/catiav5/. Hamtad 2010-03-13.

[11] PolyTrans, Okino Computer Graphics. http://www.okino.com/conv/conv.

htm. Hamtad 2010-03-13.

[12] Abdelmadjid Ketfi, Noureddine Belkhatir. Dynamic Interface Adaptability

in Service Oriented Software. Eighth International Workshop on Component-

Oriented Programming (WCOP’03), July 21, 2003 - At ECOOP 2003, Darm-

stadt, Germany.

[13] Microsoft Corporation. Programming with Components. http://msdn.

microsoft.com/en-us/library/0ffkdtkf.aspx. Hamtad 2008-11-09.

[14] Tobin Titus, Rick Delorme and Don Reamey. Pro .NET 1.1 Remoting, Re-

flection, and Threading. p343-395, ISDN 9781590594520, November 2006,

Apress.

[15] Robert C. Martin. Aglie Software Development, Principles, Patterns and

Practices. Prentice Hall, 1st edition, p149-153, October 25, 2002 ISBN

0135974445.

[16] Paul C. Clements. From Subroutines to Subsystems: Component-Based Soft-

ware Development. The American Programmer, vol. 8, no. 11, November

1995.

[17] Ivica Crnkovic. Component-Based Software Engineering - New Challenges in

Software Development. Journal of Computing and Information Technology -

CIT vol 11, no. 3, p. 151-161, 2003.

[18] Szyperski Clemens. Component Software: Beyond Object-Oriented Program-

ming. ASIN B001NJCM6M. Addison Wesley Longman Ltd, 1998.

[19] Joseph R. Kiniry. Semantic Component Composition. GCSE/SAIG Apr

2002.

[20] Developing an OSGi-like Service Platform for .NET. Escoffier, C.; Donsez,

D.; Hall, R.S. Consumer Communications and Networking Conference, 2006.

CCNC 2006. 3rd IEEE Volume 1, Issue , 8-10 Jan. 2006 p. 213-217.

http://www-2000.ibm.com/software/applications/plm/catiav5/

http://www-2000.ibm.com/software/applications/plm/catiav5/

http://www.okino.com/conv/conv.htm

http://www.okino.com/conv/conv.htm

http://msdn.microsoft.com/en-us/library/0ffkdtkf.aspx

http://msdn.microsoft.com/en-us/library/0ffkdtkf.aspx

REFERENSER 65

[21] Guy Bieber and Jeff Carpenter. Introduction to Service-Oriented Pro-

gramming (Rev 2.1), White paper, http://www.openwings.org/download/

specs/ServiceOrientedIntroduction.pdf. Hamtad Dec 2008.

[22] Griffin Caprio. Design Patterns: Dependency Injection. MSDN Magazine,

2005 - San Francisco, CA: CMP Media Inc.

[23] Ralph E. Johnson. Components, frameworks, patterns. ACM SIGSOFT Soft-

ware Engineering Notes archive Volume 22 , Issue 3 (May 1997) table of

contents Pages: 10 - 17 Year of Publication: 1997 ISSN:0163-5948

[24] Microsoft Developer Network (MSDN) Documentation: Thread Stack

Size (Windows). http://msdn.microsoft.com/en-us/library/ms686774%

28VS.85%29.aspx. Hamtad 2010–04–05.

[25] Sun Developer Network: Java HotSpot VM Options. Dokumentation for

kommandoradsparametern XX:ThreadStackSize. http://java.sun.com/

javase/technologies/hotspot/vmoptions.jsp. Hamtad 2010–04–05.

[26] Edsger W. Dijkstra, Leslie Lamport, A.J. Matring, C.S. Scholten, E.F.M.

Steffens: 1978. On-the-fly garbage collection: an exercise in cooperation.

Commun. ACM 21, 11 (Nov. 1978), p. 966–975.

[27] Perry Cheng, Guy E. Blelloch: 2001. A parallel, real-time garbage collector.

In Proceedings of the ACM SIGPLAN 2001 Conference on Programming

Language Design and Implementation (Snowbird, Utah, United States). PL-

DI ’01. ACM, New York, NY, p. 125–136.

[28] David F. Bacon, Perry Cheng, V.T. Rajan: 2003. A real-time garbage col-

lector with low overhead and consistent utilization. In Proceedings of the

30th ACM SIGPLAN-SIGACT Symposium on Principles of Programming

Languages (New Orleans, Louisiana, USA, January 15–17, 2003). POPL ’03.

ACM, New York, NY, p. 285–298.

[29] Filip Pizlo, Antony L. Hosking, Jan Vitek: 2007. Hierarchical real-time

garbage collection. In Proceedings of the 2007 ACM SIGPLAN/SIGBED

Conference on Languages, Compilers, and Tools For Embedded Systems (San

http://www.openwings.org/download/specs/ServiceOrientedIntroduction.pdf

http://www.openwings.org/download/specs/ServiceOrientedIntroduction.pdf

http://msdn.microsoft.com/en-us/library/ms686774%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/ms686774%28VS.85%29.aspx

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

66 REFERENSER

Diego, California, USA, June 13–15, 2007). LCTES ’07. ACM, New York,

NY, p. 123–133.

[30] C. J. Cheney: 1970. A nonrecursive list compacting algorithm. Commun.

ACM 13, 11 (Nov. 1970), p. 677–678. A Nonrecursive List Compacting Al-

gorithm

[31] David A. Barrett, Benjamin G. Zorn: 1993. Using lifetime predictors to im-

prove memory allocation performance. In Proceedings of the ACM SIGPLAN

1993 Conference on Programming Language Design and Implementation (Al-

buquerque, New Mexico, United States, June 21–25, 1993). R. Cartwright,

Ed. PLDI ’93. ACM, New York, NY, p. 187–196.

[32] Joshua Auerbach, David F. Bacon, Florian Bomers, Perry Cheng: 2007.

Real-time Music Synthesis in Java using the Metronome Garbage Collector.

Proceedings of the International Computer Music Conference, (Copenhagen,

Denmark, August 2007).

[33] Fridtjof Siebert: 2000. Eliminating External Fragmentation in a Non-Moving

Garbage Collector for Java. Proceedings of the 2000 international conference

on Compilers, architecture, and synthesis for embedded systems (San Jose,

California, United States, 2000). AMC, New York, NY, p. 9–17

[34] Maoni Stephens: Clearing up some confusion over finalization and other ar-

eas in GC. http://blogs.msdn.com/maoni/archive/2004/11/04/252697.

aspx. Hamtad 2008–12–15.

http://blogs.msdn.com/maoni/archive/2004/11/04/252697.aspx

http://blogs.msdn.com/maoni/archive/2004/11/04/252697.aspx

Bilaga A

Systemoversikt

Systemet bestar av fem olika vyer:

• Huvudvy: Visar ett tredimensionellt piktogram over vagnen och har knap-

par for atkomst till ovriga vyer.

• Forarvy: Visar matare for hastighet, kylvatsketemperatur, varvtal, vaxel,

batterispanning och oljetryck.

• Larmvy: Visar information om larm som uppstatt i systemet.

• Installningsvy: Ger mojlighet till att andra kulturinstallning, samt ger in-

formation om vilken CAN-hardvara som systemet ar kopplat till.

• Manualvy: Visar manualer med instruktioner for hur man felsoker och utfor

service pa fordonet.

67

68 Kapitel A. Systemoversikt

A.1 Huvudvy

Huvudvyn fungerar som ett nav i systemet, med mojlighet att ta sig till alla

ovriga vyer via knapparna i bottenraden. I vyn visas en forenklad 3D-modell

av fordonet, hastighet, bakvagnens forhallande jamte framvagnen och eventuella

larm. Modellen kan roteras genom att klicka och dra pa skarmen. Se figur A.1.

Figur A.1: Huvudvyn med ett larm som gor personalen uppmarksam pa att denbakre luckan ar oppen under korning. Nederst syns navigeringsknapparna.

A.2. Installningsvy 69

A.2 Installningsvy

I installningsvyn kan anvandaren byta kulturinstallning for systemet. Vyn in-

nehaller aven information om vilken CAN-hardvara som anvands. Knappen langst

upp till hoger skickar tillbaka anvandaren till Huvudvyn. Se figur A.2.

Figur A.2: Anvandaren kan snabbt byta kulturinstallning i installningsvyn utanatt starta om systemet.


A.3 Manualvy

Manualvyn ger anvandaren snabb atkomst till bandvagnens manual. I manualen

finns instruktioner over hur man utfor service och felsokning. En manualsida kan

innehalla klickbara ord som tar anvandaren till en annan sida. Se figur A.3.

Figur A.3: Manualvyn ger anvandaren tillgang till hjalptexter.

A.4. Forarvy 71

A.4 Forarvy

Forarvyn innehaller en digital instrumentpanel, som kan ersatta vissa av de analo-

ga instrumenten (se figur A.4). En matare nollstalls om en dess givare inte skickar

ett nytt varde innan vardets livstid gar ut (se figur A.6), detta varde ligger i in-

tervallet 200-500 milisekunder. Matarnas utseende och enheter paverkas av vilken

kulturinstallning som systemet har installt (se figur A.5).

Figur A.4: Forarvyn med visare for olika sensorvarden fran motor och vaxellada.


Figur A.5: Forarvyn nar kulturinstallningen har andrats till brittiskt. Noteraandringen i skalorna for kylarvatsketemperaturen och hastigheten.

Figur A.6: En matare blir gra och visaren forsvinner nar det inte finns nagotvarde att visa. I detta fall har endast hastighetsmataren ett giltigt varde.

A.5. Larmvy 73

A.5 Larmvy

Larmvyn (se figur A.7) innehaller en lista med aktuella och utgangna larm. I hogra

halvan av skarmen visas en beskrivning av det markerade larmet, samt datum

och tid nar det intraffade. Nar det finns ett aktivt larm i systemet sa kommer

knappen for att ga till huvudvyn att indikera att det finns ett aktivt larm.

Figur A.7: Larmvyn visar tva aktiva larm och ett utganget larm i loggen.


A.6 Design av vyer

En vy ar uppbyggd av ett antal kontroller, vilka kan positioneras ut och anpassas

visuellt i Visual Studios designlage (figur A.8). Med hjalp av databindning kan

utvecklaren binda en kontroll till ett signalvarde (figur A.9). Den underliggande

signalhanteringen tar hand om enhetskonvertering och ser till att mataren endast

visar aktuell data. Vid oversattning av vyerna anvands verktyget Sisulizer som

ger oversattaren en lista med textstrangar (se figur A.10).

Figur A.8: Forarvyn oppnad i designlaget.

A.6. Design av vyer 75

Figur A.9: Signalvarden fran fordonet kan bindas till grafiska kontroller via enklamenyer.

Figur A.10: Oversattning av installningsvyn i Sisulizer.


Bilaga B

Specifikation av

examensarbete

77

Examensarbete, 20p – informationssystem i BvS10

Område: Mjukvaruutveckling med inriktning mot informationssystem Fördjupning: Användning av C++/CLI i inbäddade system inom stridsfordonsutveckling Avsett för : Två civilingenjörer Uppdragsgivare : BAE Systems Hägglunds AB, avd. SPB Start: Augusti, 2008 Handledare: Erik Essegård, [email protected], tel. 0660-29 24 00 Ansvarig chef: Johan Persson, [email protected]

Bakgrund

Hägglunds utvecklar moderna stridsfordon med krav på avancerade grafiska och interaktiva informationssystem. VIS (Vehicle Information System) är utvecklat inom Hägglunds och används idag bl.a. i Stridsfordon 90. VIS är ett inbäddat system som presenterar enklare statusinformation, t.ex. fordonshastighet och bränslenivå men som även omfattar alarm, manualer, taktiskt stöd och stridsledningssystem. Det kör på ruggade PC med touch-screen under Windows XP Embedded och är utvecklat i C++.

Uppdragsbeskrivning

Hägglunds bandvagn, BvS10 saknar idag informationssystem och uppdraget går ut på att införa grundläggande funktionalitet med modern teknik och användargränssnitt. Speciellt skall VIS för BvS10 hantera driftdata från fordonets motor, Steyr, med avseende på bl.a. oljetryck, varvtal, m.m. Kommunikation med motorn sker över CAN-protokollet J1939 vilket skall implementeras som en del av examensarbetet. För simulering och testning bör även en simuleringsmodell tas fram med hjälp av plattformen SimBas som Hägglunds använder för ändamålet. Protokollet skall utvecklas som en komponent med beroenden enbart till standardiserade API:er och komponenter, t.ex. CAN, C/C++, STL, o.d. Informationen skall presenteras i ett grafiskt användargränssnitt utvecklat i C++/CLI .NET med Microsoft Visual Studio 2008. Diverse kontroller för mätare och liknande bör använda lämpligt komponentbibliotek, exempelvis Dundas Gauge for .NET (www.dundas.com). Applikationen bör utvecklas med lagerbaserad arkitektur omfattande åtminstone kommunikationslager, datalager och presentationslager (GUI). Om möjlighet ges finns möjlighet att gå vidare med logiklager, stöd för loggning, avancerad konfigurering, m.m. Slutligen omfattar arbetet även viss planering av arkitektur och design samt tillhörande dokumentation i form av systemdiagram och gränssnittsspecifikationer.

Uppgifter, sammanfattning

Krav :

- Utveckling av komponent, CAN protokoll J1939 mot Steyr motor (C/C++) - Utveckling av grundläggande VIS för BvS10 (C++/CLI .NET) - Teknisk dokumentation av delar utvecklade i examensarbetet Värdefullt: - Utveckling av simuleringsmodell för Steyr motor (C/C++) - Fördjupning inom lager- och komponentbaserad arkitektur - Fördjupning inom GUI-design och usability - Fortsatt utveckling av VIS BvS10

Date post:	11-Aug-2019
Category:	Documents
Upload:	trandang
View:	212 times
Download:	0 times

Prototyp av informationssystem f or milit arfordon · Abstract Computer based information systems...

Documents