2023整车操作系统发展趋势研究-正式版

亿欧智库/researchCopyrightreservedtoEOIntelligence,July2023研究报告2023整车操作系统发展趋势研究整车操作系统是汽车操作系统未来发展重要趋势11.1定义：实现整车操作系统的最佳方法论1.2特点：基于SOA架构的整车OS的最大价值在1.3于可实现“跨域功能的调度和融合”1.3趋势：EE架构向整车集中进化，整车操作系统成为汽车操作系统下一阶段1.4路径：OEM软件定义汽车转型路径2

整车操作系统实现高阶软件定义汽车2.1现状：主机厂与供应商合作共赢，短期升级E/E架构，长期重点发力SOA架构2.2主机厂技术路径选择2.3痛点：主机厂技术路径选择及面临的瓶颈2.4解决方案：ETAS（易特驰）提供用于软件定义汽车的端到端解决方案和工具生态系统目录行业标准助力构建开放、开源、多层解耦的立体生态体系3C

O

N

T

E

N

T

S3.1生态定义操作系统3.2行业标准构建开放繁荣生态4

未来整车操作系统展望与机会4.1未来整车操作系统生态趋势展望4.2未来主机厂革新趋势洞察名词解释

AUTOSAR

联盟：成立于2003

年，是一种面向汽车行业内各组织的开发伙伴关系。该联盟为汽车电子控制装置开发开放的、标准化的软件架构。

ASIL

汽车安全集成等级：ISO26262标准针对道路车辆的功能安全性定义的风险分类系统，该标准将功能安全定义为“不存在由电气电子系统故障行为相关的危害引起的不合理风险”。ISO

26262确定了四种ASIL—A、B、C和D。ASILA

代表最低程度的汽车危害，ASIL

D

则代表最高程度的汽车危险。若是识别为QM的风险，不需要有对应的安全需求。

COVESA联盟：前身为GENIVI，成立于2009年，是一个全球数十个联盟成员共同构成并驱动的非营利汽车技术联盟，专注于开放标准与技术的发展，加速互联汽车系统的创新，营造更加多元、可持续且高度整合的交通运输生态系统。

DCU域控制器：根据汽车电子部件功能将整车划分为动力总成、智能座舱和智能驾驶等几个域，集中控制域内原本归属各个ECU的大部分功能，以取代传统的分布式架构。

ECU电子控制单元：是汽车电子控制系统的大脑，它对各个传感器输入的电信号以及部分执行器反馈的电信号进行综合分析与处理，给传感器提供参考电压，然后向执行器发出控制信号，使执行器按照控制目标进行工作。

HPC高性能计算单元：通过聚合计算能力来提供比传统计算机或服务器更强大的计算性能。

OEM原始设备制造商：又称作主机厂、整车厂。

OTA空中下载：通过空中下载的方式对车辆中的软件进行远程升级。

SOA面向服务的架构：是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。

SoC

芯片：是单片系统或片上系统，是一个将电脑或其他电子系统集成到单一芯片的集成电路。单片系统可以处理数字信号、模拟信号、混合信号甚至更高频率的信号。

Tier1供应商：即一级供应商，也就是跟OEM签订供应合同的供应商。

车控操作系统：运行于车载智能计算基础平台异构硬件之上，支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合。

车用操作系统：运行于车内的系统程序集合，以实现管理硬件资源、隐藏内部逻辑提供软件平台、提供用户程序与系统交互接口、为上层应用提供基础服务等功能，包含车控操作系统和车载操作系统。

云原生：根据AWS的定义，云原生是在云计算环境中构建、部署和管理现代应用程序的软件方法。现代企业希望构建高度可扩展、灵活且具有弹性的应用程序，可以快速更新以满足客户需求。

中央计算平台：车身域以及动力域的核心计算单元，集成了中央网关、车身舒适域控制、新能源动力控制、空调热管理等功能。3整车操作系统是汽车操作系统未来发展重要趋势1996年，Gartner提出SOA，其核心思想在于“通过将庞大的计算系统按照实际业务拆分为独立部署的大小合适的功能模块，提高功能单元的复用性，降低产品开发的复杂度和成本”。如今，软件定义汽车领域引入SOA，旨在向用户提供全生命周期的跨域软件服务。基于SOA架构的整车操作系统的最大价值在于可实现“跨域功能的调度和融合”，基于标准化接口快速响应新功能需求。未来，随着汽车E/E架构向中央集中进化，消费者对智能汽车体验感的期待逐渐增加，基于SOA的整车操作系统将成为汽车操作系统下一阶段。头部主机厂纷纷加入这一领域的竞争。对比不同发展路径的优劣势后，亿欧智库认为对于绝大多数OEM而言，综合性价比和可行性最高的路径是与软件供应商合作共创，保障开发效率，降低时间和金钱成本，快速拓展开发者生态圈。41.1定义：实现整车操作系统的最佳方法论——面向服务的软件架构（SOA）

自从汽车电子电气化以来，汽车软件的主要开发模式是在电子控制器之内的嵌入式软件开发，整个汽车的EE架构是分布式的。然而未来将出现一类新类型的智能汽车软件：跨域融合软件。

根据博世的定义，整车可分为五大功能域，分别为

Energy,Motion,Body&

Comfort,Infotainment,ADAS，即动力总成域、底盘域、车身域、智能座舱域和自动驾驶域。五大功能域由三大操作系统所控制，这些操作系统统称为车用操作系统。而整车操作系统则可以实现驾舱的跨域融合，将车内各域的功能全部挂载到一套操作系统或同一套编程接口之上，基于标准化接口快速响应新功能需求。因此，软件工程师在修改或新增某一软件功能时，只需对上层应用所对应的服务组件进行代码编写，无需修改底层电子控制器，极大地减少了软件开发的复杂度和成本。亿欧智库：汽车操作系统分类整车操作系统跨域融合车用操作系统车控操作系统车载操作系统安全车控操作系统智能驾驶操作系统动力总成域底盘域车身域自动驾驶域智能座舱域负责自动驾驶过程中大量传感器融合数据的处理任务集成全液晶仪表盘、抬头显示仪、中控屏幕及后座娱乐系统等功能集成汽车传统功能控制指令和通信的计算需求安全性和实时性芯片算力需求

为实现跨域融合等中央计算平台的发展，高性能SoC产品和中央集中式E/E架构是实现跨域融合的硬件基础，而面向服务的软件架构（SOA）则是实现跨域融合的软件基础。1996年，SOA概念由Gartner提出，并率先在IT行业被应用推广。目前，SOA的架构设计理念已经广泛应用于IT和互联网行业

。SOA并非一类特定的软件产品，而是一种软件架构设计的理念，其核心思想在于“通过将庞大的计算系统按照实际业务拆分为独立部署的大小合适的功能模块，提高功能单元的复用性，降低产品开发的复杂度和成本”。如今，软件定义汽车领域引入SOA，打造“底层硬件、中间层操作系统、上层应用程序”的软件分工模式，实现上层应用软件和底层基础软件的解耦，最终“向用户提供全生命周期的跨域软件服务”。因此，SOA已经成为实现整车操作系统的最佳方法论。

值得注意的是，传统汽车软件开发的中间性工具链并不会被取代，刹车、转向、防抱死、车身稳定控制等传统车控软件是由单一ECU控制，并不适用于SOA架构，未来仍会通过基于模型仿真和嵌入式的传统汽车软件开发方式进行开发。但是由于未来新型的车用软件需具备跨域能力，因此无法按照传统单一ECU的开发方式去开发，必须采用SOA架构。需要实现跨域功能的软件。适合基于SOA架构开发的软件场景1—电动车电池预加热：电动卡车在行车途中，根据导航地图计算出下一个补能点，并提前让电池进入最佳的充电温度。场景2—舒适进入：用户在进入座舱前，蓝牙已经连上手机并且识别出驾驶人，根据之前的配置信息，调整座椅后视镜，方向盘高度，打开氛围灯和空调。适合基于模型仿真的传统汽车软件开发动力总成域、底盘域和车身域中的安全车控系统，这些软件对实时性和功能安全性具有非常高的要求。资料来源：中国汽车报、中国电动汽车百人会、《车用操作系统测试评价研究报告》、亿欧智库51.2特点：基于SOA架构的整车操作系统的最大价值在于可实现“跨域功能的调度和融合”

