43

Object-Oriented Specification of Models and Experiments in Traffic Simulation

H. Mugge, R. Meyer, L. M. Hilty, B. Page University of Hamburg, Department of Computer Science Vogt-Koelln-Str. 30, D-22527 Hamburg, Germany, Tel.: ++49-40-5494-2425, Fax.: ++49-40-5494-2311 E-Mail:{mueggelhiltylpagelrmeyer}@informatik.uni-hamburg.de

Abstract We present a prototype version of a modelling and simulation system for envi­ronmental impact assessment in the field of traffic and logistics. This software system supports the user in modelling and simulating the environmental impact of various changes to traffic systems. The MOBILE system is designed as an open distributed system and is largely platform independent. The heart of the system is an extendable model base containing complementary and competitive models for the domain of transport and environment. The components of the open distributed MOBILE system communicate in a uniform way, not depending on the language in which the simulation models are written, but using the MOBILE Script Language (MSL).

Keywords Simulation Experiment, Module Interconnection Language, Object-Oriented Specifica­tion, Environmental Modelling

INTRODUCTION

In the three-year research project MOBILE (Model base for an integrative view of logistics and environment), funded by the Volkswagen-Stiftung, we are developing a system for environmental impact assessment in traffic planning. This software supports the user in modelling and simulating systems which are characterized by coordinated transformations of objects in space and time (logistical systems). In order to provide maximum flexibility, the MOBILE system is designed to be a "construction set" for models . In contrast to most commercial software, there is no

Environmental Suflwarc Systems Vut.2 R. Dcn7.er. D.A. Swayne & G. Schimak (Eds.) G IFlP 1997 Puhlished hy Chapman & Hall

336 Part Eight Object Orientation

"one and only" simulation model embedded in the program. Rather, the user is encouraged to build his own model by selecting and composing sub-models as building blocks from the model base. Therefore we enrich the model specification by adding specific information about the model and its interface. Furthermore the MOBILE system combines simulation techniques with Geographical Information System (GIS) technology, because spatial data is fundamental for the issues that we focus upon. In contrast to traditional approaches, we consider ecological scarcity of resources and the responsibility of reducing environmental pollution as essential conditions for the design and control of logistical systems. This approach is also called eco-logistics. During the last years, we have developed several simulation models for specific problems in this field, e.g. the environmental impact of just-in-time delivery and production strategies (Hilty et al. 1994) or measures concerning commuter traffic in crowded areas. The aim of the MOBILE project is to develop a general tool which supports the user in modelling and simulating traffic and transport systems within the conceptual framework of eco-logistics.

2 ARCHITECTURE OF THE MOBILE SYSTEM

The central part of the system as shown in figure 1 is the model and experiment base system. The model base contains simulation models which can be composed to more complex models, tailored to the particular problem the user wants to study. It includes complementary as well as competitive models. In order to support the evolution of theories and models in the field of transport and the environment, the model base can be extended whenever the user wants to include a new model. The experiment base stores and organizes experiment classes as well as explicit specifications of the simulation experiments carried out so far. Experiment classes are used as templates enabling systematic variability of experiments. Experiment instances are persistent objects assuring reproducibility. The MOBILE System treats simulation models as independent processes (simulators). Complex models as well as experiments are implemented as hierarchically structured process groups which can be distributed all over the system. To increase reusability of existing simulation models, the underlying source code implementing simulators is not limited to one particular programming language. On the level of specification, however, models and experiments (as well as methods and the access to data) are described uniformly by means of the MOBILE Script Language (MSL). Such scripts are interpreted by the MOBILE Script Machine (MSM). The execution of an experiment corresponds to the interpretation of the according MSL specification, hence the MSM plays a crucial role in the MOBILE system. The model and experiment base system, the MSM, and the data and method base system form the model builder's view of the MOBILE system. This is emphasized by the modelling system interface which provides the modeller with graphical and textual

Object-oriented specification in traffic simulation 337

specification editors, a model and experiment base browser, as well as access to data and methods in order to combine existing models, develop new building blocks and validate them.

Model User Model Builder

+ + Dynamic GIS Interface Modelling System Interface

I , • Data and Model and Method Base System Experiment Base System

BI~'-I IMOO~ I GIS .. Experi- .. MSM ments

t t I Figure 1 The MOBILE system architecture_

Since MOBILE focuses on applications in eco-Iogistic contexts, strong emphasis is placed on the model user's interface. To the model user the MOBILE system appears as a Dynamic Geographic Information System (DGIS), hence he is provided with a common GIS, enhanced by features for simulation and dynamic data processing. Thus an expandable open GIS also fonns an important component of the MOBILE system. Figure I shows the system architecture representing the minimal complete configura­tion of a MOBILE system. The MOBILE system is designed as an open distributed system so that it can easily be expanded, e.g. by an additional GIS component or by multiple distributed model bases.

