Die Leistungsfähigkeit eines Industrie-PC (IPC) ist in den letzten Jahren enorm gestiegen. Damit wurde erst die Grundlage dafür gelegt, Sicherheitsfunktionen in den IPC zu verlagern. Der Fortschritt fehlersicherer intelligenter Eingabe- und Ausgabe-Einheiten (Busklemmen) sowie der hohe Standard, den die fehlersichere Kommunikation über ethernetbasierte Protokolle, wie zum Beispiel Safety-over-Ethercat heute erreicht hat, tragen ebenfalls maßgeblich dazu bei, den IPC im Safety-Umfeld einsetzen zu können. Um das Grundprinzip eines fehlersicheren IPC zu verstehen, muss man sich zunächst vor Augen halten, worin die Funktion fehlersicherer Automatisierungssysteme besteht.

Die Aufgabe eines sicheren Automatisierungssystems ist die Erkennung von Fehlern mit nachweisbar hoher Wahrscheinlichkeit und die Einleitung einer sicheren Reaktion über die Peripherie. Um Fehler zu erkennen, werden üblicherweise redundante Hardware- und Software-Kanäle genutzt. Nur wenn die Kanäle zueinander konsistente Daten liefern, werden die Ergebnisse als korrekt betrachtet und weiter verwendet. Mehrere Hardware-Kanäle bedeuten zwangsläufig auch höhere Produktkosten.

Architektur des fehlersicheren IPC mit n redundanten Software-Kanälen und Anbindung an die sichere Kommunikation. Die Eingangsdaten werden nach Empfang codiert, redundant verarbeitet und wieder an die sichere Kommunikation übergeben.

© Beckhoff Automation

Für die Zertifizierung entsprechend internationaler Sicherheitsstandards ist nachzuweisen, dass es keinen Fehler gibt, der sich auf mehrere Kanäle in gleicher Weise auswirkt. Der Vergleich der Kanäle würde in diesem Fall erfolgreich verlaufen, so dass der Fehler nicht erkannt werden kann – man spricht dabei auch von einem Common Cause Failure (CCF).
Genau diese Eigenschaft ist aber bei der Nutzung der verschiedenen Prozessorkerne von Multi-Core-Prozessoren, die sich mittlerweile in einer Vielzahl industrieller PC-Systeme finden, sehr kritisch zu prüfen, da viele Ressourcen wie Speicherbereiche und interne Busse von mehreren oder sogar von allen Kernen gemeinsam genutzt werden. Effizienter ist dagegen der Einsatz mathematischer Methoden. Diese unterstützen ebenfalls die Verwendung von Multi-Core-Prozessoren, jedoch sind die Art der Aufteilung der Teilaufgaben auf die einzelnen Prozessorkerne und die Art der Nutzung gemeinsamer Ressourcen keine Sicherheitsmerkmale, deren sichere Beherrschung nachgewiesen werden muss.

Die aufgrund der erhöhten Performance problemlos mögliche Kombination aus mehreren Software-Kanälen mit verschiedenen mathematischen Codierungen erhöht die Güte der Fehleraufdeckung beziehungsweise senkt die Restfehlerwahrscheinlichkeit beträchtlich. Zwar steigt dadurch der benötigte Speicherbedarf (längere Datentypen, größere Anzahl von Operationen pro Kanal, mehrere redundante Kanäle) und die Bearbeitungszeit nimmt potenziell zu, da die Software-Kanäle tatsächlich sequenziell abgearbeitet werden; wenn aber leistungsfähige IPCs der aktuellen Generation für diese Zwecke zum Einsatz kommen, spielt dieser vermeintliche Nachteil keine Rolle. Neben der Redundanz im Sinne der mehrfachen Ausführung gleicher oder ähnlicher Aufgaben spielt die Datenredundanz eine immer größere Rolle. Diese kann auch als „mathematische Codierung“ aufgefasst werden. Das heißt: Aus den Originaldaten werden über eine Abbildungsvorschrift Bilddaten in einem neuen, viel größeren Wertebereich erzeugt. Wenn die Daten Werte annehmen, die zwar im Wertebereich liegen, aber nicht der Abbildungsvorschrift entsprechen, gehören sie nicht zum Code. Sie sind daher ungültig und können nur durch Fehler in der Datenhaltung oder -verarbeitung entstanden sein.

Das Grundprinzip des fehlersicheren IPC

