查看購物車
  • English
  • Japanese
  • Korean
封面
市場調查報告書
商品編碼
2109327

汽車AIOS市場（2026年）

Automotive AIOS Research Report, 2026
出版日期: | 出版商: ResearchInChina | 英文 590 Pages | 商品交期: 最快1-2個工作天內

價格
簡介目錄

汽車人工智慧作業系統研究：正在實施大規模生產解決方案。

大規模生產解決方案正在小規模實施。

2026年，AIOS開始小規模部署，協助提升駕駛座各項AI功能，並拓展應用場景。此外，部分旗艦車型搭載的AIOS，透過原子服務實現跨域編配，將其執行能力擴展至車身、底盤和自動駕駛等領域。

截至 2026 年 6 月，OEM 廠商仍採用兩種 AIOS 研發模式：「內部開發」與「半外包」。

全端內部開發－蔚來汽車和理想汽車等新興汽車製造商正在將人工智慧功能深度整合到中間件層（甚至核心層），形成從晶片到應用程式的全端閉合迴路。

半外包－傳統汽車製造商建構自己的大規模、垂直整合的模型以及AIOS框架，在最低層重複使用供應商的基礎軟體。

供應商面向汽車產業的量產AIOS解決方案部署模式包括以下幾種：

主流做法是將人工智慧應用從駕駛座向下擴展到作業系統底層。例如，華為透過鴻蒙空間提供與鴻蒙作業系統相關的服務。

與晶片/硬體廠商合作－支援多家晶片廠商的解決方案，並促進軟硬體的整合。典型案例包括商湯科技的「Sage Box」（適用於SageOS）和雷電科技的「AI Box-N1」（適用於AquaDrive OS），它們與AI Box協同建構了全面的裝置端AI解決方案。

與雲端供應商合作－以 Extour Technology 為例，他們與 Volcano Engine 的雲端基礎架構合作，呼叫豆寶大型模式並提供 AI 服務。

與 2025 年相比，2026 年作業系統跨域呼叫服務將更加成熟。

以東風天元操作系統為例，其整體架構實現了車身、動力傳動系統、底盤、溫度控管和閘道器五大領域的整合。基於「太極」式大規模模型，它呼叫了超過2000個原子服務，並透過服務導向的架構支援功能的快速組合和靈活呼叫。

在AIOS的實現過程中，支撐駕駛座軟體系統跨域調用的軟體基礎仍然是汽車作業系統。以汽車作業系統為基礎，可以實現與安全無關的駕駛座功能的原子分解。隨後，由AI中間件處理的智慧汽車調度演算法，能夠動態分配和智慧調度駕駛座內的運算能力、應用程式和周邊資源。當使用者發出指令時，語音助理會分解使用者的意圖，協調多個AI框架，最終呼叫對應的原子服務。整個過程構成了AIOS的基本工作流程。

到2026年，原子函數介面的數量將激增（主流旗艦機型通常配備超過500個原子函數）。隨著客製化駕駛座場景日益普及，AIOS的競爭優勢正逐漸從「原子函數的數量」轉向「原子函數組合的便利性」。客製化和標準化的介面協議對於實現「便捷組合」至關重要。

在最大限度地發揮AIOS效能方面面臨的技術挑戰包括以下幾點：

在服務導向的架構 (SOA) 環境中，缺乏標準化的統一協定常常會阻礙原子函數的有效性。目前，函數呼叫 (Function Call) 是主流協議，而模型控制協議 (MCP) 仍處於實驗階段。這是因為函數呼叫滿足核心需求，並且易於在小規模生產環境中維護。然而，當需要進行大規模解決方案遷移時，在函數呼叫之外封裝一個 MCP 伺服器可以帶來「模型間可移植性」和「動態工具發現」的優勢。

MCP協議的意義在於其標準化，這使得跨場景功能的開發週期從數月縮短至數週。汽車製造商可以像建造積木一樣快速組裝個人化駕駛座服務。典型的例子包括Extour Technology的汽車MCP-Agent框架和SenseAuto的邊緣原生代理框架，它們都支援MCP/A2A協定。

例如，SenseAuto發布了一個支援MCP/A2A協定的邊緣原生代理框架。該公司正在建立一個標準化的「代理-工具」整合框架，該框架允許多個代理透過統一的MCP協定層高效地整合各種車載工具，例如播放器、空調和知識庫。這解決了代理開發過程中從多個來源呼叫工具、檢索資料和整合資訊的難題。

其優點如下：

降低成本和提高效率：統一的協議消除了工具對接中的碎片化障礙，顯著降低了開發和整合成本，並實現了所有類型工具的「即插即用」。

開放生態系統：支援標準化的生態系統存取機制，促進第三方服務和硬體快速整合到智慧汽車系統中，並促進多樣化生態系統的形成。

可控安全：統一的安全認證策略和集中管理簡化了流程，同時增強了系統安全性。

下一階段：從人工智慧主導過渡到人工智慧原生。

華為和東軟等供應商將人工智慧與作業系統的整合分為以下三個階段：

到2025年，大多數OEM廠商和供應商都將透過將AI框架整合到中間件層來建構AI作業系統。例如，小鵬汽車採用了跨域統一協議中間件+設備端大模型+原子服務；長城汽車在其中間件層採用了基於多模型的代理管理和運維框架；東軟瑞馳在NeuSAR操作系統上採用了NeuSAR AI框架（該框架能夠將AI應用快速部署到車輛上）。

到2026年，新興的主要OEM廠商和供應商將開始部署「AI增強核心」，著手在核心層建立原生AI作業系統。例如，蔚來汽車正在利用AI技術提昇作業系統核心根據場景動態調度資源的能力。華為的鴻蒙作業系統核心也原生支援多模態理解和個人化資料理解。

此外，隨著代理技術的引入和高性能晶片的升級，AIOS 架構也從應用層到底層發生了變化。

