Experimentell verifiering av feldetektering och feltolerans. Inledande prov med felinjicering på gränssnitt

Experimentell verifiering av feldetektering och feltolerans Projekt P9 inom Forskning och teknikutveckling för anpassning Inledande prov med felinjicering på gränssnitt Författare Håkan Edler Siv Hermansson Jan Sinclair Dokument Id 001213 WP3 0_5.doc Version 0.5 Datum 14 november 2001 Tillgänglighet Status FoTA P9 Slutligt utkast för godkännande Granskad av Datum HiSafe AB Östra Palettgatan 5 Tel 031-28 29 01 GSM 070-515 14 45 421 66 V FRÖLUNDA e-post hisafe@hisafe.se

Sammanfattning FoTA P9 syftar till att introducera automatisk provning med felinjicering som ett effektivt verktyg för att verifiera och validera datorprogram. I tidigare arbetspaket inom projektet har vi byggt upp en provningsmiljö för flygdatorn MACS från Ericsson Microwave Systems. Den är baserad på utvecklingsmiljön SEEMACS. Provningsmiljön är ett programsystem, som vi kallar FINT Fault Injection for Testing. I tidigare arbetspaket har vi också analyserat arkitekturen för programmen i SD Gripen och gjort modeller av tänkbara fel. FINT ger en systemutvecklare möjligheter att automatiskt prova funktioner och begränsningar i programenheter genom anrop av deras operationer med systematisk variation av värden på parametrarna. FINT genererar automatiskt provfall genom kombination av värden ur parametrarnas värdeförråd. Ett stort antal provfall kan skapas automatiskt, där såväl giltiga som ogiltiga värden tas med. FINT initierar och exekverar provfallen samt loggar resultaten. I de nu genomförda arbetspaketen har vi använt FINT för prov på programenheter, som är i drift för MACS. Rapporten behandlar uppläggning och genomförande av de prov vi gjort, diskuterar resultaten och ger förslag till hur det fortsatta arbetet skall läggas upp. Resultaten visar, att man med vår metod på ett mycket effektivt sätt kan verifiera och validera funktioner och begränsningar hos programenheter. Det är ett nytt sätt att prova program och som ger en utvecklare nya insikter i hur program kan konstrueras och byggas.? HiSafe AB 001213 WP3 0_5.doc 0.5 2 av 21

Dokumentets historik Version Författare Datum Ändringsinformation 0.1 HE, SH, JS 12 dec 2000 Ny 0.2 HE, SH, JS 15 dec 2000 Kompletteringar 0.3 HE 15 dec 2000 Kompletteringar 0.4 HE 9 jan 2001 Remiss 0.4.1 HE 18 feb 2001 Justeringar efter EMW påpekanden 0.5 HE 14 nov 2001 Justeringar före slutremiss? HiSafe AB 001213 WP3 0_5.doc 0.5 3 av 21

Innehållsförteckning 1. BAKGRUND... 5 2. TIDIGARE ARBETE... 6 2.1 Forskning i feltolerant programvara på Chalmers... 6 2.2 Arbete inom FoTA P9... 7 3. PROV I EXISTERANDE PROVMILJÖER... 10 4. METODFÖRSÖK PÅ PROGRAM FRÅN SAAB... 11 4.1 Använd teknik för källkodsprov... 11 4.2 Prov av GES_EIU_TEST1... 11 4.3 Genomförande och resultat... 13 5. METODFÖRSÖK PÅ PROGRAM FRÅN ERICSSON MICROWAVE SYSTEMS.. 14 5.1 Använd teknik för prov av programenheter... 14 5.2 Komplettering för FINT... 14 5.3 Genomförande och resultat... 15 6. RESULTAT AV METODFÖRSÖKEN... 17 7. FORTSÄTTNING... 19 8. REFERENSER... 21? HiSafe AB 001213 WP3 0_5.doc 0.5 4 av 21

1. Bakgrund FoTA P9 är ett projekt för överföring av ny teknik från forskningen vid institutionen för Datorteknik vid Chalmers tekniska högskola till praktisk användning i svensk industri. Pålitliga datorsystem har sedan halvtannat decennium varit ett huvudområde för forskningen vid institutionen, främst med inriktning på datorers maskinvara. Sedan början av 90-talet har intresset breddats till att också omfatta programvaran och Håkan Edler har drivit ett projekt för forskning på pålitlig programvara. Syftet med forskningen har varit att studera:?? metoder att analysera tillförlitligheten i programsystem,?? metoder att kvantifiera tillförlitligheten,?? algoritmer för att konstruera feltoleranta program och?? mekanismer att realisera dem. Forskningsprojektet har skapat en mängd ny kunskap, som publicerats på internationella konferenser och i vetenskapliga tidskrifter. Som en del i det projektet har vi på institutionen byggt en experimentmiljö för att kunna verifiera funktionerna hos provade algoritmer och mekanismer för feltolerans och för att kunna validera tillförlitligheten. Fel är sällsynta i beprövade program. För att kunna prova programmens förmåga att hantera fel måste man därför forcera feltillstånden. Det gör man genom att artificiellt införa fel i programmen under exekvering och det kallar vi felinjicering. För att få statistiskt säkra resultat räcker det inte med injicering av enskilda fel, utan ett stort antal fel injiceras under ett experiment. Den experimentmiljö vi byggt är därför en speciell form av system för automatisk provning av program, där ett stort antal fel genereras automatiskt och injiceras i de provade programmen. Beteendet hos det provade systemet loggas och analyseras i efterhand. I de system vi kört på institutionen har vi injicerat fel och observerat deras effekt på systemnivå. I stora system har ett sådant förfarande troligen begränsad användning, då sambanden mellan ett injicerat fel och systemets felbeteende kan vara svåra att förstå, då systemet är oöverblickbart. Därför gör vi också försök med att injicera fel i gränssnitten på programenheter och observera deras beteende. Ett sådant system kan vara användbart för att:?? Prova funktionerna hos en programenhet automatiskt med ett stort antal värden på automatiskt genererade provdata.?? Vara en provbänk för regressionsprov av en programenhet, då proven och deras sekvens är förutbestämd och resultat från nya prov kan jämföras med gamla.?? Prova robustheten hos en programenhet genom att genererade provdata ges ogiltiga värden.?? Prova feltoleransen hos det system modulen ingår i genom att forcera ett felbeteende hos den provade programenheten. Det blir en felkälla i det överordnade systemet. På våra forskningsresultat har vi i FoTA P9 byggt en provbänk för automatisk provning av programenheter för datorsystemet MACS från Ericssons Microwave Systems. Provbänken utnyttjar dess utvecklingsmiljö SEEMACS. I provbänken kan man definiera de variabler som finns i gränssnittet till en programenhet och vilka värden de skall ha som provdata. För anrop av en provad programenhet kan man också definiera ett godtyckligt prefix för att sätta programenheten i ett givet tillstånd före ett prov och ett suffix för att ta hand om resultatet av provet. Den tillämpning vi inriktat arbetet på är programvaran i systemdatorn för JAS 39 Gripen. Vi har kört prov på några programenheter, dels ur den generella programvaran för MACS, dels på en del av provningsprogrammen för systemdatorn. Det vi kört hittills är enbart funktionsprov och prov av robusthet. Resultaten av proven är mycket lovande och visar att man kan ha stor nytta av tekniken för verifiering av programenheter.? HiSafe AB 001213 WP3 0_5.doc 0.5 5 av 21

