Dynamic Emission Prediction Platform and Its Integration with Microscopic Traffic ...uu.diva-portal.org/smash/get/diva2:233900/FULLTEXT01.pdf · 2009. 9. 3. · Emission estimation

IT 09 019

Examensarbete 30 hpApril 2009

Dynamic Emission Prediction Platform and Its Integration with Microscopic Traffic Simulation

Zhen Huang

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress: Box 536 751 21 Uppsala

Telefon:018 – 471 30 03

Telefax: 018 – 471 30 00

Hemsida:http://www.teknat.uu.se/student

Abstract

Dynamic Emission Prediction Platform and ItsIntegration with Microscopic Traffic Simulation

Zhen Huang

With the increase of traffic congestion and vehicle emission, environmental pollutionbecomes an important concern for traffic policy makers and traffic planners in theirdecision-making process. In order to study and reduce road transport emissions, anaccurate estimation of emission amount is crucial for traffic planning and managementpurposes.

The emission value from the traffic on a given road section depends strongly on thestate of vehicles. The basis for a detailed estimation is therefore the emit rate as afunction of instantaneous vehicle state such as speed, acceleration etc.

In this thesis, an application is built by integrating emission simulation with the trafficsimulator at KTH-TPMA, which is a real time application for imitating real trafficsituations, to predict emission value. The approach adopted is based on vehicle datafrom traffic simulations which serve as real world traffic data provider. With thisapplication, traffic simulation and emission simulation could be executed with adistributed computing approach. The thesis investigates how these twosimulations are implemented in a computer simulation system and theirperformance and accuracy.

The major contribution of this thesis is its integrating traffic simulation with emissionsimulation to estimate reasonable emission values. It illustrates how these twosimulation applications could be integrated to provide a tool for making policy andplanning.

Key Words: Emission Model Simulation, Traffic Simulator (KTH-TPMA), Distributedcomputing, CORBA and Web Service.

Tryckt av: Reprocentralen ITCIT 09 019Examinator: Anders JanssonÄmnesgranskare: Ivan ChristoffHandledare: Xiaoliang Ma

Contents

1 Introduction 31.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Computer Simulation . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Tra¢ c Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Tra¢ c Impact Computation . . . . . . . . . . . . . . . . . . . 6

1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 De�ned Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6 Preliminary Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 91.7 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Literature Review 102.1 KTH-TPMA Tra¢ c Simulation . . . . . . . . . . . . . . . . . . . . . 102.2 Emission Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Macroscopic Emission Models . . . . . . . . . . . . . . . . . . 142.2.2 Microscale Emission Models . . . . . . . . . . . . . . . . . . . 152.2.3 Discussion and Conclusions . . . . . . . . . . . . . . . . . . . 20

3 System Design and Implementation 223.1 Distributed Computing Approach . . . . . . . . . . . . . . . . . . . . 223.2 Distributed System Architecture . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 SOA and Web Service . . . . . . . . . . . . . . . . . . . . . . 28

3.3 E¢ cient Communication . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 Data Exchanging Mechanism . . . . . . . . . . . . . . . . . . 303.3.2 Synchronous and Asynchronous Information Exchange . . . . 313.3.3 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.5 Tra¢ c Simulation Architecture . . . . . . . . . . . . . . . . . . . . . 373.6 Emission Simulation Architecture . . . . . . . . . . . . . . . . . . . . 38

3.6.1 Data structure layer . . . . . . . . . . . . . . . . . . . . . . . 393.6.2 Logic layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.6.3 GUI layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.7 Web Service Implementation . . . . . . . . . . . . . . . . . . . . . . . 42

i

CONTENTS ii

3.7.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.7.2 Communication Implementation . . . . . . . . . . . . . . . . . 44

4 Evaluation 454.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 POLY Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Mobile 6 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Data Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Conclusion and Discussion 525.1 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

List of Figures

2.1 The Speed Control of TPMA . . . . . . . . . . . . . . . . . . . . . . 122.2 The structure of CMEM . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Comparison between ASMX and WCF . . . . . . . . . . . . . . . . . 233.2 The general organization of CORBA . . . . . . . . . . . . . . . . . . 263.3 CORBA connection initialization of Emission platform and TPMA-

HUTSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 The web service general architecture . . . . . . . . . . . . . . . . . . 293.5 Collective and Individual Sending Comparison . . . . . . . . . . . . . 303.6 Asynchronous sending data . . . . . . . . . . . . . . . . . . . . . . . 323.7 Sending time on di¤erent modes with syn/asyn . . . . . . . . . . . . 333.8 Interface used between TPMA-HUTSIM and Emission Platform. . . . 373.9 Data collecting and sending in TPMA . . . . . . . . . . . . . . . . . 373.10 MVC pattern of Emission Platform . . . . . . . . . . . . . . . . . . . 383.11 The architecture of objects in emission prediction platform modeling . 403.12 UML Diagram of Emission Platform . . . . . . . . . . . . . . . . . . 413.13 The data �ow among client Controller and Connection . . . . . . . . 423.14 runing road network . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.15 emission time series chart . . . . . . . . . . . . . . . . . . . . . . . . 433.16 Web service data �ow . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Emission Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 POLY downhill data . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 POLY uphill data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iii

List of Tables

1.1 Estimated pollution emission in the United States in 2000(thousandshort tons) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 CORBA Sending Time . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 POLY�s Coe¤ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2 Emission Model Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Mobile6 Emission Model Test . . . . . . . . . . . . . . . . . . . . . . 474.3 Mobile6 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 European Emission Standard . . . . . . . . . . . . . . . . . . . . . . 504.6 Transformed Emission Model Test . . . . . . . . . . . . . . . . . . . . 50

iv

Acknowledgement

It has been a pleasure to do the thesis work in Center for Tra¢ cResearch at Royal Institute of Technology. I would like to give mywhole hearted thanks to Dr. Xiaoliang Ma for enrolling me to thework and giving me the fabulous thesis topic and advices.

I wish to express my sincere thanks to my thesis reviewer IvanChristo¤ from Uppsala University who reviews my thesis.

I would also like to thank my thesis partner A.G.Zaman. Weworked along and collaborated very well in a same o¢ ce.

I am greatful to my parents and friends from Uppsala University fortheir encouragements and support.

Chapter 1

Introduction

This thesis is concerned with the development of a prototype softwareplatform for modeling and simulation of transport impacts, in particu-lar, tra¢ c �ow emissions. This chapter introduces the problems whicharouse the thesis. After describing these notions, a short de�nitionof thesis purpose will be given, followed by preliminary studies andmethodologies about how to solve these problems. The thesis overviewgives a short preview of the following chapters which chase after thesame purpose throughout the thesis.

1.1 Background

Transportation plays an important role in our economy and social life.However, road tra¢ c congestion and air pollution have become one ofthe major parts of greenhouse e¤ects and energy consumptions, as theamount of vehicles increases.Congestion not only block tra¢ c which leads to other vehicles more

fuel consumption and low e¢ ciency [1] but also dramatically under-mines the e¢ ciency of transportation, wastes passengers� time (�op-portunity cost�) and increases fuel consumption which leads to air pol-lution and carbon dioxide emissions which accounts for around 80 percent of Swedish greenhouse gas emissions from the combustion of fossilfuels [2].These tra¢ c emissions are harmful to human healthy. According

to health studies, it shows that exposure to exhaust primarily a¤ectsthe respiratory system and worsens asthma, allergies, bronchitis, andlung function. There is some evidence that diesel exhaust exposure can

3

1. Introduction 4

CO NOx VOCIndustrial 1,221 3,222 185Chemical manufacturing 1,112 134 407Metals processing 1,735 91 79On-road vehicles 48,469 8,150 5,035Nonroad vehicles 29,956 5,558 3,404Miscellaneous 20,806 576 2,710

Table 1.1: Estimated pollution emission in the United States in 2000(thousand shorttons)

increase the risk of heart problems, premature death, and lung cancer[3].In addition, emissions also increase green house e¤ect which leads to

global climate changes. Some of the emissions do not prevent sunlightreaching the surface of earth, but trap some of the infrared outgoing ra-diation, which increases the average temperature of earth. Without thenatural greenhouse e¤ect of the atmosphere, the surface of our planetwould be almost 35 degree colder than it is now [4]. The main source ofglobal climate change is human-induced changes in atmospheric compo-sition. These perturbations primarily result from emissions associatedwith energy use [5].Table 1.1 lists where the major emission gases come from in US.

From the table, the emission which is produced by vehicle is the majorpart, which is much more than what emit by industry and chemicalmanufacture.

1.2 Simulation

Simulation is de�ned as the process of creating a model of an existing orproposed system in order to identify and understand those factors whichcontrol the system and/or to predict or forecast the future behavior ofthe system [6]. Simulation includes physical, interactive and computersimulation. For this thesis, we mainly focus on computer simulation.

1. Introduction 5

1.2.1 Computer Simulation

