Vehicle diagnostics

from Wikipedia, the free encyclopedia

Vehicle diagnosis, based on the medical term diagnosis, describes the precise assignment of findings to defects in electrical and electronic components in automobiles. A number of technical processes and applications are summarized under the term vehicle diagnosis, which are used, for example, in error analysis in the event of repairs, in quality assurance for statistical evaluations and in vehicle development. In addition, the vehicle diagnosis is used to inform or warn the driver about errors that have occurred and to initiate deactivation of vehicle properties if their operation cannot be unequivocally ensured.

The vehicle diagnosis can basically be broken down into:

  • Diagnostic components within the vehicle - on-board diagnosis , including vehicle self-diagnosis
  • Diagnostic components outside the vehicle - off-board diagnostics (diagnostic information, diagnostic tools)

In a narrower sense, vehicle diagnostics in the automotive industry means (diagnostic) communication between an external test device, the diagnostic tester (see also vehicle diagnostic system ) and the individual electronic components, the so-called control units , via a diagnostic protocol.

The diagnostic data (now standardized via ODX ), which describe the communication and are stored in the diagnostic systems of the off-board diagnosis, serve as the link between the diagnostic tester and the vehicle . They describe the diagnostic protocol used, the individual commands, their possible responses from the control unit and the interpretation of the data, e.g. B. Conversion into physical values.

Vehicle self-diagnosis, on-board diagnosis

Technical procedures

The vehicle self-diagnosis is divided into 2 parts:

  • 1st part: Is the monitoring of the sensors and actuators located in the vehicle and connected to the control units;
  • Part 2: Self-monitoring (internal ECU diagnosis).

Different methods of diagnosis come into play in both parts, which can be distinguished in terms of their type and implementation as follows:

  1. The electrical sensors or actuators connected to the respective control unit connections are monitored using electrical diagnostics.
  2. The plausibility check is used to evaluate one or more signals that are related to each other. The evaluation is carried out by comparing it with the setpoint values, characteristics or algorithms stored in the respective control unit.
  3. The failure monitoring of cyclically incoming information or signal variables, such as B. connected networks and their data.
  4. Active testing by generating test pulses, which are sent once or cyclically, and evaluating the reaction of the respective sensor or actuator.

Documentation and storage of errors

If one or more plausible errors are found during diagnosis, so-called Diagnostic Trouble Codes (DTCs), the occurrences are recorded in the event memory, in modern vehicles in a processor (MCU) with a virtual EEPROM, in older vehicles in a separate EEPROM (both is called error memory for short ) is stored in the vehicle and can be read out at any time.

The information stored in the error memory documents the following events:

  • electrical faults specifying the type of fault, e.g. B. Interruption (one line), short circuit to positive or to ground, etc.
  • Failure of actuators
  • Signal values ​​that are implausible
  • Failure of messages
  • Notes on implemented protective functions
  • regular operating conditions

System diagnostics

Since the causes of incorrect behavior are difficult to determine in a highly networked vehicle, there are approaches to diagnosing the overall system, the so-called cross - system diagnosis . There are several options:

  1. On-board side: certain DTCs are collected in a central control unit during operation. This master control unit documents the various individual errors of the client control units in relation to time.
  2. On the off-board side: The DTCs stored in the respective control units are supplemented by additional information, such as date and time, or driving status information, and are stored locally. When read out later, this information is read out, compared and evaluated by the off-board diagnosis.

Diagnostic information and tools, off-board diagnostics

This includes those components and aids that can be used to support troubleshooting and subsequent repair. Diagnostic information can in the broader sense also z. B. the workshop manuals, service manuals, circuit diagrams, etc. The most common diagnostic tool for diagnosable systems in the vehicle is the diagnostic tester . Due to the high complexity of the diagnostic-capable technical systems in the vehicle, diagnostic testers are equipped with an interface for diagnostic communication, so that the DTCs can be read out and deleted together with frame information (freeze frame data). On the other hand, the diagnostic tester works with algorithms or expert system strategies in order to be able to determine the causes of errors more precisely. Reliable vehicle diagnosis requires the linking of diagnostic information from the off-board diagnosis with other information sources (including statements from customers about the conditions under which the error occurs, function overviews, consideration of possible causes of errors in systems that cannot be diagnosed) by workshop personnel and can still be done today cannot be carried out fully automatically.

Diagnosis and Legislation

Since the end of the 1980s, more and more legislative bodies in various countries and regions have prescribed functioning, electronic vehicle diagnostics to monitor the mode of operation of emission-relevant parts in the vehicle, in parallel to the actual emission reduction (more on this in the article exhaust gas standard ).

In the automotive industry, the term on-board diagnosis (OBD), European on-board diagnosis (EOBD) and, more recently, WWH-OBD are used for electronic vehicle diagnosis . As a rule, all control units in the vehicle monitor operation independently, i. H. carry out the actual on-board diagnosis . The decisive difference is the fact that this happens with emission-relevant components due to legal requirements and the functionality is checked in the context of the general road traffic approval by authorities and in the course of the regular examination of the engine management and emission control system (UMA).

