Reference Telematics Architecture for the Development of Highly Automated and Autonomous Vehicles

Ideation Project

Discuss with us

Send us your ideas, share your expertise,

and address your requirements.


Reference: This paper has been presented at the "Diagnose in mechatronischen Fahrzeugsystemen" on May 15 - 16, 2018 in Dresden, Germany [Presentation]



Autonomous driving requires the highest degree of reliability. For the life cycle of a car with highly automated or even autonomous driver assistance functions new methods and technologies for validation must be developed, which will enable efficient and cost-effective development of Autonomous Driving functions or Advanced Driver Assistant Systems (ADAS). Especially in the field of validation, telematics solutions offer considerable benefits for efficient and standard-based development processes. Based on the results of the analysis of current standardization tasks of the areas relevant for ASAM, we will introduce an innovative and integrated telematics reference architecture. It will be capable of closing some of the gaps that have been identified in the standardization for Automotive Electronics Engineering.



1 Initial situation and field of application

For vehicles with driver assistance functions at Levels 4-5, experts expect that more driven kilometers or the equivalent in the form of a suitable simulation will be necessary. New methods and technologies for validation procedures must therefore be developed. Especially for the area of validation in the field, telematics solutions are of fundamental importance for efficient and standard-based development processes, as has been demonstrated by the SafeTrans working group in its position paper. In the SafeTrans position paper on highly automated systems, the following are some of the recommendations that have been formulated (Extract from [1]):

  1. A continuous cross-industry learning processes for the development of highly automated transport systems based upon analysis of fleet data is established, enabling fast take up of new features and capabilities while maintaining and enhancing system safety and performance.
  2. A common evolvable fault tolerant system architecture, including onboard systems and infrastructure, is standardized, to facilitate the necessary innovation speed and efficient validation efforts.
  3. … methods supporting V&V, engineering and modeling of safe open world systems are developed and matured, allowing model centric validation and verification approaches. An open development environment and a development and validation process accepted by OEMs, regulatory authorities and certification bodies are established.
  4. Established deterministic model-centric development approaches are combined with cognitive automation and semantic algorithms, to enable the safe operation of dynamic open world systems and their validation.

In our opinion, these objectives will lead to a necessary standardization of telematic components and data formats, thus ensuring a more efficient gathering of data during vehicle operation. We refer to this field of application as Real Driving Validation (RDV). In addition, long-term maintenance, development, and establishment of standards in the field of driving simulation will be required.



2 Current standardization activities and gaps in standardization for Real Driving Validation

An international ASAM work group analyzed in 2017 the current standardization work of SAE, ISO, AUTOSTAR and other open interest groups for the RDV field of application.


2.1 Current standardization in ASAM e.V.

The association ASAM e.V. focuses on standardization in the development of automotive electronics. The association coordinates the development of technical standards that are developed in project groups by experts from the member companies. ASAM is pursuing the objective of increasing the efficiency of development processes by means of standardized tools. The standards define logs, data formats and application programming interfaces (APIs) for software development and the testing of vehicle control units.  ASAM standards portfolio

By way of example we would mention the following domain-shaping standards that could also be used in future for RDV applications:

  • ASAM ODS and ASAM MDF file format
  • MCD-1 XCP log
  • ASAM-2 D (ODX) file format
  • ASAM OTX extensions

One of the strengths of ASAM is the fast implementation and long-term maintenance and support of standardization measures by experienced specialists and users from the member companies.   Development process for ASAM standards

As it can be assumed that every possible driven kilometer of a vehicle on test stretches, in customer-oriented tests, or in the field will in future be used to improve the development process, the future standards must also take into consideration the following technical requirements for the specific telematic components: 

  • small footprint on embedded devices 
  • low data transfer rates
  • domain-specific access
  • security (authentication, authorization)
  • on-board test driving cycle dispatcher


2.2 Standardization in other standardization organizations

During the study, the fields relevant to these special telematics applications were examined, that is, Real Driving Validation from ISO, SAE and other standardization organizations. The table below shows, in extracts and merely exemplarily, the standardization initiatives identified in the said field of application—telematics.

ActivityShort DescriptionContent
ISO TC22/WG31/WG2Authentication, Authorization, and Secure Diagnostic Communication
(Proposed UDS Update)

In addition to the combination of $Service 27 (Security Access) with $Service 10 (diagnostic Session Control) the new $Service 29 (Authentication) is introduced.

Authentication uses 2 concepts

  • based on PKI certificate exchange procedures using asymmetric cryptography
  • based on challenge response procedure without PKI certificates using either asymmetric cryptography with software autentication tokens or symmetric cryptography

