Objekt-orienteret software safety Lisa Wells, ISIS Katrinebjerg / Aarhus Universitet SummIT 05, Temasession: Software Safety

19. januar 2005 Lisa Wells, SummIT 05 2 Plan Generelt om objekt-orienteret software safety OOSS i et industrielt projekt Teknikker til OOSS  Safety kravspecifikationer  Hazard analyse  Validering

19. januar 2005 Lisa Wells, SummIT 05 3 Safety-kritisk software Et safety-kritisk system er et system som kan skade sine omgivelser. Safety-kritisk software findes overalt i vores hverdag.  Transportmidler – flyvemaskiner, tog, biler, …  Industrielle maskiner – kraner, transportbånd, …  Fabrikker og kraftværker Der er ofte strenge regler for hvilke processer, teknikker og programmeringssprog der kan bruges til udvikling af safety-kritisk software.  Standarder baseret på mange års erfaringer.  Begrænsede programmeringssprog – Misra C, Ravenscar Ada  (Semi-) Formelle metoder – sekvensdiagrammer, endelig tilstandsmaskiner, Petri nets, …

19. januar 2005 Lisa Wells, SummIT 05 4 Objektorientering Fordele  Begrebslig ramme Modellering – samme formalisme i alle faser og domæner Understøtter iterativ og inkrementel udvikling  Teknisk ramme Indkapsling, nedarvning, komposition, polymorfi, … Mekanismer til genbrug  Udbredt i industri

19. januar 2005 Lisa Wells, SummIT 05 5 Objekt-orienteret software safety Objekt-orienteret teknikker og sprog bruges i stadig større udstrækning til udviklingen af safety-kritiske systemer. Men er det hensigtsmæssigt at bruge OO teknikker til safety- kritiske systemer…?  Standarder og eksperter indenfor safety-kritisk software anbefaler nærmest det modsatte… Oplagte problemer:  Der findes få velkendte og vidt accepterede teknikker til udvikling af safety-kritisk OO software.  Visse OO sprogkonstruktioner øger kompleksiteten af kode, og koden bliver dermed sværere at forstå, afprøve, og verificere.  OO værktøjer er ikke nødvendigvis moden nok til opgaven.

19. januar 2005 Lisa Wells, SummIT 05 6 ISIS Katrinebjerg projekt om OOSS Undersøgelse af processer og teknikker til udvikling af objekt-orienteret safety-kritisk software. Projektpartnere:  Danfoss Drives A/S  Systematic Software Engineering A/S  ISIS Katrinebjerg Projektperiode: 1. juni 2003 – 31. dec Fokus på et nyt Danfoss produkt – en frekvensomformer som skulle certificeres som safe.

19. januar 2005 Lisa Wells, SummIT 05 7 Frekvensomformere Kontrollerer hastigheden af motorer, f.eks. i elevatorer, kraner, og transportbånd. Såkaldte safety funktioner bliver aktiveret af brugere til at kontrollere og stoppe den tilsluttede motor.  Uncontrolled stop  Controlled stop  Speed-limiting Safety-kritisk software skal køre på to mikroprocessorer.

19. januar 2005 Lisa Wells, SummIT 05 8 Plan Generelt om objekt-orienteret software safety OOSS i et industrielt projekt Teknikker til OOSS  Safety kravspecifikationer  Hazard analyse  Validering

19. januar 2005 Lisa Wells, SummIT 05 9 Safety kravspecifikationer Størstedelen af ulykker hvor software var involveret kan spores tilbage til mangelfulde, tvetydige, og fejlagtige kravspecifikationer. IEC61508 er en standard for udvikling af elektroniske og programmerbare safety-kritiske systemer.  System safety kravspecifikationer skal defineres vha. semi- formelle metoder. En safety kravspecifikation på system-niveau blev forfinet til at tage højde for de to mikroprocessorer i frekvensomformeren. Vigtige egenskaber:  Synkronisering af tilstande mellem de to mikroprocessorer.  Koordinering af hardware diagnose.

19. januar 2005 Lisa Wells, SummIT Tilstandsmaskiner som kravspecifikation To modeller som modellerer både tilstande og hændelser i systemet:  Statechart  Coloured Petri Net (CPN) Tilhørende værktøj for modellering, simulation, og verifikation. Identificerede potentielle problemområder:  Deadlock under diagnose  Forsinket opdagelse af fejl pga. forældede beskeder mellem processorerne.

