基于CAN的UDS诊断服务

1. 引言与问题导入

• 故障发生原因：设计、生产、制造、使用、老化、意外等因素导致汽车在生命周期任何阶段都可能发生故障。
• 车载控制器功能需求：

  • 故障感知与通知：作为零部件系统大脑，需能感知并告知使用者或维修人员故障信息；

  • 状态存储功能：需存储故障状态或ECU状态以便后续分析；

  • 测试支持功能：需提供硬件控制等故障测试功能；

  • 数据传输功能：支持数据读写以便故障观测；

  • 安全保障：在安全前提下实现上述功能。
    

  • 典型诊断功能：

  • 核心功能：数据读取与写入、故障识别与管理、故障码与其现场状态；

  • 辅助功能：会话与安全控制、数据上传与下载、控制ECU通信/IO及其他硬件外设；

  • 标准化产物：将上述功能及通信过程标准化后形成UDS诊断协议。

2. 缩略词

分类	缩略词	全称	含义说明
协议相关	UDS	Unified Diagnostic Services	统一诊断服务，ISO14229协议定义的汽车通用诊断服务
BSW层模块	DCM	Diagnostic Communication Manager	诊断通信管理器，负责接收并响应诊断仪数据请求
BSW层模块	DEM	Diagnostic Event Manager	诊断事件管理器，处理诊断事件信息及相关数据
BSW层模块	CANTP	CAN Transportation	CAN传输层/模块，实现标准CAN传输层协议
诊断标识	DID	Data ID	数据标识
诊断标识	SID	Service ID	服务标识
诊断标识	DTC	Diagnostic Trouble Code	故障码
诊断标识	RID	Routine Control ID	例程标识

3. UDS简介

• 协议定位：
  • 应用层协议：位于OSI模型第5-7层，基于ISO14229协议；
  • 多总线支持：可在CAN、LIN、Flexray、Ethernet和K-line等不同汽车总线上实现。
• 协议分层：
  • 上层协议：ISO14229定义应用层服务；
  • 中层协议：ISO15765和ISO13400规定传输层和网络层；
  • 底层协议：各总线标准的数据链路层和物理层协议。
• 诊断交互流程：
  • 请求路径：诊断仪(tester)→应用层→网络层→链路层→电平信号→总线→ECU；
  • 响应路径：ECU→网络层→数据链路层→诊断仪各协议栈解析→显示结果；
  • 核心模块：DCM和DEM模块配合应用程序处理诊断请求与响应。

4. 诊断数据传输过程

• 基本流程：由Tester发起诊断请求，发送SID+数据；ECU根据SID判断响应方式。
• 响应类型：
  • 肯定响应：SID+0x40+数据；
  • 否定响应：7F+SID+NRC（否定响应码）。

（1）UDS常用服务标志符

服务类别	服务名称	SID	功能说明
诊断和通信管理	会话控制	10	切换ECU诊断会话（如Default/Extended/Programming会话）
诊断和通信管理	安全机制	27	种子-密钥验证，解锁高权限操作（如刷写、清除关键DTC）
诊断和通信管理	通信控制	28	开启/关闭ECU某条总线的通信（如关闭CAN报文发送）
诊断和通信管理	握手协议	3E	维持诊断会话连接（防止ECU退出诊断模式）
数据传输功能	数据读取	22	通过DID读取ECU特定数据（如ECU版本、传感器值）
数据传输功能	内存操作	23/3D	23服务读内存地址数据，3D服务写内存地址数据
数据传输功能	动态定义	2C	动态组合多个DID数据，实现自定义数据读取
存储数据传输	故障码管理（清除）	14	清除ECU存储的DTC及相关状态
存储数据传输	故障码管理（读取）	19	读取DTC列表、DTC状态、冻结帧等信息
输入输出控制	IO控制	2F	控制ECU IO端口或外设状态（如点亮LED、驱动电机）
上下装功能	数据传输（下载/上传）	34-38	34请求下载、36传输数据、37请求退出，实现ECU程序刷写或数据上传

（2）应用案例（车门控制器仿真）

