UDS在CAN和以太网上的实现方案

0 序言

在之前工作过程中，进行测试时，如果单板有故障，习惯性地会去找软件同事帮忙读一下故障码。很多时候，这个故障码会提示我的排查方向。如果没有软件的诊断支持，我也能一步一步去逼近问题，但效率比较低。

前司的产品，各个模块都是自研的，所以其故障诊断的逻辑可以自行定制。新的项目里说要加一个诊断功能，只要硬件在设计上做支持，软件添加相应代码即可。但对于汽车这种复杂产品而言，在前期分布式架构阶段，整车厂更像一个集成商的角色，买各家供应商的ECU。行业只要有分工，就必须要有规范，这样才能提高生产效率，实现收益最大化。于是，各家遵循统一的诊断标准就是必然的事。即使后期EEA发展成中央集成架构，OEM自己研发所有的控制器，这种诊断标准应该也会沿袭下来。

越是复杂的系统越是需要完善的故障诊断系统，否则问题定位的代价会很大，售后成本会很高。此外，智能化是汽车的发展趋势之一，智能化的本质就是将人做的是交给车自己来做。人根据五官收集的信息做出综合判断，然后进行相关操作。如果要车去做决策，首先就需要让车能够获得足够多的信息。自动驾驶的感知和定位模块，是车对外界环境的感知。另一方面，车还需要对自身内部有足够强的感知能力，那就需要有监测和诊断系统。如果一个传感器或执行器损坏了，而系统不自知，那么这是一个不稳定的开环系统，迟早要翻车。另外，根据我个人的感受，一个产品的诊断系统做得是否完善，很大程度上反应了这个产品的成熟度。因为只有一个产品的其他主要功能都搞好了，稳定了，工程师们可能才会有余力着重去提升产品的其他部分。

  1 UDS概述

说到车的诊断，就要引出今天的主角，即UDS协议。UDS（Unified Diagnostic Services）是ISO 14229定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（如CAN、LIN、Flexray、以太网）上实现，用于车辆电子系统的故障诊断和通信。它提供了一组标准化的诊断服务，允许诊断工具与车辆的电子控制单元（ECU）进行通信，以诊断和解决故障。

说点UDS具体的场景应用：

（1）ECU开发过程要用到它来构建bootloader，上传和下载数据，即软件刷写，控制器Reset；

（2）测试时要用它来读写存储，控制外设；

（3）产线上，要用它来校准机械件，控制例程，进行下线执行器测试，刷新软件，配置防盗，读取号码，下线配置等；

（4）在行驶过程中，要用它来监测各种故障，并记下故障码；

（5）4S店里，技师需要读取当前故障、历史故障，读取故障发生时刻环境信息状态，清除故障，判断故障发生点，还可以用来升级ECU程序。

JTAG是针对MCU或者SOC这种芯片的调试接口协议，而UDS更像是针对整个ECU的调试接口。UDS简单来说是一种Client/Server的通信服务，即Tester（诊断仪）向ECU发送诊断服务请求（Request），ECU则向Tester发送对应服务请求的响应（Response）。

UDS在OSI模型中的位置如下所示。ISO14229有中文版本，可以搜索《道路车辆 统一诊断服务(UDS)》

从上图中可知ISO 14229-1定义了UDS的规范和要求。上面讲到了，UDS可以在不同的总线上实现，于是下面的ISO14229-3定义了UDSonCAN，即UDS在CAN上的具体实现，ISO14229-3还是属于应用层的。同理，ISO14229的其他部分标准分别规定了UDS在不同总线上的实现细节。其中UDSonIP规定的是基于IP实现的UDS，常用的IP网络其实就是以太网了。ISO 14229-2定义了会话层的相关标准。

在学习过程中，有看到这样的说法：“UDS（Unified Diagnostic Services）是ISO 15765和ISO 14229定义的一种汽车通用诊断协议”，这说的不严谨，这说的其实是UDS在CAN总线上的实现，其网络模型如下。ISO15765-2可以用ISO 14229-2加上ISO14229-3替代。

