Drive
The DemonstRator for Intelligent Vehicular Environments
(DRIVE) is the testbed developed by Telefónica I+D for proof-of-concept
demonstration and experimental validation of advanced vehicular communications
and services. In line with the experimental environment of the European
CVIS
project, DRIVE consists of the following elements: the in-vehicle context,
the wireless access network, the operator network and the service infrastructure.
Fig. 1. Logical architecture of DRIVE’s elements
The in-vehicle context is composed of the user terminal, and optionally
mobile/nomadic devices belonging to the driver and/or passengers in the
vehicle. The user terminal is a logical entity that hosts the On-Board
Unit (OBU, integrating the communications manager and interfaces), Application
Unit (AU, integrating the service platform and vehicular applications,
and Human-Machine Interface [HMI] manager) and the user interaction subsystems
(e.g., a display for the Graphical User Interface [GUI]). This user terminal
can be implemented in different, combinable scenarios, namely:
• The dedicated scenario, where the terminal is a (set of)
embedded or brought-in device(s). Fig. 1 illustrates this scenario, which
is further detailed below in this page.
• The nomadic scenario, where the user terminal is a nomadic
device, e.g., a mobile phone, an ultra-mobile PC or a multimedia internet
device that, when in the vehicle, is used as the OBU, AU and HMI elements.
Examples of the dedicated scenario are in-car telematics systems, which
host the OBU, AU and HMI elements, e.g., BMW’s Connected Drive or General
Motors’ OnStar, and aftermarket equipment such as portable navigation
devices (mainly AU and HMI). We are starting to see devices interworking
with existing systems in the vehicle, e.g., mobile phones BT-connected
with the car’s on-board computer (OBC), or the combination of the OBC
and the future eCall box, which is expected to be implemented as an in-vehicle
communications module with GPS and Global System for Mobile communication
(GSM) technologies. Note that the mobile/nomadic devices interwork with
the user terminal using V2U communications, i.e., forming an in-vehicle
wireless network, in the same way regardless of whether this terminal
is implemented in the dedicated or nomadic scenario.
The wireless access network is the VANET, where V2V and V2R communications
take place (see Fig. 1). Note that for the case of V2I, this network is
only used when accessing the Internet through a roadside access point
(RSU), as f urther dtailed below in this page. Else, the cellullar network
infrastructure is used. The operator network (Fig. 1) hosts the management,
security and accouting elements necessary for DRIVE’s advanced vehicular
communications and services. Finally, the service infrastructure includes
the service-related subsystems not included in the operator network, e.g.,
service aggregation and brokers, illustrated in Fig. 1 under the generic
name of ‘Service backoffice’. Note that the operator network and service
infrastructure are described in DRIVE’s WEEDEV
2008 paper and will not be discussed any further here.
DRIVE is similar to the CVIS
platform in terms of conception and core technologies, and provides
three additional innovations: the approach towards the user terminal,
which can be mobile, nomadic, aftermarket or embedded, or a combination
of these; the extensive use of the capabilities and design of new enablers
of the IP Multimedia Subsystem ( IMS) applied to the vehicular environment;
and the implementation of a multimodal, priority-aware HMI manager. These
innovations, along with the developments in vehicular communications and
services, make DRIVE a unique experimental environment.
User terminal for the dedicated implementation scenario
In DRIVE’s dedicated implementation scenario, the user terminal is composed
of the AU and OBU subsystems, which are interconnected through an Ethernet
data link, and a multimodal HMI consisting of a GUI, voice interaction
by the user through the vehicle’s audio system, and haptic interaction.
Fig. 2 illustrates DRIVE’s in-vehicle integration of the AU and OBU as
aftermarket devices, as well as the mentioned HMI elements, where the
haptic interaction is achieved using a steering wheel pad emulator (labelled
as ‘3’ in Fig. 2).
The AU hosts the execution environment of the vehicular services, and
encompasses the modules ‘HMI Manager’, ‘OSGi service platform’ (including
priority management) and ‘App. i’ (vehicular applications) in Fig. 1.
These modules, which are part of the Telefónica In-Car Box (TICBox®),
are based on OSGi technology and run on a specific Open Embedded Linux
operating system (OS) distribution called Telefónica Linux (TELINX®).
The OBU hosts the CALM-compliant vehicular communications manager (‘ComMgr’
in Fig. 1), which handles internal and external connectivity in the vehicle
according to the Always Best Connected philosophy in a seamless, transparent
both to the user and the applications, and according to priority management
in the AU. The OBU auses the TELINX® OS with specific adaptations.
Fig. 2. In-vehicle integration of the user terminal in the
dedicated scenario.
In terms of hardware, the AU is based on an industrial embedded computer
by Advantech ARK-3383 (labelled as ‘6.1’ in Fig. 2), which features a
fanless ULV Celeron M 1-GHz processor, 1-GB RAM memory, a number of I/O
ports, 1-GB industrial CompactFlash disk, 80 GB hard disk, integrated
graphics, AC97 stereo sound and a rugged, compact aluminum chassis. The
periphericals connected to the ARK are illustrated in Fig. 2. The OBU
is composed of a PC-Engines ALIX 2C2 motherboard (labelled as ‘7.1’ in
Fig. 2) with an AMD 500Mz processor, 256 MB RAM, 1GB CompactFlash disk,
two 5 dBi omnidirectional external antennas, a Garmin G18 USB GPS receiver
and an aluminium case. The communications modules of the OBU are: a USB-connected
BT module for V2U and sensors (e.g., accelerometer for crash detection,
labelled as ‘9’ in Fig. 2), two mini-PCI-connected Ubiquiti ShortRange2
802.11b/g radio modules for V2U and V2R (Internet access), and a USB-connected
MTX-H25 High-Speed Downlink Packet Access (HSDPA) industrial modem for
V2I. Until pluggable 802.11p modules are commercially available, we are
using the V2R-based ‘Internet’ 802.11b/g interface for V2V and safety-related
V2R communications as well. Note that currently no dedicated SRC interface
(Fig. 1) is integrated in DRIVE’s OBU (Fig. 3) due to the lack of legacy
ITS services in the testbed, e.g., electronic toll collection.
Roadside infrastructure for the wireless access network
We expect the future roadside infrastructure to provide V2R communications
not only for safety and Real-time Traffic Information (RTI) services but
also Internet access to user terminals by means of RSUs. RSUs will be
installed along the roads and will be connected to one another and to
the service infrastructure through a backbone network, e.g., fiber optics
or radio links. Fig. 3 depicts the RSU deployment in the DRIVE testbed,
which is located around the Telefónica I+D’s building in Madrid and emulates
a semi-urban scenario.
Fig. 3. Roadside deployment in DRIVE
In DRIVE, each RSU hosts a communications manager similar to the OBU in
the in-vehicle context, a RTI application and a management agent. These
software elements run on the TELINX® OS with specific adaptations. In
terms of hardware, DRIVE’s RSUs are rugged outdoor equipment with IP67
rating composed of a PC-Engines ALIX 2C2 motherboard with an AMD 500Mz
processor, 256 MB RAM, 1GB CompactFlash disk, an Ubiquiti ShortRange2
802.11b/g mini-PCI radio module, a rugged outdoor aluminium enclosure
with a waterproof N-type antenna, a waterproof Ethernet RJ-45 interface
and a 8.5 dBi 2.4 GHz omnidirectional outdoor antenna. The RSUs are interconnected
through an Ethernet data link emulating the backbone network. As with
the OBU, due to unavailability of 802.11p interfaces, safety-related V2R
communications also use 802.11b/g, which in the future will be used for
commercial applications and Internet access via V2R only. Currently, DRIVE’s
RSUs broadcast safety messages received from a central server to vehicles
in their coverage area, and also act as roadside access points to connect
to the Internet.