Specifications related to bus diagnostics

1. Introduction
1.1 Scope
This document is for electronic control unit quotation materials only. All ECUs should cover the requirements defined in this document, but are not limited to the content of this document. Each ECU can add requirements based on its own functions.
1.2 Purpose
This document is specially formulated to enable suppliers to understand the requirements for ECU diagnostic development in detail in the early stage. This document is only used as a reference material for the diagnostic part of each ECU's quotation material. The specific content needs to be combined with the ECU's own functions.
2. Diagnosis requirements
The ECU should have diagnostic functions, including self-diagnosis during power-on initialization and real-time diagnosis while the ECU is running. External devices can read ECU faults and other information through the OBD interface.
2.1 Diagnosis reference standards
Diagnosis is unified as CAN-based diagnosis. The reference standards corresponding to the seven OSI layers are shown in Table 1.

2.2 Diagnostic requirements document
ECU must be developed, designed, tested and verified in strict accordance with the diagnostic requirements document. The detailed list is shown in Figure 1. The diagnostic requirements document is an internal confidential document. It will only be provided by the ECU engineer to the relevant supplier when the project kicks off after the supplier has designated it, and will be signed and confirmed on the spot. After the supplier receives the requirements document, he will read all documents within one month and provide feedback.

2.3 ECU diagnostic performance requirements
∎ The ECU must ensure that diagnostic communication can be performed when 7V<U<18V;
∎ The ECU at least includes Flash ROM, EEPROM, and RAM memory. When the ECU fails, it can store the fault code and related fault information in EEPROM or other non-volatile memory. It can store at least 15 DTCs and related fault information (the specific number is determined by the DRE and is stated in the CTS) ;
 All ECUs can clear fault codes, including current fault codes, through the $14 service. If there are special circumstances, they need to be noted in the CTS. In addition, all ECUs also have other methods to automatically clear historical fault codes. For example, if the fault is not found after 40 ignition cycles, the historical fault codes and related information in the memory will be automatically cleared; ∎ ECU supports $10, $11, $14
, Basic diagnostic services such as $19, $22, $27, $28, $2E, $2F, $31, $34, $36, $37, $3E, $85, etc. The specific content and requirements of each service must meet the diagnostic design specifications of GAEI; among them, $10, $11 , $14, $19, $22, and $3E services are supported in both default mode and extended mode; $27, $28, $2E, $2F, and $85 services are only supported in extended mode; $34, $36, and $37 services are only supported in programming mode ; The $31 service is supported in extended mode and programming mode;
∎ The $19 service supports at least sub-functions $01, $02, $04, $06, $0A. External devices can read the number of faults, fault codes, Snapshot, Extended data and other data from the ECU. Fault codes supported by ECU;
 ECU requires safety restrictions for special functions. The seed and key requirements are 4 bytes, and the seed is random, not fixed. The supplier has the ability to provide security algorithms, ensure the security and reliability of the algorithms, and provide security algorithms for review and confirmation within the specified time;
 The ECU supports the CAN-based Flash bootloader function and is developed in strict accordance with the Flash specifications. The Flash driver cannot be fixed inside the ECU and is temporarily downloaded to the ECU every time the ECU is refreshed;

 ECU supports some special functions, such as writing of configuration information, parameter calibration, parameter adjustment, and DTC setting shielding function ($2E service).
2.4 ECU diagnostic integration and testing requirements
 Must ensure that diagnostic functions are integrated one month before ET2, including at least $10, $11, $14, $19, $22, $3E functions; ∎ The second test
sample in the ET2 stage must integrate all diagnostic functions , including FBL function;
 Before suppliers provide samples, they must conduct tests in strict accordance with the test specifications and provide test reports (except for FBL function). Every time a sample is provided, a corresponding test report must be attached! If no test report is provided, testing will not be performed and the sample will be deemed to have no diagnostic function or no change in diagnostic function. The diagnostic test includes the following 4 parts:
 Diagnostic communication test, providing diagnostic communication test report;
(Corresponding to the requirements of ISO14229, ISO15765-2, diagnostic specifications)
 Diagnostic function test, providing diagnostic function test report;
(Corresponding to diagnostic specifications, ECU diagnostic parameters List, Failsafe specification requirements)
 Diagnostic system test, provide diagnostic system test report;
(Corresponding to the requirements of the diagnostic system specification)
 FBL functional test, provide FBL functional test report;
(Corresponding to the requirements of the refresh specification)
 For the provided diagnostic verification For the test report, the supplier needs to provide feedback within one week, including the cause of the problem and the rectification plan; rectification is guaranteed within one month. If rectification cannot be made on time, please give the reason!
 

Guess you like

Origin blog.csdn.net/weixin_45905610/article/details/132900773