Modellbasierte Modellierung von industriellen Zentrifugen mit … · 2015. 7. 15. · Industrielle Zentrifugen sind ein wichtiger Bestandteil f ur die Aufbereitung und Ver-arbeitung

Fachbereich:Elektrotechnik und Informatik

Modellbasierte Modellierung von

industriellen Zentrifugen mit

Codegenerierung für Steuerungssysteme

Bachelorarbeit

Autor: Nils Wortmann

Matrikel-Nummer 730377

eingereicht am: 17.07.2015

Firma: GEA Westfalia Separator Group GmbH

Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster

Zweitprüfer: Dipl.-Ing., MBA Axel Hessenkämper,

GEA Westfalia Separator

INHALTSVERZEICHNIS

Inhaltsverzeichnis

Abkü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 Aktivitä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 Durchfü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 Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XI

A.1.2 MGL Annotations . . . . . . . . . . . . . . . . . . . . . . . . XI

A.2 MSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

A.2.1 MSL Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XII

A.3 CPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

A.3.1 CPD Schlüsselwörter . . . . . . . . . . . . . . . . . . . . . . . XIII

B CML Symbole und deren Bedeutung XIV

B.1 Zentrifugenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV

B.2 Sequenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII

B.3 Funktionsbausteinmodell . . . . . . . . . . . . . . . . . . . . . . . . . XXI

III

ABKÜRZUNGSVERZEICHNIS

Abkü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 für die Aufbereitung und Ver-

arbeitung von Medien in einer ganzen Prozesslinie. Sie sorgen dafü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 durchgeführt werden kann, die aber

in der Regel keine Kenntnisse ü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 Domänen spezifischem Fachwissen besitzen,

aber nicht über die notwendigen Programmierkenntnisse verfügen, die Möglichkeit

erhalten, das Fachwissen in ein Steuerungsprogramm zu transferieren. Hierbei han-

delt es sich, wie bereits erwähnt, um die Domäne der prozesstechnischen Steuerung

von industriellen Zentrifugen. Dieses führt dazu, dass die Anwendersoftware eine

Metaebene besitzt, mit der Modelle für industrielle Zentrifugen modelliert werden

können. Aus diesem Grund muss eine Metamodellschicht mit Hilfe der Metamodel-

lierung entwickelt werden. Diese Metamodellschicht enthält die Modellierungsspra-

che Centrifuge Model Language (CML). Zudem muss neben der Metamodellschicht

ein Codegenerator implementiert werden, damit aus einem Modell ein Applikations-

code für ein Steuerungsprogramm generiert werden kann. Jedoch gibt es nicht nur

ein Steuerungssystem, auf dem das Steuerungsprogramm läuft. Deswegen muss die

Möglichkeit bestehen, dieses Steuerungsprogramm für unterschiedliche Steuerungs-

systeme generieren zu kö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 möglich.

1.1 Unternehmensprofil

Die GEA Westfalia Separator Group GmbH wurde 1893 in Oelde (Deutschland)

gegründet. Jedoch hieß sie damals noch Ramesohl & Schmidt oHG. Erst im Jahre

1941 ä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 über die Erstellung vonModellen entwickelt wird und nicht über die Programmierung von Applikationcode.

1

1 EINLEITUNG 1.2 HINTERGRUND UND MOTIVATION

Separatoren und Dekanter sind Maschinen, genauer industrielle Zentrifugen, welche

Flüssigkeiten und Feststoffe voneinander trennen (zum Beispiel Öl von Wasser). Am

Standort Oelde sind ca. 1300 Mitarbeiter beschäftigt, weltweit ca. 3600. Damit ist

Oelde der größ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 über 3000 ver-

schieden Prozessen und Verfahren. Dieses Know-how muss in Steuerungsprogramme

umgesetzt werden. Bevor der Verfahrenstechniker mit dem Programmierer über die

Umsetzung des Steuerungsprogramms sprechen kann, muss mit dem Kunden das

passende Verfahren für sein Medium ausgewä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 dafür, dass viele un-

terschiedliche Programmierkenntnisse benötigt werden. Aus diesem Grund soll eine

Metaebene ü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 möglich

sein, die Modelliersprache so zu entwickeln, dass der Verfahrenstechniker diese auch

anwenden kann, um ein Modell für eine Zentrifuge zu modellieren. Wenn des Weite-

ren aus dem Modell ein Applikationscode für Steuerungssysteme erzeugt wird, hätte

dieses zur Folge, dass der am Anfang beschriebene Arbeitsprozess verkürzt wird. Zu-

sammenfassend liegt die Motivation darin, den Arbeitsablauf zu optimieren.

1.3 Zielsetzung

Das Ziel ist ein Proof of Concept, für die Generierung von Applikationscodes aus ei-

ner Metaebene heraus, anzulegen. Hierfür muss die CML entwickelt werden. Danach

wird diese Modellierungssprache mit Hilfe einer Entwicklungsumgebung für Model-

lierungstools Cinco in eine lauffähige Anwendersoftware umgesetzt, mit der Modelle

für industrielle Zentrifugen erzeugt werden kö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 für die Verwendung eines Metaprogramms.

Somit besitzt die Software (CMT) die Eigenschaft aus einer Metaebene einen Ap-

