SAE J1939-73-2024 是重型车辆通信网络中诊断应用层的核心标准,定义了用于诊断信息报告、维修以及满足法规要求的车载诊断(OBD)服务的报文格式和协议。该标准基于高速CAN总线(ISO 11898-1),支持电子控制单元(ECU)之间的实时控制、信息交换和诊断数据交互,广泛应用于公路和非公路卡车、工程机械、农业设备等重型环境。
标准架构与诊断报文分类
该标准遵循OSI模型的应用层定义,通过参数组(PG)实现诊断功能。主要诊断报文(DM)覆盖从故障码报告到内存访问的完整范围。下表列出了关键诊断报文类别:
| 报文 |
名称 |
功能描述 |
| DM1 |
激活诊断故障码 |
实时广播当前激活的DTC,包含SPN和FMI |
| DM2 |
历史诊断故障码 |
记录之前激活但现在不活跃的DTC |
| DM3 |
清除/重置历史DTC |
用于清除DM2中存储的故障码和数据 |
| DM4 |
冻结帧参数 |
记录故障发生时的车辆状态快照 |
| DM5 |
诊断就绪1 |
提供OBD监测系统和就绪状态 |
| DM12 |
排放相关MIL点亮DTC |
报告导致MIL灯亮的排放相关故障码 |
| DM14-DM18 |
内存访问与安全 |
用于标定、诊断数据的读写,含安全认证机制 |
关键技术要点与设计考量
在实施SAE J1939-73诊断方案时,工程师需重点关注以下几点:
- DTC编码结构:每个诊断故障码由可疑参数编号(SPN)和故障模式标识(FMI)组成。SPN指明故障的部件或功能,FMI说明故障的具体形式(如短路、超限)。正确解读SPN和FMI组合是精准故障定位的关键。
- 内存访问安全(DM14-DM18):在对ECU进行内存读写、标定或启动引导时,标准要求实施安全认证。开发人员必须实现相应的安全机制(如种子-密钥),以防止未授权操作。
- OBD法规合规:标准专门定义了满足OBD法规的报文,如DM12(排放相关MIL点亮DTC)、DM23(历史MIL DTC)和DM28(永久DTC)。设计时需考虑不同地区(如CARB、中国6)的特定要求,确保报文内容与法规一致。
- 诊断就绪与系统支持:使用DM5/DM21可查询ECU支持的诊断服务。并非所有ECU都实现所有DM,建议通过DM5确认功能后再进行诊断操作。
⚠️ 常见设计误区:忽视DTC中SPN与FMI的组合关系可能导致错误判断;未按时序要求广播DM1(如过于频繁或延迟)可能影响诊断工具正常工作;对于内存访问,忽略安全要求将使ECU暴露于篡改风险。务必严格遵循标准中关于报文速率和安全流程的规定。
🛠️ 设计洞察:该标准通过统一的诊断报文层,实现了多ECU协同下的系统级诊断。结合FMI的细粒度分类和SPN的广泛覆盖,测试工程师可以快速从众多故障中定位根因。对于新平台开发,建议优先支持DM1、DM2、DM3、DM4和DM5,再逐步扩展至OBD相关报文。
常见问题解答
- 问:如何正确实现DM1激活故障码的广播?
答:DM1报文应包含当前激活的所有DTC,每个DTC由SPN、FMI以及发生次数构成。ECU需严格按照标准规定的更新速率(通常不超过1秒)广播DM1,确保诊断工具实时获取故障状态。
- 问:SPN和FMI的编码有哪些注意事项?
答:SPN为19位编码,FMI为5位编码。在报文数据场中需按照格式紧凑排列。开发时应与标准定义的SPN和FMI列表保持一致,避免自定义未定义的值。对于私有故障,建议使用制造商自定义SPN范围。
- 问:内存访问(DM14-DM18)的安全机制是如何工作的?
答:标准定义了基于请求-响应的安全流程。外部工具通过DM14发送请求,ECU以DM15响应种子(Seed),工具计算密钥(Key)并通过DM16发送,ECU验证密钥后允许后续的数据传输或操作。开发者需实现兼容的密钥算法。
- 问:设计诊断系统时应如何考虑OBD法规差异?
答:不同区域(美国、欧洲、中国等)对排放诊断有特定要求。J1939-73提供了通用OBD报文框架,设计时应为不同法规预留配置选项,例如MIL点亮条件、监控组需求、以及历史DTC存储策略。建议在系统需求阶段明确目标市场的法规版本。
🔍 建议:在实际项目中,结合DM24(SPN支持)和DM5(诊断就绪1),可以快速评估任意ECU的诊断能力。这些报文是诊断系统互操作性的基础。