; MAPS _ ADAS Validating the ADAS Interface using Active Cruise Control
Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

MAPS _ ADAS Validating the ADAS Interface using Active Cruise Control


  • pg 1
									13th World Congress on ITS, 8-12 October 2006, London                                     Paper 1683

                                           MAPS & ADAS

      Validating the ADAS Interface using Active Cruise Control

                        J. Loewenau1, A. Vogt1, W. Richter2, C. Urbanczik2
                                L. Beuk3, R. Pichler4, S. Durekovic5
                     BMW Group Research and Technology, 80992 Munich, Germany
                          BMW Group Development, 80788 Munich, Germany
                          Siemens VDO Trading B.V., Eindhoven, Netherlands
                                      Siemens PSE, Linz, Austria
                                     NAVTEQ, Sulzbach, Germany

                              Phone +49 89 382 44993, Fax +49 89 382 66423
                               jan.loewenau@bmw.de, www.bmwgroup.com

This paper shows the results of the implementation and validation of the MAPS&ADAS interface for a precision
navigation in ACC. Some improvements and additions to the protocol are described. The paper explains further
how driver assistance systems, using ACC as an example, can take advantage of navigation data. The operational
concept of the assistance function has to be designed according to the particular properties of this additional data
source. Even with the quality of navigation data available today, BMW’s ACC system can be enhanced by
dynamics, which adapt to the situation, providing even more benefit for the customer. Furthermore,
considerations and a comparison of the BMW protocol with the MAPS&ADAS protocol are given.

The ADAS Interface and protocol developed, tested and validated within MAPS&ADAS will be further
developed and improved by the ADASIS Forum and its 30 Members from vehicle manufacturers, ADAS
suppliers, navigation system suppliers and map providers.

MAPS&ADAS at a Glance
MAPS&ADAS (start February 2004, duration 3 years) is a sub-project of the Integrated Project (IP) Preventive
Safety (PReVENT), funded by the European Commission. The MAPS&ADAS subproject seeks to develop and
validate both appropriate methods for the collection and maintenance of safety content to be integrated into
safety-enhanced in-vehicle digital maps and related changes of the standardized exchange format (GDF) to be
used in Advanced Driver Assistance Systems (ADAS) and Navigation Applications, as well as a standard
interface from navigation systems or general positioning and map systems towards ADAS that make use of map
data for track preview purposes.
The MAPS&ADAS Consortium comprises the following partners: ERTICO (project coordinator), BMW,
DaimlerChrysler, Ford, Volvo Tech, Blaupunkt, NAVIGON, Siemens VDO, NAVTEQ, Tele Atlas, Lower
Saxony, TRANSVER and Hanover University. Further Information is given at http://www.prevent-
ip.org/maps_adas (see Ref. [1] and [2]).

The development of ADAS and, more generally, of in-vehicle ITS applications which support the driver in
driving safely, comfortably and economically, are of major importance to the automotive industry. Typical
examples of ADAS applications are Active Cruise Control (ACC), Adaptive Light Control (ALC) or Dynamic
Pass Prediction [3]. ADAS currently perform their function on the basis of information generated by sensors
observing the vehicle’s environment. There is a significant potential for the use of a digital map and the vehicle’s
position to predict the road geometry and to track related attributes ahead of the vehicle. ADAS applications can
benefit from this potential, and new functionality may likely be enabled. In particular, ADAS applications will
use map data for recognizing road infrastructure conditions at the vehicle’s current position and for a preview
along the track ahead (see Figure 1).

                                 Figure 1 - ADAS interface and ADAS horizon

First approaches of map-supported ADAS entering the market are currently using the vehicle’s navigation system
as the map data source for this preview with a proprietary interface [4]. The advantages of using the navigation
system are that it already has a stored record of the map data, and it already performs the tasks of vehicle
positioning and map matching. These functions can readily be used also for the ADAS preview. However, each
navigation system stores map data in a system-specific format, and uses its own version of vehicle positioning
and map matching. Moreover, when tailored to single ADAS applications, the variety of different map interfaces
may expand even more – not only due to different data sources, but also due to application-specific differences.
By standardizing access to the map data, irrespective of the data provider and physical storage format, and by
standardizing the way that position and track ahead information is presented to the applications, ADAS software
can focus on performing its main task without having to deal with the complexities of map representation (see
Ref. [5] and [6]).
Typically an ADAS application will only use a small map extract around the current vehicle position. This
ADAS-specific map extract is called the ADAS horizon (AH). It is expected that the navigation system supplier
will add a module to the navigation system that extracts the ADAS horizon data from the map and sends it across
the ADAS-Interface as shown in the architecture Figure 2.
The MAPS&ADAS project aims to standardize
    •    a Logical Data Model and Data Dictionary to describe the ADAS horizon
    •    a protocol to send the ADAS horizon incrementally on a vehicle bus
    •    an API to access the ADAS horizon