3 THE MOBILE SCRIPT LANGUAGE (MSL)

The MOBILE Script Language (MSL) is an object-oriented high-level specification language for composing simulation models and experiments from existing building blocks. It is not supposed to be just another simulation language. It is, in particular,

338 Part Eight Object Orielltatioll

not suitable for implementing of the behaviour of a single model. Unlike general purpose or simulation languages, it only covers issues such as structure representation of complex models and experiments as well as interface definitions in order to facilitate component coupling. Therefore MSL can be characterized as a channel-based Module Interconnection Language (Rice/Seidman, 1994) focussing on simulation modules.

R

structure specification of the combined model R in MSL

I I

A .- B It C , structure specification structure specification structure specification of submodel A in MSL of submodel B in MSL of submodel C in MSL

t- V t behaviour behaviour behaviour

implementation implementation implementation of submodel A of sub model B of submodel C in native code in native code in native code

Figure 2 Specification of a combined model with MSL and native code.

MSL forms the basis of model and experiment specification in the MOBILE system. It enables the model user to deal with specifications on a highly semantic level. He does not need to know about implementational details in order to choose the right model or to couple models. It does not even matter which programming language a particular model is written in. The only form of representations he has to handle are MSL specifications. This is achieved by a strict separation of model specifications into a structure defining and a behaviour defining part. MSL is above all a structure specification lan'guage, hence model structure is completely specified in MSL. The behaviour of each individual building block (atomic model) is specified in another language, e.g. C++ or Java, which we will denote as the native language further on. To join these specification parts together, the interface of each building block, which is at least implicitly specified in the native language, is explicitly given in MSL.

Object-oriented specification in traffic simulation 339

Figure 2 illustrates the connection between MSL and native language parts in an abstract manner. It depicts a model (R) consisting of three submodels (A, B and C). The corresponding representation in the model base consists of four MSL parts and three parts of native' code. The MSL parts represent inteiface and structure of the combined model and the three submodels, respectively. The three native code parts form the behaviour specifications of the individual submodels. The double interface specification for atomar simulators (the leaves of the model tree) does not only technically enable the system to deal with the model behaviour implementations. It also bridges the gap between the computer-oriented implementation level of data structures in native code and the problem-oriented semantic level of MSL specifications. Below we present the main characteristics of MSL in order to give a general idea of the language. First we focus on its object orientation which shows up clearly in the following features:

• a MSL specification of a model or experiment always defines a class and not an instance. Only experiments can be instantiated explicitly in order to specify an executable simulation experiment;

• all components (the used building blocks) of a MSL specification are (at least virtually) independent processes communicating via message passing, so that they can easily be distributed;

• communication between components of a MSL specification strictly follows the client/server paradigm and each component can appear as both a server and a client relative to its different neighbours in the data flow of one experiment;

• the components are encapsulated in the sense that they communicate only according to their interface and topology definition;

• inheritance is used for model specifications in order to enhance reusability and to facilitate navigation in the model base.

Another important characteristic of MSL is its high abstraction level, as indicated below:

• the MSL type concept is based on mathematical constructs, e.g. sets and functions; • direct use of data structures on the implementational level is avoided, since MSL

represents data on a semantic level. The MOBILE Script Machine (MSM) transforms MSL data types into native language data structures;

• MSL enables the modeller to represent metadata about data objects, models and experiments in a structured way. Examples for model metadata are physical dimensions and units or validity restrictions. This metadata can be used by the MOBILE system to automatize unit and data format conversions as well as plausibility checks for model coupling (Hilty/Miigge 1996).

340 Part Eight Object Orientation

Two versions of MSL are defined, a textual and a graphical version. In this article we focus on textual MSL. More details about the features of textual and graphical MSL can be found in (Miigge/Meyer 1996).

4 SPECIFYING EXPERIMENTS IN MSL