例如，蔚來汽車的全新SkyOS作業系統將AI功能深度整合到作業系統底層，徹底革新了傳統的架構範式。這實現了高效的終端雲端整合、異質運算資源的智慧調度以及多智慧體協作，同時提升了系統的響應速度、穩定性、數據吞吐量和電池續航力。其創新之處在於增強了核心根據場景動態調度資源的能力，包括CPU（進程和執行緒優先權排序）、記憶體管理（分配和重複使用）以及設備共用。即使在高負載場景下，也能提升系統的穩定性和反應速度。

華為千鈞作業系統擁有安全隔離引擎、AI原生核心、統一匯流排、加速引擎和畢生編譯器，可為高層ADS演算法提供確定性的低延遲和快速回應。雖然基於鴻蒙作業系統內核，但其內核已針對汽車應用進行了深度客製化和重構，成為AI原生內核，實現了車輛、道路、雲端和智慧型手機之間的無縫整合。

目錄

第1章：車載AIOS的現況與發展趨勢

  • AIOS的目前狀態
  • 從車載作業系統到車載AIOS
  • 車輛作業系統與人工智慧作業系統之間的關係
  • 汽車作業系統中人工智慧應用概述
  • AIOS供應商佈局圖
  • AIOS OEM配置
  • AIOS架構與技術分析
  • AIOS架構：部署結構
  • AIOS架構：各層的功能特性
  • AIOS架構：AI工具鏈
  • AIOS技術：實作中的技術特性
  • AIOS技術：技術框架與功能
  • AIOS技術：車輛抽象
  • AIOS技術：基於車輛的抽象
  • AIOS技術：多模態融合
  • AIOS技術：安全機制
  • AIOS技術：挑戰與解決方案
  • AIOS技術：挑戰與解決方案
  • AIOS發展趨勢
  • 趨勢：AIOS進入小規模量產階段
  • 趨勢：AIOS 正從 AI主導階段轉向 AI 原生階段。
  • 展望：人工智慧原生作業系統所需的特性
  • 展望：混合內核解決方案產生的AIOS
  • 前沿AIOS技術分析
  • 如何建構LLM作業系統
  • AIOS架構：核心模組的關鍵元件和功能
  • AIOS架構：核心模組的關鍵元件和功能
  • AIOS架構：並行操作期間的AIOS吞吐量和延遲
  • AIOS架構：在並行操作期間保持AIOS效能
  • AIOS架構：AIOS模型部署與任務工作流程
  • AIOS架構：不同AI執行時間的比較
  • 基於AIOS的框架：LSFS函數

