• Diagnoseprozesskette - Aktueller Zustand
• Diagnoseprozesskette - Ziel
• ODX - What is it?
• Applications
• Advantages and benefits
• Risks of ODX / MVCI Introduction

After we have seen in the last chapters, as the onboard communications and the application data can be described with standardized data formats, we turn in this chapter on diagnostic data, for which specifies the data format ODX (Open Diagnostic Data Exchange, ISO 22901) .

MVCI server (ASAM 3D server, ODX-Kernel)

Diagnoseprozesskette - Aktueller Zustand

The world of diagnosis is characterized in that there are many agencies involved. It begins in the development of the vehicle manufacturer, who designed the vehicle and defines its individual components. The development of the components is typically at system suppliers, which, in several rounds of samples together with the vehicle manufacturer, the electronics systems. At the end of the development phase, the transition is in production. Within the production, the individual electronic components that are installed on the vehicle are of course also tested. Therefore, the diagnosis is here within the production also been used by the vehicle during production tested. The actual development of the diagnosis is typically not in the production itself, but with the help of diagnostic systems supplier to define and implement the appropriate test procedures as specified by the manufacturer. Ultimately, even the shop chain of the vehicle manufacturer are able to service the vehicles and determine fault. Therefore, for the service is also a diagnostic approach to be developed. All agencies in this process chain typically work with different tools, different tools, and - at least in the past - even with different data formats and different diagnostic test systems. As a result of the many agencies involved and the heterogeneous tools and data formats, there is obviously considerable problems with data transfer, in the consistency of data and in particular, a considerable amount of work.

The current diagnostic process chain is characterized by a heterogeneous exchange of information relevant to diagnostics

Diagnoseprozesskette - Ziel

The basic idea of ​​ASAM now is to facilitate using a common data format, data delivery and data processing, and to unify.

The proposed ASAM solution to this problem has two parts. It will certainly not be able to reduce the number of agencies involved. On the contrary, by increasing cooperation between different manufacturers, the number of participants is sure to rise even further. But you can at least for a common data format and thus provide a relatively simple transfer of data from one location to another. This is the basic idea of ​​ODX, the "Open Diagnostic Data Exchange" data format: A standard database for diagnostic data, which is a common source and to which all involved parties have access.

ODX - the exchange of standardized diagnostic data on all phases of vehicle life cycle - Basic Principle: Single Source

The second part of the solution proposed by ASAM focuses on the diagnostic tester. During early diagnostic tests were typically proprietary systems, ASAM proposes to use a universal diagnostic tester with a standard runtime system that can not be programmed by any vehicle manufacturer from scratch. He may have a standardized interface to which access the vehicle diagnostics bus system and it is configured on the ODX database. The idea is that the diagnostic test is no longer to program depending on the vehicle, but a generic diagnostic tool to parameterize the vehicle-specific ODX data easy.

Diagnostic runtime system MVCI ISO 22900 (ASAM AE MCD 3D)

ODX - What is it?

The data format was created as ASAM ODX specification under the heading MCD 2D and is now standardized as ISO 22901-1. As an exchange format for all relevant diagnostic data, several areas are covered:

• Protocol specification for communication between the tester and control unit
• Communication parameters for ISO / OSI layers, and controller software
• ECU programming data (Flash)
• Description of the vehicle interface (connector and pin assignment)
• ECU configuration (variant coding)
• Allowed transition from the service-centered for function-centric diagnostic development

It is about the diagnostic protocol (UDS, KWP 2000, OBD), in their vendor-specific expression to the communication parameters of the party bus (transport and data link layers), the vehicle interface, connectors, pin assignments, programming data rates for the workshop, model coding, etc . In addition, a transition from a service-oriented diagnosis - that is, a more communication-oriented diagnostic messages - are available to a function-based diagnosis. Since it is irrelevant from the perspective of the workshop, which is filled with messages a particular task. A workshop organization to solve specific tasks and for that you try to design this diagnosis in future instead of function-centered services.

The goal is certainly ODX in connection with the generic term system use, but the implementation will be sure to use ODX first as a pure data format for data exchange between the parties.

Applications

Ideally ODX is used in all phases of the project and everyone involved. The OEM, its suppliers, production and in the workshop.

ODX is still applicable, if the diagnosis process chain is not consistently based on ASAM standards, but if only as an exchange format ODX is used, for example, within the development.

Similarly ODX is the distribution of diagnostic data from the appropriate manufacturer to its dealers.

Advantages and benefits

