新能源汽车整车控制器系统诊断规范精选文档

新能源汽车整车控制器系统诊断规范精选文档 TTMS system office room 【TTMS16H-TTMS2A-TTMS8Q8-

整车控制器系统诊断规范—“EV160”

文件编号：“EV14”

编制：

校对：

审核：“业务高级经理”

会签：“控制系统集成主管”

批准：“部长”

XXX年XXX月

版本信息

目录

版本信息 (2)

1.参考文献 (5)

2.网络拓扑 (5)

3.诊断接口 (6)

4.诊断需求 (7)

.诊断协议 (7)

物理层 (7)

数据链路层 (7)

网络层 (7)

应用层时间参数 (8)

.Diagnostic Services（ISO14229-1） (8)

Supported Diagnostic Services (9)

DiagnosticSessionControl（10H） (11)

ECUReset (11H) (13)

CommunicationControl（28H） (14)

SecurityAccess（27H） (15)

TesterPresent（3EH） (21)

ControlDTCSetting(85H) (21)

ReadDataByIdentifier（22H） (23)

WriteDataByIdentifier (2EH) (24)

InputOutputControlByIdentifier (2FH) (26)

ClearDiagnosticInformation (14H) (27)

ReadDTCInformation (19H) (28)

RoutineControl (31H) (35)

RequestDownLoad(34H) (37)

TransferData (36H) (37)

RequestTransferExit (37H) (37)

5.故障定义 (38)

6.故障码DTC中英文对照表 (38)

附录 A: 冻结帧信息 (39)

附录 B: (41)

版本信息参数列表： (41)

数据流参数列表： (41)

版本信息参数定义 (43)

数据流参数定义 (45)

1.参考文献

2.网络拓扑

“由网络工程师统一发布网络拓扑”

Fig 1.C70GB-2014整车网络拓扑结构

3.诊断接口

Tab 1.OBD 诊断接口针脚定义

“由线束工程师统一发布OBD接口定义”

4.诊断需求

4.1.诊断协议

4.1.1.物理层

物理层应满足ISO11898-2要求及北京新能源汽车股份有限公司企业标准《新能源汽车高速 CAN 网络节点级电子控制单元（ ECU）技术要求》要求。

4.1.2.数据链路层

数据链路层应满足ISO11898-1要求。

所有诊断请求和应答帧的数据长度应为8字节，否则电控单元将忽略该诊断请求帧。当诊断响应长度不足8字节时，空余的字节应用0xAA填充。

4.1.3.网络层

网络层应满足ISO15765-2要求和下述要求：

4.1.3.1.寻址方式

可以支持物理寻址和功能寻址。

诊断消息ID描述见下表：

D列表

“由网络工程师统一发布所有诊断ID分配，各系统填写各自的诊断ID至上表”

4.1.3.2.网络层时间参数

Tab 3.网络层时间参数需求

4.1.4.应用层时间参数

Tab 4.应用层时间参数需求

4.2.Diagnostic Services（ISO14229-1）

Services shall be implemented according to ISO14229-1. Additional details are specified in this section.

4.2.1.Supported Diagnostic Services

The overview of ECU supported diagnostic services is described in the following table.

The services need to support suppressPositveResponseBit (SPRS) are showed in following table.

according to the following priority rules：

?The 7Fh NRC have the highest priority;

?For others, the NRC with smaller number has higher priority.

4.2.2.DiagnosticSessionControl（10H）

This service is used by the client to enable different diagnostic sessions in the server(s). A diagnostic session enables a specific set of diagnostic services in the server(s).

4.2.2.1.Message Format

Timing P2*server value is provided in 10ms resolution.

4.2.2.2.Implementation Rules

This service is used by the diagnostic tool to enable different types of diagnostic sessions in a server. In order to execute a diagnostic service the appropriate session has to be started shall be only one diagnostic session active at a time.

Normal/Default Session (01h) shall be enabled automatically by the ECU if no diagnostic session has been requested at power up.

The ECU shall return to Normal/Default Session (01h) after timeout of ExtendedDiagnostic Session.

The ECU shall be capable of providing all diagnostic functionality defined for the default diagnostic session under normal operating conditions.

The ECU shall first send a DiagnosticSessionControl Positive Response (50h xx) message before the new session becomes active in the ECU.

A DiagnosticSessionControl Positive Response (50h xx) message shall be returned by an ECU if the diagnostic tool requests a session that is already running. If the ECU has already received the same request message previously and performed the requested operation, the ECU shall continue to perform the current operation . it is not a change of the session).

The ECU shall remain in its current diagnostic session if it is not able to switch into the requested diagnostic session.

The TesterPresent (3Eh) service shall be used to keep the non-default diagnostic sessions active by retriggering S3server. Also any other service request shall retrigger S3server.

A functional TesterPresent (3Eh) request without response may be sent at any time, even regardless of any other service in progress.

When receiving or transmitting any diagnostic messages, including 3Eh service, the

S3servertimer will reset.

Fig 3.Session transition diagram

4.2.3.ECUReset (11H)

This service requests the server to effectively perform an ECU reset based on the content of the ResetType parameter value (suppressPosRspMsgIndicationBit (bit 7) not shown).

4.2.3.1.Message Format

4.2.3.2.Implementation Rules

The positive response shall be sent before performing the ECU reset.

The execution of reset will take ms, which means the ECU can’t respond to any new request sent within this time.

https://www.360docs.net/doc/8615537927.html,municationControl（28H）

The service is used to “switch on/off” the transmission and/or the reception of certain messages of (a) server(s).

4.2.4.1.Message Format

4.2.4.2.Implementation Rules

There are no special general implementation rules for this service.

4.2.

5.SecurityAccess（27H）

