자동차용 OS와 AIOS의 통합(2025년)

Research on automotive AI operating system (AIOS): from AI application and AI-driven to AI-native

Automotive Operating System and AIOS Integration Research Report, 2025, released by ResearchInChina, explains the status quo and trends of AI application in automotive operating systems (OS), and analyzes how vehicle OS and AIOS mutually empower and co-evolve.

The relationship between vehicle OS and AIOS:

From 2023 to 2024, with the rise of central computing architecture, domain operating systems started evolving towards vehicle OS which takes on integrating the full-domain software system.

In the second half of 2024, AI foundation models started being mass-produced and introduced into vehicles, which raises new requirements for vehicle operating systems and also enables their scheduling capabilities, further facilitating the adoption of automotive AIOS.

AIOS is an AI-driven operating system that enables operating systems with "intelligence", that is, allow the systems to independently make optimizations and decisions during task execution and scheduling. AIOS represents the pinnacle of vehicle intelligence, and is responsible for handling complex perceptual data, executing intelligent decision, and realizing human-like interaction, while vehicle OS serves as the software foundation for all vehicle functions. The deep integration of the two is not merely a functional overlay but a key force driving reshaping of underlying architecture, deep synergy in industry chain, and redefinition of competitive rules.

1.Vehicle OS supports the implementation of AI capabilities: Beyond providing computing power and data, the SOA of vehicle OS abstracts vehicle functions into independent services through standardized interfaces, achieving hardware-software decoupling, and makes it easy to call interfaces across different software modules through atomic services, providing a stable and flexible invocation environment for AI models. Take Geely as an example:

Geely's customized OS, GOS, is based on an SOA development framework that encapsulates various vehicle functions as services and allows AI functions to quickly call these services for agile development and iteration, providing the foundation for the rapid deployment and continuous optimization of AI capabilities. In early 2025, Geely introduced its "Full-Domain AI" system, and upgraded its OS to AIOS, with a model layer set up for AIOS to call.

2.AI reconstructs vehicle OS: Shifting it from the traditional "function-driven" model to a smarter "intent-driven" model:

AI Agents at the application layer can leverage foundation models' semantic analysis capabilities to accurately understand users' natural language commands and even latent intentions, and automatically invoke underlying software modules to complete tasks. The "intent-driven" interaction model is used to enable vehicles to proactively understand needs and provide services, making user experience much more natural and convenient.

Foundation models at the middleware (or model) layer not only provide calling interfaces for agents but also optimize the scheduling capabilities of vehicle OS through planning. This process relies on historical data and real-time system states, and uses reinforcement learning and operations research algorithms to dynamically allocate system resources and prioritize tasks. For instance, when a user simultaneously initiates navigation planning and high-definition video playback, foundation models can predict the urgency of route calculation and the resource demands of video decoding, coordinate CPU, GPU, and NPU compute in advance to ensure both navigation response and smooth video playback, avoiding stuttering caused by resource contention in traditional scheduling algorithms.

Data at the resource layer serves as the bridge between the two. Vehicle OS is responsible for data collection and management, while AIOS handles data analysis and decision-making.

In ArcherMind's case, its subsidiary Arraymo developed ArraymoAIOS 1.0, an on-device AI operating system which, together with the vehicle operating system FusionOS 2.0, constitutes the technical base of AIOS. Key features of this base include:

Support use of Qualcomm SA8775P to build cockpit agents, and NVIDIA Orin to build vehicle agents, each equipped with 10+ deeply optimized on-device models (DeepSeek, Llama, Baichuan, Gemma, Yi-Chat, etc.).

Introduce intelligent scheduling algorithms to monitor and analyze multi-modal task loads (text, image, audio, etc.) in real time, and dynamically adjust the strategies for allocation of resources like CPU, GPU, and memory.

Introduce the AI acceleration engine AMLightning to efficiently schedule computing units in AI chips, allowing reasoning tasks to run on the most suitable computing unit.

Evolution of AIOS: From AI Application and AI-Driven to AI-Native

In the automotive sector, AI was initially integrated at the application layer of the operating system, invoked via interfaces for specific scenarios. Entering the era of AIOS, AI starts penetrating deeper into the underlying layer, from being integrated into the middleware layer for driving functions, to touching the OS kernel and underlying architecture. In the future, it will evolve into AI-native OS.

As of April 2025, there have been three modes of AI integration in OS, corresponding to the three development phases of AIOS:

AI Application Phase: introduced as applications to serve scenarios.

