首页 > 用车安全 > 深研OS赋能车机生态 推动软件、功能、车辆相互独立运行

计算机常常被用作一种衡量单位,代表一套从底层硬件到应用软件层的全栈式系统。实际上,在汽车仍处于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中国日发表的《汽车操作系统-未来汽车的创新驱动力》主题演讲进行理解和整理。)

猜你喜欢