plikationscode fü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 für eine industrielle Zentrifuge modelliert werden. Für den Codegenerator

wird sich zuerst einmal auf ein Steuerungssystem fokussiert, nämlich auf ein IPC

der Firma Beckhoff (TwinCAT3). Eine Schnittstelle für weitere Codegeneratoren

soll aber implementiert werden. Das Ziel ist letztendlich mit Hilfe des CMT ein

Modell für eine Zentrifuge, genauer für einen Separator, zu modellieren, um dann

einen Quellcode fü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

Zunächst werden die für die Umsetzung benötigten Grundlagen betrachtet. Der Ein-

stieg erfolgt mit der Erklärung der Funktionsweise von industriellen Zentrifugen und

geht über zu den theoretischen Grundlagen (4-Schichten Architektur, Modellierungs-

sprachen, Metamodellierung, Code Generierung). Abschließend wird im Abschnitt

der Grundlagen die Zielplattform (Beckhoff - TwinCat3) für den modellierten Quell-

code vorgestellt. Für die Entwicklung des CMT wird das Entwicklungstool Cinco

im Abschnitt”Entwicklungstool - Cinco“ vorgestellt. Im Abschnitt Durchführung

wird zuerst die Entwicklung der CML vorgestellt, bevor auf die Entwicklung des

3

1 EINLEITUNG 1.4 GLIEDERUNG

Codegenerators eingegangen wird. Nachdem die rudimentären Funktionen des CMT

lauffähig sind, ist ein zusätzliches Feature programmiert worden. Bevor der Inhalt

der Bachelorarbeit zusammengefasst und ein Ausblick gegeben wird, wird ein Fazit

über das erreichte gezogen.

4

2 GRUNDLAGEN

2 Grundlagen

In diesem Abschnitt werden die Grundlagen erklärt, die für die Umsetzung des Proof

of Concept erforderlich sind. Als erstes werden industrielle Zentrifugen erklärt, damit

der fachliche Kontext für das Verstä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 erklärt, damit

die Begriffe eindeutig eingeordnet werden können. Im Abschnitt Modellierungsspra-

chen wird die bekannteste aller Modellierungssprachen, nämlich die UML (Unified

Modeling Language) vorgestellt, da diese wichtige Grundlagen fü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 für einen IPC von Beckhoff generieren. Des-

wegen muss eine Model to Text Transformation (M2T) durchgeführt werden. Wie

eine solche Transformation umgesetzt werden kann, wird im Unterabschnitt Code-

generierung erklärt. Abschließend wird das Zielsteuerungssystem (TwinCAT3) mit

der bereits angewendeten Software Architektur für Applikationen erläutert.

2.1 Industrielle Zentrifugen

Es gibt zwei Arten von industriellen Zentrifugen, die Separatoren und die Dekan-

ter. Der größ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 Partikelgrößen ab 0,5 µm und ein Dekanter

Partikelgrößen ab 5 µm trennen kann. Außerdem beträ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 hö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 Trägheits-

kraft wirkt eine größere Kraft auf Medien mit einer größeren Dichte. Dieses bedeutet,

dass eine Zentrifuge durch eine bestimmte Drehzahl Medien voneinander trennen

kann. Die Formel (1) spiegelt genau dieses wieder, nämlich das Teilchen mit größerer

Dichte, durch die auf sie wirkende größere Radialkraft, an den Rand der Zentrifuge

gedrückt werden.

Fr = ρV r(2πn)2 (1)

Im Hinblick darauf, dass ein Steuerungsprogramm für einen Separator modelliert

werden soll, wird der Separator spezifischer erklärt. Bei einem Separator wird zwi-

schen zwei Arten von Separatoren unterschieden, einmal die Klärer und einmal die

Trenner. Klärer trennen eine Flüssigkeit und einen Feststoff voneinander. Trenner

hingegen trennen zwei Flüssigkeiten und einen Feststoff voneinander. Dieser Trenn-

prozess muss steuerungstechnisch geregelt und überwacht werden. Jedoch gibt es

nicht nur den einen absoluten Trennprozess, sondern es gibt eine Vielzahl von un-

terschiedlichen Prozessen, die abhä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

über eine Zeitrampe auf 6000 1/min hochgefahren, weil kein Initiator für die Dreh-

zahlmessung verbaut wurde oder aber der Separator besitzt diesen Initiator und

kann messen, wann die Nenndrehzahl erreicht wurde. Andere Beispiele für Unter-

scheidungen in der Hardware sind:

• mit bzw. ohne Vibrationsü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 können. Deswegen muss der

ganze Prozess ü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 lä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 für Separatorengibt, wie zum Beispiel Bier von Hefe Stückchen trennen oder Wasser von Öl

4Herzstück eines Separators: Die Trommel dreht sich mit der Nenndrehzahl und sorgt fü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 benötigt.

Diese sind nur optional, da es Fälle gibt, wo nur eins von beiden gebraucht wird.

Ebenfalls ist das Trommelschließprogramm in ca. 95% der Fälle Bestandteil in ei-

nem Separator Programm, aber jedoch nicht zu 100%. Des Weiteren sind CIP und

Wasser außer bei Mineralöl Separatoren immer Pflicht, da diese für die Reinigung

