北京新能源汽车整车控制器系统诊断规范方案

.整车控制器系统诊断规范EV160文件编号：EV160-20150002014编制：校对：审核：业务高级经理会签：控制系统集成主管批准：部长XXX年XXX月版本信息版本日期编制校对审核更新描述V1.0初始版本V1.120151127崔晓静崔晓静1、 修改数据链路层描述；2、 删除31服务的02子服务；3、 删除28服务的01、02子服务；4、 删除27 03、04子服务；5、 27添加seed为四个字节的随机数；6、 seed和key在列表中定4个字节；7、 删除2F 02子服务；8、 删除19 06子服务；9、 status改为仅bit0、3支持10、删除NRC11；11、F184修改为9个字节；12、添加故障码中英文对照表；目录版本信息21.参考文献52.网络拓扑53.诊断接口64.诊断需求74.1.诊断协议74.1.1.物理层74.1.2.数据链路层74.1.3.网络层74.1.4.应用层时间参数84.2.Diagnostic ServicesISO14229-184.2.1.Supported Diagnostic Services94.2.2.DiagnosticSessionControl10H114.2.3.ECUReset 134.2.4.CommunicationControl28H144.2.5.SecurityAccess27H154.2.6.TesterPresent3EH214.2.7.ControlDTCSetting214.2.8.ReadDataByIdentifier22H234.2.9.WriteDataByIdentifier 244.2.10.InputOutputControlByIdentifier 264.2.11.ClearDiagnosticInformation 274.2.12.ReadDTCInformation 284.2.13.RoutineControl 354.2.14.RequestDownLoad374.2.15.TransferData 374.2.16.RequestTransferExit 375.故障定义386.故障码DTC中英文对照表38附录 A: 冻结帧信息39附录 B:41B.1 版本信息参数列表：41B.2 数据流参数列表：41B.3 版本信息参数定义43B.4 数据流参数定义45术语DTC故障诊断码BS Block sizeSTminMinimum Separation Time C有条件的M强制性执行U用户选用TBD待定义SID服务标识符DID数据标识符NRC负响应码UDS统一的诊断服务Server服务器Client客户端ECU电控单元1. 参考文献NO.参考文档题目1 ISO11898-1: 2003 Road vehicles - Controller area network Part 1:Data link layer and physical signaling 2 ISO11898-2: 2003 Road vehicles - Controller area network Part 2: High-speed medium access unit 3 ISO11898-5: 2007 Road vehicles - Controller area network Part 5: High-speed medium access unit with low-power mode 4 ISO15765-2: 2004 Road Vehicle - Diagnostic on CAN Part 2: Networking Layer Services 5 ISO15765-3: 2004 Road Vehicle - Diagnostic on CAN Part 3: Application Layer Services 6 ISO14229-1: 2006 Road Vehicle - Diagnostic Systems Diagnostic Services Specification 7 ISO15031-6: 2005 Road vehicles - Communication between vehicle and external equipment for emission-related diagnostic Part 6: Diagnostic trouble code definitions 2. 网络拓扑由网络工程师统一发布网络拓扑Fig 1. C70GB-2014整车网络拓扑结构3. 诊断接口Fig 2. OBD诊断接口管脚描述1EVBUS CAN_H2/3/4接地5接地6/7/8/9EVBUS CAN_L10/11/12/13/14/15/16电源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描述见下表：控制器名称简称物理寻址诊断请求ID诊断响应ID功能寻址诊断请求ID实施网段驱动电机控制器MCU0x7E00x7E80x7DFEVBUSTab 2. 诊断 ID列表由网络工程师统一发布所有诊断ID分配,各系统填写各自的诊断ID至上表4.1.3.2. 网络层时间参数ParameterValueUnit BS 8- STmin 20msParameterTimeout Performance Requirement Unit N_As/N_Ar 70 n/a ms N_Br n/a 70 ms N_Bs 150 n/a ms N_Cs n/a 70 ms N_Cr 150 n/a ms Tab 3. 网络层时间参数需求4.1.4. 应用层时间参数ParameterMin Max Timeout Unit P2server 0 50 n/a msP2client n/a n/a 150 msP2*server 0 2000 n/a msP2* clientn/an/a5000msP3client_phys2 P2server n/a n/a ms P3client_func P2server_max n/a n/a ms ParameterMin Nominal Timeout Unit S3server n/a n/a 5000 ms S3client 0 2000 4000 ms Tab 4. 应用层时间参数需求4.2. Diagnostic ServicesISO14229-1Services shall be implemented according to ISO14229-1. Additional details are specified in this section.4.2.1. Supported Diagnostic ServicesThe overview of ECU supported diagnostic services is described in the following table.Table 5 Supported diagnostic services of ECUDiagnostic Services ListSessionSecurityAccessAddressingSID Service NameDefaultExtendedProgrammingPhysical AddressFunction Address10DiagnosticSessionControl 11EcuReset 27SecurityAccess 28CommunicationControl 3ETesterPresent 85ControlDTCSetting 22ReadDataByIdentifier 2EWriteDataByIdentifier 13 2FInputOutputControlByIdentifier 114ClearDiagnosticInformation 19ReadDTCInformation 31RoutineControl 13 34RequestDownLoad336TransferData337RequestTransferExit3说明：访问权限1表示需要扩展安全级权限,3表示需要编程安全级权限。The services need to support suppressPositveResponseBit are showed in following table.Tab 5. Services supported SPRS bitDiagnostic Services ListSupportSPRS bitSIDService Name10DiagnosticSessionControl11EcuReset27SecurityAccess28CommunicationControl3ETesterPresent85ControlDTCSetting22ReadDataByIdentifier2EWriteDataByIdentifier14ClearDiagnosticInformation19ReadDTCInformation2FInputOutputContorlByIdentifier31RoutineControl34RequestDownload36TransferData37RequestTransferExitThe negativeResponseCodes used by ECU are defined as follows:Tab 6. Negative Response CodesNRCDescription11HserviceNotSupported12HsubFunctionNotSupported13HincorrectMessageLengthOrInvalidFormat22HconditionsNotCorrect24HrequestSequenceError36HexceededNumberOfAttempts31HrequestOutOfRange33HsecurityAccessDenied37HrequiredTimeDelayNotExpired35HInvalidKey72HgeneralProgrammingFailure78HresponsePending7FHserviceNotSupportedInActiveSession92H/93HVoltageTooHigh / voltageTooLow7EHsubFunctionNotSupportedInActiveSessionIf 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. DiagnosticSessionControl10HThis service is used by the client to enable different diagnostic sessions in the server. A diagnostic session enables a specific set of diagnostic services in the server.4.2.2.1. Message FormatRequest：ByteNameCvtValue#1RequestServiceIdentifierM10#2Sub-function = DefaultSession ProgrammingSessionExtendedDiagnosticSession M010203Positive Response：ByteNameCvtValue#1PositiveResponseServiceIdentifierM50#2Sub-Function=DefaultSessionProgrammingSessionExtendedDiagnosticSession M010203P2server =#3byte#1M00-FF#4byte#2M00-FFP2*server =#5byte#1M00-FF#6byte#2M00-FFTiming P2server value is provided in 1ms resolution.Timing P2*server value is provided in 10ms resolution.Negative Response：ByteNameCvtValue#1NegativeResponseServiceIdentifierM7F#2RequestServiceIdentifierM10#3NegativeResponseCodeMNRCSub-function Parameter DefinitionHEXDescription Cvt01 DefaultSessionThis diagnostic session enables the default diagnostic session in the serverand does not support any diagnostic application timeout handling provisions. .M02ProgrammingSessionThis diagnostic session enables all diagnostic services required to supported the memory programming of a server.M03 ExtendedDiagnosticSessionThis diagnostic session can e.g. be used to enable all diagnostic services required to support the adjustment of functions like Idle Speed, CO Value, etc. in the servers memory. It can also be used to enable diagnostic services, which are not specifically tied to the adjustment of functions.MNegative Response Codes NRCDescriptionCvt12 The sub-function parameter in the request message is not supported.M13 The length of the message is wrong.M22 The ECUcurrent conditions do not allow the change ofdiagnostic Session.M4.2.2.2. Implementation RulesThis 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 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 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 message before the new session becomes active in the ECU.A DiagnosticSessionControl Positive Response 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 .The ECU shall remain in its current diagnostic session if it is not able to switch into the requested diagnostic session.The TesterPresent 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 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 diagram4.2.3. ECUReset This service requests the server to effectively perform an ECU reset based on the content of the ResetType parameter value suppressPosRspMsgIndicationBit not shown.4.2.3.1. Message FormatRequest：ByteNameCvtValue#1RequestServiceIdentifierM11#2Sub-Function= ResetType: HardResetSoftResetM0103Positive Response：ByteNameCvtValue#1PositiveResponseServiceIdentifierM51#2Sub-Function= ResetType: HardResetSoftResetM0103Negative Response：ByteNameCvtValue#1NegativeResponseServiceIdentifierM7F#2RequestServiceIdentifierM11#3NegativeResponseCodeMNRCSub-function Parameter DefinitionOption Description Cvt01 HardResetThis value identifies a hard reset condition which simulates the power-on / start-up sequence typically performed after a server has been previously disconnected from its power supply .M03SoftResetThis value identifies a soft reset condition, which causes the server to immediately restart the application program if applicable. The performed action is implementation specific and not defined by the standard. A typical action is to restart the application without reinitializing of previously learned configuration data, adaptive factors and other long-term adjustments.MNegative Response Codes NRC Conditions Cvt12 Sub-function parameter in the request message is not supported. M13 The length of the message is wrong M22The criteria for the ECUReset request are not met.M4.2.3.2. Implementation RulesThe positive response shall be sent before performing the ECU reset.The execution of reset will take ms, which means the ECU cant respond to any new request sent within this time.4.2.4. CommunicationControl28HThe service is used to switch on/off the transmission and/or the reception of certain messages of server.4.2.4.1. Message FormatRequest：ByteNameCvtValue#1RequestServiceIdentifierM28#2Sub-Function = EnableRxAndTxDisableRxAndTx M0003#3CommunicationType= NormalCommunicationMessagesNetworkManagementCommunicationMessages NetworkManagementCommunicationMessagesAndNormalCommunicationMessages M010203Positive Response：ByteNameCvtValue#1PositiveResponseServiceIdentifierM68#2Sub-Function = EnableRxAndTxEnableRxAndDisableTx DisableRxAndEnableTxDisableRxAndTx M00010203Negative Response：ByteNameCvtValue#1NegativeResponseServiceIdentifierM7F#2RequestServiceIdentifierM28#3NegativeResponseCodeMNRCNegative Response CodesNRC Conditions Cvt12 Sub-function parameter in the request message is not supported. M13 The length of the message is wrongM22The operating conditions of the server are not met to perform the required action.M31None of the requested CommunicationType values are supported by the device.MSub-function Parameter Definition：OptionDescription Cvt00EnableRxAndTxThis value indicates that the reception and transmission of messages shall be enabled for the specified CommunicationType.M03DisableRxAndTxThis value indicates that the reception and transmission of messages shall be disabled for the specified CommunicationType.MData Parameter Definition：OptionDescription Cvt01NormalCommunicationMessagesThis value references all application-related communication .M02NetworkManagementCommunicationMessagesThis value references all network management related communication.M03NetworkManagementCommunicationMessagesAndNormalCommunicationMessagesThis value references all network management and application-related communicationM4.2.4.2. Implementation RulesThere are no special general implementation rules for this service.4.2.5. SecurityAccess27HThe 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 vehicles 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 the clients 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 . The client shall use this method to determine if a server is locked by checking for a non-zero seed.The Seed-Key algorithmfor SecurityAccessMandatory：Key = 4 XOR seed XOR seed。The Security Seed is 4Bytes random numbers.Fig 4. Security Access procedure4.2.5.1. Message Format4.2.5.1.1. Request SeedThis 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.Request：ByteNameCvtValue#1RequestServiceIdentifierM27#2SecurityAccessType = RequestSeedM01,11Positive Response：ByteNameCvtValue#1PositiveResponseServiceIdentifierM67#2SecurityAccessType = RequestSeedM01,11SecuritySeed = M#3seed#1 M00-FF#6seed#m M00-FFNegative Response：ByteNameCvtValue#1NegativeResponseServiceIdentifierM7F#2RequestServiceIdentifierM27#3NegativeResponseCodeMNRCNegative Response CodesNRC Conditions Cvt12 Sub-function parameter in the request message is not supported. M13 The length of the message is wrong.M22 The criteria for the SecurityAccess request are not met.M37requiredTimeDelayNotExpiredM4.2.5.1.2. Send KeyThis 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 the clients access to specific services/data.Request：ByteNameCvtValue#1RequestServiceIdentifierM27#2SecurityAccessType = SendKeyM02,12SecurityKey = M#3key#1 M00-FF#6key#m M00-FFPositive Response：ByteNameCvtValue#1PositiveResponseServiceIdentifierM67#2SecurityAccessType = SendKeyM02,12Negative Response：ByteNameCvtValue#1NegativeResponseServiceIdentifierM7F#2RequestServiceIdentifierM27#3NegativeResponseCodeMNRCNegative Response CodesNRC ConditionsCvt12 Sub-function parameter in the request message is not supported. M13 The length of the message is wrong.M22 The criteria for the SecurityAccess request are not met.M24 requestSequenceErrorThe sendKey sub-function is received without first receiving a requestSeed request message. M35 invalidKeyM36exceededNumberOfAttemptsSend if the delay timer is active due to exceeding the maximum number of allowed falseaccess attempts.MSub-function Parameter DefinitionHEXDescriptionCvt01requestSeedlevel 1M02sendKeylevel 1M11requestSeedlevel 3 flashM12sendKeylevel 3 flashM4.2.5.2. Implementation RulesAfter 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 Any SecurityAccess request during this time will be rejected with the negative response code Required time delay not expired .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 and the security access failu