STANDARDIZATION OF TRAFFIC SIMULATIONMODELS THROUGH VERIFICATION AND
VALIDATION
Ryota Horiguchi, Dr. Engineering
President of i-Transport Lab. Co., Ltd.
2-12-404 Ageba-cho Shinjuku-ku Tokyo 162-0824 Japan,
phone and fax: +81-3-5261-3077, e-mail: horiguchi@i-transportlab.jp

INTRODUCTION
This paper introduces the movement of standardization of traffic simulation models in Japan. We now
find many reports of the simulation studies in business scene. However, the users except model developers
would have less knowledge about the simulation models, because it is difficult to fully understand thenature of the models only by reading literatures or manuals. The simulation is sometimes criticized as"black box", and reconciles itself to unreliable technique.
In order to cope with this criticism, Simulation Committee in Japan Society of Traffic Engineers(Sim@JSTE) have encouraged model developers to disclose the nature of their models throughverification [Horiguchi, et al. 2000] and validation [Horiguchi, et al. 1998] with the purpose to promote
the utilization of traffic simulation. The basic ideas of verification and validation are as follows:“Verification” is a series of simple tests to confirm that fundamental model functions areproperly programmed as in the specification. The simulated result is compared with what theresult should be obtained from the well-authorized theory. In order to individually examine eachof functions and also to get the theoretical solutions to be compared, we should use virtual dataon a simplest network.
“Validation” seems quite similar to “Verification” in general. However, we clearly distinguish“Validation” such that it is the evaluation of the model specification using real field data. Even if
the model is verified as in the specification, the model specification itself may not be adequate todescribe real traffic phenomena. The model cannot be practically applicable, if actual traffic
situations are not sufficiently reproduced due to the incomplete model specification.
Furthermore, the model performance as a system should also be confirmed, such as whether the
execution of the model can be finished within a practical computation time.
One of our outcomes is the verification manual [JSTE. 2001a], which describes the standard verification
procedure so as to be applied to various different types of models. The manual contains a series of basic
tasks to check the reproducibility of traffic conditions of a model by applying simple but ideal dataset.
Each of the basic tasks evaluates 1) vehicle generation pattern, 2) bottleneck capacity and saturation flowrate at an intersection, 3) shockwave propagation, 4) capacity of merging and diverging section, 5) right(left) turn capacity decline at a signalised intersection, and 6) dynamic route choice behaviour. In each task,
simulation results are to be compared with 'well-known' theories in traffic engineering. A theory, which1sometimes too much simplifies the traffic phenomena, can give us some good standing point to understandthe models’ behaviour. We do not, therefore, require the model completely follows the theory, but when thesimulation result is different from the theory, the verifier of the model can explain why the result showssuch discrepancy to vindicate the model itself.
Several simulation models that are practically used in Japan have been evaluated based upon the proposed
verification process. We have verified seven pilot models, such as AVENUE [AVENUE. WWW site],
SOUND [Yoshii, et al. 1995], tiss-NET [Sakamoto, et al. 1998], Paramics [Paramics. WWW site],
NETSIM [NETSIM. WWW site], REST [Yoshida, et al. 1999], and SIPA [Yokochi, et al. 1999] along
the verification manual.
Other output is the benchmark datasets, which are real field data observed and processed well [Hanabusa,
et al. (2001)]. Although verification can help us to comprehend the models' behaviour, it does not tell us
the applicability for the real world where various traffic phenomena embedded and affect each other.
Therefore, the model developers have to show the evidence that those models can reasonably reproduce
such complex situation through the validation with benchmark dataset. The benchmark datasets have beengathered so that developers can utilize them to validate their models, since in general acquisition of real
field data is substantially expensive and time consuming. Some of the pilot models were validated throughthe application with benchmark dataset [Horiguchi, et al. 1996] [Sawa and Yamamoto. 2002].
These outputs can be found in “Clearing House of Traffic Simulation Models” at an Internet website[JSTE. 2001b]. The developers and users of simulation models are also encouraged to publish theirexperiences on verification and validation through Clearing House. Our activities for verification andvalidation can make sense as the objection against the "black-box" criticism only when the ability of themodel is disclosed.

