技术背景

本节介绍虚拟化解决方案;技术概念应用于我们的试验实现, 如时间调度、不同操作系统 (OS) 的资源分配和使用虚拟化技术的跨分区通信机制。它还描述了虚拟化系统如何支持不同的操作系统和用于将组件实现和集成到单个系统中的工具。然后, 本节重点介绍了与本论文相关的 AUTOSAR 体系结构模块的基本概念。本节中解释的概念将帮助读者清楚地理解多用途 ECU 原型的设计和实现, 这是在后面的章节中描述的。

4.1 虚拟化

虚拟化被松散定义为 "将计算机资源划分为多个执行环境的框架或方法, 通过应用一个或多个概念或技术 (如硬体和软体分区、时间共享、部分或完全机器模仿, 仿效和许多其他 [25]。"

虚拟化是在计算机或嵌入式系统中实现虚拟化技术的软体或固件 [8]。VMware、虚拟桌面基础结构等虚拟化技术最初在伺服器域中广泛使用, 用于在单个伺服器上承载多个逻辑伺服器实例, 然后逐步进入企业域进行软体基础结构整合。然后它被应用在消费者空间为同时运行多个操作系统 (OS) 在一台个人计算机 [8, 23]。

4.1.1 在嵌入式系统上部署虚拟化

最初, 嵌入式系统主要是单一应用程序和单处理器系统, 实现了简单而专用的功能。然而, 现代嵌入式系统必须实现几个复杂的功能域和计算要求苛刻的软体应用程序, 具有严格的可靠性和安全性。因此, 可以看出, 在资源共享和系统整合方面, 嵌入式系统已经达到了与伺服器企业空间相媲美的复杂程度和挑战。大多数嵌入式系统使用可定制的系统体系结构, 反过来更适合于虚拟化 [22、23]。

虚拟化被认为是嵌入式系统架构师和产品开发工程师的下一个前沿领域, 以解决与增加现代嵌入式系统的资源和应用需求相关的决策难题。此外, 强大的多核处理器的问世, 对高性能和低功耗的需求一直是在航空电子学, 医疗和工业设备, 下一代移动平台的虚拟化部署背后的主要推动力和汽车系统 [11, 23]。处理器晶元提供商对虚拟化扩展的支持进一步推动了嵌入式系统中管理程序技术的引入 [8]。虚拟机管理程序解决方案提供了在同一多核处理器上承载异构操作系统的灵活性。它还实现了可靠的可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的用户应用程序之间的安全分离。

4.1.2 虚拟化技术分类

根据部署和实现的方式, 虚拟化系统可以分为两种类型。

  1. Type1 或硬体级别的虚拟化系统, 在内核模式下直接在硬体上执行监控程序, 并处理硬体和不同的 vms [28]
  2. Type2 或 os 级别的虚拟化, 在该系统中, 虚拟机在常规 os 环境的顶层作为应用程序运行, 然后对在硬体 [28] 以上的第三级运行的guest- OS 进行处理。

另一种类型的分类是根虚拟化系统如何虚拟Guest -OS的方式进行的

  1. "完全虚拟化" 技术, 它要求硬体处理器支持虚拟化, 并在运行时使用 OS 指令的二进位转换来捕获 VMM。没有必要修改guest-os操作系统, 并且guest- os 不知道它正在被虚拟化。但是, 在执行之前, 由于 OS 二进位指令的扫描和翻译, 将会产生很高的性能开销 [8, 23]。
  2. "半虚拟" 技术, 它要求修改后的guest- os 将操作系统代码指令替换为与 VMM 直接通信的超级调用。这将导致高性能和低虚拟化开销, 并且guest- OS 也知道正在虚拟 [23]。

由于嵌入式系统的资源有限, Type1 虚拟化系统具有精简的虚拟机管理层和小型受信任的代码库 (TCB), 适用于嵌入式系统中的虚拟化。同样, 虚拟更适合嵌入式系统, 因为它提供高性能和更少的代码开销, 而且在guest-OS 中的修改也不复杂, 因为嵌入式系统中的内核代码通常很小, 并且易于应用程序开发人员。

4.2 COQOS 虚拟化解决方案

COQOS 是一个高度可伸缩的软体框架, 用于在汽车领域 [12] 实现虚拟化技术。它为汽车 oem 和供应商提供了一个灵活的解决方案, 可以无缝地集成娱乐资讯单元、远程信息处理和消费电子用户应用程序以及实时 AUTOSAR 的汽车应用, 如ADAS系统, 底盘控制等在单一 ECU 系统使用一个强有力的处理器 [12]。在本论文中, COQOS 包含一个轻量级的 PikeOS 微内核实现 [12, 26], 这是类似于一个 Type1 的管理程序, 部署在我们的试点实施多用途 ECU 系统。虚拟是为 AUTOSAR 和 Linux访客操作系统完成的, 并且他们在这个虚拟化解决方案之上被移植。

