今年2月23日，梅赛德斯--奔驰发布了打造自有操作系统MB.OS的具体计划，该操作系统将在本年代中期随全新梅赛德斯-奔驰模块化架构（MMA）平台推出，预计2025年用户将能体验到它的强大功能。

据悉，基于覆盖芯片到云端的全新架构，MB.OS整车操作系统将全面打通车辆功能，包括信息娱乐功能、智能驾驶辅助及自动驾驶功能、车身与舒适功能、行驶与充电功能。

这并非是第一家要自研整车操作系统的车企。

早在2019年，大众汽车就宣布将在2025年前，为旗下所有新车搭载自研的汽车操作系统——VW.OS，为此还专门成立了Car.Software部门。

2022年有消息称，丰田汽车计划在2025年前推出自研汽车操作系统Arene，基于Arene操作系统的汽车软件平台可以处理从基本功能到自动驾驶等应用的所有内容。

可见，随着软件定义汽车趋势愈加明朗，这股车企自研OS的潮流，或进一步验证了车企们更愿意相信诸如此前上汽有关“灵魂论”的论调和观点。

一方面，在特斯拉OTA升级的带动下，车企的盈利模式从“一次售卖”转变为“硬件预埋＋软件付费解锁”，由此驱动汽车软件架构的迭代，即从面向信号的软件架构，过渡至面向服务的SOA架构，以实现汽车在使用寿命内常开常新。

另一方面，软件取代硬件定义汽车，业内普遍认为汽车的品牌差异化将由软件驱动，而汽车操作系统OS决定软件生态，广义OS包括从BSP、操作系统内核、中间件及库组件等硬件和上层应用之间的所有程序，不可否认是未来汽车产业链的灵魂。

汽车智能化新引擎

迈向2023年，汽车软件业务争夺战已经全面爆发。

诚然，汽车电子电气架构正由分布式往域集中式架构演进，为了实现软件定义汽车，智能汽车的软件架构正向着SOA升级。

毕竟，在传统分布式EE架构下，每个ECU通常只负责控制一个单一的控制单元，彼此独立并分别控制着发动机、刹车、车门等部件。汽车软件的运行主要基于面向信号的架构，各ECU之间通过CAN总线或者LIN总线连接在一起，通过厂商预先定义好的通信协议交换信息。

面向智能汽车的软件开发或升级需求，分布式电子电气架构显然不足以支撑。

其一是架构固定，缺乏灵活性。ECU各功能的编码在架构设计阶段被预先定义在ECU排序文件中，仅能依次调用、逐个运行，而且ECU 间信号收发大部分由网关转发，一般不支持请求和响应模式，灵活性较差。

另外，分布式架构下软件与硬件高度耦合，软件运行强烈依赖硬件，软件需要改动或升级，整车通讯系统和ECU都要随之改动，还要对整车进行集成验证，时间成本较高且难度大。

随着整车EE架构朝域集中式发展，几个域控制器承担了整车主要逻辑运算任务，通过域控制器就能实现对底层硬件的控制，在架构设计上为SOA提供良好基础。

所谓的SOA或者基于服务的中间件平台，即整车操作系统OS，是将车内各不同域的功能全部挂载到一套操作系统，或者是同一套编程接口之上，基于标准化接口快速响应新功能需求，软件工程师在修改或新增某一软件功能时，只需对上层相对应的服务组件进行代码编写，极大地减少了软件升级的复杂度和成本。

“举例来说，早期分布式电子电气架构下，要开发一个可以在路面上投送图标的智能互联车灯应用，需要协调矩阵大灯的供应商，协调自动驾驶、算法，包括摄像头、传感器的供应商，还要进行大量车内通信矩阵的设计，每个供应商都需要修改自己的ECU，包括预控制器内的软件、算法，需要大半年甚至一年时间。”

易特驰CTO郑心航向高工智能汽车表示，使用整车操作系统OS，类似智能互联车灯等新应用只需在操作系统之上，通过简单的调用编程接口API，预计2到3周可以开发完成，极大地提升了软件开发与升级效率。

