Der Zustandsautomat von Workflowknoten, Workflowgruppen und Prozessfunktionen ist entsprechend des ISA-S88-Standards umgesetzt. Die Zustände werden nach dem folgenden Farbschema symbolisiert:

 

[Begriffe] die in rechteckigen Klammern gesetzt sind, sind Befehle, die Sie per Kontextmenü ausführen.

Achtung: Nicht jeder Workflowknoten unterstützt alle Zustände und Transitionen. 

 

"Reset"-Befehl

Der Reset-Befehl ("Zurücksetzen") ist bei den meisten Zuständen erlaubt. Dieser überführt den Workflowknoten in den Zustand "Inaktiv". 

 

Wichtig:

1. Setzen Sie niemals Workflowknoten zurück, die auf dem physikalischen Modell eine Funktion gestartet haben! Öffnen Sie dazu die Visualisierung und das entsprechende Monitorbild mit dem von der Workflowgruppe belegten Prozessmodul (Die Adresse sehen Sie im Tooltip wenn Sie die Maus über die Workflowgruppe bewegen). Überführen Sie die aktive Funktion in den "Inaktiv"-Zustand über den Abbruch- oder Stop-Befehl.
2. Setzen Sie niemals Workflowgruppen zurück, die auf dem physikalischen Modell ein Prozessmodul belegt haben und deren Funktionen noch aktiv sind! Führen Sie zuerst Schritt 1 aus, damit keine Funktion mehr auf dem Prozessmodul aktiv ist. Danach dürfen Sie die Workflowgruppe zurücksetzen.
3. Zum Verständnis: Machen Sie sich bewusst, dass Workflowknoten und Funktionen nicht das selbe sind. Beide haben einen eigenen Zustand die nichts miteinander zu tun haben!

 

Wichtige Workflowgruppenzustände

Inaktiv (Blau/Grau): 

Die Workflowgruppe ist noch nicht gestartet worden oder ist bereits abgearbeitet.

 

 Startend (Mattgrün): 

Die Workflowgruppe ist im startenden Zustand (A) und wartet auf die Freigabe des Prozessmoduls mit dem es sich verbinden will. Ursachen warum der Workflowgruppenknoten wartet:

• Meist ist das Prozessmodul bereits durch einen anderen Workflow belegt und deswegen wartet der Workflowgruppenknoten.
• Andere Workflowgruppen, die auf die selben Prozessmodultypen warten haben eine höhere Priorität. Der Priorisierungsalgorithmus sucht dabei nach allen Workflows deren Workflowgruppen ebenfalls warten und sortiert diese nach dem ältesten Workflow-Startdatum (Zeitpunkt wann der Workflow gestartet wurde). Die Workflowgruppe, deren Workflow das älteste Startdatum hat, darf als erstes das Prozessmodul belegen und wechselt dann in den Zustand "Läuft". Mit dem Kontext-Menü-Befehl "Höchste Priorität setzen" können Sie den Priorisierungsalgorithmus aushebeln und die Workflowgruppe zwingen das freie Prozessmodul für sich zu belegen.

 

 Läuft/Aktiv (Hellgrün):

Das Prozessmodul wurde durch die Workflowgruppe belegt (B). Mit dem Mauszeigertooltip kann man sich das verbundene Prozessmodul anzeigen lassen. Sobald eine Workflowgruppe aktiv geworden ist, startet sie ihre Kindelemente bzw. den Startknoten (Weißer Balken am oberen Rand).

 

Unterstatus

Eine Workflowgruppe besitzt zusätzlich noch einen „Unterstatus“ (F). Mit diesen Unterstati kann das Prozessverhalten in einen anderen Modus versetzt werden. Man erkennt dies daran, dass rechts oben das Symbol (F) erscheint:

 

Per Mauszeiger kann man sich den Unterstatus anzeigen lassen. Es gibt folgende Unterstati:

