Masterthesis im Fachbereich Elektrotechnik & Informatik an ...edoc.sub.uni-hamburg.de/haw/volltexte/2015/2887/pdf/MAThesis.pdf · Nadine Gohert Thema der Masterthesis Automatische

MasterthesisNadine Gohert

Automatische SPS-Codegenerierung fürSyntheseverfahren der Supervisory Control

Theory

Fakultät Technik und InformatikDepartment Informations- undElektrotechnik

Faculty of Engineering and Computer ScienceDepartment of Information andElectrical Engineering

Nadine Gohert

Automatische SPS-Codegenerierung fürSyntheseverfahren der Supervisory Control Theory

Masterthesis eingereicht im Rahmen der Masterprüfungim Masterstudiengang Automatisierungam Department Informations- und Elektrotechnikder Fakultät Technik und Informatikder Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer : Prof. Dr.-Ing. Florian WenckZweitgutachter : Prof. Dr. rer. nat. Annabella Rauscher-Scheibe

Abgegeben am 4. Dezember 2014

Nadine Gohert

Thema der MasterthesisAutomatische SPS-Codegenerierung für Syntheseverfahren der Supervisory ControlTheory

StichworteEreignisdiskrete Systeme, Supervisory Control Theory, Steuerungssynthese, SPS-Codegenerierung, Automaten, Petrinetze

KurzzusammenfassungDiese Arbeit befasst sich allgemein mit der SPS-Codegenerierung und deren Proble-matik für verschiedene Syntheseverfahren der Supervisory Control Theory. Die au-tomatische SPS-Codegenerierung wird für zwei Verfahren umgesetzt. Dafür wird einCodegenerator entwickelt. Das erste Verfahren ist der lokal-modulare Entwurfsansatzfür Automaten und das zweite ist der Steuerungsentwurf mit Stelleninvarianten fürPetrinetze. Der generierte SPS-Code wird abschließend anhand einer realen Ferti-gungszelle verifiziert.

Nadine Gohert

Title of the paperAutomatic PLC code generation for synthesis methods of the Supervisory ControlTheory

KeywordsDiscrete event systems, Supervisory Control Theory, control synthesis, PLC codegeneration, Automata, Petri nets

AbstractThis work generally deals with the PLC code generation and their problems for differ-ent synthesis methods of the Supervisory Control Theory. The automatic PLC codegeneration is implemented for two methods. Therefore a code generator is developed.The first method is the local-modular design approach for automata and the secondis the control design with place invariants of Petri nets. The generated PLC code isfinally verified by a real manufacturing cell.

Danksagung

An dieser Stelle möchte ich mich bei den Professoren Prof. Dr.-Ing. Florian Wenck und Prof.Dr. rer. nat. Annabella Rauscher-Scheibe für ihre Arbeit als Erst- und Zweitprüfer bedanken.Insbesondere danke ich Herrn Prof. Dr.-Ing. Wenck für das gemeinsame Entwickeln desThemas im Bereich der SCT und für die gute, richtungweisende Betreuung während jederEntwicklungsphase dieser Arbeit. Außerdem bedanke ich mich herzlich bei Herrn Dipl.-Ing.Huß für seine Unterstützung im Labor.

Vielen Dank auch an Ariane Dauch und Yvonne Seifert für die Durchsicht dieser Arbeit.

Ich danke meiner Familie und meinen Freunden dafür, dass sie mich in jeder Lebenlageunterstützen und großes Vertrauen in mich haben.

Für meine Eltern, meine Schwester Janina und für Dominique

Inhaltsverzeichnis

Tabellenverzeichnis 7

Abbildungsverzeichnis 8

Abkürzungsverzeichnis 10

1. Einführung 121.1. Einführung und Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3. Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2. Grundlagen 152.1. Systemtheoretische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Ereignisdiskrete Systeme . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2. Beschreibungsformen für ereignisdiskrete Systeme . . . . . . . . . . 162.1.3. Analyse ereignisdiskreter Systeme . . . . . . . . . . . . . . . . . . . 242.1.4. Supervisory Control Theory . . . . . . . . . . . . . . . . . . . . . . 282.1.5. Strukturelle Steuerungsentwurfsansätze . . . . . . . . . . . . . . . . 31

2.2. SPS-Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3. Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.1. Siemens TIA Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.2. DESTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.3. SPNBOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3. Automatische Codegenerierung 393.1. Grundstrukturen und ihre Codegenerierung . . . . . . . . . . . . . . . . . . 393.2. Problematiken der Codegenerierung . . . . . . . . . . . . . . . . . . . . . . 423.3. Literaturüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.1. Codegenerierung mit Selfloop Ausgängen . . . . . . . . . . . . . . . 453.3.2. Codegenerierung mit der DECON9 Methodik . . . . . . . . . . . . . 463.3.3. Codegenerierung mit SIPN . . . . . . . . . . . . . . . . . . . . . . . 50

4. Konzeption 524.1. Auswahl des Entwurfsverfahren . . . . . . . . . . . . . . . . . . . . . . . . 52

Inhaltsverzeichnis 6

4.2. Konzept zur Codegenerierung . . . . . . . . . . . . . . . . . . . . . . . . . 534.3. Auswahl des Entwicklungstools . . . . . . . . . . . . . . . . . . . . . . . . 55

5. Entwicklung des Entwurfsansatzes für Petrinetze mit der Toolbox SPNBOX 56

6. Codegenerator ACArrow 586.1. Aufbau des Codegenerators . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2. Die Datenbank als zentrales Werkzeug . . . . . . . . . . . . . . . . . . . . 606.3. Analyse der Eingangsprotokolle . . . . . . . . . . . . . . . . . . . . . . . . 626.4. Codegenerierung für Automaten . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4.1. Ein- und Ausgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.4.2. Benutzerfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4.3. Programmfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 686.4.4. Codegenerierungsbeispiel für den lokal-modularen Ansatz . . . . . . 70

6.5. Codegenerierung für Petrinetze . . . . . . . . . . . . . . . . . . . . . . . . 766.5.1. Ein- und Ausgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.5.2. Benutzerfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.5.3. Programmfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5.4. Codegenerierungsbeispiel für den Entwurf mit S-Invarianten . . . . . 80

6.6. Ausgabedateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7. Anwendungsbeispiel: Fertigungszelle 857.1. Beschreibung der Fertigungszelle . . . . . . . . . . . . . . . . . . . . . . . 857.2. Entwurf nach dem lokal-modularen Ansatz . . . . . . . . . . . . . . . . . . 897.3. Steuerungsentwurf mit S-Invarianten . . . . . . . . . . . . . . . . . . . . . 917.4. Realisierung und Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . 93

7.4.1. Implementierung der Steuerung . . . . . . . . . . . . . . . . . . . . 937.4.2. Initialisierung der Strecke . . . . . . . . . . . . . . . . . . . . . . . . 947.4.3. Betriebsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8. Auswertung - Entwurfsansätze und Codegenerierung im Vergleich 97

9. Zusammenfassung 100

Literaturverzeichnis 102

Anhang 107

Tabellenverzeichnis

2.1. Sprachentheoretische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . 162.2. Verwendete Operationen aus DESTool . . . . . . . . . . . . . . . . . . . . 382.3. Verwendete Funktionen der SPNBOX . . . . . . . . . . . . . . . . . . . . . 38

3.1. SPS-Code eines einfachen Generators . . . . . . . . . . . . . . . . . . . . 40

4.1. Automaten - Auswahltabelle für Codegenerierungsansätze . . . . . . . . . . 534.2. Petrinetze - Auswahltabelle für Codgenerierungsansätze . . . . . . . . . . . 54

6.1. Datenbanktabelle Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2. Datenbanktabelle Generator - Initialzustände . . . . . . . . . . . . . . . . . 616.3. Datenbanktabelle Petrinetz . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.4. Datenbanktabelle Petrinetz - Initialstellen . . . . . . . . . . . . . . . . . . . 626.5. Datenbanktabelle Petrinetz - Ausgangszuweisung . . . . . . . . . . . . . . . 626.6. Eingangsprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.7. Eingangskategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.8. Codegenerator Automaten - Programmfunktionen . . . . . . . . . . . . . . . 696.9. Tabelle im Reiter Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . 786.10.Codegenerator Petrinetze - Programmfunktionen . . . . . . . . . . . . . . . 796.11.Ein- und Ausgänge des Tanksystems . . . . . . . . . . . . . . . . . . . . . 81

7.1. Komponenten der Fertigungszelle . . . . . . . . . . . . . . . . . . . . . . . 857.2. Puffergrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.3. Hardware der Fertigungszelle . . . . . . . . . . . . . . . . . . . . . . . . . 887.4. Generatoren der Strecke . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.5. Spezifikationen und lokale Systeme . . . . . . . . . . . . . . . . . . . . . . 917.6. Petrinetze der Streckenkomponenten . . . . . . . . . . . . . . . . . . . . . 917.7. Spezifikationen in Form von Ungleichungen . . . . . . . . . . . . . . . . . . 92

8.1. Vergleich: Anzahl der Modellzustände . . . . . . . . . . . . . . . . . . . . . 978.2. Vergleich: Speicherplatz der Ansätze . . . . . . . . . . . . . . . . . . . . . 988.3. Bewertung verschiedener Kriterien bezüglich der Entwurfsansätze . . . . . . 98

Abbildungsverzeichnis

1.1. Fertigungszelle im Labor c©Andreas Ißleib . . . . . . . . . . . . . . . . . . 13

2.1. Beispielgenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2. Beispielpetrinetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3. Basisstrukturen in Petrinetzen . . . . . . . . . . . . . . . . . . . . . . . . . 232.4. Steuerkreis S/G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5. Konzept der Steuerbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.6. Steuerkreise verschiedener Entwurfsansätze . . . . . . . . . . . . . . . . . 312.7. Venn-Diagramm der Ereignisalphabete . . . . . . . . . . . . . . . . . . . . 33

3.1. Ein Generator und der zugehörige Kontaktplan . . . . . . . . . . . . . . . . 393.2. Beispiel: ein Automat mit Ausgang als Selfloop . . . . . . . . . . . . . . . . 453.3. DECON9 - Flussdiagramm des Hauptprogramms . . . . . . . . . . . . . . . 463.4. Beispiel: Fragmentales SIPN mit Programmcode in SCL . . . . . . . . . . . 51

5.1. Flussdiagramm - Aufbau der MATLAB-Datei . . . . . . . . . . . . . . . . . . 56

6.1. Aufbau von ACArrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.2. Aufteilung der Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . 596.3. Generator mit zeitabhängigem Ausgang . . . . . . . . . . . . . . . . . . . . 666.4. Screenshot von ACArrow, Hauptmenü Automaten . . . . . . . . . . . . . . . 676.5. Flussdiagramm der Funktion findChoice() . . . . . . . . . . . . . . . . . . . 696.6. Fertigungsline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.7. Generatoren der Maschinen . . . . . . . . . . . . . . . . . . . . . . . . . . 716.8. Spezifikationen der Puffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.9. Reduzierte lokal-modulare Supervisor . . . . . . . . . . . . . . . . . . . . . 726.10.Screenshot von ACArrow, Hauptmenü Petrinetze . . . . . . . . . . . . . . . 776.11.SIPN - Flussdiagramm des Hauptprogramms . . . . . . . . . . . . . . . . . 796.12.Tanksystem und Petrinetz . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.1. Fertigungszelle von oben . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.2. Handling Unit und Roboter . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.3. Generator G5 und Spezifikation K3_2 . . . . . . . . . . . . . . . . . . . . . 897.4. Generator G9 und ein Fragment der Spezifikation K7_1 . . . . . . . . . . . 89


7.5. Implementierungsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 937.6. Screenshot der WinCC Visualisierung . . . . . . . . . . . . . . . . . . . . . 96

Abkürzungsverzeichnis

δ . . . . . . . . . . . . . . . . ZustandsübergangsfunktionA . . . . . . . . . . . . . . . AdjazenzmatrixL . . . . . . . . . . . . . . . . GewichtungsmatrixΩ . . . . . . . . . . . . . . . Ausgabefunktionω . . . . . . . . . . . . . . . Zuordnung der Ausgänges . . . . . . . . . . . . . . . . Präfix eines Stringsφ . . . . . . . . . . . . . . . . Zuordnung der SchaltbedingungenΣ . . . . . . . . . . . . . . . Ereignisalphabet/Endliche Menge von Symbolenσ . . . . . . . . . . . . . . . . EreignisΣ∗ . . . . . . . . . . . . . . Kleene-HülleΣce . . . . . . . . . . . . . . Menge der gemeinsamen EreignisseΣc . . . . . . . . . . . . . . . Menge der steuerbaren EreignisseΣpe . . . . . . . . . . . . . Menge der privaten EreignisseΣuc . . . . . . . . . . . . . Menge der nicht steuerbaren Ereignisse× . . . . . . . . . . . . . . . SPC / Produkt zweier Generatorenε . . . . . . . . . . . . . . . . Leerer String|| . . . . . . . . . . . . . . . . SYPC / Parallele Komposition zweier Generatoren#»µ . . . . . . . . . . . . . . . Markierungsvektor eines Petrinetzes#»

b . . . . . . . . . . . . . . . Konstantenvektor# »

p(k) . . . . . . . . . . . . Markierungsvektor eines Petrinetzes zum Zeitpunkt k#»s . . . . . . . . . . . . . . . S-Invariante#»t . . . . . . . . . . . . . . . T-InvarianteA . . . . . . . . . . . . . . . Menge von AusgängeAc(G) . . . . . . . . . . Erreichbarere Teil des Generators Gcat(s, t) . . . . . . . . . Konkatenation der Strings s und tCoAc(G) . . . . . . . Ko-erreichbarere Teil des Generators GE . . . . . . . . . . . . . . . . Menge von EingängeG . . . . . . . . . . . . . . . Generator/StreckeK . . . . . . . . . . . . . . . Formale SpezifikationK↓C . . . . . . . . . . . . . Infimale präfix-geschlossene steuerbare OberspracheK↑C . . . . . . . . . . . . . Supremale steuerbare TeilsprachL . . . . . . . . . . . . . . . . Formale Sprache


L(G) . . . . . . . . . . . . reguläre Sprache von GLm(G) . . . . . . . . . . markierende reguläre Sprache von GN . . . . . . . . . . . . . . . NetzmatrixN−, N+ . . . . . . . . Flussrelationen der Prä- und PostkantenP . . . . . . . . . . . . . . . . Menge der Stellenp . . . . . . . . . . . . . . . . Stelle/PlatzP0 . . . . . . . . . . . . . . . InitialmarkierungsvektorPN . . . . . . . . . . . . . Autonomes PetrinetzR . . . . . . . . . . . . . . . AkzeptorS . . . . . . . . . . . . . . . . Supervisor/Steuerungs . . . . . . . . . . . . . . . . StringS(s) . . . . . . . . . . . . . SteuereingriffS/G . . . . . . . . . . . . Gesteuertes SystemT . . . . . . . . . . . . . . . . Menge der Transitionent . . . . . . . . . . . . . . . . Transitiont• . . . . . . . . . . . . . . . Menge der PoststellenTakt(p(k)) . . . . . . Menge der zum Zeitpunkt k aktivierten TransitionenTrim(G) . . . . . . . . Erreichbarer und ko-erreichbarer Teil des Generators GX . . . . . . . . . . . . . . . Zustandsmengex . . . . . . . . . . . . . . . . Zustandx0 . . . . . . . . . . . . . . . AnfangszustandXm . . . . . . . . . . . . . . Menge der markierten Zustände•t . . . . . . . . . . . . . . . Menge der PrästellenA . . . . . . . . . . . . . . . . Ausgang der SPSAS . . . . . . . . . . . . . . AblaufspracheAWL . . . . . . . . . . . . AnweisungslisteDES . . . . . . . . . . . . . Discrete Event SystemE . . . . . . . . . . . . . . . . Eingang der SPSFBS . . . . . . . . . . . . . FunktionsbausteinspracheFUP . . . . . . . . . . . . . FunktionsplanKOP . . . . . . . . . . . . . KontaktplanPS . . . . . . . . . . . . . . ProduktsystemRFID . . . . . . . . . . . . Radio-frequency identificationSCL . . . . . . . . . . . . . Structured Control LanguageSCT . . . . . . . . . . . . . Supervisory Control TheorySIPN . . . . . . . . . . . . Steuerungstechnisch interpretierte PetrinetzeSPC . . . . . . . . . . . . . Strict Product CompositionST . . . . . . . . . . . . . . Strukturierter TextSTR . . . . . . . . . . . . . Steuerbares Ereignis in der SPSSYPC . . . . . . . . . . . Synchronous Product

1. Einführung

1.1. Einführung und Motivation

Die Steuerungstechnik stellt einen Bereich der Automatisierungstechnik dar. Die Worther-kunft entstammt dem Verb steuern, ein gehobenes Wort für entgegenwirken [7]. Technischgesehen wird ein Prozess oder eine Anlage durch eine Steuerung beeinflusst, sodass sichein gewünschtes Verhalten einstellt. Eine Steuerung kann durch unterschiedliche Methodenerstellt werden. Die von Ramadge und Wonham [41, 60] eingeführte Methode heißt Super-visory Control Theory und wird häufig abgekürzt durch SCT. Ziel der Methode ist es, eineSteuerung durch eine Synthese und durch Möglichkeiten der Analyse zu erstellen. Das un-terscheidet die SCT von vielen Steuerungen, die nur über das Testen einer Anlage empirischverifiziert werden können.

Die automatische Codegenerierung ist ein wichtiges Thema, um die SCT für den prakti-schen Gebrauch weiterzuentwickeln. Das Ergebnis der SCT sind Modelle. Diese Modellemüssen umgewandelt werden, sodass sie von einer Hardware interpretiert werden können.Für eine Speicherprogrammierbare Steuerung (SPS) werden die Modelle in Programmcodeübersetzt. Es stehen jedoch erst wenige in Software umgesetzte Codegeneratoren zur An-wendung bereit. An dieser Stelle soll diese Masterthesis ansetzen, um neue Erkenntnissebezüglich der Entwicklung und Umsetzung eines Codegenerators und der Erprobung desgenerierten Codes an einer Anlage zu gewinnen.

Zur Vermittlung des Inhalts wurde die Arbeit folgendermaßen strukturiert: Im zweiten Kapitelwerden Grundlagen für die SCT und anderen Aspekten der Arbeit erläutert. Das dritte Kapitelbeschreibt die automatische Codegenerierung, es werden vor allem verschiedene Ansätzefür eine Codeumsetzung besprochen. Die Konzeptionen für die entstehenden Entwicklun-gen werden in Kapitel 4 erläutert. Eine erste Entwicklung beschreibt das fünfte Kapitel, eszeigt die Softwareerweiterung für den Entwurfsansatz mit Petrinetzen. Im sechsten Kapitelwird die Hauptentwicklungsarbeit, der Codegenerator, vorgestellt. Anhand von Beispielenwird die Funktionsweise verdeutlicht. Getestet wird der generierte Code an einer Fertigungs-zelle, dies beschreibt das Kapitel 7. Ein Vergleich der Ergebnisse von den unterschiedli-chen Modellierungs- und Codegenerierungsansätzen wird in Kapitel 8 vorgenommen. ZumSchluss wird die Arbeit in Kapitel 9 zusammengefasst und es wird ein Ausblick gegeben.

1. Einführung 13

1.2. Aufgabenstellung

Aufgabe dieser Arbeit ist die Analyse von Ansätzen der automatischen Codegenerierung fürverschiedene Entwurfsansätze der Supervisory Control Theory. Bei der Analyse werden Ent-würfe für Automaten und Petrinetze unterschieden. Aus den erarbeiteten Ergebnissen soll einCodegenerator entwickelt werden. Es müssen folglich Entwurfsverfahren, Codgenerierungs-ansätze und Entwicklungstools ausgewählt werden. Der generierte Code soll wiederum aneiner Fertigungszelle getestet und verifiziert werden. Die Fertigungszelle wird mit einer SPSder Firma Siemens gesteuert und stellt einen Stückgutprozess dar, der Werkstücke nachFarben und Qualität sortiert (siehe Abbildung 1.1).

Abbildung 1.1.: Fertigungszelle zur Realisierung eines Stückgutprozesses

Ausgangspunkt dieser Arbeit ist die Masterthesis von Urland [53], in der bereits die Modellefür die Fertigungszelle entwickelt wurden und eine Steuerung nach dem modularen Ent-wurfsansatz realisiert wurde. Die Modellierung der Anlage ist somit nicht Teil dieser Arbeit.Durch die Umstellung der Anlage auf eine neuere SPS und dem Wechsel von der Program-miersoftware Siemens STEP 7 auf das Siemens TIA Portal besteht jedoch die Anforderung

1. Einführung 14

der Adaption der Ergebnisse von Urland an das neue System. Zusammengefasst bestehenzu Beginn nur wenige konkrete Anforderungen an diese Arbeit, da detaillierte Anforderungenerst aus den gewonnenen Ergebnissen extrahiert werden.

1.3. Zielsetzung

Ziel dieser Arbeit ist es, einen Literaturüberblick über die verschiedenen Ansätze zur automa-tischen Codegenerierung zu geben. Aus diesen Ansätzen werden die besten in Abhängig-keit von der Beschreibungsform, dem Entwurfsverfahren und anderen Kriterien ausgewähltund umgesetzt. Es soll gezeigt werden, dass mit einem gut strukturierten und benutzer-freundlichen Codegenerator ein kompletter Steuerungsentwurf auch für ganz verschiedeneEntwurfsmodelle möglich ist. Ein weiteres Ziel ist, dass die Fertigungszelle mit den neu ent-wickelten Codegenerierungen ihren Arbeitsauftrag vollständig erfüllt. Die Vor- und Nachteileder umgesetzten Entwürfe und Codegenerierungen sind einem abschließenden Vergleich zuentnehmen.

2. Grundlagen

2.1. Systemtheoretische Grundlagen

In diesem Kapitel werden die Grundlagen zur Supervisory Control Theory beschrieben. DieSystemtheorie der beschreibenden ereignisdiskreten Systeme wird vorgestellt, um anschlie-ßend die SCT und verschiedene Steuerungsentwurfsansätze zu erläutern.

2.1.1. Ereignisdiskrete Systeme

„Reale Systeme im Allgemeinen werden als komplexe Anordnungen in sämtlichen Bereichender Natur und der vom Menschen geschaffenen Welt verstanden“ [56]. Ein dynamisches Sys-tem wird durch Struktur, Verhalten und Funktion definiert. Systeme können sehr unterschied-lich sein und werden folglich in Klassifizierungen eingeteilt. Die in dieser Arbeit betrachtetenSysteme sind ereignisdiskret, abgekürzt mit DES (engl. discrete event system/s). Ein DESwird nach [56] wie folgt definiert:

Definition 2.1 (Ereignisdiskretes System). Ein ereignisdiskretes System ist ein dyna-misches System mit einem diskreten Zustandsraum X, dessen Zustände sich spontandurch das asynchrone Auftreten von Ereignissen über die Zeit ändern. Ein Ereignis isteine Erscheinung oder eine Aktion ohne zeitliche Dauer.

Auch wenn viele Systeme nicht von Natur aus ereignisdiskret sind, kann ein System häufigdurch Abstraktion als DES betrachtet werden. So sind beispielsweise oft nur Endpositionenvon Interesse und werden als abstrahiertes Ereignis von kontinuierlichen Bewegungen inter-pretiert.

Ereignisdiskrete Systeme können nach [27] mit logischen, zeitbewerteten, stochastischenund zeitbewerteten stochastischen Modellen dargestellt werden. Es werden hier nur logischeModelle betrachtet. Diese Modelle beschränken sich darauf, zu zeigen, was mit dem Systempassiert und in welcher Reihenfolge. Formal wird die Trajektorie des logisch betrachtetenDES durch die nicht zeitbewertete Folge von Tupel der Form

(x0, σ1), (x1, σ2), (x2, σ3), (x3, σ4), ... (2.1)

2. Grundlagen 16

beschrieben, mit dem Anfangszustand x0 ∈ X, den Zuständen xi ∈ X und den Ereignissenσi ∈ Σ für i>0 [56]. Die Menge X ist die Menge aller möglichen Zustände und Σ die Mengealler möglichen Ereignisse. Das DES ist deterministisch, wenn durch eine beliebige Ereig-nisfolge aus Σ und einem Anfangszustand der Zustand des DES eindeutig bestimmt werdenkann.

2.1.2. Beschreibungsformen für ereignisdiskrete Systeme

Für die Modellbildung logischer DES stehen verschiedene Beschreibungsformen zur Verfü-gung. In diesem Kapitel werden reguläre Sprachen, Automaten und Petrinetze vorgestellt.

Grundlagen zu regulären Sprachen

Die regulären Sprachen sind Teil der formalen Sprachen. Alle Begriffe und Definitionen zuformalen Sprachen sind aus [6] und [58] entnommen. Zunächst werden Sprachentheoreti-sche Grundlagen eingeführt, die zur Beschreibung für formale Sprachen benötigt werden.

Begriff Beschreibung oder Definition

Alphabet Σ endliche nichtleere Menge von paarweise verschiedenen Sym-bolen

Symbol σ Zeichen, kann zum Beispiel ein Ereignis darstellenString s Sequenzen von Symbolen σ1σ2σ3σ4...σk für k ≥ 1 (Konkatena-

tion von Symbolen σi ∈ Σ)leerer String ε ε /∈ Σ, ε 6= ∅Menge Σ+ die Menge aller endlichen Sequenzen von Strings aus Σ mit

Ausnahme von ε

Kleene-Hülle Σ∗ Kleene-Hülle von Σ: Σ∗ = ε ∪ Σ+

Konkatenation cat cat : Σ∗ × Σ∗ → Σ∗ ist definiert alscat(ε, s) = cat(s, ε) = s, s ∈ Σ∗

cat(s, t) = st, s,t ∈ Σ+

Länge eines Strings |s| definiert als |ε| = 0, |s| = k für s = σ1...σk ∈ Σ+

Präfix eines Strings s Präfix von s ist s = t, wenn s = tσ mit t ∈ Σ∗, σ ∈ Σ

Suffix eines Strings Suffix von s ist v ab σ, wenn s = uσv mit u, v ∈ Σ∗, σ ∈ Σ

Substring eines Strings Substring von s ist t, wenn s = utv mit u,t,v ∈ Σ∗

Tabelle 2.1.: Sprachentheoretische Grundlagen

2. Grundlagen 17

Mit den Grundlagen aus Tabelle 2.1 können nun formale Sprachen und ihre Eigenschaft derRegularität folgendermaßen definiert werden [56]:

Definition 2.2 (Formale Sprache). Eine formale Sprache L über einem Alphabet Σ isteine beliebige Teilmenge L ⊆ Σ∗. Wird eine formale Sprache von einem endlichen Auto-maten erkannt, ist sie regulär.

Die Definition deutet bereits an, dass reguläre Sprachen im Zusammenhang mit Automatenverwendet werden können. Die regulären Sprachen und die Automaten sind äquivalenteDarstellungsweisen. Auf reguläre Sprachen können viele Operationen angewandt werdenund sie eignen sich daher gut um Beweise durchzuführen.

Da Sprachen Mengen sind, können die gebräuchlichen Operationen Vereinigung, Schnitt,Differenz, Komplement und Symmetrische Differenz aus der Mengenlehre, wie in [29] be-schrieben, verwendet werden. Weiter Operationen sind:

• Konkatenation: enthält nur zusammengesetzte Strings aus L1 und L2,L1,L2 ⊆ Σ∗, L1L2 = s ∈ Σ∗|(s = s1s2) ∧ (s1 ∈ L1) ∧ (s2 ∈ L2)

• Präfix-Hülle: enthält alle Strings aus L und alle ihre Präfixe,L ⊆ Σ∗, L = s ∈ Σ∗|∃t ∈ Σ∗(st ∈ L)- gilt L = L, ist die Sprache präfix-geschlossen

• Kleene-Hülle: enthält ε und eine endliche Anzahl Konkatenationen von Strings aus LL ⊆ Σ∗, L∗ = ε ∪ L ∪ LL ∪ LLL ∪ ...

Die regulären Sprachen sind abgeschlossen unter Vereinigung, Schnitt, Komplement, Kon-kationation, Bildung der Präfix- und Kleene-Hülle. Die genaue Beschreibung für DES mitregulären Sprachen folgt im nächsten Abschnitt über Automaten.

Automaten

Die hier betrachtete Automatenklasse ist die der deterministischen endlichen Automaten(DFA, engl. deterministic finite automaton) oder auch Standardautomaten [27]. Ein DESkann grafisch dargestellt werden durch Zustände und Zustandsübergänge. Die Tupelfolgeaus Gleichung (2.1) erhält eine Struktur. In der SCT werden diese Automaten als Genera-toren bezeichnet. Dieser Begriff wurde von Ramadge und Wonham [60, 59] eingeführt. Erunterscheidet sich in der Art und Weise wie Zustandsübergänge erzeugt werden. Ein Ge-nerator generiert spontan Ereignisse, die zu den Zustandsübergängen führen können. DerDFA in seiner ursprünglichen Definition ist jedoch passiv und erkennt nur die Zustandsüber-gänge. In der Informatik wird mit einem DFA zum Beispiel eine bestimmte Sprache erkannt.Die Definition ist jedoch in beiden Fällen ein Quintupel und lautet in diesem Fall für einenGenerator [58]:

2. Grundlagen 18

Definition 2.3 (Generator). Ein Generator G ist ein Quintupel

G = (X, Σ, δ, x0, Xm) (2.2)

mit endlicher Zustandsmenge X, endlichem Ereignisalphabet Σ, Zustandsübergangs-funktion δ : X × Σ → X, Anfangszustand x0 ⊆ X und der Menge der markiertenZustände Xm ⊆ X.

Die totale Zustandsübergangsfunktion ∀(x, σ) ∈ (X × Σ), δ(x, σ)! gilt bei einem Genera-tor nicht. Das Ausrufezeichen steht hier für Existenz des Übergangs, ¬δ(x, σ)! wäre nichtexistent. Der Generator unterscheidet sich also vom DFA darin, dass seine Zustandsüber-gangsfunktion nicht total sein muss, sondern üblicherweise partiell ist [56]. Für den DFAwird meist ein Dump-State eingeführt um eine totale Funktion zu erreichen, der alle nichtzur Sprache gehörenden Übergänge abfängt. Ein Dump-State existiert bei einem Generatornicht, da dieser ein reales technisches System beschreibt. Nicht in jedem Zustand können al-le möglichen Ereignisse des Systems einen Zustandsübergang definieren. Außerdem ist dieAnnahme der spontan generierten Ereignisse nur im Kontext der Modellierung zu betrach-ten. Ist ein Zustandsübergang jedoch definiert δ(x, σ)!, so ist der Folgezustand x′ eindeutigbestimmt:

x′ = δ(x, σ), x′ ∈ X. (2.3)

Somit ist der hier eingeführte Generator deterministisch, wie in dem Begriff DFA bereits in-diziert wird. Das Quintupel beschreibt außerdem eine Zustandsmenge Xm mit markiertenZuständen. Der Anwender kann wichtige Zustände, die einem Ziel der Anwendung entspre-chen, markieren. Wie die grafische Umsetzung erfolgt, zeigt Abbildung 2.1 anhand einesexemplarischen Generators. Ein Zustand wird mit einem Kreis dargestellt. Zeigt ein Pfeil auf

0

1 2

a

b

c

dc

Abbildung 2.1.: Generator mit X=0,1,2, Σ=a,b,c,d, x0=0 und Xm=0

