State Management SWS 总结

花了一两天时间，把SM的SWS又草草看了一遍。

温故而知新，每次阅读都会有些惊喜。

SM概览

SM是决定整个平台的状态。属于是平台管理的核心模块之一，如果说系统需要进行一些设计或者架构的话。

SM主要和EM及PHM交互。也和APP及NM、诊断DM等东西交互。

主要任务就是根据外部输入和状态、进行状态切换。切换Machine的状态、切换Function Group的状态。调用EM这个工具人来启停FG。通过服务接口中的Notifer和Trigger来和APP交互，影响APP或者被APP影响。

SM用了很多AP内部接口，而不是ARA接口。ARA是给APP用到。SM是平台应用。

而前面说的，服务是通过CM的机制来提供，这意味着，过于细节的调度，可能通过SM来实现会显得不够敏捷。

所以，SM的状态，影响的对象，应该是FG，也就是为了完成某一个功能而联合起来的一系列进程。

SM依赖的功能簇

SM不直接使用操作系统接口，在架构设计中，和操作系统相关的内容被EM封装和执行。SM负责仲裁和决策。SM会告诉EM要进入的状态，然后EM再去执行。

PHM管理整个平台的健康，本质是狗。会依照自己的输入，算出一个健康状态，如果有异常，会通知SM处理，如果SM不处理，例如超时之后，PHM自己也会下场处理。

DM和SM的交互在于SM进入诊断专用状态保护系统不休眠，或者被诊断要求切状态复位等协作。

SM和UCM，例如SM保护UCM更新软件过程中不休眠。

SM也管理NM。他可以禁用谁谁的网络，通过当前状态下要操作的NetworkHandle，来管理某些局部网络的使能。

SM的职责

SM需要在所有的Machine State中保持运行。要不然没人切状态了

SM里面可能会维护多个状态机，在进入状态的时候，按照顺序执行ActionList里的各个ActionListItem。这些Item的内容可能是 切换某个FunctionGroup或者Machine的状态、SYNC、开启新的状态机。SYNC是因为，在SYNC之前，ActionList中的item是并行执行的。到了SYNC等一等，等大家都干完了，再继续下面的Item. 实现先后顺序。

SM也要被PHM监控。

对于外部输入事件，SM判断：

• Event type

• Event priority

• Application identifier

常见可能改state的外部平台输入：

PHM

DM

UCM

NM

和EM交互

OS自动启动EM -->EM 启动SM

SM问EM现在是什么状态-->SM切EM状态

要为SM关闭后的Error设置特定的处理机制，因为不再有人报告和切状态了

State

Machine State一般描述 startup run shutdown之类的，只有几个。来进行初始化或者有顺序的收尾工作。为了更灵活的状态切换，使用了Function Group State。

对EM来讲，各个FG之间是独立的。但是对SM来讲，可能启停是有先后顺序的。这由集成人员来配置部署。

另外，可以通过标定来影响state下FG启停策略。实现变体。

SM架构

AP只定义接口 描述逻辑和框架的结合形式。逻辑要自己开发。

SM和APP之间交互，通过Trigger和Notifer接口。可以实现APP之间状态传递、系统或者APP内状态切换等灵活的操作。

在此基础上，SM还通过CM的CommunicationGroup实现类似于广播的状态传递方式。可以一下子影响很多APP的状态。

在此基础上，有提出了APP PowerMode的功能。实现类型“延迟唤醒”。可以减少从关机过程中突然唤醒重新启用功能花费的时间。也可以为关机做好准备更快的休眠。我觉得是类似于关机过程中的缓冲状态，先把事情干完，但是东西还保留。要起来也快，要睡下去也快。

SMControlApplication

看起来 似乎是 开发一个独立于SM的控制SM的APP来进行状态仲裁。

如果不需要仲裁 只是处理EM和PHM的反馈和要求，则不需要开发这个APP。