Entwicklung sicherer Steuerungsapplikationen mit Safety-Automaten Development of PLC Safety Applications with “Safety Automata“ Prof. Dr.-Ing. Georg Frey, Universität des Saarlandes, Saarbrücken; Dr.-Ing. Rainer Drath, Dr. rer. nat. Bastian Schlich, ABB Forschungszentrum Deutschland; Dr. rer. nat. Robert Eschbach, ITK Engineering AG, Herxheim
Kurzfassung Dieser Beitrag definiert erstmalig „Safety-Automaten“ als Beschreibungsmittel sicherheitsge-
richteter Steuerungsfunktionen und schließt somit eine Lücke im methodischen Werk-
zeugkasten des Automatisierungstechnikers. Die Anwendung und Vorteile des Safety-Auto-
maten werden am Beispiel des Bausteins SF_Equivalent der PLCopen erläutert. Dazu erfol-
gen schrittweise die Spezifikation mittels Safety-Automaten, die Implementierung des Auto-
maten in einem ablauffähigen SPS-Code sowie die Ermittlung von Testfällen zur Überprü-
fung des Automaten und des lauffähigen SPS-Codes.
Abstract This contribution defines the „safety automaton“, a new description language for safety con-
trol functions. To illustrate the value of this description language, the specification, implemen-
tation and test case generation is explained by means of the function block SF_Equivalent of
the PLCopen.
1 Motivation Automaten gelten in der akademischen Welt als durchdrungen und bieten vielfältige und at-
traktive Analysemöglichkeiten. Leider entwickeln sie für reale Systeme häufig eine nur
schwer beherrschbare Komplexität, weshalb sie ihren Durchbruch in der industriellen Praxis
noch nicht erreicht haben. Für sicherheitsgerichtete Funktionen mit ihrer naturgemäß gerin-
gen Komplexität bieten sich Automaten als Spezifikationsmittel jedoch geradezu an. Die für
die Nutzung von Automaten benötigte zustandsbasierte Denkweise ist in der Automatisie-
rungstechnik und insbesondere in der SPS-Programmierung ein seit Jahrzehnten be- und
anerkanntes Mittel zur funktionalen Beschreibung von Programmen (SFC, StateCharts, Sta-
teFlow, etc.). Auch die PLCopen wendet Automaten zur Spezifikation sicherheitsgerichteter
Bausteine an [1]. Allerdings wird die dabei verwendete Automatenklasse nicht definiert, zu-
dem fehlen Hinweise zur Implementierung oder zum Test der Safety-Bausteine. Die Interpre-
tation der PLCopen-Automaten, der Weg zur Implementierung und zum Test von Safety-
Bausteinen muss sich daher jeder Anwender selbst erschließen. Dabei bieten Automaten
vielversprechende Mittel für die Automatisierung von Implementierung, Test und Verifikation,
siehe auch [2] und [3]. In Fortsetzung dieser Arbeiten verfolgt dieser Beitrag das Ziel, eine
systematische und belastbare Grundlage zur Verwendung von Automaten zur Spezifikation
sicherheitsgerichteter Funktionsbausteine zu schaffen. Dazu werden erstmalig die Klasse
der „Safety-Automaten“ definiert, Transformationsregeln zur Umsetzung in der SPS-
Programmiersprache SFC aufgestellt und anhand einer prototypischen Umsetzung des Bau-
steins „SF_Equivalent“ illustriert. Abschließend wird ein darauf aufbauender methodischer
Zugang zur Erzeugung von Testfällen vorgestellt.
2 Definition des „Safety-Automaten“ 2.1 Ziele und Anforderungen Mit der Definition des „Safety-Automaten“ werden folgende Ziele verfolgt:
1. Eindeutige Festlegung von Syntax und Semantik.
2. Reduktion auf das Wesentliche als Grundlage für die Vereinfachung der Kommunika-
tion zwischen Entwicklern, Anwendern und Prüfern.
3. Ausrichtung auf eine Ziel-SPS-Sprache als Basis zur leichten, eindeutigen, fehler-
vermeidenden und möglicherweise automatisierten Umsetzung in einer SPS-
Sprache.
4. Erschließung algorithmischer Zugänglichkeit als Basis für automatisierte Verifikations,
Generierungs-, Test-, Implementierungs- und Dokumentationsansätze.
Diskussionen mit Fachleuten innerhalb der GMA haben bezüglich des nötigen Funktionsum-
fangs zur Spezifikation von Safety-Funktionen folgendes Bild ergeben:
1. Es muss eine klare und einfache Trennung zwischen Ein- und Ausgaben im Automa-
ten erfolgen.
2. Die Ausgangsbelegung soll für jeden Zustand klar und eindeutig erkennbar sein, ins-
besondere bei einer im Ablauf visualisierten Form der Darstellung.
3. Hierarchien oder Modularisierung sind sekundär.
4. Nebenläufigkeiten wie im SFC führen im Zweifel zu schwerer nachvollziehbaren Ab-
läufen.
Diese Punkte legen nahe, das gewünschte Beschreibungsmittel als Zustandsautomat in
Moore-Darstellung mit Ausgaben an den Zuständen und Booleschen Verknüpfungen von
Eingangssignalen an den Transitionen auszuführen. Für die Transitionen werden zudem
Prioritäten und Zeitbedingungen sowie eine eindeutige Notation für die Aktivierung bzw. De-
aktivierung der Safety-Funktion benötigt. Der Einsatz von Prioritäten lässt sich zwar immer
durch eine geeignete Ergänzung der Transitionsbedingungen vermeiden, wird aber von An-
wenderseite gewünscht, um eine kompaktere Notation zu erreichen. Dies zeigt sich bei-
spielsweise auch bei der gerade stattfindenden Überarbeitung der IEC 61499, in der ECC
um Prioritäten erweitert wurde. Zeitbedingungen tauchen in Safety-Funktionen in Form von
Wartezeiten auf. Hier muss eindeutig festgelegt werden, wann ein Timer gestartet wird, wann
ein Reset erfolgt und wie der Ablauf der Zeit in Transitionsbedingungen verwendet werden
darf. Zusätzlich ist gerade hier auf eine einfache Umsetzbarkeit und Verifizierbarkeit zu ach-
ten. Aus diesen Gründen ist in der Definition die Abfrage der Zeitdauer vorgesehen, die sich
der Automat in einem Zustand befindet. Dies entspricht dem Schritt-Timer (StepName.T) im
SFC. Die entsprechende Uhr wird bei Eintritt in den Zustand gestartet und bei Verlassen des
Zustandes rückgesetzt und gestoppt. Eine Abfrage der Aufenthaltszeit ist nur an direkt von
diesem Schritt abgehenden Transitionen durch einen Vergleich mit einer Maximalzeit erlaubt
und sinnvoll. Um eine einheitliche Aktivierung bzw. Deaktivierung zu erreichen, sollten ent-
sprechende Variablen vorgesehen werden.
2.2 Der Safety-Automat - und Hinweise zur guten Modellierung Der Safety-Automat ist ein Automat vom Moore-Typ in der Form eines E/A-Automaten mit
Booleschen Ein- und Ausgängen [4]. Er enthält eine endliche Menge von Zuständen mit ei-
nem einzigen ausgezeichneten Anfangszustand. In der grafischen Notation werden Zustän-
de als Kreise, Langrunde oder Quadrate dargestellt und der Anfangszustand grafisch durch
einen Doppelkreis oder einen dickeren Rand hervorgehoben.
Mögliche Übergänge zwischen Zuständen werden in der grafischen Notation als Pfeile vom
Ausgangszustand zum Zielzustand dargestellt. Diese Transitionen hängen von Bedingungen
ab. Eine Bedingung ist ein Boolescher Ausdruck in den Eingangsvariablen des Automaten.
In jedem Zustand legt der Automat die Booleschen Ausgangsvariablen fest. Darüber hinaus
werden folgende Erweiterungen definiert:
1. Angabe von Prioritäten in Form nicht-negativer Ganzzahlen an den Transitionen (hierbei
ist der Wert 0 für die höchste Priorität vorgesehen)
Diese Erweiterung gilt der Vereinfachung der grafischen Notation, lässt ich aber immer
vermeiden bzw. für den Fall einer Konsistenzprüfung, einer Implementierung oder auch
der Testfallgenerierung durch geeignete Erweiterung der Schaltbedingungen ersetzen.
Hinweis zur guten Modellierung: Für zwei gegebene Transitionen T1 und T2 ausgehend
vom selben Zustand mit Schaltbedingung B1 und B2 lässt sich eine höhere Priorität für T1
dadurch erreichen, dass die Schaltbedingung für T2 in B2neu = B2 AND NOT B1 geän-
dert wird. Dieses Verfahren kann auf beliebig viele Transitionen geradlinig erweitert wer-
den.
2. Optionale Verwendung der Zeit, die der aktuelle Zustand bereits aktiv ist, in der Transi-
tionsbedingung durch Vergleich mit einer vorgegebenen Zeit.
Diese Erweiterung ist inhaltlicher Art. Hierzu wird angenommen, dass bei Aktivierung
eines Zustandes eine Uhr τ gestartet wird. Der Stand dieser Uhr kann dann in den nach-
folgenden Transitionen für Vergleiche mit einem vorgegebenen Wert in der Form „τ ≥
Wert“ verwendet werden. Eine Verwendung anderer Vergleiche wird für Safety-Automaten
abgelehnt. Die Prüfung auf Gleichheit sollte bei Zeiten aus grundsätzlichen Erwägungen
nicht vorgenommen werden. Die Prüfung, ob die abgelaufene Zeit kleiner als eine vorge-
gebene Zeit ist, könnte zu Schaltbedingungen führen, die ab einer gewissen Zeit nicht
mehr erfüllbar sind, was zu einer Verklemmung des Automaten führen könnte. Ein sol-
ches Verhalten ist unerwünscht.
Hinweis zur guten Modellierung: Eine gewünschte Bedingung der Form „τ < Wert“ kann
über eine Bedingung „τ ≥ Wert“ und einen zusätzlichen Fehlerzustand mit einer entspre-
chenden Rücksetzroutine problemlos realisiert werden, siehe Bild 1.
falsch
Start0000
!Error
0: timer <10 & Bedingung
Weiter0001
!Error
richtig
Start0000
!Error
ErrorC001
Error
0: timer >= 10
1: Bedingung
Weiter0001
!Error
Bild 1: Beispiel zur Verwendung von Timer-Vergleichen
3. Festlegung einer Eingangsvariablen zur Aktivierung der Safety-Funktion sowie einer Aus-
gangsvariable zur Anzeige der Aktivität. Zudem sollten Regeln für die Deaktivierung
(Übergang in den Anfangszustand) definiert werden.
Die Erweiterung 3 vereinfacht den Umgang mit Safety-Automaten, insbesondere wenn
hier mit einheitlichen Bezeichnern über eine Bausteinbibliothek (oder gar mehrere Biblio-
theken) gearbeitet wird.
Hinweis zur guten Modellierung: Es wird vorgeschlagen, wie in der PLCopen, den An-
fangszustand mit „Idle“, den Aktivierungseingang mit „Activate“ und den Aktivitätsausgang
mit „Ready“ zu benennen.
4. Der Safety-Automat erlaubt nur Boolesche Ein- und Ausgaben.
Eine darüber hinausgehende Erweiterung würde zwar neue Anwendungsfälle erschlie-
ßen, aber die automatische Prüfung und Testfallgenerierung beträchtlich erschweren. Im
Falle der Eingaben muss ohnehin auf eine Boolesche Transitionsbedingung abgezielt
werden. Kontinuierliche Prozessgrößen lassen sich auf Boolesche Werte zurückführen,
z.B. durch Überprüfung von Grenzwerten. Dies kann im Sinne einer Vorverarbeitung
außerhalb der Darstellung des Safety-Automaten ergänzt werden. Auch eine entspre-
chende Nachbereitung von Ausgaben ist, falls erforderlich, möglich.
Hinweis zur guten Modellierung: Der Zustand des Safety-Automaten gibt Aufschluss über
den Systemzustand und insbesondere über vorliegende Fehler. Die PLCopen schlägt in
diesem Zusammenhang die „Ausgabe“ von Fehlercodes bzw. Diagnosecodes in jedem
Zustand des dort verwendeten Automatenmodells vor. Nach Verständnis der Autoren soll-
ten diese Codes eindeutig sein, d.h. die entsprechende Information sollte bereits in der
Aktivität des Zustandes selbst vorliegen. Eine sinnvolle Benennung der Zustände sollte
eine entsprechende Zusatzdefinition überflüssig machen. (Die zusätzliche Ausgabe weite-
rer Information im Sinne einer Annotation, kann bei einer Implementierung bspw. in SFC
(siehe Kapitel 3) durch eine zusätzliche Funktion erfolgen.)
Eine formale Definition des Safety-Automaten wird in Anhang A vorgestellt.
2.3 Beispiel und Vergleich mit PLCopen
Zur Erläuterung des Safety-Automaten wird im Folgenden der Baustein SF_Equivalent der
PLCopen modelliert. Bild 3 stellt diesen Funktionsblock aus der PLCopen dar. Die Hauptauf-
gabe dieses Bausteins ist die Prüfung, ob die beiden Eingänge S_ChannelA und
S_ChannelB TRUE sind, beispielsweise durch Drücken zweier Schalter. In diesem Fall wird
am Ausgang S_Equivalent=TRUE ausgegeben. Ist einer der beiden Ausgänge FALSE oder
der Baustein inaktiv, so ist auch der Ausgang S_Equivalent=FALSE. Zusätzlich dazu werden
weitere Bedingungen überprüft und ggf. ein Fehler ausgegeben.
Bild 2: SF_Equivalent Funktionsblock aus [1]
Bild 3 zeigt den Automaten des SF_Equivalent Bausteins aus der PLCopen.
Bild 3: SF_Equivalent Baustein aus der PLCopen gemäß [1]
Vom Startzustand Idle gelangt man über Activate in den Zustand Init. Ab diesem Zustand ist
Ready=TRUE und die eigentliche Ausführung beginnt. In der Darstellung der PLCopen sind
etliche Werte und Transitionen nur implizit angegeben. Die Transition oben links, die ohne
Ausgangszustand mit Priorität 0 in den Idle Zustand geht, kann z.B. von jedem Zustand aus-
geführt werden, sobald Activate=FALSE ist. Die impliziten Ausgaben werden über die gestri-
chelten Linien umgesetzt. Oberhalb der oberen gestrichelten Linie ist Ready=FALSE und
unterhalb dieser Linie ist Ready =TRUE. Der Automat bedarf folglich einer menschlichen
Interpretation und verwendet gemischt formale und informale Ausdrucksformen.
Bild 4 zeigt den Baustein SF_Equivalent als Safety-Automaten. Alle Transitionen und Aus-
gangsbelegungen sind explizit definiert. Zur übersichtlicheren Darstellung wurden die lo-
gischen Operatoren anhand von Zeichen dargestellt: „!“ steht für NOT und „&“ steht für AND.
Idle0000
!Ready!S_EquivalentOut
!Error
Init8001
Ready!S_EquivalentOut
!Error
1: Activate
Wait for Channel A8014
Ready!S_EquivalentOut
!Error
Wait for Channel B8004
Ready!S_EquivalentOut
!Error
Error 1C001
Ready!S_EquivalentOut
Error
Error 2C002
Ready!S_EquivalentOut
Error
Error 3C003
Ready!S_EquivalentOut
Error
0: !Activate
3: S_ChannelA& S_ChannelB
1: S_ChannelA& !S_ChannelB
1: Timer>=DiscrepancyTime
2: !S_ChannelA
1: !S_ChannelA& !S_ChannelB
2: !S_ChannelA& S_ChannelB
2: ! S_ChannelB
1: !S_ChannelA& !S_ChannelB
1: Timer>=DiscrepancyTime
From Active Wait8005
Ready!S_EquivalentOut
!Error Safety Output Enabled8000
Ready!S_EquivalentOut
Error
3: S_ChannelB 3: S_ChannelA2: !S_ChannelA& !S_ChannelB
1: !S_ChannelA& !S_ChannelB
2: !S_ChannelA& !S_ChannelB
1: Timer>=DiscrepancyTime
1: !S_ChannelAXOR !S_ChannelB 0: !Activate
0: !Activate
0: !Activate 0: !Activate
0: !Activate
0: !Activate 0: !Activate
Bild 4: SF_Equivalent Baustein als Safety-Automat
2.3 Unterschiede zum Automaten der PLCopen Im Gegensatz zur Automaten-Verwendung der PLCopen [1] sind im Safety-Automaten alle
Transitionen explizit angegeben. Die PLCopen erlaubt hier einen „versteckten“ Übergang mit
Priorität 0 zum Anfangszustand sowie verborgene Übergänge, die sich aus informellen Er-
läuterungen ergeben. Im Safety-Automaten sind zudem in jedem Zustand die Werte
True/False für alle Ausgänge explizit angegeben. Die PLCopen verwendet hingegen auch
informale Zusatzinformationen im Text oder über Zonen - eine Fehlerquelle.
Der Safety-Automat des Beispielbausteines benötigt einen Zustand mehr als die Darstellung
der PLCopen. Dies liegt daran, dass die PLCopen bei der Ausgabe des Fehlercodes von der
Moore-Denkweise abweicht und diese Ausgabe im Zustand „Error 1, Error 2“ wie in einer
Mealy-Denkweise vom Vorgängerzustand abhängig macht. Im Safety-Automaten gilt die
Moore-Eigenschaft: Ausgaben hängen nur vom aktuellen Zustand ab. Deshalb wird der
Sachverhalt hier korrekt durch zwei Zustände „Error 1“ und Error 2“ dargestellt.
3 Überführung in SFC 3.1 Transformationsregeln vom Safety-Automaten zu SFC Die Umsetzungsregeln des Safety-Automaten nach SFC sind eine 1:1 – Umsetzung des Sa-
fety-Automaten gemäß
Tabelle 1.
Tabelle 1: Transformationsregeln vom Safety Automaten zum SFC
Element des Safety-Automaten Entsprechendes Element des SFC Zustand Schritt Variablenbelegung Aktion Kante Transition Kantenbedingung Transitionsbedingung
3.2 Beispiel Dieser Abschnitt zeigt eine prototypische Umsetzung des Bausteins SF_Equivalent mit dem
SPS-Programmiersystem CoDeSys. Bild 5 zeigt eine Instanz des Bausteins. Das Ergebnis
ist identisch zur Abbildung der PLCopen aus Bild 2.
Bild 5: Der Baustein SF_Equivalent in CoDeSys gemäß IEC61131
Bild 6 zeigt das zugehörige lauffähige SFC. Jeder Schritt des SFC entspricht einem Zustand
des Automaten. Jeder Schritt gibt die Ausgangsbelegung des Bausteins explizit vor. Alle
Zustandsübergänge sind exakt wie im Safety-Automaten modelliert.
Prioritäten sind in CoDeSys durch die geometrische Reihenfolge der Alternativzweige von
links nach rechts modelliert. Der DiagCode lässt sich nicht mit einer Aktion zuordnen, aller-
dings lässt sich in CoDeSys eine Entry-Aktion festlegen.
Bei der Modellierung empfehlen die Autoren, die Verwendung von Jumps möglichst zu mini-
mieren: so konnten in diesem Beispiel die Rücksprünge zum Init-Zustand mit einem einzigen
Jump realisiert werden. Die Namen der Schritte sollten möglichst aussagekräftig sein und
idealerweise mit denen des Safety-Automaten übereinstimmen. Zur Verkürzung der Jumps
wurde hier eine verkürzte Schreibweise vorgenommen.
Act
ivat
e
NO
T A
ctiv
ate
S_Ch
anne
lAA
ND
NO
T S_
Cha
nnel
BN
OT
S_C
hann
elA
AN
DS_
Cha
nnel
B
S800
4.t >
= D
iscre
panc
yTim
e
S_C
hann
elA
AN
DS_
Cha
nnel
B
NO
TS_
Cha
nnel
AS_
Chan
nelB
NO
TS_
Cha
nnel
AA
ND
N
OT
S_C
hann
elB
NO
T A
ctiv
ate
NO
T A
ctiv
ate
S801
4.t>
=Disc
repa
ncyT
ime
Act
ivat
e
S_C
hann
elB
S_C
hann
elA
NO
TA
ctiv
ate
(S_C
hann
elA
XO
RS_
Cha
nnel
B)
S800
5.T>
=Disc
repa
ncyT
ime
NO
TS_
Chan
nelA
AN
D
NO
TS_
Chan
nelB
NO
T A
ctiv
ate
NO
T A
ctiv
ate
NO
TA
ctiv
ate
NO
TS_
Cha
nnel
AA
ND
N
OT
S_C
hann
elB
NO
TS_
Cha
nnel
AA
ND
N
OT
S_C
hann
elB
NO
TS_
Cha
nnel
AA
ND
NO
TS_
Cha
nnel
B
Bild
6: S
FC fü
r den
Bau
stei
n S
F_E
quiv
alen
t in
CoD
eSys
4 Generierung von Testfällen 4.1 Einführung Dieser Abschnitt ist der Generierung von Testfällen aus Safety-Automaten gewidmet. Die ge-
nerierten Tests können verwendet werden, um einerseits den Automaten selbst zu prüfen
und andererseits die Implementierung auf einer Soft-SPS oder einer realen SPS im Umfeld
der realen Hardware, Firmware und Laufzeitumgebung durchzuführen. Die Generierung der
Testfälle erfolgt automatisch und kann je nach erwünschter Testtiefe nach unterschiedlichen
Überdeckungskriterien erfolgen. Die automatische Generierung erspart zum einen deutlichen
Zeitaufwand im Vergleich zur manuellen Ableitung von Testfällen und garantiert zum ande-
ren eine hohe und reproduzierbare Qualität der Testfallausführung und -auswertung, dies im
Wesentlichen durch die direkte Kopplung an die Struktur des Safety-Automaten. Je nach
Testtiefe können unterschiedliche Überdeckungskriterien festgelegt und darauf aufbauend
mit geringem Aufwand Testfälle automatisiert generiert werden.
Für weniger kritische Safety-Funktionen empfehlen wir mindestens eine Überdeckung aller
Zustände des Safety-Automaten. In Anlehnung an den Safety-Standard IEC 61508 gilt diese
Empfehlung für alle Safety-Funktionen mit Safety Integrity Level 2. Für Safety-Funktionen mit
SIL 3 empfiehlt sich die vollständige Transitionsüberdeckung, d.h. durch die Testfälle werden
alle Transitionen des Safety-Automaten abgedeckt. Für Safety-Funktionen mit SIL 4 empfeh-
len die Autoren die Bedingungs- und Entscheidungsüberdeckung MC/DC (modified condition
/ decision coverage). Neben dieser Art der strukturellen Überdeckung existieren auch Mög-
lichkeiten Transitionen mit Übergangswahrscheinlichkeiten zu versehen, und die Testfallge-
nerierung gemäß dieser Wahrscheinlichkeiten auszurichten. Die Gesamtheit der Testergeb-
nisse lässt sich dann statistisch auswerten um ein Gesamtbild der erreichten Testtiefe und
der überprüften Software-Qualität zu erhalten [10].
Tabelle 2: Geforderte Testüberdeckung in Anlehnung an den Safety-Standard IEC 61508
Safety Integrity Level Testüberdeckungsmaß Testüberdeckungsziel
SIL 1 - -
SIL 3 Transitionsüberdeckung 100 %
SIL 4 Modified Condition / Decision Coverage 100 %
4.2 Testerzeugung Die Testfallerzeugung für den Baustein SF_Equivalent wird exemplarisch anhand der Werk-
zeuge graphwalker [6] und yEd [7] durchgeführt. Zunächst wurde der Automat im Werkzeug
yEd modelliert, siehe Bild 7. Hierbei wurde der Safety-Automat aus Bild 4 zugrunde gelegt.
Bild 7: Safety-Automat für SF_Equivalent im Werkzeug yEd
Im zweiten Schritt wird das Modell aus yEd im Dateiformat graphml [8] gespeichert. Das
Werkzeug graphwalker kann dieses Dateiformat lesen und erlaubt dem Anwender, den Start-
zustand festzulegen, das gewünschte Überdeckungskriterium und den gewünschten Such-
algorithmus auszuwählen. Anschließend werden die Testfälle automatisch erzeugt und zur
Weiterverarbeitung in einem Text-File abgelegt.
Im vorliegenden Beispiel wurde als Startzustand Idle, als Suchalgorithmus der A*-Algorith-
mus und als Überdeckungskriterium die Transitionsüberdeckung festgelegt. Im Ergebnis ent-
steht ein einziger Testfall, der sämtliche Transitionen und Zustände abdeckt und dabei 50
Zwischenstationen durchläuft. Alternativ kann der Anwender auch die Zustandsüberdeckung
als schwächeres Überdeckungskriterium wählen, Im Ergebnis entsteht ein einziger, aber kür-
zerer Testfall, der alle Zustände, aber nicht alle Transitionen abdeckt.
Tabelle 3: Testfallstatistik Zustands-, Transitionsüberdeckung
Kriterium Überdeckte Zustände
Überdeckte Transitionen
Unbesuchte Zustände
Unbesuchte Transitionen
Testfall-Länge
Zustandsüberdeckung 100% (10/10) 57% (15/26) 0 11 29 Transitionsüberde-ckung
100% (10/10) 100% (26/26) 0 0 50
Alternativ, wenn die Testfall-Länge zu groß werden würde, können im Werkzeug yEd gezielt
explizite Exit-Zustände festgelegt werden, um nur bestimmte Teilbereiche des Automaten zu
testen. Im Ergebnis werden mehrere Testfälle erzeugt mit weniger Testschritten. Angesichts
der Kompaktheit des Safety-Automaten ist der vollständige Test jedoch vorzuziehen, da die
Anzahl der Stationen mit 50 bei Transitionsüberdeckung bzw. 29 bei Zustandsüberdeckung
hinreichend klein ist.
Einschränkend für das Werkzeug graphwalker ist festzustellen, dass nur Automaten akzep-
tiert werden, die stark vernetzt sind – jeder Zustand muss (evtl. über Zwischenstationen) mit
jedem verbunden sein. Dies ist für sinnvoll definierte Safety-Automaten (wie auch für das
vorliegende Beispiel gegeben), da einerseits der Startzustand per Definition von jedem ande-
ren Zustand erreicht werden kann und andererseits jeder Zustand von Startzustand erreich-
bar sein sollte. Als alternatives Werkzeugt zum modellbasierten Test, insbesondere auch für
nicht stark vernetzte Teilautomaten, sei auf das Werkzeug JTorX [9] verwiesen.
4.3 Diskussion der Tests Die erzeugten Tests decken tatsächlich alle Transitionen und Zustände des Safety-Automa-
ten ab. Fehlende Zustände, fehlende Zustandsübergänge, fehlerhafte Zustandsübergangs-
bedingungen würden detektiert. Allerdings könnten im zu testenden SPS-Code versteckte
zusätzliche Zustände, verborgene Zustandsübergänge oder zusätzliche Bedingungen nicht
erkannt werden, weil sie bei der Testfallerzeugung nicht bekannt sind.
Dies kann durch einen Code-Review vermieden werden. eine Reviewgruppe müsste sicher-
stellen, dass sich im SPS-Code keine zusätzlichen Zustände, Transitionen oder Bedingun-
gen verbergen. Dies ist durch die 1:1-Umsetzung des Safety-Automaten in SFC recht ein-
fach.
Die Ausführung und Dokumentation der Tests hier nicht behandelt, allerdings ist eine Über-
führung der Tests in eine auf der SPS laufenden Testsoftware empfehlenswert, weil sie dann
auf derselben Zielplattform durchgeführt werden, auf der SPS-Code im industriellen Einsatz
laufen würde. Diese Methodik wurde in [2] bereits beschrieben.
5 Zusammenfassung und Ausblick Dieser Beitrag definiert die Klasse der „Safety-Automaten“ und schließt damit eine Lücke im
methodischen Werkzeugkasten des Automatisierungstechnikers. Darauf aufbauend beleuch-
tet der Beitrag die wesentlichen Stationen des Entwicklungsprozesses anhand des Bausteins
SF_Equivalent: die Spezifikation einer Sicherheitsfunktion mit Hilfe des „Safety-Automaten“,
die Implementierung des Automaten in einem ablauffähigen SFC sowie Ansätze zur Ermitt-
lung von Testfällen zur Überprüfung des Automaten und des lauffähigen SPS-Codes.
Die Ähnlichkeit zwischen Safety-Automaten und SFC ist gewollt und eröffnet erhebliche Op-
timierungspotentiale im sicherheitsgerichteten Entwicklungsprozess. Zunächst können aus
dem Automaten automatisch lauffähige SFCs generiert werden. Allerdings könnte sogar auf
den Automaten verzichtet werden, wenn der entsprechend eingeschränkte SFC selbst als
Spezifikationsmittel anstelle des Automaten verwendet würde. Zudem können aus Automa-
ten mit verfügbaren Mitteln automatisch Testfälle generiert werden, eine wichtige Basis für
die Überprüfung des SFC. Die Erzeugung von Testfällen sowie des SPS-Codes aus demsel-
ben Automaten ist entgegen der verbreiteten Auffassung (z.B. [2]) durchaus sinnvoll, da die
automatische SPS-Code-Generierung, der Compiler, der Download, die Hardware oder die
Laufzeitumgebung fehlerbehaftet sein können.
Diese Arbeit ist Teil der Fachausschusstätigkeit des GMA 1.50, der an einem Leitfaden zur
Entwicklung sicherheitsgerichteter Steuerungsfunktionen erarbeitet (VDI/VDE 3541). Ein
Fokus der Richtlinienarbeit liegt auf der Auswahl geeigneter Beschreibungsmittel und Me-
thoden zur Entwicklung sicherer Funktionsbausteine für Steuerungen nach IEC 61131.
6 Literatur [1] PLCopen TC5: Safety Software Technical Specification, Version 1.0, Part 1: Concepts
and Function Blocks. PLCopen, 2006.
[2] Drath R., Hoernicke M.: „Konzept für einen effizienten Entwicklungsprozess zur Erstel-
lung von sicherheitsgerichteten SPS Bibliotheken“. Kongress Automation, Baden Ba-
den, 2010
[3] Frey, G.; Drath, R.; Schlich, B.: Leitfaden zur Entwicklung von Safety-Applikationen auf
Anwenderebene. Kongress Automation, Baden-Baden, 2011.
[4] J. Lunze: Automatisierungstechnik: Methoden für die Überwachung und Steuerung
kontinuierlicher und ereignisdiskreter Systeme, Oldenbourg Wissenschaftsverlag,
2003.
[5] IEC 61131-3 Speicherprogrammierbare Steuerungen: Programmiersprachen.
[6] Model-Based Testing Tool graphwalker, http://graphwalker.org/
[7] yEd, http://www.yworks.com/en/products_yed_about.html
[8] graphml, http://graphml.graphdrawing.org/
[9] Model-Based testing Tool JTorX https://fmt.ewi.utwente.nl/redmine/projects/jtorx
[10] Jesse H. Poore, Lan Lin, Robert Eschbach, and Thomas Bauer, "Automated Statistical
Testing of Embedded Systems", Chapter in "Model-Based Testing for Embedded Sys-
tems", Series on "Computational Analysis, Synthesis, and Design of Dynamic Sys-
tems.", 2011
Anhang A: Formale Definition des Safety-Automaten Syntax: Elemente Ein Safety-Automat SF ist beschrieben durch ein 11-Tupel SF = (Z, T, E, A, z1, e1, a1, τ, o, s, p) bestehend aus Z = {z1, …zn} eine nichtleere, endliche Menge von n Zuständen T = {t1, …tm} eine nichtleere, endliche Menge von m Transitionen E = {e1, …ek} eine nichtleere, endliche Menge von k Booleschen Eingangsvariablen A = {a1, …al} eine nichtleere, endliche Menge von l Booleschen Ausgangsvariablen z1 ∈ Z ein Anfangszustand e1 ∈ E ein Aktivierungseingang a1 ∈ A ein Aktivitätsausgang τ eine Zustandsuhr, die immer die Zeit seit dem letzten Zustandswechsel angibt o eine Ausgangsfunktion, die in jedem Zustand zi aus Z allen Ausgangsvariablen aj aus A einen Boole-
schen Wert zuweist: o(zi, aj) ∈ {True, False} ∀ i∈{1,…n}, j∈{1,…l} s eine Schaltfunktion s(ti), die jeder Transition ti aus T eine Boolesche Schaltbedingung über der Menge
der Eingangsvariablen E sowie einer optionalen Wartebedingung (τ ≥ Zeitwert) zuweist. p eine Prioritätsfunktion p(ti), die Transitionen eine optionale Priorität aus dem Bereich der nichtnegativen
ganzen Zahlen zuweist. Niedrigere Zahlen bedeuten dabei eine höhere Priorität der Transition (0 = höchste Priorität)
Syntax: Bedingungen Transitionen verbinden immer zwei unterschiedliche Zustände (Selbstschleifen sind ausgeschlossen). Übergänge in den Initialzustand gibt es von jedem anderen Zustand. Deshalb setzt sich die Menge der Transitionen aus zwei disjunkten Teilmengen Taktiv und Tinit wie folgt zusammen: T = Taktiv ∪ Tinit T besteht aus zwei Teilmengen Taktiv und Tinit Tinit = Z\{z1} × { z1} Tinit enthält für jeden anderen Zustand einen Übergang in z1 Taktiv ⊆ Z × Z\{z1} Taktiv enthält beliebige weitere Übergänge zwischen Zuständen (zi, zi) ∉ T ∀ i∈{1,…n} T enthält keine Selbstschleifen Der Aktivitätsausgang soll nach außen anzeigen, ob sich der SF im Initialzustand befindet oder nicht: o(z1, a1) = True o(zi, a1) = False ∀ i∈{2,…l} Sobald der Aktivierungseingang False wird, geht der SF vom (beliebigen) aktuellen Zustand in den Anfangszustand über. Dieser Übergang erfolgt mit höchster Priorität und hängt von keinen weiteren Bedingungen ab: s(t) = NOT e1 ∀ t ∈ Tinit p(ti) = 0 ∀ t ∈ Tinit Die Priorität von unterschiedlichen Transitionen aus einem Zustand muss unterschiedlich sein: j ≠ k impliziert p(zi,zj) ≠ p(zi, zk) ∀ i,j,k ∈ {0, …n} Syntax: grafische Darstellung Für die grafische Darstellung ist in Anlehnung an existierende Formate Folgendes vorgesehen: ZuständeKreise, Langrunde oder Quadrate (ggf. mit abgerundeten Ecken) in die der Zustandsname geschrieben wird Anfangszustand Hervorhebung durch doppelte oder fette Randlinie Ausgabefunktion am oder im Zustand Transitionen Pfeile vom Ausgangs- zum Zielzustand Schaltfunktion an der entsprechenden Transition Prioritätsfunktion Angabe der Priorität am Ursprung der Transition oder am Anfang vom Label Eingangsvariablen Tabelle mit Kennzeichnung der Aktivierungsvariable Ausgangsvariablen Tabelle mit Kennzeichnung der Aktivitätsvariable Semantik (Abarbeitungsregeln) Es wird einem E/A-Automaten ausgegangen, der nicht autonom ausgeführt wird. D.h. es erfolgt eine Synchronisation mit der Umgebung. Im Bereich der Steuerungstechnik wird dies idealerweise durch einen zeitbasierten zyklischen Aufruf realisiert. Eine ereignisgesteuerte Ausführung (bspw. immer bei Änderung einer der Eingangsvariablen) ist denkbar. In diesem Fall muss bei Vorhandensein von Zeitbedingungen in der Schaltfunktion aber eine zusätzliche Prüfung vorgese-hen werden. Für die Abarbeitung gelten folgende Regeln: Bei Aufruf wird geprüft on unter der vorliegenden Belegung der Eingangsvariablen und beim aktuellen Stand der Zustandsuhr eine Transition schalten kann. Ist dies der Fall führt der SA diese Transition aus. Der Automat führt hierbei immer nur eine einzelne Transition aus. Es gibt also keine tran-sienten Zustände wie bspw. im Grafcet. Können mehrere Transitionen aufgrund ihrer Schaltbedingung schalten, so wird die mit der höchsten Priorität (kleinster Wert von p) zum Schalten ausgewählt. Danach wird die Zustandsuhr neu gestar-tet und die Ausgangsvariablen werden basierend auf der im neuen Zustand geltenden Ausgabefunktion gesetzt. Kann bei einem Aufruf keine Transition schalten, so bleibt der Automat im aktuellen Zustand (implizite Selbstschleife).