Analyse sicherer Signalpfade

Bild 1a:Zweikanalig ausgeführten Applikation mit Not-Halt + Schutztür-Überwachung. Der Not-Halt wird im EmergencyStop-Baustein ausgewertet; die Schutztür im Guard­Monitoring-Baustein. Die sicheren Signalpfade sind gelb hervorgehoben. © KW-Software

Neben sicheren Signalen, die ihren Ursprung in einem sicheren Sensor beziehungsweise einem sicheren Eingangs­gerät haben, verarbeiten Sicherheitssteuerungen ebenso Standard-Signale. Diese stammen von „gewöhnlichen“ Feldkomponenten beziehungsweise stellen Prozesswerte der Standardsteuerung dar. Die gemeinsame Verarbeitung von sicheren Signalen und Standard-Signalen ist notwendig, weil eine Automatisierungsaufgabe oft nur durch eine gesamtheitliche Betrachtung zu lösen ist.

Beim kombinierten Einsatz von sicheren Signalen und Standard-Signalen ist bei der Programmierung darauf zu achten, dass die Standard-Signale keinen Einfluss auf die Sicherheitsfunktion haben. Konkret bedeutet dies, dass die sicherheitsgerichtete Abschaltung einer Maschine nicht von einem Standard-Signal beeinflusst werden darf. Ein Standard-Signal darf ein sicheres Signal nicht überbrücken und somit die sicherheitsrelevante Abschaltung verhindern.

Grafischer Projektvergleich

Bild 2: Grafischer Projektvergleich, der den Unterschied eines Programm-Arbeitsblattes zwischen zwei Projektständen darstellt. Geänderte Objekte sind blau, neue Objekte grün ... © KW-Software

Das Konfigurationsmanagement spielt im Lebenszyklus einer Anlage beziehungsweise Maschine und ihrer Sicherheitsfunktionen eine zentrale Rolle. Mit dem grafischen Projektvergleich wie er in Safeprog 3.00 realisiert wurde, lassen sich unterschiedliche Versionsstände eines Sicherheitsprogramms miteinander vergleichen und die Unterschiede visuell auf­bereiten. Der Projektvergleich beinhaltet den Vergleich der Projektstruktur, der Variablen-Deklarationen, der Parameter­definition und vor allem der Programmquellen der Funktionsbausteinsprache sowie des Kontaktplans. Beim Vergleich der Programmquellen werden folgende Unterschiede erkannt:

• neue Objekte,
• gelöschte Objekte,
• geänderte Objekte,
• verschobene Objekte.

... und gelöschte Objekte sind rot markiert. Die beiden Abbildungen zeigen den Vergleich derselben Sicherheitsfunktion in verschiedenen Versionsständen.

© KW-Software

Wichtig in diesem Zusammenhang ist, dass nur solche Unterschiede erkannt werden, die unmittelbaren Einfluss auf die Sicherheitslogik haben. So genannter Whitespace wird dagegen nicht berücksichtigt. Ändert sich die Positionierung der Objekte, ohne dass sich deren Abarbeitungsreihenfolge ändert, so wird diese Änderung als nicht relevant klassifiziert und nicht dargestellt. Der Vergleichsmechanismus agiert direkt auf den Programmquellen (PLCopen XML) und benötigt kein gültiges Com­pilat. Somit lassen sich auch Projekte miteinander vergleichen, welche aufgrund von Programmierfehlern nicht übersetzbar sind oder sich mitten in der Entwicklung befinden.

Der grafische Projektvergleich unterstützt also den Anwender letztlich darin, über alle Lebensphasen einer Sicherheitsanwendung hinweg Modifikationen am Sicherheitsprogramm auf einfache Art und Weise nachvollziehen zu können (Bild 2).

Strukturierter Text

Der Entwicklungsprozess für die Realisierung von Safety-Funktionen mittels programmierbarer Sicherheitssteuerungen ist durch die Anforderung geprägt, möglichst in allen Entwicklungsphasen Fehler zu vermeiden. Die Programmierung der Sicherheitsanwendung erfolgt deshalb in Programmiersprachen mit geringer Komplexität und eingeschränktem Funktionsumfang. Der Fachbegriff für diese Art der Programmiersprache lautet Limited Variability Language (LVL). Frei übersetzt könnte man dies als „Programmiersprache mit eingeschränkten Möglichkeiten“ bezeichnen.

