Simulator Protocol

coordinator simulator Component tN tN. tL After each transition tN = t + ta(), tL = t simulator Component tN tN. tL simulator Component tN tN. tL Coupled Model 1 nextTN 2. outTN 3 getOut 4 sendOut 5 applyDelt Simulation of coupled models-- Basic DEVS Simulation Cycle 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. 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. 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.

coordinator Atomic Model Atoimc3 coupledSimulator simulators.tellAll("initialize“) simulators.AskAll(“nextTN”) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) message coupledSimulator Atomic Model Atomic Model simulators.tellAll("initialize“) --- at start of simulation simulators.AskAll(“nextTN”) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) DEVS cycle DEVS Simulation Protocol as Implemented in DEVSJAVA coupling 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. genDevs. simulation. coordinator genDevs. simulation. coupledSimul ator 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.

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?

DTSSCoord Atomic Model Atoimc3 DTSSSim simulators.tellAll("initialize“) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) message DTSSSim Atomic Model Atomic Model simulators.tellAll("initialize“) --- at start of simulation simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) Situation one: DEVS Simulation Protocol Specialized to Discrete Time coupling 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. genDevs. simulation. DTSSCoord.ja va 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 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”) coordinator simulators.AskAll(“nextTN”) tN = compareAndFindTN(); simulators.tellAll("computeOut“,tN) simulators.tellAll("sendOut") simulators.tellAll("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.

Simulate hierarchical coupled model in fast mode Coordinator CoupledCoordinatorCoupledSimulator4 Atomic4 CoupledSimulator3 Atomic3 simulators.tellAll("initialize“) simulators.AskAll(“nextTN”) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) putMessage CoupledSimulator1CoupledSimulator2 Atomic1Atomic2 putMessage putMyMessage Coupled1 sendDownMessage

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 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, t ext (no earlier than the current clock and no later than tN), the sleeping thread is interrupted and If t ext == tN the output is generated. Then the input is processed by the confluent or external event transition function, depending on whether t ext coincides with tN or not. genDevs. simulation.realTi me atomicRTSimula tor tL =: t tN =: t + ta(s) When receive m if m!= null and t < tN, s :=  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) s =: s init tL =: 0 tN =: ta(s init ) m timeline inject at time t tN tL Legend: m = message s = state t = clock time tL = time of last event tN = time of next event If t == tN generate output (s) sleep for ta(s) 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: real 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.

Simulate coupled model in real time mode -- centralized way RTCentralCoord CoupledSimulator1 Atoimc1 CoupledSimulator3 Atoimc3 CoupledSimulator2 Atoimc2 simulators.tellAll("initialize“) simulators.AskAll(“nextTN”) myThread.sleep( nextTN – currentTime) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) putMessage

RTcoordinator Time synchronization Atomic Model Atoimc3 RTSimulator sideMessage RTSimulator Atomic Model Atomic Model sideMessage Flat Decentralized Distributed Real-Time Simulation with Activities Real World DEVS Activity outputFrom Activity

Simulate hierarchical coupled model in real time mode -- Centralized way RTCentraCoord CoupledCoordinatorCoupledSimulator4 Atomic4 CoupledSimulator3 Atomic3 putMessage simulators.tellAll("initialize“) simulators.AskAll(“nextTN”) myThread.sleep( nextTN – currentTime) simulators.tellAll("computeInputOutput“) simulators.tellAll("sendMessages") simulators.tellAll("DeltFunc“) CoupledSimulator1CoupledSimulator2 Atomic1Atomic2 putMessage putMyMessage Coupled1 sendDownMessage

Simulate hierarchical coupled model in real time mode -- decentralized way RTCoordinator RTCoupledCoordinatorCoupledRTSimulator4 Atomic4 CoupledRTSimulator3 Atomic3 putMessage CoupledRTSimulator1CoupledRTSimulator2 Atomic1Atomic2 putMessage putMyMessage Coupled1 sendDownMessage simulators.tellAll("initialize“) simulators.tellAll("simulate“) simulators.tellAll("stopSimulate")

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();//initialize the coordinator c.simulate(600);//provide the number of iterations to execute }