它已被选择, 因为它提供了以下功能。

  • 支持 AUTOSAR 框架和半虚拟 Linux 内核版本。
  • 支持各种处理器体系结构和目标平台

4.2.1 PikeOS 微系统

COQOS 解决方案使用 SYSGO 的 PikeOS 微内核体系结构 [26]。PikeOS 微内核已经被广泛部署在关键的航空电子项目中, 并被证明符合严格的安全和安保标准。它提供了几种功能状态和能力, 这本身就是一个广泛的研究课题 [26, 27]。我们简要介绍了 PikeOS 在我们的试点实施中使用和应用的技术方面, 如

  1. 使用资源分区技术严格隔离和分配资源。
  2. 实时和非实时任务的灵活高效调度的时间划分机制。
  3. 分区间通信, 用于实现数据信号传输的分区之间的通信。

4.2.2 资源分区

资源分区是逻辑容器具有静态定义的硬体和软体应用程序资源集的 具有预定义的访问级别。PikeOS 微内核将全局内核内存空间划分为静态可配置的池子集, 然后在创建时将其分配到资源分区中的任务中。此机制确保了分区之间的严格隔离, 因为一个资源分区中的应用程序出现故障, 只能耗尽分配给它的内存, 并且无法访问其他资源分区的内存池。这是一个简单的解决方案, 因为它维护一个最小的受信任的代码库, 唯一的挑战是开发人员应该预先预测RTOs 和 GPOs 的内核内存需求。同样, RAM 用户内存资源通过 PikeOS 使用预定义的配置分配给分区。在系统启动期间, 将创建包含相应 RAM 内存页的地址空间并将其分配给每个分区。分区中的线程总是连接到地址空间, 并且它只能访问和管理它拥有的地址空间 [26, 29]。

此外, 还会为每个线程分配访问许可权和通信许可权, 以限制和监视其对系统调用介面的访问。每个访问许可权都允许任务访问一组系统调用, 而微内核可以检查任务的每个系统调用及其相应的分配能力, 以确保它不会占用过多的内核资源或操纵系统设置。任务的能力存储在相应的任务描述符表中, 并且不能在任务的生存期内进行更改或扩展。此外, 还可以配置健康监视器, 用于在运行时 [29] 期间执行的错误检测、故障处理和分区和用户应用程序的恢复。上述机制保证了资源分区之间的系统资源的严格分离和保护。

4.2.3 时间分区

多用途 ECU 系统的试验实现将同时承载实时 AUTOSAR 和非实时 Linux 应用。应该有一个灵活的机制, 同时安排关键的实时和非实时任务。PikeOS 实现了一种高级时间分区方案, 它既包括基于时间驱动的优先顺序调度, 也包含用于运行硬实时任务以及软实时和非实时任务 [26、27] 的计划。在 PikeOS 中, 时间划分可以看作是一个两步过程。PikeOS 创建用于为每个资源分区分配特定 CPU 时间的时间分区。PikeOS 系统中的资源分区首先分配给时间分区, 如图4.1 所示。

有一个主要的时间框架, 定期重复周期。这个时间框架被细分成可变持续时间的几个时段。时间分区分配给主要时间帧中的时间段, 如图4.2 所示。时间驱动的调度机制在主要的时间框架内安排时间分区。在每个时间分区中, 根据优先顺序优先演算法 [26, 27], 应用程序按优先权排定。

该调度方法在多个实时操作系统中得到了应用。然而, PikeOS 的独特之处在于, 有两个时间间隔可以同时活动;带有 ID 0 (T0) 的特殊时间分区, 称为 "背景时间分区", 它是始终活动的, 另一个时间分区, Ti 从 T1,T2 中选择的,.., TN-1 (其中 N 是创建的最高时间分区), 作为前台时间分区, 切换周期性地由时间驱动的调度程序如图4.3.所示实时任务分配在时间驱动的分区 T1, T2,.., TN-1, 并给予一个中等到高级优先顺序。非实时任务分配在后台时间分区, T0, 并提供了一个共同的低优先顺序。安全关键的系统服务, 如健康监控和看门狗被分配到后台时间分区, T0 和他们被分配的最高优先顺序, 使他们可以立即激活。这种灵活的调度机制确保了不同类型任务之间的有效负载平衡。严格的, 时间驱动实时任务得到他们的固定时间插槽, 是根据他们的最坏的情况下执行时间计算。如果这些任务早完成, 则将其时间段的剩余空闲时间切片分配给低优先顺序, 使用 PikeOS 调度程序的后台分区中的非实时任务, 从而有效地利用了剩余的计算时间。此外, PikeOS 提供了在系统配置期间可以创建的不同计划方案, 并提供了在运行时 [26、27] 期间在这些方案之间动态切换的能力。

4.2.4 内部分区通信

