ELEC 3442

Embedded
Systems
Mod-3: Specifications and Modeling
Motivation for considering
specs & models
Why considering specs and models in detail?

If something is wrong with the specs,

then it will be difficult to get the design right,
potentially wasting a lot of time.

Typically, we work with models of the system

under design (SUD)

What is a model anyway?

Model
Definition: A model is a simplification of another entity, which can be a
physical thing or another model. The model contains exactly those
characteristics and properties of the modeled entity that are relevant for a
given task. A model is minimal with respect to a task if it does not contain
any other characteristics than those relevant for the task.

[Jantsch, 2004]

Which features/requirements do we have for our models?

 Requirements for specification & modeling
techniques (1)
Hierarchy
Humans not capable to understand systems
containing more than ~5 objects.
Most actual systems require more objects
F Hierarchy (+ abstraction)

Behavioral hierarchy
Examples: states, processes, procedures
Structural hierarchy
Examples: processors, memories, printed circuit boards
proc
Processors include registers proc
proc
Multiplexers include gates
Requirements for specification &
modeling techniques (2)
• Component-based design
• Systems must be designed from components
• Must be “easy” to derive behavior from
behavior of subsystems
• e.g., add a GPS unit to a car

• Concurrency
• Human beings are not very good at understanding concurrent systems

• Synchronization and communication

• Cooperation
• Components share resources
Requirements for specification &
modeling techniques (3)
Timing behavior
Essential for embedded and cy-phy systems!
Standard theories in computer science model time only in a very
abstract way, e.g., big-O notation

“The lack of timing in the core abstraction (of computer science) is a flaw,
from the perspective of embedded software” [Lee, 2005]
Requirements for specification &
modeling techniques (4)
4 types of timing specs required

1. Measure elapsed time

Check, how much time has elapsed since last call

? execute
t

2. Means for delaying processes

t
Requirements for specification &
modeling techniques (5)
3. Possibility to specify timeouts
Stay in a certain state a maximum time

4. Methods for specifying deadlines

Not available or in separate control file

execute
t
Specification of ES (6): Support for designing
reactive systems
State-oriented behavior
Required for reactive systems;
classical automata insufficient
Event-handling
external or internal events
Exception-oriented behavior
Not acceptable to describe
exceptions for every state
Requirements for specification & modeling
techniques (7)
Presence of programming elements
Executability
Support for the design of large systems (F OO)
Domain-specific support: control, data, centralized, distributed
Readability
Portability and flexibility
Termination
Support for non-standard I/O devices
Non-functional properties: fault-tolerance, extendibility, weight, user friendliness
Support for the design of dependable systems
No obstacles for efficient implementation
Adequate model of computation
Models of Computation (MoCs)
Describe the mechanism assumed for performing computations
MoCs define:
- Components and organization of computations in such components
execution model for computations for each component
e.g. procedures, processes, functions, finite state machines
- Communication protocols describe methods for communication between
components
model for exchange of information between components
e.g. asynchronous message passing, rendezvous based communication
Dependence graph: Definition
Sequence
constraint
Nodes could be programs or simple
operations

Def.: A dependence graph is a directed graph G=(V,E) in which E Í

V ´ V is a relation.
If (v1, v2) Î E, then v1 is called an immediate predecessor of v2 and
v2 is called an immediate successor of v1.
Suppose E* is the transitive closure of E.
If (v1, v2) Î E*, then v1 is called a predecessor of v2 and v2 is called a
successor of v1.
Dependence graph: Timing information
Dependence graphs may contain additional information,
for example:
Timing information

Arrival time deadline

Dependence graph: I/O-information
Dependence graph: Shared resources
Dependence graph: Periodic schedules

A job is single execution of the dependence graph

Periodic dependence graphs are infinite

Dependence graph: Hierarchical task graphs

• Granularity
Models of communication
Two communication paradigms
Shared memory
Message passing
Shared memory
Comp-1 memory Comp-2

