操作系统/体系结构论文导读（四十一）：Re-Thinking Mixed-Criticality Architecture for Automotive Industry 20‘ICCD

一、文章INTRO

1. 文章背景与挑战

这篇文章分析了当前理论模型与工业标准（如ISO26262）之间的不匹配，并提出了一个工业级的混合关键性系统架构，称为Z-MCS。这种架构的设计基于传统的自适应混合关键性（AMC）模型，但添加了对工业安全需求的考虑。关键挑战如下：

• 理论与实践的差距：理论模型（如Vestal的MCS模型）关注于任务分配、可调度性分析和资源管理，但往往忽视了工业中的安全标准要求，比如运行时的安全分析、关键性任务的隔离等。
• 多关键性系统的复杂性：现代的安全关键性系统，如自动驾驶等，需要整合不同的功能模块，这些模块具有不同的安全关键性（ISO26262中的ASIL A到D），而且这些模块共用硬件资源。确保这些模块不会互相干扰，且能够在发生故障时优雅降级，是当前MCS架构的一个重要难题。

2. Z-MCS架构的关键特性

Z-MCS架构在传统AMC模型的基础上，针对工业应用场景增加了几项关键的功能：

• 运行时安全分析：在不同系统模式下，Z-MCS能够确定哪些应用需要保留，哪些可以终止。该功能能够应对运行时硬件故障，确保系统的安全性。
• 隔离与划分：Z-MCS对系统中的不同关键元素进行了严格的时间、空间和故障隔离，确保任务之间不会相互影响，尤其是高关键性任务和低关键性任务之间的隔离。
• 可调度性分析：文章提出了通用的可调度性分析方法，以确保系统能够在给定的任务集下按时完成任务。这种分析方法不仅适用于双模式的MCS系统，还可以扩展到包含更多模式的系统。

3. 三种实现方法

文章进一步提出了Z-MCS的三种实现方法：

1. 软件虚拟化（Z|swv）：利用虚拟化技术来实现不同关键性应用之间的隔离。
2. 受信任执行环境（Z|tz）：通过硬件级的隔离技术（如ARM TrustZone）来增强系统的安全性和性能。
3. 硬件辅助虚拟化（Z|hwv）：在硬件层面实现虚拟化和隔离，以进一步减少系统的开销和提高性能。

 二、SOTA

1. 传统的MCS模型

• 执行模式：传统的MCS模型假设系统具有多个执行模式（例如Mode A, B, C, D等），每个任务都有不同的执行时间和关键性级别。
• 任务定义：每个任务 τi\tau_iτi​ 由以下属性定义：
  • 周期（Ti）：任务的周期时间。
  • 截止时间（Di）：任务的相对截止时间。
  • 优先级（Pi）：任务的调度优先级。
  • 关键性级别（li）：任务的关键性级别，可以是A, B, C, D等。
  • 最坏执行时间（WCET）：这是系统在不同关键性模式下的最坏执行时间估计集，例如 Ci,A,Ci,B,...,Ci,li，表示在不同模式下任务的执行时间。任务的执行时间在更高关键性模式下会变得更加保守，即：Ci,A≤Ci,B≤...≤Ci,li
• 模式切换：系统从最低模式（如Mode A）开始运行，所有任务都被调度执行。如果某个任务超出了在Mode A下的执行预算（即Ci,A），系统将切换到下一个模式（例如Mode B），并暂停所有关键性低于B的任务（即li<B的任务）。

2. Vestal的MCS模型

• 扩展：Vestal在2007年提出了最早的MCS模型，该模型最初仅针对单核处理器和双模式系统（即低关键性和高关键性模式）。后来，该模型被进一步扩展，包括多模式、多关键性级别的支持，任务在被暂停后是否重新激活等。
• 模型基础：Vestal的模型为Z-MCS的提出奠定了基础。Z-MCS假设系统模式不会向后切换，且一旦任务被终止，它们不会在之后的模式中重新激活。

3. 系统架构

• 系统架构：文章基于理论模型下的不同框架提出了MCS的通用系统架构。架构参考了嵌入式系统/计算机架构，并额外加入了系统监控器。该监控器位于操作系统层，负责任务监控和系统模式切换的管理。
  • 系统监控器的实现：监控器可以通过多种方式实现，比如修改后的操作系统内核，或者通过额外的虚拟机监控器（hypervisor）来管理任务和模式切换。