以太网可以确定会成为未来车辆内的主干总线，当10base-T1标准完善，以太网可能会完全取代CAN总线。因此本文关注UDS在CAN和以太网上的实现。

在刚学习的时候，会对UDSonCAN和DoCAN有疑问，不知道二者有什么区别。DoCAN的全称是Diagnosis on CAN。UDSonCAN和DoCAN是在通信模型不同层中的不同叫法，其规定了不同层的技术标准。UDSonCAN仅存在于应用层，而DoCAN只适用于网络层和传输层。

这里要说下OBD，因为在看诊断的时候，也有看到OBD的概念，这也是UDS下面的一个分支。

OBD（全称：On Board Diagnostics），即车载自动诊断系统，是汽车排放和驱动性相关故障的标准化诊断规范，有严格的排放针对性，其实质就是通过监测汽车的动力和排放控制系统来监控汽车的排放。当汽车的动力或排放控制系统出现故障，有可能导致一氧化碳(CO)、碳氢化合物(HC)、氮氧化合物(NOx)或燃油蒸发污染量超过设定的标准，故障灯就会点亮报警。

OBD与UDS的区别是：

（1）OBD是关注车辆实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范。电动车不需要满足这个标准，因为没有尾气排放。燃油车通常既要满足OBD，又要满足UDS。诊断服务下面才会讲到，看完诊断服务可以回头看这里。UDS的诊断服务代码是从0x10开始的，小于0x10的代码则被OBD用了。

（2）UDS是面向整车所有ECU的，而OBD是面向排放系统ECU的。既然UDS可以用于所有的ECU，那是否能把OBD完全取代呢？这点不太清楚。

本文不关心OBD，只关心UDS。

2 基于CAN总线实现的UDS

ISO 14229-1定义了UDS的所有服务规范。UDS在CAN上的应用，相对于在其他总线上应用上可能有一些差别，把这部分摘出来形成标准就是ISO 14229-3，这是为了将UDS的主体部分摘出来，尽量和具体的总线解耦，便于后期标准各部分的扩展。ISO 14229-3的内容不是很多，主要是会话层的内容，定义了数据传输和接收的一些时间参数，如果不是深入做协议栈的开发，这部分甚至可以直接跳过。

在网络层和传输层，遵循的是ISO 15765-2的标准。这里主要是为了解决应用层数据长度与CAN总线数据长度不统一的问题。UDS并不仅仅是为了CAN总线设计的，其最大容量可以达到4095字节，而经典CAN总线的数据长度是8个字节。如何科学、快捷、安全地将多个字节通过CAN总线传输出去，就成了一个需要解决的问题，这就需要用到ISO 15765-2。所以下面主要从ISO 14229-1和ISO 15765-2两个方面来看基于CAN总线实现的UDS。

2.1 ISO14229-1是什么

ISO14229-1描述的是与诊断相关的服务需求，并未涉及通信机制，所以它可以在不同的汽车总线上实现。实际应用中，测试人员同步外部的诊断仪和车相连，而所谓的诊断服务，是指车能够提供哪些信息反馈。

比如ECU接受特定的命令，进行重启；又或者，ECU根据某个指令反馈某个存储器某个地址的数据。这些都是已经约定好了的一些服务，这些服务的集合就是ISO14229-1标准。还是上面那句话，IS014229-1规定了要提供哪些服务，至于在具体总线协议上怎么实现，它不管。

UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）。

    2.2 ISO14229-1请求/响应机制

在应用层，UDS的通信机制很简单。诊断方发送服务请求，ECU返回响应。诊断服务的请求和响应根据是否具有Subfunction（子功能）分为两类。什么是Subfunticon呢？以0x10这个服务为例，其服务种类是Diagnostic Session Control，即诊断会话控制。其实就是控制ECU进入不同的会话权限。这个服务常用的有三个子功能，服务子功能的代号是01-03。其中01是指默认会话；02是指编程会话；03是扩展会话。上电后ECU初始状态是默认会话，这个状态下，ECU能支持的诊断服务是有限的，如果想要ECU把更多的诊断服务开放出来，就需要申请其他子功能，比如进入扩展会话模式。关于0x10这个服务，下面细讲。