der Trommel zu stä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 Abhä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 kö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 Grundsätzen basiert:

• Die höhere Schicht beschreibt die niedrigere Schicht, welche genau unter derhöheren Schicht liegt.

• Die niedrigere Schicht ist eine Instanz von der höheren Schicht

In der untersten Schicht M0, bzw. Laufzeitschicht, befindet sich der Separator und

stellt somit die Realität dar. Die Modellschicht M1, welche sich über der Lauf-

zeitschicht befindet, abstrahiert den Separator in ein Diagramm. Damit das Modell

allerdings gelesen werden kann, wird die Metamodellschicht (M2) benötigt, denn das

Metamodell gibt die Regeln für das Modell in der Modellschicht (M1) vor. Die letzte

Schicht ist die Metametamodellschicht (M3) und definiert die Elemente (Symbole

und Notationen) die für ein Metamodell zulä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 fü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 Domäne. Bei dem Metamodell handelt es sich um die

Domäne von industriellen Zentrifugen, bei dem Metametamodell hingegen um die

Domä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) ermöglichen es ein reales System

in einem Diagramm abstrakt zu beschreiben. Hierfür besitzen sie eine festgelegte

Syntax und Semantik. Eine Modellierungssprache ist zudem ein Metamodell, da

diese Sprache die Regeln für das Modell bzw. für das Diagramm vorgibt und somit

in der Schicht M2 zu finden ist. Zudem besitzt sie eine graphische Sprache um Mo-

delle beschreiben zu können. Es gibt eine Vielzahl solcher Modellierungssprachen,

die bekannteste ist die Unified Modeling Language (UML), welche exemplarisch

erklä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, unabhängig von deren Fach- und Realisierungsprinzip.

Sie liefert Notationselemente gleichermaßen für statische und dynamische Model-

le von Analysen, Design, Architektur und unterstützt insbesondere objekorientierte

Vorgehensweisen.[8, S.4] Mit dieser Beschreibung stimmt die UML mit der Defini-

tion einer Modellierungssprache ü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


nes Klassendiagramms und einzelne Aktivitäten/Algorithmen mit Hilfe eines Akti-

vitätsdiagramms beschrieben. Deswegen liefert die UML den Schlüssel zum Erfolg

für die CML. Denn die nachfolgenden drei Diagramm Typen liefern den Grund-

stein fü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 lässt sich mit Hilfe des Zustandsautomaten ein System beschreiben,

Abbildung 2.4: Zustandsautomat eines Separators

10


welches sich zu jedem Zeitpunkt in einem bestimmten Zustand befindet. Eben-

falls muss der Übergang von einem in den nächsten Zustand ohne zeitliche Verzöger-

ung geschehen.[8, S.330] Wenn die beschriebenen Sequenzen aus dem Unterabschnitt

Separatoren als Zustände interpretiert werden, ermöglicht dieses Diagramm den Ab-

lauf des Separators zu beschreiben, da die Sequenzen in Beziehung zueinander ge-

setzt werden kö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 selbsterklä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 Zustände dargestellt, die

die Sequenzen repräsentieren. Zwischen den einzelnen Zuständen sind Transitionen

eingefügt worden, an denen teilweise auch Bedingungen (Trigger) geknüpft sind. So

kann zum Beispiel der Zustand Anlauf nur in den Zustand Trommelschließprogramm

übergehen, wenn die Nenndrehzahl erreicht wurde. Des Weiteren enthält jeder Zu-

stand, bis auf Betriebsbereit, bestimmte Verhalten, sodass beim Anlauf der Motor

eingeschaltet wird oder beim Produkt wä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 gewä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


Diesmal wird jedoch kein Bezug zum Separator genommen, weil das Diagramm

im eigentlichen Sinne für die Beschreibung eines Separators nicht sinnvoll ist und

deswegen später für die CML stark verändert wird. Jedoch liefert dieses Diagramm

eine wertvolle Idee, nämlich Interaktionen zwischen komplexen Strukturen darstel-

len zu wollen. Damit der Aufbau des Diagramms bekannt ist, soll es anhand eines

Liedwechsels erklärt werden. Die Notationselemente werden wieder in der Abbildung

benannt und auf der sogenannten Lebenslinie werden die Kommunikationspartner

eingefügt. In der Abbildung ist letztendlich dargestellt, wie ein Zuhörer über eine

Fernbedienung ein Liedwechsel vornimmt. Dabei kommuniziert der Zuhörer über die

Fernbedienung mit dem Audiogerät.

2.3.3 Aktivitätsdiagramm

Ein Aktivitätsdiagramm (Activity Diagram) stellt Aktivitäten mit einem nichttrivia-

len Charakter dar. Eine Aktivität im Sinne der UML2 spezifiziert dabei die Menge

von potenziellen Abläufen, die sich in der Realität (im Programmiersprachenjar-

gon”

zur Laufzeit“) unter bestimmten Randbedingungen abspielen.[8, S.264] Somit

können mit Hilfe eines Aktivitätsdiagramms Abläufe beschrieben werden, um eine

Hardware Komponente auszulesen oder aber einen Prozessablauf.

Abbildung 2.6: Aktivitätsdiagram - Motor einschalten

12

2 GRUNDLAGEN 2.4 METAMODELLIERUNG