The concept of ADAS in the PReVENT project will be a major focal point of the EU research program. ADAS
applications help to reduce high workloads on the driver and mitigate the consequences of specific driver
deficiencies. Several sensors are used to determine the driving situation. However, because of the limitations of
these sensors, driver assistance functions at best possess only part of the information needed to describe the
whole situation. Consequently, the driver will always experience a deficit in the expectations if the subjectively
perceived information does not correspond to the full picture of the driving environment. The map preview can
act as an additional sensor that will enhance the assessment of the situation of the vehicle.

                                                             Interface                       API

                         positioning               AHP                     data filter &
                             &                     ADAS                     data store                     ADAS-
                          matching                Horizon                    manager                     application

                                                                                                   1D - view


                                extract local horizon from               copy of local horizon     deliver app.-specific
                                   complete map base                      on application side       1D-track preview

         Figure 2 - Transformation and flow of map data from source via bus towards application

The MAPS&ADAS results presented here consist of two main items: the current BMW series integration and
implementation issues of the ADAS standard protocol. The following sections describe the current integration in
BMW 5 Series and the implementation setup with the foreseen benefits of the MAPS&ADAS framework.

Current integration in BMW 5 Series
System Architecture
During the BMW 5 Series development a first step was made on the basis of the already available map and
navigation data in order to improve the performance of the ACC [4]. This solution is available on the market
since March 2005 in BMW 5 and 6 Series. With this solution also any other ADAS client within the BMW 5
Series car can be served. In the following the current BMW realisation of an ADAS protocol is described.

Like all other possible receivers of the ADAS messages ACC is located on the PT-CAN of the vehicle, whereas
the navigation system has connections to the MOST-bus and K-CAN. This results in the following
communication path and shows the possible complexity of a MAPS&ADAS system (see Figure 3).

                           Figure 3 - Communication path of the BMW ACC system

BMW Communication Concept and System Integration
For the original navigation functions such as route planning, reports and turning indications, the vehicle' current
                                                                            map            .
position needs to be related to a stored map. This comparison is called ' matching'It supplies most of the
navigation data required by the ACC functions, and also keeps additional navigation system costs within limits.
Nevertheless, there are a few conditions that need to be taken into account with regard to the navigation interface.

Navigation systems in today’s vehicle concepts are typically located near the vehicle' communication, audio and
multimedia functions. For this reason there can be a long way, in terms of onboard network topology, to the
navigation data users such as the active cruise control. If the communication path leads from the navigation

system to the ACC via several gateways, then on the one hand the communication load must be matched to the
weakest bus, and on the other hand the system must be in a position to recognize delays or to compensate for
them more effectively, Figure 3.

To avoid high bus load no redundant data will be sent. The ADAS protocol makes a distinction between
synchronous and asynchronous data. Synchronous, i.e., periodic data are only used to produce a relative link to
an already asynchronous prediction transmitted on demand.

After the ADAS block within the navigation system has created the ADAS data, the ADAS data output from the
navigation system has to pass several gateways: MOST-CAN Gateway and K-CAN – PT-CAN Gateway. In total
5 different messages containing ADAS content are transmitted either periodically or event triggered.
With the content of these messages the ACC is able to reconstruct the ADAS horizon. Figure 4 shows the
reconstructed ADAS horizon with some listed attributes:

                                     Figure 4 – ADAS horizon (BMW)

Based on the BMW experience with introducing an ADAS protocol into series production, a standardized ADAS
protocol has at least to meet following main requirements and take into account several limiting factors:

    •   Error recovery and diagnosis is necessary, realised in the BMW protocol with two way communication
        The ADAS horizon must be designed in a way that all possible routes of the vehicle are covered,
        independent from the planned route.
    •   The Messages and the communication process must be testable with independently developed standard
    •   The amount of the messages and bus load must be independent from quality and coverage of the map
    •   Any kind of ADAS protocol must fit to the OEM network design and interface design policies.

