30.03.2021

So werden Haftungsrisiken minimiert

Safety richtig dokumentieren

Gerade bei der Entwicklung von Antrieben und Motoren muss von Anfang an jede Projektphase mit Verantwortlichkeiten genau dokumentiert werden. Tut man das nicht, steht viel auf dem Spiel: Denn werden Menschen verletzt, kann es schnell teuer werden. Deshalb sind für Entwicklungsprojekte, die im Rahmen der Vorgaben für funktionale Sicherheit ablaufen, bestimmte Methoden für die Dokumentation verbindlich vorgeschrieben.


Gleich zu Anfang stellt sich die Frage, welche Bestandteile benötigt eine vollumfassende FuSi-Dokumentation? Generell gilt: In jeder Phase des Produktentwicklungsprozesses sind verschiedene Dokumente verbindlich zu erstellen. Nur auf diese Weise kann systematisch nachgewiesen werden, dass man alles getan hat, um die Zielvorgaben zu erreichen - und dass folglich keine Nachlässigkeit vorliegt. Das bedeutet im Umkehrschluss: Ohne eine belegte Risikobetrachtung und ohne Safety-Konzept betritt der Produktentwickler dünnes Eis. Denn alle Nachlässigkeiten im Konzept können während der Realisierung Löcher aufreißen, die dann immer schwerer zu stopfen sind.

Das Safety-Konzept setzt den Grundstein für die aus der Risikobetrachtung ermittelte technische Maßnahme, die ja die zu realisierende Sicherheitsfunktion darstellt. Aus den Risikoparametern wird der zu erreichende Sicherheitsintegritätslevel (SIL) ermittelt, um die Gefährdung entsprechend zu beherrschen. Neben allen Einflussfaktoren, die zu der (oder den) eigentlichen Sicherheitsfunktion(en) führen, ist es natürlich auch entscheidend, Funktion und Integrität systematisch abzubilden. Abhängig vom SIL - in der Maschinenwelt die Stufen 1 bis 3 - werden Verfahren und Maßnahmen zu allen Phasen vorgegeben, die entsprechend berücksichtigt werden sollten. Natürlich kann bei guter Begründung vom vorgezeichneten Weg abgewichen werden. Jedoch sollte dies dann entsprechend dokumentiert werden.

Welche Dokumente in welcher Phase des Produktlebenszyklus?

Die reine Dokumentation eines FuSi-Projekts unterscheidet sich kaum von der eines klassischen Produktentwicklungsprojekts. Allein inhaltlich wird von der EN61508 eine gewisse Systematik zur Fehlervermeidung gefordert. Für jede Phase des Produktlebenszyklus ist festgelegt, welches Ausgangsdokument jeweils erstellt werden muss, das für die Folgephase dann als Eingangsdokument dient. Innerhalb dieser Phasen müssen dann für die Dokumentation die Verfahren und Maßnahmen berücksichtigt werden - abhängig vom angestrebten SIL. So sind beispielsweise in der Konzeptphase Blockschaltbilder und Ablaufdiagramme immer eine sinnvolle Darstellungsweise, um gerade komplexere Zusammenhänge anschaulich zu dokumentieren. So kann der Entwickler rückblickend prüfen, ob das gesetzte Ziel auch tatsächlich erreicht wurde. Alle Verfahren und Maßnahmen dienen letztlich dazu ein Produkt, ein Bauteil oder einen Prozess von verschiedenen Seiten her zu beleuchten, um systematische Fehler zu vermeiden.

Konzeptphase

Das Konzept startet mit der Produktidee und mündet in der Spezifikation der Anforderungen an die Sicherheitsfunktion sowie alle sonstigen Funktionen. Für diese Phase sind von Bedeutung:

  • • Das Konzept und dessen Anwendungsbereich.
  • • Die Gefährdungs- und Risikoanalyse, die neben der identifizierten und zu realisierenden Sicherheitsfunktion auch wichtige konstruktive Vorgaben und nicht zuletzt die Hinweise zu Restrisiken für das Handbuch liefert.
  • • Aus der Gefährdungs- und Risikoanalyse ergeben sich die Anforderungen zur Gesamtsicherheit, die entsprechend zugeordnet werden müssen.
  • • Die Konzeptphase mündet in der Spezifikation der Anforderungen an die Sicherheit.

Da die Folgephasen auf diesen Arbeitspaketen aufbauen, ist es ratsam, bereits hier nach einer festen Systematik vorzugehen, die über den Safety-Plan allen Beteiligten vorgegeben wird. Abhängig vom zu erreichenden SIL wird an dieser Stelle für alle Phasen die entsprechend anzuwendende Methodik vorgegeben und sollte bereits alle Vorgaben enthalten zu

  • • Projektmanagement
  • • Anforderungsmanagement
  • • Modifikationsmanagement
  • • Konfigurationsmanagement

Insbesondere, wenn mehrere Partner an einem Projekt beteiligt sind, ist es wichtig diese Vorgaben entsprechend zu (ver-)teilen.

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.

Empfehlungen der Redaktion

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.

Anzeige