A computer simulation is a computer program which runs on a com-puter or network of computers and imitates real-world�s action. Sincethe future state in real life is complex to understand and predict, weresort computer simulation to achieve these goals through mathemat-ical models which de�nes rules in real world. Simulation applicationallows human to evaluate, compare and optimize alternative designs.It is often used when the consequences of a proposed action, plan ordesign cannot be directly and immediately observed and/or it is simplyimpractical or prohibitively expensive to test the alternatives directly[7]. It is also because of some uncertain factors and objects interactionwhich are di¢ cult to model directly.Computer simulation usually applies a model which is basically a

mathematical representation. Models is represented as the basic rulesof objects action. These equations normally have a list of parameterswhich is calibrated from a mass of tested data. The prediction�s accu-racy depends upon adopted models and parameters it adopts.

1.2.2 Tra¢ c Simulation

Tra¢ c Simulator can be considered as the e¢ cient emulate of vehiclethrough the tra¢ c road network. Tra¢ c system is di¢ cult to analyzeand control because there are too many uncertain factors a¤ect result,such as driver behavior. To overcome these problems, tra¢ c simulationis developed.There are three di¤erent types of Tra¢ c Simulation Models which

are:Macroscopic ModelMacroscopic simulation model simulates tra¢ c �ow by considering

cumulative tra¢ c stream characteristics such as speed, �ow and densityand their relationships. This model considers section by section insteadof tracking individual vehicles. This model is used to predict the spatialand sequential extent of congestion caused by tra¢ c demand or inci-dents in a network. Such as - FREFLO [8], KRONOS [9], METANET[10], METACOR [11].Mesoscopic ModelMesoscopic model combines the properties of both microscopic and

1. Introduction 6

macroscopic simulation models. Mesoscopic model is less consistentcomparing to microscopic model. This model simulates individual ve-hicles without their individual activities and interactions. Such asMETROPOLIS [12], DYNASMART [13], DYNAMIT [14].Microscopic ModelAMicroscopic model describes individual vehicle movements through

the tra¢ c simulation model. It helps capturing the detailed behavior ofdrivers and their interaction with tra¢ c environment. In a Microsim-ulation, each vehicle moves through the tra¢ c network with updatedcharacter which is determined by speed, acceleration, time, and indi-vidual driver behavior. The driver behavior is determined by a set ofmodels such as car following, lane changing, acceleration noise and etc.Microsimulation can be used to develop new tra¢ c systems and op-

timize their e¤ectiveness. It can estimate the impacts of a new schemeby producing outputs on a wide range of measurements of e¤ectiveness.Many of these impacts, such as the amount of emissions, are often di¢ -cult to measure in the �eld. KTH-TPMA in the thesis is a Microscopicmodel.

1.2.3 Tra¢ c Impact Computation

Emission estimation is one of the most essential procedures for tra¢ cimpact analysis. Microscopic emission simulation is built on emissionmodels, and the emission of individual vehicle is determined by onlinestates of vehicle, for example engine speed, acceleration, vehicle typeand even the time how long vehicle has been used. In the project,Emission platform takes online vehicle information from KTH-TPMAas input and applies these data on an emission model to predict theemission on the road network. The emission for a road network is notonly determined by each vehicle running on it but also the geographyof road network, for example the gradient and the altitude of the road.We evaluate di¤erent emission models in this thesis and they will bedescribed in later chapters.

1. Introduction 7

1.3 Problem Statement

Despite there are many attentions on limiting emission and controllingthe air quality and fuel consumption, and it has been major topics innational and local regulation. Nevertheless the direct measurement oftra¢ c emission in the real world is very costly. Emission estimationtechniques are needed to be re�ned to improve the quality [15]. Tomeasure the emission value in a certain road network, we consider toimplement a platform which combines emission prediction with tra¢ csimulators such as KTH-TPMA. KTH-TPMA is a tra¢ c Microscopicsimulator implemented by CTR, KTH (Center for Tra¢ c Research atRoyal Institute of Technology, Sweden). Microscopic tra¢ c simulatoris an application which could help tra¢ c planners to analyze road con-ditions by imitating the real tra¢ c activities and operations.Tra¢ c simulation is a computing intensive application. Because it

runs at a very detailed level, emulating the behavior of every individ-ual entity in the system, therefore its computational a¤ord is higherthan a common application. On the other hand, running a micro sim-ulation of a metropolitan area tra¢ c network involves mimicking thebehavior of cars, tra¢ c signals, pedestrian, intersection etc. so the sim-ulation becomes more computation expensive. Emission simulation isalso computational intensive for emission models are implemented foreach individual vehicle, and these models can be individual or aggregatemodel which is also normally computing intensive.However, it is possible to divide tra¢ c simulation and emission sim-

ulation into two di¤erent and independent modules. Distributed com-puting architecture need to be implemented to set these two parts beexecuted in di¤erent computers. Implementing an emission simulationplatform and modifying KTH-TPMA to be able to send generated ve-hicle information to emission platform are the main objects of the the-sis. We use some well developed emission models from literatures foremission prediction. To simulate emission in a practical way, the roadnetwork is divided into segments. Each of these segments representstra¢ c behavior in an area.Our idea is to build an emission platform to dynamically retrieve

basic vehicle state information from KTH-TPMA and predict emis-sion amounts based on these data with tra¢ c emission models. KTH-

1. Introduction 8

TPMA microscopic tra¢ c simulator is integrated to yield vehicle datafor predicting emission. To predict emission we use distributed comput-ing architecture not only for functionality but also better performance.KTH-TPMA sends vehicle data to Emission Simulation Platform, afteremission prediction �nished, and then Emission Simulation Platformsends back a message to KTH-TPMA.

1.4 De�ned Tasks

In general, the tasks of the thesis include:

� Developing an Emission Prediction Platform which can analyzeonline or o ine emission value with di¤erent models

� Implementation of communication between Emission PredictionPlatform and Tra¢ c simulator in di¤erent approaches, for exampleCORBA and Web Service;

� Evaluate emission prediction value according to received onlineinformation in simulation using di¤erent emission models;

� Visualizing emission estimation results in an interactive way.

Communication between emission and tra¢ c simulation platform issupposed to follow the client-server dual role mode.

1.5 Contribution

This thesis aims to build an integrated system which is able to ap-ply microscopic tra¢ c and emission simulation for predicting emissionvalue on a certain area. It is a joint project by A.G Zaman fromKTH and Zhen Huang from Uppsala University. Zaman is responsi-ble for KTH-TPMA module, which includes microscopic tra¢ c simula-tion and KTH-TPMA side data communication. This thesis is mainlyon implementation of Emission Prediction Platform which listens to aconnection request and data communication from KTH-TPMA. Withthese data, Emission Prediction Platform is able to predict and visu-alize emission on several views. In addition, This thesis also includesdetailed emission model study and evaluation.

1. Introduction 9

1.6 Preliminary Knowledge

As this thesis includes distributed communication of two systems, whichare implemented in Delphi and Java. We use Common Object RequestBroker Architecture (CORBA) for the communication. The technolo-gies below are required:

� CORBA(Visibroker, MTDORB IDLJ and Jacorb);

� Emission models;

� KTH-TPMA tra¢ c simulator;

� Delphi and Java;

� SOA and web service

1.7 Thesis Overview

Chapter 2 reviews some classic models (include tra¢ c simulation andemission simulation) and makes a comparison between them. Chapter3 describes the communication methods between two simulation appli-cations. Because there are several ways for distributed systems com-munication, we discuss what we have tried and their respective prosand cons. This chapter also explains how these simulation applicationsare developed and illustrates their architectures and models. Chapter4 lists the result of the emission prediction and compares the result tostandard value. Chapter 5 concludes the thesis and shows the directionof further development of the thesis.

Chapter 2

Literature Review

According to the table 1.1 in chapter one, vehicle emission is one of themajor sources of air pollution. To estimate the emission quantity, wedescribe microscale tra¢ c simulator and various approaches presentedin literature to model emission simulation which describes the amountof emission produced by single vehicle or vehicles in a road segment inthis chapter. Strengths and weaknesses of these modeling approachesare identi�ed and examples of emission models are presented.

2.1 KTH-TPMA Tra¢ c Simulation

Tra¢ c Performance on Major Arterials (TPMA) was initiated and�nanced by Swedish National Road Administration (SNRA). KTH-TPMA is a further developed application based on it. KTH-TPMA isdeveloped mainly as a workplace which performs actual freeway micro-scopic tra¢ c simulation and deals with details of single driver behaviorsuch as car following and lane changing [16].KTH-TPMA was originally intended for simulation of tra¢ c in sig-

nalized urban street network which is composed of some road segments.Some of these segments have tra¢ c lights to control vehicle �ow. Eachvehicle has its departure point and destination on the road network.The vehicle�s behavior is controlled by its desired speed and varioustra¢ c situation around it. As the Figure 2.1 shows, when the actualspeed is below desired speed and there are enough space for vehicle tomove for example there is a long distance to the vehicle in front of it,the vehicle chooses to speed up which increases its acceleration. Oth-erwise if there is a tra¢ c jam before the vehicle, it has to decelerate

