【ISO14229_UDS_0x36服务详解】

1、0x36服务(TransferData,数据传输服务)

  Service description:
  0x36服务(TransferData,数据传输服务),既可以被客户端用于从客户端到服务端的数据传输(即下载),也可以用于服务端到客户端的数据传输(即上传)。
  数据传输方向由进程中的RequestDownload 或者是 RequestUpload的服务来决定。如果客户端开始一个RequestDownload服务,要下载的数据应该包含在transferRequestParameter的参数中,具体的参数在0x36服务的请求报文中。如果客户端开始一个RequestUpload服务,要上传的数据应该包含在transferResponseParameter的参数中,具体的参数在0x36服务的应答报文中。
  在多个TransferData请求中,防止有一个TransferData服务失败了,TransferData服务的请求包含了一个blockSequenceCounter,来改善错误处理。当接收到RequestDownload (0x34)服务或者RequestUpload (0x35)服务的请求报文时,服务端的blockSequenceCounter应该被初始化为1。这意味着在RequestDownload (0x34) 或者 RequestUpload (0x35)请求消息之后的第一个TransferData (0x36)的请求报文,blockSequenceCounter会从1开始。

2、请求报文格式

2.1 请求报文定义

  下表定义了请求报文的格式:

字节序号参数值约定字节值
#1TransferData Request SIDM0x36
#2blockSequenceCounterM0x00 - 0xFF

#3
.
.
#n
transferRequestParameterRecord[] = [
               transferRequestParameter#1
               .
               .
               transferRequestParameter#m ]

C
.
.
U

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

  C = Conditional:如果一个下载正在进程中,该参数则是强制的。

2.2 请求报文中子函数参数定义

  该服务未使用子函数参数。

2.3 请求报文中数据参数定义

  该服务在请求报文中的数据参数定义如下表所示:

定义
blockSequenceCounter
在RequestDownload (0x34)或RequestUpload (0x35)服务之后的第一个TransferData请求,blockSequenceCounter的参数值从0x01开始。对于每个后续的TransferData请求,其值递增1。blockSequenceCounter增加,超过在0xFF的值时,下一个TransferData请求消息从0x00重新开始。
使用的案例如下:
— 在服务端,如果一个TransferData下载数据的请求被正确的接收并且处理了,但肯定应答报文没有到达客户端,那么客户端将会确认应用层超时,并且会重复同样的请求(包括同样的blockSequenceCounter)。服务端将会接收重复的TransferData请求,并且基于包含的blockSequenceCounter去确认这个TransferData请求是重复的。一旦再一次写入数据到内存中后,服务端会立即发送肯定应答报文。
— 在服务端,如果一个TransferData下载数据的请求没有被正确的接收,接着服务端不会发送肯定应答报文。客户端将会确认应用层超时,并且会重复同样的请求(包括同样的blockSequenceCounter)。服务端将会接收重复的TransferData请求,并且基于包含的blockSequenceCounter去确认这个TransferData请求是新的。服务端将会处理这个服务,并且会发送肯定应答报文。
— 在服务端,如果一个TransferData上传数据的请求被正确的接收并且处理了,但肯定应答报文没有到达客户端,那么客户端将会确认应用层超时,并且会重复同样的请求(包括同样的blockSequenceCounter)。服务端将会接收重复的TransferData请求,并且基于包含的blockSequenceCounter去确认这个TransferData请求是重复的。一旦再一次写入数据到内存中后,服务端会立即发送肯定应答报文。
— 在服务端,如果一个TransferData上传数据的请求没有被正确的接收,接着服务端不会发送肯定应答报文。客户端将会确认应用层超时,并且会重复同样的请求(包括同样的blockSequenceCounter)。服务端将会接收重复的TransferData请求,并且基于包含的blockSequenceCounter去确认这个TransferData请求是新的。服务端将会处理这个服务,并且会发送肯定应答报文。
transferRequestParameterRecord
此参数记录包含服务端支持数据传输所需的参数。该参数的格式和长度由汽车制造商指定。
EXAMPLE  对于下载来说,transferRequestParameterRecord包含了传输的数据内容。

3、肯定应答报文

3.1 肯定应答报文格式定义

字节序号参数值约定字节值
#1TransferData Response SIDM0x76
#2blockSequenceCounterM0x00 - 0xFF

#3
.
.
#n
transferResponseParameterRecord[] = [
        transferResponseParameter#1
        .
        .
        transferResponseParameter#m ]

C
.
.
U

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

  C = Conditional:如果一个上传正在进程中,该参数则是强制的。

3.2 肯定应答报文数据参数定义

  该服务肯定应答报文中使用到的数据参数的定义见下表:

定义
blockSequenceCounter
该参数是请求报文中的blockSequenceCounter参数。
transferResponseParameterRecord
该参数包含了一些参数,这些参数是客户端支持数据传输所需要的。这个参数的格式和长度是车辆制造厂商所指定的。
EXAMPLE  对于下载来说,参数transferResponseParameterRecord可以包括服务端计算得到的checksum值。对于上传来说,参数transferResponseParameterRecord包含了上传的数据内容。对于下载来说,参数transferResponseParameterRecord不会重复transferRequestParameterRecord。

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

  本服务实施了如下否定响应代码,下表记录了每个否定应答码发生的情况,如果服务端在错误场景使用了该服务,则应使用如下列出的否定响应码。

NRC描述
0x13incorrectMessageLengthOrInvalidFormat
请求报文长度不正确时,会发送该NRC。(比如消息长度不满足requestDownload服务的肯定应答报文中返回的maxNumberOfBlockLength参数的要求)
0x24requestSequenceError
以下情况会则会使用该否定应答码:
— 当该服务接收到请求时,如果RequestDownload 或者 RequestUpload服务没有激活;
— 如果RequestDownload 或者 RequestUpload服务已经激活,但服务端已经接收到所有的数据了,数据由在激活的RequestDownlod 或者 RequestUpload服务中的memorySize参数来决定。
0x31requestOutOfRange
以下情况会会发送该NRC:
— transferRequestParameterRecord包含了额外的控制参数(如附加的地址信息)并且这个控制信息是无效的;
— transferRequestParameterRecord与requestDownload 或者 requestUpload服务中的参数maxNumberOfBlockLength不一致;
— transferRequestParameterRecord与服务端内存中分配的约束条件不一致;
0x71transferDataSuspended
如果下载模块的长度与requestDownload服务请求报文中发送的memorySize参数不一致时,会返回该否定应答码。
0x72generalProgrammingFailure
在下载数据过程中,如果服务端在永久内存设备(如Flash)擦除或者刷写一块内存区域时,检测到错误发生,会发送该NRC。
0x73wrongBlockSequenceCounter
blockSequenceCounter的顺序发生错误时,会发送该NRC。
0x92/0x93voltageTooHigh / voltageTooLow
下载数据到服务端永久内存中时,检测到服务端针脚上的电压超出可接受范围,会发送该NRC。

  0x36服务(RequestUpload,请求上传服务)的否定应答码(NRC)具体处理过程如下。
在这里插入图片描述

5、0x36服务(TransferData,数据传输服务)案例说明

  具体的案例见0x37服务(RequestTransferExit,请求传输退出服务)的案例

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

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值