UDS诊断服务基础篇之27 |
您所在的位置：网站首页 › 格式刷是干什么用的怎么用 › UDS诊断服务基础篇之27 |
UDS诊断服务基础篇之27
|
前言
首次，请教大家关于诊断服务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比较，如果一致则解锁成功，否则解锁不成功；
从上图中可看出，每一次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步骤：
下图3中各参数解释如下：
如下图4所示为Send Key步骤，即图1中所示S3步骤，在S3中Client向Server发送Key的验证请求，看是否能够安全解锁成功。
图4中的各个参数解释如下图5所示：
从图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所示：
以 27 01 请求种子(Request Seed) 为例，如下图7所示：
假设此时Server通过正响应并给到的Seed(0x36 0x57), 然后Client便会基于该Seed计算出对应的Key(假设为0x C9 0xA9)，并发送如下Send Key请求实例(27 03):
从图7与图8可以看出，请求Seed的字节数目与算出的Key字节数目一般情况下是保持一致的，且27 01 与27 02 诊断请求中一个为奇数，一个为偶数，且两者是加1的加1 的关系，符合我们上述提到的Request Seed与Send Key的定量关系。 服务响应服务响应是针对Client对Server诊断请求的响应。 正响应格式如下图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请求示例所对应的正响应：
其中，0x01表示request Seed的子服务，0x36 0x57则为Server接受到来自Client的种子请求之后通过调用随机数算法生成的Seed，这样Client便可以基于该Seed作为输入并按照客户或者平台要求的安全算法进行计算。 Verify Key 如下图10所示，则为Server发送给到Client的Verify 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：
对于从事过UDS开发的小伙伴可能会发现，其实针对每个服务的Bug都是有迹可循的，万变不离其宗，绝大多数问题都是由于针对需求理解不清晰或者其他人为因素导致的问题。 因此，为了方便大家能够在工作过程中能够快速找到问题症结所在，特将小T了解到的常见27服务Bug分享给到大家，当然具体问题还是要具体分析，小T这里所列出的只是比较典型且出现错误次数较多的Bug，仅供参考。
更多精彩内容！敬请关注公众号: ADAS与ECU之吾见 公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！
|
【本文地址】