智能汽车SOA软件架构的特点在于分层化、模块化。其中，下层基础软件具备接口标准化、相互独立、松耦合的特点。•

汽车软件架构分层化：智能汽车SOA按层级自下而上大致可分为硬件平台、系统软件（虚拟机、系统内核、中间件）、功能软件以及应用软件。广义操作系统由系统软件和功能软件组成，处于上层应用软件和底层硬件之间，一般采用分层的方法和结构由底层向上构建，以此来实现软硬件解耦，从而将软件功能的更新与车型的更新分离开来。•

汽车软件架构模块化：按照业务功能，智能汽车SOA把软件系统拆分为多个独立的功能模块（即服务），模块之间通过标准化的接口和数据格式相互调用。在汽车生产中，模块化带来的优势是实现应用层功能在不同车型、硬件平台、操作系统上复用，通过减少重复设计实现了更低的开发成本，提高开发效率，还可基于标准的接口对应用功能进行快速迭代升级。

基于SOA架构的整车操作系统的最大价值在于可实现“跨域功能的调度和融合”。由于API已经提前预埋好，在SOA架构下开发和升级软件无需改变原有ECU内的控制模型。上层应用软件在中央计算平台上，可通过SOA调用直接控制跨域的ECU事件。因此，软件开发时间可从半年被压缩到2周，再经历2周验证后，车企即可对用户进行OTA推送。例如，通过身份识别判定车内不同座位上的人员，自动调整车内的座椅和靠背的位置、分区空调、后视镜角度。由于这种功能体验集成涉及到4至5个不同的ECU，在传统的开发模式下，需要每个ECU的供应商修改其嵌入式软件，再进行功能安全验证，耗时非常长。亿欧智库：整车操作系统架构图SOA架构应用软件功能软件应用软件动力系统数据地图底盘系统HMI感知融合决策规划信息娱乐控制执行工具链｜｜开发&仿真&调试&测试等广义操作系统车身系统自动驾驶自动驾驶网联/云控整车控制执行智能座舱安全体系中间件组件（AUTOSARRTE/分布式通信/管理平面和数据平面等）狭义操作系统：内核（Linux/VxWorks/OSEKOS等RTOS）Hypervisior/BSP/Drivers系统软件硬件平台AI单元/计算单元（ASIC/GPU/CPU/FPGA）控制单元MCU外围硬件车辆平台摄像头、雷达、GPS惯导等传感器V2X（云控/地图）动力、底盘控制等自动驾驶车辆/功能需求/平台技术/整车集成资料来源：公开资料、亿欧智库61.3趋势：E/E架构向中央集中进化，消费者对智能汽车体验感的期待增加，基于SOA的整车操作系统成为汽车操作系统下一阶段

技术层面：整车电子电气架构由传统分布式向域集中式，进一步向中央集中式演进，给整车操作系统发展带来必要的硬件基础。目前市面上大部分主流量产车（尤其是燃油车）都是传统分布式E/E架构，各项功能由上百个ECU来控制，且采用“面向信号”的软件结构，ECU之间通过CAN/LIN,

总线进行点对点通信。由于这种架构下的软硬件深度绑定，软件升级成本较高，时间周期较长，无法满足车辆功能的增长速度和车载计算能力日益增长的需求。而引入以太网且基于五大域的域集中式架构，一方面能够减少ECU数量，从系统上降低成本、重量和功耗；另一方面基于SOA软件架构，实现软件快速创新与迭代。

未来，ECU的功能进一步集成到中央计算单元，智能汽车从域集中式架构将演变成为一个开放的超级计算机（中央集中式平台），其形态是中央计算单元+区域控制器。平台上运行着标准化的硬件系统和多核、分布、异构的操作系统及中间件服务，其上运行着各类丰富的应用(部分属于云应用软件)，横跨五大域。一方面，可以满足对更强大的算力部署、更高的信号传输效率需求，另一方面，可以搭建车内操作系统应用级生态。亿欧智库：整车操作系统E/E架构演进域控制器1域控制器2域控制器3域控制器4中央计算平台传统分布式架构每个ECU功能固定，相互难协同孤岛式开发：各ECU底层代码复用和移植困难，切换供应商需从头开发域集中式架构中央集中式架构中央计算平台运行统一的操作系统传感器和执行器由中央计算单元通过标准化接口进行控制••••••算力集中化：由少数几个高性能域控制器取代数以百计的ECUSOA软件架构，支持整车OTA特点描述•整车OS：同时负责车控、座舱和智能驾驶支持网络安全、OTA升级、网联等••集成嵌入式的环境，对实时性和安全性的需求高开始出现车载OS和车控OS•不同域控制器上搭载不同操作系统，满足不同功能安全等级和实时性需求的应用的运行对操作系统的需求•E/E趋势：集中式、轻量精简、可拓展时间2020年以前2025年左右2030年左右

消费者层面：消费者对智能汽车驾乘体验的期待日益增长，从需求侧反向推动供给侧升级。由于大多数消费者在购车时对SOA概念并无太多认知，因此“SOA架构”无法构成促进销售的直接卖点。但是消费者对SOA架构的推广仍存在间接作用：随着自动驾驶和智能座舱的发展，未来消费者对于智能汽车的期待是其能通过功能融合方式充分发挥出除了运输之外的各种能力，例如娱乐、社交功能等，汽车作为除家和公司外的第三生活空间的电子消费属性会越来越强，智能汽车中核心驾乘功能在消费者体验感中的占比反而会逐渐降低。因为车内驾乘体验提升需要通过跨域来实现，而通过SOA开发可极大提升开发效率和交互速度。

虽然从SOA落地到实现汽车应用商店还有很长的路要走，未来3至5年难以推动规模化的软件销售。但是可以明确的是未来主机厂的智能汽车品牌差异性和核心竞争力将从底层芯片转移为上层应用软件，即通过软件方式实现功能跨域融合。因此，主机厂需要有一套能够覆盖车内所有元器件、软硬件能力的强大的中央计算平台，这样才能够更好地给予消费者服务。

综上所述，基于SOA软件架构的整车操作系统将成为智能汽车发展的必然趋势。资料来源：专家访谈、博世、ETAS、亿欧智库71.4路径：OEM软件定义汽车转型路径

在SOA软件框架下，OEM、Tier1以及软件开发者都将融入应用软件的开发生态。基于OEM不同的研发实力、产品开发需求与供应商的关系，OEM软件定义汽车转型呈现出3种路径模式：•

全栈式自研：OEM成立软件子公司或内部软件部门，负责软件研发，实现全栈技术自研布局，OEM逐渐掌握软件、算法、芯片等全技术栈的自主研发能力，一定程度上绕过传统Tier1的架构升级路线。•

合作研发：OEM一边扩充内部研发队伍，一边与Tier1建立战略联盟，OEM负责推进软件生态建设，Tier1负责执行。•

直接外采：OEM直接外采成熟的整车操作系统解决方案，一般是由Tier1提供软硬件一体化的“黑盒”产品，软硬件解耦难度非常高。

整车操作系统行业尚处于发展初期，未来存在一定的不确定性。但是从实践看，部分之前明确提出全栈自研整车OS的主机厂陆续出现进展推迟或不再按固定节奏披露实际进度，甚至在未来规划的产品组合当中不再全盘考虑自研操作系统的情况，有些则明确表示部分产品将搭载Tier1的产品。

考虑到技术、时间、资金、生态等要素，亿欧智库预测，未来或许有极少数

OEM

能够完成“芯片+操作系统+应用软件”全栈自研，但对于绝大多数

OEM