In Abbildung 2.6 ist ein solches Diagramm, für eine Hardware Komponente eines

Separators, dargestellt und die Notationselemente werden zudem benannt. Genauer

betrachtet bildet das Aktivitätsdiagramm die Hardware Komponente”Motor“ ab.

Hierbei wird nach dem Starknoten der Zustand des Motors geprüft. Wenn er aus

ist wird auf eine Einschaltbedingung geprüft. Ist diese wahr, wird der Motor einge-

schaltet, wenn nicht bleibt er aus. Dasselbe gilt fü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 spätetere CML wird diese Eigenschaft ebenfalls teilen, da Ablä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 Prä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 dürfen. Die Semantik definiert

schließlich die Bedeutung der Symbole bzw. der Notationen und legt die Kombinati-

onsmö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 möchte. Dabei ist die Codegenerierung einfacher, wenn das Metamodell exakt

auf die Domäne zugeschnitten ist und die Architektur des Programmes gut gewählt

wurde. Zudem gewä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 Codegröß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 Fehlerfrüherkennung

implementiert werden.

13

2 GRUNDLAGEN 2.5 CODEGENERIERUNG

Generell mü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 ausgefü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 übernommen, sodass die Modelle letztendlich noch validiert

und transformiert werden müssen, bevor der Code generiert werden kann. Diese drei

Aufgaben werden somit selbst in Cinco implementiert. Zudem müssen Codegene-

ratoren folgende Eigenschaften unterstü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 für die Implementierung des Codegenerators vor, sodass diese

Eigenschaften vorhanden sind. Fü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

enthä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, Einfügen privater Methoden

14

2 GRUNDLAGEN 2.6 BECKHOFF IPC - TWINCAT 3

Bei einem Steuerungsprogramm für eine industrielle Zentrifuge ist eher der zwei-

te Fall gegeben, weil die Codestruktur und die Syntax vorgegeben sind, aber die

eingefü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 Ausdrücke, die wä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-

zugefügt werden sollen. Aus dem Grund das die eingefügte Logik sehr variable ist,

muss in das Template noch sehr viel variabler Code eingefügt werden. Somit werden

Algorithmen gebraucht die Logik in einem String zusammenfassen, sodass dieser an

der Stelle eines Tags eingefügt werden kann. Diese Algorithmen gilt es in 4.2.2 zu

entwickeln.

2.6 Beckhoff IPC - TwinCAT 3

Die Firma Beckhoff liefert ein vollständiges Steuerungssystem mit einem IPC und

Karten für digitale/analoge Ein-und Ausgänge. Die Kommunikation zwischen IPC

und Peripherie wird somit von Beckhoff bereitgestellt. Des Weiteren arbeitet Beck-

hoff mit Microsoft zusammen, sodass die Entwicklungsumgebung fü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 Echtzeitfähigkeit zu gewährleisten. So können nur beim Start des Programms

Klassen allokiert werden, damit im Betrieb die Größ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


Abbildung 2.8: Beckhoff eXtended Automation Architectur nach Vorlage[2, S.3]

Diese Runtime sorgt dafür, dass die Echtzeitfähigkeit eingehalten wird, indem

ein Real-Time Kernel von Beckhoff in das Betriebssystem integriert wird. In diesem

Kernel läuft dann das Programm als Prozess ab. In Abbildung 2.8 wird die eXtended

Automation Architectur (XAA) dargestellt, welche einen guten Überblick ü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“

während der Allokation allokiert. Aus Gründen der Ü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 benötigten

”GEA Sequences“ und

”GEA FunctionModule“. Dabei müssen die

”GEA Function-

Module“ zuerst allokiert werden, da den”GEA Sequences“ die Objekte der benö-

tigten”GEA FunctionModulen“ übergeben werden. Den

”GEA FunctionModulen“

werden hingegen die Referenzen von definierten Inputs, Outputs und Daten ü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 später nachaußen sichtbar ist, wie Eingänge, Ausgänge und Daten.

16


Die Daten, die in der TMC File definiert wurden, liegen im TwinCAT Transport

Layer und können somit von einem Open Platform Communications (OPC)7 Ser-

ver abgegriffen werden. Die Inputs und Outputs können ü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, müssen eigene Klassen (z.B.”GEA Timer“,

”GEA -

Counter“) geschrieben werden, die diese Funktionalitäten gewährleisten.

In den”GEA FunctionModulen“ wird die eigentliche Logik abgearbeitet, sodass die-

se Timer (Timer), Zähler (Counter) und Regler (Controller) benötigen, damit jedes

der”FunctionModule“ die passende Anzahl von diesen Objekten für sich allokiert.

Fü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 für die Timer setzt, da diese auch wie Counter arbeiten. Nur das

diese letztendlich immer die Zykluszeit addiert. Nach dem ersten Zyklus überprü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 dafür sorgen

das z.B. Ausgä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 (vollständig: Cinco SCCE Meta Tooling Suite) ist eine Entwicklungsumge-

bung fü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

aufgehängt. Die spätere CML wird mit Hilfe dieser beiden Metasprachen ausge-

drückt. Wenn das neue Metamodell mit Hilfe dieser Modellierungssprachen spezi-

fiziert wurde, kann aus diesem ein Java Programm generiert werden, welches das