• 安全控制机制：
  • 会话分级：Default session（受限权限）→ Extended session（更多数据）→ Programming session（Flash刷写权限）；
  • 安全验证：采用27服务，通过种子-密钥机制验证上位机合法性。
• 数据操作演示：
  • 读取示例：成功读取ECU序列号（22服务）；
  • 通信控制：通过28服务关闭/恢复ECU通信。
• 故障码管理：
  • 注入电压过低故障码（19服务读取）；
  • 清除故障码（14服务）。
• 协议实现特点：
  • 传输层依赖：可在CAN/以太网等不同总线上实现（UDSonCAN/UDSonIP）；
  • AUTOSAR架构：应用层（DCM+DEM模块）、传输层（CAN TP报文重组）、数据链路层（CAN IF驱动交互）。

5. AUTOSAR架构下的诊断模块

（1）通信描述

• PDU数量与长度：系统中有5条用于诊断通信的IPDU，每条PDU长度固定为8字节。
• 帧对应关系：每个PDU都有对应的诊断帧（Diagnostic Frame）在通信系统中。
• 诊断帧类型：
  • Physical Request：诊断仪发送给ECU的物理请求帧；
  • Physical Response：ECU返回给诊断仪的物理响应帧；
  • Functional Request：诊断仪通过功能寻址发送的功能请求帧（多ECU同时响应）。
• 配置检查要点：
  • 收发配置验证：在系统描述阶段需确认目标ECU（特别是VCU）是否正确配置了诊断报文的收发功能；
  • 自动生成机制：若配置无误，BSW生成阶段工具可自动生成相关通信配置；
  • ODX文件支持：工具支持ODX文件导入，但当前版本该功能尚不完善。
• PDU生成机制：
  • 自动生成条件：当系统信息描述配置完全正确时，BSW生成工具会自动创建所需PDU；
  • PDU数量计算：针对3种诊断报文（2条Request+1条Response），考虑IF/TP层连接后共需生成9个PDU；
  • 关联关系验证：需特别检查PDU与DCM（诊断通信管理器）之间的连接关系。

（2）BSW配置

① 函数请求PDU配置

• 路径连接：从CAN IF到CAN TP，再到PduR，最后到DCM模块；
• 长度特性：各连接段的PDU长度均为8字节。

② 物理响应PDU配置（Physical Request PDU 路径与模块创建）

• 传输方向：诊断仪向ECU发送的诊断请求；
• 逆向路径：从CAN IF到CAN TP，再到PduR，最后到DCM模块；
• 模块检查：需在COM Stack的CAN Modules下确认诊断相关模块是否建立完成；
• 创建步骤：首先创建缺失的CAN TP模块。

③ DCM与DEM模块创建

• 创建位置：在BSW Modules下的Service文件夹中创建；
• 模块关系：DEM模块可与DCM模块放在同一个ARXML文件中描述；
• 创建结果：完成诊断相关的所有模块建立（DCM/DEM/CAN TP）。

④ 配置思路与模块关系

• 核心模块：DCM与DEM是处理应用层协议的核心；
• 数据传输流：DCM通过PduR将PDU传给CAN TP进行包重组→CAN TP调用CAN IF将报文发送到CAN总线；
• 配置顺序：在CAN IF模块已建立的前提下，优先配置CAN TP模块。

⑤ CAN TP模块配置

• 配置选项：
  • Burst Q Sites：可保持默认不配置；
  • RB Page Confirmation：建议先失能；
  • 读参数API：默认不使用；
• 重点区域：配置完成后需重点关注CAN TP Channels配置。

⑥ CAN TP Channel配置

• 命名规范：通道建议命名为UDS；
• 模式选择：选择全双工模式；
• 关键参数：
  • Main Function Period：设置为1ms处理周期；
  • Max Count：选择4条通道以留有余量；
• 报文对应：
  • 需要配置2个Rx NSDU（物理寻址和功能寻址）；
  • 1个Tx NSDU（对应Physical Response）。

⑦ TX SDU配置

• 时间参数：
  • NAs：设置为1.0秒；
  • NBs：设置为1.0秒；
  • NCs：设置较小值；