• 工业需求缺失：尽管理论模型提供了坚实的基础，但在实际工业应用中，例如汽车和航空系统中，MCS的实现需要更复杂的架构，尤其是对于安全、任务隔离和模式切换的管理。Z-MCS正是为了弥补这一缺陷而提出的，旨在结合理论模型和工业标准，创建一个适用于现实应用的混合关键性系统架构。

三． 工业要求中的 MCS

1. 工业MCS架构的标准化问题

目前，工业MCS架构的开发并没有得到任何安全相关标准的系统化指导。然而，一些基础概念和要求，比如“在共享平台上集成不同关键性的安全功能”，已由ISO26262等标准提出。这表明，虽然标准并没有直接提供指导，但它们确实涵盖了MCS的某些核心原则。

2. 优雅降级（Graceful Degradation） vs. 模式切换（Mode Switch）

• 模式切换：在理论模型中，系统模式切换是一种关键策略，用于通过暂停低关键性任务来确保高关键性任务的执行。然而，工业标准并没有明确定义系统的模式切换。

• 优雅降级：根据ISO26262标准，“优雅降级”是指在系统故障时，优先保持更重要的系统功能，而放弃次要功能。换句话说，模式切换的实施关键在于确定哪些功能更重要，并确保这些功能的执行，而不是单纯根据任务的关键性级别来决定。

  然而，在工业环境中，“高关键性”并不总意味着“更重要”。关键性级别的决定需要通过安全评估来完成，例如危险分析（Hazard Analysis，HA）。关键性级别的决定通常取决于**严重性（Severity）、暴露率（Exposure）和可控性（Controllability）**三大因素。尤其是严重性，评估的是任务在故障情况下可能导致的灾难性后果。这样，如果在模式切换时终止一个低关键性任务，它可能比终止一个高关键性任务带来更严重的后果，尤其是当低关键性任务的严重性较高时。

  此外，依赖性也是一个关键因素。如果一个高关键性应用依赖于低关键性应用的输出，那么终止低关键性任务也可能导致高关键性任务的失败。

• 缺失需求 I：在模式切换过程中，必须对正在执行的应用进行安全分析（无论是运行时还是离线分析），以确定需要保留的任务，避免因终止某些任务而引发灾难性后果。

3. 自由无干扰（Freedom from Interference） vs. 分区与隔离（Partitioning and Isolation）

• ISO26262的要求：ISO26262及其他安全相关标准中，都明确要求对不同关键性功能之间进行隔离和分离。这是为了确保在系统架构中，各个关键性元素能够独立执行，避免相互干扰。标准还指出，如果在架构设计中无法论证元素之间没有干扰，则所有这些元素都必须按照最高的ASIL级别（Automotive Safety Integrity Level，汽车安全完整性等级）进行开发。

• 隔离类型：文章讨论了三种必须充分考虑的隔离形式：

  1. 时间隔离（Temporal Isolation）：确保不同关键性任务的执行时间互不影响，避免一个任务占用过多的处理器时间而影响其他任务。
  2. 空间隔离（Spatial Isolation）：确保任务在不同的内存区域中运行，防止内存冲突或数据污染。
  3. 故障隔离（Fault Isolation）：确保不同关键性任务之间的故障不会传播，尤其是在低关键性任务容易发生故障时，避免它影响高关键性任务的执行。

• 工业MCS的隔离需求：在工业MCS架构中，不同关键性级别的组件有不同的设计和验证要求，尤其是容错能力的差异。因此，空间隔离和故障隔离可以避免低关键性组件中的故障传播到高关键性组件中。而时间隔离则能有效防止由于某个任务占用过多处理器时间而引发的系统故障。

• 缺失需求 II：在工业MCS架构中，必须同时保证不同关键性元素之间的时间、空间和故障隔离。虽然已有的MCS框架引入了应用层的隔离，但所需的隔离必须涵盖整个系统架构。

四、 Z-MCS通用工业架构详解 

1. 运行时安全分析

文章提出了一种两级安全分析来解决模式切换中的关键问题（缺失需求 I），确保在模式切换时保留系统中“重要功能”的正确性。该分析分为两步：

• 第一级：失效模式效应分析（FMEA）
  在模式切换过程中，首先评估终止任务的影响。如果终止某个任务会导致不可接受的后果（例如灾难性的影响），则该任务会被保留，否则将被终止。