Bild 3: Einfacher Dreisatz x = (c*b)/a – einmal in grafischer Programmierung mittels Funktionsbausteinsprache und einmal in textueller Programmierung mittels Strukturiertem Text umgesetzt. © KW-Software

Aufgrund der reduzierten Freiheitsgrade einer LVL wird die Fehlerwahrscheinlichkeit bei der Programmierung der Sicherheitsfunktion reduziert. Typische Vertreter einer LVL sind Kontaktplan und Funktionsbausteinsprache. Textuelle Programmiersprachen wie Anweisungsliste oder C gelten hingegen als Full Variability Language (FVL). Auf Deutsch: Eine FVL ist eine Programmiersprache mit vollem Funktionsumfang. Kennzeichnend dafür ist die Möglichkeit des nicht strukturierten Programmablaufs (Sprünge) oder der Zeigerarithmetik.

Einfache binäre Verknüpfungen lassen sich sehr leicht mit grafischen Programmiersprachen realisieren. Die zunehmende Komplexität von Sicherheitsfunktionen, speziell in den Bereichen Motion Control oder Prozesstechnik, zeigt jedoch, dass grafische Programmierung nicht immer die beste Wahl ist. Insbesondere bei numerischen Berechnungen ist die Schreibweise höherer Programmiersprachen wie Strukturierter Text (ST) weitaus intuitiver und greifbarer als bei grafischen Programmiersprachen (Bild 3).

Da aber einschlägige Sektornormen, wie die ISO 13849, die IEC 62061 oder die IEC 61511, den Einsatz einer LVL vorschreiben, hat KW-Software den in Safeprog 3.00 unterstützten Sprach- und Funktionsumfang für den Einsatz von Strukturiertem Text in der Sicherheitstechnik entsprechend reduziert. Dies führt dazu, dass ST nun als LVL gemäß einschlägiger Sektornormen gilt.

Die angewendeten Einschränkungen im Sprach- und Funktionsumfang richten sich dabei nach den Vorgaben der „PLCopen – Technical Committee 5 – Safety Software Technical Specification“. Die darin definierten Einschränkungen für grafische Programmiersprachen wurden für ST übernommen. So sind zum Beispiel bedingte Anweisungen oder Sprünge nicht verfügbar. Der Anwender kann damit komplexe Sicherheitsfunktionen auf Basis von ST implementieren und hält sich gleichzeitig im Geltungsbereich einschlägiger Sektornormen auf.

Der Editor zur Eingabe des ST-Quelltextes beinhaltet Autovervollständigung oder die Anzeige von Formalparameternamen von Funktionsbausteinen bereits während der Eingabe. Weiterhin gewährleistet sowohl eine syntaktische als auch semantische Analyse während des Editierens, dass Programmierfehler unmittelbar erkannt und dargestellt werden. Die Code-Erzeugung basiert auf zwei divers redundanten Compilern. Das heißt, der Laufzeit-Code für ein zweikanaliges System wird auf zwei unterschiedlichen Wegen erzeugt und die Compilate beider Pfade unterscheiden sich aufgrund der geplanten Diversität stark voneinander. Der Diagnose-Deckungsgrad erreicht dadurch einen hohen Wert bei einem gleichzeitig geringen Wert für Fehler gemeinsamer Ursache.

Die beiden Compiler erzeugen nativen und somit hoch performanten Laufzeit-Code für das sichere Laufzeitsystem Safeos. Für die Code-Analyse kommen dieselben Regeln zur Anwendung wie bei den grafischen Programmiersprachen. Durch diese Analyse des Daten- und Kontrollflusses wird der Anwender auf eine potenziell fehleranfällige Programmierung aufmerksam gemacht.

Kurzum: Strukturierter Text führt insbesondere bei numerischen Berechnungen zu einem leicht verständlichen und wartbaren Programm.

Autor:
Dr. Tobias Frank ist Manager Safety Software bei KW-Software in Lemgo.