UDS诊断服务基础篇之27

最新推荐文章于 2024-03-26 20:50:29 发布

king110108

最新推荐文章于 2024-03-26 20:50:29 发布

阅读量4.8k

点赞数 6

分类专栏： UDS 文章标签： 27服务

原文链接：https://blog.csdn.net/wto9109/article/details/121985204

版权

UDS 专栏收录该内容

8 篇文章 58 订阅

订阅专栏

前言

首次，请教大家关于诊断服务11的几个问题：

27服务有何作用，为什么要有27服务呢？
27服务在使用过程中有哪些注意事项呢？
27服务诊断请求与诊断响应如何交互？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文
服务功能
功能描述
根据ISO14119-1标准中所述，诊断服务27应用场合主要是用于Server数据上传或者下载，重要信息传递，功能安全等实施的过程中，比如如果对于重要数据的上传或者下载过程不做任何限制，很有可能会对整车的行车安全造成极大的威胁，特别是针对底盘域的控制器更是要在这方面做好全方位的安全防护措施，此时27服务便应运而生！

下列文中使用到的Client可直接理解为上位机Tester，Server可直接理解为接受Tester诊断请求的ECU。

应用场景
一般而言，对于27诊断服务，主要应用场景为以下场合：

在针对Server重新编程时，需要首先通过27安全解锁才能够进行后续的重编程操作，否则将对Server造成极大的安全风险；
在产线写入较为重要的版本或者标定等信息过程中，则首先需要使用27服务才能够使用写操作的诊断指令，如2E服务；
一般而言，如果需要往Flash中写入相关数据时都需要优先执行27安全解锁之后才能够进行安全写入；
执行十分重要的31 Routine时，也需要优先执行27安全解锁之后才能够执行对应的routine；

上述这些应用场景较为常见，除此以外，当然还有很多面向ECU内部测试验证的应用场合，这里就不一一列举。

安全解锁基本原理：

如下图1所示，针对27服务的安全解锁的过程是基于Seed-Key 机制来实现，具体过程可分为以下四个阶段：

Client向Server请求种子；
Server向Client发送随机种子；
Client基于接收到来自Server的随机种子计算出对应的Key并发送给到Server；
Server接受来自Client算出来的Key并与内部算出的Key比较，如果一致则解锁成功，否则解锁不成功；

图1 27服务安全解锁Seed-Key模型

从上图中可看出，每一次27服务安全解锁流程均是有以Client发起Seed请求作为开始，以Server回复正响应或者负响应作为结束。

S1-S2: 该两步骤中描述了当Server接受到来自Client的seed请求之后，会通过内部的随机数生成算法生成随机数，并通过诊断响应发送给到Client；

S3-S4：该两步骤中描述了Client基于上述步骤接受到的Seed，并引入安全算法中进行计算得出Key，然后通过诊断服务发送给到Server，同时Server根据发送给到Client的Seed并使用与Client一致的安全算法算出对应的Server key，然后将接收到的Key与本地生成的Server Key进行比较，如果一致则回复正响应，如果不一致则回复负响应并并附带对应的NRC来表示当前安全解锁失败的原因。

服务请求
服务请求是Client发送给到Server的诊断服务指令。

请求格式
按照ISO14229-1标准所述，如下图1所示为Request Seed的27服务诊断请求格式，即上图1中的S1步骤：

图2 27诊断服务Request Seed请求格式

下图3中各参数解释如下：

27诊断请求格式

图3 27服务Request Seed请求格式说明

如下图4所示为Send Key步骤，即图1中所示S3步骤，在S3中Client向Server发送Key的验证请求，看是否能够安全解锁成功.

图4 27服务Send Key 请求格式

图4中的各个参数解释如下图5所示：

5-27诊断sendkey请求格式

图5 27服务Send Key 请求格式说明

从图3与图5的解释说明对比可看出Request Seed的Subfuntion必须为奇数，而Send Key的Subfunction则必须为偶数。且两者Subfuntion还必须存在一个确定的定量关系：即Subfuntion(Request Seed) + 1 = SubFunction(Send Key)。

同时虽然27服务也支持抑制正响应，但是由于27服务需要通过回复正响应或者负响应来判断是否成功解锁，所以一般情况下针对27服务我们一般不使能抑制正响应位。

另外在从事项目开发的过程中，无论是平台开发还是客户项目开发，针对Subfuntion的定义取值还是带有很大的随意性，并没有按照UDS14229-1规范中的要求实施，因此有必要在此说明下27服务的Subfuntion的取值定义说明，如下图6所示：
6-27服务subfunction说明

