Electronic Horizon - Providing Digital Map Data for

ADAS Applications

Christian Ress, Aria Etemad, Detlef Kuck and Julián Requejo

Ford Research & Advanced Engineering Europe

Suesterfeldstr. 200, 52072 Aachen, Germany

Abstract. The number of vehicle navigation devices has increased tremen-

dously during the last years. The digital maps of these systems contain a lot of

valuable information that provides benefit for other features besides route guid-

ance as well. The area of potential applications reaches from driver information

and warning up-to comfort and active safety applications, so-called ADAS

Since built-in sensors are limited to a relatively short range, digital map data

can be used to "look" much further into the direction of the vehicle's path. The

map data, e.g. road geometry, number of lanes, speed limits, etc. is provided on

a vehicle bus system as the so-called Electronic Horizon. European automotive

industry has teamed up in the ADASIS Forum to develop a common standard-

ized interface to access the Electronic Horizon. Ford Research & Advanced

Engineering Europe has developed a prototype system for Lane Keeping Assis-

tance as one application example.

1 Introduction

Nowadays, modern vehicles are equipped with a variety of sensors to enable safety

and comfort features. However, these on-board sensors are limited to a relatively

short range of a few hundred meters. On the other hand, digital maps of a navigation

system contain valuable information about the road segments lying ahead, such as

road geometry, functional road class, number of lanes, speed limits, traffic signs, etc.

This data can be extracted and provided to applications as the so-called Electronic

Horizon. This virtual sensor is now able to provide information within an extended

range, see Figure 1. Thus it enables the vehicle to prepare earlier for an up-coming

situation.

Fig. 1. Range of vehicle sensors.

Advanced Driver Assistance Systems

Ress C., Etemad A., Kuck D. and Requejo J. (2008).

Electronic Horizon - Providing Digital Map Data for ADAS Applications.

In Proceedings of the 2nd International Workshop on Intelligent Vehicle Control Systems, pages 40-49

 SciTePress

2 Overview

The support of ADAS requires an accurate knowledge about the road ahead of the

vehicle. Since the last years, map vendors already have significantly improved the

level of detail and accuracy of digitised data. Up-to-date digital navigation maps

contain detailed information about road geometry, topology, and typical attributes

such as functional road class, number of lanes, speed limits, traffic signs, etc. Future

maps will support even more details depending on the requirements demanded by the

automotive industry to support ADAS.

The so-called Electronic Horizon contains road attributes from the digital map as

well as vehicle position data. Fig. 2 gives an overview about the principle. The Navi-

gation system, or more generally the Electronic Horizon Provider, extracts map data

in the vicinity of the vehicle position. All relevant attributes required by applications

are extracted and stored locally. The prediction of the Most Likely Path, which the

vehicle is expected to take, has a significant influence on the quality and reliability of

the Electronic Horizon. Ford Research and Advanced Engineering has developed

algorithms for calculating the Most Likely Path based on historic information and

current vehicle status [2]. The Electronic Horizon is provided to applications on the

vehicle's bus system, most likely the CAN bus. The specification of the interface

between Electronic Horizon Provider and applications is of special interest for the

vehicle manufacturer. In order to reduce development cost and risk, a standardized

interface is highly appreciated. As a result of this need, the European ADASIS Forum

was launched in the year 2001. Section 4 outlines the interface specification and

ADASIS Forum activities.

Fig. 2. Electronic Horizon.

3 Electronic Horizon Provider

Ford Research & Advanced Engineering has developed a prototype system to provide

an Electronic Horizon, the so-called Information Manager [1] [3]. The system has

been implemented as a prototype and integrated into test vehicles. The system does

not only provide vehicle position and digital map data, but also predicts the Most

Likely Path of the vehicle [2]. Fig. 3 gives an overview about the systems architec-

ture. The entire system is designed in a modular way, allowing a maximum of flexi-

bility and providing the opportunity to enhance and modify due to future require-

ments.

...

Power

Supply

Mgt.

Electr.

System

Control

Application

ADAS

application

...

Information Manager

Application

Interface

Input

Interface

Electronic Horizon

Past Experience Processing

EH Post-

Processing

Vehicle Route Prediction

Information

DriverDriver

GPS DataGPS Data

Sensor

Information

and Switch

