

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
The details of homework 3 for the ece575 class taught by moon ho hwang during the fall 2006 semester. Students are required to simulate devs models of an atomic crossroad controller and a monorail system using the odevs-c++ library. Diagrams and pseudo codes to help students understand the phase transition diagrams and the initial conditions of the systems.
Typology: Assignments
1 / 2
This page cannot be seen from the preview
Don't miss anything!


10/07/06 Sat.) By deriving from Atomic class of ODEVS-C++ library, develop a concrete class of a crossroad controller which has been introduced in homework #2. Simulate its behavior to make sure that the model satisfies the requirements addressed in homework#2.
10/12/06 Thu.) [System and its Modeling] Figure 1. illustrates the configuration of a monorail system which consists of 4 stations whose names are ST0, ST1, ST2 and ST3, respectively. Each station is an instance of Station class which is suppose to be a derived class of the atomic DEVS, and to have an input event set X = {?vehicle, ?pull} and an output event set Y ={!vehicle, !pull}. A state of the station is presented by the cross production of (1) phase {Empty (E), Loading (L), Sending (S), Pulling (P), Waiting (W), Collided (C)} and (2) the other variable nso {false(f), true(t)} which is indicating that “next station is occupied” if nso = t, or not, otherwise. Figure 1. Network Diagram of Monorail System Figure 2. illustrates the phase transition diagram of the station in which (1) a node represents a phase and its life time. (Notice that loading time of station 1 is longer than that of other stations s.t. lt=30 for ST1, lt=10 for STi, i{0,2,3}) (2) an arc shows its enabling pre-condition and post-condition of a state transition such that if ( ?input_event & pre-conditions of non-phase variables ) , ( post-conditions of non-phase variables & !output_event );
a. A solid arc such as L →S or S→ P, represents to update the next schedule; so when this is ext , make sure to call Atomic::x_RescheduleMe() ; b. A dashed arc such as L→ L or P→ P, indicates to preserve the next schedule. This arc should be ext and make sure NOT to call Atomic::x_RescheduleMe(). For the sake of simplicity, Figure 2 uses abbreviations of events such as ?p (for ?pull), ?v(? vehicle), !p (!pull) and !v(!vehicle). Since this diagram is to describe the atomic DEVS, each arc should be either one of ext or int with . For example, pseudo ODEVS-C++ codes for them may look like: int (){ if (phase = P && nso = f) nso= t; } and (){ if (phase=L) return PortValue();which is ODEVS-C+ +;}, while ext ( PortValue x){ if (phase = W & x.port = ?p) {nso = t; phase = S;} } Figure 2. Phase Transition Diagram of Station [Initial Condition] Since this system operates two vehicles, the initial states of stations are: phase = W for ST1 and ST3, phase = P for ST0 and ST2; nso = true for all stations. These initial variable settings are supposed to be done in the overriding void Station::init() function which is called when simulation run starts. [Testing Requirement] If your model is correct, every station’s phase moves around E→L→{S→W, or S}→P→E … forever, as well as it never get into C. It will be tested with observation time 1,000,000 seconds (11.57 days). For the fastest execution, we can change the mode before simulation run using SRTEngine::SetTimeScale(DBL_MAX) (or scale 0 command ), SRTEngine::SetAnimationFlag(false) (or tcmode none command) and SRTEngine::Set_dtmode(SRTEngine::P_NONE)(or tdmode none command). ===================================================================== Make two separating folders for each problem inside ODEVS/Examples folder. Zip each project folder into a zip file without object files (*.obj). Submit the zip file by Email.