Members Only | Ezine | Links | Legal Notice | Contact us |

NEWS

Official release
Creating PLCopen
Compliant Libraries
v1.0

 


PLCopen OPC-UA
Client v 1.1
now released





PLCopen
Safe Motion v0.99
Release for Comments



PLCopen
presentations
available

 


 

 


 

 




 

 

 

PLCopen Safety - Sichere Funktionsbausteine in ihrer Anwendung

Provided by Bosch Rexroth





PLCopen Safety - Sichere Funktionsbausteine in ihrer Anwendung

Jochen Ost, Bosch Rexroth, BRC/PRM3
Reinhold Fischer, Bosch Rexroth, BRC/EPY
Michael Mühlbauer, Bosch Rexroth, BRC/ESM

PLCopen Safety – Safe Function Blocks in their Application

The independent association PLCopen, together with its members and external safety related organizations, are defining safety related aspects within the IEC61131-3 development environments. In order to support the users to apply all the different safety related standards the goal of the TC5 group is basically to simplify the programming procedure as best as possible. The easier it is the less mistakes can be made and the validation and certification will be speeded up. The approach is to define standard function blocks, a style guide and recommendations for the programming environment. The report shows the results in their application.

Safety, PLCopen, function blocks, certified, IEC61508, IEC61131, factory automation

1. Motivation

Allein in Europa sehen sich Maschinenbauer mit unzähligen Safety-relevanten Standards konfrontiert. Gerade kleinen Herstellern ist es nahezu unmöglich, all diese Standards zu kennen – geschweige denn diese zu implementieren ohne dass Performance und Funktionalität der Systeme darunter leiden und ohne dass beträchtliche Kosten entstehen. Insbesondere die zunehmende Bedeutung der Sicherheitstechnik in Anlagen und der voranschreitenden Ablösung diskret verdrahteter Implementationen durch flexibel programmierbare Sicherheitslogik konfrontiert den Applikationsprogrammierer mit einer unüberschaubaren Anzahl sicherheitsrelevanter Normen. Während in der Vergangenheit dem Anwender bei der Realisierung von diskreter Sicherheitstechnik „bewährte Techniken“ als Kochrezepte und Orientierungshilfen zur Verfügung standen, sucht dieser heute Hilfestellung, Sicherheitstechnik zuverlässig und zielgerichtet realisieren zu können.

Eine einfache Energiefreischal-tung ist längst nicht mehr die beste Maßnahme um Sicherheit zu garantieren. Die intelligente Antriebstechnik bietet hierfür eine Vielzahl von sicheren, zertifizier-ten Betriebsarten und Sicher-heitsfunktionen.(siehe Abb. 1). Der Anwender möchte diese Funktionalität nutzen können, ohne sich mit der hersteller-spezifischen Implementation im Detail auseinandersetzen zu müssen. Aufgrund der Vielzahl an unterschiedlichen Produkten verlangt der Anwender nach einer standardisierten Einbindung der Funktionalität in die Steuerung.

Vor allem die zunehmende Komplexität des Anwenderprogramms durch die verschiedenen Betriebszustände der Gesamtanlage und die voranschreitende Modularisierung der Maschine verlangen nach „ease of use“ Strukturen in der Ablaufsteuerung. Wie Abbildung 2 zeigt, ist zwischen der Systemebene und der eigentlichen Anwenderebene zu differenzieren. Die herstellerspezifischen Mechanismen bleiben dem Anwender im positiven Sinne verborgen. Der Wunsch besteht nach einem einfachen Interface, das die notwendigen Signale im Anwendungsprogramm „einfach“ anwendbar macht.



Abb. 2 - Einbindung von intelligenter, Antriebsbasierter Sicherheitstechnik

2. Aufgabe

Namhafte Firmen haben sich deshalb unter dem Dach der PLCopen TC5 die Aufgabe gestellt, das Thema Sicherheitsrelevante Applikationsprogrammierung für den Anwender praxistauglich und sicherer zu gestalten.

Die frühzeitige Mitwirkung von TüV und BIA garantiert, dass die Aktivitäten auch im Sinne der Zertifizierungsstellen stattfinden. Das ermöglicht eine Vereinfachung und Beschleunigung des gesamten Zertifzierungs- und Abnahmeprozesses. Der Leitsatz: „Je einfacher die Anwendbarkeit, desto minimaler ist die Gefahr für Mensch und Maschine“ gilt für den Anwender, die Abnahmestellen und die Versicherungs-gesellschaften gleichermaßen. Je niedriger das Risiko für fehlerhafte Programmierung ist und je einfacher Programme verifiziert werden können, umso einfacher gestaltet sich die Abnahme des Anwenderprogramms. Dies führt zur Verkürzung der Abnahme und trägt entscheidend zur Kosteneinsparung bei.

