【ISO14229_UDS_0x27服务详解】

1、0x27服务(安全访问服务)

  0x27服务的目的就是能够允许去访问一些数据或者诊断服务,当然这些都是限制类型的访问,可能是出于保密、排放或者是安全因素。对于一些诊断服务,用于下载/上传例程或者数据到服务端,或者是从服务端读取一些特定内存值,这些情况下安全访问可能是有必要的。当一些不恰当的控制例程或者数据下载到ECU中,可能会损伤电子器件、车辆部件、或者是使得车辆不满足排放、安全、保密等标准。0x27服务采用了种子(Seed)和密钥(Key)的概念。
  0x27服务具体的使用案例如下:
—— 客户端向ECU请求种子(Seed);
—— ECU向客户端发送种子(Seed);
—— 客户端向ECU发送密钥(Key)(可以基于随机数等一些方法计算出Key值);
—— ECU对客户端发送的密钥进行比对并应答,如果Key有效,那么ECU将会解锁;
  请求种子(‘requestSeed’)子函数的参数值总是为奇数如0x01,0x03,0x05,在同样的安全等级下,发送密钥的子函数参数值则应该等于(‘requestSeed’)子函数的参数值加1,如27 01对应27 02;
  在任何情况下,只有一种安全等级被激活。例如,如果与0x03(‘requestSeed’)子函数有关的安全等级处于活跃状态,并且客户端成功解锁了与0x01有关的安全等级,那么只有与0x01有关的安全功能才会被解锁使用。之前与0x03有关的其它安全功能,则当前不可使用。安全等级的编号是任意的,并不意味着安全等级之前有任何的关系。
  客户端应该通过发送请求种子(‘requestSeed’)去请求ECU解锁(“unlock”),ECU应该在肯定应答消息中发送一个种子(Seed)。接下来,客户端拿到ECU给的种子值,通过随机数等方法计算得到密钥(Key)值,在‘sendKey’请求消息中反馈给ECU。ECU应该将客户端请求的密钥值与自身存储或者计算出的密钥值进行比对,如果二者匹配,ECU将会允许客户端去访问一些特定的服务/数据,并且对‘sendKey’请求指令做出肯定应答。如果二者不匹配,这就意味着客户端做了一次错误尝试,需要客户端从请求种子(‘requestSeed’)从头开始。
  如果客户端支持安全访问,但是当前的安全等级已经被解锁,并且0x27服务的请求种子(‘requestSeed’)消息也已经得到了肯定应答,那么服务端就会发送值全部为0的种子值。在当前安全等级被锁住的情况下,客户端应该永不不会发送值全为0的种子值,客户端可以根据这个规则检查种子的应答值,来判定ECU是否被锁在某种特定的安全等级下。
  当ECU上电/重启之后,客户端安全访问错误的尝试了一些次数后,汽车制造厂商要求在此种情况下应该延时一段时间才能使用安全访问的服务。当安全访问错误尝试的次数达到了汽车厂商规定的次数,或者是ECU上电/重启之后并且安全访问失败了,则对延时使用安全访问服务应该被支持。如果ECU支持延时的计时器,安全访问服务发送密钥被成功执行之后,用于显示ECU上电/重启后显示延时计时器的消息应该被清除。如果ECU支持延时计时器,并且不能判处出在ECU上电/重启前安全访问服务是否失败了,那么延时计时器应该总是处于激活状态。这种延时只有在ECU上电/重启时被锁住的情况,汽车制造厂商可以自主选择是否支持这种延时。
  安全访问的尝试不应该影响到正常车辆通讯或者是其它诊断服务通讯。支持安全性的ECU应该在被锁住的时候,对安全访问服务发送拒绝类的消息。
  在特定诊断会话下,成功地请求的某些诊断功能/服务,需要执行特定的安全访问序列。在这种情况下,则要求如下的安全访问序列:
——诊断会话控制服务(0x10服务)
——安全访问服务(0x27服务)
——保密的诊断服务
  在ECU中不同的会话模式下,有不同的访问模式。

2、请求消息格式

请求消息的格式定义:
请求种子(‘requestSeed’),子函数的参数定义详见下表:

字节序号参数值约定字节值
#1SecurityAcces Request SIDM0x27
#2sub-function = [
    securityAccessType = requestSeed ]
