【AUTOSAR-DCM】-15.1-UDS/OBD诊断如何支持多组物理/功能寻址CANID,响应CANID

最新推荐文章于 2025-06-19 23:38:10 发布
最新推荐文章于 2025-06-19 23:38:10 发布
阅读量2.6k 收藏 9
点赞数 3
CC 4.0 BY-SA版权
分类专栏： Autosar_BSW高阶配置 # DCM Autosar 文章标签： autosar
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qfmzhu/article/details/122839580
该博客介绍了如何配置Autosar BSW模块来支持多组UDS/OBD诊断CAN ID，包括经典CAN标准帧、扩展帧和CANFD帧的不同寻址方式。通过在/Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRows路径下创建多个"DcmDslProtocolRow"和"DcmDslConnection"，以满足项目中不同类型的诊断CAN ID需求。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

案列背景：

假设有以下多组UDS/OBD诊断CAN ID，该如何配置Autosar BSW模块呢？

==>UDS诊断CAN ID：

第一组：功能寻址ID：0x780；物理寻址ID：0x781；响应ID：0x782(上述ID都是“Classic经典CAN标准帧”)；

第一组：功能寻址ID：0x780x；物理寻址ID：0x781x；响应ID：0x782x(上述ID都是“CANFD扩展帧”)；