STAGES OF MODEL DEVELOPMENT
In order to clarify the standpoint of verification, let us start with stages of the model development. We
consider the following five stages:

Framework
According to purposes of model applications, we have to first construct the model framework; that is, what
the model input and output are, what kind of traffic phenomena should be described, and so on. Then, we
have to conceptually decide vehicle motions as well as travellers’ behaviour to be incorporated so as toreproduce the traffic phenomena concerned.

Specification
The model framework defined above should be specified in more detailed way. For instance, we should
decide how long the scanning interval is, and what kind of car-following models as well as route choicemodels should be employed, etc.

Implementation
This process consists of programming to run the model contrived in the previous stage on a computer anddebugging to check if the computer operates according to the algorithm. Debugging is just the fixing
coding errors and it must be distinguished from verification described in the next.

Verification
Verification is a series of simple tests to confirm that fundamental model functions are properly2

programmed as in the specification. As mentioned earlier, the simulated result is compared with what theresult should be obtained from the well-authorized theory. In order to individually examine each offunctions and also to get the theoretical solutions to be compared, we should use virtual data on a simplest
network.

Validation“Validation” seems quite similar to “Verification” in general. However, in this paper, “Validation” must
be clearly distinguished such that it is the evaluation of the model specification using real field data. Even
if the model is verified as in the specification, the model specification (or the model framework) itself may
not be adequate to describe real traffic phenomena. The model cannot be practically applicable, if actual
traffic situations are not sufficiently reproduced due to the incomplete model specification. Furthermore,
the model performance as a system should also be confirmed, such as whether the execution of the model
can be finished within a practical computing time.

MANUAL OF STANDARD VERIFICATION PROCESS
Verification is a sort of virtual test using ideal network and demand configurations to qualify basic
phenomena on road traffic. Generally, we do not expect a simulation model to reproduce real traffic
situation perfectly, since some simplification in vehicle motions and user behaviours have to be made andalso discretization of time and space is required to some degree. Accordingly, in the verification, thesimulation result is not expected to exactly agree with the theoretical results. When the simulated result is
far different from the theory, we should revise the programming. However, in most of the cases, thesimulation would perform slightly different way. In these situations, we should utilize the verification tounderstand the model characteristics. Establishing this linkage will provide us very helpful information tounderstand the model characteristics. At the same time, it is considered important to define the relationshipbetween certain model parameters and model behaviour.

Features to be considered through Simulation
We have included six basic features in the verification manual, which should be at minimum considered by
the network simulation models.
Generation of Vehicles and Flow Conservation
For implementation of simulation, it is necessary to generate the traffic at the entry end according to thearrival distribution of vehicles from outside the study area. Most of the simulation models seem to assume
random arrival at a network boundary section, but there might be some other arrival patterns to be adopted
by considering the objective of the simulation study. For example, the uniform arrival may be assumed insome cases of the analysis for over-saturated traffic conditions, in order to avoid the undesirable tendencyof pseudo-random series. The verification process here requires whether the generation pattern assumed in
the model really achieved. It should be also checked whether the number of vehicles generated in a certain
time period is equal to or different from the given volume.
Once a vehicle generated, it must not disappear until it reaches its destination. Even in the case that vehicle
queue spills out of study area, newly generated vehicles are added to the end of the point queue outside the
network and will flow into the network after sufficient time period. Simulation models, so that, must keep
this flow conservation law not only at every links but also outside of network.
Bottleneck Capacity / Saturation Flow Rate at Link’s Downstream End
As the discharging flow rate from a bottleneck section like sags or tunnels contributes to the reproduction
accuracy of the delay caused by the congestion at the bottleneck, it is essential that the capacity of the3bottleneck should be reproduced in a stable manner during the simulation.
Even on surface streets in under-saturated conditions, a vehicle may have the delay caused at signalisedintersections. The outflow from an intersection continues at the saturation flow rate till a vehicle queuedeveloped during the red vanishes. It is important to clarify how the saturation flow rate is reproduced in
the simulation model as for the bottleneck capacity.
Growing and Shrinking Traffic Jam Consistent with Shock Wave Theory
When traffic jam beginning at a bottleneck grows to the upstream link, even traffic that does not need topass through the bottleneck may be also affected. As a difference in the jam’s growing/shrinking speed
results in difference in the degree of influence on the total delay upon whole network, it is important toreproduce this phenomenon by using physical-queue to reasonably maintain the traffic density ofcongestion. The verification of these phenomena is made by comparing the shock wave speed simulatedwith the one based on the shock wave kinematics, as shown in Figure 1.
Arrival: A

