Entscheidungshilfe Safety kaufen oder selber lösen?

Vorreiter in Sachen vernetzter Sicherheitstechnik sind vor allem Automobilhersteller, die in Fertigungsstraßen mehr und mehr dazu übergehen, auch sichere Signale über installierte Feldbusse oder Industrial-Ethernet-Netzwerke zu übertragen. So müssen nicht zwei getrennte Netzwerke aufgebaut, gewartet und gepflegt werden. Ein Netzwerk ist für alles zuständig: Prozessdaten, Energiemanagement und sichere Signale. Nach und nach setzt sich dieser Ansatz auch im Maschinenbau, in Fertigungseinrichtungen und in der Prozessautomatisierung durch. Hier gibt es jedoch nicht nur einen Standard, sondern ähnlich wie bei Feldbussen und Industrial-Ethernet-Lösungen haben sich unterschiedliche sichere Kommunikationsstandards etabliert, mit jeweils eigenem Protokoll und eigenen Konfigurationsmöglichkeiten. Diese Lösungen stehen im Wettbewerb − jeder Standard verwendet eigene Prinzipien für die Übertragung der sicherheitsgerichteten Signale. In Europa ist Profisafe verbreitet, in den USA Cip Safety. Safety over EtherCat hat sich im Maschinenbau etabliert, und in der Antriebstechnik greift man auf Sercos und Ethernet Powerlink zurück, dort sind also Cip Safety und OpenSafety gefragt. Ein international agierender Gerätehersteller wird auf alle vier Technologien treffen. Doch sich mit all diesen Standards zu beschäftigen ist aufwendig.

Allen Ansätzen gemein ist das „Black Channel“-Prinzip. Alles, was mit dem eigentlichen Übertragungsmedium zu tun hat, − die Ebenen 1 bis 7 der Übertragungsprotokolle im ISO-Schichtenmodell − wird als „Black Channel“ und damit als nicht sicherheitsrelevant betrachtet. Hierfür sind Standardkomponenten einsetzbar, wie man sie benutzen würde, um Echtzeitdaten über beispielsweise Profinet oder Ethernet/IP zu übertragen. Alle Sicherheitsfunktionen sind hierarchisch über dem Black Channel im sogenannten Safety Layer angeordnet und festgeschrieben. Dieses Prinzip wurde mit Zertifizierern wie dem TÜV ausgearbeitet und in internationalen Standards wie dem IEC 61784-3 festgeschrieben. So macht ein zusätzlicher Safety Layer oberhalb des Black Channel aus einem Standardbus ein System, mit dem sich zuverlässig auch sichere Signale übertragen lassen. Diesen Weg haben alle genannten Safety-Standards hinter sich – nur die Protokolle und Mechanismen einzelner Systeme im Safety Layer unterscheiden sich deutlich. Es bestehen Mindestanforderungen für den Black Channel, beispielsweise muss eine bestimmte Übertragungszuverlässigkeit in dem nicht sicherheitsrelevanten Bereich gegeben sein. Dies erfüllen die modernen Kommunikationssysteme jedoch zuverlässig. Im Safety Layer sind die relevanten zusätzlichen Prüfmechanismen hinterlegt, sodass sich über ein- und dasselbe Kabel Standarddaten wie sicherheitsrelevante Signale übertragen lassen. Beim Aufbau einer sicherheitsgerichteten Kommunikation muss der Entwickler so zwei Komponenten im Blick haben: die Standardkommunikation im Black Channel und den übergeordneten Safety Layer.

Kaum generische Lösungen

Wie geht ein Gerätehersteller vor, der ein derartiges System entwickeln möchte? Bei Standardanschaltungen ohne Sicherheitsfunktionen kommen oft generische Lösungen zum Einsatz. Kaum jemand wird einen Profinet-Stack selbst entwickeln. Hier bestehen viele Lösungsansätze auf Basis von FPGAs, ASICs, Stacks und Module, auf denen die komplette Hard- und Software für eine derartige Anschaltung vorliegt. Damit reduziert der Hersteller Entwicklungsaufwendungen und Entwicklungsrisiko deutlich, denn es muss nicht jedes Detail, jedes Bit und jede Spezifikation bekannt sein – der Entwickler kann sich auf anwendungsorientierte Aspekte konzentrieren. Im Gegensatz zur Standardkommunikation gibt es in der funktionalen Sicherheit bisher kaum generische Lösungen. Viele Entwickler realisieren Safety-Lösungen individuell oder beauftragen Dienstleister, was erhebliche Kosten verursachen kann: Eine Safety-Entwicklung muss strenge Entwicklungsgrundsätze gemäß Normen wie IEC 61508, IEC 62061, ISO 13849 oder IEC 61511 einhalten.

