LEGO Mindstorms-Steuerung mit BPMN

Oliver Hock 29. November 2016

Ein Prozess lernt laufen – LEGO® MINDSTORMS®-Steuerung mit BPMN

Betriebliche Abläufe gehören heute zum Geschäftsalltag wie LEGO zur Kindheit. Doch leider bleibt die strukturierte Darstellung, Transparenz und Wartbarkeit bei der Ausführung von Geschäftsprozessen immer wieder auf der Strecke. Wenn allerdings Kinder in unseren gemeinnützigen Workshops mit Legosteinen spielen und daraus Roboter bauen, erleben wir genau das Gegenteil – und zwar ein äußerst hohes Maß an Verständlichkeit und Zielorientierung.

Oft als "Alte-Männer-Thema" abgestempelt, setzt eine Prozessautomation mit BPMN (Business Process Model and Notation) genau an den Schwachstellen an und schließt die Lücken zwischen Business und IT.

In diesem Artikel wird am Beispiel eines MINDSTORMS-Roboters, der einen Zauberwürfel löst, ein professionelles Prozessmanagement mit seiner BPMN-Automation verheiratet. Motoren und Sensoren werden über Java angesprochen und bringen so unsere strukturierte Geschäftswelt und die Welt unserer Kinder zusammen. Ein Ansatz, der äußerst jung, dynamisch und zukunftweisend daher kommt.

Geschäftsprozesse und der Mehrwert einer BPM-Plattform

In unseren Unternehmen implementieren wir unsere Geschäftsprozesse auf unterschiedlichste Weise, doch bilden sie immer unser Kerngeschäft ab und werden durch Unterstützungsprozesse ergänzt. Während beispielsweise ein IT-Startup seine Entwicklungs- und Lieferprozesse erfinderisch gestaltet, sorgt eine Versicherung eher für eine wohldefinierte und transparente Prozesslandschaft.

Alle Organisationen haben dabei eines gemeinsam: Ihre Abläufe verändern sich im Laufe der Zeit. Daher sollten regelmäßig Optimierungen durchgeführt werden, um Verbesserungspotenziale zu nutzen. Das gilt sowohl für die wiederkehrenden Ausführungen der Geschäftsprozesse, also den Betrieb, als auch für die vorangehende Optimierungsphase. Ein Unternehmen identifiziert i. d. R. einen oder mehrere ineffiziente Bereiche und schafft mit dedizierten Projekten eine messbare Verbesserung.

Eine BPM-Plattform unterstützt dabei, die Geschäftsprozesse mit einer standardisierten Sprache zu beschreiben. Diese lassen sich über eine im Unternehmen vorhandene Plattform veröffentlichen, dienen also gleichzeitig als Dokumentation. Beim Einsatz von BPMN werden die Prozessbeschreibungen von der IT aufgegriffen, automatisiert und einzelne Systemkomponenten integriert.

Sogar das Internet der Dinge (IoT) spielt zunehmend eine Rolle. Der Informationsfluss verteilt sich über eine wachsende Anzahl von Gadgets und Geräten, die allesamt bedient werden wollen. Wenn das Business technische Komponenten steuert, wird oftmals von BPM Everywhere gesprochen.

Aspekte der Geschäftsprozessmodellierung mit BPMN

Geschäftsprozesse lassen sich mit der standardisierten BPMN modellieren. Einige Elemente aus dieser Notation werden hier besprochen, wobei dies die Elemente sind, welche auch in dem Projekt zur Lösung des Zauberwürfels verwendet werden.

Ein Prozess beginnt immer mit einem Event, der Quelle. Senken beenden einen Prozess, wobei es von einer Quelle genau eine pro Prozess gibt. Senken hingegen sind mehrere innerhalb eines Prozesses erlaubt.
Gatways steuern den Prozessfluss. Ein Exclusive lässt genau einen Ausgang zu, ein Parallel steuert alle Ausgänge an.
Aktivitäten führen Aufrufe für den Datenaustausch aus. Sie wickeln also die Interaktion mit der Umwelt eines Systems ab.
Die Verbindungen definieren die Richtung des Informationsflusses im Prozess und beschreiben, welche Elemente miteinander kommunizieren.