第2章 車輛作業系統與基礎作業系統

  • 定義和發展歷史
  • 汽車作業系統
  • 作業系統發展史
  • 車輛作業系統：定義
  • 軟體層架構
  • 車輛操作系統特性
  • 車輛作業系統開發模型的演進：基於汽車架構
  • 車輛作業系統開發模式的演進：基於研發模式
  • 車輛操作系統經營模式的演變
  • 各汽車製造商車輛作業系統概述
  • 車輛作業系統中的跨域調用：演算法調用
  • 汽車作業系統發展趨勢
  • 趨勢：開放原始碼生態系統對競爭格局的影響
  • 趨勢：開放原始碼生態系統對軟體經營模式的影響
  • 趨勢：OEM廠商的作業系統佈局模式
  • 趨勢：供應商車輛作業系統佈局模式
  • 趨勢：汽車製造商專有的車輛操作系統－優勢與劣勢
  • 趨勢：OEM廠商自主研發的車輛操作系統－決策流程
  • 趨勢：OEM廠商自主研發的汽車作業系統－分階段發展。
  • 趨勢：OEM廠商自主研發的車輛操作系統－更高層的應用生態系統
  • 趨勢：OEM廠商自主開發的車輛作業系統中介軟體
  • 趨勢：OEM廠商自主開發的車輛作業系統 - 通訊中間件
  • 趨勢：OEM廠商自主研發的車輛操作系統－成本管理
  • 各汽車製造商自主研發的汽車作業系統面臨的主要競爭因素
  • 汽車作業系統分類
  • 汽車作業系統的分類：狹義上的汽車作業系統和廣義的汽車作業系統
  • 汽車作業系統分類：即時汽車作業系統與非即時汽車作業系統
  • 即時作業系統供應商及產品列表
  • 除即時作業系統 (RTOS) 以外的其他供應商和產品列表
  • 汽車作業系統分類：微內核、巨集內核、混合內核
  • 汽車作業系統分類：車輛控制作業系統與車輛作業系統
  • 汽車作業系統市場規模預測
  • 軟體架構
  • 廣義的通用作業系統架構
  • 智慧車輛軟體生態系統框架
  • 核心是汽車軟體架構的核心。
  • 經營模式
  • 汽車作業系統的經營模式類型
  • 主要汽車作業系統公司的經營模式
  • 探索汽車作業系統的發展趨勢和經營模式
  • 汽車產業的基本作業系統和經營模式
  • 汽車即時作業系統和經營模式
  • 供應商作業系統經營模式
  • 汽車電子設備標準：AUTOSAR
  • AUTOSAR概述
  • AUTOSAR 分類
  • 核心成員
  • 經典 AUTOSAR：架構
  • 經典 AUTOSAR：功能
  • 自適應 AUTOSAR：框架
  • 傳統AUTOSAR與自適應AUTOSAR的比較
  • 自適應 AUTOSAR 和 ROS 整合應用
  • AUTOSAR 亮點
  • AUTOSAR中國工作小組架構
  • 來自 AUTOSAR 中國工作小組的專案範例
  • AUTOSAR相關軟體工具供應商的經營模式
  • Vector的AUTOSAR解決經營模式
  • EB的AUTOSAR解決經營模式
  • 東軟瑞馳的AUTOSAR解決方案經營模式
  • iSOFT基礎架構軟體的AUTOSAR解決方案經營模式
  • 景偉海蘭的AUTOSAR解決方案商業模式
  • 中介軟體佈局
  • 主要OEM廠商（小鵬汽車、蔚來汽車、理想汽車等）核心作業系統中介軟體組件對比
  • 主要供應商（華為、ThunderSoft、ArcherMind 等）核心作業系統中介軟體組件對比
  • BlackBerry
  • QNX在汽車產業的發展過程
  • QNX 商業
  • QNX產品：安全等級
  • QNX產品：即時作業系統（RTOS）的特性
  • QNX 產品：即時作業系統架構
  • QNX產品：駕駛座軟體平台解決方案（SDP8.0）
  • QNX產品：ADAS平台
  • QNX產品：駕駛座整合控制器
  • QNX產品：QNX雲端模擬平台
  • QNX產品：網域控制站基礎軟體平台
  • QNX 安全作業系統：產品概述
  • QNX作業系統安全性：安全效能比較
  • QNX在機器人領域的應用
  • QNX 合作夥伴
  • QNX 的最新趨勢
  • Linux 和 AGL
  • AGL成員
  • Linux架構
  • RT-Linux
  • Linux 基金會的 AI開放原始碼項目
  • AGL應用框架：UCB
  • Android
  • Android 與 Android Automotive OS 概述
  • Android Automotive OS 架構
  • Android Automotive OS 功能
  • Android Auto 已引進人工智慧功能。
  • 放慢AOSP更新速度的影響
  • 使用者開發狀態
  • Huawei
  • HarmonyOS簡介
  • HarmonyOS 開發歷史
  • HarmonyOS技術架構：未來發展方向
  • HarmonyOS 汽車製造商之間的協作模式
  • 智慧駕駛作業系統 - AOS
  • 智慧型車輛控制系統-VOS
  • 跨域整合軟體框架車輛棧
  • iDVP平台升級
  • Qiankun OS 符合 AI+SOA 賦能的自動駕駛汽車的要求。
  • 千坤作業系統融合了世界模式。
  • CCA：VCU（中央計算單元）+ 3-5 VIU（ZCU）
  • CCA：系統框架和全端解決方案
  • HarmonyOS AI 功能
  • HarmonyOS 中「所見即所得」的兩種實作模式
  • Alibaba
  • AliOS簡介
  • 板馬智信的車輛作業系統演進戰略
  • AliOS作業系統架構
  • AliOS 應用層
  • 阿里巴巴群文大規模模型與作業系統整合：系統代理系統
  • 阿里巴巴群文大規模模型與作業系統整合：Yan AI系列
  • AliOS解決方案：AliOS智慧駕駛座作業系統
  • AliOS Drive 智慧駕駛作業系統
  • 斑馬智行作業系統經營模式
  • Banma虛擬機器管理程式讓升級變得輕鬆
  • 來自 AliOS 的最新進展
  • VxWorks
  • Wind River VxWorks 微核心架構
  • WindRiver 產品：WindRiver Linux 和 WindRiver AUTOSAR 自適應軟體平台
  • WindRiver 產品：Helix 虛擬化平台
  • WindRiver 的新型 RTOS 產品
  • 汽車產業的最新趨勢
  • Ubuntu
  • 輪廓
  • 應用
  • 汽車業的合作
  • webOS
  • 發展歷程
  • webOS OSE 元件和開發藍圖
  • webOS 和 AGL 整合
  • 汽車產業的最新趨勢
  • ROS
  • ROS簡介
  • ROS 2.0簡介
  • ROS 2.0 迭代歷史
  • ROS 2 與其他中介軟體的區別
  • ROS 2.0架構
  • ROS應用範例

第3章：AIOS供應商

  • Neusoft Reach
  • NeuSAR aCore
  • ThunderSoft
  • ArcherMind Technology
  • SenseTime
  • Kernelsoft
  • Linux
  • SYNCORE AUTOTECH
  • Extour Technology
  • STEP
  • 其他

第4章：車輛作業系統供應商

第5章：中國OEM廠商的作業系統

  • Li Auto
  • NIO
  • Xpeng
  • Xiaomi
  • Leapmotor
  • Geely
  • SAIC Motor
  • Great Wall Motor
  • FAW Hongqi
  • GAC Group
  • Changan
  • Dongfeng Motor
  • BYD
  • Chery

第6章 海外OEM廠商的作業系統

  • BMW
  • Mercedes-Benz
  • Volkswagen
  • Toyota
  • Honda
簡介目錄
Product Code: GX024

Automotive AIOS Research: Mass Production Solutions Are Implemented

Mass Production Solutions Are Implemented on A Small Scale.

In 2026, AIOS starts small-scale implementation, helping to improve various cockpit AI functions and enable more comprehensive application scenarios. In addition, the AIOS of some mainstream flagship vehicle models realizes cross-domain orchestration capabilities through atomic services, expanding execution capabilities to body, chassis, intelligent driving and other domains.

As of June 2026, OEMs have still adopted two AIOS R&D models: self-development and semi-outsourcing:

Full-stack self-development: Emerging automakers led by NIO and Li Auto deeply integrate AI capabilities into the middleware layer (even kernel layer), forming a full-stack closed loop from chip to application.

Semi-outsourcing: Traditional OEMs independently build the vertical large model + AIOS framework, reusing basic software from suppliers at the bottom layer.

The in-vehicle deployment modes of mass-produced AIOS solutions of suppliers include the following:

Extending from cockpit AI applications to the bottom layer of OS: the mainstream approach. For example, Huawei provides HarmonyOS-related services via HarmonySpace.

Binding with chip/hardware manufacturers: Adapt to chip solutions of multiple chip manufacturers for software-hardware collaboration. Typical examples include Sage Box for SenseTime SageOS and AI Box-N1 for ThunderSoft AquaDrive OS, which build comprehensive on-device AI solutions coordinated with AI Box.

Binding with cloud providers: Represented by Extour Technology, bind with Volcano Engine's cloud base and invokes Doubao Large Model to provide AI services.

