Adaptive Platform AUTOSAR(AP)平台设计(4)——执行管理

Hello!大家好!

本篇是AP AUTOSAR平台设计(4)——执行管理

AP和CP相关资料获取和工具咨询、更多精彩内容欢迎订阅微信公众号“搞一下汽车电子”

整理不易,如果觉得不错,点赞分享支持一下吧~

邮箱:[email protected]

微信:shactiontech


1.概览

执行管理负责系统执行管理的所有方面,包括平台初始化和应用程序的启动/关闭。

执行管理与操作系统结合使用,以执行应用程序的运行时调度。


2.系统启动

启动计算机后,将首先初始化操作系统,然后启动执行管理作为操作系统的初始过程之一。然后,执行管理将启动Adaptive Platform Foundation的其他功能集群和Application-Level类型的应用程序。

Adaptive Platform Foundation启动并运行后,执行管理将继续启动Adaptive Applications。Platform-Level类型的应用程序和Application-Level类型的应用程序的启动顺序由执行管理根据Machine Manifest和执行Manifest信息确定。

图1 AP启动顺序

执行管理(可选)支持经过身份验证的启动,其中从信任“锚”开始,在保持信任链的同时启动Adaptive Platform。在经过身份验证的启动过程中,Execution Management会验证应用程序的真实性和完整性,如果检测到违规,将阻止其执行。

通过这些机制,可以建立可信平台。


3.执行管理责任

执行管理负责Adaptive Platform执行管理和应用程序执行管理的所有方面,包括:

①平台生命周期管理

执行管理是Adaptive Platform启动阶段的一部分,它负责对Adaptive Platform和已部署的应用程序进行初始化。

② 应用程序生命周期管理

执行管理负责部署的应用程序的有序启动和关闭。执行管理根据Machine Manifest和执行Manifest中的信息确定已部署应用程序的集合,并根据声明的应用程序依赖性导出启动/关闭的顺序。根据Machine状态和Function Group状态,已部署的应用程序会在Adaptive Platform启动或更高版本期间启动,但是,由于许多应用程序将为其他应用程序提供服务,因此,预计不会所有的Application立即开始活动工作。

执行管理不负责应用程序的运行时调度,因为这是操作系统的事。

但是,执行管理负责OS的初始化/配置,以使其能够根据执行管理从Machine Manifest和Execution Manifest中提取的信息执行必要的运行时调度。


4.确定性执行

确定性执行提供了一种机制,使得使用给定输入数据集进行的计算始终在限定时间内产生一致的输出。执行管理区分时间和数据确定性。前者指出输出总是在截止日期之前产生的,而后者则指从相同的输入数据集和内部状态产生相同的输出。

执行管理提供的支持集中于数据确定性,因为它假定时间确定性已通过提供足够的资源来处理。对于数据确定性,执行管理提供了DeterministicClient API,以支持对内部流程的控制,确定性工作人员池,激活时间戳和随机数。对于软件锁步,DeterministicClient与可选的软件锁步框架进行交互,以确保冗余执行的流程具有相同的行为。DeterministicClient与Communication Management进行交互,以使数据处理与周期激活同步。

图2 Deterministic Client说明了DeterministicClient支持的API及其与应用程序的交互

5.资源限制

自适应平台允许在同一台机器上执行多个自适应应用程序,因此确保不受干扰是系统属性。因此,行为不当的自适应应用程序应受到影响其他应用程序的能力的限制,例如,应避免某个应用程序消耗比指定时间更多的CPU时间,因为这可能对其他应用程序的正常运行产生潜在影响。

执行管理通过配置一个或多个分配了应用程序进程的ResourceGroup来支持不受干扰。然后,可以为每个ResourceGroup分配CPU时间或内存限制,以限制应用程序的可用资源。


6.应用程序恢复

执行管理负责流程启动/停止的状态相关管理,因此它必须具有启动和停止流程的特殊权限。平台运行状况管理会监视进程,并可以触发恢复操作,以防任何进程的行为不在指定参数之内。集成商根据平台运行状况管理的软件体系结构要求定义恢复操作,并在执行清单中进行配置。


7.受信任的平台

为了保证系统的正确功能,确保平台上执行的代码具有合法来源至关重要。保留此属性使集成商可以构建受信任的平台。

实施受信任平台的系统的关键属性是信任“锚”(也称为信任根)。信任“锚”通常被实现为存储在安全环境中的公钥。在不可修改的永久内存或HSM中。

系统设计者负责确保至少系统以信任“锚”开始,并保持信任直到启动执行管理。根据系统设计者选择的建立信任链的机制,可能已在系统启动时检查了整个系统的完整性和真实性。但是,如果系统设计者仅确保已经检查过已执行的软件的完整性和真实性,则执行管理在接管系统控制权时将接管继续信任链的责任。在这种情况下,系统集成商负责确保正确配置了执行管理。

从信任“锚”向操作系统和自适应平台传递信任的一个示例(即建立信任链)可能看起来像这样:信任“锚”-根据定义是一个真实的实体-在启动引导程序之前对引导程序进行身份验证。在引导过程的每个后续步骤中,应首先对要启动的可执行文件进行身份验证。真实性检查应由已经过身份验证的实体完成,例如,真实性检查可以通过以下方式完成:例如,由先前启动的可执行文件或某些外部实体(例如HSM)决定。

操作系统可靠启动后,它将启动执行管理作为其第一个过程。在启动执行管理之前,操作系统应确保执行管理的真实性已由已经过身份验证且因此可信赖的实体进行了验证。

注意:如果未通过Trust Anchor本身的功能(根据定义是真实的)检查身份验证,则在应用该软件之前必须对用于验证可执行文件真实性的软件进行身份验证。例如,如果将使用Crypto API来验证可执行文件的身份验证,则在使用Crypto API本身之前,必须先由某些受信任实体对Crypto API进行身份验证。

执行管理现在负责启动自适应应用程序,然后再启动它们。但是,存在不止一种可能性来验证可执行代码的完整性和真实性。在SWS_ExecutionManagement中,提供了完成此任务的可能机制的列表。

原创文章 32 获赞 107 访问量 7545

猜你喜欢

转载自blog.csdn.net/DJAction/article/details/105489841