了解本专栏 订阅专栏 解锁全文
UDS/OBD诊断：多组物理/功能寻址CANID与响应CANID的嵌入式支持
PixelPusher的博客
09-11 780
在诊断过程中，诊断工具向汽车控制单元发送请求消息，控制单元根据CANID识别请求，并发送相应的响应消息。总结而言，通过动态CANID配置和适当的处理逻辑，嵌入式系统可以轻松地支持多组物理/功能寻址CANID，并实现相应的请求和响应功能。这样，诊断工具可以根据需要发送不同类型的请求消息，并正确地接收到相应的响应消息，以此实现对车辆进行全面的诊断和故障排除。此外，确保在使用诊断功能时遵守相关的法律法规和安全准则。在某些情况下，诊断工具需要发送具有不同物理或功能寻址的请求消息，同时期望接收相应的响应消息。
AUTOSAR从入门到精通-浅谈车载自诊断系统(OBD)
getusushu的博客
12-13 385
OBD是英文On-Board Diagnostics的缩写，中文翻译为“车载自动诊断系统”。这个系统将从发动机的运行状况随时监控汽车是否尾气超标，一旦超标，会马上发出警示。当系统出现故障时，故障(MIL)灯或检查发动机(Check Engine)警告灯亮，同时动力总成控制模块(PCM)将故障信息存入存储器，通过一定的程序可以将故障码从PCM中读出。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。
Autosar诊断系列介绍17 - 物理寻址及功能寻址详解
initiallizer的博客
07-03 7956
两种寻址方式分别是什么意思？有什么区别？对应哪些使用场景等，下面我们就逐一介绍，保证大家看了就能理解。
MCAL学习（6）——诊断、DCM
最新发布
weixin_70362088的博客
06-19 1046
汽车诊断就是通过汽车总线（CAN LIN Eth）来进行诊断会话，大部分通过CAN总线通讯进行请求与响应。
AUTOSAR BSW OBD Config 配置
汽车电子电气
07-31 1188
文档中包含了详细的配置步骤、参数设置和示例屏幕截图。
AUTOSAR从入门到精通-浅谈车载自诊断系统(OBD)（二）
getusushu的博客
12-12 247
OBD是On Board Diagnostics的缩写，意思是：车载自动诊断系统。这套系统能在汽车运行过程中实时监测发动机电控系统和车辆的其它功能模块的工作状况。如果有发现工况异常，则会根据特定的算法判断出具体的故障，并以诊断故障代码（DTC，Diagnostic Trouble Codes)的形式存储在系统内的存储器里。系统自诊断后得到的有用信息能够为车辆的维修和保养提供帮助，维修人员可以利用汽车原厂专用仪器读取故障码，从而可对故障进行快速定位，以便于对车辆的修理，减少人工诊断的时间。
AUTOSAR——DCM&DEM (UDS&OBD)
usstmiracle的博客
10-10 1万+
1.术语与缩写 术语 DCM Diagnostic Communication Mannger DEM Diagnostic Event Mannger UDS Unified diagnostic services OBD On-Board Diagnosis DSD Diagnostic Service Dispatcher DSL
【AUTOSAR-CanTp】-2.10-复用UDS/OBD诊断物理/功能寻址/响应CAN_ID--Extended addressing扩展寻址
「汽车电子助手」的博客
02-10 2754
背景介绍：共36页精讲（Extended addressing扩展寻址：附配置完成后的诊断交互LOG） 每组UDS/OBD诊断ID中，功能寻址ID和物理寻址ID相同； 两组UDS/OBD诊断ID中，复用同一个响应ID。 手把手教你创建一个自定义的物理寻址和功能寻址经典CAN (UDS/OBD)诊断ID。从CanIf模块 --> CanTp模块 --> PduR模块--> DCM模块完整的配置。 目录 1 预设条件 2 EcuC模块配置 3 CanIf模块配置 4 CanTp模
【DBC专题】-12-不同类型报文(应用/诊断/网管/测量标定)在DBC中配置，以及在Autosar各模块间的信号数据流向
「汽车电子助手」的博客
03-15 1万+
1)Autosar中不同类型报文(App应用，UDS/OBD诊断，NM网络管理报文，XCP测量标定)的信号数据流向； 2)CAN DBC中，不同的Attribute属性决定不同类型报文（APP应用报文，UDS/OBD诊断报文，NM网络管理报文，XCP报文）。
【AUTOSAR-CanTp】-2.2-配置channel：基于经典CAN2.0标准帧诊断ID --Extended addressing扩展寻址
「汽车电子助手」的博客
01-26 1194
共18页精讲：手把手教你创建一个自定义的UDS/OBD物理寻址和功能寻址诊断ID(Extended addressing扩展寻址)。 <--返回「Autosar_BSW高阶配置」总目录--> <--返回「Autosar_BSW高阶配置」专栏主页--> <--返回「个人博客」首页--> 1 预设条件 2 EcuC模块配置 3 CanIf模块配置 4 CanTp模块配置 ...
AUTOSAR从入门到精通-统一诊断服务（UDS）（一）
getusushu的博客
12-27 1431
UDS协议即ISO14229,全称Unified Diagnostic Services，统一诊断服务；UDS不属于AUTOSAR，他们之间的关系，只是AUTOSAR提供了一些接口，可以与UDS进行集成；在AUTOSAR架构中，应用层（Application Layer）提供了一些标准的应用程序接口（API），可以与诊断协议进行集成，这些诊断协议之中就包括UDS协议。
道路车辆-统一诊断设备(UDS)-第3部分：控制区局域网络(CAN)实施的统一诊断服务(UDSonCAN)
07-10
道路车辆-统一诊断设备(UDS)-第3部分：控制区局域网络(CAN)实施的统一诊断服务(UDSonCAN)
AUTOSAR_DCM&DEM(UDS&OBD)
热门推荐
qq_25920091的博客
02-11 2万+
1.术语与缩写 术语 DCM Diagnostic Communication Mannger DEM Diagnostic Event Mannger UDS Unified diagnostic services OBD On-Board Diagnosis DS...
AutoSAR_BSW高阶 4. 全面解析OBD诊断服务
一直在水些技术小文
09-28 553
OBD是一种用于监测车辆性能和检测故障的标准化系统，包括OBD-I和OBD-II两种版本。Autosar_BSW高阶配置是Autosar标准的一部分，它定义了Autosar系统的高级配置选项。在这个配置中，OBD诊断服务的设置和参数是至关重要的，因为它们直接影响车辆的诊断功能和通信性能。
AutoSAR_BSW高阶 22.AUTOSAR Diagnostic Event Manager（DEM）：UDS/OBD DTC 增加功能抑制与预条件
一直在水些技术小文
10-07 270
AUTOSAR DEM 模块是 AUTOSAR 标准中的一个关键模块，负责管理和报告 ECU（Electronic Control Unit）中发生的故障和事件。DEM 模块可以监测各种类型的事件，包括传感器故障、通信故障、控制单元故障等。其中，DTC 是 DEM 模块的核心概念，用于标识和描述诊断事件。通过增加功能抑制和预条件，我们可以扩展 UDS/OBD DTC 的功能，提高诊断系统的灵活性和可定制性。这些功能允许我们根据特定条件来控制 DTC 的报告，以满足不同的市场需求和法规要求。
论文研读—基于 AUTOSAR 的汽车故障诊断系统的设计与实现
小胡同学的工程师学习之路
04-08 2853
看了几篇AutoSAR方面的研究生论文，感觉学到了不少东西，这里做个总结分享。今天分享这篇来自浙江大学 胡琦的《基于 AUTOSAR 的汽车故障诊断系统的设计与实现》。
【AUTOSAR-DEM】-2.2-给UDS/OBD DTC增加功能抑制/PreCondtion
「汽车电子助手」的博客
05-11 1901
点击返回「《Autosar_BSW高阶配置》总目录」 案例背景（共8页精讲）： 给UDS/OBD DTC增加功能抑制/Pre-Conditon。 接着“【AUTOSAR-DEM】-2.1-APP SWC设置UDS/OBD DTC检出和恢复”博文讲解，增加功能抑制/PreConditon：当12V供电电压低于6V，不报告Busoff UDS/OBD DTC（其它抑制条件可参照这一篇博文）。 目录 1 功能抑制/PreConditon的理论基础 1.1 DEM模块中的描述 1.2 API介绍 1.
非发动机控制器基于Autosar的OBD II诊断开发
qq_37315601的博客
08-17 2932
文章目录 前言 一、pandas是什么？ 二、使用步骤 1.引入库 2.读入数据 总结 前言 在整车里，除发动机控制器以外的其他主要控制器需要支持OBD II诊断时，都被称为 PrimaryECU。本文主要介绍PrimaryECU在已经开发完UDS诊断的基础上增加OBD II诊断 一、OBD II与UDS的区别？ 这里主要介绍在诊断开发上面OBD II与UDS的区别，此外为了方便描述，下文中用OBD指代OBD II协议。 1.OperationCycle...
UDS/OBD诊断协议在嵌入式系统中的物理层与功能寻址和响应CAN_ID的应用
FDSJRU的博客
09-23 341
综上所述，本文介绍了在嵌入式系统中实现UDS/OBD诊断协议的物理层通信和功能寻址以及CAN_ID的响应。通过合理配置CAN控制器和收发器，并根据不同的功能寻址和CAN_ID进行相应的处理，可以实现嵌入式系统中的诊断功能。CAN协议是一种快速可靠的串行通信协议，适用于嵌入式系统中的实时通信。在嵌入式系统中实现CAN通信，需要使用CAN控制器和CAN收发器，并配置相应的引脚和寄存器。以上代码示例中，根据CAN消息中的第一个字节作为CAN_ID，使用switch语句进行功能寻址，并调用相应的处理函数。
AutoSAR配置与实践（深入篇）10.7 诊断通信管理(DCM)
02-27
<think>好的，用户让我深入介绍一下AutoSAR中的诊断通信管理（DCM）模块，特别是10.7版本的内容。首先，我需要回顾一下之前用户询问过关于CI/CD的内容，可能用户是从事汽车软件开发的，现在转向更具体的AutoSAR配置问题，特别是诊断通信部分。用户可能已经具备一定的基础知识，现在需要更深入的实践指导，或者是项目中的具体应用需求。 首先，我需要确认AutoSAR DCM的基本概念和其在汽车电子架构中的位置。DCM主要负责处理诊断通信，包括UDS和OBD相关的协议，这是车辆诊断和故障排查的关键模块。用户提到的是10.7版本，可能是指特定的AutoSAR版本，比如经典平台（CP）的某个版本，需要注意不同版本之间的差异和更新内容。 接下来，用户可能想知道DCM的配置流程、与其他模块的交互、实际开发中的挑战以及最佳实践。需要分解DCM的功能结构，例如诊断服务处理、会话管理、安全访问等。同时，可能需要结合实际案例或配置步骤，让用户能够理解如何实施。 考虑到用户可能需要的是实践指导，我应该重点放在配置工具的使用，如ETAS ISOLAR或Vector的工具链，配置参数的具体设置，比如DID、DTC的配置，以及如何与DEM、ComM等其他模块集成。此外，可能还需要提到测试和验证的方法，例如使用CANoe或诊断工具进行诊断通信的测试。 另外，需要注意用户可能遇到的常见问题，比如诊断服务响应时间过长、安全访问失败、DTC上报不正确等，提供一些排查技巧或优化建议。同时，结合ISO 14229标准，说明DCM如何实现UDS服务，例如0x10会话控制、0x22读数据、0x2E写数据等。 最后，总结部分应强调DCM在整车诊断中的重要性，以及正确配置和优化对车辆维护和故障排查的影响。可能还需要提到未来趋势，比如Adaptive AutoSAR中的诊断管理变化，或者与OTA更新的结合，以满足用户对前沿技术的兴趣。 需要确保内容结构清晰，分点阐述，使用实际例子帮助理解，同时避免过于技术化的术语，或在必要时进行解释。确保回答符合用户要求的深入篇，不仅涵盖理论，还有实践中的注意事项和解决方案。</think>好的，我将以工程师视角为您深入解读AutoSAR中的**诊断通信管理模块（Diagnostic Communication Manager, DCM）**，重点聚焦配置实践中的核心问题。以下内容基于经典平台（CP）10.7版本，建议结合具体工具链（如Vector/ETAS）理解。 --- ### 一、DCM的核心定位 #### 1. 功能层级 ``` [整车诊断体系] ▲ ECU诊断通信(DCM) → 与DEM(诊断事件管理)、ComM(通信管理)深度交互 ▲ 物理层通信(如CAN/LIN/FlexRay)通过PDU Router接入 ``` - **核心标准**：ISO 14229-1 (UDS)、ISO 15765-3 (DoCAN)、ISO 15031-5 (OBD) #### 2. 关键能力 - **诊断服务处理**：实现UDS/OBD标准服务（如0x10会话控制、0x22读数据、0x2E写数据） - **会话与安全管理**：控制默认会话/扩展会话/编程会话的切换，管理安全访问层级（0x27服务） - **周期报文控制**：支持$0x2A$服务配置周期性DID上报 - **多路复用处理**：应对不同诊断请求的并发场景 --- ### 二、配置实践详解（以Vector工具链为例） #### 1. 服务映射配置 ```xml <!-- 示例：配置0x22读数据服务 --> <DCM-SERVICE> <SHORT-NAME>ReadDataByIdentifier_0x22</SHORT-NAME> <SERVICE-ID>0x22</SERVICE-ID> <DID-REF> <!-- 关联DID 0xF189对应的DEM数据 --> <DID-IDENTIFIER>0xF189</DID-IDENTIFIER> <DATA-ACCESS-MODE>READ</DATA-ACCESS-MODE> </DID-REF> </DCM-SERVICE> ``` - **关键参数**： - `SERVICE-CLASS`：区分物理/功能诊断 - `SUPPRESS-POS-RESPONSE`：是否抑制肯定响应 - `DID-REF`：绑定到具体数据标识符 #### 2. 时序控制配置 ``` [诊断响应时间约束] ▲ ├── P2Server_max（请求到响应的最大间隔）→ 典型值50ms ├── P2*Server_max（连续帧间隔）→ CAN总线常设5ms └── S3Server（服务器响应超时）→ 默认5000ms ``` - **实践技巧**：在`DcmDspRoutine`中配置时间参数时需考虑总线负载率，避免因超时导致诊断失败 #### 3. 安全访问配置 ```c /* 安全算法示例（种子生成+密钥验证）*/ void Dcm_SecurityAlgo(uint8 seed[4], uint8 keyReq[4]) { // Level 1算法：简单移位异或 keyReq[0] = (seed[0] << 1) ^ 0xAA; keyReq[1] = (seed[1] >> 1) ^ 0x55; ... } ``` - **安全层级**：通常设置2-3个安全等级（如解锁刷写需Level 3） - **防暴力破解**：需在Dem配置错误计数器（$0x31$服务），超过阈值锁定诊断 --- ### 三、典型问题排查指南 #### 1. 常见故障现象 | 现象 | 可能原因 | 排查工具 | |---------------------|-------------------------|------------------------| | 诊断仪无法连接 | ComM通道未激活 | CANoe + Trace窗口 | | 0x7F否定响应 | 服务未配置/权限不足 | DCM模块Log分析 | | 数据读取异常 | DID未绑定DEM数据源 | Davinci Developer映射检查 | #### 2. 性能优化建议 - **内存优化**：通过`DcmDsd`模块限制并行诊断请求数量 - **响应加速**：对高频服务（如0x22）启用缓存机制（`DcmCache`） - **总线负载**：使用`DcmDsp`配置抑制非必要周期报文 --- ### 四、与Adaptive AutoSAR的差异（对比CP） | 特性 | CP DCM | Adaptive DCM | |--------------------|-----------------------|-----------------------| | 通信协议 | 基于CAN/LIN | 支持SOME/IP、DoIP | | 服务部署 | 静态配置 | 动态服务发现 | | 安全机制 | 传统加密算法 | 支持TLS/HTTPS | --- ### 五、实战案例：OTA升级中的DCM作用 ``` [OTA流程] 1. 诊断会话进入编程模式（0x10 03） 2. 安全访问解锁（0x27 01） 3. 擦除内存（0x31 01 FF00） 4. 数据传输（0x34+0x36） 5. 校验并激活（0x31 01 F200） ``` - **关键点**：需在`DcmDsl`中特别配置编程会话的独立通信通道 --- 总结：DCM作为整车诊断的核心枢纽，其配置质量直接影响ECU的诊断能力。建议开发时严格遵循**V流程**：需求→服务设计→模块配置→HIL测试→实车验证，特别注意与DEM、BSW模块的交互验证。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车电子助手

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值