跟我学UDS(ISO14229) ———— 0x27(SecurityAccess)

前言

为什么需要安全访问？因为在下载/上传的诊断服务例行程序或数据进入服务器并从服务器读取特定的内存位置的情况是可能需要安全访问。 不正确的例程或数据下载到服务器中可能损坏电子设备或其他车辆部件，或冒着车辆遵守排放，安全或安全标准。所以，安全访问还是很重要的。

如何解锁安全模式？具体的流程又是怎样的？
第一步：客户端发送seed请求
第二步：服务端发出seed
第三步：客户端发送key密钥，依据服务发出的seed进行处理
第四步：服务端分析客户端发过来的key密钥，如果无误则完成解锁功能

一、发送seed请求

具体的格式如下。这里需要对Sub-function参数说一个说明，当sub-function的值为奇数时，才是发送seed请求的命令。

通常来说，我们在请求seed的时候，一般不对参数securityAccessDataRecord进行赋值。因为该参数在协议中定义为一个可选项。

二、发送key密钥

具体的格式如下。这里需要对Sub-function参数说一个说明，当sub-function的值为偶数时，才是发送key密钥的命令。securityKey的值是通过获取到的seed值，在ECU自己内部计算得到的一个key值，所以这个值是随着seed值变化而变化的。这一点在自动化过程中需要注意。

这里就涉及到一个对应关系：即27 01的seed请求，对应的是哪一个key密钥。
这里在ISO 14229 中有着明确定义：

转换成我的理解是：seed请求对应的key密钥的关系是相邻且大于seed的最小整数。

关于sub-function的具体格式定义如下：

三、正响应格式

具体格式如下。这里说明一下参数securitySeed，该参数只针对于seed请求的响应才存在。也就是说，当我们发送key密钥请求的时候，返回的正响应只有参数Service ID 和 securityAccessType这两个。

四、负响应的NRC码

该服务下支持的NRC错误码具体如下：

其中，对于35/36/37这三个错误码，需要比较关注一下。具体的测试细节因项目不同而不同。之前的项目是第一次发送错误的key，上报0x35； 等待5s，第二次发送错误的key，上报0x36；等待5s，第三次发送错误的key，上报0x37。

具体如何在CAPL脚本中自动化实行安全解锁功能，请参考另一篇文章：CPAL脚本自动化测试 ———— 诊断模块的安全解锁函数分析