Embed Size (px)
Citation preview
Implementation and Performance Analysis of InformationCommunication between Traf�c Simulation and Emission Estimation
Systems
A. G. M. ZAMAN
Master of Science ThesisStockholm, Sweden 2009
TRITA-ICT-EX-2009: 84
iii
Implementation and Performance Analysis of InformationCommunication between Traf�c Simulation and Emission Estimation
Systems
Master of Science Thesis in�Software Engineering of Distributed Systems�
byA. G. M. Zaman
Stockholm, Sweden 2009
Supervisor: Xiaoliang Ma, Ph.D.Centre for Traf�c Research (CTR), KTH
Examiner: Vladimir Vlassov, Associate ProfessorRoyal Institute of Technology (KTH)
School of KTH/ICT/SCSStockholm, Kista
Sweden
iv
v
Abstract
Transportation is one of the rapidly developing �elds and directly connected with the social
economic growth of a country. And at the same time, it is one of the major sources of emission
production, which has an enormous impact in the global environment and all the living beings. Cur-
rently using emission estimation methods are very expensive and use only once or twice a year. But
we can estimate emission in real time by using traf�c simulator along with the emission estimation
systems. The goal of this thesis is to develop performance ef�cient communication platform be-
tween the KTH-TPMA traf�c simulator and the emission estimation systems to measure the online
emission. To build up the communication platform different traf�c simulation models, architec-
ture of the KTH-TPMA traf�c simulator (i.e., object hierarchy and relationships, different object
interactions models, event handling mechanism, and the object update principals), communication
middleware for heterogeneous environments, and different emission estimation models are studied
and investigated. The communication platform is implemented using CORBA and SOA (i.e., Web
Service). In CORBA, synchronous and asynchronous (i.e., deferred synchronous) communication
methods are implemented. The traf�c simulator can exchange the information in three different
ways, i.e., individual, collection, and thread communication modes.
To �nd out the optimum communication method between these two applications different ve-
hicle demand and road network con�gurations are used to measure the communication time. And
evaluate these communication times to �nd out the ef�cient communication method. After evalua-
tion, we �nd that the CORBA asynchronous communication is the most ef�cient respect to remote
communication time. But synchronous communication is better for precise emission value.
Key Words: Simulation, Traf�c simulator, Emission prediction application, Emission predic-
tion models, Communication, Synchronous & Asynchronous Communication, CORBA, Service
Oriented Architecture (SOA), Web Service, and Vehicle demand.
vi
Abstract in Swedish
Transport är en av de snabbt växande områden och i direkt sambandmed den sociala ekonomiska
tillväxten i ett land. Och samtidigt är det en av de största källorna till utsläpp produktion, som
har en enorm påverkan på den globala miljön och alla levande varelser. För närvarande använder
metoder för skattning av utsläpp är mycket dyra och endast använda en eller två gånger per år. Men
vi kan beräkna utsläppen i realtid med hjälp av tra�k simulator tillsammans med uppskattning sys-
tem. Målet med detta examensarbete är att utveckla prestanda effektiv kommunikationsplattform
mellan KTH-TPMA tra�k simulator och uppskattning för att mäta online utsläpp. För att bygga
upp den kommunikationsplattform Olika simuleringsmodeller, arkitektur av KTH-TPMA tra�k
simulator (dvs objekt hierarki och relationer, olika objekt interaktioner modeller händelse hanter-
ing mekanismen, och objektet uppdatera huvudmän), kommunikation middleware för heterogena
miljöer, och olika uppskattning modeller studeras och undersökas. Meddelandet plattform genom-
förs med hjälp av CORBA och SOA (dvs. Web Service). I CORBA, synkron och asynkron (dvs
uppskjutna synkron) kommunikationsmetoder genomförs. Tra�ken simulator kan utbyta informa-
tion på tre olika sätt, det vill säga enskilda, insamling och tråd meddelande lägen.
För att ta reda på det optimala sättet mellan dessa två ansökningar olika fordon efterfrågan
och vägnätet kon�gurationer används för att mäta kommunikation temne. Och utvärdera dessa
kommunikation gånger för att ta reda på effektiv kommunikation metod. Efter utvärdering �nner vi
att CORBA asynkron kommunikation är det mest effektiva avseende på fjärrkontrollen meddelande
temne. Men synkron kommunikation är bättre för exakt utsläppsvärdet.
Nyckelord: Simulation, Traf�c simulator, Utsläppsfaktor prognos ansökan Utsläppsfaktor prog-
nos modeller, kommunikation, synkron och asynkron kommunikation, CORBA, Service Oriented
Architecture (SOA), Web Service och fordon efterfrågan.
vii
Acknowledgement
I would like to take this opportunity to thank my thesis supervisor Xiaoliang Ma, Ph.D. for his
invaluable support and time. Always he helps to �nd a solution whenever problems arise. And
also thanks to the Centre for Traf�c Research (CTR) for initiating this thesis project. Thanks to
Zhen Huang, my thesis colleague, for his support and being passing a good time. Finally, I want
to express my gratitude to my parents and my beloved wife.
viii
Table of Contents
Abstract .................................................................................................................................................................................................................vi
Abstract in Swedish ...................................................................................................................................................................................vii
Acknowledgement ....................................................................................................................................................................................viii
List of Tables.....................................................................................................................................................................................................xi
List of Figures ................................................................................................................................................................................................xii
Chapter 1 Introduction.......................................................................................................................................................................11.1 Introduction.....................................................................................................................................................................................11.2 Motivation / Emission Computation ............................................................................................................................21.3 Problem statement......................................................................................................................................................................41.4 Tasks.....................................................................................................................................................................................................51.5 Methodology ..................................................................................................................................................................................61.6 Evaluation Criteria.....................................................................................................................................................................71.7 Preliminary studies....................................................................................................................................................................81.8 Thesis Outlook..............................................................................................................................................................................81.9 Contribution....................................................................................................................................................................................9
Chapter 2 Literature Review......................................................................................................................................................102.1 Introduction..................................................................................................................................................................................102.2 Computer Simulation............................................................................................................................................................102.2.1 Traf�c Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Emission Estimation Models ..........................................................................................................................................142.3.1 POLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Mobile6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 KTH-TPMA Traf�c Simulation Architecture....................................................................................................172.4.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.3 Represent Traf�c Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.4 Object Oriented Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.5 Vehicle/Driver-Vehicle Unit (DVU) Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.6 Simulation Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 3 Distributed Simulation System Design & Implementation .......................................................283.1 Introduction..................................................................................................................................................................................283.2 Distributed Computing ........................................................................................................................................................283.2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 SOA & Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Design and Implementation.............................................................................................................................................323.3.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.2 Road Network Con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ix
3.3.3 CORBA Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.4 Web Service Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 4 System Evaluation ....................................................................................................................................................474.1 CORBA Synchronous Communication (Same Computer)......................................................................474.1.1 A Single Lane Road Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.2 A Large Intersection Road Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 CORBA Synchronous Communication (Different Computers)...........................................................504.2.1 A Single Lane Road Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.2 A Large Intersection Road Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 CORBA Asynchronous Communication...............................................................................................................544.4 Web Service Communication.........................................................................................................................................55
Chapter 5 Conclusion & Future Research .......................................................................................................................56
References.........................................................................................................................................................................................................58
Appendix: A Delphi format of the WSDL �le .............................................................................................................62
Appendix: B Lane Segment Emission................................................................................................................................69
Appendix: C Emission Comparision ...................................................................................................................................70
x
List of Tables
Table 3.1 Road Network's Lane Segment Speci�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 3.2 Road Network's Vehicle Generator Speci�cation . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Table 3.3 Description of the methods of the ConnectEmission class . . . . . . . . . . . . . . . . . . . 40
Table 4.1 Vehicle information exchanging time in different modes (Single, Collection,and Thread) with the emission estimation application in different Vehicledemand for a small road network (same computer) . . . . . . . . . . . . . . . . . . . . . . . . . 49
Table 4.2 Vehicle information exchanging time in different modes (Single, Collection,and Thread) with the emission estimation application in different Vehicledemand for a large intersection road network (same computer) . . . . . . . . . . . . . . . 51
Table 4.3 Vehicle information exchanging time in different modes (Single, Collection,and Thread) with the emission estimation application in different Vehicledemand for a single lane road network (different computers) . . . . . . . . . . . . . . . . . 52
Table 4.4 Vehicle information exchanging time in different modes (Single, Collection,and Thread) with the emission estimation application in different Vehicledemand for a large intersection road network (different computers) . . . . . . . . . . . . 53
Table 4.5 CORBA Synchronous and Asynchronous communication time table . . . . . . . . . . 54
Table 4.6 Web Service and CORBA communication time comparison . . . . . . . . . . . . . . . . . 55
xi
List of Figures
Figure 1.1 Carbon dioxide emissions from the road-transport sector in Sweden in 1990 and2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Figure 1.2 Online emission estimation using traf�c simulation and emission estimationsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 1.3 The sequence follow during the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 2.1 Simulation clock's next-event time advance updates approach . . . . . . . . . . . . . . . 11
Figure 2.2 Simulation clock's �xed-increment time advance update approach . . . . . . . . . . . 11
Figure 2.3 Flow chart of the traf�c simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 2.4 Represent traf�c infrastructure in the simulation model . . . . . . . . . . . . . . . . . . . . 20
Figure 2.5 Basic Objects that form Traf�c System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 2.6 Simpli�ed Class diagram of the traf�c simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2.7 Driver behaviour in a traf�c system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2.8 Reference vehicle can be in the free area, stable area or no entry area . . . . . . . . . 24
Figure 2.9 Lane changing gap acceptance model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2.10 A sample double link list of traf�c objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2.11 The interface of KTH-TPMA traf�c simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 3.1 Basic CORBA architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 3.2 Basic web service architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 3.3 A sample XML road con�guration �le with segment de�nition . . . . . . . . . . . . . . 36
Figure 3.4 Use case & class diagram of the loading process of the XML road networkcon�guration �le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 3.5 IDL �le for the CORBA communication (EmissionTPMA.idl) . . . . . . . . . . . . . . 38
Figure 3.6 Class diagram of the CORBA communication between traf�c simulator andemission application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
xii
Figure 3.7 Share individual vehicle information in a synchronous way . . . . . . . . . . . . . . . . . 42
Figure 3.8 Share individual vehicle information by thread in a synchronous way . . . . . . . . . 43
Figure 3.9 Share collection of vehicle information in a synchronous way . . . . . . . . . . . . . . . 44
Figure 3.10 Class diagram of the web service communication . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 4.1 System evaluation �ow chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 4.2 A single lane road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 4.3 Vehicle information sharing time in different communication mode for a singlelane road network (single computer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 4.4 A large intersection road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 4.5 Vehicle information sharing time in different mode for a large intersection roadnetwork (same computer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 4.6 Vehicle information sharing time in different communication mode for a singlelane road network (different computers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 4.7 Vehicle information sharing time in different communication mode for a largeintersection road network (different computers) . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure B.1 Lane Segment Emission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure C.1 Emission Comparision in Different Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
xiii
Chapter 1 Introduction
1.1 Introduction
Transportation is de�ned as the movement of the people and goods from origins to destinations.
It is about the mobility, ef�ciency, reliability, and safety of the transport of the people and goods
[8]. Transport is one of the most rapidly developing �elds and is directly connected with the
social economic growth of a country. It connects the different parts of a country through different
routes which have a great in�uence both how and where peoples are living. It is also provide
access to the natural resources which helps countries to grow faster. The ef�cient movement routes
between natural resources, territories, and countries reduce the cost of production of goods which
is one of the key factors of the economic growth. But this increasing rate of transportation places
huge pressure to the global environment, and all living beings including human. And it is one of
the most signi�cant sources of pollution in the urban environment, and also for the global CO2
emissions. But we can't replace the transportation because it is part of our daily life and the
country's production chain. The importance of the transportation sector is indicated by the sector
production which is 10% of the GDP of the European Union and more than 10 million people are
working in this sector [2].
The Figure: 1.1, which is taken from the Swedish Road Administration (Vägverket) shows the
carbon dioxide (CO2) emission by the road traf�c in 1990 and 2007. In 2007 the CO2 is increased
by 12% compared to 1990. But if the amount of traf�c was constant between 1990 and 2007 then
the CO2 emission is reduced by 8% because of new petrol and diesel engine cars consumed an
average of 7.31/100 km (181 g CO2/km) in 2007, compared with 7.81/100 km (189 g CO2/km)
in 2006. On the other hand the bio fuels consumption in the road- transport is increased from 3.5
percent in 2006 to 4.5 percent in 2007 [3]. Even though there is a reduction of fuel consumption
and increasing rate of the bio fuels, the emission is increasing because of the high growth rate
of traf�c. This air pollution also caused 6% of total mortality or more than 40,000 attributable
cases per year. About half of all the mortality caused by air pollution was attributed to motorized
traf�c, more than 25,000 new cases of chronic bronchitis (adults); more than 290,000 episodes of
bronchitis (children); more than 0,5 million asthma attacks; and more than 16 million person-days
of restricted activities [4].
Predicting the road traf�c emission of vehicle require the detailed traf�c information, such as
1
Milli
onto
nesp
erye
ar
Figure 1.1: Carbon dioxide emissions from the road-transport sector in Sweden in 1990 and 2007
vehicle speed, acceleration, vehicle type, vehicle age, road curve pro�les, and also the location
speci�c factors, such as congestion levels, road geometry. But this detailed information of individ-
ual vehicle is not easy to collect from the real life traf�c system. Therefore, measure emission of
individual vehicle is crucial. Currently vehicle emissions are measured annually of even less fre-
quently [5]. So to measure the online vehicle emission in a cost ef�cient way is dif�cult. But traf�c
simulation could be use to predict the online vehicle emission, because of information availability
of vehicles, road geometry information, and vehicle interactions for different levels of congestions.
By using the traf�c simulator the dynamics of traf�c can be simulated on different road network
and emission of the vehicles or road network can be accurately estimated in a cost ef�cient way.
In this thesis, a microscopic traf�c simulator is used to simulate the road traf�c to different road
network. And an emission estimation application is used to estimate the online emission of the ve-
hicles of road network using vehicle information generated in simulation. This thesis is devoted
to implement and performance analysis of vehicles information communication between traf�c
simulator and emission estimation system.
1.2 Motivation / Emission Computation
Vehicles are one of the major sources of air pollution. In Finland, traf�c generates about 55%
of total emissions of carbon monoxide (CO) and nitrogen oxides (NOx). And in the United States,
cars, trucks, and off-road vehicles are currently responsible for about 40 to 50% of the hydrocarbon
2
(HC) or volatile organic compounds (VOC) emissions, 50% of the NOx emissions, and 80 to 90%
of the CO emissions [5]. To reduce the emission different actions could be taken e.g., increase
the bio fuels consumption, reduce engine fuels consumption, improve ef�ciency of the engine, and
develop sustainable road infrastructure and management system to reduce emission.
Reliable data to estimate traf�c emission is crucial. There are different emission estimation
models exist. The most common way is to use the experimental data obtained from the laboratory
measurement performed on selected vehicles in different simulated driving conditions. COPERT
(Computer program to calculate emissions from road transport) is such a model which is one of
the most extensive traf�c emissions modelling method uses in the European context. To measure
emission, the COPERT project uses vehicle travel speed, vehicle types (e.g., passenger cars, vans,
trucks, etc.), fuel consumption type, engine capacity, and the emission legislation category [6].
The COPERT model uses the historical data to estimate the emission. And CAL2QHC is another
widely accepted model and used by the California Air Resources Board and US Environmental
Protection Agency [7]. In this method, data is collected by placing sensors to the roadside which
detect CO and NO2. The collected data is stored to the hard disk to estimate emission. Although
all of these above methods are widely used for measuring traf�c emission but all are depend on
certain situation. The COPERT method uses historical data which is very time consuming and
expensive to collect. And in the CAL2QHC, data collection is depending upon the sensor which is
also expensive and not easy to implement all the road network. Using these methods emission is
normally estimated once a year or even less.
Even though these expensive emission computation methods are widely used but using these
it is not possible to estimate the real time traf�c emission. As a result, need for online emission
estimation tool for the road traf�c is becoming more crucial for the design and evaluation for the
pollution control strategies, and develop sustainable road network to reduce emission reduction.
Figure: 1.2 shows the basic architecture of how we can measure online traf�c emission (i.e., emis-
sion of lane segment, and individual vehicle) by using the traf�c simulation tool along with the
emission estimation application. This emission computation technique is better than COPERT and
CAL2QHC in several ways. First of all, by using traf�c simulation tool we can simulate vehicles
to different traf�c road network which gives us the simulated view of that traf�c road network.
Using this simulated vehicles information, we can compute emission through different emission
estimation models, which is cost ef�cient, gives online view of traf�c emission, and helps to de-
sign sustainable road network for producing low emission. Secondly, we want to separate this
3
Figure 1.2: Online emission estimation using traf�c simulation and emission estimation systems
emission estimation system from the traf�c simulation application (i.e., distributed application)
because, traf�c simulation is itself a costly process, and it needs to run real time to simulate ve-
hicles in real time. So integrates the emission estimation application inside the traf�c simulation
application would reduce performance and hence we may not able to view the traf�c emission
in real time. On the other hand, by making these applications distributed we can increase per-
formance, and different emission estimation models could be implemented easily. And in future,
this emission estimation application could be adopts with other traf�c simulation application. The
motivation of this thesis is to develop a communication framework between the traf�c simulation
application and the emission estimation application. And adopt the traf�c simulation application so
that it can exchange required online vehicle information (i.e., road network con�guration, commu-
nication method, simulation clock time, vehicle speed, acceleration/deceleration, position, type)
with the emission estimation application.
1.3 Problem statement
To measure the online emission, we use the KTH-TPMA (Traf�c Performance on Major Ar-
terials) traf�c simulation application with the emission estimation application. The KTH-TPMA
traf�c simulator is developed in Delphi and the emission estimation application is another part
of the whole project [1], which will be develop in Java. The KTH-TPMA is a complex traf�c
simulation application, and it needs to be understood the design and architecture of the vehicle
simulating mechanisms, the loading process of road network and other objects, and the simulation
clock for adopting this application with the emission estimation system. After adopting, we need
to exchange the simulated vehicle information in this heterogeneous environments. To exchange
the vehicles information, we build up the communication framework (Figure: 1.2) with Common
Object Request Broker Architecture (CORBA ) and Service Oriented Architecture (SOA) tech-
nologies. And to exchange on-line vehicle information, different information exchange methods
4
are implemented for faster communication.
1.4 Tasks
The primary task of this thesis is to develop different vehicle information exchange framework
between the traf�c simulator and the emission prediction application, which have to be fast enough
to measure the emission in real time. To carry out this task, I need to study different traf�c sim-
ulation models, and the architecture of the KTH-TPMA traf�c simulator, i.e., hierarchy of traf�c
objects, different object interaction models, and different event handling mechanisms. To imple-
ment the communication framework, different middleware architectures are studied and tested for
the heterogeneous environment (e.g., CORBA, Web Services). For CORBA different ORBs (Ob-
ject Request Broker) are studied and tested for Java and Delphi programming languages. Web
Service speci�cations (e.g., Service Oriented Architecture) are also studied and tested. Differ-
ent emission estimation models are studied to know what different kinds of vehicle information is
required by the emission estimation application. To estimate emission, the emission estimation ap-
plication requires the road network de�nition model in a structured way (i.e., with road segment
de�nition), so that the emission application can estimate the emission in a practical way. It requires
reformation of the current road de�nition �le with the road/lane segment de�nition and build up
the loading process for the new road de�nition �le, which is XML based. To exchange the vehicle
information ef�ciently different communication methods are implemented and evaluated. These
above tasks could be divided as follows:
� Study and understand the detail architecture of the KTH-TPMA traf�c simulator, which
includes:
� Study different traf�c simulation models
� Hierarchy of traf�c objects and its relationships
� Different object interaction models
� Event handling mechanisms and object update principals
� Study different emission estimation models
� Study different communication technologies which are �t for high performance commu-
nication in heterogeneous environment
� Study and investigate different CORBA ORBs for Java and Delphi
5
� Study and investigate the Web Services speci�cations for Java and Delphi
� Reformat the road network de�nition model, and convert it to the XML format with the
road/lane segment de�nition
� Load the new road network de�nition model inside the simulator
� Build up the communication platform using CORBA, and exchange the online vehicle
information in three different ways:
� Exchange individual vehicle information
� Exchange collection of vehicle information
� Exchange vehicle information by thread
� And also build up the SOA communication platform to exchange the online vehicle in-
formation with the emission prediction application, using
� Evaluate the performance of the communication platform in different road networks and
different vehicle demands.
1.5 Methodology
The Figure: 1.3 shows the speci�c analysis technique of the whole thesis activities and tasks.
Below is the description of the process.
� The KTH-TPMA traf�c simulator was developed in Delphi and the emission prediction
system is in Java. To establish the CORBA communication between these two applica-
tions, different ORBs (Object Request Broker) need to explore
� To establish the SOA communication between these two application different SOA archi-
tectures are explored, So that it �t for both Delphi and Java
� Test CORBA and SOA communication with different technologies to determine the ef�-
cient one
� Study and investigate the system architecture, different object behavioral models, object
interaction models, event handling mechansims, and the object updating principals of
KTH-TPMA traf�c simulation application
� Adopt the road network con�guration �le to incorporate road segment objects which is a
6
Exploredifferent ORBfor Java andDelphi
Understand &Analyze theKTHTPMAtraffic simulator
Design andImplementationof thecommunicationframework
Test CORBA &Web Service
Explore Delphiand Java WebServiceArchitecture
Performanceanalysis
1 43
2
7
5
6
Adopt the XMLroad networkconfigurationfile
Figure 1.3: The sequence follow during the thesis
composition of lane segment objects. It helps to measure & view emission in a practical
way
� System design and implement of the distributed computing framework to integrate traf�c
simulator and emission estimation application, which includes:
� Develope different methods for exchange online vehicle information
� Study different emission estimation models to �nd out the list of essential information
that is need to exchange
� Finally, compare and analyzing the communication ef�ciency under CORBA & SOA in
different conditions and environments
1.6 Evaluation Criteria
The goal of the communication platform is to exchange online vehicle information with emis-
sion estimation application through CORBA & SOA. To determine the ef�cient CORBA & SOA
communication for exchanging vehicle information, different information exchange strategies are
implemented. In CORBA communication, synchronous and asynchronous information exchange
methods are evaluated. And in each method three different communication ways (i.e., exchange
7
vehicle information individual, collectively, and by thread.) are evaluated to �nd out the commu-
nication ef�ciency. And for the SOA communication, Web Service communication technology
is implemented to evaluate and measure the communication ef�ciency. And �nally, compare the
results of these above communication methods to determine the ef�cient communication method.
1.7 Preliminary studies
To carry out this thesis project, pre-studies in the following topics are conducted
� CORBA technologies (IDLJ, JacORB, VisiBroker, MTDORB). To establish the commu-
nication between the traf�c simulator (developed in Delphi) and the emission prediction
system (developed in Java) different ORB is studied
� Service Oriented Architecture. To implement the SOA, Web Services information ex-
change technology is used
� Delphi. As the KTH-TPMA traf�c simulator is developed in Delphi. So it requires know-
ing the Delphi computer language
� Different Traf�c Simulation Models. To understand the traf�c simulation technique dif-
ferent traf�c simulation models are studied
� KTH-TPMA traf�c simulator architecture. Adopt the KTH-TPMA to exchange online
vehicle information with emission estimation application Before adopting the traf�c sim-
ulator it needs to understand how it simulates vehicles to different road network
� Emission estimation models
1.8 Thesis Outlook
This is thesis is consist of �ve chapters. The outlook of the thesis is divided as follows:
� Chapter 1 introduces the motivation, problem statement, tasks, methodology, and evalua-
tion criteria
� Chapter 2 explains the background of the thesis, e.g. computer and traf�c simulation,
different traf�c simulation models, architecture of the KTH-TPMA traf�c simulator, and
the emission prediction models for the road traf�c
� Chapter 3 illustrates the design and implementation of the information exchange archi-
tecture and methods
� Chapter 4 evaluates the performance of the KTH-TPMA traf�c simulator
8
� Chapter 5 discusses the conclusion and future research
1.9 Contribution
This project work has been carried out under close collaboration with Zhen Huang, who is from
the Uppsala University and responsible for develops the emission estimation application [1].
9
Chapter 2 Literature Review
2.1 Introduction
This chapter will introduce the readers regarding the different kinds of traf�c simulations, and
the architecture of the KTH-TPMA traf�c simulation application. And also the emission models
which are used by the emission estimation application to estimate the emission.
2.2 Computer Simulation
Computer simulation is a comparatively recent addition to the family for modeling methodolo-
gies. And it is perhaps the most widely used (and, unfortunately, misused) method today [51]. It is
now widely used computer program for the decision makers to make decisions. Through using the
simulation it is possible to analyze the behavior of system that is not possible to predict without
implementation. It can be de�ned as, �Simulation is the process of designing a model of a real sys-
tem and conducting experiments with this model for the purpose of understanding the behavior of
the system and/or evaluating various strategies for the operation of the system� [9]. Simulation ap-
plications are used in many different contexts, because they are offering a number of advantages,
e.g., industrial production systems, natural system, traf�c engineering, etc.
� Using simulation new designs and plans could be tested without implement it
� As simulation application can control time so using it for long time helps to predict the
future behavior of the systems
� And implement different models inside the simulation help us to predict the different
situation
In computer simulation the system states are changing over time. This change of the state
variable could be divided in two different ways [51].
� Fixed-increment time advance approach (synchronous model of time)
� Next-event time advance approach (asynchronous model of time)
In the next-event time advance approach the simulation clock is �rst initialized to zero. In the
Figure: 2.1, the simulation clock is advanced to the next step after receiving �rst event, and the state
of the system is also updated at the same time. In this method the simulation clock is advancing
from one event time to another event time until stop. As the state change is depend only event time
10
Time
e0 e2e1
T2T1
Event
Simulation clock
T0
Figure 2.1: Simulation clock's next-event time advance updates approach
RealTime
T0
e0 e2e1
T2T1
Event
Simulation clock
T3dt dtdt
Simulation clock update time
Figure 2.2: Simulation clock's �xed-increment time advance update approach
so the periods of inactivity are skipped over by jumping the clock from event time to the next event
time.
In the �xed-increment time advance approach the simulation clock is advanced in increments
of exactly �t time units. �t is a small amount of time, and the value of is depend on the simulation
type. In each update of the clock a check is made to determine whether any events have occurred
during this time �t. If events are happened within that �t time then the system states are updated
accordingly. In the Figure: 2.2, where the curved represent the advancing of the simulation clock
and the simulation clock update after the �xed interval of �t time. An event occurs in the time
interval between T0 and T1 but it is considered as happened at T1 time. And there is no event
happens between the time interval T1 and T2, but the simulation checks to determine this. Within
the time interval T2 and T3 events e1 and e2 happened but both events are considered to occur at
time T3.
2.2.1 Traf�c Simulation
Traf�c simulation is a computer program which mimics the real world traf�c in cybernetic
world. It provides a simulated view of the real life traf�c situation in the computer, depending
upon traf�c simulation models.11
The real world traf�c system is very complex so it is hard to test, evaluate and demonstrate
before implementation. For these reasons traf�c simulator is used in different �elds, both for
researchers and traf�c policy and management makers. Through using simulation it is possible
to visualize the future traf�c condition. So it helps the decision makers to make decisions on
evaluation and design of traf�c control and management systems, traveler information systems,
impact of sensor technologies, safety studies, environmental (e.g. emission and noise) impact
studies, testing of new technologies for which no prior operational experience exists, etc. [14].
Traf�c simulation models could be divided into four types.
� Macroscopic Model
� Mesoscopic Model
� Microscopic Model
� Nanoscopic Model
Macroscopic Model
Macroscopic simulation model simulate traf�c �ow, taking into consideration cumulative traf�c
stream characteristics (speed, �ow, and density) and their relationships to each other. The simu-
lation in a macroscopic model takes place on a section-by-section basis rather than by tracking
individual vehicles. It can be used to predict the spatial and sequential extent of congestion caused
by traf�c demand or incidents in a network; however, it cannot model the interactions of vehi-
cles on alternative design con�gurations [10]. FREFLO [38], NETVACI [39], KRONOS [40],
METANET [41], and METACOR [42] are the example of macroscopic traf�c simulation model.
Mesoscopic Model
Mesoscopic models combine the properties of both microscopic and macroscopic simulation
models. Mesoscopic models are somewhat less consistent than microscopic model, but are superior
to some other traf�c analysis techniques. These models simulate individual vehicles, but describe
their activities and interactions based on aggregate (macroscopic) relationships. It can simulate
the routing of individual vehicles equipped with in-vehicle, real-time travel information systems.
The travel times are determined from the simulated average speeds on the network links, which, in
turn, are calculated from a speed-�ow relationship. Typical applications of mesoscopic models are
evaluations of traveler information systems [10]. METROPOLIS [43], DYNASMART [44], and
INTEGRATION [45] are the example of mesoscopic traf�c simulation model.
Microscopic Model
12
Microsimulation is the dynamic and stochastic modeling of individual vehicle movements within
a system of transportation facilities. Each vehicle is moved through the network of transportation
facilities on a split second by split second basis according to the physical characteristics of the ve-
hicle (length, maximum acceleration rate, etc.), the fundamental rules of motion (e.g., acceleration
times time equals velocity, velocity times time equals distance) and rules of driver behavior (car
following rules, lane changing rules, etc.) [11]. VISSIM [46], MITSIMLab [47], INTRAS [49],
FRESIM [50], and CORSIM [48] are the examples of the microscopic traf�c simulation model.
Microscopic Simulator offers a number of key bene�ts over other traf�c simulator techniques:
� A detailed real time and graphical user interface of the traf�c system
� Through modeling the individual vehicles in different road networks provides better illu-
sion of real road traf�c
� Nanoscopic model can be further implement in side the Microscopic model
� Different driver models can be implement inside
In this thesis the KTH-TPMA traf�c simulator is used, which is a microscopic traf�c simulator.
It simulates the individual vehicle through the road infrastructure with the updated characteristic
e.g. vehicle speed, acceleration, deceleration, lane change, route choice, etc. These vehicles char-
acteristics are determined by the models. These models belongs to two categories: models that
capture traf�c dynamics (e.g. speed, acceleration/deceleration and lane changing) and models that
capture travel behavior (e.g. route choice and response to traveler's information) [14].
Nanoscopic Model
In the above described traf�c simulation models, there are no separation between the driver and
vehicle models. In these models, the driver and vehicle are represented as a single object, which
is called the Driver Vehicle Unit (DVU). Because of that there is no interaction between them, so
the �vehicle� can always execute whatever the �driver� wants exactly and timely. In real life traf�c
system, the driver interacts with the surrounding traf�c environment and makes decisions which
are executed by the vehicle. But in these simulation models, the driver model receives the input
and makes decisions which are then passed to the vehicle model, and it respond accordingly. The
execution of the instructions by the vehicle is not always responds exactly and timely as desire
because due to the properties of the vehicle [12]. Nanoscopic model is special kind of microscopic
model where the driver and vehicle are modeled as separate models. The rules in microscopic
model are derived from fundamental safety requirements, while the rules in nanoscopic are derived
13
from the knowledge of human perception and cognition [13].
2.3 Emission Estimation Models
Emission estimation models are commonly used to provide traf�c emission information for the
prediction and management of air pollution levels near roadways [15]. These emission estimation
models could be classify at different levels i.e., ranging from road links to city-wide road networks
[16].
Vehicle emissions have been measured in different ways, e.g., in laboratories, and in �eld exper-
iments. But these measured data are only useful in the measured context, e.g., vehicle information,
geographical condition, and time. As a consequence, traf�c simulation models and/or emission
simulation models are commonly used to overcome these limitations [17]. These emission models
are useful to estimate the emission of the large road network and also to predict the future emis-
sion. It is also essential for effective air quality management and policy making, which requires the
identi�cation, quanti�cation, forecasting and control of all air pollutant emission sources [18],[19].
The necessity of the emission estimation [16], [20] is given below:
� Evaluation of existing air quality control strategies
� Assessment of effectiveness of alternative policy options
� Assessment of importance of road traf�c to overall air pollution
� Development of transport policies
� Identi�cation of high priority areas or locations with severe air pollution
� International obligations/ negotiations e.g. greenhouse gas emission
� Forecasting of air pollution
There are different emission estimation models exists. To to estimate the emission of vehicles
POLY and Mobile6 models are implemented in this project.
2.3.1 POLY
POLY is a microscale emission model. It was developed by both Polytechnic University and
Texas Southern University. This emission model was developed in two steps; at �rst, it classi�ed
the vehicles into different categories based on the vehicle size (i), model year (j), and emitter
type (k). The proportion pi;j;k for each category (i; j; k) of the vehicles was derived based on the
national level vehicle distributions. And this classi�cation level is based on the national level of
14
vehicle distribution. Classifying the vehicles into different categories is necessary because it is
impossible to develop separate emission models for each type of vehicle. So the vehicles, which
have relatively homogeneous characteristics, could be classi�ed into same category. Thus this
model classi�ed the vehicles into 41 groups, made before 1997 [21].
And, in the second step, microscale emission models, ei;j;k;m(t), were developed for each emis-
sion type m (e.g., CO, HC, or NOx) and vehicle category (i; j; k); which is developed in the �rst
step. So, the emission type m that is produced by a vehicle with size i at time t, ei;m(t), can be
estimated as [21]:
ei;m(t) =P
j
Pk ei;j;k;m(t):pi;j;k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (1)
From the above Equation (1), we �nd that the vehicle size is the only parameter that is directly
related to emission of type m for a vehicle size i at a speci�c time t. So the m type emission
for a vehicle with size i is an average value that combines the emissions that are produced by
the vehicles in all the subcategories corresponding to vehicle size i. And to measure the m type
emission for a vehicle group (i; j; k) at time t, i.e., ei;j;k;m(t), was represented as:
ei;j;k;m (t) = �0 + �vV (t) + �v2V 2 (t) + �v3V 3 (t) + �T�T�(t) + �T��T��(t) + �AtA (t) + ... +
�At�9A (t� 9) + �WW (t) + �i;j;k;m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (2)
Where:
�0 = Constant,
�x = Coef�cient for variable x,
V (t) = Speed (m.p.h.) at time t,
T�(t) = Continuing acceleration time (second) up to time t since its inception,
T��(t) = Continuing deceleration time (second) up to time t since its inception,
A (t) = Combined acceleration or deceleration at current time t,
A (t� 1) = Combined acceleration or deceleration at time t� 1,A (t� 9) = Combined acceleration or deceleration at time t� 9,W (t) = Speci�c power at time t, which is equal to the product of V (t) and A (t) ;
�i;j;k;m = error term.
In the Equation (2), four factors are related to measure the emission, these are tractive power,
grade, time dependence, and kinetic power. Tractive power is represented in the model by the
speed value V (t) in at a speci�c time t, square of the speed V 2(t) at that time t, and the cube of the
speed V 3(t) at that time t. The grade factor is related to the acceleration or deceleration (m=s2)at a
speci�c time with the road segment grade information. Time dependence in emission measurement
15
is related with acceleration and deceleration of preceding time periods, not the acceleration or
deceleration at the current time, that has the most obvious impact on the emission at time t. In the
Equation (2), the notion A(t); :::A(t � 9) represents the combined accelerations or decelerationin the current and the immediate past time periods. And, two additional variables are introduced
to represent the duration of continuous acceleration or deceleration since its inception. These are
represented as T�(t) and T��(t). And the kinetic power is considered in the model by using the
variable of Speci�c Power (SP ), since Speci�c Power multiplied by vehicle mass is the kinetic
power [21].
2.3.2 Mobile6
Mobile6 was developed by the US Environmental Protection Agency (EPA). This model divides
the vehicles into 28 different classes from passenger cars to heavy trucks. And this model also
divide the roads into different types e.g. freeway, ramp, artery, and local. To measure the emission
it considers four types of information.
� Vehicle �eet characteristics
� Fleet activity characteristics
� Fuel characteristics
� Meteorological parameters
Vehicle �eet characteristics depend upon the information of the vehicle age, vehicle total travel
distance in mile, diesel & natural gas fraction information, inspection & maintenance description
and the anti-tempering inspection program.
Fleet activity characteristics describe the information of the vehicle speed distribution by hour
and roadway, vehicle miles travel to the particular road way, engine information, average trip
length, and the total miles traveled by vehicle class.
The fuel characteristics contain the information of the raid vapor pressure, sulfur content and
the oxygenate content.
Meteorological parameters include the time (e.g., January, July), temperature, humidity and the
attitude information [22].
The MOBILE6 emission model uses the Equation (3) to estimate the emission [52].
Ei =P
c
Pl V KTl:fc:BERi(sl;c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (3)
Where:
Ei = Denote the total emissions of a type i or the total fuel consumption for a given time period
16
and a given road network,
c = Vehicle category,
l = is the index of a sub-network (i.e., a single link or a set of links) characterized by an average
speed sl,
V KTl = total kilometers or miles traveled in a given time period in a speci�c sub-network l,
fc = fraction of vehicles of category c,
BERi(sl;c) = is the base emission rate per kilometer or mile for a type i. BERi(sl;c) is de-
termined from standard driving cycles at a particular average speed sl, for each vehicle category
c. This base emissions are also called cycle emissions, and non-base emissions are called off-
cycle emissions. The BERscan be corrected at different speeds with the used of speed correc-
tion factors (SCFs). The correction factors also include different conditions, i.e., cold-start and
facility-speci�c models of operation.
2.4 KTH-TPMA Traf�c Simulation Architecture
2.4.1 Introduction
The project �Traf�c Performance on Major Arterials� (TPMA) was initiated and �nanced by
Swedish National Road Administration (SNRA) between 1997 to 2001. In this project, a previous
traf�c simulation tool HUTSIM (a traf�c simulator which was developed at department Laboratory
of Transportation Engineering at the Helsinki University of Technology in Finland), was further
developed and calibrated for the use of Swedish road networks [24]. HUTSIM was �rst developed
to simulate the signal controlled/non-signalized intersections and small road network consisting
of several intersections. It also includes different vehicle types and pedestrians and bicycles. As
HUTSIM was based on the DOS platform, the researchers at Center for Traf�c Simulation Re-
search (CTR) in Royal Institute of Technology (KTH) in Sweden have tried to transfer the TPMA
into the Windows Platform in 2002 & 2003 [23]. KTH-TPMA is a microscopic traf�c simulator,
its design and architecture is described below.
2.4.2 Design overview
Before discussing the Object Oriented Architecture of the traf�c simulator, it is necessary to
provide a general view of the real life traf�c system. This will help to identify and classify the
components of a traf�c system. A traf�c system consist of road network, driver-vehicle unite
(DVU), stop stations, toll plazas, traf�c signals, traf�c signs, and Intelligent Transport System
(ITS). These components could be divided into two parts, e.g., dynamic and static part. The DVU,
traf�c signals, and the ITS are the dynamic parts; and road network, stations, toll plazas, traf�c
17
signs are the static parts. To simulate the vehicles across traf�c network, it iteratively makes
decisions of vehicles update (e.g., speed, acceleration, deceleration, lane change) in a speci�c
frequency. To update each vehicle, it requires interactions between the dynamic and the static part
of the traf�c components. And these interactions are processed by different behavioral models
inside the simulation objects to make vehicle update decisions. In Figure: 2.3, it shows �owchart
of microscopic traf�c simulation [25]. The description of the �owchart is given below:
� First the simulator is loading the initial simulation parameters and the road network con-
�guration information
� Update the state of the traf�c signals, signs, and incidents
� Update the routing tables with the origin and destination information
� Create vehicles with the origin-destination (OD), and initialize it with other desired para-
meters
� Load the vehicles from a queue to the road network
� Update the vehicles acceleration or deceleration and make lane change decision
� Advance vehicles from the current position to the updated position. And if the sensor is
activated then it recorded corresponding vehicle information, e.g. speed, average vehicle
speed, average vehicle �ow, etc.). If vehicle reached at the end of a lane then it is moved
to the next lane but if it reached to its destination then the vehicle is removed from the
road network
� Update the view of simulated road network
� Update the simulation clock, and execute the next iteration
2.4.3 Represent Traf�c Infrastructure
In the KTH-TPMA traf�c simulator, traf�c infrastructure data is stored in a text based con�gu-
ration �le with a prede�ned format. The detailed information of this con�guration �le is described
in chapter 3. Figure: 2.4, describes a logical view of the road infrastructure, and illustrates how
the real life road infrastructure is presented in computer simulation. The road infrastructure �le is
consisting of these below information:
� Lane segment
18
Calculate acceleration/deceleration
Lanechange
Safe lanechane
Select the desire lane
Move to the lane
Load simulation parameters and road network
Start
Update states of traffic signals, signs, and incident
Calculate time –dependent shortest paths
Update OD trip tables, Generate vehicles andappend them to queues
Load vehicles from queues to the road network
Advance vehicle and update speed
Arrives at destination
Invoke Surveillance SystemSensor activated?
Reaches lane end?
Pass vehicle to the next lane Remove vehicle from the roadnetwork
Update Phase (for every vehicle)
Yes
Yes
NoNo
No
Yes
Yes
YesNo
Update GUI
Terminate simulation?
No
StopYes
Advancesimulation
clock
No
Figure 2.3: Flow chart of the traf�c simulation model
19
Lane segment
Lane segment
Lane segment
Lane segment
Lane segment
Lane segment
G
D
D
G
Vehicle Generator
VehicleDestination
Figure 2.4: Represent traf�c infrastructure in the simulation model
� Linking information between lane segments
� Linking information between lane segments, traf�c signals and signs
� Curve of the lane segments
� Vehicle generator
� Vehicle destination
� Route table information
Lane segments are the smallest unit of road network, which hold the property �rst-in-�rst-out.
So DVUs in the same lane segments are not allowed to overtake each other. But as lane segments
are connected with other segments so DVUs can overtake others or change path by shifts among
lane segments. The connections between lane segments form the different driving paths. And all
the lane segments contain the rout table information, which provides the availability to select the
travel route of DVUs. Traf�c signals and signs are also connected with the lane segments, so DVUs
are also interacting with these objects through this. The vehicle generators are responsible for
generating DVUs with the necessary vehicle information, i.e., desire speed, destination, etc. And
the vehicle destinations are responsible for remove these DVUs which reached to the destination.
2.4.4 Object Oriented Modeling
Object-Oriented Modeling helps us to plot the physical objects into the computer simulation.
To �nd out the physical objects, it is �rst necessary to analyze and divide the real life traf�c
system into smaller parts, and group similar and well de�ned parts in terms of their features and
20
Vehicle
Traffic ControlSystem
SensorRoad Network
Driver
Pedestrian
Station
VehicleGenerator
VehicleDestination
Figure 2.5: Basic Objects that form Traf�c System
tasks. Then �nd out the interactions between different objects and the properties, methods, and
associations of these objects. The Figure: 2.5, shows the different traf�c objects that form the
traf�c system. The simulator is consisting of several different types of objects. The Figure: 2.6,
is shows the simpli�ed class diagram of the traf�c simulator. It is found that the primary class of
the traf�c simulator is the �Basic Object� class. This class is consisting of the common attributes
and methods/virtual methods which are implemented by the corresponding inherited classes. The
classes �Lane Segment�, �Vehicle�, �Generator�, �Station�, and �Signal� are inheriting the �Basic
Object� class.
The class �Lane Segment� is representing the smallest unit of the roads. The method �Read-
cnfData()�/�ReadPipeXMLFile()� is responsible for reading the roads information from the road
network con�guration �le. The �ObjUpdate()� method is updating the lane segments in each iter-
ation while the simulation is running. The �VehicleCount()� method is counting the total number
of vehicles which are currently in a lane segment.
The �Generator� class is the base class of the �VehGen� and the �VehDest� classes. The �Read-
cnfData()�/�ReadPipeXMLFile()� class is responsible for reading the con�guration information
of the vehicle generators/destinations from the road network con�guration �le. The �VehGen�
class generates DVUs while the simulation is running. This DVUs generation depends upon the
speci�c speci�cation of that vehicle generator (i.e., DVUs generating rate per hour, speed distrib-
ution, DVUs type distribution, etc.). And the �vehDest� class removes the DVUs objects from the
simulation model, after reach their destination.
The �Vehicle� class is responsible for making update decision of DVUs while simulation is
running, i.e., selecting route, lanes changing, deciding speed/acceleration/deceleration, moving
DVU, and update the DVU states.
The �ModelMgr� class controls the general simulation logic. It is associated with the �Basic
21
Object� class. The method �ReadCnfConnections()� of �Basic Object� class uses the method
�BuildModel()�/�BuildModelXML()� method of the �ModelMgr� class for reading connection
information between lane segments, and between lane segments and traf�c signals, signs, and
sensors. After reading these connections, it populates the route table and other information list of
the lane segment. The �ObjUpdate()� method of this class updates all of the simulation objects
(i.e., execute the �ObjUpdate()� method of other simulation objects) through a repeat-until loop.
And after each update, the model manager class updates the simulation clock.
2.4.5 Vehicle/Driver-Vehicle Unit (DVU) Movement
When a DVU is moving through a traf�c road network, it interacts (Figure: 2.7) with different
traf�c objects. This interaction includes DVU in front, traf�c signals and pedestrian; helps to
decide the speed, acceleration/deceleration, and lane changing decision. These interactions could
be modeled as follows:
� Car following model
� Lane changing model
Each DVU moves through the simulation based on the logic of these models. The car following
model is responsible for deciding the acceleration/deceleration of a DVUwhile interacting with the
front DVU. And the lane changing model is responsible for making the decision of lane changing.
Car following model
Car following model calculates a DVU's acceleration/deceleration rate, taking into considera-
tion its relationship with the leading vehicle [25]. Figure: 2.8 shows a car following model exam-
ple. Depending on the position of the reference vehicle/DVU, its position can be divided into three
ares, such as:.
� Free area
� Stable area
� No entry area
If the distance between the reference vehicle/DVU and the front vehicle/DVU is more that a
pre-determined value then the reference vehicle/DVU is in the free area. In this scenario, the
reference vehicle/DVU doesn't need to interact with the front vehicle/DVU, and if the reference
vehicle's current speed is less than its desired speed, then it is free to accelerate at the maximum
22
+ReadPipeXMLFile()+ObjUpdate()+VehicleCount()+ReadCnfData()+ReadCnfConnections()
+SpeedLimit, PipeAngle : Long+VehCount : Long+LaneChLeftLane : Lane Segment+LaneChRightLane : Lane Segment+VehAtALaneList : Object
Lane Segment
+ReadCnfData()+ReadCnfConnections()+SetRingPointers()+GoNext()+GoPrev()+InitFromFile()+ObjUpdate()
+IdNo : Long+ObjType : Long+ObjLength : Double+ObjWidth : Double+ObjSpeed : Double+ObjPosit : Double+PrevObj, NextObj : Basic Object
Basic Object
+ShowGenOrDest()+ReadCnfData()+ReadCnfConnections()+ReadGeneratorXMLFile()
+VehsGenerated : Long+NoVehExits : Long+MaxRoute : Long
Generator
+UpdateVehExitCount()
VehDest
+CreateVehicle()+InitVehicle()+SetDestination()+SelectRandomFromVehTypeDistr()+SelectRandomFromVehRouteDistr()+SelectRandomFromVehSpeedDistr()
VehGen
+FindVehiclesAhead()+DecideRoute()+DecideSpeed()+MoveVehicle()+ObjUpdate()+RemoveFromPipe()
+VehType, DesiredSpeed : Long+LstDec, LstAcc : LongVehFront, VehBack : Vehicle
Vehicle
Rectang/Station
+ReadCnfData()+ReadCnfConnections()+ReadConsXML()
StationObj Signal
+BuildModel()+BuildModelXML()+LoadModel()+ObjUpdate()+StartRun()+StopRun()+BreakRun()+ResumeRun()
+MgBasicObjectArr : Basic Object+VehicList, VehLaneSegmentList : Object+FirstObj, RunObj, CurVehic : Basic Object
ModelMgr
+Initialize()+SetTimeCounter()+ObjUpdate()+StartRun()+StopRun()+BreakRun()+ResumeRun()+TimeToInt()
+SimHours, SimMins, SimSecs : Long+TimeSpeed : Long+TimeStepReal, TimeStepFixed : Long
Clock
11
1
*
Figure 2.6: Simpli�ed Class diagram of the traf�c simulator
23
ReferenceVehicle
Pedestrian
Vehicle(Front)
Traffic SignalFigure 2.7: Driver behaviour in a traf�c system
Stable Area
Free AreaNo Entry
Front VehicleReference
Vehicle
Figure 2.8: Reference vehicle can be in the free area, stable area or no entry area
acceleration rate to achieve the desired speed. But if the current speed is higher than the desired
speed then it decelerates normally to reach to its desired speed.
If the distance between the reference and the front vehicle/DVU is less than a pre-determined
value; then it is in the no entry area. In this case, the reference vehicle/DVU needs to decelerate to
a certain rate to avoid collision.
If the distance between the reference and the leading vehicle/DVU is in between a pre-determined
value; then it is in the safe area. In this case, the reference vehicle/DVU accelerates its speed de-
pends upon the acceleration model.
Lane changing model
When vehicles run they need to change their lane; because they need to reach to their destina-
tions (depending on the route), achieve desired speed, and pass the blockage. In the Figure: 2.9,
when a vehicle V3 in lane L1 decided to change lane to L2; then it needs to examine the front and
back gap G2 and G1 in lane L2.24
V3
V1V2 G1 G2
Lane : L1
Lane : L2
Figure 2.9: Lane changing gap acceptance model
Vehicle
VehicleDestination
VehicleGenerator
Signal Vehicle
Pipe
Vehicle
Pipe
Figure 2.10: A sample double link list of traf�c objects
If the both gap G1 and G2 are acceptable (depend upon the simulation) then the vehicle V3 in
lane L1 changes to lane L2.
2.4.6 Simulation Update
Before discuss the update mechanism of traf�c objects, it's necessary to know the task execution
sequence followed by the simulator, and how objects are organized in side. The simulator �rst
reads the road network con�guration �le in two steps. At the �rst step, it reads the position,
width, and length information of lane segments, vehicle generators/destinations, sensors, and traf�c
signals from the road network con�guration �le. After �nish reading, the simulator draws the
entire road network in the simulation. And, in the second step, it reads all the link information
of lane segments, vehicle generators/destinations, route information of lane segments, pedestrian,
and signal control. While it is reading this linking information, it forms a double link list with all
of these traf�c objects. And after running the simulation, vehicle generators are adding the vehicle
objects into that double link list (Ref. Figure: 2.10). And Figure: 2.11 shows the interface of the
running KTH-TPMA traf�c simulator.
To update the objects in the simulation two issues has to considered, �rst one is under which
25
models objects are updated and the second one is the time. Models are necessary to de�ne the
behavior of the each type of objects. But models don't say anything about the time, i.e., when the
actions have to be performed. Models help to �nd the answers of vehicles speed, acceleration, lane
changing, etc.; which is already discussed in the Vehicle/Driver-Vehicle Unit (DVU) Movement
section.
Time is an important factor in the simulation. As there is no absolute time, so the simulation
events are controlled by the reference clock of the simulator. In the KTH-TPMA simulator, �xed-
increment time advance approach (synchronous model of time) is used to execute the events. In
the �xed-increment time advance approach, the clock is updated after all the events are executed.
The simulation is capable of handles the time in two different ways, such as:
� Real Time Mode
� Fast Time Mode
In real time mode, the simulation runs accordingly to the real world clock (or computer clock).
It means if we give input 10 minutes to run the simulation then it will run exactly 10 minutes. It
is also possible to adjust the �xed-increment time or update frequency of the simulation clock. By
default the update frequency value is 40. It means the simulation divides each second (each second
is divided into 100 parts) into 25 �xed time steps (100 divided by (40/10)). So the simulation
updates the traf�c objects states (Figure: 2.10) in each 0.04 second. The lower and upper bound of
this time step value is respectively 10 and 1000. So, the lowest time step value is representing the
smallest update frequency and the highest time step value is representing the vice versa.
In the fast time mode, the simulation will run as fast as possible depend upon the computing
power of the system. So the simulation can be �nished earlier or later than the speci�ed simulation
time. In this mode it is also possible to input the update frequency of the simulation clock. By
default the time step value is 100, which means the simulation is updating the list (Figure: 2.10)
in each 0.1 second (in each second 10 times). The lower and upper bound of the time step value
is respectively 10 and 1000. Through this mode it is possible to simulate the reality faster than the
real time. But in lowest time step value the simulation will update the list in 100 times in a second,
which could be making the simulation running even slower than the real time depends on the size
of the road network and traf�c demand.
26
Figure 2.11: The interface of KTH-TPMA traf�c simulator
27
Chapter 3 Distributed Simulation System Design & Implementation
3.1 Introduction
This chapter discusses the distributed computing technologies and the system design & imple-
mentation of the information exchange between the KTH-TPMA traf�c simulator and the emission
estimation system. The emission estimation system is a different module of the traf�c simulator.
It estimates the on-line emission of vehicle or road segments by using the simulated vehicle infor-
mation of KTH-TPMA.
3.2 Distributed Computing
Distributed computing deals with hardware and software systems containing more than one
processing element or storage element, concurrent processes, or multiple programs, running under
a loosely or tightly controlled regime [26]. In distributed computing a program is split into different
parts, (i.e., components and objects) that run simultaneously on more than one computer over a
network. There are different communication mechanisms exists, such as:
� Message passing via sockets
� Message Passing Interface (MPI)
� Remote Procedure Calls (RPCs)
� Distributed Objects:
� Java RMI (Remote Method Invocation)
� Common Object Request Broker Architecture (CORBA)
� Service Oriented Architecture (SOA)
Among these communication mechanisms, socket is the lowest level of end to end communi-
cation between a server program and one of more client programs. Socket is an end point of a
virtual network connection between processes. The interactions between processes is based on a
request/response protocol, and requests are mapped to procedures or methods on objects located
on the server. The chief drawback of using sockets is in the messaging model itself [27]. It is not
suitable for our distributed computing because we need to share objects on-line.
MPI is a speci�cation for an API that allows computers to communicate with one another. It is a
28
language independent message passing communication protocol and remains dominant model for
its high communication performance. In MPI, tasks are divided to slaves processes by the master
process and after they completed, new tasks are assigned by the master process. The result of the
�nished tasks sends to the master process. Even the high-performance advantage of MPI, it is not
feasible to use in our case because we need concurrent programming model to share objects rather
than parallel computing. And the MPI has no of�cial language binding for Java [28].
Remote procedure call (RPC) is a communication mechanism to construct client-server based
application. It is the extending notion of conventional local procedure calling, in RPC the called
procedure need not exist in the same address space as the calling procedure. The two processes
may be on the same system, or they reside in different systems with network connection. RPC
supports high level form of communication; it hides the network communication by allowing a
process to call a procedure which is implemented on a remote computer. But RPC is only for the
procedural programming language which is not suitable for the Object Oriented Languages.
RMI is the object-oriented analog of RPC in a distributed object oriented environment. It is
the mechanism to invoke a method in a remote object. It is supported the high level form of
communication and capable to passing objects between the client and the server, but it is only in
between Java Virtual Machines (JVM). As in our case we need to share objects between Java and
Delphi so Java RMI is not suitable for us.
CORBA is a framework for an object oriented communication technology for the heterogeneous
client - server communication, proposed by Object Management Group (OMG). It offers high
speed communication. The only limitation is that a programming language must have a CORBA
implementation for it.
SOA is a group of services that communicate with each other. The process of communication
involves either simple data-passing between a service provider and service consumers, or a more
complicated system of two or more service providers [29]. SOA is a loosely coupled collection of
services, so its services are independent and provides a very �exible way to change when required.
In this thesis, CORBA and SOA distributed computing mechanisms are used to implement
the communication platform between the KTH-TPMA traf�c simulator (Delphi) and the emission
estimation platform (Java).
We want to study and investigate CORBA in our thesis, because it �ts in our thesis context,
and as we need language binding for Java and Delphi which the CORBA has. And CORBA also
offers faster communication. We also study and investigate SOA to compare the communication
29
Client/ObjectImplementationNaming
Service
Logical data flow
OS
Network
ORB
Stub/Skeleton
Server/ObjectImplementation
OS
Network
ORB
Skeleton/Stub
Physical data flow
Object Lookup
Internet IIOP
Figure 3.1: Basic CORBA architecture
ef�ciency between these two distributed computing technologies.
3.2.1 CORBA
Common Object Request Broker Architecture (CORBA) is a middleware (software layer be-
tween the Operating System and the application), and its standard is de�ned by the Object Man-
agement Group (OMG). Figure: 3.1, shows the basic architecture of CORBA; Object Request
Broker (ORB) is the most fundamental component of CORBA, whose task is to facilitate the com-
munication between objects. To facilitate the communication between objects, ORB needs the
Interoperable Object Reference (IOR). IOR is a text string encoded in a speci�c way, such that a
client ORB can decode the IOR to locate the remote server object. It contains enough informa-
tion to locate the correct server object and the IOR is unique for each object reference. A client
retrieves the IOR from the naming service where the server objects bind with particular key. After
obtaining an IOR the client application can access the remote CORBA object via Internet Inter-
ORB Protocol (IIOP). IIOP is the implementation of the General Inter-ORB Protocol (GIOP) for
TCP/IP, which is the abstract protocol by which the ORB communicates. The client application
that obtains an IOR, constructs a GIOP message and send it to the sever object. The IOR contains
all the information needed to route the message directly to an appropriate server [30],[31],[32].
The interface of the CORBA objects is speci�ed by the CORBA Interface De�nition Language
30
ServiceProvider
ServiceRequestor
ServiceRegistry
Find
Serv
ice
Bind Service
PublishService
ServiceDescription/
WSDL
Figure 3.2: Basic web service architecture
(IDL). An IDL compiler translates the IDL de�nition into an application programming language,
such as C/C++, Java, Ruby, Smalltalk or Python; and generate the IDL stubs and skeletons that
respectively provide the framework for client side and server side proxy code. In this thesis we
analyzed these below ORB.
� VisiBroker
� MTDORB
� Sun Java ORB
In the KTH-TPMA traf�c simulator (Delphi) side/client, we use the VisiBroker ORB, which is
developed by Borland. And we also tested the MTDORB which is a free and open source ORB for
Delphi and Kylix. It is intended to be a fully compliant implementation of CORBA 2.6 standard
[33]. We examine the MTDORB in the traf�c simulator side to make the communication with
the emission prediction application. But because of the lack of documentation of this ORB it was
not possible to be used. Finally, VisiBroker is used in this thesis. And in the emission estimation
application Sun Microsystems's ORB is used with the ORBD naming service.
3.2.2 SOA &Web Service
Service Oriented Architecture (SOA) is an architecture relies on service-orientation as its fun-
damental design principal [35]. The World Wide Consortium (W3C) de�nes SOA as `A set of
components which can be invoked, and whose interface descriptions can be published and dis-
31
covered'. The fundaments goal of the SOA is to build the loosely coupling of services. Only
the interface of the service is published and other services are easily interacting with that service
through the published interface. And this service interface hides the underlying complexity, i.e.,
service implementation language, platform, etc.
Web Service is an implementation of SOA. It de�nes by the W3C as �A Web service is a
software system designed to support interoperable machine-to-machine interaction over a network.
It has an interface described in a machine process able format (speci�cally WSDL). Other systems
interact with the Web service in a manner prescribed by its description using SOAP messages,
typically conveyed using HTTP with an XML serialization in conjunction with other Web-related
standards�. The Figure: 3.2, shows the basic web service architecture. It consists of three main
parts:
� Service Provider
� Service Requester
� Service Broker/Registry
The service provider implements the service and published the service description or the Web
Service Description Language (WSDL) in the service registry. The service requestor looks for the
required web service through sending the XML request into the service registry. The service reg-
istry is the place where new services are published and searched by the service requestor to use
the service. After retrieving the WSDL, service requestor binds with the service provider and con-
sumes the service using SOAP (Simple Object Access Protocol) messages. A valid SOAP message
is a well-formed XML documents, and relies on other application layer protocols (such as, Remote
Procedure Call (RPC) and HTTP) for transmission. It provides the basic messaging framework
for web service communication [37]. In this thesis, web service communication technology is also
used to build up the communication between these two applications to evaluate the performance.
3.3 Design and Implementation
This chapter illustrates the requirement analysis, design, and implementation of the communi-
cation platform between the traf�c simulator and emission estimation platform. The requirements
analysis section formulates the requirements and categorizes these into different divisions. The de-
sign and implementation section implements these above requirements which are formulated from
the requirement analysis section.
32
3.3.1 Requirement Analysis
Before design and implementation it is necessary to �nd the requirements and analysis those to
�nd the relationships and dependences among them. Below is the list of requirements.
� Enable the KTH-TPMA traf�c simulator to read the XML road network con�guration �le
with the road segment information
� Build up the communication platform through CORBA and Web Service
� Send the XML road network con�guration �le and other necessary information to the
emission prediction application
� Different ways to exchange vehicle information in real time
� Exchange individual vehicle information in each update cycle
� Exchange information of all vehicles in each cycle after updating all of them
� Exchange information by thread
� Exchange vehicle information via Web Service
� Evaluate and �nd the optimum communication time
� And intact the traf�c simulator code
Analyzing these above requirements, the design and implementation section could be divided
into a hierarchical ways. First of all, modify the text based road network con�guration �le in to the
XML format with the road segment information. Then implement the loading process of the XML
road network �le inside to the traf�c simulator. After that, implement the communication plat-
form through CORBA and Web Service, and exchange the vehicle information in different ways.
And �nally, to �nd out the optimum communication way, the communication time is measured
in different communication ways, and compared in different road network with different vehicle
demand.
3.3.2 Road Network Con�guration
The traf�c simulator an simulates vehicles on different road network. And the road network
de�nition is de�ned in a text �le (.cnf) within a prede�ned format which is readable only by this
simulation. Transforming this text base con�guration �le to the XML format will enable to load
that con�guration �le to any other simulator (for this loading, simulators has to agree on the set of
33
Lane Segment's Con�guration Lane Segment's De�nition11 `11' represent the lane segment's starting point1 1 ID number of the lane segment2 30 283 80 283 Start and end position of the lane segment3 50.00 Length of the lane segment4 0.00 Position from end of lane segment21 0 0 1 0 0 0 0 0 0 0 Route table (0 - 9)23 0 0 0 0 0 0 0 0 0 0 Route table (10 - 19)22 0 Speed limit; 0 = No limit41 1 Number of connections42 2 List of ID number of connected object0 End of lane segment's de�nition
Table 3.1: Road Network's Lane Segment Speci�cation
tags). The text based con�guration �le represents the road network by lane segment, which is the
smallest unit of road network. But to measure the emission of the road network in a reasonable
way we need one additional piece of information of road network which is road segment. Road
segment represents a small part of the road network which will helps to measure the emission of
the road network is a reasonably way.
To convert a text-based road network con�guration �le to XML format, it is necessary to know
the de�nition of that con�guration �le. The con�guration �le speci�es lane segments, vehicle
generators, vehicle destinations, traf�c signs, linking information of different components, etc.
But in our case we need to get familiar at least three type of components.
� Lane segment
� Vehicle Generator
� Vehicle Destination
A lane segment's de�nition is explain in the Table: 3.1. The route table information of each
pipe (rows 21 & 23) forms the travel route, which helps vehicles to make decision to reach to
its destination. And row `41' represents the number of objects that are connected with that lane
segment, and row `42' contains these connected object's ID number.
Vehicle generator's speci�cation is demonstrated in the Table: 3.2. In the table, rows `23' &
`33' specify the route distribution of the vehicle generator, it assign the route of the vehicles at time
of generating vehicles. The rows `24' & `34' specify the vehicle types, such as car, bus, truck etc.
And the rows `25' & `35' indicate the speed distribution of vehicles.
The Figure: 3.3 shows a sample of a XML road network con�guration �le with road segment
de�nition. The loading process of the XML road network �le is as same as the loading process of
34
Vehicle Generator's Con�guration Vehicle Generator's De�nition21 '21' represents the starting point1 80 ID number of the vehicle generator2 10 293 30 293 Position of the generator3 20.00 Length of the generator4 0.0021 800 Traf�c �ow (vehicle/hour)22 4 Number of legs23 0 100 0 0 0 0 0 0 0 Route distribution33 0 0 0 0 0 0 0 0 0 0 Route distribution24 0 1 0 0 0 0 0 0 0 Vehicle type distribution34 0 0 0 0 0 0 0 0 0 0 Vehicle type distribution25 0 0 0 0 10 15 50 15 10 Desired speed distribution35 0 0 0 0 0 Desired speed distribution26 11 Leg number29 0 Traf�c �ow (1 =absolute traf�c �ow)41 1 Number of connections42 1 List of ID number of connected objects0 End of vehicle generator's de�nition
Table 3.2: Road Network's Vehicle Generator Speci�cation
the text based con�guration �le. The simulator loads the con�guration �le in two steps.
� Read the XML �le and create the objects (lane segment, vehicle generator, vehicle desti-
nation)
� In the second step, the simulator reads the connections between objects and constructs
a double link list of all of these objects. And also builds the lane changing and routing
information which helps vehicle to select the route and desired lanes
In the traf�c simulator, the �File Manager� class is responsible for handling the �le operations.
For loading the con�guration �le the �File Manager� class is associated with the �Model Manager�
class. This is the main class for building the model and also the connections between different
objects. Figure: 3.4, shows the use case and class diagram of the loading process of the XML road
network con�guration �le. The loading process is divided into two parts, �rst it builds the model
and after that it builds the connections between objects. To load the XML road network �le, adding
a method (i.e., BuildModelXML()) in the �Model Manager� class, which does both building the
During the loading process, if any error occurs then the �confError� boolean parameter of that
method becomes true and stop the loading process of the �BuildModelXML()� method.
3.3.3 CORBA Communication
To construct the CORBA communication between the KTH-TPMA traf�c simulator and the
emission prediction application, �rst we need to design the IDL (Interface De�nition Language)
35
<Segment SegmentID="0"><VehiclePipe ObjID="1"><Position><X1>30</X1><Y1>283</Y1><X2>80</X2><Y2>283</Y2>
</Position><Length>50.00</Length><PositionFromEndOfPipe>0.00</PositionFromEndOfPipe><RouteTable>0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</RouteTable><SpeedLimitation>0</SpeedLimitation><LaneSwitchAllow>0</LaneSwitchAllow><Grade /><NumberOfConnection>1</NumberOfConnection><ConnectionList>2</ConnectionList>
</VehiclePipe><VehiclePipe ObjID="2"><Position><X1>80</X1><Y1>283</Y1><X2>130</X2><Y2>283</Y2>
</Position><Length>50.00</Length><PositionFromEndOfPipe>0.00</PositionFromEndOfPipe><RouteTable>0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</RouteTable><SpeedLimitation>0</SpeedLimitation><LaneSwitchAllow>0</LaneSwitchAllow><Grade /><NumberOfConnection>1</NumberOfConnection><ConnectionList>3</ConnectionList>
</VehiclePipe></Segment>
End of Segment definition
End of lane segment definition
Start lane segment definition
End of lane segment definition
Start Segment definition
Start lane segment definition
Figure 3.3: A sample XML road con�guration �le with segment de�nition
36
+LoadConfFile(in ECurrConfDir : String, in ECurrConfFile : String)
FileMgr
+BuildModel(in ConfError : Boolean = False)+BuildConnections(in ConfError : Boolean = False)+BuildModelXML(in ConfError : Boolean = False)
ModelMgr
1
1
Load XML RoadNetwork
Trafic Simulator User
Build Model
Build Connectionsbetween objects
«uses»«uses»
1
0..*1
0..*
Figure 3.4: Use case & class diagram of the loading process of the XML road network con�gura-tion �le
�le. Because in CORBA communication IDL �le works like a bridge between the distributed ap-
plications. The Figure: 3.5 shows the EmissionTPMA.idl �le, which contains all the necessary
data structure and methods that are necessary by the both traf�c simulator and the emission predic-
tion application to share the vehicle information in real time. Before describing the data structure
and the methods of the IDL �le it needs to describe the different IDL parameter passing mode. In
CORBA IDL, the parameters are passed into three different ways between the caller (client) and
the collie (implementation).
� in parameter
The caller assigns the input parameters. The collie can only read that parameter, and cannot
change the value.
� out parameter
The caller allocates the type of the `out' parameter and the collie sets the value. After �nish
the method call the caller get back the out parameter value that is set by the collie.
� inout parameter
In this case, the caller sets the initial value of the `inout' parameter and the collie may
change the value. And after �nishes the method call the caller again returns the value from the
collie.
37
module EmissionIDL{
//Structure of Shared Vehiclestruct VehicleInformation{
double vehicleID;double speed;double acceleration;long type;double length;double width;long pipeID;double objPosition;long X1, X2, Y1, Y2; // position of vehiclelong X1s, X2s, Y1s, Y2s;double simTime;
};
typedef sequence<VehicleInformation> VehicleArray;
// Interface that call by the Server.interface ClientInterface{
boolean startStop(in boolean flag);boolean disconnect();boolean getConnectionStatus();
};// End of Client Interface
// Interface that call by the Client.interface ServerInterface{
// connect method will return a client ID.ServerInterface connection(in ClientInterface clientRef, in string roadNetwork,
in string IP, in string hostname, in long simTime);
// Client call this method to pass the vehicle information to the server side.
// Asynchronious callingoneway void updateVehicleArray(in VehicleArray vehicles);oneway void updateVehicleInformation(in VehicleInformation vehicle, in long
vehicleNum);// synchronious callingvoid updateVehicleArray(in VehicleArray vehicles);void updateVehicleInformation(in VehicleInformation vehicle, in long
vehicleNum);// Disconnect from Java sideboolean disconnect();
};// End of Server Interface
};
Figure 3.5: IDL �le for the CORBA communication (EmissionTPMA.idl)
38
In the IDL �le, the data structure of the vehicle information contains all the necessary para-
meters of vehicle, such as, vehicle ID, speed, acceleration, type, length, width, lane segment ID,
position, and the simulation clock time which are necessary for the emission prediction models to
estimate the emission. The IDL �le also contains two interfaces. The client interface is imple-
mented inside the traf�c simulator. It consists of three methods, such as:
� boolean startStop(in boolean �ag)
� boolean disconnect()
� boolean getConnectionStatus()
These methods are called by the emission estimation application to start or stop the simulation,
disconnect the traf�c simulator, and query the connection to know whether the traf�c simulator is
connected with the emission application or not. And the server interface which is implemented
inside the emission estimation application consists of the following methods, such as:
� ServerInterface connection(in ClientInterface clientRef, in string roadNetwork, in string
IP, in string hostname)
� void updateVehicleArray(in VehicleArray vehicles)
� void updateVehicleInformation(in VehcileInformation vehicle, in long vehicleNum)
� boolean disconnect()
The �connection()� method is called by the traf�c simulator to get connection with the emission
prediction application. The �connection()� method contains four �in� type parameters; the �clien-
tRef� is the reference of the �clientInterface� object, which is used by the emission application
to call the methods that are implemented inside the traf�c simulator. The traf�c simulator is also
passing the string format of the road network �le, IP address, and the host name of the traf�c sim-
ulator. After accomplish the �connection()� method the emission application return the reference
of the �ServerInterface� object, which is used by the traf�c simulator to call the vehicle update
methods (�updateVehicleArray()�, and �updateVehicleInformation()�), for sending the vehicle in-
formation; and the �disconnect()� method is to disconnect the traf�c simulator from the emission
application. To exchange the vehicle information, traf�c simulator has to be adapted. The adapted
traf�c simulator can exchange on-line vehicle information with the emission estimation platform
in three different ways, such as:
39
ConnectEmission Method Description of the MethodsInitORB() Initializes the ORBreadCNFFile() Reads the road network con�guration �le, and forms a wide stringInitTime() Initialize the time variables for measuring the communication timeConnect() It Calls the remote connection methoddisconnect() It calls the remote disconnect method to get disconnectedCollectVehicleInfo() Collects the current vehicle information, and forms a vehicle objectSendIndividualVehicleInfo() Sends the individual vehicle information to the emission applicationSendVehicleInfo() Sends the collection of vehicles information to the emission application
Table 3.3: Description of the methods of the ConnectEmission class
� Exchange individual vehicle information in each update cycle
� Exchange information of all vehicles in each cycle after updating all of them
� Exchange information by thread
The Figure: 3.6 shows the class diagram of the modi�ed traf�c simulator, which is capable of
exchanging the vehicle information in different ways in real time. The �ConnectEmission� class is
the base class for the communication, and the description of the methods is given in the Table: 3.3.
Synchronous & Asynchronous Communication
The communication between these two applications could be established in two different ways,
either synchronous or asynchronous. At the lowest level, CORBA supports two forms of commu-
nication, such as:
� Normal
� Oneway or Deferred synchronous
The �Normal� mode is the synchronous request/response communication way, which allows an
application to make a request to some CORBA object and wait until a response is received. And the
�Oneway� mode is the deferred form of synchronous request/response communication way which
allows an application to make request to some CORBA objects and receive an empty response
immediately. So in this case, the caller application performs other operations after immediate
CORBA calling instead of waiting for the response. In our communication platform, to share the
online vehicle information the remote operations have to be executed rapidly in each update cycle
of the simulator. For the faster remote communication, the deferred synchronous communication
method could be best choice if we don't need the order of vehicle data. But to predict the emission
precisely, the emission application needs the ordered vehicle information. For the ordered vehicle
40
+Init()+InitORB()+InitTime()+readCNFFile()+getHostIP()+Connect()+disconnect()+CollectVehicleInfo()+CollectVehicleInfo_WSDL()+SendIndividualVehicleInfo()+SendVehicleInfo()+SendVehicleInfoWSDL()
+aorb : TORB Object+aobj : CORBAObject+ServerInterfaceObj : ServerInterface object(idl)+ClientInterfaceObj : ClientInterface object(idl)+hostName : String+hostIP : String+cnfFile : String+VehicleInfo : vehicle Object
ConnectEmission
+ObjectUpdate()+DecideRoute()+DecideSpeed()+MoveVehicle()+FindVehicleAhead() : Basic Object
+RefVehicle : Vehicle
Vehicle
+ReadCnfData()+ReadCnfConnections()+SetRingPointers()+GoNext() : Basic Object+GoPrev() : Basic Object
+IdNo : Long+ObjType : Long+ObjLength : Double+ObjSpeed : Double+ObjPosit : Double+ObjWidth : Double+PrevObj, NextObj : Basic Object
Basic Object
+startStop(in flag : boolean(idl)) : boolean(idl)+disconnect() : boolean(idl)+getConnectionStatus() : boolean(idl)
«interface»ClientInterface
+connection(in clientRef : ClientInterface object(idl), in roadNetwork : string(idl), in IP :string(idl), in hostname : string(idl)) : ServerInterface object(idl)+disconnect() : boolean(idl)+updateVehicleArray(in VehicleArray : Vehicle (array of Vehicles))+updateVehicleInformation(in VehicleInformation : Vehicle, in vehicleNum : Long)
«interface»ServerInterface
+StartRun()+SynchSendVehicleInfo()
VehicleInfoSendThread
+ViewEmissionWindow()+DrawChart()+CalculateSimulationInformation()+SetTrackBarPosition()
ChartTime : TChart ObjectSeries1 : TPieSeries Object
MeasureEmission
TThread
Emission
1 1
1
1
1
1
0..1
*
The Emission prediction application is theanothe part of this whole project [1].
Figure 3.6: Class diagram of the CORBA communication between traf�c simulator and emissionapplication 41
Update Vehicle Status
1
V1
V6
V5 V4
V3
V2V7
V8
Send Vehicle Information
Receive Acknowledgement2
EmissionApplication
3 Send Vehicle Information
Receive Acknowledgement4
Figure 3.7: Share individual vehicle information in a synchronous way
information, synchronous CORBA calling is the best choice but the drawback is that it will block
the simulation until it gets the response from the emission application. And in the deferred syn-
chronous CORBA calling the emission estimation application has to perform some additional tasks
to maintain the order of vehicle information. In this thesis, both ways of CORBA communication
methods are implemented to share the vehicle information into three different ways.
The traf�c simulator can share the individual vehicle information in two different ways, such
as, send the information by the vehicle object itself or by a thread. In each update cycle of the
simulator, the vehicle object executes its object update method. Through this method, the vehi-
cle objects are updating its status. After updated the status, it sends the updated information to the
emission estimation application by itself or by a thread. The Figure: 3.7 is showing the individ-
ual information sharing, in a synchronous way by the vehicle object itself. When the vehicle sends
the information in a synchronous way then it has to wait until it receives acknowledgement from
the emission application. In this scenario, the following vehicle object has to wait until the �rst
one �nished sending the information. This synchronous communication is costly but it guarantees
the ordered vehicle information to the emission side. But, the deferred synchronous method of-
fers faster communication (no wait time for the acknowledgement) but no grantee of the ordered
vehicle information. In this communication way, extra computation is also needed in the emission
application to sort the vehicle information in an order way (by the simulation clock time), which
is also expensive.
In the synchronous communication, sharing individual vehicle information is also possible by
a thread. In this case, after updating the vehicle status, it uses a thread for sharing the vehicle
42
Update Vehicle Status
1
V1
V6
V5 V4
V3
V2V7
V8
Send V1 Information
Acknowledged
EmissionApplication
Send V2 Information
Thread
Senda
b
Acknowledged
Sendc
d
2
Figure 3.8: Share individual vehicle information by thread in a synchronous way
information with the emission application. Threading offers two bene�ts. First one is, the waiting
time to receive the acknowledgement from the emission application is lie into the thread, and this
waiting time is utilized by the following vehicle to update its status. And the second one is it offers
faster communication compare to sending information by the vehicle object itself. We will discuss
this communication time in the evaluation chapter in more details. But the disadvantage of thread
is that handling thread is expensive.
The remote communicate is expensive respect to time and performance of the traf�c simulator.
To reduce the number of remote communication, the simulator application can share the collection
of vehicle objects information (once in each update cycle of simulator) that are exists to the sim-
ulator's vehicle object list. The Figure: 3.9 shows the sharing of collection of vehicle information
with the emission estimation application by synchronous way. In this method, the vehicle's up-
dated information is preserved after each update of vehicle object. After �nish updating the entire
vehicles in the list, the simulator sends the collection of vehicle objects information to the emis-
sion estimation application. This communication way is effective respect to the number of remote
calling compare to the individual communication. As the simulator can share the vehicle infor-
mation through fewer remote communications, this communication way obviously offers better
performance of the simulator. But this communication way also has some drawback, such as; if
the vehicle object list is very big then it costs time to preserve all the information, and the sim-
ulator has to check whether the updating cycle of vehicles is �nished or not. The asynchronous
method of group communication is also ef�cient because of no waiting time for the acknowledge-
ment. But extra computation is also need by the emission application to maintain the order of
43
Update Vehicle Status
V1
V6
V5 V4
V3
V2V7
V8
Acknowledged EmissionApplication
Send Collection of Vehicle Information
After updating all the vehicles, the simulator send thecollections of vehicle information to the emission application
Save vehiclestatus
(V1 to V8)
Figure 3.9: Share collection of vehicle information in a synchronous way
vehicle information, same like the individual communication.
3.3.4 Web Service Communication
To exchange online vehicle information, web service communication mechanism is also imple-
mented to test the communication time. To implement the communication, Apache Axis2/Java is
used in the emission estimation application to convert the communication interface to the WSDL
format. And in the traf�c simulator side, WSDL importer tool is used to import the WSDL service
description �le into the Delphi format. The emission application de�nes interface is given below:
� connection(String roadNetwork, String IP, String hostname)
� updateVehicleInformation(int clientID, double vehicleID, double speed, double accelera-
tion, double length, int pipeID, double objPosition, int vehicleNo, double simTime)
� disconnect(int clientID)
The �connection()� method sends the road network de�nition �le, IP, and hostname of the sim-
ulator to the emission application . After execute this method, it returns a �clientID�. This �Clien-
tID� is used as a unique identi�er for afterward communication to handle multiple clients by the
emission application. The �updateVehicleInformation()� method exchanges the necessary vehicle
information, and the �disconnect()� method disconnect the simulator with the emission application
After de�ning the interface, the emission application converts the interface to the web service
Description Language (WSDL) through the Apache Axis2/Java. This WSDL description allows
the traf�c simulator to utilize the emission web service without knowledge of the implementation
44
details of the service. The WSDL �le contains all the information which are necessary for the
traf�c simulator to invoke the web service methods [36], such as:
� Data types used for method's parameters or return values
� Methods name and signatures
� Protocol and message formats allowed for each method
� URLs to access the web service
After publish the web service, it consumes by the traf�c simulator through the Delphi WSDL
importer tool. Appendix A contains detail information of the description of the Delphi WSDL
�le. This �le hides the communication complexity between these two applications, and the traf�c
simulator calls the necessary web service via the interface. The Figure: 3.10 shows the simpli-
�ed class diagram of the web service communication between these two applications. In web
service communication, vehicle information is exchange individual/collection after each update
of vehicle object or after �nish the vehicles object list. After each update of the vehicle object,
the necessary information of the vehicle is collected by the �CollectVehicleInfo_WSDL()� method
of the �ConnectEmission� class. And after collecting vehicle information the �SendVehicleIn-
foWSDL()� method sends these information as SOAP message to the emission prediction appli-
cation via the "ProjecteStarter" class. In CORBA, the collie object is identi�ed by the IOR which
is retrieved from the naming service, but in web service collie service is identi�ed by the URL (i.e.,
http://IP_Address:8080/WebService/services/ProjectStarter.ProjectStarterHttpSoap11Endpoint/), which
act as a CORBA IOR to locate the web service.
45
+Init()+InitORB()+InitTime()+readCNFFile()+getHostIP()+Connect()+disconnect()+CollectVehicleInfo()+CollectVehicleInfo_WSDL()+SendIndividualVehicleInfo()+SendVehicleInfo()+SendVehicleInfoWSDL()
+aorb : TORB Object+aobj : CORBAObject+ServerInterfaceObj : ServerInterface object(idl)+ClientInterfaceObj : ClientInterface object(idl)+hostName : String+hostIP : String+cnfFile : String+VehicleInfo : vehicle Object
ConnectEmission
+ObjectUpdate()+DecideRoute()+DecideSpeed()+MoveVehicle()+FindVehicleAhead() : Basic Object
+RefVehicle : VehicleVehicle
+ReadCnfData()+ReadCnfConnections()+SetRingPointers()+GoNext() : Basic Object+GoPrev() : Basic Object
+IdNo : Long+ObjType : Long+ObjLength : Double+ObjSpeed : Double+ObjPosit : Double+ObjWidth : Double+PrevObj, NextObj : Basic Object
Basic Object
+ViewEmissionWindow()+DrawChart()+CalculateSimulationInformation()+SetTrackBarPosition()
ChartTime : TChart ObjectSeries1 : TPieSeries Object
MeasureEmission
Emission
1 1
1
1
The Emission prediction application is theanothe part of this whole project [1].
+connection() : Integer+updateVehicleInformation()+disconnect()
+roadNetwork : String+IP : String+hostName : String+VehicleInformation : Vehicle+ClientID : Integer
ProjectStarter/WSDL file
+connection()+updateVehicleInformation()+disconnect()
WSDL Interface
1 1
*1
1 1
Figure 3.10: Class diagram of the web service communication
46
Chapter 4 System Evaluation
The objective of the chapter is to evaluate the performance of information communication be-
tween traf�c simulation and emission estimation application. The communication time is measured
in different communication mode and with different vehicle demand (number of vehicles gener-
ated by a vehicle generator per hour) to a particular road network. Figure: 4.1 shows the system
evaluation �ow chat. The system evaluation is divided into two different ways, i.e., CORBA and
web service. In CORBA communication it is divided into two parts, such as, synchronous and
asynchronous. The synchronous communication time is also tested in same system (both appli-
cation running in a single computer) and different system (applications running in two different
computers). And these evaluations are also performed in two different road networks.
4.1 CORBA Synchronous Communication (Same Computer)
The computer that is used to measure the communication time is consist of a standard System
with core 2 duo with 1.80 GHz CPU, 2.00 GB memory and 32 bit vista operating system. In the
same system evaluation the communication is measured in two different road networks which are
described below.
4.1.1 A Single Lane Road Network
The con�guration of the single lane road network is presented in Figure: 4.2. This road network
has one segment (consist of three lane segments), one vehicle generator and one vehicle destina-
tion. To measure the communication time, the simulation is running in fast mode for 10 minutes in
different vehicle demand. The Table: 4.1 shows the vehicle information exchanging time in differ-
ent modes (i.e., single, collection, and thread) with the emission estimation application in different
vehicle demand. Figure: 4.3 builds by using the data of the Table: 4.1. From the Figure: 4.3,
it is obvious that the �collection� communication mode is the most ef�cient one. And after that
�thread� communication mode is better compare to �individual� or �single� communication mode.
The �thread� mode is better in synchronous communication, because the waiting time for receiv-
ing the acknowledgement from the emission application resides inside the thread. And this waiting
time is used by the next vehicle object to update its status.
4.1.2 A Large Intersection Road Network
The con�guration of the large intersection road network is presented in Figure: 4.4. In this
evaluation scenario, the simulation runs under fast mode for 10 minutes. And the road network
47
System Evaluation
Small Road Network
Synchronous
Same System
Web ServiceCORBA
Different System
Asynchronous
Big Road Network
Figure 4.1: System evaluation �ow chart
Figure 4.2: A single lane road network
48
Vehicle Flow/hr. Sim Time(Min.) Communication Mode Communication Time(Sec.) Total Vehicles400 8.346 67800 18.736 1331200 10 Single 13.512 1911600 15.309 2622000 13.447 326
400 6.002 67800 8.205 1331200 10 Collection 2.089 1911600 1.661 2622000 2.33 326
400 8.36 67800 15.875 1331200 10 Thread 13.576 1911600 13.433 2622000 13.541 326
Table 4.1: Vehicle information exchanging time in different modes (Single, Collection, andThread) with the emission estimation application in different Vehicle demand for a small roadnetwork (same computer)
8.346
18.736
13.51215.309
13.447
6.002
8.205
2.089 1.661 2.33
8.36
15.875
13.576 13.433 13.541
01.5
34.5
67.5
910.5
1213.5
1516.5
1819.5
400 800 1200 1600 2000
Vehicle demand/ hour
Compare the vehicle information communication time in different mode
Single ModeGroup ModeThread Mode
Com
mun
icatio
ntim
eins
econ
d
Figure 4.3: Vehicle information sharing time in different communication mode for a single laneroad network (single computer)
49
Figure 4.4: A large intersection road network
con�guration consists of 15 vehicle generators and 20 to 30 road segments. The Table: 4.2 shows
the communication time in different mode, (i.e., single, collection, and thread) and different vehicle
demand for exchanging vehicle information with the emission estimation application. Figure:
4.5 builds from the data of the Table: 4.2. From the Figure: 4.5 it is clear that the �collection�
communication mode is the most ef�cient one. And compare to �thread� communication �single�
communication mode is better in low vehicle demand, but for high vehicle demand the �thread� is
better. Because in low vehicle demand, (i.e., demand less than or equal to 1200, and number of
vehicle less than 3000) the traf�c simulator and communication platforms are fast enough to handle
all the remote calls in every vehicle objects update cycle. But in the higher demand, the numbers
of vehicles are increased. And in this case, the �thread� communication is ef�cient because the
waiting time to receive the acknowledgement from the emission application resides inside the
thread. And this waiting time could be used by the traf�c simulator to update the next vehicle
status. Even though the thread management is expensive but in higher vehicle demand it is ef�cient
due to the large number of synchronized remote calls.
4.2 CORBA Synchronous Communication (Different Computers)
In this scenario, we use two different computers to run these two applications to evaluate the
communication time. In this case, we also use run the simulator in fast mode for 10 minutes to
simulate the vehicles. The emission estimation application is running in a standard System with
core 2 duo with 1.80 GHz CPU, 2.00 GBmemory and 32 bit vista operating system. And the traf�c
simulator is running in a VirtualBox on PCLinux 7, with Intel(R) Pentium D 2.80GHz, 1.00GB of
RAM, Windows XP Professional SP2. 50
Vehicle Flow/hr. Sim Time(Min.) Communication Mode Communication Time(Sec.) Total Vehicles400 170 1003800 333.615 19631200 10 Single 382.109 29801600 432.148 38812000 383.472 4867
400 28.106 1003800 31.058 19631200 10 Collection 41.57 29801600 38.67 28812000 32.801 4867
400 262.172 1003800 383.644 19631200 10 Thread 398.48 29801600 402.737 28812000 323.635 4867
Table 4.2: Vehicle information exchanging time in different modes (Single, Collection, andThread) with the emission estimation application in different Vehicle demand for a large inter-section road network (same computer)
170
333.615
382.109
432.148
383.472
28.106 31.058 41.57 38.67 32.801
262.172
383.644 398.48 402.737
323.635
0306090
120150180210240270300330360390420450
400 800 1200 1600 2000
Vehicle demand/ hour
Compare the vehicle information communication time in different mode
Single Mode
Collection Mode
Thread Mode
Com
mun
icatio
ntim
ein
seco
nd
Figure 4.5: Vehicle information sharing time in different mode for a large intersection road network(same computer)
51
Vehicle Flow/hr. Sim Time(Min.) Communication Mode Communication Time(Sec.) Total Vehicles400 1.753 67800 2.804 1331200 10 Single 3.289 1911600 3.192 2622000 2.901 326
400 0.852 67800 1.705 1331200 10 Collection 1.361 1911600 1.609 2622000 1.357 326
400 1.588 67800 3.059 1331200 10 Thread 2.555 1911600 3.242 2622000 2.59 326
Table 4.3: Vehicle information exchanging time in different modes (Single, Collection, andThread) with the emission estimation application in different Vehicle demand for a single laneroad network (different computers)
4.2.1 A Single Lane Road Network
The small road network con�guration is provided in Figure: 4.2. The traf�c simulator
is running in fast mode for 10 minutes and measure the communication time in different vehicle
demands. The measured data is presented in Table: 4.3. By using the data of the Table: 4.3, Figure:
4.6 is constructed. From the Figure: 4.6, it is clear that the �collection� communication mode is
the most ef�cient. And after that in any vehicle demand �thread� communication method is better
than �individual� communication mode. Because in remote communication synchronization time
is higher; and in �thread� mode this time is used by the following vehicle object to update its status.
4.2.2 A Large Intersection Road Network
The large intersection road network image is provided in Figure: 4.4. In this case, the simulation
also runs in fast mode for 10 minutes. The Table: 4.4 shows the communication time of the
individual, collection, and thread communication mode. The Figure: 4.7 builds from the data of
the Table: 4.4. It is straightforward from the Figure: 4.7 that the �collection� communication
method is the most ef�cient. It is the ef�cient way of communication in all the vehicle demand.
And the others communication ways are very expensive compare to the collection sending.
52
1.753
2.804
3.289 3.1922.901
0.852
1.7051.361
1.6091.357
1.588
3.059
2.555
3.242
2.59
0
0.5
1
1.5
2
2.5
3
3.5
4
400 800 1200 1600 2000
Vehicle demand/ hour
Compare the vehicle information communication time in different mode
Single Mode
Collection Mode
Thread Mode
Com
mun
icat
ion
time
inse
cond
Figure 4.6: Vehicle information sharing time in different communication mode for a single laneroad network (different computers)
Vehicle Flow/hr. Sim Time(Min.) Communication Mode Communication Time(Sec.) Total Vehicles400 49.089 930800 55.173 19631200 10 Single 62.496 29801600 70.034 38812000 56.578 4867
400 19.036 1003800 26.175 19631200 10 Collection 28.653 29801600 32.223 38812000 26.13 4867
400 39.066 1003800 63.753 19631200 10 Thread 82.988 29801600 69.71 38812000 56.839 4867
Table 4.4: Vehicle information exchanging time in different modes (Single, Collection, andThread) with the emission estimation application in different Vehicle demand for a large inter-section road network (different computers)
53
49.08955.173
62.496
70.034
56.578
19.036
26.175 28.65332.223
26.13
39.066
63.753
82.988
69.71
56.839
152025303540455055606570758085
400 800 1200 1600 2000
Vehicle demand/ hour
Compare the vehicle information communication time in different mode
Single Mode
Collection Mode
Thread Mode
Com
mun
icatio
ntim
ein
seco
nd
Figure 4.7: Vehicle information sharing time in different communication mode for a large inter-section road network (different computers)
Comm. Mode Synchronous Comm. Time(Sec.) Asynchronous Comm. Time(Sec.)Single 70.018 9.884
Collection 36.815 2.395Thread 68.355 5.174
Table 4.5: CORBA Synchronous and Asynchronous communication time table
4.3 CORBA Asynchronous Communication
Asynchronous (or deferred synchronous) communication method is the most ef�cient way of
communication, because of no waiting time for receiving the acknowledgement. Table: 4.5 shows
the synchronous asynchronous communication time in different modes. To measure these time
we use the large intersection road network (i.e., Figure: 4.4) and run the simulation in fast mode
for two minutes in 800 vehicle demands. From the table, it is clear that within these three com-
munication methods (individual, collection, and thread) collection communication method is the
most ef�cient and after that thread communication. Though the thread creation and managing is
expensive but it is faster because the sending time is used by the simulator for updating the follow-
ing vehicle. The drawback of asynchronous communication is that the lost of vehicle information,
and the emission application has to maintain the order of vehicle information. For that reason the
emission estimation application needs to perform extra computation to maintain the order. And for
losing the vehicle information the emission estimation is not so precise compare to the synchro-
nous communication data.
54
Comm. Mode Synchronous Comm. (Sec.) Asynchronous Comm. (Sec.) WS Comm. (Sec.)Single 70.018 9.884 <120
Collection 36.815 2.395 Not TestedThread 68.355 5.174 Not Tested
Table 4.6: Web Service and CORBA communication time comparison
4.4 Web Service Communication
The web service communication method is the most expensive for exchanging the vehicle infor-
mation with the emission prediction application. Because it uses the SOAP messages for commu-
nication, and SOAP is an XML based messaging format which requires a lot of data to represent
a small message compare to CORBA. The XML encoding is also expensive. Generating and pars-
ing of XML documents require huge memory and CPU cycles as well. And it also consumes a lot
of bandwidth for network communication. The Figure: 4.6, shows the comparison of communica-
tion time between CORBA & web service. To measure these time we use a large intersection road
network (i.e., Figure: 4.4) and run the simulation in fast mode for two minutes in 800 vehicle de-
mand. From the Table: 4.6, it is clear that the web service is the most expensive. Because for two
minutes simulated time only the communication takes more than two minutes. So, web service
is not a good choice for the online emission estimation, where we need a large number of remote
communications and also need to send large amount of data.
55
Chapter 5 Conclusion & Future Research
This chapter summarizes the main contributions and results of the thesis, and the limitations
which can be addressed in future.
In the �rst part of this thesis, I study and investigate the different kinds of traf�c simulation
models and specially the KTH-TPMA traf�c simulator, which is a microscopic traf�c simulator.
It needs to understand the detail architecture, i.e., hierarchy of objects and its relationships, object
interaction models, event handling mechanisms, object update principals, different driver behavior
models, de�nition of road network model and its loading procedures, how the objects connected
and updated its states over time, and the different mechanisms of updating the simulation clock.
After that, I need to load the reformatted road network de�nition model inside the simulator, which
is XML based. Because in the text base road network de�nition model there is no lane segment
de�nition (i.e., group of segments or a part of road network), but for measure emission in a practical
way we need to group the small segments of roads into reasonable way. And the other bene�ts of
this XML road de�nition are that it could be loaded by other traf�c simulator if they agree on the
tags, and readability is much higher than the text base. After adopted the KTH-TPMA now it can
load both text and XML based road de�nition models.
In the second part, I study and investigate different communication middleware which are �t
for the heterogeneous environment and performance ef�cient for the real time emission compu-
tation. CORBA and Web Service communication platform is implemented to share the online
vehicle information with emission estimation application. To implement the CORBA communi-
cation platform, �rst explore the MTDORB, which is an open source ORB for Delphi but due to
con�ict with the simulators source codes, �nally decide to use VisiBroker ORB. To exchange the
vehicles information online, three different communication ways (i.e., individual, collection, and
thread) are implemented in both synchronous and asynchronous ways. But before exchanging the
vehicle information it needs to know which speci�c information is needed by the emission esti-
mation models to measure the emission. For measuring emission, POLY and Mobile6 emission
estimation models are used. Appendix B shows the emission values of the selected lane segment,
and the appendix C shows the comparisons between emission values which are produced by dif-
ferent emission models. To implement the communication platform, the KTH-TPMA code needs
to keep integral and add this part as a module. And the Web Service communication mechanism is
also tested. To implement this, we use Apache Axis2/Java and the Delphi WSDL importer tool.
56
In the third part, we evaluate (Chapter: 4) the performance of the communication platform in
different ways (Figure: 4.1). In CORBA communication, we test both synchronous (Section: 4.1
& 4.2) and asynchronous (Section: 4.3) ways. In synchronous method, we test the performance
by running both applications into the same computer as well as in different computers in the net-
work. And in each case, we test it both single lane and multilane road networks in different vehicle
demands (i.e., number of vehicles generated by the vehicle generators per hour). And in the asyn-
chronous communication mechanism, we �nd that the communication time is too small (less than
10% of simulation running time) compare to the synchronous mechanism. The draw back of the
asynchronous communication is the loss of vehicle information and extra computation is needed
by the emission application to maintain the order of vehicle data. Even though the loss of data
and extra computation, it is the most ef�cient way for exchange information online. And the loss
of data is not very effective for emission computation because the emission application estimate
emission once per second. But, it could be happen that the measured emission value may not be
so precise compare to synchronized communication data. We also test the Web Service commu-
nication (Section: 4.4), but we �nd that, only the remote communication time is more than the
prede�ned simulation running time (i.e., if we want to run simulation for 2 minutes but the com-
munication charges more that 2 minutes). Time is an important factor for real time applications,
as the Web Service communication makes the simulator running slower than the real time so the
main goal of this project is lost. Among all of these communication mechanisms we �nd that the
CORBA asynchronous communication is the most effective for real time emission computation.
In future, different kinds of traf�c simulation application could be integrated with this emission
estimation system for computing the emission, such as, macroscopic traf�c simulator. And also
the KTH-TPMA traf�c simulation application can be update to get the real life traf�c data through
the sensors, which are connected with the real traf�c road network, and the emission application
can estimate the real life traf�c emission by using these data.
57
References
[1]. Z. Huang, 2009. Dynamic Emission Prediction Platform and its Integration with MicroscopicTraf�c Simulator, Uppsala University, Sweden.
[2]. A. Torok. Estimation method for emission of road transport, http://www-sre.wu-wien.ac.at/ersa/ersaconfs/ersa06/papers/489.pdf
[3]. H. Johansson, Environment Section. Swedish Road Administration.http://www.naturvardsverket.se/
[4]. Künzli et. al. Public health impacts of outdoor and traf�c-related air pollution: a Europeanassessment. Lancet, 2000.
[5]. M. Känsäkoski, 2008. Rapid Traf�c Emission Measurement Technology,www.vtt.�/liitetiedostot/uutta/ViaNordica_Kansakoski.ppt
[6]. R. Berkowicz, M. Winther, M. Ketzel. Traf�c pollution modelling and emission data,ftp://ftp.elet.polimi.it/users/Giorgio.Guariso/papers%202000-07/08002213561209687.pdf
[7]. H. Zhou, D. Sperling. Traf�c Emission Pollution sam-pling and analysis on urban street with high-rising buildings.http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1020&context=itsdavis
[8]. H. Liu, 2009. CE3210: Introduction to Transport Engineering, Univer-sity of Minnesota, Lecture Notes in Transport Engineering, January 21, 2009.http://www.ce.umn.edu/~liu/ce3201/introduction.pdf
[9]. Robert E. Shannon. Introduction to the Art and Science of Simulation, http://delivery.acm.org
[10]. Microsim, California Department of Transportation, http://www.dot.ca.gov
[11]. California Department of Transportation publication. Guidelines for Applying Traf�c Mi-crosimulation Modeling Software.
[12]. Daiheng Ni. 2DSIM: A Prototype of Nanoscopic lkaf�c Simulation,http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01212881
[13]. Microscopic Traf�c Simulation. Helsinki University of Technology,http://www.tkk.�/Units/Transportation/ITS/Source/Posters/Poster_Microsim.pdf
[14]. T. Toledo. Topics in Traf�c Simulation and Travel Behaviour Modeling,http://www.graduate.technion.ac.il/heb/StudentsResearch/toledo.pdf
[15]. Smit et al., 2008 R. Smit, M. Poelman and J. Schrijver. Improved road traf�c emission inven-tories by adding mean speed distributions, http://www.sciencedirect.com
58
[16]. Affum and Brown, 1999 J.K. Affum and A.L. Brown. Estimating urban air pollution levelsfrom road traf�c in TRAEMS approach, http://www.sciencedirect.com
[17]. Namdeo, A., Mitchell, G. & Dixon, R. (2002) TEMMS: an integrated package for modellingand mapping urban traf�c emission and air quality, Environmental Modelling &Software.
[18]. Lindley, J.A. , 1987. Urban freeway congestion: quanti�cation of the problem and effective-ness of potential solutions.
[19]. Lindley, J.A. , 1989. Urban freeway congestion problems solutions: an update.
[20]. Robin Smit. School of Environmental Planning, Gif�th University. An Examination of Con-gestion in Road Traf�c Emission Models and Their Application to Urban Road Networks.
[21]. Hualiang (Harry) Teng, Lei Yu and Yi (Grace) Qi. Statistical Microscale Emission ModelsIncorporating Acceleration and Deceleration.
[22]. Mobile6. http://http-server.carleton.ca/~dkarman/82571/MOBILE6_05.ppt
[23]. Xiaoliang Ma. Report on Development of KTH-TPMA Windows 1.0.
[24]. Iisakki Kosonen, 1999. HUTSIM � Urban Traf�c Simulation and Control Model Principlesand Applications.
[25]. Qi Yang, 1997. A Simulation Laboratory for Evaluation of Dynamic Traf�c ManagementSystems.
[26]. Wikipedia, Distributed Computing. http://en.wikipedia.org/wiki/Distributed_Computing
[27]. Sockets. http://www.cs.umanitoba.ca/~comp3010/Documents/03DistributedProgramming-2Sockets-4up.pdf
[28].Wikipedia, Message Passing Interface. http://en.wikipedia.org/wiki/Message_passing_interface
[29]. Wikipedia, Service-oriented architecture. http://en.wikipedia.org/wiki/Service-oriented_architecture#Bene�ts
[30]. Wikipedia, IIOP. http://en.wikipedia.org/wiki/IIOP
[31]. IIOP, http://www4.informatik.uni-erlangen.de/~geier/corba-faq/iiop.html
[32]. The CORBA Architecture, http://slsbd.psi.ch/pub/slsnotes/tmeta030225/node2.html
[33]. MTDORB. Sourceforge. http://sourceforge.net/projects/mtdorb
59
[34].Wikipedia, Object Managemnt Group. http://en.wikipedia.org/wiki/Object_Management_Group
[35]. An alternative view, particularly after initial deployments, denies that SOAs properly oughtto dictate physical implementation, so the formal de�nition should not include �network�. High-performance SOAs may not be viable, especially if deployed to distributed nodes on a network.Separate nodes for every (or most) services could become prohibitively expensive.
[36]. ORACLE. http://edocs.bea.com/wlw/docs101/guide/webservices/conWsdlFiles.html
[37]. Wikipedia, SOAP. http://en.wikipedia.org/wiki/SOAP
[38]. H. J. Payne, 1978. FREFLO: A macroscopic simulation model of freeway traf�c.
[39]. Y. Shef�, H. Mahmassani, and W. B. Powell, 1982. A transportation network evacuationmodel.
[40]. E. K. K. M. C. P. M. S. Song, 1997. Enhancements of the kronos simulation package and data-base for geometric design planning, operations and traf c management in freeway networks/corrid.
[41]. Y. Wang, 2001. Freeway network simulation and dynamic traf c assignment with metanettools.
[42]. H. S. Habib, 2003. Metacor: a dynamic macroscopic modeling tool for corridor traf�c.
[43]. M. Minuth, 1996. Lattice theory and metropolis simulation.
[44]. GAINESVILLE, 2008. Dynamic network assignment-simulation model for advanced road-way telematics.
[45]. M. van Aerde, 1992. INTEGRATION: A dynamic traf�c simulation / assignment model.
[46]. PTV, 2003. VISSIM User's Manual 3.7, PTV AG, Karlsruhe.
[47]. Toledo, T., H. Koutsopoulos, A. Davol, M.E. Ben-Akiva, W. Burghout, I. Andreasson, T.Johansson & C. Lundin, 2003. Calibration and validation of microscopic traf�c simulation tools:Stockholm Case Study.
[48]. US-DoT, 1995. TRAF user reference guide, Federal Highway Administration.
[49]. FHWA, 1980. Development and testing of INTRAS: a microscopic freeway simulationmodel.
[50]. FHWA, 1994l. FRESIM User Guide. Technical Report Version 4.5.
[51]. I. Mitrani, 1982. Simulation techniques for discrete event systems.
60
[52]. A. Cappiello, 1998. Modeling Traf�c Flow Emissions.
61
Appendix A Delphi format of the WSDL �le
This appendix describes the Delphi format of the WSDL de�nitions and presents the �lewhich contains the description of all the necessary information that is needed to call the emissionWeb Service:
� Location of the service,
� Web Service type,
� Available functions,
� Arguments for each function and the data type of these arguments,
� And the data type of each return value of each functions.
The location of the service is mentioned in the URL (i.e., URL : http://130.237.64.142:8080/WebService/services/ProjectStarter.ProjectStarterHttpSoap11Endpoint/). And all the functionsare placed inside the interface (i.e., ProjectStarterPortType = interface(IInvokable)). And the listsof available functions are given below:
� function connection(const roadNetwork: string; const IP: string; const hostname: string):
Integer; stdcall;
� function updateVehicleInformation(const clientID: Integer; const vehicle: VehicleInfor-
mationWSDL; const vehicleNo: Integer): Boolean; stdcall;
� function disconnect(const clientID: Integer): Boolean; stdcall;
The "Connection()" function has three parameters (i.e., roadNetwork, IP, and hostname),the �roadNetwork� parameter passes the road de�nition �le to the emission application, �IP�,and �hostname� sends the IP and hostname of the simulator accordingly. This function returnsan integer �ClientID� which act as a unique identi�er to handle multiple clients by the emissionapplication. The �updateVehicleInformation()� function has three parameters, which sends thevehicle information, total vehicle number in the traf�c simulator, and the unique client ID to theemission application. And it returns a Boolean value after �nish calling. And the �disconnect()�function disconnect the traf�c simulator from the emission application. The traf�c simulator onlysends the cline ID to get disconnected. And it returns a Boolean value after execute this function.To invoke these methods we only need to know the interface (i.e., ProjectStarterPortType) throughwhich the KTH-TPMA traf�c simulator and the emission estimation application exchange the realtime vehicle information. And if the address of the Web Service is changed then we only need toreplace the old IP address with the new one inside the URL and the rest of the part is same.
// ************************************************************************//
// The types declared in this �le were generated from data read from the// WSDL File described below:// WSDL : http://localhost:8080/Hello/services/ProjectStarter?wsdll// >Import : http://localhost:8080/Hello/services/ProjectStarter?wsdll>0// >Import : http://localhost:8080/Hello/services/ProjectStarter?wsdll>1// Encoding : UTF-8// Version : 1.0
62
// (2009-2-18 15:26:28 - - $Rev: 16699 $)// ************************************************************************
//unit ProjectStarter2;interfaceuses InvokeRegistry, SOAPHTTPClient, Types, XSBuiltIns;constIS_OPTN = $0001;IS_UNBD = $0002;IS_NLBL = $0004;IS_REF = $0080;type// ************************************************************************
//// The following types, referred to in the WSDL document are not being represented// in this �le. They are either aliases[@] of other types represented or were referred// to but never[!] declared in the document. The types from the latter category// typically map to prede�ned/known XML or Borland types; however, they could also// indicate incorrect WSDL documents that failed to declare or import a schema type.// ************************************************************************
//// !:double - "http://www.w3.org/2001/XMLSchema"[Gbl]// !:int - "http://www.w3.org/2001/XMLSchema"[Gbl]// !:boolean - "http://www.w3.org/2001/XMLSchema"[Gbl]// !:string - "http://www.w3.org/2001/XMLSchema"[Gbl]VehicleInformationWSDL = class; { "http://emissionTPMAServer/xsd"[GblCplx] }// ************************************************************************
//// XML : VehicleInformationWSDL, global, <complexType>// Namespace : http://emissionTPMAServer/xsd// ************************************************************************
//VehicleInformationWSDL = class(TRemotable)privateFacceleration: Double;Facceleration_Speci�ed: boolean;Flength: Double;Flength_Speci�ed: boolean;FobjPosition: Double;FobjPosition_Speci�ed: boolean;Fspeed: Double;Fspeed_Speci�ed: boolean;FvehicleID: Double;FvehicleID_Speci�ed: boolean;Fwidth: Double;Fwidth_Speci�ed: boolean;FX1: Integer;FX1_Speci�ed: boolean;FX1s: Integer;FX1s_Speci�ed: boolean;FX2: Integer;FX2_Speci�ed: boolean;FX2s: Integer;FX2s_Speci�ed: boolean;FY1: Integer;FY1_Speci�ed: boolean;FY1s: Integer;FY1s_Speci�ed: boolean;FY2: Integer;FY2_Speci�ed: boolean;
63
FY2s: Integer;FY2s_Speci�ed: boolean;FpipeID: Integer;FpipeID_Speci�ed: boolean;Ftype_: Integer;Ftype__Speci�ed: boolean;procedure Setacceleration(Index: Integer; const ADouble: Double);function acceleration_Speci�ed(Index: Integer): boolean;procedure Setlength(Index: Integer; const ADouble: Double);function length_Speci�ed(Index: Integer): boolean;procedure SetobjPosition(Index: Integer; const ADouble: Double);function objPosition_Speci�ed(Index: Integer): boolean;procedure Setspeed(Index: Integer; const ADouble: Double);function speed_Speci�ed(Index: Integer): boolean;procedure SetvehicleID(Index: Integer; const ADouble: Double);function vehicleID_Speci�ed(Index: Integer): boolean;procedure Setwidth(Index: Integer; const ADouble: Double);function width_Speci�ed(Index: Integer): boolean;procedure SetX1(Index: Integer; const AInteger: Integer);function X1_Speci�ed(Index: Integer): boolean;procedure SetX1s(Index: Integer; const AInteger: Integer);function X1s_Speci�ed(Index: Integer): boolean;procedure SetX2(Index: Integer; const AInteger: Integer);function X2_Speci�ed(Index: Integer): boolean;procedure SetX2s(Index: Integer; const AInteger: Integer);function X2s_Speci�ed(Index: Integer): boolean;procedure SetY1(Index: Integer; const AInteger: Integer);function Y1_Speci�ed(Index: Integer): boolean;procedure SetY1s(Index: Integer; const AInteger: Integer);function Y1s_Speci�ed(Index: Integer): boolean;procedure SetY2(Index: Integer; const AInteger: Integer);function Y2_Speci�ed(Index: Integer): boolean;procedure SetY2s(Index: Integer; const AInteger: Integer);function Y2s_Speci�ed(Index: Integer): boolean;procedure SetpipeID(Index: Integer; const AInteger: Integer);function pipeID_Speci�ed(Index: Integer): boolean;procedure Settype_(Index: Integer; const AInteger: Integer);function type__Speci�ed(Index: Integer): boolean;publishedproperty acceleration: Double Index (IS_OPTN) read Facceleration write Setacceleration
stored acceleration_Speci�ed;property length: Double Index (IS_OPTN) read Flength write Setlength stored length_Speci�ed;property objPosition: Double Index (IS_OPTN) read FobjPosition write SetobjPosition stored
objPosition_Speci�ed;property speed: Double Index (IS_OPTN) read Fspeed write Setspeed stored speed_Speci�ed;property vehicleID: Double Index (IS_OPTN) read FvehicleID write SetvehicleID stored
vehicleID_Speci�ed;property width: Double Index (IS_OPTN) read Fwidth write Setwidth stored width_Speci�ed;property X1: Integer Index (IS_OPTN) read FX1 write SetX1 stored X1_Speci�ed;property X1s: Integer Index (IS_OPTN) read FX1s write SetX1s stored X1s_Speci�ed;property X2: Integer Index (IS_OPTN) read FX2 write SetX2 stored X2_Speci�ed;property X2s: Integer Index (IS_OPTN) read FX2s write SetX2s stored X2s_Speci�ed;property Y1: Integer Index (IS_OPTN) read FY1 write SetY1 stored Y1_Speci�ed;property Y1s: Integer Index (IS_OPTN) read FY1s write SetY1s stored Y1s_Speci�ed;property Y2: Integer Index (IS_OPTN) read FY2 write SetY2 stored Y2_Speci�ed;property Y2s: Integer Index (IS_OPTN) read FY2s write SetY2s stored Y2s_Speci�ed;property pipeID: Integer Index (IS_OPTN) read FpipeIDwrite SetpipeID stored pipeID_Speci�ed;property type_: Integer Index (IS_OPTN) read Ftype_ write Settype_ stored type__Speci�ed;
64
end;Array_Of_VehicleInformationWSDL = array of VehicleInformationWSDL; { "http://emissionTPMAServer
/xsd"[GblUbnd] }// ************************************************************************
//// Namespace : http://emissionTPMAServer// soapAction: urn:%operationName%// transport : http://schemas.xmlsoap.org/soap/http// style : document// binding : ProjectStarterSoap11Binding// service : ProjectStarter// port : ProjectStarterHttpSoap11Endpoint// URL : http://130.237.64.158:8080/Hello/services/ProjectStarter.ProjectStarterHttpSoap11Endpoint/// ************************************************************************
//ProjectStarterPortType = interface(IInvokable)['{4ADEF51E-4CED-23CD-E7C5-C501EE342043}']function connection(const roadNetwork: string; const IP: string; const hostname: string):
Integer; stdcall;function updateVehicleInformation(const clientID: Integer; const vehicle: VehicleInforma-
tionWSDL; const vehicleNo: Integer): Boolean; stdcall;function disconnect(const clientID: Integer): Boolean; stdcall;function updateVehicleArray(const clientID: Integer; const vehicles: Array_Of_VehicleInformationWSDL):
Boolean; stdcall;end;function GetProjectStarterPortType(UseWSDL: Boolean=System.False; Addr: string=�; HTTPRIO:
THTTPRIO = nil): ProjectStarterPortType;implementationuses SysUtils;function GetProjectStarterPortType(UseWSDL: Boolean; Addr: string; HTTPRIO: THTTPRIO):
ProjectStarterPortType;constdefWSDL = 'http://localhost:8080/Hello/services/ProjectStarter?wsdll';defURL = 'http://130.237.64.158:8080/Hello/services/ProjectStarter.ProjectStarterHttpSoap11Endpoint/';defSvc = 'ProjectStarter';defPrt = 'ProjectStarterHttpSoap11Endpoint';varRIO: THTTPRIO;beginResult := nil;if (Addr = �) thenbeginif UseWSDL thenAddr := defWSDLelseAddr := defURL;end;if HTTPRIO = nil thenRIO := THTTPRIO.Create(nil)elseRIO := HTTPRIO;tryResult := (RIO as ProjectStarterPortType);if UseWSDL thenbeginRIO.WSDLLocation := Addr;RIO.Service := defSvc;RIO.Port := defPrt;end elseRIO.URL := Addr;�nallyif (Result = nil) and (HTTPRIO = nil) then
65
RIO.Free;end;end;procedure VehicleInformationWSDL.Setacceleration(Index: Integer; const ADouble: Dou-
ble);beginFacceleration := ADouble;Facceleration_Speci�ed := True;end;function VehicleInformationWSDL.acceleration_Speci�ed(Index: Integer): boolean;beginResult := Facceleration_Speci�ed;end;procedure VehicleInformationWSDL.Setlength(Index: Integer; const ADouble: Double);beginFlength := ADouble;Flength_Speci�ed := True;end;function VehicleInformationWSDL.length_Speci�ed(Index: Integer): boolean;beginResult := Flength_Speci�ed;end;procedure VehicleInformationWSDL.SetobjPosition(Index: Integer; const ADouble: Dou-
ble);beginFobjPosition := ADouble;FobjPosition_Speci�ed := True;end;function VehicleInformationWSDL.objPosition_Speci�ed(Index: Integer): boolean;beginResult := FobjPosition_Speci�ed;end;procedure VehicleInformationWSDL.Setspeed(Index: Integer; const ADouble: Double);beginFspeed := ADouble;Fspeed_Speci�ed := True;end;function VehicleInformationWSDL.speed_Speci�ed(Index: Integer): boolean;beginResult := Fspeed_Speci�ed;end;procedure VehicleInformationWSDL.SetvehicleID(Index: Integer; const ADouble: Dou-
ble);beginFvehicleID := ADouble;FvehicleID_Speci�ed := True;end;function VehicleInformationWSDL.vehicleID_Speci�ed(Index: Integer): boolean;beginResult := FvehicleID_Speci�ed;end;procedure VehicleInformationWSDL.Setwidth(Index: Integer; const ADouble: Double);beginFwidth := ADouble;Fwidth_Speci�ed := True;end;function VehicleInformationWSDL.width_Speci�ed(Index: Integer): boolean;beginResult := Fwidth_Speci�ed;end;
66
procedure VehicleInformationWSDL.SetX1(Index: Integer; const AInteger: Integer);beginFX1 := AInteger;FX1_Speci�ed := True;end;function VehicleInformationWSDL.X1_Speci�ed(Index: Integer): boolean;beginResult := FX1_Speci�ed;end;procedure VehicleInformationWSDL.SetX1s(Index: Integer; const AInteger: Integer);beginFX1s := AInteger;FX1s_Speci�ed := True;end;function VehicleInformationWSDL.X1s_Speci�ed(Index: Integer): boolean;beginResult := FX1s_Speci�ed;end;procedure VehicleInformationWSDL.SetX2(Index: Integer; const AInteger: Integer);beginFX2 := AInteger;FX2_Speci�ed := True;end;function VehicleInformationWSDL.X2_Speci�ed(Index: Integer): boolean;beginResult := FX2_Speci�ed;end;procedure VehicleInformationWSDL.SetX2s(Index: Integer; const AInteger: Integer);beginFX2s := AInteger;FX2s_Speci�ed := True;end;function VehicleInformationWSDL.X2s_Speci�ed(Index: Integer): boolean;beginResult := FX2s_Speci�ed;end;procedure VehicleInformationWSDL.SetY1(Index: Integer; const AInteger: Integer);beginFY1 := AInteger;FY1_Speci�ed := True;end;function VehicleInformationWSDL.Y1_Speci�ed(Index: Integer): boolean;beginResult := FY1_Speci�ed;end;procedure VehicleInformationWSDL.SetY1s(Index: Integer; const AInteger: Integer);beginFY1s := AInteger;FY1s_Speci�ed := True;end;function VehicleInformationWSDL.Y1s_Speci�ed(Index: Integer): boolean;beginResult := FY1s_Speci�ed;end;procedure VehicleInformationWSDL.SetY2(Index: Integer; const AInteger: Integer);beginFY2 := AInteger;FY2_Speci�ed := True;end;function VehicleInformationWSDL.Y2_Speci�ed(Index: Integer): boolean;
67
beginResult := FY2_Speci�ed;end;procedure VehicleInformationWSDL.SetY2s(Index: Integer; const AInteger: Integer);beginFY2s := AInteger;FY2s_Speci�ed := True;end;function VehicleInformationWSDL.Y2s_Speci�ed(Index: Integer): boolean;beginResult := FY2s_Speci�ed;end;procedure VehicleInformationWSDL.SetpipeID(Index: Integer; const AInteger: Integer);beginFpipeID := AInteger;FpipeID_Speci�ed := True;end;function VehicleInformationWSDL.pipeID_Speci�ed(Index: Integer): boolean;beginResult := FpipeID_Speci�ed;end;procedure VehicleInformationWSDL.Settype_(Index: Integer; const AInteger: Integer);beginFtype_ := AInteger;Ftype__Speci�ed := True;end;function VehicleInformationWSDL.type__Speci�ed(Index: Integer): boolean;beginResult := Ftype__Speci�ed;end;initializationInvRegistry.RegisterInterface(TypeInfo(ProjectStarterPortType), 'http://emissionTPMAServer',
'UTF-8');InvRegistry.RegisterDefaultSOAPAction(TypeInfo(ProjectStarterPortType), 'urn:%operationName%');InvRegistry.RegisterInvokeOptions(TypeInfo(ProjectStarterPortType), ioDocument);RemClassRegistry.RegisterXSClass(VehicleInformationWSDL, 'http://emissionTPMAServer/xsd',
'VehicleInformationWSDL');RemClassRegistry.RegisterExternalPropName(TypeInfo(VehicleInformationWSDL), 'type_',
'type');RemClassRegistry.RegisterXSInfo(TypeInfo(Array_Of_VehicleInformationWSDL), 'http://emission
TPMAServer /xsd', 'Array_Of_VehicleInformationWSDL');RemClassRegistry.RegisterSerializeOptions(TypeInfo(Array_Of_VehicleInformationWSDL),
[xoInlineArrays]);end.
68
Appendix B Lane Segment Emission
This appendix shows the emission values (Figure: B.1) of the selected lane segment of theroad network [1].
Figure B.1: Lane Segment Emission
69
Appendix C Emission Comparision
This appendix shows the emission value comparision (Figure: C.1) between POLY, Mobile6,and Euro3 Model. The Mobile6 and Euro3 model produced emission values are close but POLY'semission value is higher than these models. The POLY emission value is higher because it producesemission based on the vehicles produced in 1975 - 1980. But Mobile6 uses the 2003 context andEuropean Emission Standard 3 is for 2000 passenger cars [1].
Figure C.1: Emission Comparision in Different Models
70
