SOAFEE架构介绍

一、简介

1.1. 软件定义车辆

移动性经历了向互联、自主、共享和电动（CASE）方向的重大数字化转型。这种转变主要基于软件技术，而软件定义车辆的特点是在整个生命周期中很大程度上由软件管理其功能和操作。

1.2. 计算集中化

由于技术和商业原因，以软件为中心，车辆的电子架构朝着计算更加集中的方向转变。汽车计算整合的趋势可以带来一些改进，例如降低布线复杂性和重量等。这些改进可以优化供应链和制造，并有望使产品开发变得更容易、更便宜。

1.3. 新商业模式

向软件定义车辆的转变使 OEM 能够随着时间的推移增强车辆的功能，因为新功能以可以通过无线方式交付的软件来表达。这将允许增强的商业模式，最终用户可以在车辆离开经销商后购买额外的功能。

1.4. 硬件和软件分离

随着车辆功能在车辆的整个生命周期中不断更新或增强，将相同的软件组件部署到不同的车辆计算机变体中变得至关重要，从而实现硬件和软件的分离。

1.5. 虚拟开发和验证

为了缩短新软件功能的上市时间，并允许软件验证随着车辆数量和硬件变体的数量而扩展，虚拟开发和虚拟验证的使用变得至关重要。快速、频繁的软件部署随着车辆与数字消费生态系统的连接，对快速、频繁的软件部署的需求主要是由网络安全要求驱动的，而网络安全要求目前变得越来越重要。除了技术和商业方面之外，法律标准也发生了重大变化。此外，硬件和软件的生命周期将被解耦，最新版本的软件可能会安装在已经运行数年的车辆上。

1.6. 影响

行业迁移到软件定义车辆模型有很多好处，但这种迁移也存在差异化和非差异化挑战。第一个问题是，传统上车辆被视为嵌入式平台，其中软件在很大程度上依赖于硬件。这意味着如果没有潜在的大量前期工程成本，一个系统的软件可能无法轻易转移到另一个系统。在软件定义的世界中，任何增加障碍（例如依赖项增加总体开发成本）的事物都会降低在竞争市场中的吸引力。第二个问题是随着集中计算模块的复杂性增加而出现的。这些可能包括用于应用程序、实时和基于微控制器的工作负载的异构计算岛，

实时配置文件，包括其组合。这些 SoC 的工作负载配置和部署有可能变得非常特定于系统，从而再次降低工作负载从一个系统轻松迁移到另一个系统的能力。这两个主要的复杂性角度是潜在的障碍，将挑战行业向软件定义车辆迁移的速度。加快汽车领域向软件定义汽车迁移的步伐将依赖于行业就开放标准和方法达成一致，以帮助管理和缓解这些挑战。SOAFEE 特别兴趣小组 (SIG) 正在通过标准化的系统架构规范来应对这些挑战。随着开放标准和最著名方法论的发展，该规范将随着时间的推移而成熟和发展。

2.架构概述

随着更多的最终产品以软件形式表达，汽车软件变得越来越复杂。这种复杂性体现在很多层面上。汽车原始设备制造商表示，开发板支持包和新片上系统 (SoC)/平台集成的成本是不必要的，而且在很大程度上是非增值费用。SOAFEE 打算通过采用云原生和边缘计算标准来改变这一现状，使汽车 OEM 能够专注于其核心竞争力并提高软件的可重用性。SOAFEE 将采用并增强当今云原生世界中使用的当前标准，以帮助管理汽车软件定义的车辆架构的软件和硬件复杂性。

2.1. SOAFEE 架构概述

SOAFEE 的主要目标是定义一个支持车辆应用程序和功能的云原生开发和车辆边缘平台部署的框架。该框架允许集成不同的中间件和应用程序软件堆栈，并重点关注在汽车用例中构建面向服务的架构的基本元素。此外，SOAFEE架构将支持所有工作负载的云原生开发，包括具有功能安全性、安全性、时间分区、空间分区和实时要求的工作负载。这些是下一代车载嵌入式边缘平台的重要特征。

2.2. SOAFEE 架构指导原则

现实世界中的可部署汽车用例推动 SOAFEE 的系统架构要求至关重要。SOAFEE 系统架构工作组 (WG) 建立了一个工作流程，汽车用例通过该工作流程驱动 SOAFEE 架构规划流程的架构分析、细化和需求分配。从长远来看，SOAFEE 系统架构工作组的目标是分析和分解所有提议的用例，以确保 SOAFEE 系统架构能够满足以下领域的用例需求：

2.2.1. 安全

完全期望 SOAFEE 架构将支持执行安全关键（微）服务以及非安全关键服务的用例。因此，执行平台需要可靠且安全，以确保此类电气/电子（E/E）系统的功能安全。ISO 26262 安全标准在汽车领域的应用有助于确保安全关键平台元件的正确运行，并将残余误差保持在可接受的低水平。由于开发符合安全标准的整个平台是不切实际的，因此策略是根据 ISO 26262 仅开发（或鉴定）安全关键元件，并相应地将它们与非安全关键元件隔离，以确保空间、时间和通信免于干扰 (FFI)。

