【UDS诊断】

1 简介与概述

不同诊断通信协议的开发,调整,实施和维护会给车辆制造商,系统供应商和ECU供应商带来不必要的成本。为了解决此问题,将不同的技术协议和数据通信原理编译为一个国际ISO标准,通常称为统一诊断服务(ISO 14229-1)。

UDS ISO 14229-1:2013(UDS)和ISO 15765-3:2004(基于在CAN上的诊断)是互补标准,共同指定“ 基于CAN上的UDS”应用层协议。

【UDS诊断】_第1张图片

对于基于CAN总线的乘用车,将参考ISO 15765-2和ISO 11898。对于基于CAN总线的卡车(总质量大于3500 kg的道路车辆)将参考ISO 11992-4和ISO 11992-J。它们指定了道路车辆及其牵引车辆之间的诊断数据通信。下图总结了相关的ISO标准以及相应OSI层

【UDS诊断】_第2张图片

UDS服务的协议数据单元(PDU)包含地址信息和诊断消息(数据字段)。数据字段由服务标识符组成(SID)和可选的数据参数组成。数据字段由一字节长的服务标识符来控制服务的功能(这一个字节也可理解成为是Appliction layer的协议控制信息)。

应用协议层的下方是传输层/网络层,其PDU包含控制信息PCI,数据信息Data.即N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节,N_DATA值主要集中在后面7位字节。其中,SF_DL 代表单帧中数据个数,FF_DL代表 连续帧中的数据总数,SN代表此帧为连续帧中的第几帧, FS参数控制发送端是否能继续传输数据,BS规定发送端允许持续传输连续帧数目的最大值,STmin限定连续帧相互之间所允许的最小值。具体如下图所示

【UDS诊断】_第3张图片

2 UDS诊断服务介绍

诊断服务根据功能处理目的被分类为各个不同的功能单元,下图总结了各种不同功能单元,UDS服务和及其服务ID。ISO 14229-1指定的25种统一诊断服务分为六个功能单元。

【UDS诊断】_第4张图片

a. SID是服务标识符的缩写。

b. Def是默认会话层的缩写。ECU上电后会重置为默认会话层。

c. RoE是事件响应的简称。在此列中的“ x”表示该服务可作为事件响应机制的事件服务。

d. Sub-Fct是子功能的缩写。此服务支持子功能,因此支持肯定的响应抑制功能。

e. 这些服务如果在默认会话中可能需要安全访问服务才能请求。

f. 在默认会话中无法访问(某些数据标识符DID)。需要发出单独的$ 27(SecurityAccess)来解锁以访问这些数据。

2.1 根据服务的功能单元和请求服务标识符对服务进行分类

诊断和通信管理功能单元

$10 DiagnosticSessionControl 该服务请求ECU从活动会话过渡到其他会话。

$11 ECU重置

该服务请求ECU执行复位。ECUReset请求参数的示例包括hardReset,keyOffOnReset和softReset。

$27 SecurityAccess

此服务用于在活动诊断会话中达到更高的安全级别。可能需要SecurityAccess请求来解锁并访问受保护的功能及数据(例如通过DID读取ECU ID信息)。也可以用于从一个会话通过解锁以成功切换到其他会话。

$28 CommunicationControl

该服务请求ECU控制其通信行为。一个典型的示例包括要求CAN总线中的ECU关闭车载通信,以提高诊断通信的效率。

$3E TesterPresent

TesterPresent请求通常定期发送,并包含一个功能地址。它指示测试仪仍处于连接状态(存在),并请求ECU保持当前诊断状态(例如,除默认会话之外的其他会话处于活动状态,RoE机制仍处于活动状态)。对这个服务的正响应抑制可以减少总线负载。

$83 AccessTimingParameter

该请求用于读取和/或修改通信定时参数。

$84 SecuredDataTransmission

