诊断与通讯管理功能单元详解

欢迎来到​​《UDS协议详解系列》​​的第2篇文章，本文将开始介绍ISO14229定义的功能单元，内容主要基于ISO14229来阐述，以期待让人明白如何阅读该协议，同时也能较全面地介绍最常用的服务。先来了解诊断与通讯管理功能单元，其中最常用的是诊断会话控制（$10）和安全访问（$27）。

图1 诊断与通讯管理功能单元列表，引自[1]

诊断会话控制服务（$10）

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

图2 诊断会话，引自[1]

图3 会话模式切换关系示意

这里分为三种会话模式，主要考虑的是服务的使用权限问题，不同会话模式下能使用的服务有区别，如图4所示。默认会话是指ECU在刚上电时保持的会话状态，其服务的使用权限小，即可操作的功能单元服务少，比如图4所示，不能使用27，28，83，84等服务；编程会话是仅使用与刷写程序相关的诊断服务，比如图4所示的27，31，34，36，37等服务；而扩展会话相较于默认会话，其使用服务的权限大，即可操作的功能单元服务多，默认会话模式下不能使用的服务，在扩展模式下都能使用。这里引用一个例子说明下三者的关系：

引自[2]: 这三个会话模式好比普通项目成员(默认会话)、项目组长(扩展会话)和会计(编程会话)的关系，小职员权限最小，小职员有的权限项目组长全有，项目组长还多了些其他的高端权限（如写数据、例程控制）。会计则不同，它有些自己独有的权限（刷写程序），但项目组的很多权限它没有（读/擦故障码），因为它只干会计相关的事，本身不参与项目。

图4 不同会话模式下服务允许使用的情况，引自[1]

总的来说，服务端（ECU）一定处于这三种会话模式的一种，图3大致示意了它们之间的切换关系，这里再详细了解下，如下图5所示。

• 当ECU上电时，ECU总是从默认会话模式开始；
• 当ECU上电后，非默认会话没被激活时，ECU会一直处于默认会话模式；
• 当非默认会话被激活时，ECU会进入非默认会话；
• 当进入非默认会话后，如果服务端的S3定时器超时或请求了默认会话，将进入默认会话；
• 当进入非默认会话后，如果控制服务端的S3定时器不超时，比如使用待机握手服务（$3E），则即可进行编程会话与扩展会话切换，也可相应的会话模式进行所允许的服务。

图5 会话模式切换情况示意，引自[3]

这里解释下S3定时器：

S3server：服务器的定时参数，通常取5000ms，仅用于非默认会话模式。该定时器是在系统通过功能寻址检测器将原先的默认会话模式切换为非默认会话模式时使用。在S3Server 时间内，如果服务端没有收到任何诊断请求服务，则退出非默认会话，返回默认会话。

S3client：客户端的定时参数，通常取4000ms，客户端为保持非默认会话自动化连接，两个连续的待机握手服务请求的间隔时间。

即ECU处于非默认会话模式，如果不使用3E服务，如果5000ms都没有诊断服务请求，则会跳转到默认会话；如果使用3E服务，且每4000ms请求一次，则不管是否有其他诊断服务请求，都可以使ECU保持在非默认会话模式。

诊断会话控制服务，即$10，采用请求格式是SID+SF(sub-function,子功能)，即图6所示。

图6 引自[1]

其中SF的定义如下图7，即请求默认会话模式，则客户端发送10 01；请求编程会话模式，则发送10 02；请求扩展会话模式，则发送10 03；这里只介绍最常用的三种子功能。

图7 引自[1]

当客户端发送诊断服务请求，那么服务端收到就需要响应，其正响应格式如下图8，即请求10 01，则响应50 01 xx xx xx xx；请求10 02，则响应50 02 xx xx xx xx；请求10 03，则响应50 03 xx xx xx xx。这里正响应信息数据参数的定义如下图8：

图8 引自[1]

注：通常设置P2server_max=50ms，P2*server_max=5000ms，这样上述响应的xx xx xx xx为00 32 01 F4。即以请求编程会话为例，如下图9所示：

图9 引自[1]

