Loading...
Please wait, while we are loading the content...
Similar Documents
Vehicle Internal Architecture BASEMENT Real-Time System: The Simulator Tool
| Content Provider | Semantic Scholar |
|---|---|
| Author | Emanuelsson, Mikael Sjodin, Mikael |
| Copyright Year | 1995 |
| Abstract | ion Transformation Implementation Validation Validation Model Conceptual Computation System Model Specific Real Simulator Validation (Experimentation) Validation Figure 3: Activities and results in the modeling process VIA BASEMENT RTS: The SimulatorTool, ProVIA-DoCS-94104, Version 1 / Document, January 31, 1995 8 In gure 3 the dashed lines illustrate the need to assure that no important information is lost in the di erent phases. If only the experimental validation is performed and anomalies are found, it is very hard to locate where in the modeling process they have been introduced. 4.2 Types of Simulation There are numerous types of simulation techniques. When about to build a simulator a technique which captures the aspects one which to study in the real systemmust be chosen. Also, many techniques require that the system are modeled in a particular fashion, eg. using di erential equations. Some of the more common techniques are: Hardware Emulation Eg. emulation of CPU's and other hardware in the system. It can be argued whether emulation is a simulation technique, but still, it can be useful in some situations for example when one which to simulate software. Monte Carlo Simulation This technique models probabilistic phenomena in a static mathematical model. The method is to scatter a random set of points in the model and analyse the results of the probes. Continuous Time Simulation The system is modeled by a series of di erential equations. The system state change continuously over time. Discrete Time Simulation The system is modeled by a series of di erence equations. The systems state change at discrete points in time, the points are equally spaced over time. Discrete Event Simulation The state of the model is updated at discrete points in time; the times when events occur. Events can occur at any point in time, and multiple events can occur at the same point in time. The model consists of entities which a ect each other by exchanging events. This technique is useful when entities in the real system are hard or impossible to model mathematically, eg. with di erential equations. There are also techniques which tries to combine one or more of these techniques, often called multi-model techniques. 4.3 Discrete Event Simulation When using this technique any changes to the system state is considered to be instantaneous. Changes in the system state are caused by events. Example of VIA BASEMENT RTS: The SimulatorTool, ProVIA-DoCS-94104, Version 1 / Document, January 31, 1995 9 events in a car simulation system are: ignition key turned on and compartment door closed. Exactly what constitutes an event depends on the level of granularity in the model. In gure 4(a) a model of how a compartment door is opened and closed is described. Such a model is probably su cient in many cases but if one which to study some aspect of the system during the time the door is about to be opened or closed a model like gure 4(b) might be more appropriate. Closed Opened Opened Closing Closed Opening Close Open Begin close Complete close Complete open Begin open (b) (a) Figure 4: Discrete event systems In gure 4(a) and 4(b) the boxes represents possible states of the compartment door and the labeled arrows corresponds to the events which make the door change state. The gures 4(a) and 4(b) are di erent models of one entity in a whole system. The system state is a composition of all the states of the di erent entities in the system. Discrete event simulation is a powerful simulation method. It allows simulation of any entity whose behaviour can be captured by a computer program. This exibility can however sometimes result in very complex programs, often the notion of process orientation is used to structure the program. By using process orientation, entities becomes encapsulated processes which may interact with other processes in well de ned and understood ways. 5 Our Work In the following sections we describe the background research made and the decisions we took based upon what we found. 5.1 Platform for Development All implementation work has been performed on SUN work-stations using SunOS Release 4.1.3 (UNIX). The programming languages used are C++ and C, compiled with GNU's compiler gcc. Some code is auto-generated from GNU C++ class-library. Also, the part of VIA BASEMENT RTS: The SimulatorTool, ProVIA-DoCS-94104, Version 1 / Document, January 31, 1995 10 the simulator which reads con guration les has been created with the GNU tools flex and bison. To create the C++ code for di erent types of simulation events, we wrote a lisp program which runs under emacs (The GNU text editor). The graphical user interface has been developed with the tool TeleUSE [Tel]. We used a simulator building tool which imitates the capabilities of Simula, called C++SIM [LM]. C++SIM needs an underlying task mechanism, we choose to use REX lightweight process library [(js93], also known as the GNU lightweight process library. All software except SunOS and TeleUSE is freely distributed for non-commercial use. GNU programs are available at the internet URL ftp://prep.ai.mit.edu/pub/gnu, C++SIM is available at the internet URL ftp://arjuna.ncl.ac.uk, REX-lwp is available at the internet URL ftp://gummo.doc.ic.ac.uk/rex. 5.2 Choice of Simulation Technique In our case three of the techniques described in section 4.2 can be immediately eliminated, since we are dealing with a system which changes over time and whose entities are di cult to model as equations. Thus we ruled out monte carlo simulation, continuous time simulation and discrete time simulation. As for hardware emulation, we recognise the goal to test application on many different types and con guration of hardware. If emulation was chosen each type of hardware in the system would have to have its own emulator. Such a solution would be far to in exible and also very slow, hence we eliminated it. The decision for choosing a discrete event simulation model was not only based on the shortcomings of other models. Discrete event simulation o ers many advantages due to its exibility. Discrete event simulation models are easy to combine with other models. In our case the environment simulator may need to model some continuous processes, eg. friction between road and tires. Also, since a discrete event simulator is not based on mathematically described objects, it is easy to add and replace objects in the model. The only interface to an object is the events which it sends and receives. In our case this is important since the BASEMENT kernel or other system speci cations might be modi ed. Another advantage of discrete event simulation is the availability of simulator building tools. This has allowed us to nd a tool which suits our needs rather than adapt our needs to available tools. VIA BASEMENT RTS: The SimulatorTool, ProVIA-DoCS-94104, Version 1 / Document, January 31, 1995 11 5.3 Choice of Simulator Building Tool As soon as we recognised the need for a tool to help us build our simulator we stated some requirements for the tool and begun to investigate di erent tools and compare them against our stated requirements. A document summarising the tools we looked at was created [Ema95]. The requirements we stated can be summarised as follows: The tool should be able to call C functions. This is so that is can execute the applications, which are compiled to C, and the BASEMENT kernel, which is written in C. The tool should support a high level of abstraction and modern programming principles. It could for instance support process orientation which is a powerful concept when, like in our case, dealing with many concurrent tasks. The tool should be possible to integrate with a graphical user interface. The tool should posses a certain degree of maturity, and be easy to learn, understand and use. The tool should be available at reasonable cost. The tool should be portable to di erent UNIX and PC systems. As a major source of information about simulations tools we used Internet, mainly the News groups comp.simulation and comp.realtime. The requirement to be able to run C code was quite limiting, it e ectively eliminated most tools which was not directly based upon C or C++. Also, there was a certain resistance from Mecel AB against using another language than C or C++. We did however nd some interesting non C/C++ tools which are able to call C functions: The Simula compiler \Cim" [KJM91]. This is complete Simula compiler which is free-ware. It is completely based on C which makes it quite portable, and which also makes it easy to call C functions from Simula programs. Modsim, a language from the Naval Research Laboratory [Her]. The language is similar to Modula-2 with extensions for discrete event simulation. It is intended to be used for building large process oriented discrete event simulation models through modular and object oriented development techniques. The compiler is available for both DOS and UNIX environments. There exists compilers which are free of charge for research and educational purposes. The languages above, support a high level of abstraction, but they reduce our exibility to control the execution of the simulation; we would be in the hands of the VIA BASEMENT RTS: The SimulatorTool, ProVIA-DoCS-94104, Version 1 / Document, January 31, 1995 12 language run-time system. Thus, it would be hard to integrate a graphical user interface and an environment simulator. Even though the high level of abstraction available in these languages is appealing, their bene t was a bit uncertain2. Instead, we decided to use a simulation tool for C or C++. This allows us to change the run-time systems if necessary. When studying the available C and C++ simulation tools we soon discovered that most modern packages were developed in C++. We were neither surprised or displeased with the fact, since object orientation is well suited for simulation. We found quite many simulation packages in C++, as shown in [Ema95], the s |
| File Format | PDF HTM / HTML |
| Alternate Webpage(s) | http://www.docs.uu.se/docs/provia/sim_report.ps |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