neuentwickelte und domänenspezifische Metamodell beinhaltet und graphisch ab-

bildet. Es wird somit zum einen das Metamodell und zum anderen ein graphischer

Editor von der höheren Spezifikation (Metametamodell) vollständig generiert. Der

graphische Editor erlaubt es die graphischen Objekte, die das Metamodell später

beinhaltet, zu verschieben, zu vergröß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 für einen eigenen Codegene-

rator zur Verfügung, der aus dem generierten Metamodell einen Applikationscode

fü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

ausfällt.[7] In den folgenden Unterabschnitten wird die Metasprache von Cinco und

die Schnittstelle für den Codegenerator detaillierter erklä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) ausgedrückt. Die MGL

definiert die Eigenschaften und Regeln, die für ein Symbol bzw. fü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 kö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. Ü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 ausgeführt werden (Abbildung 3.2 b)).[6]

(a) Generien des Cinco Pro-

duktes

(b) Ausführen des Cinco Produktes

Abbildung 3.2: Codegenerierung des Cinco Produktes und dessen Ausführung

20


Die nächsten Unterpunkte befassen sich mit der konkreten Syntax dieser drei

Spezifikationen. Jedoch wird nicht alles bis ins kleinste Detail erklä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

Schlüsselwörter und den Annotationen im Anhang (A.1) zu finden. In Listing 3

ist der Quellcode fü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 über”incomingEdges“ in den

Konten hineinkommen und welche über”outgoingEdges“ hinaus dürfen. Dabei wer-

den in den runden Klammern die Kantentypen mit einer unteren und oberen Grenze

für die Anzahl übergeben. Das bedeutet im Genauen für die”outgoingEdges“ in Li-

sting 3, das zwei unterschiedliche Typen hinausgehen dürfen, nämlich”Transition“

und”LabeledTransition“. Allerdings darf es mindestens und maximal eine Kante

sein. Ein”*“ bedeutet hingegen das es beliebig viele sein dürfen. Ebenfalls kann

über eine Trennung, wie es bei den”incomingEdges“ der Fall ist, die Anzahl von

Kanten für jeden Typen konkret definiert werden und nicht für beide zusammen.

Zudem erbt der Knoten vom Knoten”AbstractSequence“ und besitzt drei Annota-

tionen. Über die Style Annotation wird die Verlinkung zur Style Definierung in der

MSL Datei hergestellt und ein Attribut kann übergeben werden. Dieses Attribut

wird von der AbstractSequence geerbt. Die Annotation”@icon“ hinterlegt einen

Icon in der Palette und ü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 vollstä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“ hinzugefügt. Für die Bedeutung der anderen einzelnen

Annotationen wird erneut auf den Anhang (A.1.2) verwiesen. Zudem ist zu be-

21


merken, dass der Knoten”Sequence“ auch die Annotation von

”AbstractSequence“

