1 引言和功能概述
诊断事件管理器(Dem)这一服务组件,主要负责对诊断事件(故障)及相关数据进行处理与存储。此外,它还会向诊断通信管理器(Dcm)提供故障信息,例如从事件存储器中读取所有已存储的诊断故障码(DTC)。Dem 为应用层和其他基础软件(BSW)模块提供了相应的接口。
本 Dem 规范文档的核心目标,是为汽车制造商和零部件供应商制定一套通用的“诊断故障存储器”实现方法。
该规范对 AUTOSAR 基础软件模块——诊断事件管理器(Dem)的功能、应用程序接口(API)以及配置进行了明确界定。其中,部分内部行为因制造商而异,相关细节会在“限制条件”章节中说明。
2 缩略语和缩写词
以下术语表包含了与 Dem 模块相关,但未收录于《AUTOSAR 术语表》[4] 中的缩略语和缩写词。
2.1 缩略语
| 缩略语 | 描述 |
|---|---|
| 激活模式 1 | 无故障——故障指示灯(MIL)应闪烁一次。 |
| 激活模式 2 | “按需故障指示灯(MI)”——若车载诊断(OBD)系统根据区分显示策略指令触发按需故障指示灯,故障指示灯(MIL)应闪烁两次。 |
| 激活模式 3 | “短时故障指示灯(MI)”——若车载诊断(OBD)系统根据区分显示策略指令触发短时故障指示灯,故障指示灯(MIL)应闪烁三次。 |
| 激活模式 4 | “持续故障指示灯(MI)”——若车载诊断(OBD)系统根据区分显示策略指令触发持续故障指示灯,故障指示灯(MIL)应保持常亮状态(“持续故障指示灯”)。 |
| 老化(Aging) | 当某个事件/诊断故障码(DTC)在规定的运行循环次数内未再出现故障时,从事件存储器中删除该事件/诊断故障码(DTC)的过程。 |
| 老化计数器(Aging Counter) | “老化计数器”“老化循环计数器”或“诊断故障码(DTC)老化计数器”指的是用于执行老化操作的计数器,它会统计直至事件/诊断故障码(DTC)从事件存储器中被删除所经历的运行循环次数。 |
| B1 类计数器(Class B1 counter) | 发生 B1 类故障且已确认并检测到故障的发动机运行小时数。 |
| 组合诊断故障码(Combined DTC) | 常规诊断故障码(DTC),但会被多个监测器报告的多个事件引用(例如,由不同硬件故障构成的电子控制单元(ECU)故障)。 |
| 持续故障指示灯计数器(Continuous-MI counter) | 发动机在故障指示灯(MI)被指令持续点亮期间的运行小时数。 |
| 累计持续故障指示灯计数器(Cumulative Continuous-MI counter) | 故障指示灯(MI)在其使用寿命内被指令持续点亮的总发动机运行小时数。 |
| 去抖计数器(Debounce counter) | 用于基于计数器的去抖算法的内部计数器。 |
| 诊断事件管理器组件/受监测组件(DemComponent / Monitored Component) | 受监测组件是系统的一部分,会通过一个或多个监测器检查其运行是否正常(详见第 7.5 章)。 |
| 诊断事件管理器内部数据值(Dem-internal data value) | 部分数据值(如发生计数器)由诊断事件管理器(Dem)模块内部自行计算得出。 |
| 分母(Denominator) | 特定监测器 m 的分母(Denominatorm)是一个计数器,用于统计符合该特定监测器相关条件的车辆行驶事件次数。 |
| 从属/次级电子控制单元(Dependent / Secondary ECUs) | 从属/次级(或简称 dep. / sec.)电子控制单元(ECU)始终与主电子控制单元(Master ECU)或初级电子控制单元(Primary ECU)相关联。 |
| 有向无环图(Directed acyclic graph) | 不存在循环依赖的依赖关系图。 |
| 替换(Displacement) | 用需要存储的更重要的事件存储器条目,替换事件存储器中重要性最低的条目。 |
| 诊断故障码组(DTC group) | 唯一标识一组诊断故障码(DTC),一个诊断故障码组会映射到有效诊断故障码(DTC)的取值范围。通过指定诊断故障码组,意味着要求对该组内的所有诊断故障码(DTC)执行特定操作。诊断故障码组的定义遵循 ISO 14229-1[2] 标准,同时也可由原始设备制造商(OEM)/供应商自行定义。 |
| 所有诊断故障码组(DtcGroupAllDtcs) | 所有已配置诊断故障码(DTC)的分组(标识为 0xFFFFFF)。 |
| 事件组合(Event combination) | 一种将多个事件合并为一个特定组合诊断故障码(DTC)的方法,用于将不同监测器的结果适配为一个显著的故障,以便在服务站进行清晰评估。 |
| 事件去抖(Event debouncing) | 去抖是一种特定机制(如基于计数器的机制),用于判断诊断事件是否合格。它在潜在的信号去抖基础上运行,可在软件组件(SW-C)内部或诊断事件管理器(Dem)内部实现。 |
| 事件确认(Event confirmation) | 若在多个循环或一段时间内,通过故障确认计数器检测到多次合格事件,则诊断事件被确认,同时诊断服务(UDS)状态位 3(确认诊断故障码(ConfirmedDTC))会被置 1。 |
| 事件存储器(Event memory) | 事件存储器(如主存储器)由多个事件存储条目组成。 |
| 事件存储条目(Event memory entry) | 事件存储条目是单个事件及其相关数据的存储容器,会动态分配给特定事件。 |
| 事件存储器溢出指示(Event memory overflow indication) | 用于指示特定事件存储器是否已满,以及是否有新的事件需要存储到该事件存储器中。 |
| 事件合格(Event qualification) | 当诊断事件的结果为通过(passed)或失败(failed)时(无论是诊断事件管理器(Dem)内部计算得出,还是由其他基础软件(BSW)模块或软件组件(SW-C)报告),该诊断事件即被判定为合格。 |
| 事件相关数据(Event related data) | 事件相关数据是额外的数据,例如传感器值或时间戳/里程数,会与事件一同存储在事件存储器中。国际标准化组织(ISO)定义了两种类型的事件相关数据:冻结帧(快照记录)和扩展数据。 |
| 事件状态字节(Event status byte) | 基于事件级别的、符合 ISO 14229-1 [1] 标准定义的状态字节。 |
| 扩展数据记录(Extended data record) | 用于存储与故障相关的特定信息的记录。 |
| 失败计数器(Failure counter) | 失败计数器对应 ISO 14229-1 [2] 标准中的行程计数器(Trip Counter),用于统计发生故障的运行循环(行驶循环)次数。当计数器达到阈值(例如 2 个行驶循环)时,确认位会从 0 变为 1。 |
| 故障检测计数器(Fault Detection Counter) | 符合国际标准化组织(ISO)标准和故障检测计数器应用程序接口(FDC-APIs)的有符号 8 位(sint8)值。 |
| 冻结帧(Freeze frame) | 冻结帧定义为一组数据记录(数据标识符(DID)/参数标识符(PID)),与 ISO-14229-1[2] 标准中的快照记录(SnapShotRecords)含义相同。 |
| 通用分母(General Denominator) | 一个计数器,用于统计符合通用条件的车辆运行次数。 |
| 恢复(Healing) | 在一段时间内/经过多个运行循环,若监测到多次通过(passed)结果,则关闭警告指示灯,并进行相关处理。 |
| 使用中性能比率(In-Use performance ratio) | 车载诊断(OBD)系统中特定监测器 m 的使用中性能比率(IUPR)计算公式为:IUPRm = 分子m(Numeratorm)/ 分母m(Denominatorm) |
| 主电子控制单元(Master ECU) | 作为初级电子控制单元(Primary ECU),主电子控制单元(Master ECU)会在其事件存储器中存储自身的以及相关从属/次级电子控制单元(dep. / sec. ECUs)上报的故障。此外,主电子控制单元(Master ECU)还需承担一些特殊的主电子控制单元(Master)任务,例如故障指示灯(MIL)主控制或提供“通用分子”信息。 |
| 监测器(Monitor) | 诊断监测器是一种用于判定组件运行是否正常的例行实体,也可称为“诊断功能”。 |
| 分子(Numerator) | 特定监测器 m 的分子(Numeratorm)是一个计数器,用于统计车辆运行过程中,满足该特定监测器检测故障所需的所有监测条件的次数。 |
| 标记为需执行非易失性存储器(NvM)全写(NvM is marked for NvM_WriteAll) | 诊断事件管理器(Dem)调用非易失性存储器管理器(NvM)的 NvM_SetRamBlockStatus() 函数,将相应的非易失性存储器(NvM)块设置为需通过 NvM_WriteAll() 函数写入数据的状态。 |
| 运行循环(Operating cycle) | 运行循环是事件合格判定以及诊断事件管理器(Dem)调度的基础(例如,点火开关关-开循环、行驶循环等)。 |
| 车载诊断(OBD) | 车载诊断(On-Board Diagnostics,简称 OBD)是一个通用术语,指车辆的自诊断和报告功能。通过车载诊断(OBD)系统,车辆所有者或维修技术人员可以获取车辆各个子系统的运行状态信息。 |
| 车载诊断(OBD)电子控制单元(ECUs) | 一辆车辆中可能存在三种不同类型的车载诊断(OBD)电子控制单元(ECU): • 主电子控制单元(Master ECU)(每辆车一个) • 初级电子控制单元(Primary ECU)(每辆车多个) • 从属/次级电子控制单元(Dependent / Secondary ECUs)(每辆车多个) |
| 动力系统代码(P-Code) | 动力系统代码(Power train code) |
| 永久故障码行驶循环(PFC cycle) | 永久故障码(Permanent fault code)行驶循环(车载诊断(OBD)术语) |
| 非易失性存储器(NvM)正向回调(Positive Callback from NvM) | 若诊断事件管理器(Dem)需要在 Dem_Init 和 Dem_Shutdown 之间存储数据,则应使用非易失性存储器管理器(NvM)[5] 的 NvM_WriteBlock 和 NvM_GetErrorStatus 应用程序接口(API)。此外,若块写入操作成功完成,NvM_GetErrorStatus 应用程序接口(API)应等待正向响应。 |
| 可能的错误(PossibleErrors) | 指元模型中定义的应用错误(ApplicationErrors)。 |
| 初级电子控制单元(Primary ECU) | 初级电子控制单元(Primary ECU)会在其事件存储器中存储自身的以及相关从属/次级电子控制单元(dep. / sec. ECUs)上报的故障。 |
| 基于比率监测的行驶循环(RBM cycle) | 车载诊断(OBD)术语:通用分子/基于比率的监测行驶循环(车载诊断(OBD)术语) |
| 就绪状态(Readiness) | 就绪状态与诊断服务(UDS)状态字节中的“自上次清除后测试未完成”位(第 4 位)和“本运行循环测试未完成”位(第 6 位)相关。 |
| 触发写入非易失性存储器(NvM)(Triggered to NvM) | 若诊断事件管理器(Dem)需要在 Dem_Init 和 Dem_Shutdown 之间触发数据存储,则应使用非易失性存储器管理器(NvM)[5] 的 NvM_WriteBlock 应用程序接口(API)。此外,若请求已被接受,诊断事件管理器(Dem)模块应等待 NvM_WriteBlock 应用程序接口(API)的正向响应。 |
| 诊断服务(UDS)状态位 0 | 诊断服务(UDS)状态字节的“测试失败”位,指示最近一次执行测试的结果。 |
| 诊断服务(UDS)状态位 1 | 诊断服务(UDS)状态字节的“本运行循环测试失败”位,指示在当前运行循环期间,诊断测试是否曾报告过失败结果。 |
| 诊断服务(UDS)状态位 2 | 诊断服务(UDS)状态字节的“待决诊断故障码(PendingDTC)”位,指示在当前或上一个已完成的运行循环期间,诊断测试是否曾报告过失败结果。 |
| 诊断服务(UDS)状态位 3 | 诊断服务(UDS)状态字节的“确认诊断故障码(ConfirmedDTC)”位,指示是否已多次检测到故障,且该故障对应的诊断故障码(DTC)需要存储到长期存储器中。 |
| 诊断服务(UDS)状态位 4 | 诊断服务(UDS)状态字节的“自上次清除后测试未完成”位,指示自上次调用“清除诊断信息”函数以来,诊断故障码(DTC)测试是否曾运行并完成。 |
| 诊断服务(UDS)状态位 5 | 诊断服务(UDS)状态字节的“自上次清除后测试失败”位,指示自上次调用“清除诊断信息”函数以来,诊断故障码(DTC)测试是否曾完成且结果为失败。 |
| 诊断服务(UDS)状态位 6 | 诊断服务(UDS)状态字节的“本运行循环测试未完成”位,指示在当前运行循环期间,诊断故障码(DTC)测试是否曾运行并完成。 |
| 诊断服务(UDS)状态位 7 | 诊断服务(UDS)状态字节的“警告指示灯请求”位,报告与特定诊断故障码(DTC)相关的任何警告指示灯的状态。 |
| 诊断服务(UDS)状态字节(UDS status byte) | 基于诊断故障码(DTC)级别的、符合 ISO 14229-1 [1] 标准定义的状态字节。 |
2.2 缩写词
| 缩写词 | 描述 |
|---|---|
| API | 应用程序接口(Application Programming Interface) |
| BSW | 基础软件(Basic Software) |
| CDD | 复杂设备驱动程序(Complex Device Driver) |
| CRC | 循环冗余校验(Cyclic Redundancy Check) |
| Dcm | 诊断通信管理器(Diagnostic Communication Manager) |
| Dem | 诊断事件管理器(Diagnostic Event Manager) |
| Det | 默认错误跟踪器(Default Error Tracer) |
| DID | 数据标识符(Data Identifier) |
| DTC | 诊断故障码(Diagnostic Trouble Code) |
| DTR | 诊断测试结果(Diagnostic Test Result) |
| DYC | 车载诊断(OBD)术语:行驶循环(OBD Term) |
| ECU | 电子控制单元(Electronic Control Unit) |
| EcuM | 电子控制单元管理器(Electronic Control Unit Manager) |
| FDC | 故障检测计数器(Fault Detection Counter) |
| Fim | 功能禁止管理器(Function Inhibition Manager) |
| FMI | 故障模式指示器(SAE J1939)(Failure Mode Indicator (SAE J1939)) |
| FTB | 故障类型字节(Failure Type Byte) |
| HW | 硬件(Hardware) |
| ID | 标识/标识符(Identification/Identifier) |
| ISO | 国际标准化组织(International Standardization Organization) |
| IUMPR | 使用中监测性能比率(车载诊断(OBD)术语)(In Use Monitoring Performance Ratio (OBD Term)) |
| J1939Dcm | SAE J1939 诊断通信管理器(SAE J1939 Diagnostic Communication Manager) |
| MIL | 故障指示灯(SAE J1979)或指示灯(SAE J1939)(Malfunction Indicator Light (SAE J1979) or Lamp (SAE J1939)) |
| NVRAM | 非易失性随机存取存储器(Non volatile RAM) |
| OBD | 车载诊断(On-Board-Diagnostics) |
| PID | 参数标识符(SAE J1587 或 SAE J1979)(Parameter Identification (SAE J1587 or SAE J1979)) |
| RAM | 随机存取存储器(Random Access Memory) |
| ROM | 只读存储器(Read-only Memory) |
| RTE | 运行时环境(Runtime Environment) |
| SPN | 可疑参数编号(SAE J1939)(Suspect Parameter Number (SAE J1939)) |
| SSC | 同步服务器调用点(synchronous server call point) |
| SW-C | 软件组件(Software Component) |
| UDS | 统一诊断服务(Unified Diagnostic Services) |
| V-OBD | 车辆车载诊断(Vehicle On-Board-Diagnostic) |
| WUC | 车载诊断(OBD)术语:暖机循环(OBD Term)(Warm up cycle (OBD Term)) |
| WIR | 警告指示灯请求(Warning Indicator Request) |
| WWH-OBD | 全球统一车载诊断(World Wide Harmonized On-Board-Diagnostic) |
3 相关文档
3.1 输入文档及相关标准和规范
参考文献
[1] 统一诊断服务(UDS)——第 1 部分:规范和要求(2006-12 版本)http://www.iso.org
[2] 统一诊断服务(UDS)——第 1 部分:规范和要求(2013-03 版本)http://www.iso.org
[3] 道路车辆——全球统一车载诊断(WWH-OBD)通信要求的实现——第 1 部分:通用信息和用例定义 http://www.iso.org
[4] AUTOSAR 术语表(Glossary AUTOSAR_TR_Glossary)
[5] 非易失性存储器管理器规范(Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager)
[6] 基础软件模块通用规范(General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral)
[7] SAE J1939 诊断通信管理器规范(Specification of a Diagnostic Communication Manager for SAE J1939 AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager)
[8] 功能禁止管理器要求(Requirements on Function Inhibition Manager AUTOSAR_SRS_FunctionInhibitionManager)
[9] 诊断通信管理器规范(Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager)
[10] 诊断要求(Requirements on Diagnostics AUTOSAR_SRS_Diagnostics)
[11] 基础软件模块通用要求(General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral)
[12] 道路车辆——车辆与外部设备之间关于排放相关诊断的通信——第 5 部分:排放相关诊断服务 http://www.iso.org
[13] SAE J2012-DA 数字标准
[14] SAE J1939-73 应用层——诊断(SAE J1939-73 Application Layer – Diagnostics)
[15] 道路车辆——拖挂车辆与被拖挂车辆之间电气连接的数字信息交换——第 4 部分:诊断通信 http://www.iso.org
[16] ISO 17356-3:道路车辆——嵌入式汽车应用开放接口——第 3 部分:OSEK/VDX 操作系统(OS)
[17] SAE J1979 标准
[18] SAE J1979-DA 电子/电气诊断测试模式数字附录(SAE J1979-DA Digital Annex of E/E Diagnostic Test Modes)
[19] 加利福尼亚法规第 13 篇第 1971.1 节:2013 及后续车型年重型发动机车载诊断系统要求(HD OBD)
[20] 加利福尼亚法规第 13 篇第 1968.2 节:2004 及后续车型年乘用车、轻型卡车和中型车辆及发动机的故障和诊断系统要求(OBD II)(2008-2011 双年审查)http://www.arb.ca.gov/regact/obdii06/19682clean.pdf
[21] 道路车辆——全球统一车载诊断(WWH-OBD)通信要求的实现——第 3 部分:通用消息字典 http://www.iso.org
[22] 软件组件模板(Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate)
[23] 诊断提取模板(Diagnostic Extract Template AUTOSAR_TPS_DiagnosticExtractTemplate)
3.2 相关规范
AUTOSAR 提供了基础软件模块通用规范([6, SWS BSW General]),该规范同样适用于诊断事件管理器(Dem)。因此,基础软件模块通用规范(SWS BSW General)应被视为诊断事件管理器(Dem)的补充性强制规范。
4 约束条件和假设
诊断事件管理器(Dem)中定义的部分同步应用程序接口(API)调用的完成时间可能不固定,因此在系统配置时必须考虑这种时间可变性。
[SWS_Dem_00126] ⌈每个电子控制单元(ECU)应仅存在一个诊断事件管理器(Dem)模块。⌋(SRS_Diag_04002)
诊断事件管理器(Dem)可以包含多个不同的事件存储区域,诊断故障码(DTC)到相应存储区域的映射通过“诊断故障码(DTC)来源”参数实现。某个特定电子控制单元(ECU)的诊断事件管理器(Dem)仅能被位于同一电子控制单元(ECU)内部的软件组件访问。
4.1 限制条件
整个电子控制单元(ECU)都需考虑时序约束。如果对诊断事件管理器(Dem)的响应速度有明确的更快要求,且超出了诊断事件管理器(Dem)的基本循环时间,则需要实施本 AUTOSAR 文档中未规定的特殊措施,这种情况在具有大量事件的电子控制单元(ECU)中尤为常见。
在极少数情况下,事件状态变化和诊断故障码(DTC)状态变化的回调函数执行并非确定性的,因此不应将其用于安全相关的用例。同时,需参考 ISO-14229-1[2] 中的通用说明,不建议将诊断故障码(DTC)状态与故障安全策略相关联。
本软件规范(SWS)未涉及运行时环境(RTE)在诊断事件管理器(Dem)与软件组件(SW-C)交互过程中报告的基础设施错误处理方式,若实施者有相关需求,需自行考虑。
诊断事件管理器(Dem)支持额外的事件存储器(永久存储器、镜像存储器和用户定义存储器),但未详细定义这些特定事件存储器的处理流程。
本规范未详细规定诊断事件管理器(Dem)与特定排放相关软件组件(SW-C)之间的部分交互细节,因为这些细节依赖于软件组件(SW-C)的实现。以下功能未在本规范中定义:
• 故障指示灯(MIL)激活(故障指示灯(MIL)处理器与诊断事件管理器(Dem)的交互、故障指示灯(MIL)灯泡检查、就绪状态闪烁、催化转化器损坏性失火情况下的闪烁等)
• 失火故障处理(所有气缸的去抖处理、单个/多个失火故障的过滤)
• 失火故障和燃油系统故障特定恢复的类似条件支持
注:对于车载诊断第二代(OBD2),要求失火故障和燃油系统故障仅能在与故障检测时相似的条件下恢复(即退出服务 $07)。这里的“相似性”是基于故障检测时发动机转速、发动机负荷和温度条件范围所构成的“窗口”来判定的。
对于相似条件的处理,假设失火检测/燃油系统诊断的软件组件(SW-C)模块会自行执行必要的计算,而非在诊断事件管理器(Dem)中进行全局处理。
然而,基于相应失火检测/燃油系统诊断的特定接口要求,可能需要对诊断事件管理器(Dem)进行扩展。任何相关的进一步实现都需根据具体的发动机控制单元(ECU)项目、诊断需求和诊断事件管理器(Dem)实现来定义。
诊断故障码存储数据记录编号(DTCStoredDataRecordNumber)(绝对冻结帧记录寻址功能)仅限于 0x00(车载诊断(OBD)冻结帧,详见 7.11.2.4 小节)。
由记录编号标识的特定扩展数据记录的结构在每个电子控制单元(ECU)中是唯一的。
由于架构设计原因,诊断通信管理器(Dcm)在处理“读取诊断数据”服务时,可能会锁定事件存储器更新(参考 [SWS_Dem_00270])。
本规范涵盖了部分与 SAE J1939 相关的诊断要求(详见 [7, SWS J1939 Dcm] 中的表 1:支持的 DMx 消息)。可疑参数编号(SPN)转换方法仅限于版本 4(CM=0)。
AUTOSAR 仅支持用户定义的存储器标识(ID),其取值范围为 0x10 至 0xFF,该范围是 AUTOSAR 向 ISO 14229:1[2] 提议的。
指示灯仅局限于诊断事件管理器事件存储集(DemEventMemorySet)本地,诊断事件管理器(Dem)不支持指示灯用于多个诊断事件管理器事件存储集(DemEventMemorySet)的配置。
参数“诊断事件管理器运行循环自动启动(DemOperationCycleAutostart)”[ECUC_Dem_00805] 已过时,应忽略。
4.2 汽车领域适用性
诊断事件管理器(Dem)的设计既满足有车载诊断(OBD)要求的电子控制单元(ECU)的设计需求,也适用于无车载诊断(OBD)要求的电子控制单元(ECU)。目前其直接适用的领域包括车身、底盘和动力总成电子控制单元(ECU),但并无技术障碍阻止将其用于信息娱乐等其他汽车领域的电子控制单元(ECU)实现。
585

被折叠的 条评论
为什么被折叠?



