Autosar AP – SM职责

最新推荐文章于 2024-06-27 14:02:24 发布

小火球2.0

最新推荐文章于 2024-06-27 14:02:24 发布

阅读量2.5k

点赞数

分类专栏：车载技术文章标签： p2p 网络协议网络

本文链接：https://blog.csdn.net/wangxu696200/article/details/123332617

版权

车载技术专栏收录该内容

14 篇文章 25 订阅

订阅专栏

■ Function Group(功能组)

Function Group即一组相互关联，需要统一控制的进程的集合。依据Function Group的状态，启动进程或者终止进程。

在AUTOSAR中，Function Group的状态被称为Function Group State。主要和用户级应用有关。

每一个应用都可以在Execution Manifest中定义在那些Function Group States的情况下，它的进程可以运行。

■ SM内部状态

状态管理是负责确定当前内部状态的功能集群，SM接收可能改变内部状态的事件，并对事件进行评估：

▪ 事件类型 Event type (根据项目需求定义)

▪ 事件优先级 Event priority (根据项目需求定义)

▪ 应用标识符 (在R21-11中不支持)

如果触发了SM内部状态的修改，可能要去请求EM将Function Groups或者Machine State设置为新的状态。

状态修改请求可以来自这些AUTOSAR Adaptive平台应用：

▪ PHM触发了错误恢复，例如激活后备功能

▪ 诊断请求切换到其他的诊断状态，并且触发了系统重启

▪ UCM模块将系统切换到升级或者升级验证状态

▪ NM模块设置网络状态。NM并不会主动请求，NM提供几组NetworkHandle字段，SM可以注册到这些handle并在NM更改这些字段时进行相应处理

SM会最终根据项目需求做出决定。

■ SM内部状态

AP应用会通过ara:com接口提供他们的属性或者事件给到SM，以触发SM内部事件。由于SM功能非常关键，必须保证其他应用的访问是受保护的（例如借助IAM模块）。

▪ SM模块应当被PHM模块监控并监管

▪ SM通过 ara::com 提供了一系列的 Trigger 和 Notifier fields。SM 监听 Triggers，执行状态机处理，将影响提供给 Notifier

状态管理中定义了Machine state和function group state功能组状态的当前集合，并通过反馈状态改变的请求给执行管理(EM)它们来启动状态转换。

■ MachineState 机器状态

Machine State是Function Group State的特殊类型。

1. EM要求每个机器至少配置有一个功能组，这个功能组叫做“机器状态”功能组，它的功能组状态叫做机器状态，代表了机器的全局状态。主要用于控制机器生命周期（启动/关闭/重启）、平台级进程和其他基础设施。

2. “机器状态”功能组有一些标准强制的状态，除此以外，也可以根据需求定义其他的状态，在machine manifest中定义。EM本身并不会去由自身触发状态变更，都需要由SM来统一管理，为了在任何状态下，其他应用都能影响状态的改变，SM需要保证被配置在Manifest文件中所有状态，包括启动，关闭和重启状态下，都需要运行。

▪ Startup

▪ Shutdown

▪ Restart

3. AUTOSAR标准定义了许多预定义的MachineState状态，也可以根据需要定义其他状态。

功能组状态(包括机器状态)，定义了当前运行的进程集合。每个APP可以在Execution Manifests里声明它应该在哪个功能组状态里运行。机器状态(包括其他功能组状态)由SM来请求，活动的状态集受车辆范围内的事件和模式显著的影响。

■ MachineState 机器状态

Machine State是Function Group State的特殊类型。

▪ Startup

▪ Shutdown

▪ Restart

3. AUTOSAR标准定义了许多预定义的MachineState状态，也可以根据需要定义其他状态。

■ Function Group State 功能组状态

如果在机器上安装了一组功能一致的应用，那么有一起控制它们的能力是很重要的，因此AP提出了功能组的概念。

每个功能组有着它自己的进程集和状态集(功能组状态)，每个功能组状态定义了当SM请求激活哪个状态时，哪些进程将会被EM启动，每个功能组至少有一个进程，最多由实现限制。作为一个控制应用的进程启动和停止的工具，系统集成者可以将进程分配到功能组状态，然后用SM来请求它。

主要用于单独启动和停止功能一致的用户级应用程序进程组，即用于控制（通常是功能上的）相关应用程序实例的执行。它们可以在机器清单中配置。

▪ 过程状态：流程状态用于应用程序生命周期管理，由执行管理内部状态机实现。

▪ 执行状态：执行状态表征应用程序可执行文件（即进程）的任何实例的内部生命周期。每个进程必须向执行管理报告执行状态更改。

▪ 实例的执行状态：此状态由应用程序实例本身在内部管理，例如使用ReportExecutionState API，因此不受状态管理功能集群的控制。

总得来说，机器状态用来控制机器和平台级别的应用的生命周期（启动/停止/重启），其他的功能组状态单独控制属于同一功能的用户级别应用，当然这并不意味着所有的平台级应用都必须要被机器状态控制。

一个进程必须分配到一个，且只能分配到一个功能组。

■ SM架构

AUTOSAR_SWS_StateManagement.pdf

-> 5.1 Platform dependencies

SM对平台依赖如下：

1. Operating System Interface

2. Execution Manager Interface

3. Platform Health Management

4. Diagnostic Management

5. Update And Configuration Management

6. Network Management

■ SM和APP交互

当EM需要改变进程的内部行为时，它需要将进程从中存储中移除，然后将可执行程序从文件系统载入到内存当中。这样的操作非常消耗带宽，CPU负载和执行时间。

因此，SM提供一个带有“Notifier" Field的服务接口，每一个AP应用都可以订阅它，每当SM内部状态发生改变时都可以通过这个接口通知到应用。当应用收到这个提醒后，可以执行相应操作。

相反地，AP应用也可以借由SM带有"Trigger" field的接口，影响SM的行为。当然，你需要把这个AP应用配置相应的权限，否则无法通过这个field写入任何值。

SM还提供第三种接口，它既有Trigger又有Notifier，当Trigger值发生变化时，SM根据Trigger值进行相应操作，最终也会改变Notifier并通知。

"Trigger" field - TriggerIn_{StateGroup}

" Notifier " field - TriggerOut_{StateGroup}

■ 多个APP同步

Autosar Ap在某些场景需要更复杂的处理，SM内部状态的改变只能是相关的模块处理触发专用状态时才能完成。目前SM有两个不同的用例：

1. 针对电源模式，通知机器中所有运行的模块处理；

2. 针对诊断重置原因，通知所有运行的模块处理；

●

为了处理不同Modelled Processes组的通信，提出了通信组的概念。

通信组，服务端：

1. 向组内所有客户端广播消息；

2. 向组内专用客户端发送消息

3. 获得所有组内客户端表

4. 接收组内所有客户端回复

通信组，客户端：

1. 从服务器接收消息

2. 向服务器发送回复

■ 针对APP(包括平台APP)的电源模式