Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi...

Week 6 Fall 2001 CS599 1

The STATEMATE Semantics of Statecharts

D. Harel and A. Naamand

Ahmad Alsawi 1-4

Bob Chen 5-8

Dapeng Xie 9-11


Introduction to STATEMATE

• STATEMATE is a system

• Statechart is a language (executable semantics)

• Initial version 10 years ago

• Simulation, dynamic tests, and code generation tools of STATEMATE since ‘87


STATEMATE Design Objectives

• Intended for “real engineers in real systems”

• Support different styles of modeling• Simple• Intuitive• Straightforward

– To enable fast simulation of models– To generate s/w and h/w codes


Basics (1)

• Used for modeling reactive systems• Based on structured analysis paradigm

– Activity-chart (hierarchical data-flow diagram)• Functional description: Activities, data elements, and signals

• Behavior desc.: Control-activities

• Functional semantics is dynamically noncommitting– Only activities can happen

– But no will happen, when, or why (behavior desc.)


Basic (2)

• Activity's statechart controls dynamics of – Sub activities– Data flow

• Activate and deactivate activities

• Write, read, and update data

• Send and sense signals

• Defining semantics of activity-chart is the core for how the tool works


Terminology

• State Types– OR-states have XOR substates– AND-states have AND substates– Basic state no substates

• Root: no parent state• Event e• Condition c• Action a


Syntax

• General syntax: e[c]/a

• All are optional

• Special e, c, and a– Start(P), st!(P) causes the activity P to start– Entered(S), en(S) is an event

• Events and conditions are closed under Boolean ops: or, and, and not


Timing of Conditions

• Actions associated with entrance to S are executed in the step in which S is entered

same as

• Actions on the transition leading into S

• Events are sensed one step after it happened– Ex(S) is sensed one step after S was existed


Static Reactions

• Event/action orthogonal AND-subset


Behavior

• Run: a set of possible behavior– A series of snapshots of system responses to

external environment stimuli

• Status: a snapshot of system situation

• Step: transition between two snapshots


Some Timing Issues

• An activity A is active within state S, means throughout S

• Schedule(a,d): d is time units• Timeout(e, d)• The execution takes zero time• The time between two consecutive steps is

excluded from step semantics (this is part of user control)


Principles in Defining the semantics

• Reactions to events, and changes occurred within a step, can be sensed only after the step

• Events live in the step following their occurrence, for one step only.

• Calculations are based on situation at the beginning of the step

• A maximal subset of nonconflicting transactions and SRs is always executed


Configuration

• A maximum set of states (C) that the system can be simultaneously in

• C contains root state• If C contains OR-state A, it must contain

only one of A’s substates• If C contains AND-state A, it must contain

all of A’s substates• The only states in C are the above no extra


Configuration (cont)

• Configurations are closed upward– system in state A, and it must be in A’s parent

state

• Basic configuration is a maximal set of basic states that the system can be in simultaneously


Basic configuration

Full configuration (all parents and root)


Racing

• X:=X+1; Y:=X*5; if …. else

• Semicolon means “do this in parallel” not “do this in sequence”

• In this case, no problematic racing– The value of x is changed at the end of step


Compound Transitions (CT)

• Execution of a setup must lead to a legal configuration

• Statechart cannot be in non basic state without being able to enter appropriate substate

• CT is full transitions, combined triggers and concatenated actions


ANDFork

Join


OR condition, selection and junction

condition


CT

• Initial CT

• Continuation CT

• Full CT is an initial CT and possibly several continuation CTs

• See figures


Full CT

Initial {t1, t2}

Continuation CT{t5, t3} and {t5, t4}


Part II by Bob Chen


DEALING WITH HISTORY

• Algorithm



• T1 to target state: B1 {t1, t2}

• T1 to target state: B2 {t1, t3}

• T1 to target state: B {t1, t4, t2}


DEALING WITH HISTORY• t1, t2 has priority

over t3• C1 is false t3 is

executed• C2 is false it is a

loop• STATEMATE

will detective a loop



• Clear history of S first, or

• Enter S via its history first

• Answer is latter• hc! = history clear


SCOPE OF TRANSITIONS

• CT is enabled– At the beginning of the step the system is in all the states

of its source set & if its trigger is true

• CT often pass different levels of statechart hierarchy

• tr – scope of a CT the lowest OR-state in the hierarchy of

states that is a proper common ancestor of all the sources and targets of tr