2.2.1 不带Subfunction的机制

下图是不具有Subfunction的UDS诊断服务请求和响应机制。

（1）诊断方（Tester）向ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。

（2）ECU接收到请求数据（Request）后会返回响应，可返回肯定响应或者否定响应。肯定响应是指正常回应服务请求，而否定响应是指由于某种原因没有回应服务请求。在否定响应中，会有一个否定响应码，即NRC，会表明否定响应的原因。有些地方也将肯定响应翻译成正响应，否定响应翻译成负响应。

（3）肯定响应（Positive Response）格式为：（SID+0X40）+数据。例如，请求0X10服务，肯定响应第1个字节为0X50；请求0X22服务，肯定响应第1个字节为0X62。

（4）否定响应（Negative Response）格式为：0X7F+SID+NRC。例如，请求0X10服务，否定响应第1个字节为固定的0X7F，第2个字节为0X10，第3个字节为NRC。NRC是否定响应码，可以根据返回的NRC判断是什么原因导致的否定响应。下图是常见的一些NRC码，需要看全的NRC码，可以去查看标准原文。

举两个例子，比如否定响应码0x11表示的是ECU不支持诊断方请求的服务，诊断方想读取某个数据，但是ECU就没有这个数据；0x78表示请求已经收到，但可能ECU正忙，无法回复请求。其余的NRC码就不展开了，标准里都说明了对应的NRC码的功能。

2.2.2 带Subfunction的机制

下图是有Subfunction的UDS诊断服务请求和响应机制。与不带Subfunction的请求响应相比，其实也就是多了个Subfunction的编码。

  2.2.3 根据数据标识符读写

除了SID，SID+SF两种请求命令的构成方式以外，还有SID+DID，SID+SF+DID两种。其中DID是Data Identifier，即数据标识符。DID表示存储数据的地方，一般存储整车厂和零件供应商定义的数据，包括模拟输入和输出信号（比如转速信号），数字输入和输出信号（比如车门信号），内部数据和系统状态信息等。根据DID就可以知道需要调取哪些数据，而不必知道具体的内存位置。

2.3 诊断服务示例

2.3.1 诊断会话控制服务-0x10

UDS涉及26个服务，这里只试着讲其中几个，一个个讲就是翻译标准了，没啥意义。先来看下诊断会话控制服务，上文在讲Subfunction的时候其实就有提到0x10。

诊断会话控制服务被用来使能服务端中的不同诊断会话模式，诊断会话模式分为两大类：默认会话和非默认会话，其中非默认会话又包括编程会话和扩展会话，如下图所示。

这里分为三种会话模式，主要考虑的是服务的使用权限问题，不同会话模式下能使用的服务有区别，如下图所示。

 

默认会话是指ECU在刚上电时保持的会话状态，其服务的使用权限小，即可操作的功能单元服务少，比如不能使用27，28，83，84等服务；编程会话是仅使用与刷写程序相关的诊断服务，比如27，31，34，36，37等服务；而扩展会话相较于默认会话，其使用服务的权限大，即可操作的功能单元服务多，默认会话模式下不能使用的服务，在扩展模式下都能使用。

模式切换遵循以下规则：

（1）当ECU上电时，ECU总是从默认会话模式开始。

（2）当ECU上电后，非默认会话没被激活时，ECU会一直处于默认会话模式。

（3）当进入非默认会话后，如果服务端的S3定时器超时或请求了默认会话，将进入默认会话；

（4）当进入非默认会话后，如果控制服务端的S3定时器不超时，比如使用待机握手服务（$3E），则即可进行编程会话与扩展会话切换。

