汽车系统设计(全面讲解智能汽车系统诊断管理模块设计)

整个诊断汽车管理包括诊断通信管理(Diagnostic Communication Manager, DCM)、诊断事件管理DEM（Diagnostic Event Manager）、功能抑制管理FIM（Function Inhibition Manager）几大模块。诊断功能贯穿汽车的开发生产及售后等过程，如开发过程中EMC、ESD等实验均可使用诊断服务实现，生产过程中的软件下载更新、ECU产线EOL、汽车产线EOL等、售后过程中读取DTC、控制输出调试功能等。尤其是在智能汽车上，诊断功能显得尤为重要，因为智能汽车的很多功能模块需要承载更多的Sensor和Controller，且其功能都是自适应触发。因此，对于其自身系统及其关联系统的诊断要求比传统汽车要高很多。

如下图，表示了AUTOSAR架构中的所有诊断通信模块之的关联关系。在底层软件中，包括模式管理Mode Manager、诊断Diagnosis、存储Memory、通信Communication几个模块。

在AUTOSAR中，DCM和DEM是两个关键的诊断模块，它们之间通过一些通信链路相互作用。DCM主要负责与外部诊断工具（例如诊断扫描仪）进行通信，以便读取和清除故障码，并执行一些诊断任务。DEM则负责管理和记录车辆的诊断事件，例如故障码、诊断状态和诊断数据等。

诊断通信管理模块DCM

作为AutoSar诊断模块的重要组成部分，DCM主要负责诊断数据流和管理诊断状态（即能检查诊断服务的请求是否满足条件），包括诊断会话、安全状态及诊断服务分配等。DCM模块主要实现UDS和OBD诊断服务的实现，但是DCM跟其他模块的交互比较频繁，需要了解诊断服务的机制需要其他模块配置，比如BswM、DEM、EcuM以及SWC等。

DCM模块可以分为四个子层，分别是DSD（Diagnostic Session Dispatcher）、DSL（Diagnostic Service Layer）、DSP（Diagnostic Service Processor）和DCL（Diagnostic Communication Layer）。在这个上下文中，DCM、DSD、DSL和DSP之间的关系可以描述如下：

1、DSL ：诊断服务层。

该层处于DCM模块的最底层，用于处理诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序。它接收来自DSD层的诊断请求，并根据请求类型将其路由到相应的DSP子层服务。同时，DSL也负责将来自DSP子层的诊断响应传输回DSD层。

整个处理诊断请求及响应的过程如下：

DSL负责接收PduR模块上传的诊断请求及调用PduR模块发送诊断响应数据，管理并确保诊断协议时序和诊断状态（如当前安全级别保存和复位，当前会话状态，默认会话与非默认会话之间的转换，对不同诊断协议优先级定义和抢占处理）。

2、DSD：诊断会话调度器。

处于中间层，这个子层主要负责管理诊断会话，如处理诊断会话切换、请求取消、会话超时等功能。此外，它还负责将来自DCL层的诊断请求转发到相应的DSL层服务。

当接收到新的诊断请求后转发到诊断服务器，完成诊断请求处理后转发诊断响应。

3、DSP：诊断服务处理器。

处于最上层，具体实施诊断服务处理，当接受到DSD请求处理诊断服务并转发诊断请求后，将完成实际的诊断服务功能响应及处理。它包含了处理不同诊断服务（如读取故障码、控制执行、数据参数ID请求等）所需的功能。每个具体的诊断服务都可以看作是一个独立的DSP子层。

DCM作为诊断通信管理器，通过DSD负责诊断会话管理，DSL处理诊断服务请求和响应，而DSP负责实施具体的诊断服务，以上各子层的协同作用可以有效的实现各种诊断服务的处理和响应。

诊断事件管理（DEM）

DEM负责处理车辆的故障诊断信息。DEM模块可以接收来自各种传感器和控制器的诊断信息，然后根据故障严重程度进行分类和记录，并提供诊断状态和故障码等信息。

