Sieben Bausteine der Realisierungsphase
Innerhalb der Realisierungsphase findet die eigentliche Produktentwicklung statt, an deren Ende das fertige Produkt steht. Die Realisierung unterteilt sich klassischerweise in die folgenden, aufeinander aufbauenden Unterphasen und die entsprechend dazugehörige Dokumentation:
1. Spezifikation der Anforderungen an den Entwurf: Nützliches Hilfsmittel aus dem Konzept: Das Blockschaltbild – es zeigt die zeitunabhängige Struktur der Schaltung und erleichtert die Synthese und Analyse komplexer Schaltungen. Zusätzlich werden die möglichen Wege eines Signals durch die Schaltung visualisiert. Der Entwickler hat so die Chance, mögliche Schwachstellen und Fehlerquellen im System frühzeitig zu entdecken – und schon in der Designphase auszumerzen. Und: Blockschaltbilder haben eine wichtige Funktion als Abstraktionsebene. Denn sie sind so anschaulich, dass sich Hardware- und Softwareentwickler auf dieser Basis austauschen können – ohne dass der eine coden und der andere Schaltpläne lesen kann.
2. Planung der Validierung: Hier werden alle Test-Cases erstellt, um die Typprüfung des Produktes abzuwickeln. Innerhalb der Realisierungsphase spielt die Anforderungsverfolgung eine tragende Rolle, damit über die Umsetzung und den Test nachgewiesen werden kann, dass jede Anforderung berücksichtigt und deren korrekte Funktion am Ende nachgewiesen wurde. Darin unterscheidet sich das FuSi-Projekt von keinem anderen Entwicklungsprojekt. Die hier jedoch explizit geforderte Verfolgbarkeit in beide Richtungen dient ebenfalls der systematischen Fehlervermeidung.
3. Entwurf und Entwicklung: Für den Entwurf ist wichtig, dass dieser strukturiert erfolgt und in Modulen abgewickelt werden kann – auch um das Testen zu vereinfachen. Außerdem wird dadurch die Wiederverwendbarkeit in späteren bzw. anderen Projekten ermöglicht. Die Simulation ist ein wichtiges Verfahren in dieser Phase. Das Modifikations- und Konfigurationsmanagement wird hier an den Start gerufen.
4. Integration: Auch die hier durchzuführenden Funktions- und Black-Box-Tests müssen geplant werden. Vom Modul bis zum Verbund werden hier die alle Komponenten auf die korrekte Funktionsweise getestet und das Ergebnis über einen finalen Bericht dokumentiert.
5. Installations-, Inbetriebnahme-, Betriebs- und Instandhaltungsverfahren: Neben allen technischen und konstruktiven Maßnahmen muss der Anwender natürlich auch auf Restrisiken und die richtige Verwendung des Produktes hingewiesen werden. Alle Informationen dazu werden im Handbuch entsprechend dargestellt. Das stellt zwar den Teil der Dokumentation dar, den man später mit dem Produkt weitergibt, aber das macht eben nur einen kleinen Teil der Dokumentation aus.
6. Validierung: Der Tag der Wahrheit steht an. Typischerweise sind hier die Testlabore gefragt, die nach dem Validierungsplan alle Anforderungen entsprechend abprüfen. Am Ende stehen die Prüfberichte der Einzeldisziplinen, die zusammengetragen und ausgewertet werden.
7. Verifikation: Neben den typischen Verifikationstätigkeiten innerhalb der einzelnen Realisierungsschritte bleiben zum Ende diverse Verifikationstätigkeiten, die in einem Verifikationsplan entsprechend angedacht werden müssen. Der Plan sollte besonders dann auch alle Zwischenschritte adressieren, wenn die Aufgabenpakete über mehrere Parteien verteilt werden.
Mehr Testaufwand und mehr Dokumentation
Vor allem das Testen fällt bei Entwicklungsprojekten, die Aspekte der Funktionalen Sicherheit berücksichtigen müssen, deutlich umfangreicher aus. So muss beispielsweise die Funktionalität unter allen Bedingungen nachgewiesen werden – neben Grenztemperaturen auch unter Fehlerbedingungen. Insbesondere Fehlereinpflanzungstests können durchaus deutlich aufwendiger sein, als die vorangegangenen Funktionstests. Denn hier muss die Schaltung mit ihrer Testeinrichtung zeigen, dass sie sich entsprechend der vorher erstellten Ausfallbetrachtung verhält. Abhängig von den Ausfallarten und aus welchen Betriebsmodi eine Fehlererkennung erfolgt, kann der Testaufwand erheblich sein.
Ein anderes Beispiel sind Black Box Tests im Softwarebereich. Diese können im FuSi-Umfeld ebenfalls sehr umfangreich ausfallen. So kommen beispielsweise aus einem Bus-System definierte Datenpakete, auf die das neue entwickelte Produkt mit einer bestimmten Funktionalität reagieren muss. Gleichzeitig darf es aber auf alle anderen Datenpakete explizit nicht reagieren. Auch das muss systematisch getestet und dokumentiert werden.
Saubere Dokumentation und einfache Zulassung
Insgesamt fällt für ein Entwicklungsprojekt im Umfeld der Funktionalen Sicherheit mehr Aufwand an, als für ein herkömmliches. Zum einen, aufgrund der zwingend einzusetzenden Methodiken, zum anderen wegen der höheren Testaufwands. Zu jeder einzelnen Anforderung muss geklärt sein, ob sie erfüllt und wirksam ist. Viel Arbeit also, die am besten in Händen eines erfahrenen Functional Safety Engineers liegt. Er trägt Sorge dafür, dass alles richtig umgesetzt, getestet, Zeitpläne eingehalten und die notwendigen Dokumentationen angefertigt werden. Auf diese Weise wird sichergestellt, dass jede Projektphase mit den richtigen Eingangsinformationen startet und mit dem entsprechenden Output abgeschlossen wird.
Trotz allen Aufwands: gut umgesetzte FuSi-Projekte bergen einen entscheidenden Vorteil: die Wahrscheinlichkeit, dass große Fehler die anschließende TÜV-Zulassung oder Go-To-Market stark verzögern, ist wegen der systematischen Fehlervermeidung sehr gering. Genau so wie das Risiko, wegen Fahrlässigkeit in Regress genommen zu werden.
