本系列文章将从以下六个方面来介绍AP平台核心技术：
已分享文章：
AP AUTOSAR硬核技术（1）：执行管理的秘密揭晓
AP AUTOSAR硬核技术（2）：详解状态管理
接下来，让我们来看第4个部分：
执行管理与状态管理的交互
图中展示了状态管理模块和执行管理（EM）模块如何协调功能组状态（Function Group State）的切换的过程。
它们之间的步骤如下：
状态管理模块接收到来自不同来源的状态切换请求（Trigger），例如应用程序、功能集群、平台健康管理、诊断、事件或模式等。它会根据优先级来选择一个请求，并通知EM模块。
状态管理模块通过服务接口SetState来告诉EM模块需要切换到哪个功能组状态。
EM模块根据SM模块返回的状态结果来启动start或停止stop相应的应用程序进程，并配置它们的参数。
状态管理模块通过服务接口GetState来获取当前的功能组状态。
状态管理模块还可以把当前的功能组状态的结果返回给请求切换状态的进程，以便进行相应的操作。
AP 状态管理是一种控制 AP 平台和应用程序的运行状态的组件。
状态管理通过ara::com 提供了一组Triger和Notifier field接口。
SM本质上是监听Triger，并在内部执行特定于实现的状态机处理，如果有Triger字段，则为其提供仲裁结果。
状态切换是指从一个状态转换到另一个状态的过程，状态切换的Triger来源有以下几种：
应用程序（Application）：应用程序是指在 AP 平台上运行的软件单元，它可以通过 ara::com 服务接口向 SM 模块发送状态切换请求，例如请求从运行状态转换到关闭状态（Shutdown State）。
功能集群（Functional Cluster）：功能集群是指按照服务和自适应 AUTOSAR 基础进行分组的模块，例如通信管理，更新和配置管理UCM等。功能集群可以通过标准接口向 SM 模块发送状态切换请求，例如请求从关闭状态转换到启动状态。
平台健康管理：PHM 是一种监控和恢复 AP 平台和应用程序的故障的组件，它可以根据故障的严重程度和影响范围向 SM 模块发送状态切换请求，例如请求从运行状态转换到诊断状态（Diagnostics State）。
诊断（Diagnostic）：诊断是指检测和修复 AP 平台和应用程序的问题的过程，它可以通过诊断接口向 SM 模块发送状态切换请求，例如请求从运行状态转换到复位状态（Reset State）。
事件或模式（Event or Mode）：事件或模式是指影响 AP 平台和应用程序运行的外部或内部因素，例如车辆速度，电池电量，用户输入等。事件或模式可以通过事件或模式接口向 SM 模块发送状态切换请求，例如请求从运行状态转换到休眠状态（Sleep State）。
状态管理是一个项目特定的组件，只有接口和职责是标准化的。内部逻辑定义仍然在每个项目的责任范围内。
下图为状态管理提供的接口图，用于获取和设置其内部状态。
图中的App A B C是属于同一个功能组（MachineState）的进程，它们在Startup状态下运行。
“MachineState”实际上是功能组的一个特例
当它们中的一些进程需要改变状态时，它们会向状态管理（SM）模块发送请求。
SM模块会根据优先级来选择一个状态切换请求，并通知执行管理（EM）模块。
EM模块会把功能组的状态从Startup切换到Shutdown，并执行相应的操作。
在Shutdown状态下，进程App A仍然运行，进程App B和C被停止，进程App D被启动并运行。
在AP平台中，每个进程都属于一个功能组，功能组定义了进程在不同的状态下是否需要运行。状态管理（SM）负责请求功能组的状态转换，执行管理（EM）负责根据请求启动或停止进程。
为了保证进程的正常运行，AP平台有以下的规则：
不同功能组之间的进程不能互相依赖，否则可能导致进程在错误的状态下被启动。
每个功能组是一个独立的实体，它的状态转换只影响它自己的进程，不影响其他功能组的进程。这是EM的视角，而SM则需要考虑不同功能组之间的状态机逻辑。
状态转换是一个复杂的过程，但有三个基础逻辑步骤：
终止所有当前正在运行，但请求的状态下不需要的进程
重启所有当前正在运行，并且当前状态下启动配置和请求状态下的启动配置不一致的进程
启动所有现在没有运行，但请求状态下需要的进程
EM判断进程是否在运行，是检查进程状态是否在Idle或Terminated，如果是，则说明进程是停止状态
这个案例是AP平台的启动流程，它涉及到执行管理和状态管理两个模块的交互。
我想从以下几个方面来描述这个流程：
OS初始化后，EM作为第一个进程被启动，它负责平台和应用的初始化、启动和停止。
EM运行后，它首先创建并启动状态管理进程，SM负责管理平台和应用的状态转换。
SM启动后，它通过ReportExecutionState API向EM报告自己的执行状态为Running，表示状态管理已经准备好工作。EM收到报告后返回kSuccess，表示EM已经确认SM的状态。
SM收到EM的确认后，它通过SetState API向EM请求将Machine State切换为Driving，表示平台已经进入驾驶模式。EM收到请求后执行相应的操作，并返回kSuccess，表示Machine State已经切换成功。
这是关于AP平台的状态管理和执行管理模块之间的交互案例，它展示了如何通过SetState和ReportExecutionState API来实现Machine State和Function Group State的切换。
我想从以下几个方面来描述这个案例：
首先当某一条件触发时，状态管理通过SetState API向EM请求将Machine State功能组的状态改为StateXYZ，表示平台需要进入一个新的状态。
执行管理根据Machine Manifest和Execution Manifest文件中的信息，确定哪些进程属于Machine State功能组，以及它们在不同状态下的行为。
执行管理根据配置信息，终止App1进程，并等待它释放资源和退出。
其次，执行管理创建并启动App2进程，并分配资源和配置给它。
App2启动后，通过ReportExecutionState API向EM报告自己的执行状态为Running，表示App2已经准备好工作。
最后，当执行管理收到App2 Running的报告后，完成Machine State功能组的状态切换。
这是关于AP平台的进程状态依赖运行流程，它说明了不同的功能组和状态如何影响进程的启动和停止。
我想用以下的信息来描述这个流程：
进程A只在MachineState功能组的Startup状态下运行，它是一个一次性的进程，执行完就结束了。
进程B在MachineState功能组的Startup和Running状态下运行，它要等进程A结束后才能启动，这是通过配置文件设置的。
进程C只在MachineState功能组的Running状态下运行，当MachineState功能组要切换到Diagnostics状态时，它就要停止。
进程D和E在功能组1 的Running状态下运行，它们之间没有启动或停止的依赖关系，执行管理可以随机地启动或停止它们。
进程F在功能组2 的Running状态和Fallback状态下运行，它在不同的状态下有不同的启动参数，所以当功能组2 从Running状态切换到Fallback状态时，它要先停止再重新启动。
系统设计和集成要保证Machine在任何时候都有足够的资源供所有需要运行的进程使用，也就是说要考虑所有引用当前活动状态的进程的资源需求。
状态管理模块和执行管理模块如何协调功能组状态（Function Group State）的切换呢？
功能组状态是指每个功能集群（Functional Cluster）的运行状态，例如启动，运行，关闭等状态。
状态管理根据系统状态和功能组状态的变化，决定是否启动或停止应用程序。因此，应用程序需要向EM注册，以便EM能够监控和控制应用程序的状态。
它们之间的过程如下：
1 状态管理模块接收到来自不同来源的状态切换请求（Trigger），它会根据优先级来选择一个请求，并通知EM模块。
如：状态管理通知执行管理将功能组1，从状态1切换到状态2，
2 执行管理模块根据应用程序的配置文件，找到应用程序所属的功能组和对应的系统状态。
图中的功能组在当前状态1时，功能组中的大部分进程都处于idle的状态
功能组在目标状态2时，功能组中的一些进程将切换到运行的状态。
3和4 执行管理模块根据功能组的当前状态1和目标状态2，启动或停止应用程序，并且创建或销毁进程和资源。
5 应用程序在启动或停止的过程中，会通过ReportExecutionState接口向执行管理模块报告自己的运行状态，比如正在启动、正在运行等。
6 执行管理模块在收到应用程序的运行状态后，会给状态管理模块返回一个状态切换成功或失败的信号。
同理，状态管理请求执行管理将功能组从状态2切换到了状态3，以此来改变功能组中进程的执行状态：
如从running状态切换到Terminating，此时进程会通过ReportExecutionState接口向执行管理报告自己的运行状态，正在停止Terminating。
执行管理模块在收到应用程序停止的运行状态后，会给状态管理模块返回一个状态切换成功或失败的信号。
这就是通过状态管理来触发功能组状态切换，到执行管理去执行功能组状态切换的过程。
自适应应用程序Adaptive Application是一种按照AUTOSAR标准来开发的应用程序，它可以满足用户的不同需求。
完整的自适应应用程序不是一个单独的实体，而是由以下几部分组成的软件包：
可执行文件（Executable File）：一种包含应用程序代码和入口点的二进制文件，可以在机器上运行。一个应用程序可以由一个或多个可执行文件组成。
数据和元数据（Data and Metadata）：一种包含应用程序的配置和参数的文件，可以在运行时被读取或修改。
执行清单（Execution Manifest）：描述应用程序的属性和服务实例的XML文件，它在集成阶段被创建，并在部署阶段被处理和部署到机器上。执行清单提供了将应用程序部署到AP平台上所需的信息。
使用自适应应用程序的优点是，它可以保持软件和部署的分离，这意味着：
我们可以在同一台机器上创建多个应用程序实例，它们使用同一个可执行文件，但有不同的数据和元数据。
我们可以将软件部署到多台机器上，并为每台机器创建不同的应用程序实例，它们使用不同的数据和元数据。
集成器将描述中的信息与机器清单相结合，创建一个可部署的软件包deployment package ，它包含了应用程序的可执行的文件和清单，配置文件和依赖的库等
图中我们将执行管理过程分为两个部分：
1、Off-board：中的开发和集成，以生成可执行文件和清单的部署包（我们上一页PPT介绍了这部分内容）
2、On-board：是应用程序的部署流程，把开发好的软件放到用户的Machine上，让它能够正常运行的过程。
这个过程一般分为以下几个步骤：
软件配置管理人员把软件打包成一个部署包并拷贝到需要部署的Machine上，部署包里包含了软件的可执行文件、清单文件和其他必要的文件。
执行管理负责把部署包中的软件安装到用户的Machine上。它会先读取清单文件，了解软件的相关信息，然后申请系统资源，比如内存、磁盘空间等，创建进程，把可执行文件复制到指定的位置，并设置好运行环境。
应用程序进程：应用程序进程是软件运行时产生的一个或多个进程，它们使用标准化的API和服务与平台（执行管理、操作系统、其他功能集群）交互，完成软件的功能。
本文作者：刘向，汽车嵌入式工程师
-end-
本专栏是由汽车电子与软件打造的中立性技术科普专栏，将系统地阐述软件定义汽车下的关键挑战和工程实践。欢迎订阅本专栏！
