Funktionale Sicherheit Sicherheitsgerichtetes Embedded-System entwickeln

Sicherheit im System.
Sicherheit im System.

Die Sicherheits-SPS ist für viele Projekte die beste Lösung. Für andere Projekte lohnt es sich jedoch, eigens ein sicherheitsgerichtetes Embedded-System zu entwickeln. Mit einem geprüften Design-Konzept gelangen Entwickler zügig und sicher von einer Lockstep-CPU zur funktionalen Sicherheit auf Systemebene.

Still und heimlich hat die Norm ISO 13849:2008 im letzten Jahr ihren fünften Geburtstag begangen. In unseren Landen als DIN EN ISO 13849 bezeichnet, ersetzt diese Norm die 2007 zurückgezogene EN 954 und ist eine Umsetzung der »Richtlinie 2006/42/EG des europäischen Parlaments und des Rates ... über Maschinen... « – besser bekannt als Maschinenrichtlinie.

Der Bereich der funktionalen Sicherheit taucht im Alltag überall dort auf, wo wir uns auf Technik einlassen oder auf sie angewiesen sind, sei es in Fahrstühlen, in der Bahn, im Bereich unserer Fahrzeuge (Automotive), in der Avionik, an Produktionsmaschinen, in Kraftwerken oder in chemischen Anlagen.

Normen- und Begriffsvielfalt

Im Bereich der Maschinenrichtlinie begegnen uns oft neben ISO 13849 auch DIN EN IEC 62061 (vereinfacht ausgedrückt: das IEC-Pendant zur ISO-Norm) oder auch DIN EN IEC 61508.

IEC 61508 ist als Grundnorm für Sicherheit ausgewiesen und dient oft als Basis für andere Normen. Bereiche wie Software bzw. Software-Entwicklung für Anwendungen funktionaler Sicherheit verweisen dann nur auf sie. IEC 61508 und IEC 62061 verwenden im Wesentlichen gleiche bzw. ähnliche Terminologie, wovon ISO 13849 etwas abweicht. So sprechen die IEC-Normen von SIL (Safety Integrity Level), während ISO 13849 hier zwei unterschiedliche Begrifflichkeiten verwendet, die der PL (Performance Level) und die der Kategorien. Die Kategorien der ISO 13849 kommen von der inzwischen außer Kraft gesetzten EN 954 und fordern teils absolute Fehlererkennungsraten bzw. schreiben auch bestimmte Architekturen vor. SIL und PL andererseits verfolgen probabilistische Ansätze. Der wesentliche Unterschied hier ist, dass die probabilistischen Ansätze immer Fehler zugestehen, während die harte Interpretation der Kategorien vorschreiben kann, dass ein Fehler immer erkannt werden muss bzw. nicht zu einem unsicheren Zustand führen darf.

SPS oder Embedded System?

IEC 61508 spricht von E/E/PES-Systemen, also elektrischen, elektronischen oder programmierbaren elektronischen Systemen. Für uns von Interesse ist das PES. Möchte man ein PES einsetzen, so hat man die Qual der Wahl, die geeignete Norm entweder für eine SPS für sicherheitsgerichtete Anwendungen oder für ein anwendungsspezifisches Embedded-System zugrunde zu legen.

Eine SPS für sicherheitsgerichtete Anwendungen kann man von vielen Anbietern von der Stange erwerben, zumeist auch mit einem passenden Steuerungsprogrammiersystem. Die Sicherheits-SPS ist für viele Projekte die beste Lösung, denn hier kann auf bewährte Komponenten aufgesetzt und auf einer vergleichsweise hohen Abstraktionsebene gearbeitet werden. Allerdings ist für viele Projekte eine solche SPS ein teures Vergnügen, vor allem dann, wenn hohe Stückzahlen ähnlicher Geräte produziert werden sollen oder wenn spezielle Anforderungen in Hinblick auf Ein- und Ausgänge oder Kommunikation bestehen, die von Standardsystemen nicht befriedigt werden können. Sicherheitsgerichtete Embedded-Systeme andererseits können maßgeschneidert für ein Projekt entwickelt werden, bedeuten aber auch höhere Entwicklungszeit im Hardware- und Software-Bereich. Allzu oft geht auch neben der damit verbundenen späteren »Time to Market« ein höheres Projekt- und Kostenrisiko aufgrund der komplexeren und aufwendigeren Entwicklungstätigkeiten einher. Schön wäre es, ein projektspezifisches, sicherheitsgerichtetes Embedded-System mit der Entwicklungszeit einer sicherheitsgerichteten SPS entwickeln zu können. Dieser Traum ist momentan noch keine Realität, aber das Verwenden bestehender und verfügbarer Grundkomponenten ist auch hier eine Option, die Entwicklungszeit und Risiko dramatisch senken kann.