OpenEnergySim: A 3D Internet Based Experimental
Framework for Integrating Traffic Simulation andMulti-User Immersive Driving
Arturo Nakasone

Helmut Prendinger

Marc Miska

National Institute ofInformatics
2-1-2 Hitotsubashi,Chiyoda-ku
Tokyo 101-8430, Japan

National Institute ofInformatics
2-1-2 Hitotsubashi,Chiyoda-ku
Tokyo 101-8430, Japanarturonakasone@nii.ac.jp

helmut@nii.ac.jp

Smart Transport Center
Queensland University ofTechnology
GPO Box 2434
Brisbane, QLD 4001, Australia

Martin Lindner

Ryota Horiguchi

marc.miska@qut.edu.au
Masao Kuwahara∗

National Institute ofInformatics
2-1-2 Hitotsubashi,Chiyoda-ku
Tokyo 101-8430, Japani-Transport Lab., Co., Ltd.
Jinbo-cho 1-4, Chiyoda-ku
Tokyo 101-0051, Japan

Tohoku University
Aoba, Aoba-ku, Sendai
Miyagi 980-8579, Japanrhoriguchi@itransportlab.jp

kuwahara@plan.civil.
tohoku.ac.jp

martinl@nii.ac.jp
ABSTRACT

Categories and Subject Descriptors

In recent years, the use of computer-based simulations in
the transportation domain has become increasingly important to analyze and test measures for Intelligent Transport
System (ITS) policies. Simulators were built to address several aspects of transport, including traﬃc, driving experience, and pedestrian behavior. However, as the majorityof available simulators are single-user stand-alone systems,
traﬃc engineers cannot easily analyze more complex phenomena, such as the interaction between multiple humandrivers or pedestrians. Furthermore, this limitation makes
it diﬃcult to collect large-scale behavioral data, which isnecessary to draw valid conclusions on driving behavior.
Emerging virtual world technology oﬀers a convenient alternative. As a networked multi-user framework that allows users to immerse in the virtual world via a graphicalself-representation (an ‘avatar’), it allows to develop integrated simulation applications that are conveniently accessible by Internet. In this paper, we present OpenEnergySim,a virtual world based visualization application that integrates traﬃc simulation and immersive multi-user driving.
OpenEnergySim opens new and exciting ways to explore realistic transport scenarios, in which users can participate as
drivers, pedestrians, or traﬃc engineers. Our solution is created in collaboration with research institutes and industry.

I.6.7 [Simulation and Modeling]: Simulation Support
Systems; I.6.7 [Simulation and Modeling]: Types of Simulation—Animation, Combined, Visual∗This author is also aﬃliated to the ITS Center, Instituteof Industrial Science, The University of Tokyo.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.
SimulationWorks ’11 Barcelona, Spain
Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.

General Terms
Design, Human Factors

Keywords
Traﬃc Simulation, Driving Simulation, Virtual Worlds, OpenSimulator

1.

INTRODUCTION

Simulation of transportation systems has been one of theimportant application areas of computer simulation for morethan 20 years [3, 8]. Recently, the demand for evaluating andtesting Intelligent Transport System (ITS) applications has
raised even more interest in simulation-based approaches.
By using simulators, it is possible to estimate the eﬀects
of ITS measures without interfering traﬃc of the real-worldtransport network. Microscopic traﬃc simulation tools arebeing increasingly applied by traﬃc engineers and transport professionals to address dynamic and operational traﬃcproblems and to evaluate such systems [21]. Many models
for microscopic traﬃc simulation are now available (see [4]for an extensive list).
However, most available systems operate on rather artiﬁcial conditions. For instance, micro-simulation applications,i.e. traﬃc simulations that represent the trajectories of individual cars, do not consider the driving behaviors of realusers as variables for their models. There are two main
reasons. First, traﬃc engineers often follow mainly analytical objectives, and second, the technical implementation ofcomplex traﬃc scenarios is cost-intensive. Currently, there
is no integrated visualization platform capable of handlingsuch dissimilar features as (1) smooth visualization of largescale data for traﬃc simulation and (2) realistic physics emulation for users’ driving experience.
Virtual world technology is considered as a convenient,cost-eﬀective visualization platform for scientiﬁc research [2,22], and [14] already proposed a virtual world based solution
for visualizing the simulation of a Personal Rapid Transit
System. However, the implementation of a systematic integrative solution using virtual worlds has not been exploredyet. Therefore, in this paper, we present OpenEnergySim,
an integrative virtual world based platform that combines
traﬃc simulation and realistic user driving experience withthe goal of providing traﬃc engineers a simulation tool for
exploring and testing advanced ITS strategies.
This paper is organized as follows. Section 2 presents an
overview of research work on driving and traﬃc simulatorsand transportation visualization. Section 3 describes the
OpenScience framework, our in-house implemented technology to facilitate application development for virtual worlds.
Section 4 provides a detailed description of OpenEnergySim,
by explaining its diﬀerent components (server and client
modules, game wheel interface) and their integration. Finally, Section 5 discusses and concludes the paper.

