Real-Time Systems,
COSC-4301-01,
Lecture 16
Stefan Andrei
7/29/2017
COSC-4301-01, Lecture 16
1
Reminder of the last lecture
Verification, debugging and optimization of
Linear RTL.
7/29/2017
COSC-4301-01, Lecture 16
2
Overview of This Lecture
Modechart – Chapter 6, section 6.8 of [Cheng;
2002]
7/29/2017
COSC-4301-01, Lecture 16
3
Modechart specification language
Although the RTL language is very capable specifying
properties of real-time systems, it can be tedious and
error-prone due to its textual nature.
To remedy this problem, a hierarchical graphical
representation language, called Modechart, was
introduced in [Jahanian, Mok; 1994].
The semantics of Modechart are given in terms of
RTL, allowing a translation of a Modechart
specification into corresponding RTL formulas.
7/29/2017
COSC-4301-01, Lecture 16
4
Modechart specification language (cont)
A Modechart specification represents a real-time
system as a collection of modes (boxes) and transitions
(edges between modes).
The collection of modes represents the (control) state
of the specified system and transitions represent the
control flow of the specified system [Stuart,
Brockmeyer, Mok, Jahanian; 2001].
A Modechart specification is called a modechart.
The model of computation used by Modechart
considers a computation as a sequence (partial
ordering) of sets of time-stamped event occurrences.
All event occurrences in the same set happen
simultaneously.
7/29/2017
COSC-4301-01, Lecture 16
5
Modes
A mode is drawn as a box and is considered
active from the time it is entered to the time
just before it is exited.
A mode is both active and inactive at the time
instant when the mode is exited or entered.
Three types of modes:
7/29/2017
Atomic
Serial
Parallel
COSC-4301-01, Lecture 16
6
Modechart 1 (Figure 6.4 of [Cheng; 2005],
page 172)
7/29/2017
COSC-4301-01, Lecture 16
7
Modechart 2 (Figure 6.5 of [Cheng; 2005],
page 173)
7/29/2017
COSC-4301-01, Lecture 16
8
Atomic mode
Has no internal structure and represents a
primitive control state of the system.
Atomic modes are basic buildings blocks of a
Modechart specification.
Examples:
7/29/2017
Figure 6.4: ModeA, ModeB, ModeC, ModeD, and
ModeE
Figure 6.5: ModeA, ModeC, ModeD, ModeE,
ModeF, and ModeG.
COSC-4301-01, Lecture 16
9
Serial mode
Contains one or more child modes connected
sequentially by transitions, and these child modes are
to be in series.
One of the child modes in a serial mode must be
active at any time when the serial mode is active.
One of these child modes is labeled as the initial
mode, and this is the mode that is entered when the
serial mode itself is entered.
Examples:
7/29/2017
Figure 6.4: Mode1 and Mode2. The initial mode of Mode1 is
ModeA.
Figure 6.5: Root and ModeB. The initial mode of ModeB is
ModeC.
COSC-4301-01, Lecture 16
10
Parallel mode
Contains zero or more unconnected child modes,
and these child modes are said to be in parallel.
All of these parallel modes in a parallel mode must
be active at any time when the parallel mode is
active.
A parallel mode with no child is equivalent to an
atomic mode.
Examples:
7/29/2017
Figure 6.4: Root.
Figure 6.5: Mode1 and Mode2
COSC-4301-01, Lecture 16
11
Transitions
A transition from one mode to another mode
represents the control flow between these modes,
and thus indicates a change in the control information
of the specified system.
Since the child modes of a parallel mode must be all
active, a transition can occur only between modes in
series.
Examples:
7/29/2017
Figure 6.4 (slide 7): ModeA ModeB, ModeB ModeA,
ModeC ModeD, ModeD ModeE.
Figure 6.5 (slide 8): ModeC ModeD, ModeC ModeG.
COSC-4301-01, Lecture 16
12
Transitions (cont)
Is an event that happens simultaneously (take zero
unit times):
“Ms Md” is the event of mode transition (Ms is the source
mode, Md is the destination mode);
“ M” is the event of entering the mode;
“M ” is the event of exiting the mode.
Every computation is a sequence of sets of mode
entry events, mode exit events, and/or transition
events.
Each transition may be labeled with a condition c1
… ck (each ci is a triggering or a timing condition).
7/29/2017
COSC-4301-01, Lecture 16
13
Triggering conditions
Is expressed as e1 … en, and each ei is either an event
or a predicate.
For a triggering condition to be satisfied, all events in it must
occur and all predicates in it must hold at the same time.
Each ei may be:
1.
2.
3.
4.
5.
6.
7.
Event “M” is satisfied when mode M is entered;
Event “M” is satisfied when mode M is exited;
Event “M1M2” is satisfied when the transition “M1M2” occurs;
Predicate “M==true” is satisfied if mode M is active;
Predicate “M==false” is satisfied if mode M is not active;
Mode list predicate “{(M1, …, MN})” is satisfied if any of the list’s
mode are active;
‘before’ list predicate “{(< M1, …, MN})” is satisfied if any of the list’s
mode are active and have been active for at least one time unit.
7/29/2017
COSC-4301-01, Lecture 16
14
Timing conditions
Is a delay and deadline pair of the form (r,d), where r
≤ d and both values are non-negative integers (it is
also called lower/upper bound condition).
(delay r) means (r, ∞).
(deadline d) means (0, d).
(alarm r) means (r, r).
Example: In Figure 6.4 (slide 7), the timing condition
(2, 5) from ModeA to ModeB indicates that this
transition can occur 2 times units after ModeA is
entered and within 5 time units after this mode is
entered.
7/29/2017
COSC-4301-01, Lecture 16
15
Verifying timing properties of
MODECHART specifications
To verify timing properties in a Modechart specification, we first
generate a computation graph [Jahanian, Stuart; 1988] from the
specification.
It represents all behaviors allowed by the Modechart specification.
To determine if a given timing property is satisfiable, we apply:
Specialized decision procedure [Jahanian, Stuart; 1988]
More general model-checking algorithms [Clarke, Emerson, Sistla;
1986]
To apply either of these approaches, the computation is viewed as
the model of the specified system and the timing property to be
checked is given as an RTL formula.
Then the decision procedure or model checker decides whether the
computation graph satisfies this property.
7/29/2017
COSC-4301-01, Lecture 16
16
System computations
Given a Modechart specification, we can generate a
computation tree showing all possible behaviors of
the system, that is, all possible sequences of sets of
event occurrences.
The computation tree is a rooted directed edge,
possibly of infinite size, with nodes labeled with
events and with events indicating causality.
A node in the computation tree is a point.
A point P pointed to by an edge represents the event
occurrence caused by the events along the path from
the root to P.
A point may be labeled with more than one event if
the events occur at the same time.
7/29/2017
COSC-4301-01, Lecture 16
17
Computation tree
Since there are timing constraints on transitions between
modes in the Modechart specification, the corresponding
computation tree is augmented with lower/upper bound
requirements on time separation (distance) between two
points along a path starting from the root.
A computation of a system is an assignment of time
values, consistent with the lower/upper bound
requirements, to the events along a path starting from
the root of the tree.
Given a pair of points Pa and Pb, with a < b, along a path
(so Pa appears earlier than Pb on the path), we
represent the lower bound separation requirement as Pa
+ I ≤ Pb and the upper bound separation requirement as
Pb ≤ Pa + I, where I is a non-negative number.
7/29/2017
COSC-4301-01, Lecture 16
18
Computation graph
Since the above computation tree augmented with
lower/upper bound requirements is usually infinite, a
need exists to generate a finite computation graph
that represents the computations of the system
[Jahanian, Stuart; 1988] so that model checking or
similar verification techniques can be applied to it.
To derive a finite computation graph from an infinite
computation tree, we use a point Pa that is already
generated instead of generating a new one Pb (as in
the case of the computation tree) if Pa is equivalent to
Pb except for their time stamps.
7/29/2017
COSC-4301-01, Lecture 16
19
Computation graph (cont)
An infinite number of equivalent points are grouped
together into an equivalence class.
Since a finite number of equivalence classes exist in
the point space of a Modechart specification, we can
obtain a finite computation graph by generating at
most one point from each equivalence class.
The computation graph construction algorithm starts
by generating the root point of the computation graph.
Then it checks every transition from the active modes
in the root point to see if it can be taken.
7/29/2017
COSC-4301-01, Lecture 16
20
Computation graph (cont)
A transition can occur if it satisfies its associated
triggering or timing condition.
If a transition can be taken, the algorithm generates
a new point (succesor to the root point) if it is not in
the same equivalence class as the root point, and
this transition and this new point are added to the
computation graph.
The above steps are repeated in a breadth-first
exploration for every new point until no new points
can be included in the computation graph.
7/29/2017
COSC-4301-01, Lecture 16
21
Summary
Modechart – Chapter 6, section 6.8 of [Cheng;
2002]
7/29/2017
COSC-4301-01, Lecture 16
22
Reading suggestions
Sections 6.8, 6.9 of [Cheng; 2002]
7/29/2017
COSC-4301-01, Lecture 16
23
Coming up next
Model checking of finite-state systems
Chapter 4 of [Cheng; 2002]
7/29/2017
COSC-4301-01, Lecture 16
24
Thank you for your attention!
Questions?
7/29/2017
COSC-4301-01, Lecture 16
25
© Copyright 2026 Paperzz