Simulation Software: Not the Same Yesterday, Today Or Forever M Pidd* and a Carvalho Lancaster University, Lancester, UK

www.palgrave-journals.com/jos

Simulation software: not the same yesterday, today or forever M Pidd* and A Carvalho Lancaster University, Lancester, UK

It is probably true, at least in part, that each generation assumes that the way it operates is the only way to go about things. It is easy to forget that different approaches were used in the past and hard to imagine what other approaches might be used in the future. We consider the symbiotic relationship between general developments in computing, especially in software and parallel developments in discrete event simulation. This shows that approaches other than today’s excellent simulation packages were used in the past, albeit with difﬁculty, to conduct useful simulations. Given that few current simulation packages make much use of recent developments in computer software, particularly in component-based developments, we consider how simulation software might develop if it utilized these developments. We present a brief description of DotNetSim, a prototype component-based discrete event simulation package to illustrate our argument. Journal of Simulation (2006) 0, 000–000. doi:10.1057/palgrave.jos.4250004

Keywords: simulation software; Microsoft.NET; composability; the future

Introduction methods are also common in the various sub-disciplines of the social sciences and management sciences. Since this new It will be very obvious to readers of this new journal that a journal is published on behalf of the Operational Research computer can be used to simulate the operation of a system Society, we focus on simulation as used in OR/MS such as a factory or call centre, but whether it was so (operational research/management science)—but there is obvious to the pioneers is not so clear. It is clear, though, much more to simulation than this. Within OR/MS, the that when they realized the possibilities they were creative term ‘computer simulation’ covers discrete event simulation, and enthusiastic in developing methods that would harness the emerging power of computers to the improvement of continuous simulation, system dynamics and agent based productive systems. When computer simulation began, there modelling. Since we have too little space to cover every were no programming languages in the sense that we aspect of simulation, even in OR/MS, here we concentrate understand them today. Instead, the earliest simulation on discrete event simulation. modellers found themselves flipping switches or writing in A well-rounded discrete event simulation modeller re- machine code and, a few years later, writing in assembler; all quires three related skill sets. First, expertise in and rather clumsy. More than 50 years later, computer simula- knowledge of probability and statistics, since many systems tion methods are taken for granted in many areas and there modelled by discrete event simulation contain elements that are easy-to-use tools that enable people with limited are best represented stochastically. This does not mean that computing skills to develop and run simulation models simulation modellers must be professional statisticians, but (Hollocks, 2004). Our aim, here, is to review the develop- they really should be comfortable with statistical variation ments that occurred in that half century, trying to do justice and probability. Secondly, modellers need expertise and to the pioneers and to those who have moved things on since experience in computing, since discrete event simulations are then. About 20 years ago, one of us reviewed developments implemented in computer programs. It would be a mistake, in simulation and linked these to developments in computing however, to assume that modellers require fully developed (Pidd, 1987), but much has changed since then. programming skills in the sense that this would have been Nowadays, computer simulation is rather a broad field meant 20 years ago. As will become clear later in this paper, with applications in all scientific disciplines: indeed much of many, possibly most, discrete event simulations are im- climate science is wholly based on simulation models, many plemented in modelling packages. These are often known as of which are impossible to validate in any sense. Simulation Visual Interactive Modelling Systems (VIMS) and, although they do require some programming, this consists of small *Correspondence: M Pidd, Department of Management Science, Lancaster sets of logical statements rather than full programs. Thirdly, University Management School, Lancaster University, Lancaster LA1 4YX, UK. and perhaps less obviously, discrete event simulation E-mail: [email protected] modellers must be able to model. That is, they must learn 2 Journal of Simulation Vol. ]],No.]] the skills of extracting the essence from a situation, develop understanding. That is, modern simulation tools embodying these in a conceptual model and using them have shifted the emphasis from programming and software once they are implemented in a suitable computer system to development to modelling and model use—at least as far as draw inferences about the system being simulated. simulation modellers are concerned. Of course, hidden away One of us, Pidd, is a management scientist who has been in the background are the software engineers and developers involved with computer simulation for over 30 years. During who provide the tools that have enabled this shift. this period, he has maintained an interest in both the theory and practice of simulation, especially of discrete event Aquick review of the history of discrete event simulation simulation; though with more than a passing interest in software system dynamics. The other, Carvalho, is an experienced computer scientist who, at the time this paper is written, is Without over-simplifying matters too much, we can consider close to completing a PhD in computer simulation, as part of discrete event simulation software as passing through the which she developed DotNetSim which is described later. following phases. Our joint insights form the basis of this paper, which we hope will be of value to people in considering not just the 1. Almost any programming language can be used to write a past of simulation but also its possible future. Over the years, discrete simulation application from scratch, as long as it a symbiotic relationship has developed between simulation supports both numerical computation and logical opera- and computing. In general, computing has been ahead of tion. Thus, people have used FORTRAN, Pascal, discrete event simulation; that is, simulation modellers have BASIC, Modula II, C, C þþ and the variations around taken up developments that occurred elsewhere in comput- these languages. Since common operations occur in any ing. But there have been exceptions to this rule, such as when discrete event simulation, programmers were quick to object orientation first appeared in the simulation program- develop libraries of subroutines and functions that could ming language SIMULA (Dahl and Nygaard, 1966) and be re-used. Initially, such re-use was for a single also in the use of graphics for decision support. individual or organization, but gradually products such In general, we consider the strong links between discrete as GASP (described in Pritsker, 1974) and SIMON (Hills, event simulation and developments in computing over the 1965), which were libraries of subroutines, appeared in last half century and suggest that, useful though they are, the market. SIMON, a library of Algol routines, was so- today’s simulation packages may need to be radically re- named because its originator, Robin Hills, intended it to thought if they are to meet users’ future expectations. For a be simple to use—compared to the available alternatives. broader treatment of developments in simulation see Today, some simulations are still written by cutting Robinson (2005) who discusses issues beyond software. general-purpose code, but probably very few of these are in the commercial world. 2. Since computer programming skills have rarely been Developments in computing and their effect on discrete widespread, simulation software developers realized that event simulation users without proper programming skills could be supported by the development of application packages It may once have been true that simulation modellers were based around the idea of a flow diagram, sometimes pleased to find any way to run even a simple simulation known as a block diagram. Early examples of these were model. Anyone who has written a reasonably complex GPSS (described in Gordon, 1962) and HOCUS (Hills, program in a language like FORTRAN or C þþknows the 1971). As originally envisaged, such models would be feeling of relief when it seems to work properly—and the all developed in a two-stage process. First, the user would too common despair when a bug appears later. Eventually draw a flow diagram that represented the outline of the the program will be declared fit for purpose, but behind this logic of the system to be simulated. Secondly, this logic will have been many bugs and development problems sorted would be translated by the modeller into a command out one by one, in a laborious process of debugging and sequence (using punched cards in the early days) that verification. Nowadays, the existence of VIMS allows a would be read by the flow/block diagram system (eg modeller to take for granted that a simulation model will run GPSS) as data. As long as the application was relatively once it has been built. Models can be built very quickly, simple, the simulation could then be run. However, such sometimes while the client for the work is watching and flow diagrams can rarely capture the full logic of a taking part in the work. In the early days, a huge proportion simulation application and further development was of the effort in a simulation project involved getting a model needed. Since an experienced modeller could write down into a computable form, so it could be used. That is; a series of GPSS block commands without drawing a programming, testing and refinement. Nowadays, thanks to diagram, systems such as GPSS came to be regarded as simulation tools, the emphasis is on the conceptualization simulation languages and the idea of a GPSS ‘program’ and use of a model to think through options for change or to appeared. M Pidd and A Carvalho—Simulation software 3

