Entwicklung und Implementierung von Heuristiken zur optimierten ...

Fakultät 2
Department für Informatik
Entwicklung und Implementierung von
Heuristiken zur optimierten Fehlersuche für
PLC-Automaten
Individuelles Projekt
24. Mai 2005
Bearbeitet von:
Nico Mischok - Matrikelnummer: -
E-Mail: nico.mischok@informatik.uni-oldenburg.de
Erstgutachter: Prof. Dr. Ernst-Rüdiger Olderog
Zweitgutachter: Dr. Henning Dierks

Zusammenfassung
Diese Arbeit widmet sich der optimierten Fehlersuche in PLC-Automaten.
PLC-Automaten stellen eine spezielle Klasse von Realzeitautomaten dar. Es
bietet sich somit die Möglichkeit, aufgrund der kontextuellen Information in
der Realzeitsemantik der PLC-Automaten die Suche nach Fehlern zu steuern.
Es werden Heuristiken vorgestellt, die die Suche nach Fehlern signifikant verbessern,
die etwa ein Ergebnis schneller liefern, als dies die einfache Tiefenoder
Breitensuche kann.
Inhaltsverzeichnis
1 Einleitung 3
2 PLC-Automaten 5
2.1 Programmable Logic Controller . . . . . . . . . . . . . . . . . . . . . 5
2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Realzeitsemantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Zugsensorsteuerung 1 . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Zugsensorsteuerung 2 . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 Realzeitsemantik der Zugsensorsteuerung 1 . . . . . . . . . . . 13
3 UPPAAL CORA 15
3.1 Linearly Priced Timed Automata . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4 Kostenfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.5 Symbolische Semantik . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1

4 Fallstudie: Fehlertolerante Fertigungszelle 24
4.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Eingabeförderband . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Rotierender Tisch . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Roboter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4 Pressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.5 Ausgabeförderband . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Sensoren und Aktoren . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Aktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Lebendigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Simulation des Werkstücks . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Heuristiken 33
5.1 Kosten für einen Zyklus . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Kosten für die Änderung einer Eingabevariable . . . . . . . . . . . . . 34
5.3 Abstand zum Fehlerzustand . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Schlussbetrachtung 41
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2

1 Einleitung
Dieser Text entstand im Rahmen des Individuellen Projekts, das in der Abteilung
Semantik der Carl-von-Ossietzky-Universität durchgeführt wurde. Als Erstgutachter
fungiert Prof. Dr. Ernst-Rüdiger Olderog und als betreuender Gutachter Dr.
Henning Dierks.
Die Verifikation mit dem Model-Checker UPPAAL ergibt, sofern über ausreichend
Speicher und Zeit verfügt werden kann, immer ein Ergebnis. Voraussetzung
für ein positives Ergebnis ist, dass der gesamte Zustandsraum erfolglos nach einem
Gegenbeispiel für die gewünschte Eigenschaft durchsucht wurde. Wird ein Gegenbeispiel
gefunden, so gilt dies als negatives Ergebnis, die angefragte Eigenschaft
wurde nicht bestätigt. Um die Durchführung der Suche nach einem Gegenbeispiel
bei der Verifikation einer Eigenschaft eines Realzeitautomaten zu verbessern, kann
UPPAAL CORA, die kostenoptimierende Version von UPPAAL eingesetzt werden,
um mithilfe von Heuristiken einen Ablauf, der ein Gegenbeispiel darstellt, schneller
zu finden.
Üblicherweise ist bei der Verifikation eine positive Antwort das Ziel, für die der
gesamte Zustandsraum durchsucht werden muss. Aus diesem Grund unterstützen
Modelchecker typischerweise keine Methoden, mit denen Gegenbeispiele schnell gefunden
werden können. Es ist allerdings in manchen Fällen wünschenswert, den
Model-Checker beispielsweise mithilfe von Kosten an Transitionen oder einer Prioritätsliste
der Zustände auf der Suche nach einem Gegenbeispiel lenken zu können:
• Es kann gewünscht sein, dass ein optimaler Ablauf oder Plan gesucht wird,
bsplw. zu Debugging-Zwecken in der Programm-Verifikation.
• Erhält man bei der Verifikation einer Abstraktion eines Modells ein Gegenbeispiel,
so ist nicht klar, ob dieser Ablauf auch im eigentlichen Modell möglich
ist. Dieses abstrakte Gegenbeispiel muss noch einmal im gesamten Modell auf
seinen Erfolg getestet werden.
• Bei der so genannten abstraction refinement loop wird die Verifikation zunächst
mit einer sehr groben Abstraktion des eigentlichen Modells begonnen. Typischerweise
erhält man ein abstraktes Gegenbeispiel, aus welchem geschlossen
3

werden kann, an welcher Stelle die Abstraktion zu grob war. Der Prozess wird
dann so lange mit jeweils feinerer Abstraktion neu gestartet, bis kein abstraktes
Gegenbeispiel mehr gefunden wird.
Darüber hinaus kann ein schnelles Finden von Fehlerabläufen in großen Systemen
natürlich zu wichtiger Zeit- und damit oft verbundener Kostenersparnis führen.
Um aber die Suche nach Fehlern sinnvoll steuern zu können, bedarf es zusätzlicher
kontextueller Information über das zu verifizierende System. Diese wird sich
daraus ergeben, dass wir mit den PLC-Automaten eine spezielle Klasse von Realzeitautomaten
betrachten. Die Realzeitsemantik der PLC-Automaten dient dann
UPPAAL CORA als Eingabe zur Verifikation.
Um die Grundlagen zu legen, werden wir uns in den ersten beiden Kapiteln den
PLC-Automaten sowie UPPAAL CORA widmen. In Kapitel 4 wird die Fallstudie
vorgestellt, die Grundlage der Versuche zur Evaluation der Heuristiken war. In Kapitel
5 werden die Heuristiken vorgestellt, die es möglich machen, die Fehlersuche für
PLC-Automaten zu optimieren. Die heuristisch gesteuerte Fehlersuche wird dann
zu evaluieren sein und sich mit einfacher“ Tiefen- oder randomisierter Fehlersuche
”
messen müssen.
Wenn diese Evaluation zum Erfolg führt, wird innerhalb dieses Textes kurz
auf die Implementierung der Heuristiken eingegangen, die einen weiteren wichtigen
Aspekt dieses Individuellen Projekts ausmacht. Die Heuristiken werden in den
UPPAAL-Service des Tools Moby/PLC implementiert. Moby/PLC ist ein Tool, mit
dem PLC-Automaten erstellt und bearbeitet werden können, der UPPAAL-Service
berechnet die Realzeitsemantik der gewünschten PLC-Automaten, sodass diese als
Eingabe zur Verifikation mit UPPAAL dienen können.
Abschließend werden in einer Schlussbetrachtung die wichtigsten Aspekte noch
einmal hervorgehoben. Außerdem wird ein Blick in die Zukunft gewagt, an welchen
Stellen eine Erweiterung des hier Aufgezeigten möglich sein könnte bzw. welche
andere Herangehensweise an das Thema interessant ist.
4

2 PLC-Automaten
Es soll nun mit den PLC-Automaten eine Abstraktion von Realzeit-Programmen
vorgestellt werden. Ein großer Vorteil von PLC-Automaten ist, dass sie sich in konkreten
Source-Code für eine in der Industrie häufig verwendete Klasse von Hardware
(PLC für Programmable Logic Controller, deutsch: Speicherprogrammierbare Steuerungen)
übersetzen lassen. Speicherprogrammierbare Steuerungen (im Folgenden
nur noch PLC genannt) werden häufig dazu genutzt Realzeitsysteme zu steuern, da
sie robust gebaut sind und in widrigen Verhältnissen eingesetzt werden können (z. B.
Hitze, Kälte), so z. B. in Verkehrsampeln. Die Einsatzgebiete der PLC-Automaten
werden uns allerdings im Folgenden weniger interessieren, es soll hiermit lediglich
aufgezeigt werden, wo die Anwendungsgebiete liegen.
Es soll nun zunächst etwas näher auf die PLC eingegangen werden, um dann
die Syntax der PLC-Automaten aufzuzeigen. Danach wird die Semantik der PLC-
Automaten in Realzeitautomaten vorgestellt, da der verwendete Modelchecker UP-
PAAL diese verifizieren kann.
2.1 Programmable Logic Controller
Die PLC haben ein eingebautes Betriebssystem, das das Verhalten vorschreibt. Der
Nutzer hat aus Sicherheitsgründen keinen Einfluss auf dessen Verhalten. Durch das
Betriebssystem ist folgendes zyklisches Verhalten der Maschine vorgeschrieben:
• Polling: In dieser ersten Phase des Zyklus werden die Input-Busse gelesen.
Die gelesenen Werte werden in einem ausgezeichneten Speicherbereich zwischengespeichert.
• Computing: In der nächsten Phase des Zyklus wird das Programm des Anwenders
einmal ausgeführt. Dieses Programm darf beliebige Berechnungen auf
Arbeitsspeicher einschließlich der Sonderregister der gelesenen Input-Werte
machen und ebenfalls Sonderregister für die Output-Busse auslesen und beschreiben.
5

