诊断开发在汽车中的应用

张晶

摘 要：本文主要介绍在汽车研发、生产、售后各环节诊断开发的主要工作内容以及相应的作用，智能诊断系统应用，为从事汽车诊断开发工作的工程师提供一定的参考。

关键词：汽车 诊断 开发 设计 ECU 故障码 远程 软件 升级

1 引言

随着汽车电子技术的发展，越来越多的智能控制系统（ECU）应用于汽车，整车出现电器类相关的故障越来越越多，电器类故障与机械类故障相比，故障原因纷繁复杂，如果靠经验以及拆解故障件去查找问题原因，往往很难定位问题原因且原因确认周期较长。故诊断开发及应用在汽车整个生命周期中的作用非常重要，它能帮助人们快速准确定位问题方向及查找问题原因。严重故障时，驾驶员通过观察汽车人机交互接口的故障指示灯以及文字、声音提示信息，来确认车辆安全与否，确保在安全的情况下驾驶车辆，出现问题后引导客户及时对车联进行维修。

2 汽车研发阶段的诊断开发

车辆的诊断需要有诊断仪端和ECU端，诊断仪端和ECU端通过一问一答的形式进行通信，因而诊断仪端和ECU端都需要遵循同样的诊断通信协议，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。

大部分主機厂都是基于ISO 14229、ISO 15765、ISO 15031、ISO 14230国际标准及基于主机厂策略细化具体要求来制定企业级别的通用诊断规范。主要内容包括：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层相应要求。本文着重介绍应用层要求。

2.1 诊断服务开发

如表1所列的诊断服务诊断开发阶段所要进行具体定义的服务。本文着重介绍0x10、0x27、0x3E、0x22、0x2E、0x2F、0x14、0x19、0x31服务。

每个模块都应定义独有的诊断物理寻址ID，所有模块都应定义相同的功能寻址ID。

2.1.1 0X10服务

0X10服务定义的内容是诊断会话窗口，10 01为默认会话窗口，10 02为编程会话窗口，10 03为扩展会话窗口，所有的服务均需要定义支持哪些会话窗口。某些特定的服务只能支持在10 02或10 03会话窗口，模块上电后默认的是默认会话窗口，要想进入非默认会话窗口需要诊断仪进行服务请求。

2.1.2 0X27服务

0X27服务定义的内容是安全访问，27 01/02为一级安全访问，27 03/04或09/0A为二及安全访问，27 05/06为三级安全访问，安全访问算法由主机厂释放给ECU供应商，安全访问等级不是越高算法越复杂，各级安全算法独立运行，每个模块安全算法不一样，因此需要基于模块进行个性化开发。具体什么服务需要定义什么样的安全等级可根据服务目的进行界定。

2.1.3 0X3E服务

0X3E服务定义的内容是诊断仪在线，3E 00为不抑制模块正响应服务，3E 80为抑制模块正响应服务，此服务的目的告知模块诊断仪需要与之在既定的会话窗口下保持持续通话，例如为防止模块从扩展会话因超时机制自动跳转回默认会话，可提前选择3E服务。

2.1.4 0X22服务

0X22服务定义模块需要通过诊断服务可读取到的信息，例如读取车速信息、电压信息、零件号信息、车VIN信息等等，每个模块都有自己的独特的22服务所需要进行读取的信息，因此需要基于模块进行个性化开发。22服务通常不需要安全访问。

2.1.5 0X2E服务

0X2E服务定义模块需要通过诊断服务写入的信息，例如在IMMO防盗及钥匙匹配过程中，需要向相应的模块内部定义好的标识符内写入相应的值才能完成匹配。每个模块都是自己独特的2E服务所需要写入的信息，因此需要基于模块进行个性化开发。想进入2E服务通常是需要通过27安全访问。

2.1.6 0X2F服务

0X2F服务定义模块需要通过输入输出端口进行诊断控制，如开关指令输入、转向灯、大灯等输出控制，每个模块都是自己独特的2F服务所需控制的输入输出，因此需要基于模块进行个性化开发。

2.1.7 0X14服务

0X14服务定义清除故障码服务，可以选择一次性清除所有故障码，也可以选择清除某一个故障码或某一组故障码。

2.1.8 0X19服务

0X19服务定义了故障读取服务，可以按需求读取历史故障码，当前故障码，还可以通过如下组合读取更多类型的故障码。DTC（Diagnostic Trouble Codes）， DTC状态由8个位组成的一个字节。这8个位分别代表不同的含义，具体这8个位代表的含义，包括这8个位初始值是什么，它什么时候被置1，什么时候又被置0，在什么情况下用及怎样用，在14229-1版附录D有详细的定义（表2）。

2.1.9 0X31服务

0X31服务定了模块需要满足的例程服务，如网关的报文映射，电动助力转向的零位标定，无钥匙进入系统的钥匙学习，仪表的保养提醒复位等功能都需要在相应的ECU内部定义相应例程服务来支持。31服务通常需要通过安全访问。

