Chapter 13 Simulation and Execution Protocols: Model Continuity

1
Chapter 13 Simulation and Execution Protocols
Model Continuity

• Review of Basic DEVS Simulation Protocol
• Hierarchical Simulators
• Distributed Simulators
• Real-time Simulators
• Real-time Executors
• Real-time Control
• Model Continuity across Design Stages and
  Simulators

2
Simulation of coupled models-- Basic DEVS
Simulation Cycle
For a coupled model with atomic model components,
a coordinator is assigned to it and
coupledSimulators are assigned to its components.
In the basic DEVS Simulation Protocol, the
coordinator is responsible for stepping
simulators through the cycle of activities shown.

• Coupled Model Coordinator
• Coordinator sends nextTN to request tN from each
  of the simulators.
• All the simulators reply with their tNs in the
  outTN message to the coordinator
• Coordinator sends to each simulator a getOut
  message containing the global tN (the minimum of
  the tNs)
• Each simulator checks if it is imminent (its tN
  global tN) and if so, returns the output of its
  model in a message to the coordinator in a
  sendOut message.
• Coordinator uses the coupling specification to
  distribute the outputs as accumulated messages
  back to the simulators in an applyDelt message to
  the simulators for those simulators not
  receiving any input, the messages sent are empty.
  

1 nextTN
Coupled Model
coordinator
After each transition tN t ta(), tL t

• Each simulator reacts to the incoming message as
  follows
• If it is imminent and its input message is empty,
  then it invokes its models inernal transition
  function
• If it is imminent and its input message is not
  empty, it invokes its models confluence
  transition function
• If is not imminent and its input message is not
  empty, it invokes its models external transition
  function
• If is not imminent and its input message is empty
  then nothing happens.

