UDS服务基础篇之85_uds 85服务，2024年最新聊聊 物联网嵌入式开发 开发的现状和思考

用户33914928060
206 阅读7分钟

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。 img img

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

  • 用于在诊断刷写的过程中关闭DTC记录，因为在刷写的过程中往往是针对某个ECU节点单独进行刷写，其他的对手件ECU节点始终处于正常工作状态，那么此时应当发送功能寻址给到各ECU节点使得其停止记录DTC，刷写完成之后在重新开启对手件DTC记录功能即可。
  • 用于某些特殊不需要记录DTC的场景；

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

除了在哪些应用场景下使用，在此还需要针对85服务提出如下几点注意事项：

  • 当通过85服务控制DTC不报出时，也就意味着当前DTC的状态将不会更新，DTC状态将保持现状；
  • 一旦85服务控制DTC报出或者session超时回到默认会话或者软件复位等操作时，那么此时DTC状态将会继续保持更新；
  • 当85服务控制DTC不报出时，此时执行14清除DTC服务时，DTC的状态将会正常被14服务处理，不会收到85服务的影响；
  • 如果某event并没有Mapping DTC，那么85服务将不会对这个event做任何处理，因为85服务处理的基本对象是DTC；
  • 如果某故障event发生会触发安全行为，此时如果执行85服务抑制DTC，同时触发14服务那么DTC状态将会被清除，相应的安全行为可能失效，因为对于安全关键系统，一般建议出现这种情况时，已触发的安全行为不应该被同步抑制；

DTC控制基本原理：

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

  • Client 发送诊断指令给到Server，Server接收到指令后内部会置位某全局变量；

  • 软件内部故障触发时，会首先检查如下两个条件是否满足才会进行event的处理；

    • enable condition是否满足；
    • **DTC控制有无关闭(85服务)；**只有当enable condition满足并且抑制DTC上报的开关为FALSE的情况下，上报的故障事件才能够得到进一步处理；

在这里插入图片描述

图1 85服务DTC控制原理图

服务请求

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

请求格式

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

在这里插入图片描述

图2 85诊断服务请求格式

一般来说参数DTCSettingControlOptionRecord几乎不使用，仅用到前面两个参数，一个是SID，另外一个是DTCSettingType。

下图3中各参数解释如下：
在这里插入图片描述

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

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

在这里插入图片描述

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

请求实例

关闭DTC监控(OFF)

以抑制DTC上报为例，85服务诊断请求实例如下图5所示：

在这里插入图片描述

图5 85服务抑制DTC上报请求实例

开启DTC监控(ON)

以开启DTC上报为例，85服务诊断请求实例如下图6所示：

在这里插入图片描述

图6 85服务使能DTC上报请求实例

服务响应

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

正响应格式

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

在这里插入图片描述

图7 85诊断服务正响应格式

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

  • Response ID：该参数固定为SID+0x40 = 0xC5；
  • SubFunction：该参数为上述诊断请求格式中DTCSettingType;
正响应实例

关闭DTC监控(OFF)

如下图8所示，为上述85 02请求示例所对应的正响应：

在这里插入图片描述

图8 85 02正响应示例

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

开启DTC监控(ON)

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

在这里插入图片描述

图9 85 01正响应示例

负响应NRC支持

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

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

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

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。 img img

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

avatar
文章
阅读
粉丝