10

2. Literature Review 11

to decrease the speed. Vehicle can change it lane segment dependingon the tra¢ c situation and their desired speed level. The lane whichvehicle originally runs on is called basic lane. When a vehicle detects itis necessary to change lane and there is su¢ cient space both in front ofand behind it, then it jumps to another lane beside the basic one, andchange back when basic lane has enough space for it. Each vehicle ismotivated by its destination, desired speed and its driver behavior withthe tra¢ c condition around it. Each of vehicles tries to reach its desiredspeed through acceleration and lane changing, on the other hand, thespeed of vehicle is limited by tra¢ c lights, tra¢ c congestion and othervehicles in front of it.Vehicle generators can yield vehicle in 4 categories: car, truck, lorry

and bus. The generator produces vehicle continuously running on theroad network within a period of simulation time. The number of vehi-cles and their destinations can be con�gured in con�guration �le or inparameter panel in KTH-TPMA application.In KTH-TPMA there are 2 types of running modes: real time and

fast. In real time mode, it simulates tra¢ c situation according to thetime speci�ed in con�guration �le. In fast mode, it uses all the compu-tation resource that can be collected to run a fast simulation.The basic models in KTH-TPMA are shown in �gure 2.1 [17]. All

the objects in the simulation model are basic tra¢ c objects in general.Each basic tra¢ c object has some elementary properties like identity,double link pointers, size, color, coordinates and status. A basic tra¢ cobject also has general methods like showing or hiding itself, movingand resizing as well as initializing, updating and disposing. Any typeof objects can call these parent methods. However the inherited objectmay also override the actual code to be executed by the function call[16].A simulation is performed based on one con�guration �le which de-

�nes a road network. The road network is composed of several lanesegments which is called �pipe�in the implementation in KTH-TPMA,and each lane segment can have vehicle running on. It is connected withother lane segment(s) so vehicle can change the lane segments when itis running. All the lanes contain the rout table information which pro-vides reachable destinations. It is also able to provide the speed limita-tion information to the vehicles. In the con�guration �le besides road


Figure 2.1: The Speed Control of TPMA


network de�nition, vehicle generators are de�ned for vehicles to sam-pling di¤erent destinations. KTH-TPMA applied car following and lanechanging model which are discussed before. It is possible to con�guresimulation parameters through simulation control panel, for instancegeneral simulation time etc.

Basic Objects in TPMA

2.2 Emission Models

Emission models are generally developed from emission measurementsin reality. Generally speaking, there are 4 types of input parameters:

� Vehicle technology speci�cations, i.e. basic vehicle information,for example vehicle type, length and fuel type (gasoline or diesel)etc.

� Vehicle status, e.g. vehicle age.

� Vehicle operating conditions, such as engine speed, physical speed,acceleration and others.

� External environment conditions, such as temperature and roadgeometric condition.

In principle, vehicle operating conditions are most relevant inputs tothe models, while external environment conditions can be introduced assecondary inputs. Several vehicle emission models are used worldwide


to estimate road tra¢ c emissions mainly with those inputs. Analyticalemissions modeling divides the whole emission process into di¤erentcomponents that correspond to physical phenomena associated withvehicle operation and emission production. Each component of theprocess is then modeled as an analytical representation consisting ofvarious parameters that can characterize the process. These parameterstypically vary according to vehicle type, engine, and emissions technol-ogy [18]. This section reviews the various models that were found inliterature and investigated before emission platform implementation.What we study and implement later mainly focus on microscopic simu-lation. In this �eld there are several general ways to establish a model.What the thesis expects to implement in Emission Prediction Platformis a real time simulation and prediction which means emission value inthe platform is preferred to be measured by current vehicle informationbut not refer to a long historical running state.The following categories of emission models were identi�ed from lit-

erature study:

2.2.1 Macroscopic Emission Models

In this category, emission measurement is based on a segment insteadof individual vehicles. It uses a top-down approach which aggregatestra¢ c activity data for an entire area combined with a single emissionfactor, for example g=km, to compute total area emission levels. Tra¢ cactivity data on annual Vehicle Kilometers Traveled (V KTs) are oftenderived from statistics [19].Let Eidenote the total emissions of a species i or the total fuel con-

sumption, for a given time period and area, Macroscopic emission mod-els calculate Ei as:

Ei =Xc

Xl

V KTl � fc �BERi(�sl; c) (2.1)

where:c is the vehicle species;l is the index of a sub-network (e.g. a lane segment or a collection

of lanes) characterized by an average speed �sl ;V KTl are the vehicle-kilometers traveled (or vehicle-miles traveled

VMTl ) in the given time period in sub-network l ;


fc is the fraction of vehicles of category c ;BERi(�sl; c) is the basic emission rate per kilometer (or mile) for a

species i. BERi(�sl; c) is derived based on driving tests at an averagespeed �sl , for each vehicle category c.An example of these models is average speed-based Mobile 6 model

developed by U.S. Environmental Protection Agency (EPA). It inte-grates toxic emissions data and algorithms from EPA�s Complex Modelfor Reformulated Gasoline. Moreover, the model can estimate emis-sions of other hazardous air pollutants (HAPs) based on user providedinformation [20].MOBILE 6 calculates average emissions on lane segments [21] for:

� HC , CO, and NOx ;

� evaporative emissions;

� gasoline, diesel, and natural gas-fueled cars, trucks, buses, andmotorcycles;

Since the speed could be di¤erent from the average one, BERs canbe corrected at di¤erent speeds with the use of speed correction factors(SCFs) which can also be used to take account of di¤erent conditionsin mobile 6.

2.2.2 Microscale Emission Models

In this category, emissions are estimated for single vehicles to ful�lhigher accuracy, although Macro emission models estimating emissionsfrom a �eet can be used for emission computation of larger network.In Micro Emission Models there are Emission Map Model, Load basedModel, statistical Model and etc.Emission MapIn the Emission Map model, it uses a two-dimensional lookup ta-

ble that provides instantaneous emission factors (grams per unit time).Rows represent speed intervals and columns represent acceleration in-tervals expressed as either "acceleration" or "acceleration�speed". Thedata on the table was obtained by several sample tests and experiments.The advantage of this model basically is simplicity. With such a tableas database, emission prediction program can just look up the table


and �nd corresponding emission rates. However they are not so �ex-ible. Some of the factors that can also change the emission value arenot involved such as road grade, vehicle historical state and so on.In this category, there is a model called MODEM which is a micro-

scopic emission database developed as a part of the European Com-mission�s DRIVE II research program. The data is derived from testson 150 vehicles in di¤erent European countries [22]. In this model, itgroups vehicle into di¤erent family according to speed and acceleration,and uses the corresponding emission rate in the database to estimatethe emission value.Load based ModelLoad-based model is based on physical and chemical phenomena

that formulate emissions. The primary variable of load based model isthe fuel consumption rate (FR). When a vehicle stops, the fuel rateis set to a small constant value. Otherwise, fuel rate mainly dependson engine speed, engine power, and air-to-fuel ratio. Engine power iscalculated as the sum of total tractive power requirements, but also cantake account of external environment such as air conditioning. Trac-tive power is given by the sum of an inertial driving term, a rollingresistance term, and an air drag resistance term. These terms dependon vehicle characteristics, vehicle speed and acceleration [21]. Throughfuel consumption, the engine-out emission value can be calculated withair-to-fuel ratio. From engine-out emission and the catalyst pass frac-tion, the emission which is actually emitted can be derived. Howeverthe computations a¤ord in load based model are often much highercomparing to other models.An example of load based models is Comprehensive Modal Emissions

Model (CMEM) which is a model developed at the University of Cali-fornia at Riverside and at the University of Michigan [23]. CMEM alsouses NCHRP database to calibrate parameters for 26 vehicle categories.As shown in �gure 2.2 , there are power demand, engine speed, air/fuelratio, fuel rate, engine-out emissions and catalyst pass fraction modulesin CMEM. It predict emission value according to fuel consumption ratein each second and its tailpipe emission rate.Statistical Models"Statistical models are usually linear or nonlinear regressions that

employ functions of instantaneous vehicle speed and acceleration, or


Figure 2.2: The structure of CMEM

modal variables, as explanatory variables. These models overcome thesparseness and discretization problems of the emission maps. However,they may lack a clear physical interpretation, and may also over�t thecalibration data when using a large number of explanatory variables.Therefore these models can give non-desirable results if applied to sit-uations not covered by the calibration data" [24].An example of statistical models is regression-based POLY model,

