Funktionale Sicherheit in der Praxis

by | 07.11.2016 | Requirements Engineering

„Es hätte einfach nicht sein müssen! Warum zum Teufel sagt ihr nicht Bescheid, wenn es nicht läuft und ihr die Goals nicht erreicht!!?“

Die rote Ader auf der Stirn des Entwicklungsleiters pulsierte bedrohlich. Er schaute in die betretenen Gesichter seines durchaus fähigen Teams, die seinem Blick auswichen. Er verstand es einfach nicht. Es war immer das Gleiche. Die Entwicklung lief gut an, angeblich klappte alles, auch die festgelegten Audits waren den Umständen entsprechend positiv gewesen und nun, gegen Ende des Projektes war es wieder soweit. Bei der Implementierung der Software waren Fehler aufgetreten, die auszuführende Funktion konnte nicht aufrecht gehalten werden und viele Anforderungen wurden nicht erfüllt. Verschiedene Komponenten rauchten in den Belastungstest ab, waren “für diesen unvorherzusehenden Spezialfall” nicht ausgelegt gewesen. Er war sauer, er schickte sein Team auf Fortbildungen und doch passierten gegen Projektende immer wieder die gleichen Fehler, die immer wieder den gleichen Effekt des “verdammt, da hätten wir drauf kommen können / das hätte doch auffallen müssen” aufkommen ließen. Gut, dass es wenigstens jetzt passierte, noch ein kostenintensiver Rückruf und er würde seinen Job verlieren. Eigentlich mochte er seinen Job, hatte ein gutes Team, aber immer kürzere Entwicklungszyklen und der enorme Druck hatten eine nachhaltige Entwicklung zuletzt immer schwieriger werden lassen.

Unterschiedliche Ansichten und Standards
Es gibt viele Unternehmen, die vergleichbare Situationen im Entwicklungsbereich oder in der Produktion erleben. Zum Teil wird weltweit entwickelt, nach unterschiedlichen Ansichten und Standards. Begriffe wie “sicher”, “zuverlässig” oder auch einfach “gut” werden unterschiedlich verstanden und interpretiert. Es entstehen Missverständnisse und Resignation. Etwas altkluger Galgenhumor gefällig? – meistens unnötig. Natürlich ist der Schlüssel zur Lösung Kommunikation – ach was? – aber es ist nur die halbe Miete, man muss in der kurzen, zur Verfügung stehenden Zeit auch noch über das Richtige reden. Vielleicht war einer dieser Momente in den Projekten die Geburtsstunde der funktionalen Sicherheit. Der Gedanke, es besser machen zu wollen und sicherer – wenn man schon mal dabei ist.

Entgegengesetzt der einschlägigen Meinung, dass Sicherheit etwas ist, was zwar irgendwie wichtig wäre, aber dann doch eher stiefmütterlich am Rande gemacht wird, kann die funktionale Sicherheit richtig angewendet, eine Menge Druck reduzieren und echte Vorteile bieten.

Was ist und bringt die funktionale Sicherheit?

Wer schon mal eine Norm gelesen hat weiß, dass sich die Nutzungsvereinbarungen jeder beliebigen App besser lesen lassen. Deshalb nun ein kleiner Einblick in die funktionale Sicherheit (FuSi): Wie der Name schon sagt, sorgt die funktionale Sicherheit dafür, dass eine zuvor definierte Sicherheitsfunktion aufrechterhalten und damit der zuvor definierte sichere Zustand für ein System gewährleistet wird. Dies beschränkt sich jedoch auf die elektrischen, elektronischen und programmierbaren Bereich der Entwicklung.

Um dieses Ziel zu erreichen, wird – hier als Beispiel im Maschinen und Anlagenbau – wie folgt vorgegangen:

  1. Analyse möglicher Gefährdungen. Welche Gefahren können von dem zu entwickelnden Produkt ausgehen? Mit Hilfe einer HAZOP (engl. Hazard and Operability) oder einer PAAG (Prognose, Auffinden der Ursache, Abschätzen der Auswirkungen, Gegenmaßnahmen) lassen sich diese Gefährdungen herausfinden und einschätzen.Diese Verfahren legen nicht nur den Grundstein für das Vorgehen in der funktionalen Sicherheit, sondern minimieren hier schon frühzeitig die Wahrscheinlichkeiten von Rückrufen oder rechtlichen Konsequenzen durch Ausfälle oder im schlimmsten Falle Verletzungen von Kunden im Feld.
  1. Definieren von Sicherheitsfunktionen. Jeder gefundenen Gefährdung wird nun eine Sicherheitsfunktion zugeordnet. Diese beschreibt, wie die Gefährdung verhindert werden kann. Je nach Eintrittswahrscheinlichkeit und Schadensausmaß der Gefährdung wird jeder Sicherheitsfunktion ein SIL (engl. Safety Integrety Level – wobei 4=höchster; 1=niedrigster) zugeordnet. Dieser SIL steht für das Maß an Risikominderung das notwendig ist, um das System in einen sicheren Zustand zu überführen und die Gefährdung auf ein vertretbares Restrisiko zu reduzieren.

