Remote Control
Statecharts Kurzdefinition [Harel88]: Statecharts = state-diagrams + depth + orthogonality + broadcast communication
Statecharts Elements (1) Events (e.g. txt)» Typeless» no value (it exists or is absent)» no duration (it exists only one step ) Basic States (e.g. STANDBY) Composite States (containing a group of states)» AND-States (e.g. NORMAL) orthogonal, several concurrent regions» OR-States (e.g. SOUND) sequential
Default Transition (pseudo state) Statecharts Elements (2) Transition Label Syntax (e.g. p1/sm) event [ condition ] / action (all parts are optional, i.e. event, /action or [condition] are possible labels) External Events (e.g. txt) Internal Events (e.g. sm) Event Broadcasting (e.g. sm)
Statecharts Elements (3) Special Events Timeout-Event tm(n) (e.g. tm(1)) Hierarchy Sub-States (e.g. CHANNELS and SM are sub-states of NORMAL) Transition Priorities Transitions originating from parent states have a higher priority than transitions from sub-states (e.g. poweroff vs. txt).
Mögliche Änderungen/Verbesserungen (Remote Control) Wenn auf MUTE geschaltet wird, bleibt dieser Zustand unabhängig von TXT, P1 und P2 erhalten. TXT, P1, P2, MUTE/SOUND bleiben auch im ausgeschalteten Zustand erhalten. P1/P2 bleibt auch nach zwischenzeitlichem TXT ausgewählt. Während TXT kann zwischen P1 und P2 umgeschaltet werden.
Statecharts Elements (4) Special Events (Implicit Events) Entry-/Exit-Events Static Reactions differ from self transitions in that way that no exit- and entryactions will be performed Pseudo States: join, fork, branch (for decluttering charts) History-States: enter last visited state(s)» (Shallow) History: only current level of hierarchy» Deep History: all subsequent hierachical levels
Statecharts Elements (5) Logic Operators in Transition Labels NOT, AND, OR, () Action Lists in Transition Labels action1 ; action2 Action Language implementation language independent Generic data items with explicit types Root state (has no parent state)
Statecharts Semantics (1) General A statechart diagram specifies the states that a system can reside in and describes the event triggered flow of control, as the result of the system s reactions to events from the environment or internal events. Reactions include changing states, executing internal actions and sending events to other systems or subsystems.
Statecharts Semantics (2) Run, Configuration, Step The behavior of a system described with Statecharts is a set of possible runs, each representing the responses of the system to a sequence of external stimuli (i.e. events) generated by its environment. A run consists of a series of detailed snapshots of the system s situation; such a snapshot is called a configuration. The first in the sequence is the initial configuration, and each subsequent one is obtained from its predecessor by executing a step. If no further transition can be taken without at least one external stimulus (i.e. event) the system is said to be in a stable configuration.
Statechart Configurations Configuration: A maximum set of states (C) that the system can be simultaneously in. C = { STATE1, STATE2,..., STATEn} Examples (Remote Control): CINIT = { STANDBY } C1 = { ON, IMAGE, SOUND, NORMAL, MUTE, CHANNELS, SM, CH1, REST } C2 = { ON, IMAGE, SOUND, VIDEOTXT, SOUND.ON } CSTABLE = { ON, IMAGE, SOUND, VIDEOTXT, MUTE }
Synchronous Paradigm / Synchrony Hypothesis The fundamental idea of the synchronous approach: Reactive systems are idealized by assuming that a stimulation and reaction are simultaneous, i.e. reaction takes zero time. Abstracting physical time offers a number of advantages:» the granularity of time may be changed without affecting the sequence of events, and» System components can be composed and decomposed into subcomponents without changing the observable behavior. In practical terms, the synchrony hypothesis states that a system reacts fast enough to record all external events in the proper order. This property has to be checked during implementation!
Some additional consequences resulting from synchrony hypothesis Events have no duration. Generation of events doesn t consume time. Transitions don t consume time. The system is always in a unambiguous state. Events are instantaneous visible in the whole system. The system is always able to react to external and internal stimuli.
Consequences resulting from synchrony hypothesis A1 B1 C1 A/B B/D A and D/E A2 B2 C2 All three transitions occur at the same time, as are events A, B, D and E!
Paradoxon resulting from synchrony hypothesis A1 B1 not E1/E2 E2/E1 A2 B2 Possible Solution for this semantic problem: micro-steps (and macro-steps)
Micro-Step and Macro-Step Semantics Reactions to events, and changes occurred within a (micro-) step, can be sensed only after the step. Events live in the (micro-)step following their occurence, for one (micro-)step only. Calculations are based on the situation at the beginning of the (micro-)step. The execution of a micro-step changes the configuration of a statechart. Micro-steps don t consume time! Time passes in a macro-step only which occurs if no transition takes place, i.e. if the system is in a stable configuration (i.e. tick-events are only generated during macro-steps).
Tool Implementations of Statecharts STATEMATE (I-Logix) first and de-facto reference implementation of Harel statecharts Stateflow (Mathworks) special Matlab/Simulink package VisualState (IAR Systems) BetterState (Wind River) Several academic tools (AutoFocus, Ptolemy...) Renoir (Mentor Graphics) Design Entry tool for HDL-oriented designs Several UML tools (Rhapsody, Rose, Real-time Studio...) Statecharts are part of the UML standard
UML: (Main) Differences between STATEMATE Statecharts and UML Statecharts single event dispatching (run-to-completion) A dispatcher selects one event from an event queue. Events are processed one by one, each after the other. Accordingly, transitions are triggered by at most one event (i.e. no compound event triggers). a lower level transition has priority over a higher level one both asynchronous and synchronous communication (the caller must wait until the callee has finished) no broadcasting (communication has to be directed) no zero-time assumption (i.e. transitions consume time) actions are executed in the given order no negated trigger events deferred (pending) events
Themen für studentische Tätigkeiten (Projektseminar, Praktikum, Beleg, Diplom) Ansprechpartner: Wolfram Kattanek wolfram.kattanek@imms.de 03677/6783-55 Weitere Angebote unter: www.imms.de Modellierung und Implementierung von Steuer- und Regelfunktionen für den IMMS Concept Truck Statemate, Stateflow, ASCET-SD, CANoe, OSEK-Emulation, OSEK, Bildverarbeitung Automotive UML Bearbeitung von Fallstudien mit unterschiedlichen Tools und Methoden Portierung des Echtzeitbetriebssystems ecos und Entwicklung von Gerätetreibern CAN, Ethernet, PCB-Design, NET+ARM, NIOS, Board und Architektursimulator Applikations- und Middleware-Entwicklung für das Echtzeitbetriebssystem ecos UML, Java/JVM, Synthetic ecos Targets