computer, Internet connection, and optionally, a game wheel
for realistic driving. The OpenSim viewer is free for download. OpenSim supports persistent virtual worlds, where
researchers may alter the test scenario collaboratively andin real-time, and the changes will be reﬂected in a central
database for future use.

3.

Our OpenScience virtual world framework API (Application Programming Interface) is based on OpenSim, an open
source virtual world server. It was conceived to help developers implement OpenSim-based applications in a quick
and easy way. The framework extends the functionality oflibraries such as EML3D [20], MPML3D [24] and LibOpenMetaverse4 by providing new features or more eﬃcient versions of current existing ones, while maintaining platform
independency for application development.
The OpenScience framework consists of two main components (see Fig. 1):• OpenLibrary plugs directly into the OpenSim server
and provides low level access to simple functions suchas the creation and deletion of prims (primitive graphical elements in the simulator) or the subscription to
speciﬁc virtual world events through a TCP/IP-based
interface.

2. RELATED WORK
The visual representation of traﬃc ﬂow in most currently
available traﬃc simulation tools is two-dimensional (2D) [15,7, 6] or three-dimensional (3D) [3, 27, 5, 26, 16]. The simulation component and the viewer (viewing program) areeither located in the same machine (e.g. [3]), or organized
in a client-server architecture (e.g. [27]).
3D visualization becomes an essential feature when there
will be human-driven cars interfering with the simulation.
Driving simulators are eﬃcient tools to evaluate drivers’ behavior. They use virtual reality tools to generate the user’s
sensations similar to those of driving a real car [28]. There
are two kinds of driving simulators: (1) a moving-base simulators [12, 1, 10, 13, 11, 17] and (2) ﬁxed-base simulators[25]. For instance, moving-base simulators are capable ofgiving motion feedback about how the car is moving in thesimulated world.
However, often less advanced simulators are suﬃcient toobtain realistic data of users’ driving behavior. For instance,[29] have implemented an environment for testing the inﬂuence of a voice-based command system on the user’s driving.
User-controlled cars and computer-controlled cars share a
virtual space for experimentation. The STSoftware1 usedsupports multiple users and easy scenario conﬁguration. In
contrast to our method, this approach is based on licensed
software and does not provide on a persistent virtual world.
For evaluating an ITS application known as Intellidrive2 ,the U.S. Department of Transportation used a driving simulator based in the Unreal game engine3 . They claim thatwithin a development period of four months, a demo withvery high quality graphics could be developed. However, thesimulator can only handle a single user at a time and notavailable to the general public.
Unlike the available methods, our approach is based on the
networked OpenSim world simulator, which just requires a

THE OPENSCIENCE FRAMEWORK• OpenAppCore provides an abstraction layer on top of
OpenLibrary, which enables developers to encapsulate
complex virtual world objects to simplify their use in
subsequent application developments. This layer also
implements an access wrapper for OpenLibrary called
OLWrapper to facilitate function calls to the library.

Figure 1: Functional diagram of the OpenScience
framework.

3.1

OpenSim

1

OpenSim is a virtual world server technology that was introduced as an open source alternative to Linden Labs’ popular “Second Life” service5 . OpenSim allows users to build
content and interact with each other inside a virtual world2

4

http://www.stsoftware.nl/
http://www.intellidriveusa.org/
3
http://www.udk.com/

5

http://lib.openmetaverse.org/
http://secondlife.com/

using a Second Life compatible client application. OpenSim
maintains a large community of users and developers are actively working on it. At the time of writing of this paper,
most of the functionality provided by Second Life has been
implemented or even extended in OpenSim. OpenSim has
several advantages over Second Life:• Extensibility. OpenSim server functionality can be extended through the use of plug-ins (application modules that are automatically recognized and loaded by
OpenSim). These plug-ins have complete access to
OpenSim’s internal structures, allowing developers tocreate highly customized solutions.
• Server Control. Using OpenSim allows developers tohave full control of the whole application implementation process. In other virtual worlds such as Second
Life, developers are constrained by the limitations imposed by the owners of the servers in which the virtualworlds run. With OpenSim, developers can overcome
those limitations and ﬁnd out the real limits for theirimplementations based on their own infrastructure.
• Content Ownership. The use of OpenSim also guarantees the complete control of the content deployed andgenerated in the virtual world, easing the fears of users
regarding the ownership of their creations.