It is possible to authenticate the client only against the server, to authenticate the client against the server and the server against the client, and to transfer a Certificate independently or after a previous authentication. The access rights can be controlled, e.g. by the Certificate.

SAE TEVDS20Data Link Connector Vehicle Security Committee 
(Hardening of the OBDII port)
The committee provides guidelines for securing communications with any off-board device for vehicles utilizing either methodology. Main focus is securing the Data Link connector (OBD II Port).
SAE (Initial Discussion)Trust Anchor and Authentication Work AreaA secured Vehicle Interface consists of the following layers: 
  • Secure Interface (requires authentication)
  • Secure Gateway (separated functional domains, and isolated TCU and OBD-II)
  • Secure Network (secure messaging with authentication and encryption) and 
  • Secure Processing (authentication of ECUs)
ISO TC 22/WG31/WG6

Extended Vehicle ("ExVe")

  • ISO 20077 - Part 1 and 2 available

Design methodology


The data are transferred via the mobile telecom networks from the vehicle to the vehicle manufacturer's server (OEM backbone), and then made accessible to service providers via the standardized interface.

  • ISO 20078 - Part 1 till 4 as DIS available
Access to OEM cloud with WebServices
As data format JSON is used, for authentication and authorization JSON Web Token is used
  • ISO 20080
Remote diagnostic supports a feature discovery
  • Identify ECUs fitted to the vehicle
  • Read Diagnostic Trouble Codes (either from one or all ECUs in a vehicle)
  • Read readiness codes
  • Read DTC Snapshot data
  • Read selected diagnostic parametric dynamic data
  • Read malfunction indicator status
  • Clear all DTCs
  • Adjust the settings of a selected system
  • Activation of actuators
  • Activate a self-test routine
ISO TC 204 
  • ISO 13185-2 Unified gateway protocol (UGP) - available

ASAN.1 based protocol to Vehicle station service Gateway (e.g. Telematic Control Unit)


Generic data exchange for parameters (with identifier and type) for the Out-Vehicle communication


Vehicle Interface data format describes the parameters and is used to Client and Server. In focus are diagnostic data, Dedicated Short Range Communications (SAE J 2735), event-based probe vehicle data (ISO 29284) and vehicle probe data for the wide area communication (ISO 22837) are in focus. Access is restricted to described data (seen as a user specific description) and global access rights (read, write, user).


No knowledge about the vehicle protocols is required by the connected UGP Client. For authentication and authorization purposes, a public key mechanism is used (for the TCU but not for ECUs)

ISO TC 127

ISO/TS 15143-3

Earth moving machinery and mobile road construction machinery

  • For Mixed Fleets

Different service levels (AEMP = level 2), other levels in Verband der Baubranche, Umwelt und Maschinentechnik defined


The data are the base for a cross manufacturer FMS

FMS /rFMSOBD data, data set distinguishes between a common set and special parameters for bus and truck

The Fleet Management System Interface (FMS) is an open standard for accessing electronic data from the internal network of commercial vehicles (trucks and buses). The data are available according to SAE J1939.


The rFMS API is a HTTPs based REST API for retrieval of vehicle data from a specific customer's fleet of trucks /buses. The refresh rate of data of the vehicle position for each vehicle is at least once every 15 minutes. The refresh rate of data of the vehicle status reports for each vehicle is at least once every 60 minutes. 

NGTPNext Generation Telematics Patterns (Dead?)
  • BMW, Navteq, WirelessCar, ygomi

  • Focused on telematic backend system
  • Defines a message format on semantical leve

Table 1: Examples of identified standardization initiatives with relevance to use cases


As an example, we mention the following ASAM / ISO Standards, which could also be used for RDV applications in the future . 

  • ISO (ODX)
  • ISO (OTX)
  • ISO (extended vehicle)

OTX was identified as being especially suitable for the development of a test environment with process security over the entire life cycle.


RA Consulting expects, for example, that future licensing and inspection drives will take place not only in a secure test environment but above all in real surroundings. This requires systems that can automatically identify and document the driving cycles to be covered in a test drive (e.g. certain vehicle maneuvers in specific traffic situations at a particular statistical frequency). This can be replicably depicted from the technical aspect using OTX. 

2.3 Standardization in open interest groups


Based on the analysis of current research projects in the field of autonomous driving, it was possible to quickly identify standards with relevance to the simulation of test drives. For the simulation of test drives, standards are required for the description of the environment and the driving maneuver and for the control of the simulation system. By way of example, we refer to the standards and standardization initiatives such as OpenDRIVE, OpenSCENARIO, OpenCRG, and Open Simulation Interface (OSI), which could be used for RDV simulation in the future .


