Vad är RTCA DO-178C? och: Hur arbetar Saab med dessa krav? Lars Ljungberg, Saab AB, Avionics Systems

Transkript

1 Vad är RTCA DO-178C? och: Hur arbetar Saab med dessa krav? Lars Ljungberg, Saab AB, Avionics Systems

2 FUNCTONAL SAFETY DO-178C är processorienterad dentifiera risker (hazards) och de säkerhetsfunktioner som krävs. Designa system mha passande processer. Verifiera att systemet fungerar som tänkt. Skaffa objektiva bevis.

3 Vad är RTCA DO-178C? Har tagits fram av en kommitté av myndigheterna och industrin. Krävs för kommersiella flygplan i USA och Europa. FAA och EASA säger att den är ett sätt att uppfylla kraven. Täcker hela framtagningen av programvara: Planering Utveckling Verifiering Certifiering (civilt; FAA och EASA)

4 RTCA DO-178C FLOSOF n God we trust.all others bring data Underliggande filosofi: Programvaran fungerar inte om vi inte visat något annat. Du måste skapa bevis på att programvaran fungerar. RTCA DO-178C tillhandahåller ett strukturerat sätt att göra detta. Edwards Deming - Father of the Japanese post-war industrial revival and quality guru RTCA DO-178C definierar ingen utvecklingsprocess. Processen måste instansieras genom planerna.

5 Grunden i DO-178 Det bästa sättet att få en säker programvara är att göra den så enkel som möjligt Med enkelhet kommer predikterbarhet, lätt att underhålla (det man förstår kan man ändra utan större risker), lätt att verifiera etc. KSS! Keep t Simple, Stupid!

6 Processen Planering Krav Design Kod ntegrering Erfarenhet visar att man får högre kvalitet med en bra process. Dessutom lättare att: underhålla. visa att all kod som finns med har ett syfte och används. visa att vi har verifierat all kod.

7 Stegen mellan delprocesserna DO-178 finns krav på att vi ska bedöma om vi får börja en viss delprocess. Vi måste veta att output är tillräckligt mogen innan vi går vidare till nästa steg, att vi vet tillräckligt om åtminstone delar av funktioner. Men: det finns inga krav på hur dessa transitions ska se ut! Kravet är att vi ska bedöma om vi har tillräckligt för att börja en viss fas. VÄG RSKER MOT FÖRDELAR!

8 Mer om övergångar Om man påbörjar ett steg innan föregående är definierat så introducerar man fel som är mycket svåra att bli av med Alltså: producera NTE output UTAN definierat input! DO-178 har inget krav på vattenfall! Kravet är: Definierade kriterier för start av nästa steg. Avsluta stegen i rätt ordning (sätt upp kriterier även här).

9 Oberoende För bland annat verifieringar och granskningar så ska det vara någon annan som kollar det jag gjort. Man blir hemmablind! Jag vet ju vad jag menade, även om jag skrev något annat Dessutom måste någon säkra att vi gör som vi sagt att vi ska göra. Dvs att vi följer planerna = QA. princip: en skriver, en granskar och en övervakar; 3 personer behövs.

10 Spårbarhet Krav måste vara spårbara ner till kod och till verifiering. Vi måste kunna visa att alla ovanliggande krav (systemkrav, systemdesign, säkerhetskrav) är implementerade och verifierade. Dessutom: vid ändringar av fastställt underlag måste vi ha spårbarhet MELLAN baselines! Vi måste kunna visa full spårbarhet för verifieringsbevis även i en miljö där vi tillåter och implementerar ändringar.

11 nnan sluttest Observera att vi måste veta HUR vi testat, miljön är också viktig! Glöm inte att provköra alla tester NNAN vi kör sluttest! Fel kommer man säkert att hitta men på detta sätt kan vi förbereda oss; kan vi acceptera avvikelserna, är det fel på testerna själva eller måste vi åtgärda koden?

12 Efter leverans Alla ändringar måste baseras på formella beslut, normalt av CCB. Det finns exempel på att man ändrat ett kommatecken till en punkt vilket lett till att ett flygplan kraschade! Detta var en icke godkänd ändring. Vi måste även efter år kunna visa att vi gjort vad vi kunnat för att verifiera vår produkt om det händer en incident, dvs vi måste vara noggranna med baselines både av kod och miljö.

13 Saab s Vision t s a human right to feel safe! 13

14 Exempel på produkter DAL A, B och C

15 Avionics Systems utvecklingsprocess

16 PSAC DO-178C OBJECTVES D System Requirements DAL SDP SVP Requirement Coverage Analysis Statement of compliance SAS High-level Requirements req. SW Architecture Specification Source Code Source Code Result Executable Object Code (Executable Object Code) Target Hardware = traceability DAL D 16

17 DO-178C OBJECTVES C Statement of compliance PSAC System Requirements DAL SDP SVP Requirement Coverage Analysis SAS + Statement + SW Coupling Req. Std High-level Requirements req. Des. Std Code Std SW Architecture Low-level Requirements Source Code req. Specification Source Code Result Analysis Executable Object Code (Executable Object Code) Target Hardware = traceability Std = standard DAL D DAL C 17

18 DO-178C OBJECTVES B Statement of compliance PSAC System Requirements DAL SDP SVP SAS Requirement + Statement Coverage Analysis + Decision + SW Coupling Req. Std High-level Requirements req. Des. Std Code Std SW Architecture Low-level Requirements Source Code req. Specification Source Code Result Analysis Executable Object Code (Executable Object Code) Target Hardware = traceability Std = standard DAL D DAL C DAL B = independency 18

19 DO-178C OBJECTVES A Statement of compliance PSAC System Requirements DAL SDP SVP SAS Requirement + Statement Coverage Analysis + Decision + SW Coupling + MC/DC Req. Std High-level Requirements req. Des. Std Code Std SW Architecture Low-level Requirements Source Code Executable Object Code req. Specification Source Code (Executable Object Code) Target Hardware Analysis Result = traceability Std = standard DAL D DAL C DAL B DAL A = independency 19

20 SW Development Environment CM Tool -Dimensions Requirements Tool -DOORS Simulation Tool -Matlab, Simulink Design Tool -Visio, Rhapsody, SCADE Code Editor -Eclipse, Notepad++ Static Code Analyser -Lint, C++ Build Tools -Compiler / Assembler / Linker / Debugger Exec environment -Target / Simulator Tool -Cantata++

21 Verktyg: Dimensions Stöder den krävda nivån på Configuration Management som: Unik identifering av delarna Versionskontroll och baselines Problemrapportering, spårning och lösningshantering Ändringskontroll för att skydda produkterna och baselines Olika roller som Designer, Verifier, er, etc. ger mekanismer för att Skydda mot inte tillåtna ändringar Visa oberoende

22 Verktyg: DOORS Kravhanteringsverktyg inklusive spårbarhet För spårbarhet och analyser av vad som påverkas Länkar krav till högre nivå av krav (och tvärtom) Länkar testfall till krav Länkar testresultat till testfall

23 Verktyg: CANTATA++ Tillhandahåller ett testramverk (förenklar testning) Verktyg för Structural coverage Mäter om all kod blir exekverad under test

24 Kombinera med iterativ utveckling

25 Återanvändning som vi tänkt oss

26 Slutligen! Använd NGENJÖRSKUNSKAP och NDUSTRELL ERFARENHET och skapa ENKLA LÖSNNGAR så kommer vi långt! Se till att ha BEVS på att vi följt de olika kraven i RTCA (objective evidence) Dessutom: Enligt DO-178/254 är du SKYLDG tills motsatsen bevisats!

27