• Updating: Die letzte Phase des Zyklus dient dazu, die berechneten Werte der
Außenwelt sichtbar zu machen, indem die Inhalte der Sonderregister für die
Output-Busse auf die Output-Busse gelegt werden.
Abbildung 1: Zyklus einer SPS (Quelle: [13])
Eine SPS besitzt eine Zykluszeit (in Abbildung 1: max. cycle time), in der ein
Zyklus vollständig durchgeführt sein muss. Der tatsächliche Zeitverbrauch eines Zyklus
hängt von der Größe der Input- und Output-Busse und des Programms selbst
ab.
2.2 Syntax
Ein Tupel A = (Q, Σ,δ,q 0 ,ε,S t ,S e , Ω,ω) ist ein PLC-Automat, wenn folgendes gilt:
• Q ist eine nichtleere, endliche Menge von Zuständen,
• Σ ist eine nichtleere, endliche Menge von Eingaben,
• δ ist eine Funktion vom Typ Q × Σ ↦−→ Q (Transitionsfunktion),
• q 0 ∈ Q ist der Startzustand,
6

• ε > 0 ist die obere Grenze für einen Zyklus,
• S t ist eine Funktion vom Typ Q ↦−→ R ≥0 , die jedem Zustand q eine Zeit
zuordnet, in der die Eingaben, die S e (q) enthält, ignoriert werden,
• S e ist eine Funktion vom Typ Q ↦−→ P(Σ), die jedem Zustand q eine Menge
von Eingaben zuordnet, die S t (q) lang ignoriert werden,
• Ω ist eine nichtleere, endliche Menge von Ausgaben,
• ω ist eine Funktion vom Typ Q ↦−→ Ω (Ausgabefunktion).
Die Komponenten Q, Σ, δ und q 0 haben dieselbe Bedeutung wie in endlichen
Automaten. Das ε stellt die obere Schranke für einen gesamten Zyklus dar. P(Σ)
bezeichnet die Potenzmenge von Σ. S t und S e modellieren eine weitere praktische
Eigenschaft der PLC-Automaten, deren Sinn die Beispiele in Kapitel 2.4 deutlich
machen werden. Eine Eingabe, die in S e enthalten ist, wird S t im betreffenden
Zustand ignoriert. ω ordnet jedem Zustand eine Ausgabe aus Ω zu.
2.3 Realzeitsemantik
UPPAAL akzeptiert als Eingabe lediglich einen oder mehrere Realzeitautomaten.
Um die erforderliche kontextuelle Information über das System zu erhalten, betrachten
wir allerdings PLC-Automaten. Es soll nun vorgestellt werden, wie ein
Realzeitautomat konstruiert werden muss, damit er einen PLC-Automaten simuliert.
Sei A ein PLC-Automat mit A = (Q, Σ,δ,q 0 ,ε,S t ,S e , Ω,ω). Dann definiere einen
Realzeitautomaten R(A) = df (S,S 0 ,X,L,E,I,P,µ) mit
• S = df {0, 1, 2, 3} × Σ × Σ × Q einer Menge von Zuständen,
• S 0 = df {(0,a,b,q 0 )|a,b ∈ Σ} einer Menge von initialen Zuständen,
• X = df {x,y,z} einer Menge von Uhren,
• L = df Σ ∪ {poll,test,tick} einer Menge von Beschriftungen bzw. Eingaben,
7

(i,a,b,q)
(0,a,b,q)
(1,a,b,q)
(1,a,b,q)
(1,a,b,q)
(2,a,b,q)
(3,a,b,q)
(3,a,b,q)
c,true,{x}
↦−→ (i,c,b,q) if c ≠ a (1)
poll,0S t(q),∅
↦−→ (3,a,b,q) if S t (q) > 0 ∧ b ∈ S e (q) (4)
test,true,∅
↦−→ (3,a,b,q) if S t (q) = 0 ∨ b /∈ S e (q) (5)
tick,true,{z}
↦−→ (0,a,b,q) (6)
tick,true,{z}
↦−→ (0,a,b,δ(q,b)) if q = δ(q,b) (7)
tick,true,{y,z}
↦−→ (0,a,b,δ(q,b)) if q ≠ δ(q,b) (8)
Tabelle 1: Transitionen in Realzeitsemantik
• einer Menge von Transitionen E, die in Tabelle 1 gegeben sind, wobei i ∈
{0, 1, 2, 3}, a,b,c ∈ Σ und q ∈ Q,
• I(s) = df z ≤ ε einer Invariante für jeden Zustand s ∈ S,
• P = Σ ∪ Q ∪ Ω einer Menge von Propositionen,
• µ(i,a,b,q) = df a ∧ q ∧ ω(q) einer Proposition für jeden Zustand.
Abbildung 2: Der Programmzähler
Die Menge der Zustände von R(A) besteht aus vier Dimensionen. Die erste ( Programmzähler“,
vgl. Abbildung 2) nimmt die möglichen Werte {0, 1, 2, 3} an und
”
beschreibt den internen Zustand des Pollingsystems (siehe Abbildung 2). Ist dieser
8

Wert ”
0“, so wurde der aktuell anliegende Eingabewert noch nicht gepollt 1 , bei einer
1“ wurde dies bereits getan. Ob eine Transition dann ausgeführt wird, hängt von
”
S t und S e des PLC-Automaten ab. Die zweite Dimension der Zustände bezeichnet
den aktuell anliegenden Eingabewert, die dritte den zuletzt gepollten Eingabewert
und die vierte den aktuellen Zustand des PLC-Automaten.
Die drei Uhren haben folgende Aufgaben: Uhr x merkt die Zeit, die die letzte
Eingabe anliegt, Uhr y merkt, wie lange der SPS-Automat sich im aktuellen Zustand
befindet und Uhr z überwacht die Zeit des gesamten Zyklus. Die aktuell anliegende
Eingabe wird von der Umwelt gesteuert und kann sich deswegen prinzipiell zu jedem
Zeitpunkt ändern (Transitionen (1)). Die Transitionen, die die erste Komponente der
Zustände des Realzeitautomaten ändern, sind mit poll, test und tick beschriftet. Die
Pollingphase muss eine gewisse Zeit nach Beginn des Zyklus geschehen, weswegen
die Transitionen (2) mit z > 0 beschriftet wurden. Auch der aktuelle Eingabewert
muss bereits eine gewisse Zeit anliegen, darum muss auch x > 0 gefordert werden.
Nach dem Polling muss überprüft werden, ob eine Transition genommen werden
muss, was abhängig von S e , S t und der Uhr y ist. Ist im PLC-Automaten keine
Delay-Zeit S t angegeben oder ist die zuletzt gepollte Eingabe nicht zu ignorieren
(b /∈ S e (q)) so geht R(A) über in einen Zustand mit führender ”
3“, was bedeutet, dass
die Transition des PLC-Automaten A auch im Realzeitautomaten R(A) genommen
wird (Transitionen (5)). Ist eine Delay-Zeit für den Zustand q angegeben und die
gepollte Eingabe b ist zu ignorieren (b ∈ S e (q)), dann führt R(A) die Transition nur
dann aus, wenn y > S t (q) gilt, was bedeutet, dass die Zeit, die der Zustand des PLC-
Automaten bereits anhält, größer ist als die Delay-Zeit S t (q) (Transitionen (3) und
(4)). Die tick-Transitionen (6-8) beenden den Zyklus, der aufgrund der Invarianten
z ≤ ε nach oben durch ε beschränkt ist, da nur die tick-Transitionen die Uhr z
zurücksetzen.
Die ”
praktische Semantik“ sieht indes ein wenig anders aus: Der UPPAAL-
Service von Moby/PLC, mit dessen Ausgabe die Versuche zur Verifikation mit UP-
PAAL CORA durchgeführt wurden, erstellt aus einem PLC-Automaten eine Parallelkomposition
mehrerer Realzeitautomaten. Die Transitionen (1), die die Änderungen
der Umwelt modellieren, werden hierbei durch so genannte Treiber ersetzt.
1 Aufgrund der Verbreitung des Verbes pollen wird auf eine Übersetzung in diesem Text verzichtet.
Am nächsten käme wohl ”
einlesen“.
9

Für jede Eingabevariable gibt es einen Treiber, der die Änderung des Wertes zu
jedem Zeitpunkt erlaubt. Außerdem wird der Wert des Programmzählers als interne
Variable gespeichert, weswegen die Zustandsmenge eines Realzeitautomaten die
gleiche ist wie die des zu simulierenden PLC-Automaten. Der Zustandsraum des
Realzeitautomaten ist - wie gesehen - ungleich größer als der des PLC-Automaten.
2.4 Beispiele
Ein Fallbeispiel soll dem Leser die PLC-Automaten und ihre Realzeitsemantik näher
bringen und motivieren. Bis auf die Realzeitsemantik ist dieses [13] entnommen.
2.4.1 Zugsensorsteuerung 1
Ein Zugsensor kann die Signale train (Zug) und no train (kein Zug) verarbeiten.
Die Ankunft eines Zuges wird dann durch den Wechsel vonno train zutrain angezeigt.
Ein bekanntes Phänomen ist, dass eine gewisse Zeitspanne (hier: 4 Sekunden)
nach Ankunft eines Zuges mehrere solcher Wechsel geschehen, obwohl tatsächlich
kein Zug angekommen ist ( Stottern“). Sei der zeitliche Mindestabstand zwischen
”
zwei Zügen 6 Sekunden, dann zeigt Abbildung 3 eine mögliche Lösung.
Abbildung 3: Zugsensorsteuerung 1
Dieser Automat besteht aus zwei Zuständen N und T. Die Namen der Zustände
legen auch die Ausgabe dieser nahe, nämlich N → Kein Zug“ und T → Zug“.
” ”
In Zustand T ist die Zeitspanne angegeben (in Sekunden), die auf die angegebenen
Eingaben (in diesem Fall all={train, no train}) nicht reagiert werden soll. Die
Zykluszeit von hier 0,2 Sekunden wird üblicherweise in einer kleinen Box neben dem
Automaten angegeben. Abbildung 4 zeigt einen typischen Ablauf des Automaten.
10

