1 概述
1.1 模式管理的组成
AUTOSAR为ECU的运行时软件的状态处理提供了模式管理组件，例如
• BswM模式管理器
• NM网络管理
• ECU状态管理器
• COMM通信管理器
• WDGM看门狗管理器
当然，除了这几个标准的AUTOSAR基础模块外，模式管理组件还涉及到了应用程序模式管理器（APP Mode Management）和RTE的相关功能。后面的章节将一一为你剖析。
2 AUTOSAR架构下的模式管理
模式管理中有三种模式角色，即模式请求者，模式用户和模式管理器。
模式请求者
请求模式管理器更改模式。
模式管理器
处理模式更改请求以更改内部模式，同时并将更改后的模式交付给其他模式用户。
模式用户
从模式管理器接收当前模式信息，或将其用作执行可运行程（Runnable）的事件。
模式的信息是使用RTE上的端口接口或BSW侧的C-API接口从模式管理器提供给模式用户的。模式信息以ModeDeclarationGroup格式定义。该ModeDecleartionGroup包含在软件组件描述文件中，并在生成RTE后作为代码中的枚举量。管理模式信息的模式管理器实现为BswM或AppM。
2.1 BSW模式管理
根据ECU的当前状态，BswM控制 ECU状态处理中的用户可定制的功能。BswM的行为通过“ if-else”语句形式的一组规则进行配置。由于功能安全和低功耗要求，需要为系统定义一系列状态，当进入各自的状态时，模式管理器将按照设置的操作并执行在该状态中定义的一系列任务。 对于应用层，使用MBD 状态机模型将使应用开发变得简单明晰，对于AUTOSAR 环境下，AUTOSAR提供了一种模式管理机制，用于执行与状态机等效的管理机制。 如下图1所示，BswM的模式管理由模式仲裁和模式控制组成。根据相应的条件执行分配的操作列表。动作列表由一个或多个控制其他BSW的ActionList组成。APP SWC可以使用发送端口接口向BswM请求模式。信息通过RTE传输，BswM通过接收端口接收信息。 注：BswM的每个配置参数在EcuC文件中描述，EB或DaVinci Generator基于此EcuC参数文件生成代码。
图1 BSWM 模式管理示意图
2.2 应用软件模式管理
应用软件的内部状态管理可以通过通用的软件开发方法(例如状态机)来实现，实现向其他SWC或BswM提供其相关的状态信息，或者基于该状态执行特定的Callout function。在这种情况下，应使用AUTOSAR RTE提供的模式接口。 如图3所示，AppM可以配置为模式管理器，处理来自其他模式请求模块的模式请求以更改模式。使用模式声明组预先定义要处理的模式。 模式用户通过接收端口接收当前模式信息和模式改变事件。 模式端口接口可以触发与其连接的可运行对象（Runnable），也可以停止调度另一个RTE事件触发的可运行对象。
图2 应用层模式管理
2.3 BswM模式的配置
在ECU运行生命周期的运行状态由BswM管理。如图3（a）所示，根据上层应用程序或BSW内部的状态转换设置相应的规则以执行特定操作。BswM由针对特定条件的逻辑决策表达式和针对表达式结果的一系列执行动作组成，如图3显示的状态机所示。
图3 BSWM的规则
根据BswM的规则，用于规则判断的每个条件的输入为ModeRequestSource，输出为AvailableAction。如下表中BSWM RULES所示, 为了构造状态机，我们首先通过考虑应将子状态的条件信息组合成复合的状态来定义必要的状态，每个关联规则的复合状态以条件表达式的形式表示，以创建状态转换条件，并将输出与该转换条件关联。 规则库可以定义为：{ Rule_aa，Rule_ab ，Rule_JK，……}，其中J表示条件下标，K表示ActionList 下标。具体可参看代码中的数组表的定义。
注：表中的BswMModeRequestSource是AUTOSAR 设计元素中的ChoiceContainer容器。如下图为模式请求类型为BswMCanSMIndication的配置：
图4 BSWM 的配置
注：对于BswM_CanSM_CurrentState(NetworkHandleTypeNetwork,CanSM_BswMCurrentStateType CurrentState)， 它可能具有多个实例，例如多个CAN通道。对于这些多个实例必须映射到不同的端口上。
2.4 应用层模式管理的开发
基于模型的ECU软件开发已被业界广泛采用。在AUTOSAR环境中，一些成熟的商业软件工具MATLAB / Simulink和TargetLink，可以通过应用软件的SWC Arxml文件来提取端口原型和SWC描述文件中定义的可运行信息，并自动生成模型的模板。在模板中实现算法并自动生成可执行代码。 在基于模型的应用程序软件开发过程中，Matlab Simulink 或TargetLink导入SWC的Arxml描述文件，描述文件包括输入和输出以及软件组件的内部行为（Runnbale，Event）的描述信息。其一般是在架构工具中事先定义好，如下图用SystemDesk设计了Indicatorlogic 组件，其包含了红框中的设计要素。
图5 APP SWC的组成要素
注：应用程序软件模式管理器模块为了处理与状态相关的信息，应该配置传递模式信息的端口，并且应该配置包括定义的模式信息的模式描述组 （Mode Declaration），并将其映射到模式端口接口中。
3 基础软件模式管理模块
模式管理功能集包括四个基本软件模块： • NM网络管理，协调网络节点的状态。 • ECU 状态管理器，控制AUTOSARBSW 模块的启动阶段，包括 OS 的启动； • 通信管理器，负责网络资源管理； • 看门狗管理器，基于应用软件的生存状态触发看门狗。
3.1 网络管理
网络管理堆栈包括：
► 与总线无关的网络管理接口模块Nm
► CAN网络管理模块CanNm
► FlexRay网络管理模块FrNm
► UDP / IP /以太网网络管理模块UdpNm
LIN没有网络管理。Nm模块的目的是为ComM模块提供独立于总线的接口。此外，Nm可以配置为NM协调器。如果连接了两个或更多总线，则NM协调器将处理同步关闭。
3.2 ECU状态管理器
ECU状态管理器是一个基本软件模块，管理 ECU 的状态（OFF、RUN、SLEEP），以及这些状态之间的转换（过渡状态：STARTUP、 WAKEUP、SHUTDOWN）。详细地， ECU状态管理器：
• 负责初始化和de-initialization所有基本软件模块，包括 OS 和RTE；
• 在需要时与所谓的资源管理器（例如，通信管理器）协作，关闭ECU；
• 管理所有唤醒事件，并在被要求时配置ECU 为SLEEP 状态。
为了完成所有这些任务， ECU 状态管理器提供了一些重要的协议：
• RUN 请求协议，调整ECU 是保持活动状态还是准备关闭，
• 唤醒确认协议，从“不稳定的”唤醒事件中区分出“真正的”唤醒事件， • 时间触发的增多非工作状态协议（TimeTriggered Increased Inoperation - TTII），允许 ECU 更多地进入节能的休眠状态。
ECU状态管理器必须支持独立的预处理动作和过渡，以启动 ECU 或将其转换到低功耗状态（例如，休眠状态/备用状态）。通过良好使用 ECU状态管理器的特性和能力，此模块能够用于执行电源消耗的预定义策略，因此提供了对 ECU 的有效能源管理。 ECU状态管理器的特性和优势包括： • 初始化和关闭基本软件模块。 • ECU 主要状态的标准化定义。 • 时间触发的更多非工作状态。
3.3 看门狗管理器
看门狗管理器是 AUTOSAR（服务层次）的标准化基本软件体系结构的基本软件模块。它监控与计时约束有关的应用执行的可靠性。 分层体系结构方法使得应用计时约束和看门狗硬件计时约束分离。基于此，看门狗管理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。 看门狗管理器提供以下特性：
• 监督多个处于ECU 的单独应用，这些应用有独立的计时约束并且需要特别监督运行时的行为和生存状态。
• 每个独立的受监控实体都有故障响应机制。
• 可以关闭对单独应用的监督，而不会违反看门狗触发（例如，对于禁止的应用）。
• 通过看门狗驱动触发内部或外部、标准或窗口，看门狗。（internalor external, standardor window, watchdog）对内部或外部看门狗的访问由看门狗接口处理。
• 根据ECU状态和硬件性能选择看门狗模式（OffMode, Slow Mode, Fast Mode）。
3.4 通信管理器
通信管理器收集并协调来自通信请求者（用户）的访问请求。 通信管理器的目的是：
• 简化通信协议栈的使用。包括通信栈的初始化，以及简单的网络管理。
• 调整ECU 上多个独立软件组件的通信栈（允许发送和接收消息）的可用性。
• 暂时禁止发送消息以阻止ECU（主动地）唤醒物理通道。
• 通过为每个物理通道实现一个状态机来控制ECU 的多个物理通道。
• 可以强制ECU 保持物理通道处于“ silent 通信”模式。
• 分配所请求的通信模式需要的所有资源，简化资源管理。
通信管理器定义了“通信模式”，表示一个特定的物理通道对于应用是否可用，以及如何使用（发送/接收，只接收，即不发送也不接收）
4 COMM 管理模块示例
ComM模块是对总线通信系统的控制的抽象。当模块User配置和访问网络总线通道(Channel ID)，不必考虑网络总线的类型（CAN，FlexRay，UDP / IP /以太网或LIN）。GONG中号：糖果Autosar 注：模块User包括：
请求通信的ECUM/BSWM 模块， 例如：Can控制器检测到唤醒后，BSWM通过模式端口请求打开通信。
应用层软件组件。
对于CAN，CANIF ,CANSM,COMM的每个模块都维护着自己的状态机。而对于每个网络通道，ComM模块中的状态机具有以下状态：
►完全通信（根据NM报文状态，包含相应子状态：准备睡眠，请求打开网络通信）
►静默通信。
►无通信。
每个状态的通信行为都不同。如下表所示：
关于网络管理，如果COMM_NM_VARIANT变体是Full，Com通信模式的改变会相应的去调用COMM_NM_NETWORKREQUEST或COMM_NM_NETWORKRELEASE实现是否同步唤醒和休眠 。在COMM_NM_LIGHT_VARIANT和COMM_NM_NONE_VARIANT变体时不进行同步。
4.1 CAN 全速通信的模式的实现示例
以CAN 全速通信为例，程序流如下图：
4.2 Can总线状态检测实现示例
再如下图的CAN通信的传输模式系统，CanSM管理MCU中CAN硬件的初始化以及诸如总线BUS OFF之类的模式状态。BswM通过CanSM监视CAN的通信状态，并在需要通信时请求COM模块激活相应的Pdu组，从而启用通信。在总线的BUS OFF状态下，请求停用PduGroup以停止传输。
图7 Can通信传输模式的设置
其中基于CAN 模块的BSWM模式管理器的详细的状态机如下图所示：
图8 基于CAN 模块的BSWM模式管理器的状态机
GONG中号：糖果Autosar
有很多读者给我留言，希望我做一个完整的AUTOSAR系列课程。我以后按照下面的目录系统地介绍Autosar各个模块.
AUTOSAR基础培训:
内容： 1)AUTOSAR概述和目标
2)AUTOSAR简介
3)AUTOSAR应用层
4)AUTOSAR RTE（运行时环境）
5)AUTOSAR BSW（基本软件）
6)AUTOSAR的方法论
7)AUTOSAR 的移植
AUTOSAR进阶培训:
1)操作系统 ：>基本了解AUTOSAR操作系统的介质和机制>任务，警报，事件等>AUTOSAR OS可扩展性类别
2)软件组件：>RTE >软件组件，端口，连接，任务映射和RTE生成的设计
3)输入和输出：>与I / O模块的数据交换>I/ O模块基础软件的配置
4)通信：>通过CAN进行数据交换>通讯模块的基础软件的配置
5)状态管理和系统服务: >ECU睡眠和唤醒和总线 > ComM，EcuM和BswM模块的作用>在基本软件中配置模式管理器模块
6)总线系统 :>了解总线系统的概念差异以及配置的重要性> CAN，LIN，FlexRay，以太网的介绍
7)非易失性内存访问:>访问非易失性存储器>非易失性存储器访问的基本软件配置
8)诊断：>使用AUTOSAR诊断 >配置诊断基本软件