Zyklische Tests erkennen Fehler Aufbau eines dreifach redundanten Sicherheitssystems

Autor / Redakteur: Dr.-Ing. Peter Dellwig / Reinhard Kluger

Zertifiziert nach SIL 3, konzipiert für Turbomaschinen kann ein Schutzsystem aber auch den kompletten Maschinenstrang sichern. Und weil es sich zudem modular ausbauen lässt, kann es der Anwender kostengünstig an seine Aufgaben anpassen. Der Sicherheitskern besteht aus redundant ausgeführten Mikrocontrollern, auf denen ein zertifizierter Sicherheitskern abläuft. Dem Maschinenbauer erspart all das aufwändige eigene Zertifizierungen.

Firmen zum Thema

( Archiv: Vogel Business Media )

Kleine Ursache, große Wirkung: Wenn Anlagen sehr komplex sind, kann allein der Ausfall eines Teilsystems die Produktion kräftig stören oder sogar vollständig lahm legen. Der Markt fordert deshalb hoch verfügbare und besonders sichere Systeme. Die Gebhardt Automation in Ennepetal entwickelte das vom TÜV Rheinland nach SIL3 zertifizierte Sicherheitssystem TMR, ein dreifach modular aufgebautes System. Neben den eigentlichen Sicherheitsanforderungen mit einer sehr hohen Fehleraufdeckung (>99%) legte man besonderen Wert auf die Diagnose der Prozesse und Systeme (HMI, offene Kommunikation, Datenaufzeichnung).

Innerhalb des TMR-Sicherheitssystem sind alle Eingangs-, Verarbeitungs- und Ausgangsgruppen dreifach redundant ausgeführt. In der Regel führt dies zu einer Hardware-Toleranz von 2 und mehr. In einigen wenigen Ausfall-Szenarien hat das System eine Hardware-Toleranz von 1, das heißt, ein einzelner Fehler beeinträchtigt das Gesamtsystem nicht. Jede Teilkomponente ist während des Betriebs austauschbar, und zwar per Hot-swap. Über alle Signalzustände wird eine Mehrfachentscheidung (Mid-Of-3, 2oo3) vorgenommen. Über abweichende Signalzustände werden entsprechende Fehlermeldungen generiert, die Prozessvisualisierung alarmiert darüber. So lassen sich innerhalb der Prozessvisualisierung jederzeit alle Systemzustände über zusätzliche Diagnosebilder abfragen.

Bildergalerie
Bildergalerie mit 8 Bildern

Zur Systemarchitektur: Die verwendeten intelligenten und sich selbst überwachenden analogen und digitalen Eingangskarten sowie die digitalen Ausgangskarten sind modular und in sich redundant aufgebaut. Die Systemarchitektur besteht aus drei unabhängigen Bussystemen. Auf jedem einzelnen davon können bis zu 16 Ein-/Ausgangskarten integriert werden.

Den sicheren Datenaustausch zwischen den einzelnen E/A-Karten steuert und überwacht auf jedem einzelnen Bussystem (horizontale Kommunikation) eine eigens entwickelte ICU (Industrial Controller Unit) mit einem integrierten Linux-Betriebssystem. Die einzelnen Prozessoren übernehmen dabei die Aufgabe eines „intelligenten Bus-Controllers“. Außerdem kommunizieren alle drei Prozessoren eines TMR-Systems mittels eines gemeinsamen Tri-Busses (vertikale Kommunikation) über spezielle „Four Port RAM“(FPR)-Karten untereinander. Alle verwendeten Systemkomponenten sind daher dreifach redundant aufgebaut.

Zum Sicherheitskern: Alle E/A-Karten arbeiten mit redundant ausgeführten Mikrocontrollern, auf denen jeweils ein zertifizierter Sicherheitskern abläuft. Ein intelligenter Fenster-Watchdog wurde durch einen zyklischen Austausch von Nachrichtenpaketen realisiert. Weiterhin zeichnet sich das System durch eine zeitliche und logische Programmablaufkontrolle aus.

„data exchange“-Modul läuft unter Linux

Das zyklische und zeitliche Abarbeiten sämtlicher Selbsttests (built-in tests) überwachen beide Mikrocontroller gegenseitig. Alle sicherheitsgerichteten Funktionen laufen innerhalb des Sicherheitskerns ab, der alle Maßnahmen zu einer sehr hohen Fehleraufdeckung beinhaltet. Die Wirksamkeit der Fehleraufdeckung wird durch die ständige Ausführung zyklischer Tests während des Betriebs nachgewiesen. Weiterhin sind die Kommunikationskanäle zwischen den einzelnen E/A-Karten redundant aufgebaut.