Positions

Sensor

Information

and Switch

Positions

Data Store

Information Manager

Fig. 3. Systems architecture of Ford's Electronic Horizon Provider (Information Manager).

The following paragraphs introduce the Information Manager in more detail.

3.1 Electronic Horizon & EH Post Processing

The "heart" of the system is a module that retrieves a configurable number of attrib-

utes from the digital map in the vicinity of the vehicle (the so-called Electronic Hori-

zon module, EH). In a first step, the road segments for all possible paths are extracted

from the map in the vicinity of the vehicle. Therefore the current vehicle position is

estimated by a GPS receiver, and then matched on a road segment. The quality of the

Electronic Horizon obviously depends on the correct estimation of the vehicle's path.

If the road attributes would be provided for a path the vehicle does not take, the in-

formation will be worthless for the application and will cause a re-calculation of the

Electronic Horizon. That would consume processing power and time leading to a gap

of input data on the application side. In order to avoid re-calculations and to ensure

proper operation of the system, the module receives information about the Most

Likely Path of the vehicle from Vehicle Route Prediction [2]. The EH module then

extracts all relevant attributes attached to the road segments only for this single path.

The pre-processed Electronic Horizon is filtered in a second step, the EH Post

Processing, due to the requirements of the supported applications. The EH Post Proc-

essing includes also demonstration software to visualize the Electronic Horizon as

shown in Fig. 4. The module can be enhanced with additional sub-modules, e.g. a

speed estimator that is calculating a predicted speed profile for the road segments

ahead of the vehicle.

Fig. 4. Visualization of Electronic Horizon.

The calculated Electronic Horizon is then transferred to the Data Store.

3.2 Data Store

The Data Store is the common database of the system, which stores all data required

by the applications as well as needed internally for the Past Experience Processing.

Incoming data is received from the EH Post Processing as well as vehicle sensor data

from the Input Interface. Data is then provided to the Application Interface as well as

to the Past Experience Processing modules.

3.3 Input/ Output Interfaces

The Application Interface provides all data for any connected application in a speci-

fied format. The Application Interface supports the ADASIS protocol as described in

section 4.2. At the moment, the Application Interface is implemented for the CAN

bus only. However, other bus systems can be integrated easily by adding the adequate

software.

The Input Interface manages all input data for the Information Manager. This in-

cludes vehicle sensor data, switch positions and other data available on the vehicle

bus system as well as GPS position data. In addition, a driver identification mecha-

nism is used, allowing the system to behave differently depending on the current

driver. This information is needed by the Past Experience Processing and the Route

Prediction modules.

3.4 Past Experience Processing

The Past Experience Processing stores the route currently driven by the vehicle,

which is subsequently used by the Route Prediction module.

The Past Experience Processing contains a database for storing the collected in-

formation, building the basic step for a learning system. This database stores all trip

data on segment by segment basis. That is while driving, all road geometry data is

broken up into road segments as stored in the digital map. Along with coordinates or

keys that allow identifying the segments later, additionally time, date and other data is

stored as needed by other supported applications. Fig. 5 illustrates how the map data-

base stores geometry information by splitting up the road network into segments and

nodes. When driving to a destination the Past Experience Database receives the se-

quence of segments. For convenience, the system can either store the whole trip as

that sequence or store only the transitions, which are consecutive segment pairs,

where the second is always a successor to the first along with the time and date.

These segment pairs are also called decision points.

Fig. 5. Storing transitions while driving.

In order to optimize the memory usage, data is stored with an expiration time-

stamp. Once the past experience data reaches a specified age, the affected records are

deleted. The memory management can further be improved by limiting the amount of

stored data. Instead of keeping track of complete routes, only the segments that build

a so-called decision point are considered (see above). During testing, it has been

estimated that 3 -5 Mbytes of storage capacity will be sufficient for achieving a high

prediction quality. This amount of memory would allow storing all routes driven by a

typical driver during a period of three years.

Additionally, other data might be stored as well, in order to generate profiles and

history of vehicle data. For instance, individual travel times can be recorded per each

link. This information is then taken into account for future route calculations allowing

to calculate an optimum route based on real-world travel times. Nowadays navigation

systems only use static values based on the functional road class not matching reality

e.g. in terms of traffic jams during rush hours.