which is developed by researchers at the Polytechnic University of NewYork and the Texas Southern University [25]. Regression models weredeveloped to consider the acceleration/deceleration for each vehicle cat-egory . To fully capture the dynamics of acceleration or deceleration,not only the in the current period of time but also in the previous pe-riods are included in these models. It also takes account of historicalacceleration and deceleration duration time. The factor of gradient isconsidered in the models by using it to adjust the values of accelerationor deceleration. The results from the calibration of the models indicatedthat most of the coe¢ cients can be reasonably explained. The emis-sions model developed in this study were evaluated from microscopicand macroscopic perspectives.POLY model classi�es vehicles into di¤erent groups according to

vehicle size, made year, and emitter type. These groups contain most


of the vehicles on the current market. These groups are:

� LDGV: light-duty gasoline vehicles, i.e., passenger cars,

� LDGT1: light-duty gasoline trucks, under 6000 lbs. gross vehicleweight,

� LDGT2: light-duty gasoline trucks 6000 lbs. to 8500 lbs. grossvehicle weight.

Speci�cally, the type m emission for vehicle group at time t , i.e.,ei;j;k;m(t), was represented as [25]:

ei;j;k;m(t) = �0 + �v(v) + �v2(v2) + �v3(v

3) + �t0t0(t) + �t00t

00(t) +

�AtA(t) + : : :+ �At�9A(t� 9) + �ww(t) + �i;j;k;m (2.2)

where:�0 = constant;�x = coe¢ cient for variable x ;V (t) = speed (m.p.h.) at time t ;t0(t) = continuing acceleration time (second) up to time t since its

inception,t0(t) = continuing deceleration time (second) up to time t since its

inception,A(t) = combined acceleration or deceleration at current time t ,A(t� x) = combined acceleration or deceleration at time t� x,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.It considers road grade by calculating the acceleration at time t�x :

A(t� x) from acceleration and grade degree as follows:A(t� x) = a(t� t) + 9:81 � (g(t� t)=

p1 + g(t� t))

where x means the period before current timeg(t) = grade(in %)9.81 is the gravitational constant.POLY model also uses NCHRP vehicle emission database, and it is

compared with Comprehensive Modal Emission Model (CMEM) whichis developed in the late 1990�s with sponsorship from the NCHRP and


the U.S. Environmental Protection Agency (EPA) to ful�ll the needfor microscopic emissions modeling. The result is more accurate whentests are performed in downhill and uphill.Mixed modelsStatistical Models and Load based Model can be mixed to reduce

computation and increase the accuracy. An example of mixed models isthe EMIT model developed by Alessandra Cappiello in MassachusettsInstitute of Technology. It is an instantaneous model based on fuelconsumption of light-duty composite vehicles. It combines load-basedmodel and statistical model which will be described in next section, sothat the computation of this model becomes less.The idea of EMIT is to calculate each species of emission according

to fuel rate and the percentage of each species of emission in consumedfuel. The fuel consumption rate depends on engine friction factor, en-gine speed, engine displacement and engine power out. The parametersabove can be known from vehicle status except engine power output,which is possible to be derived from total tractive power requirementand vehicle drivertrain e¢ ciency.Mathematically, the emission output (EO) for emission i can be

calculated from [21] :

EOi =

8<:EOstoichi � =i +�iv + �iv

3 + � iav if 0 < Ptract <= P enrichtract

�+ �EOstoichi if Ptract > P enrichtract

�0i if Ptract = 0

9=;(2.3)

wherea is the current acceleration of vehiclev is the current speed of vehicle�; �; �; �; �; � are coe¢ cients according to each emission species iBased on emission output, the tailpipe emission rate (TPi) can be

get from:

TPi = EOi � CPFi (2.4)

where CPFi is the catalyst pass fraction


CPFi =

8<:m0i � EOi + q0i if 0 <= EOi < z0i

m00i � EOi + q0i if z0i <= EOi < z

00i

m000i � EOi + q00i if EOi > z00i

9=; (2.5)

where m0i, m

00i , q

0i, q

00i , z

0i, and z

00i are calibrated parameters of the

catalyst pass fraction function.The data used for EMIT model is from National Cooperative High-

way Research Program (NCHRP) vehicle emission database. NCHRPvehicle emissions database was developed by UC Riverside. The data-base includes chassis dynamometer measurements of second-by-secondspeed, and engine-out and tailpipe emission rates of CO2 , CO, HC andNOx on three driving cycles. The parameters are calibrated by normalemitting cars, normal emitting trucks and high emitting vehicles.Neural network modelNeural network model is another approach to develop Microscale

emission models that can learn and capture the correlation betweenemissions and acceleration/deceleration aspect. With this model, pre-dictive emissions can be derived from input data through training. Itis considered a viable way to predict accurate result.

2.2.3 Discussion and Conclusions

The sections above have examined many emission models in di¤erentcategories. Most of these models have been deployed for practical appli-cations. There are various factors that in�uence emissions for vehiclesin tra¢ c �ow, but what we discussed in the thesis mainly focus onspeed and acceleration. Emission modeling requires simple and generalapproach that can take account of vehicle behavior. In this study, wedon�t consider those models requiring inputs more than we can obtain.Emission Map Model might not be accurate enough because usuallythe emission of vehicle is not only relied on the vehicle state at currentsecond but also some previous seconds. To overcome sparseness anddiscretization problems some of the models often take previous secondsstatus to predict the current emission value, so the 2-dimensional tableis not accurate enough to get the emission value. Neural network modelis also not considered for its high computational cost since running atra¢ c simulation model would be substantial when the neural networkemission models are integrated with tra¢ c simulation model. For load


based model, since it is developed and calibrated for hot-stabilized con-ditions, and it does not represent history e¤ect, the computational e¤ortis also high [21], so we did not choose it for implementation.At last we choose POLY and mobile 6 as the models to be imple-

mented in emission platform, due to the variables are available fromKTH-TPMA, and they are validated with reasonable results. Howeverthey have their own limitations also. For POLY model, it is complex todesign and calibrate to adapt to another road network, since those pa-rameters are calibrated and o¤ered to the model based on a measuredarea, which means the model is place speci�c. For the mobile 6 model,although its computational e¤ort is relatively low, it is in fact a macroscale model.

Chapter 3

System Design and Implementation

In this chapter, we present the methodology and detailed approachesto develop a general emission prediction and analysis platform. Todevelop this system, we applied distributed computing approach andModel�view�controller (MVC) architecture.

3.1 Distributed Computing Approach

�By local computing (local object invocation, etc.), we mean programsthat are con�ned to a single address space. In contrast, we will use theterm distributed computing (remote object invocation, etc.) to referto programs that make calls to other address spaces, possibly on an-other machine. In the case of distributed computing, nothing is knownabout the recipient of the call (other than that it supports a particularinterface). For example, the client of such a distributed object doesnot know the hardware architecture on which the recipient of the callis running, or the language in which the recipient was implemented.�[26].The project uses this approach to separate tra¢ c simulation and

emission simulation into work of di¤erent computers. One computer isrunning emission simulation and listens for tra¢ c simulation�s connec-tion and communication. Other computers can run one or more tra¢ csimulation application to interact with emission simulation application.There are some characters for distributed computing approach to be

suitable:

� Better Performance

22

3. System Design and Implementation 23

Figure 3.1: Comparison between ASMX and WCF

Distributed system is suitable for those applications or systems whichrequire high performance computing since the system distributes worksto di¤erent machines and collect their results. Figure 3.1 shows thesending e¢ ciency with 1 object, 10 and 100 objects. This experimentis performed with Windows Communication Foundation (WCF) andASP.NET Web Services (ASMX). Both of them use existing .NET dis-tributed communication technologies [27]. From the �gure it shows,the computation time reduces while objects increase since it distrib-utes di¤erent works on di¤erent computers.

� Independency

With the structure, system can bene�t from independency. Since itis independent between machines, failure of one machine will not a¤ectothers. An example of this is the Middleware which is a layer usedin networking to hide the heterogeneity of the collection of underlyingplatforms. With middleware, it can o¤er a higher level of abstraction ofimplementation. Client and server can be implemented as if they werein a same environment. Middleware can handle the communication orconnection between computers, but the individual work is supposed tobe done by itself [28]. There is a naming service in most middleware. Itenables server looked up in a directory list. A naming service maintainsa set of bindings, which relates the name of each object registered in a


standard way. When some clients request a service name, then it canrequest naming service to �nd the resource. Service or function is also akind of resources that can be provided by emission prediction platform,thus, when middleware is involved, publishing service becomes easier.Tra¢ c simulation is one of the most computational resource consum-

