Voettekst
Safety Event 2015 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 Engineer @ D&F Consulting FS Eng (TÜV Rheinland, #9013/14, Machinery)
Safety Event 2015
INTRODUCTIE – Wat ziet u hier?
Safety Event 2015
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.
Safety Event 2015
INTRODUCTIE – Even bij het begin beginnen Voorbeeld veiligheidsfuncties:
Safety Event 2015
INTRODUCTIE – Even bij het begin beginnen Functional Safety Plan
02
06
Specificatie (SRS)
01
Risicobeoordeling
Validatie
03
05
Systeemontwerp
Testen
Hoofd proces
04
Realisatie
Verificatie Validatie
Safety Event 2015
V-MODEL (SOFTWARE) VOLGENS PL-NORM
SSRS
Software Safety Requirements Specification
Safety Event 2015
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 10.000 regels. • Mobiele telefoon 200.000 regels met 500 fouten. • Windows 27 miljoen regels met 50.000 fouten. • Space shuttle 3 miljoen regels met 300 fouten. • Bananensoftware (rijpt bij de klant).
(bron: Kleine BUGs, groβe GAUs, prof Thomas Huckle 2003)
Safety Event 2015
SOFTWARE - een aantal statistieken
(bron: Defects per function point of excellent, average and poor software according to the origins of the faults [Jones 2008])
Safety Event 2015
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)
Safety Event 2015
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)
Safety Event 2015
DEFINITIES LVL
Limited Variability Software. Ladderdiagram, SFC, function block diagram
FVL
Full Variability Software. Instruction list, Structured text, C, java etc
SRASW Safety Related Application Software. SRESW Safety Related Embedded Software.
Safety Event 2015
SOFTWARE IN SIL EN PL NORMEN
SRESW
SRASW in FVL
SRASW in LVL
Safety Event 2015
EN-IEC 62061 §6.11.1 EN-IEC 61508 -3 EN-ISO 138491 §4.6.2 EN-IEC 62061 §6.11.3 EN-ISO 138491 §4.6.3
DOEL Ontwikkel software op een systematische manier (V-model)
Maak software: • Leesbaar • Begrijpelijk • Te testen • Te onderhouden
Safety Event 2015
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: 4.6.3. g1, g2 SIL: 6.11.3.2 Safety Event 2015
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: 4.6.3. g1, g2 SIL: 6.11.3.2 Safety Event 2015
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: 4.6.3. g1, g2 SIL: 6.11.3.2 Safety Event 2015
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: 4.6.3. g1, g2 SIL: 6.11.3.2 Safety Event 2015
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: 4.6.3.B2; B3 SIL: 6.11.3.1.1.; 6.11.3.1.3.a; 6.11.3.1.8; 6.11.3.4.2; 6.11.3.4.4 Safety Event 2015
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: 4.6.3.B2; B3 SIL: 6.11.3.1.1.; 6.11.3.1.3.a; 6.11.3.1.8; 6.11.3.4.2; 6.11.3.4.4 Safety Event 2015
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; 4.6.2 SIL: 6.10.1; 6.10.2.2 ; 6.10.2.3
Safety Event 2015
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: 6.4.3 a1; a2; a3; a4 SIL: 6.10.2.4; 6.10.2.6 Safety Event 2015
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: 6.4.3. c2 SIL: 6.11.3.5.2; 6.11.3.1.3a; 6.11.3.1.c Safety Event 2015
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: 6.4.3 c3; c4; c5; c7 SIL: 6.11.3.5.3; 6.11.3.5.4 Safety Event 2015
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: 4.6.3 b1, c6, e1, e2 SIL: 6.11.3.6.1 Safety Event 2015
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: 4.6.3 d1, d2 SIL: 6.11.3.1.5 Safety Event 2015
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: 4.6.3 e3,e4,e5 SIL: 6.11.3.1.6; 6.11.3.1.7 Safety Event 2015
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: 4.6.3 e3,e4,e5 SIL: 6.11.3.1.6; 6.11.3.1.7 Safety Event 2015
SOFTWARE – Voorbeeld 1 (waar gaat het mis?)
SOFTWARE – Voorbeeld • •
Safety Event 2015
Modulariteit Testbaar
SOFTWARE – Voorbeeld 2 (waar gaat het mis?)
• • •
Safety Event 2015
Modulariteit? Outputs op 2 plaatsen geschreven Geen symbolische variabelen
SOFTWARE – Voorbeeld 3
Safety Event 2015
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: 4.6.3 H SIL: 6.11.3.6.2 Safety Event 2015
SOFTWARE – Verificatie voorbeelden
Safety Event 2015
SOFTWARE – Verificatie voorbeelden
Safety Event 2015
SOFTWARE – Verificatie voorbeelden
Safety Event 2015
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: 4.6.3 f1,f2,f3,f5; 13849-2 9.5
Safety Event 2015
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 4.6.3. (SRASW) juist zijn toegepast “Should the safety related software be subsequently modified, it shall be revalidated on an appropriate scale” PL: 13849-2 9.5
Safety Event 2015
Vragen ?
While (VRAGEN?) { Beantwoorden(); } Cout<<“Bedankt voor uw aandacht!”;
Safety Event 2015