den Kreis, ist dies der Anfangszustand. In dem Beispiel ist es der Zustand 0. Der doppelteRing in diesem Zustand zeigt an, dass dies ein markierter Zustand aus der Menge Xm ist.In diesem Generator ist nur ein Zustand markiert. Die Verbindungspfeile zeigen die Zustand-übergangsfunktion an. Das auslösende Ereignis betitelt den Pfeil. Mit der Übergangsfunktion

2. Grundlagen 19

1 = δ(0, a) wird beschrieben, dass von Zustand 0 ein Wechsel mit dem Ereignis a auf denZustand 1 erfolgt. Eine Schlinge, die zum selben Zustand zurückführt, wird als Selfloop be-zeichnet. Dies ist beim Zustandsübergang 2 = δ(2, c) zutreffend.

Die Darstellungsweise des DFA als Adjazenzmatrix A zeigt alle Übergänge an. Die Matrixhat N × N Elemente, wobei N die Anzahl der Zustände ist. Ein Element aij ist dann gleichdem Ereignis σ, wenn δ für den Übergang von j nach i definiert ist. Wird für eine existierendeKante eine Eins statt dem Ereignis verwendet, können mit der Matrix nach [27] folgendemathematische Analysen durchgeführt werden: Erreichbarkeit von Zuständen, Existenz vonZyklen und einen Erreichbarkeitsbaum erstellen.

Die Adjazenzmatrix A kann den Generator aus Abbildung 2.1 wie folgt darstellen:

A =

0 b da 0 00 c c

. (2.4)

Eine äquivalente Darstellung zum Generator sind die bereits eingeführten regulären Spra-chen. Alle vom Generator aus dem Anfangszustand x0 generierbaren Strings bilden dieSprache L(G) ⊆ Σ∗ des DES. Das ungesteuerte Verhalten L(G) wird nach [6] definiertals:

L(G) = s ∈ Σ∗| δ(x0, s)!. (2.5)

L(G) ist immer präfix-geschlossen L(G) = L(G), da ein Pfad oder String nur existierenkann, wenn auch seine Präfixe existieren. Das markierende Verhalten Lm(G) enthält alleStrings ausgehend vom Anfangszustand, die einen markierenden Zustand erreichen. Somitist Lm(G) ⊆ L(G) und wird nach [6] folgendermaßen definiert:

Lm(G) = s ∈ L(G)| δ(x0, s) ∈ Xm. (2.6)

Ist X = Xm, so ist Lm(G) = L(G) und ist ebenfalls präfix-geschlossen. Für einen gegebe-nen Generator werden L(G) und Lm(G) nicht explizit mit Werten aufgefüllt, sondern dieseSprachen werden aufgrund ihrer prägnanten Beschreibung des Systemverhaltens verwen-det.

Die Komposition ist eine wichtige Operation auf Automaten. Ein technisches Modell für einekomplexe Anlage in nur einem Generator aufzustellen, wäre eine herausfordernde Aufgabe.Ein System besteht aus verschiedenen Systemkomponenten, die einzeln modelliert wer-den können. Wie die Komponenten anschließend zusammengesetzt werden, hängt von ihrerKopplung ab. Zwei Basiskompositionen werden vorgestellt, die für den späteren Steuerungs-entwurf benötigt werden. Die Definitionen zu verschiedenen Kompositionen zeigen Wenckund Richter [57]. Für die Definition werden zunächst die Alphabete zweier Generatoren Σ1

2. Grundlagen 20

und Σ2 betrachtet. Diese können in gemeinsame Ereignisse (ce, engl. common events)

Σce = Σ1 ∩ Σ2 (2.7)

und in private Ereignisse (pe, engl. private events)

Σpe = (Σ2 − Σ1) ∪ (Σ1 − Σ2) (2.8)

aufgeteilt werden. Die strenge Synchronisation (SPC, engl. Strict Product Composition) oderProduktkomposition lässt zwei Generatoren nur im totalen Gleichschritt schalten und verbin-det diese zu einem neuen Generator [56]. Der Operator wird für Rückkopplungsstrukturenverwendet, wie die Zusammenschaltung von Strecke und Steuerung.

Definition 2.4 (Produkt (SPC)). Das Produkt zweier Generatoren G1 und G2 ist mit x1 ∈X1, x2 ∈ X2 und σ ∈ Σce definiert als

G = G1 × G2 = (X1 × X2, Σce, δ, (x01, x02), Xm1 × Xm2) mit (2.9)

δ((x1, x2), σ) =

δ1(x1, σ)× δ2(x2, σ) falls δ1(x1, σ)! ∧ δ2(x2, σ)!nicht definiert sonst.

(2.10)

Also werden nur gemeinsame Ereignisse zugelassen, sofern diese in δ1 und δ2 für denjeweiligen Zustandsübergang definiert sind. Private Ereignisse sind immer ausgeschlossen.Die reguläre Sprache des entstandenen Generators ist

L(G) = L(G1 × G2) = L(G1) ∩ L(G2). (2.11)

Nur die gemeinsamen Strings bleiben in der Schnittmenge erhalten. Dies gilt auch fürLm(G).

Das synchrone Produkt (SYPC, engl. Synchronous Product Composition) oder die Paralle-le Komposition beschreibt die Kopplung zweier Generatoren im partiellen Gleichschritt undverbindet diese zu einem neuen Generator [56]. Der Operator wird zum Beispiel bei Res-sourcenzuteilung verwendet.

Definition 2.5 (Parallele Komposition (SYPC)). Die Parallele Komposition zweier Ge-neratoren G1 und G2 ist mit x1 ∈ X1, x2 ∈ X2 und σ ∈ Σ definiert als

G = G1||G2 = (X1 × X2, Σ, δ, (x01, x02), Xm1 × Xm2) mit (2.12)

2. Grundlagen 21

δ((x1, x2), σ) =

δ1(x1, σ)× δ2(x2, σ) falls δ1(x1, σ)! ∧ δ2(x2, σ)!δ1(x1, σ)× x2 falls δ1(x1, σ)! ∧ ¬δ2(x2, σ)! ∧ σ /∈ Σce

x1,×δ2(x2, σ) falls ¬δ1(x1, σ)! ∧ δ2(x2, σ)! ∧ σ /∈ Σce

nicht definiert sonst.(2.13)

Die Komposition ist bezüglich der gemeinsamen Ereignisse mit der SPC identisch. Priva-te Ereignisse werden in diesem Fall jedoch nicht mehr ausgeblendet, sondern sind immermöglich, wenn δ im jeweiligen Generator definiert ist.

Sind die Ereignisalphabete Σ1 und Σ2 der Generatoren gleich, geht SYPC in SPC überund der Spezialfall wird nach [58] mit „Meet" bezeichnet. Haben die Ereignisalphabete Σ1und Σ2 keine gemeinsamen Ereignisse, bleiben die Generatoren vollkommen unabhängigvoneinander. Dieser Spezialfall wird nach [58] „ Shuffle" genannt . Die reguläre Sprache desunter Paralleler Komposition entstandenen Generators ist

L(G) = L(G1||G2) = P−1Σ1

(L(G1)) ∩ P−1Σ1

(L(G2)). (2.14)

Die hier verwendete Funktion P−1 ist die inverse natürliche Projektion. Durch die Funktionsind die privaten Ereignisse im jeweils anderen Generator immer erlaubt. Für die Definitionder inversen natürlichen Projektion wird auf [6, 27] verwiesen.

Petrinetze

Die hier betrachteten Petrinetze haben keine Eingangsgrößen und werden daher autonomePetrinetze genannt [27]. Besonders parallele Prozesse können mit einem Petrinetz gut dar-gestellt werden. Außerdem sind parallele und sequentielle Teilprozesse gut zu unterschei-den. Das Petrinetz ist ein bipartiter Graf und besteht aus Stellen und Transitionen, die mitgerichteten Kanten verbunden sind.

Definition 2.6 (Autonomes Petrinetz). Das autonome Petrinetz PN ist ein Quintupel

PN = (P, T, N+, N−, P0) (2.15)

mit P der Menge der Stellen mit |P| = n, T der Menge der Transitionen mit |T| = m, denFlussrelationen N+ ∈ Zn×m und N− ∈ Zn×m und dem Initialmarkierungsvektor P0.

Die Matrix N+ zeigt die Flussrelationen der Postkanten an. Postkanten führen von einerTransition zu einer Stelle. Mit der Matrix N− wird dies für die Präkanten angezeigt, die voneiner Stelle zu einer Transition führen. Ein Element n+

ij der Matrix N+ ist Eins, wenn von

Transition j zu Stelle i eine Kante existiert, sonst Null. Ein Element n−kj der Matrix N− ist

2. Grundlagen 22

Eins, wenn von Stelle k zu Transition j eine Kante existiert, sonst Null. Die Netzmatrix N voneinem Petrinetz verbindet die Matrizen nach [30] in der Form:

N = N+ − N− ∈ Zn×m. (2.16)

Für eine Transition t ∈ T werden die Stellen, von denen eine gerichtete Kante zu t führtPrästellen (Symbol •t) genannt und die Stellen zu denen eine gerichtete Kante hinführt wer-den Poststellen (Symbol t•) genannt. Der aktuelle Netzzustand wird durch eine Markierungangezeigt, bei der Stellen mit einer Marke belegt werden. Der Zeilenvektor P0 gibt für je-des Element aus P die Anzahl der initialen Markierungen an. Im Gegensatz zu Automatenwerden bei diesen Petrinetzen keine Schlingen verwendet, es sind reine Petrinetze [27]. Die

p1

t2p2

t1

Abbildung 2.2.: Petrinetz mit P=p1, p2, T=t1, t2, N+ =

(0 11 0

)und N−=

(1 00 1

)und

P0 = (1 0)

Abbildung 2.2 zeigt ein einfaches Petrinetz mit zwei Stellen und zwei Transitionen. Nebender Struktur ist das Verhalten eines Petrinetzes zu definieren. Dabei werden die Markennach folgenden Regeln durch das Netz bewegt [27]:

Definition 2.7 (Schaltregel). Eine Transition t ist aktiviert, wenn1. alle Prästellen p ∈ •t markiert sind und2. alle Poststellen p ∈ t• nicht markiert sind.

Schaltet eine aktivierte Transition, dann werden den Prästellen die Marken entzogen unddie Poststellen werden markiert. Es können mehrere aktivierte Transitionen gleichzeitigschalten, sofern ihre Mengen von Prä- und Poststellen disjunkt sind.

Die Schaltregel besagt, dass die Anzahl der Marken nicht konstant sein muss. Sind mehrereTransitionen aktiviert, zeigt sich ein nichtdeterministisches Verhalten [27]. Die Transitionenkönnen zwar schalten, müssen es aber nicht. Neben der logischen Beschreibung kann dasVerhalten auch in algebraischer Form dargestellt werden. Mit

# »

p(0) = P0 (Initialmarkierung) (2.17)

2. Grundlagen 23

ergibt sich# »

p(k + 1) =# »

p(k) + N ·# »

t(k) ∀# »

t(k) ∈ Takt(p(k)). (2.18)

Der Markierungsvektor# »

p(k) ∈ Zn×1 zum aktuellen Zeitpunkt k enthält ein Element für alleStellen des Petrinetzes. Die zum Zeitpunkt k markierten Stellen sind gleich Eins, sonst Null.Die Menge der aktivierten Transitionen zum Zeitpunkt k ist Takt(p(k)). Der Schaltverktor# »

t(k) ∈ Zm×1 enthält für jede Transition ein Element, das gleich Eins ist, wenn die Tran-sitionen schalten, sonst Null. Begonnen wird bei k = 0 mit der Initialmarkierung, die beimModellieren vom Anwender sinnvoll festgelegt wird. Um ein System zu beschreiben wird alsonach [27] statt der Zustands- und Ereignisfolge, wie beim DFA, die Markierungs- und Tran-sitionsfolge betrachtet. Sprachentheoretisch beinhalten Petrinetze die regulären Sprachen,können jedoch über diese hinaus gehen und auch nicht regulär sein [30]. Petrinetze sindsomit grundsätzlich eine gleich mächtige oder mächtigere Beschreibungsform als der DFA.Die in dieser Arbeit betrachteten autonomen Petrinetze mit Stellenkapazität und Kantenge-wichtung gleich Eins sind jedoch immer regulär [27].

In Petrinetzen sind vier Basisstrukturen (Abbildung 2.3) zu finden: Aufspaltung, Auswahl,Synchronisation und Begegnung [27]. So kann zwischen parallelen und sequentiellen Pro-zesspfaden umgeschaltet werden.

Aufspaltung Auswahl

Synchronisation Begegnung

Abbildung 2.3.: Basisstrukturen in Petrinetzen

2. Grundlagen 24

2.1.3. Analyse ereignisdiskreter Systeme

Die Analyse eines DES hilft dabei, wichtige Eigenschaften des Systems zu erkennen. DieErreichbarkeitsanalyse ist sowohl für Automaten, also auch für Petrinetze durchführbar. Beiden Automaten wird untersucht, wie eine Blockierung festgestellt werden kann. Für Petri-netze werden Invarianten definiert, die nur von der Netzstruktur abhängig sind. Diese Eigen-schaft wird später für einen Steuerungsentwurf verwendet. In den folgenden Abschnitten wirdzuerst die Analyse für Automaten und anschließend die Analyse für Petrinetze betrachtet.

Automaten - Erreichbarkeitsanalyse

Ein effizientes Modell sollte frei von nicht erreichbaren Zuständen sein. Diese können durcheine fehlerhafte Modellierung auftreten oder bei einer Komposition entstehen. Ein Zustandx ist erreichbar (engl. accessible), wenn die Übergangsfunktion δ(x0, s) = x existiert. DieAc-Operation entfernt nicht erreichbare Zustände aus G und ist nach [6] wie folgt definiert:

Definition 2.8 (Ac-Operation). Die Ac-Operation wird auf einen Generator G angewandt

Ac(G) = (Xac, Σ, δac, x0, Xac,m) mit (2.19)

Xac = x ∈ X|(∃s ∈ Σ∗)δ(x0, s) = x, (2.20)

Xac,m = Xm ∩ Xac, (2.21)

δac = δ|Xac×Σ→Xac . (2.22)

Die Notation δac = δ|Xac×Σ→Xac ist hier die Restriktion auf die erreichbaren Zustände. EinGenerator G ist also erreichbar, wenn G = Ac(G) beziehungsweise X = Xac. Die Opera-tion hat keinen Einfluss auf L(G) und Lm(G).

Für den späteren Steuerungsentwurf ist eine zweite Erreichbarkeitsanalyse, die Ko-Erreichbarkeit, von Bedeutung. Hier wird betrachtet, ob von jedem Zustand aus der MengeX ein String zu einem markierten Zustand führt. Ein Zustand ist ko-erreichbar (engl. co-accessible), wenn ein String s ∈ Σ∗ existiert, sodass δ(x0, s) ∈ Xm. Die CoAc-Operationentfernt nicht co-erreichbare Zustände aus G und ist nach [6] wie folgt definiert:

Definition 2.9 (CoAc-Operation). Die CoAc-Operation wird auf einen Generator G an-gewandt

CoAc(G) = (Xcoac, Σ, δcoac, x0,coac, Xm) mit (2.23)

Xcoac = x ∈ X|(∃s ∈ Σ∗)δ(x, s) ∈ Xm, (2.24)

x0,coac =

x0 falls x0 ∈ Xcoac

nicht def. sonst, (2.25)

2. Grundlagen 25

δcoac = δ|Xcoac×Σ→Xc0ac . (2.26)

Die Notation δcoac = δ|Xcoac×Σ→Xcoac ist hier die Restriktion auf die co-erreichbaren Zu-stände. Ein Generator G ist also co-erreichbar, wenn G = CoAc(G) beziehungsweiseX = Xcoac. Außerdem hat die CoAc-Operation Einfluss auf die Sprache L(G), da auch er-reichbare Zustände eliminiert werden können. Lm(G) wird nicht verändert. Sprachentheo-retisch ergibt sich daraus folgende Bedingung für Co-Erreichbarkeit:

L(G) = Lm(G). (2.27)

Beide Operationen werden in der Trim-Operation zusammengefasst [6]:

Definition 2.10 (Trim-Operation). Die Trim-Operation wird auf einen Generator G ange-wandt

Trim(G) = CoAc[Ac(G)] = Ac[CoAc(G)]. (2.28)

Ein Generator G ist also erreichbar und co-erreichbar, wenn G = Trim(G) beziehungswei-se X = Xcoac = Xac.

Automaten - Blockierung

Die Überschrift Blockierung schließt die Situationen Deadlock und Livelock mit ein. Allgemeinwird darunter verstanden, dass markierte Zustände, die ein Ziel der Anwendung beschrei-ben, nicht erreicht werden können. Der Deadlock beschreibt die Situation, dass der Automateinen Zustand enthält, der durch keine Übergangsfunktion wieder verlassen werden kann.Somit ist x /∈ Xm und ¬δ(x, σ)!, ∀σ ∈ Σ und es gilt nach [56]

Lm(G) ⊂ L(G). (2.29)

Diese Inklusion gilt ebenfalls für einen Livelock, bei dem eine Zustandsmenge X ⊆ X mitx /∈ Xm, ∀x ∈ X erreicht wird, von der aus kein markierter Zustand mehr erreicht werdenkann. Der Automat schaltet nur innerhalb von X. Durch Vermeidung der echten Inklusion2.29 ergibt sich für einen Generator die Eigenschaft für nichtblockieren:

Definition 2.11 (Nichtblockierung von G). Ein Generator G ist nichtblockierend, wenn

Lm(G) = L(G). (2.30)

Entsprechend gilt für die Blockierung von Generator G: Lm(G) ⊂ L(G).

2. Grundlagen 26

Petrinetz - Erreichbarkeitsanalyse

Die Erreichbarkeitsanalyse erfolgt bei Petrinetzen mit dem Erreichbarkeitsgrafen. Die Zu-stände eines Erreichbarkeitsgrafen heißen Knoten und die Zustandsübergänge Kanten. DieErstellung erfolgt mittels eines Algorithmus aus [27] für ein Petrinetz mit der Anfangsmarkie-rung #»p0.

1. erster Zustand des Erreichbarkeitsgrafen entspricht der Anfangsmarkierung# »

p(0)

2. Bestimmung der Menge aller aktiven Transitionen Takt(p(k)) (Definition 2.7)

3. Bestimmung aller Nachfolgemarkierungen# »

p(k + 1) mit Gleichung (2.18)

4. Erweiterung des Erreichbarkeitsgrafen um neue Knoten mit den Nachfolgemarkierun-gen und neue Kanten, die entsprechend der geschalteten Transitionen benannt wer-den

5. Wiederholung ab Punkt 2 bis alle Transitionen, sofern ein Schalten möglich ist, abge-arbeitet wurden

Die Analyse erfolgt nach [27]:Enthält der Erreichbarkeitsgraf Blattknoten, existiert ein Deadlock im Petrinetz. Ein Blattkno-ten ist ein Knoten ohne abgehende Kante, entsprechend kann dieser Zustand nicht wiederverlassen werden. Sind keine Blattknoten vorhanden, heißt das Petrinetz schwach lebendig.Eine Transition heißt tot, wenn diese nicht im Erreichbarkeitsgrafen vorkommt, somit niemalsaktiviert ist und nicht schalten kann. Es kann auch von der Anfangsmarkierung abhängen,ob eine Transition tot ist. Ein Petrinetz ist lebendig, wenn auf jede Markierung mindestenseine Nachfolgemarkierung folgt. Das Netz kann sich immer weiter bewegen.

Ist der Erreichbarkeitsgraf endlich, wurde das Petrinetz in einen DFA umgewandelt. Hierweist das Petrinetz die gleiche Modellierungsmächtigkeit wie die regulären Sprachen undder DFA auf. Ist der Graf nicht endlich, ist folglich die Sprache des Petrinetzes nicht regulärund somit mächtiger [6].

Petrinetz - Invarianten

Die Invarianten sind strukturelle Eigenschaften von Petrinetzen und somit unabhängig vonder Anfangsmarkierung. Zwei Arten von Invarianten werden in diesem Abschnitt vorgestellt,die Transitionsinvarianten (T-Invarianten) und die Stelleninvarianten (S-Invarianten). Die De-finitionen sind aus [27] entnommen.

Die T-Invarianten sind die Mengen von Transitionen, deren Schalten eine bestimmte Mar-kierung

#»

p reproduzieren. So werden zyklische Prozesse aufgezeigt. Zur Vereinfachung wird

2. Grundlagen 27

angenommen, dass eine reproduzierbare Markierung#»

p zum Zeitpunkt k = 0, zum Zeitpunktk wieder auftritt.

# »

p(k) =# »

p(0) =#»

p , (2.31)

eingesetzt in Gleichung (2.18) ergibt:

#»

p =#»

p + N ·k−1

∑k=0

# »

t(k). (2.32)

Definition 2.12 (T-Invarianten). Die ganzzahligen elementaren Lösungen des folgendenlinearen Gleichungssystems ergeben die T-Invarianten eines Petrinetzes:

N · #»t =#»

0 (2.33)

Dabei entspricht Vektor#»t der Summe aus Gleichung (2.32). Die Existenz einer T-Invarianten

ist nur eine notwendige Bedingung, dass eine beliebige Anfangsmarkierung reproduzierbarist. Zusätzlich muss die Schaltregel überprüft werden. Ist eine T-Invariante vorhanden, ist dasPetrinetz lebendig. Die Matrix N hat die Dimension n×m und den Rang r. Daraus ergebensich m− r T-Invarianten. Die Lösungen der Gleichung (2.33) können mit dem GaußschenAlgorithmus bestimmt werden und es entstehen dabei (m − r) m-dimensionale Vektoren#»t .

Die S-Invarianten sind die Mengen von Stellen, deren gewichtete Markenzahl beim Schaltenfür alle

# »

t(k) konstant bleibt. Die Beschreibung erfolgt durch Zeilenvektor#»

s′ und es ergibt sichdie Bedingung:

#»

s′ ·# »

p(k + 1) =#»

s′ ·# »

p(k). (2.34)

Das heißt, die gewichtete Summe ∑ si · pi(k) bleibt über der Zeit k konstant. Eingesetzt inGleichung (2.18) ergibt dies:

0 = 0 +#»

s′ · N ·# »

t(k), ∀# »

t(k). (2.35)

Definition 2.13 (S-Invarianten). Die ganzzahligen, nichttrivialen und nichtnegativen Lö-sungen des folgenden linearen Gleichungssystems ergeben die S-Invarianten eines Pe-trinetzes.

#»

s′ · N =#»

0′ (2.36)

Sind alle Stellen Teil der Menge der S-Invarianten, so ist das Petrinetz lebendig. Die Matrix Nhat wieder die Dimension n×m und den Rang r. Daraus ergeben sich n− r S-Invarianten.Die Lösungen der Gleichung (2.36) können mit dem Gaußschen Algorithmus bestimmt wer-den und es entsteht dabei (n− r) n-dimensionale Vektoren #»s .

2. Grundlagen 28

2.1.4. Supervisory Control Theory

Die Supervisory Control Theory, die bereits in der Einleitung kurz genannt wurde, wird indiesem Kapitel näher definiert. Der Begriff SCT verbindet eine Ansammlung von Metho-den zur formalen Synthese von Steuerungen. Dabei werden hier nur Methoden für logischenichtzeitbewertete DES betrachtet. Ursprünglich wurde die SCT für Generatoren und regu-läre Sprachen definiert, ist aber nicht darauf begrenzt. Zum Beispiel können auch Petrinetzeals Beschreibungform verwendet werden, die Steuerungssynthese ist dabei das Bindegliedzur SCT. Die Methoden werden häufig nur in kleinen theoretischen Beispielen untersucht.[23], [56], [33] und [53] sind einige wenige Beispiele, in denen die SCT bei größeren realenAnlagen angewandt wurde. Für die Industrie ist das Konzept der mathematisch verifiziertenSteuerungen sicherlich interessant, es wird jedoch nur selten eingesetzt. Das liegt zum einenan dem hohen Rechenaufwand für große Industrieanlangen und zum anderen sind die Me-thoden und Beschreibungsformen noch unbekannt [56] oder es fehlen Erfahrungswerte.

Die folgenden Beschreibungen zur SCT beziehen sich auf Generatoren und reguläre Spra-chen. Der Gedanke bei der Synthese ist die Aufspaltung der Steuerungsaufgabe in einenbeschreibenden und einen spezifizierenden Teil. Der beschreibende Teil ist die Strecke Gmit dem ungesteuerten Verhalten des Systems. Dem gegenüber steht die Spezifikation Kals spezifizierender Teil. Aus beiden Beschreibungen entsteht durch Synthese die Steue-rung oder der Supervisor S. Das Ereignisalphabet des Systems kann in steuerbare (c, engl.controllable) und nicht steuerbare (uc, engl. uncontrollable) Ereignisse partitioniert werden[58].

Σ = Σc ∪ Σuc mit Σc ∩ Σuc = ∅ (2.37)

Die Steuerung greift auf die steuerbaren Ereignisse zu, um die Strecke zu kontrollieren. Mitden nicht steuerbaren Ereignissen wird der Streckenverlauf nachvollzogen. Die Steuerungüberwacht die generierte Ereignisfolge s der Strecke G und deaktiviert die unerwünsch-ten Folgeereignisse. Wie in Abbildung 2.4 dargestellt, werden nur die von S erlaubten Fol-geereignisse S(s) an die Strecke weitergegeben, nicht steuerbare Ereignisse müssen dabei

Abbildung 2.4.: Steuerkreis S/G

2. Grundlagen 29

immer erlaubt werden. In dieser Arbeit wird davon ausgegangen, dass alle Ereignisse beob-achtbar sind.

Der Steuerkreis S/G zeigt den monolithischen Entwurfsansatz, er besteht aus einem Modellfür die Strecke und einem Modell für den Supervisor. Das geschlossene Verhalten des Sys-tems L(S/G) ⊆ L(G) wird nach [58] mittels regulärer Sprachen rekursiv ausgedrückt.

1. ε ∈ L(S/G),

2. (s ∈ L(G/S) ∧ σ ∈ S(s) ∧ sσ ∈ L(G))⇒ sσ ∈ L(S/G),

3. keine anderen Strings gehören zu L(S/G)

Der leere String ε ist immer Teil von L(S/G), somit ist L(S/G) nichtleer nach der erstenBedingung. Die zweite Bedingung besagt, dass ein String nur dann durch ein Folgeereignisσ erweitert werden darf, wenn dieses in S erlaubt und in G möglich ist. Das markierendeVerhalten bilden die im Steuerkreis noch erlaubten Strings aus Lm(G):

Lm(S/G) = L(S/G) ∩ Lm(G). (2.38)

Nach Definition 2.11 ist das Nichtblockierende Verhalten von S bezüglich G definiert als:

Lm(S/G) = L(S/G) (2.39)

Neben dem Verhalten des Systems ist auch die Steuerbarkeit zu betrachten. Daher bestehtzunächst die Frage nach der Steuerbarkeit einer Spezifikation K bezüglich der Strecke G.Ist das System nicht steuerbar bezüglich K, kann auch keine Steuerung zur Erfüllung von Kexistieren. Die Steuerbarkeit nach [58] ist folgendermaßen definiert:

Definition 2.14 (Steuerbarkeit). Eine Spezifikation K ⊆ Σ∗ ist steuerbar bezüglich derStrecke G, wenn gilt:

KΣuc ∩ L(G) ⊆ K. (2.40)

Dies bedeutet, dass kein auftretendes nicht steuerbares Ergeignis zu einem Verlassen vonK führen darf und wird in Abbildung 2.5 verdeutlicht. Ist K nicht steuerbar, so wird eineSpezifikation gesucht, die eine möglichst geringe Abweichung zur ursprünglichen Spezifi-kation aufweist. Das ist die supremale steuerbare Teilsprache K↑C oder die infimale präfix-geschlossene steuerbare Obersprache K↓C. Definitionen und einen Algorithmus zu derenErstellung zeigt [56]. Die Erzeugung einer solchen Teilsprache erfolgt normalerweise mit derUnterstützung einer Software, wie zum Beispiel DESTool [31]. Ist eine steuerbare Spezifika-tion gefunden, muss festgestellt werden, ob diese auch nichtblockierend ist. Es existiert eine

2. Grundlagen 30

Abbildung 2.5.: Konzept der Steuerbarkeit mit σ ∈ Σuc

nichtblockierende Steuerung S bezüglich G, sodass gilt Lm(S/G) = K ∧ L(S/G) = K,genau dann wenn

K = K ∩ Lm(G). (2.41)

Diese Eigenschaft wird Lm(G)-Abgeschlossenheit genannt.

Verschiedene Standardprobleme werden in [6, 58] diskutiert und gelöst. Das für diese Arbeitrelevante Problem ist das BSCP-NP (engl. Basic Supervisory Control Problem-Nonblocking).Bei diesem Basisproblem handelt es sich um Systeme mit nicht steuerbaren, aber aus-schließlich beobachtbaren Ereignissen, für die eine nichtblockierende Steuerung gefundenwerden soll. Das Problem wird wie folgt definiert:

Definition 2.15 (BSCP-NP). Gegeben ist ein Generator G mit einem EreignisalphabetΣ mit Σuc ⊆ Σ und eine Lm(G)-abgeschlossene Spezifikation K ⊆ Lm(G). Bestimmeeine nichtblockierende Steuerung, sodass gilt:

1. Lm(S/G) ⊆ K

2. Lm(S/G) "maximal" ist, also für jede andere nichtblockierende Steuerung S′ mitLm(S′/G) ⊆ K gilt:

Lm(S′/G) ⊆ Lm(S/G) (2.42)

Die Lösung ist, eine Steuerung so zu wählen, dass

Lm(S/G) = K↑C. (2.43)

Die gefundene Steuerung kann als Liste S oder wie in dieser Arbeit als Akzeptor R, derdie Sprache K↑C markiert, realisiert werden. Der Akzeptor R = Y, Σ, ζ, y0, Ym wird sokonstruiert, dass Y = Ym, Σ gleich dem Ereignisalphabet der Strecke G, R = Trim(R)

2. Grundlagen 31

und ζ, sodass Lm(R) = L(R) := K↑C. Mit der strengen Synchronisation ergibt sich derSteuerkreis wie gewünscht zu:

L(G× R) = L(G) ∩ L(R) = L(G) ∩ K↑C = L(S/G) (2.44)

Lm(G× R) = Lm(G) ∩ Lm(R) = K↑C ∩ Lm(G) = L(S/G) ∩ Lm(G) = Lm(S/G)(2.45)

2.1.5. Strukturelle Steuerungsentwurfsansätze

Der im vorherigen Abschnitt vorgestellte Entwurfsansatz, der monolithische Entwurf, kannstrukturell erweitert werden durch Modularisierung und Hierarchisierung. Die Modellkomple-xität, die Steuerungsstruktur und die algorithmische Komplexität erfordern diese Maßnahmenfür komplexere Systeme. Die Hierarchisierung wie in [24, 23] wird nicht weiter betrachtet. Es

Abbildung 2.6.: Steuerkreise für den (a) modularen (b) lokal-modularen und (c) dezentalenEntwurfsansatz

werden drei modulare Ansätze für Automaten aus [56] kurz vorgestellt. Die Steuerkreise sindin Abbildung 2.6 für jeweils zwei Supervisor S1 und S2 dargestellt. Der modulare Entwurfs-ansatz (a) moduliert nur den Supervisor und der lokal-modulare Entwurfsansatz (b) teiltden Supervisor und die Strecke in mehrere Komponenten auf. Der dezentrale Entwurfsan-satz (c) moduliert, wie der modulare Enwurfsansatz, nur den Supervisor, braucht aber durchdie natürliche Projektion keine global verfügbaren Ereignisse. Die natürliche Projektion istdie Abbildung von einem ausgewählten Teil der Ereignisse und wird in [27] definiert. DieSupervisor können dadurch verteilt implementiert werden.