Bottleneck capacity: C1
Q

Free flow

A

Congestion
Shock wave speed: v1

v2

Bottleneck capacity: C2 > C1

Arrival: A

Flow

C2
v1

C1

K

Congestion

DensityFree flow
Shock wave speed: v2

Figure 1: The growing speed of jam is determined by the arrival demand and the bottleneck capacity.

For surface streets, on the other hand, even if a signalised intersection is under-saturated, the vehicle queue
grows and shrinks in every cycle. The tail of the queue moves with some time lag at the begging of thegreen phase due to drivers’ response delay at departure. Because of this time lag, when two signalisedintersections are close and the queue heading to the one intersection spreads beyond another, there may be
the case that the vehicles in the tail of the queue cannot pass through the near intersection depending on thesignal offset. Therefore, the simulation model that is considering signal control effect must reasonably
reproduce this phenomenon including shock wave propagation.
Capacity of Merging and Diverging Section
Not only sags or tunnels but also merging and diverging sections can be the most remarkable bottleneck of
highways. At a congested merging section, the travel time on each approaching branch may vary with themerging ratio even if the capacity of the merging section stays constant. Contrary, the capacity of thediverging section is constrained by the capacities of downstream links and may change depending on the
proportion of the demand to each branch. The verification step includes these merging and diverging
configurations.
Gap Acceptance of Right (Left)-Turn at a Signalised Intersection
In ordinary streets, it is daily observed that vehicles waiting for right (left)-turn in the signalisedintersection sometimes obstruct travel of followers and cause congestion. Such vehicles are waiting to findan acceptable gap in the opposing straight-through traffic in the green phase, and consequently the right(left)-turn capacity declines according to the opposing traffic volume. A simulation model that treats a4

signalised intersection would be required to describe such relationship between the turning capacity andthe opposing traffic volume by some set of gap acceptance parameters.
Drivers’ Route Choice Behaviour
Modelling for drivers’ route choice behaviour considered in simulation will be classified as follows:a) No route choice,b) Dynamic User Optimal (DUO) principle,c) Dynamic User Equilibrium (DUE) assignment,d) Probabilistic route choice.
Of these models, the one using a) above is considered applicable to evaluation of the short-term traffic
management that need not consider routes of drivers, or to a network without any alternative routes.
Verification of these models is not necessary because it is equivalent to the verification at amerging/diverging section.
On the other hand, the simulation model using principles of b), c) or d) let a driver select an appropriate
route according to the presented information for routes. This type of models is frequently used to evaluate
the operational policy such as dispersing the traffic spatially by means of informative service or road
construction. Models with route choice can be verified using a simplified network, e.g. with two routes for
one O-D pair, to avoid the difficulty to figure out the theoretical flow pattern to be compared with thesimulation result. It is also interesting to examine results by changing settings of simulation model such as
an update interval of route costs and locations where the drivers can receive the travel cost information.

UNDERSTANDING MODELS' NATURE THROUGH VERIFICATION
AND VALIDATION
In advance of case studies, a user might think what simulation model can be applicable to the subjective
problem. For that, the user must have good knowledge about his/her available models’ nature to choose
appropriate one of them. Since the major purpose of this paper is to give a reader some idea how theverification and the validation processes referred in the manual will be helpful to understand the nature ofmodel, let us introduce several results of verification and validation as examples in this section. The detailsof verification process and further results of verification are referred by [Horiguchi and Kuwahara. 2002].