Compared with 2025, cross-domain invocation services of OS became more mature in 2026.

In the case of Dongfeng Tianyuan OS, the entire architecture realizes integration across five domains: body, powertrain, chassis, thermal management and gateway. Based on the Taichi Large Model base, it invokes more than 2,000 atomic services and supports rapid combination and flexible invocation of functions via service-oriented architecture.

In the process of AIOS deployment, the software foundation for cross-domain invocation of cockpit software system is still the vehicle OS. Based on the vehicle OS, non-safety cockpit functions can be disassembled atomically. Then, automotive intelligent scheduling algorithms carried by AI middleware realize dynamic allocation and intelligent scheduling of computing power, applications and peripheral resources in the cockpit. When the user issues an instruction, the voice assistant disassembles intentions, coordinates multiple AI frameworks to work, and finally invokes atomic services. This entire process is the basic workflow of the AIOS.

In 2026, the number of interfaces for atomic capabilities surged (mainstream flagship vehicle models generally have more than 500 atomic capabilities). Against the backdrop of increasingly popular customized cockpit scenarios, the competitive edges of AIOS have gradually shifted from "more atomic capabilities" to "easier combination of atomic capabilities". Protocols for customized and standardized interfaces are critical on the issue of "whether to combine more easily".

Some of the engineering challenges involved in highlighting the effects of AIOS are as follows:

The lack of standardized unified protocols makes it very easy to hinder the effectiveness of atomic capabilities under SOA. At present, Function Call is the mainstream protocol adopted, while MCP is still in the trial stage. The reason is that Function Call can meet core requirements and is easy to maintenance under small-scale mass production conditions. However, when large-scale migration of solutions is required, wrapping MCP Server outside Function Call demonstrates advantages of "cross-model portability" and "dynamic tool discovery".

The significance of the MCP protocol lies in standardization, compressing the development cycle of cross-scenario functions from months to weeks. Automakers can quickly combine personalized cockpit services like building blocks. Typical cases include Extour Technology's automotive MCP-Agent framework and SenseAuto's edge native agent framework supporting MCP/A2A protocols.

For example, SenseAuto launched an edge native agent framework supporting MCP/A2A protocols. It builds a standardized "Agent-Tool" integration framework, allowing multiple agents to efficiently integrate various vehicle tools such as players, air conditioners and knowledge bases through a unified MCP protocol layer, solving difficulties in tool invocation, data acquisition and multi-source information integration during agent development.

Its advantages include:

Cost reduction and efficiency improvement: The unified protocol eliminates fragmentation barriers for tool docking, greatly cutting development and collaboration costs and enabling all types of tools to be "plug-and-play".

Open ecosystem: Supports a standardized ecosystem access mechanism, facilitating rapid integration of third-party services and hardware into intelligent vehicle systems, and promoting diversified ecosystems.

Controllable security: Unified security authentication policies and centralized management simplify processes while strengthening system security.

Next Stage: Shift from AI-Driven to AI-Native

Suppliers including Huawei and Neusoft divide the integration of AI and OS into three stages:

In 2025, most OEMs and suppliers built AI operating systems by deploying the AI framework at the middleware layer. Examples include XPeng's deployment of cross-domain unified protocol middleware + on-device large model + atomic services, Great Wall Motor's deployment of multi-model base and Agent management/operation framework at the middleware layer, and Neusoft Reach's deployment of NeuSAR AI Framework on NeuSAR OS for rapid introduction of AI applications into vehicles.

In 2026, leading emerging OEMs and suppliers start deploying "AI-enhanced kernels" to build kernel-layer native AIOS. For instance, NIO leverages AI to improve the OS kernel's ability to dynamically schedule resources according to scenarios; Huawei HarmonyOS kernel natively supports multi-modal understanding and personalized data understanding.

In addition, with the deployment of agent technology and upgrading of high-compute chips, the AIOS architecture has also undergone changes from the application layer to the bottom layer.

For example, NIO's new SkyOS deeply integrates AI capabilities into the bottom layer of the operating system, replacing the traditional architectural paradigm. It realizes efficient end-cloud integrated collaboration, intelligent scheduling of heterogeneous computing power, and multi-agent collaboration, while improving system response speed, stability, data throughput and battery life. Its innovation lies in enhancing the kernel's ability to dynamically schedule resources according to scenarios, including CPU (process and thread priority), memory management (allocation and recycling) and device sharing. It can boost system stability and response speed in high-load scenarios.

In the case of Huawei Qiankun OS, it contains a security isolation engine, AI-native kernel, UnifiedBus, acceleration engine and Bisheng Compiler, providing deterministic low-latency rapid response for upper-layer ADS algorithms. Its kernel is based on HarmonyOS kernel but deeply tailored and reconstructed for automotive scenarios to become an AI-native kernel, and can realize seamless flow of "vehicle-road-cloud-mobile phone".

Table of Contents