3.2 OpenLibrary
OpenLibrary6 was implemented as an plug-in based on
OpenSim’s extensible architecture. It is loaded and instantiated by OpenSim during startup through .NET’s reﬂection
mechanism. The library features a similarly modular design
approach and, therefore, allows the automatic discovery,loading and activation of functional units called managers
during the server’s startup. The current version is composedof a central Interface Manager and a set of core managers,which implement the functionality of OpenLibrary itself.

3.2.1 The Interface Manager
The Interface Manager acts as the central administration
component in OpenLibrary and is responsible for loading
the core managers and delegating commands to them (seeFig. 1). In order to provide access to the virtual world functionality to the core managers, the Interface Manager receives as initialization parameters references to virtual world
regions (called Scenes in OpenSim) and to OpenSim conﬁguration values. When the Interface Manager locates and loads
the core managers, a reference of itself is passed to thesemanagers, allowing not only manager development independency, but also a uniﬁed way to access OpenSim’s sharedresources.

3.2.2 The Core Managers
In addition to the Interface Manager, OpenLibrary includes a set of core managers that encapsulate the actual
functionality of the library. Currently, seven core managers
have been implemented: Communication, Avatar, Event,Data, Land, Physics and Object. Each manager is responsible for one speciﬁc set of tasks as described below:• The Communication Manager is used for communication between OpenLibrary and external applications.
It provides the ability to handle socket communication.
6

http://www.prendingerlab.net/globallab/technology/• The Avatar Manager implements functions related tothe creation and manipulation of avatars, including
functions to log avatars in and out, move avatars, andsend chat messages.
• The Object Manager implements functions to create
and manipulate objects in the virtual world, except
objects considered part of nature such as trees or grass.
Various types of primitive objects such as boxes, spheresor cylinders can be built and connected. Objects’color, texture and other physical properties can be
modiﬁed as well.
• The Land Manager implements functions to create objects related to nature (e.g. trees, clouds, smoke) andto modify terrains.
• The Data Manager implements functions to connect
external data sources to objects in OpenSim and viceversa. For instance, an external temperature data
stream can be mapped to the height of an object in thevirtual world or moving an object located inside thevirtual world could trigger actions in the real world.
• The Event Manager implements event handling in OpenLibrary. For instance, an external application can
subscribe for chat messages or object updates (e.g.
changes in position, deletion, and so on).
• The Physics Manager implements functions to manipulate the physical properties of virtual world objects(e.g. apply forces to objects).

3.3

OpenAppCore

OpenAppCore is a software layer implemented over OpenLibrary. Its main objective is to provide virtual world based
application programmers with a simple, ﬂexible, and fully
functional framework to interconnect and reuse runtime components that operate with entities in the virtual world. In
OpenAppCore, programmers can develop customized, virtual world based components by using OpenAppCore’s access point to OpenLibrary (the OLWrapper component) tofacilitate function callings and event subscriptions. Oncethe components are implemented, other developers can use
those components by instantiating them using OpenAppCore’s component management processes. In this way, we
are able to ensure that programmers can modularize theirwork and increase their development performance throughsoftware reusability. For instance, a user driven car component involves the implementation of several complex functions such as “accelerate”, “turn lights on”, and so on, andeach of these functions involves, in turn, the implementation of several complex OpenLibrary function calls. Without OpenAppCore, each developer that desires to implement
a user driven car would have to adapt or reimplement thesame code for his/her own solution, creating problems forsoftware maintenance and versioning. On the other hand,by using OpenAppCore, developers that merely want to use
a user driven car would just need to copy the component totheir own solution and instantiate it, saving precious development time.
Most of the objects managed by OpenEnergySim were
implemented as OpenAppCore components, giving us thepossibility to modularize our work and considerably reduce
the application’s overall implementation time.

Figure 2: Functional diagram of server Module of OpenEnergySim.

4. INTEGRATING TRAFFIC SIMULATION
AND MULTI-USER DRIVING
In this section, we will describe OpenEnergySim, a platform for behavioral driver studies in virtual worlds based on
the OpenScience framework. OpenEnergySim allows us to
integrate and synchronize simulation of microscopic traﬃcwith the driving simulation of multiple drivers. The twomain modules of OpenEnergySim are:
• Server Module. This module is responsible for (1) controlling the visualization of the traﬃc simulation, (2)managing the interactive virtual world based interface,(3) synchronizing the traﬃc simulation with the online
driving behavior from users.
• Client Module. This module provides users the means
to drive virtual cars using either a keyboard interface
or a gaming wheel device.
The main components of both Server and Client modules
will be explained in the following sections.

