UDS作为汽车电子领域必备技能,之前文章《UDS基础知识介绍》已经介绍过UDS基础知识,AUTOSAR发展至今已经20多年,是行业内各大厂商智慧的结晶,其架构设计的内容依然是如今行业学习的标杆和榜样。本文将介绍UDS是在AUTOSAR软件中如何实现的。
本文将从三个方面介绍,UDS功能如何在AUTOSAR中实现的1.1 AUTOSAR中哪些模块与UDS相关?
在AUTOSAR中用于实现诊断协议栈功能的模块是DCM和DEM - DCM模块主要负责车辆电子系统与外部诊断工具之间的通信,实现诊断信息的传输和处理。
- DEM模块主要负责处理和存储诊断事件(即故障和错误)及相关数据,如故障码(DTC)、故障状态字节、故障发生计数器、冻结帧数据等。
其余关联性较大的模块有CanTp,PduR,CanIf,Can等。1.2 什么是Dcm
Figure 7.1: Possible interaction between the submodules in the DCMDcm是一个比较复杂的模块,AUTOSAR将其内部分成三个子模块,DSL,DSD和DSP1.2.1 DSL
DSL(Diagnostic Session Layer)子模块确保与诊断请求和响应相关的数据流,监督并保证诊断协议定时,并管理诊断状态(诊断会话和安全)。 DSL子模块提供了以下功能,它确保了诊断会话的安全性、可靠性和高效性:- 应用层定时处理:管理超时时间、请求间隔以及响应等待时间等,以确保诊断过程的顺利进行;
1.2.2 DSD
DSD(Diagnostic Service Dispatcher)是DCM的一个重要子模块。DSD的主要职责是处理报文的统一校验及将报文分发到内外部处理模块,它是DSL与DSP之间的桥梁,具有承上启下的作用。- 支持诊断服务标识符检查和诊断消息适配:检查其诊断服务标识符(SID)的有效性。这确保只有受支持的服务请求被进一步处理;
- 处理“suppressPosRspMsgIndicationBit”;
- 验证功能:对诊断请求的初步验证,包括检查请求的格式、长度、数据范围等是否符合协议要求;
1.2.3 DSP
DSP(Diagnostic Service Processing)子模块负责处理实际的诊断服务(或子服务)请求,是处理实际诊断服务请求的核心部分。- 诊断模式声明组:处理与诊断模式相关的请求,这些模式可能包括默认会话模式、扩展会话模式等。
- 环境条件依赖的执行:某些诊断服务的执行可能受到车辆当前环境条件(如发动机运行状态、车速、温度等)的限制
- 传递SwDataDefProps属性从DEXT文件到Dcm Service SW-C;
如何找到模块交互的信息?搞明白一个模块的内涵,最简单入手的就是先了解这个模块的接口,提供了参数?2.1 如何简单的理解PDU?
PDU是在通信网络中传输的数据单元,PDU负责封装和传递应用层数据,使得不同的模块和设备能够互相交换信息。 依据通讯OSI分层模型,AUTOSAR分别定义了I-PDU,N-PDU,L-PDU用于不同的数据层;- PDU(交互层PDU):应用层信号的通讯数据单元,对于诊断I-PDU为n个N-PDU经过TP层打包封装组成;
- N-PDU(网络层PDU):指单帧,首帧,连续帧,流控帧;
- L-PDU(数据链路层PDU):包含CAN ID、Data Length和Data等信息;
2.2 诊断发送
Figure 9.9: Dcm to CanTp PDU transmission- I-PDU: 62 F1 90 31 32 33 34 35 36 37 38 20 20 20 20 20 20 20 20 20
- I-PDU: 62 F1 90 31 32 33 34 35 36 37 38 20 20 20 20 20 20 20 20 20
- N-PDU[FF]: [10 14] 62 F1 90 31 32 33
- N-PDU[CF]: [21] 34 35 36 37 38 20 20
- N-PDU[CF]: [22] 20 20 20 20 20 20 20
2.3 诊断接收
- PduR_CanTpStartOfReception
- N-PDU[FF]: [10 14] 2E F1 90 31 32 33
- N-PDU[CF]: [21] 34 35 36 37 38 20 20
- N-PDU[CF]: [22] 20 20 20 20 20 20 20
- I-PDU: 2E F1 90 31 32 33 34 35 36 37 38 20 20 20 20 20 20 20 20 20
- I-PDU: 2E F1 90 31 32 33 34 35 36 37 38 20 20 20 20 20 20 20 20 20
AUTOSAR中的配置扮演着至关重要的角色,它对于确保汽车电子系统的灵活性、可重用性、可扩展性和互操作性具有重要意义。如下展示对Dcm学习比较有益的几个配置框图,并仅对其中部分做解释说明,详细的配置参数说明请参阅AUTOSAR标准规范。3.1 DcmDsl
AUTOSAR DCM: DcmDslBuffer configuration overviewDcmDslBuffer:上节所说的Dsl具有传输诊断消息的功能,来自PduR模块的数据,将会存储于这个DcmDslBuffer。DcmDslBufferSize:诊断请求或响应最大长度,ISO15765-2网络层协议中定义诊断最大请求和响应长度为4095Byte;软件中为节省RAM资源,请求和响应的内容共用一个Buffer,从下图关联关系中则可以看出DcmDslProtocolRxBufferRef 与 DcmDslProtocolTxBufferRef都指向DcmDslBuffer。AUTOSAR DCM: DcmDslProtocol configuration overview 前文所述的Dsl时间管理功能,则可以从配置DcmDslProtocolRow看出。AUTOSAR DCM: DcmDsd configuration overview DcmDsdService: 中主要包含支持的服务的配置信息,包含Session,Security,SID等。AUTOSAR DCM: DcmDsdSubService configuration overviewDcmDsdSubService中主要包含支持的子服务的配置信息,包含Session,Security,SubID等。 代码对于软件工程师的学习具有至关重要的作用,它不仅是软件开发的核心,也是工程师们提升技能、理解原理、解决问题和创新的基石。详细软件代码参考Q版AUTOSAR----QSAR,开源网址:https://gitee.com/QSAR/Software,基于开发板可直接运行调试。建议大家阅览过程中可以相互对照QSAR代码与AUTOSAR原文档接口与配置部分,将会更容易的理解文档。- 自己编辑做CDD/ODX文件,使用CANoe测试;
- 基于开源软件QSAR,依葫芦画瓢修改诊断协议栈的软件,并验证。
联系方式
参考文件:
[1] AUTOSAR R22-11 - AUTOSAR_SWS_DiagnosticCommunicationManager[2] AUTOSAR R22-11 - AUTOSAR_SWS_DiagnosticEventManager[3] AUTOSAR R22-11 - AUTOSAR_SWS_PDURouter[4] AUTOSAR R22-11 - AUTOSAR_SWS_CANTransportLayer[6] Autosar通信入门系列02-一文看懂各层PDU_autosar pdu-CSDN博客[7] CAN诊断轻松入门第一讲-网络层与应用层基本知识讲解 - 知乎 (zhihu.com)[8] CAN诊断轻松入门第二讲-UDS服务讲解 - 知乎 (zhihu.com)[9] CAN诊断轻松入门第三讲-DTC知识讲解 - 知乎 (zhihu.com)[10] 《UDS协议从入门到精通》系列——到底什么是DTC?_uds dtc-CSDN博客[11] ISO14229-1, Unified diagnostic services (UDS) – Part 1: Application layer (Release 2015)[12] ISO15765-2, Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network layer services[13] 小公司如何使用“AUTOSAR”?– 汽车电子与软件[14] 介绍一款开源的AUTOSAR-QSAR – 汽车电子与软件