2. Tidigare arbete 2.1 Forskning i feltolerant programvara på Chalmers Forskningen på Chalmers har främst inriktats på studier av felhantering och felpropagering. Som försöksobjekt har vi använt ett tämligen litet, inbyggt system och gjort en omvärldssimulator till det. I en inledande serie försök gjordes felinjicering i källtexten till programmen [Chr98]. 100 fel fördes in i var sin variant av programmet och samtliga programvarianter kompilerades. Ett antal provfall med varierande omvärldbetingelser definierades för varje fel och lagrades för att användas som styrdata. Provningssystemet läste dessa styrdata, laddade ned program i måldatorn och startade den. Provningssystemet satte sedan parametrarna för omvärldssimulatorn och startade den och därigenom exekverades provet. Resultaten av varje prov lagrades för senare utvärdering innan nästa provfall initierades och kördes. På så sätt körde vi ett mycket stort antal provfall automatiskt. I senare försök i samma provningssystem med mindre ändringar har forskargruppen sedan studerat effekten av att injicera feltillstånd direkt i exekverande program i stället för de felkällor ändringarna i källtexten ger [CRH98]. Vidare har man studerat effekten av att göra programmen robusta med hjälp av exekverbara utsagor [Hil98] och hur fel fortplantar sig genom systemet [Hil00]. För att studera möjligheter och begränsningar med injicering av fel i programenheters gränssnitt byggde vi ett nytt provningssystem för systemanropen till ett realtidssystem [Car00]. Den fundamentala principen är att man provar varje systemanrop för sig med en stor mängd automatiskt skapade provfall. Provningssystemet genererar provfallen genom att systematiskt välja alla kombinationer av värden ur tabeller med provdata för varje parameter. Provdata får man fram genom att studera parametrarnas datatyper. Två grundläggande principer för val av provdata är [WP2]:?? uppdelning i ekvivalensklasser och?? gränsvärdesanalys. Kännetecknande för en ekvivalensklass är, att alla datavärden inom klassen hanteras på samma sätt av det anropade programmet. Om förutsättningen om likartad hantering är sann, räcker det med att välja ett värde inom varje klass. Gränsvärdesanalys grundar sig på erfarenheten att fel hopar sig på gränserna mellan ekvivalensklasser. Provdata bör därför väljas på dessa gränser och så nära dem som möjligt. Med det system vi byggt är det möjligt, att definiera:?? ett anrop till realtidssystemet och dess parametrar,?? de datatyper varje parameter tillhör och?? en värdetabell för varje datatyp. Provningssystemet kan sedan generera provfall genom att cykliskt permutera parametervärden, initiera prov som gör anropen, övervaka dem och logga resultaten [Car00]. Det körs på en simulerad variant av realtidssystemet, som exekveras i en NT-dator. Systemet är sedan vidareutvecklat till att kunna köras i en målmaskin med en PPC 603e-processor [Dum00].? HiSafe AB 001213 WP3 0_5.doc 0.5 6 av 21

2.2 Arbete inom FoTA P9 Forskningen på Chalmers med injicering av fel i exekverande program syftar till att studera beteendet hos ett system när inneslutna felkällor aktiveras. Det har skapat en hel del ny kunskap om hur fel uppträder och kan hanteras i programsystem. I försöken har ett komplett system använts som försöksobjekt, vilket kan bli oöverblickbart i större system. Därför byggde vi systemet som provar systemanrop. I FoTA P9 bygger vi vidare på det senare provningssystemet och inriktar oss på att studera beteendet hos programkomponenter när man injicerar fel i deras gränssnitt. I en tidigare etapp av projektet [WP1] har vi byggt en prototyp för provning av program till MACS och som utnyttjar SEEMACS. Vi har därmed haft en väl beprövad utvecklingsmiljö att bygga på. Systemet kallar vi FINT Fault INjection for Testing. Det skapar program i Pascal D80, som provar anrop av programenheter. Det är konstruerat och byggt för att kunna hantera även andra blockstrukturerade programspråk som Ada och C++. Den nuvarande versionen har ingen styrning av en omvärldssimulator, så bara programenheter utan interaktion med omgivningen kan provas. FINT är dock konstruerat för att också kunna styra en omvärldssimulator. I FINT definierar man den programenhet och det anrop, som skall provas. I ett anrop samverkar den anropade programenheten med sin omgivning via ett antal variabler. Dessa variabler är parametrar, funktionsvärden och globala variabler. Parametrar kan referensanropas eller värdeanropas. Varje variabel tillhör en given datatyp och datatypen har ett givet definitionsområde. Definitionsområdet kan delas in i ett antal ekvivalensklasser. Den indelningen och gränsvärdesanalys ger ett antal värden på provdata för varje datatyp, som kan lagras i en tabell med provvärden. Ett anrop av en programenhet kan ha flera provmönster. Ett mönster innehåller en text för att kunna generera direktiv för kompilering, länkning, laddning och exekvering samt de texter som behövs för att skapa programtexten med prefix, anrop och suffix. Prefixet behövs för att kunna sätta programenheten i ett givet tillstånd före ett prov. Suffixet behövs för att kunna ta hand om resultatet och återställa systemet. Programenhet Prefix Anrop Provmönster Suffix Variabel Direktiv Datatyp Programtext Direktiv Värdetabell Fig 1. Datastruktur för generering av provfall i FINT? HiSafe AB 001213 WP3 0_5.doc 0.5 7 av 21

