Vehicle OS：为软件定义时代下的敏捷开发而生

盖世汽车荟荟

“实现软件定义汽车需要从哪几个方面同时考虑？”

2023年3月14-16日，2023第四届软件定义汽车论坛暨AUTOSAR中国日上，维克多汽车技术（上海）有限公司商业开发经理张骏表示，首先是集中式电子电气架构，包括HPC节点和方位域控制器的引入；为了满足愈发复杂的ECU功能需求，就需要进一步引入高性能的硬件、微处理器等硬件；在此基础上还需要强大的软件开发平台Vehicle OS为整车软件开发提供支撑。“OEM会在这一过程中占据主导地位，由OEM打造属于自己的车载生态环境，让不同的供应商基于统一的平台进行应用层的开发工作。”

张骏介绍：Vehicle OS由Base Layer软件和SW Factory组成，是针对整车HPC节点、车端、后台应用提供的统一、可操作性高、易于合作的软件平台，代表汽车软件的整体生态系统的发展方向。

张骏 | 维克多汽车技术（上海）有限公司商业开发经理

智能汽车新四化的趋势之下，整车架构的变化

正式讲Vehicle OS之前，首先谈一下智能汽车新四化的趋势之下，汽车电子电气架构的变革历程。

在以前，整车架构包括ECU的开发更多会从功能角度入手，工程师会根据具体需要实现的功能，将ECU开发好并安装到车上，如果新增一个功能，就需要考虑新增ECU。比如说需要实现ESP的功能，就需要在车上部署一个ESP ECU。随着智能汽车的发展，车辆的功能变得越来越复杂，如果仍然采用原来的开发方式，就会导致车内ECU的数量过多、车内的线束设计过于复杂等问题。

为了避免这样的问题，现在的E/E架构正在朝着区域化、集中式的方向发展和变革。此类E/E架构之下，车内的节点大致分三类：

图片来源：嘉宾演讲材料

第一类，如图所示，车辆中央的3个HPC节点。当然，这个数量是不固定的，实际可以有2个、3个甚至多个节点，HPC节点也被称之为车辆大脑。大家现在会在HPC节点上同时部署微控制器和微处理器，也就是MCU和SOC，以便确保硬件架构可以满足车辆复杂的功能要求，这样在硬件上具备非常高的算力。比如，现在芯片厂商推出SoC的芯片，可以支持几百甚至上千tops的算力。

图片来源：嘉宾演讲材料

从软件架构而言，HPC节点在开发中需要同时遵循AUTOSAR AP和CP规范。此外，大部分企业也会在HPC节点之上进行一些其他功能的拓展，比如部署OTA，这也使得HPC节点可以被作为车辆此后更新功能的主要载体和接口。

第二类节点是Zonal ECUs，也就是域控制器，大家更习惯将其称之为方位域控制器，方位域控制器被作为HPC节点和该方位域下游节点的转换接口，负责将HPC节点发出来的面向服务的通信指令转化成下游节点能够解析的基于信号的通信指令。同时方位域控制器一般来说在软件架构上遵循AUTOSAR CP规范做开发。

第三类节点，也就是最外围的节点主要是负责传统汽车功能的ECU，这些ECU具有高度复用性的特征，仍然采用传统的解决方案或者遵循AUTOSAR CP做后期开发。

传统架构下，整车内所有ECU的软硬件开发复杂程度基本呈均匀分布的态势。在新的EE架构之下，不同节点的软硬件复杂程度有明显的分层：比如支撑最复杂功能和车辆主要计算性能的HPC ECU，复杂度最高；方位域控制器呈中等复杂度，负责转换工作；复杂度最低、复用性最强的是传感器、执行器或者机械节点的ECU，可定制化的程度也会相对低一些。

这种E/E架构可以带来哪些好处？首先是成本的降低，这主要来自于ECU的功能整合，节省了车内节点，也降低了线束复杂度；第二，可持续性和环保性增强，在轻便化的线束设计之下，整车的重量呈现下降趋势，排放出来的二氧化碳也会减少；第三，新的E/E架构是整个行业进入软件定义汽车阶段所不可或缺的条件，这种架构才可以实现硬件和软件的解耦，并在车辆的生命周期之内实现功能的持续迭代，达到千车千面的最终愿景。

真正实现软件定义汽车的必要因素

但是，E/E架构只是软件定义的必要条件，而非充分条件，要真正实现软件定义汽车，还需要从以下几个方面同时考虑。

第一，建立E/E架构，引入HPC节点和方位域控制器；第二，引入高性能的硬件、微处理器，从而支撑车辆复杂功能的实现；第三，建立强大的软件开发平台Vehicle OS，作为整车软件开发的必要支撑。在这一过程中，OEM会占据主导地位。由OEM打造属于自己的车载生态环境。让不同的供应商基于统一的平台进行上层、应用层的开发。可以类比手机，由不同的APP供应商基于用户实际的软件需求不断开发，这也是Vehicle OS存在的关键原因。