Die hier verwendeten arithmetischen Codes basieren auf Primzahlen. Sie wurden 1989 erstmals ausführlich von P. Forin in einem Artikel mit dem Titel „Vital Coded Microprocessor Principles and Application for Various Transit Systems“ beschrieben. Der Artikel erläutert die Grundlagen zum Einsatz einer arithmetischen Codierung im Bahnumfeld. Konkrete Umsetzung fand diese Technik zum Beispiel in der Metro in Paris. In dem von Forin vorgestellten Ansatz werden die Originaldaten in einer vorgelagerten Einheit – zum Beispiel in spe­ziellen sicheren Sensoren – mit einer Primzahl A multipliziert und mit einem spezifischen Offset beaufschlagt. Wenn nach Abzug des Offset kein Vielfaches dieser Primzahl vorliegt, ist ein Fehler erkannt worden. Forin führt deshalb sogar eine 1-kanalige Lösung (1-kanalige Hardware und 1-kanalige Software) ein.

Wenn im Fehlerfall durch Zufall ein Vielfaches von A gebildet wird, kann der verfälschte Wert innerhalb der codierten Daten nicht erkannt werden. Die Wahrscheinlichkeit, dass ein Fehler nicht erkannt wird – sprich die Restfehlerwahrscheinlichkeit – berechnet sich daher aus 1/A. Der Wert von A muss dem zu erzielenden Sicherheitsgrad entsprechend möglichst groß gewählt werden. Eine wesentliche Verbesserung der Fehleraufdeckung lässt sich dabei durch eine Prüfung mit Hilfe verschieden codierter Daten mehrerer Software-Kanäle erzielen. Mit anderen Worten: Die Restfehlerwahrscheinlichkeit sinkt beim Einsatz mehrerer Kanäle beträchtlich.

Was ist nun der große Vorteil mathematischer Codierungen im Vergleich zu anderen Ansätzen, den PC „sicher“ zu machen? Die schnellen Innovationszyklen für die Mikroprozessoren lassen jeden hardwarebasierten Sicherheitsnachweis innerhalb kürzester Zeit hinfällig werden, wenn dieser Nachweis Eigenschaften der Hardware benutzt. Daher wären bei diesem Ansatz ständig neue Nachweise notwendig. Anders ist dies bei der Verwendung softwarebasierter Verfahren, wie eben mathematischer Codierungen: Aufgrund der bei diesem Ansatz gewählten, streng mathematischen Grundlage muss der Nachweis der Sicherheit nicht auf den jeweiligen Prozessor und dessen Umgebung Bezug nehmen.

Vielmehr bestimmen in diesem Fall die Eigenschaften des mathematischen Codes die Restfehlerwahrscheinlichkeit und damit verbunden den entsprechenden Safety Integrity Level – kurz SIL – nach IEC 61508. Aufgrund dieser Unabhängigkeit ist zudem die quasi gleichzeitige Ausführung sicherheitsrelevanter und nicht-sicherheitsrelevanter Steuerungsprogramme auf einem IPC möglich.

Die Entwicklungsumgebung

Aus dem erstellten Safety-Projekt wird automatisch eine Dokumentation generiert, welche alle relevanten Daten des Projektes detailliert und nachvollziehbar darstellt.

© Beckhoff Automation

Der fehlersichere IPC mit sicherer Datenverarbeitung benötigt allerdings auch eine geeignete Entwicklungsumgebung. Was dies betrifft, bietet die neue Software-Generation Twincat 3 von Beckhoff (siehe Kasten) einen eigenen Bereich zur Erstellung und Verwaltung sicherheitsrelevanter Anwendungen.Hier sind sowohl bereits bekannte sichere Logik-Baugruppen als auch der sichere IPC (Twincat Safety PLC) projektierbar. Dabei werden das Zielsystem und alle möglichen Eingabe- und Ausgabegeräte dem Projekt zunächst als so genannte Alias-Geräte bereitgestellt. Auf diese Weise lassen sich sämtliche sicherheitsrelevanten Einstellungen unabhängig von der verwendeten Hardware bereits im Voraus tätigen. Vor dem Ausführen des Projektes sind die Alias-Geräte den tatsächlich verbauten physikalischen Geräten zuzuordnen.

Die Programmierung der Logik erfolgt im neuen freigrafischen Editor. Die gewünschte Logik wird dabei mit Hilfe der Funktionsblock-Diagrammsprache (FBD) nach IEC 61131-3 in einer grafischen Darstellung spezifiziert und lässt sich zur besseren Übersicht in Netzwerken organisieren. Die Funktionsbausteine können dabei beliebig platziert und verbunden werden. Neben den bereits bekannten Funktionsbausteinen für die Logik-Baugruppen stehen für die Twincat Safety PLC zusätzliche vorzertifizierte Bibliotheken bereit. Darüber hinaus hat der Anwender die Möglichkeit, eigene Funktionsbausteine zu spezifizieren. Diese lassen sich entweder aus bereits vorhandenen Funktionsbausteinen bilden oder direkt in „Safety C“ programmieren.

