Steinturm am Strand

Symbolbild: Engineering/ F&E kritischer Systeme für funktionale Sicherheit (Safety) und Cybersicherheit (Security) Was ist der Entwicklungs-Aufwand für funktionale Sicherheit?

Lesezeit 3 min

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 Entwicklungs-Aufwand sicherheitskritischer Systeme abschätzen? Es gibt wenig öffentlich zugängliche Informationen, was mir davon vernünftig scheint, habe ich zusammengetragen und aufbereitet:

Zusatzaufwand gegenüber "normaler" Entwicklung: Faktoren

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

Funktion unter normalen Bedingungen

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

Strukturierte Entwicklung

  • CMMI Level 3 (definiert)
  • aSPICE Level 3 (etabliert)
  • ISO 26262 QM
  • DO-178C DAL-E
  • ISO 13849 PL a

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-A/ B
  • DO-178C DAL-D/ C
  • IEC 61508 SIL-1/ 2
  • ISO 13849 PL b/ c/ d

Elementare funktionale Sicherheit

zusätzlich:

  • Detaillierte Planung: Safety Pläne
  • Detaillierte Anforderungen
    • inkl. Traceability
  • Qualifikation der Software-Werkzeuge (Tool Qualification)
  • 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-C (?)/ D
  • DO-178C DAL-B/ A
  • IEC 61508 SIL-3/ 4
  • ISO 13849 PL e (?)

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

Aufwand pro Codezeile für funktional sichere Software

Codezeilen  (LOC: Line Of Code) sind ein verbreitetes, wenn auch nicht sehr genaues Mass für den Umfang eines Softwareprojektes. LOC für unterschiedliche Programmiersprachen sind ein noch schlechteres Mass für Softwareprojekte. Da jedoch die meisten funktional sicheren Projekte in C implementiert werden, sind die Zahlen zumindest insofern vergleichbar.

Die Tabelle zeigt, mit welchem Aufwand pro Codezeile über den Daumen gerechnet werden kann, um eine Grössenordnung für funktional sichere Softwareprojekte zu implementieren.

Beachten Sie, dass fast der gleiche Aufwand zu erwarten ist, um eine bestehende Software "sicher zu machen", da sich aus den Sicherheitsanforderungen in der Regel ein tiefgreifendes Refactoring der Software ergibt.

Die Grössenordnungen für die Aufwände finden Sie in dieser Tabelle (wo im Bereich Ihr Projekt liegt, hängt vor allem von seiner Komplexität ab. Signalverarbeitungs-Code z.B. erreicht oder überschreitet schnell den jeweiligen oberen Aufwand!):

Aufwand
Ph/ kLOC
Qualitäts- & Sicherheitsniveau (Beispiele)

Ziele

  • Aktivitäten & Resultate wie oben
125..500

Kritische Entwicklung

  • ISO 26262 ASIL-A/ B
  • DO-178C DAL-D/ C
  • IEC 61508 SIL-1/ 2
  • ISO 13849 PL b/ c/ d

Elementare funktionale Sicherheit

400..2500

Hoch kritische Entwicklung

  • ISO 26262 ASIL-C (?)/ D
  • DO-178C DAL-B/ A
  • IEC 61508 SIL-3/ 4
  • ISO 13849 PL e (?)

Vollständige funktionale Sicherheit

Ph/ kLOC: Personenstunden/ Tausend Codezeilen

Für ganz grobe erste Abschätzungen lässt sich die einfache Rate 1 Ph/ LOC (eine Stunde pro Codezeile) verwenden.

Verwendung der Faktoren: bitte beachten

  • Für sehr kleine und sehr komplexe Projekte wird der Aufwand höher sein.
    Für die erste Kategorie, weil der Overhead der gesamten Dokumentation relativ höher ist, für die zweite, weil die Komplexität den Aufwand bestimmt.
  • Für Projekte mit nur wenig sicherer Funktionalität ("einfache Sicherheitsfunktionen") sind die Faktoren eher zu optimistisch.
    Dies, da der Aufwand für die Implementation von z.B. Sicherheitsmechanismen für Hardwarefehler und auch der gesamte Aufwand für Prozesse und Dokumentation proportional grösser wird gegenüber der eigentlichen Grundfunktion. In einem "normalen Projekt" würde ja nur diese Grundfunktion implementiert.
  • Die Faktoren gelten natürlich nur für den funktional sicheren Teil eines Projektes. Wenn immer möglich sollten die Sicherheitsfunktionen vom Rest sicher getrennt ("Isolation", "Freedom from Interference") werden, damit nicht die Aufwände nicht über das ganze Produkt auflaufen. Ausser natürlich, wenn das ganze Produkt eine Sicherheitsfunktion ausführt, z.B. ein FADEC in der Luftfahrt oder ein Sensor für eine automatische Fahrfunktion.

Wie gesagt, diese Zahlen 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...

Andreas Stucki

Haben Sie andere Quellen, Zahlen oder Erfahrungen? Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!

Möchten Sie von unserem Wissen profitieren? Besuchen Sie unsere Kontaktseite!

Autor

Kommentare

Keine Kommentare

Was ist Ihre Meinung?

* Diese Felder sind erforderlich

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] Faktoren gem. [5]*** Faktoren gem. [5]
"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 0.125..0.5 Basis: 5.0 ^= 0.25****
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 0.4..2.5 8..50
:= 20 * 0.4..2.5

* 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.

*** Ph/ LOC

**** geometrischer Mittelwert

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+"

[5] Cost of highly safety critical software

"DAL A: 3..12 SLOC/ day
DAL B: 8..20 SLOC/ day
DAL C: 15..40 SLOC/ day
DAL D: 25..64 SLOC/ day"

SLOC: Source Line Of Code

Das ergibt für DAL A/ B: 0.4..2.5 LOC/ h und für DAL C/ D: 2..8 LOC/ h.

[6] Coverity: Risk Mitigation for DO-178C

"In typical cases, the cost of DO-178 certification can range from $25 to $100 per line of code—
that’s $2.5 million to $10 million for 100,000 lines of code!" (p 1) ergibt bei einem Stundensatz von 50 USD: 0.5..2 LOC/ h.

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren