adasis protocol for advanced in-vehicle applicationsdurekovic.com/publications/documents/adasisv2...

- 1 -

ADASIS PROTOCOL

FOR ADVANCED IN-VEHICLE APPLICATIONS

Christian Ress

Ford Research & Advanced Engineering, 52078 Aachen, Germany

+49 241 9421 458, [email protected]

Dirk Balzer

Adam Opel GmbH

65423 Rüsselsheim, Germany


Alexander Bracht

Daimler AG, 71059 Sindelfingen, Germany

+49 7031 4389 559, [email protected],

Sinisa Durekovic

NAVTEQ, 65843 Sulzbach, Germany,


Jan Löwenau

BMW Group Forschung und Technik, 80992 Munich, Germany

+49 176 601 44993, [email protected]

on behalf of the ADASIS Forum.

ABSTRACT

Since navigation systems are increasingly entering the vehicle, the available map data may

not only be used for routing purposes but also to enable advanced in-vehicle applications. The

area of potential features reaches from headlight control up to active safety applications

(ADAS1). With the ongoing development of navigation based ADAS features the interface to

access the so-called ADAS Horizon is of rising importance. In order to specify an industry

standard interface for providing an ADAS Horizon the ADASIS2 Forum has been launched.

The Forum is hosted and coordinated by ERTICO3 and constitutes of more than 30 key

players of the automotive industry, including car manufacturers, navigation system and

ADAS suppliers, as well as digital map vendors. A first version of the ADASIS protocol

specification is already available and has been successfully tested and validated within the

PReVENT project. Based on this experience the ADASIS Forum members are currently

working on the next version of the protocol specifications. This paper outlines the ADASIS

concept and describes the basic principles of ADASIS v2. Finally it introduces an application

example: Adaptive Speed Recommendation.

1 Advanced Driver Assistance System(s)

2 Advanced Driver Assistance System Interface Specification

3 ERTICO - ITS in Europe

- 2 -

THE ADASIS FORUM

The ADASIS Forum was established in May 2001 by a group of car manufacturers, in-vehicle

system developers and map data companies with the primary goal of developing a

standardized map data interface between stored map data and ADAS applications. Main

objectives of the ADASIS Forum are:

• Define an open standardized data model and structure to represent map data in the vicinity

of the vehicle position (i.e. the ADAS Horizon), in which map data is delivered by a

navigation system or a general map data server.

• Define an open standardized interface specification to provide ADAS horizon data

(especially on a vehicle CAN bus) and enable ADAS applications to access the ADAS

Horizon and position-related data of the vehicle.

Following a period of one year, when preliminary requirements were established and a basic

working approach agreed, the ADASIS Forum was brought to ERTICO in June 2002 for

project management. Requirements have been worked out and specifications were developed

until end of 2003.

Beginning of 2004, a group of ADASIS members started working on the PReVENT

MAPS&ADAS project. In the scope of MAPS&ADAS, further details of the specification

have been worked out and multiple test implementations have been developed. Intensive tests

have been performed and the feasibility and interoperability of the concept have been proven.

Nevertheless also some shortcomings have been identified.

Since the end of the corresponding MAPS&ADAS work packages in 2006 the ADASIS

Forum now continues working as an open industry forum hosted by ERTICO. It consists of

more than 30 members from different sectors of the European automotive industry, i.e. car

manufacturers, navigation system and ADAS suppliers, as well as digital map vendors. In this

scope, an updated version of the CAN protocol specification has been developed (ADASIS v2)

which is presented in this paper.

ADAS HORIZON CONCEPT

The ADASIS Forum and respectively the PReVENT MAPS&ADAS project partners have

specified systems architecture as well as interfaces to extract and supply enhanced map data

to vehicle applications. Figure 1 gives an overview about the ADAS Horizon concept: Since

built-in vehicle sensors to capture the vehicle's environment are limited to a relatively short

range the available digital map data can be used as a virtual sensor to look more forward on

the path of the vehicle. The digital map contains attributes attached to the road segments, such

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

The “road ahead” concept is basically called Most Probable Path (or Most Likely Path)

derived from the ADAS Horizon. For each street segment, the probability of driving through

this segment is assigned and given by the ADASIS protocol. Figure 2 shows the Most

Probable Path in blue and possible alternative paths with lower priority in orange.

- 3 -

Figure 1 - ADAS Horizon overview

The map data is extracted by a so-called ADAS Horizon Provider and delivered on a vehicle

bus system (e.g. CAN). Therefore an ADASIS CAN protocol has been defined. The Horizon

data contains vehicle position data as well as road segment attributes from the map. On the

receiver side a Horizon Reconstructor is decoding the bus messages and stores the data.

Figure 2 - ADAS Horizon (orange) & Most Probable Path (blue)

ADASIS PROTOCOL 2ND VERSION

The ADASIS Forum and the PReVENT MAPS&ADAS project have developed a first

version of interface specification (ADASIS v1) to predict the road geometry with its related

attributes ahead of a vehicle based on the vehicle's position and a digital map. This

specification has been prototypically implemented on a CAN bus by several partners and the

performance and interoperability of the implementations have been successfully tested. The

ADASIS concept has proven to be technically feasible.

However, the ADASIS interface has not been implemented in the series product environment

of an OEM yet. On the contrary, more and more company specific solutions evolve on the

market and threaten the success of the ADASIS standardization approach. The ADASIS

Forum has discussed this development and the possible reasons. Among other company

internal reasons, one major argument not to use ADASIS is that the concept is rather

- 4 -

complex. The multiple path prediction and the transport protocol require a rather high effort to

implement an ADAS Horizon Provider and an ADAS Horizon Reconstructor in series

production. With high focus on a minimized busload only relative data should be transmitted

which creates a low data load on the bus as well as low efforts on the reconstruction side.

Therefore the ADASIS Forum is currently developing a specification of a simplified ADAS

horizon based on a single path concept: ADASIS v2. A single path concept extended by

intersection stubs or selected alternative paths is seen as appropriate for most applications that

are currently ready for series implementation.

Main entities in general architecture of a map-based ADAS application (see Figure 3) are:

• ADASIS Horizon Provider (AHP) which generates ADAS Horizon and messages that will

be sent to ADAS applications.

• ADASIS v2 Protocol that defines how ADAS Horizon will be sent to ADAS

Applications.

• CAN Bus is expected the transport layer for ADAS v2 Protocol.

• ADAS Application reconstructs and uses ADAS Horizon.

ADAS Horizon

Provider

(AHP)

ADAS Horizon

Provider

SVDO

ADAS Horizon

Provider

Bosch

ADAS Horizon

Provider

NAVIGON

ADAS v2 Horizon

Provider

ADAS Application

#3

ADAS Application

#1

ADAS Application

#2

CAN Bus

AD

AS

IS v

2A

DA

SIS

v2

AD

AS

IS v

2

AD

AS

IS v

2

Figure 3 - Map-based ADAS Systems Architecture

ADAS Horizon Concept

Characteristics of both protocols are summarized in Table 1, but the main difference between

ADASIS v1 and ADASIS v2 is the way how the ADAS Horizon is represented in the

protocol. ADASIS v1 transfers LINKs and CONNECTIONs as building elements of the

ADAS Horizon network. It is up to the client to interpret those entities in order to construct

paths that the vehicle may drive. Main logical entity used in ADASIS v2 protocol is a PATH.

A PATH is described with STUB, which specifies connection point between PATHs, and

SEGMENT that describes a part of the PATH. As consequence of this approach, the ADASIS

v2 Reconstructor for an ADAS Application can be realized much simpler.

- 5 -

ADASIS v1

(MAPS & ADAS)

ADASIS v2

Transport

Concept

Network Paths

CAN Identifiers

used

2-11 2-6

CAN

multiplexing

Required Optional

CAN

Error Detection

Yes Yes

CAN

Error Recovery

No Yes

(bi-directional communication

required)

CAN Robustness:

Consequence of

lost CAN frame

Potentially all following frames

are invalid

Missing part of data;

does not affect other frames

Attachments 1. Traffic Signs Up to 262,143

Profiles 1. Speed Restriction (5-bit)

2. Heading Change (8-bit)

3. Curvature (8- or 12- bit)

4. Slope (10-bit)

5. Number of Lanes (3-bit,

driving direction only)

Up to 62 different types

(9- or 29-bit values)

Traffic Signs 63 variants 131,072 variants