19. januar 2005 Lisa Wells, SummIT UML-baseret softwarearkitektur Softwarearkitekturen blev beskrevet vha. UML diagrammer:  Klasse, pakke  Objekt, deployment  Sekvensdiagrammer Arkitekturen skulle opfylde kravene specificeret i Statechart og CPN modellerne. Udfordring: sikre konsistens mellem kravspecifikationen og softwarearkitekturen (og evt. koden).

19. januar 2005 Lisa Wells, SummIT Hazard analyse En hazard er en farlig tilstand eller hændelse som vil føre til en ulykke. Hazard analyse skal:  Identificere hazards for et system  Identificere hvordan hazards kan opstå  Identificere effekten af hazards Hazard analyse blev udført på:  Kravspecifikationer  Modeller og design repræsentationer

19. januar 2005 Lisa Wells, SummIT Fault tree analyse (FTA) FTA identificerer hvordan hazards opstår. En hazard brydes ned til basale hændelser som er tilstrækkelig til at forårsage hazard’en. Håndtering af de basale hændelser:  Minimere sandsynligheden for at de opstår  Bevis at de ikke kan opstå  Ændre design’et således at de bliver håndteret på en passende måde. Metoden kan bruges i alle udviklingsfaser, også i forbindelse med OO software.

19. januar 2005 Lisa Wells, SummIT FTA (2) FTA af Statechart modellenFTA af softwarearkitekturen

19. januar 2005 Lisa Wells, SummIT Hazard and Operability analysis HAZOP analyse er en systematisk undersøgelse af design repræsentationer til at identificere hazards forbundet til afvigelser fra design intentioner. HAZOP kan også anvendes på i alle udviklingsfaser  Passer godt med brug af UML Der mangler klare retningslinier for HAZOP på UML diagrammer. En ny systematisk metode for anvendelse af HAZOP på UML modeller blev udviklet. Entity = Class HAZOP Attribute Guide word Interpretation isActiveReverseThe class is active, even though it should not be, and vice versa. UML Attributes NoneThe class contains none of the necessary UML attributes. As well as The class contains all of the necessary UML attributes, as well as additional UML attributes. Part ofThe class contains some, but not all, of the necessary UML attributes.

19. januar 2005 Lisa Wells, SummIT Validering af softwarearkitektur prototype En eksekverbar software arkitektur prototype blev implementeret  Skelet klasser skrevet i Java Udfordring: sikre konsistens mellem arkitekturprototypen og safety kravspecifikationen (Statechart eller CPN model) Vigtige brugsscenarier (beskrevet som sekvensdiagrammer) blev implementeret i Java for at afprøve arkitekturprototypen.

19. januar 2005 Lisa Wells, SummIT Validering (2) Metoder i prototypen blev instrumenteret. Afbildning defineret mellem metoder i arkitekturprototypen og hændelser i CPN modellen af system kravspecifikationen. Når metoder i arkitekturprototypen bliver kaldt, sendes metodenavne til CPN modellen. Hvis metoderne svarer til en lovlige sekvens af hændelser i CPN modellen, bliver brugsscenariet valideret, ellers er der blevet fundet en fejl. Java-baseret eksekverbar softwarearkitektur prototype metodenavne OK/ikke OK

19. januar 2005 Lisa Wells, SummIT OO programmeringssprog og safety- kritisk software Ingen enighed mellem safety eksperter om hvornår OO sprog skal bruges  Aldrig  Til mindre kritiske projekter  Det afhænger af både projektet og programmørernes erfaring. Der er nogle retningslinier til brug af OO sprog, f.eks.  Undgå multipel nedarvning, overloading af metoder, død kode, og dynamisk allokering af hukommelse  Begræns brug af tråde  Undgå templates som øger kodekompleksitet Safe delmængder af OO sprog kunne defineres.

19. januar 2005 Lisa Wells, SummIT Konklusioner OO teknikker bliver brugt til udvikling af safety-kritisk software, om safety eksperterne anbefaler det eller ej. Velkendte safety analyse teknikker kan anvendes på OO software. Tid, erfaring, og en fokuseret indsats vil forbedre processerne og teknikkerne til udviklingen af objekt- orienteret safety-kritisk software.