而言，综合性价比和可行性最高的路径是与软件供应商合作共创，保障开发效率，降低时间和金钱成本，快速拓展开发者生态圈。亿欧智库：OEM软件定义汽车转型路径优势劣势•••主导权唯一，自主把握架构升级路线任务分工更明确、部门协作性强、效率高掌握软件、算法、芯片等全技术栈的自主研发能力•软件操作系统和中间件的本质是提高开发效率，但并不会给消费者体验带来差异化区分，因此OEM对底层软件的自研投资回报很低全栈式自研•掌握开发者生态资源，形成垄断优势•对软件Know-how

积累较浅，缺少软件思维和软件人才•••全栈自研依赖AI芯片支持，自研门槛高开发反馈少，软件迭代速度慢内部封闭式的工具链，对汽车技术要求很高，难以吸引到外部开发者•OEM之间无法进行技术共享，行业存在大量重复劳动，效率很低••••供应商具备更强的软件开发能力和芯片定义能力，更丰富的系统应用场景，可更快实现产品迭代，降低研发成本OEM可最大程度实现自主可控，有选择性地在具备战略性差异的领域建立研发能力，共性软件由供应商提供••存在架构升级路线争议问题存在知识产权争议问题合作研发直接外采双方共同拓展开发者生态圈，效率更高前期无需投入时间和资金，OEM承担风险低••••属于“黑盒模式”的一锤子买卖遵循软件厂商的架构升级路线图软硬件解耦难度非常高无法掌握软件、算法、芯片等技术栈的自主研发能力资料来源：公开资料、亿欧智库8整车操作系统实现高阶软件定义汽车越来越多的传统主机厂在软件定义汽车领域激流勇进，并将研发整车操作系统提上日程，以期实现高阶的软件定义汽车。但是考虑到技术门槛、成本、效率等因素，主机厂研发整车操作系统的最佳路径是与优秀的供应商携手“合作研发”，短期升级E/E架构，长期重点发力SOA架构。本章以大众汽车、吉利汽车、上汽零束为例，分别分析三家车企在整车操作系统领域的发展现状和未来规划，并洞察它们的优势、劣势和挑战。在此基础上，总结主机厂在发展整车操作系统时面临的六大瓶颈。为解决“效率”、“安全”、“生态”难点，易特驰ETAS可为主机厂提供用于软件定义汽车的端到端解决方案和工具生态系统。92.1现状：主机厂与供应商合作共赢，短期升级E/E架构，长期重点发力SOA架构

近些来，随着“软件定义汽车”兴起，为给用户带来更丰富的智驾体验，同时确保知识产权和技术能力自主可控，越来越多的主机厂提出“全栈自研OS”的战略。但是行业对“全栈”并没有清晰的定义，若按照从底层芯片、硬件模组、操作系统再到软件系统的全栈定义，目前车企提出的全栈自研通常不是真正意义上的全栈，部分软件和硬件仍需Tier1和Tier2供应商提供技术和产品。而国际主机厂出于软件技术难点和效益考虑，已经经历了从自研OS转为合作研发OS的发展路线。

目前，大多数造车新势力得益于自身强大的软件开发能力和属性，选择了核心领域和核心技术全栈自研的发展路径。而积极谋求转型升级的传统主机厂，一方面组建软件部门或者成立软件子公司，另一方面通过资本手段与Tier1合资，或者与科技公司建立合作，构建自身软件能力。例如，大众集团旗下软件子公司CARIAD中国与地平线成立合资公司；吉利汽车成立亿咖通科技，赋能吉利汽车智能化；上汽集团旗下的零束科技与SOC芯片、算法、域控制器等多类外部供应商合作，共同打造全栈解决方案，不仅赋能集团，未来将会对其他车企开发平台。

SOA软件架构的硬件基础是E/E架构集中化，五大功能域之间开始尝试进行跨域融合。短期来看，大部分主机厂的发展重点是“E/E架构升级”和“底层基础软件（系统内核、AUTOSARAP、中间层等）”。各大主机厂开始研发或发布下一代E/E架构，中央计算平台和域控制器的组合是下一代E/E架构的重点。例如，2025年，大众、奥迪、保时捷三个平台将统一使用E3

2.0SSP（Scalable

Systems

Platform）中央计算平台；吉利GEEA2.0时代是高度集成的域控制架构，2025年进入GEEA3.0时代，即中央计算平台架构；上汽零束的整车计算平台（零束银河全栈3.0版本）采用两个HPC高性能计算单元和4个域控制器。亿欧智库：大众、吉利、上汽零束智能汽车架构形态对比大众汽车吉利汽车上汽零束SSP中央计算平台（2025）GEEA3.0（2025）2个HPC+4个区域控制器（2022）E/E架构软件架构SOA架构SOA架构SOA架构相互融合的功能域车身域+动力域+底盘域整车控制域车身域+座舱域座舱域+智驾域舱驾一体域最终形态暂未公开跨域计划资料来源：专家访谈、公开资料、亿欧智库102.1现状：主机厂与供应商合作共赢，短期升级E/E架构，长期重点发力SOA架构

由上可以看出各主机厂规划的中央集中式架构并不完全相同，但研发设计理念大同小异。在硬件层面，先将部分域的功能集成到一个高性能计算单元内，再逐渐聚合更多的功能域，最终实现1个中央计算平台+区域控制的架构方案。在软件层面，采用SOA软件架构，实现软硬件解耦。舱驾融合（智能座舱域和智能驾驶域）则是在发展过程中的产物。

但是考虑到技术门槛和车型量产节奏，目前，大部分主机厂的SOA架构落地方式是基于不同的域控制器，例如基于SOA架构开发智能驾驶域OS或智能座舱域OS。由于国内传统主机厂，无论是E/E架构变革，还是软硬件开发方式变革，都将牵涉众多车型以及庞大的供应商体系，因此传统E/E架构模式难以一步升级到位，因此采用更保守的推进方案，将SOA软件开发架构率先应用在智能座舱的娱乐系统或者ADAS中，以期逐步推广到整车架构。

亿欧智库预计，未来3-5年将迎来SOA量产的高峰期。长期来看，SOA架构的开发模式是技术发展的主要方向。亿欧智库：主机厂跨域融合OS发展路径整车OS长期来看，随着座舱域和驾驶域逐渐走向融合，驱动整车向更高级别的智能化形态演03进，必然需要整车层面的OS才能支撑，整车OS、中央计算平台将成为主机厂和科技公司的新战场。中央计算平台硬件架构智控智驾智舱跨域OS02目前，跨域融合更多集中在舱驾融合。该阶段，主机厂大多采用SOA的架构，实现软硬件解耦，且主要是在系统侧做舱驾融合。智驾计算平台智舱计算平台智驾计算平台智舱计算平台智驾+智舱计算平台智控计算平台硬件架构智控+智驾计算平台智控+智舱计算平台智能座舱OS+智能驾驶OS+安全车控OS与智能驾驶域

OS

更加注重高实时、安全性不同，座舱域OS

由于更加注重应用和开发者生态，功能安全要求相对较低，技术上更容易实现，所以座舱域OS变成了许多主机厂和科技公司率先进军的领域。01智驾计算平台智舱计算平台硬件架构智控+智驾计算平台资料来源：专家访谈、公开资料、亿欧智库112.2主机厂技术路径选择2.2.1大众汽车：软件子公司CARIAD携手供应商，重点打造中央计算平台SSP和VW.OS

大众汽车为了加速智能驾驶和智能座舱技术的应用，提升软件能力，先后通过组建软件研发部门、成立软件子公司、与优秀供应商合作等方式研发整车操作系统VW.OS。亿欧智库：大众汽车整车操作系统发展历程•成立软件子公司CARIAD，前身是“Car.Software”，同时接手MobilityAsia的工作•大众汽车旗下智能出行服务公司MobilityAsia成立•大众推出MEB模块化电驱动平台•大众宣布量产ID3•大众汽车公开宣布•大众发布ID4。随着MEB平台推出、大众ID3和ID4发布，跨域融合式架构在大众内部落地•大

众

汽

车

宣

布

研

发VW.OS车载操作系统正式成立“Car.Software”车载软件开发部门