• "SMBC": Breche alle aktiven Workflowknoten ab und entlade zum Schluss den Workflow (Batchabbruch).
• "SMEM": Breche alle Materialbezugsknoten ab und fahre Anlage leer.
• "SMDTNC": Breche den Materialbezugsknoten ab transportiere das unfertige Zwischenprodukt zu einem Sonderziel und wiederhole die Komponenten bzw. Materialeinsatz.
• "SMID": Führe eine Zwischenentleerung / Abtransport durch weil maximale Kapazität der Maschine (Waage o.ä.) erreicht ist. Arbeite danach wieder den restlichenMaterialeinsatz ab.
• "SMLB", "SMLBEM": Das ist der letzte Batch. Es soll kein neuer Batch mehr gestartet werden. Der Auftrag soll beendet werden.
  Workflowgruppen werden in diese Modi versetzt
  • entweder durch Benutzereingriffe z.B. Dosierabbrüche, Materialmangequittierungen
  • oder durch eine speziell implementierte Logik.

Ein Unterstatus kann per Kontextmenü mit dem Befehl „Unterstatus zurücksetzen“ wieder zurückgesetzt werden.

Wichtige Workflowknotenzustände

 Inaktiv (Blau/Grau): 

Die Workflowknoten ist noch nicht gestartet worden oder ist bereits abgearbeitet. Dass ein Workflowknoten bereits abgearbeitet worden ist, erkennt man daran, dass rechts oben ein Häkchen gesetzt ist (D). Wenn Workflowknoten in Schleifen eingebaut werden, dann können Sie mehrmals ausgeführt werden. Wie oft ein Workflowknoten ausgeführt worden ist zeigt der Zähler rechts unten an.

 

 Startend (Mattgrün): 

Der Workflowknoten wurde gestartet und wartet (E) auf den "Läuft"-Zustand. Er wartet im Hintergrund bis eine bestimmte Startbedingung eingetreten ist. In diesem Zustand erscheint auch oft ein Hinweis/Alarm als Warndreieck rechts oben.

 

 Läuft/Aktiv (Hellgrün):

Der Workflowknoten ist erfolgreich gestartet worden (C) und ist aktiv.

Je nach Workflowklassenimplementierung funktionieren Workflowknoten auf unterschiedliche Weise:

• Delegierend: Wie bereits zuvor erwähnt, verbinden sich Workflowgruppen mit einem passenden Prozessmodul. Ein Prozessmodul ist die Repräsentation eines physikalisch existierenden Anlagenteils. Dieser Anlagenteil stellt Funktionen bereit (z.B. Dosieren, Entleeren, Mischen, Temperieren…) die letztendlich in der SPS ausgeführt werden. Ein Workflowknoten, der delegierend funktioniert, delegiert quasi seine Aufgabe an das physikalische Modell weiter und startet eine Funktion. Deswegen gibt es im Steuerungsdialog die Karteikarte „Methode“. Hier sind die Parameter aufgelistet, die beim Start an die SPS übertragen werden. Nachdem ein „Methoden“-Aufruf von Workflowknoten durchgeführt worden ist, macht ein Workflowknoten nichts mehr und wartet bis die Prozessfunktion abgearbeitet worden ist. Tritt während dieser Wartezeit (solange die Prozessfunktion aktiv ist) ein Alarm auf, bleibt der Workflowknoten grün. Die Prozessfunktion dagegen zeigt den Alarm in der Visualisierung bzw. Monitor-Visualisierungsbildern an.
• Selbstständig: Der Workflowknoten muss sich nicht mit einem Prozessmodul/Prozessfunktion verbinden sondern wickelt die Aufgabe selbstständig ab (z.B. Wartezeiten, UND-Gatter, ODER-Gatter). Hier wird dann auch die „Methoden“-Karteikarte ausgeblendet und es können nur „Konfigurations“-parameter eingegeben werden. Konfigurationsparameter beziehen sich daher nur auf den Workflowknoten selbst. Daher besitzen auch delegierende Workflowknoten Konfigurationsparameter, weil dadurch das Verhalten seiner Logik beeinflusst werden kann bevor er den Methodenaufruf auf dem Prozessmodul durchführt.

