entwicklung sicherer steuerungsapplikationen mit safety ... · informale zusatzinformationen im...

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


!Error

Wait for Channel B8004


!Error

Error 1C001


Error

Error 2C002


Error

Error 3C003


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



From Active Wait8005


!Error Safety Output Enabled8000


Error

3: S_ChannelB 3: S_ChannelA2: !S_ChannelA& !S_ChannelB




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).

entwicklung sicherer steuerungsapplikationen mit safety ... · informale zusatzinformationen im...

Documents