Horizon.KOM: A First Step Towards an Open Vehicular Horizon

Provider

Daniel Burgstahler, Christoph Peusens, Doreen Boehnstedt and Ralf Steinmetz

Multimedia Communications Lab (KOM), Technische Universit

at Darmstadt, Darmstadt, Germany

Keywords:

ADASIS, Electronic Horizon, Most Probable Path, Tree-structure, Horizon Size Determination, Trafﬁc

Information, Open Street Map.

Abstract:

Modern vehicles are commonly equipped with several sensors to gather information about the direct environ-

ment. Due to the physical limitation of these sensors, the detection range and ﬁeld of view are limited to the

direct vicinity. This limits the functionality of driver assistance systems. A way to overcome this issue is to

use digital road maps to generate a so called electronic horizon as virtual sensor about the environment ahead.

All known electronic horizon providers are closed source and owned by companies. In the work at hand we

present our concept of an electronic horizon provider that we have published as open source.

1 INTRODUCTION

Modern vehicles are equipped more and more with

assistance systems to increase comfort, economy and

safety. These systems are based on sensors that ob-

serve the vehicle’s environment. However, all sensors

are limited in terms of sensing range and view an-

gle. The environment behind other objects, as well

as in a larger distance is commonly not visible. De-

veloping new applications, serving advanced tasks

in a more complex environment, raises the desire

of an extended view. The Adaptive Front Lighting

(AFL) (Durekovic et al., 2011) can serve as example.

It adjusts the headlight alignment to achieve an opti-

mal illumination of the road. Assuming knowledge

about the road geometry, algorithms can be applied

to determine vehicle parameters and settings, which

lead to a decreasing energy consumption while main-

taining the same overall speed and comfort. A com-

mon technology to provide an extended view is to use

a so-called electronic horizon (eHorizon), that pro-

vides information about the road network ahead of

a vehicle. An according illustration is given in Fig-

ure 1. It enables applications to perceive the road

geometry, including additional information, with an

increased range and ﬁeld of view. However, to the

best of our knowledge all existing implementation for

such a eHorizon provider are closed source and part of

comercial products. We have developed a model that

extracts relevant road information from a digital map

and provides those to other applications. We name

Figure 1: Example illustrating the eHorizon.

our solution Horizon.KOM and provide the source

code to the community. We will start with a short

introduction of the ADASIS speciﬁcation, which is

used for the standardized distribution of road infor-

mation via a vehicle on board data bus. Afterwards

we will compose our model including several com-

ponents such as the dynamic data storage, data pro-

cessing, and most probable path prediction. The pur-

pose and tasks of each module will be explained in

detail supported by visual examples. At the end of

this paper we will prove the feasibility of our model

by introducing a prototype implementation using an

android operated mobile device and road maps from

the OpenStreetMap project.

2 RELATED WORK

As mentioned before we make use the ADASIS speci-

ﬁcation (Ress et al., 2005; Ress et al., 2008), in partic-

ular version 2. It was designed for Advanced Driver

Assistance Systems (ADAS) in order to transmit rel-

Burgstahler, D., Peusens, C., Boehnstedt, D. and Steinmetz, R.

Horizon.KOM: A First Step Towards an Open Vehicular Horizon Provider.

In Proceedings of the International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2016), pages 79-84

ISBN: 978-989-758-185-4

Figure 2: Schematic illustration of the dynamic data management structure.

evant road information via a vehicle data bus. In this

manner our Horizon.KOM will be considered as an

ADAS eHorizon provider, and connected clients will

be denoted as ADAS application.

• The ADAS Horizon knows the vehicles current

position, velocity and driving direction. It also has

access to at least one digital road map. Using this

information, the ADAS Horizon will construct a

digital eHorizon holding all relevant information

about the road network ahead of the vehicle.

• An ADAS Application can decode and recon-

struct the transmitted eHorizon, by implementing

a so called ADASIS Reconstructor. This enables

the application to use information about the road

network ahead of the vehicle without the con-

straint of implementing its own eHorizon based

on a locally stored digital road map.

ADASISv2 supports 4 different modes of operation

determining the amount of data which will be trans-

