Review textuelle Syntax für Statecharts

rvh: hat während KLausuraufsicht mit verschiedenen Syntaxen herumgespielt

• Grundsätze:
  • allow anonymous states (States without names)
  • make common case compact
  • allow structuring (separate/external components)

Allgemeine Ideen

• Ideen:
  • {} um hierarchisch zu schachteln
  • Transitionen: WaitA -(A)-> final;
  • state modifier: zustand -(translabel)-> zustand;

• alternativen:
  • zustandsname
  • state zustandsname vs init zustandsname
  • init state zustandsname

• Initial Pseudostate ist eher init Modifier als echte Transition

• Nachteil von Transitionslabeln in Pfeilen: unübersichtlich bei langen Labeln

  AB-(laaaaaanges Label
        superlanges Label
      )->final;
  

• Quellzustände nur einmal assoziieren: zu unübersichtlich, Quellzustand ausfindig zu machen
• Mischen von Modifiern an verschiedenen Stellen zu gleichem Zustand problematisch. Syntaxchecker sollte das überprüfen und warnen
• schm: Sinnvoll feste Ordnungen zwischen Transitionen und States festzulegen? Unklar, möglicherweise nur als Konvention.
• Transitionsarten: über labels: z.B. A-(strong: I/O)->B
• Symbole: final state (()) oder ()statename, Strong abort: o-(R)-
• Claus: schöner mit expliziten Schlüsselwörtern als modifier

Beschlüsse

• Strukturierung
  • einfacher Mechanismus (textuelle Ersetzung)
  • Umbenennung nochmal extra

• {} für Verschachtelungen UND beliebigem Inhalt (wie im SyncChart?-MetaModell?)
  • Transitionen besser nicht darin enthalten (Analogie zum grafischen Editor)

• Inhalt z.T. ausserhalb definiert wie z.B. Modifier
  • Dann evtl auch Label ausserhalb "label" optional, sonst ist der Identifyer (Name) das Label
  • ID optional, aber trotzdem eindeutig! d.h. "keine Id ist auch EINE EINDEUTIGE ID", andernfalls ID mit leerem Label
  • Schlüsselwörter bei Uneindeutigkeit (z.B. einmal als final, einmal als init)
    • dann visuelle Warnung!!!
    • nicht überschreibbar (erste Deklaration bleibt gültig)

• Keine verschiedenen Klammern

• Transitionen
  • Transitionen als symbolische Abkürzungen für weak, strong, join
  • Symbole zusammenhängend als "Bild"
  • kein Modifier wie strong, join danach
  • with-Modifier + Label + erstmal ohne Semikolon (s.u.)
  • keine Schlüsselwörter für die symbolischen Abkürzungen
  • Quellzustände immer implizit als zuletzt deklarierter/genannter Zustand (wenn kein optionaler Quellzustand)
    • Aber nochmalige Referzierbarkeit des Quellzustands
    • Immer nur EIN Quellzustand, hier A: A --> B --> C

• Variablen
  • an Esterel V5 angelehnt, nach Möglichkeit "nichts neues ausdenken"
  • input, output, local, var, inputoutput

• Priorities
  • Reihenfolge durch textuelle Reihenfolge (analog zu XML)

• Whitespace
  • Sollte KEINE Rolle spielen

• Semikolon
  • Als Separator oder Terminator
  • Aber möglichst nur bei Uneindeutigkeit

• Actions
  • keine extra modifiyer (entry, exit, inside)
  • besser nur ein zusammenhängendes schlüsselwort
    • onenry I/O
    • oninner I/O
    • onexit I/O
    • suspend I/
  • Delay gehört zur Action
    • nicht zur Transition
    • nachträgliche semantische Überprüfung (oAW Check)
    • kein extra Schlüsselwort

• Regions mit Namen (?)

• Parallelität
  • Symbol wie in KIT
  • Eindeutige IDs pro State (nicht global eindeutige) (?)
  • Pfad-Notation mit Punkt (.)
  • In parallelen Regions, Namen eindeutig (?)

Examples

See the attachement Syntax.pdf in the minutes of this meeting for the examples below:

