UDS诊断系列之五 诊断会话控制(10)服务

诊断会话控制服务,其服务ID是0x10,主要功能为控制服务端的会话模式的切换。

一、诊断会话模式

诊断会话模式分为默认会话模式和非默认会话模式,不同的会话模式所支持的功能、权限、时间参数等等是不一样的。

1.会话模式定义

首先明确一点就是一个服务端(ECU)正常运行的时候,当前只会存在一个会话模式,不会同时存在两个会话模式。

无特殊情况下上电会在默认会话模式下,在该模式下仅支持一般的信息读取和查询操作,例如读取VIN和软硬件版本,查询和清除故障信息等。

非默认会话模式不是一个模式,而是一个模式分类的称呼,除了默认会话模式,其他的会话模式都是非默认会话模式。常用的非默认会话模式有扩展会话模式和编程会话模式:扩展会话模式主要是用来写入一些信息如VIN和序列号等,以及控制ECU执行一些特殊请求如控制应用通信和故障信息的更新等;编程会话从字面上就很好理解,如果需要对ECU进行程序刷写操作,就需要进入编程会话才能执行相关操作。除了以上非默认会话模式,实际还有一些其他的主机厂自己定义的模式如OTA模式,定义这类自定义的模式的目的就是为了满足特定的场景需求。

2.会话模式切换

当服务端(ECU)收到诊断会话模式请求时,需要切换到请求的诊断会话模式中去,一般情况下响应之后完成切换即可,特殊情况如编程会话模式的切换可能需要在切换之后再进行响应。切换会话模式的时候,有可能会有一些条件限制如车速、发动机转速、传感器位置等,这时候如果条件不满足则需要给出否定响应(NRC22),因为会话模式切换意味着可能要对服务端进行一些操作,这些操作会对车辆产生影响,所以这些条件限制主要目的是保证人员安全。如果请求的会话模式与当前会话模式相同,那么也需要给出肯定响应。

 上图是标准里的一张诊断会话模式切换图,里面包含接收到会话模式请求的四种情况,下面按标准内容进行解释。

①在默认会话模式下收到默认会话模式请求:服务端应当重新初始化默认会话,即之前被临时激活或者改变的数据都应该恢复到刚上电初始化的状态,写入到非易失存储器(断电数据不会消失的存储器)的数据不会重新初始化。

②在默认会话模式下收到任何非默认会话模式请求:服务端应当切换到被请求的会话模式,并且如果通过0x86服务设置了事件的话,这时候需要暂停。但是目前基本上不会使用0x86服务,所以一般直接切换即可。

③在非默认会话模式下收到非默认会话模式请求:服务端完成会话模式切换的同时需要完成以下操作:

  • 停止通过0x86服务设置的事件;
  • 重新锁定安全访问状态,并且重置依赖于安全访问的服务;
  • 不依赖于安全访问的服务,如果在被请求的会话模式也支持,应当保持当前状态,例如通信控制服务和DTC控制服务。

 ④在非默认会话模式下收到默认会话模式请求:服务端应当恢复之前被暂停的通过0x86服务设置的事件,停止所有默认会话模式不支持的服务,其余需要执行的操作与第①条一样。

对于哪些服务在哪个会话模式下支持,可参照ISO14229-1里面的表格,这里就不贴了。 

二、应用数据格式

1.请求报文

下表是请求报文的数据格式,格式比较简单,只包含两个字节,服务ID占一个字节0x10,子功能占一个字节,数据可取范围为0x00-0xFF。

 2.响应报文

下表是响应报文的数据格式,与请求报文有两点不同,响应的服务ID变成了0x50,子功能之后带了四个字节的时间参数。时间参数的作用是为了告知激活的会话模式支持的参数值,便于客户端(诊断仪)按照该参数处理响应。

 3.子功能

子功能表示具体的诊断会话模式,下表列举了常见会话模式:

子功能诊断会话模式
01默认会话模式
02编程会话模式
03扩展会话模式

一般常见的就这三种会话模式,除默认会话模式是强制要求的,标准里并没有强制支持其他会话模式,但是这里注意一般主机厂会有强制要求,因为如果仅支持默认会话的话很多功能是不方便执行的。

4.时间参数

时间参数有两个,P2server_max和P2*server_max,每个参数占用两个字节,所以一共占用四个字节。虽然每个参数都是两个字节,但是其单位(精度)是不一样的,P2*参数的单位是10ms,也就是说P2*的结果需要把后面两个字节的数值乘以10才是实际的时间。关于P2和P2*是什么,后续在ISO14229-2里面会详细说明。

5.常用NRC

在ISO标准里给出了该服务的常用NRC,主要有三个,如下表所示,服务端需要根据实际的情况进行响应。

 三、数据示例