1 Status Quo and Development Trends of Automotive AIOS

  • 1.1 Status Quo of AIOS
  • From Vehicle OS to Vehicle AIOS (1)
  • From Vehicle OS to Vehicle AIOS (2)
  • From Vehicle OS to Vehicle AIOS (3)
  • Relationship between Vehicle OS and AIOS
  • Overview of AI Application in Automotive OS (1)
  • Overview of AI Application in Automotive OS (2)
  • Overview of AI Application in Automotive OS (3)
  • AIOS Layout of Suppliers (1)
  • AIOS Layout of Suppliers (2)
  • AIOS Layout of OEMs (1)
  • AIOS Layout of OEMs (2)
  • 1.2 AIOS Architecture and Technical Analysis
  • AIOS Architecture (1): Deployment Structure
  • AIOS Architecture (1): Functional Characteristics of Different Layers
  • AIOS Architecture (1): AI Toolchain
  • AIOS Technologies (2): Technical Features in Deployment
  • AIOS Technologies (2): Technical Framework and Functions
  • AIOS Technologies (2): Vehicle Abstraction
  • AIOS Technologies (2): Vehicle Base Abstraction
  • AIOS Technologies (2): Multi-Modal Fusion
  • AIOS Technologies (2): Security Mechanisms
  • AIOS Technologies (2): Challenges and Solutions
  • AIOS Technologies (2): Challenges and Countermeasures
  • 1.3 Development Trends of AIOS
  • Trend 1: AIOS Enters Small-Scale Mass Production Stage
  • Trend 2:
  • Trend 3:
  • Trend 4:
  • Trend 5: AIOS Moves from AI-Driven Stage to AI-Native Stage
  • Trend 5: Case 1
  • Trend 5: Case 2
  • Outlook (1): Required Characteristics of AI-Native OS
  • Outlook (2): AIOS Generated by Hybrid Kernel Solutions
  • 1.4 Technical Analysis of Cutting-Edge AIOS
  • Construction Methods of LLM OS
  • AIOS Architecture: Main Components and Functions of Kernel Module (1)
  • AIOS Architecture: Main Components and Functions of Kernel Module (2)
  • AIOS Architecture: Main Components and Functions of Kernel Module (17)
  • AIOS Architecture: Throughput and Latency of AIOS under Parallel Operation
  • AIOS Architecture: Performance Maintenance of AIOS under Parallel Operation
  • AIOS Architecture: Model Deployment and Task Workflow of AIOS
  • AIOS Architecture: Comparison between Different AI Runtimes
  • AIOS-derived Framework: LSFS Functions (1)
  • AIOS-derived Framework: LSFS Functions (2)
  • AIOS-derived Framework: LSFS Functions (6)

2 Vehicle OS and Basic Operating Systems

  • 2.1 Definitions and Development History
  • Automotive Operating Systems
  • Development History of Operating Systems
  • Vehicle OS: Definition
  • Software Layer Architecture
  • Characteristics of Vehicle OS
  • Evolution of Vehicle OS Development Models: By Automotive Architecture
  • Evolution of Vehicle OS Development Models: By R&D Model
  • Evolution of Vehicle OS Business Models
  • Summary of OEMs' Vehicle OS (1)
  • Summary of OEMs' Vehicle OS (2)
  • Summary of OEMs' Vehicle OS (8)
  • Vehicle OS Cross-domain Invocation: Algorithm Invocation
  • 2.2 Development Trends of Automotive Operating Systems
  • Trend 1:
  • Trend 2: Impacts of Open-Source Ecosystem on Competitive Landscape
  • Trend 2: Impacts of Open-Source Ecosystem on Software Business Models
  • Trend 3: OEMs' Operating System Layout Modes
  • Trend 3: Suppliers' Vehicle OS Layout Modes (1)
  • Trend 3: Suppliers' Vehicle OS Layout Modes (2)
  • Trend 4: OEMs' Self-Developed Vehicle OS - Advantages and Disadvantages
  • Trend 4: OEMs' Self-Developed Vehicle OS - Decision-Making Process
  • Trend 4: OEMs' Self-Developed Vehicle OS - Gradient Status
  • Trend 4: OEMs' Self-Developed Vehicle OS - Upper-Layer Application Ecosystem
  • Trend 4: OEMs' Self-Developed Vehicle OS - Middleware
  • Trend 4: OEMs' Self-Developed Vehicle OS - Communication Middleware
  • Trend 4: OEMs' Self-Developed Vehicle OS - Cost Control
  • Core Competitive Factors of OEMs' Self-Developed Vehicle OS
  • 2.3 Classification of Automotive Operating Systems
  • Classification of Automotive Operating Systems: Narrow-Sense and Broad-Sense Automotive OS
  • Classification of Automotive Operating Systems: Real-Time and Non-Real-Time Automotive OS
  • List of RTOS Suppliers and Products (1)
  • List of RTOS Suppliers and Products (2)
  • List of RTOS Suppliers and Products (3)
  • List of Non-RTOS Suppliers and Products (1)
  • List of Non-RTOS Suppliers and Products (2)
  • Classification of Automotive Operating Systems: Microkernel, Macro Kernel, Hybrid Kernel
  • Classification of Automotive Operating Systems: Vehicle Control OS and Vehicle OS
  • Automotive Operating System Market Size Forecast
  • 2.4 Software Architecture
  • Typical Broad-Sense OS Architecture
  • Intelligent Vehicle Software Ecosystem Framework
  • Kernel Is the Core of Automotive Software Architecture
  • 2.5 Business Models
  • Types of Automotive Operating System Business Models
  • Business Models of Major Automotive OS Companies
  • Development Trends and Business Model Exploration of Automotive Operating Systems
  • Basic Automotive Operating System and Business Models
  • Automotive RTOS and Business Models (1)
  • Automotive RTOS and Business Models (2)
  • Operating System Business Models of Suppliers (1)
  • Operating System Business Models of Suppliers (2)
  • Operating System Business Models of Suppliers (3)
  • Operating System Business Models of Suppliers (4)
  • 2.6 Automotive Electronic Standards: AUTOSAR
  • Profile of AUTOSAR
  • AUTOSAR Classification
  • Core Members
  • Classic AUTOSAR: Architecture
  • Classic AUTOSAR: Functions
  • Adaptive AUTOSAR: Framework
  • Comparison between Classic AUTOSAR and Adaptive AUTOSAR
  • Integrated Application of Adaptive AUTOSAR and ROS
  • Highlights of AUTOSAR
  • Architecture of AUTOSAR China Working Group
  • AUTOSAR China Working Group Project Cases
  • Business Models of AUTOSAR-Related Software Tool Suppliers (1)
  • Business Models of AUTOSAR-Related Software Tool Suppliers (2)
  • Business Models of AUTOSAR-Related Software Tool Suppliers (7)
  • Vector's AUTOSAR Solution Business Model
  • EB's AUTOSAR Solution Business Model
  • Neusoft Reach's AUTOSAR Solution Business Model
  • iSOFT Infrastructure Software's AUTOSAR Solution Business Model
  • Jingwei Hirain's AUTOSAR Solution Business Model
  • 2.7 Middleware Layout
  • Comparison of Core OS Middleware Components between Major OEMs: XPeng, NIO, Li Auto, etc.
  • Comparison of Core OS Middleware Components between Major Suppliers: Huawei, ThunderSoft, ArcherMind, etc.
  • 2.8 BlackBerry
  • Development History of QNX in Automotive Field
  • QNX Business
  • QNX Products: Safety Levels
  • QNX Products: Features of RTOS
  • QNX Products: RTOS Architecture
  • QNX Products: Cockpit Software Platform Solution (SDP8.0)
  • QNX Products: ADAS Platform
  • QNX Products: Cockpit-Driving Integrated Controller
  • QNX Products: QNX Cloud Simulation Platform
  • QNX Products: Domain Controller Basic Software Platform
  • QNX OS for Safety: Product Overview
  • QNX OS for Safety: Safety Performance Comparison
  • QNX Application in Robotics
  • QNX Partners
  • Latest Dynamics of QNX
  • 2.9 Linux & AGL
  • AGL Members
  • Linux Architecture
  • RT-Linux
  • Linux Foundation AI Open-Source Projects
  • AGL Application Framework: UCB
  • 2.10 Android
  • Introduction to Android & Android Automotive OS
  • Android Automotive OS Architecture (1)
  • Android Automotive OS Architecture (2)
  • Features of Android Automotive OS
  • AI Functions Introduced to Android Auto
  • Impacts of Slowing AOSP Update Pace
  • User Development Status
  • 2.11 Huawei
  • Introduction to HarmonyOS
  • Development History of HarmonyOS
  • Technical Architecture of HarmonyOS
  • HarmonyOS Technical Architecture: Future Development Directions
  • Cooperation Models between HarmonyOS and Automakers
  • Intelligent Driving OS - AOS
  • Intelligent Vehicle Control OS - VOS
  • Cross-Domain Integrated Software Framework Vehicle Stack
  • Upgrade of iDVP Platform
  • Qiankun OS Meeting Requirements of AI+SOA Enabled Autonomous Vehicles
  • Qiankun OS Integrates World Model
  • CCA: VCU (Central Computing) + 3-5 VIUs (ZCUs)
  • CCA: System Framework and Full-Stack Solution
  • AI Functions of HarmonyOS
  • Two Implementation Modes of "See and Speak" on HarmonyOS
  • 2.12 Alibaba
  • Introduction to AliOS
  • Banma Zhixing's Vehicle OS Evolution Strategy
  • AliOS Operating System Architecture
  • AliOS Application Layer
  • Integration of Alibaba Qwen Large Model and OS: System Agent System
  • Integration of Alibaba Qwen Large Model and OS: Yan AI Series
  • AliOS Solution: AliOS Intelligent Cockpit OS
  • AliOS Drive Intelligent Driving OS
  • Banma Zhixing's OS Business Model
  • Banma Hypervisor Facilitates Upgrade
  • Latest Dynamics of AliOS
  • 2.13 VxWorks
  • Introduction to VxWorks
  • Wind River VxWorks Microkernel Architecture (1)
  • Wind River VxWorks Microkernel Architecture (2)
  • WindRiver Products: WindRiver Linux and WindRiver AUTOSAR Adaptive Software Platform
  • WindRiver Products: Helix Virtualization Platform
  • New RTOS Products of WindRiver
  • Latest Dynamics in Automotive Field
  • 2.14 Ubuntu
  • Profile
  • Application
  • Cooperation in Automotive Field
  • 2.15 webOS
  • Development History
  • webOS OSE Components and Development Roadmap
  • Integration of webOS and AGL
  • Latest Dynamics in Automotive Field
  • 2.16 ROS
  • Introduction to ROS
  • Introduction to ROS 2.0
  • Iteration History of ROS 2.0
  • Differences between ROS 2 and Other Middleware
  • ROS 2.0 Architecture
  • ROS Application Cases