fered. Mode 0 only transmits data about the Most

Probable Path. Information regarding alternative

routes or intersections along this path is excluded.

Mode 1 adds additional data about the so-called Stubs

along the MPP. Stubs denote intersections, including

ﬁrst curvature values. Mode 2 extends mode 1 by

adding information about intersecting road segments

along the MPP, excluding second level intersections.

Mode 3 considers the entire road network and has no

restrictions in therms of maximum levels and inter-

sections. Each road segment is represented as a one

dimensional line and is free of absolute geographical

coordinates. Each segment representation has a ﬁxed

length and includes curvature values, denoted with

offset values from zero to segment length, to preserve

the road shape information. The maximum length of

each segment is given by 8190m (13 Bit). A road seg-

ment from the digital map exceeding this maximum

length has to be split. The current position of the vehi-

cle is given by an offset value along the currently used

road segment. Similar notation applies to all values

that are bound to an ﬁxed geographical position. On

the provider side two parameters determine the eHori-

zon size. A value for the Maximum Length of Trans-

mitted Path gives a maximum offset threshold, a value

for Current Length of Transmitted Path describes the

maximum offset of data that has already been sent.

ADASISv2 incorporates 7 message types which are

used to operate the data transmission. The POSITION

Message is used to distribute the vehicles current po-

sition and velocity. It includes a reference to the cur-

rently used road segment. Using the SEGMENT Mes-

sage, information about road segments are transmit-

ted, including the road type, speed limits or other at-

tributes. STUB Messages are sent to provide infor-

mation about intersections and connecting road seg-

ments. The PROFILE Message is used to deﬁne the

proﬁle type of a segment, which can either be discrete,

linear or non-linear. The ATTACHMENT Message

contains information about special elements of the

road network like trafﬁc sings or trafﬁc lights. Used

settings like the operating mode, used units or version

number of the ADAS Horizon Provider are distributed

by using the META-DATA Message. Each message

is only sent once by the ADAS Horizon Provider,

except if an ADAS application requests a retrans-

mission by sending a RETRANSMISSION-REQUEST

Message. More detailed information about the ADA-

SISv2 speciﬁcation can be found in (Ress et al.,

2005) (Ress et al., 2008). For data storage of dig-

ital road maps, different formates have been devel-

oped for different purposes. For plain data stor-

age or archiving, formats like the Geographic Data

File (GDF) (Volker, Walter, 1996) or the german

Amtliches Topologisches Kartographisches Informa-

tionssystem (ATKI) (Volker, Walter, 1996) are used.

The OpenStreetMap project has developed its own

OSM-XML format, that is based on an XML-structure

which has no restrictions in therms of extensions.The

GDF, ATKI and OSM-XML formats all store data in a

serial manner, which is very costly in terms of search-

VEHITS 2016 - International Conference on Vehicle Technology and Intelligent Transport Systems

Figure 3: Movement within the current tree structure.

Passed nodes are neglected.

ing for a speciﬁc element. Therefore, road maps used

for runtime applications are commonly compiled to a

binary format to reduce storage requirements and in-

crease data access speeds. However, binary formates

are not designed for updates later on. Another im-

portant topic is Map-Matching that becomes impor-

tant for every mobile application that makes uses of

digital road map data. Map-Matching describes the

action of mapping the vehicles geographical position

onto the map and determining the currently used road

segment. Several algorithms to solve this task have

been published in literature. Kim et al. (Kim et al.,

1996) presented already in 1996 a light weight ap-

proach of mapping positions to the closest point on

the map. However, in order to achieve overall good

mapping results, the algorithm has to compensate in-

accuracies and variations in positioning data. Quddus

et al. (Quddus et al., 2003) introduced in 2003 a more

advanced and accurate approach, that uses the recent

position history and dead reckoning to identify the po-

sition of the vehicle on a map. Dead reckoning uses

other sensor data like steering angle and vehicle ve-

locity to calculate deltas in the position. It is also used

to keep up navigation, if for a short period of time no

satellite position signal is received, e.g. while driv-

ing through a tunnel. Several other approaches, serv-

ing various requirements can be found in literature.

For geographical location determination, we consider

