1. 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

2. 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

3. 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)

4. 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

5. 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

6. 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

7. 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.

8. 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.

9. 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.

10. 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

11. 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

12. 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

13. 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

14. 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?

15. Wait for loading
Wait for unloading

16. 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.

17. 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?

18. 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

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

20. 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?

21. 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.

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

23. 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.

24. 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

25. 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)

26. 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

27. 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

28. 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

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

30. Architecture Model
proc
coord
Job_in
Job_finished

31. 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

32. 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

33. Workflow Architecture Modelsin
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

34. 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

35. 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