利用 PikeOS 微内核对资源分区进行严格隔离和分离。但是, 在不同资源分区中的应用程序以受控方式相互通信也很重要。PikeOS 微内核为实现分区间通信机制提供了三种方法 [29]。

  1. 队列埠: 它实现了资源分区之间的点对点通信通道。消息存储在每个通道中, 最多可在第一个 (FIFO) 队列中的用户定义的最大大小。当读取或写入通道时, 队列将被阻塞, 并具有超时值。
  2. 取样埠: 这等同于排队埠;但是, 没有用于存储消息的队列。采样埠由一个固定大小的消息缓冲区组成, 当新消息到达时, 旧消息被重写。可以以更快的速度定期更新消息。
  3. 共享内存区域: 用于传输大量数据。共享内存段被视为共享文件系统, 并为每个分区配置对共享内存的读写访问。此外, 它还需要特定于应用程序的协议来同步和协调不同分区之间的读写访问。

4.2.5 Pike OS 支持AUTOSAR 和Linux虚拟化

在 PikeOS 中, 应用程序/用户程序可以直接在 PikeOS 微内核介面的顶层执行, 或者在承载虚拟操作系统的资源分区的顶层进行, 这些系统适用于 PikeOS 微内核。这些Guest-OS可以运行在 PikeOS 微内核的顶层被称为特性 [26, 29]。在我们的原型实现中, 我们使用 PikeOS、嵌入式 linux (ELinOS) 和便携操作系统介面 (POSIX 实时) 提供的以下特性, 用于在 PikeOS 微内核上分别移植虚拟化的 linux 和 AUTOSAR OS [26, 31]。

ElinOS

ELinOS 是由 SYSGO AG 提供的一个嵌入式 Linux 发行版 [31]。ELinOS 提供了用于工业实时应用的所有功能, 并支持广泛的 bsp、驱动程序和实时硬体扩展。它为 linux HMI 演示应用程序提供最新的内核版本 (2.6.35), 用于创建可在 PikeOS 微内核上的分区上承载的虚拟化 linux OS。

POSIX实时系统

PikeOS POSIX 实时特性适合于在一个分区中部署紧凑的实时系统, 我们使用它来模拟AUTOSAR 操作系统, 因为它为 AUTOSAR os 的概念提供了良好的支持, 如任务模型、事件、调度、报警机制和资源管理。posix 实时特性为编程环境提供 posix API 函数 [29]。

4.2.6 PikeOS 开发和集成过程

PikeOS 提供了一个基于 Eclipse 的 IDE 工具, 名为 CODEO, 用于支持的虚拟 OS 的软体应用程序的交叉编译, 然后在单独的分区 [30] 中进行配置。使用 PikeOS 交叉编译器工具, 可以将应用程序编译、链接并内置到目标硬体系统的应用程序二进位文件中。PikeOS 系统设置由开发人员使用 CODEO 进行配置, 这些参数将自动更新并以 xml 格式 (称为 VMIT. xml [30]) 存储在配置文件中。系统配置设置 (如分区、其资源要求、时间调度参数、分区间通信通道和埠以及在分区内执行的应用程序) 的规范将在此更新文件.最后, 将分区配置文件 (VMIT. xml)、用户应用程序二进位和 PikeOS 二进位对象 (微内核模块和 PikeOS 系统软体) 组装起来, 并使用 ROM 映像生成器工具将其内置到单个二进位文件中。此二进位文件是可在嵌入式硬体平台 [30] 上下载和初始化的 PikeOS ROM 图像文件。CODEO 指定在嵌入式目标硬体中启动 ROM 映像的引导机制。

4.3 AUTOSAR

AUTOSAR 是一个开放和标准化的软体架构框架, 由汽车制造商、主要 OEM 供应商和汽车工具开发商共同开发, 以应对车辆中电子/电子系统日益复杂的问题 [4]。它为汽车领域的不同利益相关者提供了一个协作、可转移性、可重用和合作的软体基础平台, 同时促进了创新功能的竞争 [32]。

4.3.1 模块、层级架构

AUTOSAR 标准化提供了一个模块化的, 分层的 ECU 软体架构, 使基于模型的开发 (MBD) 的汽车嵌入式软体功能, 也有助于消除边界之间的多样化的汽车功能域.此外, AUTOSAR 提供了软体组件框架, 允许在组件软体实体 (深港西部通道) 方面对汽车功能进行描述, 进而帮助对软体进行个性化需求的建模。AUTOSAR 为 ecu 提供了一个标准的和简化的开发基础结构, 其中实现汽车功能 (深港西部通道) 的应用软体与平台特定的基本软体模块 (BSW) 分离, 通过透明中间件层, 称为运行环境 (RTE), 如图4.4 所示。此设计有助于开发汽车软体功能, 而不了解相应的 ecu [4、32]。

4.3.2 基础软体（BSW）

基本的软体模块提供了一个 ecu 的基础设施功能, 它包含了标准化和 ecu 的特定组件。基本软体模块分为子层, 如下表4.1 所示, 根据其功能 [32]。

服务 Services

