全车载控制器基于CAN的UDS诊断服务功能解析与测试项.docx

《全车载控制器基于CAN的UDS诊断服务功能解析与测试项.docx》由会员分享，可在线阅读，更多相关《全车载控制器基于CAN的UDS诊断服务功能解析与测试项.docx（9页珍藏版）》请在第一文库网上搜索。

1、车载控制器基于CAN的UDS诊断 服务功能解析与测试项一、UDS功能的作用- 下线检测。写入相应的数据以及读取整车是否存在故障情况。读取 ECU的信息(零件号，软件版本，硬件版本等)，然后将该信息与生产 系统中该车应该安装的ECU的信息做比较及时发现零件错装的问题， 以及车辆下线的传感器自学习与标定等。- 故障记忆与存储。能够存储记忆汽车故障，能够实日由是供汽车各种运 行参数。- 故障维修。外部诊断设备通过一定的诊断通信规则与ECU建立诊断 通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。- 程序更新。依据ISO14229的UDS协议,定义的控制器软件升级流 程。二.UDS功能概述

2、UDS本质上是一种定向的通信是一种交互协议(Request/Response )z 采用的是Client/server的模式，基本是Client发送一个请求报文， Server根据请求报文做出回应Oient 一般情况下是指测试仪(Tester), Server 一般是指电控单元(ECU )。UDS协议栈中，协议分为常规的 七层，其中主机厂最为关注的也是第七层应用层。根据协议的类型，采 用何种通讯协议都会有对应的诊断服务类型，UDS协议可以是UDSonCANs UDSonLINs UDSonlP 等。三、UDS功能服务ISO14229-1协议中定义了 6类功能，26种服务，UDS功能服务主要 依

3、托于UDS报文的信息不同，UDS报文的格式为：SID+SF+DID的通 用格式，可以衍生出SID、SIDSFs SID+DID的报文格式。服务中SID的定义规则及规范如下表所示。正响应:SID+40 ;负响应:7F+SID+NRC ;-SID 0x10.Oxlls0x27、0x28、03Ex0x83、0x84s0x85.0x86-SF :主要应用在传输的数据比较大的服务中，例如更新程序，数据 的下载。网络层分为单帧和多帧，单帧(SF)就是一帧can报文8字节内就可以把 数据处理完毕。多帧就是一帧can报文8字节内无法发送完毕,需分为 首帧（FF）,流控帧（FC）,连续帧（CF）来进行处理。多帧

4、信息传输。SF.DL 单帧的字节数，FF_DL多帧的字节数。SN表示连续帧的序号，第一帧 为1 ,第二帧为2 ,第三帧为3等。FS表示的是流控状态参数。例如O 表示的是继续发送，1表示的是等待，2表示溢出。BS表示的是块的大 小，即发送端一次性能够发送多少个连续帧,OO的代表持续发送到完 毕。-Stmin发送两个连续帧需要等待的最短时间。应用举例：Tester请求：22 Fl 90 （单帧传输）ECU 响应:62 Fl 90 31 30 35 30 30 30 30 31 32 33 34 35 36 37 3839 39 （多帧传输），其多帧传输的具体过程为：ECU响应首帧（FF）: 10

5、14 62 Fl 90 31 30 35 （ 10代表首帧，14代表 传输的字节总数,62代表22的正响应）Tester收到首帧，发送流控帧（FC） : 30 00 64 （ 30代表流控帧, 00代表连续发送到完毕，64代表IOomS周期发送）ECU收到流控帧，发送第一条续帧（CF） : 21 30 30 30 30 31 32 33 （21中的2代表连续帧，1代表连续帧的第一帧）ECU间隔IOmS （即OXOA）后，发送第2条续帧（CF） : 22 34 35 36 37 38 39 39 （ 22中的2代表连续帧，2代表连续帧的第二帧）-DID :例如常见的FI85、F190等ISO标准

6、定义的DID ,以及用户自己定义的DIDo-NRC在ISo 14229中,负响应代码范围可以划分为3个范围OxOO :正响应参数值；OxOl - -0x7F :与通信相关的否定响应代码；0x80OxFF :针对特 定条件的否定响应代码。每一个服务对应的NRC都会根据具体的功能 不同。例如22服务支持的NRC包括0x13、0x14. 0x22、0x31、0x33等。所有的NRC参考ISOl4229-1的第325页举例：22 Fl 90负响应z2F Fl 90 13(出现错误的原因是NRC为0x13的描述导致的)诊断和通信管理功能单元(Diagnostic and CommunicationMan

7、agement)$10 -诊断会话控制(Diagnostic Session Control)服务请求ECU在各种会话模式中演桀。包含三个子功能:01-Default.02-Programmings 03-Extendedo$11 -电控单元复位(ECU Reset)该服务请求ECU执行复位。ECUReset请求参数的示例包括：HardResets KeyOffOnResetx SoftReseto$27 -安全访问(Security Access )此服务用于在对某些特殊数据读取和写入功能上加入一层保护功能。通 过SecurityAccess请求来解锁并访问受保护的功能及数据。$28 -通讯