4.1 Server Module
The main purpose of the Server Module is to connect andsynchronize the traﬃc simulator and the OpenSim virtualworld, by performing the following tasks: (1) Receive information about virtual objects and/or vehicles controlled by
the traﬃc simulator and create or update their corresponding graphical representations in OpenSim, and (2) receive
information about user interaction with objects (such as vehicles) in OpenSim and forward it to the traﬃc simulator.
The Server Module is composed of ﬁve main components(see Fig. 2):• Core component, whose main function is to instantiate
the other components when the application starts.
• User Interface component, which is in charge of managing the virtual objects created by OpenEnergySim.

• Traﬃc Simulator component, which generates microscopic traﬃc, i.e. trajectories of individual cars. Currently, we use the X-Roads traﬃc simulator [18, 9].
• Data Rate Converter component, which handles thedata synchronization between the traﬃc simulator andthe user driven vehicles in the virtual world.
• Event Logging component, which stores attributes ofuser-controlled and computer-controlled cars (position,
velocity) in a central database on a frame per frame
basis.
OpenEnergySim uses OpenLibrary and OpenAppCore, twocomponents of our OpenScience framework (see Sect. 3) thathelps programmers to implement virtual world based applications easily. While OpenLibrary provides low level accessto simple functions such as ‘create’ and ‘delete’ prims (primitive graphical elements) and listen to speciﬁc virtual world
events, OpenAppCore allows programmers to create and distribute complex objects based on OpenLibrary’s functionality.
When the application is executed, the Server Module creates an instance of the OpenEnergySim Core component,
which in turn instantiates the X-Roads Traﬃc Simulator
component, the Data Rate Converter component, the User
Interface component, and the Event Logging Module component.

4.1.1

Data Rate Converter

Since the majority of traﬃc simulators such as X-Roads
was primarily designed to run on stand-alone platforms, thetraﬃc processing data rate is approximately 100 frames/sec.
A frame is deﬁned as the attribute information (position,
velocity) of all the vehicles at a speciﬁc moment during thesimulation. This update rate is extremely diﬃcult to maintain in networked environments such as client/server based
virtual worlds, because of the lag imposed by the network
infrastructure.
To accommodate for the speciﬁc requirements of virtualworld technology, we developed the Data Rate Converter

component, which is responsible for maintaining coherent
synchronization between the information generated by thetraﬃc simulator and the information generated in OpenSim.
The main purpose of the component is to collect all the asynchronous update events from X-Roads and the User Interface component, and synchronously forward them to theirrespective recipient in ﬁxed-time intervals. Since both XRoads and OpenSim have very diﬀerent update rates, theData Rate Converter automatically performs two procedures
to ensure data interchange consistency:• Prioritization of Updates. Prioritization means that
updates that are more critical to the execution of thevisualization are passed ﬁrst. For instance, a VEHICLE DELETE command has a higher priority than a
VEHICLE UPDATE POSITION command since thetraﬃc simulator may try to update attributes of an
object that does not exist in the virtual world anymore. Note that most traﬃc simulators follow an O–
D (Origin–Destination) scheme, where cars are createdat some initial location, and removed if outside of thearea determined by the traﬃc simulator.
• Merging of Updates. Merging means that updates thatare irrelevant because they were superseded by otherupdates are eliminated. For instance, a VEHICLE UPDATE POSITION command can be deleted if another
VEHICLE UPDATE POSITION for the same vehicle
arrived.

Figure 3: Virtual representations of objects manipulated by X-Roads: a gantry for customized message
display (top), a traﬃc light (bottom-left), and a sensor (bottom-right).

The functionality of the Data Rate Converter provided asmoother visualization of the car trajectories generated by
the traﬃc simulator.

4.1.2 User Interface – Connecting to OpenSim
The User Interface component is in charge of (1) the creation, deletion and manipulation of any user interface object
deﬁned inside the virtual world, and (2) the handling theevents generated by user interaction. The component interacts with OpenSim through the use of our OpenAppCore
framework component solution. There are two types of userinterface objects:• Objects that are dynamically manipulated by the trafﬁc simulator, including vehicles, traﬃc lights, sensors,and Variable Message Signs (VMS).
• Objects that are used by users to manipulate the ﬁrst
type of objects, speciﬁcally button array objects forsensor manipulation.
Figure 3 shows the virtual world representation of the objects currently manipulated by X-Roads. Figure 4 shows
the button array interface for instantiation of user driven
vehicles and sensor creation. Users can create a car thatis controllable by a wheel (bottom button), or controllable
by a keyboard if a wheel is not present (above-bottom button). Sensor creation and deletion functions use the current
position of the avatar that clicked the button to determine
where the sensor is to be created or which sensor to remove.
Some User Interface objects are considered static and always present in the virtual world (e.g. traﬃc lights), wheras
others have to be created at runtime, such as vehicles or
sensors controlled by OpenEnergySim. The creation of an
object in OpenSim is achieved in one of two ways:

