UDS诊断(ISO14229-1) 85服务

本文介绍了AUTOSARUDS中的85服务(ControlDTCSetting),用于控制DTC状态更新,包括应用场景、控制原理、请求与响应格式,以及NRC的使用。特别强调了在诊断刷写和特殊场景下DTC控制的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

功能简介

85服务,即 ControlDTCSetting(控制 DTC 设置)服务,该服务用于停止或继续ECU中 DTC 状态位的更新(是否记录DTC)。

可以使用 ControlDTCSetting(控制 DTC 设置)请求消息来停止个别ECU或一组ECU中 DTC 状态位的更新。

应用场景

常见场景:

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

DTC控制基本原理

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

  • Client 发送诊断指令给到Server,Server接收到指令后内部会置位某全局变量;
  • 软件内部故障触发时,会首先检查如下两个条件是否满足才会进行event的处理;
    • 1、enable condition是否满足;
    • 2、DTC控制有无关闭(85服务);

只有当enable condition满足并且抑制DTC上报的开关为FALSE的情况下,上报的故障事件才能够得到进一步处理;
在这里插入图片描述

请求和响应

1、请求

基本格式

归纳起来,诊断的request格式无非以下两种:

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

即有无sub-function的区别。Parameter可以是DID,可以是输入参数,可以是自定义的值,字节数视具体要求而定。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2、子功能

子功能参数定义(1字节数据):

  • Bit7:抑制肯定响应消息指示位suppressPosRspMsgIndicationBit
    • 0=False:需要肯定响应
    • 1=True:禁止肯定响应
  • Bit6-0:子功能参数值(0x00~0x7F)

无。

3、肯定响应

基本格式:

<SID + 0x40> + <Sub-function> + <Parameter>

<SID + 0x40> + <Parameter>

要注意,第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的,具体要看协议规定。

在这里插入图片描述

4、否定响应

基本格式:

<0x7F> + <SID> + <NRC>

看起来比较简单,格式比较固定,只要是Negative Response,第一字节就是0x7F,第二字节照抄原来的SID,第三个字节是错误响应码,指示具体错误响应的原因
在这里插入图片描述
在这里插入图片描述

注意

  • 当通过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状态将会被清除,相应的安全行为可能失效,因为对于安全关键系统,一般建议出现这种情况时,已触发的安全行为不应该被同步抑制;

报文示例

  • 示例 1—ControlDTCSetting(控制 DTC 设置)( DTCSettingType = off)

在这里插入图片描述
在这里插入图片描述

  • 示例 2—ControlDTCSetting(控制 DTC 设置)( DTCSettingType = on)

在这里插入图片描述
在这里插入图片描述

UDS中常用 NRC

在这里插入图片描述

参考

  • https://zhuanlan.zhihu.com/p/567271514
### 关于UDS 85服务的信息 ISO 15765标准定义了一种用于汽车网络通信的协议栈,其中包含了通用诊断服务(Universal Diagnostic Services, UDS)。从已知信息来看,UDS服务支持被划分为多个部分,其中包括一般信息、OBD规定的立法服务以及UDS本身所支持的服务[^1]。 对于具体的UDS 85服务而言,它通常指的是统一诊断服务中的某个特定功能或子集。然而,在现有的引用中并未直接提及关于UDS 85的具体细节。因此,以下是基于专业知识对该主题的一些补充说明: #### UDS 85服务的功能概述 UDS 85可能涉及的是ISO 14229-1标准下的某种扩展服务或者自定义实现。常见的UDS服务包括但不限于读取数据标识符(Read Data by Identifier)、写入数据标识符(Write Data by Identifier)、输入输出控制(Input Output Control),以及其他定制化功能。如果提到具体编号为“85”的服务,则可能是厂商专有的扩展服务之一,或者是针对某些特殊场景设计的功能模块。 为了进一步确认其确切含义,可以参考以下方法获取更多信息: 1. **查阅车辆制造商文档**:不同品牌和型号可能会对UDS进行个性化配置,建议查看对应车型的技术手册。 2. **分析ECU固件文件**:通过逆向工程手段提取并解析目标控制器内的软件逻辑,从而定位到该服务的实际作用范围及其交互流程。 3. **利用工具测试响应行为**:借助CANoe、Vector CANalyzer等专业设备发送请求帧至车载总线,并观察返回的结果包来推测此服务的目的所在。 ```python # 示例代码展示如何模拟发送一条简单的UDS请求消息 import can def send_uds_request(bus, arbitration_id, data): message = can.Message(arbitration_id=arbitration_id, data=data, is_extended_id=False) try: bus.send(message) print(f"Message sent on {bus.channel_info}") except can.CanError as e: print(e) if __name__ == "__main__": with can.interface.Bus(bustype='socketcan', channel='vcan0') as bus: uds_service_identifier = b'\x85' # 假设这是我们要查询的服务ID additional_payload = bytearray([0x00]) * 6 # 构造其余填充字节 full_data_field = bytes(uds_service_identifier + additional_payload) send_uds_request(bus, 0x7E0, full_data_field) # 使用假设的目标地址作为例子 ``` 上述脚本片段展示了怎样构建并向虚拟CAN接口广播一个携带指定SID (Service ID)诊断命令序列;当然实际应用当中还需要考虑更多因素比如超时处理机制等等。 --- ### 解决与排查问题的方法论 当遇到有关UDS 85服务的问题时,可以从以下几个方面入手解决: 1. **验证物理层连接状态** - 确认当前使用的硬件设施工作正常无误码现象发生; - 测试线路是否存在短路开路等问题影响信号传输质量。 2. **检查高层协议一致性** - 对照官方发布的API指南核实参数设置是否匹配预期值; - 如果涉及到跨平台操作还需注意端序差异可能导致的数据错乱情况。 3. **收集日志记录辅助判断** - 开启调试模式捕获完整的会话过程以便后续审查错误根源; - 运用专门的日志管理框架保存重要事件便于长期追踪维护。 4. **尝试降级兼容策略** - 当发现新版本引入不稳定性可暂时回退至上一稳定版继续运行; - 同样适用于探索潜在冲突源的过程之中逐步缩小怀疑区间直至锁定根本原因。 以上措施均需严格遵循相关行业安全规范执行以免造成不必要的损害风险增加额外成本负担。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值