Infos zum Datenaustausch: Unter Linux läuft ein „data exchange“-Modul, das als Hintergrund-Prozess unter Linux zyklisch alle anfallenden Nachrichten zwischen den einzelnen E/A-Karten austauscht. Diese Aufgaben unterstützt ein entsprechendes Sicherheitsprotokoll, das die unterschiedlichen Nachrichtentypen (Request, Response usw.) und Adressierungsarten (point-to-point, multicast, broadcast usw.) unterstützt. Zur Zeit entwickelt man eine Erweiterung, um die anfallenden Daten zwischen mehreren TMR-Systemen sicher austauschen zu können.

Die Prozessdaten werden zyklisch von jeder Eingangskarte zu allen im System vorhandenen Ausgangskarten übertragen. Daher lassen sich auf jeder Ausgangskarte die analogen Eingänge einer „Mid-Of-3“-Auswahl und die digitalen Eingänge einer „2-out-of-3“-Auswahl zuführen. Ein zyklischer Datenaustausch findet zwischen allen Ausgangskarten statt, sodass die programmierbare Anwendersoftware verteilt auf mehreren Ausgangskarten abläuft. Dies wird unter anderem auch zum Abgleich interner Systemzustände (z.B. Nachführung der RS-Flipflops) verwendet. Weiterhin können optional zur Vorverarbeitung alle Daten zwischen den Eingangskarten ausgetauscht werden.

Ein „Event Corder“ hilft bei der Fehleranalyse

Darüber hinaus stellt das „Data exchange“-Modul die vollständige Funktionalität für das HMI mit dem komfortablen Programmiersystem „GA safeEdit“ bereit. Neben der eigentlichen Programmierung, die der Anwender in strukturierter Textform und/oder grafischer Blockdarstellung vornehmen kann, kann das System zusätzlich umfangreiche Funktionen zur Systemdiagnose und Fehlerstatistik bereitstellen. Es wird sowohl analoge als auch digitale Signalverarbeitung in SIL3 unterstützt. Zusätzlich können alle I/O-Daten im „Maintenance“-Mode für Loop-Checks und zur Funktionsprüfung der Anwendersoftware „geforct“ werden.

Zur Modbus-Kommunikation: Zum flexiblen Anbinden des Systems an übergeordnete Visualisierungssysteme steht unter Linux ein „modbus daemon“ bereit, mit dem sich alle E/A-Daten und interne Systemzustände sowohl über das Ethernet basierende „Open Modbus TCP“ – als auch über das serielle „Modbus RTU“-Protokoll auslesen lassen.

Darüber hinaus gibt es bereits einen „OPC Server“, der intern über das „Open Modbus TCP“-Protokoll zyklisch alle Daten einliest und per „Data Access“(DA)-Protokoll bereitstellt. Das bestehende „Open Modbus TCP“-Protokoll nutzt zusätzlich die Funktionalität „Event Data Message“, um zukünftig auch über den OPC Server alle prozessseitigen „Alarms & Events“ (AE-Protokoll) des Sicherheitssystems anbieten zu können. Das „Data exchange“-Modul selbst stellt alle Prozessdaten bereit. Um Rückwirkungsfreiheit zu gewährleisten, lassen sich diese intern sicheren Datensätze über ein System-Interface nur auslesen. Alle übergeordneten Start-/Stopp-Befehle sind daher zurzeit „hardwired“ auszuführen. Diese sollen zukünftig als „unsichere Daten“ über den „modbus daemon“ bereitgestellt und innerhalb der programmierbaren Anwendersoftware des verteilten Sicherheitssystems rückwirkungsfrei verarbeitet werden können.

Zur Datenaufzeichnung: Zum Aufzeichnen von Prozessdaten gibt es ein „datalog daemon“, ein Programm, das im Hintergrund alle Prozessdaten und alle internen Systemspannungen und Systemtemperaturen aufzeichnet. Außerdem können zusätzlich intern berechnete Größen aufgezeichnet werden. Die Aufzeichnung wird sowohl ständig als „Perma Store“ als auch ereignisgesteuert als „Event Corder“ vorgenommen. Beim „Perma Store“ zeichnet das Programm alle Prozessdaten kontinuierlich mit einer einstellbaren Abtastzeit (z.B. 1 Minute) über einen einstellbaren Zeitraum (z.B. 1 Tag, 1 Woche, 1 Monat) auf. Nach Ablauf der Zeit wird jeweils eine neue Datei angelegt. Diese Datensätze dienen in der Regel zur Langzeit-Überwachung aller Anlagen- und Maschinenkomponenten.