erbt und das über ein”enum“, ein Drop-Down-Menü 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


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{


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 erwähnt, muss dem einzelnen Knoten bzw. der einzelnen Kante ein Style

hinzugefü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

grün, sowie die Schrift innerhalb des Rechtecks. Die Definierung einer Kante folgt

analog und weitere Schlagwörter kö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 übergebene Argument von der MGL File wird beim

Text, genauer beim Attribute value”%s“, eingefü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 erwähnt, kann über Rechtsklick auf diese

Datei letztendlich das Cinco Produkt generiert werden. Weitere Schlagwö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 erläutert kann mit Hilfe von Cinco ein neues Metamodell definiert wer-

den, welches in einem graphischen Editor zur Verfü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 Verfügung stellt,

23


welches die Annotation”@generatable“ in der MGL Datei interpretiert. Diese An-

notation verursacht, dass in dem graphischen Editor ein Generator Button eingefügt

wird, welcher bei Ausführung aus dem aktuell geöffneten Modell, einen Quellcode

erzeugt. Der Codegenerator muss selbststä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 ü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 fü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


Anschließend wird die Methode”generate()“ aufgerufen. Der

”generate()“ wird eine

Instanz des jeweiligen Modells ü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 für jeden

Knoten, für jede Kante und für das Modell an sich Klassen enthä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 zurückgreifen:

• Nachfolger und Vorgä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 natürlich noch viel mehr Methoden, die verwendet werden können, auch

für die Kanten. Diese werden aber an gegebener Stelle erläutert, wenn der selbstim-

plementierte Codegenerator erklärt wird. Ebenfalls kann ü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 müssen und welche generiert werden. Aus generierten Klassen und

selber implementierten Klassen ergibt sich schließlich das CMT.

26

4 DURCHFÜHRUNG

4 Durchführung

Die Durchfü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 für modellgetriebene Software Entwicklung entwickelt wird [10, S.59]. Die

Begrü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 lauffä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. verändert wird und auch die Klassen-

diagramme sich laufend verändern. Aus diesem Grund wird zum Beispiel Refecto-

ring8 betrieben. Zudem werden bei der Durchführung noch weitere Best Practices

für die Software Entwicklung angewendet, die zum Beispiel in Scrum oder Extreme

Programming definiert sind. Diese sind unter anderem in den Vorlesungsfolien für

Software Engineering [1] bzw. in einem Buch ü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“ erlä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 enthä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 erklärt. An dieser

Stelle erfolgt auch die Spezifizierung der CML. Vorab ist zu erwähnen, dass das CMT

bisher nur die englische Benutzersprache unterstützt, sodass alle Abbildungen, die

Ausschnitte aus dem CMT abbilden, englische Bezeichnungen enthalten können.

8Ein Best Practice von Extreme Programming: Der Code wird optimiert und verschönert, nachjeder Iteration. Dabei ist wichtig, dass keine neue Funktionalität implementiert wird, sondern dieFunktionalität dieselbe bleibt.

9Javadoc ist ein Dokumentationstool, welches automatisch HTML-Dateien erstellt. DieseHTML-Dateien bilden das Programm ab und beschreiben dieses.

27

4 DURCHFÜHRUNG 4.1 ENTWICKLUNG DER CML

4.1.1 Analyse der Anforderungen an die CML

Um eine Modellierungssprache für Zentrifugen erstellen zu kö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 über das Human Machine

Interface (HMI) Einfluss auf einen Separator.

Abbildung 4.1: Use-Case Anwendersicht

Aus diesem Diagramm lassen sich die wesentlichen Merkmale fü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 können. Deswegen muss eine

weitere Abstraktionsebene für die Beschreibung der”Was-Sicht“ eingeführt werden.

28


Es werden deshalb die gefundenen Sequenzen (z.B. Stillstand, Hoch laufen, Be-

triebsbereit) nach der gleichen Vorgehensweise wie beim Separator analysiert. Als

Ergebnis erhält man mehrere Aufgaben, die ein Separator in einer Sequenz abarbei-

ten muss. Diese Aufgaben muss er immer wieder durchführen, bis alle abgeschlossen

sind. Diese sind zum Beispiel:

• Motor einschalten und überwachen

• Vibration überwachen

• Öl Pumpe einschalten und überwachen

Somit wird mit Hilfe von zwei Ebenen die”Was-Sicht“ vollständig beschrieben, denn

diese treffen darü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 fü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 darüber Auskunft wie der Separator im Einzel-

nen detailliert funktioniert. Deswegen mü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 ermö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 dazugehörigen Modellen,

sind selbst entworfene Modelle und haben somit nichts mit den Namensvä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 erklärt wird.

Bemerkung zur Ebene 3: Wie bereits erwähnt, stellen die beiden obersten Ebe-

nen die”Was-Sicht”dar und die dritte Ebene die

”Wie-Sicht”. Die

”Was-Sicht“ deckt

somit die Bedürfnisse eines Verfahrenstechnikers ab, da dieser sich die Frage stellt:

”Was muss ich unternehmen, um ein bestimmtes Produkt separieren zu können,

sodass es sich in den Prozess integrieren lässt?“. Mit der”Wie-Sicht“ hingegen

beschäftigt sich der Programmierer, denn dieser stellt sich die Frage:”Wie muss

29


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 Überlegung, die dritte Ebene direkt in Appli-

kationscode zu schreiben, sodass die zweite Ebene exemplarisch auf fertige C++

Klasen zurü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 für alle Steuerungssysteme

Applikationscodes generiert. Dieses impliziert, dass die Möglichkeit vorhanden sein

muss auch für die Funktionsbausteine Applikationscodes für verschiedenen Zielplatt-

formen erzeugen zu können. Somit ist die Ebene 3 notwendig. Ein weiterer Vorteil

ist, dass die Programmierer, die die”Wie-Sicht“ umsetzten, eine einheitliche Mo-

dellierungssprache zur Verfügung haben. Zudem garantiert diese Ebene, dass ein

angelegtes Funktionsbausteinmodell fü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 können unterschiedliche Sequenzen auf denselben Baustein zugreifen. Dieses

muss gegeben sein, da zum Beispiel der Funktionsbaustein”Hauptmotor“ den Motor

in jeder Sequenz überwachen und steuern muss. Somit besteht ein vollständiges Mo-

dell von einem Separator aus einem Zentrifugenmodell, mehreren Sequenzmodellen

30


und mehreren Funktionsbausteinmodellen. Hierbei kann sogar noch feiner definiert

werden. Alle Separatoren bzw. Zentrifugen an sich, mü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 für die CML folgende Regeln:

• Das höhere Modell beschreibt die Verschaltung des darunter liegenden Modells

• Das untere Modell beschreibt einzelne Modell Elemente des höheren Modellsgenauer

• Beim obersten bzw. untersten Modell gilt nur die Sicht nach unten bzw. nachoben

Jedoch beschreibt jedes Modell an sich einen vollstä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 Ü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 erwähnt, basiert die CML auf drei Ebenen bzw. auf drei

Modellen, die es ermöglichen ein Steuerungsprogramm für eine Zentrifuge zu mo-

dellieren. Aus jedem Modell lä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 Rückmeldung an das obere Modell

• das höhere Modell ruft das darunter liegende Modell auf

Dabei wird zwischen fünf Arten von Rückmeldungen unterschieden. Diese werden

in Tabelle 4.1 dargestellt. In der untersten Ebene, also in der Funktionsbaustei-

nebene, wird eine dieser Rückmeldungen zurückgegeben. Die Sequenzebene wertet

dann die Rückmeldung aus. Die Sequenzebene bekommt nicht eine, sondern meh-

rere Rückmeldungen zurück, da das Modell in der Ebene mehrere Modelle aus der

Funktionsbausteinebene erhält. Die Sequenzebene gibt dann die Rückmeldung mit

der höchsten Priorität an die Zentrifugenebene zurück. Dabei ist Priorität Fünf die

31


Priorität Rückmeldung

1 wahr (true)2 falsch (false)3 Fehler (failure)4 Error (error)5 Notfall (emergency)

Tabelle 4.1: Prioritätstabelle für Rückmeldungen

hö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 Rückgabewert an die Sequenzebene zurückgegeben wird,wird ein Modell aus der Sequenzebene aufgerufen, welches die

”Runter-Fahren“

Sequenz beschreibt

• immer wenn ein Notfall Rückgabewert an die Sequenzebene zurü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-“ Rückgabewert auswerten. Doch diese Rü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 ausgewählt werden muss, sowie ein Name, eine Beschreibung

und ein Autor eingetragen werden mü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 hö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 erfüllt sein müssen,

damit von einer Sequenz in eine andere gewechselt werden kann. Der Zustandsau-

tomat wird deshalb als Vorlage für dieses Modell gewählt. Der Zustandsautomat ist

sehr semiformal und kann somit viele unterschiedliche Anwendungen beschreiben.

Das Zentrifugenmodell benötigt diese Flexibilität nicht, da es nur eine industrielle

Zentrifuge bzw. einen Separator beschreiben soll.

32

4DURCHFÜHRUNG

4.1ENTW

ICKLUNG

DER

CML

Abbildung 4.3: Zentrifugenmodell für einen Separator

33


Aus diesem Grund, mü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. Für das bessere Verstä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 enthält. Dieser

Text beschreibt, welche Informationen auf welchem Wert abgefragt werden. Durch

Anwählen dieses Knoten öffnet sich ein Properties-Fenster, in dem die Eigenschaf-

ten spezifiziert werden müssen. Hierzu gehört, neben einer internen Benennung un-

ter”Name“, auch ein

”HardwareName“ der über ein Drop-Down-Menü ausgewählt

werden kann. Der”HardwareName“ gibt explizit darüber Auskunft, welcher digitale

Hardware Eingang an einer Karte, oder welche Taste an einem HMI abgefragt wird.

Zudem kann ü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


Hierfür wird noch die”Operation“ benötigt. Für die

”Operation“ sind alle boo-

leschen Vergleichsoperationen zulässig (!= , ==). Diese Attribute, bis auf den Hard-

warenamen, werden dem Knoten ü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.“ hinzugefügt. Diese beiden Knoten besitzen sonst dieselben Eigenschaf-

ten, bis auf dem Unterschied, dass andere”HardwareNames“ im Drop-Down-Menü

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 fü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 für die Definierung des Styles des Knoten

HmiRequest

35


Im Listing 9 ist zudem zu erkennen, dass in einem Abfrageknoten nur eine Kante

hineingehen darf und zwei Kanten herausgehen dürfen. Dieses lässt sich damit be-

gründen, dass nach einem Abfrageknoten, der auf einen booleschen Wert abgefragt

wird, nur zwei Aussagen entstehen kö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 müssen, weil ü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. Über anwählen der Kante öffnet sich ebenfalls

ein Properties Fenster, indem über ein Drop-Down-Menü die Bezeichnung”true“

oder”false“ ausgewählt werden kann, damit nicht beliebige Bezeichnungen eingetra-

gen werden können. Neben der”LabeledTransistion“, besitzt das Zentrifugenmodell

noch die Transition. Diese beiden Typen von Kanten kö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 wäre, um wieder in einen Abfrageknoten zu gehen. Bevor die Ab-

frageknoten abgeschlossen werden können, muss der Knoten”FailureRequest“ noch

erklärt werden. Denn dieser Knoten wertet den Rückgabewert”Fehler (failure)“ aus.

Sodass, wenn ein Sequenzmodell einen”Fehler“ zurück gibt, die Abfrage dies aus-

wertet und anschließend entscheidet, was dieses für eine Folge hat. Somit sind drei

von den fünf Rückgabewerten definiert. Zudem unterscheidet sich die Fehlerabfrage

von den anderen Abfragen in der Hinsicht, dass nur Kanten vom Typ”Transition“

hineingehen dürfen. Warum dieses so ist, wird später erläutert.

Vorab wurde der Sequenzknoten erwähnt. Dieser wird im Sequenzmodell als”Se-

quence“ bezeichnet. Hierbei handelt es sich um einen Knoten, der einen Zustand re-

präsentiert und somit vergleichbar ist mit dem Zustand im Zustandsautomaten. Ne-

ben den Sequenzknoten gibt es noch Bibliothekssequenzknoten (Library Sequences),

die ebenfalls einen Zustand reprä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 für richtig erklärt, sodass dieses als vorhandene”Black-

Box“ betrachtet werden kann. Die Menge der Bibliotheks-Sequenzen wird sich stetig

erweitern. Bisher wurde nur eine Sequenz fü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 Objektübergeben)