此请求用于传输受加密方法保护的诊断数据。为此,必须实现位于应用程序层与测试仪和ECU的应用程序之间的“安全子层”。数据根据ISO 15764(扩展数据链接安全性)进行处理。

$85 ControlDTC设置

该服务要求ECU停止/恢复DTC的设置。将此服务与车载通信切换 (服务$28通讯控制)相结合,可增加用于Flash编程的速度。

$86 ResponseOnEvent

事件响应(RoE)服务请求ECU自动传输指定事件的响应。

$87 LinkControl

该服务请求控制通信数据速率。对于CAN,它会影响ISO 11898中规定的数据链路层,从而影响用于板载通信以及诊断通信的数据速率。转换数据速率的请求分为(1)验证网络上的ECU是否允许特定的数据速率;(2)在验证结果为肯定的情况下请求转换;以及(3)执行转换。

数据传输功能单元

$22 ReadDataByldentifier

该服务请求读取由DID参数标识的数据记录值。DID用于标识特定的本地数据记录。数据标识符$F224可以包含诸如电池电压,歧管绝对压力,空气质量流量,车辆大气压以及计算出的负载值之类的数据。

$23 ReadMemory ByAddress

该服务请求读取指定内存范围的当前值。请求参数是内存地址和内存大小。用于请求参数的字节数在addressAndLengthFormatldentifier中指定。

$24 ReadScalingDataByidentifier

该服务请求ECU将缩放信息值传输到测试仪。测试人员使用定标信息值来转换数据。这项服务的实施增加了ECU软件的实用性。作为替代,测试器可以将缩放比例信息存储在数据库中。

$2A ReadDataUyPeriodicidentifier

该服务请求定期发送数据记录值。所请求的数据的传输速率由传输模式参数设置,例如“中等速率发送”,例如300 ms。

$2C DynamicallyDefineDataldentifier

该服务允许测试人员在ECU中动态定义新的数据标识符,其中包含对静态定义的标识符和/或内存地址的引用。测试人员随后可以通过服务请求2A(readDataByPeriodicIdentifier)读取此动态定义的数据记录。动态定义的标识符的一个优点是, 一次服务可以请求传输很多的的数据记录

$2E WriteDataByldentifier

通过此服务,可以将由标识符(DID)指定的数据记录写入ECU存储器。

$3D WriteMemoryByAddress

该服务允许将数据记录直接写入ECU的内存。请求参数是内存地址和内存大小以及数据记录。用于参数内存地址和内存大小的字节数在addressAndLengthFormatidentifier中指定。

存储数据传输功能单元

$14清除诊断信息

此服务允许在一个或多个ECU中清除错误存储器的内容。因此,可以使用物理地址或功能地址来请求服务。

$19 ReadDTC信息

诊断故障代码(DTC)用于编码和识别检测到的与排放有关和与排放无关的故障。DTC通常为三个字节,这意味着最多可以定义16,777,216个不同的DTC。该服务从一个或多个ECU请求DTC信息的状态。因此,该服务可以用物理地址或功能地址查询。测试人员可以请求与DTC关联的已存储数据记录,也称为“ DTC快照”。DTC快照包含故障发生时的特定数据值。

输入输出控制功能单元 $2F InputOutputControlByIdentifier

该服务主要用于代替输入信号的值和/或控制ECU的输出。通常,此服务会绕过ECU的应用程序软件并直接触发输出电路,然后直接读取连接到输入电路的传感器。

例程服务单元 $31例程控制

该服务用于维护和停止ECU内部例程。可以读取例程的结果以进行分析。该例程由两个字节的例程identifier标识。

上传下载功能单元 $34请求下载

此服务启动从测试仪到ECU的数据传输。当ECU准备从测试仪接收数据时,它会发送肯定响应,其中包含用于后续数据传输的可用块大小(每个传输数据请求的数据字节数)

$35请求上传

