Autosar诊断协议栈-AutoSAR诊断模块总篇【诊断架构】

1 诊断的意义

诊断，通俗一点，就是程序的自检，如果有故障，把诊断结果及相应的上下文数据存在非易失性存储器中，以供后期维修的离线诊断提供分析的依据；严重的故障则实时地通过点亮报警灯提示驾驶员。下图1是诊断仪和ECU（Server）的交互图，诊断仪通过满足UDS/OBD格式的诊断协议进行故障数据的获取，即Client Tester通过特定帧的诊断报文发送诊断请求，Ecu Server根据诊断协议的规定(UDS/OBD)发送特定信息的诊断报文（特定信息可能包含DID读取或写入的系统或传感器信息；故障信息；扩展数据）。 具体的OBD诊断协议，见下图2的OBD诊断服务概述；具体的UDS诊断协议，见下图3UDS诊断服务概述，具体可以参考我公众号文章的《 UDS诊断看这篇就够了，吐血整理》。

图1 诊断仪和ECU（Server）的交互图

图2 OBD诊断服务概述

图3 UDS诊断服务概述

2 诊断协议栈功能架构

下图是诊断协议栈的功能概述，从图中可知，诊断协议栈由DEM（诊断事件管理器)，DCM(诊断通信管理器)，FIM（功能抑制管理器）组成；诊断消息的发送接收通过“网络通信基础设施服务”实现（Pdur抽象出特定的总线收发接口）；事件Event相关的数据（DTCs/FreezeFrame）的存储通过Memory Stack中的NvM实现；上层SWC Runnable（即Monitor Fuction）使用特定主机厂的DTC表格，使用诊断滤波算法实现故障的监控，故障的设置和清除通过RTE，使用CS/SR接口访问DEM提供的接口实现SetEventStatus（passed/failed）；可以启动和停止监控周期；以callbcak接口的形式读写DID（Diagnostic Data Identifier,如标识LED电压DID_D125,LED电流DID_D126,LED温度DID_D127）。

图4 AutoSAR Diagnostic Stack

2.1 诊断事件管理器（DEM）

2.1.1 概述

DEM在AutoSAR系统服务层中，负责处理诊断事件和存储诊断事件Event及诊断事件相关的数据（包含冻结帧数据和扩展数据，其一般包含多个DID数据,例子:当LED故障时，存储相应的DTC(三个字节0xppttdd)及冻结帧数据（电压电流温度；freezeframe recors通过引用上述的三个DID：LED电压DID_D125,LED电流DID_D126,LED温度DID_D127）到NvM中（NvM为冻结帧数据 定义相应的memory blocks，其中Ram blocks Dem_Cfg_PrimaryEntry_x(x范围为0-N)）在触发条件trigger condition满足时被写入对应的NV block，见下图5DEM 存储layout所示的冻结帧数据及扩展数据和DTC存储类型（primary（一般用于工厂人员）/secondary（一般用于开发人员））及Event ID和DTC的信息 ；除此之外，还通过接口为DCM提供相应的诊断信息（DTC status/快照数据（freeze-frame)（注意：DCM使用DTC number读取诊断事件的信息）

2.1.2 DTCs(诊断故障码)

DEM模块定义了一系列的DTCs(诊断故障码)。DTCs一般情况下和诊断事件（比如传感器故障）相对应的；SWCs（监控应用层故障状态）和BSWs（监控BSW模块的故障状态）通过Event ID（标识Evnet,全局唯一性）报告Event状态（Passed/Failed）到DEM模块；如果事件Falied，则DEM模块根据ISO14229规范设置Dtc status bytes并请求NvM存储事件和事件相关数据。（存储的trigger condition一般是test failed bit is set or confirmedDTC bit is set）

2.1.3 Event Aging

当Event被存储到NvM中后，并且Event不在诊断为Failed时，持续一定的周期后（即start aging），事件被称为Aged(老化)；则事件被从NvM 中remove；机制就是每个操作周期Aging cycle counter递增（当前操作周期没有tested failed，只有tested passed），当Aging cycle counter值等于配置的阈值（一般配置为40 个周期）；则触发NvM删除这条Event Entry。

图5 DEM 存储layout

2.1.4 DEM的三种事件滤波机制

• Time Based Debouncing
• Counter Based Debouncing
• Monitor internal Debouncing;

前两种由DEM实现，通过SetEventStatus（prepassed/prefailed）； Monitor internal Debouncing由应用层软件根据DTC表格规定的pass/fail滤波时间实现deboucing；经过deboucing后的Event被确认为tested，并返回fail/pass结果。( 具体查看DTC状态字节：Dem_UdsStatusByteType,如下表所示)

2.1.5 DEM的配置步骤

综上所述的理论，使用工具配置DEM步骤如下：

1. Configure DTC :

