Transcript Simulation and Simulator - Arizona State University

Simulator Protocol
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.
1 nextTN
3 getOut
coordinator
Coupled
Model
Coupled Model Coordinator:
1.
Coordinator sends nextTN to
request tN from each of the
simulators.
2.
All the simulators reply with their
tNs in the outTN message to the
coordinator
3.
Coordinator sends to each
simulator a getOut message
containing the global tN (the
minimum of the tNs)
4.
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.
5.
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.
5 applyDelt
4 sendOut
simulator
tN
2. outTN
simulator
tN
simulator
tN
After each transition
tN = t + ta(), tL = t
Component
tN. tL
Component
tN. tL
Component
tN. tL
Each simulator reacts to the incoming message as follows:
•If it is imminent and its input message is empty, then it invokes its model’s inernal
transition function
•If it is imminent and its input message is not empty, it invokes its model’s confluence
transition function
•If is not imminent and its input message is not empty, it invokes its model’s external
transition function
•If is not imminent and its input message is empty then nothing happens.
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“) --- at start of simulation
coordinator
genDevs.
simulation.
coordinator
simulators.AskAll(“nextTN”)
simulators.tellAll("computeInputOutput
“)
simulators.tellAll("sendMessages")
simulators.tellAll("DeltFunc“)
DEVS cycle
message
message
coupledSimulator
coupledSimulator
Atomic
Atomic
Model
Model
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.
Atomic
Atoimc3
Model
genDevs.
simulation.
coupledSimul
ator
Simulating Large-Scale Models
Considering a coupled model that includes thousands of atomic
models
Two Situations:
1. In every cycle, almost every atomic model are imminent
2. 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?
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“) --- at start of simulation
DTSSCoord
genDevs.
simulation.
DTSSCoord.ja
va
simulators.tellAll("computeInputOutput
“)
simulators.tellAll("sendMessages")
simulators.tellAll("DeltFunc“)
message
message
DTSSSim
DTSSSim
Atomic
Atomic
Model
Model
coupling
DTSSSim
Atomic
Atoimc3
Model
genDevs.
simulation.
DTSSSim.jav
a
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
A new coordinator -- oneDCoord
coordinator
simulators.AskAll(“nextTN”)
tN = compareAndFindTN();
simulators.tellAll("computeOut“,tN)
simulators.tellAll("sendOut")
simulators.tellAll("ApplyDelt“,tN)
oneDCoord
tN = minSelTree.getMin()
imminents = minSelTree.getImms()
imminents.tellAll("computeOut“,tN)
imminents.tellAll("sendOut")
imminents = imminents.addAll(influencees)
imminents.tellAll("ApplyDelt“,tN)
imminents.tellAll(“sendTNUp”)
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.
Simulate hierarchical coupled model in fast mode
simulators.tellAll("initialize“)
Coordinator
simulators.AskAll(“nextTN”)
simulators.tellAll("computeInputOutput“)
simulators.tellAll("sendMessages")
simulators.tellAll("DeltFunc“)
putMessage
putMessage
CoupledCoordinatorputMessageCoupledSimulator3
Coupled1
sendDownMessage
Atomic3
putMyMessage
putMessage
CoupledSimulator1
Atomic1
CoupledSimulator2
Atomic2
CoupledSimulator4
Atomic4
Real-time Simulation
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
Real-time simulation
Why need real-time simulation?
Hardware-in-the-loop simulation
Human-in-the-loop simulation
PC
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
Real-Time Simulator/Executor
m
real timeline
tN
tL
inject at time t
s =: s init
If t == tN
tL =: 0
tN =: ta(sinit)
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.
generate output  (s)
sleep
for ta(s)
When receive m
if m!= null and t < tN,
s := ext (s,t-tN,m)
Legend:
This difference is seen in the following
alteration of the simulator:
• When first entering the state, s, the
simulator starts a thread to sleep for a
time ta(s)
if m!= null and t == tN,
m = message
s = state
t = clock time
tL = time of last event
tN = time of next event
s := con (s,t-tN,m)
if m= null and t == tN,
s =: int (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
tL =: t
tN =: t + ta(s)
genDevs.
simulation.realTi
me
atomicRTSimula
tor
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 modelcontinuity discussed later.
•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.
Simulate coupled model in real time mode
-- centralized way
simulators.tellAll("initialize“)
RTCentralCoord
simulators.AskAll(“nextTN”)
myThread.sleep( nextTN – currentTime)
simulators.tellAll("computeInputOutput“)
simulators.tellAll("sendMessages")
simulators.tellAll("DeltFunc“)
putMessage
putMessage
CoupledSimulator1putMessageCoupledSimulator2
Atoimc1
Atoimc2
CoupledSimulator3
Atoimc3
Flat Decentralized Distributed Real-Time
Simulation with Activities
RTcoordinator
Time
synchronization
sideMessage
RTSimulator
sideMessage
sideMessage
RTSimulator
Atomic
Atomic
Model
Model
RTSimulator
Atomic
Atoimc3
Model
Real
World
DEVS
Activity
outputFrom
Activity
Simulate hierarchical coupled model in real time mode
-- Centralized way
simulators.tellAll("initialize“)
RTCentraCoord
simulators.AskAll(“nextTN”)
myThread.sleep( nextTN – currentTime)
simulators.tellAll("computeInputOutput“)
simulators.tellAll("sendMessages")
simulators.tellAll("DeltFunc“)
putMessage
putMessage
CoupledCoordinatorputMessageCoupledSimulator3
Coupled1
sendDownMessage
Atomic3
putMyMessage
putMessage
CoupledSimulator1
Atomic1
CoupledSimulator2
Atomic2
CoupledSimulator4
Atomic4
Simulate hierarchical coupled model in real time mode
-- decentralized way
RTCoordinator
simulators.tellAll("initialize“)
simulators.tellAll("simulate“)
simulators.tellAll("stopSimulate")
putMessage
putMessage
RTCoupledCoordinator
CoupledRTSimulator3
putMessage
Coupled1
sendDownMessage
Atomic3
putMyMessage
putMessage
CoupledRTSimulator1
Atomic1
CoupledRTSimulator2
Atomic2
CoupledRTSimulator4
Atomic4
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);
c.initialize();
c.simulate(600);
}
//create a coordinator and pass the digraph model
//initialize the coordinator
//provide the number of iterations to execute