An initial evaluation of the standards in mid-2017 provided the first recommendations for extensions and improvements in quality that would be required for further industrial application of the standards. As an example, we mention the following suggestions for OpenDRIVE:

  • Additions to or in the standard are expedient (e.g. parameters for frequency distribution).
  • Some formal revisions that are required for a standard should be made: (Formal chapters, such as introduction and use-case descriptions should be expanded; unclear references to external information revised, and the structure of the document standardized.)
  • Transformation of the OpenDRIVE data model to UML and the incorporation of the UML model into the standard
  • Automatic generation of XSD from the UML model (single source)
  • Provision of a validation tool


3 Reference architecture for the defined field of application

Based on the analyses, an integrated ASAM telematic reference architecture using existing, market-relevant standards was designed, by which the standardization gaps for this particular application are to be closed as far as possible. Where feasible, existing standards, and standards that are currently being developed in a wide range of organizations, will be used here in order to ensure the fastest possible introduction of these components to the market. Besides the existing standards, for example in the area of vehicle diagnostics, the architecture for current development projects in the field of autonomous driving was also defined and extended. This reference architecture is complemented by new standardization initiatives of ASAM where necessary. 


In the context of the newly established ASAM ideation process, RA Consulting GmbH submitted idea for an ODX run-time format in 2017 as a proposal for a new standard. The data driven diagnosis in a run-time system according to ASAM MCD-3 D is defined in the ODX standard as the most important, but not the only target. Rather, many other aspects are taken into consideration in the structure of ODX containers (PDX stands for packaged ODX format) (single-source principle for the definition process of diagnostic data). For example, the work-shared development of diagnostic functionality (e.g. through heredity and linking), the documentation of diagnostic architectures, the exchangeability of the containers with suppliers, and the tracking of changes through administrative meta data. The implementation of this type of runtime system for the field of diagnostics is achieved with the so-called MDC 3D server. "D" stands for diagnosis. For that reason, the name D-server is used frequently, alternatively: ODX kernel. This is defined in the standard ISO 22900 where it runs under the name "MCVCI server".


The lack of optimization of ODX containers or PDX containers for diagnostic run-time systems makes direct access to the information of an ODX container by an MVCI server very inefficient and lowers performance. This is primarily because:


  • the dimensions of the ODX container increase continuously due to greater requirements posed on diagnosis, and the processing of large files sometimes exceeds the RAM capacity of conventional computers.
  • the nodes of an ODX container are semantically interlinked (e.g. via ODX links). The exchange format XML, on the other hand, is based on a purely hierarchical structure. This “discrepancy” must be resolved every time the container is loaded, which is both processor and memory intensive. This is not feasible with larger ODX containers.
  • from the aspect of the run-time system, an ODX container has a high level of “noise”. That is information that is not required for carrying out a diagnosis and which relates to other aspects of the diagnosis development, such as change management, administrative data, and technical descriptions, such as the occupancy of electric plugs.

The transfer and processing of large ODX files is even more critical in the field of embedded and telematic applications than in conventional applications. There, computer performance, memory capacity and transfer bandwidth to the tester are available only in a very limited scope. Almost every diagnostic run-time implementation thus uses its own proprietary format for a more efficient data-driven diagnosis. A preprocessor transforms a given ODX container into a data format that is optimized, but not standardized for the run-time system.


For the specification of an ODX run-time format, an adapted, partial optimization must be undertaken for the two rival design objectives of completeness and task orientation: Normally, an ODX container fully describes and documents the diagnosis functionality of a logical unit. Logical units are, for example, control units, control unit families, vehicles or entire vehicle platforms with differing control unit variants. In practice, however, the diagnosis is usually task-oriented. A tester then requires for the run-time only the parts of a complete description that are necessary for a specific task. For example, an OTX sequence, which reads out precisely one measured value from precisely one control unit with precisely one log through exactly one diagnostic service. A reduction of the diagnosis data to a previously known partial quantity would decisively reduce the size of the description 

(all vehicle variants)
> 500> 1000 MB
(all ECU variants)
50 - 15050 - 200 MB
(one variant of an ECU)
8 - 302 - 15 MB

Specific vehicle