Abbildung 4: Typischer Ablauf der Zugsensorsteuerung 1 (Quelle: [13])
Die durchgezogenen Pfeile stellen genommene Transitionen dar, die gepunkteten
weisen auf eine Transition hin, die wegen der noch nicht vergangenen 5 Sekunden
nicht genommen wurden. Dass die dritte Transition durchgezogen gekennzeichnet
ist, liegt daran, dass es sich hierbei um eine Schleife handelt und deshalb ohnehin
kein Zustandswechsel auftreten kann.
Zwei Züge können in diesem Beispiel im Abstand von 6 Sekunden eintreffen
und das Stottern dauert maximal 4 Sekunden. Damit ergeben sich 5 Sekunden als
mögliche Grenze des Ignorierens der Eingaben im Zustand T, da es nicht passieren
kann, dass ein Wechsel von no train nach train fälschlicherweise als Stottern interpretiert
wird und der Automat sich bei Ankunft eines Zuges immer im Zustand
N befindet.
Die oben angegebene Struktur ist ein sehr einfacher PLC-Automat für dieses Beispiel,
eine Erweiterung soll dem Leser weiterhelfen, den Sinn von PLC-Automaten
nachzuvollziehen.
2.4.2 Zugsensorsteuerung 2
Erneut wird die Steuerung eines Zugsensors betrachtet, allerdings kann der Zugsensor
in diesem Fall zusätzlich das Ereignis Error verarbeiten, welches Fehler am
Sensor meldet. Der Filter soll nun so erweitert werden, dass auf ein Error-Signal
sofort reagiert und in einen Zustand X gesprungen wird. Eine mögliche Lösung ist
in Abbildung 5 zu sehen.
11

Abbildung 5: Zugsensorsteuerung 2
Zu beachten ist, dass nun im Zustand T nicht mehr alle Eingaben 5 Sekunden
lang ignoriert werden sollen, sondern dass bei einem Auftreten des Fehlersignals
sofort in den Zustand X gesprungen wird. Abbildung 6 zeigt einen möglicher Ablauf
dieses Automaten der Zugsensorsteuerung 2.
Abbildung 6: Typischer Ablauf der Zugsensorsteuerung 2 (Quelle: [13])
Interessant ist, dass das erste train-Signal zu kurz war um gelesen zu werden.
Um sicher zu stellen, dass keine Signale übersehen werden, muss also dafür gesorgt
werden, dass ein Signal eine gewisse Zeitspanne anliegt und die obere Zeitschranke
des PLC-Automaten klein gehalten wird.
12

2.4.3 Realzeitsemantik der Zugsensorsteuerung 1
Am Beispiel der Zugsensorsteuerung 1 wurde der entsprechende Realzeitautomat
entwickelt, dieser ist in Abbildung 7 zu sehen.
Abbildung 7: Realzeitsemantik von Zugsensorsteuerung 1
Die Eingaben train und no train wurden durch n und t ersetzt. Die Beschriftung
der poll, test und tick-Transitionen wurde durch Kennzeichnung mit verschiedenen
Pfeilen ersetzt.
13

Außerdem gehört zu jedem Zustand die Invariante z ≤ 0.2. Die Zustände (2,n,
n, N), (2, t, n, N), (2, n, t, N), (2, t, t, N) sind nicht erreichbar und
wurden somit Opfer der Übersichtlichkeit. Diese Zustände sind nicht erreichbar,
da im Zustand N des PLC-Automaten keine Verzögerungszeit angegeben ist, folglich
kann in jedem Fall zu einem der Zustände mit dem Wert 3 in erster Dimension übergegangen
werden. Befindet sich der PLC-Automat im ZustandT(simuliert durch die
Zustände im Realzeitautomaten, die mit T enden), so müssen die Eingaben 5 Sekunden
lang ignoriert werden. Dieses Verhalten simuliert der Realzeitautomat mithilfe
der Uhr y, die die Zeit misst, die der PLC-Automat sich in einem Zustand befindet.
Ist der Wert dieser Uhr kleiner als 5, so kann der Realzeitautomat nur zwischen den
Zuständen mit führender 0, 1 oder 2 hin- und herspringen. Der Wechsel von einem
mit T endenden Zustand zu einem mit N endenden Zustand ist allerdings erst in einem
Zustand mit führender 3 möglich. In einen solchen gelangt der Realzeitautomat
allerdings erst, wenn die Uhr y einen Wert größer als 5 hat.
Es sollte offensichtlich sein, dass die Zustandsmenge eines Realzeitautomaten,
der einen PLC-Automaten simuliert, mit wachsender Menge Eingaben und Zustände
des PLC-Automaten sehr schnell wächst. Ein Realzeitautomat zum PLC-Automaten
der Zugsensorsteuerung 2 bestünde bereits aus 4*3*3*3=148 Zuständen. Das wichtige
allerdings ist, dass überhaupt die Möglichkeit besteht, einen PLC-Automaten
durch einen Realzeitautomaten zu simulieren. Deswegen kann der Modelchecker UP-
PAAL genutzt werden, und das Bestimmen eines Realzeitautomaten von einem PLC-
Automaten ist in Moby/PLC automatisiert.
14

3 UPPAAL CORA
UPPAAL ist ein Werkzeug zur Modellierung, Simulation und Verifikation von Realzeitsystemen
und wurde entwickelt in Zusammenarbeit von Basic Reasearch in Computer
Science von der Universität Aalborg in Dänemark und dem Department of
Information Technology von der Universität Uppsala in Schweden (vgl. [15]). Der
Name UPPAAL setzt sich also aus den Anfangsbuchstaben der Universitäten zusammen.
UPPAAL CORA ( cost-optimising reachability analysis“) wurde vom UPPAAL-
”
Team als Teil der Projekte VHS (Verification of Hybrid Systems, [12]) und AME-
TIST (Advanced Method for Timed Systems, [14]) entwickelt. Während UPPAAL
Realzeitautomaten als Eingabe analysiert und in jedem Fall den gesamten Zustandsraum
durchsucht, erhält UPPAAL CORA als Eingabe einen oder mehrere Linearly
Priced Timed Automata 2 , eine Erweiterung von Realzeitautomaten ([2]). UPPAAL
CORA findet dann einen optimalen Pfad, d. h. einen kostenminimierten Pfad zu
einem Zielzustand.
Durch die Eingabe eines oder mehrerer Linearly Priced Timed Automata (im
Folgenden nur noch LPTA) wird dem Benutzer erlaubt, dem Realzeitmodell zusätzliche
Information, wie z. B. Kosten für Transitionen oder Zustände, hinzuzufügen,
um die Fehlersuche zu verbessern. Ein Hinzufügen einer unteren Abschätzung der
verbleibenden Kosten (über das Setzen der Variable remaining), bis der Zielzustand
erreicht ist, kann bsplw. die Zeit, die zur Fehlersuche benötigt wird, drastisch
reduzieren.
3.1 Linearly Priced Timed Automata
Ein LPTA ist ein Realzeitautomat mit der hinzugefügten Variable Kosten. Diese
ist initial null und steigt monoton. Die Kosten werden an Transitionen erhöht oder
aber mit einer Rate nach vergangener Zeit. Ist die Rate in einem Zustand bsplw. 2
dann wären die Kosten nach vergangenen 1,6 Zeiteinheiten in diesem Zustand um
3,2 größer. Die Variable Kosten kann allerdings an keiner Transition als Bedingung
2 Aufgrund der großen Verbreitung wird auf eine Übersetzung verzichtet.
15

oder in Invarianten genutzt werden, da dies das Verhalten des Systems beeinflussen
würde. Das Modelchecking wäre unentscheidbar, da die Variable Kosten eine
Stoppuhr darstellen würde. In [8] wird das Erreichbarkeitsproblem von Stoppuhr-
Automaten auf das Halteproblem von Zwei-Zähler-Maschinen reduziert.
3.1.1 Syntax
Ein LPTA A ist ein Tupel (S,s 0 ,X, Σ,E,I,P), wobei gilt:
• S ist eine endliche Menge von Zuständen
• X ist eine Menge von Uhren
• Σ ist eine endliche Menge von Eingaben
• E ⊆ S × B(X) × Σ × P(X) × S ist eine Menge von Transitionen, wobei
eine Kante einen Ausgangszustand, Uhrenbedingungen sowie eine Aktion, eine
Menge von Uhren, die zurückgesetzt werden und einen Zielzustand besitzt
• I : S ↦−→ B(X) ordnet jedem Zustand eine Invariante zu
• P : (S ˙∪E) ↦−→ N ordnet sowohl Zuständen als auch Transitionen Kosten zu
Hierbei ist B(C) die Menge der Formeln, die Konjunktionen der atomaren Uhrenbedingungen
der Form x ⊲⊳ n und x − y ⊲⊳ n sind, für x,y ∈ X, ⊲⊳∈ {}
und n ∈ N. P(X) bezeichnet die Potenzmenge von X. Für den Fall (s,g,a,r,s ′ ) ∈ E
schreiben wir s ↦−→ g,a,r
s ′ .
Die Werte der Uhren werden durch Funktionen von X in die nicht-negativen
reellen Zahlen repräsentiert. Diese heißen Uhrenbelegungen und mit R X wird die
Menge aller Uhrenbelegungen über X bezeichnet.
Abbildung 8 zeigt einen LPTA. Die Bedingungen über den Zuständen sind die
Invarianten, die Zahl im Zustand ist jeweils die Rate der Kosten. Ein optimaler
Ablauf zum Endzustand s 2 muss zweimal den Anfangszustand besuchen und hat
die Kosten 10.
16