3. Once the idea of a simulation program as a sequence of such as the Winter Simulation Conference or at the high-level commands is accepted, it starts to become biennial simulation software survey conducted by Jim sensible to develop full programming languages that Swain for INFORMS (Lionheart Publishing, http:// incorporate commands that execute operations frequently www.lionhrtpub.com/ORMS.shtml) shows that VIMS used in a simulation. In this way, GPSS eventually now rule the roost. became GPSS/H (Crain, 1996), moving away from its roots in flow diagrams by adding limited program control constructs. Also employing a block structure, Pegden Package bloat developed SIMAN (described in Pegden et al,1990), which included the concept of a simulation experiment, or Hence, simulation modellers have moved from a state frame, linked to the simulation model. SIMSCRIPT in which they were pleased to get any computer simulation (Markowitz et al, 1963) and its descendent SIMSCRIPT to run, even a simple one, after days of tedious debugging. II.5 (Russell, 1987) also appeared; as did CSL (Buxton We now find ourselves with a wide range of VIMS and Laski, 1963) and ECSL (Clementson, 1973). With the well-suited to specific application domains and, by using benefit of hindsight, the queen of these simulation them, we can quickly develop a simulation model that languages was SIMULA (Dahl and Nygaard, 1966), will run. However, like most software, discrete event which introduced the concepts now included within simulation packages have begun to show signs of package object orientation. bloat. That is, the relatively simple idea of a simulation 4. These language developments were also accompanied by executive that dynamically executes the static logic laid out the creation of interactive program generators, of which in event, process or activity code has ended in a situation in the best known was perhaps CAPS/ECSL (Clementson, which the typical package is, effectively, a simulation 1982), although the ideas first appeared in Ginsberg et al modelling and support environment that provides the (1965). These required the user to develop a flow diagram, following: which was described graphically or in text to the program generator, which then wrote code that would compile and Modelling tools, such as run and, most significantly, could be edited to add those * A graphical modelling environment. tweaks that were impossible to represent on the flow * Built-in simulation objects (eg machines, conveyors) diagram. It should be noted, though, that editing with defined properties and behaviour. someone else’s computer program requires advanced * Property sheets and visual controls to enable simulation skills and some confidence and so these program parameters to be set and varied. generators were not widely used. * Sampling routines and other utilities employed in the 5. As PCs grew cheaper and more powerful, they also model. provided inexpensive and high-quality graphical displays. Especially in the UK, simulation software developers Tools to execute the simulation, such as were quick to capitalize on this and, building on * A simulation executive to run a model. Hurrion’s work at Warwick University (Hurrion, 1976), * Animated graphics or virtual reality representations to Istel developed SEE-WHY (Fiddy, Bright and Hurrion, allow a user to view the model state as the simulation 1981) and an offshoot of British Steel developed FORS- proceeds. SIGHT (Business Science Computing, 1982). These were * Simulation run control to enable the user to interact Visual Interactive Simulation (VIS) packages that safely with the simulation as it runs. allowed animations of model performance to be displayed on-screen as a simulation ran and permitted the user to Tools to support experimentation, such as interact with the model in a gaming mode. However, they * Experimental frames that define run lengths, outputs still required the user to write code—typically in and parameters. FORTRAN. * Analysis tools that enable results to be interpreted and 6. These VIS were quickly followed by VIMS in which the presented. user develops the core of a simulation model by placing * Optimization tools. and linking icons from an on-screen palette. Detailed event logic is added by allowing the user to write event Links to other software such as spreadsheets, databases code in property sheets that are linked to the on-screen and corporate systems. diagram. The first such VIMS that enjoyed any success was probably Witness, created by Istel (Gilman and Watramez, 1986), which was quickly followed by many Figure 1 shows a hypothetical but typical simulation others: including ProModel, Automod and Taylor II. A package and its various components that provide the above quick glance at the software on display at conferences functionality. 4 Journal of Simulation Vol. ]],No.]]

Debuggers, Interpreters Code generators and compilers Libraries of prefabricated objects Legend

Data Input Analysis Core (ExpertFit, Sat::Fit, …) Graphical Editor Rules Editor Simulation application (adding logic and programming Add-ons Graphics generators (Designing the data to objects language (predefined user-defined model layout) and connections) External graphs,…) General purpose components Report generators programming (predefined user-defined languages reports,…) Simulation engine (running scenarios) Output analysis

Optimisers (OptQuest,…) Core application 3D representation and Templates Wizards to generate Access to external animation (classes of problems) models data sources

General-purpose packages ExpertFit, Stat::Fit, Oracle, Microsoft Office, ...

Figure 1 A typical simulation package currently consists of a core application, and a wide range of add-ons.

Hence, modellers expect discrete event simulation soft- successive software development paradigms. Understanding ware packages to present themselves as huge, monolithic this explains much of why simulation software has taken its applications that aim to do almost everything. They possess form and also suggests how a different approach might be functionalities that are constantly extended by adding used in future. The review here begins in the 1970s, when wizards, templates, etc in a generalizing–customizing– computer programming was an established skill but most generalizing development cycle. This has happened because programs were developed in languages such as FORTRAN simulation software vendors, like other software suppliers, and COBOL, in versions that now seem very crude. The use have been trapped by their own success. It has been easier to of such languages led to a crisis in software development in add features, however inelegantly done, than to design again which it became clear that there was a need for standardiza- from scratch. In this way, most current simulation packages tion and for approaches that ease software development and have enough functionality to cope with a large number of subsequent maintenance. problems, but may be an evolutionary dead-end. Theoretical frameworks or paradigms were successively Most of these packages were designed with a particular designed to provide programmers with a set of laws, rules application domain in mind, usually manufacturing. How- and generalizations that enable programs to display desir- ever, they have enjoyed success in other areas that could able properties. Naturally, there are different paradigms for hardly have been imagined by their originators, and their different programming domains as these also target different pre-deﬁned object libraries have grown to accommodate this sets of desirable properties. Our scope is however conﬁned to broad range of applications. This approach, however application software for simulation and hence Table 1 lists successful, may be reaching its limits and other development some of the desirable properties for simulation software. It alternatives should be considered in order to support robust, should be no surprise, though, that virtually all application easy-to-use, quick-to-develop, quick-to-change and quick- software has similar core requirements; that is, to software to-run simulation software solutions. In doing so, it is professionals, many core simulation software requirements sensible to resort to the latest advances in component-based are the same as those in other application domains. Hence, it and layered-based paradigms, and integration mechanisms is worth reviewing four programming paradigms, each of to promote the composition of simulation software solutions which was intended to support the development of software from existing or newly developed prefabricated components. with these properties.

Aquick review of software development paradigms 1. Structured programming (Dahl et al, 1972) was the ﬁrst In order to see a better way forward for discrete event formal programming paradigm on which others where simulation software, it is necessary to quickly review built. Modularity and its implicit ‘divide and conquer’ M Pidd and A Carvalho—Simulation software 5

Table 1 Desirable properties of simulation software Property Brief description Aprogram should

Dependability Ability to deliver the intended functionality when Be reliable, available, safe, secure and robust. requested without causing danger or damages, resisting external attacks (Sommerville, 2004) and handling error conditions. Usability Ability to provide friendly user interfaces that permit Be easy to learn and operate, adaptable to speciﬁc different levels of utilisation, detection and recovery models of work, and recoverable from user errors. from input errors. Modularity Ability to be incrementally built by composition of Be modularly composed and extendible. self-contained units—functions, procedures, modules, components, etc. Reusability Ability to run on different conﬁgurations, be Be portable, integrable and interoperable composed with other programs and to communicate with packages of different vendors

principle were its most important contributions to programming language and is used mainly for expert programming. It advocates techniques to structure the systems. program’s flow control that are still recommended so as Functional logic programming paradigms combines to make programs easier to read and to maintain. these two paradigms so that the programming primi- Structured programs are sets of modules, which are, in tives have the power of logical inference, in for turn, sets of procedures or functions. Procedures may example, non-deterministic search and the efficiency invoke themselves or other procedures and functions to of the functional evaluation strategies such as lazy manipulate local and global variables. The program runs evaluation. ALF, Babel and Curry are examples of by passing data through parameters among procedures. functional logic programming languages. Although functions and procedures can be re-used by lifting them from one program and pasting them into 3. Object-oriented programming (OOP) (Booch, 1994; another, it remains true that structured programs are Meyer, 1994) originated with Simula, an Algol-based monolithic pieces of code developed from scratch or, language that supported discrete simulation. The applica- sometimes, from scavenged code. tion of OOP in simulation is demonstrated in Pidd (1995) 2. Functional and logic programming paradigms (Bird and and is based on the notion of objects, their attributes and Wadler, 1998) and their combination emerged within the the functionalities they provide. An object is a data artificial intelligence community in the early 1990s. They structure composed of data (attributes) and code led to declarative programming paradigms, that is, they (methods) that implement the object’s functionalities. focus on the description of data’s relationships, either For example, a queue is an object with attributes such as mathematically or logically, as a means to approach queue name, location and discipline and methods that human modes of thought. enqueue and dequeue elements, determine the length of Functional programming approaches derive from the the queue at each state, reverse the queue, etc. Objects Church’s-Calculus (Church, 1941) and, therefore, con- interact by invoking methods of other objects, that is, by sist of sets of functions that produce values or other requesting others to execute the functionalities they functions, once applied to their arguments. The provide. An observer service, for example, may be execution of a functional program deals with the another object that interacts with the queue by invoking evaluation of expressions and their replacement by its methods to enqueue and dequeue clients and compute the corresponding values. This implies referential performance indicators. Several programming languages transparency, that is, functions must not produce side implement OO concepts. Some are fully object-oriented effects, since it is crucial to guarantee that the such as C# and VB.NET. Others, such as earlier versions application of a function to the same argument always of Visual Basic and corresponding subsets (VBA) are not returns the same result. Functional programming fully OO languages as they do not implement inheritance originated heavily recursive languages such as Lisp, and offer limited utilization of abstraction and poly- Miranda and Haskell, which are intuitive but lead to morphism. programs that are memory-demanding and slow to run. Classes are fundamental to OO programs. A class is an Logic programming derives from the first-order pre- abstraction of an object that defines the attributes and dicate calculus, hence the outputs of a logic program methods of a family of objects. An object is therefore a are inferred from the known facts and the relationships class’s concretization. For instance, the class Queue is a between a set of objects. Prolog is the commonest logic generalization of all queues and the object ‘Queue for