View
5
Download
0
Category
Preview:
Citation preview
Fachbereich:Elektrotechnik und Informatik
Modellbasierte Modellierung von
industriellen Zentrifugen mit
Codegenerierung für Steuerungssysteme
Bachelorarbeit
Autor: Nils Wortmann
Matrikel-Nummer 730377
eingereicht am: 17.07.2015
Firma: GEA Westfalia Separator Group GmbH
Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster
Zweitprüfer: Dipl.-Ing., MBA Axel Hessenkämper,
GEA Westfalia Separator
INHALTSVERZEICHNIS
Inhaltsverzeichnis
Abkürzungsverzeichnis IV
1 Einleitung 1
1.1 Unternehmensprofil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Hintergrund und Motivation . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 5
2.1 Industrielle Zentrifugen . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 4-Schichten Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Modellierungssprachen . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Kommunikationsdiagramm . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Metamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Codegenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Beckhoff IPC - TwinCAT 3 . . . . . . . . . . . . . . . . . . . . . . . 15
3 Entwicklungstool - Cinco 19
3.1 Metasprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 MGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 MSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.3 CPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Codegenerieungs Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Durchführung 27
4.1 Entwicklung der CML . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Analyse der Anforderungen an die CML . . . . . . . . . . . . 28
4.1.2 Entwurf der CML . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 Spezifizierung des Zentrifugenmodells . . . . . . . . . . . . . . 32
4.1.4 Spezifizierung des Sequenzmodell . . . . . . . . . . . . . . . . 38
4.1.5 Spezifizierung des Funktionsbausteinmodells . . . . . . . . . . 41
4.2 Entwicklung des Codegenerators . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Validierung des Modells . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 M2T Transformation . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 Codegenerierung . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Navigation durch die Ebenen . . . . . . . . . . . . . . . . . . . . . . 67
II
INHALTSVERZEICHNIS
5 Fazit 69
6 Zusammenfassung und Ausblick 70
Abbildungsverzeichnis V
Tabellenverzeichnis VII
Listings VIII
Literatureverzeichnis X
A Cinco Syntax XI
A.1 MGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI
A.1.1 MGL Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XI
A.1.2 MGL Annotations . . . . . . . . . . . . . . . . . . . . . . . . XI
A.2 MSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII
A.2.1 MSL Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XII
A.3 CPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII
A.3.1 CPD Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XIII
B CML Symbole und deren Bedeutung XIV
B.1 Zentrifugenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV
B.2 Sequenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
B.3 Funktionsbausteinmodell . . . . . . . . . . . . . . . . . . . . . . . . . XXI
III
ABKÜRZUNGSVERZEICHNIS
Abkürzungsverzeichnis
CML Centrifuge Model Language
CMT Centrifuge Modelling Tool
CPD Cinco Produkt Definition
HMI Human Machine Interface
IPC Industrial PC
MDSD Model-Driven Software Development
MGL Meta Graph Language
MSL Meta Style Language
M2T Model to Text Transformation
PLC Programmable Logic Controller
TMC TwinCAT3 Module Class Editor
OPC Open Platform Communications
UML Unified Modeling Language
URI Uniform Resource Identifier
XAA eXtended Automation Architectur
IV
1 EINLEITUNG
1 Einleitung
Industrielle Zentrifugen sind ein wichtiger Bestandteil für die Aufbereitung und Ver-
arbeitung von Medien in einer ganzen Prozesslinie. Sie sorgen dafür das Medien mit
unterschiedlicher Dichte voneinander getrennt werden. Hierbei kann die Einbindung
der industriellen Zentrifuge in die Prozesslinie und die eingesetzten Komponenten
sehr unterschiedlich sein. Aus diesem Grund muss sie immer erneut konfiguriert und
programmiert werden. Jedoch ist dieses leider so schwierig, dass die Programmierung
nur von speziellen Technikern/Programmierern durchgeführt werden kann, die aber
in der Regel keine Kenntnisse über den entsprechenden Prozess bzw. des Verfahren
besitzen.
Ziel dieser Bachelorarbeit ist daher, die Anwendersoftware Centrifuge Modelling
Tool (CMT) zu entwickeln und zu beschreiben. Mit Hilfe dieser Anwendersoftware
sollen Mitarbeiter, die ein hohes Maß an Domänen spezifischem Fachwissen besitzen,
aber nicht über die notwendigen Programmierkenntnisse verfügen, die Möglichkeit
erhalten, das Fachwissen in ein Steuerungsprogramm zu transferieren. Hierbei han-
delt es sich, wie bereits erwähnt, um die Domäne der prozesstechnischen Steuerung
von industriellen Zentrifugen. Dieses führt dazu, dass die Anwendersoftware eine
Metaebene besitzt, mit der Modelle für industrielle Zentrifugen modelliert werden
können. Aus diesem Grund muss eine Metamodellschicht mit Hilfe der Metamodel-
lierung entwickelt werden. Diese Metamodellschicht enthält die Modellierungsspra-
che Centrifuge Model Language (CML). Zudem muss neben der Metamodellschicht
ein Codegenerator implementiert werden, damit aus einem Modell ein Applikations-
code für ein Steuerungsprogramm generiert werden kann. Jedoch gibt es nicht nur
ein Steuerungssystem, auf dem das Steuerungsprogramm läuft. Deswegen muss die
Möglichkeit bestehen, dieses Steuerungsprogramm für unterschiedliche Steuerungs-
systeme generieren zu können. Dabei wird zwischen zwei Arten von Steuerungssyste-
men unterschieden. Zum einem gibt es den Industrial PC (IPC) und zum anderen
den Programmable Logic Controller (PLC). Abschließend ist eine modellbasierte
Software Entwicklung1 mit Hilfe der Anwendersoftware möglich.
1.1 Unternehmensprofil
Die GEA Westfalia Separator Group GmbH wurde 1893 in Oelde (Deutschland)
gegründet. Jedoch hieß sie damals noch Ramesohl & Schmidt oHG. Erst im Jahre
1941 änderte sich der Name in Westfalia Separator. Seit 1994 ist Westfalia Sepa-
rator Teil der GEA Group und wurde aus diesem Grund 2008 in GEA Westfalia
Separator Group GmbH umbenannt. Die Produkte sind Separatoren und Dekanter.
1Modellbasierte Software Entwicklung bedeutet, dass eine Software über die Erstellung vonModellen entwickelt wird und nicht über die Programmierung von Applikationcode.
1
1 EINLEITUNG 1.2 HINTERGRUND UND MOTIVATION
Separatoren und Dekanter sind Maschinen, genauer industrielle Zentrifugen, welche
Flüssigkeiten und Feststoffe voneinander trennen (zum Beispiel Öl von Wasser). Am
Standort Oelde sind ca. 1300 Mitarbeiter beschäftigt, weltweit ca. 3600. Damit ist
Oelde der größte Produktionsstandort. Zudem befinden sich noch weitere Produkti-
onsstandorte in Chateau-Thierry (Frankreich), Niederahr (Deutschland), Bengaluru
(Indien) und Wuqing (China).
1.2 Hintergrund und Motivation
Die GEA Westfalia Separator Group GmbH besitzt ein Know-how in über 3000 ver-
schieden Prozessen und Verfahren. Dieses Know-how muss in Steuerungsprogramme
umgesetzt werden. Bevor der Verfahrenstechniker mit dem Programmierer über die
Umsetzung des Steuerungsprogramms sprechen kann, muss mit dem Kunden das
passende Verfahren für sein Medium ausgewählt werden. Anschließend implemen-
tiert der Programmierer das Verfahren in eine Steuerung. Hierbei entsteht ein wei-
teres Problem, denn die Vielfalt der Steuerungssysteme sorgen dafür, dass viele un-
terschiedliche Programmierkenntnisse benötigt werden. Aus diesem Grund soll eine
Metaebene über die vielen unterschiedlichen Steuerungssysteme gelegt werden. Die-
ses hat den großen Vorteil, dass die vielen unterschiedlichen Programmierkenntnisse
entfallen und somit alle Programmierer eine einheitliche Modelliersprache nutzten.
Wenn der Gedanke der Metaebene noch weiter vorangetrieben wird, sollte es möglich
sein, die Modelliersprache so zu entwickeln, dass der Verfahrenstechniker diese auch
anwenden kann, um ein Modell für eine Zentrifuge zu modellieren. Wenn des Weite-
ren aus dem Modell ein Applikationscode für Steuerungssysteme erzeugt wird, hätte
dieses zur Folge, dass der am Anfang beschriebene Arbeitsprozess verkürzt wird. Zu-
sammenfassend liegt die Motivation darin, den Arbeitsablauf zu optimieren.
1.3 Zielsetzung
Das Ziel ist ein Proof of Concept, für die Generierung von Applikationscodes aus ei-
ner Metaebene heraus, anzulegen. Hierfür muss die CML entwickelt werden. Danach
wird diese Modellierungssprache mit Hilfe einer Entwicklungsumgebung für Model-
lierungstools Cinco in eine lauffähige Anwendersoftware umgesetzt, mit der Modelle
für industrielle Zentrifugen erzeugt werden können. Anschließend wird ein Codege-
nerator in die Anwendersoftware integriert. Da Codegeneratoren Programme sind,
die selber wieder Programme erzeugen, werden diese Metaprogramme genannt [10,
S.143]. Cinco bietet eine Schnittstelle für die Verwendung eines Metaprogramms.
Somit besitzt die Software (CMT) die Eigenschaft aus einer Metaebene einen Ap-
plikationscode für unterschiedliche Steuerungssysteme zu generieren. Bevor der Ap-
plikationscode jedoch generiert werden kann, muss im CMT mit Hilfe der CML ein
2
1 EINLEITUNG 1.4 GLIEDERUNG
Modell für eine industrielle Zentrifuge modelliert werden. Für den Codegenerator
wird sich zuerst einmal auf ein Steuerungssystem fokussiert, nämlich auf ein IPC
der Firma Beckhoff (TwinCAT3). Eine Schnittstelle für weitere Codegeneratoren
soll aber implementiert werden. Das Ziel ist letztendlich mit Hilfe des CMT ein
Modell für eine Zentrifuge, genauer für einen Separator, zu modellieren, um dann
einen Quellcode für einen Beckhoff IPC zu generieren. In der Abbildung 1.1 wird
die grundlegende Funktionsweise des CMT dargestellt.
Abbildung 1.1: Grundlegende Funktionsweise des Centrifuge Modeling Tools
1.4 Gliederung
Zunächst werden die für die Umsetzung benötigten Grundlagen betrachtet. Der Ein-
stieg erfolgt mit der Erklärung der Funktionsweise von industriellen Zentrifugen und
geht über zu den theoretischen Grundlagen (4-Schichten Architektur, Modellierungs-
sprachen, Metamodellierung, Code Generierung). Abschließend wird im Abschnitt
der Grundlagen die Zielplattform (Beckhoff - TwinCat3) für den modellierten Quell-
code vorgestellt. Für die Entwicklung des CMT wird das Entwicklungstool Cinco
im Abschnitt”Entwicklungstool - Cinco“ vorgestellt. Im Abschnitt Durchführung
wird zuerst die Entwicklung der CML vorgestellt, bevor auf die Entwicklung des
3
1 EINLEITUNG 1.4 GLIEDERUNG
Codegenerators eingegangen wird. Nachdem die rudimentären Funktionen des CMT
lauffähig sind, ist ein zusätzliches Feature programmiert worden. Bevor der Inhalt
der Bachelorarbeit zusammengefasst und ein Ausblick gegeben wird, wird ein Fazit
über das erreichte gezogen.
4
2 GRUNDLAGEN
2 Grundlagen
In diesem Abschnitt werden die Grundlagen erklärt, die für die Umsetzung des Proof
of Concept erforderlich sind. Als erstes werden industrielle Zentrifugen erklärt, damit
der fachliche Kontext für das Verständnis der CML bekannt ist, wobei die Fokus-
sierung auf dem Separator liegt. Bevor genauer auf Modellierungssprachen und die
Metamodellierung eingegangen wird, wird die 4-Schichten Architektur erklärt, damit
die Begriffe eindeutig eingeordnet werden können. Im Abschnitt Modellierungsspra-
chen wird die bekannteste aller Modellierungssprachen, nämlich die UML (Unified
Modeling Language) vorgestellt, da diese wichtige Grundlagen für die CML liefert.
De CML wird basierend auf diesen Grundlagen weiter entwickelt, sodass ab diesem
Zeitpunkt der Begriff Metamodellierung ins Spiel kommt. Zudem soll die Software,
die CMT heißt, den Applikationscode für einen IPC von Beckhoff generieren. Des-
wegen muss eine Model to Text Transformation (M2T) durchgeführt werden. Wie
eine solche Transformation umgesetzt werden kann, wird im Unterabschnitt Code-
generierung erklärt. Abschließend wird das Zielsteuerungssystem (TwinCAT3) mit
der bereits angewendeten Software Architektur für Applikationen erläutert.
2.1 Industrielle Zentrifugen
Es gibt zwei Arten von industriellen Zentrifugen, die Separatoren und die Dekan-
ter. Der größte Unterschied zwischen einem Separator und einem Dekanter liegt
in seinem konstruktiven Aufbau, denn beim Separator ist die Trommel vertikal und
beim Dekanter horizontal angeordnet (siehe Abbildung 2.1). Aus der jeweiligen Kon-
struktion ergibt sich, dass ein Separator Partikelgrößen ab 0,5 µm und ein Dekanter
Partikelgrößen ab 5 µm trennen kann. Außerdem beträgt die Durchlaufleistung bei
einem Separator bis 500.000 l/h und bei einem Dekanter bis 350.000 l/h. [11] Im
Allgemeinen gilt, dass der Dekanter Medien mit höherem Feststoffanteil voneinander
trennt.
(a) Separator (b) Dekanter
Abbildung 2.1: Darstellung Separator und Dekanter (Abbildungen aus [11])
5
2 GRUNDLAGEN 2.1 INDUSTRIELLE ZENTRIFUGEN
Dabei basiert die Trennung auf der Radialkraft2. Denn mit Hilfe dieser Trägheits-
kraft wirkt eine größere Kraft auf Medien mit einer größeren Dichte. Dieses bedeutet,
dass eine Zentrifuge durch eine bestimmte Drehzahl Medien voneinander trennen
kann. Die Formel (1) spiegelt genau dieses wieder, nämlich das Teilchen mit größerer
Dichte, durch die auf sie wirkende größere Radialkraft, an den Rand der Zentrifuge
gedrückt werden.
Fr = ρV r(2πn)2 (1)
Im Hinblick darauf, dass ein Steuerungsprogramm für einen Separator modelliert
werden soll, wird der Separator spezifischer erklärt. Bei einem Separator wird zwi-
schen zwei Arten von Separatoren unterschieden, einmal die Klärer und einmal die
Trenner. Klärer trennen eine Flüssigkeit und einen Feststoff voneinander. Trenner
hingegen trennen zwei Flüssigkeiten und einen Feststoff voneinander. Dieser Trenn-
prozess muss steuerungstechnisch geregelt und überwacht werden. Jedoch gibt es
nicht nur den einen absoluten Trennprozess, sondern es gibt eine Vielzahl von un-
terschiedlichen Prozessen, die abhängig von der jeweiligen Applikation3 sind. Zudem
wird nicht jeder Separator gleich konstruiert, welches Unterschiede in der elektrisch
verbauten Hardware zur Folge hat. So wird zum Beispiel ein Separator entweder
über eine Zeitrampe auf 6000 1/min hochgefahren, weil kein Initiator für die Dreh-
zahlmessung verbaut wurde oder aber der Separator besitzt diesen Initiator und
kann messen, wann die Nenndrehzahl erreicht wurde. Andere Beispiele für Unter-
scheidungen in der Hardware sind:
• mit bzw. ohne Vibrationsüberwachung
• mit bzw. ohne Feststofftank
• mit bzw. ohne Frequenzumrichter
Prozesstechnische Unterschiede wirken sich meistens nur auf die Parameter aus.
Beim Prozess selber gibt es keine Endschalter, die einen bestimmten Zustand einlei-
ten oder Sensoren, die in der Trommel4 platziert werden können. Deswegen muss der
ganze Prozess über Timer gesteuert werden, zum Beispiel wie lange das Produkt ge-
fahren wird oder wie lange eine Entleerung5 dauert. Hardware und prozesstechnische
Unterschiede haben somit Einfluss auf die Sequenzen, in denen sich ein Separator
befinden kann. Denn generell lässt sich ein Separator in Elf von diesen Sequenzen
aufteilen, wobei einige optional sind.
2Radialkraft auch Zentrifugalkraft genannt, ist eine Kraft, die von der Rotationsachse radialnach außen gerichtet ist)
3Applikationen bedeuten in diesem Kontext, dass es verschiedene Anwendungen für Separatorengibt, wie zum Beispiel Bier von Hefe Stückchen trennen oder Wasser von Öl
4Herzstück eines Separators: Die Trommel dreht sich mit der Nenndrehzahl und sorgt für dieTrennung
5Entleerung: Bei der Entleerung wird der Feststoff aus der Trommel geschleudert
6
2 GRUNDLAGEN 2.1 INDUSTRIELLE ZENTRIFUGEN
• Stillstand (Stand Still)
• Anlauf (Start Up)
• Trommelschließprogramm (Bowlclosingprogram) [Optional]
• Betriebsbereit (Standby)
• Produkt (Product)
• Wasser (Water) [Optional]
• CIP (CIP) [Optional]
• Teil Entleerung (Partial Ejection) [Optional]
• Total Entleerung (Total Ejection) [Optional]
• Runter fahren (Slow Down)
• Notfall (Emergency)
Wobei die mit”Optional“ gekennzeichneten Sequenzen mit Vorsicht zu genießen
sind, denn eine Teil Entleerung oder eine Total Entleerung wird immer benötigt.
Diese sind nur optional, da es Fälle gibt, wo nur eins von beiden gebraucht wird.
Ebenfalls ist das Trommelschließprogramm in ca. 95% der Fälle Bestandteil in ei-
nem Separator Programm, aber jedoch nicht zu 100%. Des Weiteren sind CIP und
Wasser außer bei Mineralöl Separatoren immer Pflicht, da diese für die Reinigung
der Trommel zu ständig sind. In Abbildung 2.2 ist der fehlerfreie Durchlauf der
Sequenzen, eines Standard Separator dargestellt. Wobei die Notfall Sequenz und
die Transitionsbedingungen nicht mit abgebildet werden. Im Hinblick auf die CML,
muss diese es schaffen, diese Sequenzen abzubilden, die Eigenschaften dieser Sequen-
zen zu definieren und sie in Abhängigkeit zueinander zu stellen. Wie genau dieses
umgesetzt wurde, wird in dem Abschnitt 4 beschrieben.
Abbildung 2.2: Darstellung des Durchlaufs der Sequenzen bei einem Standard Se-parator ohne Nofall Sequenz und Transitionen
7
2 GRUNDLAGEN 2.2 4-SCHICHTEN ARCHITEKTUR
2.2 4-Schichten Architektur
Um die Konzepte, die sich hinter Modellierungssprachen und Metamodellierung ver-
bergen, besser verstehen zu können, wird an dieser Stelle die 4-Schichten Architektur
vorgestellt. In dem Buch UML 2.0 Glasklar wird diese Architektur so beschrieben,
dass sie auf zwei Grundsätzen basiert:
• Die höhere Schicht beschreibt die niedrigere Schicht, welche genau unter derhöheren Schicht liegt.
• Die niedrigere Schicht ist eine Instanz von der höheren Schicht
In der untersten Schicht M0, bzw. Laufzeitschicht, befindet sich der Separator und
stellt somit die Realität dar. Die Modellschicht M1, welche sich über der Lauf-
zeitschicht befindet, abstrahiert den Separator in ein Diagramm. Damit das Modell
allerdings gelesen werden kann, wird die Metamodellschicht (M2) benötigt, denn das
Metamodell gibt die Regeln für das Modell in der Modellschicht (M1) vor. Die letzte
Schicht ist die Metametamodellschicht (M3) und definiert die Elemente (Symbole
und Notationen) die für ein Metamodell zulässig sind.[8, S.35 ff] In Abbildung 2.3
ist die 4-Schichten Architektur dargestellt. Zudem steht in den Klammern jeweils
der direkte Bezug zu den Inhalten dieser Bachelorarbeit.
Abbildung 2.3: 4-Schichten Architektur, mit Bezugnahme zu den Inhalten der Ba-chelorarbeit Vorlage nach [4, S.30]
8
2 GRUNDLAGEN 2.3 MODELLIERUNGSSPRACHEN
In den Vorlesungsfolien für”Modellgetriebene Softwareentwicklung“ wird die 4-
Schichten Architektur noch detaillierter beschrieben, sodass in der Schicht M2 und
M3 eine Unterteilung stattfindet. Das Metametamodell bzw. das Metamodell be-
schreiben die Konzepte einer Domäne. Bei dem Metamodell handelt es sich um die
Domäne von industriellen Zentrifugen, bei dem Metametamodell hingegen um die
Domäne der graphischen Erstellung von Metamodellen. Diese besitzen eine stati-
sche Semantik und abstrakte Syntax. Die Sprache, die dem Metamodell, und die
Metasprache, die dem Metametamodell zugeordnet ist, besitzt das jeweilige Meta-
modell bzw. Metametamodell, eine konkrete Syntax und Semantik. Das bedeutet
zum Beispiel, wenn im Metamodell der Knoten”Timer“ definiert wird, ist dieser
erstmal abstrakt und wird dann durch die Sprache entweder textuell oder graphisch
spezifiziert.[9]
2.3 Modellierungssprachen
Die Modellierungssprachen (Modeling Language) ermöglichen es ein reales System
in einem Diagramm abstrakt zu beschreiben. Hierfür besitzen sie eine festgelegte
Syntax und Semantik. Eine Modellierungssprache ist zudem ein Metamodell, da
diese Sprache die Regeln für das Modell bzw. für das Diagramm vorgibt und somit
in der Schicht M2 zu finden ist. Zudem besitzt sie eine graphische Sprache um Mo-
delle beschreiben zu können. Es gibt eine Vielzahl solcher Modellierungssprachen,
die bekannteste ist die Unified Modeling Language (UML), welche exemplarisch
erklärt werden soll. Im Buch UML 2.0 Glasklar ist die Sprache folgender Maßen
definiert: Sie dient zur Modellierung, Dokumentation, Spezifizierung und Visuali-
sierung komplexer Systeme, unabhängig von deren Fach- und Realisierungsprinzip.
Sie liefert Notationselemente gleichermaßen für statische und dynamische Model-
le von Analysen, Design, Architektur und unterstützt insbesondere objekorientierte
Vorgehensweisen.[8, S.4] Mit dieser Beschreibung stimmt die UML mit der Defini-
tion einer Modellierungssprache überein. Somit liefert die UML das Werkzeug um
ein beliebiges System auf eine semiformale Art zu beschreiben. Jedoch entsteht aus
diesem Vorteil auch ein Nachteil, denn diese Sprache ist nicht formal. Aus diesem
Grund beschreibt die UML nicht in kompletter Exaktheit die Funktion und Um-
setzung des Systems. Trotzdem muss beachtet werden, dass die UML nicht nur auf
die bekannten Diagramme, wie das Klassendiagramm oder Use-Case Diagramm,
reduziert wird. Denn die UML liefert eine Vielzahl von unterschiedlichen Diagram-
men. So kann ein System zwar nicht mit einem UML Diagramm exakt beschrieben
werden, jedoch mit Hilfe mehrerer unterschiedlicher Diagramme die Exaktheit der
Systembeschreibung verbessert werden. Zum Beispiel wird ein Programm erst mit
dem Use-Case Diagramm analysiert. Anschließend wird die Struktur mit Hilfe ei-
9
2 GRUNDLAGEN 2.3 MODELLIERUNGSSPRACHEN
nes Klassendiagramms und einzelne Aktivitäten/Algorithmen mit Hilfe eines Akti-
vitätsdiagramms beschrieben. Deswegen liefert die UML den Schlüssel zum Erfolg
für die CML. Denn die nachfolgenden drei Diagramm Typen liefern den Grund-
stein für die CML. Diese Diagramme sind Bestandteile der Modellschicht M1, da sie
Instanzen vom Metamodell sind.
2.3.1 Zustandsautomat
Zustandsautomaten (State Machine Diagram) sind in der UML im Allgemeinen die
Kombination von Mealy- und Moore-Automaten, welche um neue Elemente ange-
reichert wurden. Somit sind sie eine Erweiterung der endlichen Automaten. Letzt-
endlich lässt sich mit Hilfe des Zustandsautomaten ein System beschreiben,
Abbildung 2.4: Zustandsautomat eines Separators
10
2 GRUNDLAGEN 2.3 MODELLIERUNGSSPRACHEN
welches sich zu jedem Zeitpunkt in einem bestimmten Zustand befindet. Eben-
falls muss der Übergang von einem in den nächsten Zustand ohne zeitliche Verzöger-
ung geschehen.[8, S.330] Wenn die beschriebenen Sequenzen aus dem Unterabschnitt
Separatoren als Zustände interpretiert werden, ermöglicht dieses Diagramm den Ab-
lauf des Separators zu beschreiben, da die Sequenzen in Beziehung zueinander ge-
setzt werden können. Es entsteht somit eine detailliertere Darstellung als in Ab-
bildung 2.2, welche in Abbildung 2.4 zu sehen ist. In der Abbildung sind zudem
die Notationselemente benannt und alle bis auf dem Guard sind selbsterklärend.
Der Guard ist nichts anderes als eine Bedingung, die wahr sein muss, damit die
Transition durchlaufen wird. Sie kann zudem in Verbindung mit einem Trigger ver-
wendet werden. Im Zustandsautomaten sind somit acht Zustände dargestellt, die
die Sequenzen repräsentieren. Zwischen den einzelnen Zuständen sind Transitionen
eingefügt worden, an denen teilweise auch Bedingungen (Trigger) geknüpft sind. So
kann zum Beispiel der Zustand Anlauf nur in den Zustand Trommelschließprogramm
übergehen, wenn die Nenndrehzahl erreicht wurde. Des Weiteren enthält jeder Zu-
stand, bis auf Betriebsbereit, bestimmte Verhalten, sodass beim Anlauf der Motor
eingeschaltet wird oder beim Produkt während des Eintritts das Zulaufventil auf
geht.
2.3.2 Kommunikationsdiagramm
Das Kommunikationsdiagramm (Communication Diagram) zeigt Interaktionen zwi-
schen Teilen einer meist komplexen Struktur. Das Abstraktionsniveau ist so gewählt,
dass das Zusammenspiel (Nachrichtenaustausch) zwischen den Kommunikations-
partnern und den Verantwortlichkeiten (wer macht was) herausgearbeitet werden.[8,
S.474] In Abbildung ist ein solches Diagramm dargestellt.
Abbildung 2.5: Kommunikationsdiagramm - Lied wechseln
11
2 GRUNDLAGEN 2.3 MODELLIERUNGSSPRACHEN
Diesmal wird jedoch kein Bezug zum Separator genommen, weil das Diagramm
im eigentlichen Sinne für die Beschreibung eines Separators nicht sinnvoll ist und
deswegen später für die CML stark verändert wird. Jedoch liefert dieses Diagramm
eine wertvolle Idee, nämlich Interaktionen zwischen komplexen Strukturen darstel-
len zu wollen. Damit der Aufbau des Diagramms bekannt ist, soll es anhand eines
Liedwechsels erklärt werden. Die Notationselemente werden wieder in der Abbildung
benannt und auf der sogenannten Lebenslinie werden die Kommunikationspartner
eingefügt. In der Abbildung ist letztendlich dargestellt, wie ein Zuhörer über eine
Fernbedienung ein Liedwechsel vornimmt. Dabei kommuniziert der Zuhörer über die
Fernbedienung mit dem Audiogerät.
2.3.3 Aktivitätsdiagramm
Ein Aktivitätsdiagramm (Activity Diagram) stellt Aktivitäten mit einem nichttrivia-
len Charakter dar. Eine Aktivität im Sinne der UML2 spezifiziert dabei die Menge
von potenziellen Abläufen, die sich in der Realität (im Programmiersprachenjar-
gon”
zur Laufzeit“) unter bestimmten Randbedingungen abspielen.[8, S.264] Somit
können mit Hilfe eines Aktivitätsdiagramms Abläufe beschrieben werden, um eine
Hardware Komponente auszulesen oder aber einen Prozessablauf.
Abbildung 2.6: Aktivitätsdiagram - Motor einschalten
12
2 GRUNDLAGEN 2.4 METAMODELLIERUNG
In Abbildung 2.6 ist ein solches Diagramm, für eine Hardware Komponente eines
Separators, dargestellt und die Notationselemente werden zudem benannt. Genauer
betrachtet bildet das Aktivitätsdiagramm die Hardware Komponente”Motor“ ab.
Hierbei wird nach dem Starknoten der Zustand des Motors geprüft. Wenn er aus
ist wird auf eine Einschaltbedingung geprüft. Ist diese wahr, wird der Motor einge-
schaltet, wenn nicht bleibt er aus. Dasselbe gilt für das Ausschalten des Motor, nur
das der Motor an sein muss bevor die Ausschaltbedingung abgefragt wird.
Nachbemerkung zu den UML Diagrammen
Alle drei vorgestellten UML Diagramme sind im Prinzip Graphen mit gerichteten
Kanten. Die spätetere CML wird diese Eigenschaft ebenfalls teilen, da Abläufe be-
schrieben werden.
2.4 Metamodellierung
Die Erstellung einer Modellierungssprache im Kontext von Model-Driven Software
Development (MDSD) wird als Metamodellierung (engl. Meta Modeling) bezeich-
net.[4, S.24] Des weiteren beschreibt Heiko Kern in seiner Präsentation, dass beim
Erstellen einer Modellierungssprache erst ein Metamodell spezifiziert werden muss,
welches die abstrakte Syntax definiert, bevor die konkrete Syntax und Semantik
definiert werden kann. Dabei legt die Syntax die Symbole bzw. Notationen fest,
die in der Modellierungssprache verwendet werden dürfen. Die Semantik definiert
schließlich die Bedeutung der Symbole bzw. der Notationen und legt die Kombinati-
onsmöglichkeiten dieser Elemente fest.[4, S.24] Somit wird bei der Metamodellierung
ein neues Metamodell mit einer Sprache, also die M2-Schicht, erstellt.
2.5 Codegenerierung
In dem Kapitel Codegenerierung im Buch”Modellgetriebenen Softwareentwicklung“
wird beschrieben, dass die Codegenerierung in einem sehr engen Zusammenhang mit
der Metamodellierung steht, da man das vorher entwickelte Modell weiter verarbei-
ten möchte. Dabei ist die Codegenerierung einfacher, wenn das Metamodell exakt
auf die Domäne zugeschnitten ist und die Architektur des Programmes gut gewählt
wurde. Zudem gewährleistet die Codegenerierung eine hohe Performance, da man
vorab konfigurieren kann, wie sich das System verhalten soll. Dieses ist besonders
wichtig bei Echtzeitsystemen. Des Weiteren kann eine passende Codegröße bestim-
met werden, die nur so groß ist, wie die Anwendung es erfordert. Bei eingebetteten
Systemen ist dieses ein wichtiger Punkt. Ebenfalls kann eine Fehlerfrüherkennung
implementiert werden.
13
2 GRUNDLAGEN 2.5 CODEGENERIERUNG
Generell müssen bei der Codegenerierung folgende typische Aufgaben der Reihe nach
abgearbeitet werden:
• Einlesen des Modells
• Verlinken des Modells
• Validieren des Modells
• Transformieren des Modells (M2T)
• Generieren des Codes (auf Basis von Modellen)
Der Codegenerator der in der Bachelorarbeit entwickelt wird, wird zur Laufzeit
des Basisprogramms ausgeführt, da die Erstellung des CMT mit Hilfe des Entwick-
lungstool Cinco erfolgt. Zudem wird durch die bereits vorhandene Schnittstelle
eines Codegenerator Plug-Ins (siehe Abschnitt 3.2), das Einlesen und das Verlinken
des Modells von Cinco übernommen, sodass die Modelle letztendlich noch validiert
und transformiert werden müssen, bevor der Code generiert werden kann. Diese drei
Aufgaben werden somit selbst in Cinco implementiert. Zudem müssen Codegene-
ratoren folgende Eigenschaften unterstützen:
• schreiben von Text in Dateien
• aus dem Eingabemodell Werte abfragen
• String Konkatenation aus dem statischen Text und den Informationen aus demModell.
Cinco sieht Java für die Implementierung des Codegenerators vor, sodass diese
Eigenschaften vorhanden sind. Für String Konkatenation gibt es zum Beispiel die
Klasse”StringBuilder“ aus dem Package
”java.lang“. In dieser Bachelorarbeit basiert
die M2T auf Templates. Dieses ist auch ein sehr verbreitetes Mittel. Templates sind
insbesondere dann sinnvoll, wenn zum einen der generierte Code viel statischen Text
enthält oder aber auch, wenn durch das Template die Codestruktur vorgegeben
wird.
1 class Template
2 {
3 public:
4 Template(void);
5 ~Template(void);
6
7 virtual SHORT update ();
8
9 private:
10
11 };
Listing 1: Template C++ Header, Einfügen privater Methoden
14
2 GRUNDLAGEN 2.6 BECKHOFF IPC - TWINCAT 3
Bei einem Steuerungsprogramm für eine industrielle Zentrifuge ist eher der zwei-
te Fall gegeben, weil die Codestruktur und die Syntax vorgegeben sind, aber die
eingefügte Logik variabel ist. Im Allgemeinen besteht ein Template aus einem be-
liebigem Text, der an bestimmten Stellen mit sogenannten Tags versehen ist. Diese
Tags enthalten Ausdrücke, die während des Generierungsvorgangs von der Template
Engine (dem Codegenerator) ersetzt werden.[10, S.139ff]
In Listing 1 ist ein Beispiel eines solchen Templates zu sehen. Dargestellt ist ein
C++ Header File in der private Methoden, an der Stelle”〈privateMethoden〉“ hin-
zugefügt werden sollen. Aus dem Grund das die eingefügte Logik sehr variable ist,
muss in das Template noch sehr viel variabler Code eingefügt werden. Somit werden
Algorithmen gebraucht die Logik in einem String zusammenfassen, sodass dieser an
der Stelle eines Tags eingefügt werden kann. Diese Algorithmen gilt es in 4.2.2 zu
entwickeln.
2.6 Beckhoff IPC - TwinCAT 3
Die Firma Beckhoff liefert ein vollständiges Steuerungssystem mit einem IPC und
Karten für digitale/analoge Ein-und Ausgänge. Die Kommunikation zwischen IPC
und Peripherie wird somit von Beckhoff bereitgestellt. Des Weiteren arbeitet Beck-
hoff mit Microsoft zusammen, sodass die Entwicklungsumgebung für Steuerungs-
programme in Visual Studio c© integriert ist. Dieses Gesamtpaket wird von Beckhoff
TwinCAT3 genannt. Bei dem Erstellen eines neuen Steuerungsprogramms ist zu
beachten, dass Beckhoff eine bestimmte Programmstruktur und Constraints vorgibt
um die Echtzeitfähigkeit zu gewährleisten. So können nur beim Start des Programms
Klassen allokiert werden, damit im Betrieb die Größe des Programms und somit sei-
ne Zykluszeit gleich bleiben.
Abbildung 2.7: vorgeschriebener Programmablauf von Beckhoff
Außerdem sind zum Beispiel alle Standard Input- und Output-Streams gesperrt,
damit sich das Programm nicht an einer Stelle blockieren kann. In Abbildung 2.7 ist
der vorgeschriebene Programmablauf dargestellt. Damit das Steuerungsprogramm
letztendlich auf einem IPC laufen kann, muss auf dem IPC ein Windows Betriebssy-
stem installiert sein. Hier ist ein Windows Embeeded Betriebssystem zu empfehlen.
Zudem muss die TwinCAT3 Runtime installiert werden.
15
2 GRUNDLAGEN 2.6 BECKHOFF IPC - TWINCAT 3
Abbildung 2.8: Beckhoff eXtended Automation Architectur nach Vorlage[2, S.3]
Diese Runtime sorgt dafür, dass die Echtzeitfähigkeit eingehalten wird, indem
ein Real-Time Kernel von Beckhoff in das Betriebssystem integriert wird. In diesem
Kernel läuft dann das Programm als Prozess ab. In Abbildung 2.8 wird die eXtended
Automation Architectur (XAA) dargestellt, welche einen guten Überblick über das
Steuerungssystem von Beckhoff liefert.[2] Die bereits programmierten Steuerungs-
systeme besitzen die Architektur, die in Abbildung 2.9 mit Hilfe eines Klassen-
diagramms dargestellt wird. Eine”GEA Main“ wird von der der
”Beckhoff Main“
während der Allokation allokiert. Aus Gründen der Übersicht wurde die”Beck-
hoff Main“ im Klassendiagramm nicht dargestellt, da der Fokus auf der eigenen
Architektur liegt. Anschließend allokiert die”GEA Main“ seine konkret benötigten
”GEA Sequences“ und
”GEA FunctionModule“. Dabei müssen die
”GEA Function-
Module“ zuerst allokiert werden, da den”GEA Sequences“ die Objekte der benö-
tigten”GEA FunctionModulen“ übergeben werden. Den
”GEA FunctionModulen“
werden hingegen die Referenzen von definierten Inputs, Outputs und Daten über-
geben, welche in der TwinCAT3 Module Class Editor (TMC) File6 definiert wurden.
6TMC File: Ist eine Datei, die mit Hilfe des TMC erstellt wird. Aus dieser Datei wird ein C++Header generiert, in der Structs definiert sind, auf die intern zugegriffen werden kann. Zudem sinddiese Structs nach außen sichtbar. Zusammenfassend wird im TMC alles definiert was später nachaußen sichtbar ist, wie Eingänge, Ausgänge und Daten.
16
2 GRUNDLAGEN 2.6 BECKHOFF IPC - TWINCAT 3
Die Daten, die in der TMC File definiert wurden, liegen im TwinCAT Transport
Layer und können somit von einem Open Platform Communications (OPC)7 Ser-
ver abgegriffen werden. Die Inputs und Outputs können über den Fieldbus einen
Eingang von einer Eingangskarte lesen oder einen Ausgang von einer Ausgangskarte
setzen. Somit kann mit Hilfe der Referenz direkt auf die Addressbereiche zugegriffen
werden, um die Inputs, Outputs und Daten auszuwerten.
Da TwinCAT3 keine eigenen logischen IC Bausteine, wie es bei einigen PLC Spra-
chen der Fall ist, mitbringt, müssen eigene Klassen (z.B.”GEA Timer“,
”GEA -
Counter“) geschrieben werden, die diese Funktionalitäten gewährleisten.
In den”GEA FunctionModulen“ wird die eigentliche Logik abgearbeitet, sodass die-
se Timer (Timer), Zähler (Counter) und Regler (Controller) benötigen, damit jedes
der”FunctionModule“ die passende Anzahl von diesen Objekten für sich allokiert.
Für die Alarme wird direkt auf eine Struct zugegriffen, die von der TMC File ge-
neriert wurde. Im Listing 2 ist diese Struct dargestellt. Nach dem Allokationszyklus
wird von der”Beckhoff Main“ die
”update-Methode“ der
”GEA Main“ aufgerufen.
Im ersten zyklischen Update wird die private Methode”firstCycle“ aufgerufen, wel-
che die Zykluszeit für die Timer setzt, da diese auch wie Counter arbeiten. Nur das
diese letztendlich immer die Zykluszeit addiert. Nach dem ersten Zyklus überprüft
die”GEA Main“ in welcher Sequenz sie sich befindet und entscheidet mit Hilfe be-
stimmter Bedingungen, in welche Sequenz sie springen muss, um diese zu updaten.
In der Sequenz selber werden die FunctionModule aktualisiert, die dann dafür sorgen
das z.B. Ausgänge gesetzt werden und Timer ablaufen [3].
1 typedef struct _stAlarm
2 {
3 STRING80 Massage;
4 bool Active;
5 } stAlarm , *PstAlarm;
6 };
Listing 2: Generierte Struct von der TMC File
7OPC, ist eine standardisierte Schnittstelle um Daten zwichen Anwendugen, von verschiedenenHerstellern in der Automatisierungstechnik, auszutauschen.
17
2GRUNDLAGEN
2.6BECKHOFFIP
C-TW
INCAT
3Abbildung 2.9: Klassendiagramm der TwinCat3 Steuerungssoftware
18
3 ENTWICKLUNGSTOOL - CINCO
3 Entwicklungstool - Cinco
Cinco (vollständig: Cinco SCCE Meta Tooling Suite) ist eine Entwicklungsumge-
bung für Modellierungstools, welche in Eclipse integriert ist. Mit Hilfe einer textuel-
len Metasprache, die sich in die zwei Spezifikationen”Meta Graph Language (MGL)“
und der”Meta Style Language (MSL)“ gliedert, kann ein neues Metamodell bzw.
eine neue Modellierungssprache erstellt werden. Somit ist Cinco in der M3 Schicht
aufgehängt. Die spätere CML wird mit Hilfe dieser beiden Metasprachen ausge-
drückt. Wenn das neue Metamodell mit Hilfe dieser Modellierungssprachen spezi-
fiziert wurde, kann aus diesem ein Java Programm generiert werden, welches das
neuentwickelte und domänenspezifische Metamodell beinhaltet und graphisch ab-
bildet. Es wird somit zum einen das Metamodell und zum anderen ein graphischer
Editor von der höheren Spezifikation (Metametamodell) vollständig generiert. Der
graphische Editor erlaubt es die graphischen Objekte, die das Metamodell später
beinhaltet, zu verschieben, zu vergrößern und in Relationen zueinander zu stellen.
In Abbildung 3.1 ist der graphische Editor mit ein paar graphischen Objekten ab-
gebildet. Des Weiteren stellt Cinco eine Schnittstelle für einen eigenen Codegene-
rator zur Verfügung, der aus dem generierten Metamodell einen Applikationscode
für das Steuerungssystem erzeugen soll. Aus dem Grund, dass sich der Codegene-
rator auf sein eigens entwickeltes Metamodell bezieht, kann dieser auch nur selbst
entwickelt werden, da er je nach Metamodell unterschiedlich komplex und schwierig
ausfällt.[7] In den folgenden Unterabschnitten wird die Metasprache von Cinco und
die Schnittstelle für den Codegenerator detaillierter erklärt.
Abbildung 3.1: generierter Graphischer Editor mit einem Modell
19
3 ENTWICKLUNGSTOOL - CINCO 3.1 METASPRACHE
3.1 Metasprache
Nach dem Cinco Users Manuel gibt es drei unterschiedliche Dateien:
• example.mgl
• example.style
• example.cpd
Dabei wird die example.mgl mit der MGL, die example.style mit der MSL und
die example.cpd mit der Cinco Produkt Definition (CPD) ausgedrückt. Die MGL
definiert die Eigenschaften und Regeln, die für ein Symbol bzw. für eine Notation
in einem Modell gelten. Alle Elemente basieren dabei auf zwei grundlegenden Ty-
pen, den Kanten (edges) und den Knoten (nodes). Zudem gibt es noch Container
(container), welche Kanten und Knoten beinhalteten können. Die MGL gibt somit
die statische Semantik und abstrakte Syntax vor. Die MSL definiert hingegen wie
diese Kanten und Knoten auszusehen haben. Somit wird hier die graphische Dar-
stellung spezifiziert und die Sprache, also die konkrete Syntax, definiert. Die CPD
definiert die Produkteigenschaften und ist somit der Einstiegspunkt der Codegene-
rierung. Über einen Rechtsklick auf die example.cpd-Datei kann das Cinco Produkt
generiert werden (Abbildung 3.2 a). Abschließend kann das generierte Produkt als
Eclipse Applikation ausgeführt werden (Abbildung 3.2 b)).[6]
(a) Generien des Cinco Pro-
duktes
(b) Ausführen des Cinco Produktes
Abbildung 3.2: Codegenerierung des Cinco Produktes und dessen Ausführung
20
3 ENTWICKLUNGSTOOL - CINCO 3.1 METASPRACHE
Die nächsten Unterpunkte befassen sich mit der konkreten Syntax dieser drei
Spezifikationen. Jedoch wird nicht alles bis ins kleinste Detail erklärt, sodass an
dieser Stelle bei weiterem Interesse auf das Cinco Manuel [6] verwiesen wird.
3.1.1 MGL
Mit der MGL werden die Eigenschaften von Knoten bzw. Kanten beschrieben.
Aus dem Grund das die MGL noch recht unbekannt ist, ist eine Auflistung der
Schlüsselwörter und den Annotationen im Anhang (A.1) zu finden. In Listing 3
ist der Quellcode für einen Knoten namens”Sequence“ dargestellt. Dieser Knoten
besitzt zwei Attribute, einen Namen (name) und eine Beschreibung (description).
Ebenfalls wird festgelegt, welche Arten von Kanten über”incomingEdges“ in den
Konten hineinkommen und welche über”outgoingEdges“ hinaus dürfen. Dabei wer-
den in den runden Klammern die Kantentypen mit einer unteren und oberen Grenze
für die Anzahl übergeben. Das bedeutet im Genauen für die”outgoingEdges“ in Li-
sting 3, das zwei unterschiedliche Typen hinausgehen dürfen, nämlich”Transition“
und”LabeledTransition“. Allerdings darf es mindestens und maximal eine Kante
sein. Ein”*“ bedeutet hingegen das es beliebig viele sein dürfen. Ebenfalls kann
über eine Trennung, wie es bei den”incomingEdges“ der Fall ist, die Anzahl von
Kanten für jeden Typen konkret definiert werden und nicht für beide zusammen.
Zudem erbt der Knoten vom Knoten”AbstractSequence“ und besitzt drei Annota-
tionen. Über die Style Annotation wird die Verlinkung zur Style Definierung in der
MSL Datei hergestellt und ein Attribut kann übergeben werden. Dieses Attribut
wird von der AbstractSequence geerbt. Die Annotation”@icon“ hinterlegt einen
Icon in der Palette und über die Annotation”@palette“ wird der Knoten in der
Palette zugeordnet.
1 @style(sequence ,"${name}")
2 @icon("icons/Sequence.PNG")
3 @palette("Sequences")
4 node Sequence extends AbstractSequence{
5 attr EString as description
6 incomingEdges (Transition[1 ,*], LabeledTransition[1 ,*])
7 outgoingEdges ({ Transition ,LabeledTransition }[1,1])
8 }
Listing 3: Styledefinierung eines Knoten (Node)
Das Listing 4 zeigt eine vollständige MGL Datei. In dem Listing ist zudem zu er-
kennen, dass ein Modell mit dem Namen”CenModel“ erstellt werden kann, welches
dann bestimmte Knoten und Kanten hat. Exemplarisch ist der Knoten”Sequence“
und die Kante”LabeledTransistion“ dargestellt. Ebenfalls wurden weitere Annota-
tionen, wie”@generatable“ hinzugefügt. Für die Bedeutung der anderen einzelnen
Annotationen wird erneut auf den Anhang (A.1.2) verwiesen. Zudem ist zu be-
21
3 ENTWICKLUNGSTOOL - CINCO 3.1 METASPRACHE
merken, dass der Knoten”Sequence“ auch die Annotation von
”AbstractSequence“
erbt und das über ein”enum“, ein Drop-Down-Menü genieriert wird. Denn das Mo-
dellattribute”CDestinationSystem“ kann nur den Wert
”Beckhoff“ oder
”Siemens“
annehmen.
1 @style("model/General.style") // Style Datei die den Style festlegt
2 @generatable("info.scce.cinco.product.cml.codegen.Generate","/src -gen/")
3 graphModel CenModel {
4 package info.scce.cinco.product.cml
5 nsURI "http :// cinco.scce.info/product/cml"
6 iconPath "icons/SomeGraph.png"
7 diagramExtension "cenmodel"
8
9 attr EString as description
10 attr EString as modelName
11 attr CDestinationSystem as destinationSystem
12
13 enum CDestinationSystem{
14 Beckhoff
15 Siemens
16 }
17 @doubleClickAction("info.scce.cinco.product.cml.action.OpenSeqFile")
18 @postCreate("info.scce.cinco.product.cml.hooks.SequenceDefaultValues")
19 abstract node AbstractSequence{
20 attr EString as name
21 }
22 ...
23 @style(sequence ,"${name}")
24 @icon("icons/Sequence.PNG")
25 @palette("Sequences")
26 node Sequence extends AbstractSequence{
27 attr EString as description
28 incomingEdges (Transition[1 ,*], LabeledTransition[1 ,*])
29 outgoingEdges ({ Transition ,LabeledTransition }[1,1])
30 }
31 ...
32 @style(labeledArrow , "${value}")
33 edge LabeledTransition {
34 attr CBool as value
35 }
36 ..
37 }
Listing 4: Beispiel MGL File
3.1.2 MSL
Wie schon erwähnt, muss dem einzelnen Knoten bzw. der einzelnen Kante ein Style
hinzugefügt werden. Exemplarisch wird dem Knoten”Sequence“ ein Style zugeord-
net. In Listing 5 wird dieser als Rechteck mit abgerundeten Ecken definiert. Des
Weiteren bekommt das Rechteck einen schwarzen Hintergrund. Die Kanten sind
grün, sowie die Schrift innerhalb des Rechtecks. Die Definierung einer Kante folgt
analog und weitere Schlagwörter können im Anhang nachgeschaut werden(A.2). Ne-
22
3 ENTWICKLUNGSTOOL - CINCO 3.2 CODEGENERIEUNGS PLUG-IN
ben einem Rechteck mit abgerundeten Kanten, kann zum Beispiel ein Kreis oder ein
Polygon definiert werden. Das übergebene Argument von der MGL File wird beim
Text, genauer beim Attribute value”%s“, eingefügt.
1 nodeStyle sequence(1) {
2 roundedRectangle recSequence {
3 appearance greenBorderBlackBackground
4 position (0,0)
5 size (170,50)
6 corner (8,8)
7 text {
8 appearance greenText
9 position relativeTo recSequence ( CENTER , MIDDLE )
10 value "%s"
11 }
12 }
13 }
Listing 5: Style Definierung einer Kante (Edge)
3.1.3 CPD
Abschließend soll noch die CPD Datei vorgestellt werden, welche in Listing 6 darge-
stellt ist. In der CPD Datei wird ein neues Cinco Produkt mit dem Namen”CMT“
definiert. Zudem sieht man, dass das Produkt nicht nur ein Modell besitzt, sondern
drei. Wie zum Anfang dieses Abschnittes erwähnt, kann über Rechtsklick auf diese
Datei letztendlich das Cinco Produkt generiert werden. Weitere Schlagwörter sind
wieder im Anhang unter A.3 zu finden.
1 cincoProduct CMT{
2 mgl "model/CenModel.mgl"
3 mgl "model/SeqModel.mgl"
4 mgl "model/FmModel.mgl"
5 about {
6 text "With this Tool you can modeling Centrifuge Software"
7 }
8 }
Listing 6: Beispiel CPD Datei
3.2 Codegenerieungs Plug-In
Wie bereits erläutert kann mit Hilfe von Cinco ein neues Metamodell definiert wer-
den, welches in einem graphischen Editor zur Verfügung gestellt wird. In Bezug auf
die Abbildung 1.1 kann die CML mit Cinco definiert werden, jedoch soll anschlie-
ßend aus einem Modell ein Applikationscode erzeugt werden. Aus diesem Grund
muss ein Codegenerator (Metaprogramm) geschrieben werden. Im Forschungsbericht
”Domain-Specific Codegenerator Modeling: A Case Study for Multi-faceted Concur-
rent Systems“ wird beschrieben, dass Cinco ein Meta Plug-In zur Verfügung stellt,
23
3 ENTWICKLUNGSTOOL - CINCO 3.2 CODEGENERIEUNGS PLUG-IN
welches die Annotation”@generatable“ in der MGL Datei interpretiert. Diese An-
notation verursacht, dass in dem graphischen Editor ein Generator Button eingefügt
wird, welcher bei Ausführung aus dem aktuell geöffneten Modell, einen Quellcode
erzeugt. Der Codegenerator muss selbstständig implementiert werden, da dem But-
ton ein Handler hinterlegt wird, der gegen ein Interface arbeitet. Zudem muss bei
der Annotation direkt die Klasse, die das Interface implementiert, hinterlegt werden.
Der Zielordner, in dem sich der Quellcode nach der Generierung befinden soll, muss
ebenfalls übergeben werden. Die Annotation sieht dann exemplarisch wie folgt aus:
@generatable(“info.scce.cinco.product.cml.codegen.Generate“,“/src-gen/“)
Im Listing 7 ist der grundlegende Aufbau der Klasse, die das Interface implementiert,
dargestellt. Im Listing 8 ist hingegen ein Ausschnitt aus dem generierten Handler
von Cinco dargestellt. Des Weiteren ist dort die Allokation der eigens geschriebenen
Klasse zu sehen.
1 import info.scce.cinco.product.cml.cenmodel.CenModel;
2 import de.jabc.cinco.meta.plugin.generator.runtime.IGenerator;
3 import org.eclipse.core.runtime.IPath;
4 import org.eclipse.core.runtime.IProgressMonitor;
5
6 public class ChooseGenerateLanguageCen extends implements IGenerator {
7 private AGenerateCen m_GenerateSep;
8
9 @Override
10 public void generate(CenModel model , IPath targetDir ,
11 IProgressMonitor monitor) {
12 ...
13 }
Listing 7: Eigene Klasse für die Codegenerierung
1 ...
2 IGenerator generator= new info.scce.cinco.product.cml.codegen.Generate ();
3 IProject project = null;
4 if (uri.isPlatformResource ()) {
5 String platformString = uri.toPlatformString(true);
6 IResource s = ResourcesPlugin.getWorkspace ().getRoot ().findMember(
platformString);
7 project = s.getProject ();
8 }
9 final org.eclipse.core.runtime.IPath outlet = project.getLocation ().append("/src -
gen/");
10 if(! outlet.toFile ().exists ()){
11 outlet.toFile ().mkdirs ();
12 }else if (! outlet.toFile ().isDirectory ()){
13 throw new RuntimeException("Outlet /MyProject/src -gen/centrifuge already exists
, but is no directory.");
14 }
15 generator.generate(graphModel ,outlet ,monitor);
16 ...
Listing 8: Aufruf der eigene Klasse in einem Cinco Handler
24
3 ENTWICKLUNGSTOOL - CINCO 3.2 CODEGENERIEUNGS PLUG-IN
Anschließend wird die Methode”generate()“ aufgerufen. Der
”generate()“ wird eine
Instanz des jeweiligen Modells übergeben. In diesem Falle handelt es sich um ein
”CenModel“. Aus dem Grund, dass das Cinco Produkt unter anderem mit Hilfe
der MGL Datei generiert wird, wird direkt eine Bibliothek generiert, die für jeden
Knoten, für jede Kante und für das Modell an sich Klassen enthält, mit der man
die Instanz des Modell interpretieren kann. Dieses bedeutet im Detail, dass man
sich keine Gedanken um das Einlesen und Verlinken des Modells machen muss, son-
dern nur um das richtige Interpretieren. Somit kann man zum Beispiel auf folgende
grundlegende Methoden zurückgreifen:
• Nachfolger und Vorgänger eines jeden Knoten (z.B. nodeA.getSuccessors())
• Einlesen der Parameter eines Knoten (z.B. NodeA.getName()) (allgemeine get-ter Methoden)
• Setzen von Paramentern eines Knoten (z.B. NodeA.setName()) (allgemeinesetter Methoden)
Es gibt natürlich noch viel mehr Methoden, die verwendet werden können, auch
für die Kanten. Diese werden aber an gegebener Stelle erläutert, wenn der selbstim-
plementierte Codegenerator erklärt wird. Ebenfalls kann über”instanceof“ der Typ
eines Knoten abgefragt werden, sodass abschließend auf einen bestimmten Knoten
gecastet werden kann [7].
Abbildung 3.3: Projektexplorer von Cinco
25
3 ENTWICKLUNGSTOOL - CINCO 3.3 ZUSAMMENFASSUNG
3.3 Zusammenfassung
Zusammenfassend kann mit Hilfe von Cinco das CMT implementiert werden, indem
Metamodelle mit Hilfe der Metasprache von Cinco spezifiziert werden und der
Codegenerator mit Java programmiert wird. In Abbildung 3.3 ist der Projektexplorer
vom letzten Stand zu sehen, damit nochmals visualisiert wird, welche Dateien selbst
angelegt werden müssen und welche generiert werden. Aus generierten Klassen und
selber implementierten Klassen ergibt sich schließlich das CMT.
26
4 DURCHFÜHRUNG
4 Durchführung
Die Durchführung der Bachelorarbeit wurde mit Hilfe des iterativ-inkrementellen
Vorgehensmodells umgesetzt [5, S.172ff]. Dabei wurde die CML und der Codege-
nerator parallel entwickelt. Die Literatur empfiehlt ebenfalls dieses Vorgehen, wenn
ein Tool für modellgetriebene Software Entwicklung entwickelt wird [10, S.59]. Die
Begründung liegt darin, dass der Auftraggeber bzw. der Kunde besser im Prozess
integriert ist, da dieser nachher mit Hilfe der CML Modelle erstellen muss. Ein wei-
terer wichtiger Vorteil dieses Verfahrens ist, dass so immer nach einer bestimmten
Zeit eine lauffähige Software vorhanden ist. Jedoch besitzt diese Vorgehensweise die
Gefahr, dass der Code nach einer gewissen Zeit zu einem”Flickenteppich“ werden
kann, da dieser immer wieder erweitert bzw. verändert wird und auch die Klassen-
diagramme sich laufend verändern. Aus diesem Grund wird zum Beispiel Refecto-
ring8 betrieben. Zudem werden bei der Durchführung noch weitere Best Practices
für die Software Entwicklung angewendet, die zum Beispiel in Scrum oder Extreme
Programming definiert sind. Diese sind unter anderem in den Vorlesungsfolien für
Software Engineering [1] bzw. in einem Buch über Software Engineering [5] zu fin-
den.
In diesem Abschnitt wird jedoch die Entwicklung der CML und die des Codegenera-
tors separat betrachtet. Es wird jeweils der finale Stand, der nach letzten Iteration
vorhanden war, beschrieben. Hierbei wird erst die CML im Unterabschnitt”Entwick-
lung der CML“ beschrieben und anschließend der Codegenerator in”Entwicklung
des Codegenerators“ erläutert. Die CML und der Codegenerator wurden beide in
Cinco implementiert, sodass daraus das CMT entstand. Die Codedokumentation
erfolgt mit Hilfe von Javadoc9.
4.1 Entwicklung der CML
Zu Beginn werden die allgemeinen Anforderungen an die CML analysiert. Bevor auf
die einzelnen Modelle, die die CML enthält, detaillierter eingegangen werden kann,
wird vorher die Beziehung der einzelnen Modelle untereinander definiert und die
CML im Allgemeinen entworfen. Es wird insgesamt drei unterschiedliche Modelle
geben. Diese werden in separaten Unterabschnitten detaillierter erklärt. An dieser
Stelle erfolgt auch die Spezifizierung der CML. Vorab ist zu erwähnen, dass das CMT
bisher nur die englische Benutzersprache unterstützt, sodass alle Abbildungen, die
Ausschnitte aus dem CMT abbilden, englische Bezeichnungen enthalten können.
8Ein Best Practice von Extreme Programming: Der Code wird optimiert und verschönert, nachjeder Iteration. Dabei ist wichtig, dass keine neue Funktionalität implementiert wird, sondern dieFunktionalität dieselbe bleibt.
9Javadoc ist ein Dokumentationstool, welches automatisch HTML-Dateien erstellt. DieseHTML-Dateien bilden das Programm ab und beschreiben dieses.
27
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
4.1.1 Analyse der Anforderungen an die CML
Um eine Modellierungssprache für Zentrifugen erstellen zu können, muss zuerst eine
Zentrifuge, bzw. in diesem Fall ein Separator, analysiert werden. Hierbei werden
die Anwendersicht und die Servicetechnikersicht betrachtet und in einem Use-Case
Diagramm (Abbildung 4.1) festgehalten. Dabei nehmen sie über das Human Machine
Interface (HMI) Einfluss auf einen Separator.
Abbildung 4.1: Use-Case Anwendersicht
Aus diesem Diagramm lassen sich die wesentlichen Merkmale für die Bedienung
und Konfiguration eines Separators ablesen, welche folgende sind:
• Manuelle Steuerung (Anwender und Service Techniker)
• Konfigurieren von Einstellungen (nur Service Techniker)
Neben dieser Anwendersicht bzw. der Servicetechnikersicht, liefert ein Blick auf einen
betriebenen Separator viele Erkenntnisse, welche bereits in den Grundlagen disku-
tiert worden sind und an dieser Stelle in einem Zustandsautomaten (Abbildung 2.4)
dargestellt wurden. Jedoch reicht es nicht aus, nur diese eine Sichtweise zu betrach-
ten, um die”Was-Sicht“ vollkommen beschreiben zu können. Deswegen muss eine
weitere Abstraktionsebene für die Beschreibung der”Was-Sicht“ eingeführt werden.
28
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Es werden deshalb die gefundenen Sequenzen (z.B. Stillstand, Hoch laufen, Be-
triebsbereit) nach der gleichen Vorgehensweise wie beim Separator analysiert. Als
Ergebnis erhält man mehrere Aufgaben, die ein Separator in einer Sequenz abarbei-
ten muss. Diese Aufgaben muss er immer wieder durchführen, bis alle abgeschlossen
sind. Diese sind zum Beispiel:
• Motor einschalten und überwachen
• Vibration überwachen
• Öl Pumpe einschalten und überwachen
Somit wird mit Hilfe von zwei Ebenen die”Was-Sicht“ vollständig beschrieben, denn
diese treffen darüber eine Aussage, was zum einen der Separator bzw. der Anwender
leisten muss, um eine bestimme Sequenz zu erreichen und zum anderen was der
Separator in der Sequenz für Aufgaben abarbeitet.
Diese Aufgaben werden abschließend in Funktionsbausteinen (Function Module) be-
schrieben, sodass ein Baukastenprinzip entsteht. Diese Bausteine beschreiben somit
die”Wie-Sicht“, denn sie geben darüber Auskunft wie der Separator im Einzel-
nen detailliert funktioniert. Deswegen müssen diese Funktionsbausteine am Ende in
einem Modell beschrieben werden. Hierbei wird jedoch der Abstraktionsgrad sehr
niedrig, da an dieser Stelle die Funktion der Funktionsbausteine detailliert und ex-
akt beschrieben werden muss.
Somit ergeben sich drei Ebenen bzw. Level, die es ermöglichen einen Separator als
Modell zu beschreiben.
• Ebene 1 : Zentrifugenebene (Level 1 : Centrifuge Level)
• Ebene 2 : Sequenzebene (Level 2 : Sequence Level)
• Ebene 3 : Funktionsbausteinebene (Level 3 : Function Module Level)
Bemerkung zur Namensgebung: Die Ebenen mit den dazugehörigen Modellen,
sind selbst entworfene Modelle und haben somit nichts mit den Namensvätern, wie
dem Sequence-Diagramm aus der UML, zu tun. Sie sind aus diesem Grund in einem
anderen Kontext zu verstehen, welcher in den folgenden Abschnitten erklärt wird.
Bemerkung zur Ebene 3: Wie bereits erwähnt, stellen die beiden obersten Ebe-
nen die”Was-Sicht”dar und die dritte Ebene die
”Wie-Sicht”. Die
”Was-Sicht“ deckt
somit die Bedürfnisse eines Verfahrenstechnikers ab, da dieser sich die Frage stellt:
”Was muss ich unternehmen, um ein bestimmtes Produkt separieren zu können,
sodass es sich in den Prozess integrieren lässt?“. Mit der”Wie-Sicht“ hingegen
beschäftigt sich der Programmierer, denn dieser stellt sich die Frage:”Wie muss
29
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
ich die einzelnen Aufgaben implementieren, damit der Separator die Funktionswei-
se liefert?“. Somit soll der Verfahrenstechniker die Ebene 3 im strengen Sinne gar
nicht verwenden. Deswegen war eine Überlegung, die dritte Ebene direkt in Appli-
kationscode zu schreiben, sodass die zweite Ebene exemplarisch auf fertige C++
Klasen zurückgreift, die sich in einer Bibliothek befinden. Jedoch wurde diese Idee
verworfen, da wie bereits in der Motivation beschrieben wurde das Langzeitziel dar-
in besteht, eine Modellierungssprache zu besitzen, die für alle Steuerungssysteme
Applikationscodes generiert. Dieses impliziert, dass die Möglichkeit vorhanden sein
muss auch für die Funktionsbausteine Applikationscodes für verschiedenen Zielplatt-
formen erzeugen zu können. Somit ist die Ebene 3 notwendig. Ein weiterer Vorteil
ist, dass die Programmierer, die die”Wie-Sicht“ umsetzten, eine einheitliche Mo-
dellierungssprache zur Verfügung haben. Zudem garantiert diese Ebene, dass ein
angelegtes Funktionsbausteinmodell für alle Zielplattformen direkt vorhanden ist.
Abbildung 4.2: Beziehung der CML Modelle zueinander
Zum Schluss muss noch die Beziehung der einzelnen Modelle zueinander genau
analysiert und deren Schnittstellen definiert werden. In Abbildung 4.2 wird diese
Beziehung visualisiert. In dieser Abbildung ist gut zu erkennen, dass ein Separator
mehrere Sequenzen besitzt und jede Sequenz auf Funktionsbausteine zugreifen kann.
Dabei können unterschiedliche Sequenzen auf denselben Baustein zugreifen. Dieses
muss gegeben sein, da zum Beispiel der Funktionsbaustein”Hauptmotor“ den Motor
in jeder Sequenz überwachen und steuern muss. Somit besteht ein vollständiges Mo-
dell von einem Separator aus einem Zentrifugenmodell, mehreren Sequenzmodellen
30
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
und mehreren Funktionsbausteinmodellen. Hierbei kann sogar noch feiner definiert
werden. Alle Separatoren bzw. Zentrifugen an sich, müssen mindesten sieben Se-
quenzmodelle besitzen. Diese sind Stillstand, Anlauf, Betriebsbereit, Produkt, Teil-
oder Totalentleerung runter fahren und Notfall (Vergleiche Abschnitt 2.1). Somit
gelten für die CML folgende Regeln:
• Das höhere Modell beschreibt die Verschaltung des darunter liegenden Modells
• Das untere Modell beschreibt einzelne Modell Elemente des höheren Modellsgenauer
• Beim obersten bzw. untersten Modell gilt nur die Sicht nach unten bzw. nachoben
Jedoch beschreibt jedes Modell an sich einen vollständigen Part des Applikationco-
des und ist in sich geschlossen. Denn die Architektur des Steuerungsprogramms von
Beckhoff ist identisch mit der vorhin beschriebenen Modell Struktur (siehe Abbil-
dung 2.9). Die Übereinstimmung ist sehr praktisch, da nun bei der Codegenerierung
gegen das bereits vorhandene Steuerungsprogramm validiert werden kann und kein
neues Steuerungsprogramm mit der Architektur, die zum Modell passt, entwickelt
werden muss. Im Hinblick, dass das Beckhoff Steuerungsprogramm in C++ pro-
grammiert wird, kann jedes Modell in eine Klasse umgewandelt werden.
4.1.2 Entwurf der CML
Wie schon in der Analyse erwähnt, basiert die CML auf drei Ebenen bzw. auf drei
Modellen, die es ermöglichen ein Steuerungsprogramm für eine Zentrifuge zu mo-
dellieren. Aus jedem Modell lässt sich ein Applikationscode erzeugen, welcher aber
nur Sinn im Verbund mit dem generierten Applikationscode der anderen Ebenen
macht. Die in der Analyse beschriebenen Regeln werden an dieser Stelle noch weiter
verfeinert:
• das untere Modell gibt Rückmeldung an das obere Modell
• das höhere Modell ruft das darunter liegende Modell auf
Dabei wird zwischen fünf Arten von Rückmeldungen unterschieden. Diese werden
in Tabelle 4.1 dargestellt. In der untersten Ebene, also in der Funktionsbaustei-
nebene, wird eine dieser Rückmeldungen zurückgegeben. Die Sequenzebene wertet
dann die Rückmeldung aus. Die Sequenzebene bekommt nicht eine, sondern meh-
rere Rückmeldungen zurück, da das Modell in der Ebene mehrere Modelle aus der
Funktionsbausteinebene erhält. Die Sequenzebene gibt dann die Rückmeldung mit
der höchsten Priorität an die Zentrifugenebene zurück. Dabei ist Priorität Fünf die
31
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Priorität Rückmeldung
1 wahr (true)2 falsch (false)3 Fehler (failure)4 Error (error)5 Notfall (emergency)
Tabelle 4.1: Prioritätstabelle für Rückmeldungen
höchste und Eins die niedrigste. In Bezug darauf, dass eine Zentrifuge immer eine
”Runter-Fahren“ Sequenz und eine
”Nofall“ Sequenz besitzt wird definiert:
• immer wenn ein Error Rückgabewert an die Sequenzebene zurückgegeben wird,wird ein Modell aus der Sequenzebene aufgerufen, welches die
”Runter-Fahren“
Sequenz beschreibt
• immer wenn ein Notfall Rückgabewert an die Sequenzebene zurückgegebenwird, wird ein Modell aus der Sequenzebene aufgerufen, welches die
”Notfall“
Sequenz beschreibt
Aus diesem Grund muss das Modell in der Sequenzebene nur noch den”Fehler-“,
”Falsch-“ oder
”Wahr-“ Rückgabewert auswerten. Doch diese Rückgabewerte lassen
sich bei genauer Betrachtung nochmals vereinfachen. Diese Vereinfachung wird aber
bei der Implementierung des Zentrifugenmodells thematisiert. Des Weiteren ist zu
bemerken das jedes Modell dieselben Properties besitzt, weil in jedem Modell das
Zielsteuerungssystem ausgewählt werden muss, sowie ein Name, eine Beschreibung
und ein Autor eingetragen werden müssen. Dabei spiegelt der Name zum Beispiel
den Klassennamen wieder.
4.1.3 Spezifizierung des Zentrifugenmodells
Das Zentrifugenmodell (Centrifuge Model), ist das Modell, welches sich in der Zen-
trifugenebene befindet und ist die höchste abstrakte Sicht auf eine Zentrifuge bzw.
auf einen Separator. In diesem Modell wird dargestellt, wie die einzelnen Sequen-
zen in Beziehung zu einander stehen und welche Bedingungen erfüllt sein müssen,
damit von einer Sequenz in eine andere gewechselt werden kann. Der Zustandsau-
tomat wird deshalb als Vorlage für dieses Modell gewählt. Der Zustandsautomat ist
sehr semiformal und kann somit viele unterschiedliche Anwendungen beschreiben.
Das Zentrifugenmodell benötigt diese Flexibilität nicht, da es nur eine industrielle
Zentrifuge bzw. einen Separator beschreiben soll.
32
4DURCHFÜHRUNG
4.1ENTW
ICKLUNG
DER
CML
Abbildung 4.3: Zentrifugenmodell für einen Separator
33
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Aus diesem Grund, müssen vorher Regeln definiert werden, damit das Modell
verbaler wird. Als erstes beinhalten diese, die Regeln, die in den Unterabschnitten,
”Analyse bzw. Entwurf der CML“ definiert wurden. Diese Regeln werden jetzt er-
weitert. Für das bessere Verständnis wird in Abbildung 4.3 ein Zentrifugenmodell
abgebildet. In dieser Abbildung ist zu erkennen, dass die”Kreuzungspunkte“ aus
der Abbildung 2.4 durch sogenannte Abfrageknoten (Request Nodes) genauer spe-
zifiziert wurden. Hier wird eine Bedingung auf”wahr“ oder
”falsch“ abgefragt. Es
gibt insgesamt drei verschiedene Typen von Abfrageknoten:
• HmiKeyRequest
• CardKeyRequest
• FailureRequest
In der CML sind diese in der Palette unter Request (Abfrage) zu finden. Alle drei
Knoten erben von einem abstrakten Knoten namens”CenRequest“. Die Abfra-
geknoten werden durch eine Route dargestellt, welche einen Text enthält. Dieser
Text beschreibt, welche Informationen auf welchem Wert abgefragt werden. Durch
Anwählen dieses Knoten öffnet sich ein Properties-Fenster, in dem die Eigenschaf-
ten spezifiziert werden müssen. Hierzu gehört, neben einer internen Benennung un-
ter”Name“, auch ein
”HardwareName“ der über ein Drop-Down-Menü ausgewählt
werden kann. Der”HardwareName“ gibt explizit darüber Auskunft, welcher digitale
Hardware Eingang an einer Karte, oder welche Taste an einem HMI abgefragt wird.
Zudem kann über”Value“ ausgesucht werden, ob die Bedingung auf
”true“ oder auf
”false“ ausgewertet wird.
Abbildung 4.4: Darstellung eines Abfrage Knoten mit dem Properties Fenster
34
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Hierfür wird noch die”Operation“ benötigt. Für die
”Operation“ sind alle boo-
leschen Vergleichsoperationen zulässig (!= , ==). Diese Attribute, bis auf den Hard-
warenamen, werden dem Knoten übergeben, sodass der Text innerhalb des Knoten
lesbar wird. In Abbildung 4.4 ist der”HmiKeyRequest“ groß mit seinem Properties
Fenster dargestellt. Zudem ist dort zu erkennen, dass vor der internen Benennung
noch”HMI.“ steht. Dieses visualisiert, dass es sich um einen
”HmiKeyRequest“
handelt und nicht um einen”HmiCardRequest“. Beim
”HmiCardRequest“ wird ein
”CARD.“ hinzugefügt. Diese beiden Knoten besitzen sonst dieselben Eigenschaf-
ten, bis auf dem Unterschied, dass andere”HardwareNames“ im Drop-Down-Menü
hinterlegt sind. In Listing 9 und 10 wird die Spezifikation dieses Knoten in Cinco
dargestellt. Listing 9 stellt dabei den Auszug aus der mgl Datei und Listing 10 den
Auszug aus der style Datei dar.
1 // Standard Attributes
2 abstract node CenStandardAttributes{
3 attr EString as name
4 }
5 ...
6 // Request abstract Node
7 abstract node CenRequest extends CenStandardAttributes{
8 incomingEdges ({ LabeledTransition ,Transition }[1,1])
9 outgoingEdges ({ LabeledTransition }[1,2])
10 }
11 // Request a HMI Input
12 @style(requestInput , "HMI","${name}","${operation}","${value}")
13 @icon("icons/CenModel/CardRequestInput.PNG")
14 @palette("Requests")
15 node HmiKeyRequest extends CenRequest{
16 attr EString as operation
17 attr CBool as value
18 attr HMIKeys as hardwareName
19 }
Listing 9: Auszug aus der CenModel.mgl für die Definierung des Knoten HmiRequest
1 ...
2 nodeStyle requestInput(4){
3 polygon polrequestInput{
4 appearance greenBorderGrayBackground
5 position(0,0)
6 points [(80,0)(160,45)(80,90)(0,45)]
7 text{
8 appearance greenText
9 position relativeTo polrequestInput ( CENTER , MIDDLE )
10 value "%s.%s %s %s"
11 }
12 }
13 }
14 ...
Listing 10: Auszug aus der General.style für die Definierung des Styles des Knoten
HmiRequest
35
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Im Listing 9 ist zudem zu erkennen, dass in einem Abfrageknoten nur eine Kante
hineingehen darf und zwei Kanten herausgehen dürfen. Dieses lässt sich damit be-
gründen, dass nach einem Abfrageknoten, der auf einen booleschen Wert abgefragt
wird, nur zwei Aussagen entstehen können (wahr oder falsch). Aus diesem Grund
splittet sich der Graph an dieser Stelle in zwei Zweige. Des Weiteren wird in Listing
9 definiert, dass diese Kanten vom Typ”LabeledTransition“ (Transition mit einer
Bezeichnung) sein müssen, weil über die”LabeledTransition“ die Aussage getroffen
wird, ob es sich nach der Abfrage um den”wahren“ oder um den
”falschen“ Zweig,
in Bezug auf die Abfrage, handelt. Über anwählen der Kante öffnet sich ebenfalls
ein Properties Fenster, indem über ein Drop-Down-Menü die Bezeichnung”true“
oder”false“ ausgewählt werden kann, damit nicht beliebige Bezeichnungen eingetra-
gen werden können. Neben der”LabeledTransistion“, besitzt das Zentrifugenmodell
noch die Transition. Diese beiden Typen von Kanten können in die Abfrageknoten
hineingehen, insgesamt darf aber nur eine Kante hineingehen, da nach jeder Abfra-
ge mindestens ein Zweig wieder in einen Sequenzknoten gehen muss und somit nur
noch ein Zweig frei wäre, um wieder in einen Abfrageknoten zu gehen. Bevor die Ab-
frageknoten abgeschlossen werden können, muss der Knoten”FailureRequest“ noch
erklärt werden. Denn dieser Knoten wertet den Rückgabewert”Fehler (failure)“ aus.
Sodass, wenn ein Sequenzmodell einen”Fehler“ zurück gibt, die Abfrage dies aus-
wertet und anschließend entscheidet, was dieses für eine Folge hat. Somit sind drei
von den fünf Rückgabewerten definiert. Zudem unterscheidet sich die Fehlerabfrage
von den anderen Abfragen in der Hinsicht, dass nur Kanten vom Typ”Transition“
hineingehen dürfen. Warum dieses so ist, wird später erläutert.
Vorab wurde der Sequenzknoten erwähnt. Dieser wird im Sequenzmodell als”Se-
quence“ bezeichnet. Hierbei handelt es sich um einen Knoten, der einen Zustand re-
präsentiert und somit vergleichbar ist mit dem Zustand im Zustandsautomaten. Ne-
ben den Sequenzknoten gibt es noch Bibliothekssequenzknoten (Library Sequences),
die ebenfalls einen Zustand repräsentieren. Sequenzknoten werden als Rechteck dar-
gestellt. Somit gibt es zwei Arten von Sequenzknoten. Die Unterscheidung der bei-
den Knoten liegt darin, dass ein Sequenzknoten definiert werden muss, indem ein
Sequenzmodell angefertigt wird. Bei einer Bibliothekssequenz wurde bereits ein Se-
quenzmodell erstellt und für richtig erklärt, sodass dieses als vorhandene”Black-
Box“ betrachtet werden kann. Die Menge der Bibliotheks-Sequenzen wird sich stetig
erweitern. Bisher wurde nur eine Sequenz für den Notfall als Bibliothekssequenz hin-
terlegt. Dieser Knoten heißt”EmergencySequenzeLib“. Die Sequenzknoten besitzen
folgende Properties:
• Name (Name: gibt die interne Benennung an und wird dem graphischen Objektübergeben)
36
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
• SequenceTyp (der Sequenztyp gibt an, um welchen Typ Sequenz es sich han-delt (Sillstand, Ablauf,. . . ) und kann über ein Drop-Down-Menü ausgewählt
werden)
• Description (Gibt eine Beschreibung an, besonders wichtig bei einer LibrarySequenz)
• DestinationFolder (Gibt den Ordner an, in dem sich das zugehörige Sequenz-modell befindet. Dieses wird für ein Zusatz-Feature benötigt, welches bei Dop-
pelklick das Modell öffnet, bzw. ein neues Modell erstellt, wenn kein Modell
bisher vorhanden ist)
Bei Bibliothekenssequenzen werden diese Properties über die Annotation”@post-
Create“ gesetzt. Hierbei erhält der Knoten einen Handler, der aufgerufen wird, wenn
der Knoten neu erstellt wird. Die Implementierung der zugehörigen Java Klasse ist
in Listing 11 zu sehen.
1 /**
2 * Sets the Properties for EmergencySequence
3 *
4 * @author Nils
5 */
6 public class PostCreateEmergencySequence extends CincoPostCreateHook <
EmergencySequence > {
7
8 @Override
9 public void postCreate(EmergencySequence emergencySequence) {
10 emergencySequence.setName("EmergencyNormalLib");
11 emergencySequence.setSequenceTyp(CSequenceTyp.EMERGENCY);
12 emergencySequence.setDestinationFolder("Sequence");
13 emergencySequence.setDescription("A water valve opens and then
14 water flows in the bowl. Because of this the bowl slow down faster.");
15 }
16 }
Listing 11: Implementierung einer Java Klasse für eine postCreate Annotation
Des Weiteren können in die Sequenz Knoten beliebig viele Kanten hineingehen, aber
es darf nur eine Kante vom Typ Transition hinausgehen. Die Begründung liegt dar-
in, das Sequenz Knoten von beliebig vielen anderen Knoten (Abfrageknoten und
Sequenzknoten) erreicht werden können, aber nach einer Sequenz klar sein muss,
welche Sequenz folgt. In Bezug auf die Abbildung 4.3 bedeutet dieses, dass nach
der Sequenz”Start up“ nur die Sequenz
”Standby“ folgen kann (ausgenommen sind
natürlich die Fälle, in denen ein Error oder ein Notfall Rückgabewert zurückgegeben
wird). An dieser Stelle kommen die letzten beiden Rückgabewerte ins Spiel, denn
”Start Up“ kann nur in
”Standby“ wechseln wenn der Rückgabewert
”wahr“ ist.
Es fehlt somit nur noch der Rückgabewert”falsch“. Dieser bedeutet, dass nicht alle
Bedingungen erfüllt sind, um die Sequenz wechseln zu können. Wenn eine Sequenz
37
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
unterschiedliche Nachfolger haben soll, müssen Abfragen eingefügt werden, damit
wieder genau definiert ist, wie der Sequenzwechsel erfolgt.
Im Hinblick auf die Codegenerierung muss eine weitere Bedingung eingefügt wer-
den. Die Abfragen werden in dem Applikationscode nur dann abgefragt, wenn der
Rückgabewert”wahr“ oder
”falsch“ ist. Dieses ist deshalb sinnvoll, weil bei
”Er-
ror“ und”Notfall“ vordefinierte Wechsel passieren und die Sequenz bei
”falsch“ in
derselben Sequenz bleiben soll. Jedoch wäre es unerwünscht, wenn vor einem”Fai-
lureRequest“ ein”HmiKeyRequest“ erfolgt. Aus diesem Grund muss die
”Failure-
Request“ direkt nach einem Sequenzknoten eingefügt werden. Dieses wird dadurch
gewährleistet, indem bei einem”FailureRequest“, wie schon erwähnt, nur eine Kante
von Type”Transition“ hineingehen darf. Somit kann diese nur direkt nach Sequen-
zen folgen und nicht nach einem Abfrageknoten.
Neben dem Knoten, der den Start definiert, gibt es zwei Rückgabeknoten (”Re-
turnError“ und”ReturnEmergency“) in diesem Modell, wobei die Return Knoten
für die Visualisierung der definierten Regeln sorgen. Diese besitzen als Grundform
einen Kreis. In den Startknoten, sowie in den Rückmeldeknoten, können somit keine
Kanten hineingehen und es darf nur eine Kante von dem Typ Transition hinausge-
hen. Ebenfalls wird später bei der Validierung des Modells abgefragt, ob nach dem
Startknoten immer eine Sequenz von dem Typ”StandStill“, nach dem
”ReturnEr-
ror“ eine Sequenz von dem Typ”SlowDown“ und nach dem
”ReturnEmergency“
eine von dem Typ”Emergency“ folgt. Die Rückmeldeknoten werden mit ihren Se-
quenzen in einem Container dargestellt. So wird ersichtlich, dass diese nichts mit
der Logik an sich zu tun haben, sondern es sich um definierte Regeln handelt. Ab-
schließend ist zu bemerken, dass in diesem Modell auch Schleifen modelliert werden
können. Im Genauen bedeutet dieses, dass von einer späten Sequenz, wie eine vom
Typ”SlowDown“, zum Anfang zurückgekehrt werden kann. Denn immer wenn eine
Sequenz aufgerufen wird, beginnt ein neuer Zyklus. Nach dem Zyklus wird dann
entschieden, was im nächsten Zyklus ausgeführt wird, also welche Sequenz durch-
laufen wird. Deshalb muss jede Sequenz wieder erreicht werden können. Es bedeutet
aber auch, dass in den folgenden Modellen keine Schleifen mehr erlaubt sind, da die-
se einen zyklischen Ablauf stören würden. Im Worst Case wäre dieses eine Endlos
Schleife. Alle Knoten bzw. Kanten werden mit ihren Symbolen, Argumenten bzw.
Properties in Tabellen im Anhang unter B.1 dargestellt.
4.1.4 Spezifizierung des Sequenzmodell
Das Sequenzmodell (Sequence Model) ist das Modell, welches sich in der Sequenze-
bene befindet und ist eine detailliertere”Was-Sicht“ auf die Zentrifuge bzw. auf den
Separator. Das Sequenzmodell gibt an, was genau in einer Sequenz passiert. Die-
ses Modell ist das vermutlich einfachste von den drei Modellen der CML, denn es
38
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
gibt an, welche Funktionsbausteine sich in einer Sequenz befinden. Als Vorbild wird
das Kommunikationsdiagramm genommen, weil dieses Interaktionen von komplexen
Strukturen beschreibt. Aus diesem Grund soll das Sequenzmodell die Interaktionen
der komplexen Funktionsbausteine zueinander beschreiben. Jedoch wird das Kom-
munikationsdiagramm sehr stark verändert, sodass das Element”Nachrichtenname“
wegfällt und die Richtung des Nachrichtenflusses vorgegeben wird. Deswegen erfolgt
der Fluss immer in einer Richtung. Die Lebenslinie bleibt jedoch erhalten und die
Knoten repräsentieren die Kommunikationspartner, die es im Kommunikationsdia-
gramm gibt. Letztendlich besitzt das Modell die Knoten”SeqStart“,
”SeqEnde“ und
”FunctionModule“.
”SeqStart“ und
”SeqEnde“ werden wieder mit Hilfe eines Krei-
ses dargestellt und der”FunctionModule“ als Rechteck. Der
”FunctionModule“ re-
präsentiert dabei ein Modell welches in der Funktionsbausteinebene modelliert wur-
de. Zudem können durch das Bibliothek Prinzip, welches im Zentrifugenmodell schon
vorgestellt wurde, beliebig viele”FunctionModule“ als Bibliotheksbausteine existie-
ren. Dabei unterscheiden sich die Properties bei jedem Bibliotheksbaustein, denn je-
der Baustein verarbeitet andere Aufgaben. Aus dem Grund, dass zum Beispiel, ein
Funktionsbausteinmodell von einem Hauptmotor (MainMotor) eine Rückmeldung
überwacht, die zeitlich verzögert ist, muss die Möglichkeit bestehen, diese zu kon-
figurieren. Dieses kann in den Properties eingestellt werden, wie in Abbildung 4.5
zu sehen ist. Bei genauerer Betrachtung, definiert der”SeqStart“ Knoten den Ein-
stiegspunkt in die Sequenz und der”SeqEnde“ Knoten den Ausgangspunkt.
Abbildung 4.5: Properties eines Funktionsbaustein als Bibliotheksbaustein im Se-quenzmodell
39
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
Abbildung 4.6: Sequenzmodell einer kleinen Start Up Sequenz
Zwischen den”SeqStart“ und
”SeqEnd“ Knoten können
”FunctionModule“ ein-
gefügt werden, die über einfach gerichtete Verbindungen miteinander verbunden
werden, sodass eine einfache Aneinanderreihung von”FunctionModule“ erfolgt. So-
mit geht aus jedem”FunctionModule“ Knoten die Kante
”Transition“ hinein und
heraus, sodass nur der Kanten Typ”Transition“ in diesem Modell existiert. In
”Se-
qStart“ geht wiederum lediglich eine”Transition“ nur heraus und in
”SeqEnd“ eine
nur hinein. Die Abbildung 4.6 zeigt ein sehr vereinfachtes Modell für eine”StartUp“
Sequenz. Trotzdem lässt sich das Prinzip sehr gut an dieser Abbildung erklären.
Jeder”FunctionModule“, der sich in der Sequenz befindet wird nacheinander aufge-
rufen und dadurch wird eine Aufgabe erledigt, welche im Funktionsbausteinmodell
definiert wurde. Nach Abarbeiten einer Aufgabe, gibt der zugehörige”Function-
Module“ eine Rückmeldung. Wir nehmen an, dass zum Beispiel der Bibliotheks-
baustein”MainMotorLib“ den Rückgabewert
”falsch“, der
”LubricationOilWithOil-
PUmp“ Funktionsbaustein”Error“ und der
”EmergencyStop“ Funktionsbaustein
”true“ zurückgibt. Ein Methode namens
”checkFmReturnValue“, die fest hinterlegt
ist in der abstrakten Klasse”GEA Sequence“ (siehe Abbildung 2.9), wertet dieses
aus und gibt letztendlich den Rückgabewert”Error“ (besitzt die höchste Priorität)
an das Zentrifugenmodell zurück. In diesem Modell ist keine Rückführung einer
Transition auf einen, in der Vergangenheit liegenden, Knoten erlaubt, da man sich
zu diesem Zeitpunkt in einem Zyklus befindet und somit sequentielles Abarbeiten
40
4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML
gewährleistet sein muss. Somit muss die Richtung des Nachrichtenflusses vorgege-
ben werden. Alle Knoten bzw. Kanten sind wieder mit ihren Symbolen, Argumenten
bzw. Properties in Tabellen im Anhang unter B.2 zu finden.
4.1.5 Spezifizierung des Funktionsbausteinmodells
Das Funktionsbausteinmodell (Function Module Model) ist das Modell, welches
sich in der Funktionsbausteinebene befindet und ist die”Wie-Sicht“ auf die einzel-
nen Funktionen einer Zentrifuge bzw. eines Separators. Somit wird an dieser Stelle
die Funktionsweise einer Hardware Komponente bzw. eines Prozessablaufs exakt
beschrieben. Als Basis wird das Aktivitätsdiagramm (Abbildung 2.6) genommen.
Dieses Diagramm besitzt zwei zentrale Knoten, die”Kontrollknoten“ und die
”Ak-
tionen“, die sehr verbal ausgelegt sind. Diese werden formalisiert, indem definiert
wird, wie die Aktionen beschrieben werden und der Kontrollknoten eine Abfrage
darstellt, die etwas auf”true“ bzw.
”false“ abfragt. Der Startknoten bleibt erhal-
ten. Der Endknoten hingegen wird genauer spezifiziert, weil der Funktionsbaustein
unterschiedliche Rückmeldungen an das Sequenzmodell geben kann. Das Modell
basiert letztendlich auf drei verschiedenen Type
Recommended