2024年7月蔚来科技日上，蔚来正式推出Sky.OS即天枢操作系统。
蔚来宣称这是蔚来历时4年研发、投入超过23,000人月、面向AI打造的汽车智能底座，对全生命周期的用户体验与企业的体系化效率提升，将发挥重要作用。
2025年4月中旬，理想发布星环OS白皮书。
理想星环OS架构
蔚来数字架构
从中不难看出，天枢系统是一个虚拟机之上四个小型操作系统，严格地说与天枢关联最密切的是SkyOS-M，SkyOS-C是一个改造过的安卓。
SkyOS-M架构
看起来非常复杂，全部使用了专业缩略语，要明白这个图，需要把“lib”即库，这个前缀去掉，blk是block，net自然指网络，serial是指串行，dev就是devices，器件。Srv或sv是service的缩写。
天枢操作系统是基于德国seL4微内核的，2024年10月的seL4峰会上，蔚来技术副总裁曲宁做了演讲，文档如下https://sel4.systems/Foundation/Summit/2024/slides/software-defined.pdf。曲宁北大毕业后去卡梅隆大学深造，第一份工作是英伟达系统软件工程师，然后跳槽到谷歌Linux核心队伍，2018年进入百度，是百度CarOS首席工程师，阿波罗智能驾驶系统也有参与，2020年进入Waymo，负责深度学习Runtime团队，2022年进入蔚来。严格讲seL4也不是德国的，它是一个跨国组织，顶级会员有四家，分别是地平线、蔚来、悉尼大学和高频交易自营商Jump Trading。高级会员中知名的只有苹果，一般会员基本都是大学，包括苏黎世理工学院、堪萨斯州立大学、俄勒冈Lewis & Clark大学、RISC-V国际。此外需要说明，seL4也是Linux基金会的一员。
理想星环OS未透露太多详情，李想解释星环OS的动机时说是2021年芯片尤其是MCU供应紧张，李想试图更换MCU芯片，但这需要AUTOSAR做半年以上的适配和验证，费时费力费钱，所以才开发星环OS。同样蔚来的天枢OS也没有AUTOSAR，特斯拉也可以确定不用AUTOSAR。蔚来的动机应该也是摆脱AUTOSAR限制。
AUTOSAR是欧美汽车工业主导的一个中间件标准，欧美汽车工业一般都是能外包就外包，很少搞垂直化，软件领域则更为明显，基本上所有的软件工作都由独立的第三方软件商供应，这些软件供应商数量众多，且大多是小厂，只做自己专业内的产品。
AUTOSAR方便整车厂和众多第三方软件商对接，提高软件开发复用率，降低软件成本，让软件供应商摆脱对硬件的依赖（对软件开发商如此，对整车厂不是）。而中国汽车工业最初基本是照搬德国汽车工业的经验，因此也接受了AUTROSAR。当然AUTOSAR也秉承了德国汽车工业的严谨，AUTOSAR历经了长期的时间验证。
此外，AUTOSAR很好地覆盖了ISO26262的大部分。AUTOSAR利用MCU提供的某些硬件功能覆盖了大部分安全机制。目前很多厂商拿到车规级MCU并不理解如何利用内部的安全机制，而AUTOSAR通过芯片商提供的MCAL层隐藏了大部分这些看上去"难用"的功能，因而开发更加便利，使得那些软件能力差的车企产生了AUTOSAR依赖。AUTOSAR对中国本土MCU芯片厂家也是个障碍，本土厂家自然对欧美主导的AUTOSAR配合不够。
AUTOSAR不是一个具体标准，它包含了一系列标准和开发方法，包括基本软件模块规范、定义应用接口以及构建基于标准化交换格式的通用开发方法，AUTOSAR依据的标准包括OSEK、HIS、ASAM和ISO等标准，以及CAN、FlexRay和LIN等工业标准，在它们的基础上制定和推广操作系统、硬件驱动和协议的概念及标准定义工作。AUTOSAR架构基于分层和模块化原则构建。它将汽车电子系统的硬件与软件分离，把功能模型软件、软件组件分开，由不同制造商研发，再经自动配置过程组合成具体项目。其设计是典型的分层架构。
AUTOSAR包括基本软件层BSW：由标准化软件模块构成，大多不针对特定汽车工作，但能提供运行上层软件功能所需的服务，像微控制器抽象层、控制器抽象层（ECU和微控制器硬件抽象层HAL）以及相互独立的服务层（如操作系统、通信协议和存储器管理）等都属于基本软件层。
BSW里包含一个RTOS，可以看作是OSEK/VDX （德文: Offene Systeme and deren Schnittstellen fur die Elektronik im Kraftfahr-zeug，汽车电子开放式系统及其接口，法文Vehicle Distributed eX-ecutivr, VDX）的放大版，Autosar OS相对于OSEK增加了调度表，调度表是一个数据结构，用于定义在特定时间间隔内需要执行的任务和事件。它描述了任务的执行顺序、周期、优先级以及其他调度相关的信息。调度表的主要目的是确保系统中的任务能够按照预定的时间和顺序执行，从而满足实时性要求。再有就是中断（Interrupt），中断是AUTOSAR OS的重要组成部分，允许系统在特定事件发生时立即响应。
运行时环境（RTE）：作为中间件，RTE负责在应用程序软件组件之间，以及基本软件和应用程序软件组件之间进行ECU内部和ECU之间的信息交换，也被称为虚拟功能总线（Virtual Function Bus），其作用是控制数据交换，确保软件组件可任意分布在不同设备上，而无需考虑其他运行时系统或不同功能的计算结果。
AUTOSAR需要第三方厂家配合才能达到实用产品级，包括一系列工具链和开发工具。国外企业主要是VECTOR、Elektrobit（EB）、ETAS和KPIT。VECTOR在国内市场占有率较高。国内企业主要是东软睿驰开发的NeuSAR基础软件平台，普华基础软件的PrimusAutoSAR产品，经纬恒润的AURIX TC3xx系列AUTOSAR解决方案。Autosar的标准和架构都是免费开源，主要要钱的都是符合Autosar标准和架构的具体软件产品的一次性费用和授权费，以及配套工具链使用授权费。基本上按模块收费，不同车型的模块仍然要再次收费，理想汽车曾经每年要付出几千万人民币的AUTOSAR费用，蔚来在 2022 年购买 AUTOSAR时花了 2000万~3000 万元。
新兴造车与传统车企最大区别就是新兴造车是用IT行业的经验来造车，软件工作大部分内部完工，并且中国的软件工程师资源非常丰富，有数千万人，整车厂只要愿意，可以招到足够的软件工程师，可以内部完成90%的软件工作，AUTOSAR此时就失去价值，不仅如此，它还会成为累赘，不仅导致开发周期长，开发成本高，灵活性差。在运行时，AUTOSAR还要消耗一定的硬件资源，增加系统延迟。特斯拉，中国新兴造车企业基本上都不用AUTOSAR或准备放弃AUTOSAR。
理想星环OS核心架构
通信框架、Linux、RTOS和虚拟机是软件定义汽车的四大核心，基本上没有整车厂能在这四个领域有所创新，基本上都只能沿用现成的标准做微小改动。大部分所谓汽车OS都无法触及这四个核心领域，偶尔有能做虚拟机的，但也是基于开源方案。
奔驰的MB.OS
图片来源：奔驰
奔驰的MB.OS用QNX做RTOS，与VECTOR合作开发CP AUTOSAR和AP AUTOSAR，虚拟机采用第三方提供，天枢OS和星环OS都比MB.OS技术含量高得多，都抛弃了AUTOSAR，自己开发虚拟机。不过相比大众的VW.OS，奔驰的MB.OS技术含量还是不低，大众的VW.OS充其量只是一个统一App接口界面。
SOME/IP所在位置
图片来源：松下汽车欧洲
智能汽车时代，AUTOSAR的核心或者说最有价值的地方是SOME/IP，SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议，最突出特色之一是兼容老旧的汽车总线如CAN\LIN\MOST\FlexRay。
Scalable指该协议设计的初衷之一就是为了实现不同硬件平台、不同操作系统或嵌入式固件以及不同应用软件的异构设备之间的可扩展性和互操作性。
service-Oriented表明它是一种面向服务的基本协议。因此仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据，这就确保了永远不会浪费带宽，且仅在需要的时间和地点进行数据通信/交换。
over IP表示它是一个基于以太网的协议。
严格讲，SOME/IP不是一款特定的产品，而是一种技术标准。其最早由宝马在2012-2013年开发，并于2014年集成进AUTOSAR 4.2.1中。当前，全球最大的商用SOME/IP产品供应商是Vector。开源版的SOME/IP则是由Genivi协会（现在更名为Connected Vehicle Systems Alliance ，即COVESA）维护，即VSOMEIP，基于Mozilla Public License v2.0协议开源，由BMW贡献。汽车智能化时代的网络基础是以太网，SOME/IP让汽车行业得以大量应用车载以太网。大部分传统车厂之所以接受AUTOSAR也是因为SOME/IP。
抛弃AUTOSAR，多数厂家都选择用DDS取代SOME/IP，此外也有一些厂家只在智能驾驶系统使用DDS，其他部分还是SOME/IP。近年来DDS发展迅速，国内不少新兴造车已经将DDS落地，理想的星环OS核心也是DDS。SOME/IP独立性很强，可以集成进任何操作系统中，也就是说放弃AUTOSAR，一样还可以使用SOME/IP通讯协议栈。一向激进不在乎车规的特斯拉可能没采用SOME/IP，也没用DDS，而是用MQTT，MQTT以其简单性和低资源需求给人留下了深刻的印象。该协议设计用于在不可靠的通信通道上传输少量数据，并且非常适合将少量数据传输到后端。网上知名的第三方开源软件特斯拉日志TeslaMate就是用的MQTT，也很容易被黑客甚至是一般程序员利用其漏洞远程控制车辆。
目前主流的面向服务的中间件有数据分发服务（Data Distribution Service, DDS）、基于IP的可扩展面向服务的中间件（Scalable service-Oriented MiddlewarE over IP， SOME/IP）、消息队列遥测传输协议（Message Queuing Telemetry Transport, MQTT）。DDS是由对象管理组织（Object Management Group, OMG）制定的一种面向服务的通信中间件协议。采用发布订阅模型，强调以数据为中心，提供多种服务质量策略（Quality of Service, QoS），以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求。
DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，后来扩展至航空、航天、船舶、国防、金融、通信、汽车等领域，包括作战系统、船舶导航和控制系统、船舶防御系统、无人机驾驶系统和地面控制系统、装甲车辆控制系统、仿真和培训系统、雷达处理和空中交通管理系统、金融系统等。
在汽车领域，早在2018年，AUTOSAR AP在通信管理模块中加入了DDS技术；ROS2、Apollo CyberRT的底层也是基于DDS协议；Orin、Xavier等面向自动驾驶的系统级芯片（System On Chip, SOC）上也都预留了DDS的接口。DDS已被奥迪、大众等多家OEM厂商应用于智能驾驶、泊车充电、仿真测试平台等场景；国内的造车新势力小鹏汽车等也已经将DDS技术应用到量产车型上。
自动驾驶领域比较有影响力的开源DDS是由RTI原核心团队成员在欧洲创办的eProsima公司推出的FastDDS。国内DDS大多也是基于FastDDS。在eProsima将FastDDS的源代码开放出来后，用户可以直接在github上免费下载。但FastDDS使用起来比较麻烦，这个时候，用户就需要通过向eProsima支付费用来取得支持。此外还有OpenDDS ，由位于圣路易斯和凤凰城的Object Computing的 ACE/TAO 团队开发，它与FastDDS具有一定的相似性——两者都是基于RTPS实现的，面向数据的通信框架，遵循的是同一标准。这类框架的典型特征是去中心化，支持QoS机制，支持实时通信。通常会绑定如protobuf等序列化工具。商业版的有RTI的Connext DDS 、ADLink的 OpenSplice、华玉通软的Swift（雨燕） DDS等。其中华玉通软的Swift（雨燕） DDS早在2021年就已经推出，还有针对MCU的SWIFT DDS-RT版。2023年7月，获得ISO 26262 ASIL D级功能安全产品认证。已适配过市场上主流的车载操作系统和平台，包括Linux、VxWorks、QNX、FreeRTOS、AUTOSAR AP、AUTOSAR CP、CyberRT、ROS2等多种操作系统；同时已成功部署在地平线“征程”系列J5、赛灵思ZU5、英伟达Orin、芯驰G9X、NXP S32G2、TI TDA4以及英飞凌TC397等芯片上。
与SOME/ IP、MQTT相比，DDS具有以下特点：
SOME/IP 是针对汽车领域的中间件，在车载领域已经应用了较长的时间，体量比较小，消耗资源少。MQTT适用于低带宽及不稳定的网络，但它依赖于一个中央代理。DDS本身是一个工业级别的通信标准，适用于多种的应用场景，体量比较大，消耗资源多，用在汽车领域时需要做专门的裁剪以适应汽车领域较低的硬件资源环境。DDS是面向数据的，节点越多，数据量越大，其优势越明显，DDS特别适合V2X这种多个车辆之间的数据交互，SOME/IP适合一辆车内部的数据交互。
相比于SOME/IP，DDS引入大量标准内置特性，在灵活性、可伸缩性等方便更具优势。
SOME/IP主要采用远程过程调用（Remote Procedure Call, RPC）的通信方式，服务器（server）和客户机（client）之间仍有一定的耦合性。而DDS采用发布/订阅机制，实现了通信双方在时间、空间和数据通信上的多维松耦合或解耦。
SOME/IP没有定义QoS机制，只能保证数据可靠，不能保证延迟。MQTT也具有保证稳定传输的机制的，但其仅支持QoS0、QoS1、QoS2的QoS策略。DDS具有丰富的QoS策略，能够满足高复杂性、高灵活性的数据流要求。
DDS在车辆上的应用处于刚起步阶段。简单来说，DDS在车辆上的部署主要有三种方式。第一种是类似于ROS2或Cyber RT，对DDS进行封装后，直接将DDS部署在操作系统上。第二种是依托AUTOSAR AP平台，将DDS部署在AP的Ara::com模块中。由于AUTOSAR AP已经能支持DDS的集成，基于AUTOSAR分层架构，DDS的部署和SOME/IP一样对于应用层是透明的。通过不同的网络绑定，DDS便能较为快捷地集成在AUTOSAR AP中。第三种，面向资源受限设备的DDS集成方案，即将DDS部署在微控制器（Micro Control Unit, MCU）上。这样MCU便能通过DDS与其他的DDS网络通信实现信息交互。而传统的MCU一般是基于AUTOSAR CP开发的，而目前CP平台仅支持SOME/IP的功能，并不支持DDS的集成。另外，一般基于C++版本实现的DDS资源占用率较高，并不适合部署在资源受控的微控制器上，因此，需要开发DDS的轻量化版本。
各个组织或团队对汽车软件标准的争夺
图片来源：15th AUTOSAR Open Conference, Jennifer Neumüller
实际蔚来和理想做的，中国汽车工业协会软件定义汽车工作小组可能也在做，即图上的CAAM SDV，从上图可以看出，CAAM SDV完全覆盖AUTOSAR的功能范围。CAAM SDV在2022年12月底发布了SDV设备抽象API接口和SDV原子服务API接口。
传统车企对AUTOSAR的依赖性短期内还会存在，大部分新兴造车企业都会开发出类似天枢OS和星环OS的系统。自己开发系统会有不少好处，除了成本，还能加快迭代速度。但AUTOSAR在安全方面可能确实有点优势，同时对传统车厂来说，AUTOSAR更容易划分责任范围，所以传统车厂AUTOSAR的依赖性还会存在，不过天枢和星环的出现，会刺激AUTOSAR价格下降，这都得感谢蔚来和理想。
免责说明：本文观点和数据仅供参考，和实际情况可能存在偏差。本文不构成投资建议，文中所有观点、数据仅代表笔者立场，不具有任何指导、投资和决策意见。
全部评论 （0）