Bild 1. Anlagenmodell eines einfachen Produktionsprozesses.

© Fortiss

Das Modell stellt meist eine erhebliche Vereinfachung der Realität dar, da seine Mächtigkeit im Zielkonflikt mit der Synthesezeit steht. Beim vorgestellten Ansatz besteht das Modell aus drei Ebenen: dem Hardwaremodell, dem Anlagenmodell und dem Aufgabenmodell.

Das Hardwaremodell beschreibt die Eigenschaften der verbauten Hardwaremodule. Jedes Modul wird dabei durch eine Menge von Arbeitspositionen und einer Menge von Aktionen charakterisiert. Die Arbeitspositionen repräsentieren Orte im jeweiligen Modul, an denen sich Werkstücke befinden können. Die Aktionen erlauben es, die verschiedenen Arbeitsschritte zu modellieren, die das Modul ausführen kann. Ein unidirektionales Förderband ist im einfachsten Fall durch zwei Arbeitspositionen und eine Aktion „bewege-Band“ charakterisierbar, die ein Werkstück von Position 1 nach Position 2 transportiert (siehe Tabelle).

Module einer Produktionsanlage werden im Hardwaremodell abstrakt beschrieben.

© Fortiss

Entsprechend können einfache Bearbeitungsschritte, wie das Bohren eines Lochs in ein Werkstück, durch ein Modul „Bohrer“ mit einer Arbeitspo­sition und der Aktion „bohre-Werkstück“ beschrieben werden. Die Modellierung von Sensoreingaben erfolgt ähnlich: Die Erkennung, welche Farbe ein Werkstück hat, wird mittels der Aktion „erkenne-Farbe“ im Modul „Farbsensor“ abgebildet.

Im Anlagenmodell werden die Hardwaremodule zu einer konkreten Anlage kombiniert. Eine Anlage kann zum Beispiel aus den in Bild 1 dargestellten Komponenten bestehen. Um die Anordnung der Module im Modell zu erfassen, wird definiert, welche Arbeitspositionen jeweils „überlappen“. In der Beispielanlage überlappt Position 2 der Weiche mit Position 1 des Förderbands – hier mit „B“ gekennzeichnet. Gleiches gilt beispielsweise für Position 2 des Förderbands und die linke Position des Drehtellers (C). Aus dieser Definition und den zur Verfügung stehenden Aktionen lässt sich automatisch der mögliche Materialfluss ableiten.

Bild 2. Das Entwicklungswerkzeug MGSyn unterstützt den Benutzer bei der Eingabe der Modelle und der Synthese.

© Fortiss

Das Aufgabenmodell erlaubt schließlich die Spezifikation einer abstrakten Arbeitsaufgabe. Dabei werden Anfangszustand und gewünschter Endzustand benannt. Die informelle Beschreibung einer möglichen Aufgabe in der Beispielanlage ist: „Gegeben ein Werkstück namens ‚WS‘ an Position ‚A‘ (unteres Ende des Stapelmagazins), soll der Endzustand sein, dass sich das Werkstück an Position ‚I‘ befindet (oberes Ende der Rutsche) und genau dann gebohrt ist, wenn es rot ist.“ Diese Aufgabe kann wie folgt notiert werden:

• Anfangszustand: Position(WS, A)
• Endzustand: Position(WS, I)  (gebohrt(WS) ⇔ Farbe(WS, rot))

Die Konstrukte „Position“, „Farbe“ und „gebohrt“ stammen dabei aus dem Hardwaremodell und repräsentieren den Zustand der Anlage und der darin befind­lichen Werkstücke zu einem gewissen Zeitpunkt. Für die Spezifikation der drei Modelle wurde das frei verfügbare Entwicklungswerkzeug MGSyn erstellt (siehe Bild 2).

Synthese von Steuerungs­programmen

Nun kann das „Spiel“ beginnen. Auf Knopfdruck werden die vorhandenen Aktionen dazu zunächst in Züge von Steuerungsprogramm und Umgebung mit entsprechenden Vor- und Nachbedingungen umgewandelt. Im konkreten Fall kann das Steuerungsprogramm die Weichen, das Förderband und den Drehteller bewegen, den Bohrer auslösen und die Umgebung nach der Farbe eines Werkstücks fragen, sofern dieses sich beim Farbsensor befindet. Die Umgebung wartet auf eine Anfrage nach der Farbe und hat dann als Antwort drei „Züge“ zur Verfügung, die den drei möglichen Farben Schwarz, Rot und Silber entsprechen. Der spielbasierte Löser übernimmt nun die Generierung eines Steuerungsprogramms, das in der Lage ist, auf die Eingaben aus der Umgebung (modelliert als Züge des Umgebungsspielers) während der Ausführung zu reagieren. Hier besteht ein wesentlicher Unterschied zur traditionellen Planung, bei der in der Regel alle Parameter bereits vorab bekannt sind und die abzuarbeitenden Schritte im Voraus festgelegt werden.