内存管理, 诊断, 看门狗, ECU 状态管理, CRC, 端到端保护, 并实现 BSW 模块的调度功能。

通信 Communication

车载网路通信与管理服务

OSEK RTOS

实时调度、任务和事件管理、告警、资源分配和中断处理服务。还处理内核到多核处理器中的应用程序的分配。

MCAL

i/o 设备的驱动程序介面, 通信、存储器和单片机直接访问和内部外设

4.3.3 微处理器抽象层（MCAL）

MCAL 包含微控制器的内部驱动程序, 它使 AUTOSAR 堆栈的上层独立于硬体实现 [32]。在本论文中, 利用 MCAL 中的 can 通信模块接收和处理 can 网路模拟器工具 CANalyzer 中包含数据值的帧。

4.3.4 AUTOSAR 操作系统

为了保持与汽车遗留应用程序的向后兼容性, AUTOSAR os 基于标准的 OSEK os 规范 [6]。AUTOSAR OS 的基本特征是 [6]

  1. 可以被静态配置和伸展
  2. 可服从某种实时性能定制
  3. 提供基于运行时间的调度和保护功能的优先顺序
  4. 可以在低端处理器上做主机并不需要外部资源

4.3.4.1 AUTOSAR 理念

任务管理

任务是由调度程序执行的软体应用程序的实体。每个任务都可以在任何状态下, 如下所述。

1. 运行: 正在执行任务, 并将 CPU 时间分配给此任务, 并在处理器平台中, 在任何时间点, 只有一个任务可以处于运行状态。

2. 就绪: 任务已满足执行的所有条件, 并等待计划程序将处理器时间分配给它。

3. 等待: 等待事件发生以继续执行的任务。

4. 暂停: 由计划程序终止的任务进入此状态, 直到由计划程序再次激活为止。

任务在配置阶段静态分配其优先顺序, 以便计划程序可以根据其优先顺序 [6] 确定任务执行的优先顺序。

调度器

它是一个系统应用程序, 它确定应授予系统资源 (即处理器、i/o 设备等) 访问许可权的任务。OSEK OS 使用事件驱动的、固定优先顺序调度策略, 其中任务由周期性定时或零星事件激活和停用, 任务根据其分配的优先顺序执行。

事件机制

AUTOSAR OS 使用事件来同步任务, 即任务从运行状态转换为等待状态, 反之亦然。事件可以是计时器的过期、接收消息、资源的可用性、硬体中断的通知等。

资源管理

AUTOSAR OS 模块使用资源管理来保护和协调共享资源 (如内存、硬体设备等) 的不同任务。它使用 OSEK 优先顺序上限协议 (PCP) 来防止死锁和优先顺序反转问题, 即降低优先顺序任务的间接抢占, 并延迟执行等待访问共享资源的更高优先顺序任务。根据该协议, 所有共享资源都被指定为静态上限优先顺序, 即优先顺序最高的任务, 将使用该资源。每当任务获得资源时, 其优先顺序将临时提升到资源的最高优先顺序, 并且它将是在共享此资源的所有任务中处于运行状态的唯一任务, 因此, 死锁和优先顺序反转问题永远不可能发生。

告警和计数

AUTOSAR 机制为周期性事件的处理提供了警报和计数器机制, 即在常规事件中发生的中断、定期接收帧等。计数器等效于计时器。每个计数器都与当计数器到达某个特定值时过期的报警功能相关联, 在警报到期时, 任务被激活, 或者为任务设置了事件。

除此之外, AUTOSAR OS 还通过提供相应的中断服务常式 (isr)、将应用程序的可运行实体映射到任务、内存和定时保护等, 执行硬体和软体中断的处理。

4.3.4.2 操作系统抽象层

在 AUTOSAR 框架中, 标准 OSEK OS 规范用于 AUTOSAR 软体组件的执行。如果将这些软体组件实现为在专有 OS 之上运行, 则应使用操作系统抽象层 (OSAL) 来模拟和提供 OSEK os 介面。

4.3.5 AUTOSAR 运行环境 （RTE）

在 AUTOSAR 框架中, RTE 是中间层提供应用层服务来自BSW 层的。SWCs 之间的所有通信, 无论是 ecu 还是内部 ecu 是由 RTE 使用虚拟功能汇流排 (VFB) 的介面, 即映射连接器和埠来完成的。它还负责 SWCs [33] 的实时调度。RTE 的基本任务是确保 SWCs 独立于他们所映射的 ECU。由于深港西部通道的依赖类型的应用, rte 必须为特定的 ECU, 它服务和 rte 将区分不同的 ecu 和 SWCs 可以保持相同的完成预期的功能 [33]。

4.3.6 软体组件（SWC）