3
DEVS Simulation Protocol as Implemented in
DEVSJAVA
The DEVS Simulation Protocol implemented in
DEVSJAVA is basically the same as the one just
discussed. However, instead of having simulators
send their output messages to the coordinator,
they exchange messages when told to do so by the
coordinator. To be able to do so, they need the
coupling that is relevant to their attached
models this is transmitted to them in a a step,
called informCoupling, that is performed by the
coordinator at start up.
simulators.
tellAll
("initialize)
simulators.
tellAll
("initialize) --- at start of simulation
genDevs. simulation. coordinator
coordinator
simulators.
AskAll
(
nextTN
)
simulators.
AskAll
(
nextTN
)
simulators.
tellAll
("
computeInputOutput
)
simulators.
tellAll
("
computeInputOutput
)
simulators.
tellAll
("
sendMessages
")
simulators.
tellAll
("
sendMessages
")
DEVS cycle
simulators.
tellAll
("
DeltFunc
)
simulators.
tellAll
("
DeltFunc
)
message
message
coupledSimulator
coupledSimulator
coupledSimulator
Atomic Model
Atomic Model
Atomic Model
Atoimc3
genDevs. simulation. coupledSimulator
coupling
For example, the simulator for generator, g in
the coupled model gpt, knows that an output on
port out should be paired with port in in a
message to the simulator for processor p.
4
Simulating Large-Scale Models

• Considering a coupled model that includes
  thousands of atomic models
• Two Situations
• In every cycle, almost every atomic model are
  imminent
• In every cycle, only one or a few atomic models
  are imminent
• Question How to revise the standard protocol to
  improve the performance of the simulation for
  these two special situations?

5
Situation one DEVS Simulation Protocol
Specialized to Discrete Time
For an isolated discrete time coupled model the
DEVS simulation protocol can be simplified.
Assuming the time advance of each atomic model is
always the same, the global tN need not be
computed. Further, all components are always
imminent, leading to the cycle shown below. Note
This alternative only is more efficient that the
standard DEVS protocol under the conditions of
very high activity.
simulators.
tellAll
("initialize)
simulators.
tellAll
("initialize) --- at start of simulation
genDevs. simulation. DTSSCoord.java
DTSSCoord
simulators.
tellAll
("
computeInputOutput
)
simulators.
tellAll
("
computeInputOutput
)
simulators.
tellAll
("
sendMessages
")
simulators.
tellAll
("
sendMessages
")
simulators.
tellAll
("
DeltFunc
)
simulators.
tellAll
("
DeltFunc
)
message
message
DTSSSim
DTSSSim
DTSSSim
Atomic Model
Atomic Model
Atomic Model
Atoimc3
genDevs. simulation. DTSSSim.java
coupling
6
Situation two
Simulators.tellAll() or AskAll() is not efficient
if only one or a few models are imminent in every
cycle So, the idea is to get the imminents in
every simulation cycle and then only tell those
imminents to go through the cycle, instead of
telling all simulators to go through the cycle
7
A new coordinator -- oneDCoord
oneDCoord tN minSelTree.getMin() imminents
minSelTree.getImms() imminents.tellAll("computeOut
,tN) imminents.tellAll("sendOut") imminents
imminents.addAll(influencees) imminents.tellAll("A
pplyDelt,tN) imminents.tellAll(sendTNUp)
coordinator simulators.AskAll(nextTN) tN
compareAndFindTN() simulators.tellAll("computeOut
,tN) simulators.tellAll("sendOut") simulators.tel
lAll("ApplyDelt,tN)
minSelTree is a data structure which keeps track
of the smallest tN and the associated simulators.
The last step of the oneDCoord cycle
imminents.tellAll(sendTNUp) updates the
minSelTree data structure. The variable imminents
are the simulators which has smallest tN in this
cycle. The variable influencees are the
simulators which are receive messages from the
imminent models. Step imminents
imminents.addAll(influencees) updates the
imminents to include influencees --- these are
the simulators which need to execute ApplyDelt.
8
Simulate hierarchical coupled model in fast mode
9
Real-time Simulation
10
Time in Simulation
Time concepts in simulation Simulation time Wall
clock time
Two simulation types Fast simulation run
simulation as fast as possible Real-time
simulation -- time are synchronized with the
wall clock time
11
Real-time simulation
Why need real-time simulation? Hardware-in-the-loo
p simulation Human-in-the-loop simulation
Consider testing a hardware, saying a robot,
using simulation methods. The simulation running
on PC provides stimuli to the robot to test if
the robot moves as expected. Because it takes
time for the robot to move, the simulation
running on PC has to synchronize with this time.
In this case, the simulation running on PC need
to be real-time simulation
12
Real-Time Simulator/Executor
Execution in real time of an atomic model is
similar to its simulation in logical or abstract
time. The difference is that rather than being
controlled by an events list within the
coordinator, each simulator governs itself
according to the host processor system clock.
Thus passage of time in the model is identical to
that of a wall clock. This difference is seen in
the following alteration of the simulator
m
timeline
real
tN
tL
inject at time t
s s init tL 0 tN ta(sinit)
If t tN generate output ? (s)
sleep for ta(s)
When receive m if m! null and t ?ext (s,t-tN,m) if m! null and t tN, s
?con (s,t-tN,m) if m null and t tN, s
?int (s)

• When first entering the state, s, the simulator
  starts a thread to sleep for a time ta(s)
• If an external event is injected to the model at
  some time, text (no earlier than the current
  clock and no later than tN), the sleeping thread
  is interrupted and
• If text tN the output is generated.
• Then the input is processed by the confluent or
  external event transition function, depending on
  whether text coincides with tN or not.

Legend m message s state t clock time tL
time of last event tN time of next event
tL t tN t ta(s)
Real time execution of DEVS models is facilitated
by the separation of model from simulator which
allows the simulator to be changed out by one
that adheres to a real clock. The ease of
migration from simulation to execution enables a
design process called model-continuity discussed
later.
genDevs. simulation.realTime atomicRTSimulator
13
Simulate coupled model in real time mode--
centralized way
simulators.tellAll("initialize) simulators.AskAll
(nextTN) myThread.sleep( nextTN
currentTime) simulators.tellAll("computeInputOutpu
t) simulators.tellAll("sendMessages") simulators.
tellAll("DeltFunc)
RTCentralCoord
putMessage
putMessage
CoupledSimulator1
CoupledSimulator3
CoupledSimulator2
putMessage
Atoimc1
Atoimc3
Atoimc2
14
Flat Decentralized Distributed Real-Time
Simulation with Activities
RTcoordinator
Time synchronization
sideMessage
sideMessage
RTSimulator
RTSimulator
RTSimulator
sideMessage
Atomic Model
Atomic Model
Atomic Model
Atoimc3
Real World
DEVS Activity
outputFromActivity
15
Simulate hierarchical coupled model in real time
mode-- Centralized way
16
Simulate hierarchical coupled model in real time
mode-- decentralized way
17
Running a digraph model in Fast-mode
To run any digraph model in fast mode, provide a
main function in the class that uses a
coordinator, explicitly. Below is the code for
the digraph model HierarModel in package
GenDevsTest. public static void main(String
args) HierarModel hm new
HierarModel() coordinator c new
coordinator(hm) //create a coordinator and pass
the digraph model c.initialize() //initia
lize the coordinator c.simulate(600) //pr
ovide the number of iterations to execute
18
Intelligent, Real-time, Reactive Control
classes or situations
actions
categorize inputs
decision rules
actuators
sensors
sensory inputs
environment

• sensors provide information about environments
  state
• sensor inputs must be categorized into a
  relatively small number of classes or situations
• these classes become the inputs to decision rules
  that produce action commands
• the commands are carried out by actuators to
  effect the environment state

19
North/South and East/West flows are represented
by laneProcQ an extension of ProcQ
Simparc .laneProcQ
Real-time control Example Traffic control at an
intersection
Simparc .intersect Control

• Traffic lights alternate to control the flow of
  an intersection
• In fixed timed control, the times allocated to
  the red and green phases do not change
• In adaptive control, these times can be varied
  according to the state of the traffic flow
• One simple rule, is implemented which switches
  green to red color when it sees that all cars in
  the corresponding direction have cleared the
  intersection
• This requires that sensors provide the size of
  the waiting lines

light controller with information proceessing and
decision making capability
queue feedback to controller
An extension of SimpArc.ef has generators for the
two intersecting flows and measures the thruput
and average crossing time
Under conditions where NS traffic is heavier than
EW traffic, the adaptive approach allows NS
traffic to get through the intersection in less
time.(called priority) while still allowing EW
traffic through (called fairness)
Simparc .intersection
20
A Model Continuity Process
Control model
Hardware interface
System Requirement
System Modeling
Simulation-based Test
Deployment and Execution

• Model continuity refers to the ability of
  transition as much as possible of the model
  specification through different design stages.
• We clearly separate the control model from its
  external environment interface. Thus model
  continuity actually means the control models
  continuity
• This approach makes it easier to manage
  softwares complexity and maintain systems
  consistency.