Für Petrinetze sind viele Ansätze nicht so umfassend aufgestellt wie bei Automaten. EinAnsatz arbeitet mit Erreichbarkeitsgrafen [55]. [11] zeigt Petrinetze im Kontext der SCT mit

2. Grundlagen 32

Strecke und Spezifikation wie bei den Automaten. Auch Cassandras und Lafortune zeigenin [6] wie Petrinetze als Strecke und Spezifikation verwendet werden können und welcheProbleme dabei auftreten. Sie stellen fest, dass diese Art von Synthese nicht gut geeignet ist,wenn die Sprache des Petrinetzes nicht regulär ist. Stattdessen wird der häufig angewandteAnsatz mit S-Invarianten vorgestellt.

Der lokal-modulare Entwurfsansatz und der Entwurfsansatz mit S-Invarianten werden in denfolgenden Abschnitten ausführlich vorgestellt, da diese Ansätze im Verlauf der Arbeit zurAnwendung kommen.

Lokal-modularer Entwurfsansatz

Der Ansatz wurde von Quieroz und Cury eingeführt und alle Definitionen, Begriffe und Zu-sammenhänge wurden aus [38, 39] entnommen. Der Vorteil des lokal-modularen Entwurfs-ansatzes ist, dass kein komplettes Gesamtmodell der Strecke benötigt wird. Für eine einzel-ne Spezifikation werden nur die Komponenten der Strecke zusammengefasst, die Teil derSpezifikation sind. Dieser Ansatz eignet sich besonders für Systeme, die viele nebenläufigeKomponenten enthalten.

Ein Kompositionssystem besteht aus n′ Komponenten G′i die mit der Parallelen Kompositionzusammengefasst werden. Daraus ergeben sich das Gesamtmodell G und das Ereignisal-phabet Σ. Sind alle Komponenten asynchron zueinander, wird das Kompostionssystem einProduktsystem (PS) genannt. Das feinste Produktsystem hat die größtmögliche Anzahl anasynchronen Komponenten. Werden aus einem Produktsystem Komponenten durch eineSpezifikation synchronisiert, entsteht ein lokales System. Es werden die Komponenten syn-chronisiert, die gemeinsame Ereignisse mit der Spezifikation besitzen.

Definition 2.16 (Lokale Systeme). Gegeben ist ein Produktsystem G mit n Kompo-nenten Gi und außerdem m Spezifikationen KXj definiert über ΣXj ⊆ Σ. Die lokalenSysteme GXj enthalten Komponenten Gi, die von den Spezifikationen KXj zwanghaftsynchronisiert werden und sind definiert als

GXj = ||i∈NXj Gi mit NXj = k ∈ 1, ..., n|Σk ∩ ΣXj 6= ∅. (2.46)

Wird eine Komponente im feinsten Produktsystem nicht durch eine Spezifikation einge-schränkt und somit keinem lokalen System GXj zugeordnet, hat diese Komponente keinenEinfluss auf das Gesamtsystem und kann daher weggelassen werden. Daraus ergibt sich

2. Grundlagen 33

das eingeschränkte System:

Ge = ||mj=1GXj und Σe = ||m⋃

j=1

ΣXj. (2.47)

Die Spezifikation kann nun folgendermaßen an die lokalen Systeme, das eingeschränkteSystem und das Gesamtsystem angepasst werden:

EXj = KXj||Lm(GXj) (2.48)

EXje = KXj||Lm(Ge) (2.49)

EX = KXj||Lm(G). (2.50)

In [38] wird die SYPC-Komposition auch für Sprachen definiert und auch die Spezifika-tion ist eine Sprache, daher die Verwendung in den Gleichungen. Nach [21] gilt auchEXj = KXj||GXj für Generatoren. Die markierende Sprache Lm deutet darauf hin, dassdie Generatoren vollständig erreichbar (G = Trim(G)) sein sollten. Das Beispiel aus [56]wird hier für das bessere Verständnis der Anpassung der Systembeschreibung und der Spe-zifikationen vorgestellt. Es sind ein Kompositionssystem mit fünf Komponenten G′i und Er-eignisalphabete Σ′i mit i = 1, ..., 5 und zwei Spezifikationen KX1 ⊂ Σ∗X1 und KX2 ⊂ Σ∗X2gegeben. Das Venn-Diagramm in Abbildung 2.7 zeigt die Relationen zwischen den Ereig-

Abbildung 2.7.: Venn-Diagramm der Ereignisalphabete

nisalphabeten an. Das feinste Produktsystem ist: G1 = G′1, G2 = G′2||G′3, G3 = G′4 undG4 = G′5.

Die lokalen Systeme setzen sich zusammen aus: GX1 = G1||G2 und GX2 = G3||G3. DieKomponente G4 kann keinem lokalen System zugeordnet werden und ist daher auch nichtTeil des eingeschränkten Systems Ge = GX1||GX2 = G1||G2||G3. Die Anpassung derSpezifikation erfolgt durch EX1 = KX1||GX1 und EX2 = KX2||GX2.

Mehrere Spezifikationen müssen außerdem lokal-modular sein. Die Eigenschaft muss gel-ten, damit sich die Spezifikationen nicht gegenseitig blockieren. Formal ist lokale Modularitätdefiniert als: I sei eine beliebige Indexmenge und Li ⊆ Σ∗i , i ∈ I, dann ist die Menge

2. Grundlagen 34

Li, i ∈ I lokal modular, wenn||i∈I Li = ||i∈I Li. (2.51)

Aus [38] gilt für einen Entwurf mit zwei lokalen Spezifikationen folgender Zusammenhang:

Definition 2.17 (lokal-modularer Entwurf für zwei Spezifikationen). Gegeben sei einKompositionssystem G mit n′ Komponenten G′i und zwei lokalen Spezifikationen KX1und KX2. Es sei supC(EX1, GX1) die supremale steuerbare Teilsprache von EX1 be-züglich GX1 und für supC(EX2, GX2) entsprechend. Sind diese supremalen steuerbarenTeilsprachen lokal-modular, dann gilt

supC(EX1e ∩ EX2e , Ge) = supC(EX1, GX1)||supC(EX2, GX2). (2.52)

Der Zusammenhang zeigt, dass es ausreichend ist Steuerungen mittels L(S1/GX1) =supC(EX1, GX1) und L(S2/GX2) = supC(EX2, GX2) zu berechnen, sofern diese lokal-modular sind. Die lokale Modularität kann explizit mit

supC(EX1, GX1)||supC(EX2, GX2) = supC(EX1, GX1)||supC(EX2, GX2) (2.53)

überprüft werden.

Im letzten Schritt werden die Supervisor mit einem Algorithmus nach [49] reduziert. Dabeiverlieren die Supervisor Informationen über die Strecke. Das Produktsystem muss daherzum Ausgleich mit in das Steuergerät implementiert werden. Supervisor und Strecke bildeneine verzahnte Einheit. Ein Beispiel wird in Kapitel 6.4.4 gezeigt.

Entwurfsansatz mit S-Invarianten

Dieser Entwurfsansatz unterscheidet sich von anderen Ansätzen durch die Beschreibungs-form der Spezifikation. Wichtige Entwickler des Ansatzes sind Moody, Antsaklis [30] und Ior-dache [17]. Die Spezifikation wird hierbei durch eine Ungleichung angegeben. Sollen zweiStellen pX und pY eines Petrinetzes G nicht gemeinsam markiert werden, lautet die Unglei-chung µGx + µGy ≤ 1. Wobei µGx , µGy die Markierungen der Stellen pX und pY darstellenund # »µG allgemein den Markierungsvektor von G angibt. Die Bezeichnung # »µG wird anstelle

von# »

p(k) eingeführt, da sich diese auf keinen bestimmten Zeitpunkt bezieht. Die anschlie-ßende Synthese basiert auf einer Lösung von algebraischen Gleichungen. Dem Petrinetzwerden dabei zusätzliche Stellen, die Steuerstellen (engl. control places), hinzugefügt. DasVerhalten wird der Spezifikation angepasst und die Steuerstellen nehmen Einfluss auf dasSchalten der Transitionen. Die Formale Lösung des Ansatzes erfolgt nach [30] durch diefolgenden Beschreibungen:

2. Grundlagen 35

Die Strecke ist ein Petrinetz G nach Definition 2.6 mit nG Stellen, mG Transitionen undder Netzmatrix NG. Das Ergebnis des Steuerungsentwurfes ergibt den Supervisor S be-ziehungsweise ein Petrinetz C mit nC Stellen, mC Transitionen und der Netzmatrix NC. DieSpezifikation ist eine Ungleichung in der Form:

L · # »µG ≤#»

b (2.54)

mit der Gewichtungsmatrix L ∈ ZnC×nG , dem Markierungsvektor # »µG ∈ ZnG von G, derKonstante

#»

b ∈ ZnG und nC der Anzahl der linearen Ungleichungen. Diese Anzahl entsprichtden neuen Steuerstellen, die Anzahl der Transitionen bleibt unverändert. In dieser Arbeitwerden autonome Petrinetze mit der Stellenkapazität gleich Eins betrachtet. Der Ansatz giltjedoch auch für Stellen-Transitionen-Netze mit einer Stellenkapazität größer gleich Eins [6,27]. Diese Petrinetze sind jedoch nicht regulär.

Die Ungleichung kann in ein Gleichungssystem umgeformt werden zu

L · # »µG + # »µC =#»

b . (2.55)

In der Gleichung stellt # »µC den Markierungsvektor der Steuerung dar. Die Netzmatrix des

gesteuerten Systems ist N =

[NGNC

]∈ Z(nG+nC)×mG . Diese wird unter Berücksichtigung

des Zusammhangs aus Gleichung (2.55) in die Gleichung (2.36) für S-Invarianten eingesetzt:

S′ · N = [L I] ·[

NGNC

]=

#»

0 (2.56)

mit der Einheitsmatrix I ∈ ZnC×mC . Die Gleichung kann umgeformt werden zuL · NG + NC =

#»

0 und sagt aus, dass die Markenanzahl für die gewichtete Netzmatrix NGplus eine zusätzliche Netzmatrix NC konstant bleibt. Daraus ergibt sich für die Steuerungs-synthese:

Definition 2.18 (Steuerungssynthese mit S-Invarianten). Die Netzmatrix NC und dieAnfangsmarkierung # »µC0 der Steuerung werden bestimmt durch:

NC = −L · NG (2.57)

# »µC0 =#»

b − L · # »µG0 . (2.58)

Die Anfangsmarkierung der Strecke ist # »µG0 . Diese Steuerungssynthese gilt nur, wenn:

#»

b − L · # »µG0 ≥#»

0 . (2.59)

Das gesteuerte System S/G ist wieder ein Petrinetz mit |P| = nG + nC, |T| = mG = mC

2. Grundlagen 36

und N =

[NGNC

]∈ Z(nG+nC)×mG . Ein Beispiel wird in Kapitel 6.5.4 gezeigt. In [30] wird

auch auf nichtsteuerbare und nichtbeobachtbare Transitionen eingegangen.

2.2. SPS-Programmiersprachen

Die Norm IEC 61131-3 [15] legt die Programmiersprachen für speicherprogrammierbareSteuerungen fest. Bevor diese Norm und ihre Vorgänger in Kraft traten, gab es bereits Pro-grammiersprachen für SPS. Viele Hersteller besaßen jedoch eine eigene Syntax, obwohl dieSprachen sehr ähnlich aufgebaut waren. So weichen einige Hersteller bis heute leicht vondieser Norm ab. Einer dieser Hersteller ist Siemens. In dieser Arbeit wird eine reale Anlagemit Siemens Hard- und Software in Betrieb genommen. Deswegen wird bei der Programmie-rung zwischen IEC 61131-3 und Siemens Syntax unterschieden.

Die Norm definiert fünf Programmiersprachen [25].

• Anweisungsliste - AWL (engl. Instuction List - IL): textbasierte Sprache, ähnlich einerMaschinensprache, jede Zeile enthält eine Operation

• Kontaktplan - KOP (engl. Ladder Diagram - LD): grafische Sprache, Stromlaufplan,elektrischen Schaltungen nachempfunden

• Funktionsbausteinsprache - FBS (engl. Function Block Diagram - FBD): grafischeSprache, miteinander verbundene Funktionsbausteine

• Ablaufsprache - AS (engl. Sequential Function Chart - SFC): grafische Sprache, eineArt Zustandsdiagramm

• Strukturierter Text - ST (eng. Structured Text - ST): textbasierte Sprache, ähnelt einerHochsprache

Siemens benennt diese Sprachen in gleicher Reihenfolge: AWL, KOP, FUP beziehungs-weise CFC, S7 Graph und SCL (Structured Control Language). Somit hat Siemens sechsProgrammierspachen, wobei CFC (Continuous Function Chart) eine Erweiterung von FUP(Funktionsplan) darstellt. CFC wird auch bei anderen Herstellern zur Erweiterung von FBSverwendet.

2. Grundlagen 37

2.3. Entwicklungswerkzeuge

In diesem Kapitel werden die verwendeten Entwicklungswerkzeuge kurz vorgestellt: das Sie-mens TIA Portal für die Steuerung der realen Anlage, das Programm DESTool zur Steue-rungssynthese mit Automaten und die Toolbox SPNBOX für MathWorks MATLAB zur Steue-rungssynthese mit Petrinetzen.

2.3.1. Siemens TIA Portal

Das Siemens Totally Integrated Automation Portal (TIA Portal) V12 bietet alle benötigtenFunktionen zur Automatisierung unter Siemens in einem Programm. Sechs Hauptkategori-en zur Bearbeitung, Einstellung und Entwicklung bilden das Grundgerüst des TIA Portals:Geräte- und Netzkonfiguration, SPS-Programmierung, Motion und Technologie, Antriebspa-rametrierung, Visualisierung, sowie Online und Diagnose. Die SPS-Programmierung ver-wendet die in Kapitel 2.2 genannten Programmiersprachen. Siemens stellt außerdem einePLCSIM zur Verfügung, mit der das Verhalten der Steuerung simuliert werden kann. EineEinführung zeigt [44].

2.3.2. DESTool

Das frei erhältliche Programm DESTool [31] der Universität Erlangen-Nürnberg wird in dieserArbeit für die Analyse und Steuerungssynthese von Automaten verwendet. Die Generatorenkönnen als Systeme per „Drag and Drop“ erstellt werden. Auf diese Systeme werden Ope-rationen der SCT angewandt. Die eingebundene c++ Bibliothek libFaudes [32] liefert wichti-ge Strukturen und Algorithmen für Automaten und reguläre Sprachen. Außerdem kann mitDESTool eine schrittweise Simulation durchgeführt werden. Die Verbindung zu einer realenStrecke wird über das libFAUDES IoDevice plug-in unterstützt, kommt in dieser Arbeit jedochnicht zum Einsatz. Die Tabelle 2.2 zeigt die verwendeten Funktionen.

2. Grundlagen 38

Funktion Beschreibung

isDetermistic Prüft, ob G deterministisch istisTrim Prüft, ob G nicht erreichbare oder co-erreichbare Zustände besitztisNonblocking Prüft, ob G nicht blockiertisNonblocking Prüft, ob zwei Generatoren nichtblockierend sindisControllable Prüft, ob eine Spezifikation bezüglich G steuerbar istTrim Führt die Trim-Operation durchProduct Führt die SPC-Operation durchParallel Führt die SYPC-Operation durchSupConNB Berechnet die nichtblockierende supremale steuerbare TeilspracheSupReduce Berechnet den reduzierten Supervisor nach [49]

Tabelle 2.2.: Verwendete Operationen aus DESTool

2.3.3. SPNBOX

Die SPNBOX [16] ist eine Toolbox für MathWorks MATLAB [43]. Die Toolbox wurde 2002entwickelt und 2013 wieder lauffähig gemacht. Die Aktualisierungen zu Version 1.2 wurdejedoch auf der Plattform Octave ausgeführt, daher waren für MATLAB kleine Änderungennotwendig. Eine Anleitung wird dazu in Anhang A gezeigt.

Damit die Toolbox funktioniert, muss außerdem lp_solve installiert werden, ein Löser fürgemischt-ganzzahlige lineare Programmierung (engl. Mixed Integer Linear Programming -MILP). Unter [1] sind alle Informationen über lp_solve inklusive Lizenzierung (GNU) aufge-listet. In [18] werden die wichtigsten Funktionen der SPNBOX beschrieben. Interessant ist,dass auch nicht steuerbare Transitionen betrachtet werden. Die folgende Tabelle 2.3 zeigtdie verwendeten Funktionen:


d2dd Teilt eine Netzmatrix N in die Flussrelationen N+ und N− aufgetpn Erstellt eine Struktur, die ein Petrinetz repräsentiertpncpraph Erstellt den Erreichbarkeitsgrafenilp_adm Prüft und ändert eine Spezifikation, sodass diese zulässig istdp Prüft und ändert eine Spezifikation, sodass diese nichtblockierend istlinenf Synthese, es entsteht NC

Tabelle 2.3.: Verwendete Funktionen der SPNBOX

3. Automatische Codegenerierung

In diesem Kapitel wird die automatische Codegenerierung betrachtet. Die Modelle aus derSCT müssen übersetzt werden, sodass eine reale Anlage mit Ein- und Ausgängen gesteuertwerden kann. Die hier betrachtete Codegenerierung soll ausschließlich für die SPS erstelltwerden. Zunächst wird die Programmierung der Grundstruktur von einem Generator undeinem Petrinetz vorgestellt. Verschiedene Programmiersprachen aus Kapitel 2.2 kommendabei zum Einsatz. Anschließend werden Probleme diskutiert, die bei der Programmierungauftreten können. Für die automatische Codegenerierung sind Konzepte wichtig, die Lö-sungen für verschiedene Entwurfsansätze bieten. Ein Literaturüberblick zeigt verschiedeneinteressante Ansätze. Von diesen Ansätzen werden drei detailliert vorgestellt.

3.1. Grundstrukturen und ihre Codegenerierung

Die Codegenerierung wird zunächst für Automaten betrachtet. Die Zustände eines Automa-ten werden durch boolsche Variablen oder bei Siemens als Merkerbits repräsentiert. Ereig-nisse sind Eingänge oder ebenfalls boolsche Variablen beziehungsweise Merkerbits.

A B

x

yz

Abbildung 3.1.: Ein (a) Generator und der zugehörige (b) Kontaktplan

Die Abbildung 3.1 (a) zeigt einen Generator. Aus Vergleichsgründen wird auch der Kontakt-plan (3.1(b)) angegeben, da dieser in vielen wissenschaftlichen Arbeiten verwendet wird. ImFolgenden wird die Programmierung des Generators in den Programmiersprachen AWL und

3. Automatische Codegenerierung 40

ST nach der IEC 61131-3 Norm, sowie AWL und SCL nach der Siemens Syntax, in Tabelle3.1 dargestellt. Die AWL-Syntax der Norm und von Siemens (deutsche Version) unterschei-

IEC 61131-3 AWL Siemens AWL IEC 61131-1 ST Siemens SCT

LD BAND yS AR B

LD AAND xS BR A

LD AST x

U "B"U "y"S "A"R "B"

U "A"U "x"S "B"R "A"

U "A"= "x"

IF B AND y THENA:=1; B:=0;

END_IF;

IF A AND x THENB:=1; A:=0;

END_IF;

x:=A;

IF "B" AND "y" THEN"A":=1; "B":=0;

END_IF;

IF "A" AND "x" THEN"B":=1; "A":=0;

END_IF;

"x":="A";

Tabelle 3.1.: SPS-Code eines einfachen Generators

den sich bereits in diesen einfachen Operationen. SCL und ST sind hier identisch. Das giltmeistens, jedoch nicht generell und jede Sprache sollte für sich betrachtet werden. Bei Sie-mens wird eine Variable immer mit Anführungszeichen eingerahmt. Im weiteren Verlauf derArbeit werden Beispiele in der Programmiersprache SCL beschrieben. Es ist sinnvoll, dieseSprache festzulegen, da SCL in Kapitel 7 auch für die Inbetriebnahme der Fertigungszelleverwendet wird. Der in dieser Arbeit entwickelte Codegenerator kann den Quellcode für al-le Sprachen aus Tabelle 3.1 generieren. Die Sprachen sind textbasierend und eignen sichdaher gut für die Generierung.

Ein Zustandsübergang wird anhand des Beispiels aus Abbildung 3.1 wie folgt programmiert:Ist der Zustand B aktiviert, also das Merkerbit ist Eins, und tritt das geforderte Ereignis y auf,wird der Zustand B zurückgesetzt (B=0) und der Zustand A gesetzt (A=1). In KOP wird dieAbfrage der Zustände und Ereignisse durch Schließer dargestellt, in AWL und ST/SCL miteiner Konjunktion.

Eine Reihenfolge sollte bei der Programmierung beachtet werden: nicht steuerbare Ereignis-se werden zuerst abgefragt. Eine SPS arbeitet den Programmcode zyklisch ab, würde nunzuerst ein steuerbares Ereignis abgefragt werden, würde der Zustandsübergang erfolgen.Ein ebenfalls aufgetretenes nicht steuerbare Ereignis mit einem anderen Zustandsübergangwürde, obwohl es immer erlaubt sein müsste, ignoriert werden. Die Strecke befände sich ineinem falschen Zustand und die korrekte Steuerung wäre nicht gegeben. Im Beispiel aus


Abbildung 3.1 ist das Ereignis x steuerbar (symbolisiert durch einen Strich in der Mitte desPfeils), die beschriebene Situation kann dort nicht auftreten, da vom Zustand A kein weite-res nicht steuerbares Ereignis abgeht. Trotzdem sollte die Reihenfolge generell eingehaltenwerden.

Das Setzen von steuerbaren Ereignissen wird hier am Ende des Codes ausgeführt. Nach[8] kann dies alternativ auch direkt in der betreffenden Zustandsabfrage erfolgen. Dem Bei-spiel ist zu entnehmen, dass die Selfloop mit dem Ereignis z nicht Teil des Programmcodesist, da keine Zustandsänderung stattfindet. Diese Selfloop kann jedoch für die Modellierungentscheidend sein.

Die Ausgänge einer Strecke müssen aus der Steuerung aktiviert werden. Es gibt zwei Mög-lichkeiten wie Ausgänge als steuerbare Ereignisse gesetzt werden:

1. Der Ausgang ist nicht selbsthaltend und nur für einen Zyklus gesetzt.

2. Der Ausgang ist selbsthaltend und bleibt solange gesetzt, bis die Steuerung wiedereingreift.

In der Literatur ist keine einheitliche Lösung vorhanden. Das Problem kann umgangen wer-den, indem Ausgänge in unterlagerten Steuerungen bearbeitet werden. So können Ausgän-ge auch zeitabhängig angesteuert werden. Andere Lösungen werden in Kapitel 3.3 vorge-stellt.

Die Programmierung der Petrinetze funktioniert auf ähnliche Art und Weise. Die Reihenfolgewird hier jedoch durch die Transitionen bestimmt. Es wird eine Transition nach der anderenabgearbeitet. Durch die zyklische Abarbeitung entsteht bei der Aufspaltung und Begegnungeine Priorisierung der zuerst abgefragten Transition. Stellen sind boolesche Variablen bezie-hungsweise Merkerbits. Ein Zustandsübergang wird dabei bezüglich einer Transition folgen-dermaßen programmiert: Sind alle Prästellen belegt (=1) und alle Poststellen frei (=0), dannwerden die Prästellen zurückgesetzt und die Poststellen gesetzt. Der Programmcode für daseinfache Petrinetz mit den Stellen p1 und p2 aus Abbildung 2.2 lautet in SCL:

IF "p1" AND NOT "p2" THEN"p1":=0; "p2":=1;

END_IF;

IF "p2" AND NOT "p1" THEN"p2":=0; "p1":=1;

END_IF;

Dies gilt für Petrinetze mit der Stellenkapazität und der Kantengewichtung gleich Eins. DieVerknüpfung des Petrinetzes mit Ein- und Ausgängen ist nicht definiert, dafür muss dasPetrinetz erweitert werden. In Kapitel 3.3 werden solche Ansätze erläutert.


3.2. Problematiken der Codegenerierung

In [21] werden Probleme bezüglich der Programmierung aus [13] aufgegriffen. Diese Proble-me beziehen sich auf Automaten, können aber auf Petrinetze übertragen werden. Bei derKonzeption in Kapitel 4 werden die Lösungen einiger dieser Probleme als Kriterien für dieBewertung von Codgenerierungsansätzen einfließen. Die fünf Probleme von A bis E aus [21]sind:

• (A) Kausalität: Entgegen der SCT, werden steuerbare Ereignisse normalerweise nichtspontan von der Strecke generiert, sondern es sind Ausgänge, die gesetzt werdenmüssen. Wie können diese generiert werden? Sind steuerbare Ereignisse auch immerAusgänge? Das Problem wurde bereits im vorherigen Abschnitt angedeutet und mussgelöst werden.

• (B) Lawineneffekt: Die Software springt über eine beliebige Anzahl von Zuständenin einem SPS-Zyklus. Dieser Effekt kann auftreten, wenn ein Ereignis für viele aufein-anderfolgende Zustandsübergänge verwendet wird. Dies ist zum Beispiel bei einemPuffer vorstellbar.

• (C) Auswahlproblem: Es kann vorkommen, dass von einem Zustand mehrere steuer-bare Ereignisse abgehen. Es ist jedoch notwendig, nur eins davon auszuwählen, dennmehrere auszuwählen könnte katastrophal und widersprüchlich sein. Was ist die besteAuswahl?

• (D) Gleichzeitigkeit: In einem SPS-Zyklus können mehrere nicht steuerbare Ereig-nisse gleichzeitig auftreten, dabei kann die genaue Reihenfolge der Ereignisse nichtfestgestellt werden. Die Reihenfolge kann jedoch bedeutsam sein, denn es könntezum Beispiel zu einem unterschiedlichen Steuereingriff führen.

• (E) Ungenaue Synchronisation: Während der Programmausführung kann ein Ereig-nis auftreten, welches jedoch erst im nächsten Programmzyklus erkannt wird1. Dieskann zu einem Problem führen, wenn durch das Ereignis eine Steuerentscheidungungültig geworden wäre.

Die Probleme A, B und C können durch die Programmierung gelöst werden. Für C ist an-zumerken, dass die Auswahl auch von der Anwendung abhängt. So könnte eine Auswahlpriorisiert, alternierend, stochastisch oder zufällig sein. Dies kann aktiv gestaltet oder nur alsErgebnis einer Programmierung ausgewertet werden.

1Eine SPS erstellt zum Zyklusbeginn ein Prozessabbild aller Eingänge, welches während der Programmbe-arbeitung nicht geändert wird. Nach der Progammausführung wird ein Prozessabbild der Ausgänge an diePeripherie übertragen [25].


Die Probleme D und E hängen stark von der Anwendung und der Hardware ab. Diese Kri-terien eignen sich weniger, um eine Codegenerierung zu bewerten. Eigenschaften könnenan die Modellierung gestellt werden, damit diese Probleme ausgeschlossen werden können.Nach [13] kann das Problem D theoretisch durch die Eigenschaft „verschachtelte Unemp-findlichkeit“ (engl. interleave insensitivity) gelöst werden. Die Eigenschaft fordert, dass nachverschachtelten nicht steuerbaren Ereignissen der Steuereingriff der gleiche sein muss. Diesist jedoch nicht immer möglich. Häufig können verschachtelte nicht steuerbare Ereignissenicht gleichzeitig auftreten, weil die reale Strecke es aufgrund der Kausalität nicht zulässt.Zur Vermeidung von E fordert [21] die Eigenschaft „verzögernde Unempfindlichkeit“ (engl.delay insensitivity), die Balemi und Brunner in [4] entwickelten und sogar eine Sprache undeinen Supervisor dafür einführten. Die Eigenschaft besagt, dass während eines Eingriffesdes Supervisors, dieser Eingriff von keinem aufgetretenen Ereignis widerlegt werden darf.Ist die Programmausführung der SPS wesentlich schneller als die Prozessgeschwindigkeit,ist das Auftreten dieses Problems unwahrscheinlich.

Nach [21] können auch Hardware Interrupts eine mögliche Lösung für D und E darstellen.Obwohl diese Probleme bedacht werden sollten, treten diese bei vielen Anlagen nicht auf.Dies gilt auch für die Fertigungszelle aus Kapitel 7 und daher müssen die Probleme D und Ein dieser Arbeit nicht weiter berücksichtigt werden.

3.3. Literaturüberblick

Die Literatur zeigt verschiedene Ansätze, die eine SPS-Codegenerierung beschreiben. Au-tomaten und Petrinetze werden dabei unterschieden.

Für die Automaten werden acht Ansätze vorgestellt. Es sind weit mehr als acht Ansätzevorhanden, aber diese zeigen interessante und unterschiedliche Varianten für verschiedeneEntwurfsansätze auf.

1. Fabian und Hellgren wurden bereits aufgeführt, denn in deren Arbeit von 1998 [13]werden die Problematiken der Codegenerierung aufgeführt. Es handelt sich nicht umeinen kompletten Ansatz, sondern es werden Strukturen und Möglichkeiten in KOPaufgezeigt.

2. Die Masterthesis von Leduc von 1996 [22] verwendet CMSSM (engl. clocked Mooresynchronous state machines), die ihren Zustand nur bei einer fallenden oder steigen-den Flanke eines Taktes ändern. Es ist ein modularer Entwurf in der Programmierspra-che KOP. Das besondere an CMSSM ist, dass ein Zustand aus einem Zustandsvektor,einem Eingangsvektor und einem Ausgangsvektor besteht und daraus eine einfacheProgrammierung resultiert. Hat ein Supervisor drei Zustände, so können diese mit ei-nem Zustandsvektor aus zwei Bits repräsentiert werden.


3. Ein lokal-modularer Entwurf wird 2002 von de Queiroz und Cury in [40] in KOP pro-grammiert. Hierfür werden das Produktsystem und die Supervisor gemeinsam imple-mentiert. Die Supervisor deaktivieren die steuerbaren Ereignisse, die in der Streckenicht ausgeführt werden dürfen.

4. Hasdemir, Kurtulan und Gören erweitern 2008 in [12] die Codegenerierung für denlokal-modularen Entwurf, um dem Lawineneffekt entgegenzuwirken. Dafür werdenzwei Bits pro Zustand verwendet.

5. Der Ansatz von Uzam, Gelen und Dalci [54] von 2009 beschäftigt sich mit Ausgängen.Anhand eines monolithischen Entwurfs wird gezeigt, dass Ausgänge als Selfloops aneinen Zustand gehängt werden können. So können diese Zustände nach der Syntheseleicht gefunden werden. Auch hier wird in KOP programmiert.

6. Eine weitere Codegenerierung in KOP für den lokal-modularen Entwurf zeigen Leal,da Cruz und da Silva Hounsell 2012 [21]. Alle Probleme aus Kapitel 3.2 werden hierdiskutiert und eine aus neun Schritten bestehende Codegenerierung, die DECON9Methodik, wird vorgestellt.

7. 2012 zeigt die Masterthesis von Urland [53] einen Ansatz für den modularen Entwurf.Hierfür fließen Strukturen aus [54] und [13] ein. Jeder Supervisor kann pro Zyklus nureine Zustandsänderung akzeptieren. Dies wird durch eine Variable erreicht, die denSupervisor nach einer Aktion blockiert. Die Steuereingriffe der einzelnen Supervisorwerden mittels Konjunktion verbunden, denn nur wenn alle beteiligten Supervisor die-sen Eingriff erlauben, wird er ausgeführt. Die Programmierung ist in AWL umgesetzt.