To use this experience in the best way possible for the development of the ADAS standard protocol, the first
protoytype of this standard will be implemented within a BMW 5 Series vehicle. This prototype will enable
comparison with the existing BMW protocol, a check of consistency with BMW vehicle network and valuable
input for the further refinement of the MAPS&ADAS standard.

Using Map in ACC
BMW offers assistance functions such as ACC, for current vehicle models. ACC supports the driver by
eliminating the need to make monotonous fine adjustments to the driving distance from preceding vehicles.
BMW achieves this by automating sub-functions within the speed and distance control. Further assistance
functions concerning lateral guidance will follow at a later stage.

              Figure 5 - Drivers View                                                   ACC View

In this context navigation systems and their associated databases can be seen as additional forward-looking
environment sensors, which make part of the missing information available. The geometry of the road surface
and other information about the road, such as its type and the number of lanes or restrictions, results in an
estimation of the driving environment. This gives rise to opportunities for optimizing the driver assistance
functions by using ACC as an example (Figure 5).

ACC systems receive information from long-range sensors about the position and movement of objects on the
road in a relatively narrow field of view of approx. ± 4° to ± 8° over a distance of about 150 meters ahead, see
Figure 6.

                            Figure 6 - ACC function enhanced by navigation data

If a vehicle equipped with ACC follows a vehicle in front in the same lane, then this is the main feature of the
driving situation. The distance control is targeted at this vehicle. The data available on the position and
movement of the vehicle in front allow it to be followed conveniently in a way that satisfies the driver’s

With the rapid further development of data quality and the degree of coverage achieved by navigation system
databases, precise prediction of the track of the road will be possible in the medium-term. In the future, further
functions can be built up on this basis. However, even without precise descriptions of bends in the road, already
considerable improvements can be achieved by making use of currently available data sources. The basis for this

is structural information, classification of bends and attributive road data such as the type of road or number of
lanes. From these data smart functions have been developed, which influence both the layout of the control
dynamic and the recognition of traffic objects.

However, after identifying a simple situation such as changing to a clear lane poses the question of the correct
system reaction. The system has to adjust the driver’s desired speed, which was typically pre-selected to be
higher than the speed maintained when following the vehicle in front. In this case, what is the correct rate of

Current ACC systems always have to work with a compromise layout, which is acceptable in different situations,
because information on the current driving environment, such as the type of road or its course is missing. The
driver, on the other hand, obviously includes this information in his own decision-making. For example,
acceleration controlled by the ACC when changing to a clear lane on a straight highway may sometimes be
judged to be too sluggish, whereas the same acceleration on a winding country road or the exit lane from a
highway can in some circumstances be felt to be dynamic to the point of uncertainty, see Figure 7.

                                High dynamic expectation
                                Middle dynamic expectation
                                Low dynamic expectation

                              Figure 7 - Anticipated dynamics

If the dynamic of one situation is applied, then loss of comfort automatically occurs in other situations. The
driver, however, expects system dynamics to adapt continuously and automatically to the current situation. Here
too, missing information about the environment manifests itself as significant system limitations, which make it
difficult to refine and optimize the system’s behaviour further until it matches the customer’s expectations.

Traffic movements consist of an incalculable number of different conditions. A person can react to each situation
appropriately. In the ideal situation the driver takes the right action. However, a technical system cannot, at least
from today’s viewpoint, depict these possibilities completely and fully. As far as problems specific to ACC are
concerned, three categories of roads are identified:

    •    Well-built highways
    •    Less important rural and main roads
    •    Roads through villages and stretches with many bends

A combination of attributes in an “AND”-gate increases recognition quality and ensures a function appropriate to
the situation.

The three dynamic steps relate to straight or at least mostly straight stretches of road. Furthermore the speed
selection also depends on how many bends the stretch of road possesses. The unit for this winding characteristic
is defined as the sum of all changes in angle per length of road. Bends with the same radius are driven through
more quickly compared with very twisting stretches of road if the curvature intensity of the entire section of road
is low. The bend configuration of the road can therefore also be a measure of the driver' dynamic awareness. If
the ACC and navigation system are linked, the resulting geometric behaviours can be used to control the
dynamic. On a stretch of road which is less twisting, the ACC vehicle can make use of the full dynamic. The
dynamic is reduced at the same rate as the intensity of the bends in the road increases. On very winding roads the
dynamic is set at the lowest level, even for a highway.