Während der Implementierung gilt es, das eigene Tun immer wieder zu hinterfragen, um zufällige Fehler zu beherrschen und systematische Fehler zu vermeiden. So müssen die Rollen bei Softwarecodierung und Softwaretests sowie Codereviews klar getrennt werden, was größere Entwicklungsteams erfordert. Die Dokumentation einer Safety-Entwicklung ist zudem sehr umfangreich, da jeder Entwicklungsschritt und jede Entscheidung dokumentiert werden muss. Ziel dieser Vorgehensweise ist, dass jeder einzelne Schritt verifiziert und jederzeit nachvollzogen werden kann und schließlich für die Zertifizierung die Wirksamkeit fehlervermeidender Maßnahmen belegt werden kann. Mit der erfolgreichen Zertifizierung ist der Sicherheitslebenszyklus jedoch nicht abgeschlossen. Vielmehr ist während des gesamten Produktlebenszyklus zu dokumentieren, welche Komponente in welchem Soft- und Hardwarestand an wen geliefert wurde oder was getan wurde, um auftretende Fehler zu beheben. Dies alles macht eine Safety-Entwicklung im Vergleich zu einer Standardentwicklung um den Faktor drei bis acht aufwendiger.

Wie könnte nun eine generische Lösung für den Safety-Teil aussehen? Zunächst ist wichtig, auch hier die beiden Blöcke Standardkommunikation und Safety klar zu trennen. Dafür wird der Safety-Block mit dem eigentlichen Safety-Protokoll in einer eigenen Hard- und Softwarekomponente gekapselt. In diesem Fall muss auch nur diese Komponente die aufwendigen Verifikationen und Zertifizierungsprozesse durchlaufen. Durch Trennen, Kapseln und das Schaffen einer definierten Schnittstelle (Black Channel) zwischen den Teilen wird der Aufwand reduziert. Zur sicheren Anwendung hin stellt so ein gekapseltes Modul beispielsweise fertig beschaltete, sichere 24-V-Eingangs- und Ausgangssignale bereit, an welche zum Beispiel ein Not-Aus-Taster direkt angeschlossen werden kann. Für die Standardkommunikation stellt Sicherheitsspezialist HMS „Anybus“-Kommunikationsmodule bereit. Darauf setzt ein Safety-Modul IXXAT Safe T100 auf, in dem dedizierte Hard- und Software den Safety Layer kapselt und abarbeitet. Die Kopplung zwischen beiden Modulen erfolgt über eine serielle Schnittstelle. Einsetzen lässt sich diese generische Lösung immer, wenn an einfachen Geräten die Sicherheitsfunktion nicht die Hauptfunktion darstellt und sich auf wenige digitale Eingänge und Ausgänge begrenzt. Ein typisches Anwendungsbeispiel ist ein Bediengerät mit Display und Tastatur, das nicht sichere Prozesse aufwendig grafisch visualisiert und die Parametereingabe ermöglicht. An solchen Bediengeräten gibt es meist einen einzelnen Not-Aus-Taster zum Deaktivieren des kritischen Prozessbereichs.

Neben der klaren Abgrenzbarkeit der Sicherheits- von der Hauptfunktion des Geräts ist eine Voraussetzung für den Einsatz einer generischen Komponente, dass deren Funktionsumfang für die sichere Anwendung ausreicht. Die hier vorgestellte Lösung beschränkt sich auf sichere E/A-Digitalsignale für Anwendungen bis SIL 3 oder Performance Level e. Komplexe, spezialisierte Sicherheitsgeräte, die sicherheitsrelevante Bereiche überwachen und bei denen Safety den Hauptbestandteil der Gerätefunktion darstellt, eignen sich meistens nicht für den generischen Einsatz.

Reduziertes Entwicklungsrisiko

Prinzipiell müssen alle Safety-Entwicklungen dieselben Schritte durchlaufen, ob es sich um eine individuelle Entwicklung handelt oder auf generische Komponenten bei der Realisierung zurückgegriffen wird. Jedoch vereinfachen sich einige Schritte bei Verwendung der generischen Lösung, weil der Entwickler geführt auf vorgefertigten Basismaterialien aufsetzen kann. Das Konzept besteht aus fertigen Hard- und Softwarekomponenten bis zum kompletten Safety-Modul. Dazu kommt ein TÜV-zertifizierter „Implementation Guide“, in dem die Schritte aufgeführt sind, die der Entwickler für eine erfolgreiche Zertifizierung der Sicherheitsfunktion mit der generischen Komponente in seinem Gerät gehen muss. So bekommt ein in Sicherheitsfragen wenig bewanderter Entwickler einen Leitfaden an die Hand, der ihm sagt, was konkret zu tun ist. Diesen ausgefüllten Leitfaden legt der Entwickler beim TÜV vor und reduziert so die Gefahr eines erfolglosen Zertifizierungsversuchs erheblich.

Eine generische Lösung reduziert Aufwand und Risiko für den Gerätehersteller, da der Safety-Lösungsanbieter das Risiko für die Safety-Komponente übernimmt. Insgesamt lassen sich so etwa 80 Prozent des Entwicklungsaufwands und 50 Prozent des Zertifizierungsaufwands einsparen. Sollte der Sicherheitsfunktionsumfang der hier vorgestellten Komplettlösung nicht ausreichen, bietet HMS kundenspezifische Entwicklungen auf Basis dieser Lösung sowie portierbare Safety-Stacks an.