这里解释以下S3参数，S3参数可分为S3server和S3client。前者是服务器的定时参数，通常取5000ms，仅用于非默认会话模式。在该模式下，如果在S3server时间内，服务端没有接受到任何诊断请求服务，则退出非默认会话，返回默认会话。S3client是客户端的定时参数，通常取4000ms。客户端为了保持非默认会话的连接，可以通过发送3E请求（待机握手服务）来保持连接，但必须在S3server的时间内发送一次。相当于每4000ms，客户端告诉服务端它还在，不要退出非默认会话。

下面来看下0x10的请求和响应格式。0x10是有多个子功能的，所以其请求格式为SID+SF。比如请求默认会话模式，客户端会发送10 01；编程会话模式，则发送10 02，其他以此类推。需要说明的是上面提到了0x10的三个子功能，其实0x10的子功能不止三个，其他的子功能如下图，这里不展开。

以客户端发送了10 01为例，服务器端应回复50 01 xx xx xx xx。这里的xx是响应的相关参数，如下图所示。

参数通常是会话参数，即P2Server和P2*Server，如下图所示。

这里来解释一下P2Server和P2*Server。

P2Server的定义如下，表示从服务器端接收到请求消息到开始发送响应消息的时间。通常取值为50ms。

P2*Server的定义如下，表示从服务器端接收到请求消息到开始发送响应消息的时间。通常取值为5000ms。

P2*Server的定义如下，表示从ECU发送了NRC为0x78的否定响应消息到开始发送下一个响应消息之间的additional max.time，通常取5000ms。

如果设置P2server_max=50ms，P2*server_max=5000ms，则肯定响应就是50 01 00 32 01 F4。

需要说明的是，时间参数不止以上两个。会话层，即ISO 14229-2还定义了其他时间参数，有需要的可以查找标准。

当客户端发送诊断服务请求，服务端需要回复否定响应时，这时否定响应格式为 7F+SID+NRC，0x10服务支持的部分NRC如下图所示。

比如客户端发送请求10 05，但服务端未定义05，即不支持该子功能，则产生否定响应7F 10 12；比如请求10 01 01，不符合请求格式SID+SF的长度，则产生否定响应7F 10 13。

2.3.2 安全访问服务-0x27

访问数据服务和某些诊断服务需要考虑保密或安全等原因，比如下载/上传诊断服务例程或数据进入ECU并从其读取特定的内存位置，或者下载到ECU中的不正确例程或数据可能会损坏电子设备或其他车辆部件，或危及车辆的排放和安全标准。为了解决这些情况，就定义了安全访问服务。

安全服务的实现过程如下图所示。

上图中请求种子使用的格式是27 2n-1，原因是ECU需要解锁情况有多种，比如扩展会话模式下读写数据前需要解锁，比如采用27 01；编程会话模式下刷写程序前也需要解锁，比如采用27 03；当然可能还包括其他情况，故上图采用27 2n-1就更具有概括性，可适用多种情况。2n-1具体对应解锁什么服务，由整车厂自己定义。

当请求种子后，ECU就需要响应，发送种子。当客户端收到种子后，通过某种算法获得密钥后，客户端发送密钥给ECU。发送密钥的子功能代码都是偶数。

举个例子，假设扩展会话模式下，读写数据前需要先解锁，比如约定好了，这种场景下解锁采用的是27 01命令。我们发送27 01请求种子；ECU发送67 01 36 57，其中36 57是种子。密钥是种子的二进制补码，于是客户端计算出密钥是C9 A9；随后通过27 02 C9 A9发送密钥给ECU；ECU验证正确后，回复67 02，表明解锁成功。解锁成功后，就可以读写数据了。

如果在解锁状态下，重复发送解锁请求，比如发送27 01的命令，则ECU会回复67 01 00 00，表明ECU已解锁。

27 01解锁的是数据读写的功能，如果要解锁刷写程序的功能，假设刷写程序解锁的子功能代码是03，则需要重复上面的，使用27 03等指令取解锁刷写程序的功能。

0x27服务支持的否定响应码如下。举个例子，如果客户端给服务端发送的密钥不对，那么服务端将会发送否定响应，即7F 27 35。

  2.3.3 根据标识符读数据-0x22

