【AutoSar_UDS服务】0x27服务_安全访问

1 术语解释

1.1 缩略语

缩写描述解释
DcmDiagnostic Communication Manager诊断通信管理
SIDService identify服务标识符
NRCNegetive reponse code否定响应码

2 功能简介

2.1 功能概述

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

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

2.2 服务应用场景

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

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

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

2.3 服务实现原理

安全解锁过程:

如下图所示,uds 0x27服务的安全解锁的过程是基于Seed-Key 机制来实现,Server中可具有多个安全等级(Level),特定的功能(打开车窗)的控制需要解锁指定的安全等级,某个安全等级(即下文中的n)解锁的具体过程可分为以下四个阶段:

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

注:一个安全等级的解锁需要发送两次请求,也就是说一个安全等级对应2个sub-function.
在这里插入图片描述
如果Server内置有多个安全等级,那么解锁的安全等级可以改变吗?
是可以的,如下图所示,只要通过上文的流程解锁对应的安全等级即可。值得一提的是,Server内只能解锁或激活一个安全等级,且如果一个安全等级状态已处于unlocked状态,当client向Server请求seed时,Server会回复一个肯定响应并且seed都为0x00。

注:解锁某个安全等级之前,须进入响应的会话;一般地,特定的安全等级对应着不同的安全事件,比如刷写的安全等级是LEV-3和例程控制的安全等级LEV-1;
在这里插入图片描述
之前说了0x27服务解锁的流程,**那在什么情况下,解锁状态会重新上锁呢?**答案如下:

  1. 会话模式改变:如果特定的安全等级解锁后,其会话模式被0x10服务切换到不支持的会话下,即会重新上锁;
  2. 重新上电或ECU重启:如果程序重新启动,那么安全等级默认为locked状态。

特殊地,0x27服务中还有这样的特性,如果解锁一定次数且解锁结果都是失败,那么需要过一段时间才允许再次解锁。这个有点像咱们的手机在解锁失败5次后,可能会被锁定5分钟。当然这个功能需要根据需求在配置中实现。

3 请求响应定义

3.1 请求消息格式

1)请求seed的消息格式如下:
根据Cvt值,securityAccessDataRecord可选发送,一般不需要发送;
在这里插入图片描述
2)发送key的消息格式如下:
在这里插入图片描述
3)0x27服务中的子服务定义如下图:
在这里插入图片描述

3.2 肯定响应格式

1)请求seed的肯定响应如下图:
在这里插入图片描述
2)接收完key的肯定效应格式:(27 + 40) + (sub-function),以子服务0x2为例,即如下图:
在这里插入图片描述

3.3 否定响应格式

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

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

4 服务请求实例

4.1 解锁正响应实例#1

Tester ECU 02 27 01(request seed) 安全等级处于locked状态 04 67 01 36 57(send seed) 04 27 02 C9 A9(send key) 02 67 02(postive reponse) Tester ECU

4.2 解锁正响应实例#2

Tester ECU 02 27 01(request seed) 安全等级处于unlocked状态 04 67 01 00 00(send seed) Tester ECU

4.2 否定响应实例

Tester ECU 02 27 01(request seed) 安全等级处于locked状态 04 67 01 36 57(send seed) 04 27 02 C9 A8(send key) 02 7F 27 35(invaild key) 04 27 02 C9 A7(send key) 02 7F 27 35(invaild key) 04 27 02 C9 A6(send key) 允许尝试三次解锁 02 7F 27 36(exceededNumberOfAttempts) 04 27 02 C9 A5(send key) Delay Timer启动 02 7F 27 37(requiredTimeDelayNotExpired) Tester ECU

5 配置说明

DcmDsdService:

  • 配置子服务和对应的会话
  • SID
    DcmDspSecurityRow:
  • 安全等级
  • 对应安全等级下的生成seed和比较key的回调函数
  • 对应安全等级下的尝试次数,和解锁失败该次数后锁定的时间(Delay time)

6 参考资料

1. UDS诊断服务基础篇之27
2. ISO 14229-1:2013
3. AUTOSAR_SWS_DiagnosticCommunicationManager.pdf

  • 21
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
autosar_sws_timesyncovercan是AUTOSAR标准中定义的基于CAN总线的时间同步服务。 在汽车电子系统中,不同的控制单元(ECU)需要按照统一的时间基准进行操作,以确保各个控制单元之间的协调和同步。autosar_sws_timesyncovercan就是为了满足这个需求而被定义的。 autosar_sws_timesyncovercan使用了CAN总线作为通信的介质,通过CAN总线将时间同步消息发送到各个控制单元。通过时间同步消息,各个控制单元可以获取精确的时间信息,并根据这个时间信息进行各种操作,例如数据传输、事件触发等。 autosar_sws_timesyncovercan实现了基于Master-Slave架构的时间同步机制。其中,Master节点负责发送时间同步消息,而Slave节点则负责接收并进行时间同步。Master-Slave架构确保了整个系统中所有控制单元之间的时间保持一致。 autosar_sws_timesyncovercan定义了不同的时间同步模式,包括周期同步模式和非周期同步模式。周期同步模式适用于需要周期性执行任务的应用场景,而非周期同步模式适用于一次性任务的应用场景autosar_sws_timesyncovercan还规定了时间同步消息的格式和传输方式,确保消息的可靠性和准确性。同时,还定义了时间同步相关的接口和API,方便控制单元的开发和集成。 总之,autosar_sws_timesyncovercan是一种以CAN总线为基础的时间同步服务,通过统一的时间基准来协调和同步汽车电子系统中的各个控制单元,实现系统的高效运行和协作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值