Workflows in iPlus haben eine etwas andere Bedeutung als Workflows in der allgemeinen Literatur beschrieben (https://de.wikipedia.org/wiki/Arbeitsablauf). Ein Workflow in iPlus ist eigentlich ein Programm (in der Entwicklersprache: "Methode") das grafisch, anstatt textuell, programmiert wird und quasi eine alternative Programmiersprache in der iPlus-Runtime darstellt.

So wie Programme wieder andere Programme (Unterprogramme) aufrufen können, können Workflows wieder andere Workflows (Unterworkflows) aufrufen. Genau genommen sind Workflows asynchrone Programme, da sie sich nach dem Start nicht sofort beenden, wie es sogenannte "synchrone" Programme tun. Das liegt daran, dass Workflows aus einem Netz von Workflowknoten* bestehen, die einen Zustand besitzen und eine zeitlang in diesen Zuständen verbleiben.

Der Zustandsautomat der Workflowknoten ist nach der https://de.wikipedia.org/wiki/ISA-88 Norm implementiert (Idle, Running, Complete...). Im Gegensatz zu der ISA-88-Norm benötigen Workflows nicht unbedingt ein physikalisches Modell was eine weit universellere Nutzbarkeit der Workflows ermöglicht.

Somit können physikalisch unabahängige Workflowknoten bzw. Workflowklassen programmiert bzw. eingesetzt werden (z.B. Warte auf E-Mail-Eingang, Sende Daten an einen Internetdienst, Warte auf Lieferscheinrückmeldung...). Natürlich können auch andere .NET-Methoden/Skripte aufgerufen werden, die ein Entwickler programmiert und in der iPlus-Runtime registriert hat.

* Synonyme: Operation, Prozesschritt, Phase, Aktion..

Workflows haben einen sogenannten "Methodennamen" über den Sie aufgerufen bzw. gestartet werden. Dieser Methodenname muss eindeutig innerhalb seiner Klasse sein zu der er gehört.
Für "Nicht-Programmierer" ist eine Klasse vergleichbar einem Dateiordner (innerhalb einer Ordnerhierachie) in der die Dateinamen eindeutig sein müssen.

In der Regel werden Workflows in "Dateiordnern" auf der obersten Hierarchieebene angelegt, den so genannten "Anwendungsdefinitions-Projekten".

Die Auswahl des Anwendungsdefinitionsprojektes erfolgt über die Combobox im Explorer. In der Liste werden dann die bereits vorhandenen Workflows mit ihren Methodennamen aufgelistet.
(Entwickler die Zugriff auf die iPlus-Entwicklungsumgebung haben, können Workflows auch bei Klassen hinzufügen, die sich auf tieferen Hierarchieebenen befinden)

Ein Workflow besteht immer aus
- einem Wurzelknoten (äußerster Rahmen A) und
- einem Start- und Endeknoten (kurzer horizontaler Balken B,C).

Workflowknoten sind verbunden durch Workflowkanten, die als Linien mit Pfeilen dargestellt sind (D). Der Pfeil gibt die Programmflussrichtung an.

Ein Workflow muss immer so programmiert werden, dass er sich selbst beenden kann.
Das bedeutet, dass die Workflowknoten so verbunden werden müssen dass der Programmfluss am letzten Endeknoten des Wurzelknotens endet (F).

Alle Workflowknoten müssen innerhalb eines Wurzelknotens plaziert werden.

Workflows sind hierarchisch. Die Hierarchie entsteht durch die Verwendung von besonderen Workflowknoten den Gruppenknoten (G). Ein Gruppenknoten besteht wie ein Wurzelknoten aus einem Start- und Endeknoten (H). Auch hier gilt, dass die Unterknoten innerhalb des Gruppenknotens durch Kanten so verbunden werden dass der Programmfluss an Endeknoten des Gruppenknotens endet.

Workflowknoten besitzen mindestens einen Eingangs- und einen Ausgangspunkt an dem die Knoten verbunden werden können (Ausgenommen Start- und Endepunkte). Die Kanten können immer nur von einem Ausgangs- zum einem Eingangspunkt eines anderen Knoten verbunden werden.

Entscheidungsknoten können auch mehrere Ausgangspunkte besitzen (z.B. Ja- oder Nein-Ausgang).
Wenn Sie Schleifen bauen, achten Sie bitte darauf, dass keine Endlosschleife entsteht!

Der Programmablauf eines aktiven Workflows ist ereignisgesteuert. Das bedeutet, nachdem ein Workflowknoten abgearbeitet ist wird über die Kante einmalig ein Signal an den Eingangspunkt des Folgeknotens gesendet (Terminologie: "Es wird ein Ausgangsevent ausgelöst"). Mehr dazu können Sie im Kapitel "Workflowablauf und Ereignisse" nachlesen.

Der Folgeknoten startet nur dann, wenn alle Kanten an seinem Eingangspunkt ein Signal gesendet haben - Eine sogenannte UND-Verknüpfung.

Das Gegenteil einer UND-Verknüpfung ist eine ODER-Verknüpfung (I). Diese muss als ein separater Workflowknoten vorgeschaltet werden, wenn man will dass ein Workflowknoten startet sobald mindestens ein Eingangsereignis aufgetreten ist.

Eingangsknoten "vergessen" Ihre Signalzustände nachdem sie den Workflowknoten gestartet haben. Das bedeutet, dass Sie beim einfügen von Schleifen daran denken müssen, dass wieder alle Eingangssignale erneut getriggert werden müssen. Daher sind Schleifen meist so programmiert, dass das Ziel der Kante ein ODER-Knoten ist (J).

 

 

Workflows können automatisch oder über Benutzerinteraktion gestartet werden. Dies obliegt dem Anwendungsprogrammierer wie das umgesetzt wird. Bei Nutzung von iPlus.MES wird der Start in vielen Anwendungsprogrammen automatisch ausgelöst (z.B. im Produktionsauftrag, Kommissionierauftrag, Lagerverwaltung,...).

Workflows werden in der Regel mehrfach gestartet, wenn parallele Prozesse benötigt werden (z.B. Batchbetrieb) oder die zu automatisierende Anlage in Form von mehrfachen Linien oder Anlagenteilen vorliegt.

Werden Workflows also zur Steuerung von Produktionsanlagen eingesetzt so konkurrieren die aktiven Workflows um gemeinsame Resourcen (Linien, Produktionseinheiten, Maschinen..) und müssen gegenseitig durch Priorisierungsregeln synchronisiert werden. Eine physikalische Resource kann zu einem Zeitpunkt nur von einem Programmablauf gesteuert werden. Dies wird mittels besonderen Workflowgruppenknoten geregelt, welche die Eigenschaft haben eine Maschine exklusiv für sich belegen zu können. Welche Maschine bzw. Typ von Maschine ein Workflowgruppenknoten belegen kann, wird implizit dadurch gelöst, dass Workflows auf der Ebene der Anwendungsdefinition (A) programmiert werden.

Die Anwendungsdefinition ist eine Art Vorlage aus der in der zweiten Stufe eine iPlus-Anwendung (B) hervorgeht. Eine iPlus-Anwendung ist meistens das physikalische Abbild einer Produktionsanlage.

In der Anwendungsdefinition werden Typen von Maschinen, Bauteilen und Funktionen definiert aus denen später in der Anwendung konkrete Instanzen werden (C). Aus einer Anwendungsdefinition können beliebig viele Anwendungen angelegt werden. Ebenso kann es beliebig viele Instanzen geben, die aus den Typen in der Anwendungsdefinition hervorgehen.

Bei der Editierung eines Workflows im Workfloweditor, bekommen Sie in der Werkzeugleiste (D) nur die workflowrelevanten Typen aus der Anwendungsdefinition angezeigt. Das sind Typen die auf sogenannten "Prozessmodulen" (E) oder "Funktionen" (F) basieren. Prozessmodule sind Objekte, die später in der Anwendung in der Regel eine Maschine o.ä. repräsentieren und die als Unterobjekte sogenannte "Funktionen" besitzen die von Workflowknoten aufgerufen/aktiviert werden.

Wird beim Editieren des Workflows der Typ eines Prozessmoduls verwendet, dann wird stellvertretend ein Gruppenknoten in den Workflow eingefügt (G).

 

Wird dagegen eine Funktion verwendet, dann wird stellvertretend ein Workflowknoten eingefügt (H), der später (wenn der Workflow aktiv ist) die entsprechende Funktion bei der konkreten Instanz aufrufen kann (physikalisches Modell). Diese werden delegierende Workflowknoten genannt.

Funktionen die einem anderen Typ von Prozessmodul angehören können nicht innerhalb des selben Gruppenknotens eingefügt werden (J).

Sie können jedoch alle anderen Workflowklassen einfügen, die nicht auf Typen einer Anwendungsdefinition basieren (K), weil diese später nicht auf ein konkretes physikalisches Objekt angewiesen sind. Diese werden selbstständige Workflowknoten genannt.

 

 

Damit Workflows angelegt werden können müssen Sie folgende Vorarbeiten durchführen:

1. iPlus-kompatible Assemblies, die Workflowklassen beinhalten, per Reflection importieren (Login per linke Strg-Taste). Damit werden diese Workflowklassen in Klassenbibliotheksprojekt der Entwicklungsumgebung registriert.
2. Ein oder mehrere Anwendungsdefinitionsprojekte in der Entwicklungsumgebung definieren. Falls Workflowknoten benötigt werden die sich auf ein physikalisches Modell beziehen, muss das Anwendungsdefinitionsprojekt mit den entsprechenden Prozessmodulen und Funktionsobjekten bestückt werden. Die daraus resultierende Anwendung kann auch später erstellt werden.