UDS服务基础篇之28

前言

首次，请教大家关于诊断服务28的几个问题：

• 28服务有何作用，为什么要有28服务呢？
• 28服务在使用过程中有哪些注意事项呢？
• 28服务诊断请求与诊断响应如何交互？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

---

正文

服务功能

功能描述

根据ISO14119-1标准中所述，诊断服务28服务主要用于网络中的报文发送与接受，比如控制应用报文的发送与接收，又或是控制网络管理报文的发送与接收，以便满足一定场景下的应用需求。

下列文中使用到的Client可直接理解为上位机Tester，Server可直接理解为接受Tester诊断请求的ECU。

应用场景

一般而言，对于28诊断服务，主要应用场景为以下场合：

• 存在某些特殊的测试场景，比如只希望接收或者发送对应的网络管理与应用报文；
• 绝大多数情况下应用在刷写ECU的过程中，即在预编程条件下执行28服务功能寻址便可以抑制总线应用报文与网络管理报文的发送与接收，以便减少网络总线负载，提高ECU下载效率，同时刷写结束后也要执行28服务使能对应控制报文的发送与接收，在此过程中一般会配合85服务一起使用，后期会给大家介绍，敬请关注。

上述这些应用场景较为常见，这里就不一一列举。

通信控制基本原理：

如下图1所示，针对28服务的通信控制过程会经过如下几个AUTOSAR BSW模块进行处理，然后完成最终的通信控制，具体步骤如下：

• Tester发送28通信控制服务请求给到Server，Server会将该诊断报文请求传递至DCM模块；
• DCM模块调用28服务对应的上层应用函数首先进行输入参数的基本校验，校验无误之后然后传递相关控制模式请求至BswM模块；
• BswM模块根据静态配置的规则来实现对应请求中的通道通信状态控制；(常见的模式控制为3X4 = 12种)

如下表1所示，列举出了常见的12种的通信控制模式：

表1 12种常见的通信控制模式

如下图1所示为28通信控制的原理图，可以看到28诊断服务经过DCM，BswM，Com，NM完成整个上述12种通信模式的控制。其中蓝色表示的部分为最终完成通信控制的函数体。

对于BswM以及NM模块还不是很熟悉的小伙伴，可以参考我之前的文章AutoSAR之基础篇CanNM (qq.com))以及AUTOSAR基础篇之BswM (qq.com)。

图1 28服务通信控制原理图

服务请求

服务请求是Client发送给到Server的诊断服务指令。

请求格式

按照ISO14229-1标准所述，如下图2所示为28服务诊断请求格式，即上述通信控制原理中诊断服务请求格式：

图2 28诊断服务请求格式

值得注意的是28服务诊断请求中的nodeIdentificationNumber仅在subFunction等于4或者5才有效，否则#4，#5参数可以不存在。

下图3中各参数解释如下：

图3 28诊断服务请求格式说明

如下图4所示，为上述subfunction(control Type)中的各项取值的具体含义：

图4 28诊断服务subfunction取值说明

如下图5所示为communicationType的各项取值具体含义：

图5 28服务communicationType定义说明

请求实例

以抑制网络管理报文发送为例，28服务诊断请求实例如下图6所示：

图6 28服务抑制网管报文请求实例

以控制远程特定地址节点进入仅诊断模式为例，节点地址为0x00 0A, 28服务诊断请求示例如下：

图7 28服务特定节点进入诊断模式请求实例

关于控制控制远程特定地址节点进入正常工作模式，这里就不一一列举，具体message Flow可参考ISO14229-1规范。

服务响应

服务响应是针对Client对Server诊断请求的响应。

正响应格式

如下图8所示，为28诊断服务的正响应格式：

图8 28诊断服务正响应格式

从上图中可以看出，28诊断服务的正响应由以下三个部分组成：

• Response ID：该参数固定为SID+0x40 = 0x68；
• SubFunction：该参数为上述诊断请求格式中controlType;

正响应实例

抑制网络管理报文发送

如下图9所示，为上述28 01 02请求示例所对应的正响应：

图9 28 01 02正响应示例

其中，0x01就是跟诊断请求中的controlType保持一致即可。

控制远程特定地址节点进入仅诊断模式

如下图10所示，则为上述28 04 01 00 0A的所对应的正响应。

图10 28 04 01 00 0A正响应示例

负响应NRC支持

绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于27服务而言支持的NRC如下表2：

表2 28服务NRC支持

• 当诊断请求的subfuntion不在Server支持的范围内时，则Server会回复”7F 28 12“；
• 当发送报文长度或者格式不对时，则Server会回复"7F 28 13"；
• 例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指请求时，Server将会回复“7F 28 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。
• 当communicationType与nodeIdentificationNumber均超出规定的范围时，则Server会回复**“7F 28 31”**；

常见Bug大揭秘

对于从事过UDS开发的小伙伴可能会发现，其实针对每个服务的Bug都是有迹可循的，万变不离其宗，绝大多数问题都是由于针对需求理解不清晰或者其他人为因素导致的问题。

因此，为了方便大家能够在工作过程中能够快速找到问题症结所在，特将小T了解到的常见28服务Bug分享给到大家，当然具体问题还是要具体分析，小T这里所列出的只是比较典型且出现错误次数较多的Bug，仅供参考。

图11 28服务常见Bug大揭秘

---

更多精彩内容！敬请关注公众号: ADAS与ECU之吾见，
公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！