什么是14229协议

ISO-14229标准，也称UDS，是一种面向汽车控制单元ECU的同意诊断服务，是目前汽车电子领域运用最广的技术协议之一。

简单的说，ISO-14229就是规定了诊断仪（Tester）与汽车ECU之间进行信息交互时所需要的数据格式，但ISO-14229只规定了与诊断相关的服务需求，并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO-15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO-14229也称为UDS（Unified Diagnostic Services 统一诊断服务）。

诊断服务基本知识

汽车诊断首先由Tester（诊断仪）向ECU发送诊断服务请求（Request），ECU则向Tester发送对应服务请求的响应（Response）。

ISO-14229确认服务使用六个服务原语，即，请求、请求确认、指示、响应、响应确认和确认。

未确认服务仅使用请求、请求确认和指示原语。

对于 ISO 14229 本部分定义的所有服务，请求和指示服务原语务必使用相同的格式和参数。因此，对于所有服务，请求和确认服务原语（除 req_confirm（req_确认）和 rsp_confirm（rsp_确认）外）必须使用相同的格式和参数。

诊断服务通常是指在应用层的服务，应用层服务用于基于客户端-服务器的系统。

诊断应用层服务访问点对于各服务，规定了六种服务原语：

• 服务请求原语：由诊断测试仪应用程序内客户端功能使用，用于向诊断应用层传输请求诊断服务相关数据；
• 服务请求-确认原语： 由诊断测试仪应用程序内客户端功能使用，用于指示服务请求原语传输的
  数据通过车辆通信总线（连接至诊断测试仪）成功发送；
• 服务指示原语：由诊断应用层使用，用于将数据传输至 ECU诊断应用程序服务器功能；
• 服务响应原语：由 ECU 诊断应用程序内服务器功能使用，用于向诊断应用层传输请求诊断服务
  相关数据；
• 服务响应确认原语： 由 ECU 诊断应用程序内服务器功能使用，用于指示服务响应原语传输的
  数据通过车辆通信总线（ECU接收器诊断请求）成功发送；
• 服务确认原语：由诊断应用层使用，用于向诊断测试仪应用程序内客户端功能传输数据。

确认的服务

请求过程：
test发送诊断请求 ——>客户端进行请求确认——>ECU接收到消息后发送指示原语 ——> 对诊断请求进行处理——>并得到诊断消息——>激活响应原语——>向test发送报文——>并进行响应确认——>test进行确认

6个服务原语都使用到了！

未确认的服务

用到了3中请求原语

请求原语格式

所有应用层服务均具有相同的通用格式。服务原语编写格式如下：

其中：

• “service_name（服务名称）”指诊断服务名称（如 DiagnosticSessionControl（诊断会话控
  制）），
• “type（类型）”指服务原语的类型（如服务请求原语），
• “parameter A、 …（参数 A...）” 指服务原语以数值列表形式传输的 A_SDU（应用层协议数据单
  元）（如寻址信息），
• “parameter A、parameter B、parameter C（参数 A、参数 B、参数 C）“指服务请求中须包含的
  强制参数"
• “ [,parameter 1, … （参数 1... ） ] ” 指取决于具体服务的参数（如，参数 1 可 为
  DiagnosticSessionControl（诊断会话控制）服务用 diagnosticSession（诊断会话））。括号表明参数列表本部分可为空。

通常与请求指令格式相同的还有一个指示指令:

这个指示指令和请求指令有着同样的数据格式，但是它是诊断应用的一个重要内部事件，它会传递诊断请求数据到诊断应用层的服务函数。这两个指令的数据格式之所以一样，也是为了保证数据传递的准确性，不会因为数据传递的过程导致数据出现差错。

其中各参数的功能：

• A_Mtype：应用层消息类型（枚举类型，范围：诊断、远程诊断）
• A_SA： 应用层源地址（2 字节无符号整数值，范围：0x0000 – 0xFFFF ）
• A_TA： 应用层目标地址（2 字节无符号整数值，范围：0x0000 – 0xFFFF ）
• A_TA_Type：应用层目标地址类型（枚举类型，范围：物理性、功能性）
• A_Result：（枚举类型，范围：ok、错误）
• A_Length：（ 4 字节无符号整数值）
• A_Data ：（字节串，不适用）

响应原语格式

响应指令格式：

确认指令