ing simulations, so is emission simulation. To get a better performanceis the most important reason why distributed computing approach isadopted in the system. On the other hand, if distributed computingis not available, for instance lack of computers or network limitation,local computing shall also work in the system. The distributed com-puting will only be applied when multi computers are involved in thesystem. Independency is also required when a KTH-TPMA connectedwith Emission Prediction Platform, if KTH-TPMA or platform crashes,the other part is supposed to disconnect from it and not get in�uenced.Because of this, when multi KTH-TPMA connect to the platform, oneof them crashing will not arouse others�instability. On the other hand,when the Emission Platform has some problems, KTH-TPMA can stillrun as a tra¢ c simulator. In addition, none of the machines containsall the data. In the thesis KTH-TPMA will not send all of its informa-tion to emission prediction platform, and Emission Prediction Platformdoes not send back the emission value, but just hold it, therefore thedata is separated, which also increases the independency. There areseveral well developed middleware such as MPI, PVM and CORBA.In the thesis CORBA is used as a middleware for its rich set of

communication mechanisms and language independency. In CORBAthe interface is de�ned with an Interface De�nition (IDL) �le whichis language independent while for the other two approaches it is di¢ -cult to specify the component interface. Comparing to MPI and PVM,CORBA addressing is based on objects and their addressing are onprocesses. In the thesis, the data transferred is preferred to use vehi-cle object because both Emission Prediction Platform and TPMA areobject oriented implemented. With CORBA, KTH-TPMA and Emis-sion Prediction Platform just concern its tra¢ c and emission simulationimplementation on their own sides. Data communication and remoteobject request are handled mostly by CORBA. TPMA and EmissionPlatform implement their communication as local invocation. In thesystem, accessing transparency hides the di¤erences in data represen-


tation for example the vehicle objects and lane segments. EmissionPlatform is implemented with Java, which means it can run on di¤er-ent operating systems, while tra¢ c simulation platform KTH-TPMAis built with Delphi on Windows. The data representations are dif-ferent in these two applications. That�s another reason to implementdistributed system architecture in the thesis.

3.2 Distributed System Architecture

There are several distributed system architectures exist. The thesismainly uses Common Object Request Broker Architecture (CORBA)as the architecture development. It uses web service as an alternative.In the following sections, the report illustrates the two implementationsof architectures and makes a comparison between them.

3.2.1 CORBA

Common Object Request Broker Architecture is simply referred to asCORBA. There are some speci�cations of CORBA established by Ob-ject Management Group (OMG). CORBA uses remote-object model.In the model, there are some objects inside server can be used by clientthrough naming service.CORBA uses Interface De�nition Language (IDL) to specify objects

and services. Interface speci�cation needs to be given by IDL. Withthis interface, applications in di¤erent languages can communicate byremote objects. The programming languages include C, C++, Java,Delphi, and Ada. All the objects and services and facilities are con-nected to Object Request Broker (ORB) which is responsible to enablethe communication between clients while hiding the detailed imple-mentation. The general structure of CORBA in our implementation isshown in �gure 3.2. KTH-TPMA implements the invocation interfacewhich is generated to IDL �le to request or invoke the object(s) or func-tion(s) on Emission Platform. Data from KTH-TPMA goes throughits Object Request Broker (ORB) which acts as the middleware inCORBA. Data is transferred between operating systems and the net-work which connects them. On the Emission Prediction Platform side,it implements skeleton interface which enables it to publish service ob-


Figure 3.2: The general organization of CORBA

jects. The platform receives data through Emission ORB through itsown OS.The implementation of CORBA communication between TPMA and

emission platform is shown in �gure 3.3. The �rst step of building aCORBA based distributed system is to set down the interface which isthe standard of invocation requests. CORBA uses an interface reposi-tory to save all the interface de�nitions. When server needs to publisha service, it is supposed to register the interface in the interface repos-itory. After that, client can retrieve published interface de�nitions.Besides the interface repository, there is an implementation repositorycontaining all the objects to be implemented. CORBA o¤ers a nam-ing service which holds a table mapping object�s name and identi�er.What a server needs to do is to hold an object which consists of an iden-tity, interface and servant which is the implementation of object. Theservant�s operations are supposed to support CORBA IDL interface.Client can invoke an operation on an object implementation throughORB.There are several available implementations to support CORBA.

The tool used in thesis is Visibroker, and MTDORB is also tested atthe �rst beginning. However after some initial test, MTDORB is notconsidered for lack of documentation.


Figure 3.3: CORBA connection initialization of Emission platform and TPMA-HUTSIM

VisibrokerVisibroker is a robust CORBA environment for distributed process-

ing. It is one of the most popular CORBA ORB on the market forit robustness and support for Java, C++ and Delphi [29]. There aresome features of Visibroker suitable for the thesis. It enables threads,connection management, and naming service. Thread enables serverscan handle multi-clients more convenient by create a new thread foreach connected client. Connection management can easily con�gurethe connected clients and their states.MTDORBMTDORB is an open source ORB. It fully supports CORBA 2.6,

and it is freely available under the terms of the GNU General PublicLicense. However there is not enough document to support it.


3.2.2 SOA and Web Service

Before we introduce web service, there is one more concept we needto explain: SOA. Service-oriented architecture (SOA) is a componentmodel [30]. In this architecture, di¤erent units (or services) are or-ganized through an interface between these services in an application.Interface is de�ned independently on hardware, operating system orprogramming language. This lets the services in the architecture com-municate in a uniform way. SOA is a replacement of traditional object-oriented model (OOM) framework which CORBA belongs to. Thedi¤erence between OOM and SOA is that OOM uses high couplingwhile SOA uses low. The advantage of low coupling is agility and itsindependency when the entire application�s services change. On theother hand, high coupling means interface and their functionality arehighly connected, therefore, when the whole application or part of theapplication needs to be modi�ed, they are fragile. There is one morefeature makes us to consider SOA. Based on eXtensible Markup Lan-guage (XML), Web Services De�nition Language (WSDL) is used todescribe interface.Web service is one of the best ways to implement SOA for its inde-

pendent function entity, huge data access and literal-based messaging.Through the index search in Universal Description Discovery and Inte-gration (UDDI), we are able to dynamically alter a service�s providerwithout a¤ecting client�s con�guration. In addition, all the accessingis through SOAP, so as long as WSDL interface is well encapsulated,external client can not access server�s data directly. By using WSDLand Literal-based SOAP request, we can realize an interface which canreceive a huge number of data in one time. However there is one bot-tleneck here since web service can only handle huge mount of data in avery LOW frequency, which is not quite suitable for our implementationin Emission Prediction Platform since the platform needs to receive andhandle relatively small size data in a frequent way. From the reasonsabove, most of features required in emission prediction platform canbe provided by Web service with SOA implemented. Although the fre-quency of communication is limited, web service is still implemented tocompare the performance with object-oriented model CORBA and alsoas an alternative for future web based emission system implementation.The structure of web service is shown in �gure 3.4. Emission Pre-


Figure 3.4: The web service general architecture

diction Platform holds 3 interfaces that can be invoked by client: con-nection, information updates, and disconnection. The platform hidestheir implementation behind these 3 interfaces. Once Emission Pre-diction platform de�nes its services interface, it generates a WSDL �lewhich uses an XML format �le to describe the services as a set of end-points operating on messages containing either document-oriented orprocedure-oriented information [31]. This WSDL �le is published onnetwork to get services registered. When a client wishes to use theseservices, it needs to know the WSDL �le. In our thesis, Tomcat andAxis2 are used for web server and engine to publish the services. Onthe TPMA side, it imports the WSDL �le to build a "pas" �le whichDelphi can use in the project. Then TPMA and Emission predictionplatform can communicate directly through interface.There are some limitations of using Web Service based on SOA:

reliability, it is not guaranteed to transfer massage once-and-only-once;security, client validation is not fully supported; performance, it is themain reason that makes Web Service just used as a test environmentbut not a formal one at the moment [32].

3.3 E¢ cient Communication

Emission simulator is an online application, whose throughput is aboutone data package per second. In our thesis, the throughput requirement


Figure 3.5: Collective and Individual Sending Comparison

is even higher because the emission simulator is supposed to supportmultiple clients and tra¢ c visualization. It is about 5 packages in onesecond. Normally, in such data packages, there are a number of vehicledata which contains vehicle speed, acceleration, position, type, simu-lation time and etc. These data is mostly in "double" type. Each ofdouble type data is 8 bytes. Therefore the data throughput is quitehigh. To improve the communication, su¢ cient data exchanging mech-anism has to be applied.

3.3.1 Data Exchanging Mechanism

In the TPMA simulation, there is a list of vehicle data to be sent everycertain period (normally can be set from 0.1 second to 1 second) whichis called "round". There is a sequence of vehicles generated sequen-tially. TPMA can send each individual vehicle data immediately whenit is generated or store it in one sequence and send the sequence af-ter all of the vehicle data are collected. Individual vehicle informationexchanging does not need to allocate extra memory space to save vehi-cle information but consumes more network resources since it requestsremote object operations more often. In Figure 3.5, it compares thesending time of collection and individual sending in a 2 minutes tra¢ csimulation. Vehicle data exchanging by collection is better than indi-vidual in performance, although the memory cost is relatively higher.


3.3.2 Synchronous and Asynchronous Information Exchange

