【转载】软件定义汽车的云原生

 汽车行业致力于软件定义的未来 - 解决当前的挑战，并为新的收入来源、效率和与消费者更紧密的终身关系开辟机会。云原生被呈现为实现目标的设计范式，但这意味着什么？云原生真的能适应汽车及其乘客的现实吗？

我的同事罗伯特·戴（Robert Day）最近在他的文章《软件定义的车辆需要走得更远的硬件》中探讨了车辆设计、生产和维护方式转变的前景。随着时间的推移，汽车的潜力会变得更好;可以通过软件更新修复、升级和改进性能、安全性和舒适性;是壮观的。更重要的是，这种方法对于满足消费者期望、颠覆性市场进入者和外部压力（如电气化驱动）的现实是必要的。为了满足这些新兴需求，汽车软件的复杂性呈指数级增长，这推动了敏捷服务导向方法的使用。在为汽车开发安全相关软件时，还需要非常严谨。

我们在哪里可以找到这样的模板来全面转变行业如何设计和构建硬件和软件？幸运的是，对于有抱负的软件定义车辆架构师来说，云计算和移动领域已经发生了这样的旅程。“云原生”已成为这两个领域大规模敏捷创新的标语。但问题仍然是，如何将云原生实践应用于像汽车这样实际参与现实世界的东西，同时保持至关重要的安全性？

由于 Arm 是 OEM 的关键技术提供商，通过其支持 Automotive 的 IP 创建下一代软件定义汽车，因此 Arm 必须与其整个汽车价值链的生态系统合作，以确定在汽车中使用“云原生”设计范式的挑战，并帮助解决这一问题，同时将其技术跨云支持到汽车边缘基础设施。

在这篇博客中，我们谈到了汽车背景下“云原生”的几个方面及其对汽车系统架构的影响。

什么是“云原生”？

云原生计算基金会 （CNCF） 将云原生定义为：

“云原生技术使组织能够在现代动态环境（如公共云、私有云和混合云）中构建和运行可扩展的应用程序。容器、服务网格、微服务、不可变基础设施和声明性 API 就是这种方法的例证。

对于不从事业务的人来说，这是很多行话。但这个词汇支撑着一个具有巨大价值和规模的生态系统。这里发展起来的基础设施使在当地咖啡馆喝咖啡边编写改变世界的代码的梦想成为可能，并立即看到代码在全球范围内进行测试、打包和推送。

云原生设计模式

云原生理念的核心是面向服务的体系结构 （SOA）。在这里，应用程序作为独立的功能服务启用，可以在与位置无关的计算系统上部署和编排。这个概念可以扩展到所谓的“微服务”。一个流行的定义是“一种将软件设计为一套小服务的方法，在它自己的过程中与轻量级机制进行通信”（https://martinfowler.com/articles/microservices.html）。实际上，微服务可以被视为将每个功能拆分为最小的逻辑独立服务。

图 1 虚拟化/容器化工作负载部署

这些服务通常部署在容器中或作为轻量级虚拟机 （VM） 部署，具体取决于应用程序体系结构（图 1）。这允许在同一台计算机上运行多个服务，同时保持彼此隔离。开放标准在数据中心领域已经发展，允许此类服务自包含、可互操作、位置透明且与硬件无关。

SOA 有几个好处：

• 每个服务都可以独立部署，允许多个开发人员在整个应用程序上独立工作
• 简化与标准 CI/CD 基础架构的集成和自动部署，从而实现最先进的 DevOps。
• 更好的故障隔离
• 跨应用程序的可扩展性和可重用性
• 每个服务都可以使用所选语言进行开发

难题的一个关键部分是容器业务流程协调程序。这是一款软件，可自动执行容器管理、部署、跨整个系统的扩展和生命周期管理的过程。最受欢迎的容器编排器之一是 Kubernetes，现在是容器编排领域的事实标准。

汽车中的云原生

在了解了一些基本的云原生技术推动因素之后，下一步是在汽车环境中将其中一些放在一起。

                                                  

图 2 汽车堆栈中的云原生趋势。

