软件定义的汽车

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

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

　　智能汽车操作系统之争

　　目前，智能汽车正在从ECU向“软件定义”过渡，车企不能一步到位，走到每辆车只有一台超级计算机的架构，只能过渡到每辆车3~4个“域计算机”（也称“域控制器”），其中有两个很重要的域：ADAS域与座舱域。

　　ADAS域计算机管理着汽车自动驾驶的传感器、AI推理、决策与控制。

　　座舱域计算机管理着汽车座舱的控制与用户交互体验。

　　这两个域的操作系统并不相同。在座舱域中，车企一般使用的是Android系统，或者是剪裁版的Linux，以保证大量应用程序的兼容性。座舱里的Linux与Android系统使用开源的底层操作系统，有巨大的开发者社区。其上层的应用App可以是开源或闭源的。

　　在ADAS域中，车企一般使用商业的实时操作系统，如QNX与VxWorks等。ADAS的底层操作系统一般不开源，而应用虽然有开源的，如Autoware与百度的Apollo，但是绝大部分算法、传感器集成以及推理应用都是不开源的。

　　当然，这两个域的操作系统也有重叠的地方。例如，座舱域中显示驾驶数据的屏幕（车速、自动驾驶信息）一般是用QNX，以保证实时的数据读写。在座舱内，对Android、Linux与QNX的需求还产生了专门的Hypervisor虚拟化解决方案，如OpenSynergy，能让几个操作系统用虚拟化的方式运行在同一个硬件计算机上。

　　因而，未来“软件定义的汽车”有很大几率会从几个域进一步进化为一个超级计算机。这个计算机需要一整套操作系统与中间件服务，去为座舱、自动驾驶等各种车内应用服务。想要实现这个操作系统，主要有以下两条路径。

　　以目前座舱使用的Linux为基础改造。一方面是把Linux继续剪裁；另一方面是在Linux上增加对实时任务的支持。尽管Linux本身不是一个实时操作系统，也不是为嵌入式设备设计的，这条路径有相当大的难度，但Linux已经有了庞大的开发者社区与应用生态。这里比较有代表性的是Linux基金会旗下的Automotive Grade Linux （AGL）。AGL有近百个成员公司，包含了世界上主要的主机厂商与一级供应商。

　　开发崭新的下一代实时操作系统。一个有力的竞争者是Linux基金会旗下的seL4。seL4是一个基于微内核的实时操作系统，它的一个主要特点是经过形式化验证，能保证内核的安全稳定性。但seL4目前只有内核，中间件与应用生态建设仍然有很长的路。好消息是汽车行业的地平线、蔚来汽车、理想汽车、Second State最近都加入了seL4基金会，共建生态。

　　我们注意到，未来汽车操作系统的明显趋势是开源的。这意味着开发者试验与进入汽车生态的门槛会越来越低。

　　在智能汽车火热的中国市场中，有技术实力的汽车软件公司也都在向自研操作系统努力。它们都是从基于Linux的座舱系统（如前述的AGL）往实时车控操作系统演进。其中比较有代表性的是以下几家。

　　阿里与上汽合资的斑马智行于2021年7月获得30亿元的增资，主要用于基于开源的AliOS的汽车操作系统开发。

　　华为于2021年发布了开源微内核的鸿蒙操作系统，业界普遍认为是可以用在未来汽车上的。

　　镁佳在2021年5月融资一亿美元，用于汽车操作系统与应用商店的研发。

　　中科创达是国内领先的汽车软件应用开发商，其高层在最近的访谈中反复强调了公司要做操作系统的决心。

　　加之前面提到的seL4基金会成员地平线、蔚来、理想、Second State，中国厂商目前在汽车操作系统的两个主要方向都有布局，正走在世界智能汽车操作系统领域的前列。

　　软件生态与容器

　　放眼智能汽车的生态圈，今天的座舱与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，写出高性能、可移植的汽车应用。

　　开发者的机会

　　软件定义的数据中心产生了“云原生”的使用场景，赋能了大量开发者。软件定义的汽车也会让第三方开发者更容易进入汽车。对于广大开发者来说，软件定义的汽车的意义在于把汽车变成一个开放的计算平台。标准化的硬件、开源的操作系统、开源的容器与运行沙盒，都会大大降低开发者参与汽车应用开发的门槛。

　　未来整车厂的核心能力将不再是引擎与变速箱，也不再是整合几个一级供应商的部件，而是像今天的公有云或者手机厂一样，整合软件开发者的生态，为用户提供最好的软件体验。

　　新程序员们，软件定义的汽车时代已经来临了，你们准备好了吗？