Behaviour Model¶

Die zwei Funktionsbaustein-Basistypen in der Common Behaviour Model Bibliothek sind die flankengesteuerten (edge triggered) Funktionsbausteine und die zustandsgesteuerten (level controlled) Funktionsbausteine. Sie werden durch unterschiedliche Eingänge definiert: Flankengesteuerte Funktionsbausteine haben einen xExecute-Eingang, wohingegen zustandsgesteuerte Funktionsbausteine einen xEnable-Eingang haben.

Bitte betrachten sie die genauere Beschreibung von

• Edge Triggered Function Blocks

• Level Controlled Function Blocks

Die CODESYS Common Behaviour Model Library stellt eine vollständige Implementierung des PLCopen Behaviour Model` zur Verfügung. Der Funktionsbaustein BehaviourModel implementiert an zentraler Stelle alle Anforderungen des Behaviour Models. Ein wesentlicher Teil des Behaviour Models ist die Implementierung eines Zustandsmaschine gemäß dem folgenden Zustandsdiagramm.

Das Zustandsdiagramm implementiert durch den BehaviourModel Funktionsbaustein.

Starting:

⇒ StartAction läift, bis xComplete TRUE ist, xBusy ⇒ TRUE

Am Anfang wird SampleAction wahrscheinlich einmal ausgeführt.

Executing:

⇒ CyclicAction läuft, bis xComplete TRUE ist

Cleaning:

⇒ CleanupAction läuft

An seinem Ende wird ExitAction wahrscheinlich einmal ausgeführt.

Nach einer Ready Condition als Eingang, sind nur die Ausgangszustände

Done (xComplete is TRUE) oder Error (eErrorID ≠ ERROR.NO_ERROR) möglich.

Nach einer Error Condition als Eingang, ist nur der Ausgangszustand

Error (eErrorID ≠ ERROR.NO_ERROR) möglich.

Nach einer Abort Condition als Eingang, sind nur der Ausgangszustände

Aborted (xAbort is TRUE) oder Error (eErrorID ≠ ERROR.NO_ERROR) sind möglich.

(xBusy is still TRUE!)

Done:

xDone ⇒ TRUE, xBusy ⇒ FALSE

Error:

xError ⇒ TRUE, eErrorID ≠ ERROR.NO_ERROR, xBusy ⇒ FALSE

Aborted:

xAborted ⇒ TRUE, xBusy ⇒ FALSE

Resetting:

⇒ ResetAction läuft, bis xComplete TRUE ist

Danach:

- the outputs xDone, xError and xAborted will be set to FALSE.

- The output eErrorID will be set to ERROR.NO_ERROR.

Eine BehaviourModel Instanz hat unter anderem auch eine Eingangsvariable itfActionProvider des Typs IActionProvider. Ein Action Provider implementiert die Operationen, die in den verbunden Zuständen des Zustandsdiagramms ausgeführt werden sollen. Die Dekoration eines Action Providers bestimmt das Verhalten der Zustandsmaschine. Wenn ein Action Provider zum Beispiel die Anforderungen für ein LConC-Verhalten erfüllen soll, sollte er mit den Dekoratoren ILevelControlled und IHasContinuousBehaviour dekoriert sein. Die Zustandsmaschine des Behaviour Models zwingt den Action Provider zu einem angemessenen Verhalten. Im Beispiel ist es nur möglich, vom Zustand Executing über Cleaning zu den Zuständen Error oder Resetting überzugehen. Die Zustände Done und Aborted sind unerreichbar. Tatsächlich transformiert eine bestimmte Dekoration des Action Providers das Original-Zustandsdiagramm zu einem spezialisierten Zustandsdiagramm, das die spezifischen Anforderungen erfüllt.

Ein spezialisierten Zustandsdiagramm, transformiert durch die Dekoratoren ILevelControlled und IHasContinuousBehaviour ⇒ LConC

Zur Vereinfachung der Programmierung gibt es für jedes Behaviour Model eine angemessene Definition. Betrachten Sie die Definition der folgenden Schnittstellen:

ILCon, ILConTl, ILConTo, ILConTlTo, ILConC, ILConTlC, IETrig, IETrigTo, IETrigTlTo, IETrigA, IETrigATl, IETrigATo, IETrigATo, IETrigATlTo

Außerdem implementiert der Funktionsbaustein BehaviourModel die Schnittstellen IBehaviourModel Die Schnittstelle stellt alle Methoden und Properties zur Verfügung, die notwendig sind, um eine``BehaviourModel`` Instanz über Schnittstellenreferenz-Variablen zu steuern. Wenn mit einer Interface-Referenz-Variablen gearbeitet wird, sollte es möglich sein, genau zu entscheiden, wann die Zustandsmaschine aufgerufen wird. Hierfür haben die Methoden StartModel, AbortModel, ResetModel und GetModelState eine Paramteter xCommit. Wenn eine dieser Methoden mit dem Wert xCommit:=FALSE aufgerufen wird, wird dies nur eine Zustandsänderung vorbereiten. Die Zustandsmaschine wird dadurch nicht aufgerufen, die zugehörigen Aktionen werden nicht ausgeführt, um den Zustand zu ändern. Wenn eine dieser Methoden mit dem Wert xCommit:=TRUE aufgerufen wird, wird eine Zustandsänderung vorbereitet. Außerdem wird dadurch die Zustandsmaschine, und die notwendigen Aktionen ausgeführt, um den nächsten stabilen Zustand zu erreichen. Manchmal benötigt die Zustandsmaschine mehr als einen Aufruf, um von einem Zustand zum nächsten stabilen Zustand überzugehen. Zu diesem Zweck kann das Codebeispiel bei IBehaviourModel hilfreich sein, um ein Common Behaviour Model über eine Schnittstellenreferenz-Variable zu handeln.