FÖRSLAG 1 (8) Ert datum Er beteckning Handläggare Håkan Edler Fördelning Godkänd av Kopia till Projektets namn Experimentell verifiering av feldetektering och feltolerans Förslagsställare Håkan Edler HiSafe Development AB Ebbe Lieberathsgatan 25 412 65 Göteborg Tel: 031-773 76 07 GSM 070-515 14 45 Fax: 031-773 76 10 E-post edler@hisafe.se 1. SAMMANFATTNING På institutionen för Datorteknik vid Chalmers tekniska högskola har jag under några år drivit ett projekt med forskning på feltolerant programvara. Syftet har varit, att hitta metoder att bygga programvarusystem, så att de kan tåla egna konstruktionsfel och andra fel i ett datorbaserat system. Som konkret resultat av forskningen har vi idag en provningsmiljö, där vi på ett systematiskt sätt injicerar fel i programvara och värderar effekten av dem. Denna provningsmiljö kommer vi att använda för experiment i det fortsatta forskningsarbetet. Som FoT-anpassningsprojekt föreslår jag, att HiSafe i samverkan med andra intressenter bland SESAM-företagen använder erfarenheterna från denna provningsmiljö i för FM relevanta system. Syftet är att föra ut forskningsresultat till praktisk användning och att få fram nya metoder att prova system. Provning med felinjicering kan höja kvaliteten i provningsarbetet avsevärt. 1.1. Mål Att i praktisk tillämpning pröva ett sätt att mäta förmågan hos datorbaserade system att upptäcka och tåla fel. Metoden är tänkt att ingå i den arsenal av provningsmetoder, man använder för att verifiera och validera datorbaserade system. 1.2. Relevans Snart sagt alla artiklar och böcker om pålitliga datorsystem inleds med påpekandet att datorer idag används inom alla delar av ett modernt samhälle och att kraven på deras pålitlighet ständigt skärps. I ökande grad blir vi beroende av datorsystem och de är kärnan i våra komplexa tekniska system. Pålitliga datorsystem kräver vi inte bara när personsäkerhet eller stora materiella värden står på spel. Även system som tillverkas och distribueras i massupplaga har höga krav på pålitlighet. Feltolerans är en väsentlig aspekt av pålitlighet. Ett feltolerant datorsystem skall inte bara tåla fel i programvarans källtext utan också de fel, som introduceras av kompilatorer, länkare och run-timesystem. Ett pålitligt system måste tåla dessa fel likaväl som temporära och permanenta maskinvaru-
FÖRSLAG 2 (8) fel. Det räcker alltså inte med att försöka bygga ett system felfritt, man måste även konstruera det feltolerant. Nya tekniker måste skapas och användas för att analysera, bygga och prova ett system ur tillförlitlighetssynvinkel Certifiering av datorbaserade system i säkerhetskritiska tillämpningar är fortfarande ett problem. Oavsett utvecklingsmetodik och teoretisk verifiering måste alltid ett system provas systematiskt innan det sätts i drift. Ett sätt att prova feltoleransmekanismer i ett datorsystems programvara och maskinvara är, att systematiskt injicera fel och mäta systemets förmåga att upptäcka felen och korrigera för dem. 1.3. Utvecklingssituationen Vid institutionen för datorteknik på Chalmers har vi inom forskningsprojektet Feltolerant programvara utvecklat en provningsmiljö för försök med injicering av fel i programvara. Den är avsedd att användas för utvärdering av olika metoder att bygga system, så att de tål konstruktionsfel i den egna programvaran, kompilatorfel och andra programvarufel likaväl som transienta och i vissa fall permanenta maskinvarufel. Som provningsmiljön ser ut idag är den klart inriktad mot forskningstillämpningar. Systemet som vi kör experiment på är dock det system för uppfångning och inbromsning av flygplan HiSafe byggt åt Scama AB och levererat till Singapores flygvapen. Systemet är idag inte feltolerant, men är i grunden konstruerat för att vara det. Vi har stödfunktioner i maskinvaran för att med programvara kunna bygga in den feltolerans, som kan visa sig nödvändig. Inom forskningsprojektet kommer vi att arbeta vidare och genom försök i vår provningsmiljö studera olika algoritmer och mekanismer för feltolerans i programvara. Provningsmiljön består idag av program i en persondator, ett målsystem, en omvärldssimulator och anpassningselektronik. Vi kör automatiskt långa sekvenser av prov i målsystemet och injicerar systematiskt fel i programmet. Simulatorn genererar data slumpmässigt enligt en given användningsprofil och parametrar, som beskriver provbetingelserna. Programmen i persondatorn styr och övervakar proven. Provsekvenser, parametrar och programfel ligger som filer, vilka persondatorn laddar ned i målsystem och simulator. Valda data loggas under proven för senare analys och utvärdering. Utanför forskningsvärlden har felinjicering ännu inte fått någon större spridning, trots de obestridliga fördelar denna typ av verifiering ger. Saab har dock byggt robusta system och har för flygburna system och bl a för tillämpning i D80/D96 (MACS) med erfarenhet från Gripen och tidigare flygplan utvecklat funktionsövervakning och feldetektering, i första hand för maskinvarufel och kommunikationsfel i avioniksystemet. Datorns maskinvara övervakar vissa exekveringsfel. Programminnesinnehåll övervakas med checksummeringar. Realtidsexekutiven bevakar bl a exekveringstid och överlast samt programminnesinnehåll. Även funktionellt finns det vissa rimlighetsövervakningar. 1.4. Samband med andra kända projekt eller verksamheter När FMV från början stödde vårt forskningsprojekt var möjligheten att certifiera säkerhetskritiska system ett huvudintresse. Bland system som idag utvecklas åt FM finns sådana, som i vissa delar är säkerhetskritiska. När vi har sökt samarbetspartners för FoTA har vi funnit ett antal system, som vore intressanta att studera ur tillförlitlighetssynvinkel. Ett av dem koncentrerar vi oss nu på. Övriga FoTA-förslag, som gäller säkerhetskritisk programvara har givetvis samband med vårt förslag. Det förslag vi för fram gäller exekutiv realtidsprogramvara i fpl JAS 39 Gripen Systemdator. Programvaran har i flera versioner varit i skarp användning i mer än tio år och innehåller flera moment av robusthet i form av felupptäcktsförmåga och "global" feltolerans. Saabs programvara porteras nu och byter datorgeneration från D80 till D96/MACS (Modular Avionics Computer System) från EMW. Den bygger på standardkomponenter och stödjer programutveckling i såväl Ada som Pascal/D80. Utvecklingsmiljön har fått namnet SEEMACS och bygger på Rationals utvecklingsmiljö Apex. Det vore värdefullt, att kunna införa felinjicering som en verifieringsmetod i provningsmil-
FÖRSLAG 3 (8) jön till MACS. Detta föreslår vi som ett FoTA-projekt med experimentell verifiering av feltolerans. Diskussioner pågår med inblandade parter. EMW ställer upp med tekniskt bistånd och guidning beträffande utvecklingsmiljön. Saab har tillämpningen. Systemdatorn i Gripen har riskkategori 2 (Critical enligt MIL-Std-882C) och programkritikalitet C (Major enligt RTCA/DO-178B). Projektet skall drivas i samverkan med forskningsprojektet på Chalmers. 1.5. Projektets potential och värde Det är alltid svårt, att skatta värdet av ny teknik. Vi har på Chalmers lärt oss mycket om målsystemets svaga punkter, när vi kört felinjiceringsexperimenten. Att t ex ändra programräknaren eller systemklockan - fel som man många gånger inte räknar med - ger naturligtvis katastrofala resultat. Detta är ett drastiskt exempel, men vi har också hittat andra svagheter, som kanske inte var så lätta att inse från början. På HiSafe kör vi idag automatiska långtidsprov av system och loggar data från körningarna, som många andra också gör. Lägger vi till systematisk injicering av fel provar vi också systemets robusthet och hittar svaga punkter. En forskare sade för ett par år sedan, att FMEA var teoretisk felinjicering. Vi kan vända på detta och säga, att felinjicering är en praktisk FMEA. Vad vi kan vinna på detta projekt: Lära oss hur felhanteringsmekanismer i programvara kan klara fel i programvaran, indatafel, temporära maskinvarufel och permanenta maskinvarufel. Etablera ett sätt att analysera, konstruera och bygga programvarusystem med hänsyn till pålitlighet. Etablera för praktisk användning en provningsmiljö för experimentell verifiering av pålitlig programvara. Studera hur generella mekanismer för felupptäckt och felhantering kan byggas in i ett driftsystem. Studera en metod att mäta på gränssnitten i programvara. Detta kan vara av stor framtida betydelse, då det gäller att verifiera COTS. Den aktuella tillämpningen är en del av ett avioniksystem, där några tillämpningar med samma datortyp kommer att följa, för vilka den utvecklade tekniken blir direkt tillämpbar. Det förutsätts, att även andra (bl a avionik) tillämpningar med annan maskinvara kan utnyttja tekniken/metoden. Bl a finns i Gripen tillämpningar med högsta riskkategori (1, ccatastrophic) och programvarukritikalitet (A). 1.6. Speciella teknikbehov Vi har idag fungerande provningsmiljöer byggda för givna målsystem. Principerna för provningsmiljön är dock generella och kan flyttas till andra målsystem. I det föreslagna projektet behövs SEEMACS utvecklingsmiljö och en måldator. I en utveckling av projektet kan vi behöva köra redundanta måldatorer och använda en enkel omvärldssimulator.
FÖRSLAG 4 (8) 2. PROJEKTBESKRIVNING 2.1. Inriktning, mål och avgränsning Parallellt med forskningsverksamheten vid Chalmers vore det intressant för HiSafe, att sätta provningsmiljön i praktisk användning. Vi är ett stycke på väg genom att försöken idag görs på ett verkligt system, som dessutom är en militär tillämpning, men provningsmiljön är anpassad för detta system och försöken för forskningen. 2.2. Tekniskt innehåll I ett projekt med datorsystemet MACS vill vi göra en prototyp av ett felinjiceringssystem och: Undersöka möjligheterna att göra felinjicering och mätning på gränssnitten i datorsystemet MACS och dess programvara som alternativ till att injicera fel i programmen. Visa möjligheterna att med felinjicering, dels verifiera ett felhanteringssystems förmåga att upptäcka och hantera fel i målsystemet, dels upptäcka och lokalisera fel i felhanteringssystemet självt. Visa nyttan av denna typ av verifiering och få underlag för en kravspecifikation för hur den i en skarp version kan inlemmas i datorsystemet MACS. Generalisera provningsmiljön, så att den kan användas för andra typer av system och processorer. Använda FTA, FMEA och andra analytiska metoder för att identifiera säkerhetskritiska delar av systemet och värdera inverkan av dem. Andra uppgifter, som har diskuterats, men inte finns med i förslaget är: Undersöka robusthet hos periodiska system jämfört med händelsestyrda. Detta är i och för sig inte en nedärvd egenskap hos respektive systemtyp, utan har att göra med hur väl man kan skapa felmodeller, upptäcka fel, avgränsa dem och korrigera för dem. Eftersom debatten alltid är aktuell, vore det intressant att mäta. Utreda om någon av de säkerhetskritiska delarna kan specificeras och verifieras med formella metoder. Detta finns dock inte med i arbetspaketen nedan och ingår inte i förslaget. Den främsta orsaken är, att vi ännu inte diskuterat möjligheterna med en lämplig samarbetspartner. Sådan finns dock i andra förslag till FoTA-projekt. 2.3. Tekniska och/eller andra förutsättningar Vi har idag fungerande provningsmiljöer. De kan flyttas till andra typer av system. De är framtagna inom forskningsprojektet på Chalmers, som stötts av främst av NUTEK, FMV och Volvo. För NUTEK är det ett väsentligt framgångskriterium, att man lyckas sprida forskningsresultaten och att de kommer till användning inom svenskt näringsliv. I det här föreslagna projektet kan i första hand felinjiceringen ske i exekutiven för en processor. Bussexekutiv och exekutivdelarna i processor 2 och ev processor 3 utgör då en del av den samlade omgivningen, då vi vill skapa en fungerande experimentmiljö. I andra hand sker felinjiceringen i exekutiven för två eller flera processorer när man vill kunna verifiera större delar av datorsystemet. I tredje hand kan vi ta med även busskommunikationen på en av 1553-bussarna. I en sådan utbyggd miljö har man fått ett visst mått av både tids- och händelsestyrning och kan prova robustheten hos de använda mekanismerna. I den tredje processorn och med en andra busskanalprocessor kan man simulera busstrafiken och övriga terminaler på 1553-bussen.
FÖRSLAG 5 (8) 2.4. Förväntade resultat Vi förväntar oss, att i en större krets kunna etablera felinjicering som en metod att verifiera och validera datorbaserade system. Vi förväntar oss också, att i en större krets kunna etablera för regelbundet bruk metoder för analys av tillförlitliga datorbaserade system. De vi tänker närmast på är FTA och FMEA. De kan användas redan på hög abstraktionsnivå vid analys och konstruktion av system. 2.5. Osäkerheter eller svåra inslag En kritisk del i analys och konstruktion av feltoleranta system är, att hitta bra felmodeller. Man kan inte bygga robusta system om man inte vet vad man skall skydda sig mot. 2.6. Avgränsningar Inga andra än vad som sagts ovan. 3. GENOMFÖRANDE 3.1. Genomförande parter Den tillämpning vi diskuterar är Gripens Systemdatorexekutiv (Saab) på en dator av typ D96/MACS (EMW) med programutvecklingsmiljön SEEMACS och att i första hand prova felinjiceringstekniken för att få fram en kravspecifikation på hur den skall integreras i utvecklingsmiljön. På Chalmers har länge bedrivit forskning i området. De parter vi föreslår i projektet är: Ericsson Microwave Systems AB, Saab AB, Gripen, Institutionen för datorteknik förutom HiSafe Development AB Kontaktpersoner är: Tommy Andersson och Kurt Lind hos EMW, Dag Folkesson hos Saab och Håkan Edler hos HiSafe och på Chalmers. 3.2. Arbetsfördelning HiSafe Development AB har tekniskt kunnande om feltoleranta datorsystem och felinjicering och står för projektledning, systemkonstruktion, systembygge och mätningar på systemen. Institutionen för datorteknik står för forskningsnära delar av projektet. Ericsson Microwave Systems AB tillhandahåller utvecklingsmiljön och ger tekniskt kunnande om denna. Saab Gripen har tillämpningen och ger tekniskt kunnande om den. Alla parter gör tillsammans analyser av mätningar och övriga resultat av försöken.
FÖRSLAG 6 (8) 3.3. Finansiering HiSafe Development AB 1 pers fulltid 850 kkr/år Institutionen för datorteknik 1 doktorand 440 kkr/år Ericson Microwave Systems AB 1 pers 20 % 260 kkr/år Saab Gripen 1 pers 20 % 260 kkr/år Med värden enligt tabellen blir finansieringsbehovet är 1810 kkr / år för persontid. Fördelningen mellan EMW och Saab kan komma att ändras. 3.4. Projektledning och -styrning Vi föreslår, att HiSafe leder och styr projektet. 3.5. Utrustnings- och andra behov Utrustningsbehovet borde vara litet: En Sun/Solaris arbetsstation behövs för SEEMACS. Ett MACS målsystem i VME-rack. Experimenten körs i vanlig kontorsmiljö Om program för MACS skall skrivas i Ada behövs Rationals Apex. Licensfrågor måste också diskuteras med Rational. 3.6. Tidplan och kostnadsfördelning Saab kan leverera en första tillämpning för MACS tidigast 1 juli 1999. Innan dess skall dock experimentmiljön byggas upp och då kan man troligen köra på en tidig variant av exekutiven. Om inte detta går, kan man tills vidare använda programmet från processor 3 i systemdatorn. Det används idag som testprogram för MACS. Det är avhemligat och anpassat för en processor. 3.6.1. Arbetspaket WP1 WP2 WP3 WP4 WP5 Bygga upp experimentmiljön med en Sun/Solaris arbetsstation som utvecklingssystem och en måldator. Arbetsstationen skall kunna automatiskt ladda ned program, starta exekvering och logga data. Vissa av dessa funktioner kan möjligen läggas i en persondator och ett enkelt PLC-system. Göra en felmodell för driftsystemet, som omfattar: Kvarvarande programfel i ett välprovat program, temporära maskinvarufel och permanenta maskinvarufel. Bestämma provfall baserade på felmodellen. Köra driftsystemet med konstlaster. Injicera fel automatiskt enligt provfallen. Logga och analysera. 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. Bestämma provfall baserade på felmodellen. Köra systemet med konstlaster, som reagerar på injicerade fel enligt felmodellen. Logga resultaten och analysera.
FÖRSLAG 7 (8) WP6 WP7 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. 3.6.2. Tidplan WP1 WP2 WP3 WP4 WP5 WP6 WP7 H 98 V 99 H 99 V 00 H 00 3.6.3. Kostnadsfördelning Se avsnitt 3.3 ovan 4. UPPFÖLJNING 4.1. Etappuppföljning Varje arbetspaket skall avslutas med en rapport och ett seminarium. Lägesrapporter skriv kvartalsvis. 4.2. Kriterier för framgång Att vi för tillämpningen, liksom vi hittills gjort i flygfältstillämpningen: Hittar bra felmodeller. Hittar realistiska användningsprofiler. Får metoder att hitta svaga punkter i de provade konstruktionerna. Få mått på hur bra provade mekanismer för felupptäckt fungerar. Få mått på hur bra provade mekanismer för feltolerans fungerar. Att vi kan integrera den automatiska provningen och felinjiceringen i utvecklingsmiljön. 4.3. Kriterier för översyn av projektet TBD
FÖRSLAG 8 (8) 4.4. Sekretess Resultaten skall vara öppna för SESAM-företagen vad avser metoder och tekniker för felinjicering. Tillämpningarna som sådana har vanligen företagssekretess. 4.5. Nyttjanderätt m m Målet med projektet är, att föra ut ny teknik till användning i verifiering och validering av datorbaserade system. Deltagande parter och SESAM-företagen skall därför ha fri nyttjanderätt till resultaten. Deltagande parter skall ges möjlighet att anskaffa och anpassa felinjiceringsutrustning för egna tillämpningar.