确认原语由应用层使用，用于指示对客户端应用程序具有重要意义的内部事件，同时向诊断测试仪应用程序客户端功能传输先前相关服务请求结果。

诊断分层结构

结合ISO 15765-3和ISO 14229-1则实现了基于CAN总线的UDS汽车统一诊断服务。如下图所示：
UDS不是法规要求的，没有统一实现标准，其优势在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。

诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同的诊断功能的request和response定义了统一的内容和格式。

诊断服务

诊断会话控制（0x10）服务

诊断会话控制服务用于启用服务器中的不同诊断会话。诊断会话启用服务器中一组特定的诊断服务或功能。

0x10服务的请求（request）共需要两个byte，第一个byte是SID，第二个byte是sub-function，用于指示ECU将进入的session。

session具体含义：


ECU内部应始终且仅有一个激活的诊断会话，当UCU重启后会进入默认会话，且不需要超时处理。

• 当用户请求重新启动默认会话时，则服务器应该完全重启初始化默认会话（非易失性存储器除外）。

• 当用户请求从默认会话跳转到其他非默认会话时，服务器会停止默认会话期间的相应并通过0x86服务在服务器中配置其他服务。

• 当用户请求在其他非默认会话间跳转时，则服务器会对这些会话就行重新初始化。

• 当用户请求从非默认会话跳转到默认会话时，服务器会启用安全性校验，终止默认会话中不支持的诊断功能，服务器将会通过0x86服务配置默认会话。

响应实例：
这里以CAN帧举例，由于CAN帧一共8个字节，且第一个字节被网络层占用，所以我们实际的服务ID是从第二个字节开始的。

举例：

• 例如Tester请求进入01子服务：
  Tester：02 10 01 00 00 00 00 00
  ECU：06 50 01 00 32 00 C8 00

该回复表明ECU进入01子服务成功！

• 例如Tester请求进入02子服务：
  Tester：02 10 02 00 00 00 00 00
  ECU：03 7F 10 7E 00 00 00 00

该回复表明ECU进入02子服务失败！

• 例如Tester请求进入03子服务：
  Tester：02 10 03 00 00 00 00 00
  ECU：06 50 03 00 32 00 C8 00

该回复表明ECU进入03子服务成功！

说明：
请求数据格式：02 10 02 xx xx xx xx xx ，其中02是网络层单帧SF，表示应用程包含两个字节，10表示为10服务ID，02是子功能–进入编程会话

回复数据格式：XX 50 02 xx xx xx xx xx ，XX表示应用层含XX个字节，50 = 10 + 40表示SID的肯定回复，02是子功能，xx xx xx xx xx为具体数据。

回复数据格式：03 7F 10 7E xx xx xx xx ，03即应用层包含三个字节，10是SID，7E是NRC（否定响应码）。

ECU 重置（0x11）服务

客户端使用 ECUReset（ECU重置）服务来请求服务器重置。

请求消息格式：

sub-function值：

肯定响应消息格式：

其中：sub-function = [ resetType ] powerDownTime为断电时间

举例：

• 例如Tester请求进入01子服务：
  Tester：02 11 01 00 00 00 00 00
  ECU：02 51 01 AA AA AA AA AA

该回复表明ECU进入01子服务成功！

• 例如Tester请求进入02子服务：
  Tester：02 11 01 00 00 00 00 00
  ECU：03 7F 11 12 AA AA AA AA

该回复表明ECU进入01子服务失败！因为并没有开发配置11 02服务，所以没有02 子服务。

• 例如Tester请求进入03子服务：
  Tester：03 11 01 03 00 00 00 00
  ECU：03 7F 11 13 AA AA AA AA

该回复表明ECU进入01子服务成功！请求报文的长度为3字节，正确情况只需要2字节即可。

安全访问（0x27）服务

厂家可能会为ECU定义某些安全级别稍微高一些的诊断服务，在执行此类服务之前，就需要执行SecurityAccess 这个诊断命令，进行一个简单的身份验证。

完成SecurityAccess 有以下步骤：

• 诊断仪向ECU请求“Seed”（通常是一个与时间相关的伪随机数）
• ECU向诊断仪发送“Seed”
• 诊断仪向ECU发送“Key” (根据请求得到的Seed和一个本地的密码进行计算得来)
• ECU判断诊断仪发来的“Key”是否有效

