| 编辑推荐: |
本文主要介绍下AUTOSAR中的模式管理（Mode Manager）的机理。 了解模式管理之前，先解释下三个重要的概念： 模式、状态和阶段，希望对您的学习有所帮助。
本文来自于汽车控制与人工智能
，由火龙果软件Alice编辑、推荐。 |
|
Mode（模式）
模式是运行在车辆中的各种状态机(不仅仅是ECU状态管理器)的一组状态，这些状态机与特定实体、应用程序或整个车辆相关。
State（状态）
状态在各自的BSW组件内部，因此对应用程序不可见。 所以它们只被BSW的内部状态机使用。 ECU状态管理器中的状态构建阶段，因此处理模式。
Phase（阶段）
ECU管理器动作和事件的逻辑或时间组件，如STARTUP,UP, SHUTDOWN, SLEEP启动、运行、关闭、休眠等。 阶段可以由子阶段组成，这些子阶段通常被称为序列，如果它们都存在，将执行的操作序列分组为逻辑单元。 在此上下文中，阶段不是AUTOSAR方法的阶段。
模式可以看作是ECU 全局 变量的当前状态，该变量分别由RTE和调度器。 模式的赋值在模式声明组中完成，而这些组由AUTOSAR软件组件定义。 同时，模式可以用于不同的目的。 一方面，模式可用于同步软件组件和基础软件模块。 通过模式启用和禁用指定的触发器，以防止可执行实体的激活。 此外，可执行实体可以在模式切换期间明确触发。 另一方面，模式开关可以在从一种模式转换到另一种模式时显式触发可执行实体。 例如，在进入特定模式之前，RTE可以激活进入可执行实体来初始化特定的资源。 在此模式下，将激活此可执行实体的触发器。 如果保留模式，就会调用退出可执行实体，该实体可以执行一些清理代码，触发器将被停用。
模式声明
软件组件定义了一个通用的机制来描述AUTOSAR中的模式。 模式是通过模式声明定义的。 模式声明表示全局变量当前状态的可能赋值。 比如，在ECU状态管理中可能存在模式声明起动、运行、后运行、休眠。 模式声明组以枚举组的方式对多个模式声明进行分组。 在给定的示例中，这可以是ECUMODE模式声明组。 对于每个模式声明组，必须定义初始模式，它在起动时分配给变量。 其中包含了模式声明、模式声明组和可执行实体之间的关系。
图 1 关于模式的元模型摘录
模式管理器和模式用户
在模式管理中涉及到两个方面:模式管理器和模式用户。 模式管理器负责切换模式，它们是惟一能够更改全局变量值的实例。 模式管理器可以是软件组件或基础软件模块，前者需要提供一个模式请求端口，后者需要提供一个模式声明组。 模式用户通过定义良好的机制获知模式切换，并且可以随时读取当前活动模式。 如果模式用户想要切换到不同的模式，可以从相应的模式管理器请求模式切换。
RTE中的模式
模式的概念是通过RTE实现的。 RTE为原子软件组件的每个模式声明组原型创建一个叫做模式机实例的状态机，它的每个状态由各自的模式声明来定义。
图2 RTE的实例化
图2.2描述了模式管理器和模式用户之间的交互。 注意，模式用户的模式切换端口并不直接连接到模式管理器的相应端口，而是连接到RTE的模式机实例。 这对于理解RTE内部的模式切换机制至关重要。 基础软件模块，特别是ECU状态管理器模块，已经区分了ECU状态和ECU模式。 ECU模式是对应用程序可见的更持久的操作ECU状态，即起动、关闭、进入睡眠和唤醒。 ECU管理器状态通常是ECU管理器模块操作的连续序列，直到外部条件满足才终止。 例如，起动状态，包含操作系统起动之前的所有BSW初始化，当操作系统将控制返回给ECU管理器模块时终止。 通过灵活的ECU管理，在BSW模式管理器模块的控制下，ECU状态机实现了通用模式。 简单来说，状态只在内部使用，对应用程序不可见。 为了与应用程序进行交互，基础软件必须使用模式。
BSW调度器中的模式
类似RTE为软件组件提供的模式，BSW调度器为BSW模块提供类似的模式通信机制。 如果BSW模块在其描述中提供一个模式声明组原型作为提供模式组，那么BSW调度程序就会实例化一个模式机实例，为BSW模块提供模式切换API，来使能模式切换。 模式用户必须将模式声明组原型引用为需求模式组，并将获得模式API来读取当前处于工作状态的模式。 对于BSW模块，模块之间的模式请求可以通过函数调用直接实现。
不同模式的通信
在模式管理器和模式用户之间，软件组件具有以下几种不同的模式通信类型。
模式开关 ： 从一种模式转换到另一种模式的通信。 模式开关是由模式管理器启动。
模式请求 :模式用户向模式管理器提出的进入特定模式的请求。 值得注意的是，模式管理器请求进入某模式，但是并不保证其能进入此模式。 另外，它必须仲裁来自模式用户的所有请求，并决定其将进入哪种模式。 在此基础上，给出了多核ECU模式代理的概念和模式间通信的信息。
模式开关
与不同SW-C之间或SW-C与BSW之间的通信一样，模式是通过端口原型进行通信的。 每个端口原型都必须由端口接口输入。 在模式通信中，存在所谓的模式切换接口，即端口接口。 如图2.3所示，每个模式切换接口都有一个由多个模块声明组原型。 任何模式声明都表示模式声明组的一种模式，当然，其中一个定义是初始模式。
图3 模式切换接口
这些模式切换是必要的，因为软件组件需要能够响应由模式管理器发出的状态更改。 根据配置的不同，有两种机制可用，即软件组件如何对模式更改作出反应：
模式切换事件可以触发进入（OnExtry）、过渡（OnTransition）和进入可运行（OnEntryRunnable）；
在特定模式下，可以禁用RTEEvent，从而阻止协调的可运行实体的执行。
模式请求
模式请求分布在从模式请求者到模式管理器的过程中，这里提到的模式请求者主要是模式仲裁SWC或通用SWC。 每个ECU上的模式管理器必须决定并启动本地的模式切换。 因此，仲裁结果仅在每个ECU上使用RTE模式切换机制进行本地通信。
对于模式请求，模式之间的通信工作方式与模式切换略有不同： 没有模式声明组。 模式的请求是通过标准的发送-接收接口完成的。 与模式开关接口相反，所请求的模式不是由模式声明组提供的，而是由包含枚举的可变数据原型提供。 此枚举由一组包含可请求模式的集合组成。
模式请求可以分布在整个系统中。 对于应用程序和车辆模式，模式请求者的请求必须分发到所有受影响的ECU。 这意味着模式请求者和模式管理器之间存在1:n的连接。 模式管理器只需要请求模式的有关信息，而不需要模式从模式请求程序中切换。 模式管理器为每个模式请求者提供一个发送-接收端口。 为了实际传输信号，COM应该使用一个周期信号，并通知RTE信号超时，模式管理器将使用数据元素过期事件来释放模式请求。
模式开关和模式请求的一致性
如上所述，模式开关接口使用模式声明组，而模式请求接口通过包含枚举的可变数据原型接收参数。 配置 应 用程序负责确保在两种表示中表示数据的一致性。 这意味着枚举的元素必须与模式声明组的元素精确匹配。 换言之，在一个接口中可用的所有模式在另一个接口中也必须可用。
模式代理
当前AUTOSAR有一个限制，即只允许本地软件组件与服务组件通信。 因此，软件组件不可能从其他控制器的BSW模式管理器请求模式。 为了克服这个限制，AUTOSAR引入了服务代理组件类型。 图2.4描述了这个概念。
图3 服务代理组件的通信
对于应用软件和RTE, 服务代理组件类型的行为类似于“普通”原子组件类型，但它实际上是AUTOSAR的服务代理。 这意味着一方面，它必须通过服务端口与它所代表的ECU本地服务软件组件类型通信。 另一方面，它必须为应用软件组件类型提供相应的端口原型。 在元模型中， 服务代理软件组件类型 与应用软件组件类型，除了类不同之外没有什么不同。 服务代理软件组件类型之间的主要区别在系统级和应用软件组件类型:原型服务代理软件组件类型可以映射到几个ECU即使它之后的系统只出现一次,因为这样的一个原型ECU是必需的,它必须解决当地服务软件组件类型。 因此，服务代理软件组件类型只能通过网络接收而不能发送信号。
多核ECU的模式通信
RTE能够在ECU的不同分区上同步模式机实体。 这支持这样的配置:提供端口的一个模式声明组原型连接到来自多个分区的请求端口的模式声明组原型。 因此，模式声明组原型的模式用户可以分布在多个分区上。
图5 配置示例
模式机实体在模式转换期间执行10步序列:
激活模式禁用；
等待直到受下模式的模式禁用依赖影响的可执行实体终止；
执行可执行实体退出动作；
等待直到所有可执行实体退出完成；
可执行实体执行过渡动作
等待直到所有可执行实体过渡完成；
可执行实体执行进入动作；
等待直到所有可执行实体进入完成；
失活前一个模式禁用，激活当前模式禁用；
触发模式开关ACK事件。
步骤1到9可以在每个CPU核上并行执行，分别针对分布在相应核上的模式用户。 只有在整个模式机实体的其他步骤已经完成时，才可以执行步骤10。 然而，一些特定于应用程序的用例可能需要更高程度的同步。 因此，RTE提供了配置同步点的机会。
在重新启动分区时，不能将在不同分区上具有模式用户的模式机实体重新初始化为默认模式。 这将干扰其他仍在运行的分区。 因此，处理分区重启的惟一可行策略是将模式管理故障行为中的故障响应策略设置为上一模式，其中指定模式用户保留其最后一个正常模式。
|
