计算机常用作计量单位，代表从底层硬件到应用软件层的全栈系统。其实汽车还在E/E分布式架构的时候，据说就搭载了上百台小电脑——ECU。
伊莱比特合伙人管理亚洲区负责人顾春解释说，基于功能，ECU需要自下而上的开发，从硬件、操作系统、中间件到应用，OEM需要为整套系统买单。
从这个角度来说，软硬件的解耦其实也是一种节约成本的方式:通过AUTOSAR对OS和中间件的标准化，将整车装载的数百个ECU按照不同的功能分区，在同一基础上进行开发，既降低了供应商重复运维的难度，也使得主机厂不再为重复的零部件买单，可以形成一定程度的经济效益。
顾春认为，随着脱钩的深入，车载功能、软件操作平台、汽车平台之间的独立程度将向手机看齐，而车载级操作系统平台将是这一过程中的重要助推力。
操作系统:软件和硬件桥接放大器；电脑管家
操作系统是硬件之上的第一层软件，它提供了硬件和其他软件之间的接口。它诞生于裸机编程难以满足系统需求，后期维护升级成本飙升的背景下。它用于控制其他程序的运行，管理内存的分配，决定系统资源供求的优先级，以及一些基本的服务程序。可以比作电脑大房子里的专属管家。
在传统汽车行业中，ECU电子开发采用的OSEK OS是一种实时单核操作系统，旨在满足汽车电子可靠性、实时性和成本敏感性的要求。AUTOSAR在OSEK OS的基础上提出了CP AUTOSAR OS，支持多核处理，对ECU使用的OS做出了相对统一的规范。
适用于ECU的汽车操作系统有三种:基于QNX、Linux和Android。根据ECU的主要功能划分，可分为车辆控制操作系统和车辆操作系统，其中车辆操作系统主要包括信息娱乐和智能驾驶舱，车辆控制操作系统可分为安全车辆控制和自动驾驶车辆控制。
从发展的角度来看，汽车操作系统包括GPOS和RTOS(实时操作系统)。前者可以实现在线多用户交互，后者必须保证能够在可预测的时限内响应外部事件或数据。
具体来说，GPOS一般采用时间片轮换法，通过时钟中断或软中断的方式中断当前执行任务，抢占CPU控制器，调度任务并切换到新任务开始执行，一般用于娱乐系统的人机交互。
RTOS需要快速响应任务处理，并控制所有实时任务协调运行。一般用于安防、车辆控制等领域，如QNX和VxWorks。
一般来说，对于车载操作系统中的信息娱乐和智能驾驶舱部分，由于功能安全和信息安全要求不高，所以多基于Android/Linux开发，使用通用操作系统GPOS。针对安全性和实时性要求高的自动驾驶控制器，一般基于Linux/QNX/VxWorks开发，使用RTOS实时操作系统。
整车OS为汽车“瘦身”。
基于内核开发程度的不同，目前的汽车操作系统可以分为ROM汽车操作系统和定制操作系统。
汽车的ROM操作系统是基于Linux或Android有限开发的，不涉及系统内核的修改，所以难度较小，如宝马iDrive、小鹏Xmart OS、蔚来NIO OS等。定制化操作系统是在内核基础上深度开发，覆盖内核到应用层面，开发成本高，难度大，如Tesla版、华为鸿蒙系统OS、AliOS等。
随着汽车软件生态的发展，汽车操作系统与驾驶舱操作系统、智能驾驶操作系统一起逐渐向整车操作系统演进，汽车从操作系统层面由分布式智能提升到整车智能。
基于内核的改动和开发层次越深，操作系统的定制化程度越高，有助于用户体验车辆特性，真正实现软件定义车辆。
就开发方而言，整车级操作系统有助于将复杂的ECU整车网络抽象简化为单一设备，对车辆的生命周期进行管理、监督和更新，同时也能实现一定规模的经济效益:
分布式E/E架构不仅带来了海量的线束和传输问题，也增加了OEM和供应企业的成本。在AUTOSAR统一规范之前，零部件企业要想开发一个控制windows的ECU，需要进行从应用、中间件、操作系统到硬件的全栈RD，车企要为整套服务买单。
分布式E/E架构进入功能集中的区域结构后，相同功能分区的ECU可以建立在共同的基础上。AUTOSAR进一步统一了不同ECU共享的中间件和操作系统的标准，从而节省了开发和购买重复组件的成本，取得了一定程度的经济效益。
以此类推，顾春提出，如果基于统一的车辆系统抽象来构建车辆平台，将车辆的功能开发从整车生命周期中分离出来，将通用部件从功能域扩展到整车的大部分系统，甚至整车使用，将会获得更大的经济效益。
顾春解释说，所谓“抽象”是软硬件解耦的进一步演化，将汽车分为可扩展的硬件平台、核心软件、中间件和边缘计算层(Adaptive amp经典的AUTOSAR、DDS、Android)，平台服务、应用和功能服务层，从原来的基于ECU的物理线传输网络，变成了应用程序之间使用API进行通信，独立于功能域、底层硬件和执行功能的ECU。
为什么功能、软件、车辆平台要解耦？
在整车功能开发与车辆生命周期脱钩之后，顾春设想，下一阶段，汽车行业将步入功能开发与软件平台生命周期脱钩，进而实现软件平台周期与车辆平台周期的脱钩。最终的愿景是功能软件平台和车辆平台可以独立维护。
这个过程类似于手机的应用生态。不同的是，汽车功能应用、软件平台、车辆平台的生命周期相差甚远。汽车功能维护升级的周期较短，而车载平台和软件平台受硬件限制，相对较长。
顾春举例，预计2023-2029年，车辆平台迭代周期为3年，软件平台的版本更新将与车辆平台一对一，高度绑定。相反，软件平台的维护周期为十年，车辆平台的维护周期以车辆寿命为限，一般为8~15年。
对比手机行业，以iPhone6s为例。即使设备停产，手机的软件平台也在继续升级，从IOS12升级到IOS15。由此可见，目前汽车行业存在明显缺陷:无法在旧的车辆平台上升级软件平台，无法在旧的软件平台上实现新功能的兼容。
顾春表示，软件平台与车辆平台生命周期的解耦，不仅丰富了用户体验，也在一定程度上延长了车辆在同一平台上的使用时间。这就是汽车软件生态系统与手机行业接轨的意义。
要实现功能级、软件平台和车辆平台的解耦，第一步是车辆级OS的建设和可持续运行。顾春认为，应该从运维两个角度切入:从运营的角度来说，“标准化”是关键词，要统一车辆接口、系统概念、车辆功能，减少车载软件的变量。从可持续运营的角度来看，“维护”是关键词，它将软件生命周期和车辆生命周期分开。变量和版本管理通过可持续维护支持生态系统的构建。
一般来说，构建和运行汽车操作系统需要三种方法论:Automotive OS这种软件平台可以将复杂的ECU车载网络抽象简化为单一设备，目的是将软件功能从车辆生命周期中分离出来，维护是其生存的关键:变量和版本管理通过可持续的维护来支持生态系统的构建。
郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。