In addition, communication with an external test device is precisely regulated and uses its own command set, which exists as a reserved area in the diagnostic protocols and is standardized via ISO 15031 . Therefore the term OBD or EOBD is only used in connection with these electronic control units.

Since Regulation 715/2007, Article 3 Definitions of the European Parliament, the use of the term OBD has been clearly regulated within the EU and should therefore only be used in this context.

The operational monitoring procedures are also used by non-EOBD-relevant control units, although there are other reasons for motivation: troubleshooting and repair should be made easier and the replacement of supposedly defective components at the expense of the manufacturer (guarantee and goodwill ) should be prevented. In highly networked vehicles, the symptom and cause of an error are no longer exclusively local, but distributed, and the cause of the error cannot be identified without detailed knowledge.

Overview of the most important OBD regulations

Country / Region Introductory year designation
United States ( California ) 1987 OBD I
United States 1996 OBD II
European Union (EU) 2001 EOBD for passenger car gasoline engines
European Union (EU) 2003 EOBD for passenger car diesel engines
European Union (EU) 2005 EOBD I for commercial vehicles
European Union (EU) 2008 EOBD II for commercial vehicles
United Nations 2015 (planned) WWH-OBD

In addition to the country of introduction or the region, other countries also often use the existing regulations and incorporate them into their local legislation. So z. E.g. in Israel the EOBD regulation of the European Union applies. It should also be noted that the basic regulations are subject to regular updates and adjustments. EOBD was introduced in the EU with the Euro 3 regulation and is now available in the third, updated version Euro 6 , which will apply to type approvals from 2013.

Note : More on the subject of OBD in the corresponding special article on-board diagnostics

Further influences of legislation on vehicle diagnosis

Within the European Union, with the introduction of the Euro 5 and Euro 6 regulations in Regulation (EC) No. 715/2007, in addition to the pure emission reduction and control, all other components of vehicle repairs were also regulated and thus replaced the expiring one Block Exemption Ordinance (GVO), into which the motor vehicle industry was incorporated in 2002.

The main innovations through Euro-5 and Euro-6 are the regulation of access to repair and maintenance information (excerpt):

  • Unrestricted access for all dealers and workshops to the information required for repairs (as a result, the monopoly of the authorized dealers is removed )
  • Simultaneous provision of information via the Internet at any time in standardized form, according to the internationally valid standard (OASIS format), for all dealers and workshops
  • Information about components, diagnostics and error codes (including manufacturer-specific diagnostic information)
  • Information about data storage and bidirectional control and test data

For more, see the summary of Euro-5 and Euro-6 of EU legislation.

Diagnostic communication

The link between the on-board diagnosis and the off-board diagnosis tools is the diagnosis communication. Via standardized or standardized hardware and software interfaces, the control units installed in a vehicle are connected to the external diagnosis unit via the diagnosis socket (also called OBD socket) installed in the vehicle . A vehicle diagnostic system communicates via a so-called diagnostic protocol, which is based on a transport protocol (TP) and is adapted to specific hardware connections.

Overview of the communication interface

The following table shows the valid combinations of hardware interface, transport protocol and diagnostic protocol that have been used or are currently used by various vehicle manufacturers :

Note: The table is still incomplete and needs to be expanded for other vehicle manufacturers

hardware Transport protocol Diagnostic log Use at Remarks
K line - KWP1281 Volkswagen AG obsolete, no longer used standard
K line - KWP2000 light Plus Volkswagen AG obsolete, no longer used standard
CAN TP 1.6, TP 2.0 KWP2000 ( ISO 14230 ) Volkswagen AG manufacturer-specific extensions and modifications
CAN ISO-TP ( ISO 15765-2 ) KWP2000 ( ISO 14230 ) Daimler AG manufacturer-specific extensions and modifications
CAN ISO-TP ( ISO 15765-2 ) UDS ( ISO 14229 ) Volkswagen AG , Daimler AG , BMW AG , Porsche AG , MAN Trucks & Bus AG Use of different versions of standards and manufacturer-specific restrictions
CAN ISO-TP ( ISO 15765-2 ) ISO-OBD ( ISO 15031 ) Volkswagen AG , Daimler AG , BMW AG , Porsche AG
CAN BAM and CMDT SAE J1939 Commercial vehicles of all manufacturers, US vehicle manufacturers
Ethernet DoIP ( ISO 13400 ) UDS ( ISO 14229 ) BMW AG

The vehicle-internal diagnostic communication uses the respective internal buses in the vehicle such as CAN , MOST , LIN or FlexRay for communication, whereby the K-line often no longer exists and is used as a virtual K-line e.g. B. is mapped via CAN by a central control unit.

Basic functions of diagnostic communication

Vehicle diagnostic communication basically takes place as a "question-answer game", whereby positive answers can also be suppressed or the server can send spontaneous answers as a "response on event". The vehicle diagnostic system is connected to the control unit installed in the vehicle via a client-server model, with the control unit acting as a server. The client can address a specific control device via physical addressing or send a command to all of them as a broadcast via functional addressing .