3 AIOS Suppliers

  • 3.1 Neusoft Reach
  • Evolution of NeuSAR
  • Introduction to NeuSAR
  • Three Stages of AIOS
  • AI Deployment of Vehicle Intelligent OS
  • Four Layers of NeuSAR OS Architecture
  • NeuSAR SF (Service Framework) Middleware
  • NeuSAR AI Framework Middleware Products
  • NeuSAR Copilot Facilitates Efficient AUTOSAR Development
  • NeuSAR OS Completed Adaptation to DeepSeek
  • NeuSAR aCore
  • Upgrade of AUTOSAR AP Products
  • NeuSAR cCore
  • Lightweight AUTOSAR CP Products
  • NeuSAR OS Cooperation: Infineon
  • NeuSAR OS Cooperation: NXP
  • Intelligent Driving OS
  • 3.2 ThunderSoft
  • AquaDrive OS Vehicle OS
  • Integration of Rubik Foundation Model and Operating System
  • AquaDrive AIOS Application Architecture
  • AquaDrive AIOS Deployment Architecture
  • How AquaDrive OS Supports Implementation of AI Scenarios
  • Upgrade of AquaDrive AI OS: Addition of AquaClaw Automotive Agent
  • 3.3 ArcherMind Technology
  • Development History of AIOS Products
  • Arraymo AIOS Base
  • Cross-Domain Vehicle OS: FusionOS 1.0
  • Cross-Domain Vehicle OS: FusionOS 2.0
  • Vehicle OS: FusionOS 4.0 AIOS
  • Firefly AIOS
  • Products Supported by AIOS
  • 3.4 SenseTime
  • SenseAuto Qianji AIOS Kernel
  • Edge AI Solution Based on Edge Model and AIOS
  • 3.5 Kotei Informatics
  • Evolution of AIOS and Middleware Product Layout
  • A2OS System
  • Three Versions of A2OS
  • 3.6 Kernelsoft
  • AI-Oriented OS Solution
  • Real-Time Operating System
  • Linux
  • Operating System Security
  • 3.7 SYNCORE AUTOTECH
  • Mass Production of AIOS
  • Upgrade of Overseas Version of OS
  • Cockpit AI OS Solution Enables "Proactivity" and "Symbiosis"
  • Underlying Operation Mechanism of AIOS
  • 3.8 Extour Technology
  • Cockpit AI Solution Based on AIOS
  • MCP-Agent Framework Buids System Expansion Base for AIOS
  • Underlying Architecture of Xinjie AI System
  • Typical Functions of AI System
  • 3.9 STEP
  • Upgrade of AI-Native Cross-Domain Fusion Operating System
  • AI-Native OS: Accelerate Intelligent Driving Project Development
  • AI-Native OS: Advantages of Middleware
  • AI-Native OS: Empower Humanoid Robots
  • Infrastructure LLMOS Serves Cockpit AI Applications
  • 3.10 Others
  • CARThunder OS Based on Agentic AI Architecture
  • Hangsheng Electronics' AI OS Solution
  • Rockchip Launches A Series of Domestic Hardware-Software Integrated Intelligent Foundation Products Featuring AIOS
  • Horizon Robotics: Agentic Car OS Covers Cockpit-Driving Integration Scenarios
  • Megatronix's Vehicle Distributed Intelligent Operating System