Generatorn för provfall använder ett provmönster för att skapa en programtext och tillhörande direktiv för varje provfall. Direktiven styr kompilering, länkning, laddning och exekvering av programmen i SEEMACS. Exekveringen kan ske i såväl den simulerade målmaskin, som ingår i SEEMACS eller en fysisk målmaskin. I de inledande prov vi gjort har vi använt den simulerade målmaskinen och Ericsson har för ett av proven gjort motsvarande prov i den fysiska målmaskinen. Prefix Anrop Variabel Generator Programtext Kompilator Länkare Laddare Laddmodul Målsystem Logg Direktiv Värdetabell Suffix Fig. 2. Förenklat dataflöde för generering och körning av prov. Styrtransformationerna är utelämnade. Som underlag för felinjiceringsförsöken studerade vi också felmodeller för programvaran i SD Gripen [WP2]. Generellt sett gäller, att möjliga fel vid anrop av en funktion i en tillämpning är:?? Fel värden på parametrar.?? Fel ordning på parametrar.?? För få parametrar.?? För många parametrar. Endast den första är aktuell i de provade tillämpningarna, då utvecklingssystemet skall upptäcka de övriga. Fel värde på en parameter är i det enklaste fallet, att det ligger utanför definitionsområdet för parameterns datatyp. Som resultat av studien av felmodeller [WP2] fick vi bara ett fåtal möjliga feltillstånd i en subrutin efter anrop med fel i parametrarna:?? Adressfel i process. Subrutinen refererar till en adress, som ligger utanför processens tillåtna minnesrymd. Minnesskyddet skall upptäcka detta och ge avbrott.?? Adressfel i stack. Subrutinen refererar till en adress utanför det tillåtna området för stacken. Stackskyddet skall upptäcka detta och ge avbrott.?? Fel värde och ogiltigt. Parameterns värde är fel och ligger utanför definitionsområdet för dess datatyp. Ett sådant fel skall ett robust program klara av att upptäcka.?? Fel värde men giltigt. Parameterns värde är fel, men ligger inom definitionsområdet för dess datatyp. Ett sådant fel kan möjligen upptäckas av någon feltoleransmekanism i subrutinen eller dess anropande program.? HiSafe AB 001213 WP3 0_5.doc 0.5 8 av 21

I de tidigare arbetspaketen har vi alltså fått fram ett system som ger möjlighet att beskriva omfattande provningssserier. Vi har också hittat modelle r för fel i anrop av de provade programmen, vilket behövs som underlag för val av provdata.? HiSafe AB 001213 WP3 0_5.doc 0.5 9 av 21

3. Prov i existerande provmiljöer Enligt det ursprungliga förslaget till FoTA projekt [Edl98] var innehållet i de nu genomförda arbetspaketen: WP3 Bestämma provfall baserade på felmodellen. Köra driftsystemet med konstlaster. Injicera fel automatiskt enligt provfallen. Logga och analysera. WP4 Bestäm en felmodell för tillämpningsprogrammen. Vi avser prova programmen i gränssnitten mot driftsystemet och injicera fel dels i indata, dels i programmen. Resultaten från tillämpningsprogrammen loggas. WP3 är genomfört i huvudsak enligt ursprungligt förslag. Vi har dock inte haft tillgång till en målmaskin, som var tänkt från början. Eftersom tillgängliga MACS målmaskiner utnyttjats för annat arbete, så har ingen målmaskin kunnat dediceras helt för användning inom FoTA P9. Vi har därför varit hänvisade till att köra försöken i den simulator för målmaskinen, som ingår i SEEMACS. Det har fungerat alldeles utmärkt och körningarna kan direkt flyttas över till en målmaskin, som Ericsson gjort i ett av försöken. Det har däremot inte varit möjligt, att köra experiment mot en verklig omgivning eller mot en omgivningssimulator. Konstlasterna och styrning av en omgivningssimulator har därigenom inte varit relevanta. Delar av WP4 är gjorda redan i WP2. I det nu avrapporterade arbetet har vi provat programenheter på deras gränssnitt och injicerat fel i anropen. Vi har inte injicerat fel i själva programmen, då felinjiceringsmekanismer inte finns i MACS och vi har inte heller byggt några. Möjligheterna för oss att pröva våra metoder skiljer sig avsevärt mellan Saabs och Ericssons programvara. Ericssons programvara är generell med oftast självständiga programelement, som påverkas av få parametrar. Den existerande provmiljön hos Ericsson är uppbyggd för att kunna köra ett antal i förväg definierade provfall för varje programenhet [EMW]. De ligger som färdiga programtexter, som enkelt kan kompileras, länkas, laddas och köras. De är samtliga framtagna var för sig genom omfattande manuellt programmeringsarbete. Principen stämmer i huvudsak med arkitekturen hos FINT och det var relativt enkelt, att automatisera generering och exekvering av provfall. Saabs programvara är självklart tätt knuten till användningen i flygplanets systemdator. Vi har tidigare [WP2] beskrivit arkitekturen hos programvarusystemet, som uppdelad i realtidsexekutiv RTE och systemenheter SU. Exekveringen av tillämpningarna är indelad i ett antal frekvenser och för varje frekvens exekveras ett antal procedurkedjor. Anropen av de enskilda programele - menten är beroende av den sekvens av händelser, som sker i verkligheten eller i en simulerad verklighet. För en del av den mycket omfattande provning man utvecklat vid Saab har man skrivit program för köra ett antal provfall för varje procedur i en SU. Dessa program kallar man Ktest-skal. För varje provfall har man ett prefix och ett suffix. Med prefixet sätter man det provade systemet i ett givet tillstånd genom att ge variabler i systemet givna värden. Därefter anropas proceduren. Suffixet tar hand om resultatet och återställer systemet [Saab]. I grunden är förfarandet samma som hos Ericsson och i FINT. Den stora skillnaden är, att kommunikationen mellan procedurerna till stor del sker med globala variabler och att prefixen och suffixen till provfallen är unika för varje provfall. Ett Ktest-skal blir därför ett stort program, som i sig inkluderar alla provfall för en SU. Provningsmiljön från Saab var därför betydligt svårare att samordna med automatprovning enligt FINT. Med några tillägg till Ktest-skalet kunde vi dock köra ett antal provfall för ett av Saabs provfall, där vi varierade variabelvärden enligt de principer, som är bärande för FINT.? HiSafe AB 001213 WP3 0_5.doc 0.5 10 av 21

4. Metodförsök på program från Saab 4.1 Använd teknik för källkodsprov Vi använder en del av programvaran för SD programavsnitt grundflygplan, (GES), som används för säkerhetskontroll, funktionskontroll och fellokalisering på marken. Vid ett besök på Saab fick vi en genomgång hur Saab gör sina prov av programmens källkod. Programmen i SD är uppdelade i 13 enheter av programvara, SU (Software Unit). Exempel på SU är Primary Flight Data PDF, Mission Data Management MDM och FLight Control FLC. GES som är en akronym av GEneral Systems är också en sådan SU. Se beskrivning av arkitekturen hos programvaran i SD Gripen från tidigare arbetspaket [WP2]. För att prova att programkoden går att löpa igenom och är fri från abnormiteter i de olika SUna har Saab gjort en testmiljö. Där kan varje SU kan etableras på ett enhetligt sätt i det som kallas KTEST-skalet (KTEST står för KällkodsTEST). Detta är tester som endast berör källkoden och omvärlden simuleras i en för varje SU speciellt skriven modul. I KTESTet provoceras inte programvaran, utan genom att efterlikna sekvenser av händelser från verkligheten är målet att all kod skall vara genomgången. Vi förstår KTESTet på så sätt att programvaran skall vara fri från programmeringsfel (buggfri), innan man påbörjar den verkliga provningen. 4.2 Prov av GES_EIU_TEST1 OBS att TEST1 i namnet syftar på de tester som görs då tändningen slås på i flygplanet. Det innebär att vi nu beskriver hur en SU som heter GES_EIU_TEST1 testas i KTEST. I vårt metodförsök har vi fått från Saab och etablerat på vår SUN-Solaris den del av KTEST som gör att SU GES_EIU_TEST1 går att prova med simulatorn för MACS. GES_EIU_TEST1 är den SU som automatiskt går igång då tändningen slås på i flygplanet och som frågar de olika delarna av planet att de är med och att de är ok. Programmet som vi kan köra omfattar GES_EIU_TEST1 och en omgivande miljö som gör det möjligt att köra många testfall. Förenklat för att inte säga stiliserat visas programmets arbetsgång i figur 3. Figuren symboliserar att programmet på ett styrt sätt går igenom testfall efter testfall i en loop. I programmets uppstart initieras de variabler som styr vilka testfall som skall initieras och genomlöpas i loopen. Inför varje testfall räknas testfallsräknaren upp ett steg, men det behöver inte finnas programkod för alla testfall. Luckor för framtida behov förekommer. I varje testfall initieras för sekvensen relevanta variabler, GES_EIU_TEST1 anropas med denna simulerade tillståndsbeskrivning och därefter kontrolleras och loggas resultatet. Figur 4 visar våra tillägg som beskrivs i 4.2.1.? HiSafe AB 001213 WP3 0_5.doc 0.5 11 av 21