• 功能配置：
  • Transmit Cancellation：建议启用；
  • Addressing Format：选择标准ID；
  • Padding Activation：建议启用；
• 类型选择：需选择CAN TP Physical类型；
• 引用设置：需正确选择CAN TP Tx NSDU Reference。

⑧ 物理请求PDU配置

• SDU来源：从DCM模块通过P-DUR传输过来的SDU数据；
• 筛选目的：需要通过TP层的channel使用N-PDU发送出去；
• 筛选方向：首先关注response方向的发送流程；
• 筛选步骤：
  1. 响应筛选：因为是发送方向，首先筛选response响应；
  2. 数据确认：确认从P-DUR过来的SDU数据；
  3. 配置准备：需要为SDU配置对应的N-PDU；
• 传输路径：从TB模块到IF模块的physical response；
• 网络隔离：由于TP层存在网络隔离机制；
• 特殊处理：需要为数据创建RXFCN-PDU；
  • 创建原因：TP层的网络隔离机制要求；
  • 选择标准：根据实际需求选择合适的配置参数；
  • 配置要点：确保与上层模块的通信协议匹配。

⑨ 应用案例（例题:物理请求配置）

• 配置流程：
  1. 上位机发送physical request到ECU；
  2. 配置txn pdu和sdu；
  3. 创建两条rx ns du；
• 关键参数：
  • Nbl选择0；
  • Ncr选择1；
  • Addressing format根据实际CAN ID类型选择standard；
  • Padding activation选择CAN TP on；
  • STmin时间参数设置为0.002；
• 注意事项：
  • 带星号的ID不进行配置，等待生成阶段工具自动配置；
  • 命名需对应functional/physical类型；
  • 工具配置涉及arxml文件写入，速度较慢。
• NSDU配置：
  • 决定CAN TP将重组后的network PDU传送给上层哪个节点；
  • 上层将functional request发送给PDUR；
  • 需要选择CAN TP to PDUR；
• NPDU配置：
  • 链接CAN IF与CAN TP模块；
  • functional接收只需配置rx n pdu；
  • 需要准确选择对应模块。

⑩ 应用案例（例题:物理响应配置）

• 响应配置：
  1. 配置txf CN pdu作为物理网络传输层响应；
  2. 选择physical response（CAN TP to CAN IF）；
  3. 需要配置对应的SDU（PDUR到CAN TP）；
• 网络管理：
  • 可为functional通道配置网络管理；
  • 需要添加txf CN pdu；
  • 若无相关ECU可不配置；
• 概念区分：
  • 需清楚区分OSI模型中SDU和NPDU的概念；
  • SDU是服务数据单元；
  • NPDU是网络协议数据单元；
  • 理解概念后配置PDU链接会更简单；
• 配置关系：
  • PDUR连接CAN TP与DCM模块；
  • 数据流向：上位机→ECU节点→CAN TP→PDUR；
  • 可参考J1939的TP层进行类比学习；
• 后续步骤：
  1. 完成CAN TP配置后；
  2. 需要继续配置PDUR模块。

⑪ PDU配置

• 模块连接：数据由PDUR模块将CAN TP与DCM进行连接，需要配置PDUR模块；
• 声明检查：进入PDUR模块后，首先检查BSW Modules中是否有CAN TP的使用声明，若无声明需手动添加；
• 参数需参考标准配置：特别注意新创建的CAN TP模块是否被正确引用。

⑫ 路径配置

• 绝对路径验证：必须检查模块对应的绝对路径是否正确，确认路径指向新建的CAN TP模块；
• 路径错误会导致通信失败；
• DCM检查：完成CAN TP检查后需同步验证DCM配置。

⑬ 路由表配置

• 自动生成验证：检查工具是否自动生成双向路由（CAN TP→DCM方向、DCM→CAN TP方向）；
• 手动配置要点：
  • 若未自动生成需手动配置；
  • 配置内容必须与CAN通信配置完全一致；
  • 需要建立PDUR与DCM的SDU双向传输通道。