截至今天，已经有基于SOA的汽车堆栈的真实例子。其中许多是闭门造车的原型，但是在Autoware中可以看到这种部署的一个很好的公共开源示例，这是一个由Autoware基金会维护的开源自治堆栈（Scalable Autoware.Auto through k8s - Autoware）。Arm 正在积极与 Autoware 基金会 （AWF） 合作，并将 Autoware 作为未来系统的参考汽车工作负载之一，以展示云原生 DevOps。应用于Autoware的一般云原生原则应扩展到汽车领域的其他细分市场，如数字驾驶舱。

这代表了汽车应用程序开发方式的重大转变，因为成熟的云原生生态系统可以开始用于汽车软件开发，这对敏捷性、生产力和上市时间具有潜在的巨大影响。

汽车计算具有云或移动计算所不具备的某些特殊要求。特别是，在某些（但不是所有）系统中需要实时控制和功能安全。这称为混合临界。最终目标是能够使用现有的云原生基础设施来开发和部署微服务，这些微服务完全了解汽车计算的混合关键性环境并正常运行。这就是目前存在差距的地方，需要开展工作来扩展现有的云原生基础架构，以支持DevOps和混合关键工作负载的部署。

软件定义对汽车计算架构的影响

上一节探讨了汽车环境中云原生的定义，以及一些在数据中心领域已经成熟并正在为软件定义车辆铺平道路的现有技术推动因素。然而，汽车数字化的范式转变不仅限于软件，对下一代汽车计算架构产生了重大影响，如图3所示。

                                                     

图 3 汽车 E/E 架构趋势

传统建筑：

如今，大多数量产车都有多个小型固定功能的电子控制单元（ECU），通常由许多不同的供应商设计。在这样的体系结构中，除了存在多个故障点之外，隐含的是功能升级方面没有太大的灵活性。

域体系结构：

由于强大的基于异构片上系统的计算的可用性，工作负载整合的概念正在进入汽车领域。多个ECU正在整合到域控制器中，这些域控制器处理汽车的特定域功能。目前看到的典型域控制器是车载信息娱乐系统（IVI）、数字驾驶舱、ADAS/AD和电源、底盘和车身。此体系结构可降低连接复杂性，同时提高计算凝聚力。

集中式架构：车轮上的数据中心

随着功能更强大的异构、专用 SoC 的出现，出现了进一步整合的趋势，其中高性能、嵌入式加固刀片服务器将取代域控制器，为区域架构铺平道路。在这里，传感器在低计算、低功耗和实时区域控制器端接，这些控制器将进行边缘预处理，然后将数据转发到高性能中央计算机进行繁重处理。

                                                                                                      

图 4 集中式计算群集 -“车轮上的数据中心”

图 4 显示了将安装在汽车中的概念高性能嵌入式计算 （HPEC）。可以看出，尽管该架构看起来像一个典型的数据中心服务器，但在能够运行异构安全和实时相关工作负载时，车载HPEC需要考虑其他限制 - 更不用说汽车内需要考虑的冲击/振动和热方面的物理限制。一些汽车原始设备制造商已经在沿着这条进化的道路前进，而那些探索更激进用例的原始设备制造商，如机器人出租车或自动送货车，已经在部署集中式计算架构。

当我们考虑上述向集中式计算架构和在此类架构中部署微服务的转变时，虽然许多现有的云计算编排设计原则适用并且可以利用，但由于需要维护部署服务的混合关键性以及将服务与正确的异构硬件相匹配，事情变得更加复杂，这比云或移动细分市场更加多样化。

结论

这只是汽车领域正在兴起的软件定义世界的开始。这种方法将从根本上影响未来汽车软件的开发、集成、测试和部署方式。此外，现代车辆的广泛数字化正在迅速发展车辆内部署的计算架构。云原生设计模式有望采用可扩展的方法来管理汽车计算中日益增加的复杂性，但围绕混合关键性和可扩展性存在非常具体的挑战需要解决。在以后的博客中，我们将深入探讨其中的一些挑战，以及 Arm 及其生态系统正在推动的举措。

文章转载出处：

软件定义汽车的云原生方法 - 嵌入式博客 - Arm 社区博客 - Arm 社区https://community.arm.com/arm-community-blogs/b/embedded-blog/posts/cloud-native-approach-to-the-software-defined-car