(PDX, one variant per built-in ECU

~ 70~120 MB
Specific vehicle
(runtime format)
 0,5 - 5 MB

Table 2: Number of files and file sizes for various ODX formats

This limitation is possible with the use-case RDV, as the VIN and ascertainable CAN node list (device list) can serve as the basis for the limitation during a remote download of a test task to a specific vehicle. 


The objectives in standardizing a diagnostic run-time format can be summarized as follows:

  • transport of the hierarchical textual exchange format into a binary file format ideally tailored to network structures (graphs)
  • identification and elimination of the aspects which are not important for a runtime system, such as administrative data or special data groups (SDGs) 
  • resolution of modular and work-sharing aspects which do not contribute to the run-time view, for example, inheritance 
  • creation of a starting point for the further reduction with regard to task-oriented diagnosis


In the coming months, and if there is sufficient interest, proposals for further, identified telematic components are to be prepared by other ASAM members. 

  • MCD-3D server embedded
  • MCD-3MC server embedded
  • OTX Open function controller
  • OTX extensions for simulations standards and Interfaces


In developing this telematic reference architecture, we hope to achieve the following objectives in the ADAS development process:

  • The draft of a standard-based test system in order to reduce the high cost of test methods up to the point of licensing, or for repeated inspections in the operation of highly automated vehicles
  • On the basis of new standards like OTX (Open test sequence exchange format) and domain-specific extensions (OTX extensions) drafts are to be prepared for the automation of repeated test sequences, thus making them easy to understand and efficient over the entire life cycle.
  • Existing standardizing potential, for instance, with OpenDRIVE or OpenSCENARIO could be used here. The interoperability with other existing standards, or standards of ASAM, ISO or SAE that have been identified for development should be guaranteed.
  • By means of drafting domain-specific extensions of the test standard OTX, the interoperability of vehicle maneuvers for test procedures in simulation systems should be facilitated.


4 Economic benefits and a view into the future

The economic significance of automotive engineering is of huge importance to the German automotive industry. The provisions of the current research programs reflect the necessity of speeding up standardization. ASAM has seen this need and has developed an accelerated and simplified procedure for innovative standardization initiatives, in particular for the fields of “telematics and ideation”. The aim should be to publish important new standards within 12 months.


For the development of a marketable automated vehicle, experts expect that 240 million test kilometers driven on public roads will be necessary, and that for each new software status approximately five million vehicle situations must be inspected by simulation within a very short period [5]. With costs of an estimated minimum of €4 per kilometer driven as the basis for calculation, the total costs for the licensing of one vehicle type could amount to more than €1 billion. By means of innovative and reliable test procedures, vehicle manufacturers, suppliers and tool suppliers could achieve a faster entry to the market or cost advantages in the development phase. Improved, standardized and test procedures with greater process reliability will promote these new technologies and their use.


The development of a central but openly accessible test library with qualified and certified test case descriptions for the various role-players could dramatically reduce the development and licensing costs for highly automated and autonomous driving. However, the joint or coordinated generation and use of test libraries by vehicle manufacturers, suppliers, licensing bodies, engineering service providers and tool manufacturers calls for standardization on a higher level of abstraction, which must then enable platform-independent and non-proprietary use. We believe OTX provides the methodological and technical prerequisites for this as evident or feasible.


On the basis of current developments and the necessary implementation of standardization initiatives from publicly financed research projects, ASAM e.V. has begun to develop partnerships with a wide range of interest groups. Furthermore, since the beginning of 2018, ASAM has been named as an associate partner in two applications for research projects with public funding in the field of autonomous driving. The objective is to ensure the demand-oriented initiation of new standards, the acceptance of existing standardization initiatives, and the long-term guarantee of market-relevant standards in the field of automotive electronics development through ASAM. This is also to be done particularly in new domains such as simulation and telematics.

In conclusion, we would quote the central statement of SafeTrans from the paper "Highly Automated Vehicle Systems":

In order to maintain a leading European position it is therefore necessary to establish collaborations in and across industrial domains, learn from field data …, address the challenges identified … and jointly drive the strategic actions.



In the view of the authors, timely, pre-competition and high-quality standardization will be an essential component in the future development of highly automated driving and flight systems. 


[1] Peter Heidl, Werner Damm, SafeTRANS Working Group “Highly automated Systems: Test, Safety, and Development Processes”, SafeTRANS e.V., 2017
[2] (accessed on 27.03.2018)
[3] (accessed on 27.03.2018)
[4] (as of 27.03.2018)
[5] Interview with Dr. Klaus Büttner, BMW Group, VP Projects Autonomous Driving, Hanser automotive 10/2017, p. 28f


Discuss with us

Send us your ideas, share your expertise,

and address your requirements.


Our newsletter informs you about current activities.