3.5 Vehicle Route Prediction

The Vehicle Route Prediction module is responsible for determining the most prob-

able route the vehicle is likely to go. Therefore, a two-way approach is used [2]. First,

data from the vehicle's bus system is analyzed to determine a categorized driving

situation. For instance, if the vehicle approaches a crossing, the system has to decide

which way the driver intends to go. Taking into account turn signal information in

combination with the current vehicle speed and distance to the decision point, an

intelligent algorithm proposes the way of the vehicle at this crossing.

In a second step, a complete route can be proposed by taking into account the cur-

rently driven road segments and comparing these to the stored routes in the Past Ex-

perience Processing database. Particular patterns, which occur in a defined accumula-

tion, are compared and used as a decision criterion for determining which route the

driver intends to take. In order to optimize processing effort and memory usage no

complete routes are compared. Instead only decision points are taken into account, as

described in section 3.4, containing the succeeding segment for the one currently

driving on. For each successor segment a specific probability is calculated based on

the amount of occurrences, day-of-week and time-of-day when driven before. The

algorithm chooses the segment with the highest probability as the Most Likely Path.

The estimated Most Likely Path of the vehicle is then provided to the Electronic

Horizon module, which uses this information for retrieving a single-path Electronic

Horizon, as described above.

4 Interface Specification

A well-defined interface between navigation system providing Electronic Horizon

and applications is required. Vehicle manufacturers have a strong interest in using a

standard interface specification. In order to develop such a standard interface the

ADASIS Forum was founded. The following paragraphs introduce the forum itself

and its technical approach.

4.1 ADASIS Forum

In 2001 the ADASIS Forum has been launched in Europe in order to specify an in-

dustry standard interface for providing Electronic Horizon. Ford Motor Company is

playing an active role within that forum and contributing to the interface specifica-

tion. Since December 2007, Ford has taken over the chairmanship of the forum (C.

Ress).

The ADASIS Forum is hosted and coordinated by ERTICO

and constitutes to

date of more than 30 members including car manufacturers, navigation systems and

ADAS suppliers, as well as digital map vendors. The forum's purpose is to:

• Define an open standardised data model and structure to represent map data in

the vicinity of the vehicle position (i.e. the Electronic Horizon), in which map data is

delivered by a navigation system or a general map data server.

• Define an open standardised API to enable ADAS applications to access the

Electronic Horizon and position-related data of the vehicle.

The final specification is currently worked out in the ADASIS Forum and will be

transmitted as a next step to ISO for becoming an international industry standard. The

first version of the interface specification is already available for forum's members.

During the period from 2004 to beginning of 2008, the successful work of the

ADASIS Forum has been supported within the PReVENT project, i.e.

MAPS&ADAS sub-project. The objectives for MAPS&ADAS project were to

specify, implement, test, and validate the first version of ADASIS specification.

Additionally, the development of new digital maps including safety aspects was also

a goal of the project.

ADAS-

application

AHP

ADAS

Horizon

Provider

data filter &

data store

manager

Horizon

Store

Bus

Interface

API

positioning

matching

1D - view

extract local horizon from

complete map base

copy of local horizon

on application side

deliver app.-specific

1D-track preview

map

Fig. 6. ADASIS systems architecture.

European ITS organization

4.2 ADASIS Functional Architecture

The systems architecture defined by ADASIS Forum is shown in Figure 6. It consists

of the ADAS Horizon Provider (AHP) on the one side. That retrieves digital map data

around the estimated position of the vehicle using GPS and map matching. In the first

release of ADASIS only a single path in front of the vehicle is supported. Future

versions will also be capable of multiple paths where the ADAS Horizon is provided.

The data is then compressed and coded for transmission on the vehicle's bus system.

On the application side, an ADAS Horizon Reconstructor (AHR) re-builds the ADAS

Horizon from the received messages and provides it to the ADAS application. More

than one application is supported but depending on the implementation, each one

requires its own Horizon Reconstructor.

ADASIS addresses two interfaces on different levels:

(i) A "low level" interface describing the messages to be transferred on the vehicle

bus system. The ADASIS specification is generic for any bus system, the so-called

AGMP (ADASIS Generic Message Protocol). Since the CAN bus is the most used bus

system in vehicles nowadays, a specific implementation for CAN has been derived,