Dieses Vorgehen ist Branchen-übergreifend größtenteils bis auf das Wording und die Einstufung der Risiken identisch. Klingt gut, aber auch nach Mehraufwand und erstmal keinem Nutzen für einen normalen Entwickler! Um den Aufwand und Nutzen zu beurteilen, werfen wir einmal einen Blick auf die gelebte Praxis in Unternehmen: häufig werden die eingefahrenen, betriebsinternen Prozesse den ständig wachsenden Anforderungen nicht mehr zur Gänze gerecht. So schleichen sich Fehler und Fehlentscheidungen ein, die zu folgendem Prozessablauf führen:

Produktrisiken durch fehlendes Konzept

Mit einem gelebten Sicherheitskonzept könnte es wie folgt aussehen:

Problemvorbeugung durch Sicherheitskonzept

Die Analyse möglicher Gefährdungen und die Definition von Sicherheitsfunktionen bilden lediglich das Fundament und den Einstieg in die Funktionale Sicherheit. Wie die Abbildung “Projektmanagement mit Sicherheitskonzept” deutlich zeigt, entlastet die FuSi den Entwicklungsprozess anstatt ihn – wie oft angenommen – zu behindern. Durch den zunächst scheinbaren höheren Aufwand zu Beginn des Projektes, reduzieren sich die Aufwände und Stressfaktoren deutlich schon zur Mitte des Projektes hin. Dies hilft unter anderem erheblich dabei, die Entstehung systematischer Fehler in der Entwicklung zu minimieren. Die elementaren Vorteile, die dies ermöglichen sind die folgenden:

  • Das Management der funktionalen Sicherheit (der genaue Ablauf ist bspw. in der IEC 61508 beschrieben) macht klare Vorgaben und Empfehlungen. Diese weisen Mitarbeiten besondere Rollen zu, mit denen festgelegte Aufgaben verknüpft sind. Ebenso gibt es festgelegte Vorgaben zu Abläufen und Arbeitsweisen. Dies führt zu folgenden Vorteilen: 
    * Es ist klar definiert, wer was und wann macht. Damit sinkt die Rate an Missverständnissen darüber, wer eigentlich wofür zuständig wäre. Damit sinken auch Frust und Reibereien der Kollegen untereinander.
    * Dadurch, dass der vorgegebene Prozess als vollständig und umfassend angesehen werden kann, sinkt die Angst, dass Zwischenschritte vergessen oder nicht vollständig abgearbeitet worden wären. Dem Vorgesetzen kann klar kommuniziert werden, auf welchem Stand sich das Projekt befindet und was als nächstes ansteht.
  • Empfehlungen für definierte Abläufe und Vorgehen
    Um bestimmte Ziele in der funktionalen Sicherheit zu erreichen, werden Vorgaben zu Art der Entwicklung gemacht. Ein Beispiel hierfür ist das „bekannte V-Modell“. Dies führt zu folgenden Vorteilen:
    * Durch die Vorgaben von definierten Zwischenschritten und festgelegten Abläufen, wird unter anderem das Auftreten von sogenannten systematischen Fehlern minimiert.
    * Es werden interne hierarchische Problemstellungen bestmöglich geschlossen.
    * Die Qualität steigt.

Fazit

Die Vorteile einer gelebten Sicherheitskultur im Unternehmen liegen klar auf der Hand.

Vorteile fürs Unternehmen:

  • Minimierung der Wahrscheinlichkeit von Rückrufen
  • Produktion von SIL-Ready Produkten
  • Qualitätssteigerung

Vorteile für Mitarbeiter:

  • Stressreduzierung durch gemeinsame Vorgaben
  • Klare Rollenverteilungen
  • Bessere Einteilung der Arbeit
  • Viele praktische Checklisten und Tools aus Normen

Um allerdings wirklich etwas zu bewegen, müssen viele Prozesse im Unternehmen umgestellt werden. Vieles muss und wird sich verändern. Das ist positiv, weil glückliche Mitarbeiter und Teammitglieder nachweislich bessere Arbeit leisten. Natürlich ist der Initialaufwand erstmal groß und kostet Geld  – zugegeben – aber wieviel? Mehr als Rückrufe, Entschädigungszahlungen für Schäden, Haftungsfragen und resignierte Mitarbeiter kosten? Das glaube ich nicht. Die wahre Herausforderung besteht in der Aufklärung und der Akzeptanz. Die Wandlung muss und kann auch nicht sofort und umfassend geschehen, schon allein weil Prozess- und Strukturveränderungen von Entscheidern und Führungskräften getroffen werden müssen. Es kann im kleinen anfangen, in dem man in die Softwareentwicklung schon mal das V-Modell einbindet, eine Risikoanalyse macht und oder den internen Prozess Stück für Stück anpasst und verändert. Work smarter not harder.