计算机常常被用作一种衡量单位，代表一套从底层硬件到应用软件层的全栈式系统。实际上，在汽车仍处于E/E分布式架构时，就有说法称其携带了几百个小型计算机——ECU。
Elektrobit合作伙伴管理亚洲区负责人顾淳解释道，基于功能，ECU需要进行从下至上，从硬件、操作系统（OS）、中间件、到应用进行全栈式开发，OEM则需要为全套系统买单。
从这个视角去看，软硬件解耦实际上是节省成本的一条路径：通过AUTOSAR对于OS和中间件（MW）的标准化，全车装载的几百个ECU可以依据不同的功能分区，基于同一个基础进行开发，既减少了供应企业的重复作业和维护难度，也使得OEM也不再为重复部件买单，推而广之可以形成一定程度的经济效益。
顾淳认为，伴随解耦程度的加深，车载功能、软件操作平台、汽车平台之间互相独立的程度会朝手机看齐，而整车级操作系统平台将是这一过程的重要助推力。
图片来源：Elektrobit 官网
操作系统：软硬件桥梁&计算机管家
操作系统就是硬件之上的第一层软件，提供硬件和其他软件沟通的接口，它诞生于裸机编程难以满足系统需求，后期维护和升级成本激增的背景下，被用以控制其他程序运行、管理配置内存、决定系统资源供需的优先次序、以及一些基本的服务程序，可以类比为计算机这个大宅院里兢兢业业的管家。
传统汽车行业中，ECU电子开发所使用的OSEK OS（汽车电子开放系统及接口），是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统，AUTOSAR基于OSEK OS提出CP AUTOSAR OS，支持多核处理，对ECU所使用OS进行相对统一的规范。
应用于ECU的汽车底层操作系统主要分为三类：基于QNX、Linux、Android三大OS内核搭建。根据ECU的主要功能分区不同，又分为车控操作系统和车载操作系统，其中车载操作系统主要包括信息娱乐和智能座舱，车控操作系统又分为安全车控（动力、底盘等）和自动驾驶车控。
从开发上区分，汽车操作系统包含GPOS（通用操作系统）和RTOS（实时操作系统），前者能够实现联机的多用户交互，后者必须确保在可预测的时间限制内，对外界的事件或者数据进行响应。
具体而言，GPOS一般采用时间片轮转法，通过时钟中断或者软中断的方式打断当前执行任务，抢夺CPU控制器，来进行任务调度并切换至新任务开始执行，一般用于娱乐系统的人机交互。
RTOS需要对任务处理做出快速响应，并控制所有实时任务协调一致运行，一般用于安全、车控等领域，常见的有QNX、VxWorks等。
总的来说，针对车载操作系统中信息娱乐和智能座舱的部分，由于功能安全和信息安全要求不高，多基于Android/Linux进行开发，使用GPOS通用操作系统。针对有较高安全性和实时性要求的自动驾驶控制器，一般基于 Linux/QNX/VxWorks 进行开发，使用RTOS实时操作系统。
图片来源：Elektrobit 官网
整车级OS为汽车“瘦身”
基于内核的开发程度不同，目前的汽车操作系统又分为ROM汽车操作系统和定制性操作系统。
ROM汽车操作系统基于Linux或Android进行有限开发，不涉及系统内核的修改，难度较低，比如宝马iDrive，小鹏Xmart OS，蔚来NIO OS等等。定制性操作系统在内核基础上进行深度开发，覆盖内核到应用程序层面，研发成本高、难度大，比如特斯拉Version，华为鸿蒙OS、AliOS。
随汽车软件生态的发展，汽车操作系统随座舱操作系统、智驾操作系统逐步演进至整车操作系统，从操作系统层面推进汽车从分布式智能向整车智能迈进。
基于内核所做的改动和开发程度越深，也就意味着操作系统的定制化程度越高，从而有助于在用户端体验车型特色，真正实现软件定义汽车。
就开发端而言，整车级别的操作系统有助于将复杂的ECU车辆网络抽象简化为单个设备，对车辆的生命周期进行管理、监督和更新的同时，也可以实现一定规模的经济效益：
分布式E/E架构不仅带来了巨量线束和传输的问题，还提高了OEM和供应企业的成本，AUTOSAR统一规范前，零部件企业如果要开发一个控制车窗的ECU，需要从应用、中间件、操作系统到硬件进行全栈研发，车企则要对整套服务买单。
从分布式E/E架构进入功能集中区域化结构后，同一功能分区的ECU可以基于共用基础构建，AUTOSAR进一步将不同ECU所共用的中间件和操作系统的标准进行统一，由此节省了开发和购买重复组件的成本，实现了一定程度的经济效益。
图片来源：Elektrobit
以此类推，顾淳提出，如果基于统一的车辆系统抽象分别构建车辆平台，把车的功能开发与整个车辆的生命周期进行分离，将公用部分从功能域范围内扩大至整车的大部分系统、甚至于整车进行使用，将实现更大规模的经济效益。
顾淳解释，所谓“抽象”，是软硬解耦的进一步演化，将汽车分为可扩展硬件平台、核心软件（操作系统部分）、中间件和边缘计算层（Adaptive & Classic AUTOSAR, DDS, Android）、平台服务、应用与功能服务层，从原本基于ECU的物理线式传输网络，转变为使用API进行应用程序之间的通信，不依赖功能域、底层硬件、以及功能执行所在的ECU。
图片来源：Elektrobit
为何要功能、软件、车辆平台两两解耦
整车功能开发与车辆的生命周期实现解耦后，顾淳设想，下一阶段汽车行业将步入功能开发与软件平台生命周期的解耦，进而实现软件平台周期和车辆平台周期的解耦，最终愿景是功能软件平台和车辆平台可以分别独立维护。
图片来源：Elektrobit
这一进程同手机的应用生态类似。不同的是，汽车功能应用、软件平台、车辆平台的生命周期相差甚远，汽车功能需要维护和升级的周期更短，车辆平台和软件平台则受限于硬件，相对更长。
顾淳举例，预计从2023年~2029年，车辆平台的迭代周期是3年，软件平台的版本更新会同车辆平台一一对应并高度绑定。相对的，软件平台的维护周期为十年，车辆平台的维护周期以汽车寿命为限，一般在8~15年。
图片来源：Elektrobit
对比手机行业，以iPhone6s为例，即便设备停产（本机型平台停止迭代），手机的软件平台仍然在持续升级，从IOS12升级到了IOS15。可以看出，汽车行业目前缺陷明显：在旧的车辆平台上无法进行软件平台升级，在旧的软件平台上也不能实现新功能的兼容。
顾淳表示，软件平台和车型平台的生命周期解耦，不仅丰富了用户的使用体验，一定程度上也延长了在同一平台车型上的使用时间，这是汽车软件生态向手机行业看齐的意义。
要实现功能层面、软件平台、车辆平台的解耦，第一步是整车级OS的构建和可持续运行。顾淳认为要从运行和维护两个角度切入：从运行看，“标准化”是关键词，需要统一车辆接口，统一系统概念和整车功能，减少车内软件的变量。从可持续运行看，“维护”是关键词，分离软件生命周期和车辆生命周期，变量和版本管理支持通过可持续的维护来构建生态系统。
总体而言，构建和运行汽车操作系统需要三条方法论：Automotive OS这一软件平台能将复杂的ECU车辆网络抽象简化为单个设备，目的是分离软件功能与车辆的生命周期，维护是其生存的关键：变量和版本管理支持通过可持续的维护来构建生态系统。
（以上内容根据Elektrobit合作伙伴管理亚洲区负责人顾淳于2022年8月3日由盖世汽车、AUTOSAR组织联合主办的2022第三届软件定义汽车论坛暨AUTOSAR中国日发表的《汽车操作系统-未来汽车的创新驱动力》主题演讲进行理解和整理。）