Weitere Informationen können Sie im Kapitel "Physikalisches Modell" nachlesen.

Workflow’s werden nach dem ereignisorientiertem Programmierparadigma abgearbeitet. Das bedeutet dass Workflowknoten andere Workflowknoten beim Eintritt eines bestimmten Zustands benachrichtigen. Damit ein Workflowknoten einen anderen benachrichtigen kann benötigt er sogenannte „Ereignispunkte“. Ereignispunkte können „Ereignis-Empfänger“ ("Eingangspunkte") (A) oder „Ereignis-Sender“ ("Ausgangspunkte") (B) sein. Beide werden miteinander im Workflow-Designer über Verbindungslinien, die Workflowkanten bezeichnet werden, miteinander verbunden:

 

Ereignis-Sender, die sich unterhalb des Workflowknotens befinden, senden das „Fertig/Ende“-Ereignis. Ereignis-Sender, die sich seitlich befinden, senden das Aktiv-Ereignis (C). Diese Ereignisse werden über die Workflowkanten weitergeleitet an die Ereignis-Empfänger (A). Falls Ereignis-Empfänger über mehrere Workflowkanten Signale empfangen, werden diese "UND"-behandelt. Das bedeutet, dass jedes Signal einmal gekommen sein muss, bevor der ein Workflowknoten gestartet wird. Nachdem ein Ereignis-Empfänger den Workflowknoten gestartet hat, setzt er alle seine Empfangszähler wieder zurück, damit im Falle einer Schleife alle Signale erneut gesendet werden müssen bevor er wieder gestartet werden kann. Möchte man stattdessen, dass ein Workflowknoten gestartet wird, wenn nur eines der Signale angekommen ist, dann muss man ein ODER-Gatter davor setzen (siehe im Bild oben).

Diese Signale kann man auch manuell per Kontextmenü auslösen, um bestimmte Workflowknoten zu starten oder Workflowgruppen zu deaktivieren..

Es gibt folgende Kommandos:

• "Ausgangs-Ereignis auslösen": Damit sendet der „Ereignis-Sender“ (B) sein Signal.
• "Läuft-Ereignis auslösen": Damit wird das Aktiv-Ereignis (C) gesendet.
• "Eingangs-Ereignisse zurücksetzen": Damit wird der Zähler der Empfangs-Ereignisse (A) zurückgesetzt.

Workflowknoten können auch ohne die Empfangs-Ereignisse gestartet werden per Kontextmenü („Start“-Kommando). Sie können auch zurückgesetzt werden per „Reset“-Kommando. Achtung: Wenn ein delegierender Workflowknoten gestartet worden ist, dann wartet er auf die Rückmeldung von der Prozessfunktion. Hier sollte kein Reset gemacht werden sondern per Steuerungsdialog die Prozessfunktion angezeigt werden und diese Abgebrochen oder Gestoppt werden!!!

 

Workflows entladen

Workflows entladen sich automatisch wenn der letzte Endeknoten seine Empfangsereignisse erhalten hat.

Falls Sie einen Workflow vorzeitig entladen möchten, müssen dafür sorgen, dass

1. sich alle Workflowknoten im  Inaktiven  Zustand befinden und
2. alle Workflowgruppen kein Prozessmodul belegen (ebenfalls Inaktiv).

Gehen Sie dann auf die letzten Workflowgruppen, deren Ausgangs-Events mit dem letzten Endeknoten des Workflows verbunden sind. Dort lösen Sie bitte das „Ausgangsevent“ aus. Danach entlädt sich der Workflow.

Wenn man möchte dass ein Workflowknoten nicht startet obwohl er alle seine Eingangsereignisse erhalten hatte, dann kann man per Kontextmenü den Befehl "Haltepunkt setzen" ausführen. 

Es erscheint das „STOP“-Symbol am Workflowknoten:

"Haltepunkt gesetzt".

 Umgekehrt können Sie den Haltepunkt wieder entfernen mit dem Kommando "Haltepunkt entfernen".