Vehicle OS主要覆盖下图红色框图标记的部分，包括HPC节点、方位域控制器，还有个别复杂的传感器、执行器一类的ECU。

图片来源：嘉宾演讲材料

在我们看来，Vehicle OS不仅仅包括车内节点，也包括运营端和后台的应用，它是一个统一、易于合作的软件平台，由Base Layer软件和SW Factory两个关键部分组成。

Vehicle OS的组成部分和关键要素

Base Layer可以被理解为Vehicle OS在运行时的一个软件集合，这个集合可以针对不同ECU的具体实现方式和规范要求呈现不同的形态，如果是HPC节点，Base Layer就可以遵循AUTOSAR AP和CP的规范；如果是方位域控制器，就会遵循AUTOSAR CP的规范。另一个是SW Factory，也可以称为软件工厂，在车辆软件开发、集成、测试和部署的全流程中，软件工厂可以为每个环节提供稳定的、易于操作的工具链。

除了以上两点，Vehicle OS还有一个关键因素，那就是人，或者合作。基于Vehicle OS，OEM需要协调Tier 1等多方资源。

由于Vehicle OS是非常庞大的操作系统，它会覆盖整个车辆软件生命周期内的所有环节，基本上没有任何一家公司可以独立完成Vehicle OS的开发和维护工作，即使是VECTOR目前所接触到的最杰出OEM，也是需要协调各个供应商之间的资源，共同地开发与维护Vehicle OS的环境，因此合作是Vehicle OS实现的关键。

图片来源：嘉宾演讲材料

接下来重点看一下Base Layer和Software Factory具体包含的内容。

Base Layer和Software Factory的系统架构与功能

Base Layer可以针对不同ECU的具体实现方式和规范要求呈现不同的形态，也就是针对不同的硬件平台提供不同的内容。首先从软件架构上来看，Base Layer被分为三层，最底层是和硬件相关的驱动和OS，比如BSP、Linux OS等等；中间层主要是中间件，包括基于中间件实现的功能拓展，比如AUTOSAR AP和CP；最上层是应用层的开发。

在MCU硬件基础之上，Base Layer提供启动代码和Flash Bootloader刷写代码，负责ECU启动和软件更新等功能的实现，针对特殊的应用场景，比如通过硬件虚拟化不同的partition，不同分区独立进行开发，这时就可以应用Hypervisor；向上是OS、Classic AUTOSAR中间件；接着是系统功能层（System Functions），例如OTA、数据采集等功能的拓展，最上面是应用层。

左侧是HSM硬件加密部分，HSM具有独立的内核和独立的内存储存空间，可以通过硬件加速，带来整个加密算法性能的提升，密钥和敏感数据的存储也都可以在上面实现。HSM硬件之上，Base Layer也可以提供HSM updater，OS以及HSM固件本身。

最左侧是新一代的智能switch，它有自己独立的内核能够运行独立的firmware，和通过MCU控制来完成switch的配置初始化相比，这种架构的优势是，能够大幅度提高ECU的启动速度，同时通过把部分ETH功能例如时间同步功能转移到switch上实现，可以降低MCU的负载，因此Base Layer也包含在switch上运行的启动代码，Flash Bootloader, OS和firmware.

除此之外，如果涉及到不同核间的通信，例如AUTOSAR核和HSM核之间的服务调用，需要借助核间通信IPC来实现。

MCU的右侧模块是和SoC密切相关，也就是和HPC ECU开发相关的Base Layer架构呈现。

这一部分的架构同MCU的整体架构类似，Base Layer也是负责硬件基础之上启动代码、IPC、OS等等，其中和MCU侧是一些细微的细节差别：比如HPC一般都会部署Linux os。再看中间件部分，Base Layer一般会针对ADAS、IVI等不同的HPC节点部署不同的中间件形式，并在其上进行功能的拓展，比如车云诊断协同、UCM Master等。

图片来源：嘉宾演讲材料

第二个重要组成部分是SW Factory（软件工厂），对VECTOR而言，软件工厂和所运行的软件具有同样重要的地位。

如果没有这样一套完整的机制和流程，就很难确保在有限的时间内，将不同开发人员的代码进行整合，以便及时、有效、快速地完成持续集成、持续测试、持续开发的全部流程。软件工厂会把Base Layer和应用层代码都使用自动化脚本进行ECU集成。同步，在云端或者服务器端，也支持把应用程代码集成进来，充分利用云资源的灵活性，同步进行逻辑开发。之后将两者结果合并，更好的完成整车VOS的集成，以及最后VOS软件的更新和部署。而在这整个过程中，软件工厂的核心意义就在于自动化的完成集成、测试和部署工作。