AI-Driven Phase: connected at the middleware layer, utilizing components like AI Runtime and AI frameworks (models/agents/algorithm frameworks) to drive various software functions more flexibly.

AI-Native Phase: large language models (LLMs) are called as microkernel modular components, providing platform-level AI capabilities for the entire OS.

Huawei believes that the application of AI technology in terminal products typically passes through three phases: AI integration at the application layer, AI fusion at the system layer, and AI-centric new OS.

As of H1 2025, most OEMs have already deployed AI at the application layer and have begun to integrate AI components into the middleware layer. Examples include Li Auto's Halo OS, NIO's Sky OS, Xiaomi's Hyper OS, and Geely's AIOS GOS.

AI Application Phase

At this phase, AI is integrated into the application layer of OS to be called for scenarios. OS primarily provides computing power and data interfaces to optimize and upgrade basic AI functions like navigation and voice interaction. For example, in a "vehicle assistant" scenario, when a user calls AI for car-related knowledge, AI at the application layer first analyzes the request, converts it into a command, retrieves relevant data from databases, and formulates a natural-language answer displayed on the center console screen.

AI-Driven Phase

At this phase, AIOS extends into the middleware layer, becoming a mainstream approach for AI Agent invocation in intelligent cockpits. Upper-layer agents leverage AI components to directly call SOA atomic services via framework modules to control vehicle functions or other software features. Additionally, toolchains can be used to call multiple external tools and ecological interfaces to achieve "touchless" automation for scenarios.

For instance, the "people search by photographing" function of Li Auto's MindVLA requires MindVLA to successively complete such steps as object recognition, map data matching, and route planning, involving use of components like AI reasoning framework and reasoning acceleration, and invocation of external maps and location data.

Li Auto's Halo OS incorporates an AI subsystem in the middleware layer, which includes not only AI Runtime but also components like AI reasoning engine and reasoning acceleration framework.

AI-Native Phase

AI-Native refers to systems or product forms that are fundamentally driven by AI, and deeply integrate AI in design from the ground up.

An AI-Native OS is an operating system that deeply integrates AI into its underlying architecture from the beginning of design, features system-level AI capabilities, and delivers all-scenario intelligent experience and rich agent ecosystems.

When AI and OS achieve deep integration, an AI-Native OS is formed. The system can intelligently optimize resource allocation and task scheduling according to application scenarios and demands, thus bringing a qualitative leap in overall efficiency and intelligence, rather than merely taking AI as an upper-layer application or functional module.

In Huawei's case, its AI-Native OS has the following features:

Unified AI system base

AI-Native applications

Xiaoyi Super Agent

Open ecosystems

Underpinned by the AI system base, super apps/agents are built and rich ecosystems are created. AI-native HarmonyOS features multimodal understanding, personalized user data understanding, and privacy protection capabilities, and all-scenario perception and collaboration capabilities.

In April 2025, Huawei launched HarmonySpace 5, a HarmonyOS-based cockpit which adopts the MoLA hybrid foundation model architecture. It leverages a multi-model base (including DeepSeek), led by the PanGu Models, to enable system agent and vertical agent scenario applications. The entire upper-layer applications are supported by the system-level AI capabilities of HarmonyOS 5.0.

In ThunderSoft's case, in 2025, AquaDrive OS has been upgraded to an AI-native OS, offering optimizations in the following directions:

The AI middleware of AquaDrive OS includes agent perception/execution services and an agent management framework to support multi-agent interaction. It also incorporates a foundation model inference and scheduling framework, supporting connection to various cloud and on-device foundation models to achieve life-oriented multimodal recognition and environmental guidance.

Its framework provides SOA services, and enables modular software function calls with atomized support.

Table of Contents

Definitions

1 Status Quo and Trends of Automotive AIOS

• 1.1 Application Background of AIOS
• Application Background of Vehicle OS in the AI Era
• Requirements for Vehicle OS in the AI Era (1) - (3)
• Overview of AI Application in Automotive OS
• 1.2 AIOS Architecture
• Construction Methods of LLM OS
• AIOS Architecture: Main Components and Functions of Kernel Module (1) - (7)
• AIOS Architecture: Throughput and Latency/Performance Maintenance in Parallel State
• AIOS Architecture: Agent Structure
• AIOS Architecture: Model Deployment and Task Flow
• AIOS Architecture: Definition and Characteristics of AI Runtime
• AIOS Architecture: Comparison between Different AI Runtimes
• AIOS Derived Framework: LSFS Improves File Management Efficiency
• AIOS Derived Framework: Architecture of LSFS as an Additional Layer
• AIOS Derived Framework: Implementation Modes of LSFS Functions
• 1.3 Cases and Insights of Terminal AIOS in Different Industries
• Consumer-Grade AIOS Cases (1) - (2)
• Enterprise-Grade AIOS Cases (1) - (2)
• Insights from Terminal AIOS for Automotive AIOS
• 1.4 AIOS Trends
• Trend 1: Vehicle OS Lays the Foundation for AIOS Implementation
• Trend 2: AIOS Fusion Path
• Trend 3:
• Trend 4:
• Trend 5: AI-Native OS and Cases