AUTOSAR 应用程序包括由连接器 [34] 互联的几个 SWCs。SWC独立于硬体基础设施, 它封装了部分或完整的汽车功能。SWC包括一个正式说明, 其中包含有关操作和数据元素、通信属性、特定实现、内部行为 (可运行实体、任务和事件)、组合和所需硬体资源 [32] 的详细信息。SWC的本质属性是, 它应该是原子的, 只有一个实例, 一定的SWC可以存在于一个车辆, 并分配给一个 ECU [32]。

4.3.7 虚拟功能汇流排（VFB）

虚拟功能汇流排是由 SWCs、其他组件和整个车辆的系统环境之间的互连和数据交换组成的抽象层, 独立于任何底层硬体 [34]。VFB 的功能由埠、埠介面和映射连接器提供。软体组件将所需的埠 (Rport) 作为输入, 并提供埠 (Pport) 作为输出, 以便与其他软体组件交互和交换数据元素。埠应与埠介面相关联, 定义在不同 SWCs [34] 埠之间传输的服务或数据。由 VFB 支持的常用埠类型介面是客户端-伺服器和发件人-接收端介面。

在我们的应用中, 我们通过 RTE 在深港西部通道和 BSW COM 模块之间使用发件人-接收器通信机制。此机制提供非同步 (非阻塞) 通信, 其中发件人将信息分发给多个接收方, 或者一个接收方从多个发件人处获取信息, 并且没有数据或控制流响应机制。软体组件之间的埠 (需要相互交互和通信) 是使用组件连接器链接的, 如下面的图4.5 所示 [34]。

技术需求和整合策略

本论文的工作, 我们建议设计一个多用途 ECU 的试点实施, 以研究和解决的集成问题的汽车控制和娱乐应用。本节简要介绍了我们的试验性实施的要求、备选整合策略的概述, 然后我们使用虚拟化解决方案来激发选择的整合策略背后的原因。我们重点介绍了原型模型中的功能组件, 特别是虚拟化解决方案及其选择的基本原理。

5.1 多用途ECU系统的需求

系统设计总是从对系统的设置要求开始, 以便确定设计选择。多用途 ECU 系统的试点实施的主要挑战是寻找一个适合于同一目标的实时汽车控制和非实时娱乐信息系统的通用操作系统平台或系统结构。硬体, 共享系统资源, 如 CPU、内核和 RAM 内存、i/o 外围设备等。另外, 通用 os 平台应该提供一种跨操作系统的通信机制, 以便在共享硬体平台上运行的这些不同的应用程序能够在它们之间交换数据信号。

通用的操作系统平台为多用途 ECU 应该有以下功能要求。

灵活的调度机制

汽车控制应用程序必须快速响应, 因此它们需要立即访问资源。他们有严格的时间限制, 应该在规定的期限内执行。娱乐资讯应用程序不需要快速响应, 可以容忍延迟, 因为它们具有软或非实时要求。通用 OS 平台应提供一种动态调度机制, 以便在不同功能模块 (如 AUTOSAR 应用程序中的实时任务) 和 Linux 应用程序中的非实时任务之间有效地分配 CPU 时间, 通过给予高对实时任务的优先顺序, 同时仍然为非实时过程提供最佳的工作时间。

系统资源分区和分区之间的隔离能力

通用 OS 平台应该提供在 AUTOSAR 和 Linux 应用程序之间共享和划分嵌入式系统资源 (如内核、用户内存和 i/o 设备) 的功能。他们之间应该有严格的分离和隔离;不同的应用程序应该在公共平台中安全地共存和执行, 而一个错误的应用程序不应影响系统中的其他应用程序。在我们的试验模型中, AUTOSAR 和 Linux 应用程序的执行应严格隔离, 即使它们是在同一硬体平台上进行的, 并且共享诸如 CPU 时间、i/o 外围设备等资源。

应用程序之间的通信

通用 OS 平台应该为 AUTOSAR 和 Linux 应用程序之间的消息信号传输提供一种简单而快捷的方式, 即不同应用程序之间的通信应该在同一硬体平台上进行本地化, 而不需要通过外部 can 通信汇流排。

支持AUTOSAR架构和通用操作系统

统一的 ECU 系统应该有能力承载不同的操作系统, 如 AUTOSAR 体系结构 (实时控制应用程序) 和 Linux (非实时的娱乐资讯应用程序), 而无需进行实质性的修改。

除了上述, 通用操作系统平台应该能够满足以下非功能的需求, 是可测量的。

满足汽车需求例如快速启动和最小通信延迟

统一的 ECU 系统应满足汽车的实时要求, 如快速启动时间、最小信号通信延时等。例如, 汽车的实时应用应立即启动在5至10秒内, 一旦汽车的动力。统一 ecu 系统的启动时间和 AUTOSAR 和 Linux 应用程序之间的信号通信延迟应该有更好的或可比的性能, 与目前的技术, 远程连接的 ecu 系统的状态。这是很重要的, 因为汽车公司的竞争主要是成本/性能比。

基于上述要求, 我们分析了不同的设计方案, 为我们的原型模型选择合适的整合策略。

5.2 整合策略调研