Starta och initiera test. Gör att testfallen kan köras igenom från början. Starta och initiera test. Gör att testfallen kan köras igenom från början. Om FINT-variant: Sätt tillbaka testfall ett steg och fortsätt Initiera för nästa testfall, så att programmets gång leder till ett bestämt kodområde. Initiera för nästa testfall, så att programmets gång leder till ett bestämt kodområde. Initiera parametrarna till programenheten som skall testas med nästa variant. Här är SU GES_EIU_TEST1 där den koden som testas finns. Här är SU GES_EIU_TEST1 där den koden som testas finns. Tag hand om testresultat. Tag hand om testresultat. Figur 3. Figur 4. Avsluta när alla testfall har gåtts igenom Avsluta när alla testfall har gåtts igenom Som den kursiverade texten i figur 4 visar ligger tilläggen för FINT-proven i KTEST-skalet och inte i GESens SU. Vi använder loopkonstruktionen i sin ursprungliga form. Fördelerna är uppenbara. Det gör att den sekvens som skapats för ett specifikt testfall bibehålls och vi inte behöver införa någon ny otestad programkod i SUn. Då en variant ger ett fel av dignitet finns det en stor risk att också den skapade sekvensen förstörs och provet måste avbrytas. Det skulle gå att förhindra genom att man för in ny programkod i KTESTen som sparar undan alla berörda variablers värden innan GES_EIU_TEST1 anropas.? HiSafe AB 001213 WP3 0_5.doc 0.5 12 av 21

4.3 Genomförande och resultat Att varje kompilering och länkning av GESen tar ca 10 minuter omöjliggör den raka och enkla lösningen att kompilera och länka för varje provfall som genereras av FINT. För att kunna köra systematiska prov med automatskapade provfall med olika provvärden i KTEST-miljön måste man arbeta på en bestämd plats i sekvensen. Med FINT genererar vi programkod som innehåller en case-sats. Den procedur som vi provar får sina in-parametrar/variabler initierade i case-satsen. Programkoden från FINT flyttas in i ett testfall som leder till att proceduren som skall provas anropas. För att gå igenom samtliga fall i FINTs case-sats med samma tillstånd på alla andra variabler använder vi den ursprungliga loopen i KTEST, men stoppar den ursprungliga uppräkningen av testfallsräknaren tills samtliga FINTs varianter är genomgångna, se figur 4. Det betyder att alla provfall från FINT i ett prov genomförs på en bestämd plats i sekvensen. När det var dags för prov i full skala var vi tvungna att begränsa antalet provfall till 294 stycken. För det första får en case-sats inte vara större än 2048 fall. För det andra tillät inte kompilatorn att vi överskred dess maximala kodmängd i programmet, som sedan tidigare omfattande på grund av alla testfall som redan finns där. Med samtliga in och in/ut variabler varierade enligt ekvivalensmetoden skulle antalet provfall bli 1 882 384 * antal värden i en styrparameter för provning. För enbart de variabler som är av typen integer skulle antalet provfall bli 16 807. Med hänsyn tagen till nedanstående tre punkter visar de prov vi har gjort att det är möjligt att komma mycket långt med systematiskt uppbyggda prov enligt metoderna i FINT. 1. Det behövs ingående kunskaper om vilka variabler som bör varieras mot varandra och hur variablerna i Saabs nuvarande testfall skall placeras för att ge bästa utfall. Det visste vi givetvis före försöket, men vikten av det har accentuerats. 2. Ett stort antal provfall, tiotusental, kan åstadkommas genom att i FINTs generator skapa flera procedurer med 2048 stycken provfall i varje case-sats. De körs igenom med hjälp av en intelligentare algoritm än den uppräkning vi har lagt in i försöket. 3. Om man använder FINT-metoden på detta sätt är det viktigt att tänka ut sätt för återstart av såväl provprogrammet som simulatorn (macssim), eftersom vi avsiktligt misshandlar systemet med felaktiga och provocerande provvärden. Man kan förvänta, att allvarliga fel uppstår. Metoderna i FINT ersätter inte de nuvarande testfallen men tillför mervärde och kanske kan antalet befintliga testfall reduceras.? HiSafe AB 001213 WP3 0_5.doc 0.5 13 av 21

5. Metodförsök på program från Ericsson Microwave Systems 5.1 Använd teknik för prov av programenheter Vi har haft två möten med Ericsson. Det första var en genomgång av hur Ericsson genomför några typiska tester på en programenhet i SEEMACS. Det resulterade i att vi fick några exempel på rutiner, att använda i FINT-proven. Det andra var ett avstämningsmöte efter att vi genomfört några prov. Den valda programenheten i SEEMACS är skriven för att vara generell och generell programvara består oftast av självständiga programelement, som påverkas av få parametrar i rena gränssnitt. Ericsson använder i sina egna tester relativt små och raka program för att testa att deras program är korrekta. Testprogrammen hos Ericsson är gjorda för white-box testing. Med få varianter på ingångsvärden till programmodulens parametrar verifieras att den testade modulen uppträder som förväntat. De moduler vi har testat kräver inte ämneskunskaper med sådant innehåll som vi saknar. Vi kunde genomföra proven i full skala med ett stort antal provfall mycket nära den verkliga användning vi tror på för denna del av FoTA P9. 5.2 Komplettering för FINT Proven följer den arbetsgång som också beskrivs i [WP2]. Dess mest uppenbara fördel är att varje provfall startar i en ren omgivning, utan påverkan från vad som skett i tidigare provfall. För varje provfall finns ett program från vilket den enhet som skall provas anropas. Programmen genereras av FINT. Varje program är sammansatt av fyra delar, enligt figur 5. Ett program till varje provfall. Prefix: Programmets start med alla deklarationer och error prelude. Kod för att förbereda/möjliggöra anrop av den enhet som skall testas. Det är bäst om prefixet är från den beprövade miljö där enheten används. Kod som skapas av generatorn för att initiera gränssnittsvariablerna med provvärden. Här görs också utskrifter till loggen om hur det ser ut före anropet. Anropet av enheten som skall testas. Suffix: Programmets avslutning. Kod för att ta hand om resultatet från anropet. Utskrift till loggen. Utför eventuell städning samt avslutar programmet. Det är bäst om det mesta av suffixet är från den beprövade miljö där enheten används. Fig 5. Generell programstruktur för provfallen När samtliga program som ett i sänder utgör provfallen har genererats skapas direktiven för hela provet. Direktivet är i det här fallet ett rakt script, som för varje provfall:? HiSafe AB 001213 WP3 0_5.doc 0.5 14 av 21