Abbildung 8: Beispiel eines LPTA
3.1.2 Semantik
Die Semantik eines LPTA wird definiert als ein beschriftetes Transitionssystem im
Zustandsraum S × R X mit Startzustand (s 0 ,u 0 ) (u 0 weist allen Uhren aus X null
zu) und folgender Transitionsrelation:
• (s,u) ε(d),p
↦−→ (s,u + d) wenn ∀0 ≤ e ≤ d : u + e ∈ I(s) und p = d · P(s)
• (s,u)
a,p
↦−→ (s ′ ,u ′ ) wenn ∃g,r, sodass s ↦−→ g,a,r
s ′ , u ∈ g, u ′
p = P((s,g,a,r,s ′ ))
= u[r ↦→ 0] und
wobei für d ∈ R ≥0 u+d jeder Uhr x ∈ X den Wert u(x)+d zuweist und u[r ↦→ 0]
mit u für alle x ∈ C \ r mit u übereinstimmt und den Uhren aus r null zuweist. Die
Transitionen sind mit Eingaben und Kosten versehen. Die erste ist eine ε-Transition,
d. h. der Zustand wird gehalten, es vergeht lediglich Zeit. Bedingung ist, dass die
Invariante des Zustands zu keiner Zeit verletzt wird. Die Kosten eines Ablaufs dieser
Transitionsrelation sind einfach die addierten Kosten der besuchten Zustände und
gefeuerten Transitionen.
Die Semantik der LPTA führt zu einem unendlichen Zustandsraum und ist somit
ungeeignet für eine Suche innerhalb dieses Zustandsraums. Um dieses Problem zu
umgehen, werden so genannte symbolische Zustände für Kosten zur Erkundung des
Zustandsraums eingeführt. Die symbolischen Zustände für Kosten sind den symbolischen
Zuständen, die UPPAAL und andere Modelchecker nutzen, um den durch
die Belegung der Uhren unendlichen Zustandsraum zu erkunden, sehr ähnlich.
Symbolische Zustände sind typischerweise Paare der Form (s,Z), wobei s ∈ S ein
Zustand ist und Z ⊆ R X eine konvexe Menge von Uhrenbelegungen. Z wird Region
genannt und kann durch Difference Bound Matrices (DBM) repräsentiert werden.
17

Die Operationen, die zur Suche im Zustandsraum nötig sind, können effizient in der
DBM Datenstruktur implementiert werden.
Für LPTA müssen nun auch die Kosten, mit denen Zustände erreicht werden,
repräsentiert werden. Hierfür werden symbolische Zustände für Kosten (s,C) eingeführt,
wobei C eine Kostenfunktion ist, die Uhrenbelegungen in Kostenwerte in R
abbildet. Die Idee ist, dass, wenn der symbolische Kostenzustand (s,C) erreichbar
ist und u eine Uhrenbelegung mit C(u) < ∞, dann kann der Zustand (s,u) mit den
Kosten C(u) erreicht werden.
3.1.3 Kosten
Sei α = (s 0 ,u 0 ) a 1,p 1
↦−→ (s1 ,u 1 )... an,pn
↦−→ (s n ,u n ) ein Ablauf des eingeführten Transitionssystems.
Die Kosten von α, formal cost(α), sind die Summe ∑ n
i=1 p i. Für einen
gegebenen Zustand (s,u) ist mincost(s,u) das Minimum der Kosten, das nötig ist
um den Zustand zu erreichen. mincost(s,u) ist also das Minimum der Kosten aller
endlichen Abläufe, die in (s,u) enden. Für einen gegebenen Zustand s des LPTA ist
mincost(s) das Minimum der Kosten, die nötig sind, um diesen Zustand zu erreichen.
mincost(s) ist also das Minimum der Kosten aller endlichen Abläufe, die mit
beliebiger Uhrenbelegung u in (s,u) enden.
3.1.4 Kostenfunktionen
Eine Kostenfunktion C : R X ↦→ R∪{∞} ordnet jeder Uhrenbelegung u eine positive
reelle Zahl oder unendlich zu. Der Träger (engl.: support) sup(C) = {u|C(u) < ∞}
ist die Menge aller Uhrenbelegungen, denen endliche Kosten zugeordnet werden.
Um einen Ablauf der symbolischen Semantik darstellen zu können, benötigen
wir eine Definition, wie sich eine Kostenfunktion ändert durch bsplw. das Vergehen
von Zeit in einem Zustand oder das Feuern einer Transition. In Tabelle 2 sind einige
übliche Operationen auf Kostenfunktionen aufgezeigt, die von der symbolischen
Semantik verwendet werden.
Die Operation Delay modelliert hierbei das Vergehen von Zeit in einem Zustand.
Es ist zu erkennen, dass die resultierenden Kostenfunktionen bereits die Suche nach
18

Operation Kostenfunktion (R X → R ≥0 )
Delay delay(C,p) : u ↦→ inf{C(v) + p · d|d ∈ R ≥0 ∧ v + d = u}
Rücksetzen r(C) : u ↦→ inf{C(v)|u = v[r ↦→ 0]}
Satisfaction
Inkrement
Vergleich
g(C) : u ↦→ C(u)|u |= g
C + k : u ↦→ C(u) + k,k ∈ N
D ⊑ C def
⇔ ∀u : D(u) ≤ C(u)
Infimum min(C) = inf{C(u)|u ∈ R X }
Tabelle 2: Übliche Operationen auf Kostenfunktionen
dem kostenminimalen Weg unterstützen, bsplw. ordnet die resultierende Kostenfunktion
nach dem Zurücksetzen von Uhren u das Infimum aller C(v) zu, wobei
u = v[r ↦→ 0]. Die Kostenfunktion g(C) modelliert die Erfüllung einer Transitionsbedingung
und mit Inkrement werden Kosten für Transitionen addiert. Der Vergleich
und das Infimum der Kostenfunktionen sind für einen konkreten Algorithmus wichtig,
der einen kostenoptimalen Pfad findet (siehe [4]). Dass gerade diese Definition
der Kostenfunktionen es möglich macht, kostenoptimale Pfade zu finden, wird ein
im nächsten Kapitel folgendes Beispiel klarer machen.
3.1.5 Symbolische Semantik
Sei A = (S,s 0 ,X, Σ,E,I,P) ein LPTA. Die symbolische Semantik ist definiert als
ein beschriftetes Transitionssystem über symbolische Zustände für Kosten der Form
(s,C), wobei s ein Zustand und C eine Kostenfunktion ist mit der Transitionsrelation:
1. (s,C) ε → (s,I(s)(delay(I(s)(C),P(s)))),
2. (s,C) a → (s ′ ,I(s)(r(g(C))) + p) genau dann wenn s g,a,r
↦−→ s ′ und
p = P((s,g,a,r,l ′ )).
Der Anfangszustand ist (s 0 ,C 0 ) mit sup(C 0 ) = {u 0 } und C 0 (u 0 ) = 0.
Die erste Transition modelliert hierbei das Vergehen von Zeit in einem Zustand,
wobei die resultierende Kostenfunktion aus C berechnet wird, indem diese zunächst
19

