北京新能源机动车整车控制器系统诊断标准规范

\\

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

文件编号：“EV160-20150002014”

编制：

校对：

审核：“业务高级经理”

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

批准：“部长”

XXX年XXX月

版本信息

目录

版本信息 (2)

1.参考文献 (5)

2.网络拓扑 (5)

3.诊断接口 (6)

4.诊断需求 (7)

4.1.诊断协议 (7)

4.1.1.物理层 (7)

4.1.2.数据链路层 (7)

4.1.3.网络层 (7)

4.1.4.应用层时间参数 (8)

4.2.Diagnostic Services（ISO14229-1） (8)

4.2.1.Supported Diagnostic Services (9)

4.2.2.DiagnosticSessionControl（10H） (11)

4.2.3.ECUReset (11H) (13)

https://www.360docs.net/doc/3318318255.html,municationControl（28H） (14)

4.2.5.SecurityAccess（27H） (15)

4.2.6.TesterPresent（3EH） (21)

4.2.7.ControlDTCSetting(85H) (21)

4.2.8.ReadDataByIdentifier（22H） (23)

4.2.9.WriteDataByIdentifier (2EH) (24)

4.2.10.InputOutputControlByIdentifier (2FH) (26)

4.2.11.ClearDiagnosticInformation (14H) (27)

4.2.12.ReadDTCInformation (19H) (28)

4.2.13.RoutineControl (31H) (35)

4.2.14.RequestDownLoad(34H) (37)

4.2.15.TransferData (36H) (37)

4.2.16.RequestTransferExit (37H) (37)

5.故障定义 (38)

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

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

附录B: (42)

B.1 版本信息参数列表： (42)

B.2 数据流参数列表： (42)

B.3 版本信息参数定义 (44)

B.4 数据流参数定义 (46)

1.参考文献

2.网络拓扑

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

Fig 1.C70GB-2014整车网络拓扑结构3.诊断接口

Fig 2. OBD诊断接口

管脚描述

1 EVBUS CAN_H

2 /

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描述见下表：

Tab 2.诊断ID列表

“由网络工程师统一发布所有诊断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.

Table 5 Supported diagnostic services of ECU

说明：访问权限√1表示需要扩展安全级权限，√3表示需要编程安全级权限。

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

The negativeResponseCodes (NRC) used by ECU are defined as follows:

If two or more NRCs are reasonable, the ECU could send the negative response

message 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 P2server value is provided in 1ms resolution.

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 first.There 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 (i.e. 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

Byte Name Cvt Value(hex)

#1 RequestServiceIdentifier M 11

#2

Sub-Function= [

ResetType: HardReset

SoftReset]

M 01

03 Positive Response：

Byte Name Cvt Value #1 PositiveResponseServiceIdentifier M 51

#2

Sub-Function=[

ResetType: HardReset

SoftReset]

M 01

03 Negative Response：

Byte Name Cvt Value

#1 NegativeResponseServiceIdentifier M 7F

#2 RequestServiceIdentifier M 11

#3 NegativeResponseCode M NRC

Option (Hex) Description Cvt 01 HardReset

This value identifies a “hard reset” condition which simulates the

M

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/3318318255.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) the 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.

Tester

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 (i.e. 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