rto初始化和计算_一种Autosar RTO和Linux的虚拟化系统介绍-3

6 原型组建设计

基于选择的整合策略, 利用虚拟化技术, 提出了一种多用途 ECU 系统的试验实现方法。在这个 ECU 系统中, 基于 AUTOSAR 体系结构和 Linux OS 的汽车控制和娱乐资讯应用程序分别实现, 以便它们可以使用 COQOS 虚拟化解决方案在单个硬件平台上并行执行。所提出的解决方案设施整合的异构, 分布式 ECU 的节点和目的是解决集成问题的当前状态的艺术车辆系统。实时 AUTOSAR 和非实时 Linux 应用程序通过将它们分配到具有自己的内存空间的两个不同分区上进行分离, 并且这些分区共享硬件和 CPU 时间 [29] 中的 i/o 外围设备。然后, 我们在分区之间实现分区间的通信通道, 以便应用程序可以在它们之间传输数据信号。下面图6.1 所示的原型模型的高级系统设计包括三软件功能组件, 即

第一部分AUTOSAR分区包含基于AUTOSAR架构的汽车控制应用

第二部分 Linux分区包含Linux内核、根目录文件系统和HMI应用程序

第三部分 虚拟化解决方案，提供虚拟化技术

除此之外, 原型模型还包括目标硬件平台, 一是 MX53 SABRE。然而, 硬件平台是一个商业化的现成 (COTS) 产品, 是由 COQOS 虚拟化支持, 并且在这个硬件中没有针对我们的原型实现 [12] 进行特殊的设计和实现。原型模型的三软件功能组件的设计使得它们能够在同一硬件平台上实现 AUTOSAR 和 Linux 应用程序的并行执行。

原型模型的主要设计目标是

1. 将 AUTOSAR 应用程序移植到虚拟化解决方案之上。

2. 将 Linux 应用程序移植到虚拟化解决方案之上。

3. 允许并行执行 AUTOSAR 和 Linux 应用程序在使用同一虚拟机管理程序解决方案的硬件平台。这涉及到使用 PikeOS 时间划分机制的实时 AUTOSAR 和非实时 Linux 分区之间的高效处理器 (CPU) 时间共享。利用 PikeOS 资源分配机制, 在两个分区之间共享和严格分离目标设备 (i. MX53) 的硬件资源。通信接口, 使用 PikeOS 间分区通信方法, 在分区之间以一种简单快捷的方式传输数据信号。

对每个功能部件的设计考虑、技术和优化都是按照上述目标进行的, 并满足汽车快速启动时间、少信号通信延迟、严格隔离等。在设计科学研究方法中, 我们揭示了设计决策的基础, 并解释了为每个功能组件做了什么设计, 以及为什么要做 [17]。

6.1 设计AUTOSAR分区

AUTOSAR 分区由基于 AUTOSAR 框架的汽车控制应用程序组成, 可以在虚拟化解决方案的顶部移植。AUTOSAR 分区的设计注意事项是

a) 为汽车应用创建一个 PikeOS 兼容的 AUTOSAR 体系结构, 以便它可以集成并在 PikeOS 微内核上执行, 如图6.2 所示。

b) 优化 AUTOSAR 应用程序的启动时间, 以支持快速启动要求。

6.1.1 设计兼容AUTOSAR架构的PikeOS

在 AUTOSAR 体系结构中, BSW 模块和SWC依赖于底层操作系统, 用于任务和应用程序的调度和执行 [32]。通常, 工业标准 OSEK OS 规范在 AUTOSAR 中适用 [6]。在这个原型设计中, 我们使用虚拟化层, PikeOS 微内核作为 OS 模块, 创建一个 PikeOS 兼容的 AUTOSAR 体系结构, 它可以集成并在 PikeOS 微内核上执行, 如下面的图6.2 所示。这涉及两个主要的修改, 在当前AUTOSAR 框架。

a) 根据 AUTOSAR 规范, 需要实现 os 抽象层 (OSAL), 如果使用专有 os (BSW) 而不是标准的 PikeOS os [5], 则必须提供 os功能封装, 以便在 OSEK、SWC和 RTE 中模拟适当的 AUTOSAR OSEK 接口。

b) 将AUTOSAR BSW、RTE 和SWC的状态与基于 PikeOS 的 OS 模块集成, 并使用 AUTOSAR 生成过程 [41] 生成代码文件。

6.1.1.1 系统封装 OSEK OS的接口和服务模拟器

