Doma¨nenspezifische Sprachen mit passenden Entwurfs- und Transformationswerkzeugen unterstu¨tzen Anwender in speziellen Gebieten ihre Entwu¨rfe in Implementierungen umzusetzen. Sind solche Sprachen visuell, so ko¨nnen auch graphische Notationen aus dem Anwendungsgebiet u¨bernommen werden, um die Akzeptanz der Sprache zu verbessern. In diesem Artikel berichten wir u¨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]) ermo¨glichte, dass mit akzeptablem Aufwand Prototypen generiert und Sprachvarianten erprobt wurden.
Um mit einer doma¨nenspezifischen Sprache praktischen Nutzen zu erzielen, werden sprachspezifische Werkzeuge beno¨tigt. Wir haben fu¨r diese Sprache u.a. einen visuellen Struktureditor, U¨ bersetzer fu¨r SPS nach XML und einen Codegenerator fu¨r SPS implementiert und in den Entwicklungsprozess fu¨r die Produktionsstrecken eingebettet. Abschnitt 4 vermittelt einen Eindruck dieser Aufgaben jenseits der Sprachentwicklung im engeren Sinne. Neben den grundsa¨tzlichen Aufgaben zur Implementierung von Sprachen erfordert eine visuelle Sprache in erheblichem Maße zusa¨tzliches technisches und konzeptionelles Wissen sowie weiteren Entwicklungsaufwand. Wenn man trotzdem noch Entwurfsvarianten erproben will, um die Akzeptanz zu verbessern, ist der Aufwand fu¨r eine manuelle Implementierung nicht akzeptabel. Wir haben fu¨r die Realisierung dieser Sprache das von uns entwickelte Werkzeugsystem DEViL [Sch06a] eingesetzt. Es generiert vollsta¨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. 2
Die Firma Robert Bosch GmbH produziert an ihrem Standort in Bu¨hl kleine Elektromotoren in großen Stu¨ckzahlen fu¨r vielfa¨ltige Einsa¨tze in Kraftfahrzeugen. Auf langen Produktionsstrecken mit vielen einzelnen Stationen bauen Roboter die Motoren schrittweise zusammen und pru¨fen sie. Fu¨r jeden neuen Motortyp muss die Produktionsstrecke neu eingerichtet werden. Dazu wird fu¨r jede Station der Aufbau des Roboters, die Zufu¨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 u¨ber den geplanten Ablauf der Produktionsschritte der Stationen. In mehreren Iterationen werden die Pla¨ne verfeinert, in Programme umgesetzt, an den Gera¨ten getestet und verbessert. Die Pla¨ne der Abla¨ufe, sogenannte ”Schrittketten“ werden in einer speziellen Notation beschrieben, zwischen den Entwicklergruppen ausgetauscht, fortgeschrieben und dokumentiert. Die Notation entha¨lt graphische Elemente zur Skizzierung von Ablaufschritten und textuelle Annotationen fu¨r technische Angaben. Abbildung 2 und 3 zeigen Beispiele dazu.
Der Entwicklungsprozess einer Produktionsstrecke wird durch die Projektleiter mit der Entwicklung der mechanischen Konstruktion begonnen (Abbildung 1, Position 1). Aus den dabei entstehenden Dokumenten wird mit einem Generator ein Grundprojekt erstellt (Abbildung 1, Position 2). Dabei wird fu¨r jedes aktive Element der Produktionsstrecke eine sogenannte Schrittkette festgelegt, die den Ablauf des Elements beschreiben soll. Die Programmierer extrahieren die einzelnen Schrittketten (Abbildung 1, Position 3). Mit dem Schrittketten-Dokumentationssystem, das in der Abteilung verwendet wird, k o¨nnen die vorhandenen Schrittketten in festgelegter Form als Schrittketten-Ablaufzettel ausgedruckt werden (Abbildung 1, Position 4). Abbildung 3 stellt beispielhaft Bearbeitungszusta¨nde eines Ablaufzettels dar und soll einen Eindruck u¨ber die bei Bosch verwendeten Dokumente zur Beschreibung der Schrittketten verschaffen. Eine genauere Ansicht fu¨r die Schritte und Konditionen ist in der Abbildung 2 zu finden. Diese Vorlagen werden durch Projekleiter, gema¨ß den geplanten Bewegungsabla¨ufe, ha¨ndisch bearbeitet (Abbildung 3) und an die Programmierer u¨bergeben (Abbildung 1, Position 5). Programmierer setzen die Modelle in SPS-Code um und k o¨nnen daraus SPS-Programme erzeugen oder aktuelle Ablaufzettel zur Kontrolle erneut ausdrucken, bis der gewu¨nschte Ablauf der Maschine erreicht wurde und das SPS-Program vollst a¨ndig ist.
Abbildung 1: Entwicklungsprozess vor der Einfu¨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“ durchgefu¨hrt wird. Das grau unterlegte Ka¨stchen stellt den Schritt dar. Daru¨ber sind zwei vertikale Linien angeordnet, diese repra¨sentieren eine ODER-Verkn u¨pfung zwischen drei Konditionen, unter denen dieser Schritt geschaltet wird. Die untereinander aufgelisteten Variablennamen sind UNDverknu¨pft. Unter dem Schritt ko¨nnen mehrere Aktionen aufgefu¨hrt sein, die in dem Schritt durchzufu¨hren sind, bevor die Konditionen fu¨r den na¨chsten Schritt gepru¨ft werden. Eine Schrittkette kann u¨ber hundert Schritte besitzen und erstreckt sich dann u¨ber mehrere Seiten.
Die Schrittketten-Ablaufzettel sind w a¨hrend des gesamten Entwicklungsprozesses im Umlauf (Abbildung 1, Punkt 7,9). Alle A¨ nderungen an dem Ablauf oder den Maschinen fordern stets den Einsatz des Schrittketten-Ablaufzettels. H a¨ufig sind die A¨ nderungen nur gering, wie z.B. das Entfallen einiger Schritte, die A¨ nderung der Schrittreihenfolge oder eine einfache Namensa¨nderung der Schritte. Die Abbildung 3 zeigt einen Auszug aus einem laufenden Projekt mit durchgefu¨hrten Korrekturen.
Abbildung 2: Schritte, dargestellt mit dem Schrittketten-Dokumentationssystem Die gro¨ßten Engpa¨sse sind die Kommunikation zwischen den Entwicklergruppen und die dabei entstehenden Dokumente. Die Beschreibungsmo¨glichkeiten sind in dieser Notation sehr begrenzt und passen nicht mehr zum aktuellen SPS-Standard. Das f u¨hrt immer wieder zu ungenauen oder missversta¨ndlichen Beschreibungen und erfordert zusa¨tzliche Iterationen (Abbildung 1, Punkt 4-9), bis das erstellte SPS-Programm dem gew u¨nschten Bewegungsablauf entspricht.
Diese Situation sollte im Rahmen des hier beschriebenen Projektes durch eine doma¨nenspezifische Sprache verbessert werden. 3
Wie aus dem vorhergehenden Abschnitt hervorgeht, wird eine doma¨nenspezifische Sprache beno¨tigt, welche den Aufgaben angemessen ist. In diesem Abschnitt wird die Vorgehensweise fu¨r einen solchen Sprachentwurf vorgestellt. Die SPS-Programmiersprachen spielen dabei eine wesentliche Rolle, da die DSL Programme fu¨r SPS beschreiben soll. Dafu¨r wird zu Beginn eine U¨bersicht u¨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. 3.1
Die DSL soll speziell fu¨r die Entwicklung der Schrittketten eingesetzt werden, wofu¨r nur bestimmte Teile der SPS-Sprachen verwendet werden. Der Standard IEC 61131 [Inf03] vereinigt fu¨nf Sprachen fu¨r SPS. Die Ablaufsprache (AS) dient der Gliederung und Orga
Abbildung 3: Schrittketten-Ablaufzettel mit A¨nderungen nisation einer Schrittkette und bildet einen gerichteten Graph aus einer Menge von Schritten und Transitionen (Abbildung 2). Die Schrittaktionen und die Transitionsbedingungen ko¨nnen in den weiteren SPS-Sprachen beschrieben werden. Zu ihnen geh o¨ren zwei textuelle Sprachen (Tabelle 1), Anweisungsliste (AWL), Strukturierter Text (ST), und zwei Sprachen mit visuellen Elementen (Tabelle 1), Kontaktplan (KOP), Funktionsbaustein (FBS).
Die AWL fasst mehrere Anweisungen zusammen. Operanden ko¨nnen Werte zugeordnet werden, z.B. bei der Deklaration von Variablen. Die ST besteht aus Ausdru¨cken, die einen Wert liefern. Dazu geho¨ren z.B. mathematische Ausdru¨cke oder boolesche Funktionen. Außerdem ist das Beschreiben verschiedener Konstrukte wie Auswahl- oder Wiederholungsanweisungen mo¨glich.
Mit den Sprachen KOP und FBS wird ein Netzwerk in Form von Linien und Blo¨cken dargestellt. Diese Notation ist den fru¨her benutzten Schaltpla¨nen aus der Elektrotechnik nachempfunden und beschreibt Stromfluss-Pl a¨ne.
FBS stellt eine Menge von Funktionsbausteinen dar. Durch Verknu¨pfung mehrerer Funktionsbausteine miteinander ko¨nnen komplexe Funktionen realisiert werden. Dazu geho¨ren diverse mathematische Funktionen oder vollsta¨ndige Motorsteuerungen. Einen Eindruck der Sprachen vermittelt Tabelle 1. In allen vier Beispielen wird eine UNDFunktion mit Einga¨ngen % X2,5 und % X2,3 und dem Ausgang TRANS78 dargestellt. FBS
AWL KOP
Tabelle 1: SPS-Sprachen f u¨r verschiedene Zwecke: ST, AWL, FBS und KOP Mit dem Expertenwissen u¨ber SPS kann mit der Entwicklung der doma¨nenspezifischen Sprache begonnen werden. Dazu wird ermittelt, was genau die neue DSL beschreiben soll. Im Vorfeld dieser Arbeit ist eine Skizze (Abbildung 4) entstanden, welche die grundlegenden Strukturen zeigt und die Darstellungswu¨nsche der Benutzer aufgenommen hat. Daraus ist ersichtlich, dass die neue Sprache alle Sprachelemente einer Schrittkette in einer grafischen U¨bersicht darstellen sollte. Ein weiterer Anhaltspunkt fu¨r die visuelle Sprache sind die Schrittketten-Ablaufzettel (Abbildung 3).
Bereits an dieser Stelle sind Gemeinsamkeiten und Gegensa¨tze zwischen vorhandenen Werkzeugen und den Wu¨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). Gea¨ndert werden sollte die Beschreibung der Transitionen und Bedingungen: Auf den Schrittkettenablaufzetteln (Abbildung 3) werden Bedingungen modelliert, unter welchen der dazugeho¨rige Schritt geschaltet wird; in der neuen Sprache (Abbildung 4) werden Transitionen modelliert, die zum Verlassen des Schrittes fu¨hren.
Als erstes werden die zu modellierenden Elemente der SPS-Sprachen ermittelt. Daf u¨r wird das Expertenwissen aus dem Umfeld beno¨tigt, unterstu¨tzend dazu werden die vorhandenen Projektdokumente untersucht. Sobald der Satz der zu modellierenden Elemente feststeht, kann dieser in einer abstrakten Struktur fu¨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 mo¨glich. Dabei kann untersucht werden, ob sich bereits vorhandene Projekte mit den Strukturba¨umen ausdru¨cken lassen. Nachdem die abstrakte Struktur feststeht, kann mit der Modellierung der visuellen Komponenten der DSL begonnen werden. 3.2
In diesem Projekt haben wir der Evaluierung besondere Beachtung geschenkt. Dazu wurden verschiedene Methoden und Vorgehensweisen angewendet, mit denen unterschiedliche Effekte evaluiert wurden, z.B. Kommunikation zwischen den Benutzern, Versta¨ndlichkeit der Modellierungssprache usw.. Die dabei erzielten Ergebnisse sind z.T. benutzer
Abbildung 4: Erste Skizze des Schrittkettenkonfigurators abha¨ngig und mu¨ssen richtig interpretiert werden. Außerdem sollte beachtet werden, dass sich die Wu¨nsche und Meinungen der Entwickler im Verlauf der Evaluierung a¨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 wu¨nschen. Dieser Wunsch hat sich im Verlauf der Evaluierung gea¨ndert, da realistische SPS-Projekte in einer Sicht umfangreich und zu unu¨bersichtlich werden.
Neben dem Expertenwissen und Kenntnissen u¨ber die Doma¨ne muss fu¨r die Evaluierung der DSL der Kenntnisstand der Benutzer ermittelt werden. Fu¨r diesen Zweck sind Interviews und Beobachtungen vor Ort notwendig. Die Ergebnisse ko¨nnen fu¨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 fu¨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 durchgefu¨hrt. Bereits eine Skizze auf Papier (Abbildung 4) verko¨rpert den ersten Prototyp und die ersten Schritte der Evaluierung. Das “Rapid Prototyping” wurde durch den Einsatz des Generators DEViL ermo¨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 vielfa¨ltiges Angebot ist notwendig, da die Benutzer nicht den U¨ berblick u¨ber die verschiedenen Modellierungstechniken besitzen. Das bedeutet, die Benutzer ko¨nnen nicht direkt mitteilen, welche Modellierungsmethode sie bevorzugen, sondern ko¨nnen aus den pra¨sentierten Methoden eine Auswahl treffen und diese bewerten.
Die Auswahl der Benutzer fu¨r die Evaluierung beschra¨nkt sich auf die Mitarbeiter in der TEF-Abteilung bei Bosch in B u¨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 a¨gen.
• Die Programmierer sind im Umgang mit SPS erfahrener, das sie bereits SPS-Software entwickelt und mit grafischen Editoren gearbeitet haben. • Die Projektleiter programmieren nicht selbst. Ihr Bezug zu der SPS entsteht u¨ber den mechanischen Ablauf der Maschinen und die Schrittketten-Ablaufzettel. Aus den Methoden, die fu¨r solche Evaluierungen einschla¨gig sind [SCK07], haben wir in diesem Projekt folgende eingesetzt: Interview In einem Interview werden Benutzer aus verschiedenen Entwicklergruppen einzeln interviewt. Das Gespra¨ch dient dazu, die Meinungen und die Aussagen der Benutzer zu dem System zu sammeln und zu untersuchen. Vorteilhaft ist, dass auf die Benutzer einzeln eingegangen werden kann und somit unvorhergesehene Fragen und Beanstandungen gekla¨rt werden ko¨nnen.
Kontrolliertes Experiment Bei einem kontrollierten Experiment wird den ausgewa¨hlten Benutzern eine Aufgabe gestellt, die sie mit dem System bewa¨ltigen mu¨ssen. Dabei wird beobachtet, welche Entwicklergruppen in welchen Bereichen Schwierigkeiten haben. Feld-Beobachtung Eine der wichtigsten Evaluierungsmethoden fu¨r diese Arbeit ist der Feldtest. Dabei werden die Benutzer wa¨hrend der Arbeit mit dem neuen System beobachtet. Im Vergleich zum kontrollierten Experiment ist diese Methode praxisrelevanter und kann unvorhergesehene Ergebnisse liefern.
Als eine wirksame Evaluierungsmethode hat sich eine Mischung aus Gruppeninterview, Feld-Beobachtung und kontrolliertem Experiment herausgestellt. Dabei wurden mehrere Benutzer aus beiden Gruppen zu einer Pra¨sentation eingeladen. Der Ablauf der Versuche wurde dann wie folgt durchgefu¨hrt: Eine Schrittkette sollte zwischen mehreren Benutzern diskutiert und gegebenenfalls editiert werden. Die A¨nderungen an der Schrittkette, die im Verlauf des Tests entstanden, wurden z.B. von einem Projektleiter durchgefu¨hrt. Dabei konnten die Testpersonen ihre perso¨nliche Meinung einbringen. Durch solche Experimente konnten die Schwierigkeiten in der Benutzung der Prototypen des Struktureditors herausgestellt und beseitigt werden. Die eindeutigsten und aussagekra¨ftigsten Beobachtungen konnten bei der Kommunikation zwischen den Entwicklergruppen gemacht werden. Durch diese Experimente konnte die Darstellung der Benutzungsschnittstelle und der Softwarebeschreibungssprache an die Kommunikation zwischen den Entwicklergruppen angepasst werden. Die unten aufgefu¨hrten Evaluierungstests wurden sowohl mit einzelnen Personen, als auch, wie hier beschrieben, in einer Gruppe abwechselnd durchgefu¨hrt. Der erste Test sollte die Aufteilung der visuellen Sichten in den verschiedenen Prototypen herausstellen. Dabei galt es herauszufinden, wie gut sich die Benutzer in dem Struktureditor zurecht finden und welche Informationen in einer Sicht gebu¨ndelt werden oder eine eigene Sicht erhalten sollten. Dazu wurden verschiedene Prototypen des Struktureditors bereitgestellt, in denen Ausschnitte aus den SPS-Programmen, formuliert in der experimentellen DSL, in gemischten Gruppen aus Programmierern und Projektleitern diskutiert wurden.
Die Ergebnisse dieser Tests wurden fortlaufend analysiert, um neue Prototypen bereitzustellen. Durch eine große Prototypenanzahl konnte eine fu¨r die Benutzer optimale Benutzungsschnittstelle geschaffen werden, die sich recht deutlich von den Anfangswu¨nschen der Benutzer (Abbildung 4) unterscheidet. Dabei entstanden fu¨nf Sichten, in die sich der Struktureditor aufteilt: Hauptsicht, Schrittketten, Schrittketten-Variablen, Schrittketten- Aktionen und globale Variablen.
Der zweite Test bezog sich auf die Darstellung der Schritte und der Schrittketten. Das Ziel war, herauszufinden, wie versta¨ndlich die Schrittketten und Schritte mit der neuen DSL dargestellt werden. Dabei mussten die Testpersonen die Informationen aus einer vorgegebenen Schrittkette notieren. Zusa¨tzlich konnten die Benutzer in einem Interview die Eindru¨cke u¨ber die Darstellungsart und die Aufteilung der Informationen auf dem Bildschirm mitteilen.
Die Programmierer und die Projektleiter verfolgen unterschiedliche Ziele und haben sehr unterschiedliche Blickwinkel auf die Schrittketten. Daher konnten die aus diesem Test erhaltenen Ergebnisse zwischen den verschiedenen Entwicklergruppen nicht verglichen werden. Die Projektleiter hatten, wie erwartet, anfa¨nglich Schwierigkeiten zwischen den Konditionen und Transitionen zu unterscheiden. Nur eine von fu¨nf Testpersonen aus dieser Gruppe hat die Vera¨nderung und die Bedeutung sofort erkannt. Mit dem gleichen Ergebnis konnten die Schrittaktionen von den Eingangs- und Ausgangsaktionen nicht differenziert werden. Dieses Ergebnis konnte fu¨r diese Entwicklergruppe als positiv verbucht werden, da sich die Benutzer auf die fu¨r sie relevanten Aufgaben konzentrieren konnten. Aus der Gruppe der Programmierer gab es lediglich drei Testpersonen. Ohne große Mu¨he wurde die Darstellung von dieser Entwicklergruppe sofort erkannt und vollsta¨ndig interpretiert. In einem weiteren Test wurde die Darstellung der visuellen DSL untersucht. Nachdem in vorangegangenen Tests die Bedeutung der verschiedenen Aktionen in einem Schritt und die Bedeutung der Transitionen gekla¨rt wurden, konnten weitere Untersuchungen dieser Elemente durchgefu¨hrt werden. Dabei konnte speziell auf die Darstellungen der einzelnen Elemente wie Aktionen in einem Schritt, Transitionen usw. eingegangen werden. Den Testpersonen wurden dann z.B. verschiedene Transitionen vorgegeben, die interpretiert und beschrieben werden mussten. Die Darstellung der Transitionen wurde sowohl von den Projektleitern als auch von den Programmierern als intuitiv und leicht versta¨ndlich eingestuft.
Abschließend wurden mehrere Tests des gesamten Werkzeugs durchgefu¨hrt. Dazu mussten die Benutzer vorhandene Schrittketten o¨ffnen, bearbeiten und anschließend abspeichern. Die Ergebnisse aus diesen Tests sollten Schwa¨chen des Systems aufzeigen. Nach jedem Durchlauf wurden die Beanstandungen ausgebessert und ein neuer Testdurchlauf gestartet.
Fu¨r die Konstrukte der unterschiedlichen SPS-Sprachen wurden durch gezielte Evaluierung geeignete Darstellungen gefunden. Dabei ko¨nnen Schrittketten mit sa¨mtlichen beinhalteten Elementen in einer Ansicht dargestellt werden, sodass ein Benutzer eine Schrittkette mit demselben Struktureditor in derselben Ansicht editieren kann. Die Evaluierung ging so weit, dass z.B. selbst die Darstellung der Kommentare untersucht wurde. Diese sind fu¨r die Benutzer beim Erledigen ihrer Aufgaben an einigen Stellen elementar wichtig und an anderen Stellen sto¨rend und u¨berflu¨ssig.
Schrittketten, Schritte: Schritte werden in einer Schrittkette nach wie vor in einem Fluss von links nach rechts dargestellt und bestehen aus drei Teilen. Im oberen Bereich, wie in der Abbildung 5 zu sehen, befindet sich der sogenannte Schrittkopf, dem der Benutzer die auszeichnenden Informationen u¨ber einen Schritt entnehmen kann. Die dargestellten Informationen sind: Name des Schrittes, Kommentare und Timer-Attribute. Hinweisend werden ganz oben die Schrittnamen der Vorga¨ngerschritte eingeblendet, wie in der Abbildung 5 sichtbar. Weitere Schrittattribute werden in der Ansicht nicht dargestellt, da sie bei dem Entwurf und der U¨bersicht fu¨r die Benutzer zweitrangig sind. Diese ko¨nnen jedoch durch ein zusa¨tzliches Dialogfenster erreicht werden. Im mittleren Teil sind die Aktionen des Schrittes untergebracht, darunter sind die Transitionen aufgefu¨hrt.
Schritt-Aktionen In der Abbildung 5 sind einige Aktionen in einem Schritt zu sehen. Auch wenn die Schrittaktionen in AWL anders als die Eingangs- und Ausgangsaktionen in ST sind, wurde die Darstellung anna¨hernd gleich gehalten, um ein einheitliches Bild der logisch zusammen geho¨renden Aktionen zu bekommen. Besonders sei auf den Schritt N0025 in der Abbildung 5 hingewiesen. In der Ausgangsaktion dieses Schrittes ist eine bedingte Anweisung dargestellt. Solche Darstellungen sind mit den Schrittketten-Ablaufzetteln nicht mo¨glich.
Abbildung 5: Schritte/Aktionen/Transitionen Transitionen Eine Transition beschreibt die Bedingung und den U¨bergang zum na¨chsten Schritt. Wenn ein Schritt mehrere Transitionen besitzt, werden diese nebeneinander aufgereiht. Eine Transition ist, wie der Schritt, in drei Teile gegliedert. Als erstes ist der Name der Transition platziert, gefolgt von dem Zielschritt. Unten werden die Transitionsbedingungen dargestellt.
Die neue doma¨nenspezifische Sprache wurde im Rahmen des Projekts in einem visuellen Struktureditor (Abbildung 7) realisiert, der mit einem Code Generator ausgestattet wurde. Damit die Eingliederung in die vorhandene Entwicklungsroutine mo¨glich ist, wurde zusa¨tzlich ein U¨ bersetzer fu¨r SPS nach XML implementiert. Die Abbildung 6 gibt eine U¨bersicht des Entwicklungsprozesses mit dem neuen Werkzeugsystem im Vergleich zu dem urspru¨nglichen Prozess in Abbildung 1. Nach der Einfu¨hrung des neuen Systems beginnt der Entwicklungsprozess, wie bereits in Abschnitt 2 beschrieben, mit der mechanischen Konstruktion (Abbildung 6, Position 1) der Produktionsstrecke. Sobald die beno¨tigten Schrittketten festgelegt wurden, kann mit ihrer Entwicklung, in dem Schrittkettenkonfigurator, angefangen werden (Abbildung 6, Position 2). In dem Schrittkettenkonfigurator ko¨nnen Benutzer die Schrittketten beliebig mit Schritten, Aktionen und Transitionen vervollsta¨ndigen (Abbildung 6, Position 3,4).
Abbildung 6: Vera¨nderter Entwicklungsprozess mit dem Schrittkettenkonfigurator Die Projektleiter beschreiben im Wesentlichen, wie viele Schritte beno¨tigt werden und welche Aktionen in diesen Schritten enthalten sein mu¨ssen. Die genaue Parametrisierung der Aktionen ist die Aufgabe der Programmierer. Weiterhin beschreiben die Projektleiter einfache Transitionen, die ebenfalls durch Programmierer nachtra¨glich vervollsta¨ndigt werden. Alle Informationen, die das Wissen der Projektleiter u¨ber SPS-Programmierung u¨bersteigen, werden in Form einfacher Kommentare in die betroffenen Module eingetragen. Enormer Vorteil in der Kommunikation ist, dass die Benutzer bei einer gemeinsamen Schnittstelle u¨ber die gleichen Elemente und Darstellungen sprechen.
Nachdem ein erster Entwurf durch die Projektleiter erfolgt ist, u¨bernehmen die Programmierer die Beschreibung. Fu¨r die Einbettung der Schrittketten in das Grundprojekt, in der Entwicklungsumgebung IndraWorks von Rexroth [Ind], wird aus dem Schrittkettenkonfigurator direkt SPS-Code generiert. Somit kann SPS-Code zwischen dem Schrittkettenkonfigurator und IndraWorks ausgetauscht werden. Der zweite nennenswerte Verbesserungspunkt im Entwicklungsprozess ist, dass die Programmierer die erhaltenen Schrittketten
Abbildung 7: Schrittkettenkonfigurator nicht neu erfassen mu¨ssen, sondern dort anknu¨pfen ko¨nnen, wo die Projektleiter aufgeho¨rt haben. Verpackt in einem Struktureditor ist die doma¨nenspezifische Sprache perfekt in den Entwicklungsprozess integriert und unterstu¨tzt die Entwickler angemessen. 5
Fu¨r die Entwicklung der visuellen DSL und ihrer Implementierung haben wir den Generator DEViL [Sch06a] eingesetzt. DEViL basiert auf den Konzepten des U¨bersetzergeneratorsystems Eli [Eli] und ist der Nachfolger von VL-Eli [KS02]. DEViL generiert aus Spezifikationen hohen Abstraktionsniveaus vollsta¨ndige graphische Struktureditoren, die aus einer Multifensterumgebung bestehen und alle Eigenschaften heutiger visueller Editoren wie Laden und Speichern von Dokumenten im XML-Format, Kopier- und Einf u¨gesowie Undo/Redo-Operationen, Drucken von Dokumenten und Suchen bieten. Zentrale Datenstruktur der generierten Editoren ist ein abstrakter Strukturbaum. Er wird aus einer Spezifikation generiert, die einem klassenbasierten Entwurf a¨hnelt. In der Spezifikationssprache sind die Definition von Attributen mit vor- oder selbstdefinierten Typen, Referenzen auf Sprachkonstrukte sowie Aggregation von Sprachelementen und Mehrfachvererbung erlaubt. Aus solch einer Sprachspezifikation kann DEViL bereits einen rudimenta¨ren Struktureditor mit einer Baumansicht generieren. Dadurch konnten wir schon mit unterschiedlichen Strukturen unserer DSL experimentieren, bevor wir die Visuelle Repra¨sentation der Sprachelemente entworfen hatten.
Um eine visuelle Sprache zu definieren, benutzt DEViL das Konzept der visuellen Muster. Visuelle Muster sind in visuellen Sprachen ha¨ufig vorkommende Repra¨sentationen wie Listen, Formulare, Mengen oder Tabellen. Der Sprachentwickler kann aus einer großen Bibliothek von Mustern wa¨hlen, diese anpassen und dann einfach auf das Sprachmodell anwenden (Abbildung 8). Alle fu¨r die graphische Darstellung der Sprachelemente notwendigen Implementierungen leistet das System dann automatisch. Soo konnten wird mit recht geringem Aufwand die graphischen Darstellungen von Sprachelementen a¨ndern, wenn die Evaluation dazu den Anlass gab. Des Weiteren kann der Sprachentwickler eine Code Erzeugung fu¨r den Struktureditor definieren. Hier stehen ihm alle Mo¨glichkeiten des Eli U¨bersetzergeneratorsystems zur Verfu¨gung, insbesondere die Unparser. Mit diesen Mitteln haben wir die Erzeugung von SPS-Code realisiert. Die von DEViL generierten Struktureditoren erlauben es dem Benutzer, immer syntaktisch korrekte Programme zu erzeugen. Um komplexere semantische Analysen durchzufu¨hren, stehen viele weitere vordefinierte Funktionen bereit und u¨ber eine Sprachschnittstelle ko¨nnen C/C++ bzw. Tcl-Funktionen eingebunden werden.
Abbildung 8: Konzept des DEViL-Systems 6
Es existiert eine Vielzahl verschiedener Werkzeugsysteme und Struktureditoren fu¨r SPSSoftware, die unter anderem auch u¨ber visuelle Darstellungen, visuelle Sprachen und Code Generatoren verfu¨gen. Auch gibt es verschiedene Werkzeugsysteme, mit denen Struktureditoren aus Spezifikationen generiert werden. Im Rahmen dieses Papiers ko¨nnen wir lediglich eine kleine U¨ bersicht daru¨ber geben.
Wie schon aus dem SPS-Standard hervorgeht, gibt es visuelle Notationen f u¨r SPS und umfangreiche Entwicklungsumgebungen fu¨r SPS-Software, wie z.B. IndraWorks [Ind]. Diese Programmierumgebung bietet leider keine Mo¨glichkeit die Darstellungen der Sprachen zu vera¨ndern. Da diese Umgebung fu¨r professionelle Softwareentwickler ausgerichtet ist, ist sie fu¨r unerfahrene Benutzer nicht gut geignet. Durch einfachere und besser angepasste Notationen ko¨nnen auch die unerfahrenen Benutzergruppen erreicht werden. Werkzeugsysteme zur Entwicklung visueller Struktureditoren sind z.B. GenGed [Bar98], MetaEdit+ [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 Ba¨ume mit Querreferenzen repra¨sentiert, was eine entscheidende Rolle bei der Strukturmodellierung und den Sicht-Definitionen spielt. Einen a¨hnlichen Ansatz der Modellierung findet man beim MetaEdit+. Dieses System hat leider eine eingeschra¨nkte Flexibilita¨t bezu¨glich grafischer Repra¨sentationen. DEViL bietet dagegen spezialisiertere und sta¨rker parametrisierbare grafische Fa¨higkeiten. So gibt es z.B. Spezialmuster fu¨r Ba¨ume VPExplorerTree bzw. VPTree [Sch06b] mit Anbindung an das Graphlayout Werkzeug Dot und diverse Listenmuster. Außerdem sind Funktionen eingebettet um z.B. die U¨ 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 Vorga¨nger von DEViL, in anderen Projekten erfolgreich durchgefu¨hrt. So wurde in Zusammenarbeit mit Sagem Orga SIMtelligence Designer/J [SPKF02], eine visuelle Sprache zur Anwendungsentwicklung fu¨r SIM-Karten, entwickelt. 7
Das Ziel dieser Arbeit war die Modernisierung und Verbesserung des Entwicklungsprozesses von SPS-Schrittketten in industrieller Umgebung. Dazu wurde eine visuelle dom a¨nenspezifische Sprache mit dem Werkzeugsystem DEViL fu¨r zwei, miteinander kommunizierende, Entwicklergruppen entwickelt und speziell an deren Aufgaben angepasst. Fu¨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 fu¨r genau die durchgefu¨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 fu¨r beide Entwicklergruppen geeignete visuelle DSL sowie eine u¨bersichtliche und aufgabenkonforme Benutzungsschnittstelle entworfen. Der dabei entwickelte Schrittkettenkonfigurator entspricht den Vorstellungen der Benutzer. Durch die Einfu¨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 erfu¨llt, wurde erst wa¨hrend der Entwicklung die Ausbaufa¨higkeit des Systems deutlich. So wurden nachtra¨glich zum konformen Ausdrucken der Schrittketten aus dem Schrittkettenkonfigurator zusa¨tzliche Module in DEViL eingebaut und stehen somit auch allen weiteren mit DEViL generierten Editoren zur Verfu¨gung. U¨ber die systematische Evaluierung des DEViL-Systems und mit ihm erzeugter Sprachimplementierungen wird in [Sch06b] und [SCK07] berichtet. Der Struktureditor soll in Zukunft weitere Funktionen bekommen und z.B. fu¨r Analysen und diverse Simulationszwecke erweitert werden. Einige solcher Erweiterungen sind bereits geplant, z.B. eine visuelle Simulationssicht fu¨r Schritte und Aktionen. Das gesamte Konzept hat bei Bosch großen Zuspruch gefunden.
[Aue89] [Bar98]
A. Auer. SPS - Aufbau und Programmierung 2., ¨ıberarb. Aufl. Huethig, 1989. Roswitha Bardohl. GenGed: A Generic Graphical Editor for Visual Languages based on Algebraic Graph Grammars. In 1998 IEEE Symp. on Visual Lang., Seiten 48–55, September 1998. [Con02]
MetaCase Consulting. MetaEdit+ User’s Guide, 2002. http://www.metacase.com/. [Eli] [Ind] [Inf03] [KS02] [Sch06a] [Sch06b] [SCK07] [SK03]
Eli Website. http://www.uni-paderborn.de/fachbereich/AG/agkastens/eli home.html. IndraWorks von Rexroth. http://www.boschrexroth.com/.
Deutsche Kommission Elektrotechnik Elektronik Informatik. IEC 61131-3 Speicherprogrammierbare Steuerungen Teil 3, 2003. Programmiersprachen Deutsche Fassung EN 61131-3:2003.
Uwe Kastens und Carsten Schmidt. VL-Eli: A Generator for Visual Languages. In Proceedings of Second Workshop on Language Descriptions, Tools and Applications (LDTA’02), number 2027 in Electronic Notes in Theoretical Computer Science, Grenoble, France, 2002. Band 65, Elsevier Science Publishers.
Carsten Schmidt. DEViL paderborn.de/forschung/devil/.
Carsten Schmidt, Bastian Cramer und Uwe Kastens. Usability Evaluation of a System for Implementation of Visual Languages. In Symposium on Visual Languages and Human-Centric Computing, IEEE Computer Society Press , Seiten S. 231– 238, September 2007.