Der „Event Corder“ ist für die Fehlerdiagnose nützlich, dann nämlich wenn ein Störfall nachträglich zu analysieren ist. Die Daten zeichnet das Programm mit einer sehr schnellen Abtastzeit (z.B. 10 ms) über einen kürzeren Zeitraum (z.B. 6 min) zyklisch innerhalb eines Ringspeichers auf. Datensätze, die älter sind als der eingestellte Zeitraum, werden automatisch von neueren Datensätzen überschrieben. Als Triggersignal zum Abspeichern der Daten in einer Datei kann man wahlweise einen digitalen Ein-/Ausgang oder ein internes Signal definieren. Zusätzlich ist eine Nachlaufzeit (z.B. 1 min) zum verzögerten Abspeichern der Datei einstellbar, sodass innerhalb einer Datei z.B. die letzen fünf Minuten vor und eine Minute nach einem Ereignis zur Verfügung stehen. Dann wird eine neue Datei angelegt.

Datensätze bekommen einen Zeitstempel

Alle Datensätze werden zyklisch auf einer Compact Flash (2 GB) und/oder dem internem Flash Memory (32 MB) in komprimierter Form abgelegt. Der Zeitraum der Aufzeichnungen richtet sich nach dem Umfang der Prozessdaten, den eingestellten Abtastzeiten und dem frei verfügbaren Datenspeicher. Ist der minimal verfügbare Speicher unterschritten, löscht das Programm automatisch ältere Datensätze. Der Zugriff auf die einzelnen Datensätze ist mittels FTP nur nach Anmeldung (Passwort) möglich. Alle Datensätze bekommen einen internen Zeitstempel. Hierzu wird unter Linux über das „Network Time Protocol“ (NTP) eine zyklische Zeitsynchronisation vorgenommen. Die Konfiguration der Aufzeichnung, Abholung der Daten von der ICU mittels FTP und anschließende Analyse (Trend-, Kennfelddarstellung, Bode-Diagramm) erfolgt über ein externes Windows basierendes Programm. Zusätzlich gibt es einen Exportfilter zum Konvertieren von Datensätzen in das CSV-Format. Diese Daten lassen sich dann zum Beispiel per Excel-Format oder Datenbanken einlesen und weiterverarbeiten.

Zur Ereignisverwaltung: Die intelligenten E/A-Karten führen ständig umfangreiche Selbsttests durch. Die Ergebnisse dieser Tests sind auf den E/A-Karten als Selbstteststatistik in einem internen Flashspeicher hinterlegbar. Darüber hinaus werden von den E/A-Karten im Fehlerfall entsprechende Fehlermeldungen als Nachrichtenpaket übertragen. Diese Nachrichten stellt das Programmiersystem „GA safeEdit“ mit einem Zeitstempel versehen bereit. Und: unabhängig hiervon lassen sich die Nachrichten zur späteren Systemdiagnose auf der ICU selbst mittels dem „msglog daemon“ aufzeichnen. Diese Meldungen stehen wahlweise in dem flüchtigen Dateisystem des Arbeitsspeichers (RAM-Disk) und/oder innerhalb des integrierten Flash Memory in Form von komprimierten Textdateien zur Verfügung und sind mittels FTP (file transfer protocol) auslesbar. Ältere Dateien werden automatisch (nach etwa 2 bis 5 Jahren, einstellbar) gelöscht. In Zukunft soll die programmierbare Anwendersoftware auf der ICU direkt unter Linux ablaufen. Weiterhin soll ein sicherer Datenaustausch zwischen mehreren TMR-Systemen per Ethernet-Kommunikation ablaufen können. Die Unterstützung „unsichere Daten“ innerhalb des Sicherheitssystems ist geplant, eine analoge Ausgangskarte soll demnächst verfügbar sein. Außerdem sollen zusätzlich für den OPC Servern des Sicherheitssystems das „Alarms & Events“-(AE)-Protokoll bereitgestellt werden. Ein Protokoll, das bereits für das Standard-Regelungs- und Steuerungssystem verfügbar ist.

Standpunkt

Dr.-Ing. Peter Dellwig, Leiter Softwareentwicklung, Gebhardt Automation

„Mit Herausgabe der IEC 61511 ist der Bedarf an zertifizierten Schutzsystemen deutlich gestiegen. Für die Hersteller von frei programmierbaren Sicherheitssystemen hat sich die IEC 61508 als maßgebliche Norm etabliert. Dies gilt insbesondere für die Steuerungstechnik und trifft in Zukunft verstärkt auch für die Regelungstechnik zu.“

Dr.-Ing. Peter Dellwig (39) ist Leiter Softwareentwicklung der GEBHARDT Automation GmbH, Ennepetal.

(ID:178114)