Lesezeit 3 min
Sie wissen, dass Sie wohl «irgend etwas» für funktionale Sicherheit machen müssen. Die Frage, die sich nun stellt ist: wie fangen Sie an?
Vor der eigentlichen Entwicklung sollten zwei Aspekte der Zertifizierung geklärt werden, nämlich Zertifizierungsbasis und Sicherheitsziele. Zusätzlich die eigentliche Funktion des Produktes ohne funktionale Sicherheit.
Zertifizierungsbasis
Zuallererst sollte geklärt werden, welches die regulatorischen Anforderungen sind. Dies können einerseits Regulierungen von Behörden (EU, EASA, FDA etc.) sein, andererseits die Normen, welche sich aus diesen Anforderungen ableiten oder welche sonst in den angepeilten Märkten gelten. Für Komponenten eines grösseren Systems ist diese Information häufig vom Kunden d.h. vom Systemintegrator vorgegeben.
Häufig besteht die Zertifizierungsbasis am Anfang aus wenigen Normen. Sobald man sich mit dem Thema befasst, wird diese detaillierter. Typischerweise kommt man um eine intensive Normen-Recherche nicht herum.
Diese Information dokumentiert man am besten in einer «Zertifikationsbasis» als Grundlage für die Entwicklung. Dieses Dokument kann auch die anderen regulatorischen Anforderungen enthalten wie EMV, Brandschutz etc.
Sicherheitsziele / Sicherheitsfunktionen
Nun müssen noch die Sicherheitsziele geklärt werden. Diese müssen Sie in vielen Fällen selbst herleiten.
Dies geschieht mit einer Sicherheitsanalyse des ganzen Produktes, mit einer HARA (Hazard Analysis and Risk Assessment), meist in Form einer FMEA (Failure Mode and Effects Analysis) für das ganze zu entwickelnde Produkt oder Subsystem (d.h. keine Komponenten FMEA, wie z.B. bei einer FMEDA), deren Details häufig von den anzuwendenden Normen vorgegeben sind. Daraus resultieren die Sicherheitsziele, manchmal auch als Sicherheitsfunktionen formuliert (Input-Processing-Output), z.B. «Wenn die Spannung am STO-Eingang abfällt, dann dann reduziert der Motor innerhalb von 500 ms sein Drehmoment auf weniger als 30 Nm.».
Es hat sich bewährt, Sicherheitsziele positiv zu formulieren, d.h. es wird beschrieben, was sichergestellt sein muss, und nicht was nicht passieren soll. Z.B. «Der Sensor liefert die richtigen Positionswerte» statt «Der Sensor liefert keine falschen Positionswerte». Es ist in diesem Fall einfacher, zu definieren, was ein richtiger Wert ist (beispielsweise 1% Abweichung des Vollausschlags), als zu definieren, was alles falsche Werte sein könnten.
Für viele Standards muss jedes Sicherheitsziel noch mit einem Sicherheitsgrad hinterlegt werden, z.B. SIL (Safety Integrity Level), ASIL (Automotive Safety Integrity Level), PL (Performance Level) etc.
Manchmal sind die Sicherheitsziele und die Sicherheitsgrade schon vom Standard vorgegeben, beispielsweise in der Luftfahrt. Oder sie werden vom Kunden/Systemintegrator in seiner Risikoanalyse vorgegeben aufgrund der Architektur seines Systems und der Umgebung, in welcher es eingesetzt wird.
In beiden Fällen sollten vorgängig diejenigen Fragen geklärt werden, welche sich sehr stark auf die Entwicklung auswirken, wie z. B. die Definition der Schnittstellen. Häufig ist z. B. eine STO-Funktion (Safe Torque Off, sicher abgeschaltetes Moment) definiert. Es lohnt sich dann zu klären, wie das Eingangssignal aussieht, das den STO auslöst. Ein Befehl auf einem Feldbus führt zu einer komplett anderen Architektur als ein STO Eingang als statisches, digitales 24 V Signal. Im ersten Fall muss zusätzlich zur Elektronik auch eine sichere Software entwickelt werden, mit dem daraus resultierenden massiven Zusatzaufwand.
Da jedes Sicherheitsziel den Aufwand erhöht, macht es Sinn, so wenige Sicherheitsziele wie möglich zu haben, nur so viele wie nötig.
Hauptfunktion und Technologie: Prototypen
Diesen Teil können sie auslassen, wenn Sie schon ein Produkt haben oder funktionierende Prototypen, die mit der sich ergebenden Sicherheitsarchitektur kompatibel sind (siehe unten).
Wenn Sie sich über die Funktion, deren Implementation und deren Performance noch nicht ganz sicher sind, empfehlen wir, zuerst Funktionsmuster («Rapid Prototypes») aufzubauen, an welchen Sie die eigentliche Funktionen des Produkts testen können. Prototypen können Sie schneller erstellen, da Sie auf den Dokumentationsgrad und die Entwicklungsprozesse verzichten, welche von den Normen der funktionalen Sicherheit gefordert werden. Damit reduzieren Sie die Anzahl Änderungen während der sicheren Entwicklung, welche sehr viel höhere Aufwände bedeuten als Änderungen an einem Funktionsmuster.
Beachten Sie bei der Ausführung der Funktionsmuster eventuelle Einschränkungen, welche sich aus der Zertifizierungsbasis oder den Sicherheitszielen ergeben. Beispielsweise bei der Komponentenauswahl oder der Wahl der Technologie, inkl. Programmiersprachen. Es geht darum sicherzustellen, dass Sie die Erkenntnisse des Funktionsmusters möglichst 1:1 für die Entwicklung nach Normen der funktionalen Sicherheit verwenden können. Wenn Sie diese nicht berücksichtigen, dann können nicht alle Erkenntnisse des Prototypen für die sichere Entwicklung weiterverwendet werden.
Sie sind sich unsicher? Sprechen Sie mit uns, wir können Sie in allen drei Bereichen unterstützen!
Andreas Stucki
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Autor
Keine Kommentare