浅谈Adaptive AUTOSAR执行管理模块

汽车安全 3年前 (2021) admin
930 0 0

浅谈Adaptive AUTOSAR执行管理模块

简介

Execution Management(下称EM),负责平台初始化以及AP应用的启动和关闭。它根据配置好的Manifest文件执行任务,而这些Manifest文件则包含了什么时候,如何启动应用等信息。

EM需要和操作系统一起,共同执行应用的运行调度。EM需要负责操作系统的初始化/配置,让操作系统来做运行时调度,但是如何调度的这个信息,需要由EM从Machine Manifest和Execution Manifest文件当中提取出来。

应用,Adaptive应用,可执行文件,进程

应用一般包含可执行软件单元,相关执行项(例如数据或参数文件),集成/执行用的描述性信息(例如AUTOSAR模型描述文件,测试案例等等)。应用可执行文件既可以是用户级(中间件以上)也可以是AP平台的功能(中间件),但都是由EM模块进行启动/停止管理。

Adaptive应用是一种特定类型的应用,需要遵守AUTOSAR规范,也即限定只能使用AUTOSAR的标准接口,也要遵守相应的编程标准。Adaptive应用总是位于中间件以上,为了实现更好的可移植性和重复利用性,用户及的应用应当尽可能的是Adaptive应用。

浅谈Adaptive AUTOSAR执行管理模块

可执行文件作为一个软件单元,是应用的一部分,它有一个entry point(main函数)。应用可以由一个或多个可执行文件来实现。(部署/执行流程如下)

浅谈Adaptive AUTOSAR执行管理模块

进程是可执行文件的实例,AP平台中,进程作为OS进程,运行时被创建。EM仅仅控制进程的启动和停止,进程运行起来后,EM仅仅在进行状态管理或者和Deterministic Execution时才会和进程有联系。

Execution Manifest,Machine Manifest,Manifest Format

Execution Manifest在设计期间创建,和可执行文件一起被部署到机器上。Execution Manifest指定可执行文件部署相关信息,以及进程属性的配置信息(例如启动参数,resource group分配,调度优先级等等)。可以为每一个Machine State或Function Group State指定不同的配置,也就是说可执行文件对应的不同实例可以有不同的配置。

Machine Manifest在集成期间为一个特定机器创建,它包含了所有无法被Execution Manifest和Service Instance Manifest的其他配置信息,包括Machine属性,特性(资源,功能安全,信息安全等),例如Machine State,Function Group State,resource group, 访问权限组,调度配置,SOME/IP配置,内存分区等等。

Execution Manifest和Machine Manifest可以由标准ARXML文件转换为平台特定格式(也成为Processed Manifest),可以在机器启动时被读出。转换过程既可以在集成时或部署时完成,也可以在安装时(UCM升级)完成。

平台/应用生命周期管理

一般来说,EM管理两种生命周期:平台生命周期管理以及应用生命周期管理。

平台生命周期管理:作为AP平台启动阶段的一部分,EM也会被启动,并负责AP平台及部署的应用的初始化

应用生命周期管理:EM负责部署的应用能够按照顺序地启动和关闭。EM需要根据Machine Manifest和Execution Manifest决定哪些是部署地应用,并根据声明地应用依赖来得到启动和关闭地顺序。根据Machine State和Function Group State,部署的应用会在AP平台启动或启动结束时启动。当然,并不是所有的应用都会立即被启动,因为有的应用会向其他应用提供服务,需要等待并“监听”服务请求。

Execution State

Execution State代表进程内部生命周期,当到达kRunning状态时,EM将进程视为初始化完毕。

浅谈Adaptive AUTOSAR执行管理模块

Process State

Process State代表从EM的角度来看进程的生命周期,每一个进程都有自己的状态。

浅谈Adaptive AUTOSAR执行管理模块

从资源分配的角度来说,Terminated状态的进程和Idle类似,进程没有运行,也没有资源被分配,但是从执行的角度来说,他们是不同的状态,Terminated代表进程执行过了,已经被终止,可以再次启动。

系统启动

浅谈Adaptive AUTOSAR执行管理模块

机器启动后,操作系统首先被初始化,然后EM作为操作系统初始进程的一部分,也被启动。其他功能簇以及平台级的应用将随后由EM启动,当平台启动后,EM继续启动AP应用。

当设置了信任链(chain of trust)时,认证启动过程中,EM会验证应用的可信度和完整性,如果未通过检测,将不会运行这个应用。

启动/终止顺序

EM可以根据声明的执行依赖关系来得到启动和终止的顺序,我们通过这个例子来理解:

首先我们有一个DataLogger进程,依赖于另一个Storage进程,这意味着启动时,EM需要先启动Storage进程,然后再启动DataLogger,这样的流程才能让DataLogger进行日志存储。

相对应的,在终止时,需要先终止DataLogger才能终止Storage。

状态转换

浅谈Adaptive AUTOSAR执行管理模块

以上图为例,代表了不同的Machine State,Function Group,都和哪些进程有关,例如Machine为Startup状态时,需要进程A和进程B是Running状态,而到Running状态时,需要终止进程A,然后启动进程C。

浅谈Adaptive AUTOSAR执行管理模块

