<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to ControllerStateChart</title><link>https://sourceforge.net/p/mrw/wiki/ControllerStateChart/</link><description>Recent changes to ControllerStateChart</description><atom:link href="https://sourceforge.net/p/mrw/wiki/ControllerStateChart/feed" rel="self"/><language>en</language><lastBuildDate>Wed, 22 Jan 2014 17:00:00 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/mrw/wiki/ControllerStateChart/feed" rel="self" type="application/rss+xml"/><item><title>ControllerStateChart modified by Dave Brondsema</title><link>https://sourceforge.net/p/mrw/wiki/ControllerStateChart/</link><description>&lt;div class="markdown_content"&gt;&lt;h1 id="modellvorgaben-fur-das-controller-zustandsautomaten"&gt;Modellvorgaben für das Controller-Zustandsautomaten&lt;/h1&gt;
&lt;h2 id="betriebszustande"&gt;Betriebszustände&lt;/h2&gt;
&lt;p&gt;Die Betriebszustände sind normale &lt;em&gt;States&lt;/em&gt;. Der Name muss ausgefüllt werden. &lt;/p&gt;
&lt;h2 id="zustandsubergange"&gt;Zustandsübergänge&lt;/h2&gt;
&lt;p&gt;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: &lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Übergang in den eigenen Betriebszustand zurück. &lt;/li&gt;
&lt;li&gt;Übergang in einen anderen Betriebsszustand. &lt;/li&gt;
&lt;li&gt;Übergang zu einer Entscheidung. &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Die zweite Form der Zustandsübergänge geht von Entscheidungen aus und können Betriebszustände oder weitere Entscheidungen haben. &lt;/p&gt;
&lt;h3 id="zustandsubergange-durch-can-kommandos"&gt;Zustandsübergänge durch CAN-Kommandos&lt;/h3&gt;
&lt;p&gt;Ein Zustandsübergang wird als normale &lt;em&gt;Transition&lt;/em&gt; modelliert. Diese muss folgende Modellelemente enthalten: &lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Name &lt;/li&gt;
&lt;li&gt;Ein &lt;em&gt;SignalEvent&lt;/em&gt; als &lt;em&gt;Trigger&lt;/em&gt;. Auch hier muss der Name ausgefüllt werden und muss mut den Transitionsnamen übereinstimmen. &lt;/li&gt;
&lt;li&gt;Eine &lt;em&gt;Activity&lt;/em&gt; als &lt;em&gt;Effect&lt;/em&gt;. Der Name dieser &lt;em&gt;Activity&lt;/em&gt; 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. &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Im Modell ergibt sich hier ein Pferdefuß: Hat man in der &lt;em&gt;Transition&lt;/em&gt; dem &lt;em&gt;Trigger&lt;/em&gt; einen Namen gegeben, ist er nicht identisch mit dem Namen des &lt;em&gt;Triggers&lt;/em&gt; im Containment-Baum. Im späteren Generatordurchlauf erscheint dann die folgende Fehlermeldung: &lt;/p&gt;
&lt;div class="codehilite"&gt;&lt;pre&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;workflow&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="mi"&gt;9630&lt;/span&gt; &lt;span class="n"&gt;ERROR&lt;/span&gt; &lt;span class="n"&gt;WorkflowRunner&lt;/span&gt;     &lt;span class="o"&gt;-&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;ERROR&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Ein&lt;/span&gt; &lt;span class="n"&gt;Ausl&lt;/span&gt;&lt;span class="err"&gt;ö&lt;/span&gt;&lt;span class="n"&gt;ser&lt;/span&gt; &lt;span class="n"&gt;muss&lt;/span&gt; &lt;span class="n"&gt;einen&lt;/span&gt; &lt;span class="n"&gt;Namen&lt;/span&gt; &lt;span class="n"&gt;haben&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Element&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;diagram&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;CAN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;Node&lt;/span&gt;&lt;span class="p"&gt;..&lt;/span&gt;&lt;span class="n"&gt;TEST&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt; &lt;span class="n"&gt;Reported&lt;/span&gt; &lt;span class="n"&gt;by&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;UNKNOWN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
 &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;workflow&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="mi"&gt;9630&lt;/span&gt; &lt;span class="n"&gt;ERROR&lt;/span&gt; &lt;span class="n"&gt;WorkflowRunner&lt;/span&gt;     &lt;span class="o"&gt;-&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;ERROR&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Ein&lt;/span&gt; &lt;span class="n"&gt;Ereignis&lt;/span&gt; &lt;span class="n"&gt;muss&lt;/span&gt; &lt;span class="n"&gt;den&lt;/span&gt; &lt;span class="n"&gt;gleichen&lt;/span&gt; &lt;span class="n"&gt;Namen&lt;/span&gt; &lt;span class="n"&gt;wie&lt;/span&gt; &lt;span class="n"&gt;sein&lt;/span&gt; &lt;span class="n"&gt;Ausl&lt;/span&gt;&lt;span class="err"&gt;ö&lt;/span&gt;&lt;span class="n"&gt;ser&lt;/span&gt; &lt;span class="n"&gt;haben&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Element&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;diagram&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;CAN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;Node&lt;/span&gt;&lt;span class="p"&gt;..&lt;/span&gt;&lt;span class="n"&gt;TEST&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt; &lt;span class="n"&gt;Reported&lt;/span&gt; &lt;span class="n"&gt;by&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;UNKNOWN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
 &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;workflow&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="mi"&gt;9631&lt;/span&gt; &lt;span class="n"&gt;ERROR&lt;/span&gt; &lt;span class="n"&gt;WorkflowRunner&lt;/span&gt;     &lt;span class="o"&gt;-&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;ERROR&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Ein&lt;/span&gt; &lt;span class="n"&gt;Ereignis&lt;/span&gt; &lt;span class="n"&gt;muss&lt;/span&gt; &lt;span class="n"&gt;den&lt;/span&gt; &lt;span class="n"&gt;gleichen&lt;/span&gt; &lt;span class="n"&gt;Namen&lt;/span&gt; &lt;span class="n"&gt;wie&lt;/span&gt; &lt;span class="n"&gt;seine&lt;/span&gt; &lt;span class="n"&gt;Transition&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Element&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;diagram&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;CAN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;Node&lt;/span&gt;&lt;span class="p"&gt;..&lt;/span&gt;&lt;span class="n"&gt;TEST&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt; &lt;span class="n"&gt;Reported&lt;/span&gt; &lt;span class="n"&gt;by&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;UNKNOWN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Diesen Umstand kann man beheben indem man die dazugehörige &lt;em&gt;Transition&lt;/em&gt; im Containment-Baum anzeigen lässt. Klappt man diese auf, erscheint der &lt;em&gt;Trigger&lt;/em&gt;. Ö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. &lt;/p&gt;
