|
 
- UID
- 864567
|
1.2 初始化过程
诊断仪在对ECU进行任何诊断服务之前，首先需要建立和ECU之间的诊断通讯，这是通过“初始化过程”实现的。ISO14230定义了两种初始化方式-5 Baud初始化和快速初始化，5 Baud初始化是为了向后兼容ISO9141的需要，现在广泛实现的是快速初始化方式。该过程如图1所示，诊断仪发送一个WuP(WakeUp Pattern)，然后发送StartCommunicationRequest，ECU检测出WuP，然后发送StartCommunicationResponse，返回ECU支持的报文头格式、定时参数等信息。
图1 快速初始化过程 1.3 定时参数
在诊断过程中，需要遵守一些定时参数的约束，以保证正常的诊断通讯，ISO14230定义了4个定时参数管理字节间定时和报文间定时，图2为定时参数的示意图，表2解释了这4个定时参数的含义及取值区间。
图2 定时参数示意图 参数变量
| 描述
| 最小值(ms)
| 最大值(ms)
| P1
| ECU响应的字节间时间间隔
| 0
| 20
| P2
| 诊断仪请求结束和ECU响应开始的时间间隔，或ECU响应结束和下一个ECU响应开始之间的时间间隔
| 25
| 50
| P3
| ECU响应结束和诊断仪新的请求开始之间的时间间隔
| 55
| 5000
| P4
| 诊断仪请求的字节间时间间隔
| 5
| 20
|
表2 定时参数 2诊断
诊断是指汽车电子控制系统在运行过程中不断监测各个组成部分的工作情况，进行故障定位并存储，然后通过支持诊断协议的诊断工具进行在线读取，得到故障信息，它包括自诊断和在线诊断两个部分【3】。
2.1 自诊断
自诊断是指以系统实时监测为基础，据监测现象反映的电控系统运行状态，通过进一步的数据分析，判断故障位置、类型及原因，同时针对系统异常做出相应调整的过程。
BCM的主要功能是控制门锁、车窗、车灯、雨刷这些负载【4】，相应地，BCM的主要故障是负载开路及短路。开路故障不会造成很严重的后果，可以利用负载驱动芯片的电流镜像功能实现。设置一定的采样周期，通过取样电阻对负载工作电流进行周期性采样，如果工作电流小于某个阈值并持续一段时间，则认为出现开路故障。
短路发生时的负载工作电流非常大，故障持续会造成相当严重的后果，在实验过程中发现车灯短路故障超过十毫秒量级就会把电量相对不足的供电电源拉低到地，这就会造成所有从汽车蓄电池上取电的ECU复位，因此短路故障需要及时得检测出来并关断相关负载的驱
动电路。
由于负载刚启动时有很大的浪涌电流，需要和负载短路做出区分以免误判。浪涌电流持续时间一般为毫秒量级，设置负载工作电流的采样周期为10毫秒，两次采样工作电流均超过阈值则认为短路故障发生。在实际应用中，10ms的采样周期会影响系统运行效率，增大电流消耗，而采样周期设置过长则可能会造成没有及时检测出短路故障的严重后果，为了提高系统效率和短路故障检测的实时性，可以通过监测负载驱动电压的方式实现短路故障检测。
高端开关MOSFET驱动的负载对地短路时，负载驱动电压为0 v，低端开关MOSFET驱动的负载对电源短路时，负载驱动电压为电源电压。对负载驱动电压进行分压处理，以可触发中断的处理器IO脚进行检测，短路故障发生可以触发IO脚中断，这样可以提高短路故障检测的实时性，且不会出现误判负载启动为负载短路的情况。
2.2 在线诊断
在线诊断是指诊断仪根据国际通用或企业自定义的诊断协议，发送诊断服务请求，ECU根据服务请求返回响应的过程。需要指出的是，随着汽车系统的愈加复杂和ECU功能的增加，在线诊断已不再局限于早期的读取故障码，还包括软件升级、版本配置等功能。目前国际通用的诊断协议包括基于CAN总线的ISO15765和基于K线的ISO14230【5】。
基于K线的诊断网络采用总线式网络架构，多个ECU节点通过单根K线和诊断仪连接在一起，每个ECU有特定的物理地址和逻辑地址，诊断仪通过物理地址或逻辑地址对ECU进行寻址，拓扑如图3所示：
图3 诊断网络拓扑
在线诊断过程如下：首先诊断仪通过初始化过程建立和特定地址ECU之间的“诊断通讯”，自动进入默认模式的“诊断会话”，也可以通过SDS服务(StartDiagnosticSession Service)建立一个特定模式的“诊断会话”，该模式决定了在此诊断会话中可以进行哪些诊断服务，诊断结束后通过StopCommunication Service断开“诊断通讯”。诊断服务由表1中所述K线报文结构中的服务标识符Sid标识，ISO14230-3定义了各种诊断服务的Sid及Data，如清除诊断信息服务请求(ClearDiagnosticInformation Service request)的Sid为0x14，Data为两个字节标识的故障代码组(groupOfDTC)，0xFFFF表示所有故障代码,0x0000-0xFFFE为整车厂自定义的故障代码组合，该服务请求、肯定响应及否应响应的定义如表3、表4及表5所示。其他诊断服务在此不再赘述。
清除诊断信息请求
| 参数
| 说明
| 编码
| CLRDTC
| 清空诊断信息，这个服务允许擦去由一个 ECU所记录的诊断信息。
| 0x14
| groupOfDTC
| DTC组
| 0x0000-0xFFFE=厂商自定义故障组
0xFFFF=整个故障组
|
表3 清除诊断信息请求 清除诊断信息肯定响应
| 参数
| 说明
| 编码
| CLRDTCPR
| 清空诊断信息肯定响应
| 0x54=0x14+0x40
| groupOfDTC
| DTC组
| 0x0000-0xFFFE=厂商自定义故障组
0xFFFF=整个故障组
|
表4 清除诊断信息肯定响应 清除诊断信息否定响应
| 参数
| 说明
| 编码
| CLRDTCNR
| 清空诊断信息否定响应
| 0x7f
| CLRDTC
| 清空诊断信息请求Sid
| 0x14
| RC
| Response Code
| 0x12=不支持的子功能
0x22=条件不正确
0x78=回应挂起
|
表5 清除诊断信息否定响应 结语
随着汽车电子的发展，诊断功能在ECU的开发设计中已经成为必不可少的一部分，基于K线的ISO14230是在国产车中得到广泛应用的一套非常完善的车载诊断协议标准。本文结合车身控制模块BCM的诊断功能设计，分析了K线诊断协议的数据链路层和应用层规范，介绍了基于K线的BCM诊断的实现，具有很好的借鉴意义。 |
|