Schlussendlich wird im Beispiel ein Steuerungsprogramm generiert, das zunächst die Farbe des Werkstücks testet und dann das Werkstück abhängig vom Ergebnis bohrt. Sollte es für eine gegebene Aufgabe keine Lösung geben, so wird dies automatisch erkannt und entsprechend rückgemeldet. Das entwickelte Werkzeug liefert jedoch nicht nur eine Lösung für die gegebene Aufgabe, sondern beinhaltet auch Mechanismen, um diese Lösung sowohl zu simulieren als auch auf der Zielhardware zur Ausführung zu bringen. Die Simulation erlaubt es, Anlagen zu evaluieren, die es in der Realität (noch) nicht gibt. Die konkrete Ausführung auf der Zielhardware unterstützt handelsübliche Steuerungen von Siemens und Festo, die mittels OPC und Siemens-MPI angebunden sind. Zusätzlich werden mittels Code-Generierung eingebettete mikrocontrollerbasierte Zielplattformen unterstützt.

Um die synthetisierten Steuerungs­programme zu optimieren, wurden des Weiteren Mechanismen untersucht, die die gleichzeitige Ausführung von meh­reren Aktionen und die Auswahl eines optimalen Steuerungsprogramms aus der Menge aller möglichen Lösungen auf der Basis von geeigneten Kosten­modellen erlauben.

Die Stärken dieses Verfahrens zeigen sich, wenn sich die auszuführende Aufgabe ändert: Da die Beschreibung der Aufgabe im Gegensatz zur traditionellen Programmierung auf einer sehr abstrakten Ebene stattfindet, reicht eine geringe Einarbeitungszeit, um diese abändern zu können. Wichtig ist hierbei, dass das Aufgabenmodell keine konkrete Umsetzung der Aufgabe benennt, sondern vielmehr deren Anforderungen auflistet. Es wird also spezifiziert, was die Anlage tun soll und nicht wie sie es tun soll. Dies vermeidet, dass Design-Entscheidungen tief in das Steuerungsprogramm eingebettet werden. Die formale Spezifikation im Hardwaremodell könnte dabei der Hersteller der Hardwaremodule liefern, ähnlich wie Hersteller von Computerperipherie entsprechende Treiber zur Verfügung stellen.

Reif für die industrielle Praxis?

Die Einsatzfähigkeit der automatischen Synthese hängt maßgeblich davon ab, wie umfangreich die Modelle sind und wie optimal die resultierenden Steuerungsprogramme sein sollen. Im Allgemeinen steigt die Synthesezeit exponenziell mit der Größe des Zustandsraums. Handelt es sich um komplexe Systeme, so ist es sinnvoll, diese in verschiedene Teilsysteme zu zerlegen, die dann einzeln betrachtet und schneller synthetisiert werden können.

Eins ist sicher: Die automatische Synthese wird in naher Zukunft die manuelle Programmierung sicher nicht ersetzen. Selbst mit solchen Ansätzen sind noch Experten nötig, die das Hardware- und Anlagenmodell erstellen und die lokalen Regelschleifen der modellierten Aktionen umsetzen. Denn Modelle sind nur so gut wie die Informationen darin – und gleiches gilt für die daraus synthetisierten Steuerungsprogramme.

Die Modelle sollten daher als unmissverständliche Dokumentation der auszuführenden Produktionsaufgabe verstanden werden, die sich bei Bedarf auch automatisch verarbeiten lässt. Dennoch eröffnet dieser Ansatz sogar kleinen und mittelständischen Un­ternehmen die
Chance, die Software für einfache Automatisierungsaufgaben durch Erstellung beziehungsweise Anpassung des Aufgabenmodells selbst zu konfigurieren und damit Kosten zu sparen.

Autoren: Michael Geisinger arbeitet als wissenschaft­licher Mitarbeiter am Fortiss-Institut der TU München, Dr. Chih-Hong Cheng ist am Fortiss-Institut der TU München als Gruppenleiter tätig.