1. 简介
1.1 范围
本文档只用于电子控制单元报价材料所用。所有ECU都应该覆盖该文档所定义的要求，但不限制于该文档的内容。每个ECU可结合自身功能添加需求。
1.2 目的
为了使供应商前期能详细了解ECU诊断开发的需求，特制定该文档。此文档仅作为各个ECU报价材料诊断部分内容的参考材料，具体的内容需要结合ECU自身功能而定。
2. 诊断要求
ECU应该具备诊断功能，包括上电初始化时的自诊断和ECU运行时的实时诊断。外部设备能通过OBD接口读取ECU的故障及其它信息。
2.1 诊断参考标准
诊断统一为基于CAN的诊断，对应OSI七层所参考标准见表1。
2.2 诊断需求文档
ECU必须严格按照诊断需求文档进行开发设计、测试与验证。详细清单见图1所示。诊断需求文档属于内部机密文档，只有在供应商定点后，由ECU工程师在项目Kick off时提供给相关供应商，并当场签字确认。供应商收到需求文档后，1个月内将所有文档阅读完，并给以反馈。
2.3 ECU诊断性能要求
ECU必须保证在7V<U<18V时能进行诊断通讯；
ECU至少包括Flash ROM, EEPROM, RAM存储器。ECU发生故障时能将故障码及其相关故障信息存储在EEPROM或其它非易失性存储器，至少能存储15个DTC及其相关故障信息（具体个数决定于DRE，并且在CTS中写明）；
所有ECU都能通过$14服务清除故障码，包括当前故障码。如有特殊情况，需要在CTS中注明。此外，所有ECU还具备其它自动清除历史故障码的方法，比如，经过40个点火循环都没有发现该故障即自动清除存储器中的历史故障码及其相关信息；
ECU支持$10、$11、$14、$19、$22、$27、$28、$2E、$2F、$31、$34、$36、$37、$3E、$85等基本诊断服务，各服务具体内容和要求需满足GAEI的诊断设计规范；其中，$10、$11、$14、$19、$22、$3E服务在默认模式和扩展模式都支持；$27、$28、$2E、$2F、$85服务只在扩展模式下支持；$34、$36、$37服务只在编程模式下支持；$31服务在扩展模式和编程模式下支持；
$19服务至少支持子功能$01,$02,$04,$06,$0A，外部设备能从ECU中读取故障数目、故障码、Snapshot、Extended data及其ECU支持的故障码；
ECU针对特殊的功能需要进行安全限制。种子和密钥要求为4个字节，且种子为随机的，不是固定的。供应商具备提供安全算法的能力，保证算法的安全性及可靠性，并在规定的时间内提供安全算法进行审核确认；
ECU支持基于CAN的Flash bootloader功能，严格按照Flash 规范进行开发。Flash driver不能固定在ECU内部，每次ECU刷新时临时的下载到ECU中；
ECU支持某些特殊功能，如配置信息的写入、参数标定、参数调整、DTC设置的屏蔽功能（$2E服务）。
2.4 ECU诊断集成与测试要求
必须保证在ET2一个月前集成诊断功能，至少包括$10、$11、$14、$19、$22、$3E功能；
ET2阶段的第二次测试样件必须集成诊断全部功能，包括FBL功能；
供应商提供样件前，必须严格按照测试规范进行测试，并提供测试报告（FBL功能除外）。每次提供样件时，必须附上相应的测试报告！如果没有提供测试报告，将不进行测试，视为样件无诊断功能或诊断功能无变化。诊断测试包括以下4部分：
诊断通讯测试，提供诊断通讯测试报告；
（对应ISO14229、ISO15765-2、诊断规范的要求）
诊断功能测试，提供诊断功能测试报告；
（对应诊断规范、ECU诊断参数列表、Failsafe规范的要求）
诊断系统测试，提供诊断系统测试报告；
（对应诊断系统规范的要求）
FBL功能测试，提供FBL功能测试报告；
（对应刷新规范的要求）
针对提供的诊断验证测试报告，供应商需要在一个星期内给予反馈，包括问题原因和整改计划；保证在一个月内给予整改，如果不能按时整改，请给予理由！