• 第二级：依赖性分析
  在保留任务的基础上，分析任务之间的依赖关系。如果一个低关键性任务被终止，而该任务是某个高关键性任务的依赖项，那么该任务必须被重新加入保留任务集合中，以确保其依赖关系不会被破坏。

该安全分析的最终结果是生成两个集合：1）保留的任务集合，2）终止的任务集合。该分析既可以在线执行，也可以离线执行。

2. 分区与隔离

为了满足工业对隔离的需求（缺失需求 II），Z-MCS架构对不同关键性级别的应用提供了时间、空间和故障隔离。这些隔离通过软件虚拟化、受信任执行环境和硬件辅助虚拟化三种方法实现。

• 时间隔离确保高关键性任务不会被低关键性任务抢占过多处理时间。
• 空间隔离确保内存和资源之间没有冲突。
• 故障隔离防止低关键性任务的错误影响高关键性任务。

3. Z-MCS的实现方法

Z-MCS的三种实现方法

• (a) 软件虚拟化（Z|swv）：基于虚拟机隔离不同关键性任务，系统监控器集成在虚拟机管理器中。
• (b) 受信任执行环境（Z|tz）：利用ARM TrustZone实现双世界隔离，高关键性任务运行在安全世界。
• (c) 硬件辅助虚拟化（Z|hwv）：通过硬件设计的虚拟机监控器减少系统开销，并提高性能。

Z-MCS提供了三种不同的实现方式，分别为：

1. 软件虚拟化（Z|swv）：

   • 使用虚拟化技术在不同的虚拟机（VM）之间实现隔离。
   • 不同关键性的任务被分配到不同的VM中，在系统模式切换时，如果某个VM中的所有任务都被暂停，该VM将被直接终止。
   • 系统监控器集成在虚拟机监控器（VMM）中，负责虚拟化、安全分析和模式切换。

2. 受信任执行环境（Z|tz）：

   • 基于ARM TrustZone技术，将系统分为安全世界和普通世界两个执行环境。
   • 高关键性任务分配到安全世界，低关键性任务分配到普通世界。
   • 该实现的限制是，每个处理器上只能支持两个关键性级别。
   • 系统监控器在特权模式下运行，负责域间上下文切换、安全分析和模式切换。

3. 硬件辅助虚拟化（Z|hwv）：

   • 与软件虚拟化相似，但该实现通过开源硬件设计的虚拟机监控器（VMM）来减少系统开销。
   • 通过硬件设计的VMM，可以将大部分虚拟化和低层驱动的开销从软件转移到硬件，从而提高系统性能和可调度性。
   • 该方法的限制在于需要额外的硬件开销，并且需要修改操作系统内核来支持硬件虚拟化。

五、理论分析

1. 响应时间分析概述

Z-MCS系统的响应时间分析与传统的双模式AMC架构不同，Z-MCS适用于包含两种或更多模式的系统。该分析分为两个主要阶段：

• 阶段1：验证每个稳定系统模式的可调度性。
• 阶段2：验证系统模式切换的可调度性。

2. 稳定系统模式的分析

在稳定模式K中，能够执行的任务集由高关键性任务集（HΓ(K)）和保留任务集（Γ∗(K)）组成：

• HΓ(K)：返回在模式K中关键性级别等于或高于K的任务。
• Γ∗(K)：由之前的模式切换中的安全分析决定，即在模式K中需要保留的任务。

对于每个任务，其最坏情况下的响应时间计算公式如**公式(1)**所示：

• ：任务 τi在模式K中的计算时间。对于高关键性任务直接使用Ci,K。对于保留的低关键性任务，使用其最高的WCET值。
• ：表示来自比 τi优先级更高的高关键性任务的干扰。
• ：表示来自比 τi优先级更高的保留任务的干扰。

公式(2) 进一步定义了 的计算方式：

这意味着，如果任务的关键性级别低于模式K，则使用该任务的最高WCET值，否则使用模式K下的WCET值。

3. 任务保留集的定义

保留任务集 Γ∗(K) 由公式(3)给出，遵循了前面提到的任务保留标准：

• 保留任务的计算需要考虑前一个模式中的保留任务集合，以及当前模式中的依赖关系。

4. 监控器的干扰

Z-MCS的系统监控器会周期性地检查和维护系统状态，这也会对任务的响应时间产生干扰。在Z|swv和Z|tz架构中，监控器以特权模式运行，而在Z|hwv架构中，监控器集成在硬件中。