Global Positioning System (GPS), which can achieve

an accuracy around 1 to 3 meter for civil services, by

use of the European Geostationary Navigation Over-

lay Service (EGNOS) or Wide Area Augmentation

System (WAAS). An important source for informa-

tion about the current trafﬁc situation are Trafﬁc and

Travel Information (TTI), which are also supported

conceptually within Horizon.KOM.

3 MODEL

The model of Horizon.KOM is depicted in Figure 2.

It is based on dynamic and static data provided by

the vehicle’s sensors and external sources. Dynamic

data varies over time and includes the geographic po-

sition as well as trafﬁc information. Additional data

from the vehicle is also provided via the internal data

Figure 4: Further movement within the tree structure.

Adding new nodes to the tree structure.

bus. Digital map data is assumed to be mostly static.

Horizon.KOM is basically composed of six compo-

nents. The Tree-Structure (I) is used to store the road

segments located ahead of the vehicle including their

characteristics and additional information. This is a

central element that combines all other components

and further is used as interface to ADASIS. The size

of the vehicles eHorizon, which effects the number of

nodes (road segments) stored at the Tree-Structure is

deﬁned by the eHorizon Size Determination (II) and is

a function of the vehicle’s velocity. A predicted route,

which the vehicle most likely will take, is deﬁned by

the Most Probable Path (MPP)(III). It has an impor-

tant inﬂuence on the shape and the size of the vehi-

cles eHorizon area. Based on this eHorizon area and

information provided by a digital map, the Dynamic

Road Administration (IV) component deﬁnes the data

that is stored in the Tree-Structure. The Map Match-

ing (V) component keeps track and enriches the Tree-

Structure of the vehicles current position. Using the

Trafﬁc Data Manager (VI) the Tree-Structure is ex-

tended by external Trafﬁc Data Information along the

eHorizon. These components are explained in more

detail in the following.

(I) Tree-Structure: A basic component of the vehi-

cle’s eHorizon is the digital road map. In order to

enable a cost efﬁcient deﬁnition of the vehicles eHori-

zon in terms of computational power, the network of

road segments that is mapped on this eHorizon has

to be stored efﬁciently. Therefore we propose a tree-

based data structure to store road segments that are

ahead of the vehicle. Due to this Tree-Structure, the

map is easily extensible and allows a fast adaption of

new road segments or other entities. The currently

used road segment is represented by the root of the

tree. Each connecting road segment is linked to this

root node and thus mapped as a second-tier node to

the Tree-Structure. This is a multi-tier representation

and in general road segments are accessible from the

segment a tier above. Road intersections are repre-

sented by connections between nodes of different tier

levels. The driving direction of the vehicle is used

to exclude road segments from the Tree-Structure that

have already been passed. In order to limit the number

of nodes within the Tree-Structure, we limit the num-

ber of maximum tiers along the Most Probable Path

Horizon.KOM: A First Step Towards an Open Vehicular Horizon Provider

(MPP) and limit the size of the covered geographi-

cal area. Thus, leaves of the tree represent either a

dead end or a road that continues beyond the eHori-

zon area. The Tree-Structure is updates each time the

vehicle moves onto another road segment. Then this

segment becomes the root node. If the vehicle passes

an intersection, all passed segments are marked as not

accessible but remain in the Tree-Structure until the

next update. An example if given in ﬁgure 3, here

the vehicle has passed road segment 2 and nodes 2,

3 and 4 remain in the Tree-Structure marked as not

accessible. As soon as the vehicle moves onto a new

segment, the Tree-Structure is updated and the new

segment becomes the root node. The Tree-Structure

has now to be reordered and all nodes that are only

connected to the old root node are removed. New

road segments are added accordingly to the eHorizon

size as explained before. An example if given in ﬁg-

ure 4, here segment 5 becomes the new root node and

nodes 2, 3, 4, and 9 vanish by removing node 1 and,

node 14 is added. Although node 7 has left the eHori-

zon area, it will remain in the Tree-Structure, due to

the existing possibility of entering the eHorizon area

again. To store road segments as node, we use a linear

space representation, i.e., a linear line with a deﬁned

length, that provides an additional simpliﬁcation and