0x22是根据DataIdentifier（即DID）去请求读取数据，其请求格式为SID+DID。这里请求的DID可以是一个，也可以是多个。其肯定响应的格式为(SID+40)+DID+Data，看一个例子。其中22是SID，响应时SID+40=62。F1 90为DID，紫色部分则为具体的数据。

再看请求两个DID的情况。其中01 0A和01 10为两个DID。A6-7E这部分数据为01 0A这个DID的数据，8C为DID=01 10的数据。

    2.3.4 根据标识符读数据-0x2E

0x2E是根据DataIdentifier（即DID）去请求写入数据，其请求格式为SID+DID+Data.

注意这里一次只写一个DID的数据，不像读取数据服务可以一次读取多个DID的数据。通过该服务可以：写入一些配置信息到ECU（比如VIN码，即车辆识别码），清除非易失性数据，重置学习值，设置一些可选内容。

需要注意的是，2E服务需要ECU解锁了才能执行，默认会话模式不支持该服务，所以要先进入非默认会话模式，然后解锁，才能写入数据。假设F1 90为DID，根据该DID写入数据的整个过程见下图。

    2.4 ISO15765-2标准

15765-2作为车辆诊断通信的一个组成部分，规范了“传输协议和网络层服务”。

UDS网络层，又称为TP层（Transport Protocol Layer）。其存在的目的是为了解决ISO 11898协议中定义的经典CAN数据链路层与ISO 14229协议中定义的应用层，彼此之间数据长度不统一的问题。经典CAN数据链路层最大能够支持8个字节，但ISO 14229并不仅仅是为了CAN总线设计的，最大容量达到4095个字节。比如VIN码是17个字节，CAN总线必然需要传递3帧才能传完VIN码，那么如何科学、快捷、安全地将多个字节通过经典CAN来进行传输，就成了一个需要解决的问题。ISO 15765-2 协议由此诞生。

网络层协议数据单元（N_PDU，Network_Protocol Data Unit）包含N_AI，N_PCI，N_Data。即地址信息，协议控制信息和数据。

N_AI包含了源地址、目标地址和寻址方式信息，后面再展开。

N_PCI标识网络层帧的类型。网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC）。

N_Data包含应用层协议控制信息和数据，即上文我们谈到的那些。

2.4.1 N_AI

在发送报文的时候，需要在报文里体现自己是谁，报文要发给谁。这就是源地址（N_SA）、目标地址（N_TA）、目标地址类型（N_TAtype）、可选地址扩展（N_AE）。关于这几个地址有几点要说明。

（1）源地址和目标地址很好理解，但需要说明的是，一个设备的接收地址和发送地址是不一样的。比如一个设备只接收目的地址为0x741的数据，但是它在回复数据时，使用0x749为源地址。即收发是使用不同的地址。

（2）目的地址类型分为两种，物理地址和功能地址。物理地址是指一对一的寻址，功能地址是指广播。每个ECU有不同的物理地址，当你想与特定的ECU通信时，需要以特定的物理地址为目的地址。但当你想广播一个信息的时候，那就使用功能地址为目的地址，比如我们约定0x7DF为目的地址，当总线上出现了0x7DF为目的地址的信息后，所有的ECU都要动作。

（3）N_AE用于远程诊断，远程诊断的概念是指数据域里的内容将会包含“远程地址(RA)”作为远程节点的标识。

N_AI在CAN数据链路层的数据包中是要映射到CAN ID部分的。在这里插一句，通常上层协议的数据包直接填进下层协议的Data段，在这里有点特殊。先看下CAN的数据包格式。

CAN的仲裁段就是CAN ID，网络层的数据包会被拆散，其中N_AI会被映射到CAN ID段，N_PCI和N_Data整体会成为CAN的Data段。根据N_AI的映射方式，网络层定义了几种寻址方式。

（1）标准地址