In this section we present an example of an experiment specification to elucidate the use of MSL. A simple model experiment consists of the execution of one or more simulation models fed with input data, followed by the evaluation of the simulation results with the help of analysis or visualization methods. One can regard a simulation experiment as a data flow, originating from active data objects w.hich serve as sources, through a network of simulation models and transforming methods to report generators serving as data sinks. The structure of this data flow is defined in a MSL experiment class specification. In an executable MSL experiment instance specification, this class is provided with instantiation parameters. In figure 3 we present a condensed example of an experiment class RoadTraffic­Emi s s i on in MSL source code. The specification of an MSL experiment class is divided into three parts: in the parameters part, the experiment interface is given in terms of the names and types of its parameters; the following contains part declares the components of the experiment and a concluding connects part defines the topology of its data flow network. The contains part is subdivided in sections depicting the different types of components, such as data sources (sources), models (models), transformation methods (methods), subexperiments (experiments) and data sinks (reports). In addition to the instance and class names, the interface of each component (parameters, inputs and outputs) is declared and its parameters are connected to experiment parameters or provided with data objects (values, e.g. deltaTime : = 1 [hJ). The interface declaration would be superfluous for reports, since their interface is completely determined by the preceding objects in the data flow. The class RoadTrafficEmission defines a simulation experiment which assigns traffic demand to the given road network, calculates the emissions and visualizes them in terms of maps. The traffic demand (parameter trafficDemand) is passed on to the source TrafficDemand which provides the assignment model with one data item for each hour of simulation time. The assignment model then computes traffic flow and speed from the input demand, passing this data to the emission model. The emission model provides emission rates which are dependent on the composition of the traffic and the average speed of the current flow. Finally, the results are transformed into thematic maps by the visualization method EmissionVisualization.

Object-oriented specification in traffic simulation

experiment ~ RoadTrafficEmission specializes Experiment parameters

trafficDemand : DayProfile; roadNetwork : RoadNetworkTopology; geometry : RoadNetworkGeometry; /* further parameters omitted */ gng;

contains

sources

TrafficDemand of ~ EquidistantTimeSeries:

(dataObject, deltaTime; ) -> (data)

models

dataObject deltaTime

. - this. trafficDemand; := 1 [h]; }; ~;

AssignmentModel of class TrafficAssignment :

(roadNetwork; demand) -> (loads, velocities)

roadNetwork : = this. roadNetwork; }; EmissionModel of ~ VehicleEmission :

methods

( ; trafficFlow, velocities) -> (emissionRates) /* body omitted * / ~;

EmissionVisualization of ~ Visualization

(geometry; rates) -> (map) /* body and further methods omitted */ ~;

reports

EmissionMaps; /* further reports omitted */ ~;

end;

connects

~.

TrafficDemand.data t2 AssignmentModel.demand;

AssignmentModel.loads 12 EmissionModel.trafficFlow;

AssignmentModel.velocities to EmissionModel.velocities;

EmissionModel.emissionRates t2 EmissionVisualization.rates;

EmissionVisualization.map t2 EmissionMaps;

/* further connections omitted */ ~;

Figure 3 Example of a MSL experiment class specification.

341

342 Part Eight Object Orientation

MSL is capable of specifying much more complex experiments than we can present in this paper. For instance it offers the definition of higher order experiments which are comprised of subexperiments. This enables the modeller to compare different scenarios or concurrent models within one experiment specification. This is also the case for models which can be build up of any kind of submodel, so that arbitrary hierarchical networks of models and data processing methods can be specified.

5 CONCLUSION

MOBILE offers a flexible modelling and simulation system for both model builders and model users. It makes intensive use of object orientation for specification and management of complex models and experiments. For this reason we have developed the object-oriented specification language MSL (MOBILE Script Language), which offers a system-wide base for communication and object descriptions. Hence, the user becomes independent of particular programming languages used for the atomic simulators. It also enables the modeller to include arbitrarily given simulation models into the MOBILE model base. We hope that MOBILE contributes to a better understanding of complex traffic systems and supports decision making, in particular with respect to environmental issues.

6 REFERENCES

Hilty, L.M.; Page, B. and Martinssen, D. (1994) Designing a Simulation Tool for the Environmental Assessment of Logistical Systems and Strategies, in CSEIA 93 (eds. G. Guariso and B. Page), IFIP Transactions B-16, Proc. IFIP TCS/WGS. l1 Working Conference on Computer Support for Environmental Impact Assessment, Como, Italy, October 1993 North-Holland, Amsterdam.

Hilty, L. M.; Page, B.; Meyer, R. ; Mtigge, H.; Deecke, H. and Poll, M. (1996): Konzeption eines Systems zur Abschiitzung der Auswirkungen verkehrsbezogener MaBnahmen auf die Umwelt. Bericht des Fachbereichs Informatik Nr. FBI-HH-B-184/96, University of Hamburg.

Hilty, L. M. and Meyer, R. (1996) A flexible modelling and simulation system for environmental impact analysis in traffic planning, in Urban Transport and the Environment II, Computational Mechanics Publications, Southampton.

Hilty, L. M. and Mtigge, H. (1996) : Metadata in Model Base Systems, in Proc. International Seminar UFlS, March 20-22, 1996, Neuherberg

Mtigge, H. and Meyer, R. (1996) : MSL - Eine Modell- und Experimentbeschrei­bungssprache, in (eds. Ranze, C. et al. ) Intelligente Methoden zur Verarbeitung von Umweltinjormationen - 2. Bremer KI-Pfingstworkshop, Metropolis, Marburg

Rice, M.D. and Seidman, S.B. (1994) A Formal Model for Module Interconnection Languages. IEEE Transactions on Software Engineering , 20,88-101