ADAS Interface Implementation
Several components and systems have been developed and implemented within MAPS&ADAS to enable test and
validation activities [7].
     • An ADAS Horizon Provider (AHP) is a system that generates an ADAS Horizon and distributes it on a
         bus. Four AHP systems have been developed, two dedicated by Navteq and Navigon and two navigation
         based systems by Siemens VDO and Blaupunkt.
     • An ADAS Client is receiving the ADAS Horizon from the bus. It includes an ADAS Horizon
         Reconstructor (AHR) that reconstructs the received ADAS Horizon, and makes its content available to
         the application via an API.
     • The ADAS interface has been implemented in a sample ADAS application: Active Cruise Control. The
         implementation in the BMW ACC is based on an existing ACC, using the reference implementation of
         the AHR.
     • A reference implementation of the AHR was developed for testing ADAS Horizon Providers systems
         and as the basis for the implementation of the ADAS Horizon in an ADAS client.
     • The Test Container is a separate system that can measure the impact of the protocol on the CAN bus for

In a typical in-vehicle controller environment, storage space is limited, and fixed data entity sizes and limited
quantities to avoid buffer overflow on the receiver side are required. The memory available on the receiving side
is usually restricted to 1 – 10 kByte.
These tight constraints have to be taken into account when implementing the ADAS horizon provider and
reconstructor in a series car and the MAPS&ADAS protocol is designed to do so.

ADAS Interface Testing
The test container provided by DC was intended for testing and evaluating the mutual influence of the original
data traffic present on a vehicle CAN bus and the ADAS Horizon data stream injected onto this bus [8]. Mutual
influence means how the characteristics of latency and transmission error statistics of one data stream are
influenced by the presence of the other.
For these tests, the typical background CAN traffic of a vehicle that might use map supported ADAS functions
has been recorded and later replayed on a CAN bus injecting a corresponding data stream for transmission of
horizon data using the ADAS interface. The reason why this must be done off-line in a '   sand-box' environment is,
that it is not possible to introduce extra data on the CAN of a series vehicle under normal operating conditions
(i.e., driving on public roads) without incurring danger of vehicle malfunction and safety risks.
Consequently, the tests involving real vehicle CAN data streams were performed by the four OEMs (BMW, DC,
Ford, and Volvo). On the other side, the four supplier companies (Blaupunkt, Navigon, Navteq, Siemens VDO)
helped by producing the ADAS interface data streams within the different vehicle CAN environments.
Of course it is interesting for each OEM how an implementation of the ADAS interface performs on his vehicles
and how it does influence the existing CAN traffic. For this reason, the main test task for all the OEMs was to
evaluate the OEM specific properties of a possible interface usage on the own cars. Also, the OEMs were entitled
to provide the background CAN traffic files for general testing, as they are able to produce relevant real life CAN
traffic examples.

There are a number of factors that influence the behaviour of the MAPS&ADAS transmission within an existing
background CAN traffic. These factors on one hand originate from the background traffic, into which the
MAPS&ADAS transmission is to be injected. On the other hand, they are influenced by the properties of the
injected transmission itself.
To use this experience in the best way possible for the development of the ADAS standard protocol, the first
prototype of this standard will be implemented within a BMW 5 Series vehicle. Figure 8 shows this prototype
will enable comparison with the existing BMW protocol, a check of consistency with BMW vehicle network and
valuable input for the further refinement of the MAPS&ADAS standard.

                  Figure 8 - BMW test vehicle with the ADAS interface and ADAS horizon

Map data access for most ADAS-Applications will normally use only a small map extract around the current
vehicle position. This ADAS-specific map extract is called the ADAS Horizon (AH). It is expected that the
navigation system supplier will add a module to the navigation system that extracts the ADAS Horizon data from
the map and sends it across the ADAS-Interface.

ADAS Interface Validation
As one of the major objectives of MAPS&ADAS, the definition and development of an interface between in-
vehicle map data sources and assistance systems is of pure technical nature, the technical validation of the
interface properties is the most important issue of the validation task [9].