• Variables accessible to several components/tasks

• Model mostly restricted to local systems
• Critical section: segment of program code for which exclusive access
must be guaranteed
Message passing
Generally slower than shared memory based communication
Two types
Non-blocking/asynchronous message passing
Synchronous message passing / blocking communication, rendezvous based
communication
Non-blocking/asynchronous message passing
Channels can buffer the messages
Sender does not have to wait until message has arrived

… …
send () receive ()
… …

• Potential problem: buffer overflow

Blocking/synchronous message passing -
rendez-vous
Sender will wait until receiver has received message

… …
send () receive ()
… …

• No buffer overflow, but reduced performance

Organization of computations within the
components
§ Discrete event model
§ e.g., VHDL, SystemC, Verilog
queue

a 56
time
5 10 13 15 19
b 7 action
c 8 a:=5 b:=7 c:=8 a:=6 a:=9

§ Von Neumann model

Sequential execution, program memory etc.
Organization of computations within the
components
Finite state machines (FSMs)

Several machines communicate

Communicating finite state machines (CFSMs)
Organization of computations within the
components
§ Differential equations

¶2x
=b
¶t 2

§ Data flow
(models the flow of data in a distributed system)

§ Petri nets
(models synchronization in a distributed system)
Communication/ Shared Message passing
local computations memory Synchronous | Asynchronous
Undefined Plain text, use cases
components | (Message) sequence charts
Communicating finite StateCharts SDL
state machines
Data flow Scoreboarding +
Tomasulo Algorithm
Kahn networks,
(F Comp.Archict.) SDF
Petri nets C/E nets, P/T nets, …
Discrete event (DE) VHDL*, Only experimental systems, e.g.
model Verilog*, distributed DE in Ptolemy
SystemC*, …
Von Neumann C, C++, C, C++, Java with libraries
model Java CSP, ADA |
* Classification based on implementation with centralized data structures
Different MoCs have advantages in certain application areas
Mixed MoCs can help
Translate from on MoC to another
Non-von-Neumann models to von-Neumann models
Model-based design
Start with non-von-Neumann models
Why not just use von-Neumann computing (C,
Java, …) ?
Problems with von-Neumann Computing
Thread-based multiprocessing may access global variables
We know from the theory of operating systems that
access to global variables might lead to race conditions
to avoid these, we need to use mutual exclusion
mutual exclusion may lead to deadlocks
avoiding deadlocks is possible only if we accept performance penalties

Other problems …
Capturing the requirements as text
In the very early phases of some design project, only
descriptions of the system under design (SUD) in a
natural language such as English or Japanese exist.
Expectations for tools:
Machine-readable
Version management
Dependence analysis
Use cases
Use cases describe possible applications of
the SUD
Included in UML (Unified Modeling Language)
Example: Answering machine

§ Neither a precisely specified model of the computations nor a precisely

specified model of the communication
(Message) Sequence charts
Explicitly indicate exchange of information
One dimension (usually vertical dimension) reflects sequences
The other reflects distribution in space/communication components
Included in UML Component

Life-line

Asynchronous
message
Time/distance diagrams (TDDs)
• Variant of MSC
Distance

Time

No distinction between accidental overlap and synchronization

Time/distance diagrams as a special case
© www.opentrack.ch

Levi-TDD
Communicating FSMs
Describe state-oriented behavior at a more detailed level
Deterministic FSM
Only one state is active at a time
Synchronous FSM
Implicitly clocked
Other variants
Timed automata
StateCharts
Synchronous languages
SDL (specification and description language)
Timed automata
Timed automata = automata + models of time
The variables model the logical clocks in the system, that are initialized with zero
when the system is started, and then increase synchronously with the same rate
Clock constraints i.e. guards on edges are used to restrict the behavior of the
automaton
A transition represented by an edge can be taken when the clocks values satisfy
the guard labeled on the edge.
Clocks may be reset to zero when a transition is taken
Example: Answering machine
Ensures that transition takes
place