不难发现，广义上的操作系统OS，本质上是介于上层应用和底层系统之间的一套软件框架，充当着软件和硬件解耦的关键角色，可按需调整、满足自动驾驶过程中的各种开发需求，为上层应用软件提供开发和运行所需的环境。

而随着智能技术的发展、汽车开发贴近消费端需求，软件开发需求走向加速度。

因此，整车操作系统OS对算法、子系统、功能采取模块化的管理，通过提供的统一接口，让开发人员能够专注于各自业务层面的开发，无需了解无关细节，进而提高整个系统的开发效率，软件部署得以简化。

最大化开拓软件生态圈

在整车OS的助力下，由软件实现车企的品牌差异化变得更加容易。

今年自有操作系统MB.OS具体计划发布会上，梅赛德斯-奔驰集团股份公司首席执行官康林松（Ola Källenius）亦表示，软件是奔驰未来最核心的竞争力。

换个角度来看，这波扬言要自研操作系统的车企，最大的愿望或是打造更彻底的软件及其生态差异化王牌，其核心可能不在于操作系统中有关软件开发的细节如何实现，而是复刻“硬件定义汽车”时代的话语主导权。

不过，车企自研OS的难度和挑战不容小觑。一方面，不少传统主机厂仍延续过往硬件主导的基因，难以打通软件思维；另一方面，叠加车企自研的研发成本、较高开发门槛等，随之收到的开发反馈将减少，由此或造成软件迭代速度慢，不利于其差异化竞争。

“仅仅有SOA平台还不够，相比供应商提供整车操作系统，车企内部自研OS的最大差异点在于，整车厂用的是内部自研的一整套封闭式的工具链，对汽车技术要求很高，存在较高的行业门槛，很难吸引到外部开发者。”郑心航介绍到。

可以说，吸引第三方开发者加入，构建汽车软件开发者生态圈，既是目前汽车软件开发的痛点，也是车企差异化竞争焦点。

要想做到这一点，首先应打破车企的传统站位。

在软件定义汽车趋势下，放眼整个软件生态，车企的创新能力应该体现在上层应用的差异化。但上层软件生态的建立，并非通过车企独家全栈自研，亦或是整车厂协调一、二级供应商，就能够建立起壁垒和护城河。

“面向软件定义汽车，车企应把有限的资源放在为客户提供更多价值的上层应用，而不是在用户看不见的底层应用；在底层应用，业内可以携手打造一个类似于AUTOSAR的开放共用的高效工具链，但又要考虑融入更大的软件生态。”

在易特驰端到端业务拓展总监栾顺祺看来，只有联合庞大的用户群体和软件开发者，实现软件生态的有序裂变，才是最大化拓展软件生态圈的良策，也是整车厂根据市场需求进行快速迭代的差异化竞争方案之一。

“目前，汽车软件开发还是基于开源社区和欧洲主导的标准，易特驰提供基于国际标准和开源社区的SOA中间件开发工具链，助力整车厂构建未来的开发者社区，这是易特驰的优势所在。”郑心航表示。

事实上，在开源社区方面的布局，易特驰早有先例。

2022年3月，由博世携手Microsoft等行业领袖倡议的“软件定义汽车工作组”正式成立。旨在为“软件定义汽车”时代的汽车，提供包括OS内核、中间件、云服务及开发工具等与应用功能无关，对OEM品牌差异化影响微弱的通用汽车软件。

值得一提的是，工作组成员不仅来自汽车行业，还涉及IT、云计算、芯片设计以及企业咨询等众多行业。

此外，工作组的行事风格——Code  First，也颇具个性。即参与开源社区的各方把已有或正在开发的软件源码贡献出来，无需先在联盟内达成普遍共识，更加符合当下敏捷开发的需求，这也印证了工作组为复杂的汽车软件平台构建一个巨大生态的决心。

从软件生态角度来看，作为一个纯软件公司，易特驰除了联合业内外合作伙伴共建汽车生态圈，提供开源和规范技术能力注入之外，并没有与硬件供应商绑定的利益诉求，不存在捆绑销售、掌握车企“灵魂”现象。

“未来，有出海计划的车企，其上层软件应用肯定要考虑本土化，底层中间层需要适配，上层应用跟中间层也要无缝适配。”