There are two methods to exchange data: synchronous and asynchro-nous. Synchronous data exchanging means tra¢ c simulator sends datato platform and wait for a reply from Emission Prediction Platform thenstarts sending next package whereas, in an asynchronous approach,KTH-TPMA sends data along without checking if it arrives or not.There are always pros and cons in these two approaches. Synchronousexchanging ensures data arrivals, but it costs communication time. Onthe other hand, asynchronous exchanging maximizes the sending e¢ -ciency but loses the data control.In asynchronous data exchanging, as a server, it needs to handle

the data lost and late arrived cases. In our project, vehicle data canbe sent in two ways: collective and individual modes. In collectionexchanging mode each collection of data has a time stamp which logsthe simulation time in KTH-TPMA, so the platform simply discards thedelayed package or packages. When server receives a data packages, andit compares to the last one, if the time stamp of current one is earlierthan time stamp of last one, throw the current package, otherwise,updates emission with the current package.In the individual exchanging mode, the processes become more com-

plicated. An exchanging package data example is shown in picture 3.6.For each vehicle simulation update, there are several individual vehicledata packages need to be sent to server separately. It is possible that inone sending round there is one or more package(s) missing or late, lead-ing to the previous received packages to be discarded or kept waiting.For example, in each simulation step, there are 5 vehicle data packagesto be sent. The server receives the �rst 4 of 5 packages, and waits forthe last one, then the second round packages arrive, then server allo-cates a new memory to save the second round package. When server�nished receiving second round packages but the �rst round package isstill not �nished because the 5th package has not arrived. There are 2options to handle this problem: waiting for the 5th package of roundone or discarding received packages in round one. The former optiongives the data completeness but loses the performance. In this case,if the package is not late but lost because of some network issues, theprevious received data will stay in server�s memory but never used topredict the emission value since it is not complete. The latter option


Figure 3.6: Asynchronous sending data

simply throws those not completely received data when a newer roundsending �nishes. This option may throw too many data packages justbecause some network delays. In the implementation, the later optionwas more recommended to emphasize the performance.In CORBA there is an oneway identi�er to specify a function use

asynchronous mode to send data. The table 3.1 and �gure 3.7 show thesending time on a same demand in di¤erent modes. The total tra¢ csimulation time is 2 minutes, and there are 15 vehicle generators onthe road network. From the test, synchronous sending time is about 8-10 times slower than asynchronous mode. In the synchronous mode, ittakes TPMA about 1/4 to 1/2 of total time on sending data and waitingfor response from emission platform, so the performance on TPMA sideitself is also a¤ected while in asynchronous mode, only1/20-1/12 timeis spent on sending, which is acceptable in performance.


Asynchronousreal time fastSingle Collection Thread Single Collection Thread

Time 6.186 3.357 6.482 9.884 2.395 5.174Synchronousreal time fastSingle Collection Thread Single Collection Thread

Time 51.247 35.298 54.552 70.018 36.815 68,335

Table 3.1: CORBA Sending Time

Figure 3.7: Sending time on di¤erent modes with syn/asyn


3.3.3 Multithreading

A controller is the main object which controls connection and data ex-changing. Each KTH-TPMA client has one client id which speci�esits identity. When multiple KTH-TPMA clients start exchanging dataafter they are connected, controller may have to create a thread tolisten to each client for receiving vehicle data instead of receiving oncontroller object. Since when data communication is too frequent, thecontroller may not handle all the data. Another reason to use mul-tithreading is that the received data needs to be grouped accordingto corresponding client id. The cost of grouping these data may alsoslower the data communication. Figure 3.3.3 shows how client andmultiple clients work in the system. For each KTH-TPMA, it connectsto controller �rst, and then controller creates a new object which iscalled connection object. Controller returns the newly created connec-tion object reference to KTH-TPMA and waits for another connection.The connection object starts to handle the data exchanging from theKTH-TPMA which holds its object reference. So the data communi-cation is only between KTH-TPMA and the corresponding connectionobject. When a KTH-TPMA client wants to disconnect from the plat-form, it communicates controller again, and controller terminates thecorresponding connection and deletes the client id from its repositoryand release memory.


Multi client connection and data �ow

3.4 Interface

The interface which is de�ned with IDL is to communicate betweenTPMA and Emission Prediction Platform. In the IDL �le there is aVehicleInformation struct which includes the basic vehicle informationfrom TPMA.

module EmissionIDL{

//Structure of Shared Vehiclestruct VehicleInformation{

long 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 - call by the Server.interface ClientInterface{

boolean startStop(in boolean �ag);boolean disconnect();

};// Interface - call by the Client.interface ServerInterface{

ServerInterface connection(in ClientInterface clien-tRef, in string roadNetwork, in string IP, in string hostname);

boolean updateList(in VehicleArray vehicles);boolean updateSingle(in VehicleInformation ve-

hicle);boolean disconnect();

};};

The information contains vehicle id, speed, acceleration, type, length,width, position, and lane id which the vehicle is running on. 3.8 showsthe interface and its function in the thesis. The connect function isused for KTH-TPMA to connect to emission server, and the returnvalue is the Connection reference which the client uses for updatingvehicle data. updateSingle and updateList are 2 main methods to sendvehicle date, the only di¤erence is the former one exchanges vehicle oneby one, while the latter one exchanges the collection of vehicle in onetime. The report shows the performance of these 2 ways of exchanginginformation and their pros and cons in chapter 4. disconnect methodsimply stops communication and disconnects from each other .


Figure 3.8: Interface used between TPMA-HUTSIM and Emission Platform.

Figure 3.9: Data collecting and sending in TPMA

3.5 Tra¢ c Simulation Architecture

After the Interface has been de�ned, these two models can send andretrieve data between each other. Tra¢ c simulator mainly as a dataprovider in the distributed system, it has basically two parts: tra¢ csimulation and data collection. Tra¢ c simulation part is discussed inchapter 2. Here it will only explain the data collection mechanism inKTH-TPMA. There are mainly two approaches to collect vehicle data.The data collection mechanism is shown in �gure 3.9. One of theminserts vehicle data into an array in the ring that KTH-TPMA updatesvehicle information. After �nished all of these vehicles in the ring, itrequests remote objects on Emission Prediction Platform to measure


Figure 3.10: MVC pattern of Emission Platform

the emission value. The other approach is called threading. It creates anew thread to collect vehicle data meanwhile KTH-TPMA simulationmanager keeps running on its own thread. Thread collection does notneed the main thread for KTH-TPMA to consider the data collectionissue, and it improves modularization as well.

3.6 Emission Simulation Architecture

In Emission Prediction Platform, basically there are 2 models: logicmodel and GUI model. Emission prediction, CORBA server and objectstructure are included in the logic model, while GUI model only pro-duces a user interface for managing the platform and visualizing resultof emission prediction. As shown in �gure 3.10, the structure appliesMVC pattern, GUI parts is viewer and logic model contains controllerand object structure is model. Client, Pipe (which means lane segment)and Emission objects are model which is controlled by connection andcontroller. ClientFrame, EmissionPanel and RNWFrame visualize theresult which is produced by Connection and Controller.


3.6.1 Data structure layer

In the basic data structure, there is one basic abstract class BasicOb-ject, which is the parent class of all the objects that can be drawn onthe panel and have emission to be measured. These objects includeVehicle, Pipe, and Segment. BasicObject de�nes some basic propertiesand functions of these objects, such as position, measureEmission() andpaint().Vehicle is the basic unit that running on the road network and it is

also the data which Java platform retrieves from KTH-TPMA. Thesevehicles are supposed to be shown up on Emission Platform to give useran intuitive view of dynamic road network and it also could be turned o¤when performance is a concern. All the emission values are calculatedby these vehicles data. As we discussed in chapter 2, vehicle�s emissionvalue can be related to its historical acceleration value and speed, sowith these value we can predict the emission value of the vehicle.The class diagram of objects is shown in �gure 3.11. Each of the

vehicles belongs to one lane at one time, and the emission of the lane atcertain time interval is the sum of the emission values of vehicles whichare running on the lane. Some lanes which are in a measurement groupbuild up a segment. Several segments compose a road network. Eachof the objects mentioned above are derived from BasicObject. WhenmeasureEmission method is invoked in an object, this object is able tomeasure the emission values of all the objects inside it. Another basicobject is Emission which preserves 4 kinds of emission values and ameasurement method to be invoked. These 4 emission values includeHC/VOC, CO, NOx and CO2. CO2 is mostly omitted because thevalue of it is much larger than other 3.

3.6.2 Logic layer

Controller and Connection both implement IDL interface. Controlleris the entrance point of the application. The data �ow diagram ofthis layer is shown in �gure 3.13 and the class diagram of this part isshown in �gure 3.12. Controller sets up Object Request Broker Dae-mon (ORBD) which enables client to �nd and use the remote objecton servers in CORBA. It also listens to a client connect. When KTH-TPMA gets connected, it creates a connection object for the connected


