1 安全访问服务标识符 (0x27)：UDS 协议
安全访问服务用于修改存储在内存中的 ECU 数据，在此之前，用户首先必须通过该服务授予访问权限。此服务的目的是提供一种访问信息和/或诊断服务的方法，这些服务因安全、排放或安全原因而受到限制。比如一些用于将例程或信息下载/上传到服务器中，并从服务器中读取特定的内存位置的诊断服务可能需要安全访问。因为下载到服务器中的不当程序或信息无疑可能会损害ECU，或危及车辆遵守排放、违反安全或安保标准。安全访问的机制通过使用种子和密钥来实现。
注意：ECU默认上电后将处于锁定状态，如果出现任何问题或您想写入或读取OEM处于锁定状态的任何数据，则需要使用安全访问服务标识符 (0x27) 解锁ECU才能更改数据。
2 如何解锁车辆中的ECU？
要解锁车辆中的 ECU，首先，客户端将发送种子请求。对于安全访问，从 0x00 到 0xFF 的子功能可用于不同的安全级别。基本上，所有奇数值都用于种子请求，而下一个偶数值（种子请求安全级别 + 1）将用于通过使用安全访问服务标识符 (0x27) 将安全密钥发送到 ECU 来实现解锁。
如上文所示，为了防止 ECU 被未经授权的人修改，大多数 UDS 服务都被锁定。要访问用于修改 ECU 的服务，用户首先必须通过安全访问服务标识符 (0x27) 授予访问权限。只有通过安全访问服务后，才能使用请求下载和传输数据等服务。使用的安全概念称为“种子和密钥”。
安全访问服务流程：
- 客户端向它想要解锁的服务器发送一个“种子”请求。
- 服务器通过将“种子”发送回客户端进行回复。
- 客户端然后根据“种子”生成一个“密钥”并将密钥发送到服务器。
- 如果客户端使用正确的算法生成“密钥”，服务器将响应“密钥”有效并且它将自行解锁。接下来我们将详细解释每个步骤：
2.1 安全访问种子请求帧
下表<安全访问服务种子请求帧格式>说明了如何按照上述步骤从客户端向服务器请求种子以解锁 ECU。安全访问服务标识符 (0x27) 主要支持扩展诊断会话，因此在请求之前，要从默认会话跳转到扩展诊断会话的诊断会话。表1 安全访问服务种子请求帧格式
| 数据字节 | 参数名称 | 十六进制值 |
| 0 | PCI | 0x01-0xFF |
| 1 | SID: Security Access Request | 0x27 |
| 2 | SBF: Request Seed | 0x01,03,05-7D（0x00-oxFF之间的所有奇数值） |
| 3 | Data Record[0] (High Byte) | 0x00 – 0xFF |
| n… | Data Record[n] (Low Byte) | 0x00 – 0xFF |
上表定义了使用 UDS 协议中的安全访问服务请求种子时的数据格式。具体例子如下（安全访问种子的CAN 请求报文）：
| 字节 0 | 字节 1 | 字节 2 | 字节 3 | 字节 4 | 字节 5 | 字节 6 | 字节 7 |
| 0x02 | 0x27 | 0x01 | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 |
2.2 安全访问种子响应帧
响应消息具有响应 SID，如果它是肯定响应，则该参数是请求消息参数的消息 SID+0x40。如果是否定响应，则参数是八个否定响应代码之一。表2 安全访问服务种子响应帧格式
| 数据交换 | 参数名称 | 十六进制值 |
| 0 | PCI | 0x01-0xFF |
| 1 | Security Access Response ID | 0x67 |
| 2 | Request Seed SBF | 0x01,03,05-7D（0x00-oxFF 之间的奇数值） |
| 3 | Security Seed[High Byte] | 0x00 – 0xFF |
| 4 | Security Seed[Low Byte] | 0x00 – 0xFF |
上表定义了使用UDS 协议中的安全访问服务标识符 (0x27) 从 ECU 获取种子密钥响应时的数据格式。下面的例子为上述请求种子发送的响应帧。例子中的响应种子密钥是 0x1234，当然根据 OEM 算法实现，它可以是任何数字的组合。（安全访问种子响应的报文）
| 字节 0 | 字节 1 | 字节 2 | 字节 3 | 字节 4 | 字节 5 | 字节 6 | 字节 7 |
| 0x04 | 0x67 | 0x01 | 0x12 | 0x34 | 0x55 | 0x55 | 0x55 |
2.3 安全访问 SendKey 请求帧
当客户端首先向 ECU 请求种子时，ECU 将接收，并根据 ECU 的行为，将发送肯定或否定响应。如果是肯定响应，那么客户端将收到服务器发送的种子密钥，然后客户端将从ECU发送的种子密钥生成一个安全密钥。客户端将按照下表格式发送此安全密钥：表3 安全访问服务发送密钥请求帧格式
| 数据交换 | 参数名称 | 十六进制值 |
| 0 | PCI | 0x01-0xFF |
| 1 | SID: Security Access Request | 0x27 |
| 2 | SBF: Send Key | 0x02,04,06-7E（0x00-0xFF 之间的偶数值） |
| 3 | Data Record[0] (High Byte) | 0x00 – 0xFF |
| n… | Data Record[n] (Low Byte) | 0x00 – 0xFF |
下面的例子为安全访问sendkey 请求报文：
| 字节 0 | 字节 1 | 字节 2 | 字节 3 | 字节 4 | 字节 5 | 字节 6 | 字节 7 |
| 0x06 | 0x27 | 0x02 | 0xA1 | 0xB2 | 0xC3 | 0xD4 | 0x55 |
- Byte0[06]：这是一个 PCI 字节。LSB 半字节有 6，这意味着这个帧在这个 CAN 帧中保存了 6 个字节的数据。MSB 半字节定义了帧的类型，所以这里它是“0”，表示它是一个单一的帧。
- Byte1[27]：这是 CAN 数据帧中的第一个数据字节，这意味着它将是一个服务标识符。由于它的十六进制数为 27，因此它是一个安全访问服务标识符。
- Byte2[02]：所以在UDS协议的Security access service Identifier中，第二个字节是种子或“发送密钥”字节。因为它是第二个请求字节，因为我们已经发送了种子请求并从服务器接收到“种子密钥”，现在我们需要将“ sendkey ”作为子函数发送，所以这将是请求的下一个值“种子KEY”子功能。
- Byte3-6[D4C3B2A1]：这些是生成的真实安全密钥，将用于解锁ECU。我已经给出了一个示例值，它将根据编写的代码生成器算法进行更改。
- Byte7[55]：该值为空，因为没有数据要发送。所以默认值为 0x55。
2.4 安全访问 SendKey 响应帧
当客户端将发送带有有效安全密钥的“sendkey”请求消息时，服务器将检查将该密钥与客户端生成的密钥进行比较，如果匹配，则服务器将解锁 ECU。然后在解锁后 ECU 将发送如下表的肯定响应消息。表 4 安全访问服务种子响应帧格式
| 数据交换 | 参数名称 | 十六进制值 |
| 0 | PCI | 0x01-0xFF |
| 1 | Security Access Response ID | 0x67 |
| 2 | Request Seed SBF | 0x01,03,05-7D（0x00-0xFF 之间的奇数值） |
| 3 | Security Seed[High Byte] | 0x00 – 0xFF |
| 4 | Security Seed[Low Byte] | 0x00 – 0xFF |
下面的例子为安全访问种子响应报文：
| 字节 0 | 字节 1 | 字节 2 | 字节 3 | 字节 4 | 字节 5 | 字节 6 | 字节 7 |
| 0x02 | 0x67 | 0x02 | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 |
它定义了 CAN“sendkey”响应消息。
- Byte0[02]：这个 PCI 字节保存一个有 6 个 LSB 半字节，这意味着这个帧在这个 CAN 帧中保存了 2 个字节的数据。MSB 半字节定义了帧的类型，所以这里它是“0”，表示它是一个单一的帧。
- Byte1[67]：这是 CAN 数据帧中的第一个数据字节，这意味着它将是一个肯定响应服务标识符。由于它具有十六进制的 67，因此它是安全访问肯定响应服务标识符。
- Byte2[02]：这是安全访问诊断响应消息中的第二个字节。所以这个字节是请求的子功能的子功能标识符。因为它是 02，所以它是“ sendkey ”。
- Byte3-7[55]：这些是默认填充为 0x55 的空数据字节。
注意：一旦 ECU 解锁，您就可以从 ECU 读取或写入任何授权数据。但是，如果您在解锁 ECU 后不执行任何任务，则 ECU 将在一段时间后根据 OEM 定义的时间参数自动锁定。
3 安全访问否定响应消息
安全访问服务标识符 (0x27) 具有不同的否定响应代码，用于通知用户如果 ECU 中存在任何错误请求或任何故障，ECU 无法成功执行此安全访问服务标识符 (0x27) . 根据此NRC代码，客户可以理解ECU无法正确响应的原因。下面显示了所有安全访问否定响应代码 (NRC)。
- Sub-function Not Supported (12 hex)：不支持请求消息中的功能（会话类型）。
- Incorrect Message Length/Invalid Format (13 hex)：消息长度错误或可能是无效的数据格式。
- Conditions Not Correct (22 hex)：当服务器处于关键正常模式活动并因此无法根据请求消息执行请求的 DTC 控制功能时使用。它可能由于 OEM 定义和实施的温度或电压不满足条件。
- Request Sequence Error (24 hex)：如果在没有先接收到“ requestSeed** ”请求消息的情况下接收到“ sendKey ”子功能。这个 NRC 主要是针对“ requestSeed ”或“ sendKey ”之间的错误序列。
- Request Out Of Range [31 hex]：如果服务器在此服务的 DTC 设置控制选项记录中检测到错误，则应使用此响应代码。
- Invalid Key [0x35]：如果接收到预期的“sendKey ”子函数值并且密钥的值与服务器内部存储或计算的密钥不匹配，这将由 ECU 发送。
- Exceeded Number Of Attempts [0x36]：如果延迟计时器由于超过允许的最大错误访问尝试次数而处于活动状态，则该 NRC 将由 ECU 发送。根据 OEM，重试或尝试的次数可以是任意数量。
- Required Time Delay Not Expired [0x37]：如果延迟计时器处于活动状态并且发送了请求，则此 NRC 将发送。
3.1 安全访问 NRC 帧格式
下面的例子是否定响应的帧格式（安全访问 NRC 帧）：
| 字节 0 | 字节 1 | 字节 2 | 字节 3 | 字节 4 | 字节 5 | 字节 6 | 字节 7 |
| 0x02 | 0x7F | 0x22 | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 |
- Byte0[02]：这个 PCI 字节定义了单帧和两个字节的数据。
- Byte1[7F]：这是一个否定响应服务标识符。它在 ISO14229 标准中定义。
- Byte2[22]：这是第二个字节，值为 0x22，这意味着错误是条件不正确。那么这个不满足的条件是什么，如果你想知道那么你需要遵循 OEM 文档，在安全访问服务标识符中实现的条件是什么。