1.请求

现在假设我们请求服务端切换到编程会话模式,那么请求报文里,SID=0x10,子功能=0x02,此次请求需要响应,所以抑制肯定响应位=0,应用数据如下表所示。

 2.响应

响应报文里,SID=0x10+0x40=0x50,子功能=0x02,P2server_max=50ms=0x0032,P2*server_max=5000ms=500*10ms=0x01F4*10ms,应用数据如下表所示。

UDS诊断系列链接汇总_ChenglimK的博客-CSDN博客

<think>嗯,我需要回答用户关于ISO 27145协议是否支持UDS诊断协议中的10诊断会话服务的问题。首先,我应该回忆一下这两个协议的基本信息。 ISO 27145是用于车辆诊断的国际标准,主要与OBD(车载诊断)相关,尤其是在排放相关的诊断方面。而UDS(统一诊断服务)则是ISO 14229标准的一部分,广泛应用于汽车电子系统的诊断,包括各种ECU(电子控制单元)的通信。 接下来,用户提到的10诊断会话服务UDS中指的是诊断会话控制服务,其服务标识符(SID)是0x10。这个服务允许诊断仪在不同的会话模式(如默认会话、扩展会话、编程会话)之间切换,以便执行不同级别的诊断操作。 现在要确定ISO 27145是否支持这个服务。根据我所知,ISO 27145在设计时考虑了与现有诊断协议的兼容性,特别是为了整合OBD和UDS的功能。ISO 27145可能基于UDS的一些服务,但具体是否支持0x10服务需要查阅相关文档。 ISO 27145通常使用基于DoIP(Diagnostics over Internet Protocol)的通信,并且其服务可能映射到UDS服务。例如,诊断会话控制这样的基础功能在ISO 27145中应该是支持的,但可能以不同的方式实现或引用UDS的标准服务。需要确认ISO 27145是否直接采用了UDS服务,或者是否定义了自己的等效服务。 另外,考虑到ISO 27145-3部分可能详细说明了诊断服务,应该检查这部分内容。根据记忆,ISO 27145确实整合了部分UDS服务,但可能会根据排放诊断的需求进行调整或扩展。因此,诊断会话控制服务(0x10)很可能被支持,但可能需要符合ISO 27145特定的要求或上下文。 总结来说,ISO 27145协议支持与UDS兼容的服务,包括诊断会话控制(0x10),但可能在实现细节或应用场景上有所不同,特别是在排放相关的诊断中。需要参考ISO 27145的具体条款来确认,但大概率是支持的。</think>ISO 27145协议与UDS(统一诊断服务,ISO 14229)中的**10诊断会话控制服务(SID 0x10)**的关系可通过以下分析明确: --- ### 1. **协议背景** - **ISO 27145**: 主要针对车辆排放相关诊断(如OBD),整合了DoIP(Diagnostics over Internet Protocol)通信,并与ISO 14229(UDS)部分服务兼容。 - **UDS (ISO 14229)**: 提供通用诊断服务,如会话控制(0x10)、读写数据(0x22/0x2E)等,广泛应用于非排放相关ECU的诊断。 --- ### 2. **ISO 27145对UDS服务的支持** - **直接引用**: ISO 27145通过引用ISO 14229-1(UDS)**直接支持部分UDS服务**,包括**诊断会话控制(0x10)**。 - 例如:在ISO 27145-3(应用层)中,明确将UDS服务整合到OBD框架内。 - **会话模式调整**: ISO 27145可能对会话模式的定义进行扩展,例如针对排放诊断的**OBD特定会话**(如`OBD默认会话`),但其底层逻辑仍基于UDS会话控制机制。 --- ### 3. **实现细节** - **服务格式兼容性**: ISO 27145使用与UDS相同的**服务标识符(SID)**和请求/响应格式。 例如: - 诊断仪发送请求:`$10 03$`(进入扩展会话) - ECU响应:`$50 03$`(肯定响应) - **通信差异**: ISO 27145强制要求通过**DoIP(基于以太网)**传输诊断数据,而UDS通常基于CAN总线,但服务层协议保持一致。 --- ### 4. **结论** ISO 27145协议**支持UDS10诊断会话控制服务(SID 0x10)**,但在以下方面存在差异: 1. **会话类型扩展**:可能增加针对OBD的专用会话模式。 2. **传输层**:依赖DoIP而非传统CAN。 3. **应用场景**:更聚焦于排放相关诊断,而非通用ECU控制。 --- ### 参考资料 - ISO 27145-3:2012(道路车辆-与排放相关的诊断-第3部分:通用诊断服务) - ISO 14229-1:2020(统一诊断服务-第1部分:应用层)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

ChenglimK

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值