M0x01;
0x03;
0x05;
0x07-0x7D;
#3
.
.
#n
securityAccessDataRecord[] = [
              parameter#1
              .
              .
              parameter#m

U
.
.
U

0x00-0xFF
.
.
0x00-0xFF

发送密钥(‘SendKey’),子函数的参数定义详见下表:

字节序号参数值约定字节值
#1SecurityAcces Request SIDM0x27
#2sub-function = [securityAccessType = sendKey ]M0x02;
0x04;
0x06;
0x08-0x7E;
#3
.
.
#n
securityKey[] = [
       parameter#1
        .
        .
       parameter#m

M
.
.
U

0x00-0xFF
.
.
0x00-0xFF

请求消息中子函数参数定义说明:
  子函数参数——安全访问类型(securityAccessType)向ECU表明正在执行的动作,客户端想要访问的安全等级,种子和密钥的格式。如果ECU支持不同的安全等级,那么每种安全等级应该被请求种子(requestSeed)值定义,其与密钥发送(sendKey)值之间有固定的关系:
——“requestSeed = 0x01”就定义了“requestSeed = 0x01”和“sendKey = 0x02”之间的固定关系;
——“requestSeed = 0x03”就定义了“requestSeed = 0x03”和“sendKey = 0x04”之间的固定关系;
下表定义了请求种子(requestSeed)和密钥发送(sendKey)值(suppressPosRspMsgIndicationBit (bit 7)不显示):

Bit 6 - 0描述约定
0x00ISOSAEReserved
ISO保留
M
0x01requestSeed
汽车制造厂商定义了0x01——请求种子(requestSeed)的安全等级
U
0x02sendKey
汽车制造厂商定义了0x02——密钥发送(requestSeed)的安全等级
U
0x03,0x05,
0x07 - 0x41
requestSeed
汽车制造厂商定义了请求种子(requestSeed)的不同安全等级
U
0x04,0x06,
0x08 - 0x42
sendKey
汽车制造厂商定义了密钥发送(requestSeed)的安全等级
U
0x43 - 0x5EISOSAEReserved
ISO保留
U
0x5FISO26021-2 values
汽车制造厂商定义了“车载打火装置报废期的激活”——请求种子(requestSeed)的安全等级
U
0x60ISO26021-2 sendKey values
汽车制造厂商定义了“车载打火装置报废期的激活”——密钥发送(requestSeed)的安全等级
U
0x61 - 0x7EsystemSupplierSpecific
系统供应商保留使用
U
0x7FISOSAEReserved
ISO文档后续定义使用
U

请求消息中数据参数定义说明:
请求消息中数据参数定义说明详见下表:

定义
安全密钥(高和低字节)
在请求消息中的密钥(“Key”)参数是根据种子(“Seed”)值基于安全算法计算得出的
安全访问数据记录
此参数用户可选,在请求种子消息时,可向客户端发送一些数据,例如包含客户端的标识符

3、肯定应答消息

肯定应答消息格式定义如下:

字节序号参数名称约定字节值
#1SecurityAccess Response SIDM0x67
#2sub-function = [ securityAccessType ]M0x00 - 0x7F
#3
.
.
#n
securitySeed[] = [
       seed#1(high byte)
        .
        .
       seed#m(low byte)

C
.
.
C

0x00-0xFF
.
.
0x00-0xFF

肯定应答消息数据参数定义:

Definition
securityAccessType
请求消息子函数参数中的bit6 - 0
securitySeed (high and low bytes)
种子是由ECU发送,客户端在计算密钥时需要使用的一个参数。当请求发送消息中了设置子函数要求服务发送种子时,安全种子(securitySeed)数据的字节值只会在响应消息中出现。

4、支持的否定应答码(NRC_)

  该服务会支持一些否定应答码,哪些情况会产生哪些否定应答码具体如下表所示。当服务端在错误场景下使用该服务,以下否定应答码应该被使用。

NRC描述
0x12sub-functionNotSupported
子函数参数不被支持时,会发送该NRC
0x13incorrectMessageLengthOrInvalidFormat
消息长度不正确或格式无效时,会发送该NRC
0x22conditionsNotCorrect
条件不正确时,会发送该NRC
0x24requestSequenceError
请求序列不正确时,如客户端发送了密钥,却没有先请求种子,则会发送该NRC
0x31requestOutOfRange
如果用户选择的安全访问数据记录(securityAccessDataRecord)中包含了无效数据,会发送该NRC
0x35invalidKey
'sendKey’子函数的密钥值与ECU内部存储或计算得到的密钥值不匹配
0x36exceededNumberOfAttempts
错误访问尝试次数超出了最大值,延时计时器激活
0x37requiredTimeDelayNotExpired
在延时计时器激活时,发送了请求

5、0x27服务(安全访问服务)案例使用说明

案例的假设条件:
在如下给定的消息流案例中,如下的条件必须被满足,才能成功解锁服务端:
——请求种子的子函数:0x01 (requestSeed)
——发送密钥的子函数:0x02 (sendKey)
——服务端发送的种子(2字节):0x3657
——服务端的密钥(2字节):0xC9A9
案例1:服务端处于锁定状态
  Step1:请求种子
  Step1,安全访问服务(0x27服务)请求种子(子函数)的请求消息流案例,由客户端发往服务端:

字节顺序Description字节值
#1SecurityAccess Request SID0x27
#2SecurityAccessType = requestSeed,
suppressPosRspMsgIndicationBit = FALSE
0x01

  Step1,安全访问服务(0x27服务)请求种子(子函数)的应答消息流案例,由服务端发往客户端:

字节顺序Description字节值
#1SecurityAccess Request SID0x67
#2SecurityAccessType = requestSeed0x01
#3
#4
securitySeed [ byte#1 ] = seed#1 (high byte)
securitySeed [ byte#2 ] = seed#2 (low byte)
0x36
0x57

  Step2:发送密钥
  Step2,安全访问服务(0x27服务)发送密钥(子函数)的请求消息流案例,由客户端发往服务端:

字节顺序Description字节值
#1SecurityAccess Request SID0x27
#2securityAccessType =
          sendKey,
          suppressPosRspMsgIndicationBit = FALSE
0x02
#3
#4
securityKey [ byte#1 ] = key#1 (high byte)
securityKey [ byte#2 ] = key#2 (low byte)
0xC9
0xA9

  Step1,安全访问服务(0x27服务)发送密钥(子函数)的应答消息流案例,由服务端发往客户端:

字节顺序Description字节值
#1SecurityAccess Request SID0x67
#2SecurityAccessType = sendKey0x02

案例2:服务端处于解锁状态
  Step1:请求种子
  Step1,安全访问服务(0x27服务)请求种子(子函数)的请求消息流案例,由客户端发往服务端:

字节顺序Description字节值
#1SecurityAccess Request SID0x27
#2SecurityAccessType = requestSeed,
suppressPosRspMsgIndicationBit = FALSE
0x01

  Step1,安全访问服务(0x27服务)请求种子(子函数)的应答消息流案例,由服务端发往客户端:

字节顺序Description字节值
#1SecurityAccess Request SID0x67
#2SecurityAccessType = requestSeed0x01
#3
#4
securitySeed [ byte#1 ] = seed#1 (high byte)
securitySeed [ byte#2 ] = seed#2 (low byte)
0x00
0x00

返回UDS诊断服务功能单元介绍目录

  • 5
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: iso-14229是一项用于汽车电子系统通信的协议,其全称为ISO14229 Unified Diagnostic Services(UDS)on Controller Area Network(CAN)。该协议旨在为车辆的诊断、维护和修复提供标准化的方法。ISO 14229定义了诊断服务和通信的标准化消息格式,包括诊断数据、错误码、故障清除等,以使不同车辆的系统实现得到统一和互操作性。 ISO14229 UDS协议栈是用于实现ISO 14229诊断协议的软件组件。该协议栈的实现可分为物理层和软件层两个部分,其中物理层是指使用CAN总线对车辆的执行单元进行通信,而软件层则是指实现ISO 14229标准的协议堆栈。该协议栈具有标准化、可重用和可配置的特点,可在不同的客户平台上使用。 ISO 14229的文档是对该协议的规范和说明,包括协议的基本架构、消息格式、错误码表、会话层和传输层的细节等。该文档是实现ISO 14229协议的必要依据,可用于开发UDS协议栈的开发人员和车辆诊断工程师。 源码.zip则是UDS协议栈的实现源代码,包括物理层和软件层代码。开发人员可根据该源码了解UDS协议栈的实现细节和技术实现,并根据需求进行二次开发。 综上所述,ISO-14229_14229_UDS协议栈_UDS-ISO-14229_ISO14229文档_ISO 14229_源码.zip等组件,是用于实现汽车电子系统诊断的标准化协议,可为车辆的维护和修复提供规范的方法。开发人员和车辆诊断工程师可根据这些组件进行UDS协议栈的开发和实现。 ### 回答2: ISO-14229是用于诊断汽车电子控制单元(ECU)的标准协议。该协议旨在提供一种标准化的方法,让技术人员可以使用相同的工具和流程诊断不同制造商的汽车。 14229 UDS是该标准的通信协议栈。UDS指协议栈中定义的通用诊断服务,该服务可用于访问ECU的内部数据和状态。ISO14229文档提供了UDS协议栈的详细规范,以及相关的数据格式和命令集合。 此外,文档和源代码可以帮助工程师实现符合ISO-14229标准的诊断工具或ECU,提高汽车诊断系统的质量和效率。源码.zip则是UDS协议栈的代码包。 总之,ISO-14229标准和UDS协议栈提供了一种标准化的、可靠的汽车诊断协议。它们有助于提高汽车技术人员的工作效率,同时减少汽车诊断工具和软件的开发成本。 ### 回答3: ISO-14229是一种用于汽车电子系统的通讯协议。它定义了诊断通信的规范和协议,允许车辆厂商和供应商使用这些规范和协议来开发和测试车载电子控制单元。其中,UDS协议栈是实现ISO-14229的关键技术之一,能够为客户端提供远程访问ECEs的可能性。 ISO-14229规定了接口:UDS(Unified Diagnostic Service),用于与电子控制单元(ECU)之间进行通讯。 UDS协议栈则实现了UDS协议的接口,可以自动进行诊断和测试,发生故障时还能产生错误报告。 相应地, ISO14229文档描述了在ISO14229-1文档中定义的UDS协议的特定应用,与ISO15765-2的特定要求相结合。 它还包括了EVITA Light文档中的安全方面。 源码.zip文件则包含了UDS协议栈的源代码,可以在开发与应用中使用,实现对汽车电子控制单元的简便对话操作。 总之,ISO-14229及其UDS协议栈实现了车载控制电子单元的标准化通讯,可简化车辆诊断和维护过程,提高效率和可靠性。同时,相应的规范、文档和源代码也为相关人员提供了方便和支持。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值