Entwicklung und Evaluierung einer domänenspezifischen Sprache f ür SPS-SchrittkettenBastianCramerbcramer@uni-paderborn.deDepartment of Computer ScienceUwe Kastens University of PaderbornFürstenallee 1133102PaderbornGermanyDennisKlassendennis.klassen@uni-paderborn.deDepartment of Computer ScienceUwe Kastens University of PaderbornFürstenallee 1133102PaderbornGermanyEntwicklung und Evaluierung einer domänenspezifischen Sprache f ür SPS-Schrittketten9134AEF3704C2E58B4CD31FE050D8720GROBID - A machine learning software for extracting information from scholarly documents
Domänenspezifische Sprachen mit passenden Entwurfs-und Transformationswerkzeugen unterstützen Anwender in speziellen Gebieten ihre Entwürfe in Implementierungen umzusetzen. Sind solche Sprachen visuell, so können auch graphische Notationen aus dem Anwendungsgebiet übernommen werden, um die Akzeptanz der Sprache zu verbessern. In diesem Artikel berichten wir über den Entwurf, die Implementierung und Evaluation einer visuellen Sprache, die im industriellen Umfeld zur Steuerung von Robotern einer Produktionsstrecke eingesetzt wird. Der Einsatz eines Werkzeugsystems zur Sprachimplementierung (DEViL [Sch06a]) ermöglichte, dass mit akzeptablem Aufwand Prototypen generiert und Sprachvarianten erprobt wurden. 1 Einleitung Domänenspezifische Sprachen eignen sich sehr gut, um Entwürfe in speziellen Anwendungsgebieten treffend zu formulieren und mit passenden Werkzeugen in Programme oder andere formale Strukturen zu transformieren. Visuelle Sprachen sind für solche Zwecke besonders nützlich, da Strukturen und Zusammenhänge sehr anschaulich dargestellt werden können. Außerdem können sie gut an etablierte Notationen des Anwendungsgebietes angepasst werden und verkleinern dann die Distanz zwischen den Vorstellungen des Anwenders und den Sprachelementen. In diesem Artikel berichten wir über eine visuelle Sprache, die wir für die Firma Robert Bosch GmbH entwickelt haben, um damit die Steuerung von Robotern zu formulieren, die Elektromotoren montieren. Mit Entwürfen in dieser Sprache sollen Entwickler, die eine Motoren-Produktionsstrecke konzipieren, ihre Vorstellungen zum Ablauf der Montage an Programmierer vermitteln, welche die Steuerung der Roboter implementieren. Die Randbedingungen für die Entwicklung der Sprache werden in Abschnitt 2 dargestellt. Die von uns entwickelte Sprache soll eine informelle Notation ablösen, die bisher für diesen Zweck eingesetzt wurde. Damit soll erreicht werden, dass Entwürfe treffender beschrieben und Entwicklungszyklen abgekürzt werden. Der Entwurf der Sprache musste Konzepte der bisher verwendeten Notation gut aufnehmen und Erweiterungen und Präzisierungen sensibel einfügen, damit die Sprache von beiden Entwicklergruppen akzeptiert wurde. Im Abschnitt 3 stellen wir Sprachkonstrukte exemplarisch vor und berichten über die Evaluation der Sprache als akzeptanzsteigernde Maßnahme.
Um mit einer domänenspezifischen Sprache praktischen Nutzen zu erzielen, werden sprachspezifische Werkzeuge benötigt. Wir haben für diese Sprache u.a. einen visuellen Struktureditor, Übersetzer für SPS nach XML und einen Codegenerator für SPS implementiert und in den Entwicklungsprozess für die Produktionsstrecken eingebettet. Abschnitt 4 vermittelt einen Eindruck dieser Aufgaben jenseits der Sprachentwicklung im engeren Sinne.
Neben den grundsätzlichen Aufgaben zur Implementierung von Sprachen erfordert eine visuelle Sprache in erheblichem Maße zusätzliches technisches und konzeptionelles Wissen sowie weiteren Entwicklungsaufwand. Wenn man trotzdem noch Entwurfsvarianten erproben will, um die Akzeptanz zu verbessern, ist der Aufwand für eine manuelle Implementierung nicht akzeptabel. Wir haben für die Realisierung dieser Sprache das von uns entwickelte Werkzeugsystem DEViL [Sch06a] eingesetzt. Es generiert vollständige Sprachimplementierungen mit visuellen Struktureditoren als Frontend aus Spezifikationen hohen Abstraktionsniveaus [Sch06b]. Im Abschnitt 5 vermitteln wir einen Eindruck von dem Einsatz und der Wirksamkeit des Systems.
Einige Hinweise auf verwandte Arbeiten und eine Zusammenfassung beschließen den Artikel.
Vorstellung der Domäne
Die Firma Robert Bosch GmbH produziert an ihrem Standort in Bühl kleine Elektromotoren in großen Stückzahlen für vielfältige Einsätze in Kraftfahrzeugen. Auf langen Produktionsstrecken mit vielen einzelnen Stationen bauen Roboter die Motoren schrittweise zusammen und prüfen sie. Für jeden neuen Motortyp muss die Produktionsstrecke neu eingerichtet werden. Dazu wird für jede Station der Aufbau des Roboters, die Zuführung des Materials und die Weiterleitung der Produkte entworfen. Darauf abgestimmt werden die Arbeitsschritte des Roboters geplant und in speicherprogrammierbaren Steuerungen (SPS [Aue89]) programmiert.
Bei der Entwicklung der motorspezifischen Produktionsstrecke kooperieren zwei Gruppen von Entwicklern mit unterschiedlichen Aufgaben: Die hier "
Projektleiter" genannte Gruppe entwirft den mechanischen Aufbau jeder Station und den Einsatz der Roboter, Greifarme, Schub-und Dreheinrichtungen, Taster und Sensoren. Die zweite Gruppe, hier als "
Programmierer" bezeichnet, entwickelt Programme zur Steuerung der Komponenten mit speicherprogrammierbaren Steuerungen. Die beiden Entwicklergruppen kommunizieren über den geplanten Ablauf der Produktionsschritte der Stationen. In mehreren Iterationen werden die Pläne verfeinert, in Programme umgesetzt, an den Geräten getestet und verbessert. Die Pläne der Abläufe, sogenannte " Schrittketten" werden in einer speziellen Notation beschrieben, zwischen den Entwicklergruppen ausgetauscht, fortgeschrieben und dokumentiert. Die Notation enthält graphische Elemente zur Skizzierung von Ablaufschritten und textuelle Annotationen für technische Angaben. Abbildung 2 und 3 zeigen Beispiele dazu.
Der Entwicklungsprozess einer
Sprachentwurf
Wie aus dem vorhergehenden Abschnitt hervorgeht, wird eine domänenspezifische Sprache benötigt, welche den Aufgaben angemessen ist. In diesem Abschnitt wird die Vorgehensweise für einen solchen Sprachentwurf vorgestellt. Die SPS-Programmiersprachen spielen dabei eine wesentliche Rolle, da die DSL Programme für SPS beschreiben soll. Dafür wird zu Beginn eine Übersicht über die SPS-Sprachen gegeben. Anschließend wird der Sprachentwurf und die dazu verwendeten Elemente aus der vorhandenen Notation beschrieben. Im Anschluss daran werden die Evaluierung und die daraus resultierende DSL beschrieben.
SPS-Konzepte als Grundlage der DSL
Die DSL soll speziell für die Entwicklung der Schrittketten eingesetzt werden, wofür nur bestimmte Teile der SPS-Sprachen verwendet werden. Der Standard IEC 61131 [Inf03] vereinigt fünf Sprachen für SPS. Die Ablaufsprache (AS) dient der Gliederung und Orga- Bereits an dieser Stelle sind Gemeinsamkeiten und Gegensätze zwischen vorhandenen Werkzeugen und den Wünschen der Entwickler erkennbar. Z.B. sollte der Fluss der Schrittketten von links nach rechts beibehalten werden, entsprechend der bereits vorhandenen Notation in den Schrittkettenablaufzetteln (Abbildung 3, 4). Geändert werden sollte die Beschreibung der Transitionen und Bedingungen: Auf den Schrittkettenablaufzetteln (Abbildung 3) werden Bedingungen modelliert, unter welchen der dazugehörige Schritt geschaltet wird; in der neuen Sprache (Abbildung 4) werden Transitionen modelliert, die zum Verlassen des Schrittes führen. • Die Programmierer sind im Umgang mit SPS erfahrener, das sie bereits SPS-Software entwickelt und mit grafischen Editoren gearbeitet haben.
Als erstes werden die zu modellierenden
• Die Projektleiter programmieren nicht selbst. Ihr Bezug zu der SPS entsteht über den mechanischen Ablauf der Maschinen und die Schrittketten-Ablaufzettel.
Aus den Methoden, die für solche Evaluierungen einschlägig sind [SCK07], haben wir in diesem Projekt folgende eingesetzt:
Interview
Abbildung 1: Entwicklungsprozess vor der Einführung der DSL In der Abbildung 2 sind drei Schritte genauer dargestellt. Als Beispiel betrachten wir den Schritt N16, in dem die Aktion " Parkpos.anfahren" durchgeführt wird. Das grau unterlegte Kästchen stellt den Schritt dar. Darüber sind zwei vertikale Linien angeordnet, diese repräsentieren eine ODER-Verknüpfung zwischen drei Konditionen, unter denen dieser Schritt geschaltet wird. Die untereinander aufgelisteten Variablennamen sind UNDverknüpft. Unter dem Schritt können mehrere Aktionen aufgeführt sein, die in dem Schritt durchzuführen sind, bevor die Konditionen für den nächsten Schritt geprüft werden. Eine Schrittkette kann über hundert Schritte besitzen und erstreckt sich dann über mehrere Seiten. Die Schrittketten-Ablaufzettel sind während des gesamten Entwicklungsprozesses im Umlauf (Abbildung 1, Punkt 7,9). Alle Änderungen an dem Ablauf oder den Maschinen fordern stets den Einsatz des Schrittketten-Ablaufzettels. Häufig sind die Änderungen nur gering, wie z.B. das Entfallen einiger Schritte, die Änderung der Schrittreihenfolge oder eine einfache Namensänderung der Schritte. Die Abbildung 3 zeigt einen Auszug aus einem laufenden Projekt mit durchgeführten Korrekturen.Abbildung 2: Schritte, dargestellt mit dem Schrittketten-DokumentationssystemAbbildung 3 :Abbildung 3: Schrittketten-Ablaufzettel mit ÄnderungenAbbildung 5: Schritte/Aktionen/TransitionenDasZiel dieser Arbeit war die Modernisierung und Verbesserung des Entwicklungsprozesses von SPS-Schrittketten in industrieller Umgebung. Dazu wurde eine visuelle domänenspezifische Sprache mit dem Werkzeugsystem DEViL für zwei, miteinander kommunizierende, Entwicklergruppen entwickelt und speziell an deren Aufgaben angepasst. Für den zu entwickelnden Struktureditor wurden anhand eines strukturierten Entwicklungsprozesses erst die Situation bei Bosch analysiert, sowie die Aufgaben der Benutzer und das Umfeld der Aufgaben untersucht. Die Benutzungsschnittstelle und die DSL wurden für genau die durchgeführten Aufgaben ausgelegt. Durch die verwendeten Werkzeuge bestand der Hauptteil dieser Arbeit aus der Evaluierung der visuellen Sprache und der Benutzungsschnittstelle. Durch wiederholte kontrollierte Experimente, Interviews und Gruppenbesprechungen mit den Benutzern wurde eine für beide Entwicklergruppen geeignete visuelle DSL sowie eine übersichtliche und aufgabenkonforme Benutzungsschnittstelle entworfen. Der dabei entwickelte Schrittkettenkonfigurator entspricht den Vorstellungen der Benutzer. Durch die Einführung des Schrittkettenkonfigurators wird der Entwicklungsprozess der Schrittketten beschleunigt und vereinfacht. Durch den in dieser Arbeit entwickelten Schrittkettenkonfigurator wird dem Werkzeugsystem DEViL und dem Vorantreiben dieser Arbeit bei Bosch sehr großes Interesse entgegen gebracht. Obwohl der Schrittkettenkonfigurator alle zu Beginn dieser Arbeit gestellten Anforderungen erfüllt, wurde erst während der Entwicklung die Ausbaufähigkeit des Systems deutlich. So wurden nachträglich zum konformen Ausdrucken der Schrittketten aus dem Schrittkettenkonfigurator zusätzliche Module in DEViL eingebaut und stehen somit auch
Bereits eine Skizze auf Papier (Abbildung 4) verkörpert den ersten Prototyp und die ersten Schritte der Evaluierung. Das "Rapid Prototyping" wurde durch den Einsatz des Generators DEViL ermöglicht. Da sich sowohl einzelne Teile der Benutzungsschnittstelle als auch Sprachelemente separiert evaluieren lassen, kann dadurch den Benutzern eine Vielzahl von Alternativen angeboten werden. Ein vielfältiges Angebot ist notwendig, da die Benutzer nicht den Überblick über die verschiedenen Modellierungstechniken besitzen. Das bedeutet, die Benutzer können nicht direkt mitteilen, welche Modellierungsmethode sie bevorzugen, sondern können aus den präsentierten Methoden eine Auswahl treffen und diese bewerten. Die Auswahl der Benutzer für die Evaluierung beschränkt sich auf die Mitarbeiter in der TEF-Abteilung bei Bosch in Bühl. Es ist wichtig, dass beide Entwicklergruppen, Programmierer und Projektleiter, bei der Evaluation vertreten sind. Denn sie haben unterschiedlich tiefe Kenntnisse von SPS-Konstrukten, welche die DSL stark prägen.
3.2 Evaluierung der DSLIn diesem Projekt haben wir der Evaluierung besondere Beachtung geschenkt. Dazu wur-den verschiedene Methoden und Vorgehensweisen angewendet, mit denen unterschiedli-che Effekte evaluiert wurden, z.B. Kommunikation zwischen den Benutzern, Verständlich-keit der Modellierungssprache usw.. Die dabei erzielten Ergebnisse sind z.T. benutzer-
Elemente der SPS-Sprachen ermittelt. Dafür wird das Expertenwissen aus dem Umfeld benötigt, unterstützend dazu werden die vorhandenen Projektdokumente untersucht. Sobald der Satz der zu modellierenden Elemente feststeht, kann dieser in einer abstrakten Struktur für DEViL[Sch06a] implementiert werden. Aus dieser abstrakten Struktur ist DEViL bereits in der Lage einen Struktureditor mit einer simplen Baumdarstellung zu generieren. Bereits hier sind mit den generierten Struktureditoren Evaluierungstests möglich. Dabei kann untersucht werden, ob sich bereits vorhandene Projekte mit den Strukturbäumen ausdrücken lassen. Nachdem die abstrakte Struktur feststeht, kann mit der Modellierung der visuellen Komponenten der DSL begonnen werden. Abbildung 4: Erste Skizze des Schrittkettenkonfigurators abhängig und müssen richtig interpretiert werden. Außerdem sollte beachtet werden, dass sich die Wünsche und Meinungen der Entwickler im Verlauf der Evaluierung ändern, so ist z.B. in der Abbildung 4 zu sehen, dass die Benutzer alle Elemente zum Konfigurieren einer Schrittkette in einer einzigen Sicht dargestellt wünschen. Dieser Wunsch hat sich im Verlauf der Evaluierung geändert, da realistische SPS-Projekte in einer Sicht umfangreich und zu unübersichtlich werden. Neben dem Expertenwissen und Kenntnissen über die Domäne muss für die Evaluierung der DSL der Kenntnisstand der Benutzer ermittelt werden. Für diesen Zweck sind Interviews und Beobachtungen vor Ort notwendig. Die Ergebnisse können für die Dialogmodellierung verwendet werden, die beschreibt, wie sich das System zu verhalten hat und welchen Arbeitsfluss die Benutzer beim Erledigen ihrer Aufgaben haben. Außerdem kann mit Hilfe der Interviews herausgearbeitet werden, wie die Benutzungsschnittstelle auszusehen hat. Der Aufbau einer Grundakzeptanz ist für die weitere Entwicklung enorm wichtig. Erst wenn diese erreicht wurde, kann mit der Evaluierung der DSL fortgefahren werden. Die Evaluierung wurde parallel zum Prototyping und der Implementierung durchgeführt.
Wie schon aus dem SPS-Standard hervorgeht, gibt es visuelle Notationen für SPS und umfangreiche Entwicklungsumgebungen für SPS-Software, wie z.B. IndraWorks[Ind]. Diese Programmierumgebung bietet leider keine Möglichkeit die Darstellungen der Sprachen zu verändern. Da diese Umgebung für professionelle Softwareentwickler ausgerichtet ist, ist sie für unerfahrene Benutzer nicht gut geignet. Durch einfachere und besser angepasste Notationen können auch die unerfahrenen Benutzergruppen erreicht werden. Con02] und das in diesem Projekt verwendete DEViL, so wie Eclipse basierende Plattformen wie oAW oder GMF [BSM + 03]. Das System GenGed z.B. basiert auf einer als Graph modellierten abstrakten Struktur. In DEViL dagegen werden Sprachkonstrukte durch attributierte Grammatiken spezifiziert und als attributierte Bäume mit Querreferenzen repräsentiert, was eine entscheidende Rolle bei der Strukturmodellierung und den Sicht-Definitionen spielt. Einen ähnlichen Ansatz der Modellierung findet man beim MetaEdit+. Dieses System hat leider eine eingeschränkte Flexibilität bezüglich grafischer Repräsentationen. DEViL bietet dagegen spezialisiertere und stärker parametrisierbare grafische Fähigkeiten. So gibt es z.B. Spezialmuster für Bäume VPExplorerTree bzw. VPTree [Sch06b] mit Anbindung an das Graphlayout Werkzeug Dot und diverse Listenmuster. Außerdem sind Funktionen eingebettet um z.B. die Überlappungsfreiheit zu kontrollieren. Die Spezifikationen des Modells mit EMF ist grob mit DEViL vergleichbar. GMF z.B. unterscheidet analog zu DEViL zwischen der semantischen und der editierbaren Struktur, DEViL bietet jedoch weitere Spezialsprachen um die Spezifikation noch weiter zu vereinfachen Die Entwicklung einer visuellen Sprache [SK03] wurde bereits mit dem VL-Eli [KS02] System, dem Vorgänger von DEViL, in anderen Projekten erfolgreich durchgeführt. So wurde in Zusammenarbeit mit Sagem Orga SIMtelligence Designer/J [SPKF02], eine visuelle Sprache zur Anwendungsentwicklung für SIM-Karten, entwickelt.
MetaEdit+ [Werkzeugsysteme zur Entwicklung visueller Struktureditoren sind z.B. GenGed [Bar98],
allen weiteren mit DEViL generierten Editoren zur Verfügung. Über die systematische Evaluierung des DEViL-Systems und mit ihm erzeugter Sprachimplementierungen wird inDas gesamte Konzept hat bei Bosch großen Zuspruch gefundenB. für Analysen und diverse Simulationszwecke erweitertAAuerSPS -Aufbau und Programmierung 2Huethig1989ïberarb. AuflGenGed: A Generic Graphical Editor for Visual Languages based on Algebraic Graph GrammarsRoswithaBardohlIEEE Symp. on Visual Lang1998. September 1998Eclipse Modeling FrameworkFrankBudinskyDavidSteinbergEdMerksRayEllersick UndTimothyGroseBSM + 03Addison Wesleyaug 2003MetaEdit+ User's Guide2002MetaCase ConsultingRexrothIndraworks Von-3 Speicherprogrammierbare Steuerungen Teil 3IEC 61131Programmiersprachen Deutsche Fassung EN611312003. 2003Deutsche Kommission Elektrotechnik Elektronik InformatikVL-Eli: A Generator for Visual LanguagesUweKastensCarstenSchmidtProceedings of Second Workshop on Language Descriptions, Tools and Applications (LDTA'02)Electronic Notes in Theoretical Computer ScienceSecond Workshop on Language Descriptions, Tools and Applications (LDTA'02)Grenoble, FranceElsevier Science Publishers2027. 200265DEViL HomepageCarstenSchmidt2006Generierung von Struktureditoren für anspruchsvolle visuelle SprachenCarstenSchmidt2006DissertationUsability Evaluation of a System for Implementation of Visual LanguagesCarstenSchmidtBastianCramer UndUweKastensSymposium on Visual Languages and Human-Centric ComputingIEEE Computer Society PressSeptember 2007Implementation of visual languages using patternbased specificationsCarstenSchmidtUweKastensSoftware -Practice and Experience33Dezember 2003SIMtelligence Designer/J: A Visual Language to Specify SIM Toolkit ApplicationsCarstenSchmidtPeterPfahlerUweKastensCarstenFischerProceedings of Second Workshop on Domain Specific Visual Languages (OOPSLA 2002)Second Workshop on Domain Specific Visual Languages (OOPSLA 2002)Seattle, WA, USA2002. 2002