AP AUTOSAR EM模块介绍

汽车   2024-10-18 08:24   上海  


作者 | 不可说
出品 | 汽车电子与软件


#01
AP AUTOSAR EM 
  
AP AUTOSAR(Adaptive Platform of AUTOSAR)平台是一个高度集成且模块化的汽车中间件解决方案,专为现代汽车电子系统架构设计而生。该平台通过一系列基础功能或服务功能模块,构建了一个强大而灵活的软件架构框架,旨在促进汽车制造商、供应商及开发者之间的协作,加速汽车电子系统的开发与集成。
         

 

在这些构成AP AUTOSAR平台的众多功能模块中,EM(Execution Management,执行管理)模块扮演着至关重要的角色。作为平台的核心组件之一,EM模块负责协调和控制整个系统中各个软件和硬件组件的执行流程,即系统执行管理的所有方面,包括平台初始化和应用程序的启动/关闭。因为AP平台是动态配置和管理的,所以EM会与操作系统协同工作,以执行应用程序的运行时调度。
               

 

下面就聊聊EM关联的功能及特点。



#02
A系统启动
 
当AP(Adaptive Platform)硬件平台经历启动流程时,一系列设计好的初始化与启动步骤被严格执行,以确保系统的稳定、高效与安全。这一过程始于操作系统的初始化,作为整个系统启动的基石,操作系统负责资源的分配、进程调度以及系统服务的管理。
         

 

   
紧接着,作为操作系统启动后首批被激活的进程之一, EM被启动。EM负责协调并控制平台上所有软件组件的启动、运行与终止。通过EM,系统能够确保各个软件组件按照预定的顺序和策略执行,从而维护系统的整体性能和响应性。
         

 

在EM的引导下,自适应平台基础的其他功能集群(如通信管理、服务发现、数据管理等)以及平台级应用开始被逐一启动。这些功能集群和平台级应用共同构成了AUTOSAR AP平台的核心能力,为上层应用提供了必要的支撑和服务。
         

 

随着AP基础平台的全面启动和运行,EM继续发挥其作用,启动自适应应用程序。自适应应用程序是AUTOSAR AP平台的一大特色,它们能够根据车辆的运行状态、用户需求以及外部环境的变化动态调整自身的行为和功能,从而提供更加智能化、个性化的服务。
         

 

值得注意的是,平台级应用程序和自适应应用程序的启动顺序并非随意安排,而是由执行管理根据Machine Manifest和Execution Manifest中的信息来确定的。Machine Manifest包含了关于硬件平台配置和能力的详细信息,而Execution Manifest则定义了软件组件之间的依赖关系、启动顺序以及执行策略。这两个Manifest文件是通过AP开发工具由开发人员根据实际需求进行配置的,它们为执行管理提供了必要的指导和依据,确保了系统启动过程的顺利进行。   


AP启动顺序


AP启动边界

EM可选地支持经过身份验证的启动,即从信任锚点启动自适应平台,同时维护信任链。在经过身份验证的启动期间,EM将验证应用程序的真实性和完整性,并在检测到违规行为时阻止其执行。通过这些机制,可以建立一个可信的平台。   



#03
EM职责
 
EM负责自适应平台执行管理和应用程序执行管理的所有方面,包括:

1. 平台生命周期管理

EM作为Adaptive Platform启动阶段的一部分启动,并负责Adaptive Platform和已部署应用程序的初始化。

2. 应用程序生命周期管理

EM负责有序地启动和关闭已部署的应用程序。EM根据Machine Manifest和Execution Manifest中的信息确定已部署的应用程序集合,并根据声明的应用程序依赖关系导出启动/关闭顺序。根据Machine State和Function Group State,已部署的应用程序将在Adaptive Platform启动期间或之后启动,但是,由于许多应用程序将向其他应用程序提供服务,因此将等待并“监听”传入的服务请求,因此不要期望所有应用程序立即开始活动工作。
         

 

EM层不负责执行的运行时调度应用程序,因为这是操作系统的责任。但是,执行管理负责操作系统的初始化/配置,以使其能够根据Machine Manifest和Execution Manifest中提取执行必要的运行时调度的信息。



#04
确定性执行 Deterministic Execution
 
确定性执行提供了一种机制,使得使用给定输入数据集的计算总是在限定的时间内产生一致的输出。EM区分了时间确定性和数据决定性。前者表示输出总是在截止日期前生成,而后者表示从相同的输入数据集和内部状态生成相同的输出。
         

 