当客户端发送诊断服务请求，服务端负响应时，这时负响应格式为 7F+SID+NRC，负响应支持的部分NRC如下图10。比如请求10 05，但未定义05，即不支持该子功能，则产生负响应7F 10 12；比如请求10 01 01，不符合请求格式SID+SF的长度，则产生负响应7F 10 13。

图10 引自[1]

注：在实际测试过程中，经常碰到先响应7F 10 78，再正响应或负响应。

即先悬置当前请求，响应完上一条请求再响应当前请求，关于78的具体解释如下图11所示

图11 引自[1]

以上就是诊断会话控制服务（$10）的介绍，总结如下：

由上图4可知，一旦激活某种会话模式，那就可确定所允许使用的服务。下面要介绍的安全访问服务（$27），就是ECU处于非默认会话模式才允许使用。

安全访问服务（$27）

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

图12 引自[3]

那么具体怎么实现？如下图13示意：先客户端（也叫测试端）请求种子，再服务端（ECU）发送种子，然后客户端根据种子计算密钥，发送密钥，最后服务端确认密钥，有效则解锁。

图13 引自[3]

上图中请求种子使用的格式是27 2n-1，原因之一是根据请求信息定义而来，如下图14，请求种子的子功能均为奇数。原因之二是ECU需要解锁情况有多种，比如扩展会话模式下读写数据前需要解锁，比如采用27 01；编程会话模式下刷写程序前也需要解锁，比如采用27 03；当然可能还包括其他情况，故上图采用27 2n-1就更具有概括性，可适用多种情况。

图14 引自[1]

当请求种子后，ECU就需要响应，发送种子，其定义如下图15，发送种子的子功能均为偶数。

图15 引自[1]

以上不管是请求种子还是发送种子所涉及的子功能，其完整定义如下，总的来说，具体使用27 01还是27 03，或者27 2n-1来请求种子，一般均由整车厂来定义。

图16 引自[1]

同样地对于上述具体发送怎样的种子，是否需要设置安全访问数据参数，以及根据种子采用何种算法计算密钥，一般也均由整车厂来定义。

图17 引自[1]

关于正响应格式定义如下，比如使用27 01 请求种子，那么使用67 01 XX XX发送种子。

图18 引自[1]

为了加深对上面内容的理解，来看一个具体的例子，假设ECU处于上锁状态，我们定义27 01请求种子，种子为0x3657，27 02发送密钥，密钥为种子的二进制补码值，即0xC9A9。那么解锁过程如下：

图19 引自[1]

通过上述过程，我们知道ECU已经处于解锁状态了，如果这时再使用27 01请求种子，那么ECU将响应67 01 00 00，表明ECU已经解锁了，如下所示。

图20 引自[1]

假设上述的27 01定义的应用层读写数据的解锁，而27 03定义的是刷写程序的解锁，那么像上述的ECU解锁了应用层读写数据，但这时又需要解锁刷写程序，这时当前解锁状态是不支持刷写程序的，就需要通过27 03来请求种子。总的来说，安全状态处理如下图21所述：

图21 引自[3]

最后介绍下$27所支持的部分负响应类型，如下所示：

图22 引自[1]

继续采用上面的假设介绍部分NRC：ECU处于上锁状态，27 01请求种子，种子为0x3657，27 02发送密钥，密钥为种子的二进制补码值，即0xC9A9，密钥允许连续错误3次。

若请求种子27 01，发送种子67 01 36 57， 发送密钥27 02 A9 A9，这时密钥不对，ECU负响应7F 27 35，表明密钥不对。如果这时密钥连续不对超过3次，ECU负响应7F 27 36。如果密钥未到规定时间发送，ECU负响7F 27 37，表明密钥发送超时。

到此就基本介绍完了安全访问服务（$27），稍作总结如下：

以上就主要基于ISO14229协议介绍了诊断与通讯管理功能单元的最常见的两种服务（$10和$27），关于本单元的其他服务，可查阅[1]以供练习，或是参考[2]，理解好了这两种服务后，其他服务就在此基础上去实现相应的功能。

文章转载自公众号：汽车电子与软件