UDS
UDS(Unified diagnostic services),统一诊断服务,与OBD最大的区别就在于“Unified”上,“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。到目前为止,这种通信协议被用在几乎所有由OEM一级供应商所制造的新ECU上面。这些ECU控制车辆的各种功能,包括电控燃油喷射系统(EFI),发动机控制系统,变速箱,防抱死制动系统(ABS),门锁,制动器等。
单说UDS而言,它只是一个应用层协议(ISO 14229-1),所以它既可以在CAN线,LIN线上实现,也能在Ethernet上实现,并且,UDS提供的是一个诊断服务的基本框架,主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务,所以基于UDS协议的诊断又常常被称为Enhanced diagnosic(增强型诊断),UDS不是法规要求的,没有统一实现标准,其优势在于方便生产线检测设备的开发,同时更大的方便了售后维修保养和车联网的功能实现。UDS本质上是一系列服务的集合,它对所有的诊断命令进行了定义,比如诊断请求和诊断响应的格式。UDS的服务分为6大类,但常用的服务是加背景色的15种服务,每种服务都有自己独立的ID,即SID(Service Identifier),这15种服务又可粗略地划分为权限控制、读取数据/信息、写入数据/信息、通信控制、功能控制这几类。
对比OBD是关注车辆实时排放的理念形成的行业规范,而UDS是诊断服务的统一化规范。且UDS是面向整车所有ECU(电控单元)的,而OBD是面向排放系统ECU的。
ISO 11898
ISO 11898 是通信速度为 5kbps - 1Mbps 的 高速CAN 通信标准,对应于OSI是层一和层二,即物理层和数据链路层。对于物理层来说,定义了CAN总线信号在双绞线上的电压形式,对于数据链路层来说,定义了CAN帧的各个域的用途。CAN 协议中关于 ISO/OSI 基本参照模型中的传输层、数据链路层及物理层,具体有哪些定义如下图所示。
ISO14229
14229是UDS的ISO标准号,ISO 14229-2定义了为应用层提供的服务,为UDS和传输层、网络层(ISO 15765-2 UDSDoCAN,ISO 10681-2 Communication on FlexRay, ISO 13400 DoIP, ISO 14230-2 DoK-Line等)之间提供独立性。,定义了诊断会话中的各种时间参数,比如P2Server、P2*Server、P2Client等。
如下图所示,ISO 14229也就是UDS协议仅对应用层、会话层做出了定义。这里有个疑问,UDS专指ISO 14229-1吗?这种说法是不对的,UDS包含了ISO 14229下属的7个子协议,其中ISO 14229-2还是会话层的,所以UDS仅包括应用层的说法也是错误的。
- ISO14229-3定义了UDS基于CAN总线的实现;
- ISO14229-4定义了UDS基于FlexRay总线的实现;
- ISO14229-5定义了UDS基于以太网协议的实现;
- ISO14229-6定义了UDS基于K-Line总线的实现;
- ISO14229-7定义了UDS基于LIN总线的实现
ISO 14229及其子集
ISO标准以及相应OSI层
ISO15765
ISO 15765是适用于IS011898制定的CAN总线上的诊断协议,由以下几部分组成:1部分:一般信息2部分:网络层服务3部分:统一诊断服务( UDS CAN)4部分:相关排放系统要求
如上表:诊断服务(7层-应用层),在IS015765-3指定,网络服务层(3层-网络层)。在IS015765-2指定,CAN服务(1和2层-链路层 物理层),在IS011898-1指定,
ISO 11898协议中定义的经典CAN数据链路层与ISO 14229协议中定义的应用层,彼此之间数据长度不统一。
经典CAN数据链路层最大能够支持8个字节,但ISO 14229并不仅仅是为了CAN总线设计的,最大容量达到4095个字节。比如VIN码是17个字节,CAN总线必然需要传递3帧才能传完VIN码,那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输,就成了一个需要解决的问题。ISO 15765-2 协议由此诞生。
这里重点解释一下ISO 15765 -2:
15765-2作为车辆诊断通信协议ISO 15765 的一个组成部分,规范了“传输协议和网络层服务”,解决经典CAN数据链路层与ISO 14229协议中定义的应用层,彼此之间数据长度不统一的问题。
网络层
网络层最主要的目的就是把数据转换成能适应CAN总线规范的单一数据帧,从而进行传输。如果将要传输的报文长度超过了CAN数据帧的长度,则需要将报文信息进行拆分后传输,每次至多可以传输4095个字节长度的报文。
所有的网络层服务都具有相同的通用结构。为了定义这种服务,需要定义三种类型的服务原语:
A. 请求服务(Request):用于向网络层传递控制报文信息及要发送的数据,应用于更高层或应用层。如tester向ECU发出数据。
B. 指示服务(Indication):用于向更高层或应用层传递状态信息及接收到的数据,应用于网络层。如ECU收到了tester的数据,传至应用层。
具体说来,Indication前端应该执行的是底层传入数据的处理函数,即读取PDU信息,这一帧具体是SF、FC、CF还是FF。若满足条件,继续向上,即应用层传递。
C. 确认服务(Confirm):被网络层使用,用于向更高层或应用层传递状态信息。如tester收到了ECU方面的数据。
具体说来,Confirm和Indication很像的是都是从网络层向应用层传递信息,有何区别呢?
在代码的处理中,Confirm的前端应向底层外发Tx数据或超时处理函数,反馈的信息不需要包含数据。而Indication传递的信息则分为两种,一种包含真实数据,另一种不包含。
网络层协议数据单元 N_PDU
网络层协议数据单元(N_PDU,Network_Protocol Data Unit)包含N_AI,N_PCI,N_Data。即地址信息,协议控制信息和数据。
注:这里的N_PCI全称为Protocol Control Information。
网络层协议数据单元(N_PDU)有四种类型,即单帧(SF)、首帧(FF)、连续帧(CF)、流控制帧(FC),用于建立对等实体间的通信。
于TP层来说,我们可以把报文分为单帧和多帧,单帧只有一种N_PCI,即单帧;多帧有三种N_PCI,即首帧、流控制帧、连续帧。
代码实现中,主要的工作其实就在多帧的处理和对超时错误(Timeout)的处理上。
0X 单帧(SF):首个字节为0(4bit)+ Data Length(4bit),控制信息占用1个字节
举例:Data 02 10 02 55 55 55 55 55,02表示接收方应知晓,这一个单帧只有2个有效字节。后续的字节是自动填充的无效字节。
1X XX 首帧(FF):前两个字节为1(4bit)+ Data Length(12bit),控制信息共占用2个字节。
举例:Data 10 14 2E F1 90 01 02 03,0x014表示,接收方应知晓,这一个多帧组合共有20个字节。
3X 流控制帧(简称流控帧,FC):前三个字节为3(4bit)+流状态(FS,4bit)+块大小(BS,8bit)+最小间隔时间(STmin,8bit),控制信息共占用三个字节。
举例:Data 30 00 14 AA AA AA AA AA,多帧发送方应知晓,这是一个流控帧,允许你方继续发送,CF数量无限制,上一个连续帧的确认接收(ACK)到新的连续帧开始发出的最小间隔时间为20ms。
Flow State 流状态:0为继续发送,Continue To Send(CTS),1为Wait(WT),2为Overflow(OVFLW)。
间隔最短时长(STmin)值的含义如下。
2X 连续帧(CF):第一个字节为2+SN(最多16个SN,溢出后从0开始重新计数),控制信息占用1个字节。
我们通常记首帧为0x20,之后的第一个连续帧自然是0x21,之后一直到0x2F,下一个是0x20,循环。
下图是一个传输规则的例子。可以看出,这首先是一个多帧传输,下列CAN帧依次代表的含义是首帧、流控、连续帧、连续帧。