软件定义的汽车

与20年前的数据中心类似，传统汽车是经典的“硬件隔离软件”架构。每一辆量产车有50+软件供应商，要让这么多软件模块安全可靠地在同一辆车上运行，传统的方法是让每一个供应商把软件封装在自己的计算机硬件里面。这些供应商封装提供的计算机叫作ECU。每个ECU里面有一套完整的芯片、存储、操作系统与应用软件，ECU之间只通过简单的实时网络传输信息，从而达成隔离不同供应商软件的目的。今天每一辆汽车有100~150个ECU，其软件的复杂性已经很难管理。

因而，以Tesla为代表的“造车新势力”开始采用以软件为中心的架构，新一代智能汽车也不再有100+ECU，而是拥有一台到几台通用计算机。供应商的软件作为模块运行在这些计算机上，隔离不同供应商模块的不再是硬件与网络，而是软件容器，这就是“软件定义的汽车”。而以软件为中心的新架构对下一代汽车的基础软件，包括其核心操作系统，提出了新的要求。

软件生态与容器

放眼智能汽车的生态圈，今天的座舱与ADAS两个域计算机都是以整体解决方案的方式售卖给整车厂。对于整车厂来说，这两个重要域计算机是黑盒。域计算机的供应商，而不是整车厂，正在掌控着这两个域的相关软硬件生态。例如，ADAS激光雷达的选型、座舱语音识别的算法选择都是由域计算机供应商决定的。这与今天的汽车生态格格不入，也不是整车厂能够长期接受的方案。而未来，如果软件定义的汽车发展到每辆车只有一台超级计算机，对这台计算机的操作系统与软件生态的控制权，更是整车厂不能放弃的。

这里的挑战是，整车厂或者域供应商，如何在一个开放的计算平台上安全高效地集成多个下游供应商与开发者写的软件？其实，这个问题在“软件定义的数据中心”已经有了很好的解决方向：使用软件容器隔离各个供应商写的模块。

云原生数据中心用Docker这类软件容器实现隔离。汽车厂商也一直在试图使用Docker这样的软件容器。

丰田汽车以及多个整车厂都已经试验过在车上的Linux系统上运行Docker。

实时操作系统VxWorks在2019年正式推出了Docker与Kubernetes（以下简称K8s）的支持。

QNX也在多个技术会议上表达了支持Docker的意愿。但是，在云原生数据中心大量使用的Docker与K8s并不能从根本上满足汽车上软件容器的需求。它们太慢，太重，也不能满足实时性的需求。市场上急需一个更好的解决方案。

新一代的轻量级软件沙盒/容器技术，如支持多种编程语言与多种操作系统/硬件的WebAssembly Runtime，是在汽车这种边缘设备上实现软件隔离的很好选择。WebAssembly直接从操作系统的线程启动，并不需要模拟一个自己的操作系统环境，在启动时间上可以比Docker这类解决方案快100倍以上。

基于WebAssembly的软件容器也需要自己的管理与编排工具。这里主要有两个思路。

利用K8s在云原生成熟的生态，将K8s改造为能编排边缘设备上WebAssembly容器的工具。轻量级的K8s工具，如KubeEdge、SuperEdge与OpenYurt，已经在边缘设备上应用。

用数据流处理框架，在传感器的数据流之中实时启动容器与第三方应用。目前基于ROS的自动驾驶解决方案，如ERDOS与Autoware，都可以走这个方案。工业应用的实时流处理框架，如YoMo，也可以用来调度WebAssembly容器。云原生计算基金会（CNCF）的正式托管项目WasmEdge也已经实现了与YoMo和ERDOS 的适配。

WebAssembly Runtime抽象了底层的硬件与操作系统，开发者就能用现代的编程语言与框架，如Rust，写出高性能、可移植的汽车应用。