the so-called ASCP (ADASIS Specific CAN Protocol).

(ii) A "high level" interface allowing the applications to access the Electronic Ho-

rizon data after being re-built by the Horizon Reconstructor. This is a C code style

API.

The developed systems architecture and interface specifications have been imple-

mented as prototypes within the scope of PReVENT MAPS&ADAS by the project

partners. Data transmission has been realized on a CAN bus. Tests and validation

have been successfully been performed. The results look very promising: the average

additional bus load caused by the Electronic Horizon is relatively low on the CAN

bus (below 1 percent), and no latency issues or other negative effects for the CAN

bus messages have been detected. Different ADAS Horizon Providers and Recon-

structors have been developed by the project partners. These have been connected via

the CAN bus and their interoperability was also demonstrated successfully.

More information about the ADASIS Forum is available on the internet:

http://www.ertico.com/en/subprojects/adasis_forum.

5 Example Application: Lane Keeping Assistance

One of the applications, which have successfully been enhanced by the Information

Manager, is Lane Keeping Assistance. A prototype system has been implemented and

validated within the scope of the European PReVENT project. PReVENT is an indus-

try research project, co-funded by European Commission within the 6th Framework,

and has been successfully finalized in March 2008. More information about the PRe-

VENT project is available on the PReVENT web site: http://www.prevent-ip.org .

For Lane Keeping Assistance a camera system is used as the primary sensor to de-

tect if the vehicle is still within the lane. In order to support the image processing in

difficult situations, e.g. approaching a curve, driving in bad weather, or low light

conditions, Electronic Horizon data is taken into account as an additional virtual sen-

sor. This provides information about lane attributes and geometry of the road ahead.

In consequence this enables the lane tracker to evaluate more reliably if the vehicle is

still within the lane, or whether an action needs to be taken. This could then be done

in the form of a warning or by performing an active steering manoeuvre.

Fig. 7 shows an example of the benefit: ambiguous lane markings by shadows of

guardrails are not recognized correctly by the camera itself, see left picture. Using

lane width information from a digital map can help the lane tracker to exclude wrong

information and to detect the lane markings correctly, see right picture.

Fig. 7. Lane marking detection with camera only (left) and enhanced with Electronic Horizon

(right).

6 Summary and Perspectives

Nowadays navigation systems have the potential to offer much more than solely route

calculation and guidance. The digital map provides a lot of information about the

route lying ahead of the vehicle that can successfully be used to enable new or en-

hance existing applications, the so-called Electronic Horizon.

Ford Research & Advanced Engineering has successfully designed and imple-

mented a prototype system providing Electronic Horizon. It provides digital map data

as well as the vehicle's position and sensor data to ADAS applications. Special atten-

tion has been paid on the calculation of the Most Likely Path the vehicle is expected

to take. That allows a high quality of Electronic Horizon data and improves reliability

of applications.

As one example how an application can benefit of Electronic Horizon "Lane

Keeping Assistance" has been presented. Within the PREVENT project the lane

tracker algorithms have significantly been improved with the use of digital map data

as an additional "virtual sensor".

However for a series implementation of the system, some restrictions have to

overcome in the near future. For instance, the ADASIS specification has to be refined

with regard to the test experiences from PReVENT project. Also the Ford prototype

system is implemented on a PC with a relatively huge amount of memory and proc-

essing power, which has to be replaced by an Embedded Platform for future use in a

vehicle or to be integrated into the navigation system.

References

1. Ress, C., Etemad, A., Kuck, D., Boerger, M.: Electronic Horizon - Supporting ADAS

applications with predictive map data. Proceedings of ITS World Congress, London,

United Kingdom (2006)

2. Etemad, A., Ress, C., Boerger, M.: Generating accurate Most Likely Path data. Proceed-

ings of ITS World Congress, London, United Kingdom (2006)

3. Ress, C.: The potential of digital map data to enhance ADAS functions. Telematics Update

Magazine, Issue 40, First Conferences Ltd, London (2007)

4. Requejo, J, Ress, C., Etemad, A., Kuck, D.: Using Predictive Digital Map Data to Enhance

Vehicle Safety and Comfort. The Second International Workshop on Intelligent Vehicle

Control Systems, Madeira, Portugal (2008)