Figure 4: A button array interface displays the menu
of options for sensor manipulation (top three buttons) and user driven vehicle instantiation (two buttons at bottom).
• The object is loaded into the virtual world using an
XML description ﬁle.
• The object is instantiated based on an inventory asset that is already stored in the virtual world asset
manager.
In the case of the ﬁrst method, users do not need to know
about the virtual world asset manager and can instantiate
the same object independent of the virtual world environment. However, streaming XML description ﬁles into OpenSim could aﬀect the server’s performance if the method is
overused. Therefore, we use the ﬁrst method for operations
that are not so frequent, such as sensor creation or user
driven vehicle instantiation. The second option is much
faster and it is currently used to create computer-controlled
vehicles.
For static objects, which are typically created before theexecution of the application, a list containing the identiﬁers

of those objects in the virtual world is passed to the User
Interface component, so that their non-visual counterparts
can be instantiated and recognized by OpenEnergySim. Although some objects can be retrieved by providing theirname, others have to be retrieved by providing the actual
identiﬁcation number known as UUID (Universal Unique
Identiﬁer). This information has to be part of the XMLbased conﬁguration ﬁle before the Server Module starts its
execution. An example of a conﬁguration ﬁle is shown in
Fig. 5.

4.2 Client Module
The virtual driving experience in most of the car related
games is based on the implementation of two major components:• The vehicle physics engine which governs the vehicle’s
motion dynamics, andare used to specify the individual elements of the car. The
status of functional prims can change over time and aﬀect
their visualization in the virtual worlds, such as break lights
or CO2 indicator.
The car management is divided into two main components. The LandTransportBasic component runs on theserver as part of OpenEnergySim, and the LandTransportCont component that runs on the client. Both components
make use of our OpenLibrary and OpenAppCore libraries(see Sect. 3). Figure 7 shows the component architecture diagram and the interaction of server and client components.
The LandTransportCont component utilizes the WheelInterface to connect to the Logitech G27 Wheel8 and uses the
SpeedOMeterApp component to display a car’s speed. On
the other hand, the LandTransportBasic component is used
to connect the car to OpenEnergySim.
Server• the driving user interface which handles the hardware
drivers use to interact with the vehicle.
Users’ satisfaction of their driving experience is mainly determined by the stability and accuracy of the interaction
between these two components. Games and other standalone applications enjoy the beneﬁt of having both components in the same machine. In the networked environment
like OpenSim, on the other hand, a generic physics called
Open Dynamics Engine (ODE)7 is located on the server andcontrols the physical processes of the entire environment.
Therefore, a virtual world based solution has to support
a two-stage physics interaction, in which the dynamic force
values calculated by the vehicle’s physics engine (client side)
are passed to the generic physics engine (server side). The
vehicle physics engine calculates the longitudinal force to be
applied to the vehicle based on the user interface input anda vehicle proﬁle. It then passes this value to the OpenSim
physics engine which will move the vehicle inside the virtual world. Figure 6 shows the main components of vehicle
motion in OpenSim.

VehicleprofileHardwareDeviceInput

Vehicle Physics
EngineForce to Apply

OpenSimODE

ClientWheelInterface

LandTransportBasic
OpenAppCore

SpeedOMeterApp
OpenSim
OpenLibrary

VehicleprofileLandTransportCont
TCP

OpenAppCore

ODE

Figure 7: Component architecture for client vehicle
motion in OpenEnergySim.
The LandTransportBasic component instantiates the car
object in the virtual world and provides a basic interface
to receive the car’s properties, such as current velocity andposition, and to set attributes such as lights (on/oﬀ). To
instantiate a car, the component needs a XML ﬁle with thedescription of the car’s visual elements (prims) or an UUID
of an existing car inside the world. With this information,
OpenEnergySim manages the car’s creation and deletion, as
well as the logging of its properties into the central database.
To drive the car, users must provide values (via driving)
for linear force and moment applied to the car object. The
LandTransportCont component allows users to control three
car parameters:• Speed : applies a linear force to go forward or backward.
• Steering: applies moment to turn right or left.

