07/31/2020 |
Figure 1: Process sequence of a DTC
The error codes (DTCs) used today are based on the flashing codes of control units that were measured by counting. With the increasing complexity of electronics and thus more and more complicated error conditions, such proprietary diagnostic proce-dures are no longer sufficient. Thus, the development led to the currently known 2-byte (OBD legislated codes) and 3-byte DTCs (UDS standardized).
With the data obtained during diagnosis, the cause of the fault and its effect on ve-hicle functions can be analyzed. This is done in order to enable efficient and effec-tive troubleshooting and to be able to continue to operate or repair the vehicle, pos-sibly with restrictions.
Due to the existing cost pressure, it makes sense for vehicle manufacturers and their suppliers to cooperate and use common exchange formats. In embedded elec-tronics development, this resulted in the DEXT format of AUTOSAR and, for off-board diagnostics, the comparable ODX format of ASAM.
The path of a DTC from detection in an electronic control unit to diagnosis in the workshop is shown in the cover picture (Figure 1).
The application software cyclically monitors the signals for compliance with the relevant limit values using monitors also known as diagnostic functions. Compliance or non-compliance with the limit values is signaled to the Diagnostic Manager (DM) in the form of events.
Figure 2: One monitor for battery monitoring with two events
The actual monitoring function with its limit values, in the above figure 11.2 V and 15.2 V remain proprietary, but the events of the applications are defined in DEXT.
The events of the monitors are assigned to the specific DTC and are transported to the DM via Middleware. Error codes are primarily intended for the Aftersales Service and depend on the respective diagnostic strategy. Typically, the OEM determines the DTC to be used uniformly for its vehicles.
Several events can also be assigned to the same DTC. The two events “EventOver-Voltage” and “EventUnderVoltage” could be assigned to two different DTCs or have only one common DTC, such as “PowerSupply”.
An authoring tool should link the events of the monitors with the DTC of the respec-tive OEM for an ECU. Since not every monitor has to send an event, but every DTC in DM needs at least 4 bytes of memory, unused DTC must be removed.
Not every small fault should immediately generate a DTC and thus trigger the asso-ciated fault reaction. If, for example, the battery voltage is too low for a few seconds, then switching off the ABS is simply an overreaction. For this reason most events are debounced.
After all there are three different strategies, which differ considera-bly in their definition.
In addition to the 3 debouncing strategies described above, there are numerous oth-er settings in DEXT which influence the exact behavior of a DTC. Examples are the saving of the debounce counter in non-volatile memory, the reset of the debounce counter at ClearDTC and the reset at a new operation cycle.
If a DTC is stored as confirmed, the vehicle must react appropriately to this error. The vehicle manufacturer analyses such faults and their effects during the development of the vehicle. This is typically described with the aid of an FMEA (Failure Mode and Effects Analysis) and the corresponding reactions of the vehicle are deter-mined. The FIM ultimately implements the parts of the FMEA in the control unit.
The operation cycle is a defined cycle in the vehicle and the pulse for DTC ➄. It en-sures that DTC are created and also recover again.
Driven and dependent on this pulse, each DTC has a dynamic status defined in ISO 14229-1:2013 (UDS standard). Bits 0 to 6 of the StatusOfDTC describe where the
DTC is currently located in its life cycle.
Figure 3: The dynamic behavior of DTC in the vehicle
The figure above shows an example of the dynamic behavior of a DTC with cyclic monitor. The cycle is started with “ignition on”.
An error code with status is only sufficient for simple errors. For more complex errors, the environmental conditions such as speed, temperature, velocity and possibly other internal information are also required for a more precise analysis of an error.
The retrieval of measured values is already possible without DTC via the ReadDataByIdentifier UDS service. For a meaningful analysis, the measured values must also match the exact time of the triggering event. If a monitor reports “Failed”, the relevant DIDs are temporarily stored with their measured values.
Figure 4: Details of DTC Snapshot Data (FreezeFrames)
The data structure of a snapshot record corresponds to a sequence of individual DIDs from the ReadDataByIdentifier service. There is a large overlap with ODX. If the DID used for a DTC and their data structures are known, the ODX data for readDataByIdentifier and readDTC can be generated from the DEXT information and vice versa.
The Extended Data Block contains additional information about a DTC such as cycle counters, aging counters, time of last occurrences, … and dynamic data of algorithms that are not already contained in the FreezeFrame data. Similar to the DIDs, a 1-byte record number specifies the data structure of the Extend-ed Data block.
Figure 5: Details of DTC Extended Data
Up to 255 stored ExtendedDataRecords can exist for a DTC. The interpretation of the data is unambiguously determined by its RecordNumber.
The description of snapshot data and extended data are in principle very similar for ODX and DEXT. There is, however, a large amount of additional information in DEXT, such as severity, debouncing, malfunction indicator, function inhibit, which is not contained in ODX, but is mandatory for a DTC in an ECU.
The last step on the way to the tester is the DCM, which is responsible for encoding and transmitting the data to the tester. With the ReadDTC (0x19) UDS service, a DTC is encoded as a two or three-byte value according to the set DTC format and transmitted via the vehicle bus.
Depending on the selected 0x19-ReadDTC subfunction, the FreezeFrame or the corresponding ExtendedData information must be decoded in the tester in addition to the DTC. Of course, the coding of the UDS data in the ECU, based on DEXT, must be identical to the decoding based on ODX.
Figure 6: DTCs and associated data objects
There are additional challenges for Tester➇. First of all, he must find out the specific vehicle and select the appropriate VehicleInformationTable (VIT) from ODX. Then the exact SW version of the ECUs installed in the vehicle, or in the case of Adaptive AUTOSAR, the Software Cluster (SWC), is determined by means of variant identification. For this reason, the ODX data of each ECU contains the necessary interpretation for the various software variants.
In addition to data interpretation and variants, other data are also present in ODX, such as audience, speech information and meta-information, which in turn are missing in DEXT.
ODX and DEXT are exchange formats that have proven themselves in practice and are widely used. A large part of the contents of DEXT and ODX for a DTC are equivalent. However, both formats do not contain all the necessary information for a DTC.
DEXT reflects the variability of vehicle electronics. In ODX, the various software versions of an ECU accumulate over the lifetime of a vehicle.
Figure 7: Uniform data assignment process for DTCs and DIDs
If all this information is combined in a common database, the only source of truth is created. This ensures that ODX and DEXT files always contain the same information and are therefore consistent.
KPIT has already implemented these findings in its K-DCP ECU Editor. The SW developers can focus on the technical characteristics of a DTC and the relevant information and do not need to know any format details. The diagnostic developers then enter additional diagnosis-relevant metadata (texts, variants, …). By jointly storing this data in the KPIT ECU Editor, the necessary ODX and DEXT files are generated consistently, redundancy and contradiction-free at the push of a button and can also be re-imported.
Given the complexity of DTCs with their dependencies on extended and freeze-frame data, the diversity that arises due to the variability of the ECU and variants of the software, such a common process with a single common database is almost mandatory. For more information, see the Hanser article “Diagnosis in Adaptive AUTOSAR” from issue 10/2019.
KPIT is a global technology company with software solutions that will help mobility leapfrog towards autonomous, clean, smart and connected future. With 7000+ Automobelievers across the globe, specializing in embedded software, AI & Digital solutions, KPIT enables customers accelerate implementation of next generation mobility technologies . With development centers in Europe, USA, Japan, China, Thailand and India – KPIT works with leaders in mobility and is present where the ecosystem is transforming.
Stefanie Köhler
Head of Marketing Germany
Phone: +49 89 322 99 66 140
Stefanie.koehler@kpit.com
Manesh Khushu
Diagnostic Product Marketer,
Phone: +9198331 19405,
manesh.khushu@kpit.com
Diagnostics Subject Matter Expert,
KPIT Technologies
Recommend
218 likes
Diagnostic Trouble Code
Hanser Automotive
Vehicle diagnostics
Recommend
218 likes
Plot Number-17,
Rajiv Gandhi Infotech Park,
MIDC-SEZ, Phase-III,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Munich, GERMANY
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