(part of Attachment id space)

Shape Points Native, optional As Profiles, optional

Slopes Singe Interpolation type Arbitrary Interpolations

(as separate Profile Type)

Heading Change Singe Interpolation type Arbitrary Interpolations


Curvatures Singe Interpolation type Arbitrary Interpolations


Table 1 - ADASIS v1 vs. ADASIS v2

Position of events along the PATH, i.e. PROFILEs and ATTACHMENTs, are expressed only

in terms of Path Index and Path Offset, see Figure 4. Because of communication channel

limits, the Path Offset is limited to a 13-bit value. Therefore, the client must take care to

calculate properly the current offset.

0(=8192)

6144 2048

Path Coordinate Value Range

4096

out of rangeobsolete

8192(= 0)

Figure 4 - Vehicle Position and Attribute Changes along Path

ADASIS v2 is capable to support different geometries of the provided ADAS Horizon, i.e.

Single or Multiple Path Horizon (see Figure 5 and Figure 6). The easiest ADAS horizon is

provided only along one most probable path (MPP). That is probably already sufficient for a

- 6 -

wide range of applications. Attached to the MPP, intersection stubs representing the

connected roads can be transmitted that carry basic information like turn angle or road class

(Figure 5).

However, if additional alternative paths are required, these can optionally be attached to the

MPP and are coded with the same path coordinate and offset value concept as outlined above.

Alternative paths start as stubs from the MPP (Figure 6).

As a further extension, also the alternative paths can carry stub information and those stubs

can again be starting points of alternatives of higher degrees (not shown in figures).

Messages

There are three types of messages defined for ADASIS v2:

• Current Vehicle Position: includes Vehicle Position, Map Matching Quality, Vehicle

Speed, etc.;

• ADAS Horizon Information: contains attributes along the most probable path or

additional alternative paths;

• Meta Data: contains general information about map version, interface version, country

code, etc.

Stub 1Offset 230

Stub 3

Offset 270

Stub 2Offset 270

Stub 4Offset 320

Most Probable Path

Alternative Path 1

Alternative Path 3

Alternative Path 2

Alternative Path 4

Most Probable Path

Figure 5 - Single Path ADAS Horizon with Stubs

Figure 6 - Multi Path ADAS Horizon

- 7 -

Those messages are sent by the ADAS Horizon Provider to all clients (Figure 3). The first

three bits of each message is a cyclic message counter for the specific message type. It can be

used to detect missing frames on the client side. The horizon sender can optionally repeat

messages if there will be spare bandwidth. This allows the receiver to close any potential

gaps.

Repeated messages are marked with a special "retransmission" flag. The receiver can

optionally initiate a retransmission of lost message. This bi-directional communication is not

mandatory but an option to ensure robustness of the system.

Another flexible option of ADASIS v2 is the support of multiplexing. No polymorphic CAN

frames are required, but multiplexing can be used optionally, e.g. in case CAN identifiers are

only very limited.

The following messages are defined and will be introduced in order by priority in the next

paragraphs.

POSITION Message

The POSITION message describes the current position of the vehicle in terms of Path Index

and Offset along the path. Table 2 shows the bit fields of the POSITION message:

Field Description

Message Type Identifies type of message.

Cyclic Counter Cyclic counter of this message type: Reconstructor can use

this value to detect missing messages.

Retransmission If true, this message was sent already at least once before.

Path Index Index of current path: If this number differs from one

specified in previous POSITION message, vehicle left

original path and data regarding all other paths are obsolete.

Position Offset Offset of current position from the start point modulo 8191.

Position Index If AHP supports positioning alternatives, contains index of

this Position Candidate. Candidate 0 is always most

probable position candidate, candidate 1 second etc.

If AHP does not support positioning alternatives, it will be

always 0.

Position Age Age of the position relative to timestamp of last received

GPS message.

If the message is re-transmitted, value from original

message will be increased by delay between transmissions.

Speed Speed of the vehicle projected to the link.

Relative Heading Heading relative to link.

Position Probability Probability indicator.

Position Confidence Position confidence: this field contains AHP specific

values.

Current Lane Index of current lane.

Reserved Spare field to match CAN frame size.

Table 2 - POSITION message

- 8 -

SEGMENT Message