CARIAD为大众集团开发的软件平台，将分为三个阶段，分别是量产阶段、高端阶段和统一、可拓展阶段。2025年之前，旗下所有新车型将会使用VW.OS操作系统和大众汽车云。到2030年，SSP技术栈将实现在全球4000万辆汽车上的运行。其中，中国团队将主导与参与涉及全新软件平台技术栈和产品线70%的研发工作，包括本土研发和适配。亿欧智库：大众CARIAD软件平台发展阶段202520242022H2统一、可扩展阶段量产阶段（Volume）高端阶段（Premium）（Unified&Scalable）适用于MEB平台车型量产型软件平台。针对PPE平台，支撑基于安卓开源系统的先进信息娱乐系统以及高级驾驶辅助系统，并支持在部分奥迪和保时捷品牌车型上实现OTA。将搭载SSP平台，适用于集团旗下所有品牌，支撑大众自主研发的操作系统VW.OS，并连接至大众汽车云VW.AC。中国团队将主导实现在中国的ID.家族系列产品上实现OTA。中国团队将主导适用于PPE平台的高端型软件平台在中国的特定应用。资料来源：专家访谈、公开资料、亿欧智库122.2主机厂技术路径选择

大众作为头部国际主机厂发展整车操作系统具有硬件、软件和生态三大层面上的优势。

在硬件层面，大众MEB域集中式E/E架构包括3个域控制器ICAS（In-Car

Application-Server），即ICAS1车辆控制域、ICAS2智能驾驶域和ICAS3智能座舱域。ICAS的总体建设思路是实现硬件的解耦和热拔插，实现软硬件的可升级拓展，最终达到软件定义汽车。在软件层面，智能座舱操作系统的内核通常基于安卓系统，因此具有适配能力强、迭代速度快的优势，但也存在安全性较差、数据泄露等问题。因此，大众在开发ICAS和VW.OS过程中特别注重整体安全性。此外，大众集团全球年销量超过1000万辆，拥有庞大的用户群体，这是日后形成丰富的软件生态的用户基础。亿欧智库：大众发展整车操作系统的优势三大域控制器整车安全性能更强用户规模效应显著大众很早便能使用车辆控制域、智能驾驶域和智能座舱域共3个域控制器实现管理，相较于多数车企需要4到5个域控制器而言，更加节约成本。大众ICAS开发过程中充分考虑安全规范和安全防御，电池实验分析和论证到位，相较于新势力车企安全性能更好。大众拥有千万量级别的年产销规模和庞大的用户群体，软件生态能够发更显著的规模效应和更高效的优化效率。

受制于大众汽车集团庞大的组织架构和传统采购流程，大众在开发整车操作系统时面临效率低、协调成本高的难题。除此之外，大众作为主机厂，在软件能力和软件思维方面存在不足，叠之目前上层软件算法开发时间有限，后期验证不充分，存在仪表黑屏、重启死机等问题。因此，大众汽车在中国市场积极寻求与科技公司和软件公司的合作，各取所长，以增强软件研发能力。亿欧智库：大众整车操作系统发展的三大挑战传统采购流程制约OS开发进度1大众和供应商之间的采购合同有合同年限和采购量的约束，合同履行期间一般不会提前终止，大众各个部门有独立的供应商管理和研发测试流程，因此在大众内部难以短时间内推行大规模的OS资源整合。组织架构内部的协调效率较低2一汽大众和上汽大众两个合资厂统一推行应用层供应商资源，并且各有自身的生态资源合作伙伴，但供应商安全签名服务最终需要德国大众完成。因此相较于友商3-6个月的协调时间，大众需要9-12个月，内部协调成本高、效率低。3软件生态建设任重道远大众距离实现100%的软件自研还差十多年的时间，目前大众集团在软件工程人才队伍建设、相关项目经验积累以及软件生态体系能力等方面都存在短板。资料来源：专家访谈、公开资料、亿欧智库132.2主机厂技术路径选择2.2.2吉利：通过成立软件子公司亿咖通、收购魅族等方式，加强自身车机软件能力

在电子电气架构层面，目前，吉利已经进入GEEA2.0时代，即高度集成的域控制架构。其以Flexray

和以太网作为主干网，具备整车OTA和部分SOA的功能，包含智能驾驶域、动态域、影音娱乐域、车身域。吉利GEEA2.0架构已经搭载于星越L。预计2025年公司将推出GEEA3.0

中央计算平台架构，实现从域控制到中央超级大脑进化。GEEA1.0GEEA2.0GEEA3.0域控制：分为智能驾驶域、动态域、影音娱乐域、车身域分布式电子电气架构中央计算平台

在软件架构层面，吉利汽车打造端到端一体的整车软件用户体验。目前吉利研究院已经搭建电子电气架构、整车基础软件、智能座舱软件、自动驾驶软件的全栈自研体系。同时在硬件方面，吉利汽车将实现全面开放，应用SOA软件服务架构，开放1000余个API接口，向全球开发者提供软件开放平台，构建超过1000个整车应用场景引擎，与全球超过1000个数字合作伙伴，一起打造主动式场景服务。

2021年7月，吉利银河OS正式上线，其是亿咖通科技融合百度Apollo导航为吉利汽车深度定制的智能座舱系统，这套系统依托星越L所使用的GEEA2.0电子电气架构提供的超过1300个车身信号与170多个车控功能，以及基于高通骁龙第三代汽车数字座舱平台研发。

2021年11月，“智能吉利2025”战略发布，吉利宣布5年内研发投入将达到1500亿元，包括吉利的全生态布局及吉利银河系列。此外，吉利还提出构建“一网三体系”。一网是指一张“智能吉利科技生态网”，是以智能架构为新基建，围绕芯片、软件操作系统、数据和卫星网搭建端到端的自研体系和生态联盟。“三体系”则是指智能制造体系、智能服务体系、智能能源体系。

2022年，吉利集团收购魅族，引入大量软件人才，增强吉利车机自研能力。2023年3月，吉利推出全新的自研操作系统在银河L7上首发搭载的银河NOS，解决过去智能座舱不智能的问题。

目前，吉利仍在对SOA的所支撑的业务场景及其投资回报进行探索。吉利集团的规划是把智能驾驶和智能座舱完全解耦，开发智能驾驶OS和智能座舱OS，覆盖吉利、领克和几何三个品牌。由于舱驾一体不符合目前吉利的平台化能力和降本增效的目标，即舱驾一体能力难以同时覆盖不同配置的全部车型，因此暂未制定跨域OS的战略规划。亿欧智库：吉利智能座舱OS发展历程第二阶段第四阶段银河OS逐步取代GKUI，吉利和供应商共同定义产品模式逻辑聚焦ONEOS和魅族FLymeAuto的双OS融合方案第一阶段第三阶段第五阶段预计之后吉利全部车型将采用魅族FLymeAuto的OS系统吉利成立亿咖通做GKUI，目前已迭代到GKUI2.0和华为合作鸿蒙OS，在几何品牌车型搭载鸿蒙OS资料来源：专家访谈、公开资料、亿欧智库142.2主机厂技术路径选择

在智能座舱操作系统方面，吉利对标新势力，核心优势在于极致的用户交互体验，但仍存在底层芯片算力有限，芯片和操作系统的适配性有待提高等问题。亿欧智库：吉利发展操作系统的优势和劣势优势：在智能座舱域加强人性化、生态化、智能化和场景化的设计理念，打造多模态交互应用，运用3D引擎和3D渲染，围绕娱乐、出行、个性化、交互体验、生态互联和安全健康六大维度全面提升对用户的服务，给客户带来极致的交互细节体验。劣势：目前的OS系统仍然是基于亿咖通GKUI2.0改造后的版本，底层芯片算力没有明显提高，有限的算力制约了用户体验的流畅度水平。此外，操作系统和芯片的适配度也有待提高。