此外，DEM还提供了一些API（应用程序接口），用于访问和修改诊断数据。例如，可以使用API来清除已诊断的故障码或设置故障码的优先级。DEM还提供了诊断通信协议和诊断存储库，以便与其他系统进行通信和记录诊断数据。

DCM和DEM之间的通信链路主要包括以下组件：

1）DCM提供的API：DCM提供了一些API，用于从DEM中读取和更新诊断数据，例如读取故障码和清除故障码等。

2）DEM提供的API：DEM也提供了一些API，用于向DCM提供诊断信息，例如故障码、诊断状态和诊断数据等。

3）DCM-DEM通信协议：DCM和DEM之间的通信需要使用一些标准化的通信协议，例如UDS（Unified Diagnostic Services）协议和ISO 14229标准。

4）诊断存储库：DCM和DEM需要共享一些诊断数据，例如故障码和诊断状态等，这些数据通常存储在诊断存储库中，DCM和DEM可以通过这个存储库来交换数据。

举个例子，我们在对智能汽车生产线过电检时，通常需要关闭智能驾驶的环境目标检测及后台自启动功能（如AEB、MEB这类后台自动运行的功能），因为这些功能在产线上自动运行往往会导致误触发，误报警等。

那么如何通过诊断管理链路关闭这类功能呢？

这就需要用到AutoSar中非常重要的两个软件组件模块诊断事件管理DEM和实时调度系统RTE。他们之间的通信链路可以通过AUTOSAR的标准化软件接口RTE APIs来实现。首先，DEM模块可以向RTE模块发送事件（例如功能抑制信息或故障码、诊断状态信息）。RTE模块接收到这些事件后，通过其自身提供的一些API，RTE事件总线通过管理和分发来自DEM和其他模块的事件，并将它们路由到相应的处理程序中。此外，RTE操作系统作为一种特殊的软件层，它负责管理和控制运行时环境，并提供一些基础设施服务，例如任务调度、内存管理和错误处理等。从而有效的访问汽车电子系统的各种资源，例如读取传感器数据、控制执行器等。也可以触发相应的操作，例如关闭AEB或MEB功能，亦或者打开某个告警灯等。

为了更加详细的说明整个DEM的诊断链路，我们将以实际的DEM相关函数调用为例进行有效的说明。

首先，DEM的API主要包括DEM监视器DemComponent（又名MonitorComponent），主要用于有关联到的故障事件，比如传感器本身发生的故障，这时控制器读取的数据应该被视为无效。一个DemComponent是若干个事件的集合，在DemComponent内部，故障事件有优先级，当最高优先级的故障事件状态为Failed从而导致其他故障事件也为Failed时，亦或者父节点DemComponent的状态为Failed从而导致子节点DemComponent内的故障事件状态变为Failed，这种叫连续错误的故障。其他则被认为是偶发错误故障。另外，如果DemComponent内部故障事件优先级被忽略，那么仅有当父节点DemComponent状态为Failed导致子节点DemComponent的故障事件状态变成Failed时，也可被当做连续错误。

其次，DemDTCAttributes可以用于配置DTC的属性，包括老化周期、故障优先级、存储方式（立即存储还是下电存储）、快照数据需记录的最大组数以及参考的冻结帧快照数据、故障数据存储的Memory等，其中快照数据、扩展数据等需要在DemGneral中进行配置。

DemDTC用于配置故障得DTC值（即诊断故障码）、DTC的严重弄程度以及参考的DTC属性、Obd属性等。

DemDebunceCounterBaseClass、DemDebounceTimeBaseClass两项主要用于为不同的故障事件配置不同的Debounce策略，可以是基于计数器的Debounce策略，也可以是基于事件的Debounce策略，或者由SWC自定义。

DemOBDDTC用于配置OBD类故障事件是否支持PTO以及故障事件的DTC值等。

DemPidClass用于配置PID以及相关的应用层信号。

DemEventParameter用于配置故障的类型（BSW或SWC）、故障需要多少个运行循环才能确认、是否支持预存储功能、故障事件的Debounce策略以及参考的DTC属性、DemComponent、使能条件、运行循环等。

