系列文章目录
前言
本专题用于记录,在汽车电子中常见的诊断问题。后续系列内容将在[ISO-14229-1:2020]基础上实施。欢迎各位小伙伴在后续内容中共同交流交换意见。
UDS并无具体的实现方式,而是一种大家共同约定的,基于网络为通信载体,固定数据格式的一种应用层服务。
一、现状
一般来说,目前市面上大多主机厂或一级供应商开发的各电子单元均需要通过CAN网络来完成诊断。其场景包括但不限于下线配置及确认,故障返修,排放审核等。这些诊断服务均遵循UDS内容,另外对于有实力的主机厂来说还会在UDS上增加一些符合自身业务场景的诊断规范内容。
在实际开发中主机厂的供应商往往不止一家,同时青睐自研上层应用,脱离不得一级供应商所提供的开发包。主机厂会出现前期立项定点时的需求研讨,接口适配,跨部门协作上出现较多矛盾。同时大多一级供应商会出于成本考虑,更倾向于自己开发一套基于UDS上的协议栈,使得主机厂基于经验提出的需求一级供应商难以应对。
二、概述
应用层服务通常被称为诊断服务。应用层服务用于基于客户端 - 服务端的系统,以执行诸如车载车辆服务端的测试,检查,监控或诊断等功能。
客户端(通常称为诊断设备)使用应用层服务来请求在一个或多个服务端中执行诊断功能。服务端(通常作为ECU 的部分功能)使用应用层服务将由请求的诊断服务提供的响应数据发送回客户端。
客户端通常是非车载诊断仪,但在某些系统中也可以是车载诊断仪。应用层服务的使用独立于客户端,无论该客户端是车载还是非车载诊断仪。同一车辆系统中允许有多个客户端。诊断应用层的服务接口提供了大量具有相同通用结构的服务。
对于每个服务,规定了六项服务原语:由诊断仪应用中的客户端功能使用的服务请求原语,将所请求的诊断服务的数据传递到诊断应用层:
——服务请求原语:在诊断仪应用中由客户端使用,将所请求的诊断服务的数据传递到诊断应用层;
——服务请求-确认原语:在诊断仪应用中由客户端使用,指示在服务请求原语中传递的数据在诊断仪所
连接得总线上成功发送;
——服务指示原语:由诊断应用层使用,将数据发送到ECU 诊断应用的服务端;
——服务响应原语:由ECU 诊断应用的服务端使用,将由所请求的诊断服务提供的响应数据发送到诊断应
用层;
——服务响应-确认原语:由ECU 诊断应用中的服务端使用,指示在ECU 接收到诊断请求的总线上成功发
送服务响应原语中传递的数据;
——服务确认原语:由诊断应用层使用,将数据发送给诊断仪应用中的客户端。
应用层服务原语-确认服务
应用层服务原语 非确认服务
对于给定的服务,请求确认原语和响应确认原语通常具有相同的服务数据单元。
这些服务原语的目的是指示先前的请求或响应服务原语调用已经 完成。本标准中描述的服务将不会使用这些服务原语,但是数据链路特定的实施文档可能 会使用这些描述来定义诸如 服务执行参考点。(当响应完全传送到客户端时,ECU复位服务将调用复位,客户端通过服务端响应确认原语在服务端中指示)
总结
所有应用层服务都具有相同的通用格式。服务原语是按如下格式进行编写:
service_name.type (
parameter A, parameter B, parameter C
[,parameter 1, ...]
)
- “service_name”是诊断服务的名称(例如:诊断会话控制)
- “type”指示服务原语的类型(例如:请求),
- “parameter A, …”是A_SDU(应用层服务数据单元)作为服务原语传递的值的列表(寻址信息),
- “parameter A, parameter B, parameter C”是必须包含在所有服务调用中的强制参数。
- “[,parameter 1, …]”是取决于特定服务的参数(例如:parameter 1可以是诊断会话控制服务的诊断会话)。
- “[]”表示参数列表的这一部分可能为空
服务
后续将按照如下顺序介绍常见的诊断服务
序号 | SID | 描述 |
---|---|---|
0 | 10 | 诊断会话控制 |
1 | 11 | 复位 |
2 | 27 | 安全访问 |
3 | 28 | 通信控制 |
4 | 85 | 控制DTC设置 |
5 | 22 | 通过ID读数据 |
6 | 2E | 通过ID写数据 |
7 | 14 | 清楚DTC |
8 | 19 | 读取DTC信息 |
9 | 2F | 输入输出控制 |
10 | 31 | 例程控制 |
11 | 38 | 文件传输 |