/*

Module Name:  Learning Notes

Module Data:  2024.5

Module Auth:  baiyingjie

Description:   UDS诊断模块学习笔记

Others:记录一下学习UDS的资料整理

*/

1. 属于与简称

• 一.DCM，诊断通信管理，

Diagnostic Communication Mannger

主要实现UDS和OBT的诊断服务。负责处理诊断数据和管理诊断状态，包括诊断会话和安全状态，DCM模块负责检查诊断服务的请求是否满足条件。DCM由三个子模块组成，分别是DSL,诊断会话。DSD，诊断服务调度。DSP诊断服务处理。

1. DSL诊断会话服务

用于确定诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序，管理诊断状态。（诊断会话和安全状态）

• 处理诊断请求

当收到诊断请求时，PDUR调用Dcm_StartOfReception()和Dcm_CopyRxData()函数将收到的诊断请求数据放置在DCM模块的Buffer中，然后PDUR调用Dcm_TpTxConfirmation()函数通知Dcm模块接收到了新的诊断请求。

• 处理诊断响应

当需要响应诊断请求时，DSL模块通过调用PduR_DcmTransimit()和Dcm_CopyTxData()将数据传递至PDUR模块，其中PduR_DcmTransimit()函数只是传递长度信息、地址信息，数据是通过Dcm_CopyTxData()函数传递至PDUR模块，当数据传输成功后，PDUR模块通过Dcm_TpTxConfirmation()函数告知DCM数据接收成功。

• 管理安全等级

DSL提供Dcm_GetSecurityLevel()、DslInternal_SetSecurityLevel()两个函数分别用于获取当前的安全等级和设置安全等级。

对于配置层面而言，DSL菜单主要是配置诊断帧，包括物理寻址和功能寻址，单次通信的最大Buffer，以及时间参数，包括回复0x78的时间和为了防止诊断服务异常，允许0x78的最大次数等。

1. DSD服务调度

用于处理诊断数据流。DSD模块负责检查诊断请求的有效性（诊断会话、安全访问级别、应用程序权限的验证），并跟踪服务请求执行的进度，然后进行不同的服务调度

1.检查诊断服务

当DSL接收到新的诊断请求，DSL通过内部接口通知DSD，如图3所示。DSD调用Dcm_GetSesCtrlType()、Dcm_GetSecurityLevel()获取当前的Session和安全等级，DSD模块会在当前Session的“Service Identifier Table”检查诊断请求SID是否在其中，如果不在table中，DSD会发送NRC 0x7F，如果诊断服务支持，但当前Session不支持该子服务，DSD会发送NRC 0x7E；然后检查当前安全等级是否满足条件，如果当前安全等级不支持该诊断请求，DSD会发送NRC 0x33。最后检查数据的长度。

2.汇总响应数据

当DSP模块完成诊断请求处理后，DSD负责将整理响应数据。并发送至DSL。

DSD模块将服务标识符(SID)(如果是负反馈，则为0x7F)和响应的数据流添加至“Dcm_MsgContextType”。然后DSD将其传送至缓冲区，并在缓冲区的第一个字节添加SID。

对于配置而言，DSD主要是配置所需要实现的服务，以及服务所支持的session以及服执行的安全等级。

1. DSP诊断服务处理

用于处理实际的诊断请求。DSP用于实现不同服务的处理，当接收到DSD请求处理诊断服务，DSP的处理过程如下：

1、分析接收的请求信息，调用不同的诊断服务实现函数；

2、检查格式以及是否支持所寻址的子功能；

3、获取数据或者调用DEM、SWC或者其他BSW模块的接口。如图4所示。比如0x22和0x2E服务需要调用SWC的数据接口进行读写；0x28需要调用BswM的逻辑实现关闭不同的CAN报文；0x19服务需要调用DEM模块获取快照数据和扩展数据。

4、汇总响应数据。

对于配置而言，DSP模块配置项比较杂，比如：

1.DID的实现，包括DcmDspData用于配置DID的数据类型，数据长度，以及接口类型；DcmDspDidInfo用于配置DID的读写功能；DcmDspDids用于汇总DcmDspDidInfo和DcmDspData，并且添加DID value。

2.安全等级的实现，包括种子和秘钥的位数、最大的错误访问次数，以及时间参数。

