Modulare Sicherheitssteuerung

Die zentrale Idee der neuen Sicherheitssteuerung ist die Modularisierung, die nicht nur auf das Steuergerät beschränkt ist sondern sich bis in das Design der Architektur und den Softwareentwurf erstreckt. Dadurch ist es möglich aus den Basismodulen, also den E/A-Modulen sowie dem Netzteilmodul, bereits komplette Safety-Steuerungen aufzubauen. Voraussetzung dafür ist die Verteilung der Steuersoftware auf die Module. Mit der Leistungsfähigkeit heutiger Mikrocontroller Units (MCUs) stellt dies jedoch kein technisches Problem mehr dar. Dabei wurde berücksichtigt, dass Safety-Funktionen, wie z.B. von der PLCopen Safety Group vorgeschlagen, mit einer grafischen Funktionsbausteinsprache erstellt werden können. Modularisierung, definierte Schnittstellen und Wiederverwendbarkeit sind dabei auch die Methoden der Wahl, wenn es um die Zertifizierung geht. Nur damit lassen sich die enormen Entwicklungskosten für SIL3-Produkte senken. So sind auch die Steuermodule selbst in Teilmodule und Funktionsgruppen gegliedert, sowohl vom Hardware-Design als auch von den Softwarefunktionen. Durch klar definierte Schnittstellen kann jedes Modul leicht verändert oder erweitert werden, ohne dass der gesamte Zertifizierungsprozess noch einmal durchlaufen werden muss. Das transCon-S-Systemkonzept (Modularität, Architekturbaukasten, integrierte Safety-Technologie) bildet die Plattform für ein weites Anwendungsspektrum in der Automatisierungstechnik. Die Safety-Technologie öffnet den transCon-S-Anwendern eine wichtige funktionelle Ergänzung und erlaubt nun die integrierte Lösung sicherheitsgerichteter Aufgabenstellungen. Safety Alle Safety-Module sind grundsätzlich zweikanalig aufgebaut, wodurch zwei Systeme parallel laufen und sich gegenseitig überwachen. Sobald auf einem Modul eine Abweichung detektiert wird, wird der sichere Zustand eingenommen. Die Module selbst bleiben aber für Diagnosezwecke betriebsbereit. Schaltet man mehrere Safety-Module parallel, können sogar fehlertolerante Systeme aufgebaut werden, die auch beim Ausfall eines Kanals sicher weiterarbeiten. Ein weiterer Vorteil dieser Architektur ist, dass sichere und normale Steuerungsfunktionen auf einem System kombinierbar sind. So können die Safety-Sensordaten auch für die Ablaufkontrolle oder einfach nur zum gemeinsamen Monitoren verwendet werden. Für den Prototypen wurden digitale Standard-Anschlüsse verwendet, wie sie z.B. auch im Bahnbereich eingesetzt werden. Durch die lange Erfahrung der Yacoub-Automation GmbH mit Steuergeräten für die Bahntechnik konnten wertvolle Erkenntnisse bezüglich der Robustheit und Verfügbarkeit in den Entwurf eingebracht werden. Durch die Verwendung des Architekturbaukastens ist aber gesichert, dass auch andere Prozess-Schnittstellen möglich sind bzw. kundenspezifische Anforderungen berücksichtigt werden können. Unterein­ander sind die Module mit zwei Bussen verbunden, von dem einer ausschließlich für das Safety-Protokoll verwendet wird. Von diesem Protokoll sieht die Software nur die Objekt-Schnittstelle, sodass der Bus im Prinzip auch gegen eine vergleichbare Technik ausgetauscht werden kann. Systemseitig werden die Module ebenfalls als Objekte verwendet, sodass bei gleichem Profil die Module, das heißt die Objekte, austauschbar sind. Damit erlangt das Steuergerät die gewünschte Plug&Play-Fähigkeit. Dies entspricht modernen Frameworks in verteilten Systemen (bzw. der sogenannten Middleware auf der Kommunikationsebene). Weiter gedacht können über spezielle Kommunikationsmodule (Bridges) auch beliebige Vernetzungen erstellt werden und damit Konfigurationen ermöglichen, die unter dem Begriff Cyber Physical System zu fassen sind. Ein echtes modulares System erfordert natürlich auch modulare Software. Laufen in \’normalen\‘ Systemen die Steuerungen üblicherweise auf einem dedizierten Kopfmodul, so ist es in modularen Systemen möglich, die Steuersoftware zu verteilen. Dadurch lässt sich dann sogar das Kopfmodul einsparen. Software Allerdings muss zur Anlage auch eine Entwicklungsumgebung erstellt werden, um deren Vorteile zu nutzen. Dies bedeutet einen hohen finanziellen Aufwand. Andererseits kann sich auch das Portieren von Software- und Laufzeitumgebungen auf ein modulares System als Handicap herausstellen. Hier zeigen sich die Vorteile der modellbasierten Entwicklung, wie sie bei FIRST erforscht werden. Für beide Wege gibt es nämlich kostengünstige Lösungen, die kurz skizziert werden sollen. Der Vorteil für den Anwender liegt auf der Hand: Er kann den Prozess durch seine Anforderungen lenken. Um die nötige Flexibilität zu gewährleisten, nutzt Fraunhofer FIRST neueste modellbasierte Techniken um die Entwicklungsumgebung für das modulare System aus Modellen zu erzeugen. Das zugrunde liegende Sprachmodell der Steuerung ist in der IEC61131-3 fixiert. Darauf aufbauend wurden Einschränkungen in der Sprachvielfalt definiert, wie sie auch in der PLCopen Safety Group beschrieben wurden, damit die Entwicklungsumgebungen auch im Safety-Bereich einsetzbar sind. Zu einer IDE mit einem Editor und Compiler kommt noch das Laufzeitsystem des Zielrechners und eine Debug-Umgebung. Als Grafik-Editor wurde beim Prototyp auf eine Java-Swing-Umgebung gesetzt, aus der auch der Compiler (basierend auf Modelltransformationen mit gentle) aufgerufen wird. In einer späteren Entwicklung wird das System in Eclipse integriert. Eine textbasierte Vorversion verwendete Eclipse bereits als Basis. Natürlich sind Portierungen auf .Net-Plattformen genauso möglich. Anderseits können auch die gängigen Entwicklungsumgebungen verwendet werden, soweit sie den Export der Programme ermöglichen (z.B. auf XML-Basis wie von PLCopen vorgeschlagen). Sicherheitsfunktionen Für die Sicherheitsfunktionen sollen Funktionsbausteine verwendet werden, sodass aus deren Modellierung sowohl der Editor als auch der Compiler und andere Werkzeuge ableitbar werden. Dies wird am Beispiel der Entwicklung sicherer Funktionsbausteine sichtbar. Für die Laufzeitumgebung auf dem Zielsystem müssen diese Safety-Funktionsbausteine zertifiziert werden. Hier waren die Erfahrungen von Fraunhofer FIRST bei der Realisierung Domänenspezifischer Sprachen (DSLs) von großer Hilfe. So konnte in kurzer Zeit der aus der PLCopen Safety stammende, sichere Funktionsbaustein implementiert werden. Dazu wurde eine DSL entworfen, die die Spezifikation fast eins zu eins übernehmen konnte und aus diesen Automaten C-Code generiert. Braucht man für die manuelle Implementierung eines etwas komplexeren Bausteins Tage, so lässt sich die Software hier auf Knopfdruck in Sekunden erzeugen. Ein weiterer Vorteil liegt in der hohen Flexibilität bei Code-Änderungen. Hierzu ist einfach der Compiler abzuändern, das heißt Codierungsfehler durch nachträgliche manuelle Änderungen sind ausgeschlossen. Ein tagelanges Suchen nach Fehlern wegen übersehener oder vergessener Änderungen ist nicht mehr nötig. Ein weiterer Vorteil liegt in der besseren Testbarkeit der sicheren Funktionsbausteine. Hierzu werden aus den Modellen (der spezifizierten Automaten) automatisch werkzeugbasiert Tests erzeugt, deren Testqualität (das heißt Testabdeckung) sich direkt ableiten lässt. Auch hier zeigte sich, dass Erweiterungen der Tests einfach und schnell möglich waren. Nicht unerwähnt bleiben sollte die Adaptierbarkeit unter besonderen Randbedingungen. Durch die kurzen Entwicklungszeiten ist es nunmehr möglich für die Anwender erweiterte oder eigene Safety-Funktionsbausteine zu schaffen. Das heißt auch hier kann flexibel auf die Wünsche der Kunden reagiert werden. Für die compilierten Sicherheitsfunktionen aus dem Editor wird ein kleiner Interpreter benötigt. Hier muss auf der Basis eines Laufzeitmodells eine Codierung vereinbart werden, die sowohl vom Compiler als auch vom Interpreter leicht verarbeitet werden kann. Basierend auf dem Modell der Funktionsbausteine mit Eingängen, Ausgängen und einem internen Zustand muss nur die Dateiweitergabe und das Schalten der Bausteine im erzeugten Code berücksichtig werden. Der Interpreter sorgt also nur für die Datenübertragung zwischen den Blöcken und stößt deren Verarbeitung an. Der größte Teil wird im Laufzeitsystem geleistet, das – wie oben beschrieben – erzeugt wurde. Für eine Simulation ist es unerheblich, ob der Code der Sicherheitsfunktion bereits auf dem Zielsystem läuft oder noch auf dem Entwicklungssystem. Ausschlaggebend ist die Unterstützung durch mächtige Werkzeuge, die durch die Flexibilität der Schnittstellen ermöglicht wird. Damit kann aber auch \’alt\‘-Software in den Prozess eingebunden werden, sie muss lediglich auf das gemeinsame Modell transformiert werden. Durch diese Unterstützung können auch Unstimmigkeiten in Spezifikationen – wie sie auch bei einigen Funktionsbausteinen der PLCopen gefunden wurden – frühzeitig entdeckt und behoben werden. Eine frühe Validierung hilft hier viel Zeit und Geld zu sparen. Die Konfiguration der modularen Steuerung ist unabhängig von der Entwicklungsumgebung. Letztendlich müssen die Variablen der Sicherheitsfunktion mit den Anschlüssen zur Prozessseite verbunden werden und die Sicherheitsfunktion muss verteilt werden. Dies wird in einem zusätzlichen Arbeitsschritt in der Entwicklungsumgebung geleistet. Dabei ist nur darauf zu achten, dass die Zuordnung zu den Modulen auch der Reihenfolge der Abarbeitung der Funktion entspricht, damit die Safety-Eigenschaften des Systembusses nicht verletzt werden. Daraus ergibt sich, dass die Ein-/Ausgabebelegung den Anschlüssen der Sicherheitsfunktion folgt und nicht umgekehrt. Eigentlich eine Selbstverständlichkeit. Fazit Zusammenfassend lässt sich sagen, dass die Erfahrungen von Yacoub Automation und Fraunhofer FIRST gezeigt haben, dass die Modularisierung der Hard- und Software von Steuergeräten wesentliche Vorteile im Entwicklungsprozess bietet. Für die Kunden lassen sich so Zeit- und Kosteneinsparungen realisieren, die einen Wettbewerbsvorteil mit sich bringen. Kasten: Gerätekonzept Das Gerätesystem transCon-S ist ein sicherheitsgerichtetes System modularer I/O-Komponenten für den Einsatz im SIL3-Bereich. Jedes Modul besitzt modulspezifische Aktor-/Sensorfunktionen mit einer internen Busschnittstelle. In einem Modul mit dem Schutzgrad IP20 ist die notwendige I/O-Funktionalität untergebracht. Die Anbindung an eine externe SPS ist über das Kopfmodul (FCU-Modul – Fieldbus Connection Unit) möglich. Das Gesamtsystem wird auf eine Hutschiene montiert. SPS/IPC/Drives: Halle 9, Stand 569