今天我们来讲一下什么是uds以及UDS协议内容，诊断和诊断测试

uds协议

纯软件为了方便开发人员定位bug，开发人员会使用日志功能。汽车软件为了方便开发人员定位bug，开发人员需要有手段获取更多的内部信息，这就对应诊断。

诊断功能的背后对应uds协议。

can协议对应OSI七层模型中的数据链路层和物理层，uds协议对应OSI七层模型中的应用层和会话层。

应用层/会话层：uds协议数据

..............................................

数据链路层/物理层：can协议数据

can协议数据：报文id+数据域（8个字节）

uds协议数据会放在can协议数据的数据域中。

uds：统一诊断服务

uds协议由若干个诊断服务组成。

诊断就是就是给ecu发送诊断的报文（can总线上发过去）过去。诊断的报文包含诊断服务的id。

诊断服务中常用的有：

1、10服务

2、11服务

3、19服务

4、22服务

5、27服务

6、2e服务

7、3e服务

10服务

诊断会话控制服务

所有的诊断需要在会话上进行。

10 01 切换默认会话，支持读取ecu基本信息

10 02 切换可编程会话，支持ecu的刷写

10 03 切换扩展会话，支持读取ecu更全的信息以及修改ecu数据

01、02、03属于子功能。

11服务

重置ecu。

11 01 硬件复位 ecu直接断电再加电

11 03 软件复位 软件重启

对一个网站的参数配置进行修改（比如数据库参数），需要重启服务让新的参数配置生效。

修改ecu中的参数后，需要重置ecu，让新的参数生效。

标定工程师就是通过修改ecu的参数，测试修改后的性能，通过不断的调整来让性能最佳。

19服务

读取故障信息（包含故障码）。

22服务

读取ecu中信息（非故障信息），比如ecu中的软件版本、ecu中保存的车的数据等。

27服务

安全访问控制

对ecu的数据的读取和修改需要权限。

27 01 获取种子

27 02 利用本地的算法程序（dll文件）来用种子计算密钥发给ecu检查

2e服务

向ecu中写入数据。

油箱--ecu----------------------（ecu）仪表

测试仪表上油量的显示。

can工具---can盒----仪表，用can工具发送相应的报文（包含油量数据）给仪表。

不使用can工具，可以用2e服务来修改ecu中油量数据，然后再运行11服务，让修改后的数据生效。

3e服务

会话保持。

实体是发送诊断报文的一方，可以是诊断仪也可以是诊断工具（比如canoe）。

can报文中8个字节的数据，byte0的数据是指诊断数据的字节数。

上图中正好对应一个诊断报文的请求和响应。

tester(canoe)-------------------ecu

tester给ecu发送10 03的诊断报文请求。ecu的响应分为正响应和逆响应。

正响应对应6个字节的诊断数据：

1、50=10+40，表示是针对10服务的正响应。

2、03后面的4个字节是响应参数数据。

逆响应对应3个字节的诊断数据：

1、7f，表示是逆响应。

2、10服务id的后面是错误码

canoe中诊断功能

利用canoe自带诊断案例。该案例对应的不是uds协议，是kwp协议，会存在一些差异。

上图中的ecu就是仿真的ecu，对应车门控制ecu。

使用诊断的功能，操作如下：

一、点击start，运行诊断案例

二、选择读取序列号诊断指令来读取ecu中数据

上图中就是抓到的can报文，包含请求和响应。

ID：报文id，200是tester发给ecu的，400是ecu回复给tester的。200、400是专门用于诊断的报文id。

三、读取故障信息

三、修改ecu中数据，比如门的状态

发现提示逆响应。

切换会话后再次运行写入发现修改成功。

查看诊断配置。

做诊断需要加载一个诊断配置文件（比如cdd文件）。

诊断时的诊断方式有两种：

1、物理请求

针对单个ecu请求，每个ecu有自己的诊断用的报文id。

2、功能请求

针对一组ecu请求，使用统一的报文id。

什么是诊断测试

ecu需要支持各种诊断服务，是否支持以及支持是否正确，需要进行测试，这就是诊断测试。

需要把所有的诊断服务以及可能的子功能、参数都进行测试。

需要把逆响应中所有可能的错误码都测试一遍。