⑭ 配置完成验证

• 最终检查项：
  1. CAN TP的SDU正确传输至DCM；
  2. DCM的SDU通过PDUR返回至CAN TP；
  3. 确认双向通信链路完整建立；
• 配置完成标志：成功实现PDU路由功能即表示配置完成。

⑮ UDS应用层配置模块（DCM模块配置）

General配置项

• 模块构成：包括General配置项和Config Set配置项，需先建立UDS协议应用层基础概念；
• 配置建议：建议通过网文和标准资料充分理解UDS协议的服务、元素和关键词；
• 关键参数：
  • response all request：选择FALSE；
  • task time：设置为0.001秒（1毫秒）；
  • vap I：选择FALSE；
  • dcmv in reference：需在config set配置完成后引用。

RB General配置项

• 重要配置项：
  • NRC控制：先进行negative response code控制；
  • 功能开关：
    • application called request.required on request reception：关闭；
    • tx confirmation：关闭；
    • confirm for dsd：暂时关闭；
  • 非必要项：
    • ecu reset time：可不定义；
    • OS counter ID：默认使用第一个counter ID；
    • count them.macro：暂不定义；
  • 队列配置：
    • 选择cyclic count；
    • dcm rb query of request enabled：使能队列；
    • rte support：选择TRUE；
    • storing enabled：选择TRUE。

DSL配置

• 五大配置选项：
  • DSD：Diagnostic Server Dispatcher，连接DSL与DSP的桥梁；
  • DSL：Diagnostic Session Layer，负责数据流、诊断状态和时间参数管理；
  • DSP：Diagnostic Service Processor，处理诊断服务；
  • Page Buffer Config：处理page buffer；
  • Processing Conditions：涉及DCM模式管理。

DSL Buffer配置

• Buffer作用：用于DCM数据交互，涉及CAN发送和接收；
• 配置参数：
  • 命名为"ud son can rx"；
  • buffer size：根据MCU RAM空间配置（示例给1024）；
  • dcm dsl dag response maximum number response pad：设置为5。

DSL Protocol配置

• 连接配置：
  • 协议类型命名为"uds on CA"；
  • 最大response size：设置为20；
  • priority：选择1；
  • trans type：保持默认；
  • paint on trans to boot：选择FALSE；
  • P2/P2*时间参数：给0.2（需根据实际场景调整）；
  • protocol rx buffer：选择之前配置的"ud son can rx"；
  • SID table：可暂用默认service table。

Connection配置（Main Connection）

• dsm dsl protocol rx tester source address：设置为0（根据实际地址配置）；
• comm channel：使用CAN network channel。

二、配置连接

1. 接收functional和physical请求

• 功能请求通道：在main connection中需要配置functional request通道，type选择functional type；
• 物理请求通道：同时需要增加protocol rx的物理通道，用于接收physical request；
• PDU连接：这里的PDU是DCM模块与TANtb模块连接的SDU，需要选择从PDUR到DCM模块的PDU。

2. 配置physical通道

• 通道类型选择：必须明确选择physical类型；
• 方向配置：配置从PDUR到DCM模块的PDU；
• 注意事项：需要特别注意选择physical.response.dcm two p dur。

3. 配置发送protocol

• 物理通道建立：需要配置一条physical的发送通道；
• 完成标志：完成DCM DC DSL配置后，即建立了UDSON CAN的所有配置内容。

三、总线上UDS协议的实现

• 协议投射：整个UDS协议需要映射到特定总线；
• 映射方法：在DSL的protocol下面进行分组映射；
• 实现位置：通过总线配置实现协议的具体传输路径。

四、dcm dsd的配置

1. 展开service table

• 初始配置：创建DCM模块时默认生成table 0，作为服务配置的基础框架；
• 服务创建位置：在table 0下的dcm dsd services中创建UDS协议支持的具体服务。

（1）诊断会话控制配置示例

• 命名规范：将service table命名为UDS协议标准名称，show name需简洁（如删除"dsd service"前缀）；
• 关键配置项：
  • SID处理函数：配置Dcm diagnostic session control函数，处理服务请求；
  • 服务ID格式：16进制显示（如session control对应），十进制需填写16；
  • 子服务支持：session control等服务需开启subfunction支持（设为true）；