– Includes nonbasic states that are explicit sources or targets of transition arrow appearing in tr



• Scope of t1 is S• Implies exiting

states B2, B, A, C either C1 or C2



• Scope of t4 is U• Implies exiting

states W & V• Entering states V &

W• U is not exited


CONFLICTING TRANSITIONS

• Two CTs are in conflict– There are common state that would be exited if any one

of them were to be taken.


CONFLICT - example

• t1 & t2 are in conflict. – They would each

imply exiting state A.

• t4 is in conflict with all of t1, t2, t3.– When t4 is taken

system must be in U and also in one of its substates. Therefore t1, t4 cannot both be taken in the same step


TREATING CONFLICTS

Two kinds of conflict in the example– First trigger of both t1 & t2, nondeterminism

– Second conflict, t4 has priority over t1, t2, t3, no nondeterminism

– Priority: outside-in • tx and ty be conflict transition Sx & Sy be their scope

• If Sx = Sy then tx & ty has equal priority, nondeterministic


NONDETERMINISM

• STATEMATE simulation tool– Wait selection from user

– Dynamic, tries every possibility exhaustively

• Nondeterminism– Two or more conflicting CTs with same priority


BASIC STEP ALGORITHM

• Schematic description of the algorithm that executes a single step


BASIC STEP ALGORITHM• Stage 2 Compute the contents of the step• Stage 3 Execute the CTs and SRs• Example



• Possible Steps


Part III by Xie


Two Models of Time

1. Synchronous time model

2. Asynchronous time model


Two Models of Time (2)

Synchronous time model assumes that system executes a single step every time unit, reacting to all the external changes that occur in the one time unit that elapsed since the completion of the previous

step.



Asynchronous time model assumes that the system reacts whenever an external change occurs, allowing for several external changes to occur simultaneously and, most importantly, allowing several steps to take

place within a single point in time.



Superstep: a collection of steps which can take place within a single point in time.

In the simulation and dynamic test tools, various code generators, different circumstances, the way the

two models of time are reflected in the execution differs slightly among them.



This paper will concentrate on the way time is treated in the simulation tool.

The synchronous time model fits systems that are highly synchronous.

The asynchronous time model fits most kinds of asynchronous systems.



For example, in asynchronous time model, there are several different GO commands that let the user control the advance of time during simulation.



GO-REPEAT: the most important and frequently

used GO command.

GO-REPEAT does not increment the internal clock, so that many steps may be executed at the same

point in time.



GO-REPEAT command may result in an infinite loop.

There are several other GO commands, like GO-ADVANCE, GO-STEP, GO-NEXT, and GO-

EXTENDED.



Dynamic test toolsHardware Code generator:

1. RTL code style 2. Behavioral code style

Software code generator: 1. CPU clock time. 2. simulated clock.


Racing condition

Reason: Racing conditions arise when the value of an element is modified more than

once or is both modified and used at a single point in time.


Racing condition (2)

More precise description: A race situation is one in which, had we executed the enabled transitions in a different order, we might have obtained different

results in one or more of the data-items or conditions.


Racing condition (3)

Sample: t1: e / f

t2: f / x: =5

t3: f t4: /Y:=x+1


Multiple StatechartsDefination: Multiple statechart applies in all its aspects to

several statecharts running simultaneously, which in STATEMATE occurs when they represent activities that

happen to be active concurrently.


Multiple Statecharts (2)Multiple active statecharts are treated basically as orthogonal componets at the highest level of a single statechart, except

that when one of the statecharts becomes nonactive, the other charts continue to be active.


Multiple Statecharts (3)In the asynchronous time model, the steps in multiple statecharts are carried out in synchronization, just as they would have if they were

represented as orthogonal components of one big statechart.

In the synchronous time model, on the other hand, each chart may have its own clock, telling it when to execute a step.


Strength

• Nice formal (theoretical) approach

• Good marketing for STATEMATE!

• Covered the topic with many examples and figures

• Quite valuable appendix


Weakness

• Failed to reference the relationship it has with automata theory

• Lack of definitions for many terms

• Lack of definitions for figure notations


Relevance

• Statechart modeling addresses many issues related to embedded software:– environmental triggers and events– Concurrency– Timing– Non determinism– Etc

Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi...

Documents

Transcript of Week 6Fall 2001 CS5991 The STATEMATE Semantics of Statecharts D. Harel and A. Naamand Ahmad Alsawi...