reduction of overhead. This notation is related to the

segment representation of the ADASIS speciﬁcation

and provides an easy data exchange between ADASIS

and the Tree-Structure. Therefore, the natural shape

of a segment deﬁned by its intermediate points (ab-

solute coordinates) is removed. To compensate the

information loss, the natural shape is translated into

a list of curvature values that are distributed along

the segment, denoted with offset values. All location

depending information, including the current vehicle

position, is deﬁned by an offset value starting from

the beginning of the road segment and is stored inside

each node. Each node contains at minimum informa-

tion about its length, road type, and curvature values.

Additional information of any type can be stored in a

similar manner.

(II) eHorizon Size Determination: The size of the

eHorizon deﬁnes which nodes are stored in the Tree-

Structure. We have to limit the size of this eHorizon

due to limited resources in terms of processing power

and storage space. Moreover, a dynamic size of the

eHorizon is required in order to cope with different

application scenarios. A vehicle driving with high

speed, e.g., on a highway, needs an eHorizon of sev-

eral kilometers ahead. However, considering urban

areas, a smaler eHorizon is feasible. We propose two

different approaches to deﬁne the size of the eHori-

zon based on the vehicles context. (I) By identifying

the context of the vehicle, with respect of the road

type (e.g. city, highway, ...) an appropriate eHorizon

can be deﬁned. (II) We can deﬁne the eHorizon as a

function of the vehicle velocity. An increased veloc-

ity indicates road types such as a highway. However,

we need to consider a temporary reduced speed due to

characteristics of the route or trafﬁc jams on the high-

way, leading to a very low velocity. In the following

we consider the vehicle velocity to deﬁne the size of

the eHorizon due to the fact that semantic description

of the road types may not always be provided by dig-

ital maps. The maximum radius of the eHorizon is

deﬁned by the vehicle velocity (v) and the parameter

d as shown in Equation 1. The parameter d can be

used to adapt the overall size of the eHorizon.

Max

eHorizon,d

= e

log

(v)∗d

(1)

However, the size of the eHorizon is further inﬂu-

enced by four adaptations. (I) As mentioned before,

reducing the vehicle’s speed would result in a reduced

vehicles eHorizon. We will not truncate the tree-

structure due to the reduced speed, but new nodes will

only be added based on the new reduced size of the

eHorizon. (II) The depth of the tree has to be lim-

ited, i.e., to limit the number n of tier-levels. On a

highway a very large eHorizon is necessary due to

vehicle velocity. On an exit toward a city the vehi-

cle is still on a highway but the MPP goes toward an

urban area that would cause in a high overhead, espe-

cially if the vehicle is not exiting exiting the highway.

Thus the tier-levels have to be limited. (III) More-

over, we have to handle nodes that are located within

the eHorizon, but are not accessible via a route stored

in the tree-structure. We assume that these nodes will

not be added to the tree-structure, due to the miss-

ing accessibility in terms of our current tree-structure

state. Road segment 11 in Figure 3 illustrates such

a scenario. (IV) The last adaptation is the inﬂuence

of the MPP. By predicting the route with the highest

probability the respective path nodes can be included

with a higher priority. Therefore, the MPP is stored

with an increased level of detail and with an increased

number of tier-levels. This adaptation will result in an

more elongated vehicle eHorizon.

(III) Most Probable Path: In the previous sections,

we deﬁned a system that is able to map all relevant

road segments, including any related data, within a

speciﬁc distance efﬁciently in a tree based structure.

In the following the model is extended by a mech-

anism that predicts the MPP the vehicle will most

likely use. In order to predict the MPP, knowledge

about the vehicles ﬁnal destination is not mandatory

and can therefore be assumed as not given. We further

assume an inﬁnite route which is only limited by the

size of the eHorizon. Thus there will always be a suc-

VEHITS 2016 - International Conference on Vehicle Technology and Intelligent Transport Systems

Figure 5: Example for the probability distribution of the

previously introduced scenario.

cessor node, and therefore one of the child nodes will

be the next root node. Moreover, we assume the ab-

solute vehicle position as not necessary, since the root

node and vehicle offset, stored in the Tree-Structure,

