T2A1: Important Thoughts

  1. Die Core SCCharts besitzen eine kleine Menge an möglichen Konstrukten.
    Es sind genug Konstrukte, um ordentlich und vollständig zu modelieren. 
    Gleichzeitig sind es so wenige, dass das Kompilieren noch gut machbar ist.
    Die Extended SCCharts besitzen zusätzliche Konstrukte, welche jedoch lediglich
    das Modelieren vereinfachen. Alle Extended Features lassen sich auf Core
    Features reduzieren bzw transformieren. Sie sind also lediglich syntaktischer
    Zucker.
  2. Durch das Normalisieren von Core Features werden diese noch weiter reduziert.
    Normalisierte SCCharts besitzen maximal fünf unterschiedliche Konstrukte.
    Durch diese Verringerung ist es noch leichter den SCChart zu kompilieren.
  3. Ein Basic Block ist ein Abschnitt im SCG bzw eine Zusammenfassung von
    SCG statements. Dieser Abschnitt hat die Besonderheit, dass er in einem
    Stück ohne Unterbrechung ausgeführt werden kann, wenn es keine parallelen
    Blöcke dazu gibt.
  4. Bei einem Schedule ist daraus zu achten, dass vor dem Lesen einer Variable
    alle relativen Schreibzugriffe auf diese Variable in diesem Makrotick
    abgeschlossen sind. Desweiteren müssen vor jedem relativen Schreibzugriff einer
    Variable alle absoluten Schreibzugriffe dieser Variable abgeschlossen sein.
    Es ergibt sich eine transitive Reihenfolge, welche in dem Model of Computation
    als "initialize - update - read" festgehalten ist.
    Desweiteren darf keine Variable in mehreren parallelen Abschnitten absolut
    beschrieben werden. In diesem Fall gibt es keine Reihenfolge. Der SCG bzw das
    SCChart ist ungültig modeliert und nicht kompilierbar.

T2A2: Tickets

done.

 

T2A3: Modeling with SCCharts

rail.sct

T2A4: SCCharts Transformation

  1. Der Count Delay von 5 Seconds bei der Transition von stop nach waiting ist kein Core Feature. Daher muss dieses in Core Features transformiert werden.
    Ich habe das gelöst, indem ich den Zustand stop zu einem Superstate erweitert habe, welcher die 5 Seconds abwartet, danach terminiert und dann in den Zustand waiting übergeht.
    Dafür benötigt der Superstate stop eine Zählervariable, welche bei Betreten auf 0 gesetzt wird. Bei jedem Vorkommen des Signals second wird eine Selbsttransition ausgeführt, welche den Zähler inkrementiert und nicht immediate ist. Dadurch ist sichergestellt, dass auch wirklich fünf Sekunden in dem Zustand stop verharrt wird. Sollte der Zähler den Wert 5 erreichen, wird die Transition zum finalen Zustand genommen, welche eine höhere Priorität als die Transition für den Zähler haben muss, um überhaupt in der Lage zu sein, den Superstate zu verlassen. Nach Terminierung des Superstates stop, wird sofort in den Zustand waiting gegangen. Der Rest entspricht bereits einem Core SCChart.
    rail.core.png
  2. rail.normalized.png
  3. rail.scg.png
    Es gibt einen möglichen Pfad in dem SCG, auf track während eines macroticks in unterschiedlichen parallelen Blöcken geschrieben wird.
    Sollte z.B. bereits beim Start contact0 bereits true sein, wird sowohl track = 20 als auch track = 60 geschrieben. Da diese parallel sind, gibt es einen write-write Konflikt. 
    Sollte sowohl contact0 als auch contact1 true sein, gibt es einen write-write Konflikt zwischen track = 0 und track = 60.
    Dieses nichtdeterministische Verhalten darf in einem SCG nicht vorkommen.

T2A5: Code Generation

Der bei mir generierte C-Code ist nicht zu viel zu gebrauchen. Dabei macht es einen Unterschied, ob man den SCG zu S und dann zu C generiert oder direkt aus dem SCT S und dann C Code generiert.

Bei der Generierung des C-Codes über den SCT wird eine FSM mit gotos in einer tick()-Funktion realisiert. Es fehlt dabei eine Main-Funktion, welche überhaupt diese tick-Funktion aufruft. Desweiteren sind zwar die Conditions erhalten geblieben, doch die Actions, wie z.B. das Setzen von track, ist vollkommen verschwunden.

Bei der Generierung des C-Codes über den SCG entsteht ebenfalls eine tick-Funtion. In dieser werden die Guards der Basic-Blocks berechnet und es sind sogar Aktionen vorhanden. So wird mehrfach track abhängig von unterschiedlichen Guards unterschiedlich gesetzt. Es fehlen jedoch einige Initialisierungen von Guards. So wird bei mir z.B. track = 60 gesetzt, wenn guard1 == true, doch wird guard1 nie initialisiert. Desweiteren fehlt auch hier eine Main-Funktion, welche die tick-Funktion aufruft und einige Guards setzt, wie z.B. guard4 = (PRE_guard3);

Der write-write-Konflikt zwischen der go und der platform Region lässt sich beseitigen, indem die go-Region entfernt wird und ein neuer initialer Zustand statt des waiting-Zustand erstellt wird, welcher immediate mit der Action track = 60 in den Zustand waiting geht.

Die nicht nebenläufigen w-w-Konflikte lassen sich durch das Einfügen von nicht immediate Transitionen unterbinden. Dadurch wird track nicht mehr 2x in einem tick geschrieben.

station-controller.sct, station-controller.scg.pngstation-controller.c

Tags: