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 – 汽车电子与软件