提出了多用途 ECU 模型的通用体系结构的各种设计策略, 并给出了我们选择的设计策略背后的动机。

5.2.1 Linux 容器和实时Linux补丁 Patches

linux 容器 (LXC) 技术提供了一种轻量级虚拟化, 用于在单个 linux 内核和根文件系统(RFS) 上运行多个独立的 linux 系统, 并在容器之间提供资源隔离, 使用内核控制组 [53]。因此, Linux 容器技术等同于 Type2 管理程序或操作系统级虚拟化实现。该机制不虚拟化硬体平台;它只提供不同系统之间的分离。OS 级别指令直接在 CPU 上执行, 因此不需要在虚拟中进行动态翻译。RTLinux 是一个硬实时的 linux 变体, 它包含一个与典型的 linux 内核共存的小的实时内核, 可以用来支持实时控制应用程序。我们考虑将 LXC 与 RTLinux 结合使用, 作为多功能 ECU 系统的一种设计方案。但是, 这一方法有几个缺点。

  • linux 容器将只支持 linux 操作系统;AUTOSAR 体系结构需要在 Linux 操作系统的顶部移植, 并且需要大量的努力。
  • 此外, RTLinux 仅包含一个简单的基于优先顺序的处理一般中断的调度程序, 因此它不能完全取代 OSEK rto 的功能。因此, 我们需要修改内核, 以包括根据特定的汽车应用需求的可行的调度演算法。这是相当复杂的, 因此, 它不能充分支持硬实时应用程序。
  • 此外, 由于 Linux 内核本身没有强大的安全级别保证, 而且它不能提供像虚拟化技术这样的高保护级别, 因此域隔离和分离的程度更小。
  • 关键的汽车应用程序不能立即启动, 因为它需要等待, 直到 Linux 内核的启动, 它本身需要将近5秒。

5.2.2 基于AUTOSA 架构的微系统

有几篇文献研究文章提出一个 AUTOSAR 兼容微核 [35, 36]。在这种方法中, 最小的核心和安全相关功能, 如任务创建、调度和内存访问, 都是由 AUTOSAR 操作系统执行的。它是在 CPU 的特权模式下执行的唯一的软体模块, 从而创建一个具有最小代码库的薄微内核层。为了支持异构操作系统, 需要对基于微内核的 AUTOSAR 模型中的任务调度进行修改, 以包括一种用于实时和非实时任务执行的灵活调度演算法 [36]。然后 AUTOSAR 微内核可以被认为是一个虚拟化平台和其他操作系统, 如 Linux/Android 可以通过适应它的 AUTOSAR 架构的 VFB 层, 如图5.1 所示。此外, AUTOSAR 4.0 还提供内存分区和保护机制 [5]。然而, 仍然开发一个 AUTOSAR 兼容的微内核需要进行重大的体系结构更改, 如上文所述, 需要重大的技术突破来满足安全关键的需求, 并提供支持使用高解析度图形和复杂通信栈的信息娱乐和连接应用程序。这种方法需要相当大的努力和时间 (也许是几年), 因此, 对于我们打算在几个月内发展的试点实施来说, 这不是一个可行的解决办法。

5.2.3 基于系统架构的虚拟化

虚拟化解决方案已经部署在电子航空、电信交换机和下一代移动设备的嵌入式系统领域, 用于系统整合和不同功能的隔离 [23]。目前, 汽车嵌入式系统还实现了几个分散式功能域和计算要求较高的软体应用。大多数的汽车系统已经开始使用通用软体与广泛的不安全的代码库和丰富的开源 api [10]。虚拟化技术为多个功能域提供了可伸缩的体系结构, 简化了软体设计, 因为它为开发人员提供了一个通用的抽象层, 无需复杂的操作系统的移植过程, 因此现有的用户在没有重大修改的情况下, 应用可以很容易地在汽车系统中重复使用。它可以有效地利用处理器状态的处理能力, 通过并行执行应用程序 [24] 来提供峰值性能潜力。此外, 在汽车系统的几个不同的应用可以共享的硬体资源, 如内存和 i/o 外设设备之间使用的虚拟化解决方案。所选的虚拟化技术满足了5.1 节所列的多用途 ECU 的试验性实施的所有要求。它可以为托管多个不同的操作系统提供支持, 然后确保它们之间的分离和隔离。在不同操作系统中的应用可以通过虚拟哈技术提供的相互间的通信机制相互作用。大多数的虚拟化解决方案本质上都部署了高级的动态调度机制。此外, 大多数现代处理器具有较高的处理速度和能力, 因此, 它可以抵消由于附加的虚拟化抽象层而导致的小处理开销。因此, 为了解决汽车嵌入式系统的集成问题, 我们决定采用虚拟机管理技术作为整合策略来选择系统设计。

5.3虚拟化技术实施原型的配置

所提出的多功能 ECU 的试验性实施的功能部件

a) COQOS 作为虚拟化技术解决方案