从分析角度，监控器可以视为具有最高优先级和关键性级别的周期性任务。因此，监控器的干扰由**公式(1)**中的 ​ 计算，其中：

• Chv：监控器每次执行所需的计算时间。
• Thv​：监控器的周期。

5. 模式切换中的安全分析

在模式切换开始时，Z-MCS会对当前模式K中的每个任务（包括关键性为K的任务集Γ(K)和之前模式保留的任务集Γ∗(K)）执行两级安全分析，以确定在新模式K+中将保留或终止的任务集，即Γ∗(K+)（保留任务）和Γ¬(K+)（终止任务）。安全分析的最坏情况计算时间由 Csa 表示，它包括对每个任务的严重性和依赖性检查。

在模式切换期间，所有任务将遭遇最坏情况下的干扰，时间为 (∣Γ(K)∣+∣Γ∗(K)∣)×Csa(|Γ(K)|+|Γ∗(K)|) × Csa(∣Γ(K)∣+∣Γ∗(K)∣)×Csa，其中 ∣⋅∣|·|∣⋅∣ 表示任务集合的大小。这是因为在模式切换开始时，运行时安全分析会非抢占式地执行，并对每个任务进行检查。

安全分析完成后，任务集Γ∗(K+)（保留任务）和Γ¬(K+)（终止任务）将被确定。模式切换时，Γ¬(K+)中的任务会被终止，Γ∗(K+)中的任务将继续在新模式K+中执行。

6. 模式切换的响应时间公式

对于模式切换从K到K+的任务 τi\tau_iτi​，其响应时间计算公式如 公式(4) 所示：

公式解析：

• ：表示在模式切换开始时，运行时安全分析对所有任务的干扰时间。
• Ci,←K+：表示任务 τi在新模式K+下的执行时间。
• ：表示任务在模式K+中由于系统监控器的周期性检查所受到的干扰。
• ：表示来自模式K+中优先级较高、关键性等级不低于K+的任务的干扰。
• ：表示来自模式K+中优先级较高且被保留的任务的干扰。
• ：表示在模式切换期间即将被终止的任务对当前任务的干扰。

最后一项中，注意到由于终止任务不能执行整个任务的繁忙周期，所以其干扰时间是根据旧模式下的响应时间（RiK​）来计算的，而不是新模式下的响应时间。

7. 终止任务集的定义

在模式切换时，终止任务集Γ¬(K+)由 公式(5) 给出：

任务 τj​ 只有在其严重性低于新模式的最低要求（SK+​）且不属于任何当前活动任务的依赖集合时，才会被终止。这确保了在模式切换时不会错误终止对高关键性任务有重要依赖的低关键性任务。

六、总结与结论

• 理论模型与工业标准的差异： 本文通过系统架构的角度，正式分析并阐述了混合关键性系统（MCS）理论模型与工业标准之间的差异。传统的理论模型（例如AMC模式）在工业中的实际应用受限于这些差异，尤其是在安全性方面的要求，如分区、隔离和运行时安全分析。

• Z-MCS架构： 文章提出了一个通用的工业级架构，称为Z-MCS，它是在传统AMC模型基础上构建的，并且满足了工业安全标准的额外需求，包括分区、隔离和运行时安全分析。该架构旨在缩小理论与实际应用之间的差距。

• 实验结果： 实验表明，Z-MCS的软件实现存在一些缺点，例如：

  • 可调度性下降：由于系统在运行时需要额外的计算来执行安全分析和管理任务的保留与终止，这会影响系统的可调度性。
  • 运行时开销：Z-MCS的运行时安全分析和任务管理引入了额外的开销。
  • 性能和可预测性降低：由于系统监控器和虚拟化技术带来的额外开销，Z-MCS的软件实现在性能和实时性方面有所下降。

  然而，文章指出，这些问题可以通过基于硬件的解决方案得到缓解。例如，使用硬件辅助的虚拟化或专门的硬件组件可以减少系统监控和任务管理的开销，从而提高系统的可调度性和性能。

• 鼓励学术界和工业界的紧密合作： 本文的主要目的是促进学术界和工业界在MCS领域的紧密合作。通过结合理论模型和实际工业需求，Z-MCS架构提供了一个潜在的解决方案，既能保持学术界的研究优势，又能满足工业应用的严格要求。