Current diagnostic protocols provide the following basic functions:

  • Selection of the diagnostic mode (session handling)
  • Authentication mechanisms using challenge-response procedures
  • Reading and writing of memory areas via identifiers and addresses
  • Control of actuators of the control unit (IO Control)
  • Access to internal error memory ( Diagnostic Trouble Codes )
  • Freely definable diagnostic services (routines)
  • Data transfer for reprogramming
  • Control of communication behavior and error memory lock
  • Control unit reset

A more detailed description can be found in Unified Diagnostic Services .

Applications

Since diagnostic communication with the control units is a relatively powerful and varied tool, it is not only used for troubleshooting, but is also available for a number of other tasks:

  • Adjustments or adaptations of newly installed parts
  • Activate or deactivate certain functions
  • Variant coding - adaptation of the control unit to the equipment variant of the vehicle
  • Calibration - writing of individual adjustment data or characteristics
  • Reprogramming of control units (flashing) - exchange of the operating software
  • Direct access to storage and IO ports in the development phase
  • Commissioning and vehicle tests in production

Reprogramming of control units (flashing)

Control units that have their application software in a flash memory can be reprogrammed directly via the diagnostic communication. This requires elementary basic software, the so-called flash loader , which contains the basic communication and access to the flash memory. The flash loader can either not be exchanged at all or only through a more complex process (transaction mechanism). KWP2000 and UDS provide the commands required for flashing:

  • Session Control - to call the flash loader
  • Communication Control - reduces bus load in order to have more bandwidth for data transmission
  • Control DTC setting - prevents fault memory entries from this on the other control units in the vehicle
  • Security Access - Protection against unauthorized access
  • Request Download - Announcement of a Flash download
  • Request Upload - Announcement of a Flash upload, often not supported
  • Transfer Data - data transfer to the control unit or from the control unit when uploading
  • Request Transfer Exit - Completion of a transfer

Further commands such as identification of the control unit, deletion of the memory, generation of identification data, checksums and signatures are generated using the usual diagnostic services, whereby the UDS specification suggests identifiers for this.

In some control units, the routines for deleting and writing the flash memory are not part of the flash loader, but are only transferred to the control unit's RAM and executed from there when required. This process is known as software interlock and has two reasons: on the one hand, the deletion routine cannot run unintentionally; on the other hand, the parameters for flash access can be influenced, which is no longer necessary with modern flash modules.

Areas of application

The vehicle diagnosis has different target groups, which as contributors or requesters are responsible for the type and scope of the vehicle diagnosis. These include:

Apart from the separate scope of OBD commands, all target groups use the same functions (diagnostic services), whereby commands and functions that are purely for the needs of the development are deactivated or completely removed after development has been completed.

Norms and standards in the field of vehicle diagnostics

  • SAE J1850 - Automotive Interface Bus Description
  • SAE J1962 - Description of the OBD II connector
  • SAE J2534 - Pass-thru Interface
  • SAE J1939 - network protocol for commercial vehicles

Web links

literature

  • Karl-Heinz Dietsche, Thomas Jäger, Robert Bosch GmbH: Automotive pocket book. 25th edition. Friedr. Vieweg & Sohn Verlag, Wiesbaden 2003, ISBN 3-528-23876-3 .
  • Robert Bosch (Ed.): Autoelectronics Autoelectronics. 5th completely revised and expanded edition. Vieweg & Sohn Verlag, Wiesbaden 2007, ISBN 978-3-528-23872-8 .
  • Kurt-Jürgen Berger, Michael Braunheim, Eckhard Brennecke: Technology automotive engineering. 1st edition. Verlag Gehlen, Bad Homburg vor der Höhe 2000, ISBN 3-441-92250-6 .
  • Kai Borgeest: Electronics in vehicle technology. 3. Edition. Springer-Vieweg, Wiesbaden 2013, ISBN 978-3-8348-1642-9 .
  • Christoph Marscholik, Peter Subke: Data communication in automobiles - basics, bus systems, protocols and applications . Hüthig, 2007, ISBN 978-3-7785-2969-0 .
  • Werner Zimmermann, Ralf Schmidgall: Bus systems in vehicle technology - protocols, standards and software architecture. 5th edition. Springer Vieweg, 2014, ISBN 978-3-658-02418-5 .
  • Florian Schäffer: Vehicle diagnosis with OBD . Elektor, ISBN 978-3-89576-173-7 .
  • Florian Schäffer: OBD - vehicle diagnostics in practice. 1st edition. Franzis, 2012, ISBN 978-3-645-65156-1 .

Individual evidence

  1. ↑ Matthias Becker: Diagnostic work in the automotive trade as a man-machine problem . W. Bertelsmann Verlag, Bielefeld 2003, ISBN 3-7639-3145-7 .
  2. ↑ Summary of Euro-5 and Euro-6