SM通过SetState接口设置状态,EM根据状态,需要从FG1迁移到FG1:State2,这个时候需要启动相应的进程。而当SM再次请求设置状态为FG1:State3时,这个时候又需要EM将进程终止掉。

浅谈Adaptive AUTOSAR执行管理模块

进程B不允许依赖于另一个FG中的进程A,否则可能会出现启动一个不再给定状态中的进程。一个FG中的状态变化不会对其他FG产生影响。

浅谈Adaptive AUTOSAR执行管理模块

还有一种情况是,B依赖于A,但是A在FG2:Running状态下就已经运行了,但是B对A的依赖会要求A以不同的启动选项开始启动,所以A要先终止并再次以不同的选项还是启动,然后再启动B。

确定性执行

确定性执行提供这样一个机制,即当输入给定数据时,计算过程总能在有限时间内返回一致的输出结果。

默认地,时间确定性已经由足够的资源所达到,EM的这个特性主要集中于数据确定性。EM提供DeterministicClient API来支持进程内部周期控制,确定性工作池, 激活时间戳和随机数。当出现软件锁步的情况,DeterministicClient与一个可选软件锁步框架交互来确保冗余运行进程的行为一致。DeterministicClient和Com模块一起同步数据。

浅谈Adaptive AUTOSAR执行管理模块

资源限制

AP平台允许在设备上运行很多个AP应用,所以需要保证他们能够互不干扰。当某一AP应用出现错误行为时,要保证影响范围不会设计到其他应用,例如应用不应当能够使用比配置指定还要多的CPU资源,否则很有可能影响其他应用的正常执行。

EM通过配置一个或多个ResourceGroup分配给应用来支持这个特性,每个ResourceGroup都可以分配指定的CPU时间或者内存。

应用恢复

EM模块负责进程启动/停止状态相关的管理,所以EM有特定的权限去启动和停止进程。如果有进程运行发生问题,PHM会监控到并触发恢复操作。恢复操作由集成人员根据软件架构对于PHM的需求而定义,在Execution Manifest中配置。

浅谈Adaptive AUTOSAR执行管理模块

可信平台

为了保证系统的正确功能,保证平台上运行代码的合法来源是非常关键的,这样才能允许集成人员构建一个可信平台。

系统实现可信平台的关键属性是Trust Anchor (也成为Root of Trust)。Trust Anchor通常由保存在安全环境中的公钥实现,例如不可修改内存或HSM中。

系统设计者负责保证系统由Trust Anchor开始启动,直到EM运行起来。根据系统设计者选择的机制而建立的信任链, 系统的完整性和真实性在系统启动时已经被检查过了。

在此基础上,当EM接管系统控制时,也会接管信任链的职责,这个时候系统集成者需要负责EM已被正确配置。

让我们来看这样一个信任链的例子:Trust Anchor在bootloader启动之前验证bootloader,在随后自动过程中的每一步,每一个即将被启动的执行程序都需要经过验证,而这个验证应当由已经被验证过的实体来完成,可以是已经验证过且启动的执行程序,或者是HSM这样的外部实体。

浅谈Adaptive AUTOSAR执行管理模块

验证失败时的处理

可以为上述的验证过程配置两种不同的验证失败时的处理方式:

监控模式在监控模式下,完整性和真实性检查仍会执行,但不会影响启动过程,及时文件系统有损坏,AP平台仍会启动。当希望即使平台并不可信但仍能保持系统运行时,监控模式就很有用。另外一种情况是,在开发阶段时,代码经常有改动,没有必要每次都对应更改验证标签(签名),这个时候也可以用监控模式。

严格模式在严格模式下,AP平台需要保证,当执行程序,manifests,或者相关库不能成功完成完整性和真实性验证时,进程不会被执行。

举个例子,EM在验证了执行程序,相关共享obj和Manifest,启动了执行程序,这个时候EM准备启动另一个执行程序,但是它的验证失败了,那么EM就不会启动它,但其他已经在运行的程序继续保持运行。


阅读原文,关注作者博客

版权声明:本文由KimChan原创,并授权。

推荐阅读

特斯拉最新的12V蓄电池有什么不同?

特斯拉最新中央计算模块(CCM)解析

关于对自动驾驶传感器的理解

特斯拉的电池管理系统 (BMS) 相比其他电动车有哪些优势?

2021款特斯拉Model Y ECU接口梳理

详解CANoe之CAPL编程

关于CAN时间同步的理解

dbc文件的格式以及创建详解

大众ID.4 X网络架构详解

学习笔记——NVM数据处理机制

学习笔记——AUTOSAR NVM基础知识

基于UDS的Bootloder详解

关于整车上下电流程的理解

一文详解CAN总线错误帧|附下载

DoIP协议介绍,资料分享!

详解车载网络 OTA系统的开发|文末附下载

一文了解汽车嵌入式AUTOSAR架构|附下载

特斯拉Autopilot系统安全研究|附dbc下载

分享不易,恳请点个【在看】

原文始发于微信公众号(汽车ECU开发):浅谈Adaptive AUTOSAR执行管理模块

版权声明:admin 发表于 2021年11月10日 下午11:40。
转载请注明:浅谈Adaptive AUTOSAR执行管理模块 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...