吉利作为传统主机厂，仍面临决策效率低、缺乏软件思维、流程设计低效、生态建设不够完善等方面的挑战。亿欧智库：吉利发展操作系统的挑战决策方众多且目标不一致人才队伍缺乏持续迭代思维••OS研发体系涉及到三个决策方，组织架构•人才队伍中超过一半来自传统主机厂，仍停留在传统的整车制造一次交付的思维方式上，无法适应目前“先上车、后迭代升级”的OS开发思路。包括品牌研究院、研发团队和销售团队，由于三者需求不同，导致决策效率低。例如，车型项目组希望根据目标人群画像定制开发OS但没有研发经费和资源支持；研发团队希望打造平台化能力，以提高效率；销售团队希望OS契合品牌调性，以提高市场宣发能力。人才团队生态建设不够完善流程设计•软件生态方面：由于车型销量无法满足供应商对量级的需求，因此常需支付比同行更高的软件成本。流程规范不够明确和高效生态建设•目前的流程规范仍遵照传统制造业的需求管理方式，缺乏类似互联网OS产品的“PRD-UE-UI-整体验收交付”的高效流程机制。•硬件生态方面：吉利新车型大多基于高通8155和高通8295芯片，因此吉利OS是基于arm架构，而吉利自研芯片是X86架构，因此如果采用自研芯片，将面临整体

15硬件适配，落地困难较大。资料来源：专家访谈、公开资料、亿欧智库2.2主机厂技术路径选择2.2.3上汽零束：与供应商深度合作，为集团和其他主机厂提供全栈平台解决方案

上汽集团在操作系统领域布局较早，2015年上汽与阿里合作建立斑马智行并推出斑马智行操作系统，2016年落地荣威

RX5；2019年底开始筹备成立软件中心；2020年7月，正式将上汽软件中心定名“零束”，聚力发展软件开发核心能力。

上汽零束定位“平台型软件科技公司”，在成立之初便选择与软件供应商深度合作的发展路线，与多家芯片企业、域控制器企业、算法公司开展紧密合作，为整车企业提供全栈平台解决方案。2020年9月，上汽零束与中科创达达成5年的稳定战略合作关系，共同打造上汽智能网联汽车软件平台。

目前，零束全栈解决方案处于1.0阶段，有3个域控制器，即中央计算（车控及数据融合）、智能驾驶、智能座舱，同时还保留了较多分布式模块。2021年年底零束全栈

1.0解决方案在上汽智己、飞凡汽车量产落地。

2022年11月，上汽零束正式发布“银河”智能汽车全栈解决方案3.0，包括零束银河®智能车操作系统ZOS、零束银河®智驾计算平台ZPD、零束银河®智舱计算平台ZCM、零束银河®舱驾融合计算平台ZXD。在硬件层面，零束银河全栈

3.0版本的电子电气架构进一步中央集中化，通过2个HPC和4个区域控制器实现智能驾驶、智能座舱、智能计算、智能驾驶备份功能，其中1个HPC融合了座舱和智驾功能，支持L4级以上自动驾驶。在软件层面，通过中间件和SOA原子服务层，“向上”提供标准统一的API接口，实现“软软解耦”；“向下”协同国产芯片实现“软硬协同”。2024年，该方案将搭载在智己、飞凡等上汽旗下高端电车品牌上，日后将逐步向其他车企开放。

“银河”全栈智能汽车解决方案3.0为

4+1架构，“4”是指四大核心技术底座，即中央集中式电子架构，云管端一体化SOA软件平台，智舱、智驾和舱驾融合的计算平台，智能车云平台；“1”是指舱驾融合的数字化体验产品。该方案进一步实现面向服务的架构，将边缘计算和数据驱动加入功能实现，底层实现软硬协同，上层实现功能软件平台和基础软件平台的软软解耦。亿欧智库：零束银河4+1产品架构图上层应用舱驾一体化应用开发者生态应用第三方生态应用OTA零束银河进化引擎场景构建引擎多模认知引擎数据工场SOA能力舱外视觉感知引擎基础感知前端算法多模融合引擎分析推理引擎决策输出引擎舱内视觉感知引擎语音语义感知引擎基础软件SOA能力支持中央集中式电子架构资料来源：专家访谈、公开资料、亿欧智库162.2主机厂技术路径选择

上汽零束在集团的助力下积极布局智能网联领域，其发展整车操作系统具有以下优势：1）作为上汽集团体系中最为年轻的组织团队，成功摆脱传统主机厂固有的封闭式组织架构及思想，拥抱扁平化的管理模式，拥有软件迭代思维的人才团队，建立“先上车后迭代”的路线，从而实现整车操作系统的快速落地。2）上汽零束SOA软件平台为主机厂、第三方应用厂商和个人开发者提供灵活的开发工具，实现应用软件的快速迭代。3）上汽零束积极建设软件生态圈，并且传统的供应链关系，实现生态开发合作共赢。亿欧智库：上汽零束发展整车操作系统的优势积极推进组织与文化创新，走“先上车后迭代”的发展路线1零束科技作为上汽集团子公司，却拥有人事、财务等重大决策权力，并建立起符合软件公司和软件人才特点的机制，大大提高研发OS的决策效率。这也为零束全栈方案实行“先上车后迭代”的路线奠定组织和文化基础，落地速度快于其他传统主机厂。拥有丰富的SOA开发者生态，应用软件迭代速度快2上汽零束SOA软件平台的参与者不仅仅局限于主机厂，还包括第三方应用厂商和个人开发者，并对不同群体提供不同的开发工具。此外，应用软件还可实现“T+0+1+7”的迭代速度。截止2022年底，已有超过5000名开发者在开发者平台上完成注册，生成800余款场景和轻应用类产品。广泛连接供应链生态和合作伙伴，与生态开发者合作共赢3一方面，上汽零束通过联合研发项目、联合实验室、合资企业、交叉持股等方式建设软件生态圈。另一方面，商业模式上，生态圈利益共享，摒弃传统的供应链关系，转为生态开发者，2021年起零束计划每年举办SOA软件开发者大会。

除了上述优势以外，上汽零束仍面临众多挑战。首先，上汽零束旨在把“SOA软件平台”打造为谷歌的“安卓”，不仅在上汽旗下品牌上应用，并且计划对外开发。但是上汽品牌的用户基数与手机用户相比，存在很大差距。其次，其他主机厂纷纷在自研OS，对于装载银行全栈方案的意志可能不高。最后，若无法在短期内搭载更多的车型，将影响银行全栈方案的迭代速度。因此，上汽零束需要加强与其他车厂的合作，提高银河全栈方案的兼容性和可扩展性，以拓展市场和增强竞争力。亿欧智库：上汽零束发展整车操作系统的挑战其他主机厂对于银河全栈方02案的装载意志未知上汽零束作为银河全栈方案的开发者01

用户流量不足03

车型生态亟待开放和运营者，其他主机厂因具有不同的独立性和开放性，可能对于银河全栈方案的装载意志不高。上汽自主品牌，受到销量及库存限制，即使旗下车型全面安装银河全栈方案，用户基数也无法与基于手机的操作系统的用户数相比。由于短时间内不能搭载更多车辆品牌的情况下，将会影响银河全栈方案的应用软件生态系统建设、创新动力和技术壁垒等方面，从而限制了其发展潜力和市场竞争力。资料来源：专家访谈、公开资料、亿欧智库172.3痛点：主机厂研发整车操作系统面临的瓶颈