The SEGMENT message specifies most important characteristics of a segment. Each Path

consists of one or more non-overlapping segments; the position of the segment in the path is

defined by start Offset. Table 3 shows the bit fields of SEGMENT message:

Field Description





Path Index Value is Index of the path, which this segment is part of.

Offset Offset of this segment from start position modulo 8191.

Functional Class Functional road class (map vendor specific).

Route Type Type of route, according to GDF 3.0 specification.

Form of Way Form of way, according to GDF 3.0 specification.

Effective Speed Limit Current Speed Limit: May be implicit (e.g. in cities), or

explicit. Current time of day, day of week and weather

conditions are taken in account by Horizon Provider in

determining effective speed limit.

May be expressed as kph or mph, see META-DATA

message.

Effective Speed Limit Type Describes what kind of Speed Limit is in effect.

Number of lanes in driving

direction

Number of lanes in driving direction: also implies driving

direction.

Number of lanes in opposite

direction

Number of lanes in opposite direction: also implies driving

direction.

Tunnel Indicates if segment is part of a tunnel.

Bridge Indicates if segment is part of a bridge.

Divided Road Indicates if segment is part of a divided road.

Build-up Area Indicates if segment is part of a build-up area.

Part of Calculated Route Indicates if segment is part of a calculated route.

Emergency Lane Indicates if an emergency lane is available.

Complex Intersection Indicates if segment is part of a complex intersection.

Reserved Spare bit field to match CAN frame size

Table 3 - SEGMENT message

STUB Message

The STUB message describes a crossing on the Most-Probable-Path. Each stub is the origin

for a new path getting its own path number (Figure 5). Additional SEGMENT and other

messages contain characteristics of the new path. Table 4 shows the bit fields of STUB

message.

- 9 -

Field Description





Path Index This is the index of the parent path.

Offset Offset of the position of the crossing from the start path

position modulo 8191.

Sub-Path Index This is the index of the new path.

Turn Angle Angle between path and stub road: 0 for straight-ahead, 90

degrees for perfect turn right, 270 degrees for perfect turn

left.

Relative Probability Relative probability of the path on the crossing: The

probability of the continuation of the path at an intersection

can be calculated as 100 – sum (probability of all stubs).

Route Type Type of route, according to GDF 3.0 specification.

Form of Way Form of way, according to GDF 3.0 specification.

Number of lanes in driving

direction

Number of lanes in driving direction: Also implies driving

direction.

Number of lanes in opposite

direction

Number of lanes in opposite direction: Also implies driving

direction.

Priority Maneuver Priority of maneuver.

Complex Intersection Indicates if stub is part of a complex intersection.

Right of Way None/ Right-of-way/ Give-way/ Undefined

Reserved Spare bit field to match CAN frame size.

Table 4 - STUB message

3.2.4 PROFILE Message

The Path Profile is a property that has a value for any location along a path (e.g. curvature,

form of way, number of lanes, speed limit, and horizontal geometry). A Path Profile is made

up of a quantity of so called Profile Spots and the specification of a Profile Interpolation Type

that is used to estimate profile values between profile spots. As there is a plurality of

possibilities to describe a profile as a function of arc length, the Path Interpolation Type

specifies how the profile value is to be calculated from the Profile Spots at intermediate

locations using some interpolation scheme (e.g., discrete step-profile, linear or higher order

interpolation, etc.).

Figure 7 shows the key definitions involved in path profile representations, together with

visualized examples for different Profile Interpolation Types.

• Profile Type is the property which the profile shall represent.

• Profile Interpolation Type is a code specifying how intermediate profile values are to be

calculated. The following Profile Interpolation Types are identified by now:

o Discrete interpolation profile (zero order): The profile is specified by the set of

locations of attribute changes together with the new value, valid for the track

section until the following.

- 10 -

Figure 7 - Multi Path ADAS Horizon with Alternative Paths

o Linear interpolation profile (first order): The profile is specified by a set of

locations together with the attribute value at the location, where the value must be

linearly interpolated between the given locations. (Note that the polygonal 2D

representation of the map geometry is a first order profile, since the geometry

between the shape points is calculated by linear interpolation of latitude/longitude

values).

o Higher order interpolation profile (quadratic / cubic polynomial, spline, etc.): The

