1. 服务ID(Service ID/SID)
在UDS(统一诊断服务)协议体系里,Service ID(SID)扮演了服务标识符的角色,它用于指明将要执行的具体服务。每个服务均配有一个独一无二的SID,这个SID在诊断会话过程中起到了决定性作用,使得系统能够识别并区分需要执行或响应的特定服务请求。根据ISO 14229-1标准,共定义了26种服务,这些服务被细分为六大类别:诊断与通信管理类、数据通信类、存储数据交互类、输入输出管理类、例程控制类以及数据传输的上传与下载类。
2.诊断请求(Diagnostic Requst)
诊断请求是诊断设备发送给车辆的一种信息指令,旨在要求车辆执行特定的诊断服务。这种请求信息由三个核心组件构成:首先是SID(服务标识符),它负责指明需要执行的具体服务;其次是子功能部分,它允许对服务进行更细致的划分,比如启动、暂停等附加操作(这里的子功能通常由1位SPR和7位子功能代码组合而成,其中SPR可能代表某种特定的服务请求参数);最后是实际数据段,其长度可变,用于传递执行服务所需的具体信息或参数。2.诊断请求(Diagnostic Requst)
尽管UDS协议所涵盖的服务种类繁多,但所有服务均遵循统一的诊断请求包格式。具体来说,每个请求包都包含1个字节的SID、1个字节的子功能代码(其中1位用于SPR,7位用于具体的子功能定义),以及一段长度不定的实际数据。这种标准化的格式确保了诊断请求在不同车辆和诊断设备之间的兼容性和通用性。
SPR(Service Positive Response bit,服务正响应位)的设计初衷是为了向ECU(电子控制单元)提供一个指示,表明对于某个特定的服务请求,是否期望接收到正面的响应数据。这样做的目的是优化系统资源的使用,避免ECU发送那些可能并不需要的响应信息,从而实现资源的有效节约。简而言之,SPR就是一个控制开关,帮助决定ECU是否应该针对服务请求返回正响应,以此来减少不必要的通信开销。
- spr=1, 抑制正响应,即ECU不给出正响应;
- spr=0, 需要ECU给出正响应,如果某个服务没有sub-function,即没有第二个字节,那默认是要发正响应的。
|