功能抑制管理FIM

FIM实际是一种软件组件，用于实现对应功能的抑制管理。功能抑制是指在车辆故障或安全问题出现时，对某些汽车功能进行限制或禁用的操作，以保证车辆和乘客的安全。FIM组件通过AUTOSAR的标准化软件接口（FIM API）与其他软件组件（例如ECU、Sensor和Actuator）进行通信，以检测和响应车辆故障或安全问题，并执行相应的功能抑制措施。

FIM的主要功能逻辑就是基于DEM模块上报Event状态，来触发相应的FID，然后BSW层或者SWC层相关的子模块根据这些FIM功能抑制场景（也就是功能降级）。

这里举个自动窗户升降与防夹功能的例子来说明如何通过FIM相关的函数模块来调用Sensor SWC层中的Event anti_Pinch，并通过下面几个阶段来完成系统降级过程。

S1：Front-left Window-lifter SWC上报故障给到Error Management模块；

S2：Error Management模块会识别出为Event anti_Pinch故障，并调用Dem模块接口通知该Event Status发生变化；

S3：Dem模块会调用FIM模块相应的函数接口来通知FIM该Event Status对相应FID的影响；

S4：SWC模块接收到轮询的FID，然后完成相应的系统降级响应；

FIM模块提供了一些API（应用程序接口），用于访问和修改功能抑制状态、读取和更新诊断数据等。这些API通常是标准化的，符合AUTOSAR软件架构的规范。

FIM模块主要调用的API接口包括如下：

FIM_Init()：此API用于初始化FIM模块，包括初始化内部数据结构、变量和状态等。

该函数是用于完成FIM相关结构体的初始化工作。如果DET模块使能，可以判断FIM是否初始化成功，或者可以通过一个静态变量判断是否发生变化来判断初始化是否完成。因为如果FIM模块没有完成初始化，则会被其他模块调用其内部的函数，且会返回E_NOT_OK，所以调用FIM其他函数接口之前必须完成FIM模块的初始化。

FIM_InhibitFunction()：此API用于抑制特定的汽车功能。它需要输入功能ID和抑制级别等参数，并返回抑制状态和抑制结果等信息。

FIM_ReleaseFunction()：此API用于释放被抑制的汽车功能。它需要输入功能ID等参数，并返回释放状态和释放结果等信息。

FIM_GetStatus()：此API用于获取FIM模块的当前状态，例如抑制状态、抑制等级和抑制时间等。

FIM_GetDiagnosticData()：此API用于读取和更新FIM模块的诊断数据，例如故障码和诊断状态等。

如下将以具体的实例参数调用来说明如何进行功能抑制。

FIM_DemTriggerOnMonitorStatus：

该函数是为了提供给Dem模块Event Status发生变化时通知到FIM模块接口。一旦Event Status发生变化，Dem就会主动调用该函数，通知FIM，其本质上就是一种Trigger Action行为。其实FIM获取Event Status状态变化，还有一种Polling的方式，但是当Event数目比较大时，有时候就无法察觉到某些Event Status的快速变化，因此一般而言，都优先选择Trigger方式来完成对FIM模块的Event Status的通知。

FIM_GetFunctionPermission：

该函数提供给SWC或BSW模块来获取FID状态。如果请求FID超出范围或FIM模块还没有初始化完成，则FID就会直接退回FALSE。

FIM_GetFunctionAvailable：

该函数用来给BSW或SWC层设置某功能是否可用，如果输入参数为True，则该功能可以正常使用

FIM_SetFunctionAvailable：

该函数用来给BSW或SWC层来设置某功能是否可用，如果输入参数为TRUE，那么该功能可以正常使用。若输入参数为FALSE，则该功能就会被Disable。

FIM_MainFunction：

该函数是为了实现对Event Status与Inhibition Mask的计算，此处有两种方式，一种是Polling方式，另一种是Event Trigger方式，这两种方式的使能通过工具选项FIMEventUpdate TriggeredByDem是否为True决定。