• 会话类型创建：
  • default session：session for boot选no boot，level=1，P2=0.05，P2* server max=5；
  • programming session：system boot，level=2；
  • extended session：no boot，level=3；
• 配置技巧：
  • 使用ctrl+空格调出提示时必须切换至纯英文输入法；
  • 应用层检查函数可为空，表示不进行额外状态检查；
  • mode rule reference可复用通用准则，未建立时暂不配置。

五、dsd配置讲解

• 基础服务集：必须包含session control、security access、communication control等核心服务；
• 关键配置要点：
  • 每个服务需明确适用的session和security level；
  • 函数声明需准确（如routing control需声明Dcm routing control函数）；
  • service ID必须严格匹配UDS协议定义；
• 调试建议：
  • 不确定参数可参考标准工程模板；
  • 优先完成基础配置，debug阶段再针对性修正；
  • 扩展会话等特殊功能需引用对应的security level。

六、DSP配置项

• 功能定位：DSP(Diagnostic Service Process)是DCM模块的核心部分，负责处理诊断服务的配置项；
• 配置内容：主要配置服务数据、控制对象、会话模式、安全等级等UDS管理元素；
• 配置依据：需要根据实际诊断设计完成，通常由诊断工程师建立诊断数据库文件；
• 数据定义：在诊断文件中定义ECU支持的UDS服务、DID、RID等操作对象。

1. DSP清除DTC

• 功能关联：与清除DTC服务（14服务）直接相关；
• 配置选项：
  • 可配置清除DTC前的检查函数；
  • 可配置对应的检查规则(rule)；
• 注意事项：需要与DSD中建立的服务相匹配才能被Tester使用。

2. 通信控制

• 管理方式：
  • 可一次性管理所有通道；
  • 可单独设置(Setting)特定通道；
  • 可管理单独节点(Node)；
• 功能实现：
  • 支持通信通道开关控制；
  • 支持PDU组的开启/关闭；
• 配置原则：根据实际使用场景开放相应功能并正确引用。

3. 授权

• 功能作用：提供路由执行前的校验选项；
• 校验条件：
  • 可声明需要符合的RAW条件；
  • 可设置安全等级要求；
  • 可配置会话规则限制；
• 应用场景：常用于需要安全检查的Routing配置。

4. Ctrl DTC设置

• 配置内容：
  • 可启用/禁用Function功能；
  • 可配置记录(Record)选项；
  • 可设置Enable Mode的引用；
• 实现方式：通过右键新增功能项进行配置。

5. DID配置

• 数据类型定义：
  • 定义DID所属的数据类型；
  • 以真空泵压力(Vacuum Pump Pressure)为例；
• 基本属性：
  • 配置是否需要Init Function；
  • 设置大小端(Endianness)；
  • 定义数据Size和类型；
• 接口配置：
  • 提供ASW层访问的Client-Server接口；
  • 可配置Block ID引用；
  • 支持Data Redefinition功能。

6. DID信息配置

• 功能支持：
  • 配置DID支持的读写功能；
  • 设置对背后IO的单独控制；
• 高级控制：
  • Must Control功能支持；
  • Freeze Current State支持；
  • Reset to Default功能支持；
• 实现方式：通过展开具体DID项进行详细配置。

7. DSP内存配置

• 功能用途：定义按地址读取数据时的内存范围；
• 配置要求：需要明确指定内存地址范围；
• 关联功能：与内存读取类诊断服务（23服务）直接相关。

8. 周期性DID传输配置

• 功能用途：支持周期性上传DID数据；
• 配置方式：在此配置项中设置传输参数；
• 实现条件：需要底层通信协议支持。

9. PID配置

• 配置内容：
  • 设置Buffer Size；
  • 定义Control ID；
• 操作方法：通过右键使用相关功能；
• 关联功能：与Request Control服务（2F服务）相关。

10. 路由配置

