Vad är RTCA DO-178C?sesam.smart-lab.se/seminarier/sem180522/LLSaab.pdf · Avionics Systems utvecklingsprocess. 16 DO-178C OBJECTIVES D High-level Requirements ... System Requirements

Vad är RTCA DO-178C?och:

Hur arbetar Saab med dessa krav?

Lars Ljungberg, Saab AB, Avionics Systems

2018-05-07

FUNCTIONAL SAFETY

DO-178C är processorienterad

Identifiera risker (hazards) och de säkerhets-

funktioner som krävs.

Designa system mha passande processer.

Verifiera att systemet fungerar som tänkt.

Skaffa objektiva bevis.

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)

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.

RTCA DO-178C definierar ingen utvecklingsprocess.

Processen måste instansieras genom planerna.

“In God we trust….all

others bring data”

Edwards Deming - Father of

the Japanese post-war

industrial revival and “quality

guru”

RTCA DO-178C FILOSOFI

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.

KISS! Keep It Simple, Stupid!

Processen

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.

Krav

Design

Kod

Integrering

Test

Planering

Stegen mellan delprocesserna

I 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 RISKER MOT FÖRDELAR!

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 INTE 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).

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.

I princip: en skriver, en granskar och en övervakar; 3 personer behövs.

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.

Innan sluttest

Observera att vi måste veta HUR vi testat, miljön är också viktig!

Glöm inte att provköra alla tester INNAN 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?

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 20-40 å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ö.

Saab´s Vision

13

“It´s a human right

to feel safe!”

Exempel på produkter

DAL A, B och C

Avionics Systems utvecklingsprocess

16

DO-178C OBJECTIVES D

High-level

Requirements

Source Code

Test

Specification

Test

(Executable Object Code)Executable Object Code

System

Requirements

Requirement

Coverage Analysis

Target

Hardware

SDP

SVP

DALSAS

Statement of

compliance

DAL D

SW

Architecture

=

traceability

Test

Source Code

Test

Result

Test req.Review

Review

PSAC

17

DO-178C OBJECTIVES C

High-level

Requirements

Low-level

Requirements

Source Code

Review

Test

Specification

Test

(Executable Object Code)Executable Object Code

System

Requirements

Requirement

Coverage Analysis

SDP

SVP

DALSAS

Statement of

compliance

+ Statement

DAL D DAL C

Code

Std

Req.

Std

Std =

standard

SW

Architecture

=

traceability

Des.

Std

Review

Review

Test

Source Code

Test

Result

+ SW Coupling

Analysis

Review

Review

Test req.

Test req.

Review

Review

Review

Review

Review

Review

Target

Hardware

PSAC

18

DO-178C OBJECTIVES B

High-level

Requirements

Low-level

Requirements

Source Code

Review

Test

Specification

Test

(Executable Object Code)Executable Object Code

System

Requirements

Requirement

Coverage Analysis

SDP

SVP

DALSAS

Statement of

compliance

+ Statement

DAL D DAL C DAL B I =

independency

Code

Std

Req.

Std

Std =

standard

SW

Architecture

=

traceability

Des.

Std

Review

Review

Test

Source Code

Test

Result

+ SW Coupling

Analysis

+ Decision

Review

Review

I

I

I

Test req.

Test req.I

Review

I

ReviewI

Review

ReviewI

ReviewI

ReviewI

Target

Hardware

PSAC

19

DO-178C OBJECTIVES A

High-level

Requirements

Low-level

Requirements

Source Code

Review

Test

Specification

Test

(Executable Object Code)Executable Object Code

System

Requirements

Requirement

Coverage Analysis

Review

SDP

SVP

DALSAS

Statement of

compliance

+ Statement

DAL D DAL C DAL B

I

I

I =

independency

Code

Std

Req.

Std

Std =

standard

SW

Architecture

=

traceability

Des.

Std

ReviewI

ReviewI

Test

Source Code

Test

Result

+ SW Coupling

Analysis

+ Decision

Review

Review

DAL A

I

I

+ MC/DCI

I

I

I

Test req.

Test req.I

ReviewI

I

ReviewI

ReviewI

ReviewI

ReviewI

ReviewI

I

Target

Hardware

PSAC

CM Tool -Dimensions

Requirements Tool -DOORS

Simulation Tool -Matlab, Simulink

Design Tool -Visio, Rhapsody, SCADE

Code Editor -Eclipse, Notepad++

Static Code Analyser -Lint, C++Test

Build Tools -Compiler / Assembler / Linker / Debugger

Exec environment -Target / Simulator

Test Tool -Cantata++

SW Development Environment

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, Reviewer, etc. ger mekanismer för att

• Skydda mot inte tillåtna ändringar

• Visa oberoende

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

Verktyg: CANTATA++

Tillhandahåller ett testramverk (förenklar testning)

Verktyg för Structural coverage

• Mäter om all kod blir exekverad under test

Kombinera med iterativ utveckling

Återanvändning som vi tänkt oss

Slutligen!

Använd INGENJÖRSKUNSKAP och INDUSTRIELL ERFARENHET

och skapa ENKLA LÖSNINGAR så kommer vi långt!

Se till att ha BEVIS på att vi följt de olika kraven i RTCA (objective evidence)

Dessutom:

Enligt DO-178/254 är du SKYLDIG tills motsatsen bevisats!