Figure 6: Client vehicle motion in OpenSim.

• Driver’s seat: sets the position of the avatar inside thevehicle.

4.2.1 User Vehicle
A car in OpenSim is implemented as a frictionless object, composed of prims. The car is manipulated throughdirect intervention of the physics engine or through commands speciﬁed by programming scripts inside the primsthat can change its overall status.
In OpenEnergySim, a car is deﬁned by a main prim and aset of functional prims. The main prim is used to manipulate
the entire motion of the car, whereas the functional prims

The LandTransportCont component was designed with ageneric interface to support the default interaction paradigmof virtual world clients, which is the keyboard.

78

http://www.ode.org/

4.2.2

Wheel Interface

Since our goal was to provide a driving interaction device that mimics real-world driving, we developed a component called WheelInterface, which provides the connection
http://www.logitech.com/

Figure 5: Sample conﬁguration ﬁle for static objects. The UUIDS of traﬃc lights and VMS can be retrievedby their names, while vehicle templates for traﬃc simulation have to be speciﬁed directly with their UUIDs.

Figure 8: Driving a virtual car in OpenEnergySim
using the Logitech Gaming Wheel G27.
between LandTransportCont and a Logitech’s G27 Wheel 9(see Fig. 8).
The WheelInterface component retrieves the following values from the device: (1) Gas pedal pressure, (2) brake pedal
pressure, (3) steering angle, and (4) push button events(e.g. gear change). These values are used by the vehicle
physics engine to calculate the linear force and moment thatwill be applied to the car in OpenSim. In the vehicle physics
engine, we use a model that takes two types of force into account [19]: Traction, i.e. force generated by the engine, anddrag force, i.e. force created by friction and air resistance).
With these values, the vehicle physics engine calculates the9
http://www.logitech.com/enus/gaming/wheels/devices/5184. Last Access: 2010/09/08

longitudinal force, and then a linear force is sent to OpenSim.
To obtain the moment, the physics model in [19] uses theangle of the front wheels as a parameter. However, in a realcar, the angle of the steering wheel is not the same as theangle of the front wheels, thus it will thus be calculated. To
obtain angle of the front wheels, there two values were taken
into account: The steering ratio, i.e. the relation between
the angle of the steering wheel and the angle of the front
wheels, and the lock-to-lock (LTL) value, i.e. the number ofturns a steering wheel takes to reach from the maximal rightposition starting from the maximal left position.
In a real car, the steering ratio is normally between 12:1
and 20:1. (A n : 1 ratio means that a n degree angle inthe steering wheel will turn the front wheels 1 degree). In
addition, the LTL value is calculated taking into account the
maximal angle of deﬂection of the wheels δ and the steering
ratio ρ 10 . Equation 1 shows the formula for LTL calculation.
LT L = 2 × (δ × ρ)

(1)

When driving a virtual car, the LTL value stays constant but
the wheels’ deﬂection and steering ratio change dependingon the car speed. The basic principle is that with a constantsteering wheel angle, the car turning rate is inversely proportional to its speed. For instance, if the car’s speed is 100
km/h, a driver has to steer the wheel more in order to havethe same turning angle than if the car’s speed is 10 km/h.
This is summarized in Table 1.
By taking into consideration the values in Table 1, we deﬁned a linear interpolation equation to calculate the steering
ratio ρ based on the car’s speed ω. This is shown in Eq. 2.
ρ = 0.2878ω + 7.2122
10

http://www.carbibles.com/steering bible.html.
cess: 2010/09/08(2)
Last Ac-

Table 1: Steering ratio mapping using LTL = 900
degrees. Wheel deﬂection values are taken from theactual Logitech G27 documentation.
Speed (km/h)
1100

Wheel Deﬂection δ
60◦
12.5◦

Steering Ratio ρ
7.5:1
36:1

Using this steering ratio value, we calculate the car’s wheel
rotation angle α based on the current car speed ω and thesteering wheel rotation angle β (Eq. 3). The vehicle physics
engine uses α to calculate the moment applied to the car.
α=

β
β
=
ρ
0.2878ω + 7.2122