Figure 3.11: The architecture of objects in emission prediction platform modeling


Figure 3.12: UML Diagram of Emission Platform

client and returns a connection object reference by the callback method.Client holds this client reference to update vehicle data with the con-nection object. Update vehicle information and disconnect are handledby those connection objects.

3.6.3 GUI layer

There are mainly 2 frames for platform management and emission pre-diction in the GUI layer. Figure 3.14 and 3.15 show the running road


Figure 3.13: The data �ow among client Controller and Connection

network and emission result of a road segment. In this layer, Client-Frame shows how many clients are connected to the platform, and addsone button for each client on RNWFrame to visualize the real time roadnetwork state and its emission value.

3.7 Web Service Implementation

As an alternative and a distributed computing framework against CORBA,web service is also implemented. As general web service implementa-tion described in chapter two, the di¤erence between web service andCORBA is mainly on what kind of �eld services are based on. CORBAprovides object oriented service while web service provides service ori-ented one. This di¤erence makes Emission Prediction Platform cannot o¤er KTH-TPMA a reference to an object which can handle majordata exchanging work.

3.7.1 WSDL

In the WSDL �le which acts as an interface in web service,

connection(roadNetwork, IP, hostname)


Figure 3.14: runing road network

Figure 3.15: emission time series chart


Figure 3.16: Web service data �ow

updateVehicleInformation(clientID,vehicleID,speed,acceleration,

length,pipeID, objPosition,vehicleNo,simTime)

disconnect(clientID)

Similar to those in IDL �le, connection function is the initial ser-vice which connects KTH-TPMA and Emission Prediction Platform.Function updateVehicleInformation enables KTH-TPMA transfer ve-hicle data to the platform. Disconnect function quits TPMA fromplatform.

3.7.2 Communication Implementation

The communication implementation in web service is shown in �gure3.16. A KTH-TPMA can connect to Emission Prediction Platform byrequesting service in ServiceProvider who provides services on network.Once ServiceProvider established connection to KTH-TPMA, it com-municates with Controller and sends back a client id. Controller createsa new Connection instance. So when KTH-TPMA starts simulationand data exchanging, it needs to specify the client id, ServiceProvidersends vehicle information to corresponding Connection through Con-troller.

Chapter 4

Evaluation

There are two models implemented inside the emission platform. Thesetwo models are tested under a same environment for 4 times each. Thetest is performed on 2 computers, one runs for Java emission platformand the other one runs KTH-TPMA microscopic tra¢ c simulation.

4.1 Environment

Emission Server: Intel(R) Pentium M 1.73GHz, 1.24GB of RAM, Win-dows XP Professional SP2.TPMA Client: VirtualBox on PCLinux 7, with Intel(R) Pentium D

2.80GHz, 1.00GB of RAM, Windows XP Professional SP2.The tra¢ c simulation runs 2 minutes in real mode, which means also

2 minutes in reality for a large intersection road network which contains15 vehicle generators. These generators yield 298, 307, 237, 583, 558,375, 430, 430, 430, 240, 240, 140, 180, 213, 193 average vehicle �ows.Each test is performed 4 times with 2 in individual sending and 2 incollection sending. In these tests, the average speed of vehicle is 34.80km/h and the average acceleration is 0:145m=s2.

4.2 POLY Test

Table 4.1 shows the parameter of POLY model in the test. Theseparameters are calibrated from the car in 1976-1980 in U.S by Tengwho brings POLY forward [25].

45

4. Evaluation 46

LDGV Model Year (1976-1980)CO HC NOx

�0 0.121688 0.009766 0.0041V (t) 0.00408 0.000853 -6.00E-05V 2(t) 0 -2.8E-05 0V 3(t) -8.4E-06 2.48E-07 2.00E-07T 0 -0.00614 -0.00021 0.0002T 00 -0.00118 -0.00053 0.0005A(t) 0 0 -0.0005

A(t� 1) 0 0 0A(t� 2) 0 0.00104 0.0004A(t� 3) 0 0 0A(t� 4) -0.01994 0 0.0015A(t� 5) 0 -0.00248 0.0017A(t� 6) 0.009976 0 0.0014A(t� 7) 0 0 0.0007A(t� 8) 0 0 0A(t� 9) 0.016362 0.001912 -6.00E-04W (t) 0.00264 0.000216 0.0004R 0.174617 0.155871 0.670418

Table 4.1: POLY�s Coe¤

4. Evaluation 47

Model CO(g/s) NOx(g/s) VOC(g/s)POLY-1 0.115 0.0106 0.0179POLY-2 0.113 0.0108 0.0179POLY-3 0.113 0.0120 0.0182POLY-4 0.114 0.0109 0.0180

Table 4.2: Emission Model Test

The table 4.2 shows the POLY Emission value predicted in the test.

4.3 Mobile 6 Test

In mobile 6 there are 28 types of vehicles, each of them has a fractionand a set of average emission parameters [33]. However in KTH-TPMAthere are only 4 vehicle categories: car, truck, bus and lorry. Mappingthese 5 types of vehicle to 28 is not advisable, since truck and lorry arein a same category in mobile 6 while truck and car have more than 20subtypes. In the implementation randomize a vehicle type according tothe reality percentage. For fraction parameters, there is one default listof these parameters on EPAwebsite. For basic emission factor, there are12 types of data available: rural interstate, rural principle arterial, ruralminor arterial, rural major collection, rural minor collector, rural local,urban interstate, urban freeway, urban principle arterial, urban minorarterial, urban collector and urban local. Urban local with averagespeed 38 m.p.h. is chosen to be applied.

Model CO(g/s) NOx(g/s) VOC(g/s)mobile 6-1 0.020 0.0013 0.0021mobile 6-2 0.0188 0.0013 0.0020mobile 6-3 0.0193 0.0013 0.0021mobile 6-4 0.0182 0.0012 0.0020

Table 4.4: Mobile6 Emission Model Test

The table 4.4 shows the mobile 6 Emission value predicted in thetests.

4. Evaluation 48

LDGV Per(%) Fraction DescriptionLDGT1 40.21 0.504287 Light-Duty Gasoline VehiclesLDGT1 0.48 0.76726 Light-Duty Gasoline Trucks 1LDGT2 24.43 0.25529 Light-Duty Gasoline Trucks 2LDGT3 6.40 0.077912 Light-Duty Gasoline Trucks 3LDGT4 1.85 0.0358 Light-Duty Gasoline Trucks 4HDGV2B 1.92 0.008055 Class 2b Heavy-Duty Gasoline VehiclesHDGV3 0.52 0.000261 Class 3 Heavy-Duty Gasoline VehiclesHDGV4 0.34 0.000197 Class 4 Heavy-Duty Gasoline VehiclesHDGV5 0.14 0.000348 Class 5 Heavy-Duty Gasoline VehiclesHDGV6 0.81 0.000773 Class 6 Heavy-Duty Gasoline VehiclesHDGV7 1.29 0.000373 Class 7 Heavy-Duty Gasoline VehiclesHDGV8A 0.91 0.000002 Class 8a Heavy-Duty Gasoline VehiclesHDGV8B 1.52 0 Class 8b Heavy-Duty Gasoline VehiclesLDDV 0.49 0.002413 Light-Duty Diesel VehiclesLDDT12 7.71 0.001184 Light-Duty Diesel Trucks 1 and 2HDDV2B 5.32 0.003045 Class 2b Heavy-Duty Diesel VehiclesHDDV3 0.22 0.000839 Class 3 Heavy-Duty Diesel VehiclesHDDV4 0.19 0.000703 Class 4 Heavy-Duty Diesel VehiclesHDDV5 0.29 0.000252 Class 5 Heavy-Duty Diesel VehiclesHDDV6 0.64 0.001627 Class 6 Heavy-Duty Diesel VehiclesHDDV7 0.36 0.002527 Class 7 Heavy-Duty Diesel VehiclesHDDV8A 0.0016 0.003198 Class 8a Heavy-Duty Diesel VehiclesHDDV8B 0.43 0.0113 Class 8b Heavy-Duty Diesel VehiclesMC 0.5 0.0072 Motorcycles (Gasoline)HDGB 0.21 0.000832 Gasoline BusesHDDBT 0.09 0.0013 Diesel Transit and Urban BusesHDDBS 0.31 0.001968 Diesel School BusesLDDT34 2.84 0.001588 Light-Duty Diesel Trucks 3 and 4

Table 4.3: Mobile6 Parameters

4. Evaluation 49

4.4 Data Evaluation

From simulation experiments, these two models produce di¤erent emis-sion values. In general the emission value POLY predicts is 5 timeslarger than what mobile 6 produced. To explain this, it is necessary tocompare the data from European Emission Standard which de�nes thelimitation of vehicle emission in European Union.Because they use di¤erent units g/km and g/s, according to average

speed, transform the result tested to table 4.6 with the equation below.