3. Ansätze

Eine wesentlicher Ansatz ist Safety Funktionalität auf einer „höheren“ Ebene, wie im Kapitel 1 als Anforderung formuliert, zur Verfügung zu stellen. Auf diese Weise lässt sich eine größere Unabhängigkeit von der unterlagerten Hardware erreichen und der Anwender muss sich nicht mit Details der herstellerspezifischen Implementierung befassen.

Aus diesem Grund wurden eine Vielzahl von standardisierten Funktionsbausteinen definiert, die dem Anwender die sicherheitsbezogenen Grundfunktionen bereitstellen und lediglich zu verknüpfen sind. Man beschränkt sich dabei auf die grafischen Programmiersprachen der IEC61131-3, um die Pflege und Lesbarkeit der Programme zu vereinfachen und den Abnahmeprozess zu beschleunigen.

Darüber hinaus wurden in einem Styleguide Programmierrichtlinien definiert, die dem Anwender eine zusätzliche Hilfestellung bieten. Im wesentlichen handelt es sich hier um organisatorische Maßnahmen, die durch eine konsequente Einschränkung der IEC61131-3 die Programmierung der Sicherheitsapplikation einfach, überschaubar und anwendbar gestalten.

3.1 Styleguide

3.1.1 Architekturmodell

Der grundlegende Ansatz zur Vereinfachung der Programmierung von sicherheitsrelevanten Programmen ist die strikte Trennung von Standard- und Sicherheitsfunktionalität sowie die eindeutige Zuordnung der entsprechenden Prozessperipherie. Der Datenaustausch zwischen beiden Bereichen findet definiert und gerichtet statt. Es können alle Signalzustände des Safety-Programms im Standard-Bereich gelesen, aber nur wenige, definierte Anwahl-


Abb. 5 - Architekturmodell

Signale aus dem Standard-Programm im Sicherheits-Programm verarbeitet werden.
Ein Anwahlsignal ist zum Beispiel die Anforderung Leistung zuzuschalten. Das Setzen des zugehörigen, sicherheitsrelevanten Ausgangs erfolgt exklusiv durch das Safety-Programm. So kann keine Bewegung erzeugt werden, solange das Safety-Programm nicht abgearbeitet wird und den sichern Zustand der Anlage garantiert.

3.1.2 Datentyp „SAFE“

Um die sicherheitsrelevanten Signale deutlich von Standard-Signalen zu unterscheiden zu können, wurde für die Kennzeichnung der Datentyp „SAFE“ definiert. Das zeigt dem Programmierer, dass es sich um sicherheitsgerichtete Signale handelt, die mit besonderer Sorgfalt zu behandeln sind. Außerdem kann aufgrund dieser Kennzeichnung eine automatisierte Verifikation von Datenverknüpfungen vorgenommen werden, die ein unzulässiges Verknüpfen von Standard-Signalen mit sicherheitsgerichteten Signalen aufdeckt. Auch wenn der Datentyp „SAFE“ nicht garantieren kann, dass der Signalzustand ein sicherer ist (z.B.) : bei Fehlverdrahtung der Peripherie), ist er jedoch ein organisatorisches Mittel zur Minimierung von Fehlern im Anwenderprogramm. Des weiteren wird bei der Abnahme des Anwenderprogramms sofort ersichtlich, welche Signale sicherheitsrelevant sind, was eine Überprüfung des Signalflusses vereinfacht und verkürzt.

3.1.3 Einkanalige Programmierung

Sämtliche steuerungsbezogene Mechanismen zur Erreichung des Sicherheitslevels sollen auf der Systemebene realisiert sein. Um die zweikanalige Struktur, den Kreuzweisen Datenvergleich sowie die Testmechanismen zur Fehleraufdeckung darf sich der Anwender nicht kümmern müssen. Signale werden wie im Standard-Programm einkanalig programmiert, was die Komplexität des Sicherheitsprogramms deutlich reduziert.

3.1.4 Basic- und Extended Level

Ein weiterer fundamentaler Ansatz ist, dass das Sicherheitsprogramm nur aus zertifizierten Funktionsbausteinen (siehe 3.2) besteht, die einfach grafisch mit einander zu „verdrahten“ sind. Begrenzt man dazu noch die Art der Verknüpfung (siehe 3.1.5), entsteht ein der heutigen Technik angepasstes Bild vergleichbar der diskreten Verdrahtung von Sicherheitsbauteilen. Die Programme sind überschaubar und können einfach gelesen werden. Außerdem wird die Abnahme des Programms deutlich verkürzt, da es aus vorab zertifizierten Bausteinen besteht. Die PLCopen bezeichnet diesen Programmiermode als BASIC Level.