b) I.MX53 sabre ARD作为目标硬体平台

c) AUTOSAR 4.0 和 Linux (内核: 2.6. 35) 作为两个 OS 分区

d) AUTOSAR 控制应用开发使用 MECEL PICEA套件 [38]。

e) 使用 MECEL POPULUS套件 开发的 Linux HMI 仪器集群应用程序。

5.3.1原型模型功能元件选择的基本原理

基于 AUTOSAR 体系结构和基于 Linux 操作系统的非实时资讯娱乐应用的汽车实时应用的参考实现的先导演示系统, 在通用处理器平台上同时执行, 旨在作为规模下降, 多用途 ECU 的原型模型, 可以部署在未来的汽车系统。主要的挑战是设计一个简单的原型, 可以建模最终工程系统, 因此, 选择和设计的试点模型的功能组件, 使他们可以模拟的功能, 真正的工作 ECU 系统作为密切尽可能。此外, 重要的是要记住, 所选的功能组件应具有良好的相互依存性, 以便它们可以集成到一个完整的系统。

虚拟化技术方案

虚拟化解决方案的选择对于多用途 ECU 原型的实现至关重要, 因为它应该提供不同应用程序灵活调度、划分和隔离资源以及支持移植 Linux 的能力和 AUTOSAR 操作系统体系结构。有几个开放源码以及专有的虚拟化解决方案适用于嵌入式系统领域, 如基于内核的虚拟机 (KVM)、Xen、OKL4、风河管理软体和 COQOS。我们对这些程序的特性进行了比较分析, 如表5.1 所示, 为了为我们建议的多用途 ECU 的试验实施提供 Linux OS 和 AUTOSAR 体系结构的一个合适的管理程序。

5.3.2.1现有虚拟化方案的比较分析

有几个开放源码的虚拟化解决方案, 如 KVM 和 Xen, 我们认为他们的原型实现 [55, 57]。

KVM: 这是一个开源的虚拟化软体, 它利用 Linux 作为主机操作系统。Guest- OS 在 Linux 内核上被移植, 它需要硬体虚拟化扩展 [55]。这方面的主要缺点是, Linux 内核不支持硬实时应用程序, 充其量只能用于软实时应用程序。它主要用于伺服器系统和一般嵌入式设备 [54, 57]。

Xen: 这是最常用的开源 Type1 型的虚拟化系统, 如果处理器平台 [54] 中没有可用的硬体虚拟化扩展, 它可以支持完全虚拟化以及半虚拟化。由于它是开源代码, 开发人员需要根据目标应用程序的要求实现合适的和特定的调度演算法。它主要用于移动平台和一般嵌入式设备 [55, 56]。

即使, 我们可以通过使用开放源码虚拟化系统来避免高昂的成本, 但对于开源程序的安全保障信息的级别却是有限的, 这对于汽车嵌入式应用来说是至关重要的。KVM 和 Xen 程序都不支持 AUTOSAR 体系结构, 因此需要大量的努力将其放在虚拟化系统抽象层的顶层, 以便于我们的试验实现。

有几个专有的虚拟化解决方案, 如风河, OKL4 Microvisor 和 COQOS, 我们认为他们以及我们的原型实现多用途 ECU 系统。

风河管理系统: 这是一个由风河实现的 Type1 嵌入式虚拟机管理程序, 它为高性能嵌入式应用程序 [59] 提供了实时行为和功能所需的支持。它提供了一个精简的虚拟化层, 基本代码最少。它实现了可靠和安全的分区, 并且可以根据目标应用程序的要求对调度机制进行配置或修改。即使, 它为各种处理器架构模型提供支持, 但在我们的论文工作时, 没有可用于飞思卡尔主板的bsp程序包。风河虚拟化解决方案用于广泛的嵌入式应用领域, 如航空航天、电信设备、消费和医疗嵌入式设备、移动平台以及汽车系统 [59]。

OKL4 Microvisor: 这是一个开源的, 基于微内核的虚拟化系统, 由 OK 实验室提供。它对实时系统、资源管理和最小代码库有很好的支持。它主要用于移动平台, 并支持一些Guest-os访客操作系统, 如 Linux 发行版、Android、Symbian 和Windows。但是, 对于 AUTOSAR 体系结构, 没有太多的支持, 因此需要进行大量的工作, 将其移植到 OKL4 Microvisor [58、60] 之上。

COQOS: Open Synergy的 COQOS 产品是基于 SYSGO 的 PikeOS

微.虚拟化层非常薄, 只有大约3k 行代码。它还提供了对 Linux、Android 和 AUTOSAR 框架的全面支持。此外, 微内核还允许安全可靠地分配处理器资源。它还实现了最高的安全和安全标准, 因为 PikeOS 微内核已广泛应用于航空电子和安全关键应用领域。它还提供了 Linux 和 AUTOSAR 操作系统之间的可配置的通信桥。COQOS 使用虚拟而不是硬体辅助虚拟, 并提供虚拟版本的 Linux 和 Android 访客操作系统。另一个吸引人的因素是, COQOS 已经被专门设计为汽车 ECU 系统和集成的 AUTOSAR 为基础的汽车应用与 Linux/Android 的娱乐资讯应用 [1226]。