此服务启动从ECU到测试仪的数据传输。当ECU准备好将数据发送到测试仪时,它会发送一个肯定的响应,其中包含用于后续数据传输的块大小(每个传输数据请求的数据字节数)

$36 TransferData

此服务用于在测试仪和ECU之间(下载)或在ECU和测试仪之间(向上)传输数据。如果需要一个以上的transferData请求来传输数据,则使用blockSequenceCounter对传输次数进行计数。计数器允许在传输损坏后重复传输块。因此,在出现通信问题时,不必再次传输完整的数据

$37 RequestTransferExit

该服务用于终止transferData服务。完整的数据传输从requestDownloadrequestUpload服务开始,再由几个transferData服务继续,并由requestTransferExit服务完成。

3 基于CAPL的诊断服务举例

3.1 CAPL介绍

“ CAPL”是通信访问编程语言的缩写。其目标是尽可能简单地解决特定任务。典型的任务是对接收到的消息做出反应,检查和设置信号值并发送消息。
CAPL程序是事件驱动的。这意味着它们由各自的功能组成,每个功能都对被分析系统中的事件做出反应:接收消息,信号的改变,定时器到期,甚至环境变量的变化。例如,要对接收到的消息“ EngineState”作出反应,可以使用:On message EngineState{//USER DEFINED FUNCTION}。消息中名称为“ EngineState”和该消息中的信号的名称为“ EngineSpeed” // Used for display purposes. on message EngineState { @sysvar::Display::SetRPM = this.EngineSpeed / 1000.0; } 和C语言一样,可通过include和varibles去包含头文件和定义变量。但CAPL程序不向用户提供要使用的任何指针类型,而是通过this实现特定对象的绑定。

includes {

}

variables { 
    message 0x100 DiagnosisID={dlc=8};
	const byte PostiveResponse_0xF192[9] = {0x62, 0xF1, 0x92, 0x33, 0x31, 0x32, 0x34, 0x41, 0x42};
    const byte P2_Timer = 200;}

3.2 诊断服务实例分析

下面的例子使用多个不同服务来执行复杂诊断过程的过程,以完成在ECU的内存中编写一个新的变体信息和写入日期的例子。

【UDS诊断】_第5张图片

步骤1-开启ECU ECU上电后,诊断软件堆栈初始化,等到ECU中的诊断服务器初始化完成后,ECU处于默认会话中。 测试仪到目前为止禁止未传输服务,否则服务会丢失。 但是诊断仪可以做一些内部的初始化工作。如启动CANOE后调用以下函数:

v2-8f2976f7a937736aea4d05daf664bca0_1440w.webp

on start { setWriteDbgLevel(0); // set DbgLevel = 1 to get more information in Write-Window } 

步骤2-读取ECU识别码 必须读取ECU硬件的标识符,检查变体之后决定是否更新变体编码。服务22(readDataByldentifier)与数据标识符 Fl 92(systemSupplierECUHardwareNumberDataldentifier)以字节2和3一起发送。

【UDS诊断】_第6张图片

void ReadDID_0xF192 (void) { //Read ECU identification :write("Read ECU identification ");
	DiagnosisID.byte(0)=0x03;
	DiagnosisID.byte(1)=0x22;
	DiagnosisID.byte(2)=0xFD;
	DiagnosisID.byte(3)=0x92;
	DiagnosisID.byte(4)=0x00;
	DiagnosisID.byte(5)=0x00;
	DiagnosisID.byte(6)=0x00;
    DiagnosisID.byte(7)=0x00;
    output(DiagnosisID);
    } on timer Tick_timer 
{ //Check response 
    if(WaitResponseCnt < P2_Timer) { 
        WaitResponseCnt ++; 
    } else { 
        write(" Response not received ,P2 Timeout"); 
    } 
}

肯定响应:服务标识符(62),字节2( F1)和字节3(92)中的数据标识符。字节4至9, [33, 31, 32, 34, 41, 42]包含六个 ASCII 字符 “ 3124AB” ,用于识别ECU软件。测试人员将此字符串与内部存储的参考值进行比较。肯定的响应意味着ECU硬件与随后诊断操作兼容,这对于编写变体代码是必需的。

第3步-切换到Programmmg会话层 ECU收到从默认会话层切换到编程会话层的请求,子功能字节的数据参数指定了DiagnosticSessionType。ECU使用子功能字节指定编程会话层的类型。在下一步中,发送肯定响应服务标识符0指定编程会话层的类型。在下一步中,ECU发送肯定响应服务标识符 50 以响应请求。回显的 10。回显的 02反映了请求的会话类型,并标明ECU将执行转换。传递肯定响应后立即进行转换。

【UDS诊断】_第7张图片

第4步-安全访问 步骤4由两部分组成。 为了提高安全性,测试人员必须向ECU请求种子。 为此,测试人员发送一个27(securityAccess)以及子功能参数 01(requestSeed)。 ECU传输肯定响应服务标识符(67)和子功能字节( 01)。 接下来的四个字节$ [12,34,56,78)包含种子。

 void SecurityAccess_0x2701 (void) { //Request ECU seed : write(" Request ECU seed");DiagnosisID.byte(0)=0x02;
	DiagnosisID.byte(1)=0x27;
	DiagnosisID.byte(2)=0x01;
	DiagnosisID.byte(3)=0x00;
	DiagnosisID.byte(4)=0x00;
	DiagnosisID.byte(5)=0x00;
	DiagnosisID.byte(6)=0x00;
	DiagnosisID.byte(7)=0x00;

	output(DiagnosisID);
}
void SecurityAccess_0x2703 (void) { //Request to send ECU key : write(" Request to send ECU key");
    DiagnosisID.byte(0)=0x06;
	DiagnosisID.byte(1)=0x27;
	DiagnosisID.byte(2)=0x02;
	DiagnosisID.byte(3)=0x9A;
	DiagnosisID.byte(4)=0xBC;
	DiagnosisID.byte(5)=0xDE;
	DiagnosisID.byte(6)=0xF0;
	DiagnosisID.byte(7)=0x00;

	output(DiagnosisID);
}   

【UDS诊断】_第8张图片

现在,测试人员必须使用机密算法从种子计算密钥。 然后,测试人员再次发送服务请求27(securityAccess)。字节2现在包含值02(sendKey),该值指示测试人员将发送密钥。字节3至6 [9A,BC,DE,FO]包含计算出的密钥。 ECU将密钥与内部计算的参考值进行比较,如果两个值相同,则接受密钥。如果是这样,则ECU传输带有子功能字节(02)的肯定响应( 67)。

服务$ 27(securityAccess)在默认会话中不可用。

步骤5“编写变体编码

在图5.34,实现了更高的安全级别,并且测试器发送了带有数据参数14(addressAndLengthFormatfdentifier)的请求3D(writeMemoryByAddress)。 该数据参数包含以下信息:请求的内存大小为一个字节,内存地址的长度为四个字节地址 [00,FF,00,00]在字节3到6中发送。字节7的值为,这意味着将写入存储区个字节。字节到包含变体编码10,这意味着将写入存储区16个字节。字节8到23包含变体编码 [101,02,03,04,05,06,07,08,09,0A,OB,OC,OD,OE,OF,FF]。

【UDS诊断】_第9张图片

ECU发送肯定响应服务标识符(7D)和某些镜像请求字节的参数 [14,00,FF,00,00,01]。

第6步-编写编程日期 在图5.35中,显示了另一个数据在ECU内存中的写入。使用2E(writeMemoryByidentifier)代替服务 3D(write­ MemoryByAddress)。 出于归档和追溯要求,最后一次编程(第5步)的日历日期将存储在ECU的内存中。测试器发送请求2E(writeDataByidenlifier)和数据标识符 [Fl, 99](programmingDate)。有关这些数据标识符的更多信息,请参阅ISO 14229-1附件C.1。 字节4至10,[32, 30, 30, 32, 30, 34, 32, 31] 包含编程日期(2002年4月21日),编码为ASCII字符(20020421)。ECU传输肯定响应服务标识符(6E)和对应的数据标识符。

【UDS诊断】_第10张图片

步骤7-重置ECU 在示例的最后一步,测试人员通过发送请求来重置ECU 11(resetECU)和子功能字节 81。 suppressPosRspMsgIndicationBit的值为1(TRUE),表示ECU将抑制对此服务的肯定响应。 ECU不发送响应并完成复位。 子功能字节的其他七个位指定了ECU进行复位的类型,本例中为hardReset。重置后,ECU处于默认会话活动状态。

【UDS诊断】_第11张图片

4 UDS通信堆栈的状态机

  • OSI模型的分层架构 UDS诊断通讯模块采用了类似OSI模型的分层架构。如下图所示。

【UDS诊断】_第12张图片

CAN_DRV为系统的CAN硬件驱动。通过与硬件寄存器的交互,驱动提供了对CAN模块初始化以及收、发CAN Frame的接口函数。 CAN_IF通过对CAN底层驱动提供的接口进行封装,实现了网络层功能模块与硬件底层驱动之间的隔离。因此,当需要将该网络层移植到其他平台时,只需要依据新平台的CAN底层驱动对CAN_IF模块进行更新,而不需要对网络层主体功能模块作出修改,从而大大增强了模块的可移植性和可重用性。 TP_NL模块是网络层的主体功能模块,其功能是将来来自上层(应用层)的A_PDU解包成N_PDU, 并按照ISO-15765-2中描述的Segmented Message发送方式通过DC_CANIF接口与下层(CAN底层驱动)进行数据交换。或者将通过CAN_IF接收到的N_PDU封装成A_PDU,并向上(应用层)传递。TP_NLCFG是对网络层参数进行配置的模块。 TP_ALIF模块是网络层与应用层之间的接口模块。其作用是接收经过网络层打包后的A_PDU,并传递给指定服务功能模块,以及将各功能模块对请求的应答数据重新封装成A_PDU后,传递给网络层进行进一步的发送过程。TP_ALIFCFG模块维护了一张描述各应用层功能模块与A_PDU中SID的对应关系,TP_ALIF模块通过这张表格就能够快速地找到SID与应用层服务程序入口地址的映射关系,并跳转执行。

  • TP_ALIF应用层状态机

【UDS诊断】_第13张图片

在程序初始化完成后,应用层接口处于空闲状态(AL_IDLE),并通过一个10ms的任务来查询是否有来自下层的诊断服务请求。当查询到网络层报告的服务请求时,应用层接口即进入AL_BULID_AND_TRANSMIT状态。在这个状态中,应用层接口根据A_PDU中的SID信息,执行特定的诊断服务函数,得到应答的A_PDU,并传递给网络层进行发送,同时应用层接口进入AL_WAIT_CONFIRMATION状态。在AL_WAI_CONFIRMATION状态中,应用层接口等待网络层反馈的发送状态,发送成功后(或超时)后,应用层重新回到AL_IDLE状态,并等待处理下一个服务请求。 若在AL_BULID_AND_TRANSMIT状态中,从某一个诊断服务程序处得到的应答为否定0x78(Response Pending),则状态机在进入AL_WAIT_CONFIRMATION后,自动重新回到AL_BUILD_AND_TRANSMIT状态,并重新进入这个未执行完毕的诊断服务程序中进行处理,如此往复直至服务执行完毕后,状态机进入AL_IDLE状态,并等待处理下一个服务请求。

  • TP_NL网络层接收状态机

【UDS诊断】_第14张图片

当诊断仪没有发送任何服务请求时,网络层处于空闲状态(NL_IDLE)。 当接收SF时,网络层进入NL_RECEIVED_SF_FF状态。由于SF中已经包含了请求A_PDU中完整的数据信息,此时,网络层即可向通过与应用层的接口(DC_ALIF)向上层传递A_PDU已收到的消息,并有应用层依据A_PDU中的请求内容执行相应的服务程序。同时,网络层回到NL_IDLE状态,准备处理由上层传来的应答A_PDU。 当网络层在等待服务请求时,接收到的时FF时,网络层同样会进入NL_RECEIVED_SF_FF,依据ISO-15765-2中定义的Segmented Message发送方式,网络层需要发送FC来控制数据流的继续发送。因此,网络层会进入NL_TRANSMIT状态,并发送FC。在发送FC后,网络层进入NL_WAIT_CONFIRMATION状态,并判断FC发送成功后,网路层跳转到NL_RECEIVED_FC_CF状态,并进行后续CF的接收。若有必要,则重复NL_TRANMIT → NL_WAIT_CONFIRMATION → NL_RECEIVED_FC_CF的过程,直至接收完所有的Segmented Message, 并打包成A_PDU后,传递给应用层进行处理。 在UDS的应用层模块执行完服务请求的操作后,会将服务应答填充到A_PDU中,并经由DC_ALIF传递给网络层。网络层在接收到来自上层的发送请求后,便会对A_PDU进行解包成为N_PDU后。如下图所示的状态机,完成N_PDU的发送。

  • TP_NL网络层发送状态机

【UDS诊断】_第15张图片

系统的网络层在1ms任务中,对CAN底层驱动的接收情况进行轮询,同时处理网络层的CAN报文发送请求。如下图所示描述了网络层处于接收状态时的基本工作过程状态机。 当A_PDU的数据内容较少时(小于7个字节),A_PDU可以被解包成1个SingleFrame。在经过NL_TRANSMIT状态发送,并在NL_WAIT_CONFIRMATION中确认发送成功后,网络层即可回到NL_IDLE状态,开始等待诊断仪的下一个请求。 若A_PDU的数据内容较多,则N_PDU的发送必须采用Segmented Message的方式。首先,网络层在NL_TRANSMIT状态中发送FF,并在NL_WAIT_CONFIRMATION中确认FF发送成功。然后进入NL_RECEIVED_FC_CF状态中等待诊断仪发送的FC。在接收到有效的FC后,才能重新进入NL_TRANSMIT→ NL_WAIT_CONFIRMATION的循环进行后续CF的发送,直至发送完所有的N_PDU后,网络层重新回到N_IDLE状态,开始等待下一个诊断请求。

5 基于UDS规范的工具支持

5.1 诊断测试仪

  • Indigo

快速且易于操作的诊断测试仪,适用于单个ECU或整个车辆

  • CANoe / CANalyzer

支持带有ECU诊断功能的仿真和测试工具

  • CANape 支持带有ECU标定功能的测量和校准工具

5.2 Flash编程

  • vFlash 通过CAN,CAN FD,LIN,FlexRay,以太网(DoIP)刷写ECU。

5.3 诊断验证

  • CANoe.DiVa 通过数据驱动的测试案例生成,自动验证ECU中的诊断实现。

5.4 诊断规范/编写

  • CANdelaStudio 基于CDD格式模板的ECU诊断数据规范。支持ODX数据的导入和导出。
  • ODXStudio 支持查看,编辑和比较ODX 2.0.1和2.2.0数据文件

5.5 基础诊断软件堆栈

  • MICROSAR.DIAG

MICROSAR.DIAG包含BSW模块,支持根据AUTOSAR Classic实现基于UDS协议ISO 14229-1:2006(分别是ISO 14229-1:2013)协议开发的ECU诊断功能。

你可能感兴趣的:(嵌入式,单片机,UDS诊断)