2.2.2. 安全

所有用例的安全分析必须是一种常见的做法。所有实施均应通过安全检查并遵循一组最佳实践，包括：

• 威胁模型：平台和应用程序。将创建该平台的威胁模型。所有应用程序分解都应与最低限度的威胁模型相关联。

• 设计原则：基础设施（容器运行时、编排器等）和应用程序遵循的最小权限原则。

• 支持常见的安全服务，例如但不限于加密、证明等。

• 应用程序使用强大的安全 API。SOAFEE 应该包括一个标准化的 API。不定义自己的标准，而是使用可用的标准。

• 与架构无关的部署。应用程序应该能够使用来自平台的安全服务，而不管它们的支持方式（SW、HSM、TEE 等）。

• 安全服务的可发现性及其稳健性。例如，仅当底层硬件从 HSM 提供加密服务时，才可以部署应用程序。

• 应用程序身份验证：我们如何验证已部署的容器是否可信？我们如何验证容器在启动时没有在存储中被修改？

• 编码指南和静态分析。建议 SOAFEE 平台遵循 CERT 编码指南（如果适用）并运行静态分析以避免漏洞。

• 安全验证：基本的最小测试集，涵盖权限检查、模糊测试。

2.2.3. 即时的

SOAFEE 的目标是需要对工作负载的执行有时间限制的用例。必须从分析和分解工作负载的角度出发，贯穿整个 SOAFEE 软件堆栈的设计，最后在考虑软件/硬件交互时考虑实时要求。

3.未来的挑战

云原生技术并非设计用于在车辆内运行。因此，大多数可用的云原生技术都缺少对车内运行至关重要的几个方面。汽车云原生面临多项挑战。

3.1. 云原生技术安全认证

大多数旨在将功能带入车辆内部的云原生技术并未经过安全认证。通常，所使用的编程语言本身并不适合确保内存安全或确定性等重要功能。因此，诸如运行时或协调器之类的关键组件可能需要审核或重写。

3.2. 兼容的安全认证系统软件

混合关键编排是指对具有不同安全要求的应用程序进行管理。特别是对于具有安全要求的功能，编排器下方的整个软件堆栈都需要经过认证。迄今为止，还没有经过汽车安全认证且支持容器的 Linux。另一方面，一些经过认证的操作系统不支持容器。

3.3. 启动

启动车辆时，会启动多个应用程序，并且可用性要求通常在几秒钟内。这意味着您需要有启动容器的优先顺序，并且容器运行时需要在此时间段内启动 10-100 个容器。这与每个容器的启动时间低于 10-50 毫秒有关（这对当前可用的运行时提出了挑战）。

3.4. 实时约束和决定论

对于汽车功能来说，通常必须在执行期间保持时序要求。信号链的处理（例如，从传感器到应用控制单元，再返回到执行器）需要保证重要的反应时间，以避免事故。为此云原生技术需要增强以支持：

确定性调度

信号的确定性处理/延迟保证

优先处理

3.5. 汽车网络

汽车网络具有时间敏感网络 (TSN)，可实现数据通信的确定性定时。目前云原生技术不支持 TSN。资源限制：车内的高性能计算机的环境受到限制。容器只允许消耗一定数量的资源（CPU、内存、IO 等）。这应该可以通过可用的操作系统机制很好地处理，但需要在开发过程中得到保证。

3.6. 动态功能和认证

编排器的一大好处是能够在运行时添加新应用程序。另一方面，汽车法规要求在部署之前对软件进行认证过程。为了充分发挥车辆编排的潜力，需要建立动态添加或更新应用程序的流程。

3.7. 工作负载部署

在发布和部署最终用户应用程序的新版本或（操作系统）系统级更新时，汽车应用程序具有不同的含义、限制和生命周期。可以应用现有的 DevOps 方法来增强此工作流程，并对汽车领域进行一些改进。

3.8. 工作负载分区和集群

为了启用混合安全系统，通常使用虚拟机管理程序或微内核将硬件资源划分为在汽车中运行多个操作系统的域。编排器能够通过添加代理节点来管理跨单独分区的应用程序。

3.9. 基于云的测试

现代 DevOps 流程在其测试和部署管道中内置了强大的测试基础设施。目前，来自云原生世界的基础设施缺乏测试和验证实时工作负载或针对实时或基于微控制器的架构的工作负载的能力。我们需要增强基于云的工具来满足安全和实时领域的验证需求。

应对未来的这些挑战和其他挑战需要行业合作与协作。

4.云端 DevOps，边缘部署

DevOps 方法已经为云工作流程建立了良好的基础。云开发工作流程和实践在汽车行业中存在巨大的重用机会。这不仅仅是关于如何在云中进行持续测试/构建或在边缘设备上自动部署，而且还意味着如何开发最终用户应用程序。在汽车领域采用 DevOps 模型意味着大多数嵌入式软件开发人员将不再需要使用主机开发系统以及目标/边缘测试平台来开发、构建和测试应用程序。虽然可以从基于云的环境继承大多数 DevOps 实践，但在边缘设备上部署系统和应用程序面临着一系列独特的挑战。下面列出了其中一些挑战：