图6 27服务Subfunction的取值定义

请求实例

以 27 01 请求种子(Request Seed) 为例，如下图7所示：

图7 27 01诊断请求示例

假设此时Server通过正响应并给到的Seed(0x36 0x57), 然后Client便会基于该Seed计算出对应的Key(假设为0x C9 0xA9)，并发送如下Send Key请求实例(27 03):

图8 27 03 诊断请求示例

从图7与图8可以看出，请求Seed的字节数目与算出的Key字节数目一般情况下是保持一致的，且27 01 与27 02 诊断请求中一个为奇数，一个为偶数，且两者是加1的加1 的关系，符合我们上述提到的Request Seed与Send Key的定量关系。

服务响应
服务响应是针对Client对Server诊断请求的响应。

正响应格式
如下图9所示，为27诊断服务的正响应格式：

图9 27诊断服务正响应格式

从上图中可以看出，27诊断服务的正响应由以下三个部分组成：

Response ID：该参数固定为SID+0x40 = 0x67；
SubFunction：该参数为request seed(如01)或者Send Key(02)的取值;
securitySeed：该参数仅针对subfunction为Request Seed时才会回复该参数，其他情况下，Server仅会回复前两个字节(response SID + SubFunction)，其取值范围只能为0x00-0x7F；

正响应实例

Respond Seed

如下图10所示，为上述27 01请求示例所对应的正响应：

图10 27 01正响应示例

其中，0x01表示request Seed的子服务，0x36 0x57则为Server接受到来自Client的种子请求之后通过调用随机数算法生成的Seed，这样Client便可以基于该Seed作为输入并按照客户或者平台要求的安全算法进行计算。

Verify Key

如下图11所示，则为Server发送给到Client的Verify Key的正响应。

图11 27 01校验Key示例

如图中所示，securityAccessType为02，表示Server针对Client的Key进行验证的过程。Server受到来自27 02的Send Key的请求之后，便会按照与Client一致的安全算法算出本地Key与接收到的Key进行比较，如果一致，则会发送正响应，若不一致，则回复负响应。

负响应NRC支持
绝大多数情况下，Server针对Client的请求都会给到正响应，比如发生重启前需确保整车处于安全状态，如引擎熄火，车速不能超过3km/h等，或者为了防止不按照诊断请求格式进行请求，那么Server需要通过某种方式来告诉Client执行不成功的原因在哪里以便于调查问题直至得到正响应。

因此ISO14229-1针对所有的诊断服务提供了一种统一的诊断负响应的诊断格式：7F +SID + NRC。

其中NRC全称为Negetive Responce Code，每个NRC具有唯一的含义来代表当前诊断请求错误的原因所在。当然每个诊断服务支持的NRC不尽相同，具体支持的NRC需要参考ISO14229-1标准文档，对于27服务而言支持的NRC如下表1：

表1 27 服务NRC列表

例如当尝试请求复位时且当前车速条件不满足，此时Client发送诊断指令"27 01"请求Server的Seed，Server将会回复“7F 11 22”来告诉请求者当前进入编程会话的条件不满足，请再次检查进入编程会话的条件。
当发送报文长度或者格式不对时，则Server会回复"7F 27 13"；
当诊断请求的subfuntion不在Server支持的范围内时，则Server会回复”7F 27 12“；
当Server从未接受到request seed的子服务，直接发送Send Key至Server时，那么此时Server则会回复 “7F 27 24”；
当securityDataRecord超出规定的范围时，则Server会回复 “7F 27 31”；
当发送完request Seed的子服务之后但是执行send key步骤时，发送的Key与Server计算出的Key不一致，此时Server会回复 “7F 27 35”;
当尝试一定次数的Send Key，Server始终无法解锁时，Server则会回复“ 7F 27 36 ”；
一般而言，如果超过了Server规定的尝试次数，那么就会开启Delay Timer，如果在延时的过程中发送request Seed的请求，那么Server则会回复 “7F 27 37” ;

常见Bug大揭秘
对于从事过UDS开发的小伙伴可能会发现，其实针对每个服务的Bug都是有迹可循的，万变不离其宗，绝大多数问题都是由于针对需求理解不清晰或者其他人为因素导致的问题。

因此，为了方便大家能够在工作过程中能够快速找到问题症结所在，特将小T了解到的常见27服务Bug分享给到大家，当然具体问题还是要具体分析，小T这里所列出的只是比较典型且出现错误次数较多的Bug，仅供参考。
11-27服务常见Bug大揭秘