Funktionale Sicherheit: der Zusatzaufwand

Eine Produktentwicklung ist an sich schon teuer, nun sollen Sie zusätzlich für funktionale Sicherheit entwickeln. Es stapeln sich viele zusätzliche Schritte und Dokumente auf, siehe z.B. unsere Liste oder den umfassenden Blog-Beitrag.

Wie kann man den Aufwand für die Entwicklung solcher sicherheitskritischer Systeme abschätzen?  Es gibt wenig öffentlich zugängliche Informationen, was mir davon vernünftig scheint, habe ich zusammengetragen: Referenzen.

Mein Ziel war es, ein paar einfache Faktoren für grobe Abschätzungen von embedded Systemen (Software & Elektronik) zu entwickeln, welche sich leicht merken lassen. Die Faktoren sollten den Aufwand als Vielfaches des Aufwandes für ein Standard-Entwicklungsprojekt ausdrücken.

Die Faktoren finden Sie in dieserTabelle:

     

Praktischer  Faktor Qualitäts- & Sicherheitsniveau (Beispiele)

Ziele

  • Aktivitäten & Resultate
 
1 (Basis)

"Normale" Produktentwicklung

  • ISO 9001
  • CMMI Level 0/ 1
 

Funktion unter normalen Bedingungen

  • Produkt, z.B.
    • Elektronik (Herstelldaten)
    • Embedded Software (Code)
 
3

Strukturierte Entwicklung

  • CMMI Level 3
  • aSPICE Level 3
  • ISO 26262 QM
  • DO-178C DAL-E
 

Wartbarkeit, Erweiterbarkeit, Qualität

zusätzlich:

  • Dokumente:
    • Anforderungen
    • Designbeschreibung
    • Elementare Traceability der Anforderungen
  • Partielle Verifikation:
    • Reviews
    • Test
  • Konfigurations- & Änderungsmanagement
  • Prozessbeschreibungen
  • Eigene Standards
    • Anforderungen, Coding...
 
5

Kritische Entwicklung

  • ISO 26262 ASIL-B/ A
  • DO-178C DAL-D/ C
 

Elementare funktionale Sicherheit

zusätzlich:

  • Detaillierte Planung: Safety Pläne
  • Detaillierte Anforderungen
    • inkl. Traceability
  • Volle Verifikation:
    • Tests (inkl. Robustheit, Range...)
    • Code Coverage Analyse
    • Gründliche Code Reviews
    • Gründliche Reviews von Anforderungen & Tests
    • Qualitätssicherungs-Audits
  • Formales Änderungsmanagement
  • Normengerechte Dokumentation
    • Alle Design-Entscheide
    • Traceability zu Anforderungen
  • Sicherheitsanalysen
 
7

Hoch kritische Entwicklung

  • ISO 26262 ASIL-D
  • DO-178C DAL-B/ A
 

Vollständige funktionale Sicherheit

zusätzlich:

  • (semi-)formale Anforderungen
  • Eingehende Verifikation:
    • Mehr und tiefere Tests
    • Unabhängige Reviews
    • Vollständige Code Coverage Analyse
    • Umfassende Qualitätssicherungs-Audits
  • Volle Traceability der Anforderungen
  • Detaillierte Sicherheitsanalysen
 

Wie gesagt, diese Faktoren eignen sich nur für eine "über den Daumen" Abschätzung. Für eine genauere Abschätzung Ihres konkreten Projektes bieten wir unsere Schätzwerkzeuge oder kontaktieren SIe uns für einen Workshop.

Was ist nun der wichtigste Schluss aus diesen Zahlen, abgesehen von ihrem Gebrauch in groben Schätzungen? KISS! ...Keep It Simple. Jedes Feature multipliziert sich im Aufwand! Dieser lässt sich nur reduzieren, indem man möglichst viel unnötige Features weglässt...

Haben Sie andere Quellen, Zahlen oder Erfahrungen? Bitte schreiben Sie mir oder kommentieren Sie unten.

Andreas Stucki

Stichworte/ Tags

Keine Kommentare

Was ist Ihre Meinung?

Teilen auf

Referenzen

Die Referenzen als Tabelle dargestellt:

     

Qualitätsniveau

 Praktischer  Faktor (siehe oben) Faktoren gem. [1] Faktoren gem. [2] Faktoren gem. [2] Faktoren gem. [3] Faktoren gem. [3] Faktoren gem. [4] Faktoren gem. [4]
"Normale" Produktentwicklung Basis: 1 Basis: 1.0         Basis: 1.0 Basis: 2.0**
Strukturierte Entwicklung 3 3.2 Basis: 1.0 Basis: 3.0 Basis: 1.0 Basis: 2.5*    
Kritische Entwicklung 5 4.4 1.2 3.6 := 3.0 * 1.2 2.0..2.9 5.0..7.3 := 2.5 * (2.0..2.9) 1.5..4.0 3.0..8.0 := 2.0 * 1.5..4.0
Hoch kritische Entwicklung 7 5.7 1.7 5.1:= 3.0 * 1.7 4.4..6.4 11..16 := 2.5 * (4.4..4.6) 5.0..10.0+ 5.0..20.0 := 2.0 * 5.0..10.0

* Man beachte, dass die Basis für [3] CMMI Level 2/ 3 ist, ein tieferes Niveau als bei [1], wo von Level 3  ausgegangen wird; in [2] wird auch von Level 2/ 3 ausgegangen, die Zahlen sind jedoch näher bei [1]. Dadurch sind die Schritte zu den Sicherheitsniveaus bei [3] wohl eher zu hoch. Dies wurde in der Wahl dieser Basis korrigiert.

** Auch hier wurde die Basis angepasst, da "Functional System" im Kontext der Quelle (automotive)  wohl bereits einen aSPICE Level hat.

Und die dazugehörigen Links:

[1]  V. Hilderman: Calculate Critical Safety Cost Easy : (nur Aufwand, keine Werkzeugkosten einbezogen)

  • von "Basic Development" zu "Requirements, Design, Test" zu "Non-Certified Safety": plus 50% plus 50% plus 40% = 3.15
  • von "Non-Certified Safety" zu "DAL-D/ ASIL-B": plus 40% = 1.4
  • von  "DAL-D/ ASIL-B" zu "DAL-B/ ASIL-D": plus 30% = 1.3

[2] V. Hilderman: DO-178C Cost versus Benefits :

  • von"DAL-E" zu "DAL-D": plus 15% = 1.15
  • von  "DAL-D" zu "DAL-B": plus 35% plus 10% = 1.5

[3] Rockwell-Collins: Certification Cost Estimates for Future Communication Radio Platforms :

Bezieht sich auf "industry established metrics" (p 26) und "industry averages" (p 27) aus unbekannter Quelle und auf "Mentor Graphics" für Hardware (p 27).

  • p 27: gibt für DO-178B 75..150% mehr Aufwand als Hilderman ("25..40%") an, "presuming [..] CMMI Level 2 or 3 software engineering principles are used": von "Level 2/ 3" zu "DAL-D": plus 100..190% = 2.0..2.9
  • p 29: von "DAL-D" zu "DAL-B": plus 54% plus 43% = 2.2

[4] How the ISO 26262: 2018 Update Affects You: The Cost of ASIL Compliance :

"For example, to plan, execute, verify, and document compliance, the following effort multipliers could be considered:

Functional System : 1
ASIL A : 1.5x – 3x
ASIL B : 2x – 4x
ASIL C : 5x – 8x
ASIL D : 10x+"