?? Kopierar in källtexten för det aktuella provfallet till rätt bibliotek.?? Kompilerar, länkar och exekverar provfallet.?? Tar bort det provade programmet och återställer simulatorn när provfallet avslutats.?? Separerar utskrifterna i två loggfiler, en fil med utdata från programmen som är provfallen och en fil med utdata från SEEMACS och Solaris. Provningen sker som Black-box testing av de anropade enheterna i ett självständigt program för varje provfall, se figur 6. För varje provfall Direktiv Kompilering Länkning Laddning/körning i simulatorn för MACS Programtext Fig 6. Automatisk körning av provfall. 5.3 Genomförande och resultat Följande prov har genomförts: 1. Kopiering av minnesblock, med 3328 provfall, parametrarna är två adresser och ett heltal. 2. Flyttalskonvertering mellan MACS och D80E, med 22 provfall. Parametrarna är ett flyttal. 3. Sättning av datum och klocka, med 1080 provfall, parametrarna ligger i en datapost. Vi har kört alla provfallen i simulatorn och framkallat felbeteende i ett antal fall. Dessa felbeteenden är förväntade, då vi medvetet valt provfall, som provocerar programmen och som de kanske inte är konstruerade för? HiSafe AB 001213 WP3 0_5.doc 0.5 15 av 21

Vid prov 1 erhölls många "hängningar" av simulatorn. Eftersom simulatorn inte fullt ut motsvarar målmaskinen, så har Ericsson även kört dessa provfall på målmaskinen. Även då erhölls många "hängningar", om än inte i lika många fall. Provfallen visar att rutinen (minneskopiering) inte har en fullständig felhantering, eftersom den inte tar hand om alla de felaktiga minnesreferenser som genereras. Detta bekräftas av Ericsson och förklaras med att användarna efterfrågat en minneskopieringsfunktion som är optimerad för prestanda och inte för robusthet. I användarinstruktionen påpekas bl a "These procedures must be used with care since the addresses can't be supervised by the compiler." För rutinen i prov 1 kördes tidigare ett likadant prov då med 2240 provfall utan "hängningar" men med provvärden som inte var lika genomtänkta. Provvärdena påminde mer om slumpvis valda provvärden och visar hur otillräckligt slumpvis valda provvärden är. Vid prov 2 och 3 har rutinerna visat på ett robust beteende genom att ge korrekt resultat eller ett fördefinierat felmeddelande. För dessa rutiner finns referensprov golden run som kan användas vid regressionsprov i framtiden.? HiSafe AB 001213 WP3 0_5.doc 0.5 16 av 21

6. Resultat av metodförsöken Syftet med provning är att verifiera att en programenhet uppträder enligt specifikationer och att validera att en programenhet svarar mot en användares förväntningar. Dijkstra skrev: Testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence [Dij72]. Den metod för provning av program vi använt betonar verifiering och validering. Genom ett genomtänkt val av provdata kan vi automatiskt generera och exekvera ett stort antal provfall, som fokuserar på en programenhets funktioner och begränsningar. Självklart kommer man vid tillämpning av metoden att hitta ett antal provfall, där resultatet avviker från det förväntade. Den stora vinsten är dock att?? Man får en god täckning av giltiga och ogiltiga anrop till en programenhet.?? Man får en provbänk, där man kan prova en programenhet med ett stort antal provfall ett stort antal gånger under dess uppbyggnad.?? Man får en uppsättning referensprov att utnyttjas vid regressionsprov. De inledande försök vi gjort i dessa projektetapper visar, att metoden är högst användbar för provning av robusthet hos programenheter. I de exempel vi haft har det inte varit några större svårigheter att hitta ekvivalensklasserna i parametrarnas datatyper. Provdata inom ekvivalensklasserna ger sig sedan i stort sett själva. Det har inte heller varit några svårigheter att hitta provdata på gränserna mellan klasserna och omedelbart intill gränserna. Under förutsättning av att hypotesen om indelning av värdeförrådet hos en datatyp kan delas in i ekvivalensklasser håller, får vi därigenom en heltäckande mängd provdata. Väljer man provdata på detta sätt får man ett antal provfall med såväl giltiga som ogiltiga värden. Både de avsedda funktionerna hos en programenhet och dess begränsningar provas därigenom. Avsikten med att välja värden vid gränser är, att enligt erfarenhet samlas programfel vid gränser i de data en programenhet hanterar. Man försöker alltså välja provdata, som dels är representativa för programenhetens funktioner, dels är så ogynnsamma som möjligt. Då provar man inte bara funktionerna utan också begränsningarna genom att provocera programmen. I försöken med kopieringproceduren fick vi 3328 provfall med giltiga och ogiltiga värden på parametrarna vid val av provdata enligt ovan. I ett antal fall kraschade också proceduren, sannolikt genom att delar av det simulerade datorminnet skrevs över. Resultatet är egentligen väntat, eftersom proceduren inte hade särskilda krav på robusthet. I försök med 2200 provfall med slumpmässigt valda värden på parametrarna gav inget provfall ett observerbart felaktigt resultat. Resultaten av dessa försök med dels systematiskt, dels slumpmässigt valda provdata, visar hur effektiv metoden för automatisk generering och exekvering av provfall är. Provning bör vara verifiering av en programenhets funktioner och begränsningar. Väljer man provdata kritiskt med hänsyn till hur en programenhet är definierad provar man såväl de reguljära fallen som de mest ogynnsamma. Analysen av provdata ger därtill ett bra underlag för god dokumentation av en programenhet med funktioner och begränsningar. Provobjekten har inte haft någon interaktion med omgivningen och styrning av en omvärldsimulator ingår inte i FINT idag. Systemet är dock konstruerat för sådan skall ingå, så som vi gjort i provningssystemen på Chalmers. Målmaskinsimulatorn i SEEMACS har fungerat bra. Provobjekt från både Saab och Ericsson har gått att köra i den utan problem. Vid försök med ogiltiga anrop av programenheter har simulatorn kraschat. Ett av provobjekten körde också i en målmaskin. Ogiltiga anrop fick även den att krascha.? HiSafe AB 001213 WP3 0_5.doc 0.5 17 av 21

