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。

你可能感兴趣的:(Adaptive,Autosar,AUTOSAR)