CIP Safety: Durchgängige Sicherheit kombiniert mit Feldbussen

CIP ist ein Industrieprotokoll, das auf mehreren Übertragungsschichten implementiert wurde: als DeviceNet (Basis CAN), ControlNet (speziell entwickelte Physik und spezieller Transportmechanismus), Ethernet/IP (Basis Ethernet mit TCP/IP und UDP/IP) und CompoNet (modifizierte RS485-Physik für Sensor-Aktor-Netzwerke). Wie die weitaus meisten der in der Industrie eingesetzten Feldbusprotokolle ist auch CIP in seiner Grundversion nicht für Anwendungen mit garantierter funktionaler Sicherheit entsprechend IEC/EN61508 einsetzbar. Mit CIP Safety wurde ein Sicherheitsprotokoll geschaffen, das die Vorteile von CIP (Skalierbarkeit, Durchgängigkeit, universelle Einsetzbarkeit) mit den Anforderung der IEC/EN61508 bis hin zu SIL3 (SIL = Safety Integrity Level) kombiniert. Dabei wurde, wie auch bei CIP, Wert darauf gelegt, ein Sicherheitsprotokoll zu definieren, das auf allen heutigen und auch zukünftigen CIP-Netzwerken durchgängig einsetzbar ist. In jedem Fall ist ein gemeinsamer Einsatz von \’Standard\‘- und \’Safety\‘-Geräten auf dem gleichen Netzwerksegment möglich, eine Abschottung zwischen \’sicheren\‘ und \’nichtsicheren\‘ Segmenten ist nicht nötig. Alle CIP Safety-Geräte besitzen neben den Funktionen für das Sicherheitsprotokoll auch eine \’nichtsichere\‘ Funktion, so dass die standardmäßigen Merkmale, z.B. das ID Object, mit ganz normalen CIP-Methoden abgefragt werden können. Sicherheitsmechanismen CIP Safety orientiert sich – wie alle anderen Protokolle für die funktionale Sicherheit auch – daran, welche Fehler prinzipiell im System auftreten können und legt geeignete Maßnahmen zur Abwehr dieser Fehler fest. Die in Bild 1 gelisteten Maßnahmen zur Fehleraufdeckung sind in Anlehnung an dem Grundsatz für die Prüfung und Zertifizierung von \’Bussystemen für die Übertragung sicherheitsrelevanter Nachrichten\‘ des BG Fachausschuss Elektrotechnik (Mai 2005) entstanden und zeigen die innerhalb von CIP Safety verwendeten Mechanismen. Grundsätzlich ist zu sagen, dass CIP Safety, wie die Mehrzahl der anderen Sicherheitsprotokolle auch, für Anwendungen in der Maschinensicherheit entwickelt wurde, bei denen ein zügiges Stillsetzen der Maschine zum sicheren Zustand führt. Anwendungen aus der Prozessautomatisierung, die ein Weiterbetreiben des Prozesses bis zum Erreichen des sicheren Zustands erfordern, benötigen u.a. redundante Übertragungswege, die derzeit bei CIP Safety nicht abgedeckt sind. Zeiterwartung über Zeitstempel In vielen Sicherheitsbussen wird lediglich eine Zeiterwartung ­(Time­out) verwendet, um unzulässige Verzögerungen der Nachrichten aufzudecken. Bei CIP Safety wurde diese Maßnahme als nicht ausreichend erachtet, da sie schleichende Verzögerungen in Routern nicht aufdecken kann. Es wurde daher ein Zeitstempel eingeführt; seine prinzipielle Funktionsweise ist in der CIP Safety-Spezifikation beschrieben. Neben der Aufde­ckung der schleichenden Verzögerung hat diese Maßnahme auch den Vorteil, dass bereits beim Empfang der Nachricht verifiziert werden kann, dass die Nachricht nicht unzulässig verzögert wurde. ID zum Senden und Empfangen Jede sicherheitsrelevante Nachricht wird mit einem Production Identifier (PID) versehen. Diese Kennzeichnung ist einmalig im System; sie wird aus der Identifikation des sendenden Geräts (Vendor ID, Device Type, Product Code), seiner Seriennummer und der Seriennummer der CIP Connection errechnet. Empfängt ein Teilnehmer eine Nachricht mit einer falschen PID, so geht er in den sicheren Zustand. Safety CRC Da die Maßnahmen zur Absicherung der Datenübertragungsschicht nicht mit sicheren Mitteln erzeugt werden, ist eine zusätzliche Maßnahme in Form einer Sicherheits-CRC erforderlich. CIP Safety kennt zwei Typen von Sicherheits-CRCs innerhalb der Sicherheitsnachrichten. Die kurze Form (8Bit lang) reicht zur Absicherung von 1 oder 2Byte Sicherheitsdaten aus, während die lange Form (16Bit lang) zur Absicherung von größeren Daten (3 bis 250Byte) verwendet wird. Die Zweiteilung ermöglicht bei kleinen Sicherheitsdaten eine ausreichend kompakte Form der Sicherheitsnachricht, die sich noch in einem einzelnen CAN-Rahmen (8Byte) von DeviceNet übertragen lässt. Redundanz mit Kreuzvergleich Diese Maßnahme wird bei langen Sicherheitsdaten (3 bis 250Byte) auf die doppelt übertragenen Datenpakete angewandt, während sie bei kurzen Sicherheitsdaten nur auf die doppelt übertragenen CRCs wirkt. Diversitäre Maßnahmen Dadurch, dass das Sicherheitsprotokoll nur in Sicherheitsprodukten implementiert wird, ist ein korrektes Versenden von Daten nach dem Format des Sicherheitsprotokolls durch \’nicht­sichere\‘ Geräte ausgeschlossen. Verfahren zur Zeitstempelung Da das Verfahren der Zeitstempelung innerhalb von CIP bisher nicht verwendet wurde, ist es hier vom Grundsatz her beschrieben. Alle CIP Safety-Daten werden mit einem Zeitstempel versandt, der den konsumierenden Sicherheitsknoten erlaubt, das Alter der produzierten Daten zu ermitteln. Diese Methode ist den konventionellen Empfangs-Timern überlegen. Empfangs-Timer können feststellen, wieviel Zeit seit dem letzten Empfang der Nachricht vergangen ist, aber sie treffen keine Aussage über das wirkliche Alter der Daten. Ein Zeitstempel erlaubt die Erkennung von Verzögerungen bei Übertragung, Buszugriff, Warteschlangen, Wiederholung und Routing. Die Zeit zwischen Producern und Consumern wird über \’Ping\‘-Anfragen und \’Ping\‘-Antworten koordiniert, siehe Bild 2. Nachdem eine Verbindung aufgebaut wurde, sendet der Producer eine \’Ping\‘-Anfrage, die den Consumer dazu veranlasst, mit seinem eigenen Zeitwert zu antworten. Der Producer stellt die Zeitdifferenz zwischen der \’Ping\‘-Anfrage und der \’Ping\‘-Antwort fest und speichert diese als Offset. Der Producer addiert diesen Offset zu allen anschließend versandten Zeitwerten. Wenn der Consumer einen Datenrahmen empfängt, subtrahiert er den Wert seiner internen Uhr und kann damit das Alter der Nachricht ermitteln. Solange das Alter niedriger liegt als der erlaubte Wert, werden die Daten verwendet, andernfalls geht die Verbindung in den sicheren Zustand. Das wird der Anwendung im Gerät mitgeteilt, so dass diese entsprechend reagieren kann. Die \’Ping\‘-Anfragen und -Antworten werden in regelmäßigen Abständen zur Korrektur der Uhrendrift in Producer und Consumer wiederholt. Struktur der Sicherheitsnachrichten Innerhalb von CIP Safety sind fünf unterschiedliche Formate (Sektionen) von Sicherheitsnachrichten definiert: – Short Data Section (1 oder 2Bytes) – Long Data Section (3 bis 250Bytes) – Time Stamp Section – Time Coordination Section – Time Correction Section Diese Sektionen, einzeln oder kombiniert versandt, bilden die sicherheitsgerichteten Nachrichten von CIP. Die ersten beiden dienen der eigentlichen Übermittlung von sicherheitsgerichteten Daten, während die verbleibenden Sektionen der Zeitstempelung und deren Koordination dienen. Bild 3 zeigt einen Satz von sicherheitsgerichteten Nachrichten unter Verwendung der Short Data Section. Die Nachricht vom Producer zum Consumer enthält somit Sicherheitsdaten und Zeitstempel, während die Nachricht in Gegenrichtung eine Bestätigung und die Uhrzeit des Consumers enthält. Bei Sicherheitsnachrichten, die multicast versendet werden, siehe Bild 4, wird zusätzlich noch eine Time Correction Section verschickt. Wird das Multicast-Verfahren auf DeviceNet verwendet, so trennt man die Time Correction Section ab und versendet sie mit kleinerer Frequenz getrennt. Dadurch wird die maximale CAN-Rahmenlänge (8Byte) bei kurzen Sicherheitsnachrichten (1 oder 2Byte) nicht überschritten. Objekterweiterungen Es wurden die folgenden Erweiterungen des CIP-Objektmodells für CIP Safety vorgenommen: – Erweiterungen bestehender Objekte – Neue Objekte für die Konfiguration und Überwachung von sicherheitsgerichteten Verbindungen – Neue Objekte für sicherheitsgerichtete Ein-/Ausgänge Die Erweiterungen bestehender Objekte wurden beim ID Object (Class Code 0x01), beim DeviceNet Object (Class Code 0x03), beim Connection Configuration Object (Class Code 0xF3) und beim TCP/IP Object (Class Code 0xF5) vorgenommen. Das ID Object wurde in seinem Verhalten an die Erfordernisse der Sicherheitstechnik angepasst, ohne dass Erweiterungen im Attributbereich nötig waren. Das DeviceNet Object und das TCP/IP Object wurden um ein Attribut erweitert, nämlich die Safety Network Number. Mit diesem Wert (6Byte groß) lässt sich ein Sicherheitsnetzwerk über alle CIP-Netzwerke hinweg eindeutig zuordnen. Die Vergabe des Wertes erfolgt automatisch über ein Konfigurationstool oder manuell. Das Connection Configuration Object wurde bisher in der Hauptsache in Verbindung mit der Konfiguration von Verbindungen in ControlNet- und EtherNet/IP-Netzwerken verwendet. Seine Anwendung wurde auf alle CIP Safety-Netzwerke erweitert; das bei DeviceNet hauptsächlich verwendete Master/Slave Connection Set ist für die komplexen Konfigurationsvorgänge in Sicherheitsnetzwerken weniger geeignet. Um alle Anforderungen an Sicherheitsnetzwerke erfüllen zu können, wurden fünf weitere Attribute geschaffen, mit denen die sicherheitsrelevanten Parameter der einzurichtenden Safety-Verbindung beschrieben werden. Für die bereits existierenden Attribute wurden einige Erweiterungen und Einschränkungen vorgenommen, ferner wurde das Verhalten an die Anforderungen der Sicherheitstechnik angepasst. Die sicherheitsgerichteten Verbindungen der CIP Safety-Geräte werden während der Konfigurationsphase vom Safety Supervisor Object (Class Code 0x39) in Zusammenarbeit mit dem Connection Configuration Object überwacht. Erst nachdem alle Verbindungsdaten durch dieses Objekt validiert wurden, kann die Verbindung in Betrieb genommen werden. Den laufenden Betrieb der Safety-Verbindung überwacht dagegen das Safety Validator Object (Class Code 0x3A). Weichen die gesendeten oder empfangenen Daten von den für die jeweilige Safety-Verbindung festgelegten Werten, z.B. Datenlänge, Timing oder Safety-CRC, ab, so schaltet das Safety Validator Object die Verbindung in den sicheren Zustand und teilt das der Applikation mit, siehe Bild 5. Analog zu den bereits existierenden Objekten für digitale Ein- und Ausgänge wurden für die sicherheitsgerichteten Ein- und Ausgänge die Objekte Dis­crete Safety Output Point (Class Code 0x3B), Discrete Safety Input Point (Class Code 0x3D), Discrete Safety Output Group (Class Code 0x3C), Dis­crete Safety Input Group (Class Code 0x3E) und Dual Channel Safety Output Group (Class Code 0x3F) definiert. Gegenüber den \’nichtsicheren\‘ Varianten sind diese Objekte allerdings in ihrer Funktion eingeschränkt, da die vielfältigen applikationsspezifischen Möglichkeiten der Normalvarianten in der Sicherheitstechnik naturgemäß nicht erlaubt sind. Neue Profile Der grundsätzliche Aufbau eines CIP Safety-Gerätes ist in Bild 6 gezeigt. Damit folgt die Objektstruktur der eines \’nichtsicheren\‘ Gerätes, erweitert um die für die Sicherheitskommunikation notwendigen Objekte. Alle Details dieser Struktur werden in den Geräteprofilen für CIP Safety-Geräte beschrieben. Zurzeit ist nur ein weiteres Profil definiert, nämlich das Safety Discrete I/O Profile (Device Type 0x23). In diesem Profil sind alle Eigenschaften von sicheren E/A-Geräten zusammengefasst. Die verschiedenen E/A-Typen und -Größen sind darin über eine Vielzahl von Assemblies festgehalten. Konfiguration Bevor Sicherheitsgeräte in einem Sicherheitssystem benutzt werden können, müssen diese zunächst konfiguriert werden, und es müssen die Verbindungen für den Datenaustausch eingerichtet werden. Beim Konfigurationsprozess werden die Konfigurationsdaten von einem Konfigurationstool in ein Sicherheitsgerät übertragen. Dabei gibt es zwei Möglichkeiten für den Ablauf: – Direkte Übertragung zum Sicherheitsgerät – Übertragung über zwischengeschaltetes Gerät Im ersten Fall schreibt das Konfigurationstool die Daten direkt ins zu konfigurierende Gerät, während im zweiten Fall das Konfigurationstool die Daten in das Gerät überträgt, welches anschließend die Sicherheitsverbindung eröffnet. Die Konfigurationsdaten für das Zielgerät werden dann bei Eröffnung der Sicherheitsverbindung mit übertragen. Verbindungseröffnung CIP kennt bereits einen allgemeinen Mechanismus zur Eröffnung einer Verbindung, den so genannten ForwardOpen-Dienst. Für CIP Safety wird dieser Dienst durch ein weiteres Segment, das so genannte Safety-Segment, erweitert. Wie auch beim bisherigen Forward­Open-Dienst können Konfigurationsdaten in einem Datensegment angehangen werden, so dass die beiden oben beschriebenen Fälle der Konfiguration abgedeckt werden können. Der ForwardOpen-Dienst mit Erweiterung um das Safety-Segment wird dann SafetyOpen genannt. Da der ForwardOpen-Dienst von Natur aus bereits die Verbindungseröffnung über Router hinweg mithilfe von Portsegmenten unterstützt, ist das natürlich dann auch bei verkoppelten CIP Safety-Netzwerken möglich. Damit lässt sich dann z.B. EtherNet/IP als schnelles Backbone-Netzwerk zur Kopplung mehrerer DeviceNet-Netzwerke verwenden. Lokale Sicherheitsnachrichten werden im jeweiligen Netzwerk, netzwerkübergreifende Nachrichten über den Backbone ausgetauscht. Die notwendigen Verbindungen werden in einem solchen Fall direkt zwischen den Sicherheitsgeräten in den verschiedenen Netzwerken etabliert. Der große Vorteil von CIP Safety liegt darin, dass die Koppler zwischen den verschiedenen Netzwerken wie auch sonstige aktive Infrastruktur (Switches im Ethernet-Segment) selbst nicht sicherheitsertüchtigt sein müssen. Zusammenfassung Mit CIP Safety ist ein Sicherheitsprotokoll geschaffen worden, das nahtlos an die bereits existierenden \’nichtsicheren\‘ CIP-Protokolle DeviceNet, ControlNet, Ethernet/IP und CompoNet anknüpft. Durch das direkte Routen von Sicherheitsverbindungen über mehrere CIP-Netzwerke hinweg ist CIP Safety von vorneherein skalierbar, vom einfachen DeviceNet-Netzwerk bis hin zu fabrikweiten Netzwerken auf der Basis von Ethernet/IP. Derzeit stehen Steuerungen und Endgeräte für CIP Safety auf DeviceNet und auf EtherNet/IP zur Verfügung. An einer Erweiterung von CIP Safety auf Sercos wird derzeit gearbeitet; Spezifikationen und erste Geräte dazu sind in Kürze zu erwarten.