Funktionale Sicherheit: Wie starte ich?

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, dann die eigentliche Funktion des Produktes ohne funktionale Sicherheit.

Zertifizierungsbasis

Als allererstes 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 vorgegeben.

Häufig besteht die Zertifizierungsbasis am Anfang aus wenigen Normen, solbald Sie sich mit dem Theam befassen, wird diese detaillierter. Typischerweise kommt man um eine intensive Norm-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), 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 erzeugt der Motor kein Drehmoment mehr».

Es hat sich bewährt, Sicherheitsziel positiv zu formulieren, d.h. was sichergestellt sein muss, 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, 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 vorgegeben aufgrund der Analyse und Architektur seines Systems. Auch in diesen Fällen sollten doch einige Fragen geklärt werden, welche sich sehr stark auf die Entwicklung auswirken. Beispielsweise ist häufig eine STO-Funktion (Safe Torque Off, sicher abgeschaltetes Moment) definiert. Es lohnt sich dann die Fragen zu klären, wie sieht das Eingangssignal aussieht, das den STO auslöst. Ein Befehl auf einem Feldbus führt zu einer komplett anderen Architektur als ein STO Eingang auf einem Stecker. Im ersten Fall muss zusätzlich zur Elekktronik auch eine sichere Software entwickelt werden, mit dem daraus resultierenden massiven Zusatzaufwand.

Da jedes Sicherheitsziel den Aufwandd 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. Falls diese 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 diese eigentiliche Funktionen des Produkts testen können. Die Prototypen können Sie schneller erstellen ohne die Dokumentation und Prozesse, welche die funktionale Sicherheit einfordert. Und vor allem können Sie so die Anzahl Änderungen während der sicheren Entwicklung reduzieren, 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 von der Zertifizierungsbasis oder den Sicherheitszielen ergeben. Beispielsweise bei der Komponentenauswahl oder der Wahl der Technologie inkl. Programmiersprachen. Wenn Sie diese nicht berücksichtigen, dann können nichtn 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!