• 参数设置：
  • 配置Start/Stop支持；
  • 定义路由参数；
• 接口提供：配置后DCM模块会提供应用层调用接口；
• 实现方式：需要建立完整的路由参数配置。

11. 安全和会话配置

• 功能范围：涉及Session Control（10服务）和Security Access（27服务）；
• 配置内容：定义需要引用的安全元素；
• 管理对象：配置会话和安全访问相关参数。

12. 车辆信息配置

• 功能用途：定义整车基础信息用于车辆识别；
• 配置内容：设置VIN等车辆标识信息；
• 应用场景：用于诊断仪识别车辆。

13. ECU复位配置

• 功能关联：与UDS复位服务（11服务）相关；
• 配置内容：
  • 声明支持的复位类型；
  • 设置复位相关参数；
• 扩展功能：配置Read DTC相关工作参数。

七、DCM模块配置总结

• 核心配置项：
  • DSD：配置诊断服务（如10/22/27服务）；
  • DSL：配置UDS通信链路（如PDU连接、时间参数）；
  • DSP：配置UDS基础服务元素（如DID、DTC、内存范围）；
• 配置原则：
  • 严格遵守UDS标准（ISO14229）；
  • 依据诊断数据库文件提供的信息；
  • 保持与DSD配置的协同性；
• 注意事项：配置量较大，需抓住各配置项的核心功能定位。

八、dm模块配置

1. components配置

• 服务实体定义：在ASW层为每个DDC创建的服务实体，需要定义每个component对应的DTC测试；
• 状态传递机制：
  • 故障处理：当component对应的DTC测试失败时，需配置是否使用port传递状态；
  • 回调函数：可定义回调函数，当component失败时决定是否使用ASW层的port；
• 代码生成：配置完成后生成代码，会在ASW层的DEM模块中看到这些port，用于应用层与其他模块交互。

2. 消抖机制配置

• 消抖目的：
  • 提高正确率：提高故障确定的正确率；
  • 减少误报：通过消抖机制减少误报情况；
• 消抖类型：
  • 计数器消抖：基于计数器的消抖方式(Counter Base)；
  • 时间消抖：基于时间的消抖方式(Time Base)；
• 实现机制：
  • 模板类应用：定义的元素作为模板类，可通过DC event parameter引用；
  • 故障判定：当故障出现时，记录上报次数和持续时间，与预设值对比后确定是否上报；
• 配置建议：
  • 名称提示：配置名称提供良好提示；
  • 查看说明：配置时注意查看quick info中的提示内容。

3. dtc类别配置

• 基础类选择：所有使用的DTC都是counter base的class，以0d零幺这个base class为例进行展示；
• 行为定义：
  • debounce行为：需要定义debounce freeze和reset两种类型；
  • 步长设置：需要定义counter的decrement step和increment step size；
  • 阈值设定：需要配置threshold值；
  • 状态存储：counter storage可选择true或FALSE，决定是否储存counter状态；
• 时间基频：
  • 基频选择：可以1毫秒或更短时间作为处理基频；
  • 配置方式：未声明时可右键展开创建子元素查看；
  • 辅助工具：quick info可帮助建立配置模式和提供配置提示。

4. dtc属性配置

（1）dtc的存储老化机制和snapshot功能

• 老化机制原理：在特定周期后，若相关DTC故障恢复，需经过一定时间和状态验证才能清除。老化代表故障消除的验证过程。
• snapshot功能：故障发生时记录相关数据（如发动机转速等），后续读取DTC时可上传故障冻结帧和整车快闪数据供分析人员使用。
• 配置要求：需明确定义记录哪些数据，包括DM存储等功能都需要在此配置。

（2）配置选项：aging circle counter threshold

• 支持开关：首先需配置是否支持DTC老化功能。
• 周期阈值：定义经过多少个操作周期后，DTC可以退出（需设置具体周期数值）。
• 优先级设置：需配置DTC的优先级等级。
• 故障类型：可选择故障类型为"疑问故障"（significant fault）或"偶发故障"等不同类型。

（3）配置选项：freeze frame records