However, there are properties, which obviously do not need to be examined, as they are known to be uncritical
from state-of-the-art. On the other hand there are interface properties whose outcome is unsure at the moment of
its definition, but which may be very important for success or failure of a market introduction of such an
Consequently, the technical validation performed within MAPS&ADAS is focussed on these most critical or
most important issues:
     • Bandwidth usage: Does the interface as proposed by MAPS&ADAS efficiently use transmission
          bandwidth for standard application requirements? E.g., what bandwidth is spent for a typical ACC
          preview, consisting of geometry and road class information?
     • Error properties and consistency of transmitted data: Is the interface transmission and interpretation
          error level sufficiently low? What level of Integrity (error recognition rate) can be reached?
     • Timing Issues: How long does it take for the horizon and positioning data to be transmitted? How ' is
          the image presented to the application?
     • Position and distance-to-object accuracy: How does the timing influence the knowledge and accuracy of
          the proper vehicle position and its relation to the event points of the preview?
     • Interoperability: Is it assured that different horizon provider software solutions, based on different
          navigation systems and map databases deliver a horizon data stream fully compatible to the interface

Test and Validation results
Test drives have been performed on different vehicles in different environments and the resulting data streams
been mixed off-line while varying several transmission parameters [8]. Of special interest were error and latency
behaviour of the MAPS&ADAS data stream itself and also its influence on the background traffic which is
already present on that bus for normal vehicle control purposes. The whole variety of performed tests, even the
most challenging set ups have shown the following validation results:

    •    Transmission latency time: The transmission latency of the ADAS Horizon CAN frames was
         incremented by the other (background) traffic. In general the added latency was less than 1 ms.
    •    Latency of position information: The latency on the CAN bus of the position messages was for all test
         cases less than 1 ms.
    •    Influence on position accuracy: In one ms the vehicle can travel at most 7 cm (for maximum speed of
         250 km/h), which is negligible compared to the accuracy of the vehicle position.

The mixed traffic tests of the different OEMs showed some properties common to all performed tests. As a first
observation it can be stated that the background traffic characteristics are invariant with respect to the
environment scenario in which the test was performed (urban, rural, highway). However, this fact is not
astonishing, since the bus on which the tests were performed is typically the most demanding CAN-bus segment
of the vehicle which has to be traversed for reaching some ADAS destination controller. This segment normally
transmits vital vehicle function information, which typically happens in a synchronous, periodic manner.
Asynchronous, event- driven communication are untypical cases on the investigated CAN segments.
Consequently, the total CAN background traffic load as well as the distribution of traffic over the used CAN-Ids
have been observed as being practically independent from the driving situation in relation to the urban-, rural- or

           Figure 9 – Three different driving environments (from left urban, rural and highway)

As examples, examine the figures above, stating the CAN-Id usage histograms for the BMW-Tests in the three
different driving environments – it can be clearly seen that the spectra for the three situations are practically
undistinguishable. Figure 9 shows CAN-Id Usage histograms of Powertrain-CAN Background traffic for BMW
545i test-vehicle as recorded in the three different environments (the red arrows are showing the CAN frames of
the MAPS&ADAS transmission protocol). The CAN-Id usage histograms for the DC-Tests in the three different
driving environments can also be clearly seen that the spectra for the three situations are also undistinguishable.
Of course, the CAN-usage histograms for the background traffic of different vehicles are very different from each
other – for comparison, see the figures for DC and BMW and the histogram spectra of the Ford Galaxy and
Volvo truck (see Ref. [8]). Observation of independency also applies for the absolute CAN usage percentages.
The CAN traffic for the Ford Galaxy shows nearly constant behaviour at low usage rates around 13.3%. While
the Volvo truck having an average bandwidth usage of 32.3% shows some variation of background traffic
intensity from 28 to 34% with occasional peaks even reaching even 38% (especially experienced on the rural
track). These are caused by some apparently asynchronous communication in the 3 highest priority CAN Ids –
the other part of the histogram of in total 40 different CAN-Ids is essentially independent from the driving
environment (see Ref. [8]).