标准地址：这个格式最常见，也最好理解，指的是使用CAN的“标准帧”11位作为N_AI，至于源地址、目标地址等等，都是根据设备具体定义；比如上面0x741、0x749、0x7DF这些ID就已经区分了源、目标、类型这些内容了。需要说明的是，源地址、目标地址还有类型不需要单独占一个字节，不然11bit就不够用了。由于这些数据组合有限，通过自定义的映射方式，11bit就够用了。比如0x741，你自己就把它定义成，源地址是诊断仪、目标地址是ECU3，地址类型是功能寻址。

（2）标准混合地址：也叫“常规固定寻址”，这个格式从名字上就有点怪，其实就是在标准地址的基础上，把CAN的“标准帧”11位改为使用“扩展帧”29位并做了特殊位定义。

对于CAN的扩展帧，ID段有29位，相对11bit就宽裕很多。因此28-24位是固定的，23-16用于表征地址类型，15-8和7-0分别表示源地址和目的地址。

（3）扩展地址：这个格式从名字上就容易让人误解，以为是使用CAN的“扩展帧”，但其实就是在标准地址的基础上，把数据域的字节1拿出来用作N_TA来标识这个数据的接收者是谁。

很容易发现这种格式似乎并不好，因为不仅要浪费数据域的一个字节，在数据处理上CPU也要在得到数据后进行判断筛选，而它的目的只是为了扩展CAN标准帧的地址而已，那我们为什么不直接用CAN的“扩展帧”格式“标准混合地址”呢？所以正常CAN ID够用的情况下，似乎不需要使用这个格式。

（4）混合地址：又是一个从名字上就让人容易混淆的格式！是专门用于“远程诊断”的，远程诊断的概念是指数据域里的内容将会包含“远程地址(RA)”作为远程节点的标识，混合地址的格式中对CAN的“标准帧”11位和“扩展帧”29位的使用都进行了不同的定义。

其中，混合地址的CAN“扩展帧”29位的格式如下。

可以看到，主要的区别在于16~23位的值，与之前介绍的“标准混合地址”有所不同，这个dec段可以用于节点识别数据的地址格式。而且也一样占用了数据域中的第一个字节，作为地址扩展。

混合地址的CAN“标准帧”11位的格式如下。

  2.4.2 N_PCI

N_PCI字段，主要用于表征帧的类型。帧的类型分单帧、首帧、连续帧、流控帧等。

当一次通讯数据内容只需要一条CAN数据包就能包含时，就使用单帧格式。它的N_PCI需要占用1个字节，如下。

其中的SF_DL是用于表示本次传输数据的长度，由于只有4bit，它的范围和使用定义。

当一次通讯整包数据较长，需要拆分成多个CAN数据进行传输时，就需要使用首帧、连续帧与流控帧配合实现分包机制，这三种帧的多帧传输使用逻辑如下。

下面来分别介绍这三种类型的数据帧。

首帧的N_PCI需要占到2个字节，如下。第一个字节的高四位为1表示帧类型是首帧，低四位和第二个字节组成FF_DL共同表示多帧传输的字节数。那么我们可以得到一次性最多可以发送2的12次方-1个字节。那就是4095个字节了。

连续帧的N_PCI需要占用1个字节，如下。它有一个叫SN的代码区域，这SN表示的是包的连续号，从0到15后，又置零。其功能是说明帧的连续顺序。需要注意的是，首帧虽然没有SN的区域，但是在首帧也占一个SN，因此首帧之后的连续帧需要从1开始计数。

流控帧的N_PCI需要占用3个字节，其有三个区域FS,BS,STmin。

FS：表示的是流控状态参数。0表示的是继续发送(CTS)，1表示的是等待(WT)，这两个配合使用可以控制发送速度；2表示溢出(OVFLW)，用于接收者告诉发送者数据过大，在首帧后的第一条流控帧应答。

BS：表示的是块的大小，即发送端一次性能够发送多少个连续帧。要注意的是，BS表示的是在发送端没有接受到流控信号时，能够发生的帧的数目。而当BS为0则表示，在数据传输的时，接收端不再发送流控帧了。发送端应当连续不断的发送数据。

STmin：表示的是两个连续帧(FF)的时间间隔。