In this paper, we have presented OpenEnergySim, an integrative multi-user traﬃc application solution based on virtual world technology. Our preliminary tests of the systemshow very promising results in terms of traﬃc visualization
and user driving experience. In [23], we describe a carfollowing experiment that was conducted in OpenEnergySim.
The results obtained in the virtual world could be shown
were very similar to both real-world data on car-following
and a car-following model.
However, the emergent nature of the virtual world technology created several challenges during the implementationof OpenEnergySim. We will brieﬂy discuss two of them.
First, the visualization of traﬃc simulation suﬀers from theoverﬂowing amount of data from the traﬃc simulator. We
had to manually ﬁne-tune the rate of information transmission so that the visualization would not lag too much, basedon trial and error. We found that this value depends mostly
on the server’s hardware and network conditions rather thanthe visual client. Techniques such as client side prediction
algorithms might reduce the traﬃc visualization lag, butcurrent visual client applications are extremely hard to extend. In the future, we plan to address this problem byexperimenting with other, more ﬂexible, visual clients suchas Naali from RealXtend.11
HUD (Heads-up Display) interfaces would be preferable to
let users manipulate in-world menu objects, but they proved
to be extremely diﬃcult to implement. While the use of 3D
world buttons would allow simultaneous access for all users,
it is impractical in a context in which avatars need to accessthe menu no matter where they are. We will be exploring
ways to enhance client side user interfaces by implementing
new functionality in our OpenScience framework.
Despite the technical diﬃculties faced during the development of OpenEnergySim, we are convinced that virtualworlds will become the most convenient platforms to test
integrative solutions for the transportation domain. The
main reasons are low production cost and high accessibility. Several complex challenges will arise in this endeavor
since currently there is still a gap between social interaction (which is the initial main objective of the technology)
and simulation of large-scale data. Nevertheless, we believethat the ﬂexibility and openness of virtual world implementations such as OpenSim will allow us to close that gap.
http://www.realxtend.org. Last Access: 2010/12/02

6.

ADDITIONAL AUTHORS

Additional authors: Juan Camilo Ibarra (National Institute of Informatics, email: juanibarral@gmail.com). Kugamoorthy Gajananan (National Institute of Informatics, email:k-gajananan@nii.ac.jp) Ricardo Mendes (National Institute of Informatics, email: ricardo.tiago.mendes@gmail.com),and Marconi Madruga (National Institute of Informatics,
email: marconi@nii.ac.jp).

7.
(3)

5. DISCUSSION AND CONCLUSIONS

11

OpenEnergySim will allow us to provide engineers the tools
they need to handle complex scenarios that closely resemble
real-world problems.

REFERENCES[1] H. Arioui, S. Hima, and L. Nehaoua. 2 DOF low cost
platform for driving simulator: Modeling and control.
In IEEE/ASME International Conference on
Advanced Intelligent Mechatronics (AIM 2009), pages
1206–1211, 2009.
[2] W. Bainbridge. The scientiﬁc research potential ofvirtual worlds. Science, 317:472–476, 2007.
[3] J. Barceló, E. Codina, J. Casas, J. L. Ferrer, and
D. Garcı́a. Microscopic traﬃc simulation: A tool forthe design, analysis and evaluation of intelligent
transport systems. Journal of Intelligent & Robotic
Systems, 41(2):173–203, 2005.
[4] S. A. Boxill and L. Yu. An evaluation of traﬃcsimulation models for supporting its development.
Technical Report SWUTC/00/167602-1, Center forTransportation Training and Research, Texas
Southern University, 2000.
[5] B. C. da Silva, A. Bazzan, G. Andriotti, F. Lopes, andD. de Oliveira. ITSUMO: An intelligent
transportation system for urban mobility. In T. Bhme,
V. L. Rosillo, H. Unger, and H. Unger, editors,
Innovative Internet Community Systems, volume 3473
of Lecture Notes in Computer Science, pages 224–235.
Springer Berlin Heidelberg, 2006.
[6] P. Hidas. Modelling lane changing and merging in
microscopic traﬃc simulation. Transportation
Research Part C: Emerging Technologies,
10(5–6):351–371, 2002.
[7] R. Horiguchi, M. Kuwahara, M. Katakura,
H. Akahane, and H. Ozaki. A network simulation
model for impact studies of traﬃc management avenue
ver.2. In Proceedings 3rd Annual World Congress on
ITS, 1996.
[8] R. G. Hughes. Visualization in transportation:
Current practice and future directions. Transportation
Research Record, 1899:167–174, 2004.
[9] T. Jiang, M. Miska, M. Kuwahara, A. Nakasone, and
H. Prendinger. Microscopic simulation for virtualworlds with self-driving avatars. In Proceedings 13th
International IEEE Conference on Intelligent
Transportation Systems (ITSC’10). IEEE, 2010.
[10] H. S. Kang, M. K. A. Jalil, and M. Mailah. A
pc-based driving simulator using virtual reality
technology. In Proceedings of the 2004 ACM
SIGGRAPH international conference on Virtual
Reality continuum and its applications in industry,
VRCAI ’04, pages 273–277. ACM, 2004.

