(图片来源于网络)
摘要
回想当年刚进去汽车行业,做新能源车的某个“ECU”,和客户沟通需求时,人家上来就问你们支持诊断不?我心想不就是检测个继电器黏连、铜排温度什么的嘛,肯定支持呀,不然能卖给你们嘛!就信心慢慢地说支持,然后人家又问,你们的XX故障码是什么?我就疑惑了,咋还有故障码呢?啥故障码?哈哈…后来当然是很痛苦了,就没有然后了。
在汽车行业,做控制器的软件绕不开故障诊断,这是一门技术更是一种工程思想。
那到底啥是诊断呢?经常听说的UDS、ISO14229、ISO15765又是什么呢?想必点开标题看此文的朋友多少都有些了解,那我们共同交流、进步,欢迎留言&提问&点赞哦!!!
本文主要分享对于刚接触车辆诊断协议,该如何“删繁就简”&“抽丝剥茧”地、快速地了解车辆诊断的概念和原理。希望大家能对车辆诊断有个总体的初步的了解【目标】。
【持续更新】:本文持续更新,不断总结在工作中遇到的关于车辆诊断协议栈方面的问题和一丢丢的经验。
1. 基础概念
1.1 诊断的概念
生活中医生对病人的“望闻问切”叫做诊断。
汽车诊断是指诊断设备对汽车状况的监测也叫做诊断。
(图片来源于网络)
1.2 诊断的目标
诊断分为两种:在线诊断和离线诊断在线诊断
比如汽车仪表对油温、水温、车速等数据的实时监测;离线诊断是外部诊断设备通过车辆的OBD接口与汽车进行通讯,从而获知汽车的相关数据和故障信息。
这两种诊断方式都给我们的生活带来便利,节约时间和成本,这也是为什么给汽车增加诊断功能的初衷。
(图片来源于网络)
1.3 诊断的实现
外部设备和车辆通讯的方式和原则我们就称作为诊断协议。
诊断协议主要定义了请求和响应的规则,也定义了ECU如何处理响应的机制,还定义了在请求和响应中的报文所承载的物理意义的解析方式。
常见的诊断协议:ISO15031、ISO15765、ISO14229等 后面我们逐一介绍。
开始划重点了
一定要下载英文版的协议原文进行阅读,协议原文是最权威的,在学习协议过程中可以参考别人的解读和经验,但是不能代替你自己对协议的理解,尤其是在实际的协议实现和测试的时候,协议常在手,一看就知有没有。
ISO的正版协议都是需要购买的,自己找不到的朋友莫慌,后续讲到对应的协议,会分享给大家哦!
1.4 诊断是分层的
之前的文章 车辆CAN通讯系列】1 CAN通讯基础——物理层概述 就强调过通讯是分层的,不理解的朋友可以跳转过去理解一下。
如下图(ISO14229中的插图):
对于每一层都有一个协议来约束&规定,通过物理的线路和MCU的运算,将电信号转换成表示诊断信息的报文,就是依据这些协议完成的。
具体每一层的内容,可以通过下面的链接跳转:
- 物理层:CAN通讯基础——物理层概述
- 数据链路层 : CAN通讯基础——数据链路层概述
- 网络层&传输层:TBD.
- 应用层:TBD.
【UDS】搞懂故障状态位
【UDS】搞懂时间参数
2. 项目应用
乘用车一般支持ISO14229、ISO15765。
- ISO14229协议研读笔记:
【ISO_14229_1 实例解析】数据传输功能单元(Data Transmission functional unit)
【知识点】UDS刷写的一般流程介绍 - ISO15765协议研读笔记:TBD
商用车一般支持ISO14229、ISO15765、J1939、ISO15031。
- ISO15031协议研读笔记:TBD
- 国六排放法规分析笔记:TBD
- J1939协议入门:
【J1939】一、概述,协议基础 - J1939协议进阶:TBD
3. 协议栈开发
这里说的开发,纯属是个人兴趣,毫无商业竞争的意思哦!Vector、普华、恒润的朋友看到可别来找我呀!当然了,想要急于在项目中应用的话,还是要找靠谱的大公司,买他们的成熟的有量产使用经验的协议栈产品,否则买的代码到底有多不靠谱,只有在真正用的时候你才知道。
关于协议栈开发的系列文章:(还未更新呢 😃 )
- Server端程序开发:TBD.
- Client端程序开发:TBD.
- 上位机开发:PEAK System公司的APIs PCNA _UDS中的C#实例无法打开问题解决办法
- 辅助测试工具的使用:【分享】ISO-15765-2测试工具
- 基于UDS的Bootloader程序开发:TBD.