Emulation as a Means of Designing an Inline-Control Olivier Boutin and Anne L’Anton Institut de Recherche en Communications et Cybern´etique de Nantes (IRCCyN) - UMR CNRS 6597 1 rue de la No¨e – BP 92101 44321 Nantes Cedex 03, France http://www.irccyn.ec-nantes.fr Email: {Olivier.Boutin, Anne.L-Anton}@irccyn.ec-nantes.fr
Bertrand Cottenceau Laboratoire d’Ing´enierie des Syst`emes Automatis´es (LISA) - EA 4014 62 avenue Notre Dame du Lac 49000 Angers, France http://www.istia.univ-angers.fr/LISA Email:
[email protected]
Abstract— This paper aims at defining what an emulation of a Production System (PS) is, from a theoretical point of vue, and how it can be used to facilitate the design and the testing of a control system dedicated to a given PS. What is meant by emulation is explained and compared to usual simulation of a PS. Then a modelling approach for control systems is presented. The communication between the control system and the system being controlled and the validation of the emulation system issues are discussed. A description of the advantages and the drawbacks of an emulationbased approach is tackled. Finally we present a case where a (max,+) control is tested thanks to emulation.
I. Introduction Due to competition stakes, producing is no longer enough for a manufacturing company. An optimal behaviour of the PS is expected nowadays, with criteria such as production rates, minimal Work In Progess (WIP), maximal use of the resources, etc. Hence the control of those systems so as to tend towards those goals. Consequently, it becomes possible to split the actual physical system from the control system. Design, implementation and maintenance of industrial control systems as self are important issues and require a broad knowledge of the structure and the behaviour of the controlled process. That is why it seems interesting to develop the final decisionmaking system right away, keeping the advantages of a simulation-based approach (replicability, low costs, . . . ). In the following section we define what an emulation is. In section III we outline how to make an emulation model and its corresponding control model. Then in section IV and V we discuss about the advantages and the drawbacks of such an approach based on emulation. Afterwards, we present a previous work in which a (max,+) formalism has been chosen in order to control a simple emulated flowshop. Finally we complete this paper by a conclusion. II. Definitions and principle The control system of an organization is the set of the elements enabling it to continuously strive towards
the aims it follows. Whereas the physical system is the operative part of a production system. The development and the setting of a control system require stable and replicable experimentation conditions. But experimentations carried out on real physical systems are almost unreplicable, whereas in a simulation environment, everything is exactly the same in each replication. In addition, many real processes are not freely available for experimentation purposes (such as a nuclear powerproduction plant). However, a great majority of the approaches used to obtain a simulation model does not focus on the clear distinction between the system being controlled on the one hand and the control system on the other hand [1]. Let us show the different ways to study these two separate systems. A. Different approaches By considering a real system and a simulated one and emphasizing the partition between the decision-making subsystem and the physical one [2], four entities can be outlined and can interact in four different ways, as depicted in Figure 1: 1) The traditionnal way to test control systems. These tests are carried out in the field after commissioning of the operating system. 2) Emulation, or “Soft commissioning”. A combination of a real control system and a simulated physical system. 3) “Reality In the Loop” (RIL) or “Hardware In the Loop” (HIL). A combination of a simulated control system and a real physical system. 4) Off-line simulation. Both the control and the physical systems are simulated. As for emulation, which is dealt with here, the approach called RIL (or HIL) is also meant for decision support. This is done through the introduction of real elements in the simulation [4]. Thus, to be more accurate, RIL is rather a mixing between combinations 3 and 4 in Figure 1.
Fig. 2. Fig. 1.
Simulation and emulation [7]
Approaches for control systems comparison [3]
III. Modelling B. Simulation and emulation Even though simulation and emulation are close to each other, they are not used for the same purpose. Simulation is the art and science of creating a representation of a process or system for the purpose of experimentation and evaluation [5]. In other words, building a model of a system (yet existing or not), carrying out experiments on it and getting results for decision making and implementation. It allows for having a broad view of the effects of local changes over a given PS. For instance, simulation can be used to size a production line. As for emulation, it is the process of exactly imitating a real system. Nevertheless, the model should be limited to the very operating system. The emulation model is to reproduce the response of the real system to sets of inputs [6]. Emulation is a first step towards the use of a control system on the field. Indeed, the partitioning of the decision-making and the physical subsystems allows for comparison of several control systems over the exact same physical system, represented by an emulation model. Thus it is possible to carry out tests on a control system with realistic and different load conditions for the operating system, before using it on the field. Errors in the control can be detected in a cost and time effective way thanks to the emulation of the operating system, compared to a test on a shop already in use. In short, instead of validating production plans (which is the goal of simulation), emulation is used to test, evaluate and validate control systems (see Figure 2). When using simulation, one aims at observing the evolution of the internal states of a model in a predefined situation, whereas emulation is used to reproduce the dynamic interaction of a system and its environment. As a result, the faster a simulation is executed, the larger the search space can be explored in the same length of time. Whereas an emulation is to be executed in realtime, so as to be able to communicate with its control system, which is meant to interact with a system evolving in reality [8].
A. Modelling approach The approach we are presenting here is directly inspired from [7] and [3] and consists of three main steps (see Figure 3): 1) First, completely model the system thanks to a simulation tool in order to clear up the design unknowns (sizing and setting) and possibly correct design mistakes [7]. 2) Split the production process from its control logic. Simulation is used to obtain a visual feedback of the controlled process. A connexion based on an internal communication protocol is realized. 3) Implement the control system and perform tests on the system composed of the external control module and the emulation of the physical system.
Fig. 3.
How to separate control systems from emulation models
Auinger et al. [3] consider vital the validation of a control system before implementation. For instance, it seems obvious that the control of a steam turbine in a nuclear power station needs to be verified so not to harm people working in the station, or living around it. By connecting the operating system to an external control module, it is easy to switch from one control system to another. Once the decision system is validated, implementation of the operating system can be taken into consideration.
This can be done sequentially, by “shifting” the control of an emulated component to a real one [9]. By definition, an emulated model must not have any decision rule. Thus, each location where a decision must be taken is turned into a synchronization point [1], [10]. It is possible to solve design problems (like deadlocks) late in the process by going back to simulation and running experiments quicker than real-time. B. Modelling primitives Simulation/emulation models must have realistic modelling elements, having the same characteristics as their real counterparts. It is recommanded to use suited modelling libraries [8]. In litterature we came across three modelling paradigms: • A vision developped within the Austrian company named Profactor1 [3] that states a modelling element can only be described by: – A structural vision. – A behavioural vision. – And a state vision. 2 • The IMS-NoE SIG4 works which lead to define modelling primitives that correspond to physical components [1], [6]: – Workstations. – Stocks. – And transport equipments. In order to cope with manufacturing systems complexity, it is possible to distinguish three types of transformations [11]: space moving, time passage and form alteration. They closely match the three corresponding basic elements: carrying, stocks and machines. • The MAST simulation tool [9], developped by the Rockwell Automation company. It distinguishes three types of modelling elements as well: – Production cells. – Conveyors. – And shuntings. It can be noticed that the chosen level of abstraction is usually the one of the computer numerical control machine [6]. C. Communication On the one hand, the control system is to convey decisions to the company resources in terms of tasks to be fulfilled. On the other hand, the operating system sends information about resources states as a feedback (see Figure 4). This communication is typically based on a classic client/server sketch [12].
Fig. 4.
Information exchanges between PS subsystems
Those two systems need to evolve at the same speed, which can be considered as synchronization [4]. When both the controller and the emulation are executed in the same simulation model, synchronization is obvious since all events are generated by the same scheduler. When the control system and the system being controlled are split (second and third steps of the approach given in section III-A), emulation is executed and communicates in real-time. This is the way most of the control systems operate [3], [8], [13], [7], [12], but it is not the only one. Synchronous communication between those two interoperable subsystems is also possible but is quite seldom. Each time they need to communicate, they synchronize with one another [1], thus preventing real-time execution. Standard messages are used to perform communication [4], [7], [1], [6]. It allows for evaluating and comparing different control systems, provided they all share the same standard. D. Emulation model validation The real and the simulated worlds are considered equivalent when the models and the real systems have the same input/output values. Studied systems which are too simple compared to the scale of the problem to solve lead to arguable results. Indeed, the very complexity of the systems to control is most of the time one of the problem to solve. Moreover, during the operating system modelling process, the choice of the simulation tools and the subjectivity of the modeller implies that some aspects of reality will not appear in the model3 [6]. In fact, reality can be modelled with mistakes. To cope with these problems, several persons shall cooperate within the design process of the global system (at least one for each subsystem). It is a matter of making communication and interaction easier. IV. Advantages The first advantage of using an emulated system is to be able to test one or more control systems without disrupting the real PS. A lot of time can be saved so, and the production in progress can run its course freely. The emulated system is used to avoid slack periods.
1 http://www.profactor.at/ 2 Intelligent Manufacturing System Network of Ecellence, Special Interest Group 4
3 For instance, a space dimension might be lost due to simulator possibilities
Moreover, critical cases for the real system can be tested with no risks, so as to verify the robustness and the safety of a control, that is to say, that the specifications are reached. Worst case scenarios or machine faults can be observed with no hazards. Future and advanced use cases (like raw material overload) can be examined as well, to verify that the production requirements for the products variability and the system output are validated. Heavy, long or difficult processes such as chemical treatments can also be avoided. Of course, for a non-existing PS, emulation allows for testing before implementation and coupling with the real physical system to be. The final control system is used and developped from the beginning. Any extra work due to implementation is thus avoided. Results are more reliable and implementation is safer [12]. Emulation is also a means of training operators and maintenance staff in a simpler and safer environment. It offers them the possibility to appropriate the data of a PS. Finally, the design framework of a control system based on the emulation of a production shop perfectly corresponds to the development of a remote control, which would be tested “on the spot”, with the great help of the simulation graphical representation. V. Drawbacks In most of simulation languages, the control system and the system being controlled are not really independent [4]. The dissociation between these two subsystems is sometimes not so obvious to do. Communication protocols (such as TCP/IP) used to broadcast messages between the control system and the emulation not always have guarantees upon transfer times. Orders may arrive too late or important state information may not arrive on time to be taken into account for short term decisions. So replicability of an emulation model is uncertain because the information flow is unpredictible and asynchronous (most of the time). This can be taken into acount, in a power plant control for example [14]. VI. An example This section aims at illustrating an application of the approach shown in section III-A. Zmax dioid algebra is used here as the control paradigm. This example is exctracted from [10]. A. Description This manufacturing system is a simple flow-shop production line, with three machines. There is only one kind of part and each part has to visit the three machines before it can leave the shop. Each machine has its own operating time and capacity, as shown on Figure 5. We assume there cannot be any lack of raw material. The aim of the command law is thus to reduce the WIP
Fig. 5.
An academic production line example
as much as possible, by delaying production orders, while keeping a maximal production rate. Indeed, WIP would generally have to wait in the machines upstream queues, depending on machines loads and their operating times, compared to the raw material arrival rate. B. Analysis phase We use the marked graph formalism to make a conceptual model of the PS. A marked graph is a Petri net where every place has one incoming arc, and one outgoing arc. This means that there can not be conflict, but there can be concurrency. A marked graph of the flow-shop is given in Figure 64 . M u
B 1
M
1
B
1 0
Fig. 6.
M
2
8 2
B
3
3
6
B 4
y
Petri net model of the PS
A marked graph can easily be retranscribed into a function in the Max in [[γ, δ]] dioid. For instance, we obtain the following transfer function for the global system5 : H = γ 0 δ 24 ⊕ (γ 4 δ 30 ⊕ γ 5 δ 34 ⊕ γ 8 δ 36 ) ⊗ (γ 5 δ 10 )∗ C. First phase A first simulation model, in which the decision system is a surrounding resource reprensenting a finite number of transporters, was developped and can be seen in Figure 7. The main problem of this system is that the minimal number of transporters (seized and released in the surrounding blocks) has to be found empirically, by running several simulations until an optimum is found. D. Second and third phases Using the Zmax algebra, the optimal control we are looking for here is bound to be found through calculation [10], [16], [17]. The only condition is to study a Zmax -compliant system, which is the case here6 . 4 see [10] for a more extensive explanation on how to obtain such a marked graph 5 thanks to the minmaxgd library for Scilab [15]. See [10] for the series of calculations 6 it mainly means that a PS must not contain shared resources
Fig. 7.
Fig. 8.
The whole PS
The physical system alone
After separating the control and the physical subsystems, we obtain the emulation model depicted in Figure 8 for the latter. The communication block aims at sending resources status to the control system and the synchronization block is used to synchronize production orders with raw material arrival. As long as there is less production orders than the quantity of raw material needed to produce one part, raw material is “waiting” outside of the production chain, so as not to be considered as WIP. The control logic is the greatest linear feedback for the PS here [18]. It can be inferred after a calculation based on operators defined in the residuation theory5 : F = ε ⊕ (γ 14 δ 2 ⊕ γ 15 δ 6 ⊕ γ 18 δ 8 ) ⊗ (γ 5 δ 10 )∗ After the computation of the control law, it is implemented in an external control program. When the emulation starts, it waits for the control program to connect to it. Then they both evolve in real-time and respond to messages and send them as soon as they can. E. Assessments This work showed an emulated PS could be controlled by a real external control system. This testing framework comprises all the aforementioned advantages of emulation (modifying flexibility, low costs,. . . ). Moreover, the implemented control system could be used on real physical system provided the same communication standard is used. VII. Conclusion We presented an approach for the development of a control system meant for an emulated PS. It is based on the clear distinction between the physical system emulation and the decisional system representation, in order
to evaluate and compare several control policies for the same production system. They can be different because of their hierarchical organizations (hierarchical, holonic or heterarchical [19]) or because of different parameter values in the priority rules at the decision points [12]. We also showed that a Zmax -based control system can be designed thanks to emulation. The separation between the decision-making and the physical subsystems complies with Le Moigne’s systemic approach [2] and leads to modifying flexibility and low cost testings and evaluations. The tools used to build and animate simulation and emulation models are the same, which contributes towards confusion. Emulation is distinguished by a permanent interaction with its environment. The goal of an emulation approach is the accurate reconstruction of those exchanges, the emulator becoming a part of a broader production system. On the contrary, a simulation runs on its own, apart for the setting phase and results reading [6]. A detached control system implies that is it no longer necessary to integrate decisions in the simulation. The model becomes less abstract and closer to reality.7 Nevertheless, the control design is all the more weighted, as a balance. In order to allow emulation, a simulation software must [7]: • •
•
have an open framework, allow for easy communication with other software or real systems, handle standard and user-defined communication protocols.
7 an accurate knowledge of the functioning parameters of the equipment is still compulsory
To conclude, we recommend to use emulation when a control system is to be tested on a critical part of a PS or when the latter does not allow to fully test a control system. References [1] T. Klein and A. Thomas, “Distributed supply chain control system simulation, application to a furniture manufacturer,” in International Conference on Information Systems, Logistics and Supply Chain, Lyon, France, May 2006. [2] J.-L. Le Moigne, La mod´ elisation des syst` emes complexes. Dunod, 1990. [3] F. Auinger, M. Vorderwinkler, and G. Buchtela, “Interface Driven Domain-Independent Modeling Architecture for ”SoftCommissioning” and ”Reality in the Loop”,” in Proceedings of the 31st Winter Simulation Conference, WSC’99, P. A. Farrington, H. B. Nembhard, N. D. Sturrick, and G. W. Evans, Eds. New York, NY, USA: ACM Press, 1999, pp. 798 – 805. [4] C. Versteegt and A. Verbraeck, “The Extended Use of Simulation in Evaluating Real-Time Control Systems of AGVs and Automated Material Handling Systems,” in Proceedings of the 34th Winter Simulation Conference, WSC’02, E. Y¨ ucesan, C. H. Chen, J. L. Snowdon, and J. M. Charnes, Eds., 2002, pp. 1659 – 1666. [5] T. J. Gogg and J. R. A. Mott, “Introduction to Simulation,” in Proceedings of the 25th Winter Simulation Conference, WSC’93. New York, NY, USA: ACM Press, 1993, pp. 9 – 17. [6] R. Pannequin and A. Thomas, “Proposition d’une plateforme d’exp´ erimentation sur le contrˆ ole par le produit des flux de production,” in 6e`me conf´ erence francophone de MOd´ elisation et SIMulation, MOSIM’06, ser. ISBN 2-7430-0892-X, M. G. et F. Riane, Ed., vol. 1, Rabat, Morocco, April 2006, pp. 156 – 165. [7] A. Pfeiffer, B. K´ ad´ ar, and L. Monostori, “Evaluating and Improving Production Control Systems by Using Emulation,” in Proceedings of the twelfth IASTED International Conference on Applied Simulation and Modelling, ASM 2003, September 2003, pp. 261 – 267. [8] I. Mc Gregor, “The Relationship Between Simulation and Emulation,” in Proceedings of the 34th Winter Simulation Conference, WSC’02, E. Y¨ ucesan, C. H. Chen, J. L. Snowdon, and J. M. Charnes, Eds., 2002, pp. 1683 – 1688.
[9] V. Maˇr´ık, P. Vrba, K. H. Hall, and F. P. Maturana, “Rockwell Automation Agents for Manufacturing,” in 4th International Joint Conference on Autonomous Agents and MultiAgents Systems, AAMAS’05, July 2005, pp. 107 – 113. [10] O. Boutin, B. Cottenceau, A. L’Anton, J.-L. Boimond, and M.F. G´ erard, “Simulation d’une gestion de production (max,+) lin´ eaire sous SIMAN/ARENA,” in Journ´ ees de la Section Automatique du club EEA, Angers, France, March 2006. [11] M. Landry and J.-L. Le Moigne, “Towards a Theory of Organizational Information System-A General System Perspective,” in IFIP Congress, 1977, pp. 801 – 805. [12] T. LeBaron and K. Thompson, “Emulation of a Material Delivery System,” in Proceedings of the 30th Winter Simulation Conference, WSC’98, D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivannan, Eds., 1998, pp. 1055 – 1060. [13] Y. J. Son and R. A. Wysk, “Automatic simulation model generation for simulation-based, real-time shop floor control,” Computers in Industry, vol. 45, no. 3, pp. 291 – 308, 2001. [14] “Applications of Time Delay Systems,” in Lecture Notes in Control and Information Sciences, J. Chiasson and J.-J. Loiseau, Eds., no. 352. Springer, 2006. [15] L. Hardouin, “Data processing tools to handle periodic series in dioid,” http://www.istia.univ-angers.fr/˜hardouin/outils.html, 2006, accessed 6th October 2006. [16] B. Cottenceau, L. Hardouin, J.-L. Boimond, and J.-L. Ferrier, “Model Reference Control for Timed Event Graphs in Dioids,” Automatica, vol. 37, pp. 1451 – 1458, 2001. [17] C. A. Maia, L. Hardouin, R. Santos-Mendes, and B. Cottenceau, “Optimal Closed-Loop Control for Timed Event Graphs in Dioid,” IEEE Transaction on Automatic Control, vol. vol. 48, pp. 2284 – 2287, 2003. [18] B. Cottenceau, L. Hardouin, J.-L. Boimond, and J.-L. Ferrier, “Synthesis of Greatest Linear Feedback for Timed Event Graphs in Dioid,” IEEE Transactions on Automatic Control, vol. vol. 44, no. 6, pp. 1258 – 1262, 1999. [19] R. W. Brennan, “Performance comparison and analysis of reactive and planning-based control architectures for manufacturing,” Robotics and Computer Integrated Manufacturing, vol. 16, no. 2-3, pp. 191 – 200, 2000.