EM提供的支持侧重于数据确定性,因为它假定时间确定性通过提供足够的资源来处理。对于数据确定性,EM提供确定性客户端API,以支持对流程内部循环、确定性工作池、激活时间戳和随机数的控制。Deterministic Client与通信管理交互,以使数据处理与循环激活同步。Deterministic Client支持的API及其与应用程序的交互如下图所示。   


确定性客户端



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

 

EM通过配置应用程序进程分配到的一个或多个资源组Resource Groups,支持免受干扰。可以为每个资源组分配CPU时间或内存限制,以限制应用程序的可用资源。



#06
应用程序恢复
  
EM负责进程Process启动/停止的状态相关管理,因此它必须拥有启动和停止进程的特殊权利。   
         

 

与此同时,平台运行状况管理(Platform Health Management, PHM)作为系统监控的核心组件,持续不断地监视整个平台的运行状态,包括各个进程的执行情况、系统资源的利用率以及潜在的运行时错误等。PHM通过一系列预设的监控流程和阈值判断,能够及时发现并识别出任何偏离正常操作范围的行为或异常情况。一旦发现潜在问题,PHM会迅速响应,并根据预定义的策略触发相应的恢复操作,以维持平台的健康运行。


EM模块对外部模块的需求接口(含PHM)

这些恢复操作的具体内容和执行方式,是由集成方(即负责将AUTOSAR架构应用于特定车辆或系统的厂商或团队)根据PHM的软件体系结构需求来定义的。集成方会详细分析平台可能遇到的各种故障场景,并制定相应的恢复策略。这些策略随后会被配置到Execution Manifest中。通过Execution Manifest,EM和PHM能够获取到所有必要的恢复操作指令,从而在需要时自动执行,确保平台能够快速从故障中恢复,并继续提供稳定可靠的服务。



#07

可信平台 Trusted Platform  

  
为了保证系统的正确功能,确保平台上执行的代码具有合法来源是至关重要的。保留此属性允许集成器构建受信任的平台(Trusted Platform)。   
         

 

实现可信平台的系统的一个关键属性是信任锚Trust Anchor(也称为信任根Root of Trust)。信任锚通常被实现为存储在安全环境中的公钥,例如存储在不可修改的persistent memory或HSM中。
         

 

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

 

将信任从信任锚点传递到操作系统和AP(即建立信任链)的一个示例如下所示:信任锚(根据定义是一个真实实体)在启动引导加载程序之前对引导加载程序进行身份验证。在引导过程的每个后续步骤中,应首先对要启动的可执行文件进行身份验证。该真实性检查应由已经认证的实体完成,即,真实性检查可以通过之前启动的可执行文件或一些外部实体(例如HSM)完成。
         

 

操作系统真正启动后,应启动EM作为其第一个进程之一。在启动执行管理之前,操作系统应确保EM的真实性已由已认证且值得信赖的实体验证。
         

 

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

 

EM现在接管了在启动AP程序之前对其进行身份验证的责任。但是,验证可执行代码的完整性和真实性的可能性不止一种。在SWS_ExecutionManagement 里面,提供了完成此任务的可能机制列表,有兴趣的可以查阅下。



#08

应用(app)与自适应应用(AP app)补充说明

 

1. app

开发app是为了解决一组连贯的功能需求。

app由可执行软件单元、其他与执行相关的项目(如数据或参数文件)以及用于集成和执行的描述性信息(如基于AUTOSAR元模型的正式模型描述、测试用例等)组成。

app可执行文件可以位于中间件之上的用户级别,也可以实现AUTOSAR自适应平台的功能集群(位于中间件级别)。

一般来说,EM对app(无论是用户级还是平台级)一视同仁,可以使用操作系统和AUTOSAR AP平台形式的其他功能集群提供的所有机制和API。但是,这样做可能会限制其对其他实现的可移植性
         

 

2. AP app

AP app是一种特定类型的应用程序。AP app的实现完全符合AUTOSAR规范。它仅限于使用AUTOSAR标准化的API,需要遵循特定的编码指南,以允许在AUTOSAR自适应平台的不同实现之间进行重新分配。

AP app始终位于中间件之上。为了允许可移植性和重用性,用户级应用程序应尽可能是自适应应用程序。 
   

不同类型的应用程序

         

 

 
/ END /



汽车电子与软件
每天分享一篇技术文章!
 最新文章