简介
Execution Management(下称EM),负责平台初始化以及AP应用的启动和关闭。它根据配置好的Manifest文件执行任务,而这些Manifest文件则包含了什么时候,如何启动应用等信息。
EM需要和操作系统一起,共同执行应用的运行调度。EM需要负责操作系统的初始化/配置,让操作系统来做运行时调度,但是如何调度的这个信息,需要由EM从Machine Manifest和Execution Manifest文件当中提取出来。
应用,Adaptive应用,可执行文件,进程
应用一般包含可执行软件单元,相关执行项(例如数据或参数文件),集成/执行用的描述性信息(例如AUTOSAR模型描述文件,测试案例等等)。应用可执行文件既可以是用户级(中间件以上)也可以是AP平台的功能(中间件),但都是由EM模块进行启动/停止管理。
Adaptive应用是一种特定类型的应用,需要遵守AUTOSAR规范,也即限定只能使用AUTOSAR的标准接口,也要遵守相应的编程标准。Adaptive应用总是位于中间件以上,为了实现更好的可移植性和重复利用性,用户及的应用应当尽可能的是Adaptive应用。
可执行文件作为一个软件单元,是应用的一部分,它有一个entry point(main函数)。应用可以由一个或多个可执行文件来实现。(部署/执行流程如下)
进程是可执行文件的实例,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将进程视为初始化完毕。
Process State
Process State代表从EM的角度来看进程的生命周期,每一个进程都有自己的状态。
从资源分配的角度来说,Terminated状态的进程和Idle类似,进程没有运行,也没有资源被分配,但是从执行的角度来说,他们是不同的状态,Terminated代表进程执行过了,已经被终止,可以再次启动。
系统启动
机器启动后,操作系统首先被初始化,然后EM作为操作系统初始进程的一部分,也被启动。其他功能簇以及平台级的应用将随后由EM启动,当平台启动后,EM继续启动AP应用。
当设置了信任链(chain of trust)时,认证启动过程中,EM会验证应用的可信度和完整性,如果未通过检测,将不会运行这个应用。
启动/终止顺序
EM可以根据声明的执行依赖关系来得到启动和终止的顺序,我们通过这个例子来理解:
首先我们有一个DataLogger进程,依赖于另一个Storage进程,这意味着启动时,EM需要先启动Storage进程,然后再启动DataLogger,这样的流程才能让DataLogger进行日志存储。
相对应的,在终止时,需要先终止DataLogger才能终止Storage。
状态转换
以上图为例,代表了不同的Machine State,Function Group,都和哪些进程有关,例如Machine为Startup状态时,需要进程A和进程B是Running状态,而到Running状态时,需要终止进程A,然后启动进程C。
SM通过SetState接口设置状态,EM根据状态,需要从FG1迁移到FG1:State2,这个时候需要启动相应的进程。而当SM再次请求设置状态为FG1:State3时,这个时候又需要EM将进程终止掉。
进程B不允许依赖于另一个FG中的进程A,否则可能会出现启动一个不再给定状态中的进程。一个FG中的状态变化不会对其他FG产生影响。
还有一种情况是,B依赖于A,但是A在FG2:Running状态下就已经运行了,但是B对A的依赖会要求A以不同的启动选项开始启动,所以A要先终止并再次以不同的选项还是启动,然后再启动B。
确定性执行
确定性执行提供这样一个机制,即当输入给定数据时,计算过程总能在有限时间内返回一致的输出结果。
默认地,时间确定性已经由足够的资源所达到,EM的这个特性主要集中于数据确定性。EM提供DeterministicClient API来支持进程内部周期控制,确定性工作池, 激活时间戳和随机数。当出现软件锁步的情况,DeterministicClient与一个可选软件锁步框架交互来确保冗余运行进程的行为一致。DeterministicClient和Com模块一起同步数据。
资源限制
AP平台允许在设备上运行很多个AP应用,所以需要保证他们能够互不干扰。当某一AP应用出现错误行为时,要保证影响范围不会设计到其他应用,例如应用不应当能够使用比配置指定还要多的CPU资源,否则很有可能影响其他应用的正常执行。
EM通过配置一个或多个ResourceGroup分配给应用来支持这个特性,每个ResourceGroup都可以分配指定的CPU时间或者内存。
应用恢复
EM模块负责进程启动/停止状态相关的管理,所以EM有特定的权限去启动和停止进程。如果有进程运行发生问题,PHM会监控到并触发恢复操作。恢复操作由集成人员根据软件架构对于PHM的需求而定义,在Execution Manifest中配置。
可信平台
为了保证系统的正确功能,保证平台上运行代码的合法来源是非常关键的,这样才能允许集成人员构建一个可信平台。
系统实现可信平台的关键属性是Trust Anchor (也成为Root of Trust)。Trust Anchor通常由保存在安全环境中的公钥实现,例如不可修改内存或HSM中。
系统设计者负责保证系统由Trust Anchor开始启动,直到EM运行起来。根据系统设计者选择的机制而建立的信任链, 系统的完整性和真实性在系统启动时已经被检查过了。
在此基础上,当EM接管系统控制时,也会接管信任链的职责,这个时候系统集成者需要负责EM已被正确配置。
让我们来看这样一个信任链的例子:Trust Anchor在bootloader启动之前验证bootloader,在随后自动过程中的每一步,每一个即将被启动的执行程序都需要经过验证,而这个验证应当由已经被验证过的实体来完成,可以是已经验证过且启动的执行程序,或者是HSM这样的外部实体。
验证失败时的处理
可以为上述的验证过程配置两种不同的验证失败时的处理方式:
监控模式:在监控模式下,完整性和真实性检查仍会执行,但不会影响启动过程,及时文件系统有损坏,AP平台仍会启动。当希望即使平台并不可信但仍能保持系统运行时,监控模式就很有用。另外一种情况是,在开发阶段时,代码经常有改动,没有必要每次都对应更改验证标签(签名),这个时候也可以用监控模式。
严格模式:在严格模式下,AP平台需要保证,当执行程序,manifests,或者相关库不能成功完成完整性和真实性验证时,进程不会被执行。
举个例子,EM在验证了执行程序,相关共享obj和Manifest,启动了执行程序,这个时候EM准备启动另一个执行程序,但是它的验证失败了,那么EM就不会启动它,但其他已经在运行的程序继续保持运行。
阅读原文,关注作者博客
推荐阅读
特斯拉的电池管理系统 (BMS) 相比其他电动车有哪些优势?
原文始发于微信公众号(汽车ECU开发):浅谈Adaptive AUTOSAR执行管理模块