Stark prozessgetriebene Großunternehmen könnten die damit einhergehenden Anforderungen noch als Prozessanpassungen abhandeln, kleinere, eher kunden-/lösungsorientiere Sensor- und Aktorhersteller, mit überaus schlanken Prozessen, sehen sich dagegen ihrer Flexibilität beraubt, wenn sie die strikten Anforderungen der IEC 61508 in ihr Unternehmen integrieren möchten. Die zweiteilige Serie soll vor allem KMUs, die vor dem Einstieg in die Funktionale Sicherheit stehen, eine Hilfestellung geben. Im ersten Teil werden die Grundzüge der Funktionalen Sicherheit, die relevanten Normen und der (Produkt-)Sicherheitslebenszyklus erläutert. Der zweite Teil zeigt an konkreten Schritten, wie ein Unternehmen die Integration in der Praxis pragmatisch bewältigen kann.
Grundlagen
Funktionale Sicherheit ist nur ein Teil der Gesamtsicherheit eines Systems. Themenbereiche, wie die elektrische Sicherheit, sind separat zu betrachten. Generell spricht man von Funktionaler Sicherheit, wenn die Sicherheit des Systems – zumindest zum Teil – von der korrekten Funktion einer Sicherheitsfunktion abhängt. Funktionale Sicherheit muss daher immer von der realen Applikation bzw. realen Gefährdung aus betrachtet werden. Die Gefährdung wird eingeteilt in vier Stufen: SIL 1 (gering) bis SIL4 (hoch). In der industriellen Automation werden nur SIL 1 bis SIL 3 betrachtet. Die Ermittlung erfolgt in einem zweistufigen Risikobewertungsprozess. Prinzipiell läuft es aus Sicht der Funktionalen Sicherheit stets darauf hinaus gefährliche Fehler zu vermeiden bzw.zu beherrschen. Diese sind immer in Hinblick auf den Verlust der Sicherheitsfunktion zu betrachten. Unter einem gefährlichen Fehler wird alles verstanden, was dazu führt, dass die definierte Sicherheitsfunktion bei Anforderung nicht verfügbar ist. Ein einfaches Beispiel ist eine Schutztürüberwachung: Die Sicherheitsfunktion soll beim Öffnen der Schutztür dafür sorgen, dass beim Betreten des Schutzbereichs keine Gefährdung für Menschen entsteht. Im einfachsten Fall bedeutet das ein gezieltes Abschalten der Maschine. In diesem Fall ist somit alles ´gefährlich´, was dazu führt, dass das Abschalten nicht erfolgt bzw. nicht erfolgen kann. Dies kann z.B. bereits durch einen Fehler bei der Montage im System verankert sein oder durch einen zufälligen Hardware-Ausfall der Logiksteuerung hervorgerufen werden. Analysiert man reale Fehlerursachen, lassen diese sich in zwei Hauptklassen einteilen: Systematische Fehler und zufällige Fehler. Zufällige Fehler treten nur in elektrischen/elektronischen Bauteilen auf und lassen sich grundsätzlich nicht vermeiden. Teil 2 der IEC 61508 begegnet dem damit, dass für definierte technische Elemente definierte (Bauelemente-)Fehler erkannt werden müssen, wie etwa Kurzschluss oder Unterbrechung eines elektrischen Widerstands, sofern diese zu einem gefährlichen Fehler führen würden. Erkannt wird der Fehler durch zusätzliche technische Diagnosemaßnahmen im Produkt selbst oder auf einer höheren Systemebene, z.B. Testpulse einer SPS. Die Erkennung löst dann eine Fehlerreaktionsfunktion aus, wodurch der erkannte gefährliche Fehler aus Sicht der Funktionalen Sicherheit nicht mehr relevant ist. In der Industrieautomation ist die übliche Fehlerreaktion das Ausschalten der Maschine. Durch die Diagnosemaßnahmen erhöht sich der Anteil der sicheren Fehler (SFF: Safe Failure Fraction), die aus Sicht der Funktionalen Sicherheit als gut anzusehen sind. Die Grundnorm IEC 61508 macht klare Vorgaben zwischen dem SFF, der sogenannten Hardware-Fehlertoleranz (HFT), und dem maximal erreichbaren SIL. Ein einkanaliges System hat eine HFT von 0, da ein einzelner Ausfall zum Verlust der Sicherheitsfunktion führen würde. Ein zweikanaliges System besitzt folglich eine HFT von 1. Mindestens zwei Fehler sind hier zum Ausfall der Sicherheitsfunktion erforderlich. Mit steigendem SIL steigen die Anforderungen an die HFT bzw. SFF. So lässt sich ein SIL 2 Gerät unter Verwendung von komplexen elektronischen Bauteilen in einen einkanaligen System mit einer SFF von mindestens 90% und in einem zweikanaligen System mit einer SFF von mindestens 60% erreichen. Der Systemarchitekt kann also mit den Parametern Redundanz und Diagnose arbeiten. Systematische Fehler können über den gesamten Produktlebenszyklus auftreten. Von einer fehlerhaften Spezifikation, über Design Fehler in der (Produkt-)Entwicklung, Installationsfehlern, bis hin zu Bedienungsfehlern im Betrieb. Folgerichtig fordert die IEC 61508, neben dem übergeordneten Functional Safety Management, im Teil 1 konkrete qualitätssichernde Maßnahmen für individuelle Phasen des gesamten Produktlebenszyklus in den Teilen 2 und 3.
Normen
Bild 1 zeigt die Zusammenhänge der verschiedenen gültigen Normen. Im Fokus stehen dabei die Normen der Funktionalen Sicherheit. Die diversen weiteren Normen, wie z.B. zur Erfüllung der EMV-Richtlinie oder Niederspannungsrichtlinie, sind nicht dargestellt. Gerade für Neueinsteiger ist es oft schwierig, sich in diesem Normendschungel zurechtzufinden, und die Beziehung der einzelnen Normen untereinander zu erfassen. Bild 2 dient hierbei einem leichteren Verständnis der Normenlage. Ausgangspunkt ist die Grundnorm für Funktionale Sicherheit IEC 61508, die Basis für mehrere Sektor-spezifische Normen ist. Wichtig ist in diesem Zusammenhang, dass die IEC 61508 selbst keine harmonisierte Norm ist. Der Anwender muss daher zunächst die für ihn geltende harmonisierte Norm finden. Bei einem sicherheitsgerichteten elektrischen Antrieb liegt z.B. mit der EN 61800-5-2 eine geltende Produktnorm vor. Diese verweist jedoch wieder zurück auf den Teil 1 der IEC 61508, für den gesamten Themenbereich des Functional Safety Managements, und auf den Teil 3 der IEC 61508, sofern die Gerätesoftware Einfluss auf die Sicherheitsfunktion hat. Noch komplizierter wird das Ganze dadurch, dass es für die Ebene Systemintegration im Maschinenbau mit der IEC 62061 und ISO 13849 zwei gleichberechtigte Normen gibt und sich der Systemintegrator für eine der beiden Normen entscheiden kann. Die Gründe hierfür liegen in der historischen Entwicklung als Elektronik und Software in die Domäne der Funktionalen Sicherheit in den 1990er Jahren einzogen. Der Komponentenhersteller ist daran interessiert, dass seine Produkte universell nach beiden Normen verwendbar sind. Da die IEC 62061 selbst eine Sektor-spezifische Ableitung der IEC 61508 ist, ergeben sich dadurch keine größeren Probleme. Aus der ISO 13849 hingegen, ergeben sich einige zusätzliche Anforderungen an die Produktentwicklung. Am augenfälligsten ist, dass die ISO 13849 anstatt des SIL einen sogenannten Performance Level (PL a bis e) definiert.
Produktlebenszyklus
Der Produktlebenszyklus soll nun genauer betrachtet werden. Hierzu greifen wir zunächst auf den Sicherheitslebenszyklus aus Teil 1 der IEC 61508 (Bild 3) zurück. Für die Identifikation der für den Komponentenhersteller relevanten Phasen ist es wichtig zu verstehen, dass hier eine ganzheitliche Systembetrachtung abgebildet ist. Aus Sicht der industriellen Automation sind die Lebenszyklen von Anlagenbetreiber, Maschinenbauer und Komponentenhersteller (von Sicherheitsbauteilen) verschachtelt dargestellt.Für den Komponentenhersteller stellt sich die Situation wie folgt dar: Die primären, für ihn relevanten Phasen, sind Phase 9 (Anforderungsdefinition) und Phase 10 (Realisierung, d.h. die Produktentwicklung und Tests im engeren Sinne). Sekundäre Phasen für den Komponentenhersteller sind die Phasen 12, 13, 14 und 16, für die er dem Systemintegrator/-betreiber über das Sicherheitshandbuch relevante Informationen mitteilt. Interessant ist, dass die für den Komponentenhersteller wichtigste Phase 10, in Teil 2 und Teil 3 noch weiter in die Phasen 10.1 bis 10.6 unterteilt sind. Häufig wird die Norm dahingehend missinterpretiert, dass die Unternehmensprozesse exakt diesen Phasen entsprechen müssen. Dies ist jedoch nicht der Fall. In den meisten Fällen ist es sinnvoller, die vorhandenen Prozesse als Struktur beizubehalten und Abweichungen zur Norm dort selektiv zu ergänzen. Klar aus der Norm ergibt sich allerdings die grundsätzliche Vorgehensweise – nämlich geplant und in sauber definierten Schritten vorzugehen. In der Praxis ergibt bei der Entwicklung einer sicherheitsgerichteten Komponente eine V-förmige Dokumentenstruktur, wie in Bild 4 zu sehen. Die Planung erfolgt im überlagerten Functional Safety Management Plan und im Verifikation- und Validierungs-Plan (V&V-Plan). Im Projekt entstehen dann schrittweise entlang des linken Astes die typischen Dokumente SRS, SDRS, Design Spezifikationen für die Hardware und Software und erst am Ende die klassischen technischen Unterlagen, wie Stromlaufpläne und Quellcode. Eine wichtige Anmerkung: Einerseits wird jede Phase bzw. jedes Dokument durch eine vorher festgelegte Verifikationstätigkeit (z.B. Review) geprüft und freigegeben. Die Dokumentation und Verifikation dienen u.a. dem Nachweis, dass die in überlagerten Dokumenten wie SRS und SDRS beschriebenen Safety-Requirements sich in der Architektur, Design, technischen Unterlagen, Stromlaufplänen und Quellcode wiederfinden und auch getestet werden können (Traceability). Andererseits werden bereits parallel die Testspezifikationen erstellt. Die Tests durchlaufen den rechten Ast des V von unten nach oben. Dabei werden die Tests entsprechend der erstellten Testspezifikationen durchgeführt und jeweils Testreports erstellt. Bei einer Komponentenentwicklung werden meist drei Teststufen unterschieden: Modultests für Hardware und Software, Integrationstests und Systemtests, inkl. dem obligatorischen Assessment. Unser Tipp: Binden Sie den Assessor möglichst früh ein, um die Safety Strategie im Projekt abzusichern. Dieser vermeintlich zusätzliche Aufwand in der frühen Projektphase zahlt sich später durch einen schnelleren Ablauf des Projekts aus.