Ett objekt är provningsbart om man kan:?? Sätta provobjektet i godtyckligt tillstånd före ett prov.?? Stimulera med det provdata.?? Registrera dess respons.?? Jämföra erhållet respons med förväntat. Ett automatiskt provningssystem måste alltid kunna återställas till ett givet grundtillstånd inför varje provfall. Alla provfall skall starta från gemensamma förutsättningar. En automatisk återställning är viktig speciellt när man provocerar ett objekt med provfall det inte är konstruerat för. Utfallet av provet är inte sällan en krasch och alla delar i provningssystem måste kunna återstartas automatiskt. I SEEMACS är detta möjligt. Även målmaskinsimulatorn återställs. För den SU från Saab vi har provat är också återställning relativt lätt att åstadkomma. Kommunikationen mellan programenheter sker via globala variabler. De bör relativt lätt kunna sparas undan för att återla gras inför nya provfall. Vid provning i en målmaskin kräver det naturligtvis, att minne finns tillgängligt. Vår metod för automatisk provning har använts av S&T som en tillämpning av FoTA-teknik inom FoTA P12; se bifogad rapport i appendix. Sammanfattning: Syftet med provning skall vara att verifiera funktioner och begränsningar hos programenheter och system. Fel hittar man effektivast genom granskningar och i idealfallet skall de ha hittats innan man börjar kompilera. Målmaskinsimulatorn i SEEMACS fungerar utmärkt för den typ av provning vi har gjort. De provfall, som kraschar, bör köras också i en målmaskin. Provningssystem, målmaskin och målmaskinsimulator måste vara konstruerade så att de alltid kan återstarta automatiskt. Annars kan man inte köra automatprovning. Den metod FINT bygger på är effektiv för verifiering av funktioner och begränsningar hos programenheter. Den uppmuntrar till konstruktion av robusta och provningsbara program.? HiSafe AB 001213 WP3 0_5.doc 0.5 18 av 21

7. Fortsättning Enligt det ursprungliga förslaget till FoTA projekt [Edl98] skall innehållet i de kommande arbetspaketen vara: WP5 WP6 WP7 Bestämma provfall baserade på felmodellen. Köra systemet med konstlaster, som reagerar på injicerade fel enligt felmodellen. Logga resultaten och analysera. Välja några felhanteringsmekanismer i programvara, som kan inkluderas i driftsystemet som standardrutiner. Bygga in dem i driftsystemet. Köra systemet med samma provfall som i WP5. Logga resultaten och analysera. WP5 är redan gjort vad avser felinjicering på gränssnitten. Felinjicering i själva programenheterna kan vi göra på samma sätt som vi gjort i Chalmersförsöken: vi för in fel i källtexten, kompilerar och kör ett antal varianter. Det sättet att prova är lämpligt om man bygger in mekanismer för felhantering i programenheterna. Det kan vara mekanismer för upptäckt, diagnos och åtgärd av fel samt för återställande efter fel, d v s hela skalan av mekanismer från robust till feltolerant program. De föreslagna arbetspaketen kan också genomföras med felinjicering på gränssnitten. Det vi hittills provat är funktioner och begränsningar hos programenheter. FINT kan användas som det är och ge underlag för att bygga program mer robusta och sedan för att verifiera åtgärderna. FINT kan också användas för felinjicerin g på högre nivå. Injicering av fel i gränssnitten till program är injicering av feltillstånd i det överordnade systemet. Ett felbeteende hos en komponent är ju ett feltillstånd i systemet. Robusthet och feltolerans kan byggas på systemnivå ovanför de typer av komponenter vi provar idag och FINT kan verifiera den typen av pålitlighet. Vill man fortsätta att arbeta på detaljerad nivå kan vi komplettera systemet med funktioner för att styra en omvärldsimulator. Då kan vi troligen inte hålla oss på samma generella nivå som vi gjort hittills, då en omvärldsimulator i allmänhet är tillämpningsspecifik. Viss generalitet kan vi få genom att använda PLC-system eller mätdatasystem som LabView för interaktion med det provade systemet. Fördelen med dem är, att de hanterar vanligt förekommande signaltyper och att de programmeras i anpassade programspråk. Att arbeta vidare med omvärldssimulatorer innebär alltså en hel del utvecklingsarbete. Inom FoTA P12 har man visat visst intresse för vår metodik. Kockums planerade att under våren 2001 prova metodiken på ett programpaket ur företagets ubåtstillämpningar. Som det såg ut preliminärt skulle uppläggningen att bli som i de hittillsvarande programpaketen i FoTA P9. Vi analyserar gränssnittet till programenheter, väljer provdata och provar programenheterna. Programspråket är C++, så FINT måste anpassas till Kockums utvecklingsmiljö. Den delen ligger dock utanför FoTA P9. P g a tidsbrist hos Kockums har de proven inte kommit till stånd Ett annat projekt inom FoTA P12 är ett system från AerotechTelub för hantering av meddelanden. Man har idag tagit fram ett omfattande provningsprogram genom att manuellt skapa en mängd provfall. Kunde detta till en del automatiseras vore mycket vunnet. En del av provningen gäller interaktionen med brukare. Den passar inte att automatisera med vår metodik. Rollen för FINT i sammanhanget är däremot den som omvärldsimulator. Vi kan generera och ta emot en mängd meddelanden automatiskt. Varje meddelande är sammansatt av ett antal fält och varje fält kan ses som en variabel med ett givet definitionsområde. FINT kan då generera meddelanden, där valda värden för varje fält kombineras. Projektet har genomförts under hösten 2001 med gott resultat och avrapporterats inom FoTA P12? HiSafe AB 001213 WP3 0_5.doc 0.5 19 av 21

På institutionen för datorteknik vid Uppsala universitet har man tagit fram specifikationerna för en run-timekärna till Ada enligt Ravenscar-specifikationerna för ett pålitligt realtidssystem [Lun00]. Korrektheten är bevisad med formella metoder och man har vid institutionen påbörjat en implementering i Solaris-miljö. Vi har idéer om ett projekt, där vi skulle implementera runtimekärnan i en enkortsdator med en Motorola 68340-processor. Syftet med projektet är:?? Bygga en realistisk och användbar version av ett pålitligt realtidssystem för Ada 95.?? Prova vår provningsmetodik från början i ett projekt, där man för varje komponent bygger upp provningsmiljön först och sedan själva komponenten. Båda utgår från specifikationerna, men byggs separat. Detta är ett sätt att arbeta, som börjar få spridning bl a i samband med Extreme programming.?? Korrektheten i run-timekärnan är bevisad med formella metoder. Den skall dock transformeras till ett körbart program, vilket ännu så länge är manuellt, kreativt arbete. Transformationen måste liksom alla andra tekniska konstruktioner verifieras. FINT vore ett bra verktyg. Som vi diskuterat projektet med Ada Ravenscar ligger det också utanför FoTA P9. Ett par tankar till om fortsättningen på projektet:?? Under arbetet med FINT och framför allt under försöken har vi observerat, att sättet att tänka vid utveckling av program förändrats. Man blir klart benägen att tänka på robusthet, vilka fel som inträffa vid användning av programmet och hur man skall hantera dem. Man tänker också på provningsbarhet, hur programmet skall kunna verifieras under sin utveckling och sedan det är färdigt. Kanske man skulle skapa en kurs m h a FINT hur bygger man robusta och feltoleranta program.?? FINT bör utvecklas vidare och bli en produkt, som kan användas i vidare sammanhang.? HiSafe AB 001213 WP3 0_5.doc 0.5 20 av 21