Vor der Ausführung wird überprüft, ob die programmierte Logik nur aus bereits zertifizierten Funktionsbausteinen besteht oder die erstellte Anwendung einer erneuten Prüfung bedarf. Safety C stellt ein nahezu uneingeschränktes Derivat von Standard C dar. Der Programmierer kann dabei auf die aus der Programmiersprache C bekannten Kontrollkonstrukte, wie beispielsweise „If-Then-Else“’, „Switch-Case“ und die dort üblichen Datentypen zurückgreifen. Die so gewonnene zusätz­liche Funktionalität erlaubt es, Applika­tionen nach eigenen Wünschen zu strukturieren und erweiterte Funktionen zu programmieren, was auf ausschließlicher Basis von Funktionsbausteinen nur schwer zu realisieren wäre. Zur Unterstützung der Debug- und Testphase können die Programme untersucht werden, so, wie man es auch im Standard Visual Studio gewohnt ist. Online-Variablenwerte und Zustände der Funktionsblöcke werden dabei direkt in der grafischen Umgebung angezeigt und ermöglichen ein schnelles und einfaches Debuggen der Applikation. Zusätzlich ist das Projekt offline simulierbar.

Die Logik kann dadurch unabhängig von der später eingesetzten Hardware bereits vor dem Download getestet werden. Damit verkürzt beziehungsweise vereinfacht sich die Inbetriebnahme direkt vor Ort. Der Editor ist entsprechend den Sicherheitsrichtlinien IEC 61508 beziehungsweise ISO 13849 entwickelt und verfügt über einen automatischen Verifikationsmechanismus. Das heißt: Während es bisher notwendig war, das auf die Logikkomponente geladene Projekt wieder auszulesen, manuell zu überprüfen und die Korrektheit zu bestätigen, überprüft der automatische Verifikationsmechanismus selbstständig, ob das gespeicherte Projekt mit dem im Editor erstellten Projekt übereinstimmt. Eine geeignete Codierung der Daten stellt auch hier die Integrität sicher. Das beschriebene Konzept wurde in einem Prüfbericht des TÜV SÜD (Proof of Concept) bis SIL 3 nach IEC 61508 abgenommen. Das endgültige Zertifikat wird zum Entwicklungsabschluss vorliegen. Die notwendige sichere Ankopplung an die Prozess-Peripherie erfolgt über Safety-over-Ethercat. Der Safety-Editor ist mit Release vom Twincat 3 Anfang 2012 verfügbar.

Autoren: Prof. Dr. Frank Schiller ist wissenschaftlicher Leiter Safety und Security bei Beckhoff Automation.

Martin Früchtl arbeitet im Bereich Produktmanagement bei Beckhoff Automation.

Die Architektur von Twincat 3

Mit der eXtended Automation Technologie von Twincat 3 findet das Engineering im Rahmen des Microsoft Visual Studio statt. Hierbei integrieren sich die Tools für die Konfiguration von Motion Control und E/A genau so wie die Entwicklungsumgebung für IEC 61131. Direkt aus dem Visual Studio wird die Entwicklungsumgebung für C/C++ für Echtzeit-Applikationen und zum Beispiel C# für die Entwicklung nicht echtzeitfähiger Applikationen genutzt. Die Anbindung von Matlab/Simulink erfolgt über generierten C- oder C++-Code aus dem Realtime-Workshop.

Für das Engineering sicherheitsgerichteter Applikationen stehen ein freigrafischer Editor und ein Editor für die Sprache Safety C zur Verfügung inklusive entsprechender Debugging-Werkzeuge.
Die Runtime von Twincat 3 erweitert zudem die bisher bekannte Technologie in Richtung moderner Rechner-Architekturen. Das heißt: Die Runtime lässt sich auf verschiedene Kerne einer Multi-Core-CPU aufteilen, was die Performance deutlich steigert. Sowohl Engineering als auch Runtime können unter 64-Bit-Betriebssystemen genutzt werden. Dies gilt gleichermaßen für die Safety PLC, welche unter dem gleichen Twincat-Echtzeit-System läuft wie alle anderen Runtime-Umgebungen. Es ermöglicht außerdem den einfachen Austausch von Daten zwischen der Standard-Steuerung und der Safety-SPS.