CANFD下相关数据帧格式会有些不一样，这里不再展开了，有兴趣的去翻翻标准原文。有中文的标准，如下图。

    2.4.3 网络层定时参数

网络层除了定义了网络层相关协议，还定义了定时参数。

N_As:发送方发送CAN数据帧经过链路层发送的时间。

N_Ar:接受方发送CAN数据帧经过链路层发送的时间。

N_Bs:发送方接收流控帧的等待时间。

N_Br:接受方发送流控帧的间隔时间。

N_Cs:发送方发送连续帧的间隔时间。

N_Cr:接受方接收连续帧的等待时间。

具体的参数允许范围，请查看标准ISO 15765-2，这里不展开。

3 基于以太网实现的UDS

DoIP的全称是Diagnostic Over Internet Protocol，即基于TCP/IP协议的诊断协议。随着以太网技术在车载领域的应用范围逐步扩大，越来越多的控制器支持通过以太网进行诊断通信，由于采用以太网通信技术，DoIP诊断具有超高的数据传输速率，速率达到了100 Mbit/s，相较于CAN总线诊断，DoIP诊断总体速率是CAN诊断的100-200倍，网络上的传输速率是CAN诊断的300-400倍。并且硬件成本低，在个人电脑上只需要一个以太网接口即可实现诊断的物理连接。DoIP技术可以完美匹配IT基础设施，固定诊断和远程诊断均能应用，车载以太网技术将是未来解决如何快速更新ECU软件及标定的主要策略之一。

回头来看这张图，ISO 14229-1定义了各种服务规范，与总线无关。所以基于以太网实现UDS，这部分就不需要重新讲了。

ISO 14229-5，也就是UDSonIP，定义了当UDS在以太网总线上实现时需要遵循的一些特有原则，这部分的标准内容不多。

举两个例子，当使用0x10（诊断会话控制服务）时，会导致TCP连接中断，再次开始诊断前，要重新建立TCP连接，并发送路由激活报文。

当使用0x11（ECU复位服务）时，同样会导致TCP连接断开，路由激活失效，再次开始诊断前也要重新建立TCP连接，并发送路由激活报文。

再往下是ISO 14229-2，定义了会话层的相关内容，主要是数据传输/接收的一些参数设置，前文已经讲过了。

最后是我们关注的重点，ISO 13400-2，即DoIP。DoIP协议定义了从物理层(Physical Layer)到应用层(Application Layer)搭建”通信桥梁”的规则(此处可类似 CAN总线的TP层协议ISO 15765-2)

3.1 DoIP的网络架构

支持DoIP的车辆网络架构图如下。

根据ISO-13400的要求，DoIP通信在物理层支持100BASE-TX (100 Mbit/s Ethernet) 和10BASE-T (10 Mbit/s Ethernet) 两种制式。

汽车内部必须有一个DoIP的总网关，它作为和外部的诊断设备DoIP通信的唯一接口。车内网中，直接与外部诊断仪进行物理连接的节点，叫做边缘节点（DoIP edge node）。边缘节点可作为一个网络交换机，将车内网与车外网组成同一子网；也可以作为一个网关，将车内网与车外网进行安全隔离，屏蔽非法的网络访问和网络攻击。除了边缘节点之外，还有另一类网关，即车内的DoIP网关节点。车内DoIP网关节点的作用，是实现以太网到其他网络总线（如CAN、LIN）的报文路由，这样便实现了DoIP诊断与传统网络总线的兼容。多种网络总线汇聚到DoIP网关，这大大的降低了布线的复杂性，并且提高了各总线网络中ECU的诊断效率。车内网络中，还存在一般的DoIP节点，这些节点只支持对自身的诊断，而不具备路由功能。最后，还有一类网络节点（Network node），不具备DoIP诊断功能，与DoIP节点共享网络资源。

3.2 DoIP的数据帧格式

在讲DoIP数据帧格式之前，先回顾下完整的以太网数据帧如下。