auf die Invariante eingeschränkt wird (I(s)(C)). Mit delay(I(s)(C),P(s)) wird dann
die Kostenfunktion berechnet, die bei Vergehen von Zeit entsteht, wobei P(s) die
Rate des Zustands ist. Letztlich muss die resultierende Kostenfunktion wieder auf
die Invariante eingeschränkt werden.
Die zweite Transition modelliert das Feuern einer Transition mit dem Ereignis
a, wobei die resultierende Kostenfunktion aus C berechnet wird, indem C auf die
Bedingung g der Transition s g,a,r
↦−→ s ′ eingeschränkt wird. Weiterhin muss die resultierende
Kostenfunktion das Zurücksetzen der Uhren aus r modellieren und auf die
Invariante des Zustands eingeschränkt werden. Letztlich bleibt die Kosten für die
Transition s ↦−→ g,a,r
s ′ zu addieren.
Mit einem Beispiel wollen wir versuchen, den Sinn der symbolischen Semantik
nachzuvollziehen. Wir betrachten noch einmal den LPTA aus Abbildung 8 und wollen
versuchen, den kostenminimales Pfad zum Endzustand s 2 in der symbolischen
Semantik auszudrücken (dieser hat die Kosten 10). Ein möglicher Ablauf wäre:
→ (s 0 ,C 0 ) a → (s 1 ,C 1 ) ε → (s 1 ,C 2 ) b → (s 0 ,C 3 ) ε → (s 0 ,C 4 ) a → (s 1 ,C 5 ) c → (s 2 ,C 6 )
wobei sich die Kostenfunktionen C 0 ,...,C 6 folgendermaßen berechnen:
• C 0 : sup(C 0 ) = u 0 = ( )
0
0 , C0 ( ( 0
0)
) = 0
• C 1 : C 1 = [x < 2] (([true](C 0 ))[∅ ↦→ 0] ) +3
} {{ }
u↦→C 0 (u)
} {{ }
u↦→C 0 (u)
} {{ }
u↦→C 0 (u)|u|=x

• C 3 : C 3 = [x < 2] (([true](C 2 ))[{x} ↦→ 0] ) +0
} {{ }
u↦→C 2 (u)
} {{ }
u↦→inf{C 2 (v)|u=v[x↦→0]}
} {{ }
u↦→inf{C 2 (v)|u=v[x↦→0]}|u|=x

(s,u) endet, einen symbolischen Ablauf β von A, der in dem symbolischen
Kostenzustand (s,C) endet, sodass C(u) = cost(α).
2. Ist der symboliche Kostenzustand (s,C) erreichbar und u ∈ sup(C), dann ist
mincost(s,u) ≤ C(u) für alle u.
Außerdem gilt das folgende Theorem:
mincost(s) = min{min(C)|(s,C) ist erreichbar}
Auch der Zustandsraum der symbolischen Semantik ist unendlich. [4] gibt einen
Ansatz für Uniformly Priced Timed Automata, LPTA für die gilt, dass alle Zustände
dieselbe Rate haben, um dieses Problem mittels repräsentierender Kostenfunktionen
zu lösen.
3.2 Optionen
Um die Heuristiken evaluieren zu können, muss die gesteuerte Suche mit verschiedenen
”
einfachen“ Suchalgorithmen verglichen werden. UPPAAL CORA stellt folgende
Suchalgorithmen als Möglichkeiten zur Verfügung:
• bfs: Breitensuche ( breadth-first-search“).
”
• dfs: Tiefensuche ( depth-first-search“).
”
• rdf: Randomisierte Tiefensuche. UPPAAL CORA hält intern eine Warteliste
der erreichbaren Zustände, die noch zu erforschen sind. Aus dieser Warteliste
wird zufällig ein Zustand ausgewählt. Die Ergebnisse der randomisierten
Tiefensuche sind sehr unterschiedlich. Aus diesem Grund wurden für die Evaluation
der Heuristiken mehrere Testdurchläufe mit dieser Suche getätigt und
ein Mittelwert gebildet.
• shf: smallest heur first“. Es ist möglich, Zuständen einen Wert heur zuzuordnen.
Wird diese Suche verwendet, so wird UPPAAL CORA aus der Warteliste
”
der erreichbaren und noch zu erforschenden Zustände denjenigen mit dem
kleinsten Wert heur als erstes weiter untersuchen.
22

• bf (c+r): In diesem Fall werden die Werte von cost und remaining addiert
und der Pfad mit niedrigster Summe gewählt ( best first“). ”
• rbdf (c+r): Ähnelt bf (c+r)“, bei Gleichheit der Summe von cost und
”
remaining wird zufällig entschieden, welcher Pfad weiter betrachtet wird.
Außerdem gibt es weitere Optionen in UPPAAL CORA, mit denen bsplw. die
Ausgabe des gefundenen Ablaufs eingestellt werden kann. Diese sind allerdings in
diesem Text nicht weiter von Belang, sondern lediglich für die Versuche mit UPPAAL
CORA wichtig.
23

4 Fallstudie: Fehlertolerante Fertigungszelle
Um die Heuristiken entwickeln und bewerten zu können, lag die Fallstudie Fehlertolerante
Fertigungszelle“, eine leichte Abwandlung der Fertigungszelle des For-
”
schungszentrum Informatik aus Karlsruhe als PLC-Automaten Modell vor. Diese
soll im Folgenden näher beschrieben werden.
4.1 Beschreibung
Die Fertigungszelle stellt einen typischen Industrieablauf dar, in dem ein Metallblech
(im Folgenden auch Werkstück genannt) verarbeitet wird und dabei mehrere
Stationen durchläuft. Der Lebenszyklus des Blechs beginnt im Modell auf einem Eingabeförderband,
von dem aus es auf einen rotierenden Tisch gelangt. Ein Roboter,
der zur Optimierung des Prozesses mit zwei Armen ausgestattet ist, befördert dann
die Platine in eine Presse, in der die eigentliche Verarbeitung des Werkstücks geschieht.
Der Roboter befördert dann die Platine auf ein Ausgabeförderband, sodass
das fertige Werkstück ausgeliefert wird.
Es sei an dieser Stelle darauf hingewiesen, dass leichte Unterschiede zwischen dem
Modell des Forschungszentrum Informatik und der Fehlertoleranten Fertigungszelle
bestehen. So fügt das Forschungszentrum Informatik einen Kran ein, der die Platine
vom Ausgabeförderband wieder auf das Eingabeförderband bewegt, um einen
geschlossenen Prozess zu erhalten. Auf diese Maßnahme wurde im Modell der PLC-
Automaten verzichtet, um die Realitätsnähe zu erhöhen. Weiterhin wurde im Modell
der PLC-Automaten eine Presse hinzugefügt, um höhere Fehlertoleranz zu erhalten.
Nun sollen die einzelnen Stationen, die das Metallblech durchläuft, bzgl. ihrer
Aufgaben näher betrachtet werden.
4.1.1 Eingabeförderband
Die Aufgabe des Eingabeförderbandes besteht darin, Bleche aufzunehmen und zum
rotierenden Tisch zu transportieren.
24

Abbildung 9: Fehlertolerante Fertigungszelle (Sicht von oben)
4.1.2 Rotierender Tisch
Nachdem der Tisch das Werkstück vom Eingabeförderband übernommen hat, muss
er sich in die passende Position begeben, damit der erste Arm des Roboters die
Platine aufnehmen kann. Hierzu ist eine horizontale Drehung um 45 Grad nötig sowie
eine Bewegung in vertikaler Richtung, da der Roboterarm sich nicht auf gleicher
Höhe befindet.
4.1.3 Roboter
Der Roboter besitzt zwei Arme. Um eine Platine fassen zu können, muss der entsprechende
Arm ausgefahren und der Magnet des Arms aktiviert sein. Der Roboter
rotiert, sodass es sowohl Positionen gibt, in denen der erste Arm eine Platine des
Tisches übernimmt oder aber die erste bzw. zweite Presse mit einem Werkstück
versorgt ((2), (4) und (6) in Abbildung 10) als auch Positionen, in denen der zweite
Arm ein fertiges Werkstück der ersten oder der zweiten Presse übernimmt oder eines
an das Ausgabeförderband weitergibt ((1), (3) und (5)). Grundsätzlich ist eine
Rotation von Position (1) nach (2) usw. vorgesehen, wobei aus Position (6) wieder
in (1) übergegangen wird. Sind allerdings nicht alle Voraussetzungen erfüllt, um eine
25

Position abzuarbeiten, kann der Roboter auch in die vorige Position rotiert werden.
(1) (2)
(3) (4)
(5) (6)
Abbildung 10: Positionen der Roboterrotation (Sicht von oben)
4.1.4 Pressen
Die Pressen stehen für die eigentliche Verarbeitung der Bleche. Diese wird aber nicht
weiter modelliert, der Aufenthalt eines Werkstücks in einer Presse kostet lediglich
Zeit. Beide Pressen haben drei vertikale Positionen, damit sie auf Höhe der Roboterarme
gebracht werden können, die mit unterschiedlichen, nicht veränderbaren
26

Höhen modelliert sind.
Abbildung 11: Seitenansicht von Roboter und Presse
4.1.5 Ausgabeförderband
Schließlich nimmt das Ausgabeförderband ein fertiges Werkstück vom zweiten Roboterarm
entgegen und liefert dieses aus.
4.2 Sensoren und Aktoren
Im vorigen Unterkapitel betrachteten wir die Fertigungszelle ”
objekt-orientiert“, nun
soll sie aus der Sicht des Kontrollprogramms betrachtet werden.
4.2.1 Sensoren
Das Kontrollprogramm erhält folgende Information über den Zustand des Systems
über entsprechende Sensoren:
• Befindet sich ein Blech am Ende des Eingabeförderbandes?
• Befindet sich der rotierende Tisch in unterer Position?
• Befindet sich der rotierende Tisch in oberer Position?
• Wie weit ist der rotierende Tisch bereits rotiert?
• Wie weit ist der erste Arm des Roboters ausgefahren (analog für den zweiten
Arm)
27

• Wie weit ist der Roboter bereits rotiert?
• Befindet sich die erste Presse in unterer Position? (analog für die zweite Presse)
• Befindet sich die erste Presse in mittlerer Position? (analog für die zweite
Presse)
• Befindet sich die erste Presse in oberer Position? (analog für die zweite Presse)
• Befindet sich ein Blech am Ende des Ausgabeförderbandes?
4.2.2 Aktoren
Das System kann mithilfe folgender Aktionen gesteuert werden:
• Aktivieren und Deaktivieren des Eingabeförderbandes
• Rotieren des rotierenden Tisches
• Vertikales Bewegen des rotierenden Tisches
• Ein- bzw. Ausfahren des ersten Armes (analog für den zweiten Arm)
• Aufnehmen bzw. Ablegen eines Blechs mit dem ersten Arm (analog für den
zweiten Arm)
• Rotieren des Roboters
• Vertikales Bewegen der ersten Presse (analog für die zweite Presse)
• Aktivieren und Deaktivieren des Ausgabeförderbandes
4.3 Anforderungen
Nun sollen einige Anforderungen, die an die Fertigungszelle gestellt werden, diskutiert
werden. Die wichtigsten sind hierbei sicher die im Rahmen von Realzeitsystemen
am umfassendsten betrachteten Sicherheits- und Lebendigkeitseigenschaften.
Sollte die Sicherheit nicht gewährleistet sein, können in diesem Fall nicht nur Kosten
oder Ausfall von Maschinen entstehen, sondern es kann auch zu Verletzungen von
Menschen kommen.
28

4.3.1 Sicherheit
Jede Sicherheitsanforderung an die Fertigungszelle ist eine Konsequenz aus einem
der folgenden Prinzipien:
• begrenzte Maschinenmobilität: Der Roboter bsplw. würde sich bei zu großer
Rotation selbst zerstören.
• Kollisionsvermeidung: Ein Roboterarm kann mit einer Presse kollidieren, wenn
nicht beide Maschinen die richtige Ausrichtung haben.
• Sicheres Abladen einer Platine: Die Platine darf nur an sicheren Stellen abgelegt
werden, das Eingabeförderband darf z. B. nur weiterlaufen, wenn der
rotierende Tisch in der richtigen Position ist.
• Genügend Abstand der Platinen zueinander: Zwei Lichtsensoren können z.
B. zwei Platinen, die nicht in ausreichendem Abstand zueinander sind, nicht
auseinanderhalten.
4.3.2 Lebendigkeit
Eine sehr starke Anforderung an das System wäre z. B.
• Wenn eine Platine auf das Eingabeförderband gelegt wird, erreicht diese auch
irgendwann das Ausgabeförderband.
Darüber hinaus gibt es viele weitere schwächere Lebendigkeitseigenschaften, bsplw.
• Wenn eine Platine auf das Eingabeförderband gelegt wird, geht irgendwann
das Eingabeförderband an.
4.4 Simulation des Werkstücks
Von speziellem Interesse wird in Kapitel 5 die Simulation des Werkstücks sein. Um
den Realzeitautomaten verstehen zu können, benötigt man einige Variablen, die die
Werte der Sensoren und Aktoren der Fehlertoleranten Fertigungszelle darstellen.
29

Tabelle 3 gibt eine Übersicht. Die Mächtigkeit des Wertebereichs von rb rot ist 13,
da auch Zwischenpositionen“ derer, die in Abbildung 10 zu sehen sind, angezeigt
”
werden können. Mit diesen Variablen ist es nun möglich, einen Realzeitautomaten
zu konstruieren, der den Lebenszyklus eines Werkstücks abbildet:
Abbildung 12: Lebenszyklus eines Werkstücks
Der Automat beschreibt den Lebenszyklus eines Werkstücks vom Eintritt in das
System über das Eingabeförderband bis zum Austritt über das Ausgabeförderband.
Die erste Zwischenstation ist der rotierende Tisch. Bei diesem Übergang wird zu diskreten
Zeitpunkten überprüft, ob das Eingabeförderband läuft (fb=1). Wenn dies
30

Variable Werte- Beschreibung
bereich
blank start fb {0, 1} 1, wenn sich am Anfang des Eingabeförderbandes
(fb für ”
feed belt“) ein Blech (blank) befindet,
sonst 0
blank end fb {0, 1} 1, wenn sich am Ende des Eingabeförderbandes
ein Blech befindet, sonst 0
blank on tb {0, 1} 1, wenn sich auf dem rotierenden Tisch (tb für
table“) ein Blech befindet, sonst 0
”
tb vert pos {0, 1, 2} die drei vertikalen Positionen des Tisches
(1: ”
am Eingabeförderband“, 0: ” Übergabe an Arm 1“)
tb horiz pos {0, 1, 2} die drei horizontalen Positionen des Tisches
(1: ”
am Eingabeförderband“, 0: ” Übergabe an Arm 1“)
blank in pr1 {0, 1} 1, wenn sich in Presse 1 ein Blech befindet, sonst 0
blank in pr2 {0, 1} 1, wenn sich in Presse 2 ein Blech befindet, sonst 0
press1 pos {0, 1, 2} 1, wenn die Presse 1 ein Blech von Arm 1 empfängt,
0 bei Übergabe eines Bleches an Arm 2, sonst 2
press2 pos {0, 1, 2} 1, wenn die Presse 2 ein Blech von Arm 1 empfängt,
0 bei Übergabe eines Bleches an Arm 2, sonst 2
rb rot {0,..., 12} die 13 verschiedenen Positionen der Roboterrotation
a1 motor {0, 1, 2} 0 bei ausgefahrenem Arm 1, 1 bei eingefahrenem,
sonst 2
a2 motor {0, 1, 2} 0 bei ausgefahrenem Arm 2, 1 bei eingefahrenem,
sonst 2
blank start db {0, 1} 1, wenn sich am Anfang des Ausgabeförderbandes
(db für ”
deposit belt“) ein Blech befindet, sonst 0
blank end db {0, 1} 1, wenn sich am Anfang des Ausgabeförderbandes
ein Blech befindet, sonst 0
Tabelle 3: Sensor- und Aktorvariablen
31

zu 5 Zeitpunkten der Fall war, dann kann der Automat bei richtiger Stellung des
rotierenden Tisches in den Zustand on tb übergehen. Eine unsichere Situation entsteht,
wenn das Eingabeförderband zu lange läuft, ohne dass der rotierende Tisch
sich in richtiger Position zum Förderband befindet. Dies wird mit dem Fehlerzustand
err tb modelliert, zu dem übergegangen wird, wenn blank i den Wert 6 hat, d. h.,
wenn zu 6 Zeitpunkten das Eingabeförderband lief.
Vom rotierenden Tisch aus kann das Blech bei ausgefahrenem Arm 1 und passender
Position des Tisches vom Magneten an Arm 1 übernommen werden. Ist eine
Presse in passender horizontaler Position, die Roboterrotation entsprechend und der
erste Arm ausgefahren, übernimmt diese das Blech. Schließlich gelangt das Blech,
wenn alle Voraussetzungen stimmen, mit dem Arm 2 des Roboters zum Ausgabeförderband.
Mit diesem Automat, der als Testautomat aufgefasst werden kann, wurden die
Heuristiken in Kapitel 5 evaluiert. Der Vorteil ist die leichte Erweiterbarkeit. Ist
bsplw. die Anfrage nach Erreichbarkeit des Zustands end db nicht mehr erfolgreich,
d. h. die Anfrage benötigt mehr als den zugesicherten Speicher, dann kann alternativ
nach der Erreichbarkeit eines anderen, nicht so weit vom Anfangszustand entfernten,
Zustands gefragt werden. Um das System zu vergrößern, kann einfach ein weiteres
Blech zum System hinzugefügt werden. Dies kann sinnvoll sein, wenn die Anfragen
mit einem Blech im System nach kurzer Zeit eine Antwort liefern und die Güte der
verschiedenen Heuristiken nicht deswegen nicht nachvollzogen werden kann.
32

5 Heuristiken
Das Kernkapitel dieser Arbeit widmet sich den Heuristiken, die die Fehlersuche in
der Realzeitsemantik eines PLC-Automaten so steuern, dass das Ergebnis effizienter,
d. h. in weniger Zeit, gefunden wird. Da zur Verifikation mit UPPAAL die Realzeitsemantik
von PLC-Automaten genutzt wird, haben wir kontextuelle Informationen,
die UPPAAL nicht hat:
• UPPAAL differenziert nicht die verschiedenen Automaten, die im Gesamten
einen PLC-Automaten simulieren. Bsplw. wissen wir, dass es Treiber gibt, die
umweltgesteuerte Variablen setzen.
• Die Realzeitautomaten verhalten sich zyklisch, um das Verhalten der PLC-
Automaten zu simulieren.
Außerdem soll die zu verifizierende Eigenschaft ebenfalls betrachtet werden, um
so die Suche zu steuern. UPPAAL tut dies normalerweise nicht, da davon ausgegangen
wird, dass ohnehin der gesamte Zustandsraum durchsucht werden muss.
Es werden zunächst die gefundenen Heuristiken vorgestellt und danach werden
diese evaluiert. Grundlage hierfür ist die im Kapitel 4 beschriebene Fehlertolerante
Fertigungszelle, deren Realzeitsemantik als Eingabe für den Modelchecker UPPAAL
CORA diente. Alle Berechnungen wurden auf einem Pentium-M 1400 MHz mit 1
GB Speicher durchgeführt. Abschließend wird kurz auf die Implementierung der
Heuristiken in Moby/RT eingegangen.
5.1 Kosten für einen Zyklus
Ein Zyklus eines PLC-Automaten besteht aus den Phasen Polling, Computing und
Updating. Es kann sinnvoll sein, die Kosten für einen Zyklus zu erhöhen, wenn man
bsplw. die Information hat, dass das Modell mit wenigen Änderungen der Eingabevariablen
auskommt, um den Fehler zu erzeugen.
Wie bereits in Kapitel 2.3 beschrieben, wird für den Wert des Programmzählers
eine eigene Variable reserviert. Die Addition der Kosten C 1 muss lediglich während
der tick-Transitionen passieren:
33

Abbildung 13: Der Programmzähler, versehen mit Kosten für einen Zyklus
5.2 Kosten für die Änderung einer Eingabevariable
Das Ändern des Wertes einer Eingabevariable hat im Allgemeinen großen Einfluss
auf das Verhalten des Systems. Unter Umständen sind mehrere Computing-Phasen
nötig, bis die Auswirkungen komplett berechnet worden sind. Grundsätzlich kann
allerdings in jeder Polling-Phase eine Wertänderung der Eingabevariable passieren,
da die Umwelt dies theoretisch zulässt. Die Zahl der möglichen Folgezustände erhöht
sich immens, weswegen es sich anbietet, die Transitionen, die eine Eingabevariable
ändern, mit höheren Kosten (im Vergleich zu allen anderen Transitionen) zu versehen.
In Kapitel 2.3 wurde besprochen, dass für jede von der Umwelt gesteuerte Variable
ein Treiber eingeführt wird, der eine Wertänderung zu jeder Zeit zulässt.
Außerdem kann die Variable ein beliebiges Element ihres Wertebereichs annehmen.
Wir erreichen nun dadurch, dass wir jeder Treibertransition die Kosten C 2 zuordnen,
den gewünschten Effekt:
Abbildung 14: Treiber für Variable t (v ∈ dom(t) beliebig)
34

5.3 Abstand zum Fehlerzustand
Die grundsätzliche Idee dieser Heuristik ist, dass jedem Zustand ein heuristischer
Wert zugeordnet wird, und zwar in Abhängigkeit zu der Anzahl der Transitionen,
die aus diesem Zustand noch gefeuert werden müssen, um zum Fehlerzustand zu
gelangen. Ist von einem Zustand aus der Fehlerzustand nicht mehr erreichbar, so
wird als heuristischer Wert unendlich zugeordnet 3 .
Es sollen die Realzeitautomaten A 1 ,...,A n auf eine bestimmte Eigenschaft untersucht
werden. Seien für die Automaten A 1 ,...,A k die Zielzustände d i , i ∈ {1,...,k}
bekannt, dann bieten sich folgende Varianten der Heuristik an:
• f(q 1 ,...,q k ) = ∑ k
i=1 dist(q i,d i ) · C 3
• f(q 1 ,...,q k ) = ∏ k
i=1 (1 + dist(q i,d i ) · C 3 )
wobei dist(q,q ′ ) die Mindestanzahl der Transitionen liefert, die gefeuert werden
müssen um von q nach q ′ zu gelangen.
Diese Heuristik innerhalb der Realzeitsemantik der PLC-Automaten umzusetzen,
gestaltet sich nicht so einfach, wie bei den vorher vorgestellten heuristischen
Ansätzen. Sie wird deshalb Hauptthema des Kapitels 5.5 sein.
Um UPPAAL CORA noch deutlicher in Richtung des Zielzustands zu lenken,
werden wir noch eine zusätzliche Variante probieren: Für den Fall, dass q und q ′
Zustände sind, es eine Kante von q nach q ′ gibt und q ′ dem Zielzustand näher ist
als q, reduzieren wir den heuristischen Wert für q, je nachdem wie viele Variablen
den passenden Wert haben, um die Kante von q nach q ′ zu nehmen.
5.4 Evaluation
Zur Evaluation wurde der Werkstück-Automat aus Kapitel 4.4 genutzt. In Tabelle
4 sind die Ergebnisse (Zeit in Sekunden) mit einem einzigen Blech im System zu
sehen. Gewünscht ist, dass dieses Werkstück bis zu Ende des Ausgabeförderbandes
3 Praktisch reicht ein Wert, der größer als alle Werte ist, die Zuständen zugeordnet sind, von
denen aus der Fehlerzustand erreichbar ist. Denn UPPAAL betrachtet diesen Pfad dann nicht
weiter.
35

( deposit belt“) kommt, und schon bei dieser Aufgabe liefert die Breitensuche kein
”
Ergebnis trotz 900 MB Speicher und das Ergebnis der Tiefensuche ist mit 777.09
Sekunden sehr viel schlechter als mit Heuristiken. Sobald allerdings die Heuristik
des Abstands zum Fehlerzustand UPPAAL CORA als Wert für heur übergeben
wird, findet die Suche smallest heur first“, die den Pfad des kleinsten Wertes von
”
heur als Erstes verfolgt, einen Ablauf in gut 20 Sekunden. heur wird in diesem Fall
berechnet, wie in Kapitel 5.3 beschrieben, wobei der Werkstück-Automat derjenige
ist, dessen Zielzustand wir kennen. Die randomisierte Tiefensuche liefert zwar nach,
im Vergleich guten, 30,53 Sekunden im Schnitt ein Ergebnis, allerdings bleibt ein
Versuch erfolglos.
C 1 C 2 C 3 bf df rdf 4 shf bf (c+r) rbdf (c+r)
0 0 10 21.63 22.03 21.32
0 1 10 22.03 19.68 19.28
1 0 10 21.83 22.14 20.92
1 1 10 k.A. 5 777.09 30.53 6 22.75 19.92 19.48
0 0 10* 40.81 41.53 21.01
0 1 10* 1068.65 21.73 19.69
1 0 10* 40.91 40.33 20.91
1 1 10* 1063.52 21.84 19.49
Tabelle 4: Evaluation mit einem Blech im System (mit Ziel: end db)
Die Optimierungsidee, pro Variable, die den gewünschten Wert hat, um eine Kante
zu nehmen, den heuristischen Wert weiter zu reduzieren (gekennzeichnet durch
* in der Spalte C 3 ), erweist sich hier übrigens als kontraproduktiv, da die Zeiten
hierbei um 40 Sekunden liegen. Sowohl bei der Suche bf als auch bei ”
randomdepth-best-first“
wurde remaining der gleiche Wert wie heur zugeordnet, deswegen
überrascht es kaum, dass die Ergebnisse bei diesen Suchen ähnlich um 20 Sekunden
liegen wie bei der Suche bf.
Die Hinzunahme von Kosten für einen Zyklus führt zu keiner relevanten Verbesserung,
aber bei den Suchen bf und rdbf macht sich das Erhöhen der Kosten
4 Es wird ein Durchschnittswert von zehn Versuchen angegeben.
5 Nach ca. 40 Minuten war der zugesicherte Speicher von 900 MB aufgebraucht.
6 Ein Versuch blieb bei vorgesehenem Speicher von 900 MB erfolglos.
36

für eine Treibertransition bemerkbar. Dies kann daran liegen, dass Pfade, auf denen
Treibertransitionen genommen werden, von UPPAAL CORA zunächst nicht weiter
betrachtet werden. UPPAAL CORA findet dann schneller einen gewünschten Ablauf,
da das System auch keine Treibertransitionen ausführen muss, um das Blech
auf das Ende des Ausgabeförderbandes zu transportieren.
∑ ∏
C 1 C 2 C 3 | bf df rdf shf
∑
0 0 10
1.22
∑
0 1 10
1.23
∏
0 0 10
1.22
∏
0 1 10 5.41 127.74 1.23 7 1.23
∑
0 0 10*
1.22
∑
0 1 10*
1.23
∏
0 0 10*
1.23
∏
0 1 10*
1.22
Tabelle 5: Evaluation mit zwei Blechen (Ziele: start fb, end fb)
∑ ∏
C 1 C 2 C 3 | bf df rdf shf
∑
0 0 10
2.55
∑
0 1 10
2.65
∏
0 0 10
2.56
∏
0 1 10 k.A. 8 128.95 1.94 9 2.65
∑
0 0 10*
3.16
∑
0 1 10*
3.47
∏
0 0 10*
3.27
∏
0 1 10*
3.47
Tabelle 6: Evaluation mit zwei Blechen (Ziele: start fb, on tb)
7 Dieses Ergebnis wurde bei drei Versuchen erzielt, die restlichen sieben Versuche blieben erfolglos.
8 Nach ca. 30 Minuten war der vorgesehene Speicher von 900 MB aufgebraucht.
9 Dieses Ergebnis wurde bei einem Versuch erzielt, die restlichen neun Versuche blieben erfolglos.
37

∑ ∏
C 1 C 2 C 3 | bf df rdf shf
∑
0 0 10
2.55
∑
0 1 10
2.65
∏
0 0 10
2.55
∏
0 1 10 k.A. 136.47 1.94 10 2.56
∑
0 0 10*
3.16
∑
0 1 10*
3.37
∏
0 0 10*
3.06
∏
0 1 10*
3.37
Tabelle 7: Evaluation mit zwei Blechen (Ziele: end fb, on tb)
Die Tabellen 5, 6, 7 zeigen nun die Ergebnisse der Versuche mit zwei Blechen im
System der Fehlertoleranten Fertigungszelle. UPPAAL CORA vermag maximal noch
zu verifizieren, dass ein Werkstück bis auf den Tisch gelangt, was aber angesichts
der Größe des ganzen Systems auch nicht verwundern sollte.
Zwar liefert die randomisierte Tiefensuche erstaunlich schnelle Ergebnisse, allerdings
war dies nur maximal bei drei von zehn Versuchen der Fall (drei für start fb,
end fb, einer bei start fb, on tb und zwei bei end fb, on tb) und ist somit nicht
wirklich mit der heuristisch unterstützten Suche zu vergleichen. Diese liefert für die
Verifikation, dass ein Blech auf den Tisch und eins ans Ende des Eingabeförderbands
gelangt, das Ergebnis mehr als 50-mal schneller als die Tiefensuche.
Der Vergleich der Varianten Summe und Produkt für die Heuristik zum Abstand
zum Fehlerzustand lässt sich nicht ziehen, da die Heuristik sehr schnell Ergebnisse
für diese Anfragen liefert, aber leider für komplexere Anfragen nicht zum Ende
kommt. Trotzdem kann gerade die Heuristik, die sich nach Abstand zum Fehlerzustand
berechnet, als Erfolg gewertet werden. Die Variante des Reduzierens des
heuristischen Wertes pro Variable, die den gewünschten Wert hat, führt nicht zu
besseren Ergebnissen und wird aus diesem Grund auch nicht implementiert werden.
10 Dieses Ergebnis wurde bei zwei Versuchen erzielt, die restlichen acht Versuche blieben erfolglos.
38

5.5 Implementierung
Neben dem UPPAAL-Service-Fenster, das dem Benutzer ermöglicht, einen Namen
der ta-Datei sowie die zu abstrahierenden Variablen anzugeben, existiert nun ein
CO-UPPAAL-Service-Fenster, mit dem der Benutzer zusätzlich die heuristischen
Eingaben tätigen kann. Es existieren Textfelder zur Eingabe der gewünschten Kosten
für einen Zyklus und eine Treibertransition sowie ein Switch, ob die Heuristik aus
Kapitel 5.3 mit Produkt oder Summe berechnet werden soll.
Abbildung 15: CO-UPPAAL-Service-Fenster
Die Implementierung der Kosten für Zyklus und Treibertransition gestaltete sich
dann nicht sehr schwierig, was sich mit den Kapiteln 5.1 und 5.2 nachvollziehen lässt.
Deswegen wird hierauf innerhalb dieses Kapitels nicht weiter eingegangen.
39

Vielmehr soll das Augenmerk auf die Verwirklichung der Heuristik aus Kapitel
5.3 gesetzt werden. Um den Abstand eines Zustands q zum Zielzustand d zu ermitteln,
wurde zunächst eine Adjazenzmatrix A des Graphen, der den zugehörigen
PLC-Automaten darstellt, errechnet. Mit den Potenzen dieser Matrix ließ sich die
Distanzmatrix berechnen, aus der letztlich der heuristische Wert berechnet werden
kann.
Listing 1 zeigt beispielhaft, wie die Berechnung des heuristischen Werts heur in
UPPAAL CORA funktioniert. Die innerhalb des after update-Blockes angegebenen
Berechnungen werden vom Modelchecker nach Schalten einer Transition durchgeführt.
Das Beispiel zeigt, wie heur als Produkt aufgrund der Heuristik Abstand ”
zum Fehlerzustand“ für zwei Werkstücke (vgl. Abbildung 12) berechnet wird, wobei
err tb jeweils der Zielzustand ist. Mittels des UPPAAL-Service von Moby/PLC
wird automatisch zu jedem Automaten eine Variable (im Beispiel: blank0 states
und blank1 states) erstellt, die den aktuellen Zustand des Automaten speichert.
Außerdem werden Konstanten zur Verfügung gestellt, um die Zustandsvariable abfragen
zu können (z. B. ENUM blank0 states start).
Listing 1: Beispiel einer after update-Definition
after update {
heur = 0
+ (1
+ ( blank0 states==ENUM blank0 states start ? 3 : 0 )
+ ( blank0 states==ENUM blank0 states start fb ? 2 : 0 )
+ ( blank0 states==ENUM blank0 states end fb ? 1 : 0 )
+ ( blank0 states==ENUM blank0 states err tb ? 0 : 0 )
)
∗ (1
+ ( blank1 states==ENUM blank1 states start ? 3 : 0 )
+ ( blank1 states==ENUM blank1 states start fb ? 2 : 0 )
+ ( blank1 states==ENUM blank1 states end fb ? 1 : 0 )
+ ( blank1 states==ENUM blank1 states err tb ? 0 : 0 )
)
}
40

6 Schlussbetrachtung
6.1 Zusammenfassung
Neben der Möglichkeit, PLC-Automaten in konkreten Source-Code für Speicherprogrammierbare
Steuerungen zu übersetzen, bietet sich ihre Realzeitsemantik zur
Verifikation mit UPPAAL an, da sie kontextuelle Information bietet, die UPPAAL
nicht hat. Die Realzeitsemantik von PLC-Automaten dient als Eingabe für UPPAAL
CORA. Die kontextuelle Information kann genutzt werden, um UPPAAL CORA bei
der Suche nach Fehlern zu lenken, indem den Transitionen der Realzeitautomaten
Kosten zugeordnet werden oder die Reihenfolge der zu erkundenden Zustände festgelegt
wird. Speziell die heuristische Idee, dass Zustände, die dem Fehlerzustand
am nächsten sind, zuerst erkundet werden, führte dazu, dass UPPAAL CORA das
gewünschte Ergebnis in erheblich weniger Zeit lieferte.
6.2 Ausblick
Im Rahmen dieser Arbeit war es lediglich möglich, die heuristischen Ideen an einer
einzigen Fallstudie zu evaluieren, es bliebe zu prüfen, wie sie in anderen Fallbeispielen
abschneiden. Insbesondere die Kosten für das Setzen einer umweltgesteuerten
Variable haben sich innerhalb der Evaluation nicht in dem Maße ausgezahlt, wie
das vielleicht zu erwarten war.
Der Benutzer muss zurzeit die Zielzustände der PLC- bzw. Realzeitautomaten
in Moby/PLC selber angeben, es wäre sicherlich sinnvoller, wenn als zuätzliche kontextuelle
Information die zu verifizierende Eigenschaft herangezogen wird. Näheres
entnehme der interessierte Leser hierzu [7].
Darüber hinaus gilt es, die kontextuelle Information, die durch Verwendung der
Realzeitsemantik von PLC-Automaten besteht, besser zu nutzen und weitere heuristische
Ideen zu entwickeln, um die Suche nach Fehlern effizient steuern zu können.
41

Abbildungsverzeichnis
1 Zyklus einer SPS (Quelle: [13]) . . . . . . . . . . . . . . . . . . . . . . 6
2 Der Programmzähler . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Zugsensorsteuerung 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Typischer Ablauf der Zugsensorsteuerung 1 (Quelle: [13]) . . . . . . . 11
5 Zugsensorsteuerung 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6 Typischer Ablauf der Zugsensorsteuerung 2 (Quelle: [13]) . . . . . . . 12
7 Realzeitsemantik von Zugsensorsteuerung 1 . . . . . . . . . . . . . . . 13
8 Beispiel eines LPTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9 Fehlertolerante Fertigungszelle (Sicht von oben) . . . . . . . . . . . . 25
10 Positionen der Roboterrotation (Sicht von oben) . . . . . . . . . . . . 26
11 Seitenansicht von Roboter und Presse . . . . . . . . . . . . . . . . . . 27
12 Lebenszyklus eines Werkstücks . . . . . . . . . . . . . . . . . . . . . . 30
13 Der Programmzähler, versehen mit Kosten für einen Zyklus . . . . . . 34
14 Treiber für Variable t (v ∈ dom(t) beliebig) . . . . . . . . . . . . . . . 34
15 CO-UPPAAL-Service-Fenster . . . . . . . . . . . . . . . . . . . . . . 39
Literatur
[1] R. Alur and D. Dill. A theory of timed automata. 1994.
[2] G. Behrmann. Uppaal cora. http://www.cs.aau.dk/~behrmann/cora/, 2004.
[3] G. Behrmann, E. Brinksma, M. Hendriks, and A. Mader. Production
scheduling by reachability analysis a case study.
www.cs.ru.nl/ita/publications/papers/martijnh/AXXOM/axxom.pdf,
2004.
42

[4] G. Behrmann and A. Fehnker. Efficient guiding towards cost-optimality in
uppaal. In TACAS 2001: Proceedings of the 7th International Conference on
Tools and Algorithms for the Construction and Analysis of Systems, pages 174–
188. Springer-Verlag, 2001.
[5] H. Dierks. The production cell: A verified real-time system. In B. Jonsson
and J. Parrow, editors, Formal Techniques in Real-Time and Fault-Tolerant
Systems, volume 1135, pages 208–227. Springer-Verlag, 1996.
[6] H. Dierks. Plc-automata: A new class of implementable real-time automata.
In M. Bertran and T. Rus, editors, Transformation-Based Reactive Systems
Development, volume 1231, pages 111–125. Springer-Verlag, 1997.
[7] H. Dierks. Heuristic guided model-checking of real-time systems, 2004.
[8] H. Dierks. Verifikation von hybriden systemen, 2004.
[9] U. Knauer. Diskrete Strukturen - kurz gefasst. Spektrum Akademischer Verlag
GmbH, 2001.
[10] K. G. Larsen, G. Behrmann, E. Brinksma, A. Fehnker, T. S. Hune, P. Pettersson,
and J. Romijn. As cheap as possible: Efficient cost-optimal reachability for
priced timed automata. pages 493–505, 2001.
[11] C. Lewerentz and T. Lindner. Case Study Production Cell. 1993.
[12] P. Niebert. The vhs esprit project homepage.
http://www-verimag.imag.fr/VHS/main.html, 2005.
[13] E.-R. Olderog, M. Schenke, and H. Dierks. Realzeitsysteme vorlesungsskript,
2003.
[14] A. Project. Ametist. http://ametist.cs.utwente.nl/, 2005.
[15] U. UNIVERSITET and A. UNIVERSITY. Uppaal - home. www.uppaal.com,
2005.
[16] J. Xu, B. Randell, and A. Romanovsky. A generic approach
to structuring and implementing complex fault-tolerant software.
www.comp.leeds.ac.uk/edemand/publications/xu02a.pdf, 2002.
43