4 Vehicle OS Suppliers

  • 4.1 iSOFT Infrastructure Software
  • Software System Layout
  • Vehicle OS Layout: System Framework
  • Vehicle OS Layout: Development History
  • Vehicle Control OS: Architecture
  • Vehicle Control OS: Functions
  • Vehicle Control OS: Chip Ecosystem
  • Vehicle Control OS: Upgrade Cooperation with Chip Vendors
  • Vehicle Control OS: New-Generation Vehicle Control OS Platform Solution
  • Intelligent Driving OS: Features
  • Intelligent Driving OS: Security
  • Intelligent Driving OS: Architecture
  • AUTOSAR Solution
  • AUTOSAR CP+AP Integrated Solution
  • CP Products
  • 4.2 ZTE GoldenOS
  • ZTE Builds New Software-Hardware Collaboration Paradigm of Chip + OS + AI
  • AI Promotes Domain Integration
  • Microkernel and Macro Kernel Technical Architectures
  • Vehicle Control OS Solution
  • Intelligent Cockpit OS Solution
  • Intelligent Driving OS Solution: Dual-Kernel Architecture
  • Intelligent Driving OS Solution: Application Scenarios
  • Intelligent Driving OS Solution: Evolution History
  • Intelligent Driving OS Solution: Chip Adaptation
  • Dynamics in Neusoft Reach + ZTE + SemiDrive Cooperation
  • 4.3 Automotive Intelligence and Control of China Co., Ltd. (AICC)
  • Product System
  • ICVOS: Intelligent Connected Vehicle Operating System
  • ICVOS: Software Architecture
  • ICVOS: Development Architecture
  • ICVOS: SDK Architecture
  • ICVOS: Platformized, Networked and Scalable
  • ICVOS: Vehicle-Cloud Collaboration
  • ICVOS: Information Security Basic Platform
  • ICVOS: New Architecture Oriented to Autonomous Driving Domain
  • ICVOS: Cases of Software Architecture Co-development with OEMs (1)
  • ICVOS: Cases of Software Architecture Co-development with OEMs (2)
  • ICVOS: Cases of Software Architecture Co-development with OEMs (3)
  • ICVOS: Cases of Software Architecture Co-development with OEMs (4)
  • 4.4 NVIDIA DRIVE OS
  • Introduction to Drive OS
  • Drive OS SDK Architecture
  • 4.5 Elektrobit (EB)
  • Tresos Real-Time Operating System
  • Tresos AutoCore Architecture
  • Intelligent Driving Domain Operating System Based on J5
  • Virtualization Development Technology
  • 4.6 Others
  • iHUATEK Uses Large Vision Model to Build Vehicle OS
  • Freetech SOA Integrates Large Models
  • Zlingsmart's "RAITE OS" Microkernel Operating System
  • Clarence Vehicle Integrated Software Platform (RTOS)
  • Red Hat