Different from the background traffic characteristics, the density of the horizon transmission data stream is
slightly dependent on the environment, since surrounding road network layout and driving speed influence the
amount of transmittable horizon content. On the other hand, also the update rate by which the horizon content has
to be exchanged is essentially directed by the vehicle speed. Consequently, this is also reflected in the histograms
and total transmission figures of the CAN-traffic as produced by the MAPS&ADAS horizon provider modules.

So for typical CAN networks, the latency time, position information and position accuracy is not affected by the
speed of the network.
    • Influence on existing CAN traffic: The CAN traffic caused by the ADAS Horizon transmission will
         delay the existing CAN traffic. The measured delay strongly depends on the mix of priorities of the
         background traffic. For CAN messages with a higher priority than the ASCP messages, the delay was

         not significant, it is typically less then the transmission time of one CAN frame. For CAN frames with a
         lower priority, the measured delay was at most 0.53 ms.
         Note that this observation is only valid for one CAN segment. Care must be taken, when the data stream
         is to pass from one CAN segment to another via a gateway. It is a general challenge to in-vehicle
         network design to have a proper priority oriented design of the gateway.
         So with a proper priority scheme and gateway design the impact of the ADAS Horizon traffic on the
         existing network traffic can be minimized.
    •    ADAS Horizon Integrity: The ASCP messages generated by the 4 implementations of the AHP were
         received and analysed by the reference implementation of the AHR. This analysis includes detection of
         warnings and errors. The number of warnings and errors decreased during the testing, until at the end
         the AHP' had minimal errors.
         So by introducing the error checking in the AHR and resolving the errors in the AHP' the integrity of
         the transmitted data was significantly improved. At the end of the testing all AHP' had the same
         interpretation of the data model, the protocol and operation principles.
    •    Component Interoperability: The output of all AHP' was interpreted and visualized by the visualizer
         of the reference implementation. With a visual inspection the result was compared to the data that had
         been intended for transmission on the source side. For all AHP' the shape of the roads transmitted was
         almost identical to the shape in the background map of the visualizer. Slight differences were found,
         which were caused by the fact that the AHP map and the background map of the visualizer were from
         different sources.
         At an interoperability workshop all AHP' were combined with different AHR implementations, all
         based on the reference implementation. For all combinations no problems were found that would have
         impact on the specification. So for all features tested the AHP' were interoperable with the reference
         implementation of the AHR.

During validation no major barriers were found for further development and implementation of the ADAS
     • The impact on the CAN bus traffic can be minimized
     • The transmission delay on the CAN bus of ADAS Horizon messages is negligible with a proper design
     • The interface has been implemented by different project partners and when connecting different
         modules interoperability could be shown.
     • The reference implementation proved to be a valuable tool for testing AHP implementations

Transmission properties of MAPS&ADAS (transport) protocol are comparable to BMW dedicated protocol with
respect to
     • Bandwidth usage figures
     • Latency times
     • Influence on background traffic
Further feedback from series development is given by
     • Multiplexing mechanisms used in the MAPS&ADAS protocol are not allowed in BMW network design.
     • Network design issues from the series point of view.
     • BMW has experienced the need for a two-way communication (already running in the series ACC),
         especially for error recovery.
     • Define a '  static'version of the ADAS protocol to support strict CAN network policy, in close
         cooperation with series development.
Although developed completely independent from MAPS&ADAS, the BMW proprietary interface has similar
characteristics and properties. In addition it is necessary to run long-time tests to fulfil the requirements of the
series development (especially in light of effort and resources needed for test and analysis of bus systems).
Further important issues need to be addressed from BMW point of view with regards to series implementation,
These issues are detailed in Ref. [9]. Close cooperation with series departments is required to fulfill series
constraints with respect to the share of car components (e.g. CAN bus…), quality policy, test environment and
performances issues.

Considering the objectives of MAPS&ADAS with regards to the ADAS interface to develop, test and validate an
applicable standard, further steps are needed. The next steps and future work is outlined in the next section.