Es = E � 60 � 60=v (4.1)

whereEs is the standard emission g/kmE is the emission value in g/secv is vehicle speedfrom table 4.5 and 4.6, the emission value produced by mobile 6

model is under the Euro Emission Standard while what POLY producesare about 5 times larger. It proves that the emission value generated bymobile 6 model is within the European Emission Standard limitation,but what POLY produces is much larger. The diagrams 4.1 showsthe comparison of POLY, mobile 6 and European Emission StandardIII. According to [25], �gure 4.2 and 4.3 shows the measured datato calibrate parameters for POLY model and the emission rate of COmeasured by POLY and CMEM model in downhill and uphill. Fromthese �gures, it is seen that the CO value measured is quite near towhat we tested. The reason why the emission value which POLY modelpredicts is higher than Mobile and other standard is probably becausethe emission data measured is based on the vehicle produced in 1975-1980 when the �rst generation catalytic converters are built. The useof converters provides a huge indirect bene�t because lead inactivatesthe catalyst, unleaded gasoline is also introduced in 1975, while mobile6 is published in 2003 and the European Emission Standard III is for2000 passenger cars. On the other hand, because we do not have "real"tested data which is normally measured on board, therefore, we cannot calibrate a new set of parameters for POLY model. However as anenvironment to measure the emission value, it is possible to change theparameter for each model by changing con�guration �le when we get

4. Evaluation 50

Tier CO(g/km) NOx(g/km) HC(g/km)Diesel

Euro I 2.72 (3.16) - -Euro II 1.0 - -Euro III 0.64 - 0.5

GasolineEuro I 2.72 (3.16) - -Euro II 2.2 - -Euro III 2.2 0.2 0.15

Table 4.5: European Emission Standard

some parameters newly calibrated.

Model CO(g/km) NOx(g/km) VOC(g/km)POLY-1 11.90 1.10 1.85POLY-2 11.65 1.11 1.85POLY-3 11.14 1.08 1.83POLY-4 11.45 1.09 1.84mobile 6-1 2.07 0.14 0.22mobile 6-2 1.94 0.13 0.21mobile 6-3 2.00 0.13 0.21mobile 6-4 1.89 0.13 0.20

Table 4.6: Transformed Emission Model Test

4. Evaluation 51

Figure 4.1: Emission Comparison

Figure 4.2: POLY downhill data

Figure 4.3: POLY uphill data

Chapter 5

Conclusion and Discussion

In this chapter we summarize the thesis and discuss the limitation andfuture research which can be explored based on the thesis.In the �rst part of the thesis report, an overview of tra¢ c and emis-

sion simulation are introduced, and then some emission models are pre-sented and their pros and cons are discussed in general. Then it startsthe system development part which introduces CORBA and web ser-vice and discusses synchronous/asynchronous and collection/individualdata exchanging mechanism and shows the structure of how CORBAand web service are used in the system implementation. Then it con-tinues explaining the emission platform implementation and how thesemodules are organized. At last,emission estimation on road networksusing di¤erent models are tested and compared with Euro III standards.

5.1 Limitation

Since communication cost in synchronous data exchanging mode be-yond what we can accept, asynchronous sending mode is recommendedfor the study. In the communication part, normally KTH-TPMA sendsone data pack in each 0.2 second. With such data, emission platformsimulates a running network and estimate emission value in every onesecond, so some data lost may cause a few emission estimate can notbe �nished on time, therefore the time series graph is not correctly up-dated. For example, in these two models, emission are calculated every1 second, when the it reaches calculation time but the vehicle data hasnot arrived, emission estimation on this second has to be omitted.

52

5. Conclusion and Discussion 53

5.2 Future Research

Although many emission modes have been reviewed in our study, onlyPOLY and Mobile 6 are implemented for the model evaluation. Fromthe last chapter, the result shows the predicted emissions are di¤erent,and it is because of parameter issues. To get a reliable result, recalibratethese parameters based on real on board measured data is necessary.For Java Emission Platform, it is also possible to predict emission

value from another client, for example Mesoscopic tra¢ c simulationclient, as long as developers de�ne an interface which road network andvehicle data can be exchanged. The developed tool has a potential tobe envolved as a solid tool for real tra¢ c planning and managementapplications and moreover, calculate emission based on real time tra¢ cinformation obtained from reality in the future.

Bibliography

[1] LexMPO: Congestion management study, 2006. URLhttp://www.lexareampo.org/congestion/Congestion.htm.

[2] Verket NV: Swedish greenhouse gas emissions, 2007. URLhttp://www.naturvardsverket.se/en/In-English/.

[3] Nauss K: Diesel emissions health andenvironmental e¤ects, 2001. URLhttp://www.mde.state.md.us/Programs/AirPrograms.

[4] Swedish Environmental Protection Agency: National InventoryReport 2009 Sweden, 2009.

[5] Karl TR:Modern global climate change, 2003.

[6] GoldSim: What is simulation, 2009. URLhttp://www.goldsim.com/Content.asp?PageID=91.

[7] GoldSim: When to use simulation, 2008. URLhttp://www.goldsim.com/Content.asp?PageID=471.

[8] Payne HJ: Fre�o: A macroscopic simulation model of free-way tra¢ c, 1979.

[9] Kota EK, Coyle M, Michalopoulos P, Song S: Enhancements ofthe kronos simulation package and database for geomet-ric design planning, operations and tra¢ c management infreeway networks/corrid, 1997.

[10] Wang Y: Freeway network simulation and dynamic tra¢ cassignment with metanet tools, 2001.

[11] Habib HS: Metacor: a dynamic macroscopicmodeling tool for corridor tra¢ c, 2003. URLhttp://www.inrets.fr/ur/gretia/fiches/produits.

[12] Minuth, Maik: Lattice theory and metropolis simulation,1996.

54

BIBLIOGRAPHY 55

[13] Gainesville: Dynamic network assignment-simulationmodel for advanced roadway telematics, 2008. URLhttp://mctrans.ce.ufl.edu/featured/dynasmart/.

[14] Ben-Akiva M, Bierlaire M, Koutsopoulos H, Mishalani R: Dyna-mit: a simulation-based system for tra¢ c prediction, 1998.

[15] Verket NV: Tables on greenhouse gas emissions, 2007. URLhttp://www.naturvardsverket.se/en/In-English/.

[16] Kosonen I: Tra¢ c performance on major arterials, 2001.

[17] Zaman AG: A Distributed Emission Modelling Platform and Com-munication with Tra¢ c Simulator . Master�s thesis, KTH, 2009.

[18] Barth M:Modal emissions modeling: A physical approach,1996.

[19] Sturm P: Emission factors for heavy-duty vehicles and val-idation by tunnel measurements. Atmospheric Environment2003, .

[20] Technical guidance on the use of mobile6.2 for emissioninventory preparation, 2006.

[21] Cappiello A: Modeling Tra¢ c Flow Emissions. Master�s thesis,Massachusetts Institute of Technology, 2002.

[22] Park JY: Microscopic model of air pollutant concentra-tions: Comparison of simulated results with measured andmacroscopic estimates. Transportation Research Record: Jour-nal of the Transportation Research Board 2001, 1750.

[23] Barth M: Comprehensive modal emission model (cmem),version 2.0 user ¾ars guide, 1999.

[24] Smit R: An Examinaton of Congestion in Road Tra¢ c EmissionModels and Their Application to Urban Road Network . Ph.D. the-sis, Gri¢ th University, 2006.

[25] Teng H: Statistical microscale emission models incorporat-ing accerleration and decerleration. In 81st Annual Meetingof the Transportation Research Board . 2001, .

[26] Waldo J: A note on distributed computing, 2002. URLhttp://www.vs.uni-kassel.de/systems/index.php.

[27] Jawahar: Performance comparison of windows com-munication foundation (wcf) with existing dis-tributed communication technologies, 2007. URLhttp://msjawahar.wordpress.com/.

BIBLIOGRAPHY 56

[28] Tanenbaum AS: Distributed Systems: Principles and Paradigms.Prentice Hall; US ed edition, 2002.

[29] Borland: Borland visibroker, a robust corba en-vironment for distributed processing, 2002. URLhttp://www.borland.com/us/products/visibroker/index.html.

[30] Erl T: Elements of service-oriented computing, 2004. URLhttp://www.whatissoa.com/p1.asp.

[31] Christensen E:Web services description language (wsdl) 1.1,2005. URL http://www.w3.org/TR/wsdl.

[32] Spiritus-Temporis: Disadvantage of wev services, 2005. URLhttp://www.spiritus-temporis.com/web-service/.

[33] Emery C:Clark country carbon monoxide modeling and sipupdate, 2003.

Documents

Dynamic Emission Prediction Platform and Its Integration with Microscopic Traffic ...uu.diva-portal.org/smash/get/diva2:233900/FULLTEXT01.pdf · 2009. 9. 3. · Emission estimation