IP段数据帧格式如下。在网络层上DoIP使用IPV6协议，但为了向后兼容的原因，也支持IPV4,对于IPV4还要支持地址解析协议(ARP),对于IPV6还要支持邻居发现协议(NDP)，这两个协议都是用于在只知道IP地址的情况下获取MAC地址的。

TCP段数据格式如下。支持DoIP的ECU的诊断服务创建的socket必须监听在端口号13400上，外部测试设备通过连接此端口建立连接；每个支持DoIP的ECU必须支持n+1个并发的TCP socket连接，这是为了防止有多个外部测试设备同时和ECU进行诊断通信；外部测试设备创建的socket应选择本地端口，本地端口即系统随机的端口。

这里解释下套接字的概念，在TCP/IP网络中，区分不同的应用程序进程间的网络通信和连接时主要有以下3个参数：通信的目的地址、使用的传输协议（TCP或UDP）和使用的端口号（此处说明一下，Socket不仅在TCP有，在UDP同样有）。通过将这3个参数结合起来，与一个Socket进行绑定，应用层就可以与传输层一起通过套接字接口区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP/IP交互提供了称为套接字（Socket）的接口。

UDP段数据格式如下。

DoIP段数据格式如下。

DoIP数据帧前面两个字段分别是协议版本和协议版本的取反。第三个字段是数据类型，具体定义如下。

 

常用的数据类型如下：

0x0001至0x0004：用于汽车标识上报或请求，只能通过UDP报文来发送这种命令，主要用于在汽车和诊断仪进入网络之后、诊断连接建立之前的车辆发现过程。

0x0005 和0x0006：标识的Routing activation request 和 response用于在socket建立之后，进行诊断通信的请求。

0x0007和0x0008：用于Alive check，用于检查当前建立的诊断连接socket是否仍然在使用中，如果不再使用，则关闭socket释放资源。

0x8001，0x8002，0x8003：分别代表的含义分别是诊断消息、诊断消息正响应和诊断消息负响应。

Data Length标识后面的user data的长度。

IS0 13400-2标准中给出了一个报文的示例如下。

  3.3 车辆发现与声明

在实现诊断通信之前，需要先发现车辆、建立TCP连接和建立诊断连接。先看车辆发现和声明。

DoIP设备启动后，首先通过UDP广播的形式把一条DoIP报文（vehicle announcement message，Payload Type为0x0004）发给网络上的所有的其他节点，其中就包括诊断仪，目的端口是13400，其中这条消息携带了DoIP设备的DoIP版本、VIN、logical address等信息，这条信息会发送三次，而之前监听在13400端口的诊断仪接收到这条信息，就知道了DoIP设备的基本信息。

如果诊断仪没有收到，还有一种办法，就是诊断仪这边主动请求，通过UDP广播的形式，主动发一条DoIP request消息（Payload Type为0x0001），目的端口号是13400，而之前启动后就一直监听在13400的DoIP设备，接收到这条消息后，就会回复一条携带自己信息的response给诊断仪。

3.4 TCP连接

诊断仪通过创建tcp socket，然后调用connect方法向DoIP设备发起TCP连接请求（目的ip是DoIP设备ip，目的端口号是13400），而DoIP设备在启动前已经通过创建tcp socket监听在13400端口，接收到tcp连接请求后就会完成三次握手。

3.5 诊断连接

Socket一端连接着IP地址，一端连接着Port端口。并且Socket对于芯片而言是一种资源．因此有激活失效之分。在TCP连接建立后，诊断仪还需要发送一条Routing activation request的DoIP报文给DoIP设备，DoIP设备收到后会回复一条Routing activation response的DoIP报文，此时诊断连接建立，双方可以诊断通信。

  4 总结

设计一个复杂的系统后，去建立一个完善的诊断系统，往大了说，是为了提高维修效率，为公司争取经济利益。往小了说，是为了解放工程师自己，售后人员通过标准工具可以定位问题，就不会来找设计人员寻求技术支持。所以，工程师们，大家在设计复杂系统时，都记得给自己留条后路吧，不然量产后填坑会异常痛苦的。

审核编辑：黄飞