Next Steps – Necessary Efforts before Market Introduction
The feasibility assessment of an interface between ADAS and map data sources has technical, technological,
economical and business aspects. As part of its major objectives MAPS&ADAS has addressed the technical and
technological aspects and has achieved a major step by assessing the technical feasibility and the interoperability
of such standardised interface. Next step, that is out of the scope of MAPS&ADAS, deals with the necessary
efforts to integrate prototype implementation into series environment to enable market introduction. This phase
requires close cooperation with series department to fulfil series development constraints with respect to the
share of car components (e.g., CAN bus…), quality policy, test environment, performances… and is not anymore
at the pre-competitive stage.
Due to the fact that BMW already has a map supported ACC system on the market, using a proprietary interface,
MAPS&ADAS consortium decided to take advantage on this situation to work with the map supported ACC
series application. It gave the opportunity to the consortium to explore in advance potential issues and needed
cooperation with series department to enable successful series implementation and it contributed to clearly
identify next steps towards market introduction.
Further steps are needed for implementation in a series environment considering the objectives of MAPS&ADAS
with regards to the ADAS interface to develop, test and validate an applicable standard. Discussions initiated
with BMW series departments and research department of other OEMs and suppliers within MAPS&ADAS and
the ADASIS forum showed the necessity to cooperate closely with series development (network and application)
to assess the feasibility of the proposed mechanism. This cooperation has been intensified in the ADASIS Forum
as an exploitation of the MAPS&ADAS results.
Beside this a major milestone was achieved at the end of 2005, with the MAPS&ADAS activities presenting and
demonstrating the first results to the ADASIS Forum Members on 15 December 2005 at Honda in Offenbach.
With 35 participants representing 24 organisations, this successful event shows the increasing interest of the
leading European automotive industry in the ADAS Horizon concept, and the benefit of using digital maps as a
predictive sensor to enable or enhance ADAS applications.
The ADASIS Forum acting as the MAPS&ADAS User Forum is a self-funded industry initiative launched in
2002 and coordinated by ERTICO, aiming at supporting and promoting the development and the implementation
of a standardised interface between ADAS applications and digital map content. The ADASIS Forum is
composed of 30 Members from vehicle manufacturers, ADAS suppliers, navigation system suppliers and map

The very encouraging results achieved within MAPS&ADAS assess the technical feasibility of a standardised
interface between ADAS applications and digital map data and therefore confirm the potential of digital map for
road safety to enhance or enable preventive and active safety applications by extending driver horizon. As a
predictive sensor called ADAS Horizon, in-vehicle digital maps are an important source of information providing
look-ahead capability for ADAS applications and providing further information for on-board sensors to enhance
environment perception.
These expected benefits of the ADAS Horizon concept are reflected by the increasing interest and support from
the automotive industry. Since 2002 major industry stakeholders have been joining the ADASIS Forum to
promote and support implementation and near future market introduction by means of standardisation. The main
direct impact of a standardised interface will be on the economic side – this impact may be roughly estimated in
terms of economy on development efforts.

The authors kindly thank Vincent Blervaque of ERTICO for reviewing this paper and providing helpful


[1] ADASIS Forum:         http://www.ertico.com/adasis

[2] PReVENT IP:          http://www.prevent-ip.org

    MAPS&ADAS:           http://www.prevent-ip.org/maps_adas

[3] Loewenau, J. et al (2006), “Dynamic Pass Prediction – A New Driver Assistance System for Superior and
    Safe Overtaking”, 10th International Forum on Advanced Microsystems for Automotive Applications
    (AMAA), April 2006, Berlin, Germany; and Venhovens, P.J., et al (1999), “The Application of Advanced
    Vehicle Navigation in BMW Driver Assistance Systems“, SAE 1999-01- 0490, Detroit, 1999.

[4] Brandstaeter, M. et al (2004), "Functional Optimization of Active Cruise Control using Navigation Data",
    SAE 04AE-155, Detroit 2004.

[5] Mezger, K. (Editor), D12.32 Interface Requirements, Functional Architecture and Data Model,
    MAPS&ADAS project, Deliverable D12.32 revised version, Brussels, 2005

[6] Angenvoort, J., (Editor), D12.42.1 Interface and Data Entity Specifications Part 1–4", MAPS&ADAS
    Deliverable D12.42.1, Brussels, 2005.

[7] Beuk, L. (Editor), D12.72.1 Implementation Report, MAPS&ADAS project, Deliverable D12.72.1, Brussels,

[8] Loewenau, J. (Editor), D12.81 Interface Test Results, MAPS&ADAS project, Deliverable D12.81, Brussels,

[9] Loewenau, J. (Editor), D12.92.1 Interface Validation Results, MAPS&ADAS project, Deliverable D12.92.1,
    Brussels, 2006


To top