现阶段，我国整车操作系统研发以及SOA架构在汽车行业的应用均处于起步阶段，无论从主机厂自身的组织架构、人才体系、技术能力，还是从行业生态、行业标准等方面，主机厂都面临一系列挑战。从多维度了解自身长处和痛点，可以帮助主机厂在寻找合作伙伴时有的放矢，同时“有所为，有所不为”，以实现发展路径的最优化。亿欧智库：主机厂研发整车操作系统面临的六大瓶颈传统组织架构僵化，软件人才短缺整车操作系统生态支撑能力不足传统主机厂组织架构庞大臃肿，在整车操作系统研发及供应链采购过程中涉及到的决策由于涉及多部门协作，导致决策效率低、时间周期长。同时，传统汽车软件开发模式（孤岛开发）无法满足面向SOA架构的软件开发，亟待变革。此外，传统主机厂在汽车硬件有所长，但是缺少软件人才和软件思维，给转型带来一定困难。由于我国整车操作系统研发处于起步阶段，生态体系建设才开始，还需要更多Tier1供应商、科技公司和第三方开发者等参与进来。由于中国汽车操作系统开发工程师数量稀缺，因此构建整车OS必须要选择开源，只有丰富的开发者生态以及软件工具链，才能够支撑整车OS的开发。上层应用软件可调用安全域控制器，影响驾驶安全软件技术发展不成熟，缺乏SOA架构经验主机厂更擅长传统汽车软件开发，采用V模型开发模式，软件迭代时间长；需要SOA软件开发平台，以支持第三方开发者快速进行软件的开发、测试和发布。但是汽车行业SOA架构应用处于早期阶段，SOA的设计方法、设计流程、规范体系，以及工具链建设，尚没有形成体系化、标准化，尤其是目前内部自研的工具链，易用性低、学习成本高。尽管在实时和高功能安全域内进行SOA平台开发，但在实际量产项目中，中间件平台在实时域内因占用大量车内功能安全域的算力资源，很有可能会影响到汽车核心驾乘功能（如底盘刹车等），给整车行驶带来安全隐患。专注平台化能力，难以满足各车型的个性化需求整车操作系统标准体系尚不完善主机厂更加专注操作系统平台化能力的建设，以期实现一套OS可以搭载在各个车型上，但是由于主机厂旗下车型数量众多，不同的品牌部门对操作系统的需求有所不同。但是主机厂在这方面的能力相对较弱，往往难以满足不同车型的个性化需求。缺乏体系性的标准和规范，造成各个系统独立发展，难以形成规模。在安全标准规范方面，特别是涉及到功能安全和信息安全的规范大都依赖国外，自主研发的标准体系还比较匮乏。资料来源：专家访谈、公开资料、亿欧智库182.4解决方案：ETAS（易特驰）提供用于软件定义汽车的端到端解决方案和工具生态系统

随着一批有能力的主机厂参与到域控制器的软件开发，软硬件分离的需求越来越大，为实现更快地开发、部署和更新软件解决方案，主机厂需要更全面的组件支持，包括软件包、工具链、平台组件、集成方法与工具等。同时，随着E/E架构逐渐转向中央计算架构，传统的分布式软件也需要进行重构和模块化。

因此，SDV行业早已形成共识，主机厂、供应商和第三方开发者合作实现共赢是汽车软件生态的主旋律。主机厂主导基于原子服务实现对整车服务、应用、体验等进行定义、组合、增强，构建OEM差异化竞争力应用软件开发与迭代软件供应商主导••定义符合行业生态的技术架构提供开发方法论和开发与调试工具链安全体系工具链API接口功能软件•提供整车基础运行环境、基础软件等中间件组件狭义操作系统虚拟机••针对应用开发接口能力针对不同芯片深度定制化适配与抽象能力硬件平台1硬件平台2...硬件平台n硬件供应商主导

易特驰（ETAS）作为博世旗下软件子公司既可以为主机厂提供端到端的全栈方案，也可以提供个性化、模块化的解决方案。2022年，博世将汽车通用基础软件，中间件和云服务以及开发工具业务纳入ETAS旗下，使得ETAS成功吸收整合了博世在通用基础软件领域的数十年的成功经验。

值得关注的是，除了提供标准化产品，软件供应商也将参与到主机厂的差异化竞争中去，因此易特驰也会针对主机厂的个性化需求提供定制化服务，为不同车型品牌提供差异化竞争的跨域应用工具，或者联合主机厂一起开发软件基础平台里所需要的技术及产品。

面对主机厂在研发整车操作系统过程中遇到的种种挑战，易特驰聚焦“效率、安全、生态”三大方面，为主机厂提供“快速跨域应用程序开发工具链”、“保障功能安全的Safety

Guard”等产品，并倡导发起EclipseSDV工作组，为“软件定义汽车”时代的汽车提供开源、免费的通用汽车软件。效率安全快速跨域应用程序开发工具链集中式安全并与应用逻辑解耦（SafetyGuard）倡导发起EclipseSDV工作组生态资料来源：ETAS、公开资料、亿欧智库192.4解决方案：ETAS（易特驰）提供用于软件定义汽车的端到端解决方案和工具生态系统

随着一批有能力的主机厂参与到域控制器的软件开发，软硬件分离的需求越来越大，为实现更快地开发、部署和更新软件解决方案，主机厂需要更全面的组件支持，包括软件包、工具链、平台组件、集成方法与工具等。同时，随着E/E架构逐渐转向中央计算架构，传统的分布式软件也需要进行重构和模块化。

因此，SDV行业早已形成共识，主机厂、供应商和第三方开发者合作实现共赢是汽车软件生态的主旋律。主机厂主导基于原子服务实现对整车服务、应用、体验等进行定义、组合、增强，构建OEM差异化竞争力应用软件开发与迭代软件供应商主导安全体系••定义符合行业生态的技术架构提供开发方法论和开发与调试工具链工具链API接口功能软件•提供整车基础运行环境、基础软件等中间件组件狭义操作系统虚拟机••针对应用开发接口能力针对不同芯片深度定制化适配与抽象能力硬件平台1硬件平台2...硬件平台n硬件供应商主导

ETAS（易特驰）作为博世旗下软件子公司既可以为主机厂提供端到端的全栈方案，也可以提供个性化、模块化的解决方案。2022年，博世将汽车通用基础软件，中间件和云服务以及开发工具业务纳入ETAS旗下，使得ETAS成功吸收整合了博世在通用基础软件领域的数十年的成功经验。

ETAS积极加入SDV生态圈，打造一体化产品。自2004年以来，ETAS一直是AUTOSAR开发合作伙伴关系的高级成员，通过全面的工具组合、基础和平台软件、用户软件开发咨询和服务，支持在软件开发过程中引入和利用AUTOSAR标准。ETAS解决方案旨在通过创新技术、开放式接口、访问所有工具功能以及基本软件来实现与AUTOSAR兼容的开发过程，从而在其他项目中重复使用成果。

值得关注的是，除了提供标准化产品，软件供应商也将参与到主机厂的差异化竞争中去，因此易特驰也会针对主机厂的个性化需求提供定制化服务，为不同车型品牌提供差异化竞争的跨域应用工具，或者联合主机厂一起开发软件基础平台里所需要的技术及产品。

面对主机厂在研发整车操作系统过程中遇到的种种挑战，易特驰聚焦“效率、安全、生态”三大方面，为主机厂提供“快速跨域应用程序开发工具链”、“保障功能安全的Safety

Guard”等产品，并倡导发起EclipseSDV工作组，为“软件定义汽车”时代的汽车提供开源、免费的通用汽车软件。效率安全快速跨域应用程序开发工具链集中式安全并与应用逻辑解耦（SafetyGuard）倡导发起EclipseSDV工作组生态资料来源：ETAS、公开资料、亿欧智库202.4解决方案：ETAS（易特驰）提供用于软件定义汽车的端到端解决方案和工具生态系统开发快速跨域应用程序开发工具链，兼顾开发效率、安全和生态建设能力

易特驰开发的云原生工具链，将互联网在云端开发的框架引入车端，兼顾了开发效率、安全和生态建设能力。其重点自研的包括跨域工具链、AUTOSAR、博世AOS中间件、车规级容器及安全类工具链，可实现不同安全等级OS系统的隔离。在安全性方面，所谓隔离，即将来整车应用开发过程当中所占用的计算资源会有单独的SOC、单独的Linux内核保障，而不是和实时域的传统汽车软件，包括核心驾乘功能进行算力竞争。