&lt;h3 id="zustandsubergange-von-entscheidungen-aus"&gt;Zustandsübergänge von Entscheidungen aus&lt;/h3&gt;
&lt;p&gt;Diese &lt;em&gt;Transitions&lt;/em&gt; müssen den &lt;em&gt;Guard&lt;/em&gt; modellieren, weil sie die Entscheidungsgrundlage für vorausgehende für auslösende &lt;em&gt;Choices&lt;/em&gt; darstellen. Diese &lt;em&gt;Guards&lt;/em&gt; können wie bei den &lt;em&gt;Transitions&lt;/em&gt;-Methoden mehrfach wiederverwendet werden. In eingeschränktem Maße sind im Namen auch Ausdrücke möglich, die im Generat in der Auswertung der &lt;em&gt;if&lt;/em&gt;-Bedingung Anwendung findet. So ist z.B. ein _ ! _ für &lt;em&gt;nicht&lt;/em&gt; möglich. Die &lt;em&gt;Guards&lt;/em&gt; werden als &lt;em&gt;Constraint&lt;/em&gt; angelegt. Werden sie nicht angelegt, erscheint im Generatorlauf folgende Fehlermeldung: &lt;/p&gt;
&lt;div class="codehilite"&gt;&lt;pre&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;workflow&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="mi"&gt;10284&lt;/span&gt; &lt;span class="n"&gt;ERROR&lt;/span&gt; &lt;span class="n"&gt;WorkflowRunner&lt;/span&gt;     &lt;span class="o"&gt;-&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;ERROR&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Ausgehende&lt;/span&gt; &lt;span class="n"&gt;Transitionen&lt;/span&gt; &lt;span class="n"&gt;von&lt;/span&gt; &lt;span class="n"&gt;Entscheidungen&lt;/span&gt; &lt;span class="n"&gt;m&lt;/span&gt;&lt;span class="err"&gt;ü&lt;/span&gt;&lt;span class="n"&gt;ssen&lt;/span&gt; &lt;span class="n"&gt;eine&lt;/span&gt; &lt;span class="n"&gt;Bedingung&lt;/span&gt; &lt;span class="n"&gt;haben&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Element&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;diagram&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;CAN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;Node&lt;/span&gt;&lt;span class="p"&gt;..;&lt;/span&gt; &lt;span class="n"&gt;Reported&lt;/span&gt; &lt;span class="n"&gt;by&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;UNKNOWN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Ein durch ein &lt;em&gt;Guard&lt;/em&gt; gewählter Zustandsübergang kann zusätzlich eine Methode aufrufen. In diesem Fall wird wie bei den CAN-Kommandos eine &lt;em&gt;Activity&lt;/em&gt; als &lt;em&gt;Effect&lt;/em&gt; modelliert. Der Name bestimmt den Methodennamen und es gelten die gleichen Rahmenbedingungen wie bei den CAN-Kommandos. &lt;/p&gt;
&lt;h2 id="entscheidungen"&gt;Entscheidungen&lt;/h2&gt;
&lt;p&gt;Entscheidungen werden als &lt;em&gt;Choice&lt;/em&gt; 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: &lt;/p&gt;
&lt;div class="codehilite"&gt;&lt;pre&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;workflow&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="mi"&gt;9208&lt;/span&gt; &lt;span class="n"&gt;ERROR&lt;/span&gt; &lt;span class="n"&gt;WorkflowRunner&lt;/span&gt;     &lt;span class="o"&gt;-&lt;/span&gt; &lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;ERROR&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Eine&lt;/span&gt; &lt;span class="n"&gt;Entscheidung&lt;/span&gt; &lt;span class="n"&gt;muss&lt;/span&gt; &lt;span class="n"&gt;benannt&lt;/span&gt; &lt;span class="n"&gt;sein&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;Element&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="n"&gt;Data&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;diagram&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="n"&gt;CAN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;Node&lt;/span&gt;&lt;span class="p"&gt;..;&lt;/span&gt; &lt;span class="n"&gt;Reported&lt;/span&gt; &lt;span class="n"&gt;by&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt; &lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;UNKNOWN&lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Ausgehende &lt;em&gt;Transitions&lt;/em&gt; müssen den &lt;em&gt;Guard&lt;/em&gt; als Entscheidungsgrundlage modelliert haben (siehe dort). Die Reihenfolge, in der die &lt;em&gt;Transitions&lt;/em&gt; durchgetestet werden, ist nicht definiert. Die erste &lt;em&gt;Transition&lt;/em&gt;, deren &lt;em&gt;Guard&lt;/em&gt; zutrifft, wird ausgeführt. Alle weiteren Tests entfallen. &lt;/p&gt;
&lt;h2 id="modellexport"&gt;Modellexport&lt;/h2&gt;
&lt;p&gt;Das Modell muss als EMF V2 exportiert werden. &lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Wed, 22 Jan 2014 17:00:00 -0000</pubDate><guid>https://sourceforge.net19647eaceef3d9c001b5efb04b6a8c42f5c9bb53</guid></item></channel></rss>