Discrete event simulation environments: requirements

DISCRETEEVENTSIMULATION ENVIRONMENTS: REQUIREMENTS ORYALTANIR(BELLCANADA), CORPORATE QUALITY ASSURANCE. zyxwvutsrqpo zyxw zyxwv SULEYMAN SEVINC (UNIVERSITY OF SYDNEY), BASSERDEPARTMENT OF COMPUTER SCIENCE. ABSTRACT many other disciplines such as communications, programming languages, and in manufacturing of various computer components. These standards have permitted different manufactums to develop upon other manufacturers' products. 'Ihis in turn spawned a surge in the productivity and competitiveness of the market. The same type of progress in the simulation technology can also be accomplished. The concept of a simulation environment combines the various different aspects of the simulation process into one complete powerful tool. The environment is intended to provide all the necessary state-of-the-art advances and concepts that a modeller may require during the simulation development and execution process. The benefits of a standard to the simulation field are not limited to economic gains. A wider use and acceptance of simulation can be foreseen in an industry that is still not convinced of its usefulness. To many upper level management in large corporations, simulation is avoided as much as possible and the modeller is sometimes regarded as an "Alchemist" or a dabbler in the black arts. A standard can add more clout to the credibility of the simulationpractice. With more use of simulation, a faster rate of progress in ideas, concepts and implementations of simulation languages and environments can be envisioned. Hence the "environment" requirements must be suited towards the end user needs, free of obligations to learn a new language. The requirements must specify the useful features, independent of different platforms and implementation languages. Introduction The discrete event simulation community has progressed a long way since the last thirty years. Simulation is being implemented and accepted as an integral part of the product life cycle in many industries. The field promises many interesting development opportunities, however, many believe that a more standardized approach is necessary if industry is to fully participate as a partner in the expansion of the area. In this paper we intend to spur some discussion in the simulation community by laying down some issues involved in standardization. These issues are also the focus of the I.E.E.E. P1173 working group on simulation (sponsored by the I.E.E.E. Technical Committee on Simulation). There may also be some negative side effects of standardization. A potential undesired consequenceof standardization(as experienced in other fields) may be the damage it could do to research in the field, e.g. it may diminish research funding for new simulation environments. Therefore, one must be careful to use standardization as a means for advancing the field and not for inhibiting research. However, a long term disagreement in the basics may equally be harmful and certainly is not very productive. What a standard could achieve is a delicate balance between these two ends of the spectrum. The above points bring forth the concept of a Standard Discrete Event Simulation Environment (SDESE). The SDESE is different from a language in the sense Standards have been successfully developed in zyxwvuts zyxwvu zyxwvuts 160 TH0308-7/90/oooO/0160/$0.100 0 1990IEEE that it is not syntax dependant, but proposes to define the features and components of an "environment" which includes a model base, model construction and experimentation facilities. The underlying language syntax is viewed as an independent implementation detail. However the construct of the underlying language (its implementation, data structure processing capabilities etc.) may affect the ability of the language to support a SDESE. This point will be further discussed in the following section. The environment proposes to maintain a standard set of interfaces that allow it to integrate tools from multiple sources. Its significance is far reaching than this, since a standard interface also implies a common method of verification of the model. Given that two environments, although implemented differently, possess common definitions of model and specific internal features (which shall be elaborated in this paper), verification of the input/output definitions of each individual part is possible. Figure 1 further illustrates the position of the SDESE in relation to the modeller and the hardware platform and languages. Gonirtl Prrpoi# zyxwvut zyxwvutsr zyxwv Optictin( 1 As a result, a verification process applied to a given SDESE can also be used for another implementation of a SDESE. The modeller has access to a larger pool of resources than is currently available to single source languages. Simulation vendors can utilize their resources to further enhance their implementations rather than re-inventing the wheel and developing different add-ons to their products. The standards approach presents a more "unified" one, to further the cause of the simulation community. HLRDWARE essful. Perhaps one of the popular ones is the recent Unix implementation standard proposed across 80286 based personal computers. The circumstances leading to their success are quite different from those prevailing in the simulation arena. On the path of standardizing a simulation environment, as mentioned in the previous section, it is not desirable to concentrate upon implementation details. At present, simulation bases exist across various hardware platforms executing under numerous different operating systems. Furthermore, discrete event simulation itself is a wide discipline. Its use is so general that hardware requirements can range f "personal computers to parallel architectures. Defining specific implementation procedures would impose a smct limitation of the standard across specific hardware/software configurations. This in turn may not be suitable nor feasible for a given simulation project. Even for cases where the hardware is deemed adequate, the current base of Abstractions and Implementations in Discrete Event Modelling and Simulation In view of the many different implementations of discrete event simulation languages that exist, it is a considerably difficult, if not impossible, task to develop or standardize upon a given implementation. There are a few cases outside the simulation area where implementation standards are succ- Syittn zyxwvut 161 zyx zyxwvutsrqp zyxw simulation languages may not be utilized without significant re-working of the code to comply with the standard. gramming languages. The constructs found in programming languages can be adapted for implementing higher levels of abstraction used in simulation . Consequently, an SDESE would be significantly more useful if it were to concentrate upon abstraction details as opposed to implementation details. A word of caution must be presented here. The implementation language of the SDESE is a tool that provides the basic functionality of the simulation environment. As with any critical tool, they must be chosen rationally. For example, strict t y p limitations imposed by the underlying language can severely hinder the development of an environment and resmct modeller creativity. Also the underlying implementation language must allow the programmer to access lower level Components of given models if the modetler wishes to do so. Before continuing into a more detailed description of the SDESE features, the notion of an abstraction should be clarified. This concept is a key ingredient to describe the simulation practice. An abstraction is a representation of a system. It can be viewed as a mapping from a given state to another (presumably more abstract) state space. For example, a model can be viewed as an abstraction of a conceptualized system. The abstraction could contain components such as 1/0 definitions and state transitions. Proceeding one stage further with this rationale, a set can be thought of as an implementation of the states abstraction. Alternately, a heap can be considered an implementation of the sets abstraction. It can therefor be observed that there can be several layers of abstraction for a given conceptualized system. A language provides the programmer with a set of conceptual tools. If these tools are inadequate for a given problem they will be ignored and worked around. With this in mind, an Object Oriented Programming Language utilized as the basic implementation medium of the SDESE may provide more flexibility for creative development than conventional languages. This type of an approach contains some proven concepts that can ease the implementation of a SDESE. To appreciate some of the benefits of Object Oriented Programming, let us examine some examples: One of the more powerful methods of managing complexity in a simulation study is hierarchical modelling. This is the ordering of related model components in a tree structure with the general system model at the root of the tree. This type of organization is naturally defined in object oriented programming with the concept of classes and derived classes . In conventional languages, extra effort would be required to implement and manage hierarchical models. This distinction between implementation and abstraction is important when one considers which areas of the SDESE can be successfully defined. This paper will only concentrate on defining and outlining the issues concerning abstraction. The issue of language Another example is the concept of encapsulation : a model is combined with the functions and procedures that manipulate it to form an object. The "model" object can then be addressed at a significantlyabstract level allowing for flexible manipulation in a simulation study. At first one may be inclined to develop a standard containing syntax optimized for simulation abstractions. However the result would be no more than injecting yet another simulation language into a field that is not favourable to adopting just one syntactic description. This is not the intention of the SDESE. Finally, the concept of classes can be exploited: a class is a type and defines the behaviour of a set of similar objects. This can be easily extended into the simulation environment where models and sub-models are If one simply observes data types within simulation languages, one can conclude that they are not radically different than those found in other pro- I62 zyxwv zyxwvutsrqp zyxwvutsr defined with their respective behaviours. This will be further explained in the next section. also want to have operations for other pre- and postprocessing purposes such as window drawing, filtering, etc. Such operations that manage the presentation (visualization),however should not be considered as part of the model. Therefore, support for such operations can be considered desirable, but not mandatory. In particular environments, such operations may be supported through default dispatch mechanisms with provisions for allowing modellers to define their own. In the remaining parts of this paper, we will outline the kinds of constructs needed to be supported by SDESEs. It is assumed that the SDESE will utilize the primitives of a well chosen programming language. Desirable features The above, however is a very simplistic view of a model. First, a model needs to interact with its environment. Therefore, type model needs to be modified; Now that the basic objectives of the SDESE have been defined, this section will concentrate upon the necessary components of the environment. type MODEL operations data interfaces Modelling, Most people would agree that modelling is the most basic activity of a simulationist. Modelling is an activity in which real or imaginary worlds are expressed in a symbol space of a formal language. It is more abstract than coding in principal in that coding is only required if a translation is needed from the formal language in which the model is expressed to another language understood by a particular machine. interfaces are used to ensure that models can interact with their environments including other models in a predefined manner. This is done to enhance modularity which is both a powerful and necessary requkment for a SDESE. The benefits are numerous: A model is intended to represent a segment of the domain being studied. It replicates the behaviour of its real counterpart in a symbol space by generating trajectories consistent with those of what it represents. A model is the most basic construct that should be available to a simulationist. Therefore, support for defining a model in an SDESE is fundamental. Thus, there should be a construct of the form: development of a database of component models, model reusability, prerequisite for hierarchical construction of models, increased degree of testability. The second issue is decomposition: A simulation environmentmust have provisions for model decomp osition. Decomposition permits a complex model to be expressed in terms of simpler components. Verification and validation of the model can then be more readily carried out. Modularity and decomposition (also known as divide and conquer) are concepts complementary to each other. Therefore, type MODEL operations data (representation) zyxwvuts A model could be described using a set of operations operating on data. A data structure, often referred to as state or representation, may take the form of a stack, list, etc. Operations manipulate the data and have to be consistent with the structure, e.g. if data is a stack then operations may be push, pop, etc. Although the operations are primarily intended for manipulating the data, one may type MODEL component models operations data interfaces I63 becomes the extended description for a model. However it is useful to separate models which are decomposed from those that are not. A model with no components is called an atomic model, otherwise it is called a coupled model. Thus, upon that decomposing a large model into its smaller constituents makes the validation and verification process more manageable. In addition to this, in a discrete event simulation environment, a modeller would need the support for testing the components. zyx zyxw zyxw zyxw zyxwvuts zyxw type COUPLED-MODEL component models; atomic or coupled coupling scheme interfaces and type ATOMIC-MODEL operations data interfaces It is worth emphasizing that the simulationist must be freefrom the implementation details of high level con- structs in the environment. That is, the environment should provide facilities for debugging which will recognize constructs designed for simulation such as atomic or coupled models, as well as simpler types of operations. We leave open the question of whether verification support be part of any standard. Experimentation: Experimentation is the phase that follows modelling in a design or analysis task. 'Ihe purpose of experimentation is to learn more about the system under study by subjecting its model to various input sequences selected from the legitimate inputs of the model. The major distinction of coupled models is the existence of a coupling scheme to connect the interfaces of its component models. Also, coupled models may have operations for pre and post processing, as well as for manipulating their component models and outputs. The process of constructing experimental protocols resembles modelling in that it can be considered modelling the environment of the system under study. Thus we consider such protocols as realized by a model, coupled or atomic, called an experimental frame. When coupled together, models and their experimentation frames constitute a closed world. Observation of models during experimentation and checking for the acceptability of the experimentations may also be expressed using model theoretic means. The above discussion presents the basic constructs needed to support modularity and decomposition in a simulation environment. So far we have not considered timing and synchronization issues which are essential to simulation. Along the time axis, a modeller needs to be able to synchronize the activities of his models. A simulation environment needs to provide such means for the modeller. At the atomic model level, a primitive of the form "hold (duration)" may be used for scheduling the models' activities in the future. Simulation models are built for experimentation, yet modelling and design of experimentations must be as separate as possible. This is not a conflict because an experimentation may contain a set of segments of appropriate qualities rather than a single segment. Therefore, the models must be general enough SO that an entire family of experiments can be applied to them. At the coupled model level, the problem may appear as a conflict between two or more component-models scheduled for an internal activity for the same time. This situation can be handled using a tie breaking mechanism. The details of how particular implementations handle model activities should not concern the modeller, but the semantics should be clear so that it can be made to behave as in tended. In addition to features supporting modelling, an SDESE must also be able to support design and conduct of experiments. It is very fruitful to separate the design of experimentations from the modelling itself and in this respect, the environment should be able to recognize them as such. Another dimension to model development is validation and verification. It is usually agreed 164 zyxw zyxw zyxwvutsrq zyxwv zyxwvuts The fact that developing experiments is really a modelling activity implies that the support provided and experimentation specifications used in the modelling environment should enable one to design experiments as well. However there are some additional issues which are worth considering as part of a standard simulation environment: the future of the system and works in parallel with (presumably ahead of) the real system. Models may have to be synchronized with reality when necessary. Advanced features There are other features which are a mark of a well structured simulation environment. However, many of these features are still being studied and there are many others that do not appear in the following list. Therefore, it would be premature to include these in a standard. It is envisaged that, as the state of the art advances, although at a somewhat slower pace, the standard definition will be modified accordingly. Data or statistics gathering capabilities. Such facilities should provide at minimum the ability to attach observers to specific points in a model, i.e. inputs and outputs. - - Observation of interactions between the components models. Facilities for intercepting data (messages) exchanged between subcomponent models and means to relate the cause and effect of such exchanges. Facilities for granular modelling. This implies hiding the detail of a model's sub components and structure. Once the individual sub components are tested, a "higher" view of the model can be used to ease the complexity of the system components. - Models should be reusable or replicable. This facilitates model construction of similar systems and enhances the concept of a model base. - Facilities for redefining basic algorithmic components of the simulator. e.g., flexibility in choosing internal random number generators or utilizing an external algorithm or data file. - - Facilities for presentation of information related to experimentation. Some examples; check-pointing, resetting, restarting, stopping, etc. - Simplification. Simplification reduces the time and space complexity of a simulation model. We often simplify the parts of a model when they are not the focus of the simulation study. It would be beneficial to have automatic means for model simplification. - Adaptive system modelling. Adaptive modelling allows the study of systems that change their behaviours over time. Therefore, a simulation environment should at worst not prevent the simulationistsfrom developing their own techniques for adaptive system simulation and at best it should have features supporting it. - AI and modelling. There are many examples in which simulation and AI methods co-exist to solve a large prob lem together. Mature methods applying AI techniques to modelling and simulation should eventually be facilitated. - Real time inputs to the models. This involves the definition of interfaces and synchronization of models with the real system. This may be particularly useful in cibes where simulation is used in predicting 165 Parallelism. Distribution of discrete event simulation provides help in overcoming the problem of long execution times inherent in complex simulation studies. Conclusions: zyxwvutsrqpo Issues that are likely to be involved in defining a standard simulation environment were investigated. When doing so, only the functionality of such an environment was considered. We hope that these considerations will stimulate discussion and bring up others. As a result, the user is provided with a richer set of tools to produce more reliable models, and suppliers are provided with a new and potentially rewarding market to explore. ation: Paradigms for the future", Modelling and Simulation Methodology: Knowledge Systems Paradigms, M.S.Elzas, T.I.Oren, B.P.Zeigler (Eds.), North-Holland, Amsterdam, 1989, pp. 29-43. Oren, T. I., "Design of SEMA: A Software System for Computer Aided Modelling and Simulation of Sequential Machines", Proceedings of the Winter Simulation Conf. ,1980, pp. 113-123 zyx zyxwvutsr zyxwvutsrq zyxwvutsrq zyxwvutsrqpo Acknowledgments: We wish to thank B.P. Zeigler, T. Oren and F. Coallier for their comments during the preparation of this article. Sargent, R.G., "An Overview of Verification and Validation of Simulation Models", Proceedings of the 1987 Winter Simulation Conference, December 1987. BIBLIOGRAPHY: Balci, O., "Requirements for Model Development Environments" , Computers and Operations Research, 13,l (Jan-Feb), pp. 53-67. Fishwick, P.A. , "The Role of Process Abstraction in Simulation", IEEE Transactions on Systems, Man and Cybernetics, Vol. 18, No. 1, Jan/Feb. Lehmann, E.L., Testing Statistical Hypotheses, Wiley, New York, 1986. Murray, K. J., S . Sheppard, "Automatic Model Synthesis: using automatic programming and expert systems techniques towards simulation modelling", Proceedings of the Winter Simulation Conference 1987, December 1987, pp. 534-543. Nance, R.E., "The Conical Methodoloav: A framework for simulation model development", Proc. of the Conference on Methodology and Validation, (6-9 April 1987, Orlando, FL) Simulation Series (19) 1, Society for Computer Simulation, San Diego, CA, Jan. 1988. .,A Oren Oren, T.I., "Gest- A Modelling and Simulation Language Based on System Theoretic Concepts" , Simulation and Model-Based Methodologies: A n Integrative View, T.I. Oren, B.P. Zeigler, M. S .Elzas (Eds.) . Springer-Verlag, Heidelberg, Germany, pp. 281-335. , T . I., "Bases for Advanced Simul- Sevinc, S., "Automation of Simplification in Discrete Event Modelling and Simulation", Tech. Rept. 359, August 1989, University of Sydney, Basser Department of Computer Science Winston, P.H., B.K.P. Horn, LISP, Addison-Wesley Pub. Co. , Reading MA, 1984. Wymore, A.W., A Mathematical Theory of Systems Engineering-The Elements, Krieger, 1977 Zeigler, B.P., Theory of Modelling and Simulation, Krieger, 1976 Zeigler, B.P., Multifaceted Modelling and Discrete Event Simulation, Academic Press, 1984 Zeigler, B.P., "Hierarchical Modular Discrete-Event Modelling in an Object-Oriented Environment", Simulation, Nov. 1987