ControllerStateChart

Modellvorgaben für das Controller-Zustandsautomaten

Betriebszustände

Die Betriebszustände sind normale States. Der Name muss ausgefüllt werden.

Zustandsübergänge

Es gibt zwei unterschiedliche Formen von Zustandsübergängen. Die einen werden durch ein CAN-Kommando ausgelöst und müssen von einem Betriebszustand ausgehen. Diese können folgende Ziele aufweisen:

• Übergang in den eigenen Betriebszustand zurück.
• Übergang in einen anderen Betriebsszustand.
• Übergang zu einer Entscheidung.

Die zweite Form der Zustandsübergänge geht von Entscheidungen aus und können Betriebszustände oder weitere Entscheidungen haben.

Zustandsübergänge durch CAN-Kommandos

Ein Zustandsübergang wird als normale Transition modelliert. Diese muss folgende Modellelemente enthalten:

• Name
• Ein SignalEvent als Trigger. Auch hier muss der Name ausgefüllt werden und muss mut den Transitionsnamen übereinstimmen.
• Eine Activity als Effect. Der Name dieser Activity ist die Methode, die durch diesen Zustandsübergang aufgerufen wird. Diese Namen dürfen an unterschiedlichen Stellen gleich lauten. Es wird dann diese Methode eben von unterschiedlichen Stellen verwendet.

Im Modell ergibt sich hier ein Pferdefuß: Hat man in der Transition dem Trigger einen Namen gegeben, ist er nicht identisch mit dem Namen des Triggers im Containment-Baum. Im späteren Generatordurchlauf erscheint dann die folgende Fehlermeldung:

 [workflow] 9630 ERROR WorkflowRunner     - [ERROR]: Ein Auslöser muss einen Namen haben!(Element: Data.diagram.CAN-Node..TEST; Reported by: -UNKNOWN-)
 [workflow] 9630 ERROR WorkflowRunner     - [ERROR]: Ein Ereignis muss den gleichen Namen wie sein Auslöser haben!(Element: Data.diagram.CAN-Node..TEST; Reported by: -UNKNOWN-)
 [workflow] 9631 ERROR WorkflowRunner     - [ERROR]: Ein Ereignis muss den gleichen Namen wie seine Transition!(Element: Data.diagram.CAN-Node..TEST; Reported by: -UNKNOWN-)

Diesen Umstand kann man beheben indem man die dazugehörige Transition im Containment-Baum anzeigen lässt. Klappt man diese auf, erscheint der Trigger. Öffnet man die Spezifikation, ist dann der Name leer. Der Name muss dann mit dem CAN-Kommando identisch sein. Letztlich muss man den Namen also dreimal eintragen.

Zustandsübergänge von Entscheidungen aus

Diese Transitions müssen den Guard modellieren, weil sie die Entscheidungsgrundlage für vorausgehende für auslösende Choices darstellen. Diese Guards können wie bei den Transitions-Methoden mehrfach wiederverwendet werden. In eingeschränktem Maße sind im Namen auch Ausdrücke möglich, die im Generat in der Auswertung der if-Bedingung Anwendung findet. So ist z.B. ein _ ! _ für nicht möglich. Die Guards werden als Constraint angelegt. Werden sie nicht angelegt, erscheint im Generatorlauf folgende Fehlermeldung:

 [workflow] 10284 ERROR WorkflowRunner     - [ERROR]: Ausgehende Transitionen von Entscheidungen müssen eine Bedingung haben!(Element: Data.diagram.CAN-Node..; Reported by: -UNKNOWN-)

Ein durch ein Guard gewählter Zustandsübergang kann zusätzlich eine Methode aufrufen. In diesem Fall wird wie bei den CAN-Kommandos eine Activity als Effect modelliert. Der Name bestimmt den Methodennamen und es gelten die gleichen Rahmenbedingungen wie bei den CAN-Kommandos.

Entscheidungen

Entscheidungen werden als Choice modelliert. Der Name bestimmt den Methodennamen, der die Entscheidung berechnet. Dieser Methodenname muss im Gesamtmodell eindeutig sein, weil sonst im Modell "umhergesprungen" werden würde. Der Name muss ausgefüllt werden, sonst erscheint folgende Fehlermeldung:

 [workflow] 9208 ERROR WorkflowRunner     - [ERROR]: Eine Entscheidung muss benannt sein!(Element: Data.diagram.CAN-Node..; Reported by: -UNKNOWN-)

Ausgehende Transitions müssen den Guard als Entscheidungsgrundlage modelliert haben (siehe dort). Die Reihenfolge, in der die Transitions durchgetestet werden, ist nicht definiert. Die erste Transition, deren Guard zutrifft, wird ausgeführt. Alle weiteren Tests entfallen.

Modellexport

Das Modell muss als EMF V2 exportiert werden.