Safety Event Dennis van Loon Adviseur en Functional Safety D&F Consulting FS Eng (TÜV Rheinland, #9013/14, Machinery)

Transcriptie

1 Voettekst

2 Gestructureerd software ontwerpproces is essentieel! IF (fail_safe_software == 100% foutloos) THEN CLAIM_SIL_OR_PL = true, ELSE CLAIM_SIL_OR_PL = false, END IF Dennis van Loon Adviseur en Functional Safety D&F Consulting FS Eng (TÜV Rheinland, #9013/14, Machinery)

3 INTRODUCTIE Wat ziet u hier?

4 INTRODUCTIE Wat ziet u hier? On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. The failure of the Ariane 501 was caused by the complete loss of guidance and altitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system. The internal software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer.

5 INTRODUCTIE Even bij het begin beginnen Voorbeeld veiligheidsfuncties:

6 INTRODUCTIE Even bij het begin beginnen Functional Safety Plan 02 Specificatie (SRS) 06 Validatie 01 Risicobeoordeling 03 Systeemontwerp 05 Testen Hoofd proces 04 Realisatie Verificatie Validatie

7 V-MODEL (SOFTWARE) VOLGENS PL-NORM SSRS Software Safety Requirements Specification

8 SOFTWARE - een aantal statistieken Standaard software heeft 25 fouten per 1000 regels. Goed geschreven software heeft 2 á 3 fouten per 1000 regels. De NASA heeft 1 fout per regels. Mobiele telefoon regels met 500 fouten. Windows 27 miljoen regels met fouten. Space shuttle 3 miljoen regels met 300 fouten. Bananensoftware (rijpt bij de klant). (bron: Kleine BUGs, groβe GAUs, prof Thomas Huckle 2003)

9 SOFTWARE - een aantal statistieken (bron: Defects per function point of excellent, average and poor software according to the origins of the faults [Jones 2008])

10 SOFTWARE - een aantal statistieken De meeste softwareproblemen worden veroorzaakt door fouten gedurende het ontwerp en de ontwikkeling. Testen is doorgaans niet voldoende om de correcte werking van software te garanderen. Software zal niet slijten. Soms wordt software zelfs beter met de tijd omdat latente fouten worden opgelost. Dit effect wordt meestal teniet gedaan door het feit dat met software wijzigingen weer fouten worden geintroduceerd. In tegenstelling tot sommige hardware fouten is er voor software fouten geen waarschuwing vooraf. Latente fouten kunnen lang nadat de software in gebruik is genomen nog optreden. (bron: General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA, January 11, 2002)

11 SOFTWARE - een aantal statistieken Een op het oog kleine wijziging in software kan onverwacht grote problemen veroorzaken. Herbruikbare software vraagt veel aandacht tijdens de integratie. Een duidelijke definitie en documentatie is belangrijk om de werking van de softwaremodule volledig te begrijpen. (bron: General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA, January 11, 2002)

12 DEFINITIES LVL FVL Limited Variability Software. Ladderdiagram, SFC, function block diagram Full Variability Software. Instruction list, Structured text, C, java etc SRASW Safety Related Application Software. SRESW Safety Related Embedded Software.

13 SOFTWARE IN SIL EN PL NORMEN SRESW SRASW in FVL EN-IEC EN-ISO EN-IEC SRASW in LVL EN-IEC EN-ISO

14 DOEL Ontwikkel software op een systematische manier (V-model) Maak software: Leesbaar Begrijpelijk Te testen Te onderhouden

15 SOFTWARE - Algemeen Gebruik het V-model (development lifecycle) Documenteer specificatie en ontwerp Programmeer modulair en gestructureerd Voer functionele testen uit Voer passende ontwerpacties uit na een wijziging Alle lifecycle (incl. modificatie) activiteiten moeten worden gedocumenteerd, documentatie moet compleet, beschikbaar, leesbaar en begrijpelijk zijn. Het is belangrijk om aan te tonen dat de software goed genoeg is voor het vereiste PL/SIL level. PL: g1, g2 SIL:

16 SOFTWARE Configuratie Management De strategie voor het ontwikkelen, integreren, verificatie en validatie van software moet opgenomen worden in het Functional Safety Plan Configuratie management is een middel om te borgen dat alle stappen zijn doorlopen PL: g1, g2 SIL:

17 SOFTWARE Configuratie Management Documenten die onder CM worden geplaatst: risicobeoordeling; specificatie- en ontwerpdocumenten van de software; source code; testplannen en resultaten; bestaande softwaremodules en -pakketten die moeten worden geïntegreerd in de veiligheidsbesturing; hulpmiddelen etc. PL: g1, g2 SIL:

18 SOFTWARE Configuratie Management Voor wijzigingen is autorisatie nodig! Pas een wijzingsprocedure toe om: ongeautoriseerde wijzigingen te voorkomen; de wijzigingsverzoeken vast te leggen; te verzekeren dat er een impactanalyse wordt uitgevoerd; de details van en de autorisatie voor alle goedgekeurde wijzigingen vast te leggen; de architectuur van de software vast te leggen (actueel te houden). PL: g1, g2 SIL:

19 SOFTWARE Keuze van een programmeertaal Gebruik voor applicatiesoftware een LVL programmeertaal. De complexiteit moet beperkt worden (modulariteit). Gevalideerde functieblokbibliotheken van de leverancier. Als bestaande modules worden gebruikt, is het belangrijk dat deze aantoonbaar geschikt en betrouwbaar genoeg zijn voor de toepassing. (al eerder geverifieerd en gevalideerd?). PL: B2; B3 SIL: ; a; ; ;

20 SOFTWARE Keuze van een programmeertaal Compiler eisen: geschikt voor de toepassing; compleet en eenduidig gedefinieerd; past bij de applicatie eisen (PL/SIL level); kan programmeerfouten detecteren; past bij de ontwerpmethode. PL: B2; B3 SIL: ; a; ; ;

21 SOFTWARE Specificatie (PL) Safety Related Software Specification (SIL) Software Safety Requirements Specification Een specificatie van de veiligheidseisen voor de software moet worden ontwikkeld en vastgelegd. Gebruik daarbij de specificatie van de veiligheidsfunctie (SRS) als bron, houd hierbij ook rekening met de eisen in verband met de hardware architectuur en de eisen uit het Functional Safety Plan. Zorg voor voldoende detailniveau zodat het verdere ontwerp van de software met de vereiste betrouwbaarheid kan worden uitgevoerd. Ook moet de specificatie te verifiëren zijn. PL: 4.6.1; SIL: ; ;

22 SOFTWARE Specificatie Operating modes zoals beschreven in de SRS Performance eisen zoals reactietijden, capaciteit Configuratie, architectuur en (externe) interfaces Fout detectie en foutreactie in sensoren, logica en actuatoren en software zelf Interfaces naar niet veilige functies Definieer activatie en de-activatie van functies PL: a1; a2; a3; a4 SIL: ;

23 SOFTWARE Systeemontwerp Kies een ontwerpmethode en ontwikkel software op een gestructureerde manier. Verdeel in modules waar mogelijk (bij voorkeur met gevalideerde functieblokken). Doel: Verbeterde testbaarheid Eventuele wijzigingen zijn op een veilige manier door te voeren Andere personen kunnen het ontwerp begrijpen PL: c2 SIL: ; a; c

24 SOFTWARE Module ontwerp Beschrijf het ontwerp van elk functieblok en alle tests die moeten worden uitgevoerd Gebruik functieblokken met één entry en één exit point Gebruik een drietrappen architectuur: input processing output ( IO mapping) Gebruik technieken voor detectie van externe fouten en programmeer defensief! PL: c3; c4; c5; c7 SIL: ;

25 SOFTWARE Programmeren Gebruik de eerder gespecificeerde tools. Code moet leesbaar, begrijpelijk en te testen zijn. Gebruik symbolische variabelen (en geen hardware adressen). Schrijf (write) een safety output maar op één plek in het programma. Gebruik coding guidelines. PL: b1, c6, e1, e2 SIL:

26 SOFTWARE Programmeren Implementeer controles op de data-integriteit en plausibiliteit (zoals range checks op ingangen of parameters) Programmeer defensief Pas control en data flow analyse toe, tenzij de embedded software (leverancier afhankelijk) dit al doet Test code door simulatie PL: d1, d2 SIL:

27 SOFTWARE Programmeren Veilige en niet-veilige software Veiligheidsgerelateerde software en niet-veiligheidsgerelateerde software worden in verschillende functieblokken geprogrammeerd waarbij de dataverbindingen worden gedefinieerd. Een combinatie van wel en niet veiligheidsgerelateerde data mag er nooit voor zorgen dat het veiligheidsniveau wordt verlaagd. PL: e3,e4,e5 SIL: ;

28 SOFTWARE Programmeren Veilige en niet-veilige software Een logische OR tussen veilig en niet veilig mag nooit een veiligheidsrerelateerde uitgang of signaal beïnvloeden. Als er niet genoeg onafhankelijkheid is (of kan worden aangetoond) tussen veilige en niet veilige software dan moet alle software als veiligheidsgerelateerd worden behandeld! PL: e3,e4,e5 SIL: ;

29 SOFTWARE Voorbeeld 1 (waar gaat het mis?) SOFTWARE Voorbeeld Modulariteit Testbaar

30 SOFTWARE Voorbeeld 2 (waar gaat het mis?) Modulariteit? Outputs op 2 plaatsen geschreven Geen symbolische variabelen

31 SOFTWARE Voorbeeld 3

32 SOFTWARE Verificatie Naast testen wordt software ook geverifieerd door technieken als inspectie, analyse en walkthrough. Verifieer dat de gerealiseerde software in overeenstemming is met de specificatie. Laat verificatie door een persoon uitvoeren welke niet bij het ontwerp betrokken is Verificatiemethoden zijn geheel afhankelijk van systeemontwerp. Verificatieplan gebruiken dat in FSP is opgenomen PL: H SIL:

33 SOFTWARE Verificatie voorbeelden

34 SOFTWARE Verificatie voorbeelden

35 SOFTWARE Verificatie voorbeelden

36 SOFTWARE Module- en integratietesten Testplannen worden gebaseerd op het systeem en module ontwerp (zie rode pijlen) Na de individuele modules wordt het gehele systeem (integratie) getest Test functioneel gedrag en performance door black-box testen I/O testen moeten verzekeren dat de signalen correct worden verwerkt. Testcases die fouten simuleren (vooraf door analyse te bepalen) en de verwachtte reactie/afhandeling van de fouten met als doel aantonen dat de maatregelen adequaat zijn. PL: f1,f2,f3,f5;

37 SOFTWARE Validatie Controleer alle testrapporten Individuele softwarefuncties (functieblokken) die al zijn gevalideerd hoeven niet opnieuw te worden gevalideerd. Als een vhf wordt opgebouwd uit gevalideerde functieblokken moet de totale VHF wel worden gevalideerd Controleer dat, om systematische fouten te voorkomen, voldoende maatregelen en activiteiten (volgens het V-model) zijn geimplementeerd. Controleer of de maatregelen uit (SRASW) juist zijn toegepast Should the safety related software be subsequently modified, it shall be revalidated on an appropriate scale PL:

38 Vragen? While (VRAGEN?) { Beantwoorden(); } Cout<< Bedankt voor uw aandacht! ;

39