老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

本就是小人物，输了就是输了，不要在意别人怎么看自己。江湖一碗茶，喝完再挣扎，出门靠自己，四海皆为家。人生的面吃一碗少一碗，人生的面见一面少一面。人生就是一次次减法，来日并不方长。自己的状态就是自己最好的风水，自己的人品就是自己最好的运气。简单点，善良点，努力点，努力使每一天都开心，不为别人，只为自己。

本文大体如下：

1、操作系统概述

2、执行管理

3、状态管理

一、操作系统概述

操作系统(OS)负责自适应平台上所有应用程序的运行时调度、资源管理(包括监控内存和时间限制)以及Process间通信。OS与执行管理(Execution Management)协同工作，后者负责平台初始化，并使用OS 执行应用程序的启动和关闭。

自适应平台并没有为高性能处理器指定新的操作系统。相反，它定义了一个执行上下文和操作系统接口(OSI)，供自适应应用程序使用。

OSI规范包含的应用接口是ARA(自适应应用的标准应用接口)的一部分。OS本身也可能提供其他接口，如创建 Process，这是执行管理启动应用程序所必需的。但是，ARA 并不提供此类功能的接口，而且其定义取决于平台的实现。

POSIX

市场上有几种操作系统(如 Linux)提供与POSIX兼容的接口。但是，与平台服务和基础相比，应用程序必须使用更受限制的 API与操作系统连接。

一般假设是，用户应用程序应使用PSE51作为OS接口，而平台应用程序可使用完整的POSIX。如果应用层需要更多的功能，将尽可能从 POSIX 标准获取，而不是重新指定自适应平台基础和自适应平台服务功能的实现可能会使用更多的 POSIX 调用。具体调用的使用将由实施者自行决定，不会标准化。

调度

操作系统提供多线程和多Process支持。标准调度策略是POSIX 标准定义的SCHED FIFO 和 SCHED RR。允许使用其他调度策略，如SCHED DEADLINE 或任何其他操作系统特定策略，但这些策略可能无法在不同的 AP 实现中移植。

内存管理

支持多 Process 的原因之一是实现不同功能集群和 AA 之间的"无干扰"。OS 对多Process 的支持迫使每个 Process 都处于独立的地址空间，与其他 Process 分离并受到保护。同一可执行文件的两个实例在不同的地址空间运行，因此它们可能共享相同的入口点地址、代码以及启动时的数据值，但数据将位于内存的不同物理页中。

设备管理

设备管理在很大程度上与操作系统有关。自适应平台基金会有意倾向于创建服务来公开主要的系统功能。

虽然目前还没有计划对设备驱动程序本身的具体 APIS 进行标准化，但可以通过自适应平台服务对这些驱动程序实现的更高级功能进行标准化。

联网

多台 Machine 之间以及与其他传感器之间的主要互连机制预计将基于以太网。因此，TCP/IP-and UDP/IP-based 协议的使用已得到明确说明。因此，预计操作系统将提供这样一个网络堆栈。

应用程序将通过使用通信管理从网络支持中获益。作为自适应平台基础的一部分，VLAN、IPSEC 等附加功能可实现系统内和系统间的安全通信。

二、执行管理

2.1 概述

执行管理负责系统执行管理的各个方面，包括自适应平台的初始化和Process 的启动/关闭。执行管理与操作系统协同工作，配置 Process 的运行时调度。

2.2 系统启动

Machine 启动时，OS 将被初始化，然后执行管理将作为平台的初始 Process 启动。随后，执行管理将启动自适应平台基础的其他平台级 Process(代表功能集群)。自适应平台基础启动并运行后，执行管理将继续启动自适应应用程序的Process。平台级Process 和应用程序级 Process 的启动顺序由执行管理根据 Machine 清单和执行清单中指定的依赖关系来决定。

AP start-up sequence

自适应应用程序可由多个可执行元素组成，这些元素通常与文件系统中的可执行文件相对应。每个可执行文件可以有多个 Process 配置，因此启动配置也取决于可执行文件处于活动状态的功能组状态。

执行管理可选择支持验证启动，即从信任锚点启动自适应平台，同时保持信任链。在验证启动过程中，执行管理会验证应用程序的真实性和完整性，如果检测到违规行为，执行管理会(有选择地)阻止其执行。通过这些机制，可以建立一个可信平台。

2.3 执行管理职责

执行管理负责自适应平台执行管理和应用程序执行管理的所有方面，包括：

1、平台生命周期管理执行管理是自适应平台启动阶段的一部分，负责自适应平台和已部署应用程序的初始化。

2、应用程序生命周期管理执行管理负责已部署应用程序的有序启动和关闭。执行管理根据 Machine 清单和执行清单中的信息确定部署的应用程序集，并根据已声明的执行依赖关系得出启动/关闭顺序。根据 Machine 状态和功能组状态的不同己部署应用程序的 Process 会在自适应平台启动时或稍后启动，但并不是所有应用程序都会立即开始工作，因为许多应用程序会向其他应用程序提供服务，因此需要等待和"监听"传入的服务请求。

执行管理部不负责应用程序的运行时调度，因为这是操作系统的职责。但是，执行管理负责 OS 的配置，使 OS 能够根据执行管理从 Machine 清单和执行清单中提取的信息执行必要的运行时调度。

2.4 确定性执行

确定性执行提供了一种机制，使使用给定输入数据集进行的计算总能产生一致的输出而不受干扰影响。执行管理区分时间确定性和数据确定性。前者是指输出总是在截止日期前产生，而后者是指从相同的输入数据集和内部状态产生相同的输出。