根据UDS的定义，0x03, 0x05, 0x07 – 0x41 这个范围留给用于requestSeed的sub-function；0x04, 0x06, 0x08 – 0x42这个范围留给用于sendKey的sub-function。具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对sub-function，用于不同等级的安全访问。

请求消息格式：

其中功能参数定义：

举例：

• 例如Server在Locked状态：
  Tester：03 27 01 00 00 00 00 00
  ECU：04 67 01 36 57 AA AA AA
  Tester：03 27 02 C9 A9 00 00 00
  ECU：02 67 02 AA AA AA AA AA

该回复表明首先Tester请求Seed ，Server回复肯定响应，并返回Seed ，然后Tester请求Key ，Server回复肯定响应。

• 例如Server在Unlocked状态：
  Tester：03 27 01 00 00 00 00 00
  ECU：04 67 01 00 00 AA AA AA

该回复表明首先Tester请求Seed ，Server回复肯定响应，并返回全0数据，表明目前已经处于解锁状态，不再返回Seed 。

任何时间都仅可有一个安全级别处于活动状态。

例如，如果与 requestSeed（请求种子） 0x03 相关的安全级别处于活动状态，且测试仪请求成功地解锁了与 requestSeed（请求种子） 0x01 相关的安全级
别，则此时仅应解锁与 requestSeed（请求种子） 0x01 相关的安全级别所支持的受保护功能。此前已由与 requestSeed（请求种子） 0x03 相关的的安全级别解锁的任何其他受保护功能应不再处于活动状态。

诊断设备会话保持（ox3E）服务

这个服务的目的是确保诊断服务或者之前激活的通信还处在激活的状态，可以保持当前的非默认（Default Session）会话，通过周期地发送请求帧来阻止自动跳转回默认（Default Session）会话。

请求消息格式：SID+sub-function

举例：

• Tester：02 3E 00 00 00 00 00 00
  ECU：02 7E 00 AA AA AA AA AA

• Tester：02 3E 80 00 00 00 00 00
  ECU：不回复

子功能字节为0x80表示服务器不能去发肯定响应，即使服务器正常去响应请求，也不能发肯定响应消息。

该服务除了具有确定服务端是否在线的操作外还能通过周期的向服务器发送请求消息让服务器保持在非defaultSession诊断会话状态。

具体实现如下：
将诊断会话计时器S3server中记录的还没有超过5000ms的事件记录清楚，让它再从0开始计时，这时要想回到默认会话就要再等5000ms。

按标识符读取数据（0x22）

通过标识符读取数据服务就是用来获取数据标识符所对应的数据记录值的，对于服务端来说，客户端可向服务端一次请求一个或多个数据标识符。

22服务主要应用与以下场景：

• 读取当前ECU的序列号，版本号等；
• 标定成功后读取内部标定结果等；
• 读取当前ECU所处在的Session，内部状态，Snapshot Data等；
• 其他需要读取内部相关参数的场合；

消息请求格式：

dataIdentifier为数据标识符。

肯定响应格式如下：

肯定响应定义：

按标识符写数据（0x2E）服务

按标识符写数据服务允许客户端向服务器中给定数据标识符指定的内部位置写入信息。

本服务的可能用途有：

• 将配置信息编入服务器中（如 VIN）；
• 清除非易失性存储器；
• 重置所得的值；
• 设置选项内容；

数据请求格式：



受支持的否定响应代码：

清除诊断信息 （0x14） 服务

客户端使用清除诊断信息服务清除一个或多个服务器内存中的诊断信息。当清除诊断信息服务彻底处理完成后， 服务器应发送一条肯定响应。

肯定响应格式：

受支持的否定响应代码：

例如：
客户端 --> 服务器：0x04 0x14 0xFF 0xFF 0x33
服务器 --> 客户端：0x01 0x54

其他请求服务

方法已经交给大家，其他请求请也是类似的分析方法，大家可以查看14229协议，里面写的非常详细，如果想要双语版的可以留言，我发给大家！

实战

我们通过CANoe连接ECU，然后向ECU发送请求，观察ECU回复的信息，然后对信息进行解读，这里给大家一个22请求的例子，大家可以自己试着通过查看14229手册分析出该数据对应的含义。

致谢

本文参考一下文章结合自己的理解整理：

• 14229诊断协议（双语版）
• 详解汽车UDS诊断协议（一）
• 统一诊断服务 (Unified diagnostic services ， UDS) （二）