《UDS协议从入门到精通》系列——图解0x2A:通过周期读ID数据
- 一、简介
- 二、数据包格式
- 2.1 服务请求格式
- 2.2 服务响应格式
- 2.2.1 肯定响应
- 2.2.2 否定响应
- 三、通信示例
Tip📌:本文描述中但凡涉及到其他UDS服务的,将陆续提供链接跳转方式以便快速了解他们。(各服务介绍持续更新中…)
学习UDS基础知识以及其他相关内容?>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通(UDS速查手册)》<<<<<<<<<
一、简介
Tip📌:推荐先阅读《UDS协议从入门到精通》系列——图解0x22:通过ID读数据
0x2A服务被称为“ReadDataByPeriodicIdentifier”,即“按周期标识符读取数据”。这项服务允许客户端(如诊断工具)请求服务器(如车辆控制单元)周期性地传输由一个或多个周期性数据标识符(periodicDataIdentifier)标识的数据记录值。
-
客户端请求:客户端发送一个包含一个或多个1字节周期性数据标识符的请求消息。这些标识符指向服务器维护的数据记录。周期性数据标识符是数据标识符的低字节,该数据标识符属于为该服务保留的范围内(例如0xF2XX)。
-
数据记录格式:数据记录的格式和定义由车辆制造商特定,可能包括模拟输入输出信号、数字输入输出信号、内部数据和系统状态信息,前提是服务器支持这些。
-
服务器响应:服务器在接收到ReadDataByPeriodicIdentifier请求后,会检查是否满足执行服务的条件。如果条件正确,服务器将发送一个正响应消息,仅包含服务标识符。此后,服务器将访问由周期性数据标识符指定的记录数据元素,并分别发送包含相关数据记录参数的周期性数据响应消息。
-
周期性传输:周期性数据响应消息将不包含正响应服务标识符,而是包含周期性数据标识符及其数据。周期性传输的速率由车辆制造商定义,并受周期性调度器的调用频率、可以并行定义和传输的周期性数据标识符数量等目标ECU上的诸多因素影响。
-
停止传输:如果客户端请求包含传输模式“stopSending”,服务器将停止周期性传输指定的周期性数据标识符或所有周期性数据标识符(如果没有指定具体的一个)。
-
限制和支持:服务器可能根据车辆制造商和系统供应商的协议,限制可以同时支持的周期性数据标识符的数量。如果超过最大数量,服务器将发送一个负响应,并且该请求中的任何周期性数据标识符都不会被调度。
这个服务特别适用于需要定期监控车辆状态的应用,如实时数据监控或性能分析。通过周期性地获取数据,客户端可以持续跟踪车辆的状态,而无需频繁地发送请求。
下面列出了协议标准中对DID含义的预定义情况,可以看到0xF200~0xF2FF正是为periodicDataIdentifier预定义的。
二、数据包格式
2.1 服务请求格式
periodicDataIdentifier(1Byte):当传输模式(transmissionMode)设置为sendAtSlowRate
、sendAtMediumRate
或sendAtFastRate
时,请求消息中必须包含至少一个周期性数据标识符。这是为了指定客户端希望服务器周期性发送的具体数据记录。
如果传输模式设置为stopSending
,则请求消息中可以不包含任何周期性数据标识符,这将导致服务器停止所有已调度的周期性数据标识符的传输。或者,客户端可以明确指定一个或多个周期性数据标识符,以指示服务器停止这些特定标识符的周期性传输。
transmissionMode(1Byte):传输模式决定了数据传输的频率和方式。例如,sendAtSlowRate
、sendAtMediumRate
和sendAtFastRate
分别表示慢速、中速和快速传输模式,具体的速度由车辆制造商定义。当设置为stopSending
时,表示客户端希望停止所有或特定周期性数据标识符的周期性传输。
这种设置允许客户端根据需要灵活地控制数据的获取和传输。例如,如果客户端只需要监控车辆的一个特定参数,它可以请求该参数的周期性数据,并设置适当的传输模式。如果客户端不再需要这些数据,它可以发送一个包含stopSending
模式的请求,以停止数据的周期性传输,从而节省资源和带宽。
2.2 服务响应格式
2.2.1 肯定响应
对于0x2A服务(ReadDataByPeriodicIdentifier)的响应消息,可以分为两大类:初始正响应消息和后续的周期性数据响应消息。这两类消息在形式和功能上有所区别。
初始正响应消息: 当服务器接受客户端的请求时,会首先发送一个初始正响应消息。这个消息是一种确认信号,表明服务器已经理解并准备执行客户端的请求。初始正响应消息的具体内容和格式十分简单,只发送一下SID+0x40即可。
周期性数据响应消息: 在发送了初始正响应消息之后,服务器将根据客户端请求中指定的周期性数据标识符和传输模式,开始周期性地发送数据响应消息。每个周期性数据响应消息包括周期性数据标识符本身及其对应的数据值。数据值将根据请求中指定的传输模式(如慢速、中速或快速)周期性更新,一般来说更新速率取决于数据的重要性或监控的需求。
2.2.2 否定响应
可能出现的NRC及其含义如下:
NRC | 含义 |
---|---|
0x13 | 消息长度错误 |
0x22 | 当前条件不满足 |
0x31 | 请求参数不受支持,参数错误 |
0x33 | 未通过安全访问 |
NRC的处理流程如下所示(即推荐的错误情况检查顺序):
三、通信示例
============示例1:
在下面示例中,Tester使用0x2A服务请求目标ECU周期性地传输多个数据记录,具体是两个周期性数据标识符(periodicDataIdentifiers):0xE3和0x24,并且要求以中速率传输这些数据。
-
数据标识符和内容:
- 周期性数据标识符0xE3(对应的数据标识符为0xF2E3)包含以下数据:发动机冷却液温度、节气门位置、发动机转速、车辆速度传感器数据。
- 周期性数据标识符0x24(对应的数据标识符为0xF224)包含以下数据:电池正电压、进气管绝对压力、空气质量流量、车辆大气压力和计算的负载值。
-
请求和传输模式:
- Tester发送一个请求,要求目标ECU以中速率周期性地传输这些数据。中速率的具体定义由车辆制造商确定,通常介于慢速和快速之间。
-
停止传输:
- 在Tester接收到一定时间的数据后,它决定停止周期性数据标识符0xE3的传输,而继续接收周期性数据标识符0x24的数据。这通过发送一个包含传输模式“stopSending”和指定周期性数据标识符0xE3的请求来实现。
这个示例展示了如何使用UDS 0x2A服务来管理车辆数据的周期性传输。客户端可以根据需要选择性地请求和停止特定数据集的传输,从而实现对车辆状态的灵活监控和资源的高效利用。通过指定不同的传输模式,客户端可以控制数据传输的频率,确保在需要时获得足够的数据,同时在不需要时减少数据流量,节省带宽和处理资源。
这种机制特别适用于需要实时监控车辆状态但又不希望持续占用大量通信资源的场景,如远程诊断、性能监控或故障检测。通过动态调整数据传输的频率和内容,可以确保车辆系统的健康状态得到有效监控,同时避免不必要的资源消耗。
============示例2:
该示例通过图表展示Tester和目标ECU之间的通信流程和目标ECU调度器的执行情况,有以下假设:
- 快速周期性速率定义为25毫秒,中速周期性速率定义为300毫秒。
- 周期性调度器每12.5毫秒检查一次,这意味着后台周期性调度器函数以这个周期被调用(轮询)。
因此:
- 当发送快速速率的周期性数据标识符时,快速速率循环计数器设置为2(基于调度速率25毫秒除以周期性调度器轮询速率12.5毫秒,即25 / 12.5)。
- 当发送中速速率的周期性数据标识符时,中速速率循环计数器重置为24(基于调度速率300毫秒除以周期性调度器轮询速率12.5毫秒,即300 / 12.5)。
下图展示了Tester和目标ECU之间的消息交换流程,从第25ms开始,目标ECU开始周期性的发送响应数据,周期性数据传输速率设置的是中速率300ms,因此第325ms开始第二次发送响应消息。
下表则详细列出了周期性调度器的状态、变量及其在每次调度器检查时的变化。
============示例3:
在示例2的基础上,这个示例进一步扩展了UDS 0x2A服务(ReadDataByPeriodicIdentifier)的操作,展示了如何在不同速率下调度多个周期性数据标识符。示例中,三个周期性数据标识符(0x01, 0x02, 0x03)被设置为快速周期性速率(25毫秒)。随后,客户端请求另一个周期性数据标识符(0x04)以中速周期性速率(300毫秒)进行调度。
- 服务器接收到第一个ReadDataByPeriodicIdentifier请求(1),发送一个正响应(2),但没有包含任何周期性数据。
- 服务器在第一次执行周期性调度器后台函数时(t = 25.0 ms,3),开始处理快速速率的周期性数据标识符。
- 当服务器接收到第二个ReadDataByPeriodicIdentifier请求(5)时,它发送另一个正响应(7),同样不包含任何周期性数据,并开始在t = 62.5 ms(8)时执行周期性调度器后台函数,这次是以中速率300毫秒。
下图展示了Tester和目标ECU之间的消息交换流程:
下表则详细列出了周期性调度器的状态、变量及其在每次调度器检查时的变化。
============示例4:
实际上,通过周期性调度器来进行数据的传输时,不一定限制死每个周期性数据响应消息只分配唯一的ID数据。下面的例子就是可以在一个响应消息里面带两个数据。首先有以下假设:
- 快速周期性速率定义为10毫秒。
- 周期性调度器每10毫秒检查一次,这意味着后台周期性调度器函数以这个周期被调用(轮询)。因此当发送快速速率的周期性数据标识符时,快速速率循环计数器设置为1(基于调度速率10毫秒除以周期性调度器轮询速率10毫秒,即10 / 10)。
- 最大同时调度周期性数据标识符的数量为16。
- 每个周期性数据响应消息分配两个唯一的地址信息ID。
调度过程如下:
- 在t = 0.0 ms时,客户端开始发送请求,以快速周期性速率(10毫秒)调度两个周期性数据标识符(0x01, 0x02)。
- 服务器接收到请求后,在t = 10 ms时首次执行周期性调度器后台函数。
示例中提到的最大同时调度周期性数据标识符的数量为16,以及为每个周期性数据响应消息分配两个唯一的地址信息ID,这些细节展示了如何在实际应用中配置和优化周期性数据传输的设置,以适应不同的系统需求和资源限制。
============示例5:
在上个示例的基础上进行扩展,这个示例继续使用表格形式,展示了UDS 0x2A服务(ReadDataByPeriodicIdentifier)在请求的周期性数据标识符数量超过响应消息集中ID数量时的处理方式。
- 该示例中,客户端请求调度3个周期性数据标识符(0x01, 0x02, 0x03),这些标识符以快速周期性速率(10毫秒)进行调度。
- 服务器接收到请求后,在t = 10 ms时首次执行周期性调度器后台函数。
这个示例特别关注了当请求的周期性数据标识符数量超过服务器能够通过单个响应消息返回的地址信息ID数量时的处理情况。在这种情况下,服务器需要决定如何分配或重用已有的地址信息ID,或者是否需要发送多个响应消息来满足所有请求的标识符。
简言之,目标ECU如何根据接收到的请求来触发相应的数据传输操作要取决于其具体设计。
>>>>>>>>> 返回专栏总目录 《UDS协议从入门到精通(UDS速查手册)》<<<<<<<<<