2.2 故障码开发

汽车研发过程中需要定义各个模块的故障码信息。故障码分为两类，网络类故障码及电气类故障码。

网络类故障码是模块基于网络通讯矩阵未在规定时间内收到相应报文或收到报文标志位为无效，接受模块需记录相应的丢失或无效故障码及CAN BUSOFF故障。电气类故障码是基于模块内部特性，例如内部继电器故障、温度异常、电流异常等等定义的模块内部的故障码。

故障码清单需包括的内容有：故障码、故障描述、故障码运行条件、故障码设置条件、故障码设置时发生的操作、故障恢复条件、激活故障灯规则、熄灭故障灯规则、故障码清除条件。

故障灯的点亮需要进行严格界定，且不可以什么故障码都可以点亮故障灯，更不能出现故障且影响到行车安全而不点亮故障灯，此处的策略需要主机厂和供应商结合功能安全ISO26262、及故障出现时发生的操作进行充分的评估。

故障码组成，ISO 15031-6对故障组成进行了定义，如图1所示。00表示动力; 01表示底盘;10表示车身;11是网络相关的。左边第3～4位反应的是DTC是由ISO，SAE，这些标准组织所定义的故障，还是由整车厂来定义命名的故障;左边第5～8位反应的是车辆系统的区域（Area of vehicle system）;右边8位是DTC的编码。

2.3 在线配置开发

为了减少ECU零件供货状态，减少零件号，模块的差异化需要通过在配置进行，需要定义2E服务下的特定诊断标识符，用于在线配置信息的写入，针对模块差异化，需要制定不同模块的在线配置文件。模块会根据在线配置标识符写入的信息制定相应的软件逻辑。例如标识符配置为XX，模块需要收发哪些报文、记录哪些故障码、开启哪些功能，配置成其他内容则对应的收发报文、故障码、功能会不同。工程开发阶段要确保在线配置的正确性，如在线配置定义错误可能会导致某些功能无法开启，严重影响整车质量。

3 生产售后中诊断的应用

3.1 汽车生产中的诊断应用

车辆在车间产线下线时，由于各个模块不是同时装配到车辆上，模块会报报文丢失类故障码，需要通过诊断服务去清除故障码。有些模块需要在产线通过诊断服务进行相应的标定服务，如电动助力转向系统的零位标定，360模块的摄像头标定，钥匙匹配，IMMO防盗匹配，胎压模块标准胎压的写入等等，通常会用OX10、OX22、OX27、OX2E、OX31、OX14、OX19服务。产线会开发特定的设备用于产线模块标定及在线配置。产线输出的车辆应确保没有故障码，如有故障码一直不能清除，需要及时对车辆进行返修。

3.2 汽车售后中诊断应用

4S店卖出车辆后，通常会通过诊断服务开启车辆的特定模式，如用户模式的开启，维修保养功能激活等都是通过诊断服务进行的。在售后维修车辆时，需要通过诊断服务进行故障的读取及问题指向的分析，4S店人员应该能熟练操作使用专用的诊断设备，这对确认售后车辆故障原因非常重要。

4 智能診断的应用

4.1 远程诊断功能

随着汽车智能化发展，远程诊断服务正在逐步融入到用户端，用户可以通过手机APP的操作对车辆进行远程诊断，车辆上电后，网联模块模拟诊断仪发送0X19服务读取故障码，并对ECU发送的诊断报文进行回读，云平台将回读数据进行解析，并将析结果释放给用户，这样用户就可以通过手机端查看车辆状态。尤其是共享汽车在城市中的普及，远程诊断功能将帮助维护人员随时随地远程查询监控车辆状态，节约共享汽车的运营及维护成本。

4.2 ECU远程升级功能

无需进入4S店就可以实现ECU软件的更新换代，用户可以在手机端或车机端进行远程升级服务，网联模块模拟诊断仪发送相应的诊断服务，逐个对车内ECU的进行软件读取、刷新会话、下载、传输、擦除、复位等操作，将最新版软件刷写如ECU内，涉及的诊断服务有0X22、0X10、0X11、0X27、0X34、0X36、0X37、0X31、0X85、0X28等。需要注意整车需要在特定的环境下才能进行软件的更新，以防出现相关的故障影响车辆安全。

5 汽车诊断展望

随着智能化电控技术在汽车上的应用，诊断的应用范围逐步扩大，ECU关联的诊断服务会越来越多，诊断开发工作变得更加复杂繁琐，模块诊断策略开发的合理与否直接影响车辆功能实现、故障维修、用户体验等，故作为诊断开发工程师需要对ECU诊断策略的开发进行全方面考量。

参考文献：

[1]蔡浩.数据驱动式汽车诊断平台的设计与实现.上海交通大学：机械工程，2009.

[2]高永君.汽车远程诊断分析系统的设计与实现.南开大学：软件工程，2016.