Generation of Vehicles
For implementation of simulation, it is necessary to generate the traffic at the entry end according to thearrival distribution of vehicles from outside the study area. Most of the simulation models seem to assume
random arrival at a network boundary section, but there might be some other arrival patterns to be adopted
by considering the objective of the simulation study. For example, the uniform arrival may be assumed insome cases of the analysis for over-saturated traffic conditions, in order to avoid the undesirable tendencyof pseudo-random series. The “Standard Verification Process Manual” [JSTE. 2001a] requires whether
the generation pattern assumed in the model really achieved.
Adding to this, it should be also checked whether the number of vehicles generated in a certain time period
is equal to or different from the given volume. Figure 2 indicate the results with different random seeds for
AVENUE [AVENUE. WWW site] and tiss-NET [Sakamoto, et al. 1998], both of which assume random
arrival in vehicle generation. AVENUE always generates the same number of vehicles as the given demandlevel (Q=500, 1000, 2000 [veh./hr]), on the other hand tiss-NET varies its results with each random seed.
5

The results coming from the difference in the attitude of their ‘specification’ stages can be known only
through the qualify tests in verification. It gives meaningful implications that literatures would not tell us.
For this case, a user of the simulation model that has the same nature as tiss-NET in vehicle generation
should realize that he or she has to repeat the simulation for the same network and demand configuration
with different random seeds. The user also has to be careful in choosing the set of random seeds not to bebiased in the number of generated vehicles against to the given demand setting. Subsequently, the user
must evaluate the variation of the number of generated vehicles for each calculation.
Demand 交通需要：
setting = 1000
[veh./hr]
発生台数（
1000台/時）

Generated number of vehicles with different random seed

2000
Trial-1
Trial-2
Trial-3
Trial-4
Trial-5

1500
1000
500
0

Q=500 [veh./hr]

Q=1000 [veh./hr]

Generated# of veh.
発生台数(台)Generated # of veh.

2500

Q=2000 [veh./hr]

1100
1000
900
800
700
600
500
400
300
200
100
0

1060
977

952

1

2

3

985

1007

1008

1017

976

4

5

6

7

8

1023

1028

9

10

乱数seed値
Randomseeds#

Given demand level

Figure 2: Total number of generated vehicles – (Left: AVENUE, Right: tiss-NET)

Traffic Flow Characteristics and Bottleneck Capacity of C-F type Models
As the discharging flow rate from a bottleneck section like sags or tunnels contributes to the reproduction
accuracy of the delay caused by the congestion at the bottleneck, it is essential that the capacity of thebottleneck should be reproduced in a stable manner during the simulation.
According to the procedure described in the manual, the traffic flow characteristics of each C-F typesimulation model must be identified in its verification process. Here, let us introduce the verification of
Paramics [Paramics. WWW site] and SIPA [Yokochi, et al. 1999] as examples, both of which have adozen of model parameters concerning the driving behaviour and the link performance.

Model
Paramics

SIPA

Table 1: Major model parameters of Paramics and SIPA
Driving behaviour
Link performance
Minimum headway,
Headway coefficient,
Maximum acceleration,
Limit speed,
Driving aggression, etc.
Gradient, etc.
Target headway,
Allowable minimum headway,
Target speed,
Limit speed,
Maximum acceleration,
Gradient, etc.
Response delay, etc.