2 Overview of Automotive OS

• 2.1 Definition and History
• Automotive Operating System (OS)
• Evolution of Operating Systems
• Vehicle OS: Definition
• Vehicle OS: Evolution Process
• Vehicle OS: Architecture
• Vehicle OS: Characteristics
• Vehicle OS: Development Models/Business Models
• Summary of OEMs' Vehicle OS (1) - (8)
• Cross-Domain Scheduling of Vehicle OS: Algorithm Invocation
• 2.2 Trends of Automotive OS
• Trend 1:
• Trend 2:
• Trend 3: Operating System Layout Modes of OEMs/Suppliers
• Trend 4: OEMs' Self-Developed Vehicle OS (1) - (9)
• 2.3 Classification of Automotive OS
• Classification of Automotive OS: OS in Narrow/Broad Sense
• Classification of Automotive OS: Real-Time OS and Non-Real-Time OS
• List of Real-Time Operating System Suppliers and Their Products (1) - (3)
• List of Non-Real-Time Operating System Suppliers and Their Products (1) - (2)
• Classification of Automotive OS: Microkernel, Monolithic Kernel, Hybrid Kernel
• Classification of Automotive OS: Vehicle Control and In-Vehicle OS
• Automotive OS Market Size Forecast
• 2.4 Software Architecture
• Software Architecture of Intelligent Vehicles
• Software Ecosystem Framework of Intelligent Vehicles
• Kernel Is the Core of Automotive Software Architecture
• 2.5 Business Models
• Types of Business Models for Automotive OS
• Business Models of Major Automotive OS Companies
• Development Trends of Automotive OS and Business Model Exploration
• Basic Automotive OS and Business Models
• Automotive RTOS and Business Models (1)
• Automotive RTOS and Business Models (2)
• Operating Systems and Business Models of Suppliers (1) - (4)
• 2.6 Automotive Electronics Standard: AUTOSAR
• Introduction to AUTOSAR
• Classification of AUTOSAR
• Key Members of AUTOSAR
• Classic AUTOSAR: Architecture
• Classic AUTOSAR: Functions
• Adaptive AUTOSAR: Framework
• Comparison Between Classic AUTOSAR and Adaptive AUTOSAR
• Integration of Adaptive AUTOSAR and ROS
• Core Points of AUTOSAR
• Architecture of AUTOSAR China Working Group
• Project Cases of AUTOSAR China Working Group
• Business Models of AUTOSAR-Related Software Tool Suppliers (1) - (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 Automotive Electronics Standard: OSEK
• Introduction to OSEK
• Architecture and Characteristics of OSEK
• 2.8 Open Organization: COVESA
• Introduction to COVESA
• Members of COVESA
• Key Achievements of COVESA
• Example of COVESA Achievements
• Primary Role of COVESA
• Dynamics of COVESA

3 Basic Operating Systems

• Introduction to Basic Automotive Operating Systems
• 3.1 BlackBerry
• Development History of QNX in Automotive
• QNX Business
• QNX Products: Safety Levels
• QNX Products: Features of Real-Time Operating System
• QNX Products: Architecture of Real-Time Operating System
• QNX Products: Cockpit Software Platform Solution (SDP 8.0)
• QNX Products: Intelligent Assistance Platform
• QNX Products: Cockpit-Driving Integration Controller
• QNX Products: QNX Cloud Simulation Platform
• QNX Products: Domain Controller Basic Software Platform
• QNX OS for Safety: Product Panorama
• QNX OS for Safety: Comparison of Safety Performance
• Application of QNX in Robotics
• QNX Partners
• Dynamics of QNX
• 3.2 Linux & AGL
• Members of AGL
• Linux Architecture
• RT-Linux
• Open-Source Projects of Linux Foundation AI
• AGL Application Framework: UCB
• 3.3 Android
• Introduction to Android & Android Automotive OS
• Android Automotive OS Architecture (1)
• Android Automotive OS Architecture (2)
• Features of Android Automotive OS
• Android Auto Introduces AI Functions
• Impacts of Slowed Updates of Android AOSP
• User Development
• 3.4 Huawei
• Introduction to HarmonyOS
• Development History of HarmonyOS
• Technical Architecture of HarmonyOS
• Cooperation Models Between HarmonyOS and OEMs
• Intelligent Driving Operating System: AOS
• Intelligent Vehicle Control Operating System: VOS
• Cross-Domain Integrated Software Framework: Vehicle Stack
• iDVP Platform Upgrade
• CCA
• AI Functions of HarmonyOS
• Two Implementation Modes of "Say and See" in HarmonyOS
• 3.5 Alibaba
• Introduction to AliOS
• Evolution Strategy of Banma Zhixing's Vehicle OS
• AliOS Architecture
• Analysis of AliOS Application Layer
• Integration of Alibaba's Qianwen Model and OS: System Agent System
• AliOS Solution: AliOS Intelligent Cockpit Operating System
• AliOS Drive Intelligent Driving Operating System
• Business Model of Banma Zhixing OS
• Recent Dynamics of AliOS
• 3.6 VxWorks
• Introduction to VxWorks
• Wind River Software VxWorks Microkernel Architecture (1)
• Wind River Software VxWorks Microkernel Architecture (2)
• Wind River Products: Wind River Linux and Wind River AUTOSAR Adaptive Software Platform
• Wind River Products: Helix Virtualization Platform
• New Products of Wind River RTOS
• Recent Dynamics in Automotive
• 3.7 Ubuntu
• Introduction to Ubuntu
• Applications of Ubuntu
• Ubuntu's Cooperation in Automotive
• 3.8 webOS
• Development History of webOS
• webOS OSE Components and Development Roadmap
• webOS Can Be Integrated with AGL
• Recent Dynamics in Automotive
• 3.9 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

4 Hypervisor

• 4.1 Introduction to Hypervisor
• 4.2 Comparison between Major Hypervisors
• 4.3 Status Quo of Hypervisor Industry
• 4.3 Status Quo of Hypervisor Industry: China
• 4.3 Status Quo of Hypervisor Industry: Global
• 4.4 Global Automotive Hypervisor Market Outlook
• 4.5 Business Models of Automotive Hypervisor Management System
• 4.5 Hypervisor Business Models (1) - (4)
• 4.6 QNX Hypervisor
• Profile
• Architecture
• Solutions
• 4.7 ACRN
• Profile
• Components
• 4.8 COQOS Hypervisor
• COQOS Hypervisor
• COQOS Hypervisor SDK 9.5
• Mixed VIRTIO / Non-VIRTIO Architecture
• "Next Gen COQOS" Heterogeneous Cores
• 4.9 PikeOS
• PikeOS
• 4.10 EB Corbos Hypervisor
• EB Corbos Hypervisor
• 4.11 Harman Device Virtualization
• Harman Device Virtualization
• 4.12 VOSYSmonitor
• VOSYSmonitor
• 4.13 Zlingsmart
• RAITE Hypervisor: System Design
• RAITE Hypervisor: Intelligent Cockpit Solution

5 Generalized Automotive OSs and Companies

• 5.1 Neusoft Reach
• Introduction to NeuSAR
• Divide AIOS into Three Stages
• Deployment of AI in 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 Completes DeepSeek Adaptation
• NeuSAR aCore
• Upgrades to AUTOSAR AP Products
• NeuSAR cCore
• Lightweight AUTOSAR CP Products
• Collaboration with Infineon
• 5.2 ThunderSoft
• AquaDrive OS Vehicle OS
• Integration of Rubik Foundation Model with OS
• AquaDrive OS Upgraded to AIOS
• How AquaDrive OS Supports AI Function Implementation
• How AquaDrive OS Supports AI Function Implementation: Cases
• 5.3 ArcherMind
• Arraymo AIOS Base
• Cross-Domain Vehicle OS: FusionOS 1.0
• Cross-Domain Vehicle OS: FusionOS 2.0
• Recent Dynamics
• 5.4 Kernelsoft
• AI-Oriented Operating System Solutions
• Real-Time Operating System
• Linux
• Operating System Security
• 5.5 Baidu
• AI-Native Operating System: DuerOS X
• AI-Native Operating System: Architecture
• Integrated Vehicle OS Supply
• 5.6 iSOFT Infrastructure Software
• AUTOSAR CP+AP Integrated Solutions (1)
• AUTOSAR CP+AP Integrated Solutions (2)
• CP Products
• Vehicle OS Layout
• Operating System Architecture
• Vehicle Control OS: Open-Source EasyXMen
• Intelligent Driving OS: EasyAda
• 5.7 ZTE GoldenOS
• Microkernel and Macrokernel Technical Architecture
• 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
• Intelligent Driving OS Solution: Chip Adaptation
• Dynamics in Neusoft Reach + ZTE + SemiDrive Cooperation
• 5.8 AICC
• Product System
• ICVOS: Intelligent Connected Vehicle OS
• ICVOS: Software Architecture
• ICVOS: Development Architecture
• ICVOS: SDK Architecture
• ICVOS: Platform-Based, Connected, Scalable
• ICVOS: Vehicle-Cloud Cooperation
• ICVOS: Information Security Foundation Platform
• ICVOS: New Architecture for Autonomous Driving Domain
• ICVOS: Cases of Software Architecture Co-development with OEMs (1) - (4)
• 5.9 NVIDIA DRIVE OS
• Introduction to DRIVE OS
• DRIVE OS SDK Architecture
• 5.10 EB
• Tresos Real-Time Operating System
• Tresos AutoCore Architecture
• EB's J5-Based Intelligent Driving Domain OS
• EB's Virtualization Development Technology
• 5.11 Other OS Vendors
• STEP's Intelligent Driving OS Supports LLM and End-to-End Algorithm Deployment
• iHUATEK Uses Large Vision Models to Build Vehicle OS
• Freetech's SOA Structure Is Connected to Foundation Models
• Zlingsmart's "RAITE OS" Microkernel OS
• RT-Thread's "Chenxuan" Vehicle Fusion Software Platform (RTOS)
• Red Hat

6 Operating Systems of Chinese OEMs

• 6.1 Li Auto
• Vehicle OS: Evolution
• Vehicle OS: Architecture
• Vehicle OS: Components and Features
• Vehicle OS: Components (1) - Communication Middleware and Its Features
• Vehicle OS: Components (2) - Vehicle Control OS and Its Features
• Vehicle OS: Components (3) - Autonomous Driving OS and Its Features
• Vehicle OS: Components (3) - Subsystems of Intelligent Driving OS
• Vehicle OS: Components (4) - Virtualization Engine and Its Features
• 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
• Halo OS Application Advantage 1:
• Halo OS Application Advantage 2: Achieving Cross-Domain Scheduling
• Halo OS Application Advantage 3:
• 6.2 NIO
• Development History of SkyOS
• SkyOS Architecture (1): Functional Features of Different Components
• SkyOS Architecture (2): SkyOS-M Core Based On seL4
• SkyOS Architecture (2): SkyOS-M Core Based On seL4
• SkyOS Architecture (2): SkyOS-M Development History and Challenges
• SkyOS Architecture (2): SkyOS-M Micro-Perception Self-Recovery Function
• SkyOS Architecture (3): SkyOS-R Performance Under Different Loads
• SkyOS Architecture (4): Middleware
• SkyOS Architecture (4): Middleware
• SkyOS Architecture (5): Data Closed Loop
• How SkyOS Integrates AI and Achieves Cockpit-Driving Integration
• Use of AI Foundation Models Requires Computing Power Scheduling of Vehicle OS
• SkyOS Application Cases: Surround-View Display
• SkyOS Application Cases: Valet Battery Swap Service (1)
• SkyOS Application Cases: Valet Battery Swap Service (2)
• SkyOS Application Cases: Valet Battery Swap Service (3)
• SkyOS Application Cases: Valet Battery Swap Service (4)
• SkyOS Application Cases: Valet Battery Swap Service (5)
• SkyOS Application Cases: Valet Battery Swap Service (6)
• SkyOS Application Cases: Valet Battery Swap Service (7)
• SkyOS Application Cases: Valet Battery Swap Service (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 (3)
• SkyOS and Cedar Digital Architecture (4)
• SkyOS and Cedar Digital Architecture (5)
• SkyOS and Cedar Digital Architecture (6)
• SkyOS and Cedar Digital Architecture (7)
• SkyOS and Cedar Digital Architecture (8)
• Vehicle OS Scheduling Algorithm
• Chip Adaptation
• 6.3 XPeng
• Vehicle OS Integration Accelerates
• Vision for Integration of OS and AI Foundation Model (1)
• Vision for Integration of OS and AI Foundation Model (2)
• Tianji AIOS
• 6.4 Xiaomi
• AIOS-Driven Direction
• Introduction to HyperOS and Its Development History (1)
• Introduction to HyperOS and Its Development History (2)
• HyperOS Architecture Design (1)
• HyperOS Architecture Design (2)
• HyperOS Architecture Design (3)
• HyperOS Architecture Design (4)
• HyperOS Architecture Design (5)
• Vehicle OS Communication Technology Under SOA (1)
• Vehicle OS Communication Technology Under SOA (2)
• Vela Open Source
• Vela Technical Advantages (1)
• Vela Technical Advantages (2)
• Vela Cooperation Ecosystem
• 6.5 Leapmotor
• Vehicle OS Architecture
• Vehicle Fusion Architecture
• Vehicle OS Multi-Task Scheduling Method
• 6.6 Geely
• Upgrade AIOS Operating System
• Full-Domain AI System
• SOA-Based OS: GeelyOS (1)
• SOA-Based OS: GeelyOS (2)
• SOA-Based OS: GeelyOS (3)
• Intelligent Cockpit Solution: Flyme Auto IVI System
• Meizu Flyme AI OS Can Integrate with IVI System
• Advantages and Disadvantages of Flyme OS
• Zeekr's Intelligent Cockpit Solution: ZEEKR AI OS (1)
• Zeekr's Intelligent Cockpit Solution: ZEEKR AI OS (2)
• 6.7 SAIC
• IM AIOS Enables Agent Implementation
• IM AIOS Supports Multi-Agent Processes
• Z-ONE's AI Service Architecture
• Z-ONE's AI Service Architecture Is Built with 4 Layers
• Z-ONE's AIOS and Hardware Cooperation
• Z-ONE's AIOS Achieves Device-Cloud Integration Architecture (1)
• Z-ONE's AIOS Achieves Device-Cloud Integration Architecture (2)
• Z-ONE's Agent Cooperation Process
• 6.8 Great Wall Motor
• Cockpit OS: Coffee OS 3 Architecture
• Features of AI OS
• How Coffee OS Coordinates Agent Scenarios
• Vehicle OS and Central Computing Architecture (1)
• Vehicle OS and Central Computing Architecture (2)
• 6.9 FAW
• FAW.OS Architecture of FAW Hongqi (1)
• FAW.OS Architecture of FAW Hongqi (2)
• FAW AIOS Integrates Vehicle Foundation Models
• Features of FAW.OS
• 6.10 GAC
• Vehicle OS Architecture
• Vehicle OS Application
• 6.11 Changan
• Cockpit OS: Tianyu OS
• RTDriveOS Architecture
• Integrating AI into SOA Layer
• SDA: RTDriveOS Intelligent Driving OS
• SDA: L4 Layer - OS Layer
• SDA: L4 Layer - OS Layer
• 6.12 Dongfeng
• Vehicle OS Architecture (1)
• Vehicle OS Architecture (2)
• OS Development Process
• 6.13 BYD OS
• BYD OS Architecture
• BYD OS Features
• 6.14 Chery OS
• Chery OS Introduction
• Chery OS Application
• 6.15 BAIC's AIOS Vision

7 Operating Systems of Foreign OEMs

• 7.1 From Customized Automotive OS To Vehicle OS
• 7.2 Comparison between Foreign Automotive OSs (1)
• 7.2 Comparison between Foreign Automotive OSs (2)
• 7.2 Comparison between Foreign Automotive OSs (3)
• 7.3 BMW
• Mass-Production EEA: Software System Evolution
• iDrive Enables Agent Application
• 7.4 Mercedes-Benz
• MB OS Functions
• MB OS Architecture (1)
• MB OS Architecture (2)
• MB OS Architecture (3)
• MB OS Architecture (4)
• Recent Development of MB OS
• 7.5 Volkswagen
• Introduction to VW.OS
• VW.OS Development History (1)
• VW.OS Development History (2)
• VW.OS Development History (3)
• VW.OS Features (1)
• VW.OS Features (2)
• VW.OS Architecture
• 7.6 Toyota
• Introduction to Arene OS (1)
• Introduction to Arene OS (2)
• Arene OS Ecosystem Resources
• Arene OS Functions (1)
• Arene OS Functions (2)
• Cooperation With NVIDIA on OS
• 7.7 Honda
• ASIMO Operating System