从出口的角度来看，栾顺祺认为，车企应提前布局一套全球通用的工具链，既能帮助其节省出口所涉及的软件成本，又能吸引当地的开发者加入软件开发生态圈，不失为一种两全打法。

护航整车OS安全

区别于手机、电脑等电子产品，智能汽车的本质还是出行工具，其数据安全、网络安全、软件升级、功能安全和预期功能安全等安全保障仍然是“智能化”的前提。

“传统汽车软件虽然在实时、高功能安全域内进行SOA平台的开发，但在实际量产过程中，整个中间件平台由于是在实时域内，挤占了大量车内功能安全域的算力资源，很有可能会影响到汽车的底盘刹车等核心驾乘功能，给整车行驶带来安全隐患。”郑心航表示。

诚然，电子电气架构的发展驱动下，过去分散在汽车各个领域ECU里的功能安全，集中转变成面向操作系统层面的更高水平安全要求。

以跨域融合为例，尤其是车身域、底盘域等对功能安全要求非常高，如何调用实时功能安全域控亦是软件开发的一大难题。

“从跨域的角度来说，当调用到车内的功能安全组件时，易特驰开发的safety guard将会对授权问题进行核对与询问，可以更好地保障汽车的功能安全。”

据了解，易特驰开发的云原生工具链，兼顾了开发效率、安全和生态建设能力。其重点自研的包括跨域工具链、AutoSar、博世AOS中间件、车规级容器等安全类工具链，可实现不同安全等级OS系统的隔离。

在安全性方面，所谓隔离，即将来整车应用开发过程当中所占用的计算资源会有单独的SOC、单独的Linux内核保障，而不是和实时域的传统汽车软件，包括核心驾乘功能进行算力竞争。

基于此，易特驰提供的safety guard安全守护模块，从整车的角度出发，将各类功能安全的核心控制和维护，收归保障操作系统层面，智能汽车软件开发者无需对整车厂功能安全的概念了解过深，只要关心面向消费者的业务逻辑即可。

以开发驻车座椅调整为例，假如司机换成了另一个与车主身高不同的人，需要调整后视镜位置实现舒适驾车，这一行为要在驻车条件下操作，才能保障车辆行驶安全；若是在行车过程中调整，则存在安全驾驶隐患。

这时，safety guard会启动安全模式判定：后视镜在调整过程中不允许司机挂档开车。其作用类似于一道防火墙，当部分上层应用要访问涉及功能安全部分，必须经过safety guard控制，若判定该请求不满足功能安全要求，safety guard将拒绝上层应用对相关设备或相关操作的调用，确保整车功能安全。

可见，safety guard的最大意义之一，在于将安全逻辑从汽车应用程序开发中解耦出来，既保障了汽车软件开发中涉及到的跨域融合功能安全，亦符合软件开发的敏捷要求。

值得一提的是，易特驰还与合作伙伴共同布置了诸如QNX、Linux、Android、跨域通信等成熟操作系统。于智能汽车软件开发者而言，可在功能容器内快速适配成熟操作系统开发布置功能，无需重新开发整个系统，减少底层重复技术栈的开发。

“未来，易特驰能够给不同车型品牌提供差异化竞争的跨域应用，由整车软件定义汽车API提供相关封装，智能汽车软件开发者和当前智能手机行业的开发者体验类似，可以在自己的PC环境下，启动车辆仿真测试，快速对软件进行开发、迭代。”

不难发现，借助过去近30年的软件经验积淀，面向软件定义汽车时代，易特驰已经备好了足够的粮草和兵马，旨在全面赋能智能汽车软件生态。

尽管针对“车企该不该自研整车OS”这个问题，车企和供应商们或各持己见，但有关汽车软件生态圈的建立、功能安全等，双方仍站在统一战线。

正如康林松所言“要建造‘软件房子’，不必自己铺设每一块砖，你只需要当好建筑师，把控全局，让技术伙伴发挥作用，确保自己与最好的人合作”，诸如奔驰等整车厂、易特驰等供应商和第三方开发者实现共赢或是汽车软件生态的主旋律。