8. Referenser [Car00] [Chr98] [CRH98] Caron, D., Design and implementation of a system for automatic fault injection at the interface of an RTOS, tech. report no. 00-3, Department of Computer Engineering, Chalmers University of Technology, 2000. Christmansson, J. An Exploration of Models for Software Faults and Errors: a Journey through Field Data and Injection Experiments, PhD thesis, Dept. of Computer Engineering, Chalmers University of Technology, 1998. Christmansson, J., Rimén and M., Hiller, M., An Experimental Comparision of Fault and Error Injection, in Proceedings of the 9 th International Symposium on Software Reliability Engineering (ISSRE), pp. 396-378, 1998. [Dij72] Dijkstra, E. W., The Humble Programmer, Communications of the ACM, 15.5, October 1972. [Dum00] [Edl98] [EMW] [Hil98] [Hil00] [Lun00] [Saab] [WP1] [WP2] Dumortier, J., Building an environment for an automatic fault injection system at the interface of a Real Time Kernel, tech. report no. 00-18, Dept. of Computer Engineering, Chalmers University of Technology, 2000. Edler, H., Experimentell verifiering av feldetektering och feltolerans, förslag till FoTA-projekt, HiSafe, okt 1998. Användardokumentation för SDS MACS, Ericsson Microwave Systems, 1999-04-07. Hiller, M., Executable Assertions for Detecting Data Errors in Embedded Control Systems, in Proceedings of the International Conference on Dependable Systems and Networks (DSN) 2000 (FTCS-30 & DCCA-8), pp. 24-33, 2000. Hiller, M., A Tool for Examining the Behaviour of Faults and Errors in Software, tech. report no. 00-19, Dept. of Computer Engineering, Chalmers University of Technology, 2000. Lundkvist, K., Distributed Computing and Safety Critical Systems in Ada, PhD thesis, Dept. of Computer Systems, Uppsala University, 2000. Material om uppbyggnaden av provningssystem för SD Gripen. Hermansson, S. och Sinclair, J., Etablering av experimentmiljö, Rapport inom FoTA P9, HiSafe, juni 2000. Edler, H., Felinjicering och felmodeller, Rapport inom FoTA P9, HiSafe, juni 2000.? HiSafe AB 001213 WP3 0_5.doc 0.5 21 av 21

Tillämpning av felinjicering på Blueberry3D 2000-12-12 Appendix Tillämpning av felinjicering på Blueberry3D Mattias Widmark Andreas Ögren Sjöland & Thyselius Datakonsulter AB 1 Sammanfattning Blueberry3D är ett realtidssystem för 3D - visualisering av virtuella utomhusmiljöer. Systemet är tänkt att ingå i bland annat militära simulatorer, vilket ställer höga krav på stabilitet och tillförlitlighet. Valda delar av systemet, dess databashantering och API, har testats med felinjicering för att kontrollera dess stabilitet. Testning med felinjicering av felkällor visade sig vara bra för att kontrollera felhanteringen av felkällor inom systemet. Ett flertal fel i databashanteringen har upptäckts och korrigerats tack vare metoden och den är ett bra komplement till traditionella metoder för felsökning. Testning med felinjicering av feltillstånd är dock inte tillämpbart på realtidsmodulen i Blueberry3D på grund av att prestandakraven på visualiseringen inte medger extra testkontroller. Felinjicering kan delas upp i två varianter: injektion av felkällor och injektion av feltillstånd. Skillnaden är att genom att injicera en felkälla inhämtas felet genom ett specificerat gränssnitt till programmet medan om ett feltillstånd injiceras går man runt gränssnittet direkt in i programmet. 3 Blueberry3D Blueberry3D är ett realtidssystem för konstruktion och visualisering av virtuella utomhusmiljöer i 3D. Det kommer att användas som visualiseringsmotor för militära och civila simulatorer, spelmarknaden och som GIS-verktyg för 3D-presentation av digitalt kartmaterial. Programmet kan köras på PC med 3Dkort under Windows. Version 1 kommer att säljas från och med april 2001. Ett exempel på de bilder som kan genereras av Blueberry3D visas i Figur 1. 2 Tekniker för felinjicering Ett programs stabilitet kan avgöras genom studier av dess stabilitet vid normal exekvering och dess stabilitet vid exekvering när felkällor eller feltillstånd har injicerats. Att testa systemet under normal exekvering och dess felhantering från användare av systemet är ofta otillräckligt. Fel kan komma från många andra källor, som till exempel kompilatorer, systemprogramvara och hårdvara. Håkan Edler har utvecklat en metod för testning där fel injiceras i flera olika delar systemet [1]. Fel kan till exempel injiceras på elektrisk nivå, logiknivå eller funktionsnivå i hårdvaran, eller i programvaran i form av ändringar av dess minne eller maskinkod. Konsekvenserna av de genererade felen bör sedan minimeras av felhanteringsmekanismerna. Håkan Edler menar att med hjälp av felinjicering är det möjligt att?? Verifiera felhanteringsmekanismer?? Validera tillförlitligheten Detta kräver dock att man vet när, var och hur felen ska injiceras [1]. Figur 1: Terräng genererad av Blueberry3D. Blueberry3D består av tre huvudsakliga komponenter:?? Blueberry3D Viewer?? Blueberry3D Editor?? Blueberry3D SDK Blueberry3D Viewer är visualiseringskomponenten i systemet. Den arbetar interaktivt i realtid för att visualisera terrängen från olika vyer med hjälp av 1