The major parameters of each model are listed in Table 1. The meanings of some are clear, e.g. maximum
acceleration or limit speed, but not all. For instance, how is the "minimum headway" of Paramics
difference from the "target headway" of SIPA, what is the "headway coefficient" of Paramics, or is theinverse of "allowable minimum headway" of SIPA equal to the link capacity? Even if their software
manuals or technical papers state the meanings of the parameters, they are mostly conceptual explanations.
It is still mysterious how each of the parameters effects on the bottleneck capacity.
Our interest here is to understand the quantitative relationships between the model parameters and thebottleneck capacity reproduced in the simulation. Furthermore, we would like to find the most sensitive
parameters through the verification process, because it must be the most efficient strategy to fit the6simulation result to an actual traffic condition by changing the most sensitive parameters.
The left figure in Figure 3 shows a portion of the results of Paramics. The dots in the figure indicate thevolume-density plots observed with varying major parameters. The shape of the dots is associated with thesort of varied parameters. The remarkable point is that the decline of the flow rate is found only when the"headway coefficient" of the bottleneck link is 1.5 (dots surrounded by the circle) and otherwise there areno effects. This implies that only the changes on the "headway coefficient" of the bottleneck link does
affect to the bottleneck capacity while others have less influence.
The right figure in Figure 3 also shows the result of SIPA in the case that the "minimum headway" of thebottleneck link changes from 2.0 seconds to 3.0 seconds. Theoretically, the minimum headway must be
equal to the inverse of the capacity, so that the bottleneck capacity must be 1200 pcu per hour if theminimum headway is 3.0 seconds. However, the bottleneck capacity reproduced in the verification isslightly greater than the theoretical value. We may realize that the "minimum headway" of SIPA is similar
but different parameter from the link capacity.
Q-K plots varying major parameters
3000

Q 交通量
(flow rate)[pcu/hr]
Ｑ [PCU/時]

Other plots with changing the parameters
except “headway coefficient”

2400
Flow rate [pcu/hr]

Q-K plots交通流特性（
varying minimum
ＱＫ曲線） headwayof bottleneck link

3000

1800
Plots for the “headway coefficient” ofthe bottleneck link is set as 1.5.

1200
600

自由流
渋滞流（
ヘッドウェイ変化）
ジャム密度

2400

Capacity of simple section

1800
1200
600

The lowest bottleneck capacity

0

0
25

50

75

100

125

150

0

175

50

100

150

200

[PCU/km]K交通密度(density)Ｋ[pcu/km]

Density [pcu/km]

Figure 3: Bottleneck capacity and traffic flow characteristics (Left: Paramics, Right: SIPA)

There are common findings through the verification of bottleneck capacity for the car-following typemodels:i) Most of them have the parameters that affect to the minimum headway of each link.
ii) Such parameters have strong influence on the bottleneck capacity but others have less influence.
iii) Such parameters are not exactly equivalent to the inverse of the bottleneck capacity.
There are some implications obtained from i) and ii). Even if we use so-called microscopic simulation
models, we have to be rather careful in calibrating the link parameters related to headways than those todriving behaviours. In this sense, such microscopic simulation models are essentially equivalent to themacroscopic simulation models that require the capacities of links.

Saturation Flow Rate at a Signal Intersection
Even on surface streets in under-saturated conditions, a vehicle may have the delay caused at signal
intersections. The outflow from an intersection continues at the saturation flow rate till a vehicle queuedeveloped during the red vanishes. It is important to clarify how the saturation flow rate is reproduced in
the simulation model as for the bottleneck capacity.
For the verification of the saturation flow rate at a signal intersection, the tester is required to show the
profile of discharging traffic within a signal cycle. Let us introduce the result of SOUND [SOUND.
WWW site], which has the combined flow model: car following for expressways (SOUND/express) andqueuing vehicle lists for arterial roads (SOUND/A-21). The former calculates each vehicle speed
7according to the spacing-velocity (S-V) function given to each link. The S-V functions can be identified
through macroscopic surveys of traffic flows. On the other hand, the latter assumes the point-queue at thedownstream end of each link. The point-queue of each link accepts vehicles up to the jam density anddischarges them at the saturation flow rate of the link within the green signal.
Figure 4 illustrates the profile of vehicle discharging for SONUD/A-21. As SOUND/A-21 is a sort of"Q-K type" models, the discharging flow rate at saturation is expected to strictly agree with the given
saturation flow rate. Now we may confirm from the figure that the simulation result attains the given
saturation flow rate as 1600 pcu/G1hr (an effective green hour) in average.
PacketSize=1, PCU=1.0, ScanItvl=1.0
Demand=800[pcu/hr], SFR=1600[pcu/G1hr]
30
Red