8、控制(Communication Control)该服务请求ECU控制其通信行为。CAN总线中的ECU关闭和开启通 信，以提高通信的速率。$3E -待机握手(Tester Present)TeSterPreSent请求定期发送的一帧报文，它反映测试仪一直处于连接 状态。$85-诊断故障码设置控制(Control DTC Setting )该服务要求ECU停止/恢复DTC的设置。关闭和开启诊断功能，例如 可以在程序更新过程中，防止程序更新过程中会报通讯丢失故障等。数据传输功能单元(Data Transmission )$22 -通过 ID 读数据(Read Data By Identifier)

9、该服务请求读取由DID参数标识的数据记录值。$2E -通过 ID 写数据(Write Data By Identifier)通过此服务，可以将由标识符(DID )指定的数据记录写入ECU存储 器。存储数据传输功能单元(Stored Data Transmission )$14 -清除诊断信息(Clear Diagnostic Information )清除(复位)DTC格式,它可以改变DTC的状态。$19 -读取故障码信息(Read DTC Information )诊断故障代码(DTC )用于编码和识别检测到的与动力系统有关和无关 的故障。输入输出控制功能单元(Input & Output

10、Control)$2F -通过标识符控制输入输出(Input Output Control By Identifier) 该服务主要用于模拟输入的值和控制ECU的输出。通常，此服务会跳 过ECU的应用程序软件直接读取传感器的数据或者直接输出控制负载 的信号。例行程序功能单元(Remote Activation of Routine )$31 -例行程序控制(Routine Control)该服务用于维护和停止ECU内部例行程序。可以读取例程的结果以进 行分析。该例行程序由两个字节的例行程序identifier标识。上传下载功能单元(Upload & Download )$34 -请求下载(Re

11、quest Download )此服务启动从测试仪到ECU的数据传输。当ECU准备从测试仪接收数 据时,它会发送肯定响应,其中包含用于后续数据传输的可用块大/N每 个传输数据请求的数据字节数)$35 -请求上传(Request Upload )此服务启动从ECU到测试仪的数据传输。当ECU准备好外微据发送到 测试仪时，它会发送一个肯定的响应，其中包含用于后续数据传输的块 大小(每个传输数据请求的数据字节数)$36 -数据传输(Transfer Data )此服务用于在测试仪和ECU之间(下载)或在ECU和测试仪之间(向上)传输数据。$37 -请求退出传输(Request Transfer Ex

12、it) 该服务用于终止transfer Data服务。四、DTC故障码诊断故障码(Diagnostic Trouble Code , DTC ),是故障类型的具体描述，标准中对应的故障码所代表的意思全部进行了列举，用于汽车故 障时对故障部位及原因的排查。一般情况下,主机厂会针对其中的含义 或者信息进行修改，一个DTC信息占用3-4个字节，其中前2-3个字 节如下，最有一个字节为DTC的状态字节:每个DTC均由DTC内容和DTC状态表示:DTC内容描述该故障的具体故障信息。其中，DTCHighByte. DTCMiddIeByte这两个字节表示故障码，DTCLowByte的内容是描述故障种类和子

13、类型，该部分内容在ISO 15031-6中122页有具体描述，是否加入该字节的信息具体看项目是否有需要。故障码具体描述如下：1、DTCHighByte ( bit6-7 )2、DTCHighByte ( bit4-5 )00代表ISO标准定义的故障码，Ol代表制造商自己定义的故障码3、DTCHighByte( bit0-3 ),表示故障所属的子系统,主机厂或者Tierl 自己定义的内容。4、DTCMiddIeByte ( bit0-7 ),表示具体故障对象和类型,主机厂或 者Tierl自己定义的内容。DTC状态则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的 DTC状态信息。举例

14、：BitO :testFailed ;当 pendingDTC 或 ConfirmedDTC 被置 1 时，DTC 才会存储testFailed被置1的位。Bit3 : ConfirmedDTC ;当 ConfirmedDTC=I 时,testFailed = l 时, 则说明这个DTC表示的故障过去存储的故障，现在已经不存在该故障 了。当 ConfirmedDTC=I 时，testFailed=O 时，则说明这个 DTC 表 示的故障现在发送的故障。五、UDS功能的测试方法UDS协议栈测试包括诊断服务类测试项目和故障码测试类测试项目， 一般故障码需要在台架上设置相应的输入条件进行联合测试，诊断服务 类测试通过CANOE工具测试。-通过系统输出的诊断规范文件在CANdeIaStudio环境中编辑CDD 诊断数据库文件，导入到CANOE工具中，进行手动测试；通过CANdiva工具生成自动化测试工程进行测试；-通过CAPL语言编写测试程序进行自动化测试。六、UDS功能的测试 诊断报文的格式测试 诊断报文长度测试 诊断报文响应时间测试 诊断报文负响应测试 诊断报文正响应测试 会话模式测试 安全模式测试 多帧信息发送测试 ECU硬件复位 清除故障信息 读取故障信息 信息与数据的读取 信息与数据的写入 通信控制