8. Possan Junior und Leal verwenden 2012 in [37] Mealy-Automaten. Das sind spezielleAutomaten mit einer Ausgangsaktion im Zustandsübergang. Dazu muss der erstell-te Supervisor umgewandelt werden, um anschließend die Codegenerierung in KOPdurchzuführen. Dieser Ansatz gilt für einen monolithischen Entwurf. Das Setzen vonAusgängen ist hier also klar definiert.

Vier Ansätze werden für Petrinetze beschrieben.

9. In [35] von 1999 entwerfen Mušic und Matko eine Steuerung mit S-Invarianten. DieCodegenerierung wird in Ablaufsprache durchgeführt. Die Ablaufsprache ähnelt be-reits einem Petrinetz, sodass mit einigen Anpassungen bezüglich der Kontrollstellen(Anwendung von Mutex) die Codegenerierung umgesetzt werden kann.

10. Mit der Ablaufsprache können Petrinetze auch als Strecke und Supervisor implemen-tiert werden. Hellgren, Fabian und Lennartson haben dies 2001 in [14] umgesetzt.Ein Ereignis-Beobachter wurde entwickelt, der die steuerbaren Ereignisse setzt. Für inKonflikt stehende Transitionen (zwei Transitionen, die einen Eingangszustand teilen)wird so die passende Transition ausgewählt.


11. Der Ansatz von Uzam und Jones [55] aus 2002 verwendet den Erreichbarkeitsgra-fen des Petrinetzes. Aus dem Grafen werden die unerwünschten Zustände ermitteltund damit eine Steuerungsstrategie festgelegt. Das gesteuerte Petrinetz wird in KOPprogrammiert, indem jede Transition abgefragt wird.

12. In 11. wird eine Codegenerierung verwendet, die in der Automatisierungstechnik rechtverbreitet ist. Diese basiert auf einer Erweiterung des autonomen Petrinetzes zu einemsteuerungstechnisch interpretierten Petrinetz, kurz SIPN. Diese Codegenerierung istfür Petrinetze allgemeingültig und beruht nicht auf einem bestimmten Entwurfsverfah-ren. In [10] wird die Codegenerierung in AWL beschrieben.

Dieser Überblick zeigt nur einen kleinen Ausschnitt der Literaturbeiträge. Der Umgang mitEin- und Ausgängen kann nicht für alle Ansätze aufgezeigt werden, trotzdem wird ein Ein-druck der vielfältigen Möglichkeiten vermittelt. Im Folgenden wird nun die Codegenerierungfür die Ansätze 5., 6. und 12. genauer beschrieben.

3.3.1. Codegenerierung mit Selfloop Ausgängen

In dem Ansatz aus [54] (5.) werden Ausgänge intensiv betrachtet. Der Grundgedanke dabeiist, dass ein Ausgang auch durch einen Zustand repräsentiert werden kann. Das heißt, so-lange der Zustand aktiv ist, soll auch der Ausgang gesetzt sein. Das wird auch als Aktionbezeichnet. Zum Beispiel soll ein Fahrstuhl abwärts fahren, es tritt ein steuerbares Ereignisauf: fahre abwärts. Daraufhin findet ein Zustandswechsel statt und dieser repräsentiert dasAbwärtsfahren, hier muss ein Ausgang gesetzt werden. Ein nicht steuerbares Ereignis gibtan: Position erreicht. Es folgt wieder ein Zustandswechsel. Die Abbildung 3.2 stellt dieseseinfache Beispiel als Automaten dar.

1 2

fahre abwärts

Position erreichtAusgang: abwärts fahren

Abbildung 3.2.: Beispiel: ein Automat mit Ausgang als Selfloop

Ausgang: abwärts fahren wird für die Programmierung mit A_abwaerts_fahren bezeichnet.Die Programmierung des Ausgangs in SCL lautet:


"A_abwaerts_fahren":="Zustand_2";

Der Ausgang muss für die Programmierung aussagekräftig benannt werden, damit diesersich von anderen Ereignissen in Selfloops unterscheidet. Das ist wichtig, weil Selfloops nor-malerweise nicht in den Programmcode einfließen. Der Ausgang muss für die Modellierungein nicht steuerbares Ereignis darstellen. Aktivieren mehrere Zustände denselben Ausgang,werden die Zustände mit eine Disjunktion verknüpft. Bei einer Aktion muss bedacht werden,dass es immer ein Ereignis geben muss, das die Aktion beendet. In dem Beispiel ist diesdas Ereignis: Position erreicht. Die Programmierung des Automaten wird ansonsten wie inKapitel 3.1 beschrieben durchgeführt. Die Ausgänge werden am Ende des Programmcodesgesetzt.

3.3.2. Codegenerierung mit der DECON9 Methodik

Die Codegenerierung nach [21] (6.) erfolgt in neun Schritten (Abbildung 3.3). Die DECON9

Abbildung 3.3.: DECON9 - Flussdiagramm des Hauptprogramms

Methodik besteht aus zehn Funktionen. Die Programmiersprache in [21] ist KOP, aber zurVerdeutlichung der Programmierschritte werden kleine Programmausschnitte in SCL ange-geben. Diese sind an kein Beispiel gekoppelt. Ein Zeilenkommentar wird mit // eingeleitet.


Im ersten Schritt wird die Initialisierung durchgeführt. Diese Funktion wird nur einmal zumProgrammstart oder im ersten SPS-Zyklus aufgerufen. Alle Initialzustände der Generatorenwerden hier gesetzt. Ein G im Zustandsnamen steht für einen Zustand von einem Generatordes Produktsystems (PS) und ein S für einen Zustand eines Supervisors.

//1. Schritt Initialisierung - Code-Fragment"G1_Zustand1":=1; "S1_Zustand1":=1;

Das Einlesen der Eingänge wird im zweiten Schritt durchgeführt. Wird eine positive Flankean einem Eingang registriert, wird das passende Ereignis dazu gesetzt. Das Ereignis ist nurfür einen Zyklus gesetzt. Eine Flanke kann zum Beispiel mit der Standardfunktion R_TRIGdetektiert werden. Die Ereignisse werden als Gruppe Mx.0 bezeichnet, Mx steht dabei füreinen beliebigen aussagekräftigen Namen des Ereignisses (hier: UCEreignis) und das .0symbolisiert die erste Gruppe. Jedes nicht steuerbare Ereignis wird von zwei Bits Mx.0 undMx.1 repräsentiert.

//2. Schritt Einlesen der Eingangssignale - Code-Fragment"R_TRIG"(CLK:="Eingang", Q=>"UCEreignis.0");

Die zweite Gruppe Mx.1 wird im dritten Schritt das erste Mal verwendet. Die Funktion Er-stelle Mx.1:=Mx.0 ist simpel aufgebaut, die zweite Gruppe wird gleich der ersten Gruppegesetzt. Dies wird benötigt, um den Lawineneffekt zu verhindern. Ebenfalls im dritten Schrittwerden die nicht steuerbaren Ereignisse des Produktsystems ausgewertet, und zwar mit derMx.1 Gruppe. Ist ein Ereignis aufgetreten, wird es in der Abfrage zurückgesetzt und kannkeine weiteren Zustandswechsel bewirken. Mx.1:=Mx.0 muss hier nicht vor jedem neuenGenerator des PS aufgerufen werden, weil diese keine gemeinsamen Ereignisse besitzen.Mx.0 behält die Information über die aufgetretenen Ereignisse, denn diese werden auch fürdie Supervisor benötigt.

//3. Schitt : Mx.1=Mx.0 - Code-Fragment"UCEreignis.1":="UCEreignis.0";

//3. Schitt : nicht steuerbare Ereignisse des PS - Code-FragmentIF "G1_Zustand1" AND "UCEreignis.1" THEN

"G1_Zustand2":=1; "G1_Zustand1":=0; "UCEreignis.1":=0;END_IF;

Im vierten Schritt wird dasselbe Prinzip für die nicht steuerbaren Ereignisse der Supervi-sor durchgeführt. Die Funktion Erstelle Mx.1:=Mx.0 muss jedoch vor jedem Supervisor auf-gerufen werden, da mehrere Supervisor dasselbe Ereignis beinhalten können. Der Ansatzermöglicht es, dass pro Zyklus und Generator mehrere Ereignisse einen Zustandsübergang


hervorrufen können. Ein Ereignis kann pro Generator jedoch nur einen Zustandsübergangbewirken.

//4. Schitt : Mx.1=Mx.0 Aufruf vor jedem Supervisor - Code-Fragment"UCEreignis.1":="UCEreignis.0";

//4. Schitt : nicht steuerbare Ereignisse des Supervisor - Code-FragmentIF "S1_Zustand1" AND "UCEreignis.1" THEN

"S1_Zustand3":=1; "S1_Zustand1":=0; "UCEreignis.1":=0;END_IF;

Die steuerbaren Ereignisse werden im fünften Schritt überprüft. Es werden die steuerbarenEreignisse deaktiviert, welche die Supervisor verbieten. Die Zustände, in denen das Ereignisverboten ist, werden mit einer Disjunktion verknüpft.

//5. Schritt: Deaktivierung der steuerbaren Ereignisse - Code-Fragment"dCEreignis1":="S1_Zustand2";"dCEreignis2":="S1_Zustand2" OR "S1_Zustand3";

Der sechste Schritt wird notwendig, wenn zwei steuerbare Ereignisse von einem Zustandeines Supervisors abgehen. Das heißt, es besteht die Möglichkeit auszuwählen, welches derEreignisse gesetzt wird. In vielen Fällen gibt die Strecke vor, dass nur ein Ereignis gesetztwerden kann. Wenn beide Ereignisse möglich sind, würde durch die zyklische Programm-ausführung immer das zuerst abgefragte Ereignis priorisiert werden. Das ist jedoch nichtimmer gewünscht, da so ein Teil des Modells auch gar nicht zum Einsatz kommen könnte.Nach DECON9 wird in diesem Schritt ein zufälliges Auswahlsystem implementiert. Dazu wirdeine zusätzliche Variable AUX verwendet. Die Variable wird in jedem Zyklus invertiert underzeugt somit eine Art zufällige Auswahl. [21] zeigt für die Identifizierung dieses Problemseinen Algorithmus in Form eines Flussdiagramms.

//6. Schitt : Auswahl - Code-Fragment"AUX":=NOT "AUX"IF "S1_Zustand1" AND NOT "dCEreignis1" AND NOT "dCEreignis2" THEN

IF "AUX" THEN "dCEreignis1":=1 ELSE "dCEreignis2":=1 END_IF;END_IF;

Die Zustandsübergänge für die steuerbaren Ereignisse des Produktsystems werden im sieb-ten Schritt durchgeführt. Ist das Ereignis nicht zuvor deaktiviert worden, erfolgt der Zu-standsübergang und das steuerbare Ereignis wird gesetzt. Dieses zusätzliche Setzen musserfolgen, damit im nächsten Schritt für die Supervisor klar ist, welche der erlaubten Ereig-nisse auch wirklich in der Strecke ausgeführt werden können. Diese enge Verzahnung istbedingt durch den Entwurf mit den reduzierten Supervisorn.


//7. Schitt : steuerbare Ereignisse des PS - Code-FragmentIF "G1_Zustand2" AND NOT "dCEreignis" THEN

"G1_Zustand3":=1; "G1_Zustand2":=0; "CEreignis":=1END_IF;

Im achten Schritt folgen nun die Zustandsabfragen für die Supervisor. Diese werden mitden aus der Strecke gesetzten Ereignissen durchgeführt.

//8. Schitt : steuerbare Ereignisse der Supervisor - Code-FragmentIF "S1_Zustand1" AND "CEreignis" THEN

"S1_Zustand2":=1; "S1_Zustand1":=0;END_IF;

Der letzte und neunte Schritt ist für das Setzen der Ausgänge zuständig. In diesem An-satz werden Ausgänge durch auftretende steuerbare Ereignisse gesetzt und mit dem darauffolgenden nicht steuerbaren Ereignis wieder zurückgesetzt. Im Grunde ist dies der gleicheAnsatz wie mit Selfloops nach [54], nur ist die Programmierung unterschiedlich. Solange derZustand der Strecke gesetzt ist, ist auch der Ausgang gesetzt.

//9. Schitt : Ausgänge setzen - Code-FragmentIF "UCEreignis.0" THEN

"Ausgang1":=0;END_IF;IF "CEreignis" THEN

"Ausgang1":=1; "CEreignis":=0;END_IF;

Ein komplettes Beispiel mit Modellierung und Codegenerierung (in KOP) zeigt [21]. Auf einsolches Beispiel wird hier verzichtet, da dies in Kapitel 6.4.4 ausführlich für die in dieserArbeit verwendete Codegenerierung durchgeführt wird.

Zusammengefasst sind die wichtigsten Merkmale der Codegenerierung:

• Implementierung des PS und der Supervisor für den lokal-modularen Entwurfsansatz

• Aufteilung der nicht steuerbaren und steuerbaren Ereignisse für das Gesamtsystem

• Vermeidung des Lawineneffekts durch Zwei-Bit-Repräsentation pro nicht steuerbaremEreignis

• Maximal mögliche Zustandsübergänge pro SPS-Zyklus

• Auswahl bei zwei aktivierten steuerbaren Ereignissen: Zufallsauswahl


3.3.3. Codegenerierung mit SIPN

Ein autonomes Petrinetz wird zu einem steuerungstechnisch interpretierten Petrinetz, wenndieses um eine Beschreibung von Ein- und Ausgängen erweitert wird. Auch zeitliche Aspektekönnen mit diesen Netzen umgesetzt werden. In der Dissertation von Frey [9] wird ein SIPNwie folgt definiert:

Definition 3.1 (Steuerungstechnisch interpretierte Petrinetze (SIPN)). Ein SIPN wirddurch ein 9-Tupel beschrieben:

SIPN = (P, T, N, P0, E, A, φ, ω, Ω) (3.1)

mit dem Petrinetz PN = (P, T, N, P0), wobei die Flussrelationen zur Netzmatrix zusam-mengefasst wurden, der Menge von Eingängen E und der Menge von Ausgängen A. DieZuordnung φ ordnet jeder Transition eine Schaltbedingung zu, die Zuordnung ω ordnetjeder Stelle eine Menge von Ausgängen zu und die Ausgabefunktion Ω verbindet diezugeordneten Ausgänge aller markierten Stellen.

In der einfachsten Form ist die Schaltbedingung der Zuordnung φ ein einzelner Eingangoder eine boolesche Funktion aus Eingängen. Zwei kleine Beispiele dafür sind: E1∧ E2 undE2∨ ¬E3.

Eine Transition t muss im SIPN eine zusätzliche Schaltbedingung erfüllen:

• die Transition t ist aktiviert, wenn φ(t) erfüllt ist, also das Ergebnis der booleschenFunktion gleich Eins beziehungsweise true ist.

Die Bedingungen aus Definition 2.7 für Prä- und Poststellen ist nach wie vor gültig. Das Pe-trinetz schaltet solange, bis eine stabile Markierung erreicht wird. Somit können in einemZyklus mehrere Transitionen schalten. Soll kein Lawineneffekt entstehen, muss der Entwick-ler das Verhalten beim Modellieren berücksichtigen. In [3] und [10] wird die Schaltbedingungnoch erweitert, sodass unter anderem auch Zeitbedingungen abgefragt werden können. EinAusgang ist einer Stelle zugeordnet. Solange diese Stelle eine Marke trägt, ist der Ausganggesetzt.

Die Abbildung 3.4 zeigt einen kleinen Ausschnitt aus einem SIPN und den dazugehörigenSPS-Code in SCL. In der grafischen Beschreibung werden die Ereignisse durch zusätzlicheLabel angefügt. Alternativ wäre es auch möglich, die Zuweisungen in einer Liste abzubilden.Für Transitionen kann nach [3] unterschieden werden, ob die Zuweisung eine Bedingungoder eine Anweisung ist. So ist im Beispielnetz die Erhöhung des Zählers eine Anweisungfür t1 und die boolesche Funktion mit den Eingängen eine Bedingung.


//Transition t1IF "p1" AND NOT "p2" AND("Eingang1" OR "Eingang2") THEN

"p2":=1; "p1":=0; "Zaehler":="Zaehler"+1;END_IF;//Ausgänge setzen"Ausgang":="p1" OR "p2";

Abbildung 3.4.: Beispiel: Fragmentales SIPN mit Programmcode in SCL

Eine Transition mit zeitlicher Bedingung kann mit einem Timer realisiert werden. Die Timer-Funktion ist eine Standardfunktion, die durch eine steigende Flanke gestartet wird. In die-sem Fall wird diese Funktion mit einer Einschaltverzögerung gewählt. Nach der Aktivierungläuft eine vorgegebene Zeit ab, die daraufhin eine Ausgangsvariable (hier TAusgang) setzt.Die Transition besteht somit aus zwei Teilen, aus der Timer-Funktion und der Ausführung,nachdem die Zeit abgelaufen ist. Es wird angenommen, dass nach der Stelle p2 aus Abbil-dung 3.4 eine zeitabhängige Transition folgt. Die aktivierte Transition soll nach einer Sekundeschalten, der Programmcode in SCL ist:

//Transition Timer"Timer".TON(IN:="p2" AND NOT "p3", PT:=T#1S, Q=>"TAusgang");IF "TAusgang" THEN

"p3":=1; "p2":=0;END_IF;

Wird die Aktivierung ungültig, während die Zeit abläuft, dann wird die Zeit zurückgesetztund die Ausführung bleibt korrekt. Dies kann zum Beispiel auftreten, indem die Marke einerPrästelle durch eine andere Transition abgezogen wird.

Ein ausführliches Beispiel für eine Codegenerierung mit SIPN wird in Kapitel 6.5.4 darge-stellt.

Eine ähnliche Petrinetzklasse zu SIPN bilden die bewerteten Petrinetze (engl. labeled Pe-tri nets). Jeder Transition wird einem Ereignis zugeordnet, jedoch existiert keine zusätzlicheDefinition für Ausgänge. Außerdem enthält das bewertete Petrinetz eine Menge an Stellen,die eine Endmarkierung angeben, wie die Menge Xm bei Automaten. [11], [6] und [27] defi-nieren diese Netze. Für bewertete Petrinetze kann eine formale Sprache direkt angegebenwerden und diese Netze eignen sich daher als Pendant zu Generatoren im Sinne der SCT.Eine Codegenerierung wird jedoch nicht beschrieben.

4. Konzeption

In diesem Kapitel wird die Auswahl von Entwurfsverfahren, Codegenerierung und Softwa-retools begründet. Einige Entscheidungen sind aufgrund von beschränkten Möglichkeitenbereits vorgegeben, andere Entscheidungen müssen anhand von Kriterien sinnvoll getroffenwerden.

4.1. Auswahl des Entwurfsverfahren

Es stehen der monolithische, der modulare, der lokal-modulare und der dezentrale Entwurfs-ansatz für Automaten zur Auswahl. Der monolithische Ansatz wird wegen der hohen Modell-komplexität nicht in Betracht gezogen. Der dezentrale bietet keinen Vorteil für die Fertigungs-zelle, die in Kapitel 7 gesteuert werden soll, da hier alle Ereignisse global verfügbar sind.

Urland hat in seiner Arbeit [53] für diese Fertigungszelle bereits eine Steuerung mit dem mo-dularen Ansatz entworfen. Nach seinen Bewertungskriterien (siehe [53], Kapitel 4.2) ist derAnsatz am geeignetsten, aber der lokal-modulare Ansatz liegt nur knapp zehn Prozent da-hinter. Somit kann dieser ebenfalls als geeignet für die Automatisierung der Fertigungszelleangesehen werden. Im Ausblick der Arbeit von Urland wird sogar empfohlen, weiterführendden lokal-modularen Ansatz zu testen, um neue Erkenntnisse zu erhalten. Wichtig ist, dassdie algorithmische Komplexität des Systems für ein Entwicklungstool lösbar ist. Die Umset-zung des modularen Entwurfs hat das bereits bewiesen. Die algorithmische Komplexität deslokal-modularen Ansatzes ist im schlechtesten Fall gleich, häufig jedoch geringer als beimmodularen Ansatz [57]. Der Unterschied wird um so größer, je mehr nebenläufige Kompo-nenten das System hat. Die genaue Berechnung der algorithmischen Komplexität zeigt [56].Als erste Einschätzung sind also beide Ansätze geeignet. Zur Gewinnung von neuen Er-kenntnissen wird der lokal-modulare Entwurfsansatz gewählt.

Die Entscheidung für den Steuerungsentwurf mit S-Invarianten ist eindeutig. Dies ist dereinzige Ansatz mit Petrinetzen als Beschreibungsform, für den ein Entwicklungstool zur Ver-fügung steht. Außerdem ist der Ansatz besonders interessant, da sich dieser von den Ansät-zen mit Automaten stark unterscheidet, indem strukturelle Eigenschaften des Netzes ausge-nutzt werden.

4. Konzeption 53

Urland stellt in [53] (Kapitel 4.1) fest, dass Automaten für die Fertigungszelle die besse-re Beschreibungsform darstellen. Dies spielt in dieser Arbeit eine untergeordnete Rolle, dadie Codegenerierung für verschiedene Syntheseverfahren untersucht werden soll. Die Ferti-gungszelle dient lediglich als praktische Anwendung. Wichtig ist nur, dass der Ansatz reali-sierbar ist.

4.2. Konzept zur Codegenerierung

Zunächst wird die Codegenerierung für Automaten betrachten. In Kapitel 3.3 wurden achtAnsätze vorgestellt. Der 1. Ansatz steht nicht zur Auswahl, weil keine komplette Codegene-rierung vorgestellt wird. Die Ansätze 2. und 8. werden nicht betrachtet, da die Automatenvor der Codegenerierung in eine andere Struktur umgewandelt werden müssen. Die Tabelle4.1 zeigt einen Vergleich der restlichen Ansätze. Die Kriterien sind die Eignung für den lokal-modularen Entwurf, die Lösung der Problematiken A (Kausalität), B (Lawineneffekt) und C(Auswahlproblem) aus Kapitel 3.2, sowie der Umgang mit Ausgängen. Die Programmierspra-che ist kein Kriterium, da alle Ansätze in AWL und ST/SCL übertragen werden können. EinePunktzahl von Eins (- -) bis Fünf (++) wird für die Kriterien vergeben und ebenfalls für einenFaktor, der die Wichtigkeit des Kriteriums bewertet. Das Kriterium Problematik A wird mit

Kriterium Faktor 3. Ansatz 4. Ansatz 5. Ansatz 6. Ansatz 7. Ansatz

Entwurf 4 5(++) 5(++) 1(- -) 5(++) 2(-)Problematik A 5 5(++) 5(++) 5(++) 5(++) 5(++)Problematik B 3 1(- -) 5(++) 1(- -) 5(++) 4(+)Problematik C 2 3(o) 3(o) 3(o) 5(++) 3(o)Ausgänge 4 3(o) 3(o) 5(++) 4(+) 5(++)

Gesamt 81 93 73 101 89

Tabelle 4.1.: Automaten - Auswahltabelle für Codegenerierungsansätze

Faktor Fünf gewertet, es muss in jedem Fall gelöst werden, da sonst keine Steuerung erstelltwerden kann. Die Eignung für den lokal-modularen Entwurf wird mit Faktor Vier gewertet,weil theoretisch die Möglichkeit besteht, dass eine Anpassung vorgenommen werden kann.Ausgänge wurden ebenfalls mit Faktor Vier bewertet. Ein Steuergerät muss die Ausgängezwar schalten, es ist jedoch möglich, dies in unterlagerten Funktionen durchzuführen. DieProblematik B wurde mit Faktor Drei gewichtet, da die Lösung für jeden Ansatz leicht nach-gerüstet werden kann. Problematik C wird nur mit dem Faktor Zwei gewichtet, denn in vielenFällen kann diese auch in der Modellierung gelöst werden.

4. Konzeption 54

Das Kriterium der Ausgänge soll an dieser Stelle genauer untersucht werden. Hier wurdendrei Punkte vergeben, wenn zwar auf steuerbare Ereignisse eingegangen wurde, aber Aus-gänge nicht näher spezifiziert wurden. Vier Punkte wurden vergeben, wenn auch auf dieBedeutung der Ausgänge eingegangen wurde. Der 3. Ansatz (Selfloop Ausgänge) bekommtfünf Punkte, weil die Ausgänge auf besonders einfache Art und Weise gesetzt werden. Dieshat der 7. aus dem 3. Ansatz übernommen. Im Gegensatz zum 6. Ansatz (DECON9), in-dem ein steuerbares Ereignis den Ausgang setzt und ein nicht steuerbares Ereignis diesenwieder rücksetzt, muss bei 3. nur ein Zustand betrachtet werden.

Auch ohne Berechnung wird deutlich, dass der 6. Ansatz mit der DECON9 Methodik alle An-forderungen erfüllt. Mit 101 von 105 Punkten wird dieser für die automatische Codegenerie-rung ausgewählt. Die Ausgänge werden jedoch nach dem 3. Ansatz mit Selfloops realisiert,da dieses Vorgehen durch seine Einfachheit überzeugt.

Weitere Anforderungen werden zusätzlich an die Codegenerierung gestellt:

• Der Lawineneffekt muss auch für die steuerbaren Ereignisse verhindert werden.

• Einige Eingänge müssen spezialisiert eingelesen werden.

• Der Supervisor wird Ereignisse nicht verbieten sondern erlauben. Der Grund dafürist, dass in den großen Generatoren der Fertigungszelle aus Kapitel 7 viel wenigerAbfragen für erlaubte, als für nicht erlaubte Ereignisse vorhanden sind. Hat ein Gene-rator zum Beispiel zehn Zustände, so kann ein Ereignis, welches nur in einem Zustanderlaubt ist, durch eine Konjunktion anstatt durch neun Disjunktionen ausgedrückt wer-den. Dies steigert die Übersichtlichkeit.

• Es sollen zusätzlich auch zeitabhängige Ausgänge implementiert werden können.

In Kapitel 6 werden diese Änderungen ausführlich beschrieben.

Der Codegenerierungsansatz für Petrinetze wird mit Tabelle 4.2 ausgewählt. Vier Ansätzewurden für die Auswahl in Kapitel 3.3 vorgestellt. Besonders wichtig ist die Programmier-

Kriterium Faktor 9. Ansatz 10. Ansatz 11. Ansatz 12. Ansatz

Entwurf 4 1(- -) 5(++) 2(-) 5(++)Problematik A 3 5(++) 5(++) 5(++) 5(++)Problematik B 3 1(- -) 1(- -) 1(- -) 3(o)Problematik C 2 3(o) 3(o) 4(+) 4(+)Programmiersprache 5 1(- -) 1(- -) 5(++) 5(++)

Gesamt 33 49 59 77

Tabelle 4.2.: Petrinetze - Auswahltabelle für Codgenerierungsansätze

4. Konzeption 55

sprache der Ansätze (Faktor Fünf). Der 9. und 10. Ansatz eignet sich nicht für eine automa-tische Codegeneration, denn die Ablaufsprache ist nicht textbasierend. Eine nachträglicheÜbertragung in AWL oder ST/SCL wäre unnötig aufwendig. Mit Faktor Vier wurde der sichauf S-Invarianten beziehende Entwurf gewichtet. Der Ansatz 12. erhält für dieses Kriteriumfünf Punkte, weil dieser sich im Grunde auf keinen Entwurf bezieht und vollständig übertrag-bar ist. Die Problematik A ist mit Faktor Drei weniger gewichtet, als bei Automaten, da keinesteuerbaren Ereignisse gesetzt werden müssen. Das Schalten der Transition ist in erster Be-trachtung nur von den Prä- und Poststellen abhängig. Die Problematik B, mit Drei gewichtet,wird nur im 12. Ansatz beachtet, allerdings nur mit der Aussage: der Lawineneffekt muss beider Modellierung verhindert werden. Auch Problematik C wird mit Faktor Zwei gewichtet. ImGrunde findet immer eine Priorisierung statt, der 12. Ansatz gibt das explizit als Regel vor.

Der 12. Ansatz (SIPN) wird mit 77 von 85 Punkten für die Codegenerierung mit Petrinetzenausgewählt. Der Ansatz kann ohne Änderungen verwendet werden.

4.3. Auswahl des Entwicklungstools

Die Modellierung, Analyse und Synthese von einer Steuerung wird mit einem Entwicklungs-tool durchgeführt. In [53] (Kapitel 4.3) vergleicht Urland für Automaten die Tools TCT (Univer-sity of Toronto, Kanada [51]), DESTool (Friedrich-Alexander Universität, Erlangen-Nürnberg[31]) und Supremica (Chalmers University of Technology, Schweden [50]). DESTool über-zeugt vor allem durch die gute Bedienbarkeit und den großen Funktionsumfang.

Noch in der Entwicklung ist das Tool Nadzoru (Universidade do Estado de Santa Catarina,Brasilien) und wird in [26] erwähnt. Das Tool läuft unter Linux und hat eine grafische Benut-zeroberfläche. Ein Test von Nadzoru zeigte, dass die Entwicklung für eine Modellierung derFertigungszelle aus Kapitel 7 noch nicht weit genug fortgeschritten ist. Das Programm wirddaher für einen Einsatz in dieser Arbeit nicht in Betracht gezogen.

Das Programm DESTool wird für den Entwurf mit Automaten verwendet. Es wurde bereits inKapitel 2.3.2 vorgestellt. Das Tool besitzt keine Funktionalität zur Codegenerierung, es mussalso ein Codegenerator für den lokal-modularen Entwurfsansatz entwickelt werden.

Der Entwurf mit Petrinetzen wird mit der in Kapitel 2.3.3 vorgestellten Toolbox SPNBOX (Uni-versity of Notre Dame, Indiana [16]) durchgeführt. Alternativen sind nicht bekannt. Die Tool-box besitzt ebenfalls keine Funktionalität zur Codegenerierung. Das Tool SipnLab (HAWHamburg [42]) generiert aus steuerungstechnisch interpretierten Petrinetzen AWL-Code.Trotz einer guten Bedienbarkeit mit einer grafischen Oberfläche wird das Programm nichtverwendet, da die Modelle aus der SPNBOX nicht in das Tool eingebunden werden können.In den Codegenerator für den lokal-modularen Entwurfsansatz wird stattdessen die Code-generierung für den Entwurf mit S-Invarianten integriert.

5. Entwicklung des Entwurfsansatzes fürPetrinetze mit der Toolbox SPNBOX

Im Gegensatz zu DESTool, welches als Entwicklungstool direkt verwendet werden kann,muss der Entwurf mit der Toolbox SPNBOX weiterentwickelt werden. Vor allem wird eineDatei benötigt, die die Ergebnismodelle enthält.

Der Ansatz ermöglicht die Verwendung von modularen Petrinetzen, die einzelne Komponen-ten des Systems darstellen. Zuerst müssen diese Netze entworfen werden, dass kann hand-schriftlich, mit einem Zeichenprogramm oder einer anderen Software umgesetzt werden. DiePetrinetze müssen als SIPN erstellt werden, jedoch können die Bedingungen in MATLABnicht eingetragen werden, sondern werden später im Codegenerator nachgetragen. Wichtigist es festzulegen, welche Transition steuerbar und welche nicht steuerbar ist. Transitionenmit einem Eingang als Bedingung und zeitabhängige Transitionen sind nicht steuerbar. DieUngleichungen, also die Spezifikationen des Entwurfes mit S-Invarianten, werden für diePetrinetze aufgestellt.

Abbildung 5.1.: Flussdiagramm - Aufbau der MATLAB-Datei

5. Entwicklung des Entwurfsansatzes für Petrinetze mit der Toolbox SPNBOX 57

