Continue the car washer example Experimental frame Outline Continue the car washer example Experimental frame A discussion about FSM, Petri-net, and DEVS Chapter 7 – simple architecture

Expectations After This Class Decide your project topic by Wednesday Know how DEVS works and what it can do Know how to build DEVS models and run simulation using DEVSJAVA Know how your project is going to be accomplished Your should be clear about the problem statement of your project You should be clear about the aim of your project You should have a picture of how you are going to implement your project

It is all about modeling Why DEVS ? It is all about modeling Software Engineering is not only about programming Software Engineering is not only about design Software Engineering is also about specification, analysis, and verification A specification different from UML MDA (Model Driven Architecture)

An carwash example To simplify the problem, let’s first assume the system will reject any incoming cars and trucks if it is busy. Test the model: addTestInput( ) Test the model: create a car generator and couple it to the carWashCenter Add random numbers in generators Create a truck generator and add to the system Consider the capacity of the car wash center -- Add queue Make the whole system generate an output Test the model without SimView

An carwash example (cont.) Multiple inputs (a bag of inputs) at the same time There is a problem in the previous model – it will lose cars if multiple cars come in at the same time! Analyze the system – add a transducer

Processor with queue illustrating how to process a bag of inputs (multiple concurrent events) accumulate the inputs on port “in” into the queue public class procQ extends proc{ protected Queue q; public procQ(String name, double procTime ){ super(name,procTime); q = new Queue(); } public void deltext(double e, message x){ Continue(e); if (phaseIs("passive")){ for (int i=0; i< x.size(); i++) if (messageOnPort(x, "in", i)){ q.add(x.getValOnPort("in", i)); } holdIn("busy", procTime); job = (entity)q.first(); else if (phaseIs("busy")){ for (int i=0; i< x.size();i++) if (messageOnPort(x, "in", i)) { entity jb = x.getValOnPort("in", i); q.add(jb); class Queue is a container with FIFO discipline this makes sure the processed job is the one at the front public void deltint( ){ q.remove(); if(!q.isEmpty()){ job = (entity)q.first(); holdIn("busy", procTime); } else passivate(); remove the job at the front that was just finished SimpArc .procQ GenCol .Queue

Experimental Frame The main model of interest – carWashCenter Although a model, such as the carWashCenter, can be tested in a standalone fashion, it really does not “come to life” until it is coupled with a module capable of providing it input and observing its output. An experimental frame module is a coupled model, which when coupled to a model, generates input external events, monitor its running, and processes its outputs.

Experimental Frame (cont.) The design of an experimental frame reflects the objectives one has in experimenting a model. Thus the same model may be coupled to different experimental frame modules, which observe it under different conditions. Test the average processing time (including waiting) of cars in a specific time period Test the reject rate of trucks under different incoming car rates Conversely, the same experimental frame module may be employed to experiment with different models under the same conditions. ---- This exemplifies model reuse due to loose coupling and modular design. Two major components of a experimental frame are generator and transducer.

Experimental Frame for Workflow Performance Measurement SimpArc ef Output lines may diverge to indicate the occurrence of simultaneous events. When genr sends out a job identifier on port “out”, it goes at the same clock time, both to the “ariv” port of transd and port “out” of ef, hence eventually to some processor model. Input lines may converge, i.e., two or more source ports connected to the same destination port, can occur. Bags represent the collection of inputs that arrive simultaneously at a component. Instances of the classes genr and transd are coupled together to form the experimental frame, ef. The input port “in” of ef is for receiving solved jobs which are sent to the “solved” input port of transd via the external input coupling. There are two output ports: “out”, which transmits job identifiers sent to it by genr, and 'result which transmits the performance measures computed by transd. External output couplings bring about both these transmissions. There are two internal couplings: the output port “out” of genr sends job identifiers to the 'ariv port of transd the output port “out” of transd which couples to the 'stop input port of genr.

Experimental Frame in a Flat Coupled Model SimpArc gpt gpt start start generator (genr) out processor (proc) stop in out out arrived transducer (transd) out solved

Experimental Frame/Model Modularity SimpArc efp efP ef start start start out out generator (genr) processor (proc) stop in out out arrived transducer (transd) out out solved solved

ef Hierarchical Coupled Model efP start Processor With Queue (procQ) SimpArc efp efP ef start start out Processor With Queue (procQ) in out out out solved

Discussion: A Comparison Among FSM, Petri-Net, and DEVS Consider the operations of a manufacturing cell comprising of one machine and one robot. machine outgoing buffer parts buffer robot

FSM #1 Part available & machine idle Loading Wait finished part finished & outgoing buffer available Part finished & not unloaded & outgoing buffer available finished Unloading An variable to record if part is finished or not. Will the robot keep unloading even there is no part there?

Wait for loading Wait for unloading

FSM #2 Wait Loading machine idle Unloading finished Part finished & not unloaded There is no way going from loading to unloading, or from unloading to loading. Assuming incoming parts and outgoing buffer are always available.

FSM #3 How to handle the case if there are two machines? machine idle Wait Loading machine idle Unloading finished Part finished & not unloaded Loading2 Unloading2 How to handle the case if there are two machines?

FSM #4 Wait Loading1 machine1 idle Unloading1 Finished & nothing to do finished Part1 finished & not unloaded X Loading2 Unloading2 Finished & machine 2 available Finished & machine 1 available There is no way going from loading to unloading, or from unloading to loading

FSM #4 M1L M2R M1L M2L M1R M2R L1 L2 U2 U1 L1 U2 U1 L2 M1R M2L

FSM #1 Part available & machine idle Loading Wait finished Part finished & not unloaded & outgoing buffer available finished Unloading The transitions are not triggered by events, but conditions – Is this a FSM? Another FSM model where all transitions are triggered by (discrete) events?

FSM #5 Wait Loading Unloading finished Part+ Machine- Part- Machine+ Buffer+ Part Finished- Buffer- Part Finished+ Unloading Part+ To illustrate the idea, let’s first assume the incoming and outgoing buffer’s capacity is 1. What happens when unloading and a part comes in? Note that the above diagram is not complete! How about more capacities, more machines? The state explosion problem.

Now Let’s look at the Petri Net Model Incoming parts Outgoing buffer More capacities? More Machines? More robots?

Compare FSM and Petri Net We define the state of a Petri Net model as the markings of the petri net (number of tokens in all places) If we compare the Petri net model with FSM #5, every state in the petri net model is directly corresponding to the state of the FSM, and every change of marking and firing of transition is directly corresponding to the event/transitions in the FSM model.

Compare FSM and Petri Net Compare to FSM, Petri net is more suitable to model concurrency and resource competition Compare to Petri Net, FSM is more straightforward to model and understand. Both have the scalability problem. FSM: state exposition Petri net: non-modular

A DEVS model of the robot Initialization() External transition functions Parts arrives Parts finished Buffer becomes available Internal transition functions Loading takes T_load time  machine busy … Unloading takes T_unload time  machine available … Output function Loading  part (to machine) & part reduce by one (to incoming buffer) Unloading  part unloaded (to machine) & finished part (to outgoing buffer)

A DEVS model of the robot Incoming Buffer Robot Machine How about two Machines? How about two robots? – not easy to handle – need a central controller – which might have a petri net model of the whole system, and schedule the robots Outgoing Buffer

Compare DEVS with FSM and Petri Net DEVS provides an operational model for simulation. It explicitly models the different components and their interactions. It forces the “time” concept to be integrated into the model The modular, system-oriented paradigm scales well.  For complex systems, DEVS (simulation) might be the only choice to analyze the system in design. Weakness of both FSM and Petri Net: scalability, and time

Discussion (cont.) FSM is good at modeling the relationship between different states and events Petri-net is good at modeling resources and parallel processing DEVS models system components and their interactions. It supports simulation and thus makes it possible to conduct arbitrary time-related performance analysis, which is not easy using FSM and Petri-net

Multiprocessor Architecture (chapter 7) Single Processor Multi-Server Pipeline Divide and Conquer Turn around time and throughput

Architecture Model proc coord Job_in Job_finished

Multiprocessor Architecture (chapter 7) SimpArc in DEVSJAVA – efp.java Single Processor – proc.java Multi-Server – multiServer.java Pipeline – pipeSimple.java Divide and Conquer – DandC3.java

Workflow Coordinator Models public class Coord extends proc{ public Coord(String name){ super(name,1); inports.add("setup"); inports.add("x"); outports.add("y"); public void initialize(){ passivate(); super.initialize();; } protected void add_procs(devs p){ //use devs for signature System.out.println("Default in Coord is being used"); }} Coord Atomic model I/O Behavior Description divide and conquer coordinator breaks incoming jobs into parts for processing and compiles the results into a final output pipeline coordinator routes incoming jobs through a series of processing states and outputs the results Multiserver coordinator routes incoming jobs for processing and collects the results for final output SimpArc divideCoord SimpArc pipeCoord divide Coord pipe Coord multi Server Coord SimpArc multiServerCoord

Workflow Architecture Models in out x y co p0 p1 p2 Architecture SimpArc DandC3 Coupled model Divide and conquer divide and conquer coordinator with processors Pipeline pipeline coordinator with processors Multiserver multiserver coordinator with processors SimpArc pipeLine SimpArc multiServer

Performance of Simple Workflow Architectures Processing Time Average Turnaround Time Maximum Throughput Simple Processor p 1/p Multiserver homogeneous p1,p2,p3 p1=p2 = p3 =p 3/thruput 1/p+1/p2+ 1/p3 3/p Pipeline p1 + p2 + p3 = p p1=p2 = p3=p/3 1/max{p1,p2,p3} Divide and Conquer p1=p2 = p3 =p/3 max{p1,p2,p3} p/3 SimpArc .proc SimpArc multiServer SimpArc pipeline SimpArc DandC3 Average turnaround time and maximum throughput as a function of processing time

Read chapter 7 Modeling Project Homework Send me your project statement by Wednesday Start to exercise DEVSJAVA and build your own models Next class: brief description (1-2 minutes) about your modeling project