36


• SequenceTyp (der Sequenztyp gibt an, um welchen Typ Sequenz es sich han-delt (Sillstand, Ablauf,. . . ) und kann über ein Drop-Down-Menü ausgewählt

werden)

• Description (Gibt eine Beschreibung an, besonders wichtig bei einer LibrarySequenz)

• DestinationFolder (Gibt den Ordner an, in dem sich das zugehörige Sequenz-modell befindet. Dieses wird für ein Zusatz-Feature benötigt, welches bei Dop-

pelklick das Modell öffnet, bzw. ein neues Modell erstellt, wenn kein Modell

bisher vorhanden ist)

Bei Bibliothekenssequenzen werden diese Properties über die Annotation”@post-

Create“ gesetzt. Hierbei erhält der Knoten einen Handler, der aufgerufen wird, wenn

der Knoten neu erstellt wird. Die Implementierung der zugehö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 für eine postCreate Annotation

Des Weiteren können in die Sequenz Knoten beliebig viele Kanten hineingehen, aber

es darf nur eine Kante vom Typ Transition hinausgehen. Die Begründung liegt dar-

in, das Sequenz Knoten von beliebig vielen anderen Knoten (Abfrageknoten und

Sequenzknoten) erreicht werden kö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

natürlich die Fälle, in denen ein Error oder ein Notfall Rückgabewert zurückgegeben