The purpose of this service is to provide a means to access data and/or diagnostic services, which have restricted access for security or safety reasons. Diagnostic services for downloading/uploading routines or data into a server and reading specific memory locations from a server are situations where security access may be required. Improper routines or data downloaded into a server could potentially damage the electronics or other vehicle components or risk the vehicle’s compliance to safety, or security standards. The security concept uses a seed and key relationship.

The client shall request the server to unlock by sending the service SecurityAccess-RequestSeed message. The server shall respond by sending a seed. The seed is the input parameter for the key calculation algorithm. It is used by the client to calculate the corresponding key value.

In a second step, the client shall request the key comparison by sending the calculated key to the server using the appropriate service SecurityAccess-SendKey. The server shall compare this key to one internally stored/calculated. If the two numbers match, then the server shall enable

(unlock) th e client’s access to specific services/data and indicate that with the service SecurityAccess-SendKey. If the two numbers do not match, this shall be considered as a false access attempt. If access is rejected for any other reason, it shall not be considered as a false access attempt. An invalid key requires the client to start over from the beginning with a SecurityAccess-RequestSeed message.

If a server supports security, but is already unlocked when a SecurityAccess-RequestSeed message is received, that server shall respond with a SecurityAccess-RequestSeed positive response message service with a seed value equal to zero (0). The client shall use this method to determine if a server is locked by checking for a non-zero seed.

The Seed-Key algorithmfor SecurityAccess（Mandatory）：

Key = ((((seed>>4) XOR seed)<<3) XOR seed)。

The Security Seed is 4Bytes random numbers.

Fig 4.Security Access procedure

4.2.

5.1.Message Format

4.2.

5.1.1.Request Seed

This service requests a seed from the server. Based on this seed, the client is able to calculate the corresponding key to be sent for unlocking the server.

4.2.

5.1.2.Send Key

This service sends a key calculated by the client to the server. The server shall compare this key to one internally stored/calculated. If the two numbers match, then the server shall enable (“unlock”) the client’s access to specific services/data.

4.2.

5.2.Implementation Rules

After PowerOn/Reset the ECU is in locked state. The security access failure counter is set to 0.

The ECU shall wait 10 s before accepting the first RequestSeed message after

EcuReset/PowerOn.

After the third failure attempt the ECU shall wait 10s before accepting the next “Request Seed” message. A flag is stored in the EEPROM of the ECU. On every PowerOn/Reset, the ECU checks for this flag,then waits again 10s before accepting the next “Request Seed” message (It is allowed to implement the Security Access requirement without based on the Flag ) Any SecurityAccess request during this time will be rejected with the negative response code “Required time delay not expired” (37h).

If the tester requests a seed, it has to send the corresponding key to the ECU. This sequence is mandatory. If the tester sends a consecutive “Request Seed”, the request is accepted and the same seed is returned, but the security access failure counter is incremented.

If the tester sends an invalid key, the request is rejected with negative response code “InvalidKey”, the sequence shall be reset (any current seed becomes invalid) and the security access failure counter is incremented.

When the security counter reaches the value of 3 . 3 failed tries), the ECU shall wait 10s before accepting another “Request Seed” message. Any such request during this time will be rejected with the negative response code “Required time delay not expired” (37h). When the 10s wait time is elapsed the security access failure counter is decremented by one and another try is allowed. When during this try the security access failure counter is incremented again (due to an invalid key), the ECU shall wait again 10s before accepting another “Request Seed” message. When this try is valid, the security access failure counter is not changed.

BJEV uses four states (three different levels): Locked, Unlocked (Level 1), Unlock (Level 2) and Unlocked (Flash). The ECU could support some of them according to the requirement.

Fig 5.SecurityAccess

Fig 6.SecurityAccess NRC requirements

4.2.6.TesterPresent（3EH）

This service shall be used to indicate to a server that the client is present. This service is required in the absence of other UDS services to prevent servers from automatically returning to normal operation and stop communication.

4.2.6.1.Message Format

4.2.6.2.Implementation Rules

There are no special general implementation rules for this service.

4.2.7.ControlDTCSetting(85H)

This service is used to enable and disable the setting of Diagnostic Trouble Codes, DTCs, in the ECU(s).

The ControlDTCSetting request message can be used to stop the setting of diagnostic trouble codes in an individual server or a group of servers. If the server being addressed is not able to stop the setting of diagnostic trouble codes, it shall respond with a ControlDTCSetting negative response message indicating the reason for the reject.

4.2.7.1.Message Format

4.2.7.2.Implementation Rules

The setting of DTCs in the ECU shall be switched off directly after the request ControlDTCSetting with setting mode 2 (switch off) is received (Option: Suppress positive response message indication bit is set) or after successful transmission of the positive response (Option: Suppress positive response message indication bit is not set).

The setting of DTCs in the ECU shall be switched on again, when one of the following events occurs:

The request ControlDTCSetting with setting mode 1 (switch on) is received (Option: Suppress positive response message indication bit is set) or after successful transmission of the positive response (Option: Suppress positive response message indication bit is not set).

The ECU power supply voltage is down (reset or ECU power down event).

The diagnostic session changes from Extended Diagnostic Session to Default Session.

The services ReadDTCInformation - ReportDTCByStatusMask, ReadDTCInformation - ReportSupportedDTCand ClearDiagnosticInformation shall not be affected by this service. 4.2.8.ReadDataByIdentifier（22H）

The request message requests data record values from the server by one or more dataIdentifier(s).

When receiving a ReadDataByIdentifier request, the server will access the data elements of the records specified by thedataIdentifier parameter(s) and transmit their value in ReadDataByIdentifier positive response containing theassociated dataRecord parameter(s).

4.2.8.1.Message Format