Abb.2: BPMN Parallel Gateways und Service Tasks. © Oliver Hock

Aktivitäten haben unterschiedliche Ausprägungen. Eine davon ist die Call Activity. Sie ruft ein weiteres BPMN-Element auf, z. B. einen Subprozess. Der Aufrufer kann Parameter in das aufgerufene Element hineinreichen und wieder entgegennehmen. So lassen sich große Prozessmodelle gut strukturieren und die Wartbarkeit der Modellierung bleibt erhalten.

Eine zweite Ausprägung sind Service Tasks, welche mittels Java-Klassen definieren, was zur Ausführung kommt und wie. Die Klassen implementieren sog. JavaDelegate-Interfaces und nehmen die Variablen vom aufrufenden Task entgegen, die ihre Sichtbarkeit innerhalb des Execution-Kontexts haben.

Listing 1: Implementierung eines Service Tasks

public class RotateDelegate implements JavaDelegate {

   public void execute(DelegateExecution execution) throws Exception {
       String port = (String) execution.getVariab1e("port");
       Integer angle = Integer.valueOf(String.valueOf(execution.getVariab1e("ang1e")));
       Boolean immediateReturn = Boolean.valueOf((String)execution.getVariab1e("immediateReturn"));
       Integer speed = readSpeed(execution);

       /* Robot behavior here */

Der Camunda Modeler z. B. bietet Templates an. Diese erlauben die Konfiguration der implementierenden Java-Klasse plus deren Variablen, die über den Kontext in die Klasse hineingereicht werden sollen.

Abb.3: Camunda Modeler Templates. © Oliver Hock

Deklariert werden die Templates über ein JSON-Skript im Resources-Verzeichnis der Installation.

Listing 2: Template Deklaration

{
  "name": "Motor Rotation",
  "id": 'com.videap3.cube.solving.access.motor.RotateMotor",
  "appliesTo": [
    "bpmn:5erviceTask'
  ],
  "properties": [
    {
      "label": "Implementation",
      "type": "String",
      "value": "com.videap3.cube.solving.access.motor.RotateDe1egate',
      "editable": false,
      "binding": {
        "type": "property",
        "name": "camunda:c1ass"
      }
    },
    {
      "label": "Port",
      "type": "String",
      "binding": {
        "type": 'camunda:inputParameter',
        "name": "port"
      },
      "constraints": {
        "notEmpty": true
      }
    }

Verwendung von Entscheidungstabellen mit DMN

Neben den Geschäftsprozessen können auch Geschäftsregeln standardisiert abgebildet und ausgeführt werden. Die DMN (Decision Model And Notation) beschreibt ein Mapping zwischen einer Parametrisierung und einer Menge von möglichen Ausgabewerten.

Camunda hat die Entscheidungstabellen bereits in ihrem Modeler und ihrer Prozess-Engine aufgenommen. Das folgende Beispiel zeigt die Reihenfolge der Bewegungen des Zauberwürfels beim Einlesen seiner Farben. Fall 1 (upperToFront) gibt aus, wie der Würfel zu bewegen ist, um nach der Oberseite (U: Upper) als nächstes die Vorderseite (F: Front) zu scannen.

Die Geschäftsregeln werden über ein Diagramm entwickelt und aus einer Business Rule Task aufgerufen.

Robotik und LEGO MINDSTORMS-Modelle

Ein Roboter ist gekennzeichnet durch seine selbständige Interaktion mit seiner Außenwelt. Einmal bespielt mit einer Software, ist er zur ewigen und eigenen Entscheidungsfindung verdammt, z. T. ist er dabei sogar lernfähig. Ein Automat dagegen, oftmals auch Industrieautomat genannt, wie z. B. Schweißroboter, führt seine Aufgaben nach einem festen Programm aus. Von der Umwelt kommt lediglich der Befehl, mit dem Programm zu starten. Eine Steuerung schwächt die Definition noch weiter ab. Sie wird vollständig von außen beeinflusst und wir geben vor, was sie zu tun hat. Sieht ein Roboter menschlich aus und weckt er in uns Emotionen, sprechen wir vom Humanoid.

Dennoch hat ein Roboter Schnittstellen zu seiner Umwelt, um Signale zu erhalten und zu senden. Sensoren und Motoren spielen dabei die Hauptrolle. Diese Schnittstellen sind sehr hardwarenah und heißen Ports.

Motor-Ports treiben Motoren an. Unterschiedliche Beschleunigungen, Geschwindigkeiten und Distanzen sind möglich. Während des Betriebs können Werte eingelesen werden, wie z. B. die zurückgelegte Strecke oder die Motortemperatur. Sensor-Ports lesen Situationen aus der Umgebung ein. Farben, Temperaturen und Abstände sind hier u. a. möglich. Zunächst handelt es sich jeweils um Momentaufnahmen, erst mehrere Aufnahmen über einen Zeitraum verteilt, gekoppelt mit einer Software, lassen Schlüsse auf Verläufe und Prognosen zu. Displays, Mikrofone und Lautsprecher verarbeiten Informationen in Formaten, die wir Menschen mit unseren Sinnen verstehen können.

Das Lego Mindstorms-Modell EV3 hat vier Eingänge (Sensoren) und vier Ausgänge (Motoren). Das Vorgängermodell NXT hatte dagegen nur drei Ausgänge für Motoren. Der NXT ist das Basismodell für den Zauberwürfellöser in diesem Projekt.

Zauberwürfel und Algorithmus

Zum Lösen des Zauberwürfels wird auf eine Notation zurückgegriffen, die den Würfel und die Bewegungen eindeutig beschreibt. Gehalten in einer festen Position ist die Vorderseite das F: Front. Die Rückseite das B: Back. Oben und unten sind U: Upper und D: Down. Links und rechts dann L: Left und R: Right. Eine Drehbewegung nach rechts wird durch kein Zeichen („“), eine Linksdrehung mit einem Hochkomma („‘“) und eine halbe Drehung mit einer Zwei („2“) gekennzeichnet. Soll die Vorderseite z. B. nach rechts gedreht werden, wäre ein F notwendig, nach links F‘ und halb rum ein F2 usw. Mit diesen Drehbewegungen lassen sich alle Schritte abbilden, obwohl es noch weitere Notationen gibt.

Zur Berechnung des Algorithmus', welcher zu der Reihenfolge der einzelnen Drehbewegungen führt, wird ein 2-Phasen-Algorithmus von Kociemba verwendet. Dieser löst den Zauberwürfel aus allen Stellungen heraus in maximal 52 Schritten, meistens aber in weit unter 20 Schritten. Der Algorithmus ist in Java implementiert und als Open Source verfügbar.

Abb.5: Tilted Twister 2.0. © Oliver Hock

Das Legomodell ist ein Tilted Twister – Open Source – und wurde mit dem Anspruch entwickelt, aus dem Basiskasten des NXT einen Roboter zu bauen, der selbständig einen Zauberwürfel mechanisch lösen kann.

Der Brick ist die Recheneinheit des Mindstorms und wird über Bluetooth mit einem Rechner verbunden, auf dem das Programm läuft. Es handelt sich bei diesem Projekt z. Zt. noch um eine Steuerung im weitesten Sinne, aber in einer nächsten Version wird aus dem Tilted Twister ein echter Roboter, der das Programm auf dem Brick installiert bekommt.

Softwarearchitektur und Design

Die Anwendungslogik ist ein Java-Programm, das in Eclipse aufgesetzt ist. Die Prozessdiagramme wurden mit dem Activiti Modeler und Camunda Modeler beschrieben. Die XML-Repräsentationen der BPMN-Prozessdiagramme sind Teil des Java-Projektes. Zusammen mit der Logik werden diese mit der BPMN-Engine übersetzt und in ein JAR-Artefakt geschrieben. Dieses wird dann mittels einer Java VM ausgeführt, die eigens dafür auf den NXT-Brick heruntergeladen wird.

Abb.6: Softwarearchitektur. © Oliver Hock

Die Abbildung des Algorithmus' auf die Bewegungen des Roboters ist ausschließlich in den Prozessdiagrammen enthalten. Die Prozesselemente zur Ansteuerung des Mindstorms arbeiten mit Service Tasks zusammen, welche JavaDelegate-Implementierungen aufrufen. Diese wiederum implementieren jeweils genau eine Funktion des Zauberwürfellösers, z. B. das Drehen eines Motors (RotateDelegate.java) oder Einlesen der Farbe eines Würfelsteins (GetColorDelegate.java). Alle Delegate-Klassen befinden sich im sog. Access-Layer, sodass sie als Service auch von anderen Prozessen verwendet werden können.

Das Ansprechen der Sensor- und Motor-Ports übernimmt leJOS, welches das rudimentäre Protokoll der Ports in entwicklerfreundlichen Methodenaufrufen kapselt. Die leJOS-API wird zusammen mit der Java VM auf dem Mindstorms-Brick installiert. Ein Remote-Teil, der die Ports fernsteuert, wird auf dem Rechner betrieben, wo auch die Anwendungslogik läuft.

Der in Listing 1 gelistete Delegat implementiert diesen leJOS-Schnipsel.

Listing 3: LeJOS Schnipsel

if(Features.USE_LEJOS.isActive()) {
 RemoteMotor motor = new MotorFactory().getMotor(port);
 motor.setSpeed(speed != null ? speed : (int)motor.getMaxSpeed());
 motor.rotate(angle.intValue(), immediateReturn);
}

Das Feature-Toggle lässt sich im Test deaktivieren, um den Code auch ohne Roboter testbar zu halten. Die Factory liefert den statischen Motor-Port und die Rotate-Methode dreht den Motor um einen gewünschten Winkel. Angle gleich 180 liefert z. B. eine halbe Umdrehung.

Zusammenfassung

Die Idee für dieses Projekt ist aus meiner langjährigen Erfahrung als Prozessberater und Softwareentwickler entstanden. Viele Projekte unterliegen einem sehr hohen Effizienzdruck und stehen unter besonderer Beobachtung. Das Risiko, ineffiziente Prozesse abzubilden und die fachlichen Auswirkungen dessen sind immens. Auf der anderen Seite gehen die Mädchen und Jungen in unseren Computer-Workshops mit einer vielversprechenden Leichtigkeit und Freude an die Mindstorms-Programmierung.

Die Programmierung von Robotern – hier mit Lego Mindstorms – ist tatsächlich mit BPMN und Java möglich. BPMN-Modeler und Prozess-Engines dienen der Programmierung der erdachten Bewegungsabläufe der Roboter. Der Open Source-Gedanke gewährleistet die Anpassung an abweichende Anforderungen für die Kinder. LeJOS stellt eine bedienerfreundliche API zur Steuerung bereit, es lässt sich intuitiv auf dem Lego-Brick installieren und hat zudem eine gute Dokumentation und Community.

Als nächstes steht eine kinderleicht zu bedienende BPMN-Software an, die aus einer Open Source-Lösung abgeleitet wird. Die hardwarenahe Recheneinheit Titus Labs übernimmt dabei die Port-Ansteuerung über die JVM. Die Kids der Workshops sind dann unsere gnadenlose Zielgruppe zum Akzeptanztest benutzerfreundlicher Software.