Eine Spezifikation betrifft häufig zwei oder mehr Petrinetze. Auf diese Weise werden dieKomponenten zu einer Steuerung verbunden.

Die Abbildung 5.1 zeigt den groben Aufbau der entwickelten MATLAB Datei. Mit dieser Dateiwird der Entwurf durchgeführt. Ein modulares Petrinetz wird mit einer Netzmatrix N, einemString-Array S und einem Vektor P0 angegeben. Die Netzmatrix kann mithilfe einer Softwarewie JPetriNet [19] erstellt werden. Ein Petrinetz wird grafisch erstellt und das Programm gibtdie Netzmatrix aus, die anschließend in MATLAB eingetragen werden kann. Das String-ArrayS beinhaltet für jede Stelle einen Namen, zum Beispiel ’P1’. So kann der Name, der späterals SPS-Variable genutzt wird, beeinflusst werden. Der Vektor P0 ist der Initialmarkierungs-vektor. Die eingegebenen Petrinetze werden in drei Arrays für N, S und P0 zusammenge-fasst. Das ermöglicht einen einfachen Zugriff auf die Petrinetze nur über die Angabe desArray-Elements.

Für die Synthese müssen die Petrinetze durch die Angabe des Array-Elements ausgewähltwerden, die Teil einer Spezifikation sind. Zunächst werden deren Netzmatrizen mit der Funk-tion CreateMatrix zu einer Matrix verbunden. Mit MATLAB werden auch die Initialmarkie-rungsvektoren zusammengefasst. Die Angaben über die nicht steuerbaren Transitionen, desKonstantenvektors

#»

b und der Gewichtungsmatrix L (siehe auch Gleichung 2.53) müssenvom Nutzer eingegeben werden. Zu beachten ist, dass sich die Angaben auf das zusam-mengefasste Netz beziehen.

Wurden alle Angaben korrekt getätigt, wird mit der Funktion Synthese die Steuerung erzeugt.Zuerst wird in der Funktion die SPNBOX-Funktion ilp_adm aufgerufen. Es wird überprüft, obdie Ungleichungen im Bezug auf die nicht steuerbaren Transitionen zulässig sind. Ist diesnicht der Fall, werden von der Funktion alternative Ungleichungen angegeben. Der Nutzermuss diese überprüfen und bewerten, ob die Steuerungsaufgabe noch erfüllt wird. Gegebe-nenfalls muss das Modell geändert werden. Anschließend wird mit der SPNBOX-Funktiondp das Netz auf Blockierung bezüglich der Ungleichung getestet. Auch hier gibt die Funktioneventuell eine alternative Ungleichung an, die überprüft werden sollte. Mit der SPNBOX-Funktion linenf wird die Steuerung beziehungsweise der Supervisor erstellt.

Nach der Synthese müssen die modularen Netze mit der Funktion Update aktualisiert wer-den. Die Steuerstellen werden den einzelnen Petrinetzen hinzugefügt.

Es folgt eine Wiederholung der Synthese für alle Spezifikationen. Die Entwicklung ist alsoiterativ und bei der nachfolgenden Synthese muss beachtet werden, dass die Netze durchdie Steuerstellen vergrößert wurden. Dies ist zum Beispiel bei der Eingabe von L relevant.

Im letzten Schritt wird das Ergebnis in einer MATLAB-Datei (m-File) gespeichert, die so-mit alle benötigten Daten für die automatische Codegenerierung enthält. Die Datei, welcheauch als Protokoll bezeichnet werden kann, wird in Kapitel 6.3 vorgestellt. Ein Beispiel derentwickelten MATLAB-Datei zeigt Anhang A.

6. Codegenerator ACArrow

Der Codegenerator ist das Verbindungsglied zwischen Entwicklungstool und Steuergerät.Aus den Modellen wird ein Programmcode erstellt, der von dem Steuergerät, in diesem Falleine SPS, interpretiert werden kann. In [53] hat Urland den Codegenerator DES2IEC fürden modularen Entwurfsansatz entwickelt. Der Generator wird in dieser Arbeit jedoch nichtweiterentwickelt, da zum einen für die Bedienung keine grafische Benutzeroberfläche zurVerfügung steht und zum anderen die Struktur für die aufwendigere Codegenerierung deslokal-modularen Entwurfsansatz zu wenig Übersichtlichkeit bietet. Der im Rahmen dieserArbeit neu entwickelte Codegenerator heißt Automatic Codegenerator Arrow (ACArrow). DerPfeil (engl. Arrow) im Namen symbolisiert das Verbindungsglied zwischen Entwicklungstoolund Steuergerät. ACArrow wurde in der Programmiersprache C# [5] mit der Entwicklungs-umgebung Microsoft Visual Studio 2012 [28] unter Windows programmiert.

6.1. Aufbau des Codegenerators

Die Abbildung 6.1 zeigt den groben Aufbau des Codegenerators. ACArrow integriert einenCodegenerator für Automaten und einen für Petrinetze. Jeder Codegenerator erhält ein eige-nes Eingangsdatenformat. Die Auswahl für das Codegenerierungsverfahren richtet sich beiden Automaten nach dem Entwurfsansatz. Der Codegenerierungsansatz nach Urland [53]wird zur Verifizierung der Programmierung auch mit ACArrow umgesetzt. Das entspricht derFunktion modular. Die neue Codegenerierung wird mit der Funktion lokal-modular realisiert.Ebenfalls eine Übernahme aus DES2IEC ist die Funktion Adjazenzmatrix. Die Adjazenzma-trizen aller Generatoren werden in eine Excel-Datei ausgegeben, sie werden jedoch nichtweiter zur Codegenerierung benötigt. Zwar sind die Ansätze für die Funktionen modular undAdjazenzmatrix aus DES2IEC übernommen, die Funktionen wurde jedoch komplett neu pro-grammiert. Die Petrinetze haben nur eine Funktion, die SPS-Code mit SIPN erstellt.

Als Ausgabe generiert ACArrow verschiedene Dateien die den SPS-Code enthalten. Einwichtiges Element des Codegenerators ist die Datenbank. Diese wird nur temporär verwen-det, solange der Codegenerator ausgeführt wird. Die Datenbank wird genutzt, um die vielenÜbergangsfunktionen organisiert einzuordnen und bei Bedarf nach beliebigen Auswahlkrite-rien zu sortieren und abzurufen. Die grafische Benutzeroberfläche von ACArrow wurde mit

6. Codegenerator ACArrow 59

Abbildung 6.1.: Aufbau von ACArrow

einem Windows Forms-Projekt [36] erstellt. Abbildung 6.2 zeigt die Aufteilung der Benutzer-oberfläche. Über das Hauptmenü kann zwischen dem Codegenerator für Automaten unddem für Petrinetze umgeschaltet werden. Danach folgt ein Menü für verschiedene Benut-zerfunktionen. Der Anzeigebereich zeigt die Ansicht und Interaktion zur jeweiligen Benutzer-funktion an.

Abbildung 6.2.: Aufteilung der Benutzeroberfläche


6.2. Die Datenbank als zentrales Werkzeug

Als Datenbanksystem wird das Microsoft SQL Server Compact 4.0 [52] verwendet.Es ist eine eingebettete Datenbank, die unter anderem zur Entwicklung von Windows-Anwendungen genutzt wird. Der Vorteil dieser Datenbank ist, dass lediglich die BibliothekSystem.Data.SqlServerCe.dll dem Projekt hinzugefügt werden muss. Diese Bibliothek bein-haltet Klassen, die den Zugriff auf die Datenbank realisieren. Der Begriff SQL definiert einespezielle Datenbanksprache [20]. Mit SQL-Befehlen können gezielt Daten aus der Daten-bank abgerufen werden. Die SQL-Befehle sind interpretierte Strings, die durch Verwendungvon Schlüsselwörtern beispielsweise folgende Zugriffe ermöglichen: Erstellen von Daten-banken, Erstellen von Tabellen, Daten in Tabellen schreiben, Daten aktualisieren, Tabellensortieren, Daten lesen. Der Umgang mit der Bibliothek erfordert meistens pro Funktionali-tät mehrere Programmierschritte. Diese Schritte werden durch die selbst entwickelte KlasseSQLDatabase zu einem Methodenaufruf zusammengefasst.

Die Datenbank ist ein zentrales Werkzeug von ACArrow, da sie alle Daten der verwende-ten Modelle enthält. Inbesondere trägt sie zur Flexibilität des Codegenerators bei. Soll eineandere Modellierungssoftware verwendet werden, so muss nur das Einlesen des Protokollsverändert werden. Die Ausgabe bleibt gleich. Umgekehrt, soll eine neue Ausgabe mit eineranderen Codegenerierung durchgeführt werden, liegen die Daten bereits vor und müssennur neu verarbeitet werden. Die klare Struktur vereinfacht zudem die Datenverarbeitung.

Die Tabellen sind die Elemente der Datenbank. Für Automaten werden zwei Tabellen ange-legt. Die erste Tabelle 6.1 beinhaltet die Zustandsübergänge. Alle Angaben in den Tabellensind an kein Beispiel gekoppelt und dienen nur der Veranschaulichung. Die Zustände werden

NameGen 1. Zustand Ereignis 2. Zustand EreignisTyp Nr. GenTyp

G1 1 STR_x 2 0 1 0G1 2 E_x 3 1 2 0S1 1 E_x 2 1 3 1

Tabelle 6.1.: Datenbanktabelle Generator

durch Zahlen beschrieben, die Nummerierung startet für jeden Generator wieder bei Eins.Der Zustandsübergang erfolgt vom 1. Zustand zum 2. Zustand, wenn das entsprechendeEreignis auftritt. Vier Ereignistypen können dabei durch ihre Anfangsbuchstabenfolge unter-schieden werden:

Ereignistyp 0: ein steuerbares Ereignis - STR_Name

Ereignistyp 1: ein nicht steuerbares Ereignis oder Eingang - E_Name


Ereignistyp 2: ein Ausgang - A_Name

Ereignistyp 3: ein zeitliches Ereignis - T_Zeit_Name

Die Definition eines zeitlichen Ereignisses erfolgt in Kapitel 6.4.1. Die Nummer in Tabelle 6.1identifiziert jeden Eintrag eindeutig. Der Generatortyp ist entweder ein Teil der Strecke oderein Teil des Supervisors. Diese Unterscheidung ist für den lokal-modularen Ansatz wichtig:

Generatortyp 0: ein Generator der Strecke - GNummer

Generatortyp 1: ein Generator des Supervisors - SNummer

Die Einordnung in eine der Kategorien erfolgt hier jedoch nicht nach der Benennung, sondernin DESTool kann ausgewählt werden, ob der Generator Teil der Strecke oder des Supervi-sors ist. Diese Auswahl wird aus dem Protokoll entnommen. Fehlt diese Angabe, wird derGenerator nicht eingelesen. In der zweiten Tabelle 6.2 werden die Initialzustände und die

Nr. NameGen Init Anzahl

1 G1 1 32 S1 1 4

Tabelle 6.2.: Datenbanktabelle Generator - Initialzustände

Anzahl der Zustände für jeden Generator angegeben.

Die Petrinetze haben eine andere Struktur und benötigen daher auch einen anderen Ta-bellenaufbau. Die erste Tabelle 6.3 beschreibt die Transitionsübergänge. Ein Schalten der

NamePetri Prästellen Transition Poststellen Bedingung Anweisung Nr.

N1 P1,P2 T0 P3 “E_x“ 1N1 P3 T1 P4 “Zaehler“:=0 2

Tabelle 6.3.: Datenbanktabelle Petrinetz

Transition erfolgt nach der Beschreibung aus Kapitel 3.3.3. Die Spalten Bedingung und An-weisung in Tabelle 6.3 erweitern das Petrinetz zu einem SIPN. Die Angaben können direkt indie Benutzeroberfläche von ACArrow eingegeben werden. Das dazu nötige Verfahren wird inKapitel 6.5.2 erläutert. Die Programmierung der Bedingungen und Anweisungen erfolgt alsvollständig eingetragener SPS-Code. So kann der Tabelleneintrag für die Bedingung kom-plett mit einer Konjuktion in die Abfrage eingetragen werden. Die Anweisung wird komplett inden ausführenden Teil der Transitionsabfrage eingefügt. Als einziger Begriff wird der TIMER


mit Zeitangabe für eine zeitlich gesteuerte Transition eingeführt, die eine spezielle Program-mierung erfordert. Ein Beispiel folgt in Kapitel 6.5.4.

Die zweite Tabelle 6.4 für Petrinetze gibt die Initialmarkierungen an. Alle genannten Stellentragen zur Initialisierung eine Marke. Ein SIPN benötigt noch eine Zuordnung für die Aus-gänge. Die Tabelle 6.5 beschreibt diese Zuordnung. Die Ausgänge müssen nicht als Pro-

Nr. Stelle

1 P12 P2

Tabelle 6.4.: Initialstellen

Nr. Stelle Ausgang

1 P1 A_x2 P3 A_y, A_x

Tabelle 6.5.: Ausgangszuweisung

grammcode angegeben werden, da keine Spezialfälle auftreten. Werden mehrere Ausgängevon der selben Stelle aktiviert, werden diese durch ein Komma getrennt. Das gilt auch fürBedingungen und Anweisungen aus Tabelle 6.3.

6.3. Analyse der Eingangsprotokolle

Die mit den Entwicklungstools entstandenen Modelle sind als Protokolle abgespeichert. Da-mit diese korrekt eingelesen werden können, muss die Struktur des Protokolls analysiertwerden. Das DESTool Protokoll (*.pro) speichert alle Daten des Projektes. Für diese Arbeitwird die DESTool Version V0.74 verwendet. Damit das Protokoll im benötigten Format erstelltwird, muss die Option Visuelle Repräsentation ausgewählt werden. Die Tabelle 6.7 zeigt dasProtokoll für den Generator aus Abbildung 3.1. Der Generator wurde G1 genannt und dieZustände sind nummeriert und nicht mit A oder B bezeichnet.

Das Protokoll ist in einer HTML- ähnlichen Syntax verfasst. Bestimmte Begriffe können ge-nutzt werden, um die relevanten Informationen des Generators herauszufiltern. Zum Bei-spiel zeigt <Variable> an, dass in der nächsten Zeile der Generatorname zu entnehmen ist.Stimmen die Eigenschaften, wie die Angabe System und +Plant+ (Strecke), so wird dasEinlesen initialisiert. Daraufhin ist mit <Initial/> der Initialzustand in der darüber liegendenZeile zu entnehmen. Markierte Zustände werden für die Codegenerierung nicht benötigt.Das <Alphabet> wird nicht verwendet, denn alle weiteren Informationen werden den Ab-schnitt <TransitionRelation> entnommen. Die Benennung der Ereignisse wie in Kapitel6.2 vorgestellt, ist zur Einordnung für den Codegenerator notwendig. Die Ereignisse x, y undz könnten hier nicht korrekt eingeordnet werden.

Das Protokoll für Petrinetze aus MATLAB, mit der Dateiendung *.m, zeigt Tabelle 6.7 undist sehr einfach aufgebaut. Es zeigt das Beispiel aus Abbildung 2.2. Die Trennung mit einem


Komma im Variablenname, wie zum Beispiel für das erste Netz N,1, wird durch die MATLAB-Funktion dmlwrite erzeugt, die normalerweise numerische Arrays in eine Datei schreibt. Daskann im C# Codegenerator leicht wieder entfernt werden. Der Buchstabe N zeigt ein neuesPetrinetz an, nachfolgend steht in jeder Zeile der Name von einer Stelle. Durch den Buch-staben D wird initiiert, dass in den nächsten Zeilen die Netzmatrix steht. Hierbei steht eineZeile für eine Transition. Zuletzt können die Stellen, die zur Initialisierung eine Marke tragen,nach dem X abgelesen werden.

DESTool Protokoll *.pro MATLAB Protokoll *.m

<Project application="DESTool" version="0.74">

<VariablePool><Variable>G1 System +Visual+ +Plant+<Value><VioSystem><Generator name="G1" ftype="System">

<Alphabet><Event name="x"><Controllable/></Event><Event name="y"/><Event name="z"/></Alphabet>

<StateSet><State id="1"><Initial/><Marked/></State><State id="2"/></StateSet>

<TransitionRelation><Transition x1="1" event="x" x2="2"/><Transition x1="2" event="y" x2="1"/><Transition x1="2" event="z" x2="2"/></TransitionRelation>

N,1P,1P,2D,1-1,11,-1XP,1

Tabelle 6.6.: Eingangsprotokolle


6.4. Codegenerierung für Automaten

In diesem Kapitel wird die Codegenerierung für den lokal-modularen Ansatz genauer be-trachtet und ein Programmierbeispiel wird vorgestellt. Die Funktion Adjazenzmatrix generiertlediglich für jeden Generator eine Adjazenzmatrix und speichert diese in einer Excel-Datei.Die Codegenerierung für den modularen Ansatz wird in [53] ausführlich beschrieben. Aufeine genauere Beschreibung der Programmierung beider Funktionen wird verzichtet, da derFokus in dieser Arbeit auf dem Entwurf und der Codegenerierung mit dem lokal-modularenAnsatz liegt.

6.4.1. Ein- und Ausgänge

Dieses Kapitel beschreibt einige Besonderheiten bezüglich Ein- und Ausgängen. Zunächstwerden verschiedene Möglichkeiten vorgestellt, wie ein Eingangssignal eingelesen werdenkann. Anschließend wird der zeitabhängige Ausgang definiert, dies beschreibt einen Aus-gang, der nur für eine bestimmte Zeit gesetzt wird.

Verschiedene Eingangssignale

Neben dem einfachen Einlesen eines Einganges über die Flankendetektion werden drei wei-tere spezielle Eingänge eingeführt. Die Erkenntnis folgte aus der Realisierung an der Ferti-gungszelle aus Kapitel 7. Diese Eingänge sind fester Bestandteil des Codegenerators undwerden daher in diesem Abschnitt vorgestellt. Die Schwierigkeit ist zu erkennen, welcherEingang in welche Kategorie einzuordnen ist. Die Flankendetektion wird verwendet, wenndas Signal eine Rückmeldung darstellt. Ein Schwenkarm wird bewegt, ein Berührungssen-sor bestätigt das Erreichen einer Endposition. Der Eingang wird als Sensor programmiert,wenn das Abfragen eines anstehenden Signals immer möglich sein soll. Eine Lichtschrankegibt zum Beispiel an, ob ein Lager noch ein Werkstück enthält.

Die Implementierung der Kategorie Strecke ist ein sehr spezieller Fall. Es kann helfen, wennein Signal zwar ansteht, aber im Supervisor nur eine Änderung stattfinden soll, wenn auchdie Strecke dies ermöglicht. Die Strecke setzt dann ein Ereignis, dass zu einer dritten GruppeMx.2 gehört. Die Problembehandlung wird durch die starke Verzahnung von Strecke undSupervisor notwendig. Eine bessere Lösung wäre möglicherweise, dies in der Modellierungzu berücksichtigen. Es kann jedoch schwierig sein, einen steuerbaren Supervisor daraus zugewinnen.

Der logische Unterschied zwischen den Signalen, die eine Rückmeldung geben und denanstehenden Signalen, wurde in der Literatur noch nicht berücksichtigt. Es ist ein Thema, das


Kategorie Beschreibung Programmierung

FlankeBei einer positiven Flanke desEinganges wird das Ereignisfür einen Zyklus gesetzt

"R_TRIG"(CLK:="E_Eingang",Q=>"E_Ereignis_0");

SensorEingang und Ereignis werdengleich gesetzt

"ES_Ereignis_0":="E_Eingang";

Strecke

Eingang und Ereignis werdengleich gesetzt, es wird im Su-pervisor jedoch erst gesetzt,nachdem dies ein Zustand-übergang in der Strecke be-wirkt hat

"EG_Ereignis_0":="E_Eingang";

Merker

Bei einer positiven Flankewird das Auftreten des Ein-ganges gespeichert und bleibtsolange aktiv, bis es im Su-pervisor zurück gesetzt wird

"R_TRIG"(CLK:="E_Eingang",Q=>"EM_Ereignis_help");IF "EM_Ereignis_help" THEN"EM_Ereignis_0":=1;END_IF;

Tabelle 6.7.: Eingangskategorien

für zukünftige Realisierungen an realen Anlagen mit dem lokal-modularen Ansatz diskutiertwerden sollte.

Das Problem kann auch anders betrachtet werden. Eine Rückmeldung tritt auf, kann jedochnicht ausgewertet werden, weil der Generator noch mit einer anderen Aktivität beschäftigt ist.Er ist in einem Zustand, indem das Ereignis nicht ausgewertet werden kann. Das Ereignisgeht verloren. Manchmal kann es aufwendig sein eine Anlage exakt abzustimmen. Soll einemöglichst schnelle Abarbeitung erreicht werden, müssen Komponenten parallel arbeiten. AlsLösung wurde das Merker-Ereignis eingeführt. Tritt eine positive Flanke am Eingang auf, wirddiese registriert, aber erst zu einem späteren Zeitpunkt von der Steuerung verarbeitet. Wurdedas Ereignis verwendet, muss es vom Supervisor zurückgesetzt werden.

Welches Ereignis in welche Kategorie einzuordnen ist, hängt von Anwendung und Modellie-rung ab. In manchen Fällen sind auch mehrere Kategorien möglich.


Zeitabhängige Ausgänge

Ein Ziel einer Automatisierung ist es, einen möglichst hohen Automatisierungsgrad zu er-reichen. Der zeitabhängige Ausgang, also ein Ausgang, der für eine bestimmte Zeit gesetztwird, ist eine typische Anforderung einer Fertigungszelle. Die Realisierung entspricht derIdee aus Kapitel 3.3.1 mit der Anwendung von Selfloops, nur dass das Verlassen des Zu-standes mit einer selbst erzeugten Rückmeldung initiiert wird. Die Abbildung 6.3 zeigt einen

1 2

STR_Start

E_ProzessA_Prozess

T_1S_Prozess

Abbildung 6.3.: Generator mit zeitabhängigem Ausgang

Generator, indem ein Prozess gestartet wird. Daraufhin soll der Ausgang für eine Sekun-de gesetzt werden. Das Ereignis T_1S_Prozess symbolisiert die Zeitangabe. Die Wartezeitwird mittels Timers realisiert. Solange der Zustand 2 aktiv ist, wird der Timer aufgerufen undder Ausgang A_Prozess ist gesetzt. Nach einer Sekunde erzeugt der Timer eine Rückmel-dung, dies ist das Ereignis E_Prozess. Die drei mit Prozess benannten Ereignisse bildeneine Gruppe, die durch denselben Ereignisnamen gekennzeichnet ist. Indirekt sollte auchdas steuerbare Ereignis STR_Start dazu gezählt werden, welches den Vorgang auslöst.Dies muss jedoch nicht denselben Namen tragen. Zwingend müssen nur die Ereignisnamenvom Timer und von der Rückmeldung gleich sein, um eine funktionsfähige automatische Co-degenerierung zu erhalten. Der Programmcode des Generators aus Abbildung 6.3 lautet inSCL:

IF "Zustand2" AND "E_Prozess" THEN"Zustand1":=1 "Zustand2":=0

END_IF;

IF "Zustand1" AND "STR_Start" THEN"Zustand2":=1 "Zustand1":=0

END_IF;