May take place, but does

not have to
StateCharts
Classical automata not useful for complex systems

F Introduction of hierarchy F StateCharts [Harel, 1987]

StateChart = the only unused combination of “flow“ or “state“

with “diagram“ or “chart“

Used here as a (prominent) example of a model of

computation based on shared memory communication
F appropriate only for local (non-distributed) systems
Introducing hierarchy

FSM will be in exactly

one of the substates of S
if S is active
(either in A or in B or ..)
Definitions
Current states of FSMs are also called active states
States which are not composed of other states are called basic
states
States containing other states are called super-states
Super-states S are called OR-super-states, if exactly one of the
sub-states of S is active whenever S is active

superstate

substates
Default state mechanism
Try to hide internal
structure from outside
world!
F Default state
Filled circle
indicates sub-state
entered whenever
super-state is entered.
Not a state by itself!
History mechanism

(behavior different from last slide)

For input m, S enters the state it was in before S was left

(can be A, B, C, D, or E).
If S is entered for the first time, the default mechanism applies.
Combining history and default state
mechanism

same meaning

History and default mechanisms

can be used hierarchically
 Uses of StateCharts Tools to Model R.Pi
Applications

Source URL : https://blogs.itemis.com/en/how-to-program-your-raspberry-pi-with-statechart-tools-in-5-minutes

 Direct Uses of the StateCharts for R.Pi.
Programs
Using the YAKINDU StateChart Tools as above, the importing function allows
the user to use the state machine as a type in programs, which can be used for
variables, operation parameters or even events.

For instance, the following shows possible uses of the led state machine type:
var machine : led
operation myOp(param : led)
in/out event : led

Source URL : https://blogs.itemis.com/en/how-to-program-your-raspberry-pi-with-statechart-tools-in-5-minutes

 Yet Another Example of StateCharts for
R.Pi. Programs
The following state-chart has 5 states – init, idle, red, green and blue. For each color,
there is an incoming event to switch between the idle and respective color like red.

Source URL : https://blogs.itemis.com/en/how-to-program-your-raspberry-pi-with-statechart-tools-in-5-minutes

Concurrency
Convenient ways of describing concurrency req.
AND-super-states: FSM is in all (immediate) sub-states of a
super-state
Entering and leaving AND-super-states

Line-monitoring and key-monitoring are entered and left, when service switch is
operated
Types of states
In StateCharts, states are either

basic states, or

AND-super-states, or

OR-super-states

Each substate can be considered a state machine per se

Form communicating FSMs

Timers
Since time needs to be modeled in embedded & cyber-physical
systems, timers need to be modeled
In StateCharts, special edges can be used for timeouts

If event a does not happen while the system is in the left

state for 20 ms, a timeout will take place
Using timers in an answering machine

.
General form of edge labels
event [condition] / reaction