Tillämpning av felinjicering på Blueberry3D 2000-12-12 Appendix OpenGL. Blueberry3D Editor används för att utforma och konstruera terrängen i de databaser som används av Blueberry3D Viewer. Det går även spela in filmer och skapa högkvalitetsbilder för till exempel presentationsmaterial. Blueberry3D SDK, Software Development Kit, är ett utvecklingspaket som består av Blueberry3D Viewer, Blueberry3D Editor och Blueberry3D API, Application Programming Interface. Det används av externa applikationer som integreras med Blueberry3D genom att anropa de funktioner som ingår i gränssnittet [2]. Figur 2 visar en skärmbild av Blueberry3D Editor. egenutvecklad databas som är optimerad för konstruktion och visualisering i realtid. Databasen består av följande komponenter:?? Höjdraster?? Terrängklassningsraster?? Ortotexturraster?? Vektordata?? 3D-modeller?? Realtidsdatabas?? Metadata Höjdrastret har ofta en upplösning på cirka 50 meter, medan terrängklassningsrastret och ortotexturrastret bör ha högre upplösning, till exempel 25 respektive 12,5 meter. Dessa raster är tillräckliga för visualisering av den naturliga terrängen eftersom det är möjligt att med fraktaler använda en kontrollerad slumpfunktion som genererar mindre detaljer än vad som är lagrat i BBDB [3]. Vektordatat används för positionering av konstruerade objekt, såsom till exempel vägar och hus. Detta data kan referera till en 3D-modell som sedan visualiseras på den position som vektordata specificerar. Både vektordatat och rasterdatat är lagrat i binärfiler. Figur 2: Blueberry3D Editor. 3.1 Fraktalbaserad beräkning Ett problem som uppstår vid 3D-visualisering av stora datamängder är begränsningen på de beräkningsresurser som finns tillgängliga. De är ofta otillräckliga för att upprätthålla en realtidsuppdatering ifall allt data används för att beräkna bildsekvensen. Terrängvisualisering är ett exempel där detta problem uppstår. Lösningen på problemet är att endast visualisera det data som är synligt för observatören på den detaljnivå som krävs. Till exempel vill man visa enskilda löv i närliggande träd medan det räcker med en approximativ bild av träd på större avstånd. Blueberry3D utnyttjar avancerade algoritmer baserade på fraktaler för att implementera denna lösning [3]. 3.2 BBDB Den databas som används av Blueberry3D kallas Blueberry3D Database, BBDB. BBDB är en Realtidsdatabasen innehåller raster- och vektordatat i ett format som är optimerat för realtidsvisualisering. Metadatat beskriver egenskaper hos det övriga datat och är lagrat i textfiler. Det faktum att fraktaler används för beräkningen av detaljnivåerna minimerar storleken av terrängdatabasen. Geometrin till vegetationen och markytan behöver inte sparas explicit, utan beräknas under exekveringen utifrån parametrarna till fraktalerna [3]. 3.3 Blueberry3D API Blueberry3D API är ett programmeringsgränsnitt för externa utvecklare som vill integrera deras program med Blueberry3D [4]. Det består utöver BBDB av 5 klasser. Blueberry är den centrala klassen som sammanlänkar de klasser som utför beräkningen av den fraktala modellen och de som visualiserar den. De fyra andra klasserna, Single_frame_view, Renderfeed_view, Deep_freeze_world_model och Deep_freeze_single_cover_object är vyobjekt som hanterar visualiseringen. Alla ärver från en abstrakt 2

Tillämpning av felinjicering på Blueberry3D 2000-12-12 Appendix basklass kallad View. Följande metoder är deklarerade i View och används i alla fyra vyklasser:?? init() Initierar vyobjektet och måste anropas före all visualisering. Ominitiering är möjlig genom nya anrop.?? adjust_to_win_size() Anropas då ritarean i vyn ändrar form eller storlek. Den måste också anropas före all visualisering men efter init().?? set_camera_shape() Bestämmer kamerans projektionstyp till antingen perspektivprojektion eller ortogonalprojektion.?? set_camera() Bestämmer kamerans position, riktning och lutning.?? generate() Genererar den geometri av databasen för den nuvarande vyinställningen.?? paint() Visualiserar den virtuella terrängen på skärmen enligt de inställningar som satts med funktionerna ovan och de som är bestämda i BBDB. I Blueberry används endast en funktion:?? add_view() Registrerar vyobjektet och sammanlänkar kopplingen mellan dem. I BBDB används två funktioner:?? load() Öppnar en databas.?? register_client() Registrerar Blueberry-objektet så att det kan läsa från databasen. 4 Testfall Blueberry3D kommer att användas till att konstruera och visualisera databaser över virtuell terräng. Detta kan dels ske genom de egenutvecklade användargränssnitten och dels via Blueberry3D API. Därför bör BBDB, visualiseringsmodulen och Blueberry3D API testas. Ett problem med 3Dvisualisering i allmänhet är, precis som nämndes i Sektion 3, att den underliggande hårdvaran inte är tillräckligt kraftfull för de behov som finns. Programmen måste därför optimeras för att åstadkomma tillräckligt bra bildkvalité under interaktiv bilduppdateringshastighet. Detta lämnar felhanteringsprocessen på lägre prioritetsnivå i realtidsmodulen än övriga moduler och måste därför utelämnas. Det som återstår är tester av felinjicering av felkällor på BBDB och Blueberry3D API. Eftersom det utdata som programmet beräknar är de bilder det visar på skärmen, är det omöjligt att kontrollera om beräkningarna har varit korrekt utförda. Därför kommer en felaktig programkörning definieras som en krasch av programmet. 4.1 Test av BBDB Det finns både textfiler och binärfiler lagrade i BBDB. Textfilerna innehåller läsbar text medan binärfilerna bara kan tolkas av Blueberry3D. Testet genomförs genom att ändra på en byte i någon av textfilerna och sedan låta Blueberry3D läsa in databasen. Detta upprepas sedan ett stort antal gånger. I textfilerna lagras det endast läsbar text som består av alla bokstäver och siffror samt en antal extra tecken som till exempel mellanslag, brädgård, komma, kolon, lika med, citationstecken, punkt och backslash. För att åstadkomma troliga fel har testfallen utformats så att ett tecken har slumpvist valts mellan mellanslag, slumpvis siffra 0-9, slumpvis bokstav a-z eller slumpvis ASCII-kod 0-255. En störning kommer att införas på slumpvis position på varje rad i vardera av de fem textfiler som ingår i BBDB. Detta innebär att alla störningar kan inträffa, men det kommer att vara högst sannolikhet att störningen består av ett läsbart tecken. Databasen läses sedan in efter varje felinjicering. Samtidigt uppdateras en loggfil som hjälper oss hitta de fel som eventuellt uppstår. Den innehåller en beskrivning över den injicerade störningen och det resultat som störningen implicerade. 4.2 Test av Blueberry3D API Blueberry3D API består av en mängd klasser med tillhörande funktioner. Varje funktion har sin specifika uppsättning parametrar. Testet väljer ut funktionerna i en slumpvis ordning och anropas med en slumpvis uppsättning parametrar. Parametrarna är alltid i rätt antal och av rätt datatyp, eftersom en C++kompilator i alla realistiska fall inte tillåter något annat. I testkörningen kommer nio funktioner med totalt 16 parametrar i tre klasser som ingår i Blueberry3D API att testas 800 gånger. I varje test 3