wird). An dieser Stelle kommen die letzten beiden Rückgabewerte ins Spiel, denn

”Start Up“ kann nur in

”Standby“ wechseln wenn der Rückgabewert

”wahr“ ist.

Es fehlt somit nur noch der Rückgabewert”falsch“. Dieser bedeutet, dass nicht alle

Bedingungen erfüllt sind, um die Sequenz wechseln zu können. Wenn eine Sequenz

37


unterschiedliche Nachfolger haben soll, müssen Abfragen eingefügt werden, damit

wieder genau definiert ist, wie der Sequenzwechsel erfolgt.

Im Hinblick auf die Codegenerierung muss eine weitere Bedingung eingefügt wer-

den. Die Abfragen werden in dem Applikationscode nur dann abgefragt, wenn der

Rü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 wäre es unerwünscht, wenn vor einem”Fai-

lureRequest“ ein”HmiKeyRequest“ erfolgt. Aus diesem Grund muss die

”Failure-

Request“ direkt nach einem Sequenzknoten eingefügt werden. Dieses wird dadurch

gewährleistet, indem bei einem”FailureRequest“, wie schon erwä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 Rückgabeknoten (”Re-

turnError“ und”ReturnEmergency“) in diesem Modell, wobei die Return Knoten

für die Visualisierung der definierten Regeln sorgen. Diese besitzen als Grundform

einen Kreis. In den Startknoten, sowie in den Rückmeldeknoten, können somit keine

Kanten hineingehen und es darf nur eine Kante von dem Typ Transition hinausge-

hen. Ebenfalls wird spä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 Rü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

können. Im Genauen bedeutet dieses, dass von einer späten Sequenz, wie eine vom

Typ”SlowDown“, zum Anfang zurückgekehrt werden kann. Denn immer wenn eine

Sequenz aufgerufen wird, beginnt ein neuer Zyklus. Nach dem Zyklus wird dann

entschieden, was im nächsten Zyklus ausgeführt wird, also welche Sequenz durch-

laufen wird. Deshalb muss jede Sequenz wieder erreicht werden können. Es bedeutet

aber auch, dass in den folgenden Modellen keine Schleifen mehr erlaubt sind, da die-

se einen zyklischen Ablauf stören würden. Im Worst Case wä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


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 verändert, sodass das Element”Nachrichtenname“

wegfällt und die Richtung des Nachrichtenflusses vorgegeben wird. Deswegen erfolgt

der Fluss immer in einer Richtung. Die Lebenslinie bleibt jedoch erhalten und die

Knoten reprä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-

präsentiert dabei ein Modell welches in der Funktionsbausteinebene modelliert wur-

de. Zudem kö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 Rückmeldung

überwacht, die zeitlich verzögert ist, muss die Mö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


Abbildung 4.6: Sequenzmodell einer kleinen Start Up Sequenz

Zwischen den”SeqStart“ und

”SeqEnd“ Knoten können

”FunctionModule“ ein-

gefügt werden, die ü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 für eine”StartUp“

Sequenz. Trotzdem lässt sich das Prinzip sehr gut an dieser Abbildung erklä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 zugehörige”Function-

Module“ eine Rückmeldung. Wir nehmen an, dass zum Beispiel der Bibliotheks-

baustein”MainMotorLib“ den Rückgabewert

”falsch“, der

”LubricationOilWithOil-

PUmp“ Funktionsbaustein”Error“ und der

”EmergencyStop“ Funktionsbaustein

”true“ zurü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 Rückgabewert”Error“ (besitzt die höchste Priorität)

an das Zentrifugenmodell zurück. In diesem Modell ist keine Rückfü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


gewä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 Aktivitä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 Rückmeldungen an das Sequenzmodell geben kann. Das Modell

basiert letztendlich auf drei verschiedenen Type

Documents

Modellbasierte Modellierung von industriellen Zentrifugen mit … · 2015. 7. 15. · Industrielle Zentrifugen sind ein wichtiger Bestandteil f ur die Aufbereitung und Ver-arbeitung