• Configure DTC number.
• Configure whether DTC is of UDS or OBD type.
• Assign a reference of snapshot data and extended data.

2. Configure an event :

• Assign a DTC to an event.
• Enable or disable event aging.
• Aging threshold
• Event debouncing algorithm
• Immediate NVM store option enable or disable.

3. Configure DIDs :

• Configure DID number and Name
• Port for SWC to BSW communication : Client Server or Sender Receiver DID size, data type

4. Snapshot Data and Extended Data :

• Assign DIDs to respective snapshot data and extended data.
• If snapshot is configured to have number then assign number to snapshot data
• Assign number to extended data

5. NVM Block :

• NVM blocks for DEM should be configured in NVM and reference need to provide in DEM.

6. DEM General Settings :

• To enable aging
• Trigger to store snapshot data
• Event aging type
• Event displacement policy

2.2 诊断通信管理器（DCM）

1. DCM在AutoSAR系统服务层中，负责处理外部诊断仪的诊断通信请求，诊断请求的数据可能是DID值或DTC状态字

2. DCM接收诊断服务请求，执行特定检查后，执行特定服务的action(可能需要从DEM获取DTC related Info)，然后发送正响应或特定NRC(Negaeive Resonse Code)否定相应

3. 请求和响应的格式请参见SO14229规范。

• 正响应格式为：received response starts from ServiceID + 40.【比如：发送请求10；正响应50】；
• 负相应格式为：Negative response starts from 7F followed by service ID and NRC。【比如：发送请求22 FD 78 (read DID FD78), 如果服务0x22 不支持，DCM 会发送negative response 7F 22 11。11 是NRC：service not supported】）

4. 如下图的架构所示；DCM包含三个子模块（诊断会话层DSL，诊断服务分派 DSD，诊断服务处理DSP）

2.2.1 诊断会话层DSL

总的来看，DSL有诊断请求和诊断响应功能：

• 诊断请求 DSL从PduR接收诊断请求，然后转发到DSD子模块；
• 诊断响应 接收DSD的诊断响应然后通过PduR发送出去。

DSL的功能细分为：

1. 实现3E的服务，可以和其他服务并发存在；
2. 获取ECU当前安全访问等级和当前会话状态；设置所需的ECU安全访问等级和会话状态；
3. 会话层管理：如果当前时non-default session，则判断S3 server timer是否超期，如果发生了S3 server timer timeout,则复位non-default session到default session；
4. 处理不同的诊断协议，实现不同的服务表（各种服务的集合）到OBD和UDS协议的映射；
5. 负责实现NRC78 pending 的处理（NRC78 pending报文的发送取决于P2，P2Star时间的配置）
6. 转发来自DSD的诊断响应到PduR，转发来自PduR的诊断请求到DSD

2.2.2 诊断会话层DSD

总的来看，DSD模块接收来自DSL的诊断请求，validate过后，转发到DSP模块进行处理；然后收集诊断响应的message转发到DSL子模块。

DSD的功能细分为：

1. check诊断请求的有效性（session和security level是否和诊断请求服务匹配；sends NRC 0x7F Service not supported in actvie session）
2. 正响应抑制的处理
3. check诊断请求服务是否被支持（检索服务表，NRC 0x11 if service is not supported）
4. 收集来自DSP的正响应+服务ID+来自App的响应数据转发给DSL子模块；收集来自DSP的负响应+服务ID转发给DSL子模块

2.2.3 诊断服务处理DSP

总的来看，DSP接收来自DSD模块的请求，执行检查后执行诊断请求特定的Action，收集DEM或SWC的数据后，组装响应消息发送到DSD模块。

DSP的功能细分为：

1. 检查报文格式是否支持（检查子功能，NRC 0x12 sub-function not supported）
2. 特定服务的实现(e.g. implementation service 0x19 or 0x 10 as per ISO14229),实现处理后，组装响应消息

2.2.4 DCM的配置

上述讲了诊断DCM的理论部分；要配置DCM，意味着配置三个字模块（DSL，DSD，DSP）

1. 配置DSL：

• 诊断请求和响应的Diagnostic buffer配置
• 诊断请求和响应的tx/rx pdu配置
• 协议的配置
• 协议参数的配置

2. 配置DSD：

• DSD 包含 服务表（all supported services 及相应的security and session access）

3. 配置DSP：

• 包含特定服务相关的配置（如配置DID读服务【service 22】，相应的DID需要配置）

2.3 故障抑制管理器（FIM）

FIM依据Event Status来禁止软件组件的特定功能。FIM使用功能ID（FID，表示带有抑制条件的功能标识），如果监测到i抑制条件成立；则相应的功能被立即停止执行。（FID被分配给SWCs；事件被分配给FID。基于事件的状态得到FID的状态，然后决定要不要执行特定功能）