profile is specified by a set of locations with defined sets of attribute values at the

locations. The interpolation algorithm to be used to calculate the profile value

between the given locations must be specified. (Note that this may be done by

using the extended set of coordinates plus attributes from the two neighboring

points and/or additionally use values from second-degree neighbors).

• Path Location is a position along a path, defined by its distance from the path origin,

measured as the arc length along the path.

• Profile Spot is the numeric description value of a property at a Path Location (note that

this may be a single value pk, representing the property value itself (at Path Location k).

Depending on the interpolation type, a Profile Spot may also be defined as a vector

containing several values (including e.g., first or second derivatives or longitude and

latitude coordinates) necessary for smooth curve representation (e.g., for polynomial or

spline interpolations).

The PROFILE Message describes 1-dimensional characteristics of the path. The message

contains two 10-bit Profile Spots or one 29-bit. Interpretation of spot values as well as profile

interpolation between spot values depends of actual Profile Type. For parts of paths where

profile is not defined, default value is assumed (also defined by Profile Type). Table 5 shows

the bit fields of PROFILE message.

- 11 -

Field Description





Path Index Index of the path where this profile(s) is located.

Offset Offset of position of the first profile spot from start

position modulo 8191.

Profile Type Type of the Profile.

Control Point If true, values in this message specifies additional control

points required for certain interpolation types;

if false, actual profile values are specified.

Long Value If false, two 10-bit profile spots are specified in the

message.

If true, one 29-bit profile spot is defined. 29-bit value is

represented as concatenation of fields Value 0, Distance 1

and Value 1.

Value 0 Profile value at Offset.

Distance 1 Distance from first profile spot to the second one.

If 0, no other profile values are defined in this message.

Value 1 Profile value at Offset+Distance1 or least significant 10 bit

of 29-bit profile value at Offset.

Accuracy Class See ADASIS Specification Part 1, Section 4.2.2 Accuracy

Classes.

Reserved Spare bit field to match CAN frame size.

Table 5 - PROFILE message

ATTACHMENT Message

The ATTACHMENT Message describes 0-dimensional characteristics of the path. A Path

Attachments is the specification of an entity (e.g. speed bump, speed sign) with its Path

Location, i.e. the Path it is attached to and the distance along the path from the Path Origin to

where it occurs. A Path Attachment may be described by properties, represented by a set of

values. Offsets of up to two 18-bit attachments are defined in this message. Please note that

up to 262,143 attachment types can be defined. Table 6 shows the bit fields of this message.

Field Description


Cyclic Counter Cyclic counter of this message type. Reconstructor can use



Path Index Index of the path where this attachment(s) is located.

Offset Offset of position of the first attachment from path origin

modulo 8191.

Attachment Type 0 Type of attachment.

Attachment Type 1 Type of attachment.

Reserved Spare to match CAN frame size.

Table 6 - ATTACHMENT message

- 12 -

META-DATA Message

The META-DATA Message contains utility data and is sent with low frequency. It describes

basic characteristics of the system. Table 7 shows the bit fields of META-DATA message.

Field Description


Cyclic Counter Cyclic counter of this message type. Reconstructor can use



Country Code ISO 3166-1 country code.

Region Code For a given Country Code, specifies region of a country.

Driving Side 0 stands for Driving Side Left.

1 stands for Driving Side Right.

Speed Units 0 stands for miles/hour.

1 stands for kilometers/hour.

Protocol Version (Major) Major protocol version.

Protocol Version (Minor) Minor protocol version.

For instance, for protocol version 0.15 Major Protocol

Version will be 0 and Minor Protocol Version 15.

Hardware Version ADAS Horizon Provider specific.

Map Provider Map Provider of current area.

Please note if the whole map may be partitioned into parts

that can be released on different times or even by different

providers. In that case, value if this field may vary between

messages.

Map Version (Year) Content of this field is Year of release of map of current

area. For 2007, this field will contain value 7.




messages.

Map Version (Year Quarter) Content of this field is Year quarter of release of map of

current area.




messages.

Horizon Provider Capabilities Content of this field is ADASIS v2 Horizon Provider

capabilities.

Horizon Provider Mode Horizon provider mode:

• 0: Most-Probable Path only (Figure 5)

• 1: Most-Probable Path with Stubs (Figure 5)

• 2: Most-Probable Path with main sub-paths (Figure 6)

• 3: Full Horizon (Figure 6)


Table 7 -META-DATA message

- 13 -

RETRANSMISSION-REQUEST Message

The RETRANSMISSION-REQUEST message is optional and it can be sent by the client to

the Horizon Provider requesting retransmission of a specified message. For Error Detection

and Recovery the 3-bit Cyclic Counter, that is part of each message, can be used by the

Horizon Reconstructor for detecting missing frames. In case missing frame will be detected,

the Reconstructor becomes aware that no data is available for the part of the path, but since

there is no dependency between messages, it can continue to work without interruptions. In

addition, the client may request re-transmission of the message. Table 8 shows the bit fields

of the RETRANSMISSION-REQUEST message:

Field Description

Message Identifier CAN message identifier of lost message.

If this value is equal to 0, client request resend of the

complete ADAS Horizon.


Last Counter Value Counter value of last received message of that type.

Message Re-transmission

Request Counter

Number of already sent re-transmission request for this

particular message.

Retransmission Request

Counter

Total number of re-transmission requests.


Table 8 - RETRANSMISSION-REQUEST message

EXAMPLE APPLICATION: ADAPTIVE SPEED RECOMMENDATION

The application “Adaptive Speed Recommendation” (ASR) is a typical example of ADAS

applications whose usability heavily depends upon the correctness of the map data. The

Adaptive Speed Recommendation Info function provides additional, detailed information on

the stretch of road the driver is currently covering. To provide this helpful support, a traffic

sign graphics in the instrument cluster – head up display and navigation display - in the

cockpit informs the driver of the speed limit at his current location (see Figure 8). ASR has

been realized as a prototype by ADASIS Forum member BMW.

Figure 8 - BMW Vehicle using ADASIS Protocol

- 14 -

Adaptive Speed Recommendation is extended with Map Deviation Detection, Reporting and

Dynamic Map Update capabilities and it is now active part of the ADSIS protocol chain.

ASR Method

To calculate recommended speed at each moment, the following road characteristics are taken

in account:

• Curves

• Legal Speed Limits

• Crossings

• Roundabouts

As such, ASR system combines Curve Information, Speed Limit Information and Crossing

Information ADAS functions into one application. ASR will warn the user of the need to slow

down before the vehicle reaches the point where speed must be reduced. For instance, the

ASR may display the information about speed limit 50-300 meters ahead of the actual Speed

Limit traffic sign. The exact distance depends of the several factors such as Current vehicle

speed, Vehicle braking acceleration (deceleration), Driver reaction time, etc. Of course, if the

system calculates that present speed does not violate current or future legal speed limit, no

information will be shown.

The special care is taken to properly calculate the maximum allowed speed on the curves.

Current curve radius data from the vector map database is not always precise enough. In

addition, speed in the curve will depend of many other factors as well: number of lanes, width

of the road, overall road surface condition etc. While algorithm will calculate allowed curve

speed based on the available curve radius, all other relevant road attributes from the vector

map database will be used to increase or decrease that estimate (see Figure 9).

Sharp Right Curve

Ahead

Slow down to 85 km/h!

Your curve speed is

ok, but there is

60 km/h speed limit

ahead!

Figure 9 - Information inside the BMW Vehicle

- 15 -

The ASR system will monitor actual driven curve speed, compare this value with previously

calculated recommended speed and use that data in the calculation of the speed

recommendation for the next curve. In other words, system will learn from the driver to offset

the vector map data inaccuracies and road characteristics not present in the database (most

important: road surface condition).

ACKNOWLEDGEMENTS

The European ADASIS Forum consists of currently 30 members from the automotive

industry and is coordinated by ERTICO. Further information is available on the internet:

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

PReVENT was an Integrated Research project funded by the European Commission within

the 6th Framework with participation of 52 partners from Automotive OEMs, suppliers,

research institutes, public authorities and associations. Additional information is available on

the projects's website:

PReVENT: http://www.prevent-ip.org

MAPS&ADAS: http://www.prevent-ip.org/en/prevent_subprojects/horizontal_activities/maps__adas

adasis protocol for advanced in-vehicle applicationsdurekovic.com/publications/documents/adasisv2...

Documents