Funktionale Sicherheit
Funktionale Sicherheit (Functional Safety) ist der Teil der Sicherheit eines Systems, der von der korrekten Funktion sicherheitsbezogener elektrischer und elektronischer (E/E) Systeme abhängt. Ziel ist die Abwesenheit unvertretbarer Risiken durch Fehlfunktionen. Grundnorm ist die IEC 61508, im Automobilbereich gilt die ISO 26262.
Worum es geht: Risiken durch Fehlfunktionen
Funktionale Sicherheit betrachtet Gefährdungen, die durch das Fehlverhalten eines Systems entstehen: Ein Bauteil fällt aus, ein Signal ist korrupt oder eine Software tut nicht, was sie soll. Unterschieden werden dabei zufällige Hardware-Ausfälle, die probabilistisch bewertet und durch Diagnose, Redundanz und degradierte Betriebsmodi beherrscht werden, und systematische Fehler — etwa in Spezifikation oder Software —, denen mit Prozess-Strenge, geeigneten Methoden und Verifikation begegnet wird. Der Ansatz ist durchgehend risikobasiert: Gefordert ist nicht absolute Fehlerfreiheit, sondern die Reduktion des Risikos auf ein vertretbares Maß — häufig dadurch, dass das System Fehler erkennt und in einen sicheren Zustand übergeht. Wie viel Risikoreduktion nötig ist, drücken abgestufte Integritätslevel aus: SIL 1 bis 4 in der IEC 61508, ASIL A bis D in der ISO 26262.
Die Normenlandschaft
Überall dort, wo ein Systemversagen Menschen gefährden kann, existieren Sicherheitsnormen:
| Branche | Norm |
|---|---|
| Branchenübergreifende Grundnorm | IEC 61508 |
| Automotive | ISO 26262 |
| Maschinenbau | IEC 62061 |
| Bahntechnik | EN 50716, EN 50129 |
| Agrartechnik | ISO 25119 |
| Medizintechnik | IEC 62304, IEC 60601, ISO 80601 |
| Luftfahrt | DO-178C |
Viele dieser Sektornormen sind direkte Ableitungen der IEC 61508, andere folgen vergleichbaren Grundprinzipien: Sicherheitslebenszyklus, risikobasierte Einstufung, abgestufte Methodenanforderungen und Nachverfolgbarkeit zwischen Anforderungen, Umsetzung und Verifikation.
Safety vs. Security
Funktionale Sicherheit (Safety) und Cybersecurity (Security) betrachten exakt dasselbe System aus zwei Blickwinkeln: Safety schützt die Umwelt vor dem System — vor unbeabsichtigten Fehlfunktionen und Unzulänglichkeiten. Security schützt das System vor der Umwelt — vor beabsichtigten, böswilligen Angriffen. Methodisch stehen sich Gefährdungsanalyse (HARA, ISO 26262) und Bedrohungsanalyse (TARA, ISO/SAE 21434) gegenüber. Beide Disziplinen beeinflussen sich wechselseitig: Ein Security-Patch kann das Zeitverhalten der Software ändern und damit die Safety gefährden; eine neue Safety-Funktion kann neue Angriffsvektoren öffnen. Safety-Engineering, das diese Wechselwirkungen ignoriert und in Silos arbeitet, plant an der Realität vorbei.
Was funktionale Sicherheit nicht abdeckt
Funktionale Sicherheit adressiert Fehlfunktionen. Es gibt jedoch Gefährdungen, bei denen nichts ausfällt: Das System arbeitet exakt wie spezifiziert, aber die Spezifikation oder die Leistungsfähigkeit reicht für die reale Situation nicht aus — etwa wenn eine Kamera ein Hindernis bei tief stehender Sonne nicht erkennt. Für diese Klasse steht im Automotive-Umfeld die ISO 21448 (SOTIF — Safety of the Intended Functionality). Ebenfalls getrennt zu betrachten sind passive Sicherheit (etwa Gurte und Knautschzonen) und elektrische Sicherheit.
Funktionale Sicherheit in der Praxis
In der Praxis ist funktionale Sicherheit vor allem Nachweisarbeit: Für jedes Sicherheitsziel muss lückenlos belegt werden, wie es über Sicherheitsanforderungen, Architektur und Implementierung bis in den Test umgesetzt wurde — gebündelt im Safety Case. Das Rückgrat dieses Nachweises ist durchgängige Traceability über Werkzeuggrenzen hinweg. Je kürzer die Entwicklungszyklen werden und je häufiger Systeme auch nach der Freigabe Updates erhalten, desto weniger trägt das eingefrorene Sicherheitsdokument: Die Sicherheitsbewertung muss kontinuierlich mitlaufen, statt einmalig zum Meilenstein zu entstehen.