OSEK OS 概念如任务模型、基于固定优先级的任务调度、任务同步的事件机制、中断处理、资源管理和告警功能 [6] 需要迁移到相应的 PikeOS 机制中。AUTOSAR 体系结构使用这些标准化的 OS 接口实现功能。首先, 我们分析我们的 AUTOSAR 应用程序, 以了解它所使用的必要的 OS 功能。当将 AUTOSAR RTE 或 BSW 移植到适当的 os 平台时, 第三方 os 需要使用它们自己的 API 函数来重新实现这些标准化的 os 接口, 以模拟 OSEK os [5]。将 PikeOS 机制与 OSEK 接口规范进行了比较, 并进行了研究, 以分析 PikeOS 是否能够为这些标准化的 OS 接口提供支持。如果存在一到一匹配, 则需要在两个 OS 的接口之间转换和创建映射封装。在我们的原型设计的 AUTOSAR 应用程序使用一个相当有限和简单的 AUTOSAR OS 模型。

a) 任务建模:

引用 AUTOSAR 应用程序由基本 OS 任务模型组成, 而不是扩展的, 用于调度应用程序的可运行实体。在基本任务模型中, 任务有三基本状态: 运行、就绪和挂起 [6]。在我们的 OSAL 包装函数中, 我们需要为这三状态之间的状态转换提供接口。

b) 事件、计数器和报警机制:

在引用 AUTOSAR 应用程序中, OS 任务与调度程序激活和执行任务的周期性计时事件相关联。在 AUTOSAR OS 模型中, 事件以特定的警报功能注册, 这些函数设置或重置事件。这些警报函数具有预定义的计时计数器值, 当计数器达到指定值时, 将调用警报函数, 从而触发或重置关联的事件 [6]。因此, 我们需要接口增加计数器值, 设置或取消报警功能, 等等, 在 OSAL 包装功能。

c) 中断处理

在我们的参考应用中, 可以从模拟器工具发送帧, 它反过来触发了 can 硬件中断信号。这需要 OSEK 接口来捕获和处理这些CAN中断信号 [6]。因此, 我们需要 OSAL 封装函数中的相应接口来启用、禁用和处理 CAN 中断。

d) 调度和资源管理:

需要调度服务才能将系统资源分配给任务。当它被调用时, 调度程序将搜索任何处于就绪状态的任务。具有最高优先级的就绪状态下的任务将获得系统资源, 并计划运行状态 [6]。还应该有一个保护和协调访问共享资源 (如内存、i/o 设备等) 的机制, 以防止死锁和优先级反转问题。这是通过 OSEK PCP (Piroitiy Cellng Protocal) 来实现的, 它保证了不同任务之间共享的公共资源的互斥 [6]。在 OSAL 封装函数中, 我们需要相应的接口来实现调度和资源管理机制。

PikeOS 提供了几种特性对于在PikeOS系统上进行半虚拟化和仿真guest OS。我们使用Pike OS POSIX实时特性来仿真OSEK OS标准接口。COQOS 解决方案提供了 POSIX 兼容的 api [12] 和

OSAL 封装函数利用这些 POSIX API 函数来转换和映射 PikeOS 中 AUTOSAR OS 的 OSEK 接口, 这在实现部分中进行了说明。

e) 优化 AUTOSAR 应用

PikeOS 仅为分区的初始化和分区内的应用程序提供时间分片机制实施工具。但是, 应用程序的立即执行和启动取决于应用程序的设计。AUTOSAR 操作系统使用标准化接口;StartOS 在系统启动或重置 [5、6] 期间初始化 AUTOSAR 操作系统和应用程序。StartOS 接口执行图6.3 所示的初始化步骤, 它调用 StartupHook 例程, 用户可以将所有 OS 相关的初始化代码放在这个例程 [6] 中。在我们的原型系统中, 实时 AUTOSAR 应用的快速启动是汽车 ECU 系统的一个基本要求, 这取决于 OSEK 启动接口 (StartOS) [6]。

PikeOS 没有直接提供 StartOS 接口功能。相反, 它有一个等效的 os 接口, 名为 "START_AUTOSAR", 用于启动 os 服务。根据 OSEK os 提供的规范, 使用此 PikeOS 接口 (START_AUTOSAR), 在 os 抽象层 (OSAL) 中编码并实现了启动功能。StartupHook 例程中的初始化过程是自定义的, 因此不需要复杂和冗长的执行。我们在 StartupHook 函数中放置了有限的和必要的初始化程序, 以确保 AUTOSAR 应用程序的快速启动, 同时确保可以正确加载和执行 AUTOSAR 应用程序。