易特驰主要围绕DevOps提供一系列的工具链，让合作伙伴可以打通现在汽车软件开发的几十种工具链形成完整的无缝集成式开发环境，从而助力工程师高效开发迭代软件。此外，易特驰虚拟平台COSYM可以助力车企打造虚拟整车从而全面虚拟整车控制器、被控对象以及整车各种通讯网络。亿欧智库：易特驰ETAS提供的中间件组件和工具链示意图跨域应用车辆整车OS软件定义汽车API通用原子服务ETAS提供硬实时安全安全AD/ADAS云原生信息娱乐软实时应用软实时应用软实时应用通用QM功能IVI应用COEM或合作伙伴提供域功能整车数据和信号接口时间确定性中间件(跨ECU)ClassicAUTOSARAdaptiveAUTOSAR

数据确定性AOSAndroid第三方提供车规级容器LinuxRTA-CARQNXLinux核心服务跨域通讯层DDSorSOME/IP跨域工具链VSS,EclipseLeda&Velocitas,DevOps

未来的汽车软件开发模式会发生巨大的变化，汽车软件开发工程师可以通过安装SDK快速搭建开发环境和仿真环境。他们可以通过高级编程语言

Python来进行车辆应用开发，开发过程可以使用3D虚拟车型对应用进行模拟验证，实现类似智能手机的开发模式，开发者可以在PC上直接进行整车SOA层面的仿真式开发，从而大大提升开发效率，降低开发难度和成本。亿欧智库：易特驰ETAS的3D车辆应用开发和仿真环境使用python语言开发应用界面虚拟仿真环境下代码进行调试资料来源：ETAS、公开资料、亿欧智库212.4解决方案：ETAS（易特驰）提供用于软件定义汽车的端到端解决方案和工具生态系统ETAS的SafetyGuard模块可确保整车的功能安全

为解决智能汽车上层应用开发面临的功能安全问题，ETAS推出SafetyGuard安全守护模块，将安全逻辑从汽车应用程序开发中解耦出来，既保障了汽车软件开发中涉及到的跨域融合功能安全，亦符合软件开发的敏捷要求。

ETAS从整车的角度出发，将各类功能安全的核心控制和维护，收归保障操作系统层面，智能汽车软件开发者无需对主机厂功能安全的概念了解过深，只要关心面向消费者的业务逻辑即可，因此将来跨域应用开发会在QM域*中进行。以开发驻车座椅调整为例，假如司机换成另一个与车主身高不同的人，需要调整后视镜位置实现舒适驾车，这一行为要在驻车条件下操作才能保障车辆行驶安全。这时，SafetyGuard会启动安全模式，判定后视镜在调整过程中不允许司机挂档开车。其作用类似于一道防火墙，当部分上层应用要访问涉及功能安全部分，必须经过Safety

Guard控制，若判定该请求不满足功能安全要求，其将拒绝上层应用对相关设备或相关操作的调用，并切换到基本功能，以确保整车功能安全。亿欧智库：易特驰ETAS的SafetyGuard工作原理示意图车辆状态车辆应用车辆状态监控规则引擎执行器基础功能发起EclipseSDV工作组，与生态伙伴一起打造开源免费的通用汽车软件

一个开放的生态系统是“软件定义汽车”成功的关键，基于这样的考虑，2022年5月，ETAS作为助力实现软件定义汽车的车辆基础软件、中间件和开发工具的供应商，代表博世成为由

Eclipse

基金会发起的软件定义汽车新工作组的战略成员。该工作组是在

ETAS

GmbH及其母公司

Robert

BoschGmbH

的倡议下成立的，目标是为“软件定义汽车”时代的汽车提供开源、免费的通用汽车软件，即广义汽车操作系统，包括OS内核、中间件、云服务及开发工具。

过去，汽车行业的惯性思维往往是“Document

First”

，即由各个联盟先制定一系列标准规范，然后各家遵照规范实现自己的软件，从而实现彼此兼容。例如，AUTOSAR倡导“在标准上合作，在实现上竞争”，Code是各家基础软件供应商的核心竞争力，不能被公开。而Eclipse

SDV工作组遵循“CodeFirst”，参与开源社区的各方把自己已有或正在开发的软件源码贡献出来，无需先在联盟内达成普遍共识，以促进更敏捷、更快速的软件开发。

ETAS已向工作组贡献了许多项目。例如，EclipseVelocitas™项目提供端到端、可扩展、模块化和开源的开发工具链，用于创建容器化和非容器化车载应用程序；Eclipse

Leda项目提供系统映像“配方”，通过汇集来自SDV和更大的OSS社区的各个贡献者，在SDV的背景下提供基于Linux的功能映像/分发；EclipseKuksa项目提供车载软件组件，用于处理使用COVESAVSS数据模型建模的车载信号。未来博世和ETAS将持续贡献助力软件定义汽车发展的新项目。备注：ISO26262中有定义四种不同的ASIL：ASILA、ASILB、ASILC及ASILD。其中ASILD是产品最高的安全完整性，而ASIL

22A是最低的安全完整性。QM的含义是只要遵循标准的质量管理流程，无需额外的安全措施。行业标准助力构建开放、开源、多层解耦的立体生态体系我们认为必然需要构建“开放、开源、上云、多层解耦的立体生态体系”才可以最终实现操作系统持续的优秀体验与生命力。本章节从“应用生态”、“硬件生态”和“开发者生态”三个角度阐述构建丰富完善的操作系统生态的重要性。生态搭建离不开标准规范，市场上主流的汽车软件架构标准有AUTOSAR、COVESA等。两者都提高了软件的可拓展性和可复用性，使得生态伙伴可以聚焦在业务价值上，推动汽车软件更高效地发展。233.1生态定义操作系统

参考PC、手机的系统发展史，可以看到操作系统平台便是大树的根基，而丰富的应用及生态便是枝叶，两者相互依存、相互成就，好的生态会让树木枝繁叶茂呈现出不朽的生命力。而作为汽车操作系统产业，想要实现高质量发展，我们认为也必然需要构建“开放、开源、上云、多层解耦的立体生态体系”才可以最终实现系统持续的优秀体验与生命力。亿欧智库：开放、开源、上云、多层解耦的立体生态体系开放的软硬件平台可吸纳0204第三方参与。汽车操作系统需要成为各方开发者创新的战场，允许他们围绕不同层次的能力展开应用。云端协作的开发模式可以快速响应市场变化。与硬件解耦，让应用可以独立迭代，降低更新周期。开源多层解耦开放01上云03开源的协议和规范可以降低开发难度。开源避免再造轮子，节省研发成本，让生态圈中的开发者可以聚焦于创新应用。多层解耦的生态体系可以实现不同开发者参与不同层次。从底层驱动到上层应用，各司其职，共同组成完整生态。

生态中的应用软件、硬件、开发者形成良好的互动体系，通过技术共享和协同创新，共同提升整个生态圈的价值。

应用生态：丰富的应用生态可以从多方面激活整车价值，成为未来价值增长的关键点。应用生态不仅可以为整车操作系统提供高级功能和个性化体验，覆盖出行、安全、信息娱乐等多个场景，更重要的是它能形成良好的网络外部性，激发更多用户参与，从而推动整车操作系统不断改进和进步。应用带来的变革驱动力对于操作系统来说至关重要，因为这种变革驱动力最终会提高操作系统的功能、用户体验、安全性能等方面。因此构建丰富的应用生态对完善整车操作系统至关重要。亿欧智库：构建完善丰富的应用生态的重要性提供高级功能提供个性化的用户定制特定应用可以提供高级功能，比如语音交互、沉浸式体验、车载游戏等，扩展操作系统的基础功能。01不同的应用可以满足用户的个性化需求，提供用户差异化体验。020403推动进步和变革提供可更新的功能新的应用概念可以测试并改进操作系统，促使其不断进步和革新。应用可以不断更新，为操作系统提供不断变化的升级和新功能。资料来源：公开资料、亿欧智库243.1生态定义操作系统