• 应何时以及如何部署应用程序更新？

• 系统将如何处理正在运行的应用程序的更新？

• 如何确定应用程序是否有足够的资源来运行，请记住它不仅限于通常的计算资源，还包括汽车功能/组件。

• 我将如何在云中的模拟环境中以自动化方式测试应用程序。

支持云中应用程序开发的关键是需要一个基础操作系统，该操作系统不仅可以在云中运行以进行测试，而且还必须在边缘平台上运行以进行设备上测试。坚持使用 OCI 兼容容器等众所周知的云技术对于在云中开发/测试应用程序至关重要，从而允许将相同的便携式容器部署在边缘（例如车辆中）。为了帮助促进此工作流程并提供可重复的示例，SOAFEE SIG 引入了 SOAFEE 蓝图和 SOAFEE 集成实验室。

4.1. SOAFEE 蓝图

SOAFEE 蓝图是示例参考应用软件解决方案，由特定汽车软件定义的用例引导，用于验证 SOAFEE 架构概念并加速产品开发和原型设计。蓝图旨在演示云中的 DevOps 和边缘部署等概念，但是蓝图并不要求涵盖完整的端到端 DevOps 周期。这将允许 SOAFEE 成员验证应用程序级别用例并展示边缘部署。

4.2. SOAFEE集成实验室

SOAFEE 蓝图将是验证 SOAFEE 定义的软件定义模型的关键。蓝图将用于验证云中的云原生开发、集成和测试工作流程。一旦针对蓝图开发/成熟了云原生开发工作流程，下一步就是在边缘计算平台上进行测试/验证。这就是 SOAFEE 集成实验室将发挥重要作用的地方。该实验室将为工作负载的设备上测试提供受支持的边缘平台。这些实验室提供硬件来测试嵌入式边缘硬件上的“边缘部署”工作流程。集成实验室将支持测试和集成兼容的虚拟和物理硬件平台，以及边缘工作负载抽象和编排层 (EWAOL) 等 SOAFEE 兼容实现，SOAFEE 参考实现以及来自商业软件供应商的堆栈，以及符合本文档中概述的 SOAFEE 架构的 Open AD Kit 等工作负载。SOAFEE 蓝图和 SOAFEE 集成实验室的结合将为第三方创建一个快速启动工具，以便在 SOAFEE 兼容解决方案上快速轻松地构建功能解决方案。

5.架构

5.1. 概述

考虑到 SOAFEE 的关键因素和动机，很明显，在车辆中采用云原生的概念和解决方案将产生巨大的影响。基本尺寸是：

• 用于扩展和编排服务的功能和接口应该在车辆和云中以相同的方式工作，并遵循云原生技术。然而，这需要考虑汽车特定的安全需求和有限的资源占用。

• 开发/测试/部署工作流程，支持在部署到物理硬件之前在基于云的虚拟环境（模拟）中进行服务开发和测试。如果虚拟系统中的执行环境与物理嵌入式系统中的执行环境相似或等效（环境对等），我们可以将更多测试和验证场景转移到云端。

5.2. SOAFEE软件架构

在支持软件定义车辆的 SOAFEE 之旅的现阶段，SOAFEE 软件架构可以由下图中的元素表示。

此版本的 SOAFEE 架构所需的元素必须包括：

• 符合 OCI 的容器引擎和运行时：OCI 运行时规范。

• Kubernetes 兼容的容器工作负载编排：Kubernetes API。

• 在云中开发，在边缘部署（原生云开发）

• CI 支持的参考实现维护：meta-ewaol CI。

• 无需修改即可在具有基于标准的固件的平台上运行

SOAFEE 的参考实现、EWAOL是该版本架构的表达。EWAOL 的版本号反映了本文档的版本。

5.3. 未来的工作

为了继续在汽车领域采用云原生技术，需要详细说明以下主题：

• 可观察性和分析：环境平等的范例强调了 SOAFEE 的核心支柱之一，需要通过专门的观察​​和分析来证明。只有当我们能够证明结果具有可比性时，才能利用云中虚拟开发和验证的主要效率效应。

• 混合关键安全编排：汽车领域云原生的范式转变需要支持完整范围的混合关键性。将应用程序迁移到微服务需要大量投资。只有当收益证明合理时，这是可以接受的。因此，协调和简化安全、非安全、车辆和云环境中的编程模型至关重要。混合关键性问题包括考虑适当的工具，以允许在车辆的整个生命周期内灵活部署安全服务。

• 云原生试验：云原生在汽车领域的采用需要许多不同利益相关者的协作和贡献。它只能由 SOAFEE 驱动。为了指示清晰且逐步的迁移方法，需要描述清晰的轨迹（类似于云原生轨迹图）。

• 分区方案：有不同的选项来实现计算分区（容器、虚拟机管理程序、即将推出的技术，例如通过 eBPF）。需要明确的比较和指南来为专用用例选择最佳的解决方案。