Graphic Art

Simulation of Distributed Systems

Simulation of Distributed Systems
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Simulation of Distributed Systems Fernando G. Gonzalez School of Electrical Engineering and Computer Science University of Central Florida Orlando, Florida 32816 USA (407) 823-3987  Keywords: discrete event simulation, single threaded simulation, discrete event control Abstract This paper presents a methodology that allows the modeling of distributed discrete-event systems to be used in a single threaded simulation. It is assumed that the distributed system is described by a collection of independent models, one for each component. This is in contrast to distributed simulation where the simulation itself is distributed. We accomplish this task by including all of the models into a single program then simulating the communication network. This concept reduces modeling effort by reusing models, allows for trivial state initialization from hardware, and provides maximum fidelity over single model representation of distributed systems. In addition this paper describes the creation of a software tool that is designed to facilitate the modeling and simulation of distributed systems. INTRODUCTION This paper presents a methodology that allows the modeling of distributed discrete-event systems to be used in a single threaded simulation. It is assumed that the distributed system is described by a collection of independent models, one for each component. This is in contrast to distributed simulation where the simulation itself is distributed. The purpose of our work is in the intelligent control of distributed systems where simulation is used in decision making as a way to  predict to future performance under some control law in question. In addition this paper describes the creation of a software tool that is designed to facilitate the modeling, simulation and control of distributed systems. This tool is designed to perform the simulation and control of the discrete-event system using a distributed collection of models. It is assumed that the system, or actually the discrete-event aspects of the system, responds to message passing between the controller and the hardware. These large distributed man made systems include flexible manufacturing systems (FMS), intelligent vehicular traffic control systems, airport traffic control system and even military decision making systems as just a few examples. With manufacturing potentially benefiting the most, simulation and control of distributed manufacturing systems such as FMSs is the main focus of our work, see Gonzalez and Davis (2002) [17]. Our modeling methodology that is used in this tool is the focus of this  paper. Today, complex, discrete-event systems (DES) are  being proposed and designed to operate under advanced computer control. In most cases, the complexity of the overall planning and control problem for managing these systems necessitates the use of distributed  planning and control architectures. This leads to the situation where there is a hierarchy of computers used to control the system. The distributed controller is decomposed in some organized hierarchical fashion allowing communication among the individual controllers to perform their coordination. Many of these controllers are to be intelligent. They are to make decisions as part of there planning process. Today these decisions are made by testing several alternative strategies using simulation and weighing there outcome. In the intelligent control of manufacturing systems the decisions generally pertain to scheduling work on the machines. That is to decide which waiting  job gets the machine next. Optimizing this schedule can result in a more efficient operation and increased throughput for the manufacturing plant. The simulations used in this decision making process are generally used as part of a search algorithm, i.e. genetic algorithms (GA). Typically many simulation runs are  performed before the search algorithm can converge on a good solution. This process is typically performed on a single machine. The distributed intelligences come from the fact that each independent controller that exists in the hierarchy is making its own decisions. To accomplish this goal we need to model the distributed system and use this model to run simulations on a single computer. This presents a problem. Each independent controller has its own model. The complete system is therefore represented by a collection of independent models. The current simulation tools all require the use of a single model to represent the system. Currently the solution is to create a new model that represents the complete system to use for simulation. However this yields several problems. The model used for simulation is different from that used in  control. In addition to the effort of creating a complete model of the system, there is the potential that the simulation model does not represent the controller’s operation correctly. This may result in bad simulation data. Furthermore in operation the simulation must be initialized with the current state of the controller. This requires that each controller send its state to the simulation. The simulation program must use this collection of states to extract the necessary state information it needs for its own model. This is not an easy task. Finally since each controller uses intelligence and each one is in a different location within the control hierarchy, each will need its own model. Therefore this task of creating a new model and creating a translation function for the system state will be duplicated for each controller in the hierarchy. This represents an enormous effort and is one of the reasons for the lack of FMS today. The following research efforts are more closely related to our work. Peters et al. (1996) [21], Smith et al. (1994) [22] and Smith and Peters (1998) [23] have adapted Arena to control their experimental FMS. However, unlike the modeling approach to be discussed in this paper, their control architecture is limited to only one hierarchical level where a single supervisor, the cell controller, manages a set of subordinate processes. In their modification of Arena, they have included special events in order to facilitate message passing among the controllers. Narayanan et al. (1992) [20], Govindaraj et al. (1993) [10] and Bodner and Reveliotis (1997) [2] have also developed simulation tools that are capable of controlling a system. They claim that the typical approach to address the complexity of FMS control systems is a hierarchical decomposition. A widely used decomposition features tree layers, Strategic Decisions, Tactical Decisions and Operational Decisions, Arango and Prieto-Diaz (1991) [1] and Stecke (1985) [24]. In [2], [10] and [20], they claim that to handle lower level issues involving the real-time control, two additional layers are needed. The Structural and Equipment Control layers address issues such as deadlock avoidance. In their paper, hierarchical decomposition refers to the logical decomposition of the decision making process while we refer to it as the actual decomposition of the controller that yields a distributed controller. Bodner and Reveliotis (1997) [2] do not actually consider distributed systems. Incidentally they also claim that FMS exist but there are no controllers for them. cellmhspc1mhs pc1procpc1plcpc1cell pc2cellpc2mhs pc2procpc2plcpc3cellpc3mhs pc3procpc4cellpc4mhs pc4procpc4plcpc3plcfsmhs fsproc1 fsproc2fsplcfmscellfmssupSupervisor Emulator Control HierarchyPhysical Equiptmemtfscellmhsplc   Figure 1 . The hierarchical architecture used in our  physical emulator THE CONCEPTS Davis (1992) [3], Davis et al. (1993) [4], Davis et al. (1996 and 1997) [5] and [6], and Gonzalez and Davis (1999) [16] present a solution to this problem by developing a conceptual framework for the intelligent control of flexible manufacturing systems and other distributed DESs. Our conceptual framework can be summarized into three fundamental concepts: The Hierarchical Architecture, which provides a means for defining the component subsystems making up the overall system, The Simulation of Distributed Systems which allows the use of distributed models by taking into consideration the interactions among the distributed controllers into the simulation, and The Intelligent Cell Controller which provides the generic framework for the intelligent controller that is contained within each subsystem. The following section describes the first two concepts. The intelligent cell controller is not presented here since it is not within the scope of this paper. This section is described in Gonzalez (2003) [11] and Gonzalez and Davis (1999) [16]. The Hierarchical Architecture The concept of the Hierarchical Architecture was srcinally published in Tirpak et al. (1992) [25]. The architecture introduces the coordinated object, CO, as the basic element for modeling an FMS or other DESs. Each coordinated object represents a basic hierarchical element where intelligent control or integrated planning and control are to be addressed. In Figure 1 an example hierarchy is shown. Using this architecture gives rise to multi-resolutional control. At the top most level, the coordinated object's scope of control includes the most aggregate level of decision. The planning horizon may  be very long perhaps looking several months or years ahead. This coordinated object makes high level decisions. This object can be thought of as the CEO of a  company. The controller in the middle levels have a smaller planning horizon but are still making managerial type decision. These objects are similar to the middle level managers at a company. At the bottom most level, the controller has the smallest planning horizon and is limited to the most immediate concerns. These decisions are primarily concerned with the adjustment of machine-related parameters such as the speed of a certain motor or the amount of pressure at a valve. These objects are similar to the factory workers at a company. The Distributed Modeling Methodology The simulation of distributed systems discussed here is based on the distributed modeling methodology referred to as Hierarchical Object Oriented Programmable Logic Simulator (HOOPLS) in the following references, Davis et. al. (1997) [6], Davis et. al. (1993) [9] and Davis (1998) [7]. This methodology is based upon the belief that the interactions among the controllers must be considered by the simulation model in order to accurately model a system with a distributed control architecture. The single most important characteristic of the methodology and what separates it from other object-oriented simulation approaches is its attention to modeling the flow of messages among the controllers included within the architecture. By modeling the flow of messages, the methodology allows the simulation to accommodate distributed models. This has many advantages: 1.   The simulation is more accurate since it includes all of the communication among the distributed controllers. 2.   The simulation produces maximum fidelity since the same model is used for both simulation and control. 3.   The modeling effort is shared between control and simulation. They both share the same models. 4.   The control and simulation models necessarily employ the same state definition. This simplifies the task of initializing the simulation model to the current system-state. If the simulation and control models employ different state definitions, which is the usual case when one employs conventional simulation approaches, then one must translate the measured system variables into values for the state variable employed within the simulation model. See Gonzalez and Davis (1998) [15]. 5.   This methodology offers multi-resolutional modeling for simulation. Since the system models have a hierarchical organization, the simulation resolution can be dynamically selected by selecting the levels in the hierarchy to include models for. THE IMPLEMENTATION The best way to present our methodology is by describing the implementation of our simulation and control tool that is build around this methodology. The  basic process for implementing our tool consists of first implementing the simple single-model simulation as an object and then including all of these objects, each with its own model, into a single program. The coordinating function implements the multitasking operation by allocating the CPU to the objects in a manner that  provides a chronologically correct sequence of operations among the individual simulation objects. The coordination function does this by simulating the communication network and managing the flow of messages from one object to the next. The Modeling Framework Each individual simulation is represented as an object in C++. As with most simulation approaches, this approach is also event-driven, and an executive function manages the simulation by the sequential  processing of events. Two event lists are maintained where the events are stored waiting to be executed at the right time. Our simulation tool, like most simulation tools, consists of three basic parts. 1.   The executive function, which actually runs the simulation under the constraints of the system model. 2.   The data structures, which include the event list, (a list of events scheduled to occur in the future); the pending event list, (a list of events awaiting a response from the hardware to occur before they can be processed); and the resource list. 3.   The set of modeling elements that are used to  build the system model. The simulation object contains all of the data structures, the executive function and a pointer to the model and to the communication function. The  executive function manages the chronologically ordered event list, the pending event list, controls the processing of the events as they are removed from the event list, schedules new events to be placed upon the scheduled event or pending event list, and manages the allocation of resources. From here on we will refer to the event list as the scheduled event list to distinguish it from the  pending event list. The simulation object is called this way since it is the way simulation is typically written. Even though we use this object for control we still call it the simulation object. It is assumed that this object is used to control the system components. The System Model The system model for our tool plays the same role and is written in the same fashion and with the same modeling elements as a typical commercial simulation program such as Arena by Rockwell Software, Kelton (2001) [19]. This model must be  provided to the simulation object, see Figure 2, by the user and specifies the actions that must occur to execute the events as they occur. The object stores the address of this function so it can call it during execution. In our tool the system model may be implemented as a large case statement or switch statement with the event number being the variable in the switch. This makes the model be a list of events and is similar to the way models are built in Arena. Its primary advantage is that the sequence of logic is easy to see. An object oriented approach may be use as well depending on the user’s  preference. The model function simply executes a segment of code corresponding to the event number  passed to it. The execution of that segment of code models the actions taken by the system’s controller when that event actually occurs during the execution in the real system. Modeling elements are used to write these code segments. These modeling elements includes CREATE, DELAY, QUESEIZE, RELEASE, and SEIZE for the basic modeling, PENDING and INPUT for control, TALLY for gathering statistical data, and ERROR and TIMEOUT for error handling while in control mode. Other modeling elements such as DISPOSE, DECIDE and so on are not implemented  because they ca n be trivially implemented in C. The user must also supply the communication function to the executive object if running in control mode. This function handles all of the communications among the distributed controllers and the actual machines. The simulation object can run in two modes. In simulation mode, the system clock advances in discrete increments. Every time an event is pulled off of the scheduled event list, the time is incremented to the event’s time of occurrence. Figure 2.  The executive object. Note the circles represent objects, while the squares represent functions and the flat rectangles represent pointer variables  No hardware is present. The system is purely a software program. While in control mode, the system clock runs in real time. That is, the system clock is a real clock like the one on the wall. Time advances continuously. Events are pulled off of the scheduled event list when their event time occurs. Hardware may  be present. The pending event list is used to allow the hardware to determine when events occur. The events in this list do not have a time associated with them. They are in effect pending. The models are constructed using modeling elements. These elements acts as function call to the simulation engine and are used to  perform simulation activities such as scheduling events or allocating resources. For a complete list of modeling elements and more detail of there usage see Gonzalez and Davis (2002) [17] or Gonzalez and Davis (1997) [13]. The Implementation of the Coordinating Function  Now that we understand the basic structure of our tool we can present our methodology. The following section describes how the distributed simulation was implemented. This section discusses the features that are available in the simulation software that allow distributed simulation. These features along with a function that ties all of the distributed models together referred to as the coordinating function permit the simulation of distributed systems. Note, although the simulation is simulating a distributed system, the simulation itself is not distributed.   The executive function of the simulation object has certain features that allow it to simulate distributed systems. First each individual simulation is totally performed by the executive function of that object. Since the executive function, its data structures and the pointers to the user supplied functions are encapsulated into an abject one can include several instantiations of this object into a single program. This is needed since a distributed system is composed of several independent controllers. To build the simulation one simply includes all of these simulation objects into a single program without concern to duplicate variable and function names. Obviously all of the simulation objects can not run at the same time. Since there is only one thread in a program only one object can be executed at any given time. The next feature provides a method of multitasking that guarantees the correct sequential order of execution of events without wasting any CPU time. Because there are several instantiations of the simulation executive function within the distributed simulation, the executive functions cannot continuously cycle through the loop. The executive functions are modified so that it only cycles through the loop once every time it is called. It does not check the communication lines at the end of the cycle either since  by definition the system is in simulation mode. While there is communication between the simulation objects, they do not involve the network (there are no TCP/IP sockets involved). All communication is handled by the message relay. The coordination function does not execute any part of the simulation, it simply calls the executive function of the model that will execute the next event. At this time, the model’s own executive function cycles through the loop once, executing the events, before giving control back to the coordination function. Another feature addresses the manner in which messages enter the model. Instead of checking the communication lines every time the executive function reaches the end of a cycle, the lines are not checked at all. The coordination function manages the flow of messages, instead. Whenever a message is present, the coordination function calls the executive function of the appropriate submodel’s object and gives it the message. The executive function will then handle the message in the same way it previously handled messages when it was detecting their arrival. The last feature in the simulation software is the DELAY block. When a DELAY block is executed, in addition to scheduling a DELAY event onto the submodel’s scheduled event list, it also schedules an event into the coordination function’s global event list as well. This method maintains the global event list that the coordination function needs to know which object to give the processor to next. The modeler does not consider this event list when modeling a local delay. From the user’s point of view, the delay is modeled in the same way as if the model is not distributed. This is one of the nice features about this method. The user writes the model in the same fashion as is traditionally done with a single model. No need to do things differently to accommodate our method. The Coordination Function The coordination function consists of a global scheduled event list and the message relay. When a submodel’s object is being executed, the message relay receives all of the messages that are output by the simulation object that is currently running. The messages are stored into the rear of the message queue, which is used to implement the message relay. Once the simulation object finishes its execution, the coordination function removes the message that is at the front of the message queue and gives it to the recipient simulation object. Some other simulation object receives the message and executes the appropriate functions to handle the message. Further messages may  be generated by the execution of that event. These messages are also inserted into the rear of the message queue. Once control is given back to the coordination function, it removes the next message at the front of the message queue and recycles it though the loop. This is repeated until there are no more messages in the queue. If one wants to model a delay to represent the transmission time for the message, then this can be incorporated into the model by executing a delay event each time a message is received. As illustrated in Figure 3, the coordinating executive function starts its cycle and removes the next event, the one occurring in controller number 3, from the global event list. It gives the processor to simulation object number 3. Object 3 executes this event and as a result of its modeling logic it sends a message to object number 2. This message is sent to the message relay that simulates the network. Once object 3 completes its cycle it relinquishes control back to the coordinating function. The coordinating function then removes the next message from the message queue and delivers it to the proper recipient, object 2 in this case. Next object 2 receives this message and executes the appropriate event. In the execution of this event, controller number 2 schedules a new event onto its local event list and a copy is scheduled onto the global event list. At this  point, the event-execution cycle of the coordinating
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!