Green

Red

Cum.Discharge[pcu]25
20
Yellow
15
10
51600 pcu/hr

1600 [pcu/G1hr]
0

0
-15

0

15

30
45
Lapse time in Green [sec.]

60

75

Figure 4: Link discharging profile at a signal intersection -- SOUND/A-21

There is another point to be discussed in Figure 4. The discharging flow rate of SOUND/A-21
immediately goes up to the saturation flow rate when the signal turns to green. In the actual situation, it
takes some time to discharge the flow at the saturation flow rate because of the response delay of drivers.
The tester of SOUND gives the reason to this point as follows:- Instead of neglecting the starting delay, a vehicle cannot flow out during yellow signals in order toadjust the effective green time.
- At normal intersections, the duration of green signal is nearly equal to the effective green time soas to take the yellow interval as much as the starting delays.

Network Configuration to be Applicable for the Simulation ModelNot only the verification of simulation models but also the validation can give us useful information
concerned with the models’ nature. Figure 5 illustrates the surface street network in Kichijoji-Mitaka area,
Tokyo, on which precise OD trips were collected as well as travel time and signal settings. These data is in
public as “Benchmark Dataset (BM)” [Hanabusa, et al. 2002] to be applied for the model validation.
So far, the validations of AVENUE [Horiguchi, et al. 1998] and NETSIM [Sawa and Yamamoto. 2002]
with Kichijoji-Mitaka BM have been reported. Both of the cases compare the link throughputs from thesimulation result with survey data and calculate the correlation coefficient (R2) to evaluate thereproducibility of traffic condition. AVENUE was applied to the whole network that has alternative routes
for each OD pair, then it gave quite satisfactory result as R2 = 0.98.

8Whole network

Corridor section

1 km

2 km
Figure 5: The Kichijoji-Mitaka network included in the benchmark dataset.

NETSIM, at first, was applied to the whole network, same as AVENUE. The reproducibility, however,
was not satisfactory so that R2 = 0.67, shown in the left plots of Figure 6. Furthermore, the linear
regression line of the plots is slightly steeper than the diagonal line. This means NETSIM tends to overestimate the traffic volume when it is applied to the network containing loops [Sawa and Yamamoto.
2002].
Subsequently, NETSIM was applied to the corridor section in the network that has no alternative route foreach OD pair. For this case, the reproducibility was improved (R2 = 0.90) and the regression line also lies
along the diagonal line.
The reason of this problem can be explained as follows. Since NETSIM does not incorporate drivers’route choice model, the traffic demand is given as turning volume ratio at each intersection. Thus, a vehicle
may run along looped route and use the same link more than twice within its trip. This leads to overestimation of traffic volume. Therefore, the tester of NETSIM concludes that it should be applied only tocorridor shape networks.
Whole network (NETSIM)

Corridor section (NETSIM)

Figure 6: Link throughput reproducibility in the validation of NETSIM [Sawa and Yamamoto. 2002]

FUTURE WORKS
So far, we have been working for standardizing several stages in the utilization of simulation as well as themodel development stage. These our activities can be found in “Clearing House” at an Internet website:
9http://www.jste.or.jp/sim/ (in Japanese, Figure 7).
The developers and users of simulation models can also publish their experiences on verification andvalidation through Clearing House. Followings are the current menus available on Clearing House atpresent (some of them are still under construction, sorry). The best practice manual mentioned above will
be included in the future.
-

Introduction of traffic simulation models used in Japan.
Manual of Standard Verification Process for Traffic Simulation Models.
Verification results of the simulation models.
Standard Benchmark Data Sets for Validation of Traffic Simulation Models.
Validation result of the simulation models with BM data sets.
Online Q&A.

