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
- Aufwand pro Codezeile für funktional sichere Software
- Verwendung der Faktoren: bitte beachten
- Referenzen aus denen obige Daumenregeln abgeleitet sind
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
|
|---|---|---|
| 1 (Basis) | "Normale" Produktentwicklung | Funktion unter normalen Bedingungen
|
| 3 | Strukturierte Entwicklung | Wartbarkeit, Erweiterbarkeit, Qualität zusätzlich:
|
| 5 | Kritische Entwicklung
| Elementare funktionale Sicherheit zusätzlich:
|
| 7 | Hoch kritische Entwicklung
| Vollständige funktionale Sicherheit zusätzlich:
|
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
|
|---|---|---|
| 125..500 | Kritische Entwicklung
| Elementare funktionale Sicherheit |
| 400..2500 | Hoch kritische Entwicklung
| 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!
Autor
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.
Keine Kommentare