3.Session的配置，包括Session的等级，Session是否支持跳转至Boot，以及时间参数P2 ServeMax和P2* ServeMax。

总体来讲DCM模块主要是实现UDS和OBD诊断服务的实现，但是DCM跟其他模块的交互比较频繁，需要了解诊断服务的机制需要其他模块配合，比如BswM、DEM、EcuM以及SWC等。

二．DEM,诊断事件管理

Dem全称为Diagnostic Event Manager，负责故障事件的处理、故障数据的存储和管理。简单说其功能是故障事件确认前的故障debounce，故障事件确认时的故障数据存储，故障发生后的故障老化、故障替代（AUTOSAR的故障存储策略）。主要负责DTC相关的参数实现。

AUTOSAR标准中对Dem模块最上层分了两菜单栏（参见图1），分别是DemConfigSet，DemGeneral。其中DemConfigSet负责不同DTC、event等的配置，DemGeneral负责DTC、event的共用部分，包括冻结帧、扩展帧、使能条件等。

下面主要介绍上层菜单下的配置选项。

1.——DemConfigSet——

DemConfigSet下包含图2所示的配置项，下面针对常用的配置选项进行介绍。

1. DemComponent

DemComponent又名MonitorComponent，主要用于有关联的故障事件。比如传感本身发生故障，这时控制器读取的数据应该被视为无效。一个DemComponent是若干故障事件的集合，在DemComponent内部，故障事件有优先级，当最高优先级的故障事件状态为Failed导致其他故障事件状态也为Failed，或者父节点DemComponent的状态为Failed导致子节点DemComponent内的故障事件状态变成Failed，这种故障叫做连续错误（CONSECUTIVE FAULT），其他被认为是偶发错误（CAUSAL FAULT）。另外如果DemComponent内部故障事件优先级被忽略，那么仅有当父节点DemComponent的状态为Failed导致子节点DemComponent内的故障事件状态变成Failed被称作是连续错误（CONSECUTIVE FAULT）。

2. DemDTCAttributes

DemDTCAttributes用于配置DTC的属性，包括老化周期、故障优先级、存储方式（立即存储还是下电存储）、快照数据需记录的最大组数以及参考的冻结帧数据快照数据、故障数据存储的memory等，其中快照数据、扩展数据等需要在DemGeneral中配置。

3. DemDTC

DemDTC用于配置故障的DTC值（诊断故障码）、DTC的严重程度以及参考的DTC属性、Obd属性等。

4. DemDebounceCounterBaseClass、DemDebounceTimeBaseClass

这两项主要用于为不同的故障事件配置不同的debounce策略，可以是基于计数器的debounce策略，也可以是基于时间的debounce策略，或者由SWC自定义，具体请查看AUTOSAR故障Debounce策略。

5. DemObdDTC

DemObdDTC用于配置obd类故障事件是否支持Pto以及故障事件的DTC值等。

6. DemPidClass

用于配置Pid以及相关联的应用层信号。

7. DemEventParameter

DemEventParameter用于配置故障的类型（BSW or SWC）、故障需要多少个运行循环才能确认、是否支持预存储功能、故障事件的debounce策略以及参考的DTC属性、DemComponent、使能条件、运行循环等。

以上参数基本为DemConfigSet比较重要的配置项，其他未介绍的可以查看标准。

2.——DemGeneral——

DemGeneral主要用于配置DemConfigSet中不同event、DTC共用的一些参数，所以相对来说比较杂，下面针对一些进行介绍。

1. DemDataElementClass

DemDataElementClass用于配置内部、外部元素，如表1所示，用于配置扩展数据和快照数据的数据源。其中内部元素如表2所示，外部元素主要分通过C/S或S/R接口获取应用层的数据。（有一张表没加，需要下方链接自取）

2. DemDidClass

DemDidClass用于配置快照数据的Did 以及对应的DemDataElementClass。

3. DemExtendedDataRecordClass

该项用于配置扩展数据的id、扩展数据触发储存条件和参考的DemDataElementClass。

4. DemFreezeFrameRecordClass

该项主要用于配置快照数据的触发存储条件以及快照id。

5. DemFreezeFrameClass

