《UDS内容总结办公文档会议纪要_办公文档-会议纪要.pdf》由会员分享，可在线阅读，更多相关《UDS内容总结办公文档会议纪要_办公文档-会议纪要.pdf（19页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、前言.2 UDS 的 7 种服务及肯定响应和否定响应的形式.2$10 诊断会话.3$3E待机握手.4$27 安全访问.4$22 读数据.5$2E写数据.6$19 读 DTC.6$14 清除 DTC.6 统一诊断服务(Unified diagnostic services，UDS)（一）.7 Diagnostic request的格式：.7 统一诊断服务(Unified diagnostic services，UDS)（二）.8 Diagnostic Session Control(0 x10).8 诊断 response的格式：Diagnostic Session Control.9 ECU
2、Reset 诊断 request的格式.9 Security Access(0 x27).9 统一诊断服务(Unified diagnostic services，UDS)（三）.10 Tester Present(0 x3E).11 Control DTC Setting(0 x85).11 Response On Event(0 x86).11 Link Control(0 x87).12 统一诊断服务(Unified diagnostic services，UDS)（四）.12 Read Data By Identifier(0 x22).12 0 x23 服务的请求格式 0 x23.1
3、2 统一诊断服务(Unified diagnostic services，UDS)（五）.13 0 x14:Clear Diagnostic Information.13 0 x19:Read DTC Information.13 统一诊断服务(Unified diagnostic services，UDS)（六）.14 Input Output Control By Identifier(0 x2F).14 Routine Control(0 x31).16 统一诊断服务(Unified diagnostic services，UDS)（七）.16 Request Download（0 x3
4、4）：.17 Transfer Data（0 x36）：.17 Request Transfer Exit（0 x37）：.17 基于 CAN总线实现的 UDS诊断（DoCAN）.18 前言 UDS协议即 ISO14229,是 Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，比如读取故障码应该向 ECU发什么指令，读数据流又是发什么指令。OBD 是关注车辆售后实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范，只是应用层的规范。UDS(Unified diagnostic services)，与 OBD最大的区别就在于“Unified”上
5、，UDS是面向整车所有 ECU(电控单元)的，而 OBD是面向排放系统 ECU的。简单说 UDS而言，它只是一个应用层协议(ISO 14229-1)，所以它既可以在 CAN线上实现(见下图.1)，甚至也能在 Ethernet上实现(DOIP,Diagnostic over Internet protocol 见下图.2)。并且，UDS提供的是一个诊断服务的基本框架，主机厂和零部件供应商可以根据实际情况选择实现其中的一部分或是自定义出一些私有化的诊断服务来，所以基于 UDS协议的诊断又常常被称为 Enhanced diagnostic(增强型诊断)，UDS不是法规要求的，没有统一实现标准，其优势
6、在于方便生产线检测设备的开发，同时更大的方便了售后维修保养和车联网的功能实现。UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是 ISO 15765 和 ISO 14229 定义的一种汽车通用诊断协议，位于 OSI 模型中的应用层，它可在不同的汽车总线（例如 CAN,LIN,Flexray,Internet 和 K-line）上实现。UDS协议的应用层定义是 ISO 14229-1，目前大部分汽车厂商均采用 UDS on CAN的诊断协议。如下图所示，ISO 14229-1 也就是 UDS协议仅对应用层做出了定义，物理层有双绞线和光纤供用户选择，数据链路
7、层采用 CAN总线的 ISO 11898-1 协议，针对 Classical CAN仅有8 个字节的数据场与应用层可处理多帧数据的矛盾，ISO 15765-2 对网络层进行了定义。CAN的 8 字节数据场会腾出一帧来表示网络层的信息。下图右侧是排放相关的协议，ISO 15031-5主要针对 OBD协议，为法规强制要求车厂满足的协议。学习时，我们应在了解 CAN总线基本知识的前提下，着重学习 ISO 15765-2 和 ISO 11898-1 的协议内容，并通过 BootLoader 作为例子，对 UDS有一个大致的了解。UDS 的 7种服务及肯定响应和否定响应的形式 UDS本质上是一系列的服务
8、，共包含 6 大类 26 种。每种服务都有自己独立的 ID，即 SID。SID：(Service ID（Identifier）以下简称 SID)Service，诊断服务 ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给 ECU发送指定的请求数据（Request），这条数据中需要包含 SID。如果是肯定的响应（Positive Response），回复SID+0 x40，就是请求 10，响应 50；请求 22，响应 62，回复的是一组数据。如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。式统一诊
9、断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它肯
10、定响应和否定响应的形式一定要熟记。UDS的 26 种服务中，有 7 种很重要。它们分别是：$10 Diagnostic Session Control（诊断会话），$14 Clear Diagnostic Information（清除诊断信息），$19 Read DTC Information，$22 Read Data By Identifier（通过 ID 读数据），$27 Security Access（安全访问），$2E Write Data By Identifier（通过 ID 写数据），$3E Tester Present（待机握手）。下面对这 7 个服务进行解读。$10诊断会话
11、 Diagnostic Session Control(0 x10)Diagnostic Session Control诊断 request的格式 Diagnostic Session Control这个服务的 SID 是 0 x10，request固定为 2 个 byte，第一个 byte 是 SID，第二个 byte 的低 7bit 是 sub-function，用于指示 ECU将进入的 session。UDS定义的 session包括：0 x00 ISOSAE Reserved（保留）0 x01 default Session 0 x02 Programming Session 0 x0
12、3 extended Diagnostic Session 0 x04 safety System Diagnostic Session 0 x05 0 x3F ISOSAE Reserved（保留）0 x40 0 x5F vehicle Manufacturer Specific（由整车厂自定义使用）0 x60 0 x7E system Supplier Specific（由 ECU供应商自定义使用）0 x7F ISOSAE Reserved（保留）Diagnostic Session Control用于控制 ECU在不同的 session之间进行转换，session可以看作是 ECU所处的
13、一种软件状态，在不同的 session中诊断服务执行的权限不同。ECU上电之后，默认处在 default Session中，在这个 session中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。一般的诊断仪启动之后，会给 ECU发送 10 03，即让 ECU进入 extended Diagnostic Session中，在这个 session中可执行的诊断服务就很多了。而如果要让 ECU保持在 non-default Session中，则需要诊断仪每隔固定的时间发送 0 x3E 服务，ECU才会知道诊断仪有和自己通信的需求，从而保持在 non-default Session中。另一
14、个常用的 session是 Programming Session，在这个 session中可以进行软件刷写的一系列诊断服务。0 x40 0 x5F 这个范围中的 session由整车厂自定义使用，比如，某些诊断服务或诊断数据的操作需要在生产线上执行，即所谓的 End-Of-Line，整车厂可以从这个范围中选择一个值来表示 EOL session；又或者在开发阶段需要某种“超级”session，则也可以从这里选一个值用来使 ECU进入开发模式的 session。Diagnostic Session Control这个服务非常简单，但是它却是 ECU和诊断通信的第一条诊断命令。$10 包含 3
15、个子功能，01 Default，02 Programming，03 Extended，ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被
16、称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它果一段时间内没有请求，那么到时间后，诊断退回到默认会话 01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。UDS包含 4 种类型，即 SID，SID+SF（Sub-function），SID+DID（Data Identifier）（读写用），SID+SF+DID。NRC：Negative Response Code（否定响应码）。如果 ECU拒绝了一个请求，它会回应一个 NRC。不同
17、的 NRC有不同的含义。14229-1 协议第 329 页 单词：Consult（查阅）Session（会话）DTC（diagnostic trouble code）故障码Handling（处理）Conditions（条件）restricted（受限的）Concept（概念）SA（source address 源地址）TA（目标地址）例子：以 CAN总线网络举例。八个帧数据字节，第一字节被网络层占用。请求（Request）:02 10 02 xx xx xx xx xx;02 中的 0 代表网络层单帧 SF，2 代表 数据域有 2 个字节；SF，数据域有 2 个字节，10 是 SID，02 是
18、子功能。肯定响应:02 50 02 xx xx xx xx xx；02 同上，10+40 表示对 SID 的肯定回复，02 是子功能。否定响应:03 7F 10 22 xx xx xx xx；03 同上，7F表示否定响应，10 是 SID，22 是 NRC。$3E待机握手 Tester Present(0 x3E)这个诊断服务的用处可以通过它的名字很明显地得知，即告知 ECU诊断仪还在连接着。在上一篇文章中我说到了关于 session的部分，如果没有诊断命令的发送和接收，ECU将从non-default session中回退到 default session，0 x3E 就是用于使 ECU保持
19、在当前session。这应该是 UDS中最简单的一个诊断服务了，它永远只有两个 byte，格式如下：0 x3E 诊断服务的格式 当 sub-function是 0 x00 时，ECU要给出 response；当 sub-function是 0 x80 时，ECU不需要要给出 response。一般来说主机厂会为这个服务定义两个时间参数，一个参数用于规定自己的诊断仪发送0 x3E 服务的间隔，另一个参数用于定义 ECU收不到 0 x3E 服务的 timeout时间。$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。0 x3E 就是用于使 ECU保持
20、在当前 session。这应该是 UDS中最简单的一个诊断服务了，它永远只有两个 byte，格式如下：例子：02 3E 80 00 00 00 00 00，发送一个 3E服务的报文，保持非默认会话状态。80 表示无需回复。$27安全访问 Security Access(0 x27)厂家可能会为 ECU定义某些安全级别稍微高一些的诊断服务，在执行此类服务之前，就需要执行 Security Access 这个诊断命令，进行一个简单的身份验证。完成 Security Access 有以下步骤：诊断仪向 ECU请求“Seed”（通常是一个与时间相关的伪随机数）,式统一诊断服务二诊断的格式诊断的格式统一
21、诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它ECU向诊断仪发送“Seed”诊断
22、仪向 ECU发送“Key”(根据请求得到的 Seed 和一个本地的密码进行计算得来)ECU判断诊断仪发来的“Key”是否有效 根据 UDS的定义，0 x03,0 x05,0 x07 0 x41 这个范围留给用于 request Seed的sub-function；0 x04,0 x06,0 x08 0 x42 这个范围留给用于 send Key 的 sub-function。具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对 sub-function，用于不同等级的安全访问。下面我举一个完成 Security Access的诊断命令的例子，假设 0 x05 用于 request Seed，
23、0 x06 用于 send Key。诊断仪发送 27 05 ECU响应 67 05 01 01 01（seed 是 01 01 01）诊断仪发送 27 06 02 03 04（key 值是 02 03 04，seed 是 01 01 01，假设本地密码为 01 02 03，而算法就是将密码与 seed 相加）ECU验证成功 67 06 此时 ECU就处于 unlocked 的状态了，那些被保护起来的诊断服务和诊断数据可以被操作了。通常来说，如果 ECU重启，或者回到了 default session，unlocked 状态就失效了，如果要执行相关诊断服务，则需要再次执行上面描述的过程。$27
24、安全访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定的状态（Locked），我们通过$27 服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。比如下面的例子，2n-1 是一个子服务，通过首轮种子的请求，首轮 ECU会返回 67+01+AA+BB+CC+DD，AADD 就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成 k1（不一定是 1 个字节），那么发送请求，27+02+k1。ECU同样也会通过种子算出 k2。当 k1 和 k2 匹配时
25、，解锁（Unlocked）成功。$27 安全访问服务的否定响应服务 ID 也是 7F。还记得刚才否定响应的格式吗7F+27+NRC Rx：02 27 05 00 00 00 00 00 安全访问，05 子功能 Tx：07 67 05 08 27 11 F0 77 肯定响应，回复了对应安全级别的种子 Rx：06 27 06 FF FF FF FF 00 发送密钥，4 个 FF。注意 06 是与 05 成对使用的。Tx：03 7F 27 78 00 00 00 00 否定响应，7F+27+NRC Tx：02 67 06 00 00 00 00 00 肯定响应，通过安全校验$22读数据$22 读数据
26、，Request（请求）：22+DID（Data Identifier，通常是两个字节）Response（响应）：62+DID+Data DID有一部分已经被 ISO 14229-1 规定了。比如 0 xF186 就是当前诊断会话数据标识符，0 xF187 就是车厂备件号数据标识符，0 xF188 就是车厂 ECU软件号码数据 ID，0 xF189 就是车厂 ECU软件版本号数据标识符。式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应
27、用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它$2E写数据$22 写数据，Request（请求）：2E+DID+Data Response（响应）：6E+DID 注意，比如 0 xF186 这个 DID不支持直接写入数据，需要用$10 来进行会话转换
28、。也就是说，对于写数据的请求，一般来说需要在一个非默认会话，和解锁的状态下才能进行。$19 读 DTC DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将存储为 DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常 DTC占用 3 个字节，OBD II占用两个字节。图中 FTB为 Fault Type Byte。故障码包括四个大类，分别是 PCBU，P是 powertrain动力系统，C是 Chassis 底盘，B是 Body 车身，U是 network
29、通信系统。一个 DTC信息占用 4 个字节。最后一个字节是 DTC的状态。前两个字节是我们熟知的类似P0047 的故障码。LowByte 暂不清楚。$19 拥有 28 个子服务（Sub-Function）。常用的子服务有 02（通过 DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读 ECU支持的所有 DTC数据）。刚才提到，一个 DTC除了它自己的 3 个字节，还有一个字节专门用于表达 DTC的状态。这个状态字节每个位的含义可以查询 ISO 14229-1。注意，并不是所有的 DTC状态都是支持的。下图是 Request/Response。括号标识循环，可以读出
30、很多 DTC。$14清除 DTC 清除（复位）DTC格式，它可以改变 DTC的状态。3 个 FF代表清除所有 DTC。Request：14+FF+FF+FF；Response：54。我们刚才学完了 7 种重要的服务，SID。除此之外，在 CAN总线中，Addressing information寻址信息通过 CAN帧 ID 体现出来。通讯的模式分两种，一种是物理寻址（点对点），根据物理地址的不同进行访问，但只能访问单个 ECU节点，Test 为 SA源地址，ECUX 作为 TA目标地址；对应的，另一种是功能寻址（广播），根据功能的不同进行访问，它能访问多个 ECU节点。每一个 ECU都有 2
31、个 CAN帧 ID，分别对应收和发的物理寻址。以上只是一些粗浅的理解。对 26 种服务更详细的解读请拉到屏幕下方参考张老师的 8篇文章。张老师也开通了微信公众号，可以了解一下。式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断
32、不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它UDS应用的设备：在 UDS 诊断产品中知名度最高，应用最广泛的是德国 Vector 公司的CAN case 配合其 CANoe 软件，Vector 产品功能齐全，适合系统级汽车总线开发，被大部分汽车厂商采用。Vector 产品因不开放 API，不能做二次开发且价格昂贵，不适用于硬件开发团队和生产线的自动化测试。目前市面上有很多 CAN 厂商（如 Kvaser,ZLG 等）能提供低成本、体积小、驱动简单、开放 AP
33、I 的设备，很适合进行二次开发。杂记 变速器控制单元 TCU和防抱死系统 ABS是 CAN车载网络上的两大电子控制单元，这 2个 ECU要通过 CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因，2 个控制单元之间可能会出现通信丢失的现象。控制系统需要将故障信息（例如通信丢失故障信息）诊断出来，以处理通信被破坏时出现丢失帧的故障现象，并记录为 DTC（diagnostic trouble code）。ECU的输入信号主要有 4 种形式：模拟信号（水温、油压、蓄电池电压等）；数字信号（各种开关信号等）；PWM 信号（脉冲信号、频率信号等
34、）；网络信号（CAN、LIN上传输的信号）。微控制器可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等，大多数为数字信号。统一诊断服务(Unified diagnostic services，UDS)（一）UDS由 ISO-14229 系列标准定义，ISO 14229-1 定义了诊断服务，不涉及网络及实现，只有应用层的内容。而 ISO 14229-3 则定义了 UDS在 CAN总线上的实现。诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而 UDS就是为不同的诊断功能的 requ
35、est和 response定义了统一的内容和格式。Diagnostic request的格式：Diagnostic request的格式可以分为两类：一类是拥有 sub-function的，一类是没有 sub-function的，如下面两张图所示。Service ID(以下简称 SID)的长度固定为 1 个字节，代表了这条诊断命令执行的什么功能。Sub-function的长度也是 1 个字节，它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。Parameter 则根据各个诊断服务的不同具有不同的内容，长度和格式并没有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服
36、务执行的时间等。parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容。有一点要补充的是，其实 sub-function严格来说是 7 个 bit，而不是 1 个 byte，因为它的最高位 bit 被用于抑制正响应（suppress positive response,SPR），如果这个 bit 被置 1，则 ECU不会给出正响应（positive response）；式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是
37、应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它如果这个 bit 被置 0，则 ECU会给出正响应。这样做的目的是可以告诉 ECU不要发不必要的 response，从而节约通信资源。Diagnostic response 的格式：Diagnostic
38、 response分为 positive和 negative两类。positive response意味着诊断仪发过来的诊断请求被执行了 negative response则意味着 ECU因为某种原因无法执行诊断仪发过来的诊断请求，而无法执行的原因则存在于 negative response的报文中。positive response positive response的格式如上图所示，也基本上是由三部分组成，其中的 response SID这个字节作为诊断请求的 echo，它等于 SID+0X40。后面的两个部分则视具体的诊断服务而定。negative response negative r
39、esponse的格式固定为 3 个字节，第一个字节为 0 x7F，第二个字节是被拒绝掉的SID，第三个字节是这个诊断服务无法被执行的原因。下面这张图列举了部分原因代码，比如，如果 ECU给出 7F 22 13 这个 negative response，则说明 22 这个服务因为诊断请求数据长度不对的原因无法执行。总结：诊断通信的过程就是诊断仪和 ECU交换数据，前者发的是 request，后者发的是response，而 UDS最重要的作用就是定义了这些 request和 response的格式和内容。统一诊断服务(Unified diagnostic services，UDS)（二）UDS定义
40、的诊断服务从逻辑来说分为以下几类：Diagnostic and Communication Management（诊断和通信管理）Data Transmission（数据传输）Stored Data Transmission（存储数据传输，用于操作 DTC）Input Output Control（IO 控制）Routine Control（不知如何翻译好，作用是调用 ECU内部的预置函数）Upload Download（上传下载）UDS规定使用 1 个 byte 来表示诊断服务，即所谓的 Service ID,简称 SID。本文介绍一下Diagnostic and Communication
41、 Management 这一类诊断服务中的一部分。Diagnostic Session Control(0 x10)Diagnostic Session Control诊断 request的格式 Diagnostic Session Control这个服务的 SID 是 0 x10，request固定为 2 个 byte，第一个 byte 是 SID，第二个 byte 的低 7bit 是 sub-function，用于指示 ECU将进入的 session。UDS定义的 session包括：0 x00 ISOSAE Reserved（保留）0 x01 default Session 0 x02
42、Programming Session 0 x03 extended Diagnostic Session 式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时
43、更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它0 x04 safety System Diagnostic Session 0 x05 0 x3F ISOSAE Reserved（保留）0 x40 0 x5F vehicle Manufacturer Specific（由整车厂自定义使用）0 x60 0 x7E system Supplier Specific（由 ECU供应商自定义使用）0 x7F ISOSAE Reserved（保留）Diagnostic Session Control用于控制 ECU在不同的 sessio
44、n之间进行转换，session可以看作是 ECU所处的一种软件状态，在不同的 session中诊断服务执行的权限不同。ECU上电之后，默认处在 default Session中，在这个 session中很多诊断服务不可以执行，很多诊断相关的数据不能读取或写入。一般的诊断仪启动之后，会给 ECU发送 10 03，即让 ECU进入 extended Diagnostic Session中，在这个 session中可执行的诊断服务就很多了。而如果要让 ECU保持在 non-default Session中，则需要诊断仪每隔固定的时间发送 0 x3E 服务，ECU才会知道诊断仪有和自己通信的需求，从而
45、保持在 non-default Session中。另一个常用的 session是 Programming Session，在这个 session中可以进行软件刷写的一系列诊断服务。0 x40 0 x5F 这个范围中的 session由整车厂自定义使用，比如，某些诊断服务或诊断数据的操作需要在生产线上执行，即所谓的 End-Of-Line，整车厂可以从这个范围中选择一个值来表示 EOL session；又或者在开发阶段需要某种“超级”session，则也可以从这里选一个值用来使 ECU进入开发模式的 session。Diagnostic Session Control这个服务非常简单，但是它却是
46、 ECU和诊断通信的第一条诊断命令。诊断 response的格式：Diagnostic Session Control 这个诊断服务的 response分为三部分，第一部分是 0 x50，作为 SID 的 echo；第二部分是进入的 session，作为 sub-function的 echo；第三部分是 4 个字节，前两个字节代表 P2 Server_max，即 ECU在应用层上对诊断命令的响应时间，后两个字节代表 P2*Server_ max，即 ECU在暂时无法处理当前诊断命令（具体表现为发送了 NRC 0X78），在应用层上对诊断命令响应的最长时间。ECU Reset 诊断 reques
47、t 的格式 ECU Reset(0 x11)ECU Reset 这条指令的用途是通过诊断请求使 ECU重启。ECU Reset 这个服务的 SID 是 0 x11，request固定为 2 个 byte，第一个 byte 是 SID，第二个 byte 的低 7bit 是 sub-function，用于指示 ECU将模拟哪种方式进行重启。常用的 sub-function包括（只举 2 个例子，UDS还定义了很多其他的值）0 x01 hard Reset 模拟 KL30的重启 0 x02 key Off On Reset 模拟 KL15的重启 当我们通过诊断命令改写了 ECU的某些数据，或者对 E
48、CU进行了某些设置，只有将 ECU重启才能将这些配置生效，所以就有了这个诊断命令。在 ECU Reset 执行之后，ECU会从Non-default session回退到 default session中。Security Access(0 x27)式统一诊断服务二诊断的格式诊断的格式统一诊断服务三统一诊断服务四服务的请求格式统一诊断服务五统一诊断服务六统一诊断服务七基于总线实现的诊断前言协议即是统一诊断服务是诊断服务的规范化标准比如读取故障码应该范只是应用层的规范与最大的区别就在于上是面向整车所有电控单元的而是面向排放系统的简单说而言它只是一个应用层协议所以它既可以在线上实现见下图甚至也能在
49、上实现见下图并且提供的是一个诊断服务的基本框架主机厂和断又被称为增强型诊断不是法规要求的没有统一实现标准其优势在于方便生产线检测设备的开发同时更大的方便了售后维修保养和车联网的功能实现统一的诊断服务诊断协议是和定义的一种汽车通用诊断协议位于模型中的应用层它厂家可能会为 ECU定义某些安全级别稍微高一些的诊断服务，在执行此类服务之前，就需要执行 Security Access 这个诊断命令，进行一个简单的身份验证。完成 Security Access 有以下步骤：诊断仪向 ECU请求“Seed”（通常是一个与时间相关的伪随机数）,ECU向诊断仪发送“Seed”诊断仪向 ECU发送“Key”(根据
50、请求得到的 Seed 和一个本地的密码进行计算得来)ECU判断诊断仪发来的“Key”是否有效 根据 UDS的定义，0 x03,0 x05,0 x07 0 x41 这个范围留给用于 request Seed的sub-function；0 x04,0 x06,0 x08 0 x42 这个范围留给用于 send Key 的 sub-function。具体选择哪对值，由整车厂自己定义。整车厂也可以选择多对 sub-function，用于不同等级的安全访问。下面我举一个完成 Security Access的诊断命令的例子，假设 0 x05 用于 request Seed，0 x06 用于 send Ke