• 存储开关：需配置是否存储冻结帧数据。
• 记录容量：定义最大支持的冻结帧记录数量。
• 数据引用：可引用aging circle等参数（但aging operation circle需在general部分定义）。

（4）配置选项：extended data class

• 周期定义：操作周期可理解为不同整车状态周期，包括：上下电周期、休眠周期、通讯故障恢复周期；
• 扩展数据：需引用需要在DTC发生时记录的扩展数据类，这些数据会和冻结帧一起被记录；
• 引用方式：只需将需要记录的内容引用到配置中即可。

（5）配置选项：dem的memory

• 内存类型：需要为attributes添加DEM内存配置，包括：主内存（primary memory）、镜像内存（mirror memory）。

（6）dem的ddc配置：功能组严重度、标识和替代ddc

• 功能配置：在DEM的DDC中需要明确定义：功能组严重度、标识信息、替代DDC（alternative DTC）；
• 属性引用：需在DDC中引用之前创建的DTC属性选项。

5. dtc配置

• 命名规范：需要为DTC进行命名，并确定其是否为functional的一个字节；
• 信息展示：需要展示严重度信息和处理方式；
• 关键属性：DDC值、Alternative DTC、OBD相关属性；
• 参数引用：必须引用在DC attributes中定义的参数和内容。

6. dm事件参数配置

（1）参数组构成

• 包含要素：Component优先级、失败次数、来源种类、存储方式、描述和汇报行为时机；
• 引用关系：需要引用已创建的component和DTC元素；
• 类型定义：需注意定义引用类型。

（2）配置层级

• 汇报对象定义：需明确DTC汇报对象是在BSW层还是ASW(SWC)层；
• 展开配置：Callback定义、Debounce algorithm class引用、Event class引用；
• 配置要点：按照诊断数据库要求逐步创建、注意基础概念的串联、细心完成每个配置项。

7. general配置分类

（1）general的配置分类概述

• 分类依据：根据功能特性将general配置分为四大类型；
• 配置特点：相较于config set，general配置内容多而杂，需要结构化处理。

（2）功能型的配置：call back类型

• 定义方式：需要手动定义call back函数，在集成阶段进行补充；
• 触发机制：当特定条件满足时自动调用预定义的函数；
• 实现选择：可调用用户自定义函数或系统内置函数实现功能；
• 配置建议：根据实际需求选择开启/关闭对应功能项。

（3）数据定义型的配置

• 核心功能：定义需要记录的数据和状态信息；
• 典型配置：extended class基础信息、free frame相关数据、DDC运行状态数据；
• 应用场景：为诊断事件提供数据存储结构。

（4）存储型的配置

• 管理对象：非易失性数据（NvM管理）；
• 关键内容：DTC故障码、冻结帧状态、内存分配设定；
• 模块联动：需与NvM模块建立关联配置。

（5）模式型的配置

• 配置要素：存储条件（storage condition）、触发条件、响应动作；
• 功能说明：定义DDC在特定条件下的行为模式。

（6）与UDS服务相关的配置：call back类型

• 实现方式：通过状态变化触发回调函数；
• 函数类型：支持用户手写函数或系统内置函数；
• 配置原则：按需开启功能，避免不必要的性能开销。

（7）dem clients配置

• 核心功能：创建响应诊断事件的客户端；
• 关键配置：
  • dem clients use rte选项：开启时所有DEM交互必须通过RTE执行，关闭时允许直接交互；
  • 数据元素class定义；
• 配置建议：根据系统架构需求选择RTE交互方式。

（8）数据元素配置

• 定义内容：时间状态（年月日）、计数器（counter）、扩展类数据记录（extended class data record）、故障挂起计数器（fault pending counter）、供电电压（supply voltage）；
• 配置方法：确定data size、设置port传输选项；
• 应用接口：通过ASW-DM接口传递数据。

（9）诊断DID配置

• 功能说明：为DTC提供数据引用支持；
• 创建要素：DID名称引用、data elements元素关联；
• 配置特点：创建过程相对简单直接。

（10）事件内存配置