该项用于配置快照数据包含的数据，数据来自DemDataElementClass。

由于Dem信息很多，难以一一介绍，主要挑了一些主要的进行介绍

文章参考链接：AUTOSAR DEM_dtcsignificance-CSDN博客   

三.PDUR路由

PduR全称PDU Router，是汽车通信架构中的核心组件之一。它主要负责在不同通信网络之间传输和处理数据，它位于不同协议模块之间，起到了一个重要的桥梁作用。

PduR模块的核心功能主要包括接收数据、路由数据、拆分数据以及合并数据等。它能够接收来自上层协议模块的数据，如诊断（Diag）、控制器局域网（CAN）、局域网（LIN）等，并将其路由到下层协议模块，如CAN接口（CanIf）、LIN接口（LinIf）等。此外，PduR模块还可以对数据进行拆分和合并，以满足不同通信协议的要求。

在汽车通信架构中，PduR模块充当一个终极消息中转站的角色。通过PduR模块的路由功能，上层协议模块可以将数据发送到对应的下层协议模块，而下层协议模块也可以将数据发送到对应的上层协议模块。这样，各个协议模块之间可以实现高效的数据交换和共享。

PduR模块主要提供两方面的服务：

一是承上启下衔接上层和下层：发送时派发从高层模块的PDU到低层模块；接收时派发从底层模块如If或者TP接收的PDU给高层模块（COM，PduR）。

二是通信网络中的网关功能。其中网关功能有两种：从一个接口层到另外一个相同或者不同总线类型的接口层；从一个TP到另外一个相同或者不同总线类型的TP层。其中路由协议是基于一个静态的路由表和PDU ID的概念。

缩略词：

CAN Communication Matrix：CAN通信矩阵，用来描述完整的CAN网络，包括：涉及的CAN节点；CAN PDU的定义（ID和数据长度DLC）；PDU的发送和接收信息。

Physical Channel：物理通道。代表CAN网络的接口，不同CAN硬件单元的不同物理通道可以访问不同的网络。

DCM: Diagnostic Communication Manager，诊断通信管理

COM IF：communicationinterface modules，通讯接口模块

COM Tp：Communication Transport，通讯传输

IpduM：I-PDU Multiplexer，I-PDU多路复用

DLC：Data LengthCode，描述SDU长度的CAN信息。

I-PDU: Interaction Layer Protocol Data Units，交互层协议数据单元。

L-PDU：Data LinkLayer Protocol Data Unit，数据链接层的协议数据单元，包含标识符（ID）, 数据长度（DLC）和数据（L-PDU）

L-SDU：Data LinkLayer Service Data Unit数据链接层服务数据单元，它其中的数据传输到L-PDU中。

gatewaying-on-the-fly: 网关功能。在两个TP模块之间的路由，在所有数据被接收之前，数据的转发就开始了(当达到指定的阈值时)。如果在两个接口之间传输数据量较大，最好能够在从源网络接收所有数据之前在目标网络上开始传输，可以节省内存和时间。

multicast operation：组播模式。同时传递PDU给众多接收组群。（1：n）

data provision：数据条款。包含两种数据条款接口模式：直接数据条款和触发型数据条款。

last-is-best buffering：first in first out缓冲策略，用最新值覆盖最后一个值。

FIFO buffering：缓冲概念，使用先进先出策略。

SF：Single Frame，单帧

FF：First Frame，首帧

CF：ConsecutiveFrame，连续帧

N-PDU：CAN传输层的网络协议数据单元。

N-SDU：CAN传输层的服务数据单元。其中的数据传输到N-PDU中。

PDU Router：协议数据单元路由。将I-PDU从一个模块传递到另外一个模块，PDU Router可以用于网关运行或内部路由

• DTC, DID,RID,SID

DTC的定义：

DTC（Diagnostic Trouble Code）就是诊断故障码。在原则上一个DTC只能定义一个故障类别。它是故障类型的"身份ID"；用于汽车故障时对故障部位及原因的排查当发生车辆故障的时候，为了让我们能够明白具体发生了什么故障而存在的Code。外部通过诊断器就可以确认DTC的值。读出来的DTC是现在正在发生的故障，还是过去发生过的故障，这个可以通过诊断服务的控制来得到不同的结果。