执行管理提供的支持侧重于数据确定性，因为时间确定性是通过提供充足的资源来处理的。在数据确定性方面，执行管理提供了 DeterministicClient APIs，以支持对 Process内部循环、确定性工作池、激活时间戳和随机数的控制。DeterministicClient 与通信管理交互，使数据处理与周期激活同步。

2.5 资源限制

自适应平台允许在同一台 Machine 上执行多个自适应应用程序，因此确保不受干扰是一个系统属性。因此，应限制行为不正确的自适应应用程序影响其他应用程序的能力例如，应防止应用程序 Process 消耗超过规定的 CPU时间，因为这可能会影响其他应用程序的正常运行。

执行管理支持通过配置一个或多个 ResourceGroups 来避免干扰，应用程序的 Process 被分配给这些 ResourceGroups。然后，可为每个 ResourceGroup 分配 CPU 时间或内存限制，以限制应用程序的可用资源

2.6 可信平台

为保证系统功能的正确性，必须确保在平台上执行的代码来源合法。集成商可通过保持这一属性来构建可信平台。

实现可信平台的系统的一个关键属性是可信锚点(也称为可信根)。信任锚通常以公开密钥的形式实现，它存储在一个安全的环境中，如不可修改的持久内存或 HSM 中。

系统设计者有责任至少确保系统从信任锚点开始，并在执行管理启动前保持信任。根据系统设计者选择的建立信任链的机制，整个系统的完整性和真实性可能已在系统启动时进行了检查。但是，如果系统设计者只确保已执行软件的完整性和真实性已得到检查，那么执行管理就会在接管系统控制权时接手继续执行信任链的责任。在这种情况下，系统集成商有责任确保正确配置执行管理。

从信任锚向 OS 和自适应平台传递信任(即建立信任链)的一个示例如下:根据定义,信任锚是一个真实的实体，它在引导加载器启动前对引导加载器进行验证。在启动过程的每个后续步骤中，应首先对即将启动的可执行文件进行验证。真实性检查应由已通过验证的实体完成，即真实性检查可由之前启动的可执行文件或 HSM 等外部实体完成。

OS 经过身份验证启动后，应将"执行管理"作为第一个 Process 启动。在启动"执行管理"之前，OS 应确保"执行管理"的真实性已由通过验证的可信实体验证。

注：如果认证不是由信任锚点本身的功能来检查(根据定义，信任锚点本身就是真实的)，那么用于验证可执行文件真实性的软件在使用前就必须经过认证。例如，如果Crypto API用于验证可执行文件的真实性，那么 Crypto API本身在使用之前就必须经过某个可信实体的验证。

三、状态管理

状态管理是一个独特的功能集群，主要针对 ECU 开发项目，一般由系统集成商负责最终实施。它负责 AUTOSAR 自适应平台运行状态的所有方面，包括处理传入事件、确定这些事件/请求的优先级以设置相应的内部状态。根据项目需要，状态管理可由一个或多个状态机组成。

如下所述，状态管理通过由"字段"组成的项目特定 ara::com 服务接口与自适应应用程序进行交互。状态管理与其他功能集群之间的交互应通过各功能集群定义的标准化接口进行。

State Management interactions状态管理交互

状态管理可要求以下效果:

-> 1、可要求将 FunctionGroups 设置为专用状态；

-> 2、可请求删除/激活(部分)网络；

-> 3、可请求关闭或重启 Machine；

-> 4、可影响其他自适应(平台)应用程序的行为；

-> 5、可执行特定于项目的操作；

-> 6、在收到平台健康管理或执行管理通知时，从(监督)错误中恢复；

-> 7、应诊断的要求，根据诊断地址执行特定项目重置；

-> 8、根据更新和配置管理的要求，准备并验证软件集群的安装、更新或删除；

-> 9、影响运行 Process 的行为，以实现 Machine 内部(部分)的同步行为(如电源模式）。

为实现同步行为，状态管理提供了已定义的消息和回复消息，在通讯管理的通讯组范围内，可从这些消息和回复消息中生成 ara::com 方法和字段。

状态管理通过 ara::com 提供一组"触发器"和"通知器"字段。SM 本质上是监听"触发器"，并在内部执行特定状态机处理，如果"otifier"字段有效果，则将效果提供给"Notifier"字段。

由于状态管理功能至关重要，因此必须确保从其他功能组或应用程序的访问安全，如通过 IAM(身份和访问管理)。状态管理由平台健康管理进行监控。

状态管理引入了"轻量级"StateMachine 方法，以帮助自适应平台用户创建状态管理功能。StateMachines 的设计旨在以最少的配置工作覆盖标准用例。请注意，StateMachines 是 AUTOSAR 的补充部分，因此可以选择使用。预计复杂的用例仍需要用户提供源代码

StateMachine 不执行特定项目的逻辑。相反，它为特定项目的自适应应用程序(即SMControlApplication)提供输入接口。该应用程序包含项目专用逻辑，并决定下一光应请求 StateMachine 的哪种状态。请注意，对执行管理和/或平台健康管理报告的错误的反应是直接在 StateMachine 内部配置的。

Overview of ’lightweight’ StateMachine concept

为了概述 StateMachine 方法，下图显示了不同的 StateMachine 实例、相应 StateMachine 的接口、TransitionTable 和 ErrorRecoveryTable 的交互方式。

StateMachine concept - Big picture

愿你我相信时间的力量

做一个长期主义者！