Funktionale Sicherheit, die im Ernstfall wirklich hält

ASIL/SIL- oder PL-Einstufung, Sicherheitsfunktionen und Redundanzarchitektur nach IEC 61508/61511 bzw. ISO 26262 – wir moderieren die Analyse und bauen die Kompetenz in Ihrem Team auf.

SIL (Safety Integrity Level) = Sicherheits-Integritätslevel, das Maß für die geforderte Zuverlässigkeit einer Sicherheitsfunktion. IEC 61508 = branchenübergreifende Basisnorm für funktionale Sicherheit elektrischer/elektronischer/programmierbarer Systeme, IEC 61511 ihre Ableitung für die Prozessindustrie. ISO 26262 = funktionale Sicherheit im Automotive-Bereich (Automotive Safety Integrity Level), PL (Performance Level) = Ansatz zur Einstufung wie SIL/ASIL, älter; Ausgangspunkt jeder Einstufung sind G+R (Gefährdungs- und Risikobeurteilung) bzw. HARA (Hazard Analysis and Risk Assessment) – siehe auch unsere Risikomanagement-Seite.

[01] — AUSGANGSLAGE

Fehlt Ihrer Sicherheitsfunktion noch die Nachvollziehbarkeit?

ASIL/SIL/PL wird mehr geschätzt als ermittelt
Die Einstufung entsteht aus dem Bauch heraus statt aus einer nachvollziehbaren G+R bzw. HARA und anerkannten Berechnungsverfahren.
Funktionen vermischt
Sicherheits- und Betriebsfunktion laufen im selben System, ohne klare Trennung – die Nachweisführung wird dadurch unnötig komplex.
Nachweis erst am Ende
Der Sicherheitsnachweis wird kurz vor dem Audit zusammengeschrieben, statt mit dem Projekt mitzuwachsen.
Redundanz ohne Begründung
Doppelte Sensorik oder Aktorik ist vorhanden, aber nicht dokumentiert, warum genau diese Architektur (1oo2, 2oo3) gewählt wurde.
Erfahrungswert: früh geplant spart Nacharbeit
Eine von Anfang an mitgedachte Sicherheitsarchitektur vermeidet erfahrungsgemäß aufwändige Nachrüstungen kurz vor der Zulassung.
[02] — GEGENÜBERSTELLUNG

Von der Schätzung zur belastbaren Einstufung

Der Status quo

Die ASIL/SIL/PL-Einstufung wird grob geschätzt, ohne nachvollziehbare Berechnung.
Sicherheits- und Betriebsfunktion sind im selben System vermischt.
Der Sicherheitsnachweis entsteht erst kurz vor dem Audit, unter Zeitdruck.
Redundante Architektur wird gebaut, ohne die Wahl zu dokumentieren.

Mit unserem Ansatz

Die ASIL/SIL/PL-Einstufung basiert auf einer nachvollziehbaren HARA und anerkannten Berechnungsverfahren.
Sicherheitsfunktionen werden von Anfang an sauber von der Betriebsfunktion getrennt.
Der Sicherheitsnachweis wächst mit dem Projekt mit, statt am Ende improvisiert zu werden.
Jede Architekturentscheidung (z. B. 1oo2, 2oo3) ist begründet und dokumentiert.
[03] — VORGEHEN

Von der Gefährdung zur belastbaren Zulassung

Funktionale Sicherheit entsteht nicht durch ein Prüfsiegel am Ende, sondern durch einen Prozess, der von der ersten Gefährdungsanalyse bis zum fertigen Nachweis durchgängig ist. Unser Ansatz verbindet vier Schritte: Gefährdungen beurteilen, die Sicherheitsanforderungsstufe herleiten, die Architektur passend dazu gestalten und den Nachweis parallel zum Projekt aufbauen.

01
Gefährdungs- und Risikobeurteilung (G+R bzw. im Automotive-Bereich u.a. HARA)
Ausgangspunkt jeder Sicherheitsbetrachtung – knüpft an unsere Risikomanagement-Methodik an, hier sicherheitsspezifisch vertieft: welche Gefährdung, wie schwer, wie oft, wie beherrschbar.
02
SIL-/ASIL-Einstufung
Nachvollziehbare Herleitung der Sicherheitsanforderungsstufe nach IEC 61508/61511 bzw. ISO 26262 (ASIL) – dokumentiert, nicht geschätzt.
03
Sicherheitsfunktion und Architektur
Klare Trennung von Sicherheits- und Betriebsfunktion, begründete Wahl der Redundanzarchitektur (z. B. 1oo2, 2oo3) passend zur geforderten Stufe.
04
Nachweis und Validierung
Der Sicherheitsnachweis wächst mit dem Projekt mit und liegt bei Audit oder Zulassung vollständig vor, statt am Ende improvisiert zu werden.
[04] — REFERENZ

Dieselbe Methodik, auf Sicherheitsfunktionen vertieft

Funktionale Sicherheit baut auf derselben HARA-Methodik auf, die auch unsere Risikomanagement-Seite trägt – hier vertieft um die spezifischen Anforderungen von IEC 61508, IEC 61511 und ISO 26262. Über Jahrzehnte in sicherheitskritischen Branchen angewendet: Maschinenbau, Prozessindustrie, Automobilentwicklung. Diese Erfahrung hilft besonders dort, wo Sicherheits- und Entwicklungsteams eine gemeinsame Sprache brauchen, um Anforderungen nicht nur zu erfüllen, sondern auch zu verstehen.

[05] — NÄCHSTER SCHRITT

Bereit, Ihre Sicherheitsfunktion audit-fest zu machen?

Lassen Sie uns in einem Erstgespräch klären, wo Ihr System heute steht und welcher SIL/ASIL realistisch gefordert ist.