• 内存类型：mirror memory、primary memory、user defined memory；
• 配置要求：仅需声明即可，无需复杂操作。

（11）扩展数据冻结帧配置

• 功能用途：DTC发生时记录系统快照供分析；
• 配置原则：按需添加、后续可在DDC中引用；
• 引用关系：三类数据存在相互引用，需注意创建顺序；
• 最佳实践：先创建数据元素，再建立引用关系。

（12）NvM Block配置

• 必要性：DEM管理大量非易失性数据；
• 关键配置：NvM block ID定义、DEM与NvM模块联动配置；
• 对应关系：要求block一一对应确保断电存储。

（13）DTC分组配置

• 分组类型：powertrain（动力总成）、chassis（底盘）、body（车身）；
• 引用机制：DTC通过引用分组声明功能归属。

（14）运行周期配置

• 功能关联：与DTC老化机制相关；
• 周期定义：ECU上下电周期、运行时间周期；
• 实现方式：生成周期函数、在适当位置调用开始/结束函数。

（15）RB General配置

• 功能特性：实现DEM模块功能剪裁；
• 配置建议：初始保持默认状态、参考quick info和帮助手册、特殊设计时检查相关配置项；
• 最佳实践：配置前通读所有功能说明。

（16）DEM General主配置

• 配置层级：子配置选项的上层配置；
• 配置内容：基础DEM支持项选择、UDS协议类型指定（ISO 14229）；
• 注意事项：不要遗漏主配置项的设置。

九、内容总结

1. UDS协议基础概念

• 协议定义：本章介绍了用于汽车诊断的UDS协议（Unified Diagnostic Services）；
• 数据传递逻辑：详细讲解了该协议的数据传输机制和通信原理；
• 工具演示：使用CANoe工具展示了该应用层协议的实际功能和应用场景。

2. AUTOSAR架构下的配置分析

• 分层配置：基于OSI网络模型，配置分为四个层级：应用层、数据传输层、数据链路层、物理层；
• 配置参考：传输层以下的配置可参考CAN通信部分的知识。

3. 重点配置模块

• 核心模块：CAN TP（传输协议层）、DCM（诊断通信管理器）、DEM（诊断事件管理器）；
• 学习建议：
  • DCM和DEM配置较为复杂；
  • 需要查阅更多相关资料才能深入理解；
  • 建议多阅读Quick Info和帮助手册内容。

4. 学习资源建议

• 推荐资料：系统Quick Info文档、官方帮助手册；
• 学习方法：
  • 反复阅读相关资料；
  • 通过实践加深理解；
  • 重点关注DCM和DEM模块的配置细节。

十、知识小结

知识点	核心内容	考试重点/易混淆点	难度系数
UDS协议基础	统一诊断服务协议定义、功能架构及通信流程（ISO14229）	服务类型区分（6大类SID，如10会话/22读DID/19读DTC）	⭐⭐⭐
诊断会话控制	Default/Extended/Programming三种会话模式及安全机制（27服务种子-密钥）	会话切换条件与安全种子验证流程	⭐⭐⭐⭐
数据读写服务	DID标识读写（22/2E服务）、故障码读取（19服务）	物理寻址（单ECU响应）与功能寻址（多ECU响应）的区别	⭐⭐⭐
故障管理机制	DTC生成规则、冻结帧记录、老化计数器	消抖算法（时间/计数双机制）的实现逻辑	⭐⭐⭐⭐
通信层实现	CAN TP分段传输、ISO15765传输层协议	N_PDU（网络PDU）与N_SDU（网络SDU）的映射关系	⭐⭐⭐⭐
AUTOSAR集成	DCM-DEM模块分工（DCM处理请求/DEM管理DTC）、诊断事件处理流程	NVBlock与DTC存储的关联配置	⭐⭐⭐⭐⭐
安全访问机制	27服务安全等级、密钥交换算法	否定响应码（NRC 0x22权限不足/0x33密钥错误）	⭐⭐⭐⭐
演示案例	CANoe仿真：会话切换/DID读写/DTC注入	物理响应（带ECU地址）与功能响应报文的差异	⭐⭐⭐