DID (Data ldentifer):数据标识符(DID)是用于表示车辆电子控制单元(ECU)内特定数据项或数据项组的唯一标识符。这些数据项可以包括传感器读数、执行器位置和诊断故障代码(DTCs)等。

RID (Routine ldentifer):例程标识符(RID)是在诊断模块中用来识别特定服务例程的参数。SID(Service ldentifer):服务标识符(SID)是用于识别车辆诊断服务请求的唯一代码。每个SID都对应一个特定的诊断服务例如读取故障码、控制执行器或编程ECU.

四.DTC的构成

根据ISO15031-6和ISO14229-1的故障诊断码格式规定，故障码信息由四字节组成。

DTCHighByte，DTCMiddleByte，DTCLowByte表示服务中的故障诊断码；StatusOfDTC表示故障码状态。

 DTCHighByte，DTCMiddleByte两字节表示故障内码，对应5位标准故障码，如表下所示。

5位标准故障码的第一位是字母，后面四位是数字。第一个字节的bit7，8位表示字母表示故障所属系统。有00，01，10，11四个选择项，分别代表着动力系统故障（Powertrain），底盘故障（Chassis），车身故障(Body)和网络故障(Network)。

DTCHighByte第二个字符表示故障类型，使用故障内码Bit5和Bit4对应着。也有00，01，10，11四个选择项，00=ISO/SAE标准定义的故障码,01=制造商自定义的故障码而10，11为保留项。

第三位字符表示故障所属的子系统。该位“0”表示燃油和空气计量辅助排放控制整个系统，

“1”表示燃油和空气计量系统；

“2”表示燃油和空气计量系统(喷油器)；

“3”表示点火系统；

“4”表示废气控制系统；

“5”表示巡航、怠速控制系统；

“6”表示与控制单元相关；

“7”“8”表示变速箱系统等。

第四五位字符落在了DTCMiddleByte字符之上，表示具体故障对象和类型。                        

原文链接：【车载开发系列】诊断故障码DTC基本概念与定义_dtc故障诊断-CSDN博客

LowByte 这个字节表示Failure Type Byte (FTB)，包含Failure category和Failure Sub Type两个部分。（ISO 15031-6 中的DTC LowByte 表示Failure Type Byte (FTB)，而ISO 14229-1 中的DTC LowByte 表示ID序号）

参考文章：UDS DTC故障码格式_uds的状态码-CSDN博客

【车载开发系列】诊断故障码DTC基本概念与定义_dtc故障诊断-CSDN博客

/*-------------------------以下为详细解释，但没有上面总述写的好------------------------------*/

1、OBD DTC 格式结构

OBD DTC 5位标准故障码 占2字节（省略Byte0 ：0x00）。

示例：0x0143 的动力系统DTC应显示为 P0143。

字符3用于标识特定的车辆区域； 在任何区域内，显示字符4和5最多允许256个代码定义

对于动力总成，这些Bit受 ISO/SAE 控制；对于所有其他人，它们是制造商控制的

对于动力总成，11 = P3000到P33FF的制造商控制；11 = ISO/SAE为P3400到P3FFF保留

• 五.UDS子模块流程记录

对照项目可以字节看其中他们的名称，定义，作用。第一大节，第二大节有提到

        service_name.request (

A_MType,应用层服务消息类型（有本地诊断和远程诊断）

A_SA,                                   //应用层服务源地址

A_TA,                                   //应用层服务目标地址

A_TA_type,                               //应用层服务目标地址类型

[A_AE],                                  //应用层服务扩展地址

A_Length,                                //应用层服务数据长度

A_Data[,parameter 1, ...],          //应用层服务数据参数

                                                ）

————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

                        

原文链接：UDS诊断协议学习系列4——应用层服务代码原语及变量解释_uds中的原语是干啥的-CSDN博客

协议中此部分内容是约定俗称的，不做多余赘述，接下来主要是介绍A_PDU的相关内容，

A_PDU：应用层，协议数据单元，app_protocol_data_unit。

另外我们还需要知道的知识是M,C,S,U。一般主机厂给的诊断规范也会涉及这几个单词作为信息的约定限制条件等级，M即mandatory,强制的；C即conditional，有条件的；S即selectable，可选的；U即UDR，即user defined。