5 Operating Systems of Chinse OEMs

  • 5.1 Li Auto
  • Vehicle OS: Evolution History
  • Vehicle OS: Architecture
  • SOA and Basic Software: Main Components of Vehicle OS HaloOS
  • Vehicle OS: Architecture
  • Vehicle OS: Components and Features
  • Vehicle OS: Components (1) - Communication Middleware
  • Vehicle OS: Components (1) - Features of Communication Middleware
  • Vehicle OS: Components (2) - Vehicle Control OS
  • Vehicle OS: Components (2) - Features of Vehicle Control OS
  • Vehicle OS: Components (3) - Intelligent Driving OS
  • Vehicle OS: Components (3) - Intelligent Driving OS Subsystems
  • Vehicle OS: Components (4) - Virtualization Engine
  • Vehicle OS: Components (4) - Features of Virtualization Engine
  • Vehicle OS: Components (5) - Information Security
  • Vehicle OS: Components (5) - Information Security Features
  • Vehicle OS: Components (5) - Information Security Scenarios
  • Vehicle OS: Innovative Scenario - Cross-Domain Sensor Sharing
  • HaloOS Application Advantage 1: Rich Adaptable Chip Types
  • HaloOS Application Advantage 2: Cross-Domain Scheduling
  • HaloOS Application Advantage 3: Hardware Sharing
  • SOA and Basic Software: HaloOS - Key Features
  • Vehicle OS: Latest Cooperation Dynamics
  • AI-Driven Software Development Transformation: HaloOS Simulator Tool
  • Software Development Tool Transformation: HaloOS Simulator Tool - Application Scenarios
  • 5.2 NIO
  • SkyOS Full-domain AIOS Operating System: AI Model Engine - Framework
  • SkyOS Full-Domain AI Operating System: AI Model Engine - Key Components
  • SkyOS R&D History
  • SkyOS Architecture (1): Functional Characteristics of Components
  • SkyOS Architecture (2): SkyOS-M Core Based on seL4
  • SkyOS Architecture (2): SkyOS-M Development History and Challenges
  • SkyOS Architecture (3): SkyOS-R Performance Under Various Loads
  • SkyOS Architecture (4): Middleware
  • SkyOS Architecture (5): Data Closed-loop
  • How SkyOS Integrates AI and Enables Cockpit-Driving Integration
  • Application of AI Large Model Requires Computing Power Scheduling of Vehicle OS
  • SkyOS Application Cases: Cross-domain Invocation & Ultra-low Latency
  • SkyOS Application Cases: Aerial View System
  • SkyOS Application Cases: Valet Battery Swap (1)
  • SkyOS Application Cases: Valet Battery Swap (2)
  • SkyOS Application Cases: Valet Battery Swap (8)
  • SkyOS Application Cases: Data Security / 4D Comfort Pilot / High-spec Hardware
  • SkyOS and Cedar Digital Architecture (1)
  • SkyOS and Cedar Digital Architecture (2)
  • SkyOS and Cedar Digital Architecture (8)
  • Vehicle OS Scheduling Algorithms
  • Adaptable Chips
  • 5.3 Xpeng
  • Vehicle OS Accelerates Integration
  • End-to-End Deterministic Vehicle OS
  • Vehicle SOA Communication Middleware
  • Vehicle-Cloud Integrated Vehicle SOA Middleware Platform
  • Hardware Sharing Cases under SOA
  • 5.4 Xiaomi
  • Introduction to HyperOS
  • AIOS Development Direction
  • HyperOS Upgrade to 3.0
  • HyperOS Architecture Design (1)
  • HyperOS Architecture Design (2)
  • Hyper OS Architecture Design (5)
  • Vehicle OS Communication Technology under SOA
  • Open-source Vela
  • Technical Advantages of Vela
  • Vela Kernel Achieves ASIL-D Safety Level
  • Technical Advantages of Vela
  • Vela Ecosystem Cooperation
  • 5.6 Leapmotor
  • Vehicle OS Architecture
  • Integrated Vehicle Architecture
  • Multi-Task Scheduling Model of Vehicle OS
  • 5.6 Geely
  • Upgrade of AIOS
  • Full-Domain AI System
  • SOA-Based Operating System: GeelyOS
  • Intelligent Cockpit Solution: Flyme Auto IVI System
  • Meizu Flyme AI OS Allows for Integration with IVI
  • Advantages and Disadvantages of Flyme OS
  • Zeekr Intelligent Cockpit Solution: ZEEKR AI OS
  • Zeekr Vehicle OS Architecture
  • 5.7 SAIC Motor
  • Design of Z-ONE AIOS
  • Full-Stack 4.0 AI Architecture: Middleware Framework AI OS
  • Full-Stack 4.0 AI Architecture: AI Application Layer Architecture
  • Full-Stack 4.0 AI Architecture: AI Application Layer Development - Agent Framework
  • Full-Stack 4.0 AI Architecture: AI Application Layer Development - Agent Application Ecosystem
  • Full-Stack 4.0 AI Architecture: Full-Domain Fusion Super Agent - IM Ultra Agent
  • 5.8 Great Wall Motor
  • Cockpit OS: Coffee OS 3 Architecture
  • Features of AI OS
  • How Coffee OS Cooperates with Agent Scenarios
  • Vehicle OS
  • Cockpit Operating System: GC-OS
  • 5.9 FAW Hongqi
  • Lingxi AI Cockpit OS Integrated with Agent
  • FAW.OS Architecture (1)
  • FAW.OS Architecture (2)
  • AIOS Integrated with Vehicle Large Model
  • Features of FAW.OS
  • 5.10 GAC Group
  • Latest X-soul Architecture
  • Vehicle OS Architecture
  • Applications of Vehicle OS
  • 5.11 Changan
  • Cockpit OS: Tops OS
  • RTDriveOS Architecture
  • Integrate AI into SOA Layer
  • SDA: RTDriveOS Intelligent Driving Operating System
  • SDA: L4 Layer - Operating System Layer
  • 5.12 Dongfeng Motor
  • Vehicle OS Architecture
  • OS Development Process
  • Tianyuan OS
  • Tianyuan OS Architecture
  • Open-Source Components of Tianyuan Intelligent OS
  • Full-Domain Fusion of Tianyuan OS
  • EAI Agent Space of Tianyuan OS
  • Tianyuan Safe Vehicle Control OS
  • 5.13 BYD
  • OS Architecture
  • Features of OS
  • Underlying Operating System Architecture of Intelligent Driving
  • 5.14 Chery
  • Introduction to Chery OS
  • Application of Chery OS
  • Upgrade of Chery OS to AI OS

6 Operating Systems of Foreign OEMs

  • 6.1 BMW
  • Evolution of BMW iDrive System
  • Agent Application Realized by BMW iDrive
  • Software-Defined Vehicle Architecture
  • 6.2 Mercedes-Benz
  • Introduction to MB OS Functions
  • Architecture of MB OS
  • Latest Dynamics in Software Development Cooperation
  • 6.3 Volkswagen
  • Introduction to VW.OS
  • Development History of VW.OS
  • Features of VW.OS
  • Architecture of VW.OS
  • 6.4 Toyota
  • Introduction to Arene OS
  • Ecosystem Resources of Arene OS
  • Functions of Arene OS
  • Cooperation with NVIDIA on Operating System
  • 6.5 Honda
  • ASIMO Operating System Derived from Robotics
  • ASIMO Operating System Has Learning Capabilities