• fullstate

 state Statechart {
	init state fullstate{
		INTEGER localvariable
		onentry "blabla"
		oninner "blup"
		onexit "bla"
		}
}
	

• fulltransition

state SC {
	init state strt 
	>-> end with 1 myTrigger/myEffects
}
	

• thread

state Thread {
	init state disabled
	--> enabled with forked 
	state enabled { 
		state active{
			onentry "effect"
			init state preempted "stateLabel"
			o-> running with iclockAndSchedule
			running --> preempted with iclockAndNotSchedule
		}
	||
	init state inactive 
	--> final state semiEnd
	}
	>-> disabled with joined
}

• decos_monitor (See /<KIEL_DIR>/Examples/KIT/haf/decos_monitor)

state SCU_Monitor {
  init state power_off
    o-> operational with notRESET
    
    state operational{		
		init state active{			
			init state hold_mode{				
				init state init_hold
				o-> activehold with FAIL_BRAKE
				o-> brake with MS100
				
				state brake{
					init state brake_monitor
					o-> fail_act_brake with preFAIL_ACTUATORandEXCEED                                                        
					o-> final state acthold with EXCEED_AorEXCEED_B
					
					state fail_act_brake{ 
						onentry "EMERGENCE" 
					}
				} //brake
				brake >-> activehold
				state activehold{
					init state wait4motors
					o-> unspecified_failure with MS500
					o-> activehold_monitor with notEXCEED
					
					state activehold_monitor 
					o-> cond2 with EXCEED
					
					pseudo state cond2
					--> motor_fault_b with EXCEED_BandpreEXCEED_A
					--> motor_fault_a with EXCEED_AandpreEXCEED_B
					--> cs_breakage
					
					state cs_breakage{ 
						onentry "EMERGENCE" 
					}
					
					state motor_fault_b{ 
						onentry "EMERGENCE"  
					}
					
					state motor_fault_a{ 
						onentry "EMERGENCE"  
					}
					
					state unspecified_failure{ 
						onentry "EMERGENCE" 
					}
				} //activehold
			}//hold_mode
			o-> drive_hold with DRIVE
			
			drive_mode 
				//{ Inhalt von drive_mode } 
			o-> hold_mode with HOLD
		}//active
		--> emergency with EMERGENCY                                          
	}//operational
	o-> power_off with RESET
}//SCU_Monitor

• Von rvh leicht überarbeitet:

// DECOS Monitor example in experimental textual SyncChart syntax

// ===========================================
state SCU_Monitor 
{
  init state power_off
  o-> operational with notRESET
  
  extern state operational
  o-> power_off with RESET
}


// ===========================================
state operational 
{    
  extern init state active 
  --> emergency with EMERGENCY                                          
} 


// ===========================================
state active
{
  extern init state hold_mode 
  o-> drive_mode with DRIVE
  
  extern state drive_mode 
  o-> hold_mode with HOLD
}


// ===========================================
state hold_mode
{
  // -----------------------------
  init state init_hold
  o-> activehold with FAIL_BRAKE
  o-> brake with MS100
  
  // -----------------------------
  state brake 
  {
    init state brake_monitor
    o-> fail_act_brake with preFAIL_ACTUATORandEXCEED                                                      
    o-> final state acthold with EXCEED_AorEXCEED_B
    
    state fail_act_brake 
    { 
      onentry EMERGENCY
    }
  } // brake
  >-> activehold

  // -----------------------------
  state activehold 
  {
    init state wait4motors
    o-> unspecified_failure with MS500
    o-> activehold_monitor with notEXCEED
    
    state activehold_monitor 
    o-> cond2 with EXCEED
    
    cond state cond2
    --> motor_fault_b with EXCEED_BandpreEXCEED_A
    --> motor_fault_a with EXCEED_AandpreEXCEED_B
    --> cs_breakage
    
    state cs_breakage
    { 
      onentry EMERGENCY
    }
    
    state motor_fault_b 
    { 
      onentry EMERGENCY 
    }
    
    state motor_fault_a 
    { 
      onentry EMERGENCY 
    }
    
    state unspecified_failure 
    { 
      onentry EMERGENCY
    }
  } // activehold
}