Discuss with us new ideas:
Provide feedback and your market expertise.
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 the Association for Standardization of Automation and Measurement Systems (ASAM e.V.) 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.
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 ):
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.
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:
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:
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.
|ISO TC22/WG31/WG2||Authentication, 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.
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 TEVDS20||Data 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 Area||A secured Vehicle Interface consists of the following layers: |
|ISO TC 22/WG31/WG6|
Extended Vehicle ("ExVe")
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.
| ||Access to OEM cloud with WebServices|
As data format JSON is used, for authentication and authorization JSON Web Token is used
| ||Remote diagnostic supports a feature discovery |
|ISO TC 204|| |
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
Earth moving machinery and mobile road construction machinery
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 /rFMS||OBD 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.
|NGTP||Next Generation Telematics Patterns (Dead?) |
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 .
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:
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 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 - 150||50 - 200 MB|
(one variant of an ECU)
|8 - 30||2 - 15 MB|
(PDX, one variant per built-in ECU
|~ 70||~120 MB|
|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:
In the coming months, and if there is sufficient interest, proposals for further, identified telematic components are to be prepared by other ASAM members.
In developing this telematic reference architecture, we hope to achieve the following objectives in the ADAS development process:
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 . 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.
 Peter Heidl, Werner Damm, SafeTRANS Working Group “Highly automated Systems: Test, Safety, and Development Processes”, SafeTRANS e.V., 2017
 www.asam.net (accessed on 27.03.2018)
 www.pegasus-projekt.info (accessed on 27.03.2018)
 www.vires.com (as of 27.03.2018)
 Interview with Dr. Klaus Büttner, BMW Group, VP Projects Autonomous Driving, Hanser automotive 10/2017, p. 28f
What do you think? Send us your feedback! ideation(at)asam.net
© 2019 ASAM e.V. All Rights Reserved