The advantage and benefit of using ODX all involved parties. It starts with the OEM whose time is reduced considerably if he has to maintain only a single data source with a uniform data format, if can be simultaneous in that database for the management of various vehicle and equipment variants and he to the data not in the transmission the various parties involved each time re-create and verify needs.

Furthermore, the simplified specification for the supplier and the documentation of the diagnosis, because ODX is able to afford both. It can serve as a specification for the supplier, as well as documentation for the components supplied, as far as it concerns the diagnosis.

When suppliers can ODX be used for the generation of the diagnostic protocol stack. That is, instead of the diagnostic software can be programmed according to the guidelines ODX be produced with automatic tools in the ODX data files, software needed for the diagnostic protocol stack.

At the same time based on ODX can also test the software systems that the protocol stack must be tested in a real controller to be configured automatically. This software tests are reliable, since one can directly test automated tools against the ODX specification.

In production, simplifies the development of production test if you can access the ODX records. It is ensured that the same records are verified as used in the development. This reduces the number of errors and the total effort.

The After-Sales also benefited from ODX. The effort in the creation and dissemination of the diagnostic data to the workshop network is much lower because there are already verified records.

Since the data format is standardized, the car manufacturer by the tester manufacturer is more or less independently. At the same time, standardized data sets are transmitted much more easily as a diagnostic test programs. Also benefit from the workshops. It is conceivable in the future that the garage does not have to buy a subscription software updates for their workshop testers, but according to need those records for vehicles to be repaired to-date, downloading via the Internet.

The introduction of the standard data format, the diagnostic data are recorded simultaneously in a freely accessible format. This enables vendor-independent emission test systems for TÜV or DEKRA and for independent workshops to develop much more easily than with today, often proprietary data formats.

Below are all the benefits listed again:

• Suppliers

  • Automatic configuration of ECU diagnostic data and the communication protocol
  • Automatic generation of documentation (ECUs diagnostic data = Documentation)
  • Automatic configuration of the development of tests to verify the implemented diagnostic services
  • Machine-readable format (XML) for import into their own diagnostics database
  • Code generation to configure the kernel diagnosis

• Vehicle Manufacturers - Development

  • Cost reduction in diagnosing data generation
  • Single-source principle: All development tester support the same format.
  • Only a format for the import and export with the central diagnostic database

• Vehicle Manufacturers - Manufacturing

  • Cost reduction in diagnosing data verification - data must be verified only once
  • Reuse of verified diagnostic data
  • Fewer errors due to lower number of process steps
  • End-of-line tester using the same diagnostic data and the same diagnostic tests as in the development

• Vehicle Manufacturers - After Sales

  • Easier reuse of verified diagnostic data
  • Less effort in the distribution of diagnostic data
  • Retrieve diagnostic data via Intranet / Internet vs.. Deploy software updates on CD-Rom
  • A format for the various diagnostic systems

• Tool Manufacturer

  • Less effort in the preparation of diagnostic applications by using a generic data-driven approach
  • Focus: Diagnostic vs killer apps. Bits & Bytes
  • Easier reuse of verified diagnostic data

• Workshop

  • Reuse of verified diagnostic data
  • Tester configuration data download vs. Software modification
  • Download as needed vs. Purchase a software update

• Legislature

  • Standardized format for the documentation of the relevant diagnostic data (eg, DTCs, PIDs, etc.)
  • Allows non-proprietary scan tools and tools for service and instant entertainment
  • Meets the requirement of free workshops on access to advanced diagnostic data

Benefits Summary

• Reusability (single source)
• Increase safety, by reducing process steps
• Simple and easy verifiability
• Improve the maintainability
• XML format: machine and human readability
• Vendor independence
• Automated tools for configuration, document creation, code generation etc.
• Generic creating diagnostic applications

Risks of ODX / MVCI Introduction

Despite all the advantages of ODX course, must not be overlooked that the introduction of the ASAM-based approach, a number of risks.

On the one hand, manufacturers have already diagnostic tools, diagnostic testers in use and the change will mean of course that you can not throw away the old systems, but that they must continue to maintain. This means first of all caused by ODX no cost savings, but initially created an additional burden. Then they will not change the course can make a sudden, but you will need to carry out gradually. This means, first of all be introduced as a pure data exchange format ODX with import and export to proprietary systems. Then they will move the entire train to train diagnostic data based on ODX and in the end we only introduce the standardized diagnostic tester. The technical risks of course are also economic risks because it is not clear whether a standardized diagnostic test concept is really to the manufacturers now live on the development of diagnostic tests and diagnostic tools a successful business model. And if manufacturers can not implement all economically successful, the concept is going to die.