[11] N. Kuge, T. Yamamura, and O. Shimoyama. A driver
behavior recognition method based on a driver model
framework. Society of Automotive Engineers
Transactions, 109(6):469–476, 2000.
[12] J. Kuhl, D. Evans, Y. Papelis, R. Romano, andG. Watson. The Iowa driving simulator: An immersive
research environment. Computer, 28(7):35–41, 1995.
[13] W.-S. Lee, J.-H. Kim, and J.-H. Cho. A driving
simulator as a virtual reality tool. In Proceedings
IEEE International Conference on Robotics andAutomation, volume 1, pages 71–76, 1998.
[14] C. Lopes, L. Kan, A. Popov, and R. Morla. Prt
simulation in an immersive virtual world. In 1st
International Conference on Simulation Tools andTechniques for Communications, Networks andSystems and Workshops, 2008.
[15] P. Lorenz, T. Schulze, and T. Schriber. The design,
implementation, application and comparison of two
highly automated traﬃc simulators. In Simulation
Conference Proceedings, 1994. Winter, pages
1084–1092, 1994.
[16] J. Maroto, E. Delso, J. Felez, and J. Cabanellas.
Real-time traﬃc simulation with a microscopic model.
IEEE Transactions on Intelligent Transportation
Systems, 7(4):513–527, 2006.
[17] M. Maza, S. Val, and S. Baselga. Control architectureof parallel and spherical driving simulators and related
human factors. In Proceedings 10th IEEE
International Workshop on Robot and Human
Interactive Communication, pages 541–545, 2001.
[18] M. Miska. Real time traﬃc management by
microscopic online simulation. Technical Report
T2007/1, TRAIL Thesis Series, The Netherlands,
2007.
[19] M. Miska and M. Kuwahara. Nanoscopic traﬃcsimulation with integrated driving simulator toinvestigate the sag curve phenomenon. In Proceedings
9th ITS Symposium, 2010.
[20] A. Nakasone and H. Prendinger. EML3D: An XML
based markup language for 3D object manipulation in
Second Life. In Proceedings 9th International
Symposium on Smart Graphics (SG’09), pages
263–272. Springer LNCS 5531, 2009.
[21] S. Panwai and H. F. Dia. Comparative evaluation of
microscopic car-following behavior. IEEE
Transactions on Intelligent Transportation Systems,
6(3):314–325, 2006.
[22] H. Prendinger. The Global Lab: Towards a virtual
mobility platform for an eco-friendly society.
Transactions of the Virtual Reality Society of Japan,
14(2):163–170, 2009.
[23] H. Prendinger, A. Nakasone, M. Miska, and
M. Kuwahara. OpenEnergySim: Conducting
behavioral studies in virtual worlds for sustainabletransportation. In IEEE Forum on Integrated andSustainable Transportation Systems (FISTS’11), 2011.
Submitted.
[24] H. Prendinger, S. Ullrich, A. Nakasone, and
M. Ishizuka. MPML3D: Scripting agents for the 3D
Internet. IEEE Transactions on Visualization andComputer Graphics, 2010. In press.
[25] M. P. Reed and P. A. Green. Comparison of driving

performance on-road and in a low-cost simulator using
a concurrent telephone. Ergonomics, 42(8):1015–1037,
1999.
[26] D. Rieck, B. Schünemann, I. Radusch, and C. Meinel.
Eﬃcient traﬃc simulator coupling in a distributed
V2X simulation environment. In Proceedings of the
3rd International ICST Conference on Simulation
Tools and Techniques, number 72 in SIMUTools’10,
pages 1–9. ICST (Institute for Computer Sciences,
Social-Informatics and Telecommunications
Engineering), 2010.
[27] T. Wang, S. Tang, and P. Pang. 3D urban traﬃcsystem simulation based on geo-data. In 2nd
International Conference on Information Technology:
Research and Education (ITRE-04), pages 59–63,
2004.
[28] Y. Yang, J. Hu, and D. Chen. Research on driving
knowledge expert system of distributed vehicle driving
simulator. In 11th International Conference on
Computer Supported Cooperative Work in Design(CSCWD 2007), pages 693–697, 2007.
[29] A.-U.-H. Yasar, Y. Berbers, D. Preuveneers, andA. Jameel. A computational analysis of driving
variations on distributed multiuser driving simulators.
In Proceedings of the 19th IASTED International
Conference on Modelling and Simulation, MS ’08,
pages 178–186. ACTA Press, 2008.