5.3.2.2 COQOS虚拟化解决方案

最后, OpenSynergy 的 COQOS 虚拟化方案被选为多用途 ECU [12] 的试验实现的合适的虚拟化解决方案。选择 COQOS 虚拟化解决方案的主要动机是因为它满足5.1 节中指定的所有要求。

  1. 资源分区: 如第4.2.2 节所述, COQOS 提供了一种资源分区机制, 用于为不同的 OS 分区分配系统资源。AUTOSAR 和 Linux OS 可以在单个硬体平台上单独的分区上托管, 并使用此机制共享系统资源。
  2. 时间划分机制: 如4.2.3 节所述, COQOS 提供时间划分机制, 用于为驻留实时和非实时应用程序的不同 OS 分区分配 CPU 时间插槽（time slots）。AUTOSAR 实时和 Linux 的非实时应用程序可以使用这种灵活的时间划分方案来访问 CPU 时间。
  3. 系统间通信机制: 如4.2.4 节中所述, COQOS 提供了几种通信方法, 以使分区之间能够进行操作系统间的通信, 并利用其中一种方法在 AUTOSAR 和 Linux 之间传输数据信号在我们的原型模型中的应用。
  4. COQOS 是专门为汽车领域设计的, 它对 AUTOSAR 体系结构和嵌入式 Linux 操作系统的虚拟有很好的支持 [12]。
  5. 它基于 PikeOS 微内核, 它提供了一个最小的代码库的轻量级抽象层。它已广泛应用于安全关键航空电子设备和工业应用领域。它可以实现硬, 实时功能和认证符合严格的安全标准 (IEC61508, EN 50128 等)[26]。

5.3.3 目标硬体

飞思卡尔 i.MX53 Sabre ARD 可以提供以下性能

a) 高处理速度高达 1 GHZ, 用于承载附加的虚拟化层。

b) 针对CAN通讯的FlexCAN介面模块。

c) 支持 Linux OS 和执行2D/3D图形加速的功能, 并以最小的 CPU 负载支持娱乐资讯应用程序。

因此, 其他功能组件 (如虚拟化、汽车和 Linux 参考应用程序) 可以无缝地集成在这个硬体平台之上。

对先导模型的参考应用进行了选择和设计, 使其能够密切模拟实际工作的 ECU 的功能。

5.3.4 使用Autosar架构的汽车参考应用程序

我们使用 AUTOSAR 4.0 体系结构开发了一个汽车控制应用程序。车辆实时数值, 如速度, 每分钟转速 (RPM), 和发动机温度这个控制应用程序通过模拟器工具周期性的发送到 CAN 网路。AUTOSAR 应用程序主要由一个SWC应用, COM 通信栈, BSW OS 模块和生成的 RTE 模块组成。

  1. COM 通信栈 (BSW 模块, 如 CanDrv、CanIf、PDUR 和 com) 被配置为从 can 模拟器工具接收包含负载数据的 can协议帧, 封装有效载荷数据, 最后通过 RTE 模块将其交付到SWC。
  2. 带有接收端埠和发送/接收介面的SWC被创建用来通过 RTE 周期性地从 BSW 通信层读取数据值。此外, 它由一个称为可运行的 C 函数组成, 它实现了 ECU 功能的实际业务逻辑。SWC将执行一些处理与这些数据值为发动机控制功能的汽车 ECU。
  3. 在 RTE 模块中, 创建可运行的调度所需的周期性定时事件。RTE 读取这些功能, 使SWC可以访问 BSW 通信模块和获取适当的数据信号。
  4. BSW os 模块由与 RTE 计时事件相关的 os 任务组成。SWC将利用此 OS 任务对可运行函数进行周期性调度。在 AUTOSAR 应用程序 [5] 中BSW 调度程序包含激活任务的时间表。

AUTOSAR 应用程序被使用Volcano VSx 工具配置, 它利用 BSW, RTE 软体库和自动生成工具提供的 MECEL Picea套件 [38]。这个汽车应用程序模拟一个典型的控制过程功能, 可以部署在一个引擎管理 ECU。

5.3.5 使用Linux OS的导航信息参考程序

我们使用了一个仪表 HMI 应用程序,使用 MECEL PoPulus套件作为 Linux 参考应用开发 [39]。Linux 应用程序从汽车控制应用程序中定期获取输入数据值, 然后在 HMI 显示单元运行时更新仪表和指示, 如速度、转速、引擎温度等。这是一个先进的 GUI 应用程序, 部署加速2D/3D图形的高解析度和帧率。它通常类似于可用于汽车娱乐资讯单元的仪表板应用程序。


推荐阅读：
相关文章