provide sufﬁcient information. As already deﬁned, all

child nodes of a parent node are located in driving di-

rection of the vehicle and denote the set of available

successor road segments. A probability distribution is

assigned to each set of available successor nodes, as-

sociated the respective parent node. The probability

value of each node is based on a predeﬁned distribu-

tion table, which holds values for any kind of inter-

section, road type, and road class combination. The

table can be adapted individually based on statistical

data. An improvement of the table can be achieved

by searching and evaluating regularly driven routes,

e.g., the drivers route between home and workplace.

Figure 5 shows an example probability distribution of

the previously introduced scenario. The vehicle is ap-

proaching intersection S1. With a probability of 70%

the vehicle will continue on road segment no. 1 and

it will turn into the connecting segment no. 2 (side

road) with a probability of 30%. At intersection S2

two options exist (segments 5 & 9), both of the same

road class and thus denoted with 50%. This leads

to a value of 35% in the overall probability distribu-

tion of available successor nodes. Figure 6 depicts

on the left side the probability distribution inside the

Tree-Structure. The right side depicts the exclusion of

passed nodes. When the vehicle is approaching an in-

tersection, indicators like turning signals, the vehicles

speed proﬁle, steering wheel position, and as well the

currently selected lane, are used to enhance the MPP.

The vehicle is approaching intersection S2 with turn-

ing signals set and decreasing velocity (v). We have

to differentiate between ambiguous and unambiguous

probability distribution. If the road segment the ve-

hicle will turn into is vague, ambiguous probability

distribution is used. Thus the MPP can only be de-

termined by the values of the predeﬁned distribution

table. In contrast, an unambiguous probability distri-

bution provides a high probability that the next road

segment can be predicted correctly. This is the case

if the previously mentioned indicators are used. The

MPP can be extracted by traversing the Tree-Structure

Figure 6: Example for the probability distribution according

to introduced scenario.

along the highest probabilities of each child node.

(IV) Dynamic Road Administration: The Dynamic

Road Administration ﬁlls the Tree-Structure with data

and maintains its up-to-dateness as iterative process.

Furthermore, it is used to enrich the data with addi-

tional information that is not part of the digital map,

if available. The basic concept is in a ﬁrst step to de-

termine all road segments that are located the vehi-

cle driving direction and that are within the eHorizon

area according to the eHorizon Size Determination.

We assume that the minimum Tree-Structure always

contains a valid root node. At the very ﬁrst, the root

node will be determined by the Map Matching in an

initial process. Next, the Dynamic Road Administra-

tion loads all remaining road segments from the digi-

tal map and stores them in the Tree-Structure. During

movement the component continuously traverses the

Tree-Structure to determine and add missing road seg-

ments. The processing of each road segment contains

a transformation into linear space and computation of

additional information.

(V) Map Matching: The position is provided by a

GNSS system, e.g. GPS, but with limited accuracy.

A Map Matching component can compensate this by

mapping the vehicle onto a known road network. Sev-

eral algorithms are known in literature to minimize

the chance of mismatching. For this the recent po-

sition history and dead reckoning is used. We rec-

ommend to use the algorithm introduced by Quddus

et al. (Quddus et al., 2003), that is also used in our

prototype implementation. The matching of geo po-

sition and the driven distance L is combined to deter-

mine the vehicles current offset. The Map Matching

component fulﬁlls several tasks. First of all it updates

the root node with the vehicle offset, i.e., the trans-

lation of the geographical position into a segment re-

lated value. It is also responsible to ﬁnd and deﬁne

the ﬁrst root node when the model is initialized and,

therefore, the tree-structure is still empty. Further-

more it detects a vehicles road segment transition and

updates the current root node with the respective suc-

cessor node.

(VI) Trafﬁc Data Manager: The Trafﬁc and Travel

Information (TTI) is stored separately from the Tree-

Structure. The main responsibility of the Trafﬁc Data

Horizon.KOM: A First Step Towards an Open Vehicular Horizon Provider

Manager, is to sort, ﬁlter and prioritize incommoding

trafﬁc information as well as to provide a link between

the stored trafﬁc records and the road segments of the

