Bestimmt haben auch Sie mal einen Fehler in der Produktentwicklung gemacht. Fehler kommen öfters vor, insbesondere bei uns Menschen. Im Bereich der Funktionalen Sicherheit werden im Folgenden die Top 8 Fehler genauer betrachtet und einige Strategien zur Vermeidung mitgegeben.
Funktionale Sicherheit im Nachgang
Oft wird mir oder dem Gutachter das fast fertige System vorgestellt, mit der Vorstellung, dass da irgendwas getestet werden muss, damit ein Zertifikat ausgestellt werden kann. Damit ist das Kind schon in den Brunnen gefallen. Der für die Funktionale Sicherheit erforderliche chronologisch wachsende Nachweis zu den Maßnahmen zur Vermeidung systematischer Fehler im Entwicklungsprozess kann nicht mehr erbracht werden. Das vorgestellte System kann nur noch als Prototyp dienen in einem aufwendigen „recompliance process“. Das bedeutet, alle erforderlichen Prozesse und Aktivitäten im V-Modell durchgehen. Das ist sehr kostenintensiv, wie üblich, wenn Fehler spät im Entwicklungsprozess korrigiert werden müssen.
Mangelhafte Qualität im Entwicklungsprozess
Gerade das Thema Funktionale Sicherheit inkludiert den Menschen als Fehlerquelle und fordert Maßnahmen zur Vermeidung von systematischen Fehlern im gesamten Lebenszyklus. Oft muss man dann die mangelhafte Qualität mit Sicherheitsrisiko kostenintensiv korrigieren. Manchmal ist es sogar fahrlässig, wie entwickelt wird. Daher ist es oft Voraussetzung ein Qualitätsmanagementsystem in der Organisation/Firma aktiv zu „leben“ und Methoden wie die FMEA auszuführen, um Fehler im Design oder Prozess frühzeitig zu erkennen.
Fehlende Verantwortung
Oft ist kein Verantwortungsbewusstsein als Merkmal fehlender Sicherheitskultur (engl. safety culture) gegeben. Daher ist eine Verantwortungsmatrix mit Rollenbeschreibung VOR dem START des Projektes erforderlich. Nicht wissen, nichts tun, nicht melden kann in den Bereich der Fahrlässigkeit fallen. Daher müssen Verantwortliche benannt und ermächtigt werden, die obligende Plicht durchzusetzen. Das ist oft problematisch und kann im ungünstigsten Fall bis zum Verlust des Arbeitsplatzes führen. Daher muss mit vollem Bewusstsein in einem Projekt die Verantwortung übernommen werden. Das will nicht jeder udn wird oft auch schlecht bezahlt. Die Verantwortlichen suchen oft Jemanden der keinen Ärger macht und alles absegnet.
In der Praxis finden sich oft falsch ausgestellte Zertifikate, fehlerhafte Berechnungen, fragwürdige Argumentationen. Selbst benannte Stellen (Prüforganisationen) machen auch mal Fehler. Daher ist es notwendig, neben der Durchsetzungsfähigkeit auch die Kompetenz oder Qualifikation zu haben. Ihnen sollte bewusst sein, wann Sie unsicheres Terrain erkunden.
Unterschätzung der Aufwände
Das Thema Funktionale Sicherheit ist für Fachfremde auf dem ersten Blick abstrakt, nicht greifbar, oft auch unberechenbar. Daher ist es erforderlich die Kernaspekte zu verstehen und wichtige verdeckte Kriterien bei Entscheidungen aufzudecken. Darunter sind zum Beispiel Fragen wie:
- Wurde die richtige Strategie für Element x im Hinblick auf „make or buy“ getroffen?
- Kann das Team und die Firmenkultur die erforderliche sicherheitstechnische Leistungsfähigkeit bereitstellen?
- Können wir im agilen spirit auch das V-Modell leben bzw. anwenden ohne „innere Kündigung“?
- Ist ausreichend Kompetenz bei der verwendeten Technologie vorhanden?
- Ist ausreichend Kompetenz für die relevanten Methoden (FME(D)A, FTA, DPA, RBD etc…) vorhanden?
- Kann die Organisation das Unabhängigkeitsprinzip (Code-Tester ist nicht Coder, Verifizierer, Validierer etc…) abbilden?
- Sind die Kosten für die Zertifizierung und ggf. erforderliche (teilweise auch iterative) Typprüfung im Budget berücksichtigt?
- Ist ein „Safety Management“ erforderlich?
Top Level Anforderungen mangelhaft
Funktionale Sicherheit ist nur ein Teilaspekt der Produktsicherheit. Genauer handelt es sich im Kern um den Nachweis zur Integrität von Sicherheitsfunktionen als „technische Schutzmaßnahmen“ in einem Gesamtsicherheitskonzept. Oft werden elektrische, elektronische oder programmierbar elektronische Systeme entwickelt, welche diese Sicherheitsfunktionen ausführen. Es gibt auch Maßnahmen in anderen Technologien wie z.B. Hydraulik (Lasthalteventile) oder mechanische Elemente wie Überdruckventile, welche im Gesamtsicherheitskonzept spezifische Gefahren kompensieren.
Manchmal werden einfach „vom Himmel fallend“ Sicherheitsfunktionen mit scheinbar willkürlichen Integritätslevel umgesetzt. Daher entstehen Projekte mit „safety over/under engineering“ situationen.
Nicht selten werden Normen als „verbindlich“ interpretiert. Dabei sollen Normen helfen und nicht verwirren. In der Praxis sieht es allerdings oft anders aus. Normen, die dem Titel nach relevant sein könnten, werden beim DIN MEDIA Verlag gekauft ohne die Relevanz genauer zu prüfen. Oft werden auch keine Normen gekauft, weil das Internet ja genug „Fragemente“ liefert. Manchmal werden auch Normen mit Fehlern einfach umgesetzt, ohne diese zu korrigieren. Daher ist ein gesundes Maß mit einer gewissen Gründlichkeit in der Recherche VOR der Entwicklung notwendig. Erst wenn alle elevanten Top Level Anforderungen identifiziert sind, lässt sich ein Projekt seriös planen und die erforderlichen Ressourcen schätzen.
Alles andere ist die BER-Flughafen oder Stuttgarter Bahnhof Methode, die im Budget klein startet und dann das Budget um Faktor x erhöht.
Sicherheitskonzept ist mangelhaft
Ein technisches Sicherheitskonzept ist stets eine Lösung von vielen Möglichkeiten. Daher ist es erforderlich, die Randbedingungen genauer zu kennen und im Hinbick auf die Kosten den sicherheitstechnischen Nutzen genauer zu bestimmen. Daher ist es sinnvoll bereits im Entwurf eine Berechnung zu den quantitativen Zielwerten des erforderlichen Integritätslevel (SIL, PL etc…) durchzuführen. Machen Sie es grob und konservativ, also zur sicheren Seite hin.
Im Maschinen- und Anlagenbau kann ein integrierter Ansatz in einer „Safety SPS“ oft kostengünstiger sein als dedizierte Lösungen mit einer Vielzahl von „Sicherheitsrelais“. Ab 3 Sicherheitsfunktionen kann die integrierte Sicherheit kostengünstiger sein bezogen auf den Lebenszyklus. Insbesondere wenn noch analoge Messwerte ins Konzept kommen, wird es oft teuer, da nur wenige Hersteller am Markt eine sichere Analogbaugruppe anbieten.
Zertifizierer / Assessor
Drum prüfe wer sich bindet. Der Fachkräftemangel ist auch bei akkeditierten Stellen und Prüforganisationen vorhanden. Dann können in der dem Projekt zugrundeliegenden Norm auch unerfahrene „FuSi Experten“ grobe Fehler machen. Da hilft nur Kompetenz, um den Prüfer auf diesen Fehler aufmerksam zu machen. Oft denkt sich der Prüfer, dass die anderen Normen gleich sind wie die Grundnorm. Jedoch hat jede Norm eine branchenspezifische „Entstehungsgeschichte“.
Der Prüfer hat eine große Verantwortung. Er muss sich in kürzester Zeit ein Bild von der Technologie, des Entwicklungsteams und der technischen Lösung machen. Dazu kommt es auch oft vor, dass er belogen wird und eine „Dokumentenlandschaft“ präsentiert wird, die nicht dem entspricht, was er abnehmen soll. Ist das Vertrauen einmal weg, ist Schluss. Er kann sehr wohl unterscheiden zwischen Unwissenheit und betrügerischer Absicht. Andererseits gibt es Prüfer, die stellen Zertifikate aus, die nie hätten ausgestellt werden dürfen. Oft gibt es dann im Kleingedruckten einen Disclaimer, wo steht, Zertifikat auf Grundlage von xyz.
Der Faktor Zeit ist auch ein wichtiger Aspekt. In der EU gibt es mehrere akkreditierte/benannte Stellen. Die DGUV braucht i.d.R. sehr lange im Vergleich zum TÜV, wobe auch beim TÜV nochmals unterschiede zwischen dem TÜV Nord, Süd, Rheinland gibt.
Argumentation im Safety Case
Oft werden pauschale Fehlerausschlüsse gemacht oder fragwürdige Argumentationen geführt in größeren Teamrunden. Aussagen wie „haben wir schon immer gemacht“ oder „sowas haben wir nie hinterfragt“ oder „das ist Quatsch“ kommen regelmäßig. Funktionale Sicherheit ist Nachweisführung und diese braucht saubere Dokumente und gute Konzepte sowie geignete Prozesse, die gelebt wurden. Dies muss prüfbar sein. Ein Review auf ein Code zu einem Softwarestand x auf Hardware Rev. y zum Zeitpunkt t wird geprüft. Am Ende steht die Validierung, wo nicht nur getestet sondern auch analysiert wird durch eine unabhängige Person.