"STR_Start":="Zustand1";"A_Prozess":="Zustand2";"Timer_Prozess".TON(IN:="Zustand2",PT:=T#1S,Q=>"E_Prozess");


6.4.2. Benutzerfunktionen

Die Abbildung 6.4 zeigt einen Screenshot von ACArrow mit dem geöffneten Hauptmenü desCodegenerators für Automaten. Hier ist ersichtlich, dass für den Codegenerator englischeBeschreibungen verwendet werden. In dieser Arbeit werden die Begriffe jedoch in Deutschangegeben. Das Benutzermenü enthält fünf Reiter: Codegenerator, Datenbank, Option, Aus-wahl und Hilfe.

Abbildung 6.4.: Screenshot von ACArrow, Hauptmenü Automaten

Die Funktionen im Reiter Codegenerator sind: DESTool Projekt einlesen, Adjazenzmatrixerstellen, sowie den modularen und lokal-modularen Quellcode erzeugen. Diese Funktio-nen wurden bereits in Kapitel 6.1 vorgestellt. Durch das Setzen von Häkchen, kann eineAuswahl zwischen den Programmiersprachen AWL und ST/SCL getroffen werden. Für denlokal-modularen Ansatz kann die IEC oder Siemens Syntax ausgewählt werden.

Im Reiter Datenbank kann sich der Benutzer den Inhalt der temporären Datenbank in Tabel-


len anzeigen lassen. Für die Entwicklung ist diese Ansicht wichtig, da so verifiziert werdenkann, dass der Inhalt in der Datenbank korrekt eingelesen wurde.

In den Optionen kann der Benutzer die Startadresse für die Merker bestimmen. Die Adres-sen stellen die Variablen in der Siemens Syntax dar. Außerdem können die Anfangsbuchsta-ben für die Ereignisse geändert werden. Ein A_ steht zum Beispiel für einen Ausgang, wel-cher in Kapitel 6.2 vorgestellt wurde. In englischer Sprache würde ein Benutzer möglicher-weise lieber die englische Bezeichnung Output mit einem O_ oder einem Out_ verwenden.Die Änderungen werden in dieser ACArrow Version jedoch nicht dauerhaft gespeichert.

Der Reiter Auswahl ist für das Auswahlproblem, welches in Kapitel 3.2 definiert wurde, zu-ständig. Hier werden nach dem Einlesen des DESTool Projekts alle möglichen Zustände miteinem Auswahlproblem angezeigt. Wegen der hohen Komplexität einer Fertigungszelle, wiein Kapitel 7, muss der Benutzer die letzte Entscheidung treffen, ob ein Auswahlproblem vor-liegt und ob das Problem mit einer zufälligen Auswahl gelöst werden soll. Liegt ein Zustandmit einem Auswahlproblem vor, das nicht mit eine Häkchen versehen wird, findet automatischeine priorisierte Auswahl statt.

Einige Informationen über den Codegenerator für Automaten und über Einstellungen bezüg-lich dem DESTool Projekt werden unter Hilfe gegeben.

6.4.3. Programmfunktionen

Die hier betrachteten Funktionen beziehen sich ausschließlich auf die Codegenerierung mitdem lokal-modularen Entwurfsansatz. Die zehn Funktionen, die wiederum die zehn SPS-Funktionen aus DECON9 generieren, sind aus Kapitel 3.3.2 bekannt. Zusätzlich wird nocheine weiteren Funktion benötigt, die den Lawineneffekt der steuerbaren Ereignisse verhin-dert. Es wird davon ausgegangen, dass dieser Effekt nur im Supervisor und nicht in derStrecke vorkommt. Diese Funktionen werden hier nicht noch einmal aufgeführt. Das Beispielin nächsten Kapitel zeigt jedoch die komplette Codegenerierung.

Außerdem wird eine Funktion Main erzeugt, die eine SPS-Funktion darstellt, mit dem der Auf-ruf der einzelnen Funktionen geregelt wird. Für die Codegenerierung werden in zwei Funk-tionen zusätzlich Variablenlisten erzeugt. Das ermöglicht dem Benutzer, Variablen schnell indie SPS zu importieren und er muss lediglich Adressen für die Ein- und Ausgänge ange-ben.

Neben den wichtigen Funktionen zur Codegenerierung bilden die vier Funktionen aus Ta-belle 6.8 die Hauptfunktionen. Die Funktion Database_input() übernimmt das Einlesen derDESTool-Datei. In Kapitel 6.3 wurde das Verfahren bereits erläutert. Mithilfe von Abfragenwird der Inhalt der DESTool Projektdatei in der Datenbank gespeichert.



Database_input Einlesen der DESTool ProjektdateifindChoice Finden der Zustände, bei denen ein Auswahlproblem vor-

liegtDESToolProjekt_input_Click Auswahl der DESTool-Datei, Aufruf von Database_input

und findChoiceCreateLokalModular_Click Aufruf der Funktionen, die die DECON9-Funktionen für

die Codegenerierung erstellen

Tabelle 6.8.: Programmfunktionen

Mit findChoice() werden die Zustände mit einem Auswahlproblem identifiziert, also Zuständevon denen zwei oder mehr steuerbare Ereignisse abgehen. Zudem wird geprüft, ob dieseEreignisse in der Strecke gleichzeitig möglich sind. Das ist immer dann der Fall, wenn dieEreignisse nicht aus demselben Generator stammen und wenn im Generator ein Zustandvorhanden ist, von dem diese Ereignisse abgehen. Die Abbildung 6.5 zeigt ein vereinfach-tes Flussdiagramm der Funktion. Häufig werden für die einzelnen Unterpunkte SQL-Befehlegenutzt.

Abbildung 6.5.: Flussdiagramm der Funktion findChoice()


Es wird deutlich, dass die Aufgabe zwar für einen Menschen leicht zu lösen ist, in der Pro-grammierung kann dies jedoch eine aufwendige Abfrage bedeuten. Als Erweiterung könntenoch abgefragt werden, ob andere Supervisor dieses Auswahlproblem verhindern. In diesemProgramm bleibt jedoch die Entscheidung beim Benutzer, der diese mit seinen Kenntnissenüber die Anlage leicht treffen kann.

Die beiden Funktionen Database_input() und findChoice() werden von der Funktion DES-ToolProjekt_input_Click(object sender, EventArgs e) aufgerufen. Durch einen Klick auf einenzugehörigen Button kann der Benutzer zunächst das DESTool Projekt in einem OpenFileDia-log auswählen. Danach werden die Funktionen Database_input() und findChoice() aufgeru-fen. Nach dem Aufruf wechselt die Benutzeroberfläche automatisch zu dem Reiter Auswahl,damit der Benutzer seine Wahl betätigen kann. Dies ist ein Beispiel dafür, dass bei der Er-stellung des Programms auch auf Benutzerfreundlichkeit geachtet wurde.

Die Funktion CreateLokalModular_Click(object sender, EventArgs e) wird ebenfalls durchdas Klicken des Benutzer auf den zugehörigen Button aufgerufen. Diese ruft je nach Auswahlder Programmiersprache und Syntax die Funktionen nacheinander auf, die letztendlich denSPS-Programmcode in Ausgabedateien erstellen. Die Ausgabedateien werden in Kapitel 6.6beschrieben.

6.4.4. Codegenerierungsbeispiel für den lokal-modularen Ansatz

Das hier vorgestellte Beispiel wird unter anderem in [21] mit der DECON9 Methodik ver-wendet. Da der DECON9 Ansatz das Kernstück von dieser Codegenerierung darstellt, wirdeine gute Vergleichsmöglichkeit geschaffen. Das Beispiel wurde auch gewählt, da sich dar-aus einfache Generatoren ergeben, es leicht zu verstehen ist und es einige der Problemeaufweist, die bei der Codegenerierung auftreten. Es ist durchaus vorstellbar, dass diesesBeispiel ein Teil einer größeren Fertigungsanlage darstellt.

Abbildung 6.6.: Fertigungsline

Die Abbildung 6.6 zeigt die Systemkomponenten der Fertigungsline. Es sind sechs Maschi-nen Mx mit x=1...6 und vier Puffer (engl. buffer) By mit y=1...4. Die Puffer haben die Kapazität,ein Werkstück aufzunehmen. Für die Maschinen M1 und M3 wird davon ausgegangen, dass


immer ein Werkstück am Eingang zur Verfügung steht und M6 kann unbegrenzt Werkstückeausgeben. Diese Maschinenformation könnte beispielsweise eine Komponentenmischungdarstellen, jede Maschine gibt eine Zutat dazu. Das könnte eine Kuchen- oder Gewürzmi-schung sein. Solche Anwendungen kommen in der Industrie häufig vor. Das Beispiel wird soerweitert, dass jede Maschine nur fünf Sekunden arbeitet. Somit können auch zeitabhängigeAusgänge integriert werden. Den Generator einer Maschine zeigt Abbildung 6.7. Dieser ist

1 2

STR_Start_x

E_Fertig_xA_Arbeit_x

T_5S_Fertig_x

Abbildung 6.7.: Generator Gx der Maschinen mit x=1...6

einfach aufgebaut. Ein steuerbares Signal STR_Start_x startet die Maschine, dann arbei-tet die Maschine fünf Sekunden lang, indem ein Ausgang A_Arbeit_x gesetzte wird. Für einbesseres Verständnis wird das Ausgangssignal anders benannt als das Ereignis für die ZeitT_5S_Fertig_x und das daraufhin gesetzte Ereignis E_Fertig_x, welches anzeigt, dass dieMaschine die Arbeit beendet hat. In diesem Fall ist das nicht steuerbare Ereignis E_Fertig_xalso ein internes Signal. In der Modellierung macht das jedoch keinen Unterschied. Damitsind die Streckenmodelle bereits aufgestellt, welche auch das feinste Produktsystem bilden.Die Puffer werden durch die Spezifikationen modelliert. Diese verhindern einen Über- oderUnterlauf der Puffer. Durch die Spezifikationen werden die Generatoren verbunden und es

1 2

E_Fertig_x

STR_Fertig_x+1

1 2

E_Fertig_4

E_Fertig_2

STR_Fertig_5

Abbildung 6.8.: Spezifikationen Ky (a) der Puffer 1, 2 und 4 mit x=1,3,5 und (b) Puffer 3

ergeben sich folgende lokale System mit der Parallelen Komposition:GX1 = G1||G2, GX2 = G3||G4, GX3 = G3||G4||G5 und GX4 = G5||G6.

Die angepassten Spezifikationen lauten:EX1 = GX1||K1, EX2 = GX2||K2, EX3 = GX3||K3 und EX4 = GX4||K4.

Diese Generatoren werden alle in DESTool erstellt. Nun kann die Synthese ausge-führt werden. Es werden die supremalen steuerbaren nichtblockierenden Teilsprachen


SupConNB(EXy||GXy) für y = 1...4 berechnet. Das Ergebnis sind vier Supervisor. DieSupervisor werden gegeneinander mit der DESTool-Funktion IsNonblocking auf lokale Mo-dularität getestet. Die lokale Modularität wird beispielsweise für die Supervisor S1 und S2folgendermaßen berechnet: Lm(S1)||Lm(S2) = Lm(S1)||Lm(S2). Für alle möglichen Kom-binationen der Supervisor bestätigt DESTool die lokale Modularität.

SupReduce ist eine DESTool Funktion, die Supervisor nach dem Algorithmus von [49] re-duziert, sodass die Supervisor aus möglichst wenigen Zuständen bestehen. Die folgendenreduzierten Supervisor entstehen bei der Synthese: Der Supervisor S1 ist der Generator auf

1 2

E_Fertig_z

STR_Start_zSTR_Fertig_z+1

1 2

3

STR_Start_2STR_Start_4

E_Fertig_2E_Fertig_4

STR_Start_5

Abbildung 6.9.: Reduzierte lokal-modulare Supervisor mit z=1,3,5

der linken Seite der Abbildung 6.9, wenn z=1 ist. Für den Supervisor S2 ist z=3 und für S4 istz=5. Der Supervisor auf der rechten Seite ist S3.

Nun werden die sechs Maschinen (das Produktsystem) in DESTool als Steckenmodell unddie vier reduzierten Supervisor als Supervisormodell gekennzeichnet. Wird die Projektdateimit ACArrow eingelesen, werden im ersten Schritt die Zustände angezeigt, die ein mögli-ches Auswahlproblem haben. In diesem Fall besteht ein Auswahlproblem in Zustand 1 desSupervisors S3. Im Programm wird dieser als S3_Z1 bezeichnet. Die Analyse der Abbildung6.9 zeigt, dass tatsächlich ein Auswahlproblem an Puffer B3 zwischen STR_Start_2 undSTR_Start_4 besteht. Aufgrund dessen wird ein Häkchen in ACArrow bei S3_Z1 gesetzt.

Die Optionen von ACArrow werden nicht verändert und im Reiter Codegenerator wird fürden lokal-modularen Ansatz die Siemens Syntax und die SPS-Programmiersprache SCLausgewählt. Nach dem Betätigen des Buttons für die Codegenerierung des lokal-modularenEntwurfs werden die Dateien mit dem Programmcode angezeigt. Auf das Format dieser Da-teien wird in Kapitel 6.6 näher eingegangen. Zuerst wird der Code für die Hauptfunktion inSCL dargestellt:


//Main_SCTIF NOT "InitBit_SCT" THEN

"Init_SCT"();"InitBit_SCT":=1;

ELSE"Read_Input_SCT"();"Load_2_Memory_UC_Events_SCT"();"UC_Events_Plant_SCT"();"UC_Events_Super_SCT"();"C_Events_Enable_SCT"();"Choice_SCT"();"C_Events_Plant_SCT"();///////Space for interfaces

"C_Events_Super_SCT"();"Write_Output_SCT"();

END_IF;

In der Hauptfunktion werden die Unterfunktionen des Codegenerierungsverfahrens aufge-rufen. Die Funktionen entsprechen den Funktionen der DECON9 Methodik aus Abbildung3.3. Die Anpassungen des Verfahrens werden erst innerhalb der Unterfunktionen sichtbar.Die Hauptfunktion wird ebenfalls automatisch generiert, sodass der Anwender möglichst we-nig zusätzlich programmieren muss. Der Kommentar //Space for interfaces zeigt den geeig-neten Ort für Schnittstellen (engl. interfaces) an. Manche Komponenten benötigen einenProgrammcode, in der zum Beispiel Einstellungen vorgenommen werden müssen oder einbestimmter Funktionsaufruf benötigt wird. Dieser kann nicht automatisch generiert werden.Über die Ereignisse kann die Schnittstelle mit dem automatisch generierten Code verknüpftwerden. Die Schnittstelle selbst ist auch wieder eine Unterfunktion. In diesem theoretischgehaltenen Beispiel wird keine Schnittstelle benötigt. Auf der nächsten Seite wird der SCL-Code für die Unterfunktionen gezeigt.


//Init_SCT"G1_Z1":=1;

..."S4_Z1":=1;//Read_Input_SCT"R_TRIG_DB_0"(CLK:="E_Fertig_1",Q=>"E_Fertig_1_0");

..."R_TRIG_DB_5"(CLK:="E_Fertig_6",Q=>"E_Fertig_6_0");

IF NOT "InitInput_SCT" THEN"InitInput_SCT":=1;"E_Fertig_1_0":=0;

..."E_Fertig_6_0":=0;

END_IF;//Load_2_Memory_UC_Events_SCT"E_Fertig_1_1":="E_Fertig_1_0";

..."E_Fertig_6_1":="E_Fertig_6_0";//UC_Events_Plant_SCTIF "G1_Z2" AND "E_Fertig_1_1" THEN

"G1_Z1":=1; "G1_Z2":=0;"E_Fertig_1_1":=0;

END_IF;...

IF "G6_Z2" AND "E_Fertig_6_1" THEN"G6_Z1":=1; "G6_Z2":=0;"E_Fertig_6_1":=0;

END_IF;//UC_Events_Super_SCTLoad_2_Memory_UC_Events_SCT();IF "S1_Z1" AND "E_Fertig_1_1" THEN

"S1_Z2":=1; "S1_Z1":=0;"E_Fertig_1_1":=0;

END_IF;...

Load_2_Memory_UC_Events_SCT();IF "S4_Z1" AND "E_Fertig_5_1" THEN

"S4_Z2":=1; "S4_Z1":=0;"E_Fertig_5_1":=0;

END_IF;

//C_Events_Enable_SCT"STR_Start_1_0":="S1_Z1";"STR_Start_2_0":="S1_Z2" AND "S3_Z1";

..."STR_Start_6_0":="S4_Z2";//Choice_SCT (* siehe nächste Seite)//C_Events_Plant_SCTIF "G1_Z1" AND "STR_Start_1_0" THEN

"G1_Z2":=1; "G1_Z1":=0;"STR_Start_1":=1;

END_IF;...

IF "G6_Z1" AND "STR_Start_6_0" THEN"G6_Z2":=1; "G6_Z1":=0;"STR_Start_6":=1;

END_IF;//C_Events_Super_SCT"Load_2_Memory_C_Events_SCT"();IF "S1_Z2" AND "STR_Start_2_1" THEN

"S1_Z1":=1; "S1_Z2":=0;"STR_Start_2_1":=0;

END_IF;...

"Load_2_Memory_C_Events_SCT"();IF "S4_Z2" AND "STR_Start_6_1" THEN

"S4_Z1":=1; "S4_Z2":=0;"STR_Start_6_1":=0;

END_IF;

"STR_Start_1":=0;...

"STR_Start_6":=0;//Write_Output_SCT"A_Arbeit_1":="G1_Z2";

..."A_Arbeit_6":="G6_Z2";"Timer_DB_0".TON(IN:="G1_Z2",PT:=T#5S, Q=>"E_Fertig_1");

..."Timer_DB_5".TON(IN:="G6_Z2",PT:=T#5S, Q=>"E_Fertig_6");


(*) //Choice_SCTIF "AUX_0_SCT" = 1 THEN

"AUX_0_SCT":=0;ELSE

"AUX_0_SCT":="AUX_0_SCT" + 1;END_IF;

IF "S3_Z1" AND "STR_Start_2_0" AND "STR_Start_4_0" THENIF "AUX_0_SCT"=0 THEN

"STR_Start_2_0":=1; ELSE "STR_Start_2_0":=0; END_IF;IF "AUX_0_SCT"=1 THEN

"STR_Start_4_0":=1; ELSE "STR_Start_4_0":=0; END_IF;END_IF;

Die Funktion Load_2_Memory_C_Events_SCT lautet in SCT für das Beispiel:

//Load_2_Memory_C_Events_SCT"STR_Start_1_1":="STR_Start_1";

..."STR_Start_6_1":="STR_Start_6";

Änderungen zur DECON9 Methodik

In Kapitel 4.2 wurden die wichtigsten Anforderungen bezüglich notwendiger und zusätzlicherÄnderungen der DECON9 Methodik beschrieben. In diesem Abschnitt wird zusammenfas-send auf die Änderungen verwiesen oder es werden noch nicht diskutierte Inhalte vorge-stellt.

Wie verschiedene Eingangssignale eingelesen werden, zeigt Kapitel 6.4.1 ausführlich. InKapitel 3.3.1 wird die Codegenerierung für Ausgänge mit Selfloops definiert. Kapitel 6.4.1beschreibt, wie zeitabhängige Ausgänge eingebunden werden. Im Codierungsbeispiel fürden lokal-modularen Ansatz werden diese auch angewendet.

Es werden einzelne Unterfunktionen auf Besonderheiten analysiert:

• Beim Einlesen der Eingänge Read_Input_SCT ist eine zusätzliche Abfrage eingear-beitet worden. Diese wird nur beim ersten Aufruf der Funktion aktiv und löscht alledetektierten Flanken wieder. Das ist notwendig, da beim ersten Aufruf für alle Eingän-ge, die gesetzt sind automatisch eine Flanke detektiert wird. Diese Flanken stellenjedoch keine Rückmeldung dar, denn die gerade eingeschaltete Anlage hatte nochkeine Möglichkeit, in Bewegung zu geraten und Rückmeldungen zu erzeugen. Diese


Flanken können jedoch nicht erwünschte Zustandsübergänge erzeugen und müssendaher im ersten Durchgang ignoriert werden.

• Eine kleine formale Änderung zeigt unter anderem Load_2_Memory_UC_Events_SCT.Die Gruppen Mx.0 und Mx.1 werden nicht mit einem Punkt, sondern einem Unterstrichgekennzeichnet.

• In der Funktion C_Events_Enable_SCT werden die steuerbaren Ereignisse vom Su-pervisor erlaubt. Zustände aus verschiedenen Supervisorn werden mit einer Konjuk-tion verbunden. Zustände aus demselben Supervisor müssen in Klammern mit einerDisjunktion verbunden werden.

• Die Funktion Choice_SCT wurde zur original DECON9 Funktion leicht erweitert. Sokönnen nicht nur zwei, sondern beliebig viele steuerbare Ereignissen ausgewählt wer-den. Wichtig dabei ist, dass die gesamte Menge der von einem Ereignis abgehendensteuerbaren Ereignisse einbezogen werden muss. Die Auswahl ist zufällig.

• Der Lawineneffekt für steuerbare Ereignisse wird nur im Supervisor verhindert, dadie Strecke für dieses Beispiel so modelliert werden konnte, dass kein Lawinenef-fekt auftritt. Die Bearbeitung der steuerbaren Ereignisse ist folgendermaßen realisiert:Wurde das Ereignis vom lokal-modularen Supervisor erlaubt und eine mögliche Aus-wahl für Mx_0 getroffen, dann bewirkt dieses, wenn möglich, einen Zustandsüber-gang in der Strecke. Das verwendete steuerbare Ereignis Mx wird beim Übergang ge-setzt, sodass es zum einen für Schnittstellen verwendet werden kann und zum ande-ren, damit im Supervisor deutlich wird, welche steuerbaren Ereignisse wirklich einge-setzt wurden. Im Supervisor wird mit der Funktion Load_2_Memory_C_Events_SCTMx_1:=Mx gesetzt, um so den Lawineneffekt zu verhindern. Am Ende der FunktionC_Events_Super_SCT müssen die steuerbaren Ereignisse Mx zurückgesetzt werden.

6.5. Codegenerierung für Petrinetze

In diesem Kapitel wird die Codegenerierung für den Entwurf mit S-Invarianten genau be-trachtet. Ein Beispiel zeigt die Umsetzung, ausgehend von der Modellierung, dann folgt dieSynthese und am Ende wird der in ACArrow generierte SPS-Code dargestellt. Zunächstwerden wichtige Inhalte bezüglich ACArrow analysiert.

6.5.1. Ein- und Ausgänge

Im Kapitel 6.4.1 wurden bezüglich Automaten einige Spezialisierungen vorgestellt. Im Fallder Petrinetze ist die Gestaltung einfacher.


Für Ausgänge muss keine zusätzliche Zeitabhängigkeit eingeführt werden, da im SIPN be-reits zeitabhängige Transitionen eingeführt worden sind. Es sind keine weiteren Spezialisie-rungen notwendig.

Bei Petrinetzen sind für das Einlesen von Eingängen nur zwei Möglichkeiten vorhanden.Nach Tabelle 6.6 wäre das einmal die Flankendetektion als Rückmeldung oder der Sensor füranstehende Signale. Da für die Fertigungszelle in Kapitel 7 dieselben Eingänge wie für denAnsatz mit Automaten verwendet werden, müssen die Eingangskategorien Strecke (EG_)und Merker (EM_) als Sensor (ES_) interpretiert werden.

6.5.2. Benutzerfunktionen

Wie auch für das Hauptmenü Automaten sind auch im Hauptmenü Petrinetze einigeBenutzerfunktionen auswählbar. Die fünf Reiter sind: Codegenerator, Datenbank, Bedingun-gen, Optionen und Hilfe.

Abbildung 6.10.: Screenshot von ACArrow, Hauptmenü Petrinetze

Die Abbildung 6.10 zeigt einen Screenshot. Im Reiter Codegenerator kann eine MATLAB-Datei eingelesen werden und der SIPN Quellcode erzeugt werden. Durch Setzen von Häk-chen kann eine Auswahl zwischen den Programmiersprachen AWL und ST/SCL getroffenwerden. Die Syntax, IEC oder Siemens, ist ebenfalls auswählbar. Die Codegenerierung mitSIPN wurde bereits in Kapitel 3.3.3 vorgestellt.


Der Reiter Datenbank ermöglicht, wie auch für Automaten, einen Einblick in die temporäreDatenbank.

Über den Reiter Bedingungen werden die für SIPN notwendigen Bedingungen und Anwei-sungen eingegeben. Dies wird im nächsten Abschnitt genau beschrieben.

Der Benutzer kann im Reiter Optionen lediglich die Startadresse für die Merker ändern. DieAnfangsbuchstaben (wie A_), die die Ereignisse beschreiben, werden dargestellt, könnenjedoch nicht geändert werden.

Einige Informationen über den Codegenerator und über den Reiter Bedingungen werdenunter Hilfe gegeben.

SIPN Bedingungen und Anweisungen

Im Reiter Bedingungen der Benutzerfunktionen ist, nachdem eine MATLAB-Datei eingelesenwurde, eine Tabelle angegeben. Diese zeigt beispielhaft Tabelle 6.10.

Netz Objekt Bedingung Anweisung

N1 T0 TIMER 2S "Zaehler":="Zaehler"+1N1 P1 X A_1,A_2

Tabelle 6.9.: Tabelle im Reiter Bedingungen

Für alle eingelesenen Petrinetze werden zunächst die Transitionen angegeben. Die Spal-ten Bedingung und Anweisung können zur Beschreibung des SIPN verwendet werden. DieEingabe muss der Syntax und Programmiersprache des späteren SPS-Code entsprechen.Für eine zeitabhängige Transition wird das Schlüsselwort TIMER verwendet. Die Zeitangabewird nach dem Schlüsselwort eingetragen, zum Beispiel TIMER 2S (S für Sekunden). Dannfolgen die Stellen für alle eingelesenen Netze. Das X in Spalte Bedingung symbolisiert, dassnur eine Eingabe bei Anweisung erfolgen darf. Hier werden die Ausgänge verknüpft, ohneweitere Anforderungen an die Syntax. Die Ausgänge A_1 und A_2 können direkt eingetra-gen werden. Für mehrere Angaben bezüglich eines Objektes können diese Angaben durchein Komma getrennt eingegeben werden.

Wurden alle Daten in die Tabelle eingetragen, kann diese über den Button Speichern alsExcel-Tabelle gespeichert werden. Mit Laden kann die Tabelle wieder eingelesen werden.Das vereinfacht das Verfahren, falls Änderungen auftreten. Änderungen können außerdemdirekt in der Datei durchgeführt werden, sofern das Format dadurch nicht verändert wird.Ein wichtiger Schnitt ist es, mit dem Button Transferiere nach SQL die Daten in die SQLDatenbank zu transferieren, sodass diese für die Codegenerierung abrufbar sind.


6.5.3. Programmfunktionen

Der SIPN Progammcode wird in vier Unterfunktionen, einer Main Funktion zum Aufruf dieserFunktionen und zwei Funktionen, die Variablenlisten erstellen, realisiert. Im Gegensatz zurDECON9 Methodik werden beim SIPN keine Funktionen vorgegeben. Für einen organisier-ten Aufruf zeigt Abbildung 6.11 die entwickelten Unterfunktionen für SIPN.

Abbildung 6.11.: SIPN - Flussdiagramm des Hauptprogramms

Neben den Funktionen zur Codegenerierung werden die Hauptfunktionen aus Tabelle 6.10in ACArrow verwendet. Die Funktion Database_Petri_input() liest das MATLAB Protokoll ein,


Database_Petri_input Einlesen des MATLAB Protokollssave_Click, load_Click,transfer_Click

Funktionen für die Organisation der SIPN Bedingun-gen

CreateSIPN_Click Aufruf der Funktionen, die den SPS-Code für SIPN ge-nerieren

Tabelle 6.10.: Programmfunktionen

welches in Kapitel 6.3 bereits vorgestellt wurde. Der Inhalt der Datei wird mithilfe von Ab-frage sortiert in die Datenbank abgelegt. Diese Funktion wird von Matlab_Input_Click(objectsender, EventArgs e) aufgerufen.

Die Funktionen save_Click(object sender, EventArgs e), load_Click(object sender, EventArgse) und transfer_Click(object sender, EventArgs e) organisieren die Bedingungen fürs SIPN.Diese Funktionen wurden bereits kurz in Kapitel 6.5.2 vorgestellt.

Mit CreateSIPN_Click(object sender, EventArgs e) wird die automatische Codegenerierunggestartet. Je nach ausgewählter Programmiersprache und Syntax werden die entsprechen-den Funktionen aufgerufen. Diese erstellen die Ausgabedateien mit dem SPS-Code. DieseAusgabedateien werden in Kapitel 6.6 erläutert.


6.5.4. Codegenerierungsbeispiel für den Entwurf mit S-Invarianten

Das hier vorgestellte Beispiel wurde aus keiner Quelle entnommen. Es ist ein einfacheresBeispiel, da viele Details der Codegenerierung eines SIPN auch anhand eines kleinen Bei-spiels gezeigt werden können. Das Beispiel besteht aus einem Tank mit Füllstandssensoren,welche anzeigen, ob der Tank leer oder voll ist. Außerdem ist in dem Tank ein Rührgerät ein-gebaut. Das Rührgerät gibt eine Rückmeldung, wenn es eingeschaltet ist. Der Tank wird miteiner Flüssigkeit gefüllt, die mit einem Ventil V1 eingelassen werden kann. Ein Zähler wirdverwendet, um festzustellen, wie oft der Tank gefüllt wird. Ist der Tank gefüllt, soll das Rühr-gerät fünf Sekunden arbeiten. Danach wird die Flüssigkeit mit Ventil V2 wieder abgelassen.Dieser Tank könnte ein Teil einer größeren Anlage sein, die eine Mixtur herstellt, zum Bei-spiel für ein Medikament. Das Tanksystem ist in Abbildung 6.12 (a) dargestellt. Die Ein- und

Abbildung 6.12.: (a) Tanksystem (b) Petrinetz des Tanksystems

Ausgänge des Systems sind in Tabelle 6.11 aufgelistet. Mit diesen Ereignissen werden zweiPetrinetzmodelle entwickelt, ein Modell für den Tank und ein Modell für das Rührgerät. DiePetrinetze sind in Abbildung 6.12 (b) dargestellt. Zusätzlich ist bereits die Steuerstelle in blaueingezeichnet. Die roten Transitionen sind steuerbar, alle anderen nicht. Bei der Modellierungmüssen steuerbare Transitionen sinnvoll eingefügt werden. Ohne steuerbare Transition kannkeine Steuerung entwickelt werden. Transitionen, die eine Marke von einer Steuerstelle ab-ziehen, müssen immer steuerbar sein. Bei der Synthese mit der SPNBOX wird dies getestet,jedoch im Bezug auf nicht steuerbare Ereignisse. Es wird festgestellt, ob die Ungleichungzulässig bezüglich der nicht steuerbaren Ereignisse ist. Ist das nicht der Fall, zeigt die Funk-tion eine alternative Ungleichung an, jedoch kann dadurch häufig das gewünschte Verhalten


Typ Bezeichnung Beschreibung

Eingang ES_T_voll der Tank ist vollEingang ES_T_leer der Tank ist leerEingang E_R_an das Rührgerät ist eingeschaltetAusgang A_V1_auf Ventil V1 ist offenAusgang A_V2_auf Ventil V2 ist offenAusgang A_R_ein das Rührgerät arbeitet

Tabelle 6.11.: Ein- und Ausgänge des Tanksystems

nicht erreicht werden. Dann muss die Modellierung verändert werden. Selbiges gilt für dieÜberprüfung auf einen Deadlock. Sind die beiden Prüfungen positiv, kann die Ungleichungals erfüllt betrachtet werden.

Bei der Modellierung muss beim SIPN darauf geachtet werden, dass kein Lawineneffektentsteht. Diese Problematik bei der Modellierung zu erkennen, erfordert einige Erfahrungs-werte. Für eine zukünftige Programmierung sollte daher eine Blockierung der Petrinetze aufdas Schalten von nur einer Transition pro Zyklus in Betracht gezogen werden. Die Program-mierung für SIPN schreibt jedoch explizit vor, dass das Schalten von mehreren Transitionenerlaubt ist. Wäre die Bedingung E_T_an an Transition t2 nicht vorhanden, würde das Rühr-gerät nie eingeschaltet werden, da das Modell für den Tank die Marke der Steuerstelle durchden Lawineneffekt sofort wieder entziehen würde.

Die Spezifikation für die aufgestellten Petrinetze wird durch die folgende Ungleichung reprä-sentiert: µ1 + µ4 + µ6 ≤ 1Diese Ungleichung stellt sicher, dass das Rührgerät erst eingeschaltet werden kann, nach-dem der Tank vollständig gefüllt wurde.

Nun müssen die Petrinetze und die Ungleichung in MATLAB eingegeben werden, ebenso wiedie nicht steuerbaren Transitionen. Die Ungleichung ist nach der Analyse mit der SPNBOXzulässig und bewirkt keinen Deadlock. Das Ergebnis der Synthese zeigt Abbildung 6.12 (b).Die in blau abgebildete Steuerstelle wurde den Netzen hinzugefügt. In Anhang B wird dieMATLAB Datei zur Durchführung der Synthese und zur Erstellung des Protokolls gezeigt.

Das Protokoll wird in ACArrow eingelesen. Dem Benutzer wird nun der Reiter Bedingungenangezeigt. Hier müssen die Ein- und Ausgänge, sowie andere Bedingungen eingetragenwerden. Diese können wie in Abbildung 6.12 (b) zugeordnet werden. Die Art und Weise derZuordnung wurde bereits in Kapitel 6.5.2 beschrieben. Nach der Übertragung dieser Datenin die SQL-Datenbank, kann der SPS-Code generiert werden. Zuerst wird der Code für dieHauptfunktion in SCL dargestellt:


//Main_SIPN_SCTIF NOT "InitBit_SIPN_SCT" THEN

"Init_SIPN_SCT"();"InitBit_SIPN_SCT":=1;

ELSE"Read_Input_SIPN_SCT"();"Transitions_SIPN_SCT"();"Write_Output_SIPN_SCT"();//Space for interfaces

END_IF;

Die Funktionsaufrufe in der Hauptfunktion entsprechen dem Flussdiagramm aus Abbildung6.11. Wie auch bei Automaten kann es für Petrinetze notwendig sein, Schnittstellen auf-zurufen. Nach dem Kommentar //Space for interfaces können die Schnittstellen eingefügtwerden. In diesem theoretischen Beispiel wird keine Schnittstelle benötigt.

Die Unterfunktionen wurden nach SIPN, wie in Kapitel 3.3.3 vorgestellt, programmiert. Ein-zig das Einlesen der Eingänge wurde hinzugefügt, sodass auch Flanken detektiert werden.Wie das Einlesen der Eingänge in SIPN durchgeführt wird, ist nicht spezifiziert. Der EingangE_R_an, die Rückmeldung von dem Rührgerät, wird als Flanke realisiert. Die anderen zweiEingänge sind als anstehende Signale, also als Sensoren (ES_), realisiert. Die Unterfunktio-nen zu diesem Tanksystem werden auf der nächsten Seite in SCL dargestellt.


//Init_SIPN_SCT"P1":=1;"P5":=1;//Read_Input_SIPN_SCT"ES_T_voll_0":="ES_T_voll";"R_TRIG_DB_100"(CLK:="E_R_an",Q=>"E_R_an_0");"ES_T_leer_0":="ES_T_leer";

IF NOT "InitInput_SIPN_SCT" THEN"InitInput_SIPN_SCT":=1;"E_R_an_0":=0;

END_IF;//Transitions_SIPN_SCT////T0////IF "P1" AND NOT "P2" AND NOT "C1" AND "ES_T_voll_0" THEN

"P1":=0; "P2":=1; "C1":=1;"Z_Anzahl":="Z_Anzahl"+1;

END_IF;////T1////IF "P2" AND NOT "P3" AND "E_R_an_0" THEN

"P2":=0; "P3":=1;END_IF;////T2////IF "P3" AND "C1" AND NOT "P4" THEN"P3":=0; "C1":=0; "P4":=1;END_IF;////T3////IF "P4" AND NOT "P1"AND "ES_T_leer_0" THEN

"P4":=0; "P1":=1;END_IF;////T4////IF "P5" AND "C1" AND NOT "P6" THEN

"P5":=0; "C1":=0; "P6":=1;END_IF;////T5////"Timer_DB_21".TON(IN:="P6" AND NOT "P5" AND NOT "C1",PT:=T#5S,Q=>"TIMER21");IF "TIMER21" THEN

"P6":=0; "P5":=1; "C1":=1;END_IF;//Write_Output_SIPN_SCT"A_R_an":="P6";"A_V1_auf":="P1";"A_V2_auf":="P4";


6.6. Ausgabedateien

Der von ACArrow generierte SPS-Code wird in Dateien geschrieben. Die Syntax bestimmtauch das Format der Dateien.

Siemens Syntax: Dateien für die Siemens Syntax werden mit der Endung *.awl für Dateien,die in der Programmiersprache AWL programmiert sind und *.scl für Dateien, die in der Pro-grammiersprache SCL programmiert sind, erstellt. Diese Dateien können im Siemens TIAPortal als Quelle importiert werden. Das ist besonders benutzerfreundlich. Zusätzlich zumreinen Quellcode muss die ganze Funktion deklariert werden, das heißt ein Funktionskopfmuss in diesen Dateien zu finden sein. Werden Standardfunktionen, wie zum Beispiel einTimer verwendet, müssen Datenbausteine für diese erstellt werden. Siemens verwendet Da-tenbausteine statt Instanzen, das Konzept ist jedoch das Gleiche. Prinzipiell könnten auchalle Funktionen in eine Datei geschrieben werden. In dieser Version von ACArrow wird jedochfür jede Funktion eine eigene Datei erzeugt. Dies dient einer besseren Übersichtlichkeit. DerBenutzer muss nach dem Einlesen nur noch die Hauptfunktion der Codegenerierung im OB1(Siemens Anwenderprogramm) aufrufen und die Steuerung kann eingesetzt werden.

Neben den SPS-Funktionen werden auch zwei Excel-Dateien (*.xlsx) generiert. Diese ent-halten alle Variablen, die für den Programmcode benötigt werden. Das Siemens TIA Portalbietet auch hier die Möglichkeit, diese Variablen zu importieren. Anschließend muss der Be-nutzer nur noch die Ein- und Ausgänge mit der richtigen Adresse verknüpfen.

IEC 61131-3 Syntax: Diese Syntax wird von verschiedenen SPS-Herstellern verwendet. Da-her wird kein spezialisiertes Dateiformat erstellt, sondern der Code wird in eine Textdatei(*.txt) geschrieben. Der Benutzer kann diesen Text kopieren und in das SPS-Programm ein-fügen. Auch hier wird der Funktionskopf angegeben. Werden Instanzen von Standardfunk-tionen benötigt, wird vorgeschlagen, diese als globale Variablen zu deklarieren. Die „copyand paste“-Vorgänge bedeuten für den Benutzer zusätzliche Arbeitsschritte, jedoch kannder Code für alle SPS mit der entsprechenden Syntax verwendet werden.

Auch für diese Syntax werden die Variablen angegeben. Die Variablen werden in einer Text-datei zusammengefasst. Statt Merkerbits, für die sogar immer eine Adresse genannt werdenmuss, reicht hier der Typ aus. Also: Variable:=BOOL;. Wieder wird der „copy and paste“-Vorgang angewendet.

Für beide Syntaxen wird in Anhang A ein Beispiel gezeigt.

7. Anwendungsbeispiel: Fertigungszelle

Die Fertigungzelle wurde in [53] von Urland bereits mit dem modularen Ansatz automatisiert.Seit der Realisierung wurde jedoch die Hardware und Software des Siemens Steuergerätsauf eine neuere Version aktualisiert. In [53] sind viele Details zur Anlage und vor allem zu denModellen gegeben. Die Modelle wurden für den lokal-modularen Ansatz zu einem großenTeil übernommen, es waren jedoch Änderungen notwendig und es wurden einige Ergänzun-gen hinzugefügt. Der Entwurf mit S-Invarianten wurde ebenfalls an dieser Strecke realisiert.Die Umsetzung dient als Verifikation für die automatische Codegenerierung mit ACArrow.Zunächst wird die Strecke vorgestellt, dann werden die Entwürfe beschrieben und einigeDetails zur Realisierung erläutert. In Kapitel 8 werden die Ergebnisse der Umsetzung vergli-chen und einige Anmerkungen festgehalten.

7.1. Beschreibung der Fertigungszelle

Die Fertigungszelle wird als Stückgutprozess automatisiert, in dem Werkstücke nach Farbenund Qualität sortiert werden. Diese Anwendung ist zwar in einem kleinen Maßstab umge-setzt, könnte jedoch theoretisch ein Teil einer größeren Fertigung sein, zum Beispiel am En-de einer Fertigungsstraße. Die Werkstücke können unterschiedliche Sorten eines Produktesdarstellen. Die Abbildung 7.1 zeigt die Fertigungszelle in einem schematischen Modell vonoben betrachtet. Die Komponenten der Fertigungszelle werden in Tabelle 7.1 aufgezählt.

Komponente Beschreibung Komponente Beschreibung

LA Lager SA SchwenkarmLA_AS Ausschieber der Lagereinheit HU Handling UnitLI Linearachse mit Transportschlitten LS LichtschrankeWS/RFID RFID1 Stationen R Roboterarm

Tabelle 7.1.: Komponenten der Fertigungszelle

1engl. radio-frequency identification

7. Anwendungsbeispiel: Fertigungszelle 86

Abbildung 7.1.: Fertigungszelle von oben, nicht maßstabsgetreu

Ereignisnamen setzen sich für die Fertigungszelle folgendermaßen zusammen:

Ereignistyp_Komponente_Aktion

Ein Beispiel dafür ist das Ereignis STR_LA_AS_vor. Es ist ein steuerbares Ereignis (STR)vom Ausschieber der Lagereinheit (LA_AS). Die Aktion vor beschreibt, dass mit dem Er-eignis der Ausschiebevorgang, also eine Vorwärtsbewegung, gestartet wird. Das gesamteEreignisalphabet zeigt Anhang B.

Die Werkstücke tragen RFID Transponder, dass sind Datenträger (hier 20 Byte), die an denRFID Stationen gelesen und beschrieben werden können. Die Übertragung findet berüh-rungslos über Radiowellen statt. Die RFID 1 Station wird zum Beschreiben und RFID 2 zumLesen der Transponder verwendet. In der Abbildung 7.1 sind die meisten Komponenten be-schriftet. Zwei Werkstücke sind außerdem in rot dargestellt. Die gegenüberstehenden blauenKästchen sind Lichtschranken (LS). Der gelbe Kasten der Handling Unit stellt einen Schlit-ten mit Greifer dar. Im Greifer ist ein Sensor eingebaut, der die roten Werkstücke erkennenkann. Der Greifer kann auch vertikal bewegt werden, was in Abbildung 7.2 (a) ersichtlichwird. Ist der Greifer an der oberen Endposition, kann der Schlitten horizontal auf der Achsezwischen den Rutschen und der Linearachse bewegt werden. Die drei orangen Rauten sinddie Punkte, an denen die Position des Schlittens durch Sensoren ermittelt werden kann.


Abbildung 7.2.: (a) Handling Unit und (b) Roboter [2]

Der Weg eines Werkstücks durch die Anlage kann folgendermaßen beschrieben werden:Ein Werkstück wird mit dem Ausschieber aus dem Lager auf den Vorplatz geschoben. DerSchwenk-arm saugt das Werkstück an und tranportiert es zur Linearachse. Ist der Trans-portschlitten der Linearachse voll, fährt dieser zur Handling Unit. Eine LS zeigt dort an, dassein Werkstück vorhanden ist. Der Greifer der Handling Unit nimmt das Werkstück auf. Jenach Farbe wird es auf eine der Rutschen abgelegt (Rutsche1=rot). Ob Werkstücke auf denRutschen liegen, wird wieder durch eine LS angezeigt. Der Roboterarm (Abbildung 7.2 (b))entnimmt die Werkstücke aus den Rutschen und führt diese zunächst zur RFID 2 Station,dort wird der Status ausgelesen. Ein Werkstück kann OK, reparabel oder Ausschuss sein.Ist es reparabel wird es zurück ins Lager transportiert und es entsteht eine Mitkopplung.Ansonsten werden die Werkstücke außerhalb der Strecke abgelegt. Den Status des RFIDTransponders wird in dieser Anwendung vom Benutzer festgelegt, der diesen über eine Vi-sualisierung beschreiben kann, wenn die Steuerung nicht eingeschaltet ist.

Damit die Steuerung korrekt erstellt werden kann, muss beachtet werden, dass die Puffernicht über- oder unterlaufen. Die Anzahl der Werkstücke für verschiedene Puffer der Anlagezeigt Tabelle 7.2.

Puffer Anzahl Puffer Anzahl

Lager 9 Werkstücke Lager Vorplatz 1 WerkstückTransportschlitten 5 Werkstücke Rutschen 6 Werkstücke

Tabelle 7.2.: Puffergrößen


Hardware

Die verwendete Hardware wird in Tabelle 7.3 kurz beschrieben. Alle nicht in der Tabellegenannten Hauptkomponenten sind von der Firma FESTO.

Komponente Hardware Beschreibung

SPS* Simens CPU 1511-1 die Siemens SPS S7-1500 Station zurSteuerung der Anlage wird mit der CPU1511-1 PN verwendet [46]

I/O* Siemens ET 200S Ein- und AusgabebaugruppenBussystem Profinet echtzeitfähiges Bussystem zur Verbin-

dung der Siemens HardwareHMI Siemens Touchpanel Bedienung der AnlageLinearachse* SIMATIC S120 Ansteuerung des Schrittmotors [45]RFID SIMATIC RF180C regelt die Kommunikation zur RFID Stati-

on (Transponder SIMATIC RF320T, Stati-on SIMATIC RF3403)

Roboter Mitsubishi MovemasterExRV-M1

Roboterarm inklusive Drive Unit [34]

Tabelle 7.3.: Hardware der Fertigungszelle

*Diese Hardware wurde nach der Realisierung in [53] verändert.

Aus der SPS kann die RFID Kommunikation mit dem Funktionsbaustein FB45 geregelt wer-den. Dieser Siemens-Baustein wird in [48] beschrieben. Das Dokument [47] zeigt die Migra-tion auf die S7-1500.

Der Roboterarm besteht aus einem vertikalen Arm, der an fünf Achsen bewegt werden kann.Zusätzlich ist noch eine motorgesteuerte Hand zum Greifen der Werkstücke angebracht.Über eine RS-232 Schnittstelle ist die Drive Unit des Roboters mit einem PC verbunden, derwiederum eine Verbindung über Profinet zur SPS herstellt. Die Bewegungen des Roboterswerden mit Visual Basic programmiert. Der SPS kann durch Setzen von Merkerbits, den Ro-boter steuern. So kann der Roboter in verschiedene Positionen gefahren werden Werkstückeaufnehmen und Ablegen ist ebenfalls Teil der programmierten Bewegungsabläufe.

Die Bewegungen von dem Ausschieber, dem Schwenkarm und der Handling Unit werdenpneumatisch umgesetzt. Dafür werden Ventile durch die Ansteuerung der SPS geöffnet odergeschlossen. Der Ausschieber hat für die rückwärtige Bewegung eine Feder eingebaut.


7.2. Entwurf nach dem lokal-modularen Ansatz

Die Modelle für den lokal-modularen Entwurfsansatz müssen für die Strecke und die Spezifi-kation erstellt werden. Als Ausgangspunkt wurden die Modelle aus [53] übernommen und soverändert, dass funktionsfähige Supervisor entstehen. Problematisch sind dabei vor allemdie Signale der Lichtschranken. Diese werden zwar für die Steuerung benötigt, stellen aberkeine direkte Rückmeldung auf ein steuerbares Ereignis dar. Zwei Beispiele verdeutlichendie Problematik und zeigen deren Lösung.

1 2

ES_LA_KTeil

ES_LA_Teil

1 2

ES_LA_KTeil

STR_LA_AS_vorES_LA_Teil

Abbildung 7.3.: (a) Generator G5 und (b) Spezifikation K3_2

Die Abbildung 7.3 zeigt (a) den Generator G5 welcher die Lichtschranke im Lager modelliertund (b) die zugehörige Spezifikation K3_2. Der Eingang für die Lichtschranke ist hier verdop-pelt. Neben dem Ereignis E_LA_Teil, wird das Ereignis E_LA_KTeil durch die Invertierungvon E_LA_Teil künstlich erzeugt. Diese Invertierung muss der Benutzer im Steuerungspro-gramm selbst erstellen. In der Spezifikation wird nun lediglich verhindert, dass der Ausschie-ber ein Werkstück ausschieben darf, wenn kein Teil im Lager vorhanden ist. Diese Spezifi-kation wurde aus der Gesamtspezifikation ausgegliedert, sodass steuerbare lokal-modulareSupervisor realisiert werden konnten. Dieses Verfahren funktioniert und ist modellanalytischkorrekt.

1 2

EM_LS_Entnahme

STR_HU_Ende

1 2 19

EM_LS_Entnahme

STR_HU_Ende

Abbildung 7.4.: (a) Generator G9 und (b) ein Fragment der Spezifikation K7_1

Diese Methode kann jedoch nicht immer angewendet werden. Ein Beispiel dafür zeigt Ab-bildung 7.4. Die Lichtschranke bei der Entnahme der Handling Unit (G9) kann kein steuer-bares Ereignis verhindern, da alle steuerbaren Ereignisse der Handling Unit an mehrerenPositionen benötigt werden. Das heißt, das Ereignis zum Öffnen des Greifers kann nicht


verhindert werden, da auch bei den Rutschen zur Ablage des Werkstücks der Greifer ge-öffnet werden muss. Daher wurde in G9 ein zusätzliches steuerbares Ereignis eingeführt.Dieses Ereignis STR_HU_Ende dient der Synchronisation. Die Idee ist, dass das EreignisEM_LS_Entnahme erst interpretiert wird, wenn die Handling Unit überhaupt bereit ist einenneuen Transport von einem Werkstück zu beginnen. Dies ist modellanalytisch jedoch nichtkorrekt, da die Lichtschranke auch zu anderen Zeitpunkten aktiv sein kann. Durch die engeVerzahnung im späteren Supervisor musste das Ereignis daher als Merker (alternativ alsStrecke), wie in Kapitel 6.4.1 beschrieben, deklariert werden.

Insgesamt modellieren die Generatoren aus Tabelle 7.4 die Strecke vollständig. Die Numme-

Generator Beschreibung Generator Beschreibung

G1 Ausschieber Lager G7_1 Handling Unit hor. AchseG2_1 Schwenkarm Bewegung G7_2 Handling Unit GreiferG2_3 Schwenkarm Vakuum G7_3 Handling Unit vert. AchseG3 Linearachse G8 FarbsensorG4 ON/OFF Schalter G9 LS EntnahmeG5 LS Lager G10 RoboterG6 RFID Status G11 Rutschen

Tabelle 7.4.: Generatoren der Strecke

rierung ist nicht komplett durchgehend, da von den Modellen aus [53] ausgegangen wurde.Der Generator G2_2 wurde zum Beispiel in G2_3 migriert. Die Generatoren werden nicht imEinzelnen vorgestellt. Alle Generatoren sind im Anhang B dargestellt.

Die entwickelten Spezifikationen werden in der Tabelle 7.5 gezeigt. Für jede Spezifikationwird das lokale System angegeben. Die Spezifikation K9 ist nicht Teil des lokal-modularenAnsatzes, sondern wurde als modulare Spezifikation aus [53] direkt als lokal-modularer Su-pervisor übernommen. So kann der Benutzer die Anlage beliebig starten und stoppen. Wür-de diese Spezifikation lokal-modular synthetisiert werden, müssten alle Generatoren derStrecke zusammengefasst werden. Zu jeder Spezifikation wird ein Supervisor, wie in Kapitel2.1.5 beschrieben, mit DESTool umgesetzt. Nur für K9 gilt: K9=S9, da in [53] die Steuerbar-keit bezüglich der Strecke bewiesen wurde. Die Supervisor wurden anschließend auf lokaleModularität geprüft, jeweils zwei mit der Funktion IsNonblocking. Das Ergebnis ist, dass jederSupervisor lokal-modular bezüglich allen anderen Supervisorn ist.

Die Spezifikationen und die Supervisor werden in Anhang B gezeigt.

Nach dem Entwurf, wird der SPS-Code mit ACArrow erstellt. ACArrow ermittelt einige Aus-wahlprobleme. Das Auswahlproblem der Fertigungszelle tritt auf, wenn beide RutschenWerkstücke tragen. Es muss ausgewählt werden, von welcher Rutsche der Roboter ein


Spezifikation Beschreibung lokales System

K1 Lager Vorplatz GX1 = G1||G2_3K2 Linearachse Puffer GX2 = G1||G3K3_1 Ausschieber GX3_1 = G1||G2_1K3_2 LS Lager GX3_2 = G1||G5K4 Schwenkarm GX4 = G1||G2_1||G2_3||G3K5 Lager Puffer GX5 = G1||G10K6 Linearachse Be- und Entladung GX6 = G2_1||G3||G7_1K7_1 Handling Unit GX7_1 = G7_1||G7_2||G7_3||G9K7_2 Handling Unit Farbentscheidung GX7_2 = G7_1||G8K8 Linearachse GX8 = G3(K9) On/Off Schalter XK10_1 Roboter GX10 = G10||G11K10_2 RFID Status GX10 = G6||G10K11_1 Rutsche 1 Puffer GX10 = G7_1||G10K11_2 Rutsche 2 Puffer GX10 = G7_1||G10

Tabelle 7.5.: Spezifikationen und lokale Systeme

Werkstück entnimmt. Diese Auswahl muss im Supervisor S10_1 Zustand 5 getroffen werden.Für alle anderen in ACArrow angegebenen Zustände wäre ein Auswahlproblem möglich, derEntwickler weiß jedoch, dass diese für die Fertigungszelle nicht zutreffen. Daraufhin wird dieautomatische Codegenerierung (Siemens/SCL) durchgeführt. Anschließend wird der Codein die SPS als Quelle eingelesen und die Variablen werden importiert.

7.3. Steuerungsentwurf mit S-Invarianten

Im ersten Schritt müssen für die Streckenkomponenten Petrinetze erstellt werden. Die er-stellten Petrinetze werden in Tabelle 7.6 aufgezählt. Die Modelle (SIPN) werden in Anhang B

Petrinetz Beschreibung Petrinetz Beschreibung

PN1 Ausschieber Lager PN4 LinearachsePN2 Lager Vorplatz PN5 Handling UnitPN3 Schwenkarm PN6 Roboter und RFID

Tabelle 7.6.: Petrinetze der Streckenkomponenten


gezeigt. Die Puffer werden mithilfe von Zählerabfragen realisiert, allerdings werden bei die-sem Entwurf die Anzahl der Werkstücke auf der Rutsche und im Lager nicht berücksichtigt.Nur die Beschränkung auf die fünf Werkstücke des Transportschlittens werden in diesemersten Ansatz beachtet. Wichtig ist es, diesen Ansatz an der Anlage zu verifizieren. Dafürmüssen nicht alle Details eingearbeitet werden. Beim Schwenkarm wurden Timer einge-setzt, um das Vakuum zum Ansaugen und zum Entfernen zu nutzen und den Schwenkarmin der Mitte zwischen Linearachse und Lager zu positionieren. Im Modell für die HandlingUnit werden die Timer für das Öffnen und Schließen des Geifers verwendet.

Die Ungleichung im Bezug auf die zusammengesetzten Netze zeigt Tabelle 7.7. Der Robo-

Petrinetze Ungleichung Beschreibung

PN1, PN2 µ2 + µ7 + µ8 ≤ 1 der Ausschieber darf nur ausschieben, wennder Vorplatz leer ist

PN2, PN3 µ5 + µ6 + µ10 ≤ 1 der Schwenkarm darf nicht zum Lager, wennder Vorplatz belegt ist

PN3, PN4 µ9 + · · · + µ15 +µ20 ≤ 1

die Linearachse darf nur ein Schritt vorfah-ren, wenn der Schwenkarm nach dem Able-gen des Werkstücks wieder an der PositionMitte steht

PN3, PN4 µ9 + · · · + µ15 +µ21 ≤ 1

die Linearachse darf zur Entnahme fahren,wenn der Schwenkarm nach dem Ablegendes Werkstücks wieder an der Position Mit-te steht

PN4, PN5 µ23 + µ26 + · · · +µ30 + µ33 + · · · +µ38 ≤ 1

die Linearachse darf nur ein Schritt vorfah-ren oder zurück zu Beladung fahren, nach-dem die HU der LI ein Werkstück entnommenhat

Tabelle 7.7.: Spezifikationen in Form von Ungleichungen

ter ist mit keinem anderen Petrinetz durch eine Spezifikation verbunden. Dies wird möglichdurch die LS an den Rutschen, die signalisieren, dass Teile auf den Rutschen liegen. DieBearbeitung von der RFID Station ist direkt in PN6 umgesetzt.

Die Petrinetze werden in MATLAB eingegeben und für die Ungleichungen werden iterativdie Kontrollstellen erzeugt. Alle Ungleichungen sind positiv auf Zulässigkeit bezüglich dernicht steuerbaren Transitionen und auf Deadlocks getesten worden. Es werden insgesamtsechs Kontrollstellen erstellt, wobei die erste Kontrollstelle bezüglich PN1 und PN2 zurInitialisierung eine Marke tragen muss. Die MATLAB-Datei zur Erstellung der Kontrollstellenund das daraus entstandene Protokoll ist in Anhang B dargestellt.


Nun wird das Protokoll in ACArrow eingelesen und die Bedingungen und Anweisungen zuden SIPN werden, wie in Kapitel 6.5.2 beschrieben, eingetragen. Wurden die Informatio-nen in die Datenbank transferiert, wird die automatische Codegenerierung (Siemens/SCL)durchgeführt. Der Code wird in die SPS als Quelle eingelesen und die Variablen werdenimportiert.

7.4. Realisierung und Inbetriebnahme

In diesem Kapitel wird zunächst auf die Implementierung der Steuerungsentwürfe eingegan-gen. In diesem Zusammenhang werden auch die Schnittstellen näher betrachtet. Anschlie-ßend werden die Betriebsergebnisse kurz vorgestellt.

7.4.1. Implementierung der Steuerung

Die Abbildung 7.5 zeigt die Implementierungsarchitektur der SCT auf der Steuerung. Entwe-der kann der SCT-Ansatz die Strecke direkt über Ein- und Ausgänge steuern oder es werdenbereits erwähnte Schnittstellen benötigt. Zuerst wurde der bereits an der Strecke getestete

Abbildung 7.5.: Implementierungsarchitektur

modulare Ansatz von [53] mit der teilweise aktualisierten Hard- und Software wieder lauf-fähig gemacht. Die Schnittstellen mussten neu entwickelt werden. Dieser Entwurf benötigtdie meisten Schnittstellen, da in den Modellen keine zeitabhängigen Ausgänge verwendetwerden können.


Schnittstellen

Die Schnittstellen sind in SCL programmiert. Wichtig bei der Definition von Schnittstellensind immer die Übergabeparameter, in diesem Fall die Ereignisse. In diesem Kapitel wer-den die Schnittstellen beschrieben, es werden jedoch keine detaillierten Informationen zurProgrammierung angegeben. Die Programmierung wird möglichst einfach gehalten.

Für den modularen Ansatz müssen Schnittstellen für den Schwenkarm und die HandlingUnit erstellt werden, um dort zeitabhängige Ausgänge zu setzen. Das sind beim Schwenk-arm die Ausgänge für die Vakuum-Steuerung und die Einstellung der Position Mitte zwischenLinearachse und Lager. Auch alle anderen Ausgänge des SA werden in der Schnittstelle ge-setzt und rückgesetzt. Die Schnittstelle für die Handling Unit übernimmt lediglich das Öffnenund Schließen des Greifers. Der lokal-modulare Entwurfsansatz und der Entwurfsansatz mitS-Invarianten benötigen diese Schnittstellen nicht, da für die Modelle zeitabhängige Ausgän-ge eingeführt wurden.

Die Schnittstelle für die Linearachse wird für alle Ansätze benötigt. Hier werden weitereFunktionen aufgerufen, die zur Steuerung der LI verwendet werden. Es können die Positio-nen Beladung am SA und Entnahme an der HU aufgerufen werden. Alle anderen Positionenwerden erreicht, indem der Wagen um eine Werkstücklänge vorgefahren wird.

Die Roboter-Schnittstelle ist sehr einfach aufgebaut. Der Roboter erhält Befehle, indemMerkerbits gesetzt werden. Das sind M100.0 bis M100.6. Da diese Bits in der Roboter-Software erkannt werden müssen und anschließend dort zurückgesetzt werden, ist es not-wendig, die Merkerbits durch die steuerbaren Ereignisse zu setzen. Die steuerbaren Ereig-nisse können nicht direkt verwendet werden, da die automatische Codegenerierung dieserücksetzt und das zu einem Konflikt mit der Roboter-Software führen würde. Die Merker-bits M101.0 bis M101.5 sind Rückmeldungen vom Roboter, die direkt im generierten Codeals nicht steuerbare Ereignisse verwendet werden können. Zum Beispiel wird E_R_W_RFIDgleich der Adresse M101.3 gesetzt und wird direkt in den SCT Modellen verarbeitet.

7.4.2. Initialisierung der Strecke

Zum Start der SCT-Steuerung muss sich jede Komponente der Strecke in einem bestimm-ten Zustand befinden. Diese Zustände entsprechen den Initialzuständen der Modelle. DieInitialisierung der Strecke ist nicht Teil der automatisch generierten Steuerung und es musseine Funktion erstellt werden, die jede Komponente der Strecke in einen Ausgangszustandversetzt. Das heißt zum Beispiel, dass der Schwenkarm an der Position Mitte steht. Die Li-nearachse und der Roboter benötigen zusätzlich zu der Position eine Referenzierung. DieLinearachse hat einen Referenzpunkt und der Roboter sogar mehrere Endschalter, die zu


Beginn der Verwendung angefahren werden müssen. Diese Referenzfahrten sind jedochbereits vom Hersteller realisiert worden und müssen nur aufgerufen werden.

Sind außer im Lager noch Werkstücke auf der Strecke vorhanden, müssen dieser per Handentfernt werden. Alle Zustände der Modelle werden gelöscht, sodass ein kontrollierter Startmöglich ist. Es wird immer davon ausgegangen, dass keine Sensoren von außen betätigtwerden, während die Steuerung aktiv ist. Nun werden die Modelle neu initialisiert und dieSteuerung kann gestartet werden.

7.4.3. Betriebsergebnisse

Nach der Implementierung wurden die Ansätze zur Verifikation getestet. Der modulare An-satz von [53] konnte erfolgreich an die aktualisierte Hardware angepasst werden. Die Model-le mussten dafür nicht geändert werden. Lediglich die Schnittstellen wurden neu erstellt. Derneu umgesetzte lokal-modulare Ansatz konnte ebenfalls verifiziert werden. Bei der Model-lierung dieses Ansatzes wurden alle Beschränkungen der Anlage beachtet. Das heißt, allePuffer wurden korrekt modelliert und die Strecke kann zu keinem Zeitpunkt in einen undefi-nierten, blockierenden oder sogar die Hardware beschädigenden Zustand gelangen.

Die Einschränkung, dass keine undefinierte Anzahl von Werkstücken dem Lager hinzugefügtwerden darf, gilt für alle Ansätze. Es gibt eine kritische Anzahl von Werkstücken, bei der dieStrecke blockiert. Diese Anzahl hängt von den Zeitkonstanten der Streckenkomponenten ab.Werden zu Beginn neun Werkstücke in das Lager eingelegt, tritt keine Blockierung auf, auchwenn alle Werkstücke als Mitkopplung (reparabel) dem Prozess wieder hinzugefügt werden.Die kritische Zahl ist somit >9, die genaue Zahl wurde jedoch nicht genauer bestimmt.

Der Entwurf mit Petrinetzen arbeitet ebenfalls zuverlässig, jedoch wurden nicht alle Be-schränkungen der Strecke modelliert. Es sind keine Puffer für Rutschen und Lager vorhan-den, die Auswahl findet priorisiert für rote Werkstücke statt. Daher sollten Testläufe nicht mitmehr als sechs Werkstücken einer Farbe durchgeführt werden.

Alle Ansätze steuern die Strecke mit mehr oder weniger Beschränkungen zuverlässig. Somitkonnten die Modelle und die automatische Codegenerierung verifiziert werden.

Die Abbildung 7.6 zeigt ein Bild der Visualisierung, welche mit Siemens WinCC erstelltwurde. Die Visualisierung aus [53] wurde erweitert, sodass auch die Modelle des lokal-modularen Ansatzes und des Entwurfes mit S-Invarianten gezeigt werden. Die Abbildung7.6 zeigt die Petrinetze vom Ausschieber und vom Lager Vorplatz. Der Modellzustand kannabgelesen werden. Die aktiven Stellen (Stellen, die eine Marke tragen) beziehungsweiseZustände sind grün dargestellt.


Abbildung 7.6.: Screenshot der WinCC Visualisierung

8. Auswertung - Entwurfsansätze undCodegenerierung im Vergleich

In diesem Kapitel sollen die Erkenntnisse der Inbetriebnahme aus Kapitel 7 festgehaltenwerden. Im ersten Schritt werden dafür analytisch die Modellgrößen der Entwürfe bezüglichder Fertigungszelle und dem Aufwand der Codegenerierung verglichen. Im zweiten Schrittwerden kleinere Merkmale, die während der Entwicklung aufgefallen sind, genannt und be-wertet.

In Tabelle 8.1 werden die Modellgrößen der Entwürfe anhand der Zustände beziehungswei-se Stellen verglichen. Die Abweichungen werden immer im Bezug auf die größte Anzahl

Ansatz Zustände/StellenGesamt

Abweichung Zustände/StellenSupervisor

Abweichung

modular 108 16,9% 108 0%lokal-modular 130 0% 76 29,6%S-Invarianten 52 60% 5 97,2%

Tabelle 8.1.: Vergleich: Anzahl der Modellzustände

angegeben. Nach den Zahlen benötigt der Entwurf mit S-Invarianten die kleinste Anzahl anZuständen beziehungsweise Stellen. Durch die Synthese werden lediglich fünf zusätzlicheStellen zur Steuerung erzeugt. Wird ein Steuergerät mit einer stark begrenzten Speicherka-pazität verwendet, ist das ein großer Vorteil. In diesem Fall hat die SPS genug Speicherka-pazität, um jeden dieser Ansätze zu realisieren. Der Tabelle 8.1 ist zu entnehmen, dass zwardie Supervisor beim lokal-modularen Ansatz um knapp dreißig Prozent kleiner sind als beimmodularen, aber durch die Implementierung des Produktsystems insgesamt mehr Zuständeverwendet werden. Der große Unterschied zwischen den Zuständen der Supervisor zu demAnsatz mit S-Invarianten ist nicht zu stark zu gewichten, da die Methoden sehr unterschied-lich sind und daher nicht direkt verglichen werden können.

Die Tabelle 8.2 zeigt im Vergleich wie viele Byte die Ansätze vom SPS-Code-Arbeitsspeicherbelegen. Hierbei wird nur die reine automatische Codegenerierung betrachtet und keine


Schnittstellen. Der benötigte Speicherplatz ist abhängig von der Modellgröße und dem ver-wendeten Ansatz zur Codegenerierung. Die Codegenerierung für den lokal-modularen An-

Ansatz Byte Abweichung

modular 10194 25%lokal-modular 13595 0%S-Invarianten 5548 59,2%

Tabelle 8.2.: Vergleich: Speicherplatz der Ansätze

satz ist die aufwendigste. In Kapitel 3.3.2 wurde dieser detailliert vorgestellt. Ein Mehrauf-wand wird zum Beispiel geleistet, um den Lawineneffekt zu vermeiden. Für jedes Ereigniswerden mehrere Variablen benötigt, die zudem häufig neu gesetzt werden müssen. Der mo-dulare Ansatz verwendet eine einfachere Variante mit einer Blockierungsvariablen, die nureine zusätzliche Variable pro Generator erstellt. Durch die Variable kann nur ein Zustands-übergang pro Generator stattfinden. Dies beschränkt die Modellbewegung, jedoch sollte diesin den meisten Fällen keinen Unterschied für eine kurze SPS-Zykluszeit bedeuten. Diese Me-thode ist also für die Codegenerierung weniger aufwendig umzusetzen und benötigt wenigerSpeicherplatz. Eine Einführung dieser Beschränkung wäre auch für Petrinetze sinnvoll, umden Lawineneffekt bei der Modellierung nicht so stark beachten zu müssen.

Dieses und andere Kriterien werden in Tabelle 8.3 bewertet. Ein ’+’ wird vergeben, wenndas Kriterium gut umgesetzt wurde oder zutreffend ist, ’o’ für eine befriedigende Umsetzungoder ein teilweise zutreffendes Kriterium und ’-’ für eine unbefriedigende Umsetzung oderein nicht zutreffendes Kriterium. Die einzelnen Kriterien werden im Folgendem beschrieben.

Kriterium modular lokal-modular S-Invarianten

Lawineneffekt (Codegenerierung) + o -Auswahlproblem (Codegenerierung) o + oRobustheit (Modellierung) + o +Fehler finden (Modellierung) o - +Ausgänge (Modellierung) o + o

Tabelle 8.3.: Bewertung verschiedener Kriterien bezüglich der Entwurfsansätze

Das erste Kriterium ist der Lawineneffekt und wurde im vorherigen Abschnitt ausführlichbezüglich einer Blockierungsvariablen diskutiert.

Für das Auswahlproblem bietet die Codegenerierung für den lokal-modularen Ansatz eineLösung an und wird daher mit einem ’+’ bewertet. Diese Lösung könnte auch für die anderenAnsätze implementiert werden. Diese bieten aktuell nur eine priorisierte Auswahl.


Die Robustheit bezieht sich auf die Modelle. Die Modelle des lokal-modularen Ansatzes wer-den nur als befriedigend bewertet. Durch die Reduzierung der Supervisor sind häufig voneinem Zustand viele Zustandsübergänge möglich. Wird ein Eingang, beispielsweise durcheine unzureichende Entprellung, mehrmals betätigt, kann leicht ein falscher Zustandsüber-gang stattfinden.

Auch das Kriterium Fehler finden im SPS-Code wird für den lokal-modularen Ansatz durchdie reduzierten, beziehungsweise mit der Strecke verzahnten, Supervisor schwieriger. VieleZustände sind nur für einen Zyklus aktiv und so kann nicht verfolgt werden, in welchem Zu-stand das Problem entsteht. Hier müssen zum Beispiel zusätzliche Zähler eingefügt werden,um nachzuvollziehen, welche Zustände auch wirklich aktiv waren. Fehler treten nur auf, wenndie Modelle oder die Codegenerierung nicht korrekt sind. Auch bei dieser Entwicklung sindzu Beginn Fehler aufgetreten, die alle korrigiert wurden. Da der modulare Ansatz wenigerkomprimierte Supervisor verwendet, sind Fehler etwas leichter zu finden. Trotzdem müs-sen dafür in vielen Fällen mehrere Supervisor betrachtet werden. In den Petrinetzen könnenProbleme leicht lokalisiert werden, da ein Petrinetz eine Systemkomponente darstellt.

Das Kriterium Ausgänge bezieht sich ebenfalls auf die Modelle. Besonders einfach kön-nen die Ausgänge im lokal-modularen Ansatz eingetragen werden. Diese müssen nur inden Generatoren der Strecke beachtet werden. Das bedeutet einen minimalen Aufwand fürden Entwickler. Im modularen Ansatz müssen die Ausgänge auch in die Spezifikationeneingearbeitet werden. Bei den Petrinetzen können die Ausgänge ebenfalls nicht so effektiveingesetzt werden. Zum Beispiel müssen im Modell für die Handling Unit die Ausgänge fürdie horizontale Bewegung fast in jeder Stelle gesetzt werden, während im Generator deslokal-modularen Ansatzes beide Ausgänge in nur einem Zustand als Selfloop eingetragenwerden.

Zusammenfassend kann festgestellt werden, dass je nach Kriterium unterschiedliche Ansät-ze vorteilhaft sind. Daher wird auch kein Ansatz als der Beste ausgewählt, sondern in dieserArbeit sollten vor allem Codegenerierung für verschiedene Ansätze betrachtet werden. Diebeste Codegenerierung kann ebenfalls nicht ausgewählt werden, denn diese ist immer aufden Ansatz spezialisiert. Es können nur einzelne Elemente, wie beispielsweise der Lawinen-effekt, untersucht werden.

Obwohl der Ansatz mit S-Invarianten besonders kleine Modelle hervorgebracht hat, solltebedacht werden, dass innerhalb der einzelnen Petrinetze bereits der größte Teil der Steue-rung festgelegt wird und nur die Kopplung der Modelle durch die Synthese entstanden ist. Inden anderen beiden Ansätzen werden auch die Steuerungen für die einzelnen Komponen-ten durch Spezifikationen erstellt. Der Anteil der durch die Synthese erstellten Steuerung istsomit größer. Im Bezug auf die Synthese ist der lokal-modulare Ansatz am interessantesten,da die Veränderung von den Spezifikationen bezüglich der Supervisor am größten ist.

9. Zusammenfassung

In dieser Arbeit wurde die automatische SPS-Codegenerierung für zwei Entwurfsverfahrender Supervisory Control Theory umgesetzt. Dafür wurde ein Codegenerator mit einer grafi-schen Oberfläche entwickelt. Eine Fertigungszelle konnte erfolgreich automatisiert und damitder generierte SPS-Code verifiziert werden.

Zwei wichtige Beschreibungformen der SCT sind Automaten und Petrinetze. Zu Beginn derEntwicklung wurde ein Entwurfsverfahren für beide Formen ausgewählt, sodass möglichstverschiedene Aspekte der Codegenerierung gezeigt werden konnten. Der lokal-modulareEntwurfsansatz für Automaten und der Steuerungsentwurf mit S-Invarianten für Petrinetzewurden zusammen mit einem Konzept für die Codegenerierung ausgewählt.

Zur Durchführung der Steuerungsentwürfe wurde die Software DESTool für den lokal-modularen Ansatz und MATLAB mit der SPNBOX für den Entwurf mit S-Invarianten verwen-det. Die Protokolle der Entwürfe konnten anschließend genutzt werden, um die Modelldatenin den Codegenerator einzulesen.

Der Codegenerator ACArrow wurde als Windows Anwendung in C# programmiert. EineSQL-Datenbank ermöglicht das organisierte Ablegen und Aufrufen von Modelldaten. DieCodegenerierung für den lokal-modularen Ansatz basiert auf der DECON9 Methodik. Ne-ben kleineren Anpassungen wurden auch zeitabhängige Ausgänge eingeführt. Das Konzeptder Codegenerierung für den Entwurf mit S-Invarianten oder allgemein für Petrinetze ent-spricht den steuerungstechnisch interpretierten Petrinetzen. Die Codegenerierung aus [53]für den modularen Entwurfsansatz wurde ebenfalls in ACArrow integriert.

Die grafische Oberfläche ermöglicht dem Benutzer die richtigen Einstellungen für dieautomatische Codegenerierung zu treffen. So kann eine Auswahl zwischen der SPS-Programmiersprache AWL und ST/SCL getroffen werden. Die Syntax kann Siemens oderIEC 61131-3 konform gewählt werden. Die Ausgabedateien für Siemens sind als Quelle imSiemens TIA Portal importierbar.

Für die Automatisierung der Fertigungszelle konnten die Modelle für die Strecke und dieSpezifikation aus [53] für den lokal-modularen Ansatz angepasst werden. Die Modelle fürPetrinetze wurden neu aufgestellt. Die nichtblockierenden Steuerungen wurden den Ansät-zen entsprechend bestimmt. Nach der automatischen Codegenerierung mit ACArrow konn-ten die Steuerungen auf eine Siemens S7-1500 implementiert werden. Durch Testläufe an

9. Zusammenfassung 101

der Anlage konnte die korrekte Umsetzung, der in den Modellen festgelegten Steuerungs-aufgaben, bestätigt und der SPS-Code verifiziert werden.

In Kapitel 8 wurden die Ergebnisse der Implementierung des lokal-modularen Entwurfs, desEntwurfs mit S-Invarianten und des modularen Enwurfs aus [53] verglichen. Die Ansätze ha-ben verschiedene Vor- und Nachteile, je nach Wahl der Kriterien. Abschließend konnte dahernur festgestellt werden, dass diese drei Entwürfe für die Automatisierung der Fertigungszellegeeignet sind.

Ausblick

In diesem Abschnitt werden Aspekte diskutiert, die für eine industrielle Nutzung der SCT zu-künftig beachtet werden sollten. Für die SCT müssen nur die Strecke und die Spezifikationenerstellt werden. Die restlichen Schritte bis zur fertigen Steuerung werden mithilfe von Funk-tionen eines Entwicklungstools durchgeführt. Aktuell muss der Entwickler viele kleine Teil-schritte erledigen, bis die Steuerung eingesetzt werden kann. Vor allem wenn Änderungenauftreten, müssen alle Schritte erneut ausgeführt werden. Damit die Entwicklung zukünftigscheller und zielgerichteter ablaufen kann, sollten folgende Punkte zur Verbesserung einesTools berücksichtigt werden:

• Der Entwickler sollte einen Entwurfsansatz auswählen können, für den er nur die Stre-cke, die Spezifikationen und gegebenenfalls spezifische Angaben (zum Beispiel eineListe der lokalen Systeme für den lokal-modularen Ansatz) tätigen muss. Alle weiterenSchritte, inklusive spezifischer Tests auf zum Beispiel lokale Modularität, werden auto-matisch von der Software durchgeführt. Treten nun Änderungen auf, müssen lediglichdie Modelle geändert werden und der Synthesevorgang kann erneut in einem Schrittdurchgeführt werden.

• Ein Tool sollte immer einen grafischen Editor zur Modellierung verwenden. Ist diesernicht vorhanden, bedeutet das für den Entwickler einen zusätzlichen Arbeitsaufwand.Er muss die Modelle zuerst auf einer anderen Plattform modellieren, um anschließenddie benötigten Daten zu extrahieren. Für die MATLAB SPNBOX könnte in einer Arbeitein grafischer Petrinetz-Editor entwickelt werden.

• Entwicklungstool und Codegenerator sollten in einer Software vereint werden. Der Co-degenerator ACArrow könnte dafür zum Beispiel in ein bereits vorhandenes Entwick-lungstool integriert werden.

• Die grafischen Modelle sollten zukünftig als Visualisierung verwendet werden können.

Literaturverzeichnis

[1] lp_solve. URL http://lpsolve.sourceforge.net/5.5/, 06. Oktober 2014

[2] Abbildung MovemasterEx. URL http://hmt.fh-duesseldorf.de/hmt/images/3/33/Movemaster_EX_300px.jpg, 21. November 2014

[3] ASPERN, J. von: SPS Grundlagen: Aufbau, Programmierung (IEC 61131, S7), Simu-lation, Internet, Sicherheit. Hüthig Verlag Heidelberg; 2. überarbeitete und erweiterteAuflage, 2009. – ISBN 978-3-7785-4060-2

[4] BALEMI, S. ; BRUNNER, U. A.: Supervision of discrete event systems with communica-tion delays. In: Proceedings of the American Control Conference. Chicago, USA, Juni1992, S. 2794 - 2798

[5] BAYER, J.: Das C# 2012 Codebook. Addison-Wesley Verlag, 2013. – ISBN 978-3827331793

[6] CASSANDRAS, C.G. ; LAFORTUNE, S.: Introduction to Discrete Event Systems. SecondEdition, Springer Verlag, 2010. – ISBN 978-1-441-94119-0

[7] DUDENREDAKTION (Hrsg.): Duden: Die deutsche Rechtschreibung. BibliographischesInstitut & F.A. Brockhaus AG, Mannheim; 24. Auflage, 2006. – ISBN 978-3-411-04014-8

[8] FABIAN, M. ; HELLGREN, A.: PLC-based Implementation of Supervisory Control forDiscrete Event Systems. In: Proceedings of the 37th IEEE Conference on Decision andControl. Tampa, USA, Dezember 1998

[9] FREY, G.: Design and formal Analysis of Petri Net based Logic Control Algorithm, Fach-bereich Elektro- und Informationstechnik der Universität Kaiserslautern, Dissertation,2002

[10] FREY, G. ; SCHMIDT, A.: Automatische Erzeugung von SPS-Programmen aus Petri-netzen. In: Tagungsband der Fachtagung Verteilte Automatisierung 2000. VA 2000,Magdeburg, März 2000, S 177-184. – ISBN 0-7803-5662-4

[11] GIUA, A.: Petri Nets as Discrete Event Models for Supervisory Control, RensselaerPolytechnic Institute (Troy, New York), Dissertation, 1992

http://lpsolve.sourceforge.net/5.5/

http://hmt.fh-duesseldorf.de/hmt/images/3/33/Movemaster_EX_300px.jpg

http://hmt.fh-duesseldorf.de/hmt/images/3/33/Movemaster_EX_300px.jpg


[12] HASDEMIR, T. ; KURTULAN, S. ; GÖREN, L.: An implementation methodology for super-visory control theory. In: International Journal of Advanced Manufacturing Technology.März 2008, Nr. 36(3), S. 373-385

[13] HELLGREN, A. ; FABIAN, M.: PLC-based Implementation of Supervisory Control forDiscrete Event Systems. In: Proceedings of the 37th IEEE Conference on Decision andControl. Nr. 3, Tampa, Florida, USA, Dezember 1998, S. 3305-3310

[14] HELLGREN, A. ; FABIAN, M. ; LENNARTSON, B.: Modular Implementation of DiscreteEvent Systems as Sequential Function Charts Applied to an Assembly Cell. In: Pro-ceedings of the 2001 IEEE International Conference on Control Applications (CCA ’01).Mexico City 2001, S. 453-458

[15] IEC 61131-3:2013: Programmable controllers - Part 3: Programming languages (IEC61131-3:2013); German version EN 61131-3:2013. Beuth Verlag, 2013

[16] IORDACHE, M. V. ; ANTSAKLIS, P. J.: SPNBOX. URL http://www.letu.edu/people/marianiordache/abs/spnbox/#driver, 06. Oktober 2014

[17] IORDACHE, M.V.: Methods for the supervisory control of concurrent systems based onpetri net abstractions, Graduate Program in Electrical Engineering Notre Dame, Indiana,Dissertation, 2003

[18] IORDACHE, M.V. ; ANTSAKLIS, P.J.: Software Tools for the Supervisory Control of PetriNets Based on Place Invariants. Technical report of the ISIS Group. ISIS-2002-003,Department of Electrical Engineering, University of Notre Dame, April 2002

[19] JPETRINET: JPetriNet: intended to be used to model, analysis conventional Petri Netsand to simulate Timed Petri Nets. By Artur Luís Ribas Barbosa and Marcio Emilio CruzVono Azevedo. URL http://jpetrinet.sourceforge.net/, 21. Oktober2014

[20] KUHLMANN, G. ; MÜLLMERSTADT, F.: SQL - Der Schlüssel zu relationalen Datenbanken.Rowohlt Verlag, 2004. – ISBN 978-3499612459

[21] LEAL, A.B. ; CRUZ, D.L.L. da ; S. HOUNSELL, M. da: PLC-Based Implementation of Lo-cal Modular Supervisory Control for Manufacturing Systems. In: Manufacturing System.Dr. Faieza Abdul Aziz (Ed.), InTech, 2012, S. 160-181. – ISBN 978-953-51-0530-5

[22] LEDUC, R.J.: PLC implementation of a DES Supervisor for a manufacturing testbed:an implementation perspective, Department of Computer and Electrical Engineering,University of Toronto, Masterthesis, 1996

[23] LEDUC, R.J. ; LAWFORD, M. ; DAI, P.: Hierarchical Interface-based Supervisory Controlof a Flexible Manufacturing System. In: IEEE Trans. on Automatic Control 14 (2006).Nr. 4, S. 654-668

http://www.letu.edu/people/marianiordache/abs/spnbox/#driver

http://www.letu.edu/people/marianiordache/abs/spnbox/#driver

http://jpetrinet.sourceforge.net/


[24] LEDUC, R.J. ; LAWFORD, M. ; WONHAM, W.M.: Hierarchical Interface-based Super-visory Control - Part II: Parallel Case. In: IEEE Trans. on Automatic Control 50 (2005).Nr. 9, S. 1336-1348

[25] LEPERS, H.: SPS-Programmierung nach IEC 61131-3. Franzis Verlag, 2009. – ISBN978-3-7723-5806-7

[26] LOPES, Y. K. ; R.S.U. ROSSO JR., A.B. L. und ; HARBS, E.: Local Modular SupervisoryImplementation in Microcontroller. 9th International Conference of Modeling, Optimiza-tion and Simulation - MOSIM’12. Bordeaux, France, Juni 2012

[27] LUNZE, J.: Ereignisdiskrete Systeme: Modellierung und Analyse dynamischer Syste-me mit Automaten, Markovketten und Petrinetzen. Oldenbourg Verlag München Wien,2006. – ISBN 978-3-486-58071-6

[28] MICROSOFT VISUAL STUDIO: Microsoft Visual Studio: ist eine umfassende Lösungzur einfachen Bereitstellung von Anwendungen auf allen Microsoft-Plattformen. URLhttp://www.visualstudio.com//, 21. Oktober 2014

[29] MODLER, F. ; KREH, M.: Tutorium Analysis 1 und Lineare Algebra 1. Springer Verlag,2011. – ISBN 978-3-8274-2830-1

[30] MOODY, J.0. ; ANTSAKLIS, P.J.: Supervisory Control of Discrete Event Systems usingPetri Nets. Kluwer Academic Publishers, 1998. – ISBN 0-7923-8199-8

[31] MOOR, T.: DESTool. URL http://www.rt.eei.uni-erlangen.de/FGdes/destool/, 06. Oktober 2014

[32] MOOR, T.: libFaudes. URL http://www.rt.eei.uni-erlangen.de/FGdes/faudes/, 06. Oktober 2014

[33] MOOR, T. ; SCHMIDT, K. ; PERK, S.: Applied Supervisory Control for a Flexible Manu-facturing System. Workshop on Discrete Event Systems (WODES). 2010, S. 263-268

[34] MOVEMASTEREX: INDUSTRIAL MICRO-ROBOT SYSTEM Model RV-M. URL http://www.roboex.com/rv-m1.PDF, 30. Oktober 2014

[35] MUŠIC, G. ; MATKO, D.: Petri Net Based Control of a Modular Production System. In:Proceedings of the IEEE International Symposium on Industrial Electronics. 1999, Nr.3, S. 1383 - 1388. – ISBN 0-7803-5662-4

[36] PAYNE, C.: .NET Windows Forms in 21 Tagen. Oberflächen programmieren.Markt+Technik Verlag, 2003. – ISBN 978-3827264558

[37] POSSAN JUNIOR, M.C. ; LEAL, A.B.: Modelling and Implementation of SupervisoryControl Systems Using State Machines with Outputs. In: Manufacturing System. Dr.Faieza Abdul Aziz (Ed.), InTech, 2012, S. 285-306. – ISBN 978-953-51-0530-5

http://www.visualstudio.com//

http://www.rt.eei.uni-erlangen.de/FGdes/destool/

http://www.rt.eei.uni-erlangen.de/FGdes/destool/

http://www.rt.eei.uni-erlangen.de/FGdes/faudes/

http://www.rt.eei.uni-erlangen.de/FGdes/faudes/

http://www.roboex.com/rv-m1.PDF

http://www.roboex.com/rv-m1.PDF


[38] QUEIROZ, M.H. de ; CURY, J.E.R.: Modular Control of Composed Systems. In: Procee-dings of the American Control Conference. Chicago, USA, Juni 2000, S. 4051-4055

[39] QUEIROZ, M.H. de ; CURY, J.E.R.: Modular Supervisory Control of Large Scale DiscreteEvent Systems. In: Boel, R. (Hrsg.) ; Stremersch, G. (Hrsg.): Discrete Event Systems:Analysis and Control. Kluwer Academic Publishers, 2000, S. 103-110

[40] QUEIROZ, M.H. de ; CURY, J.E.R.: Synthesis and Implementation of Local ModularSupervisory Control for a Manufacturing Cell. In: Proc. of 6th International Workshopon Discrete Event Systems (WODES 2002). Saragossa, Spanien, Oktober 2002, S.377-382

[41] RAMADGE, P.J.: Supervision of discrete event processes, Dep. of Electrical and Com-puter Engineering, University of Toronto, Dissertation, 1983

[42] SAHIN, B.S.: Entwicklung eines grafischen SIPN-Editors mit AWL-Codegenerator,Hochschule für Angewandte Wissenschaften Hamburg, Masterthesis, 2011

[43] SCHWEIZER, W.: MATLAB kompakt, 5. Auflage. Oldenbourg-Verlag, 2013. – ISBN978-3-486-72114-0

[44] SIEMENS AG: Getting Started. URL http://www.automation.siemens.com/salesmaterial-as/interactive-manuals/getting-started_simatic-s7-1500/documents/DE/software_complete_de.pdf, 06.Oktober 2014

[45] SIEMENS AG: Bausteine zur einfachen Ansteuerung der Umrichtersysteme SINAMICSS/G mit SIMATIC S7-1200/150. URL http://cache.automation.siemens.com/dnl/jk/jk0OTY0MQAA_68034568_DL/SINAMICS_Bausteine_TIA_PORTAL_V12_SP1.pdf, 30. Oktober 2014

[46] SIEMENS AG: CPU 1511-1 PN (6ES7511-1AK00-0AB0) 4 Gerätehandbuch.URL https://cache.automation.siemens.com/dnl_iis/TI/TIxNTI1MQAA_68020492_HB/s71500_cpu1511_1_pn_manual_de-DE_de-DE.pdf, 30. Oktober 2014

[47] SIEMENS AG: Migration eines RFID Projekts mit FB45 von S7-300/400 aufS7-1500. URL http://cache.automation.siemens.com/dnl/DY/DYyODIyOQAA_77467630_Tools/77467630_Migration_FB45_V10_de.pdf, 30. Oktober 2014

[48] SIEMENS AG: RFID-Systeme FB 45 für MOBY U, MOBY D, RF200, RF300. URLhttps://cache.automation.siemens.com/dnl/DY/DY3MjM3AAAA_21738808_HB/FHB_FB45_0.pdf, 30. Oktober 2014

http://www.automation.siemens.com/salesmaterial-as/interactive-manuals/getting-started_simatic-s7-1500/documents/DE/software_complete_de.pdf



http://cache.automation.siemens.com/dnl/jk/jk0OTY0MQAA_68034568_DL/SINAMICS_Bausteine_TIA_PORTAL_V12_SP1.pdf



https://cache.automation.siemens.com/dnl_iis/TI/TIxNTI1MQAA_68020492_HB/s71500_cpu1511_1_pn_manual_de-DE_de-DE.pdf



http://cache.automation.siemens.com/dnl/DY/DYyODIyOQAA_77467630_Tools/77467630_Migration_FB45_V10_de.pdf



https://cache.automation.siemens.com/dnl/DY/DY3MjM3AAAA_21738808_HB/FHB_FB45_0.pdf

https://cache.automation.siemens.com/dnl/DY/DY3MjM3AAAA_21738808_HB/FHB_FB45_0.pdf


[49] SU, R. ; WONHAM, W.M.: Supervisor Reduction for Discrete-Event Systems. DiscreteEvent Dynamic Systems. Vol. 14, Nr. 1, 2004, 2004

[50] SUPREMICA: Supremica: Software for Formal Verification and Synthesis for ControlSystems. Dep. of Signals and Systems, Chalmers University of Technology, Schweden.URL http://www.supremica.org/, 20. Oktober 2014

[51] TCT: TCT: Software for Analysis and Design of Discrete-Event Systems. Dep. of Elec-trical and Computer Engineering, University of Toronto, Kanada. URL http://www.control.utoronto.ca/people/profs/wonham/, 20. Oktober 2014

[52] TIFFANY, R.: SQL Server CE Database Development with the .NET Compact Frame-work (Expert’s Voice). Springer Verlag, 2008. – ISBN 978-1590591192

[53] URLAND, C.: Ereignisdiskrete Steuerungssynthese und Codegenerierung am Beispieleiner Fertigungszelle, Hochschule für Angewandte Wissenschaften Hamburg, Mastert-hesis, 2012

[54] UZAM, M. ; GELEN, G. ; DALCI, R.: A New Approach for the Ladder Logic Implementationof Ramadge-Wonham Supervisors. In: XXII International Symposium on Information,Communication and Automation Technologies (2009). S. 1-7

[55] UZAM, M. ; JONES, A.H.: A New Petri-Net-Based Synthesis Technique for SupervisoryControl of Discrete Event Systems. Turk. J. Elec. Engin., Nr.10(1), S. 85-110, 2002

[56] WENCK, F.: Modellbildung, Analyse und Steuerungsentwurf für gekoppelte ereignisdis-krete Systeme. Shaker Verlag, 2006. – ISBN 978-3-8322-5573-2

[57] WENCK, F. ; RICHTER, J.H.: A Composition Oriented Perspective on Controllability ofLarge Scale DES. In: Proc. of 7th International Workshop on Discrete Event Systems(WODES 2004). Reims, Frankreich, September 2004, S. 271-276

[58] WONHAM, W.M.: Supervisory Control of Discrete-Event Systems. Dept. of Electricaland Computer Engineering, University of Toronto, Kanada, 1997-2010

[59] WONHAM, W.M. ; RAMADGE, P.J.: The Control of Discrete Event Systems. In: Proc.IEEE, Special Issue on Discrete Event Dynamic Systems 77 (1989). Januar, Nr. 1, S.81-98

[60] WONHAM, W.M. ; RAMADGE, P.J.: Supervisory control of a class of discrete event pro-cesses. In: SIAM J. Control and Optimization 25 (1987). Januar, Nr. 1, S. 206-230

http://www.supremica.org/

http://www.control.utoronto.ca/people/profs/wonham/

http://www.control.utoronto.ca/people/profs/wonham/

Anhang

Anhang A: Anleitung SPNBOX, MATLAB-Datei und Funktionen,Ausgabedateien

Anhang B: Modelle der Fertigungszelle (CD)

Anhang C: ACArrow (CD)

Anhang D: DESTool Projekt (CD)

Anhang E: SPNBOX (CD)

Anhang F: Siemens Steuerung (CD)

Der auf Anhang auf der CD kann beim Erst- und Zweitprüfereingesehen werden.

A. Anleitung: SPNBOX

Die Aktualisierungen der SPNBOX zu Version 1.2 wurde auf der Plattform Octave ausgeführt,daher waren für MATLAB kleine Änderungen notwendig, sodass am Ende eine Kombinationaus alter und neuer SPNBOX entstand. Folgende Änderungen wurden vorgenommen:

1. Ersetzung von M-File ip_solve in V1.0 mit ip_solve aus V1.2

2. M-File ip_sc_matlab aus V1.2 in V1.0 kopieren

3. Umbenennung ip_sc_matlab in ip_sc

29.11.14 14:05 C:\Users\Nadine\Dropbox\MThesis\Softwa re\Petrin...\MABeispiel.m 1 of 2

%% VariablenanzControl=0; %Variable zählt Control places%% EINGABE Module% Eingabe der Matrizen Zeile Stellen, Spalten Trans itionen (!Ausgabe% andersrum, damit eine Transition zeilenweise eing elesen werden kann)% Bitte Priorisierung bei Eingabe beachtenN1=[ -1 1 0 0 ; 0 -1 1 0 ; 0 0 -1 1 ; 1 0 0 -1 ]'; %EINGABE Tank 4 Stellen, 4 Transitionen

N2=[ -1 1 ; 1 -1 ]'; % EINGABE Rührgerät 2 Stellen, 2 TransitionenP1=[1 0 0 0]; %%%EINGABEP2=[1 0]; %%%EINGABES1=char( 'P1' , 'P2' , 'P3' , 'P4' ); %%% EINGABE AusschieberS2=char( 'P5' , 'P6' ); %%% EINGABE PlatzInit=char( 'P1' , 'P5' ); %%%EINGABE Initalstellen%%% 1 2, letzte Zelle soll immer [] leere Matrix s einNx=N1 N2 []; %%% EINGABE % alle Matrizen bitte eingeben, []=LeerSx=S1 S2 []; %%% EINGABE % alle Stellenvektoren bitte eingebenpx=P1 P2 []; %%%EINGABE anz=length(Nx)-1; %Anzahl der Module wird berechnet

%% Synthese 1 Tank, Rührgerätf=1 2 3; % EINGABE Wähle die Module über den Index aus, 1x L eer auswählen bei 2 Inputs% Hauptmatrix erstellen[N,m1,m2,m3,n1,n2,n3]=CreateMatrix(Nxf1,Nxf2 ,Nxf3); % Maximal 3% EINGABE Tuc, m0, b, LTuc=[1,2,4,6]; %%% EINGABEp0=[pxf1 pxf2 pxf3]'; %wird berechnetb=1; %%% EINGABEL=[1 0 0 1 0 1] ; %%% EINGABE %u1+u4+u6 [K,pk]=Synthese(N,Tuc,p0,b,L);%% Aktualisierung der modularen Petrinetze

[anzControl,Nx,Sx,Init,px]=Update(N,K,pk,Nx,Sx,f,n1 ,n2,n3,anzControl,Init,px);%% Finale Ausgabe% wird erst durchgeführt, wenn alle Controllstellen generiert wurden, also% ganz am schlussh='Protokoll.m' ;G=char( 'D' );R=char( 'N' );dlmwrite(h,strcat(R, '1' ));for i=1:1:anz if isempty(Nxi)==0 dlmwrite(h,Sxi, '-append' );

dlmwrite(h,strcat(G,int2str(i)), '-append' ); dlmwrite(h,Nxi', '-append' ); if i~=anz dlmwrite(h,strcat(R,int2str(i+1)), '-append' ); else dlmwrite(h, 'X' , '-append' ); end endenddlmwrite(h,Init, '-append' );

01.11.14 11:31 C:\Users\Nadine\Dropbox\MThesis\Softwa re\Petr...\CreateMatrix.m 1 of 2

function [D,m1,m2,m3,n1,n2,n3]=CreateMatrix(D1,D2,D3) [m1,n1]=size(D1); [m2,n2]=size(D2); if nargin==2, D3=[]; end [m3,n3]=size(D3); D=[D1 zeros(m1,n2+n3); zeros(m2,n1) D2 zeros(m2 ,n3); zeros(m3,n1+n2) D3]; endfunction [K,mk]=Synthese(D,Tuc,m0,b,L)Tuo=[]; [Dm, Dp]=d2dd(D);

% zur Überprüfung der Ungleichung[Lb, bb, R1, R2, how, dhow] = ilp_adm(L,b,D,Tuc,Tuo )pn=getpn(Dm, Dp, Tuc, Tuo, m0);[L1, b1, L0, b0, how]=dp(pn, [], Lb, bb);[Dfm,Dfp,ms, how]=linenf(Dm, Dp, Lb, bb, m0);K=Dfp-Dfm;mk=ms;endfunction [anzControl,Dx,Sx,Init,mx]=Update(D,K,mk,Dx,Sx,f,n 1,n2,n3,anzControl,Init,mx)[m0,n0]=size(D);[m5,n5]=size(K);[m6,n6]=size(mk);

[m7,n7]=size(mx);m=m5-m0; %Anzahl der Kontrollstellen, zusätzlichen ZeilenD5=[];anzControl=anzControl+m;for i=(m-1):-1:0 D5=[D5;K(m5-i,1:end)] ; %%Kontrollstellen if mk(m6-i)==1 Init=char(Init, strcat( 'C' ,int2str(anzControl-i))); mxf1=[mxf1 1]; mxf2=[mxf2 1]; mxf3=[mxf3 1];

else mxf1=[mxf1 0]; mxf2=[mxf2 0]; mxf3=[mxf3 0];end end Dxf1=[Dxf1; D5(1:end,1:n1)];Dxf2=[Dxf2; D5(1:end,n1+1:n1+n2)];Dxf3=[Dxf3; D5(1:end,n1+n2+1:end)];

for i=(anzControl-m+1):1:anzControl Sxf1=char(Sxf1,strcat( 'C' ,int2str(i))); Sxf2=char(Sxf2,strcat( 'C' ,int2str(i))); Sxf3=char(Sxf3,strcat( 'C' ,int2str(i)));end B=ismember(Dxf1,zeros(1,n1), 'rows' ) ;indi=find(B);if ~isempty(indi) Dxf1(indi,:)=[];

Augabedateien Beispiel

Siemens

DATA_BLOCK "R_TRIG_DB_100"

OriginalPartName := 'R_TRIG_1500';

VersionGUID := '0878877c-7401-11e1-9706-a2f44724019b';

S7_Optimized_Access := 'TRUE'

AUTHOR : SIMATIC

FAMILY : BIT

NAME : R_TRIG

VERSION : 1.0

NON_RETAIN

R_TRIG

BEGIN

END_DATA_BLOCK

FUNCTION "Read_Input_SIPN_SCT" : Void

S7_Optimized_Access := 'TRUE'

VERSION : 0.1

BEGIN

"ES_T_voll_0":="ES_T_voll";

"R_TRIG_DB_100"(CLK:="E_R_an",Q=>"E_R_an_0");

"ES_T_leer_0":="ES_T_leer";

IF NOT "InitInput_SIPN_SCT" THEN

"InitInput_SIPN_SCT":=1;

"E_R_an_0":=0;

END_IF;

END_FUNCTION

IEC 61131-3

FUNCTION Read_Input_SIPN_SCT : BOOL

VAR_INPUT

END_VAR

VAR

END_VAR

VAR_GLOBAL

R_TRIG_100:R_TRIG;

END_VAR

ES_T_voll_0:=ES_T_voll;

R_TRIG_100(CLK:=E_R_an,Q=>E_R_an_0);

ES_T_leer_0:=ES_T_leer;

IF NOT InitInput_SIPN_SCT THEN

InitInput_SIPN_SCT:=1;

E_R_an_0:=0;

END_IF;

END_FUNCTION

Versicherung über die Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach§16(5) APSO-TI-BM ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfs-mittel benutzt habe. Wörtlich oder dem Sinn nach aus anderen Werken entnommene Stellenhabe ich unter Angabe der Quellen kenntlich gemacht.

Hamburg, 4. Dezember 2014Ort, Datum Unterschrift

Documents

Masterthesis im Fachbereich Elektrotechnik & Informatik an ...edoc.sub.uni-hamburg.de/haw/volltexte/2015/2887/pdf/MAThesis.pdf · Nadine Gohert Thema der Masterthesis Automatische