硬件生态：应用软件的功能实现离不开完善的硬件基础，而丰富多样的硬件生态构成了这个基础，为操作系统提供演进的动力和空间。构建一个多元化的硬件生态可以帮助整车操作系统实现标准化、灵活性、安全性、可扩展性，同时减少对硬件供应商的限制。亿欧智库：构建完善丰富的硬件生态的重要性帮助实现标准化有助于降低成本不同硬件供应商构建在相同的标准和规范之上，帮助操作系统与硬件交互。标准化可以降低系统整体成本，多元化的供应链可以降低单个零部件的价格。01030204提高适配能力提供更多选择不同硬件可以测试和完善操作系统，提高其向后兼容性和适配新硬件的能力。多个硬件供应商可以提供更多选项，满足操作系统不同的需求。

开发者生态：丰富的应用是衡量操作系统影响力的最重要指标，而创造出丰富的应用的核心是打造繁荣的开发者生态。由于汽车用户体量和手机用户体量完全不在同一量级，车企单打独斗难以形成自己的庞大生态。根据Canalys数据，2023年Q1全球智能手机出货量为2.70亿部；根据IDC数据，2023年Q1，中国智能手机市场出货量约6,544万台。反观汽车行业，根据中汽协数据，2023年Q1中国乘用车销量513.8万辆，其中，智能电动汽车销量仅超过百万辆。单看销量规模就足以说明两者差异。

采用开放和开源的方式，构建优化的开发工具链，引入“云原生”，建立公开透明的合作机制，才能吸引和激发开发者的创新力量，不断为应用生态增加活力。开放、协作、共赢的开发者生态，将成为汽车操作系统生态体系持续繁荣并不断创新的重要源泉。亿欧智库：构建完善丰富的开发者生态的重要性开放性平台提供强大的技术支持引入“云原生”汽车操作系统需要提供更加开放和标准化的接口、协议及开发工具等，让第三方开发者能够更便捷高效地开发应用。未来软件开放方式将使用IT和互联网应用的开发工具链，引入大量的IT软件开发工程师。协作共享的生态机制多样化的开发者群体汇聚来自不同领域的开发者，利用互联网思维巧抓市场需求點，创造出市场需求。建立公开透明的游戏规则，保障开发者的合法权益，激励开发者效力生态共建。

丰富的应用生态激发用户需求、标准化的硬件生态适应需求变化、开放的开发者生态吸引创新力量，三者相互促进共同演进，形成一个开放、协作、迭代的生态发展机制。这样，整车操作系统才能长期维持优秀体验，满足用户个性化需求。资料来源：公开资料、亿欧智库253.2行业标准构建开放繁荣生态之AUTOSARAUTOSAR是目前应用范围最广的车载电子系统标准规范

2003年，宝马、博世、大陆、戴姆勒、通用、福特、标志雪铁龙、丰田、大众9家企业作为核心成员，成立了一个汽车开放系统架构（AutomotiveOpenSystemArchitecture）组织，简称AUTOSAR组织。AUTOSAR组织将提供统一的接口和协议，旨在实现应用软件和基础软件的解耦，为主机厂和供应商提供一个标准化的分层软件架构，为应用开发提供方法论层面的指导，以减少汽车软件设计的复杂度，提升软件的可拓展性和可复用性，节省底层软件的重复开发工作和开发成本，这样主机厂可以专注于开发具有差异性优势的应用软件。

AUTOSAR标准平台由于采用开放式架构和纵向分层、横向模块化架构，不仅提高了开发效率、降低开发成本，同时保障了车辆的安全性与一致性。截至目前，AUTOSAR组织已发布ClassicPlatform（CP）和AdaptivePlatform（AP）个平台规范，分别对应安全控制类和自动驾驶的高性能类。亿欧智库：ClassicPlatform与AdaptivePlatform的对比ClassicPlatformCAdaptivePlatformC++使用语言实时性硬实时软实时适用场景应用架构功能升级安全等级主要通信方式操作系统传统ECU（如ECM、VCU、BMS、MCU等）面向信号的架构自动驾驶、辅助驾驶、车联网面向服务的架构一般ECU开发后比较固定最高到ASILD可灵活在线升级最低ASILB（最高可到D）以太网CAN、LINAUTOSAROS（OSEKOS）POSIXOS（Linux、QNX等）

AUTOSAR组织发展至今，目前已有超过300家的整车、零部件、软件、硬件等领域的成员。欧洲主要车厂，如宝马、大众、戴姆勒等采用AUTOSARAP统一标准来构建SOA基础软件平台。但是，值得一提的是，虽然不少OEM基于AUTOSARAP进行开发，但是AUTOSAR

AP对SOA开发并不友好，存在以下问题：1）工具链不完善，使用复杂度高；2）资源消耗大，易占用实时域资源，影响安全；3）缺少灵活的API接口，应用开发难度大等问题。此外，AUTOSAR

AP目前标准不是很完善，标准每年在更新，因此，该标准其尚未获得行业普遍认可。目前，已经出现有头部主机厂和科技公司主导的新标准出现，得到越来越多的主机厂青睐。工具链不完善，使用复杂度高01资源消耗大，易占用实时域资依赖于AUTOSAR复杂的基础工具，源，影响安全缺少完善的SOA工具链，给开发人AUTOSARAPAUTOSARAP的部分功能需要在实在SOA开发中面

02临的问题员带来大量配置工作。时域中运行，例如控制汽车的刹车和加速等操作。如果AUTOSARAP缺少灵活的API接口，应用开发难度大占用了实时域资源，会影响实时性能，导致系统不能按时响应外部事件，从而影响汽车的安全性。03AUTOSARAP中的API接口大多是固定的，难以根据应用程序的需求进行灵活的调整和扩展，导致应用程序的开发难度增加。资料来源：AUTOSAR官网、CSDN、《AUTOSAR技术分析报告》、亿欧智库263.2行业标准构建开放繁荣生态之COVESACOVESA专注于开放标准与技术的发展，加速互联汽车系统的创新

COVESA(ConnectedVehicleSystems

Alliance，互联汽车系统联盟），前身是GENIVI联盟，是一个致力于推动互联汽车和智能出行领域发展的非营利组织。该组织的目标是促进互联汽车技术的全球标准化，推广互联汽车技术的应用和发展，并为互联汽车行业的各个领域提供支持和协作机会。

2021年，GENIVI更名为COVESA，专注于互联汽车开放标准与技术。GENIVI使用开源软件和社区开发的模式，加速车载操作系统面世时间。亿欧智库：COVESA的五大价值12345充分发挥网联汽车的潜力为跨行业协作和联网敞开大门非差异化技术和标准的通用方法跨越多个行业的公司、产品和服务的充满活力的生态系统开放式解决方案和可交付成果以加速行业应用

COVESA联盟顶级成员为宝马、博世，重要成员包括OEM如福特、现代等，汽车零部件制造厂商如电装、安波福等，芯片供应商如英伟达、NXP等，以及操作系统产业链的中间件、硬件和服务供应商。COVESA成员发起并促进各种合作项目，推动移动生态系统，并专注于加速互联汽车系统。亿欧智库：COVESA联盟成员单位OEMsTier1芯片供应商OSV,中间件,硬件&服务供应商资料来源：COVESA官网、公开资料、亿欧智库273.2行业标准构建开放繁荣生态之COVESA

过去，每个车辆电子系统都使用自己独立的信号描述方法和数据格式，导致不同的车辆电子系统之间无法直接通信和交互。这不仅使得车辆电子系统的开发和集成变得困难和复杂，也增加了车辆维护和诊断的难度。

为了解决这个问题，COVESA组织成员企业联合开发了VSS（Vehicle

Signal

Specification）规范。该规范提供一种标准化的车辆信号描述方法，包括车辆速度、发动机转速、车辆位置、车辆加速度、车门状态等等。这些信号可以用于诊断、车辆控制、车辆监控等应用。此外，VSS规范还提供了一些附加功能，如数据格式转换、数据筛选、数据采样等，以支持车辆电子系统的高效开发和集成。

VSS规范使得不同的车辆电子系统可以使用相同的信号定义和描述方法，实现互通性和互操作性，从而简化了车辆电子系统的开发和集成，提高了车辆维护和诊断的效率和准确性，从而最终节省时间和成本，使企业能够专注于创造商业价值和差异化解决方案。因此，VSS已