Tree-Structure. A trafﬁc record can be linked to more

than one road segment and even effect an entire geo-

graphical area. The separation is intended to reduce a

additional computation and storage overhead.

4 IMPLEMENTATION

The prototype implementation of our model is an An-

droid project and makes use of maps from the Open-

StreetMap project. The implementation has some ab-

stractions to reduce complexity. Due to the imple-

mentation on a mobile device, we have to cope with

the absence of data telemetry, provided by the ve-

hicle. Thus we simulate turning signals by imple-

menting two buttons indicating an according behav-

ior. We have implemented an own road map database

including a lightweight interface using SQLite. For

Map-Matching we have implemented an approach ac-

cording to Quddus et al. (Quddus et al., 2003). Due

to the absence of vehicle telemetry, we have applied

a simpliﬁed algorithm to determine the MPP. It is

assumed, that the vehicle will continue traveling on

the currently selected road segment with a probabil-

ity of 100%, if no signal indicator is applied. The

Android application consists of two views. The ﬁrst

view shows several information regarding the Map

Matching and size of the eHorizon. The second view

depicts, on top of a map visualization, the currently

loaded eHorizon as blue paths, the predicted MPP

marked as red paths, the current position marked by a

red dot. The eHorizon Size Determination, Dynamic

Road Administration, Most Probable Path and Map-

Matching are implemented as Android Service. Each

of these services operates in parallel with access to

the Tree-Structure, that is incorporated into the An-

droid Application Layer.

5 SUMMARY AND SOURCES

In this paper we have introduced our eHorizon

software prototype. In summary, our model of the

eHorizon provides a well suited data storage model in

form of a Tree-Structure to natively and dynamically

store the required road information. The presented

eHorizon Size Determination provides the current

eHorizon size with respect to several scenarios

regarding the vehicles velocity v and driving envi-

ronment, i.e., street type or urban area. We also have

provisioned a method to predict and incorporate the

MPP, including the learning of frequently used routes

and runtime probability adaption. The choice of the

Navigation Data Standard (NDS), accessing at least

one digital map, ensures a future interoperability

with other applications. To enrich the electronic

eHorizon data, we also have incorporated Trafﬁc

and Travel Information (TTI) into our model. The

holistic module-based approach provides the freedom

of extending our eHorizon and apply adjustments

to fulﬁll individual requirements. Furthermore, the

majority of the introduced tasks are designed to be

executed in parallel. We did several experiments to

prove the functionality of our model. In a next step

we plan a performance evaluation and a transfer into

a universal Java library to be used easily on other

platforms. The source code of our prototype is avail-

able under Apache 2.0 open source license on our

website: http://www.kom.tu-darmstadt.de/ research-

results/ software-downloads/software/horizonkom/.

Furthermore we are currently working on extensions

and improvements and will continuously update the

available implementation.

REFERENCES

Durekovic et al. (2011). Architectures of Map-Supported

ADAS. In Intelligent Vehicles Symposium (IV), 2011

IEEE, pages 207–211. NAVTEQ.

Kim, J., JH, L., TH, K., WY, L., and YG, K. (1996). Node

based map matching algorithm for car navigation sys-

tem. In International Symposium on Automotive Tech-

nology & Automation (29th: 1996: Florence, Italy).

Quddus, M., Ochieng, W. Y., Zhao, L., and Noland, R.

(2003). A general map matching algorithm for trans-

port telematics applications. GPS Solutions, 7:157–

167.

Ress, C., Balzer, D., Bracht, A., Durekovic, S., and

owenau, J. (2008). ADASIS Protocol for Advanced

in-vehicle Applications. In ITS World Congress. New

York.

Ress, C., Etemad, A., Kuck, D., and Boerger, M. (2005).

Electronic Horizon - Supporting ADAS Applications

with Predictive Map Data. In ITS European Congress,

Hannover, Germany-TS, volume 18.

Volker, Walter (1996). Zuordnung von Rraumbezogenen

Daten – am Beispiel der Datenmodelle ATKIS und

GDF. PhD thesis, Univerity Stuttgart.

VEHITS 2016 - International Conference on Vehicle Technology and Intelligent Transport Systems