We are now discussing how we encourage model developers to open their verification results to the public.
Basically, we expect the verification process to be “de-fact standard” by educating the necessity of theverification to practitioners and also to people in public sectors who order consulting jobs using simulation
models. The further discussion in our activity is expected that for to comprehend the results of theverification studies, and to estimate the characteristics of each model. Also, we will afford the movementof this standard certification process for other simulation models worldwide.

Figure 7: The Clearing House of Traffic Simulation Models (in Japanese).

REFERENCES
AVENUE. http://www.i-transportlab.jp/products/avenue/ (in Japanese).
Hanabusa, H. et al. (2001). Construction of a data set for validation of traffic simulations, Journal ofJapan Society of Civil Engineers, No. 688/IV-53, pp. 115-123.
Horiguchi, R. et al. (1996). A network simulation model for impact studies of traffic management
10

'AVENUE Ver. 2', Proceedings of the Third Annual World Congress on Intelligent Transport
Systems, Orlando.
Horiguchi, R. et al. (1998). A benchmark data set for validity evaluation of road network simulation
models, Proceedings of 5th World Congress on Intelligent Transport Systems, Seoul.
Horiguchi, R. et al. (2000). A manual of verification process for road network simulation models – anexamination in Japan, Proceedings of 7th World Congress on Intelligent Transport Systems, Turin,
CD-ROM.
Horiguchi, R. (2002). What should be proper indicators to evaluate the reproducibility of traffic
conditions for dynamic traffic Simulation? (in Japanese), Proceedings of Infrastructure Planning,
June 2002, Nagoya.
Horiguchi, R. and Kuwahara, M. (2002). Verification process and its application to network traffic
simulation models, Journal of Advanced Transportation, Vol. 35, No. 3, Special Issue of ITS.
Horiguchi, R. and Oneyama, H. (2002). Future direction for R&D activities of traffic simulation throughthe analysis on practical applications in Japan (in Japanese), Journal of Japan Society of Civil
Engineers, Vol. 709, No. IV-56, pp. 61-69.
JSTE (2001a). A manual of standard verification process for traffic flow simulation model (Draft in
English), http://www.jste.or.jp/sim/verification/manual/VfyManE.html (Japan Society of Traffic
Engineers).
JSTE (2001b). Clearing house of traffic simulation models (in Japanese), http://www.jste.or.jp/sim.
NETSIM. http://www.fhwa-tsis.com/.
Paramics. http://www.paramics.com/.
Sakamoto, K. et al. (1998). Traffic assignment method considering car-by-car behaviour for traffic
impact studies - development of the tiss-NET system, Proceedings of 8th World Conference on
Transport Research, Antwerpen.
Sawa, M. and Yamamoto, F. (2002). Validation of NETSIM using Kichijoji Benchmark Dataset (inJapanese), Proceedings of Infrastructure Planning, June 2002, Nagoya.
Smartest (1997). Review of micro-simulation models, http://www.its.leeds.ac.uk/smartest/.
Smartest (1999). Best practice manual, http://www.its.leeds.ac.uk/smartest/.
SOUND. http://www.i-transportlab.jp/products/sound/ (in Japanese).
Suzuki, H. et al. (2000). A model development for estimations of origin-destination travel time and flowon freeways, Proceedings of 6th International Conference on Application of Advanced Technologies
in Transportation Engineering, ASCE, CD-ROM.
VISITOK. http://www.visitok.gr.jp (in Japanese).
Yokochi, K. et al. (1999). Development of microscopic traffic simulator for AHS Evaluation,
Proceedings of 6th World Congress on Intelligent Transport Systems, Toronto.
Yoshida, T. et al. (1999). A basic study for the planning of ETC-dedicated highway interchange using a
traffic simulator REST (in Japanese), Proceedings of Infrastructure Planning, No.22 (2),pp.231-234.
Yoshii, T. et al. (1995). An evaluation of effects of dynamic route guidance on an urban expressway
network, Proceedings of the 2nd World Congress on Intelligent Transport Systems, Yokohama.
Yoshii, T. and Kuwahara, M. (1998). Estimation of a time dependent OD matrix from traffic counts using
dynamic traffic simulation, 8th World Conference on Transportation Research.

11