Aufwendige Berechnungen zur flexiblen Raumüberwachung oder die Integration von Antriebssicherheitsfunktionen in die sicherheitsbezogene Steuerung erfordern oftmals eine Erweiterung der sicherheitsbezogenen Firmware. Im Maschinenbau werden häufig Steuerungen eingesetzt, die für die einfache Programmierung von Sicherheitsfunktionen ausgelegt sind und einem Sicherheitslevel entsprechen. Sie unterliegen der Maschinenrichtlinie oder der ISO13849. Beide Standards schränken den Sprach- und Funktionsausbau jedoch erheblich ein, weshalb von einer Low Variability Language – kurz LVL – gesprochen wird. Komplexere Funktionen werden gemäß der Norm IEC61508 entwickelt und der Firmware der Sicherheitssteuerung als festem Bestandteil hinzugefügt. Allerdings ist der Austausch der Firmware mit hohen Aufwendungen verbunden – sowohl beim Hersteller der Firmware als auch beim Anwender in den Maschinen und Anlagen. Phoenix Contact bietet daher eine flexible Lösung, bei der die Erweiterung zusammen mit dem Applikationsprogramm auf die sicherheitsbezogene Steuerung geladen wird. Das Adjektiv ‚flexibel‘ bedeutet in diesem Zusammenhang, dass nicht mit jeder neuen Funktion ein Firmware-Update notwendig ist.
Einfachere Realisierung in Hochsprache
Sicherheitsfunktionen mit komplexen Berechnungen erweisen sich insbesondere im Umfeld der Robotik als notwendig. Die kartesische Raumüberwachung bedingt zum Beispiel trigonometrische Funktionen mit Gleitkommakalkulation. Bei Berechnungen im Bereich der Roboterkinematik sind ebenfalls meist aufwendige arithmetische Operationen erforderlich. Solche Aufgabenstellungen lassen sich einfach in Hochsprache umsetzen, da es hier entsprechende Bibliotheken gibt, die sich bewährt haben. In der Programmiersprache C kann beispielsweise die Bibliothek math.h verwendet werden, bei der es sich um eine Standardsammlung mathematischer Funktionen handelt. Als weiteres Anwendungsgebiet sei die Implementierung von proprietären Sicherheitsprotokollen genannt. Damit in bestehenden Applikationen nicht das gesamte Netzwerk erneuert werden muss, lässt sich das eingesetzte Sicherheitsprotokoll als C-Funktion einbauen und dann weiter nutzen. Oftmals ist der dafür benötigte C-Code schon vorhanden und hat sich bereits etabliert. Sicherheitsbezogene Steuerungen sind häufig zweikanalig ausgeführt. Das heißt, dass zwei unabhängige Prozessoren den Code abarbeiten und das Resultat in einem Kreuzvergleich überprüfen, was die korrekte Ausführung des Programms sicherstellt. Auf diese Weise werden die sogenannten Common-Cause-Fehler verhindert. Um die Anforderungen der funktionalen Sicherheit zu erfüllen, lässt sich für jeden Kanal ein anderer Compiler verwenden. Der so erzeugte diversitäre Binärcode läuft sogar diversitär auf den Sicherheitssteuerungen ab. Dies wird auch als redundante Diversität bezeichnet. Weil die Funktionen direkt als Maschinencode auf die sicherheitsbezogene Steuerung geladen werden, zeigen sie sich meist als kompakter und deutlich effizienter als IEC61131-3-basierte Programme. Durch die direkte Abarbeitung in der Firmware ergibt sich somit ein Performance-Gewinn.
Zusätzliches Add-in zur Erzeugung einer Bibliothek
Zur Erstellung der C-Funktionen lässt sich die gewohnte und schon im Entwicklungsprozess eingesetzte Umgebung nutzen. Die Entwickler brauchen sich also nicht in ein neues Tool einzuarbeiten. Der kompilierte Code muss im standardisierten ELF-Format (Executable and Linking Format) vorliegen. Diese plattformunabhängige Lösung wird von vielen bekannten Programmiersprachen supportet. Durch die Verwendung von Standard-Entwicklungssystemen und -Programmiersprachen sowie standardisierten Dateiformaten können während der Entwicklung ebenfalls Standard-Tools zur Unterstützung eingesetzt werden, die z.B. nicht für IEC61131-3-basierte Programme verfügbar sind. Darunter fallen unter anderem Software-Werkzeuge zur Messung der Code-Abdeckung (Code Coverage), Software zur Feststellung der Testabdeckung oder lediglich einfache Anbindungen an Versionsmanagementsysteme wie GIT oder Subversion. Aus der Nutzung von Standard-Entwicklungssystemen resultiert darüber hinaus der Vorteil, dass sich das Programm mit einfachen Mitteln überprüfen lässt. Die zu generierenden Funktionen müssen allerdings gemäß den einschlägigen Normen – wie der IEC61508 – in der Full Variability Language (FVL) entwickelt werden. Dazu bietet sich häufig die Beauftragung eines geeigneten Dienstleisters an, der die Aufgabenstellung im Rahmen eines passenden Entwicklungsprozesses realisiert. Der erarbeitete Code muss anschließend in der richtigen Form mit der sicherheitsbezogenen Anwenderapplikation an die Steuerung gesendet werden können. Die Engineering-Software PLCnext Engineer des offenen Ecosystems PLCnext Technology stellt zu diesem Zweck ein zusätzliches Add-in bereit, das es dem Ersteller der sicherheitsgerichteten Funktionen erlaubt, eine abgeschlossene Bibliothek zu erzeugen. Dies geschieht innerhalb von PLCnext Engineer mit wenigen Mausklicks.
Beigefügtes Zertifikat
Um sicherzustellen, dass der Erzeuger der Bibliothek sowie der Code jederzeit identifizierbar ist, muss der Bibliothek ein Zertifikat beigefügt werden. Dieser Mechanismus stellt nach heutigen Maßstäben die beste Variante der Security-Absicherung dar. Die fertiggestellte Bibliothek lässt sich mit der in PLCnext Engineer enthaltenen Simulation der Sicherheitssteuerung sogar testen. Außerdem kann der Code über das verwendete Entwicklungssystem – wie etwa Visual Studio – anwenderfreundlich geprüft und von Fehlern befreit werden. Die eigens entwickelten Funktionen erweisen sich meist als Differenzierung zu anderen Anbietern. Durch die abgeschlossenen Bibliotheken, die nicht automatisch an jeden Steuerungsanwender geliefert werden, bleibt dem Hersteller der komplexen Funktionalität ein Wettbewerbsvorteil erhalten.
