자동차용 AIOS 시장(2026년)

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