Natürlich wird es Projekte geben, bei denen der aktuelle Stand von zertifizierten Funktionsbausteinen nicht ausreicht. Der Anwender kann dann im EXTENDED Level die notwendigen Bausteine erstellen. Hierfür steht ein erweiterter Befehlsumfang zur Verfügung. Die Abnahme der Funktionalität ist aber für derartige Bausteine und Programme ungleich aufwändiger und erfordert entsprechend mehr Zeit. Sind die Bausteine jedoch einmal zertifiziert, dann lassen sie sich im BASIC Level mit den genannten Vorteilen verwenden

Der Vollständigkeit halber sei erwähnt, dass für Hersteller von Sicherheitssteuerungen auch ein SYSTEM Level zur Verfügung steht, in dem z.B. : auch Implementationen in herstellerspezifischen Sprachen möglich sind.
Wie auch immer die Integration der verschiedenen Level im Programmiertool durch den Hersteller erfolgt, das Prinzip reduziert die Kosten für den Anwender durch die Vereinfachung des Abnahmeprozesses deutlich.

3.1.5 Einschränkungen

Zur Vereinfachung der Programmstrukturen wurde das IEC61131-3 System in Bezug auf Datentypen, Variablendeklaration, Standard-Funktionen und Standard-Funktionsbausteinen deutlich eingeschränkt und zusätzliche Regeln wurden definiert. Zum Beispiel sind im Basic Level nur die Standard-Funktionen „AND“ und „OR“ verfügbar. Die Verwendung von Operationen wie „XOR“, „NOT“, „ADD“, „SUB“, „MUL“, „“DIV“ usw. sind nicht vorgesehen. Die Programmierung ist damit reduziert auf die Verknüpfung fertiger Funktionsbausteine mit E/A-Signalen. Im Extended Level hingegen stehen diese Operationen zur Verfügung. Trotzdem stellt auch der EXTENDED Level nur ein Subset der IEC61131-3 zur Verfügung.

3.2 Funktionsbausteine

Alle Bausteine entsprechen einem allgemeingültigen Template und bauen auf ein einheitliches Diagnosekonzept auf. Sie werden als zertifizierte Spezifikation zur Verfügung gestellt und können als Basis für die Implementation dienen.

3.2.1. Template

Für die Spezifikation der Funktionsbausteine wurde ein Template als Vorlage definiert. Es besteht im Wesentlichen aus der Beschreibung der zur Anwendung kommenden Normen, der Requirement-Spezifikation, einer Funktionsbausteinbeschreibung der Beschreibung des Diagnoseverhaltens und einem State- sowie Timing- Diagramm zur Beschreibung des Bausteinverhaltens.

3.2.2. Diagnosekonzept

Allen Bausteinen liegt ein durchgängiges und einheitliches Diagnosekonzept zu Grunde. Dadurch wird gewährleistet, dass unabhängig von der Herstellerimplementation dem Anwender einheitliche Diagnoseinformationen in Form eines DiagCodes zur Verfügung stehen. Im Fehlerfreien Zustand wird im wesentlichen der Status des Funktionsbaustein-internen Zustands (State-Machine) angezeigt. Der Fehlerfall wird generell über einen binären Ausgang (Error) angezeigt. Detaillierte Informationen über bausteininterne bzw. externe Fehler können im DiagCode ausgelesen werden. Der Baustein ist entsprechend über den Reset Eingang zurück zu setzen.

Neben den Diagnosespezifischen Signalen verfügt jeder Baustein über einen Eingang zur Aktivierung des Bausteines. Über den Ausgang Ready wird die Betriebsbereitschaft des Bausteines angezeigt. Weitere Ein- bzw. Ausgangssignale sind bausteinspezifisch.

3.2.3 Beispiel Funktionsbaustein FB_SFReducedSpeed

Exemplarisch wird der Funktionsbaustein für die Anwahl einer sicheren reduzierten Geschwindigkeit vorgestellt. Die eigentliche Funktionaltiät für Sicheren Halt bzw. Sicher reduzierte Geschwindigkeit stellt der Antrieb bereit.


Abb. 6 – Funktionsbaustein SF_SafeReducedSpeed


Abb. 7 – Zustandsdiagramm – SF_SafeReducedSpeed

Default ist der sichere Zustand. Der sichere Zustand wird durch den SAFEBOOL Ausgang SafetyActive = TRUE bestätigt. Wenn innerhalb des sicheren Zustandes der SAFEBOOL Eingang Enabled = FALSE wird, geht der Antrieb in Halt. Abhängig von der Konfiguration des Antriebes kann dies entweder ein Sicherer Halt oder ein Sicherer Betriebs-Halt sein. Für die Ausführung einer Bewegung mir Sicher reduzierter Geschwindigkeit muss der SAFEBOOL Eingang Enabled = TRUE sein.