Events:
Exist only until the next evaluation of the model
Can be either internally or externally generated
Conditions:
Refer to values of variables that keep their value until they are
reassigned
Reactions:
Can either be assignments for variables
or creation of events
Example:
on--key / on:=1
[on=1]
service-off [not in Lproc] / service:=0
Evaluation of StateCharts (1)
Pros (C):
Hierarchy allows arbitrary nesting of AND- and OR-super states
Large number of commercial simulation tools available
(StateMate, StateFlow, BetterState, ...)
Capable of translating into equivalent descritions in C or VHDL by
synthesis tools
Available “back-ends“ translate StateCharts into SW or HW
languages, thus enabling software or hardware implementations
Evaluation of StateCharts (2)
Cons (D):
Not useful for distributed applications
no description of non-functional behavior
no object-orientation
no description of structural hierarchy
generated programs may be inefficient
Data flow modeling
Definition: Data flow modeling is … “the process
of identifying, modeling and documenting how data move around an
information system.
Data flow modeling examines
processes (activities that transform data from one form to
another),
data stores (the holding areas for data),
external entities (what sends data into a system or receives data
from a system, and
data flows (routes by which data can flow)”.

[Wikipedia: Structured systems analysis and design method.

http://en.wikipedia.org/wiki/Structured Systems Analysis and Design Methodology, 2010
(formatting added)].
Data flow as a “natural” model of
applications
• Specified by a directed graph
• Nodes (called actors): computations, functional
• Arcs: communication channels
• Each process is decomposed into a sequence of firings
• Firing produces and consumes token
Example: Video on-demand system
Kahn process networks (KPN)
Each component is modeled as a program/task/process
Communication is by FIFOs; no overflow considered
F writes never have to wait (non-blocking)
F reads wait if FIFO is empty

§ Only one sender and one receiver per FIFO

Example
Properties of Kahn process
networks
Communication is only via channels
(no shared variables)

Mapping from ³1 input channel

to ³1 output channel possible

Channels transmit information within an

unpredictable but finite amount of time

In general, execution times are unknown

Key beauty of KPNs (1)
A process cannot check for available data before attempting a
read (wait)
if nonempty(p1) then read(p1)
else if nonempty(p2) then read(p2); p1 p2

§ A process cannot wait for data for >1 port at a time

read(p1|p2);

F Processes have to commit to wait for data from a

particular port
Key beauty of KPNs (2)
§ the order of reads does not depend on the arrival
time (but may depend on data)

§ Therefore, Kahn process networks are determinate

§ for a given input, the result will always the same,

regardless of the speed of the nodes
p1 p2

§ Many applications in embedded system design:

Any combination of fast and slow simulation &
hardware prototypes always gives the same result
Computational power and analyzability
It is a challenge to schedule KPNs
No assumption on the speed of the channels and nodes
KPNs are Turing-complete (anything which can be computed can
be computed by a KPN)
KPNs are computationally powerful, but difficult to analyze (e.g.
what’s the maximum buffer size?)
Number of processes is static (cannot change)
Synchronous Data Flow (SDF)
Impose restrictions on timing of nodes and channels
Easy scheduling and estimating buffer sizes
Less computationally powerful, but easier to analyze
Synchronous
= global clock controlling “firing” of nodes
Again using asynchronous message passing
= tasks do not have to wait until output is accepted
(Homogeneous-) SDF
Nodes are called actors
Actors are ready, if the necessary number of input tokens exists
and if enough buffer space at the output exists
Ready actors can fire (be executed)

1
1

§ Execution takes a fixed, known time

Actually, this is a case of homogeneous synchronous data
flow models (HSDF): # of tokens per firing the same
(Non-homogeneous-) SDF (1)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

A ready, can fire

(Non-homogeneous-) SDF (2)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

B ready, can fire

(Non-homogeneous-) SDF (3)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

A ready, can fire

(Non-homogeneous-) SDF (4)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

B ready, can fire

(Non-homogeneous-) SDF (5)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

B ready, can fire

(Non-homogeneous-) SDF (6)
In the general case, a number of tokens can be produced/
consumed per firing

2
3

1 period complete, A ready, can fire

Multi-rate models & balance equations
(one for each channel)
fire A { channel fire B {
… …
produce N consume M
… N FIFO M …
} }
f AN = fBM
number of tokens consumed

number of tokens produced number of firings per “iteration”

Decidable:
§ buffer memory requirements
§ deadlock
Schedulable statically
Parallel Scheduling of SDF Models
SDF is suitable for Many scheduling
automated mapping onto A optimization
parallel processors and problems can be
synthesis of parallel C formulated
circuits. B

Sequential Parallel
The expressiveness/analyzability conflict

[S. Stuijk, 2007]

Petri Nets
Introduced in 1962 by Carl Adam Petri in his PhD thesis
Focus on modeling causal dependencies
no global synchronization assumed (message passing only)
Key elements:
Conditions
Either met or not met
Events
May take place if certain conditions are met
Flow relation
Relates conditions and events
Conditions, events and the flow relation form a bipartite graph
(graph with two kinds of nodes)
Example:
Synchronization at single track rail
segment

“Preconditions“
Playing the “token game“
Playing the “token game“
Conflict for resource “track“
Condition/event nets
Def.: N=(C,E,F) is called a net, iff the following holds
1. C and E are disjoint sets
2. F Í (C ´ E) È (E ´ C); is binary relation,
(“flow relation“)
Pre- and post-sets
Def.: Let N be a net and let x Î (C È E).
•x := {y | y F x} is called the pre-set of x,
(or preconditions if x Î E)
x• := {y | x F y} is called the set of post-set of x,
(or postconditions if x Î E)
Example:

•x x x•
Loops and pure nets
Def.: Let (c,e) Î C ´ E. (c, e) is called a loop iff cFe Ù eFc.

Def.: Net N=(C,E,F) is called pure, if F does not contain any

loops.
Simple nets
Def.: A net is called simple if no two nodes
n1 and n2 have the same pre-set and post-set.
Example (not simple nets):

• Def.: Simple nets with no isolated elements meeting some

additional restrictions are called condition/event nets (C/E
nets)
Example: Dining philosophers problem
n>1 philosophers sitting at a round table
n forks
n plates with spaghetti
philosophers either thinking or eating
spaghetti (using left and right fork)

How to model conflict for forks?

2 forks
needed!
How to guarantee avoiding starvation?
Condition/event net model of the dining
philosophers problem
Let x Î {1..3}
tx: x is thinking
ex: x is eating
fx: fork x is available

Model quite clumsy

Difficult to extend to more
philosophers
Predicate/transition model of the dining
philosophers problem (1)
Let x be one of the philosophers
let l(x) be the left fork of x
let r(x) be the right fork of x Tokens: individuals
Semantics can be defined by
p2 replacing net by equivalent
p1 p3 condition/event net

f1
f2
f3
Predicate/transition model of the
dining philosophers problem (2)
p2
p1 p3

f1
f2
f3

Model can be extended to arbitrary

numbers of people
Evaluation
Pros:
Appropriate for distributed applications,
Well-known theory for formally proving properties
Initially a quite bizarre topic, but now accepted due to
increasing number of distributed applications
Cons (for the nets presented) :
problems with modeling timing
no programming elements
no hierarchy
Extensions:
Enormous amounts of efforts on removing limitations
Imperative (von-Neumann) model
The von-Neumann model reflects the principles
of operation of standard computers:
Sequential execution of instructions
(total order of instructions)

Bottom up process
Possible branches
Visibility of memory locations and addresses
Example languages
Machine languages (binary)
Assembly languages (mnemonics)
Imperative languages providing limited abstraction of
machine languages (C, C++, Java, ….)
Synchronous message passing: CSP
CSP (communicating sequential processes)[Hoare, 1985]
One of the first languages comprising mechanisms for inter-
process communications
Rendez-vous-based communication:
Example:
process A process B
.. ..
var a ... var b ...
a:=3; ...
c!a; -- output c?b; -- input
end end
Communication/synchronization
Communication libraries can add blocking or
non-blocking communication to von-Neumann languages
like C, C++, Java, …
 Java
Potential benefits:
§ Clean and safe language
§ Supports multi-threading (no OS required?)
§ Platform independence (relevant for telecommunications)

Problems:
§ Size of Java run-time libraries? Memory requirements
§ Access to special hardware features
§ Garbage collection time
§ Non-deterministic dispatcher
§ Performance problems
§ Checking of real-time constraints
Modeling levels
Start at different levels of abstraction
System level
Algorithmic level: just the algorithm
Processor/memory/switch (PMS) level
Instruction set architecture (ISA) level: function only
Transaction level modeling (TML): memory reads & writes
are just “transactions“ (not cycle accurate)
Register-transfer level: registers, muxes, adders, …
(cycle accurate, bit accurate)
Gate-level: gates
Layout level
Tradeoff between accuracy and simulation speed
Example: System level
Term not clearly defined
Here: denotes the entire cyber-physical/embedded system,
system into which information processing is embedded, and possibly
also the environment
Models may include mechanics + information processing.
May be difficult to find appropriate simulators.
Solutions: VHDL-AMS, SystemC or MATLAB
MATLAB+VHDL-AMS support partial differential equations
Challenge to model information processing parts of the system such
that the simulation model can be used for the synthesis of the
embedded system
Instruction set architecture (ISA)
Algorithms already compiled for the ISA
Model allows counting the executed # of instructions
Assembler (MIPS) Simulated semantics
and $1,$2,$3 Reg[1]:=Reg[2] Ù Reg[3]
or $1,$2,$3 Reg[1]:=Reg[2] Ú Reg[3]

Variations andi $1,$2,100 Reg[1]:=Reg[2] Ù 100

Simulating only of the effect of instructions

Transaction-level modeling: each read/write is one
transaction, instead of a set of signal assignments
Cycle-true simulations: exact number of cycles
Bit-true simulations: simulations using exactly the correct
number of bits
Models of computation
Communication/ Shared Message passing
local computations memory Synchronous | Asynchronous
Undefined Plain text, use cases
components | (Message) sequence charts
Communicating finite StateCharts SDL
state machines
Data flow Scoreboarding +
Tomasulo Algorithm
Kahn networks,
(F Comp.Archict.) SDF
Petri nets C/E nets, P/T nets, …
Discrete event (DE) VHDL*, Only experimental systems, e.g.
model Verilog*, distributed DE in Ptolemy
SystemC*, …
Von Neumann C, C++, C, C++, Java with libraries
model Java CSP, ADA |
* Classification based on implementation with centralized data structures
Classification
Expressiveness and succinctness indicate,
which systems can be modeled and how
compact they are;
Analyzability relates to the availability of
scheduling algorithms and the need for run-
time support;
Implementation efficiency is influenced by the
required scheduling policy and the code size.
Expressiveness of data flow models
Turing complete

Not Turing
complete
How to cope with MoC and language problems
in practice?
Transformations between models
Transformations between models are possible, e.g.
Frequent transformation into sequential code
Transformations between restricted Petri nets and SDF
Transformations between VHDL and C
Best to specify in the most convenient model
Transformations should be based on the precise description of the
semantics
Mixing models of computation: UML
(Focus on support of early design phases)

Communication/ Shared Message passing

local computations memory Synchronous | Asynchronous
Undefined use cases
components | sequence charts, timing diagrams
Communicating finite State
state machines diagrams
Data flow (Not useful) Data flow

Petri nets activity charts

Discrete event (DE) - -
model
Von Neumann model - -
UML for embedded systems?
Initially not designed for real-time
Initially lacking features:
Partitioning of software into tasks and processes
specifying timing
specification of hardware components
Projects on defining profiles for embedded/real-time systems
Schedulability, Performance and Timing Analysis
SysML (System Modeling Language)
UML Profile for SoC
Modeling and Analysis of Real-Time Embedded Systems
UML/SystemC, …
What‘s the bottom line?
The prevailing technique for writing embedded SW has inherent problems; some of the
difficulties of writing embedded SW are not resulting from design constraints, but from
the modeling
No ideal modeling technique
The choice of the technique depends on the application
Check code generation from non-imperative models
Tradeoff between the power of a modeling technique and its analyzability
May be necessary to combine modeling techniques
You may be forced, to use imperative models, but you can still implement, for example,
finite state machines or KPNs in Java or Python.