新能源汽车整车控制系统的诊断开发

1引言

近年来，新能源汽车在国内得到了飞速的发展。而相较于传统汽车，新能源汽车具有更高的电气化水平，其电子电气架构也更复杂，可能发生故障的问题点也越来越多，故障出现后其诊断也变得愈加困难。依靠传统的人工经验检测与诊断方法，无法快速、准确的判断新能源汽车电子控制系统的故障，难以适应现代汽车的快速发展。在汽车故障诊断技术方面，国内起步较晚，虽然相较于国外Vector、博世等有所差距，但也有成熟产品，不过多应用于传统车型。因此，研发具有自主知识产权的汽车故障诊断检测系统是必然趋势，具有重要的商业与应用价值。针对汽车诊断，各大汽车厂家都制定了各自的标准，导致汽车诊断规范通用性很差。欧洲汽车商推出一种基于CAN总线的诊断系统通信标准ISO15765，可满足E-OBD的系统要求。ISO15765以ISO14229定义的服务为基础,规范了基于CAN总线的诊断服务(UDSonCAN)，包括网络管理、网络定时、应用层定时等详细内容,使得该协议的适用性和可操作性更强。ISO15765符合现代汽车网络总线系统的发展趋势，被众多汽车厂商采纳,或将成为未来汽车行业的通用诊断标准。

2UDS诊断系统设计

2.1总体方案设计

结合某新能源诊断系统的现状，将UDSonCAN诊断系统的开发分为两大块：上位机与控制器ECU，参见图1。上位机部分可以结合现有的EOL平台进行拓展性开发，在时间进度与客户的认可度上有一定的保障。控制器部分主要针对现有新能源车辆配置的主要零部件，进行底层与应用层的UDS诊断适应性开发，本文主要阐述此部分诊断开发主要分四个步骤：制定协议规范（需求）、软件（代码）实现、诊断测试和实车验证。

2.2UDS需求规范制定

诊断协议是后续工作开展的基础，其基于OSI七层架构体系，依据ISO标准制定，详细定义诊断的物理层、数据链路层、网络层、会话层以及应用层需求。DiagnosticonCAN的OSI结构见表1。实际开发过程中，应结合控制器通讯协议、刷写要求等各种规范，完成诊断相关的服务在应用与下载两种情境下的模式与寻址方式等功能定义、通用DTC码定义、发生故障时冻结帧（整车或部件DTC环境信息）的定义、通用和静态数据DID信息定义、数据刷写流程定义等内容。诊断协议也是主机厂把控各零部件状态的关键。

2.3软件的实现

2.3.1软件功能概述基于UDS的故障诊断系统，一个完整的控制器需要实现以下功能：①对负载工作状态和总线网络通信状态等进行周期性检测，并在故障发生时，启动故障记录（故障本身及快照信息）和故障处理功能，必要时需及时切断输出，确保部件及整车的安全性；②根据整车点火周期定义，在整车当前点火周期结束时存储历史故障，在下一个点火周期开始时读取之前的故障记录；③当故障消除时，控制器软件能够自主启动故障码清除逻辑；④诊断仪在线时，按照诊断仪的服务请求，能够读取、清除DTC及相关快照与扩展信息，能够读写DID，能够完成一些IO或例程控制等；⑤诊断仪可以根据数据库对ECU上传的数据进行解析并显示故障类型和故障状态，并能以表格的形式导出相关数据；⑥诊断仪可以就当前控制器快捷更新程序。2.3.2软件功能划分控制器软件系统主要由底层驱动部分、协议栈和应用层策略部分3部分组成。底层驱动模块主要实现诊断数据收发（CAN）和故障码读写（存储模块）等功能。协议栈设计根据通信矩阵、诊断规范等输入文档，实现通信层、数据链路层、网络层、会话层、诊断层的代码编写，根据底层协议栈提供的诊断接口，完成诊断函数的填充，最终实现诊断功能。应用层软件采用基于模型的设计方法（Simulink），主要实现故障检测、处理和清除等功能。一般来说，具备直接网络管理功能的控制器将网络的休眠和唤醒作为一个驾驶循环；而在间接网络管理的控制器上，将控制器上电和下电作为一个驾驶循环。本方案的驾驶循环根据控制器的上下电（点火信号keyon）来定义。故障检测、记录及自恢复机制如下：①每个故障都定义故障检测计数器、故障老化计数器，下电时计数器值需要写入存储模块，上电后读取。②每个故障定义好各自的检测频率，并设置一个Counter（上限+127，下限-128）值，Counter初始值为0。③每一个检测周期，分别对各个故障进行一次判断，若当前检测周期测出信号超限，Counter+1，直至Counter值为+127，则确定为1次故障；若当前检测周期信号正常，咱Counter-1，直至Counter值为-128，则表示没有故障；当Counter值达到+127且故障一直持续，则Counter值维持+127不变；当Counter值达到-128且信号一直正常，则Counter值维持-128不变；若Counter为正数，信号正常，则Counter-1，信号出现故障，则Counter+1；若Counter为负数，信号正常，则Counter-1，信号出现故障，则Counter从0开始+1。④若Counter值为+127，则判定故障产生，将故障信息及故障产生时刻的快照信息存储在内存中。同时下一个驾驶循环周期开始，老化计数器+1。⑤若后续驾驶循环信号一直正常，则老化计数器一直累加，直至到达第40个驾驶循环周期，然后故障自动清零，同时清除故障相关的快照信息及故障计数器等信息。所有故障相关的信息存储到一个或几个临时变量数组，下电时，再把这些信息存储到存储模块的相应地址中。

2.4诊断测试

诊断功能的测试可以结合CANdelaStudio、DiVa、CANoe工具链联合完成。三套工具配合使用，可极大的简化各零部件控制器的非车载测试工作，通过最后生成的HTML格式的报告，也可以快速分析底层代码的问题所在。另外一部分测试可以在实验室通过临时搭建控制器环境，完成各零部件的诊断测试。

2.5实车验证

实车验证属于最后的综合测试，联合上位机在实车环境中一起对各控制器进行诊断测试，重点验证诊断过程中相应CAN网络的负载率情况。实车初步测试完成后，需要就整车状态进行一定的可靠性验证。

3总结

诊断系统是整车控制系统开发中至关重要的一环，关乎整车安全。而基于UDS的统一诊断系统是大势所趋，对主机厂来说，可以充分把控整车各零部件状态，确保车辆的安全性与可靠性，提升产品的市场认可度；对零部件厂来说，将一部分权限开放给主机厂，可以减少人力、物力等方面的投入，降低部分售后维修费用。总之，这对于双方来说，是一个双赢的方案。

作者：薛云鸿 张甜甜 田光烁 李照远 王方抒 单位：中国重汽集团新能源汽车研究总院