Wenn der SAFEBOOL Eingang OpMode = TRUE wird, verlässt der Antrieb den sicheren Zustand und der SAFEBOOL Ausgang SafetyActive wird auf FALSE gesetzt.
Im Falle eines Funktionsbaustein internen Fehlers verweist der WORD Ausgang DiagCode auf die Fehlerquelle, der BOOL Ausgang Error wird auf TRUE und der SAFEBOOL Ausgang SafetyActive wird auf FALSE gesetzt.

4. Anwendung

Die Anwendung der spezifizierten Safety-Funktionsbausteine soll im folgenden beispielhaft dargestellt werden. Eine wesentliche Voraussetzung ist natürlich, dass die organisatorischen Maßnahmen auch entsprechend im Programmiertool abgebildet sind.


Abb. 8 – Screenshot Programmierbeispiel

Abb. 8 zeigt die beispielhafte Verknüpfung der Bausteine mittels AND und OR Operanten. Die zertifizierten Bausteine sind bereits visuell als solche zu erkennen. Variablen vom Datentyp SAFE sind ebenfalls im Sinne der Anwenderunterstützung optisch hervorgehoben.

Wie im Fehlerfenster 2 zu sehen ist, wurde bereits vom Editor eine unzulässige Verknüpfung von Datentypen (BOOL mit SAFEBOOL) entdeckt. Der Programmierer erkennt dies zudem an der farblichen Unterscheidung zwischen Standard- und Sicherheitsrelevanten Signalen.

Es ist der Programmierlevel „BASIC“ ausgewählt. Dem Anwender steht nur ein reduzierter Funktionsumfang bzw. nur eine zertifizierte LIB zur Verfügung. Ein Wechsel in den EXTENDED Level ist natürlich jederzeit möglich, wenn weitere Bausteine benötigt werden.

Der Anwender erhält also bei der Programmierung größtmögliche Unterstützung, so dass schon bei der Programmeingabe Fehler erkannt und vermieden werden. Sei es durch entsprechende Compilerunterstützung oder durch konsequente Reduzierung der Komplexität. Die bei erster Betrachtung möglicherweise als Einschränkung wirkende Beschränkung des Funktionsumfangs hat den Vorteil, dass nur bereits zertifizierte Bausteine verknüpft werden, die Programme leicht nachvollzogen werden können und die Abnahme durch Zertifizierungsstellen deutlich verkürzt wird.

Vergleicht man abschließend die Realisierung der Sicherheitsfunktionalität in Form von „Software“ mit der klassischen Verschaltung von Sicherheitsbaugruppen, so liegen die Vorteile auf der Hand.

Diskret Programmiert
Ö Verdrahtung Ö Flexibilität in Bezug auf
· erzeugt Aufwand und Kosten · Modularität / Erweiterbarkeit
· Arbeitsprozess ist fehleranfällig · Modifikation
Ö Mangelnde Flexibilität · Funktionalität
Ö Platzbedarf Ö Inbetriebnahme-Unterstützung
· Tools und Wizards
Ö Verkürzung der Validierung
Ö Standardisierte und zertifizierte FBs
· Hardware und Hersteller unabhängig
· Einheitlich
· Vereinfachte Abnahme
Ö Nutzung von integraler Funktionalität
· z.B. ein Feldbus für Standard- und Sicherheitsperipherie
Tabelle 1 – Vergleich konventioneller mit zukünftiger Realisierung 5. Fazit und Ausblick

Zusammenfassend ist festzustellen, dass durch Standardisierung und „Ease of Use“ die Anwendbarkeit der Normen für den Anwender einfacher und überschaubarer wird und damit wesentliche Ansprüche der Zertifizierer und der Versicherer an die Programmierung von Sicherheitssteuerungen erfüllt werden. Nicht zuletzt durch die Bemühungen der PLCopen lässt sich die Programmierung einfach und sicherer gestalten und damit die Sicherheit im Gesamten steigern.

Der Umfang der zertifizierten Funktionsbausteine wird mit den Applikationen und der Weiterentwicklung der Sicherheitssteuerungen wachsen müssen. Dementsprechend werden Ergänzungen eine grundlegende Voraussetzung sein, insbesondere um den Programmiermode mit abgenommenen Bausteinen durchgängig, konsequent und mit all seinen Vorteilen nutzen zu können. Prinzipiell stehen sowohl dem Steuerungslieferant als auch dem Anwender die Möglichkeit einer Zertifizierung von Funktionsbausteinen offen. Die PLCopen und nicht zuletzt die Mitwirkenden der TC5 werden die Spezifikation von allgemeingültigen Funktionsbausteinen inklusive deren Zertifizierung weiter voran treiben und zur Verfügung stellen.