mowima

Transcription

mowima

MODELLIERUNG UND W IEDERVERWENDUNG
OBJEKTORIENTIERTER MASCHINENSOFTWARE
(MOW IMA)
Abschlußpräsentation des BMBF-Verbundprojekts MoWiMa,
30. April 1998, VDMA Frankfurt/Main
Inhalt
1 Problemstellung und Ziel von MoWiMa
1.1 Problemstellung
1.2 Ein Fallbeispiel
1.3 Ziel und Lösungsansatz
2
3
4
5
2 Informationsmodell und objektorientierte Modellierungsmethode für
Steuerungssoftware
2.1 Baukastendefinition
2.2 Maschinen- und Softwarekonfigurierung
2.3 Codegenerierung und Steuerungsankopplung
8
9
22
27
3 Werkzeugunterstützung
3.1 Aufbau des MoWiMa CASE-Tools
36
37
4 Piloteinsatz des CASE-Tools bei der Firma Behringer
4.1 Funktionsbeschreibung
4.2 Funktionsobjekte der Bandsägemaschine Typ HBP263A
4.3 Bewertung von Methode und Werkzeug
38
39
40
41
1
Modellierung und Wiederverwendung objektorientierter Maschinensoftware
4.4 Organisatorische Probleme bei der Werkzeugeinführung, Bericht eines
Anwenders
42
5 Zusammenfassung und Ausblick
44
6 Literaturverzeichnis
46
7 Anhang A: Projektpartner in MoWiMa
47
8 Anhang B: Glossar
49
2
1 Problemstellung und Ziel von MoWiMa1
1.1 Problemstellung
Modulare Maschinenkonzepte nach dem Baukastenprinzip ermöglichen es, durch die
Konfigurierung einer relativ kleinen Anzahl standardisierter und aufeinander abgestimmter Baugruppen und Komponenten rasch und wirtschaftlich individuelle Kundenanforderungen zu
erfüllen. Rechnerunterstützte Werkzeuge, die den Entwickler bei der Erstellung der
Steuerungssoftware für solche Baukastensysteme insbesondere im Hinblick auf
Variantenbildung und -pflege effizient unterstützen, fehlen jedoch bislang.
Eine häufig praktizierte Vorgehensweise zur Software-Wiederverwendung ist daher die
Übernahme eines kompletten Vorgängerprojekts und die Anpassung an die neue Problemstellung. Kritisch bei dieser Vorgehensweise ist, daß häufig aufgrund mangelnder Kenntnis von
Implementierungsdetails lediglich neue Funktionalitäten ergänzt werden. Das Löschen nicht
mehr benötigter Funktionalitäten unterbleibt aus Furcht, Fehler im scheinbar funktionierenden
System hervorzurufen. Die Folge ist, daß die Software immer schwerer verständlich wird und
Änderungen leicht zu unkontrollierbaren Auswirkungen führen, die sich oft erst im Betrieb der
Maschine oder Anlage bemerkbar machen und dann hohe Kosten verursachen.
Der Softwaretest erfolgt in vielen Fällen außerhalb des Entwicklungsbereichs bei der
Inbetriebnahme der Gesamtmaschine vor Ort. Veränderungen während des Tests lassen sich
oft nicht mehr genau einer Standardversion bzw. Variante zuordnen und daher nicht rückführen;
durch Kopieren wiederverwendete Softwareteile sind oftmals schwer identifizierbar.
Ein weiteres Problemfeld stellt die unzureichende Durchgängigkeit derzeit eingesetzter
Beschreibungsmethoden und Werkzeuge dar:
1
Projektpartner des vom BMBF geförderten Verbundprojekts MoWiMa (Modellierung und Wiederver-
wendung objektorientierter Maschinensoftware) sind die Maschinenhersteller Behringer GmbH Kirchardt,
Reis Robotics Obernburg, die Software-Häuser infoteam Software GmbH Bubenreuth und Industrielle
Steuerungstechnik GmbH (ISG) Stuttgart sowie die Forschungs- und Ingenieurgesellschaft für Steuerungstechnik GmbH (FISW) Stuttgart
3
•
Strukturierungsprinzipien von Baukastensystemen werden oftmals nicht abteilungsübergreifend eingehalten, so daß Softwarebausteine nicht kongruent zu den vom Vertrieb und der
mechanischen Konstruktion projektierten, realen Baugruppen eingesetzt werden können.
• Es fehlt ein durchgängiger, rechnergestützter Informationsfluß, so daß Informationen
redundant erfaßt werden und eine entwicklungsbegleitende Dokumentation von Maschinenfunktion und Software nur bedingt möglich ist.
• Das Programmierkonzept der IEC 1131-3 /IEC91/ und darauf basierende Programmierwerkzeuge unterstützen zwar die Wiederverwendung von Funktionsbausteinen (FB), bieten
jedoch aufgrund fehlender Softwareentwurfsmethodik keine Unterstützung für die Wiederverwendung von Softwarearchitekturen.
1.2 Ein Fallbeispiel
Die übliche Vorgehensweise der Projektbearbeitung bei der Firma Behringer (Hersteller von
Bandsägen -/anlagen) war bisher, nicht nur bei der Erstellung der Software in der
Elektrokonstruktion, sondern auch im Vertrieb das Übernehmen eines ähnlichen Vorgängerprojekts. Die Entscheidung hinsichtlich des am besten geeigneten Vorgängerprojekts
war dem jeweiligen Mitarbeiter überlassen. So wurden einmal nur die notwendigsten Dinge
geändert - Überflüssiges und Falsches blieb erhalten Ein andermal wurden Funktionen von
bereits veralteten Einheiten übernommen, obwohl neue Funktionen vorhanden waren. Nicht
systematisch registrierte Optimierungen an ausgelieferten Anlagen flossen nicht ein.
Bereits vor Beginn des Projekts wurde diese Problematik im mechanischen Bereich der
Konstruktion angegangen und die Produktpalette modular in Varianten aufgebaut. Ein Großteil
der Kundenanforderungen konnte schließlich mit diesem systematischen Baukasten bereits
durch den Vertrieb abgewickelt werden. Sonderkonstruktionen konnten in den meisten Fällen
durch ganz gezielte Rücksprachen mit der Konstruktion und der Fertigung gelöst werden.
Die positiven Erfahrungen in der mechanischen Konstruktion zeigten die Notwendigkeit, ein
durchgängiges Baukastensystem vom Vertrieb bis zur Inbetriebnahme, und hier insbesondere
für die Softwareerstellung, aufzubauen. Basis dieses Baukastensystems - es soll im folgenden
als Fallbeispiel dienen - sind die vier Teilsysteme (Bild 1):
1. Zuführeinrichtung: Versorgung der Maschine mit Rohmaterial (Stangenmaterial).
2. Positioniereinheit: Positionierung des Rohmaterials.
4
3. Sägeeinheit: Sägen des Materials.
4. Abführeinrichtung: Abtransport der Werkstücke (abgesägtes Material).
Alle genannten Teilsysteme sind prinzipiell in jeder Anlage vorhanden, es sind jedoch zahlreiche
Varianten denkbar. So sind bei der Sägeeinheit z.B. Optionen möglich wie
• Gehrungstisch, also eine zusätzliche Drehachse (C-Achse) für schräge Schnitte,
• Bündelspanneinrichtung (sie dient dem gleichzeitigen Spannen und Absägen mehrerer
Stangen) und
• mehrere Antriebsvarianten für unterschiedliche Leistungen.
1
2
3
4
1.
2.
3.
4.
Bild 1:
Zuführeinrichtung
Positioniereinheit
Sägeeinheit
Abführeinrichtung
Sägeanlage der Firma Behringer: Beispiel für ein Baukastensystem
1.3 Ziel und Lösungsansatz
Die exemplarisch dargestellte Problematik der Firma Behringer ist übertragbar auf nahezu alle
Be- und Verarbeitungsmaschinen, die modular aufgebaut sind und zahlreiche Varianten
umfassen.
5
1.3.1 Ziel
Ziel von MoWiMa ist es daher, Voraussetzungen für die bessere und effizientere Wiederverwendbarkeit von Software für die Realisierung maschinennaher Steuerungsfunktionen im
Maschinen- und Anlagenbau zu schaffen. Es sollen Entwicklungskosten und -zeiten gesenkt
sowie Softwarequalität und Flexibilität gesteigert werden. Zu diesem Zweck soll im Rahmen
des Projekts ein geeignetes, rechnergestützes Werkzeug (CASE (Computer Aided Software
Enginering) - Tool) prototypisch realisiert und den Maschinenherstellern zum industriellen
Piloteinsatz zur Verfügung gestellt werden.
Wichtig hierbei ist, die Softwareeerstellung als integralen Bestandteil des gesamten EngineeringProzesses zu betrachten und hierfür ein geeignetes Informationsmodell sowie Methoden und
Werkzeuge für ein effizientes Informationsmanagement zu schaffen. Komponenten des
Informationsmodells sollen „mechatronische Objekte“ sein (z.B. Gegenspindel einer
Drehmaschine, Bild 2, denen sowohl bauliche (Mechanik, Gerätetchnik) und funktionale
Eigenschaften (z.B. Referenzpunktfahrt), Dokumente unterschiedlicher Medien (z.B. auch
Hypertextdokumente oder Videos) sowie Steuerungshard- und -softwarebausteine zugeordnet
werden können. Für eine effiziente Wiederverwendung sollen sie in einer Baukastenbibliothek
definiert und bei der Maschinenkonfigurierung (Auftragsbearbeitung) beliebig instanziiert
werden können. Gepaart mit diesem Informationsmodell sollen systematische und innovative
Methoden erarbeitet werden für (Bild 2):
• auftragsneutrales, komponentenorientiertes Engineering durch die interdisziplinäre Modularisierung und Modellierung sowie auftragsneutrale Maschinentypbeschreibung in Form von
Baukastensystemen,
• auftragsspezifisches, komponentenorientiertes Engineering durch die baukastenunterstützte
Bildung konkreter Maschinenkonfigurationen und hieraus die Konfigurierung der
Steuerungssoftware. Die Konfigurierung von Steuerungshardware, elektronischer
Dokumentation sowie weiteren Informationssystemen, wie z.B. für Diagnose- und Service,
sollten ebenfalls, wenngleich nicht schwerpunktmäßig, Beachtung finden.
Für die effiziente Erstellung der Steuerungssoftware sollen, aufbauend auf dem
Informationsmodell, geeignete, auf die Bedürfnisse im Maschinen- und Anlagenbau angepaßte,
objektorientierte Methoden erarbeitet werden.
6
Bild 2:
Informationsmodell als Basis für innovative Softwaretechnik
1.3.2 Lösungsansatz
Der Lösungsansatz von MoWiMa basiert hier auf der Nutzung und Konkretisierung
universeller Modellierungsansätze aus der objektorientierten Softwaretechnik (Unified
Modeling Language /Booc97/, Frameworks /Bir95/, Klassenhierarchie mit Vererbung),
woraus eine problemorientierte und für die Werkzeugunterstützung zugeschnittene
Modellierungsmethode erarbeitet wurde (Bild 3). Des weiteren wurden die bereits in der
Steuerungsprogrammerstellung bekannten Ansätze der hierarchischen Gliederung von
Maschinen und Anlagen in Funktionsobjekte (Funktionsgruppen und -einheiten) und deren
Modellierung mit Zustandsgraphen /Reic95, Rath95, Aeg93/ sowie der Programmierung nach
IEC 1131-3 /Iec91/ genutzt. Diese Ansätze wurden speziell auf die Problemstellungen der
Konstruktion und Steuerungstechnik für Baukastensysteme erweitert.
7
Unified Modelling Language
Frameworks
Modellierungsansätze
aus der objektorientierten Softwaretechnik
Vererbung
Nutzung und Konkretisierung theoretischer
Ansätze
Problemorientierte Modellierungsmethode für
maschinenbauliche Anwendungen
Modellierungsmethode
MoWiMa
Werkzeugunterstützung
M
M
Funktionsobjekte Zustandsgraphen
Bild 3:
Problemstellungen
der Steuerungstechnik
und Konstruktion
VAR
...
END_VAR
IEC 1131-3
Nutzung objektorientierter Methoden für maschinenbauliche Anwendungen
2 Informationsmodell
Steuerungssoftware
und
objektorientierte
Modellierungsmethode
für
Die Vorgehensweise bei der objektorientierten Softwareerstellung gliedert sich in die objektorientierte Analyse, den objektorientierten Entwurf, die Implementierung sowie den
Softwaretest (Inbetriebnahme), Bild 4.
Analyse
Softwaretest
Entwurf
Implementierung
Bild 4:
8
Phasen bei der Erstellung objektorientierter Steuerungssoftware
Für den Aufbau von Baukastensystemen wird Steuerungssoftware speziell unter dem
Gesichtspunkt der Wiederverwendung erstellt. Daher wurde eine Erweiterung der o.g.
Vorgehensweise erarbeitet, die sich in die beiden Tätigkeiten
•
Baukastendefinition und
• Maschinen- und Softwarekonfigurierung mit Baukasten
untergliedert. Diese werden nachfolgend beschrieben.
2.1 Baukastendefinition
Ein nach einem Baukastensystem aufgebauter Maschinentyp ist dadurch gekennzeichnet, daß
•
die im Baukasten vorhandenen Komponenten (z.B. Baugruppen) in einer Vielzahl
unterschiedlicher Maschinenkonfigurationen (Varianten konkreter Maschinen) eingesetzt
werden können und die
• Maschinenkonfigurationen einen von der Struktur her weitgehend ähnlichen Aufbau
besitzen.
Für die Definition eines für ein Baukastensystem geeigneten Informationsmodells ist sowohl die
Beschreibung des grundlegenden Aufbaus und der Schnittstellen der im Baukasten enthaltenen
Komponenten als auch die Beschreibung des Zusammenspiels dieser Komponenten
notwendig. Im Rahmen des MoWiMa-Projekts wurde daher (Bild 5)
•
eine allgemeingültige Beschreibung für die Struktur einer Baukastenbibliothek mit im
System bereits vordefinierten Systemtypen (z.B. „Funktionseinheit“) festgelegt. Durch
Spezialisierung (Unterklassenbildung) von Systemtypen wird die Definition benutzerdefinierter Typen (z.B. „Rollenbahn RB36 M113“) sowie, durch Variantenbildung benutzerdefinierter Typen (z.B. „Rollenbahn RB36 M113A“), der Aufbau einer Vererbungshierarchie ermöglicht.
• eine Methode zur Beschreibung der "Baukastensystematik" festgelegt. Es werden
Klassendiagramme verwendet, um auftragsneutral die Rollen und das Zusammenwirken der
Systemtypen (im sog. „Systemklassendiagramm“) und benutzerdefinierten Typen aus der
Bibliothek für die Erstellung konkreter Maschinenkonfigurationen unter Berücksichtigung
9
von Varianten und
Klassendiagramm").
Optionen
zu
beschreiben
(im
sog.
"benutzerorientierten
Baukasten
Baukastenbibliothek
Baukastensystematik
Systemklassendiagramm
(branchenunabhängige
Beschreibung)
Funktionsgruppe
A FG
Funktionsobjekt
1..N
Funktionsobjekt
Systemtypen
A FO
Funktionseinheit
0..1
A MB
A EB
0..N
Informationshinweis
A
I
Benutzerorientiertes Klassendiagramm
RB36 M13
A FE
Benutzertypen
A FG
benutzerdefinierte Typen
1..2
Rollenbahn
A FE
0..1
1
1
Zuführeinrichtung
Sägeeinheit
A FG
Systemtypen
(Maschinentypbeschreibung)
Sägeanlage
Visualisierung
RB36 M15
Bild 5:
A EO
0..N 0..N
Elektr. Betriebsmittel
Mechanik Bauteil
Rollenbahn
Entwurfsobjekt
0..N
A
FG
Sortiereinheit
A
FG
0..1
Tragkettenförderer
A
FE
Beschreibung eines Baukastensystems, bestehend aus Baukastenbibliothek und
Baukastensystematik
2.1.1 Aufbau der Baukastenbibliothek
Eine Baukastenbibliothek umfaßt auftragsneutral sämtliche Objekte, die innerhalb eines
Maschinentyps vorhanden sind. Erster und wichtiger Schritt beim Aufbau einer Baukastenbibliothek ist das Finden geeigneter Objekte und das Definieren daraus abgeleiteter,
benutzerdefinierter Typen (in der Softwaretechnik "Klassen" genannt). Wichtig für die
Durchgängigkeit ist, daß durch diese Typen interdisziplinär nutzbare Standardlösungen
abgebildet und daher sowohl bauliche als auch funktionale Gesichtspunkte berücksichtigt
werden.
Gemäß der in MoWiMa erarbeiteten Methode wird für die Erstellung maschinennaher
Steuerungsfunktionen eine Baukastenbibliothek folgendermaßen definiert:
10
1. Aufbau einer Typen- bzw. Klassenbibliothek unter Nutzung der objektorientierten
Grundprinzipien Abstraktion zur Klassifizierung und Vererbung zur Wiederverwendung
und Variantenbildung. Die abstrakten (nicht instanziierbaren) Systemtypen Entwurfsobjekt,
Funktionsobjekt (untergliedert in Funktionseinheit und Funktionsgruppe)
ElektrBetriebsmittel (untergliedert in SensorAktorElement und BenutzerEinAusgabeElement), Mechanikbauteil und Informationshinweis bilden hierbei Oberklassen für
abstrakte und konkrete (instanziierbare) Benutzertypen (siehe Bild 6), denen
unterschiedliche Teilmodelle zugeordnet werden können.
• Allen Entwurfsobjekten sind Wiederverwendungsinformationen in Form von Suchschlüsseln (für die Suche in der Bibliothek) sowie Dokumentationsbausteine aus externen
Werkzeugen (z.B. Textverarbeitung) für Angebotstexte, Funktionsbeschreibungen,
Benutzungsanleitungen, Wartungshinweise etc. zugeordnet.
• Funktionsobjekte enthalten zusätzlich ein Funktionsmodell, welches dem
Steueungsentwurf dient und mit formalen oder semiformalen Methoden beschrieben
wird. Für die Umsetzung innerhalb des MoWiMa-Projekts wurde hierzu die
Zustandsgraphenmethode /Flec87/ aufgegriffen (siehe Kap. 2.1.1). Sie dient gleichzeitig
als Grundlage für die Generierung des Steuerungscodes ("C" oder AWL nach IEC
1131-3).
• ElektrBetriebsmitel enthalten kein Funktionsmodell. Sie sind ausschließlich durch ihre
physischen und logischen Anschlußpunkte an die Steuerung beschrieben. Sie sind
untergliedert in SensorAktorElemente, die Signale vom und zum Prozeß liefern (z.B.
Näherungsschalter oder Motoren) und BenutzerEinAusgabeElemente, die Signale vom
und zum Benutzer liefern (z.B. Taster oder Anzeigeelemente).
• Mechanikbauteile enthalten keine steuerungstechnische Funktion, können aber für das
Verständnis einer Maschinenkonfiguration oder für die Dokumentationserstellung nützlich
sein (z.B. Maschinenbett).
• Informationshinweise sind Informationen, die nicht direkt einem Funktionsobjekt,
elektrischen Betriebsmittel oder Mechanikbauteil zugeordnet werden können, aber zu
Dokumentationszwecken in einem grafischen Maschinenabbild dienen (z.B. Sicherheitshinweise).
11
Entwurfsobjekt
Funktionsobjekt
Funktionsgruppe
Zuführeinrichtung
I ZE24-F2
Funktionseinheit
Rollenbahn
Rollenbahn, 1-Richtung
I RB68-L1/4
I RB68-L1/6
Rollenbahn, 2-Richtung
I RB68-L2/4
I RB68-L2/6
ElektrBetriebsmittel
SensorAktorElement
Sensoren
Näherungsschalter
I OL 406/0067 24V
BenutzerEinAusgabeElement
Mechanikbauteil
Informationshinweis
Bild 6:
I
Systemtypen
Abstrakte
Benutzertypen
Konkrete
Benutzertypen
Vererbung
Typen-(Klassen-)hierarchie mit abstrakten und konkreten Benutzertypen
2. Benutzertypen sind durch beliebige, aufgabenbezogene Teilmodelle (Sichten) zu
beschreiben. Bild 7 zeigt beispielhaft die Teilmodelle für die benutzerdefinierte, konkrete
Funktionseinheit 'Rollenbahn RB68-L1/6'. Ihr zugeordnet sind
• elektrische Betriebsmittel (Motor, Lichtschranke),
• ein Übersichtsbild für die grafische Maschinenkonfiguration (mit Betriebsmittelkennzeichnung),
• eine Beschreibung der Funktionen, die von dieser Rollenbahn ausgeführt werden können
(einfördern, ausfördern, schrittfördern) und deren
• Umsetzung in ein Funktionsmodell (durch einen Zustandsgraph beschrieben) sowie
12
• Dokumentationsbausteine wie Stromlaufplan oder Funktionsbeschreibung.
Übersichtsbild
El. Betriebsmittel
-S1
RB 1
-M1
BMK
-S1
-M1
RB1
Funktionen
Bezeichnung
BA
Fertigmeldung
einfördern
ausfördern
schrittfördern
A
A
A
belegt
leer
schrittfördern
fertig
ausfördern
einfördern
R
Init
Hersteller
Einweglichtschranke OU 5005/OUS-OOKG 24V IFM
Hersteller
Getriebemotor
5K23-80 L/8-2BRE8
Getr. Bau Nord
Rollenbahn
RB68-L1/6
Behringer
z.B. Zustandsgraph
Funktionsmodell
Funktion
R schrittfördern
R
einfördern
belegt
leer
Dokumentationen
Stromlaufplan
schrittfördern
M -M1
Funktionsbeschreibung
fertig
ausfördern
BA : Betriebsart
A : Automatik
leer
Bild 7:
Typ
S
belegt
S
schrittfördern
S fertig
Beispielhafte Darstellung der Funktionseinheit "Rollenbahn"
Für die Beschreibung des Funktionsmodells sind prinzipiell beliebige Methoden denkbar, aus
denen direkt der Steuerungscode (z.B. nach IEC 1131-3) generiert werden kann. Da der
modularen Struktur von Baukastensystemen durch die Zustandsgraphenmethode in idealer
Weise Rechnung getragen wird, wurde sie im Rahmen von MoWiMa aufgegriffen und
entsprechend erweitert. Der Zustandsgraphenentwurf bietet eine interdisziplinäre
Verständlichkeit und orientiert sich an der hierarchischen Zerlegung einer Maschine oder
Anlage in Funktionseinheiten und Funktionsgruppen, die weitgehend baulich repräsentiert sind.
Die Zustandsgraphenmethode wird im folgenden detailliert erläutert.
2.1.2 Steuerungsentwurf mit der Zustandsgraphenmethode
Die Zustandsgraphenmethode [Hers82, Flec87, Otto92] basiert auf der Theorie der MooreAutomaten und eignet sich zur Steuerungsprogrammierung von Maschinen und Anlagen, wo
mechanische Bewegungen und zeitliche Abläufe vorrangig sind, z.B. Transferstraßen oder
Förderanlagen.
13
Der Zustandsgraph ist ein zusammenhängender, gerichteter Graph, der Zustände als Kreise
(Knoten) und Zustandsübergänge, auch Transitionen genannt, als Pfeile (Kanten) darstellt.
Zuständen können in einer sog. „Zustandsanweisung“ Aktionen zugeordnet werden. Aktionen
werden unterschieden in
• Aktionen, die einmalig beim Eintritt in den Zustand ausgeführt werden („PRE-STEP“),
• Aktionen, die zyklisch erfolgen („STEP“) solange der Zustand aktiv ist, und
• Aktionen, die einmalig beim Verlassen des Zustands initiiert werden („POST-STEP“).
Transitionen können Übergangsbedingungen zugeordnet werden. Ausgehend vom aktiven
Zustand wird bei gültiger Übergangsbedingung ein Schalten in einen Folgezustand ausgelöst.
Funktionseinheiten stellen die kleinste Betrachtungseinheit dar, die in der Regel durch eine
einzige physikalische Größe wie z.B. Druck oder Lage gekennzeichnet sind. Ihnen werden
symbolische Signaladressen für die angeschlossenen elektrischen Betriebsmittel (Sensorik,
Aktorik, Benutzer-Ein-/Ausgabeelemente) zugeordnet. Der Zustandsgraph einer
Funktionseinheit wird als sog. Elementargraph bezeichnet. Die Vorgehensweise für die
Erstellung eines Elementargraphen ist in Bild 8 dargestellt.
14
Rollenbahn RB68-L1/6
1. Zuordnen symbolischer
E/A-Signale
Sensor
Motor
belegt
2. Festlegen der
möglichen Zustände
ausfördern
einfördern
R
3. Festlegen der
Zustandsübergänge
drehen
Init
einfördern
leer
R schrittfördern
R
schrittfördern
2.
3.
belegt
4.
fertig
ausfördern
4. Festlegen des Verhaltens
bei Initialisierung
5. Festlegen der Kontrollflußschnittstellen
leer S
5.
R
R
leer
7. ausfördern
S
Bild 8:
belegt S
R
6. Festlegen der
Zustandsanweisungen
7. Festlegen der
Übergangsbedingungen
schrittfördern
S fertig
Übergangsbedingung:
LD Sensor.belegt
6.
S
S
Zustandsanweisung:
PRE-STEP:
SET Motor.drehen
POST-STEP:
RES Motor.drehen
Vorgehensweise bei der Erstellung von Elementargraphen
Zur Koordinierung von Funktionseinheiten werden Funktionsgruppen definiert und mit
Ablaufgraphen beschrieben (Bild 9). Je nach Komplexität der betrachteten Maschine oder
Anlage können Ablaufgraphen in mehreren hierarchischen Ebenen angeordnet werden; ein
Ablaufgraph koordiniert hierbei Zustandsgraphen der hierarchisch unterlagerten Ebene.
15
Ablaufgraph Zuführeinrichtung
1. Ablaufgraph erstellen:
(Zustände, Zustandsübergänge, Zustandsanweisungen, Übergangsbedingungen,
Kontrollflußschnittstellen
2. Kontrollflußschnittstellen
des Ablaufgraphen
mit Kontollflußschnittstellen der Elementargraphen verbinden
Stange in TKF
einfördern
Stange an RB
abgeben
RB
starten
S
Grundstellung
R
einfördern R
R
belegt
leer
S
Bild 9:
R
S
EingangsAusgangsKontrollflußschnittstelle
R
Übergabe
beendet
ausfördern
Zustand
Übergang
Stange in RB
gefördert
S
S
Elementargraph
Rollenbahn
...
Elementargraph
Tragkettenförderer
Koordinierung von Elementargraphen über Ablaufgraph
Gegenseitige Synchronisationen von Zustandsgraphen werden durch die Kontrollflußbeschreibung mit Auftrags- und Quittungselementen erreicht. Neben der in Bild 2 dargestellten
„indirekten Synchronisation“ zwischen einem Ablaufgraph und den hierarchisch unterlagerten
Zustandsgraphen ist auch eine „direkte Synchronisation“ zwischen Elementargraphen möglich.
Durch die Kombination parallel arbeitender Zustandsgraphen wird die Gesamtfunktion einer
Maschine oder Anlage erreicht.
Charakteristisch für Zustandsgraphen ist, daß zu einem Zeitpunkt immer genau ein Zustand
aktiv ist. Dies macht Zustandsgraphen auch für den Entwurf von Diagnosefunktionen
interessant. In Verbindung mit den Programmiersprachen der IEC 1131-3 ermöglicht die
Zustandsgraphenmethode systematisch, durchgängig und herstellerübergreifend den Entwurf,
die Programmierung und den Test von Steuerungssoftware [Lutz95, Siem96]. Durch die funktionale, hierarchische Strukturierung sowie die vollständige Kapselung der Softwarebausteine
mit definierten Kontroll- und Datenflußschnittstellen bietet sie außerdem eine gute
Voraussetzung für die Wiederverwendung, insbesondere für die Softwarekonfigurierung aus
Baukastensystemen (siehe Kap. 2.2.2).
Nachteilig bei der Zustandsgraphenmethode wurde von den beteiligten Maschinenherstellern
die mangelnde Übersichtlichkeit bei der Modellierung komplexer Funktionseinheiten oder 16
gruppen beurteilt. Werden neben der Steuerungsfunktionalität für die einzelnen Betriebsarten
auch noch Diagnose- und Fehlerreaktionsfunktionen modelliert, erreicht ein Zustandsgraph
schnell 20 Zustände oder mehr. Der Anforderung nach Strukturierungsmöglichkeiten wurde
durch zwei Prinzipien begegnet:
1. Hierarchische Zustände,
2. Layertechnik mit benutzerdefinierten Filtern.
Hierarchische Zustände
Hierarchische Zustände eignen sich für die Gliederung eines Zustandsgraphen nach
unterschiedlichen, benutzerorientierten Kriterien, z.B. in Steuerungsfunktion und Fehlerbehandlung, nach Betriebsarten (Hand, Einrichten, Automatik) oder, bei Ablaufgraphen, in
Teil- oder Alternativabläufe. Bei dem in MoWiMa realisierten Vorgehen wird die Verfeinerung
eines hierarchischen Zustands in einem separaten Fenster vorgenommen. Ein hierarchischer
Zustand, der beliebig tief geschachtelt sein kann, kann so, auf mehrere Fenster verteilt,
gleichzeitig vollständig dargestellt werden (Bild 10). Die Zustandsgraphenmethode wurde um
die zusätzlichen Beschreibungslemente 'Hierarchischer Zustand', 'Abstrakte Transition'
'Eingangskonnektor' und 'Ausgangskonnektor' ergänzt (Bild 10). Hierarchische Zustände
dienen dem Benutzer zur graphischen Strukturierung des Entwurfs. Sie sind in „flache
Zustandsgraphen“ überführbar und werden vom System, auch für die Generierung des
Steuerungscodes, als solche behandelt.
Ein hierarchischer Zustand ist grafisch gekennzeichnet durch einen zusätzlichen konzentrischen
Kreis. Ihm kann ein Name, jedoch keine Zustandsanweisung zugewiesen werden. Statt dessen
enthält er einen internen Zustandsgraph. Alle Transitionen, die einen hierarchischen Zustand als
Quelle oder Ziel haben, werden als abstrakte Transition interpretiert (Bild 10, linkes Fenster).
Eine abstrakte Transition enthält keine Übergangsbedingung. Wird der Zustandsgraph eines
hierarchischen Zustands betrachtet, erscheinen diese abstrakten Transitionen als Eingangsbzw. Ausgangskonnektoren (Bild 10, rechtes Fenster). Diese stellen Platzhalter für die Quellbzw. Zielzustände der abstrakten Transitionen im übergeordneten Zustandsgraph dar und
enthalten den jeweiligen Zustandsnamen. Von bzw. zu diesen Konnektoren können im
verfeinerten Zustandsgraph Transitionen mit Übergangsbedingungen definiert werden.
17
ZustandgraphSchlitten
Init
Graphische und
logische Strukturierung des ZG
nach z.B.
- Betriebsarten
- Fehlerbetrieb
- ...
nach_vorn
Zustandsgrapheneditor
Zeitüberwachung
Auch ohne
Werkzeugunterstützung
anwendbar
Mitte
hinten
vorn
Hierarchischer Zustand Zeitüberwachung
nach_
hinten
nach_vorn
Init
Editorfenster für
Verfeinerung
des hierarchischen
Zustands
Aufruf
Zustand
Hierarchischer Zustand
Transition (mit Bedingung)
Abstrakte Transition (von/zu hierarch.
Zustand; ohne Bedingung)
Bild 10:
nach_hinten
Eingangskonnektor im hierarchischen
Zustand mit Quellzustand
Ausgangskonnektor im hierarchischen
Zustand mit Zielzustand
Hierarchische Zustände für die Zustandsgraphenmethode
Layertechnik
Eine weitere Möglichkeit, die Komplexität von Zustandsgraphen für den Benutzer handhabbar
zu machen, ist die Gliederung in Layern, wobei durch den Benutzer beliebige Filter definiert
werden können, wie z.B. für die Betriebsarten (Hand, Einrichten, Automatik) oder für
Steuerungsfunktionen und Fehlerbetrieb. Es sind somit die gleichen Gliederungsmöglichkeiten
wie mit hierarchischen Zuständen gegeben. Der Unterschied zu hierarchischen Zuständen
besteht darin, daß alle Gliederungsbenen in einer Darstellung (innerhalb eines Fensters) ein- und
ausgeblendet werden können. Wie bei den hierarchischen Zuständen dient die Gliederung von
Zustandsgraphen in Layer nur der grafischen Strukturierung und hat keine Auswirkungen auf
die Generierung des Steuerungscodes.
18
Grafische Strukturierung
des ZG nach z.B.:
Einrichtbetrieb
- Betriebsarten
Mitte
- Normal- und Fehlerbetrieb
- ...
Nur bei Werkzeugunterstützung
sinnvoll
Hand-Betrieb
Mitte
nach_vorn
hinten
vorn
Automatik-Betrieb
nach_hinten
Bild 11:
Layertechnik
Welche der beiden in MoWiMa realisierten Gliederungsmöglichkeiten, hierarchische Zustände
oder Layer, für einen bestimmten Anwendungsfall günstiger ist, muß der Benutzer nach eigenem
Empfinden selber entscheiden.
2.1.3 Beschreibung der Baukastensystematik mit Klassendiagrammen
Das Entwurfswissen über die statische Aufbaustruktur eines Maschinentyps und somit
die Softwarestruktur wird in der Baukastensystematik (in der Informatik auch
Rahmensystem oder Framework genannt) abgelegt und für neu zu erstellende Projekte
(Maschinenkonfigurationen) als Grundgerüst vorgegeben (Wiederverwendung von Entwurfswissen).
Die Baukastensystematik wird mit Hilfe von Klassendiagrammen beschrieben. Sie zeigen,
wie oft und in welcher Zusammensetzung die in der Baukastenbibliothek enthaltenen
Benutzertypen in einer Applikation auftreten und welche Beziehungen (Assoziationen) und
Restriktionen zwischen diesen Typen vorhanden sind.
Zu unterscheiden ist hierbei zwischen dem
19
• Systemklassendiagramm, welches für einen bestimmten Anwendungsbereich (z.B. für
maschinennahe Steuerungsfunktionen) erstellt wird und als Basis bereits im System hinterlegt
ist und dem
• benutzerorientierten Klassendiagramm, welches die benutzerspezifische und auftragsneutrale Beschreibung eines bestimmten Maschinentyps enthält.
Für die grafische Notation der Klassendiagramme wurden Elemente der Unified Modeling
Language, UML (vereinheitlichte Methode der Autoren G. Booch, J. Rumbaugh und I.
Jacobson) /Booc97/ übernommen, wobei Objekttypen entsprechend der "Klassen" als
Rechtecke mit Typname dargestellt werden. Innerhalb der Rechtecke sind zusätzliche
Kennungen für abstrakte Typen („A“ im Kreis) sowie für die Systemklasse, von der der
jeweilige Typ abstammt (z.B. „FG“ für Funktionsgruppe), enthalten (siehe Legende zu Bild
12). Beziehungen (besteht_aus, benutzt) werden durch Verbindungslinien mit einer Raute
bzw. einem Kreis am Linienanfang dargestellt. Ihnen kann eine Kardinalität zugeordnet werden.
2.1.3.1 Systemklassendiagramm: Beschreibung des Anwendungsbereichs
Das Systemklassendiagramm beschreibt grundlegende Zusammenhänge für den betrachteten
Anwendungsbereich unter Nutzung der dafür definierten Systemklassen (Baukastenbibliothek,
Kap. 2.1.1) und ist bereits im System hinterlegt. In Bild 12 ist das Systemklassendiagramm für
den in MoWiMa betrachteten Anwendungsbereich „maschinennahe Steuerungsfunktionen“
dargestellt. Die Systemklassen selber und deren Vererbungsbeziehungen sind bereits in der
Baukastenbibliothek (Bild 6) hinterlegt. Durch das Systemklassendiagramm (siehe Bild 12)
werden diese um folgende Beziehungen und semantische Abhängigkeiten ergänzt:
• eine Funktionsgruppe kann aus Funktionsobjekten (also weiteren Funktionsgruppen
und/oder Funktionseinheiten) bestehen;
• Funktionsobjekte können ElektrBetriebsmittel in beliebiger Anzahl beinhalten.
Das Systemklassendiagramm enthält nur Systemtypen und deren Beziehungen, es beschreibt
noch keinen Maschinentyp. Um einen konkreten Maschinentyp zu beschreiben, wird das
benutzerorientierte Klassendiagramm verwendet.
20
Funktionsgruppe
Entwurfsobjekt
A EO
A FG
1..N
Funktionsobjekt
A FO
0..1
Mechanik Bauteil
A MB
0..N
Informationshinweis
0..N
A
I
0..N 0..N
Elektr. Betriebsmittel
1..N
FG
A EB
A
Bild 12:
Steuerungsfunktionen“
für
den
besteht_aus - Beziehung
benutzt - Beziehung
Kardinalität
Kennung für Typ z.B.
Funktionsgruppe (FG)
Kennung für abstrakten Typ
Anwendungsbereich
„maschinennahe
2.1.4 Benutzerorientiertes Klassendiagramm: Beschreibung der Baukastensystematik eines Maschinentyps
Die Baukastensystematik definiert die auftragsneutrale Beschreibung eines Maschinentyps und
wird durch benutzerorientierte Klassendiagramme dargestellt (Bild 13). Sie zeigen, wie oft
und in welcher Zusammensetzung die in der Baukastenbibliothek enthaltenen Benutzertypen in
einer Maschinenkonfiguration auftreten und welche Beziehungen und Restriktionen zwischen
diesen Typen vorhanden sind. Analog zum Systemklassendiagramm, gelten Beziehungen, die
für einen abstrakten Benutzertyp definiert wurden, auch für alle Unterklassen.
In der Praxis des Maschinenbaus ist häufig die Beschreibung von Sonderfällen notwendig, so
daß auf diese geschlossene Art und Weise die Zusammensetzung eines Maschinentyps nicht
vollständig beschrieben werden kann. Daher müssen Ausschlußkriterien abgebildet werden
können. Die UML-Notation wurde zu diesem Zweck um die Beziehungen 'alternativ'
(entweder... oder... ) und 'restriktiv' (wenn... dann..., bzw. wenn .. dann nicht ...) ergänzt.
Bild 13 zeigt den Ausschnitt eines benutzerorientierten Klassendiagramms für eine Sägeanlage
der Fa. Behringer.
21
1
Visualisierung
A FE
A FG
1
1
Zuführeinrichtung
A FG
A FE
Rollenb. RB68-L1/6
Bild 13:
1
Positioniereinheit
A
1..2
Rollenbahn
A FE
Sägeanlage
FG
1
1
Sägeeinheit
A FG
Abführeinrichtung
A FG
0..1
Tragkettenförderer
A FE
Tragkettenf. TF77-4
0..1
1..2
FG
A FE
A
besteht_aus - Beziehung
benutzt - Beziehung
wenn...dann nicht...-Beziehung
Kardinalität
Kennung für Typ z.B.
Funktionsgruppe (FG)
Kennung für abstrakten Typ
Klassendiagramm einer Sägeanlage (Ausschnitt)
Mit der Definition der Baukastenbibliothek und der Erstellung des benutzerorientierten
Klassendiagramms ist die Baukastenerstellung (auftragsneutrale Maschinentypbeschreibung)
abgeschlossen. Wie mit Hilfe eines solchen Baukastens auftragsspezifisch Maschinen
konfiguriert werden können, wird im folgenden erläutert.
2.2 Maschinen- und Softwarekonfigurierung
Die Maschinen- und Softwarekonfigurierung umfaßt auftragsspezifische Tätigkeiten, also die
Projektarbeit unter Nutzung eines vorhandenen Baukastens. Sie ist in zwei Phasen gegliedert,
wobei jeweils eine spezielle Sicht dargestellt wird:
• Maschinenkonfigurierung: Sie entspricht der Analysephase der Softwaererstellung. Es
werden, noch unabhängig von der Betrachtung der Steuerungssoftware, Entwurfsobjekte
aus der Bibliothek instanziiert, wodurch, ermöglicht durch die Teilmodelle, die den
Entwurfsobjekten zugeordnet sind (siehe Bild 6), bereits Stücklisten,
Funktionsbeschreibungen oder Angebotstexte zuammengestellt werden können. Diese
Tätigkeit wird in der Regel bereits durch den Vertrieb durchgeführt. Neben der
Instanziierung von Entwurfsobjekten aus der Baukastenbibliothek können auch
22
auftragsspezifische Entwurfsobjekte („Sonderkonstruktion“) definiert werden. Eine
Maschinenkonfiguration wird dargestellt durch Objektdiagramme.
• Softwarekonfigurierung: Sie entspricht der Designphase der Softwareerstellung. Es
werden die Funktionsmodelle, die den Funktionsobjekten der Maschinenkonfiguration
zugeordnet sind, sowie deren Zusammenwirken detailliert beschrieben. Eine
Softwarekonfiguration wird definiert durch Funktionsbausteindiagramme; Funktionsbausteine nach IEC 1499 bzw. IEC 1131-3 werden zu einem Steuerungsprogramm konfiguriert.
2.2.1 Maschinenkonfigurierung: Erstellung von Objektdiagrammen
Maschinenkonfigurationen werden durch Objektdiagramme beschrieben und stellen die
Struktur einer konkreten Maschine oder Anlage dar. Die Softwareerstellung steht hierbei noch
nicht im Mittelpunkt; Entwurfsobjekte und deren Beziehungen werden unabhängig von der
Implementierung betrachtet. Ein Objektdiagramm wird aus einem benutzerorientierten Klassendiagramm entwickelt, wobei zwei Vorgehensweisen denkbar sind:
• Es wird systemunterstützt zunächst eine Objektdiagrammvorlage generiert, in der die
(z.T. abstrakten) Klassen des benutzerorientierten Klassendiagramms als Platzhalter für
Instanzen konkreter Unterklassen repräsentiert werden. Die Ersetzung der Platzhalter durch
konkrete Benutzertypen aus der Baukastenbibliothek erfolgt durch den Benutzer, wobei die
im hinterlegten Klassendiagramm definierten Kardinalitäten und Restriktionen durch das
System überprüft werden (Bild 14).
• Es wird durch das System ein Default-Objektdiagramm generiert, das bereits einen
konkreten und vollständigen Vorschlag für die „am häufigsten verkaufte Maschine“ darstellt.
Dies bedeutet, daß die im benutzerorientierten Klassendiagramm enthaltenen Freiheitsgrade
(z.B. durch abstrakte Klassen oder Kardinalitäten) defaultmäßig aufgelöst werden. Bei einer
Änderung des Objektdiagramms wird jedoch ebenfalls die Konformität zum benutzerorientierten Klasssendiagranmm durch das System überprüft
23
Baukasten
Benutzerorientiertes
Klassendiagramm
Maschinenkonfiguration
Objektdiagrammvorlage
Zuführeinrichtung
(Maschinentypbeschreibung)
Sägeanlage
FE
A FG
A
Sägeeinheit
FG
A
1..2
FE
FG
Generierung
Sortiereinheit
Rollenbahn
A FG
0..1
Rollenbahn
A
0..1
1
1
Zuführeinrichtung
Tragkettenförderer
A
FE
Baukastenbibliothek
Funktionseinheit
Rollenbahn
Rollenbahn, 1Ri.
Objektdiagramm
(Maschinenkonfiguration)
ZE1
Instanziierung
konkreter Typen
RB1
RB68-L1/4
RB68-L1/6
Bild 14:
Konkretisierung
Visualisierung
A
I
-S1
-S2 -M1
Zuführeinrichtung
ZE24-F2
Rollenbahn
RB68-L1/6
Vom benutzerorientierten Klassendiagramm zum Objektdiagramm über die
Im Gegensatz zur UML bleibt in der MoWiMa-Methode innerhalb der Objektdiagrammbeschreibung die Aggregationsstruktur (besteht_aus-Verbindungen, Bild 15) aus dem
benutzerorientierten Klassendiagramm erthalten. Dadurch ist die für maschinenbauliche
Anwendungen wesentliche bauliche Struktur jederzeit transparent, welche auch einem
Mitarbeiter aus dem Vertrieb oder der mechanischen Konstruktion die Maschinenkonfiguration
verständlich macht. Bild 15 zeigt beispielhaft ein Objektdiagramm, das aus dem
Klassendiagramm von Bild 13 erstellt wurde.
24
Sägeanlage
HBP1
Visualisierung
VS23
Zuführeinrichtung
ZFE1
Tragkettenförderer
TF3
Rollenbahn
RB1
I
-S1
Bild 15:
-S2
-M1
-S1
-M1
besteht_aus
benutzt
Objektdiagrammm einer Sägeanlage (Ausschnitt)
2.2.2 Softwarekonfigurierung: Erstellung von Funktionsbausteindiagrammen
Bei der Softwarekonfigurierung wird die Softwareerstellung aufbauend auf der zugrundeliegenden Maschinenkonfiguration betrachtet. Werden im Objektdiagramm Funktionsobjekte
aus der Baukastenbibliothek instanziiert, werden die zugeordneten Funktionsmodelle automatisch mitinstanziiert. Für auftragsspezifische Funktionsobjekte (Sonderkonstruktionen)
müssen i.d.R. auch auftragsspezifische Funktionsmodelle erstellt werden.
Aus dem Funktionsmodell welches z.B. als Zustandsgraph modelliert ist, kann Steuerungscode
in Form eines Funktionsbausteins (FB) generiert werden. Somit kann ein Funktionsobjekt für
die Softwarekonfigurierung als Instanz eines Funktionsbausteins repräsentiert werden. Als
Erweiterung der IEC 1131-3 werden in der IEC 1499 /Iec96/ Funktionsbausteine mit
Zustandsgraphen modelliert und für die Softwarekonfigurierung als Blöcke mit Kontroll- und
Datenflußschnittstellen (Input- und Output-Events, bzw. -Variablen) dargestellt (Bild 16). Die
Softwarekonfigurierung wird schließlich durch grafisches Verbinden der Kontroll- und
Datenflußschnittstellen erreicht. Diese Art der Darstellung wird als Funktionsbausteindiagramm
(FBD) oder Continuous Function Chart (CFC) bezeichnet (Bild 17).
25
Durch die Generierung von Funktionsbausteinen aus Zustandsgraphen kann die Information aus
der Maschinenkonfiguration weitgehend in die Softwarekonfiguration übernommen werden,
was einem Übergang ohne Bruch von der Analyse- in die Designphase entspricht. Bei der
Softwarekonfigurierung können zusätzlich notwendige Anpass-Funktionsbausteine, die z.B.
steuerungs- oder antriebsspezifische Treiber enthalten, instanziiert und mit den
steuerungsunabhängigen Funktionsbausteinen aus der Baukastenbiblitohek verknüpft werden.
Zustandsgraph
Funktionsbaustein
Init
leer
R
einfördern ausfördern
R
ausfördern
R
schrittfördern
S
einfördern
belegt
schrittfördern
fertig
leer
"BlackBox"S
Darstelbelegt lung
S
InputEvents
schrittfördern
einfördern
ausfördern
InputVariablen Schrittweite
schrittfördern
fertig
OutputEvents
belegt
leer
OutputVariablen
schrittfördern
fertig
Kontrollflußschnittstelle
Datenflußschnittstelle
Bild 16:
26
Funktionsbausteindarstellung nach IEC 1499, generiert aus dem Zustandsgraph der
Rollenbahn aus der Baukastenbibliothek
Visualisierung
VS23
Sägeanlage
HBP 1
Rollenbahn
RB 1
Tragkettenförderer TF 3
Zuführeinrichtung
ZFE 1
Bild 17:
Grafischer Steuerungssoftwareentwurf als Funktionsbausteindiagramm nach IEC
1499
2.3 Codegenerierung und Steuerungsankopplung
Nach Vervollständigung der grafischen Softwarekonfiguration kann, die Unterstützung durch
ein entsprechendes CASE (Computer Aided Software Engineering)-Tool vorausgesetzt, die
Generierung von Steuerungscode sowie die Kopplung an die Steuerung vorgenommen werden.
Bei dem im Rahmen des Projekts MoWiMa erstellten CASE-Tool erzeugt für diesen Zweck
ein Codegenerator aus den Zustandsgraphen und FB-Diagrammen Anweisungsliste nach IEC
1131-3, welche durch handelsübliche Programmiersysteme eingelesen werden können. Diese
stellen dann den steuerungsspezifischen Compiler zur Verfügung, welcher den Maschinencode
erzeugt, der dann auf die Steuerung transferiert werden kann.
Für die Vervollständigung des in Bild 4 dargestellten Lebenszyklusses für objektorientierte
Steuerungssoftware sind zusätzliche Werkzeugfunktionen notwendig, die das Testen
(Monitoring, Debugging) der Software sowie das Inbetriebnehmen der Maschine in der
Entwurfsbeschreibung (z.B. auf Zustandsgraphenebene) ermöglichen. Eine Übersicht über die
Codegenerierung und Steuerungsankopplung des MoWiMa CASE-Tools zeigt Bild 18.
27
Bild 18:
Codegenerierung und Steuerungsankopplung des MoWiMa CASE-Tools
2.3.1 Codegenerierung: Integration des CASE-Tools in das IEC 1131-3 Modell
Im Kapitel 2.2.2 und Kapitel 2.3 ist die Vorgehensweise der Softwareerstellung von der
Analysephase in die Designphase über ein IEC 1131-3 Modell mit der anschließenden
Codegenerierung und Steuerungsankopplung beschrieben worden. Dieses Kapitel befaßt sich
nun speziell mit Gesichtspunkten, die bei der Anwendung des IEC 1131-3 Modells zu
berücksichtigen sind.
Bei der Wahl des Programmiermodells sind folgende Randbedingungen zu beachten:
1. Globalisierung:
International operierende Maschinen- und Anlagenbauer sind häufig gezwungen,
unterschiedliche Steuerungsplattformen zu unterstützen: Die Maschine und ihre Funktionalität
bleibt prinzipiell gleich; die Art der eingesetzten Automatisierungsgeräte wird jedoch vom
Kunden vorgegeben und wechselt daher von Wirtschaftsraum zu Wirtschaftsraum. Die
unangenehme Folge sind unterschiedliche Versionen der Steuerungssoftware für einen
Maschinentyp. Eine wirklich wiederverwendbare Software muß daher ohne große
28
Anpassungen auch für unterschiedliche Steuerungstypen und -architekturen (z.B. dezentral zentral) nutzbar sein.
2. Standardisierung in der Automatisierungstechnik:
Der Trend zur Standardisierung in der Automatisierungstechnik ist unverkennbar. Mit
Standardisierung, z.B. im Bereich der Programmierung (IEC 1131-3) und der Feldbustechnologie (CAN, Profibus etc.), wird dem Maschinen- und Anlagenbauer ermöglicht,
in seiner Automatisierungslösung Komponenten unterschiedlicher Hersteller zu verwenden.
Bei der Wahl des Programmiermodells innerhalb des MoWiMa CASE-Tools wurde
diesem Trend Rechnung getragen, um eine möglichst große Zahl von Anwendern erreichen
zu können.
3. Standardisierung im Engineering:
Hauptnutzen des MoWiMa CASE-Tools soll es sein, die Softwareerstellung als integralen
Bestandteil des Engineeringprozesses zu betrachten (Kapitel 1.3). Eine 1:1-Abbildung
zwischen Maschinen- und Steuerungshard- bzw. -softwarestruktur bildet hierfür die
Grundlage: durch die Definition von Funktionsobjekten wird ermöglicht, daß sowohl der
Maschinenkonstrukteur als auch der Steuerungsprojektierer bzw. -programmierer mit
derselben objektorientierten Betrachtungsweise arbeiten. Durch die Wahl des
Programmiermodells muß gewährleistet sein, daß diese objektorientierte Maschinenstruktur
durchgängig bis zur Implementierungsebene unterstützt wird.
Angesichts dieser Randbedingungen wurde als Programmiermodell das IEC 1131-3 Modell
gewählt. Als international unterstützter Standard findet es Anwendung auf allen Gebieten der
Automatisierungstechnik; Praxisbezug und Akzeptanz des CASE-Tools sind dadurch
weitestgehend gewährleistet. Eine wichtige Eigenschaft, die für die Umsetzung eines
objektorientierten Modells in ein Steuerungsprogramm zur Verfügung steht, ist hier das
Funktionsbausteinprinzip.
Im folgenden werden die einzelnen Schritte für die Erzeugung eines Steuerungsprogramms nach
IEC 1131-3 aus Zuastandsgraphen detailliert aufgezeigt. Die Vorgehensweise ist jedoch auch
auf andere Beschreibungmittel übertragbar. Die Erzeugung eines ablauffähigen
Steuerungsprogramms nach IEC 1131-3 gliedert sich wie folgt:
29
Bild 19:
IEC 1131-3 als Bindeglied zwischen MoWiMa CASE-Tool und Zielplattform
1. Codegenerierung aus Funktionsobjekten: Aus Zustandsgraphen werden wiederverwendbare IEC 1131-3 Funktionsbausteine (FB, Programmorganisationseinheit FUNCTION
BLOCK)) generiert, 1:1-Abbildung Funktionsobjekt <-> Funktionsbaustein.
2. Softwarekonfigurierung durch Verdrahten der FBs im Funktionsbausteindiagramm (CFC).
Generierung der Programmorganisationseinheit (POE) PROGRAM.
3. Importieren des Steuerungsprogramms in eine auf die Zielplattform angepaßte Programmierumgebung.
4. Erzeugen von Maschinencode für die gewählte Zielplattform innerhalb der Programmierumgebung.
5. Test- und Inbetriebnahme mit der Programmierumgebung (auf AWL-Ebene) sowie
innerhalb des CASE-Tools auf Entwurfsebene (z.B. im Zustandsgrapheneditor).
30
2.3.2 Generierung wiederverwendbarer IEC 1131-3 Funktionsbausteine aus
Funktionsobjekten
Wesentliches Merkmal von Funktionsobjekten ist die Wiederverwendbarkeit. Für die
Umsetzung in Steuerungsquellcode bietet das Funktionsbausteinprinzip des IEC 1131-3
Modells eine geeignete Grundlage: FBs können beliebig instanziiert und dadurch
wiederverwendet werden. Sie besitzen eine kontextunabhängige Schnittstelle mit Ein- und
Ausgangsparametern und bekommen vom Zielsystem einen eigenen Speicherbereich für ihre
lokalen Variablen zugewiesen. Dies erhöht den Grad der Wiederverwendbarkeit im Vergleich
zu dem von Steuerungen älterer Generation verwendeten prozeduralen Bausteinprinzip (z.B.
Step5).
Bild 21:
Übergang vom Funktionsmodell in das IEC 1131-3 Modell
Durch die werkzeugunterstützte Überführung des Funktionsmodells in das IEC 1131-3 Modell
wird die Integration von Designphase und Implementierung realisiert. Hierfür stehen der
Zustandsgrapheneditor (ZG) mit einem IEC 1131-3 AWL-Codegenerator, das
Funktionsbausteindiagramm (CFC) und die herkömmlichen IEC Sprachen zur Verfügung. So
kann z.B. der Maschinenkonstrukteur mit Hilfe des Zustandsgrapheneditors die Funktionalität
seines Funktionsobjektes „im Groben“ festlegen, indem er Zustände und Transitionen sowie
Kontroll- und Datenflußschnittstellen definiert. Die entsprechenden Aktionen und
Übergangsbedingungen kann er prosaisch formulieren. Der SPS-Programmierer verfeinert den
Entwurf ebenfalls mit Hilfe des Zustandsgrapheneditors, indem er, basierend auf den
schriftlichen Anmerkungen des Konstrukteurs, die Übergangsbedingungen in den Transitionen
und die Aktionen in den Zuständen in AWL ausprogrammiert.
31
Die Generierung eines Funktionsbausteins (FB) nach IEC 1131-3 aus einem Zustandsgraphen
wird folgendermaßen realisiert:
• Zustände und Transitionen spiegeln sich jeweils als lokale boolsche Variablen wieder. Dies
ermöglicht bei Test- und Inbetriebnahme das Debuggen des Zustandsgraphen.
• Kontrollflüsse werden nach außen ebenfalls als Input und Output Variablen definiert und
ermöglichen ein Verdrahten des FBs mit anderen Zustandsgraphen auf Funktionsbausteindiagrammebene (CFC).
• Benötigte Sensor/Aktorsignale werden ebenfalls als Input und Output Variablen definiert.
Sie müssen über die Programmebene des IEC 1131-3 Programms an die Peripherie
verdrahtet werden.
• Aktionen und Übergangsbedingungen sowie die Struktur des Zustandsgraphen werden in
AWL programmiert bzw. generiert. Dies ermöglicht im Hinblick auf die Portierung für
unterschiedliche Zielplattformen den größtmöglichen Wiederverwendungsgrad (siehe
Portability-Level AWL)
Die IEC 1131-3 garantiert eine größtmögliche Plattformunabhängigkeit der Steuerungssoftware. Der Standardisierungsdruck auf dem Markt hat jedoch noch nicht so weit geführt,
daß Hersteller von IEC 1131-3-kompatiblen Controllern einheitliche Programmierwerkzeuge
anbieten. Die mit unterschiedlichen Programmierumgebungen erzeugten IEC 1131-3
Applikationen sind nicht uneingeschränkt untereinander austauschbar. Dies führt dazu, daß
nicht „überall wo IEC 1131-3 drauf steht, auch IEC 1131-3 drin ist“, zumindest nicht im
Hinblick auf Kompatibilität.
Abhilfe schafft hier die PLCopen, ein Interessenverband von SPS-Herstellern und Softwareunternehmen. Im Zuge von weiterführenden und strengeren Normungstätigkeiten für IEC
1131-3 Systeme haben die Mitglieder der PLCopen verschiedene Kompatibilitätslevel, z.B.
den Portability-Level, definiert. Mit entsprechenden, fest vorgegebenen Testskripten können
Hersteller ihre Produkte auf Normkonformität und Kompatibiliät überprüfen lassen und ein
Zertifikat erlangen.
Der Portability-Level garantiert die Austauschbarkeit von IEC 1131-3 Applikationen zwischen
verschiedenen Steuerungsplattformen unterschiedlicher Hersteller. Er definiert einen auf
Dateiaustausch basierenden Import-Export Mechanismus (File-Exchange-Format, FxF) für die
jeweiligen Programmierumgebungen und garantiert, daß das Laufzeitverhalten auf allen
Zielplattformen gleich ist.
32
Der Portability-Level und das FxF beschränken sich auf die textuellen Sprachen der IEC
1131-3 (AWL und ST). Funktionsbausteine die im Original mit AS, KOP oder FBD erstellt
wurden, müssen daher in AWL oder ST querübersetzt werden. Beim Exportieren dieser Pläne
werden keine graphischen Informationen im AWL- oder ST-Funktionsbaustein abgelegt,
lediglich ein Verweis auf die Originalsprache wird hinterlegt. Beim Import solcher FBs stehen
diese Bausteine nur in AWL oder ST zur Verfügung, es sei denn, die importierende
Programmierumgebung unterstützt die Rückübersetzung von textuellen Sprachen in graphische
Originalsprachen.
Bild 22:
Anwendung des Portability-Levels
Die mit dem IEC 1131-3 Codegenerator des MoWiMa CASE-Tools erzeugte Steuerungssoftware entspricht diesem Portability-Level und kann über FxF in alle mit PortabilityLevel zertifizierten Programmierumgebungen importiert werden. Die anschließende Generierung
von Maschinencode sowie Test und Inbetriebnahme erfolgt in den jeweiligen plattformspezifischen Programmierumgebungen.
2.3.3 Test und Inbetriebnahme
Neben Entwurf und Programmierung steuerungstechnischer Funktionen ergeben sich durch die
Inbetriebnahme weitere Aufgaben für das MoWiMa-CASE-Tool. Als gegeben vorausgesetzt
wird die Anzeige steuerungsspezifischer Register (z.B. für Statusinformationen aus dem
33
Betriebssystem bzw. der Hardware der Steuerung) und die an der Steuerung anstehenden
Port-Werte.
Das Hauptaugenmerk der Inbetriebnahme soll hierbei auf den Entwurfsbeschreibungen
„Zustandsgraph“ und „CFC-Diagramm“ liegen. Um Test und Inbetriebnahme auf
Entwurfsebene durchführen zu können, werden Funktionen benötigt, die aus aktuellen
Variablenwerten der Steuerung online den direkten Rückschluß auf Modellinformationen
erlauben und diese anzeigen. Bild 23 zeigt beispielhaft die Zustandsverfolgung auf
Zustandsgraphenebene.
Bild 23:
Zustandsverfolgung im Zustandsgraph
Zusätzlich zur Anzeige sind Funktionen
Steuerungsprogramms beeinflussen:
•
•
•
•
gefordert,
die
die
Abarbeitung
des
Stopp eines /mehrerer Graphen in einem vorgegebenen Zustand (Breakpoint) bzw.
beliebiges Einfrieren des zuletzt gültigen Zustands,
Einzelschrittbetrieb mit manueller Freigabe eines Zustandswechsels und
Forcen bzw. Zwangssetzen eines Zustandsgraphen in einen definierten Zustand.
Da bisher in keiner Norm der Aufbau und Umfang eines geeigneten Testsystems festgelegt
wird, zeigt Bild 24 beispielhaft einen Vorschlag für den Testeditor: In tabellarischer Form wird
neben der Anzeige des aktuell gültigen Zustands (als Nummer und Zustandsname) der gerade
34
anstehende Bearbeitungsmodus sowie der Breakpoint angezeigt. Die o.g. Interaktionsmöglichkeiten werden über Tasten ausgelöst.
Bild 24:
Übersicht über ausgewählte Zustandsgraphen mit Interaktionstasten
Derzeitige Testsysteme kennen bereits Variablenlisten (häufig auch als „Watches“ bezeichnet).
Bei großen Projekten leidet jedoch aufgrund der Fülle anzuzeigender Daten die Übersichtlichkeit. Günstig ist es deshalb, für jedes CFC-Diagramm bzw. für jeden Zustandsgraph in einer
weiteren Relation für den Test benötigte Variablenlisten (Bild 25) zu hinterlegen und
abzuspeichern. Der Inbetriebnehmer kann somit bei der Integration getesteter Teilfunktionen in
ein Gesamtprojekt schnell auf ursprüngliche Testinformation zurückgreifen.
35
Bild 25:
Editor zur Anzeige /Änderung der im Zustandsgraph „Koordinator_1“ zum Test
hinterlegten Variablen
Der Test direkt an der Maschine ist nicht nur wegen der Bindung von Ressourcen und Geräten
zeit- und kostenintensiv, meist ist auch das Test-Umfeld psychisch und physisch belastend. Der
Einsatz von Simulationsumgebungen im Büroumfeld ist deshalb notwendig: Die Steuerung ist
nachzubilden, wobei das originale Steuerungsprogramm ohne Abänderungen abgearbeitet
werden können muß. Einflüsse der „Echtzeit“ sind weitgehend auszuschließen, um genügend
Zeit für manuelle Aufzeichnungen bzw. Interaktionen am Simulationssystem zu haben. Positiver
Nebeneffekt dieses Systems ist es, ohne die Gefahr „Zerstörung der Maschine“ testen zu
können.
3 Werkzeugunterstützung
Basierend auf den dargestellten Vorgehensweisen und Methoden wurde im Rahmen des
Projekts ein CASE-Tool realisiert, welches Werkzeugkomponenten für die abteilungsübergreifende Baukastendefinition und für die Maschinen- und Softwarekonfigurierung umfaßt
(Bild 26).
36
Zustandsgrapheneditor
Klassendiagrammeditor
Ergebnis
Baukastensysteme
Klassen-/
Typenbibliothek
Bild 26:
Klassendiagramm
Vertrieb
Kunde
Elektrokonstruktion
Auftragsbearbeitung
Nutzung von
Werkzeugen
Definition von Baukastensystemen
Nutzung von
Werkzeugen
Klassen-/
Typeneditor
Mechanikkonstruktion
Baukastendefinition
Anwendung von Baukastensystemen
Vertrieb Elektrokonstruktion
Mechanikkonstruktion
M1
ObjektdiagrammM2
editor
S1
Funktionsbausteindiagrammeditor
S2
Codegenerator
Ergebnis
Maschinenkonfigurationen
Spindeleinheit
Vorschubschlitten
M1
VAR
...
...
M2
S1
S2
END_VAR
Werkzeugunterstützte Baukastendefinition und Maschinenkonfigurierung
Die Kopplung der MoWiMa-Werkzeugkomponenten, auch mit externen Werkzeugen und
Steuerungssystemen, wird basierend auf dem von Microsoft für Windows entwickelten OLE
(Object Linking and Embedding)- bzw. OPC- Konzept (OLE for Process Control) /Opc96/
realisiert. OPC stellt einen Kommunikationsstandard basierend auf OLE dar, der eine effiziente
und einfache Kommunikation zwischen verschiedenen Automatisierungsebenen ermöglichen
soll. Es werden Objekte und Methoden für die Kommunikation zwischen Entwurfs- und
Visualisierungssystemen, Prozeßleit- und Steuerungsebenen sowie intelligenten Feldbussystemen definiert. Dadurch wird eine tragfähige Basis für PC-basierte Automatisierungslösungen geschaffen, wie sie z.B. auch in der OMAC-Spezifikation /Oma94/ von der
amerikanischen Automobilindustrie gefordert wird.
3.1 Aufbau des MoWiMa CASE-Tools
Der im Rahmen von MoWiMa eingesetzte Prototyp zeichnet sich durch die Integration von
neuentwickelten Werkzeugen mit industriell bewährten Produkten aus.
Fehler! Keine gültige Verknüpfung.Bild 27: Aufbau des MoWiMa CASE Tools
37
Neuentwickelte Werkzeuge sind:
• Bibliothek mit Browser,
• Klassendiagrammeditor (KD),
• Objektdiagrammeditor (OD),
• Zustandsgrapheneditor (ZG),
• Funktionsbausteindiagrammeditor (CFC)
• und AWL Codegenerator (AWLGen).
Integriert wurde aus der IEC 1131-3 Programmierumgebung OpenPCS von infoteam ein
AWL Syntaxchecker (AWLCheck), welcher die vom AWLGen erzeugten Quellen auf
Einhaltung der IEC 1131-3 Norm überprüft und gegebenenfalls entsprechende Fehlermeldungen liefert. Der Zugriff des CASE-Tools auf die Dienste des Syntaxcheckers erfolgt
über OLE Automation.
Für die Softwarekonfigurierung kommt der CFC-Editor des CASE- Tools zum Einsatz. Die
Anbindung an den Prozeß erfolgt im Prototypen mit Hilfe der Programmierumgebung
OpenPCS. Die vom AWLGen erzeugten Quellprogramme werden vom Compiler übersetzt
und mit der Test-&Inbetriebnahmekomponente (T&I) auf die gewünschte Zielplattform
geladen. Durch bereits vorhandene, steuerungsspezifische Ankopplungen von OpenPCS an
unterschiedliche SPSen kann das MoWiMa CASE-Tool ohne weitere Anpassung für Steuerungen der Hersteller Klöckner Moeller, Schleicher, Pilz und Weidmüller eingesetzt
werden. Die im OpenPCS enthaltene SmartPLC emuliert eine IEC 1131-3 Steuerung auf dem
PC und ermöglicht somit den Offline-Test der Applikation ohne Prozeß und ohne reale
Steuerung. Da OpenPCS von der PLCopen bereits Portability-Level- zertifiziert ist und auch
weitere Anbieter nachziehen, können durch die vom AWLGen erzeugten Quellprogramme mit
den im OpenPCS enthaltenen Import/Export-Funktionen (FxF) weitere Zielplattformen
unterstützt werden.
4 Piloteinsatz des CASE-Tools bei der Firma Behringer
Aus der Vielfalt der Bandsägemaschinen der Fa. Behringer wurde die Bandsägemaschine Typ
HBP263A für die Realisierung des Pilotprojektes ausgesucht. Die Bandsägemaschine Typ 263
A ist der kleinste Typ, der mit einem SPS-Steuerungsprogramm ausgestattet wird. Es handelt
sich um eine Standard-Bandsägemaschine, welche halbautomatisch arbeitet. Diese Wahl wurde
aus Zeitgründen getroffen, da die Maschine auf der SPS/IPC/Drives Messe mit dem Prototyp
38
des CASE_Tool-Aspect gezeigt werden sollte. Die Fertigstellung eines anderen
Bandsägemaschinentyps wäre kurzfristig nicht möglich gewesen.
4.1 Funktionsbeschreibung
Die Bandsägemaschine ist zum Trennen von Rund-Material bis max. 260mm Durchmesser
sowie von Vierkant-Material 300mm X 260mm B X H ausgelegt. Die maximale
Abschnittlänge je Hub beträgt 400mm, es können bis zu 9 Hübe eingestellt werden. Die
Abschnittlänge je Hub wird am Handrad mechanisch eingestellt, die Hubzahl wird am
Codierschalter an der Bedientafel eingegeben, ebenso die zu fertigende Stückzahl.
Die Sägemaschine arbeitet halbautomatisch, d. h. der Bediener muß das Material von Hand auf
den Nachschubschlitten legen. Nach dem Einschalten des Automatikbetriebes wird das
Material vorgeschoben und gesägt. Die Maschine arbeitet vollautomatisch bis die Stückzahl
erreicht bzw. kein Material mehr vorhanden ist. Dann schaltet sie sich selbständig aus.
Wenn das Material vom Bedienpersonal am Nachschubschlitten aufgelegt ist sowie Hubzahl
und Stückzahl eingegeben wurden, kann der Automatikbetrieb eingeschaltet werden. Dabei
muß der Benutzer vor dem Einschalten des Automatikbetriebes darauf achten, daß der Weg
für das Positionieren des zu bearbeitenden Materials frei ist. Zunächst wird das Material durch
den Nachschubgreifer gespannt und über den hydraulisch gesteuerten Nachschubschlitten in
der Maschine positioniert bzw. bis zum Anschlag der eingestellten Schnittlänge vorgeschoben.
Bei mehr als einem eingestellten Hub, wird das Material so lange vorgeschoben, bis die
Hubzahl erreicht ist.
Jetzt wird das Material durch die Materialzange, die im Sägebereich sitzt, gespannt. Ist das
Material gespannt, erhalten der Sägerahmen und der Sägeantrieb die Freigabe, die Säge zu
senken und das Material zu sägen. Wenn das Material fertig gesägt ist, fährt der Sägerahmen
hoch, und der Sägeantrieb wird abgeschaltet. Befindet sich der Sägerahmen über dem
Material, öffnet der Nachschubgreifer die Spannbacken, der Nachschubschlitten fährt zurück,
um neues Material vorzutransportieren. Hat der Nachschubgreifer das Material von neuem
gespannt, öffnet die Materialzange die Spannbacken. Dadurch wird der Weg für einen neuen
Transport frei. Der gesamte Vorgang wiederholt sich, bis die Stückzahl erreicht ist.
39
Nachschubgreifer
Säge
Sägerahmen
Materialzange
Positioniereinheit
Sägeband
Nachschubschlitten
Bild 28:
Schematischer Aufbau der Bandsägemaschine Typ HBP263A
4.2 Funktionsobjekte der Bandsägemaschine Typ HBP263A
Nach objektorientierten Gesichtspunkten konnten wir große, komplexe Elemente in kleine und
einfache Komponenten zerlegen, sog. „Funktionsobjekte“ (Bild 29).
Der Maschinentyp mit allen Bauteilen, Sensoren und Aktoren wurde unabhängig vom
Anwendungsfall durch Klassendiagramme beschrieben. Aus identifizierten Funktionsobjekten
und elektrischen Betriebsmitteln wurden benutzerdefinierte Klassen erzeugt und die Bibliothek
aufgebaut. Beziehungen zwischen Entwurfsobjekten wie besteht_aus oder benutzt sowie
Kardinalitäten wurden ebenfalls in den Klassendiagrammen definiert. Innerhalb der Bibliothek
wurde für jedes Entwurfsobjekt die genaue Verwendungsart hinterlegt.
Durch Zusammenstellen von Entwurfsobjekten in einem Objektdiagramm und die Verbindung
ihrer Schnittstellen wurde die Steuerungssoftware für eine konkrete Anlage vom Typ
HBP263A erstellt und die reale Anlage in Betrieb genommen. So konnte die erste Anlage
durch Konfigurieren aus dem Baukasten anstatt Neuprogrammierung in Betrieb genommen
werden.
Jedem Funktionsobjekt zugeordnet ist ein Zustandsgraph, der die Funktionalität des
Funktionsobjekts beschreibt. Für die Generierung von Steuerungsquellprogrammen nach IEC
1131-3 wurde der MoWiMa-Codegenerator verwendet. Die Zielpalttform stellte ein
Steuerungsgerät vom Typ PS416 von Klöckner-Moeller.
Der Softwareentwurf mit Zustandsgraphen sowie das Testen der Anlage auf Entwurfsebene
brachte eine wesentliche Verbesserung gegenüber der herkömmlichen Programmierweise. Der
40
methodische Entwurf ist übersichtlich, das Verfolgen der Zustände und das Orten von Fehlern
beim Test war schnell und einfach nachvollziehbar.
besteht aus
Sägemaschine-Ablaufsteuerung
1
1
1
1
Nachschubschlitten
Nachschubgreifer
1
FG = Funktionsgruppe
FE = Funktionseinheit
0..1
1
1
Sägerahmen-Ablaufsteuerung
Antriebs-Ablaufsteuerung
Sägeantriebs-Ablaufsteuerung
Drehzahlinitiator
Bild 29:
Sägeeinheit-Ablaufsteuerung
Positionieren
Auto_Betrieb
1
Hand_Betrieb
1
1
Bedientafel
1
Sägeantrieb
1
Sägerahmen
1
Vorschub
Spannvorrichtung-Ablaufsteurung
1
Materialzange
Klassendiagramm der Bandsägemaschine Typ HBP263A
4.3 Bewertung von Methode und Werkzeug
Durch das CASE-Tool ASPECT bekommt der Maschinenbauer ein Werkzeug in die Hand,
das ihm - insbesondere bei der Software-Erstellung - einige Vorteile zur Bewältigung seiner
Aufgaben bieten kann.
Die derzeitigen Marktanforderungen, wie höhere Maschinenflexibilität, höhere
Maschinenverfügbarkeit und kürzere Lieferzeiten zwingen uns zu immer kürzeren
Entwicklungszeiten. Das heißt, wir müssen rationeller und wirtschaftlicher als bisher arbeiten.
Die im MoWiMa-Forschungsprojekt entwickelte Methode ermöglicht uns, ein Projekt in allen
seinen Entwicklungsphasen genauestens zu beschreiben und zwar in einer Form, die für jeden
am Projekt Beteiligten verständlich ist, auch ohne genaue Kenntnisse über die
Steuerungsprogrammierung oder das CASE-Tool ASPECT zu besitzen, ähnlich wie jeder
41
Maschinenbauer eine Zeichnung lesen und interpretieren kann. Hervorzuheben ist die
interdisziplinär gute Verständlichkeit. So können Vertriebsmitarbeiter, Ingenieure, Techniker
oder Mechaniker ohne Programmierkenntnisse Aufbau und Funktion eines Maschinentyps
oder einer Maschinenkonfiguration verstehen. Darüber hinaus ist das CASE-Tool ASPECT für
jedermann leicht verständlich und erlernbar. So besteht zukünftig die Möglichkeit, ein
Werkzueg wie das CASE-Tool-Aspect durchgängig vom Vertrieb über die Konstruktion und
Softwareerstellung bis hin zum Service und Kundendienst einzusetzen.
Zusammenfassend seien aus Sicht von Behringer die Vorteile der MoWiMa-Methode und des
CASE-Tools nochmals genannt:
•
•
•
•
•
•
•
•
•
•
hierarchisch strukturierte Software, modular aufgebaut ,
Funktionsobjekte ermöglichen die Wiederverwendung,
Methode ist verständlich, transparent und übersichtlich,
Steigerung der Qualität durch Selbstdokumentation,
Steigerung der Produktqualität,
durchgehender Informationsfluß, schneller vom Entwurf zum Ergebnis,
kürzere Test- und Inbetriebnahmezeiten,
kostensparend,
Änderungen und Ergänzungen sind überschaubar und somit kalkulierbar,
besserer Personaleinsatz.
4.4 Organisatorische Probleme bei der Werkzeugeinführung, Bericht eines
Anwenders
Ein Wechsel von vorhandenen und bewährten Systemen auf neue Systeme geht niemals ohne
anfänglichen Mehraufwand vonstatten. Obwohl das MoWiMa CASE-Tool leicht zu erlernen
ist, muß man sich als Benutzer gründlich einarbeiten. Dies macht eine umfangreiche Schulung
sowohl in der Vorgehensweise und Methode, als auch in der Werkzeuganwendung notwendig.
Die Methode setzt objektorientiertes Denken voraus; eine Denkweise die durch die bisherigen
Werkzeuge nicht oder nur ansatzweise unterstützt wird und daher vielen SPS-Programmierern
fremd ist. Da das objektorientierte Denken jedoch der Natur des Gehirns entspricht, Dinge
einzuordnen, sollte die Einarbeitung für den einzelnen Mitarbeiter, unabhängig von der
Abteilungszugehörigkeit, mit vertretbarem Aufwand möglich sein.
42
Benutzung des Werkzeugs: Das MoWiMa CASE-Tool ist so aufgebaut, daß dem Benutzer die
Methode stets transparent zur Verfügung gestellt wird, von der Baukastendefinition,
Zustandsgraphenerstellung, Projekterstellung bis hin zur Codeerzeugung und Inbetriebnahme.
Da hier besonderer Wert auf Einheitlichkeit der Editoren und übersichtliche Darstellung sowie
einfache, intuitive Bedienung gelegt wurde, sollte auch hier die Einarbeitungszeit für den
einzelnen Mitarbeiter überschaubar gehalten werden können.
Bei der Einführung des Case-Tools müssen jedoch unternehmensweit einige organisatorische
Anpassungen vorgenommen werden. Bevor die eigentliche (produktive) Projekterstellung mit
dem Case-Tool beginnen kann, muß konzeptionelle Vorarbeit geleistet werden. Im folgenden
werden einige Gesichtspunkte aus Anwendersicht dargestellt:
• Analyse und Bibliotheksaufbau: Zunächst werden die ‘Standard-Anlagen’ logisch in
Funktionsgruppen und Funktionseinheiten zerlegt. Dabei gilt es, abstrakt zu denken und
besonderen Wert auf die Definition der Schnittstellen zu legen, um durch Nutzung der
objektorientierten Prinzipien Vererbung und Polymorphismus eine flexible Bildung und
Verwendung von Varianten zu ermöglichen. Die definierten Anlagenstrukturen können als
Klassendiagramme in die Bibliothek eingetragen werden. Weiterhin müssen
Zustangsgraphen für Funktionseinheiten und Funktionsgruppen erstellt werden.
• Zur Vermeidung von Doppel-Entwicklungen sollte die Bibliothek zentral verwaltet werden.
Hierbei bietet sich an, die Aufgabe der Bibliotheksverwaltung zunächst an eine einzelne
Person zu delegieren.
• Sobald die wichtigsten Standardkomponenten in der Bibliothek vorhanden sind, sollte ein
anstehendes Projekt mit dem Werkzeug erstellt werden.
• Umstieg auf andere Hardwareplattform: Das Case-Tool erzeugt Code nach IEC 1131-3.
Einige SPS-Hardwareplattformen sind nicht in der Lage, diesen Code zu verarbeiten. Sollte
dies in Ihrem Unternehmen der Fall sein, so bieten sich zwei Lösungsmöglichkeiten an:
1. Umstieg auf eine IEC 1131-3 - fähige Hardware. Welche Konsequenzen dies
haben wird, muß von Fall zu Fall geprüft werden.
2. Einsatz eines Compilers für die entsprechende Hardware. Hierzu sind auf dem
Markt Werkzeuge erhältlich, die den generierten Code direkt in Maschinencode der
entsprechenden Hardware umsetzen. Es ist dann sogar möglich, eine OnlineZustandsverfolgung im Case-Tool durchzuführen, falls das Werkzueg über eine
geeignete DDE- oder OLE Automationsschnittstelle verfügt.
43
Eine pauschale Prognose des durch die Werkzeugeinführung für ein Unternehmen entstehenden
Aufwands kann direkt nach Abschluß des MoWiMa-Projekts noch nicht gemacht werden. Im
Einzelfall müssen die anfänglich höheren Kosten mit den zu erwartenden Einsparungen im
Normalbetrieb verglichen werden.
5 Zusammenfassung und Ausblick
Im Rahmen des vom BMBF geförderten Verbundvorhabens MoWiMa (Modellierung und
Wiederverwendung objektorientierter Maschinensoftware) wurde eine Engineering-Methode
für die Modellierung und Programmierung maschinennaher Steuerungsfunktionen erarbeitet und
prototypisch in einem CASE-Tool realisiert. Sie unterstützt den Aufbau und die Nutzung
objektorientierter Software-Baukastensysteme . Für deren Beschreibung kann neben einer
Baukastenbibliothek mit wiederverwendbaren Klassen auch Entwurfsinformation über das
Zusammenwirken von Instanzen dieser Klassen für konkrete Maschinenkonfigurationen
hinterlegt werden. Es wurde hierfür eine Notation festgelegt, welche auf der objektorientierten
Modellierungssprache UML basiert und an die speziellen Bedürfnisse im Maschinen- und
Anlagenbau sowie der Steuerungsprogrammierung nach IEC 1131-3 angepaßt ist.
Wichtig hierbei ist die Integration der Softwareerstellung in den gesamten
Engineeringprozeß, der vom Vertrieb bis zur Inbetriebnahme und Dokumentation reicht. Für
einen durchgängigen und konsistenten Informationsfluß wurde ein Informationsmodell
erarbeitet, so daß eine interdisziplinäre Wiederverwendung standardisierter Lösungen
ermöglicht und somit die Basis für eine effiziente und kosten- sowie qualitätsgerechte Erstellung
von Steuerungssoftware im Maschinen- und Anlagenbau geschaffen werden kann. Das
prototypisch realisierte CASE-Tool wurde in der abschließenden industriellen Pilotphase bei
den beteiligten Maschinenherstellern erprobt, verifiziert und auf zahlreichen Messen und
Tagungen einem breiten Fachpublikum vorgeführt. Da die in MoWiMa erarbeiteten Methoden
und das Informationsmodell branchen- und unternehmensunabhängig spezifiziert wurden, ist im
Anschluß an das Projekt durch die Übertragung der gewonnenen Erkenntnisse auf weitere
Unternehmen eine Vervielfältigung des Nutzeffekts erzielbar.
Weiterführende Arbeiten beschäftigen sich mit der Nutzung des Informationsmodells für
die Betriebsphase (Bild 28). Neben der Steuerung(ssoftware) und elektronischen Dokumentation sollen Diagnose-, Service- und Produktionsinformationen in das Informationsmodell
44
integriert und somit die Basis für einen Informationskreislauf zwischen Maschinenhersteller und
-betreiber geschaffen werden.
Während des Betriebs gewonnenes Erfahrungswissen (z.B. über Störungsbehebungen) sowie
Informationen über den Produktionsprozeß (z.B. statistische Auswertungen) können dadurch
mit dem bei der Entwicklung und Konstruktion entstandenen Know-how
maschinenübergreifend zusammengeführt und unter Nutzung moderner Kommunikationstechniken wiederum dem Baukastensystem beim Maschinen- bzw. Anlagenhersteller zur
Verfügung gestellt werden.
Bild 28:
Anlageninformationsmodell
als
Maschinenhersteller und -betreiber
Basis
für
Informationssysteme
für
45
6 Literaturverzeichnis
[Aeg93]
N.N
MSL - Modicon State Language, User Manual.
AEG Modicon, North Andover, Massachusetts,1993
[Bir95]
Birrer, A. u.a.
Wiederverwendung durch Framework-Technik - Vom
Mythos zur Realität.
OBJEKT-Spektrum (1995) 5, S. .
[Booc97] Booch, G., u.a.:
Unified Modeling Language (UML) Notation Guide, Version
1.0.Rational Software Corporation, Santa Clara, 1997.
http://www.rational.com.
[Flec87]
Fleckenstein, J.:
Zustandsgraphen für SPS - grafikunterstützte Programmierung und steuerungsunabhängige Darstellung. ISW 63
Berlin, Heidelberg, New York, Tokyo: Springer Verlag,
1987.
[IEC91]
DIN-IEC 1131-3
Speicherprogrammierbare Steuerungen, Teil 3:
Programmiersprachen.
Berlin, Köln: Beuth- Verlag, 1991.
[IEC96]
IEC TC65/WG6
Function Blocks for Industrial-Process Measurement and
Control.
Working Draft for IEC 1499, 1996
[Oma94] N.N
Requirements of Open, Modular Architecture Controllers for
Applications in the Automotive Industrie.
Chrysler, Ford, General Motors, Version 1.1, Dec. 1994.
[Opc96]
N.N
Spezifikation des Kommunikationsstandards OPC (OLE for
Process Control.
http://www.industry.net/OPC.
46
[Rath95]
Rath, G.:
HIGRAPH - Grafischer Entwurf, Programmierung und Test
von SPS-Software.
In: Tagungsband "Software Engineering und CASE-Tools für
Steuerungen bei Fertigungseinrichtungen", Institut für
Steuerungstechnik, Universität Stuttgart, 1995.
[Reic95]
Reichenbächer, J.,
Lutz, R.:
Abteilungsübergreifendes Engineering von Steuerungsaufgaben.
In: Tagungsband "Software Engineering und CASE-Tools für
Steuerungen bei Fertigungseinrichtungen", Institut für
Steuerungstechnik, Universität Stuttgart, 1995.
7 Anhang A: Projektpartner in MoWiMa
Die Projektpartner (Bild 29) des Forschungsvorhabens Modellierung und Wiederverwendung
objektorientierter Maschinensoftware "MoWiMa" sind die Maschinenhersteller Behringer
GmbH Kirchardt, Reis GmbH & Co. Maschinenfabrik Obernburg, die Software-Häuser
Infoteam Software GmbH Bubenreuth und Industrielle Steuerungstechnik GmbH (ISG)
Stuttgart. Komplettiert wird der Verbund durch die Forschungs- und Ingenieurgesellschaft für
Steuerungstechnik GmbH (FISW) Stuttgart
Maschinenhersteller
Softwarehäuser
Forschungseinrichtung
Industrielle Steuerungstechnik GmbH
GmbH Stuttgart
Bild 29:
MoWiMa - Projektpartner
Behringer GmbH
47
Die Firma Behringer GmbH ist führender Hersteller hochautomatisierter Bandsägeanlagen.
Bedingt durch die Integration in den Fertigungsverbund beim Kunden, einer durch vielfältige
Maschinenvarianten gekennzeichneten SPS- und NC-Steuerungsfunktionalität sowie
steigenden Bedienkomfort wird das Vereinheitlichen und Wiederverwenden der
Steuerungssoftware immer wichtiger.
FISW GmbH
Die Forschungs- und Ingenieurgesellschaft für Steuerungstechnik GmbH arbeitet eng mit dem
Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen der
Universität Stuttgart zusammen. Aufgrund der in den letzten Jahren gemeinsam bearbeiteten
Projekte besitzt die FISW GmbH breit gefächerte Erfahrungen auf dem Gebiet der
Steuerungstechnik und der Softwareerstellung für Maschinensteuerungen.
Infoteam Software GmbH
Schwerpunkt der etwa 25 Mitarbeiter umfassenden Infoteam Software GmbH ist neben den
Bereichen Kommunikation und Betriebssysteme für technisch/wissenschaftliche Projekte die
Entwicklung
grafischer
Benutzungsoberflächen
von
Programmiersystemen
für
Speicherprogrammierbare Steuerungen (SPS) nach IEC 1131-3. Kunden dieses
Programmiersystem-Baukastens sind namhafte Steuerungshersteller. Das Unternehmen ist
Mitglied der Initiative "PLCopen", die neben der Vereinheitlichung der SPSSteuerungsprogramme deren Übertragbarkeit zwischen unterschiedlichen Geräteherstellern
betreibt.
ISG
Die Firma ISG entwickelt und lizensiert mit über 20 Mitarbeitern Softwarebausteine zum
Aufbau numerischer Steuerungen (NC). Der erfolgreiche Einsatz des Softwarebaukastens
beruht auf der intensiven Zusammenarbeit mehrerer international tätiger Maschinen- und
Steuerungshersteller. Basis des NC-Kerns ist die vollständig in 'C' geschriebene Software, die
nach einem einheitlichen, "offenen" Softwaremodell erstellt wird.
Reis GmbH & Co.
Die Erstellung hochwertiger Software als Teil eines Robotersystems spielt bei Reis GmbH &
Co. Maschinenfabrik als Hersteller von Industrierobotern seit jeher eine große Rolle. Der
Anteil der Software am Gesamtprodukt steigt stetig, eine Unterstützung der Softwareerstellung
erreicht deshalb in Zukunft zunehmende Bedeutung.
48
8 Anhang B: Glossar
Begriff
Synonym bzw. Erklärung
Benutzer
Benutzer des MoWiMa-Werkzeugs, i.d.R.
Maschinenhersteller.
Branchenneutrale Beschreibung von Maschinen und Anlagen.
Bereits im System hinterlegt. Beschreibung der durch die
MoWiMa-Methode definierten Zusammenhänge.
Benutzerorientiertes
Klassendiagramm
(Auftragsneutrale) Maschinen(typ)beschreibung. Grafische
Darstellung, welche Typen wie oft in einer
Maschinenkonfiguration vorhanden sein müssen bzw.
dürfen und welche Beziehungen (Relationen) zwischen ihnen
bestehen. Beziehungstypen: besteht_aus, benutzt,
Restriktionen und Vererbung.
Objektdiagramm
(Auftragsspezifische,) grafische Maschinenkonfiguration. Es
werden (konkrete) Funktionsobjekte instanziiert und deren
Relationen untereinander grafisch beschrieben.
Vorlage für die Erstellung einer Maschinenkonfiguration.
Wird aus dem benutzerorientierten Klassendiagramm
generiert und enthält Platzhalter, die durch Instanzen
konkreter Funktionsobjekte ersetzt werden.
Typ, Klasse
Formale und vollständige Beschreibung eines Objekts
innerhalb der Bibliothek.
Abstammen
Stammt ein Typ von einem anderen Typ ab, so stellt er eine
Unterklasse gemäß der Vererbungshierarchie dar.
Abstrakt
Nicht instanziierbar. Auf Klassen bzw. Typen bezogen.
Konkret
Instanziierbar. Auf Klassen bzw. Typen bezogen.
Systemklasse
Abstrakte Klasse oder Typ, durch das System bzw. durch
die Modellierungsmethode vorgegeben. Verwendung
ausschließlich im Systemklassendiagramm.
Systemtyp
Abstrakte Klasse
Abstrakter, benutzerorientierter
Vom Benutzer definierter, abstrakter Typ, der vorwiegend
zur Klassifizierung (Strukturierung der Bibliothek) dient, z. B.
49
Begriff
Typ
„Rollenbahn“. Kann jedoch auch selber Eigenschaften
definieren, die von den Unterklassen (die konkret oder
wiederum abstrakt sein können) geerbt werden.
abstrakter Benutzertyp
Konkrete Klasse
konkreter, benutzerorientierter
Typ
konkreter Benutzertyp
Vom Benutzer definierter konkreter Typ, der in einer
Maschinenkonfiguration instanziiert werden kann. Kann
von einem abstrakten Benutzertyp oder direkt von einem
Systemtyp abstammen. Beispiel: der konkrete Benutzeryp
„RB68-1/4“ stammt vom abstrakten Benutzertyp „Rollenbahn“ ab.
Objekt
Instanz eines Typs, bzw. einer Klasse. Objekte werden
unterteilt in Funktionsobjekte, Elektrische Betriebsmittel
etc.
Typeigenschaften,
Objekteigenschaften
Parameter sowie funktionales Verhalten eines Typs, bzw.
eines Objekts. Das funktionale Verhalten von
Funktionsobjekten wird z.B. durch einen Zustandsgraph
beschrieben und in einem Funktionsbaustein hinterlegt. Das
funktionale Verhalten von Elektrischen Betriebsmitteln wird
z.B. durch deren logische Anschlußpunkte beschrieben
Instanziieren
Kopieren und Entnehmen eines Funktionsobjekts aus der
Bibliothek und Einfügen in eine Maschinenkonfiguration. Es
wird ein (innerhalb der Maschinenkonfiguration) eindeutiger
Name (BMK) zugeordnet. Instanzspezifische Parameter
können definiert werden.
Funktionsobjekt
Objekt, welches je nach Aggregationsebene weiter als
Funktionsgruppe oder Funktionseinheit klassifiziert
werden kann. Das funktionale Verhalten von
Funktionsobjekten wird durch einen Zustandsgraph
beschrieben und in einem Funktionsbaustein nach IEC
1131-3 hinterlegt.
Funktionsgruppe „FG“
Aggregiertes (zusammengesetztes) Funktionsobjekt aus
Funktionseinheiten oder wiederum Funktionsgruppen.
Dient funktional der Koordinierung unterlagerter
Funktionseinheiten und Funktionsgruppen. Hat oftmals
50
Begriff
keine direkte physische Zuordnung (nur über die
Aggregation) jedoch eine funktionale Zuordnung (z.B. als
Ablaufgraph modelliert) in Form eines Funktionsbausteins.
Funktionseinheit „FE“
Funktionsobjekt der untersten Aggregationsebene, das
funktional nicht mehr weiter unterteilt wird. Spiegelt oftmals
die mechanischen Baueinheiten und ihre Funktionen wieder.
Baulich zugeordnet sind Sensoren und Aktoren. Funktional
zugeordnet ist ein Funktionsbaustein, der die Software und
deren Schnittstellen enthält sowie die zu den Sensoren und
Aktoren gehörigen Steuerungsein- und -ausgänge.
Elektrische Betriebsmittel
Objekt, welches einer Funktionsgruppe oder
Funktionseinheit zugeordnet ist. Das funktionale Verhalten
von Elektrischen Betriebsmitteln wird vor allem durch
deren logische Anschlußpunkte an die Steuerung
(Eingänge/Ausgänge) beschrieben.
SensorAktorElement
Elektrisches Betriebsmittel, das Signale an die Steuerung
liefert oder von der Steuerung bekommt.
BenutzerEinAusgabeElement
Elektrisches Betriebsmittel, das Signale an den
Maschinenbediener liefert (z.B. Anzeigelampe) oder vom
Maschinenbediener entgegennimmt (z.B. Taster).
Obligatorisches Objekt
Objekt, das in einer Maschinenkonfiguration enthalten sein
muß. Beschrieben durch die Kardinalität 1:1(1).
Optionales Objekt
Objekt, das in einer Maschinenkonfiguration enthalten sein
kann, aber nicht muß. Beschrieben durch die Kardinalität
1:0(1).
Eingänge/Ausgänge
Ein- und Ausgangssignale an der Steuerung. Logisch mit
Sensoren und Aktoren verbunden.
Vererbung
Aus einem vorhandenen (abstrakten) Typ werden weitere
Untertypen gebildet. Diese erben alle Eigenschaften und fügen
neue hinzu. Siehe auch Variante.
Variante
Durch Vererbung erzeugte und erweiterte Klasse bzw. Typ.
51
Begriff
Relation
Beziehung zwischen Funktionsobjekten. Relationstypen sind:
besteht_aus, benutzt, Restriktionen und Vererbung.
Kardinalität
Ist einer Beziehung zwischen zwei Klassen zugeordnet.
Bislang nur für besteht_aus-Beziehungen sinnvoll. Gibt an,
wie oft die Klasse der niedrigeren Aggregationsebene in einer
Maschinenkonfiguration vorhanden sein muß bzw. darf.
Aggregation
Inverse Sicht der baumförmigen besteht_aus-Struktur
zwischen den Objekten einer Maschine. Z.B.: Eine
Funktionsgruppe ist definiert durch die Aggregation zweier
Funktionseinheiten.
Komposition
Dekomposition
Zerlegungsstruktur einer Maschine. Baumförmige Struktur
gemäß den besteht_aus-Beziehungen zwischen den
enthaltenen Objekten. Gegenteil von Aggregation, z.B.
Dekomposition einer Funktionsgruppe in zwei
Funktionseinheiten.
besteht_aus-Beziehung
Beziehung zwischen Funktionsgruppen und
Funktionseinheiten bzw. -gruppen. Durch diesen
Beziehungstyp wird der baumförmige Aufbau der Maschine
aus baulich-funktionaler Sicht wiedergegeben. Eine
Sägeanlage beispielsweise besteht_aus einer Sägeeinheit,
einer Zuführeinheit, einer Positioniereinheit und einer
Abführeinheit.
Aggregation
benutzt-Beziehung
kommuniziert_mit-Beziehung
Rein funktionale Beziehung zwischen Funktionsobjekten, die
nicht durch eine besteht_aus-Beziehung verbunden sind.
Restriktionen
Spezifikation spezieller Konfigurierungsvorschriften innerhalb
des benutzerorientierten Klassendiagramms z. B. wenn →
dann: wenn Magazin, dann angetriebene Rollenbahn; wenn
→ dann nicht; alternativ: entweder-oder.
Zustandsdiagramm
Zustandsgraph
Grafische Beschreibung des funktionalen Verhaltens einer
Funktionseinheit oder Funktionsgruppe.
Funktionsbaustein
Instanziierbarer und damit wiederverwendbarer
52
Begriff
Softwarebaustein nach IEC 1131-3.
Übergangsbedingung
Logische Gleichung, die z.B. in AWL nach IEC 1131-3
formuliert und einer Transition zugeordnet ist.
Auftragselement
Grafische Darstellung eines Ereignisses (Input- bzw. OutputEvent) innerhalb der Zustandsgraphenmethode.
Quittungselement
Pre-Step
Zustandsanweisung für die Aktionsausführung beim Einsprung
in den Zustand.
Step
Zustandsanweisung für die zyklische Bearbeitung innerhalb
eines aktiven Zustands.
Post-Step
Zustandsanweisung für die Aktionsausführung beim Verlassen
des Zustands.
Schnittstelle eines Funktionsbausteins (Input- und OutputEvents).
Schnittstelle eines Funktionsbausteins (Input- und OutputVariablen).
53

mowima

Transcription

Similar documents

Englisch-Deutsch - University of Bath

www.interluebke.com

Ikkuna 3#07.indd - Deutsch-Finnische

Hot Stamping Machine Duosprint/Sprint

FUTUR-Prospekt (PDF-Datei, ca. 4 MB).

Produktinfos - Karl Gröner GmbH

IT-Sicherheit in der Industrie 4.0

Pneumatik Elektropneumatik Grundlagen

3DLABS WILDCAT REALIZM BEDIENUNGSANLEITUNG

GK-Planungssoftware und IMSI/Design kündigen TurboCAD 21 an

Strassstein-Dekorationssoftware