An adaptive execution method and system for vehicle-mounted hybrid artificial intelligence tasks

Abstract

The application discloses a kind of adaptive execution methods and systems for vehicle-mounted hybrid artificial intelligence task, it includes: obtaining task data and vehicle state signal, determine that vehicle is in driving or parking state;If driving, execute with background mute mode, prohibit the physical control subtask involving vehicle movement, limit resource occupation and interactive feedback;If parking, execute with initiative calculation mode, allow the physical control subtask involving vehicle movement, remove limit.The application solves the contradiction between computing power resources and driving safety by establishing dynamic binding of vehicle state and computing scheduling.During driving, interference is avoided to ensure safety, and during parking, idle computing power is used to process complex tasks, achieving a closed loop of AI inference and vehicle physical control, and improving hardware utilization and task execution continuity.The system also supports intent record pool and safety check, ensuring task cross-end synchronization and execution safety, and optimizing scheduling strategy through feedback learning.

Description

Technical Field

[0001] This application relates to the field of vehicle intelligent control technology, specifically to an adaptive execution method and system for in-vehicle hybrid artificial intelligence tasks. Background Technology

[0002] With the development of artificial intelligence technology, in-vehicle assistant systems are becoming increasingly common. However, existing in-vehicle task execution solutions have significant technical shortcomings, mainly reflected in the mismatch between computing resource scheduling strategies and the physical operating status of the vehicle.

[0003] For example, the task processing logic of traditional in-vehicle systems is usually static, whether the vehicle is in motion or parked. When the vehicle is in motion, the driver's attention must be focused on the road conditions. If the in-vehicle AI performs complex general tasks (such as generating long texts or complex dialogues), it will interfere with driving through the screen or voice, posing a safety hazard. When the vehicle is parked, the vehicle's high-performance computing chip is usually in a dormant or low-load state, resulting in a waste of hardware resources. Therefore, there is a conflict between vehicle computing resources and driving safety. Summary of the Invention

[0004] This application provides an adaptive execution method and system for in-vehicle hybrid artificial intelligence tasks, which can solve the technical problem of the conflict between vehicle computing resources and driving safety in the prior art.

[0005] In a first aspect, embodiments of this application provide an adaptive execution method for in-vehicle hybrid artificial intelligence tasks, comprising: Acquire task data and vehicle status signals, and determine the vehicle's status based on the vehicle status signals; If the vehicle is determined to be in motion, the task data will be executed in background silent mode. If the vehicle is determined to be parked, the task data is executed in active calculation mode; In the background silent mode, physical control subtasks involving vehicle movement are prohibited from execution, and the resource consumption and interactive feedback intensity of artificial intelligence inference operations are limited. In the active computing mode, physical control subtasks involving vehicle movement are allowed to be executed, and the restrictions on resource consumption and interactive feedback intensity are lifted.

[0006] Preferably, the vehicle status signal includes at least a vehicle speed signal, a gear position signal, and a handbrake status signal; The step of determining whether the vehicle is currently in a driving or parked state based on the vehicle status signal includes: When the vehicle speed signal is greater than zero, or when the gear position signal indicates that the gear is not the parking gear, it is determined to be the driving state; When the vehicle speed signal is equal to zero, the gear position signal indicates that the gear is parking, and the handbrake status signal indicates that the handbrake is engaged, the parking state is determined.

[0007] Preferably, limiting the resource consumption and interactive feedback intensity of artificial intelligence inference operations includes: Limit the CPU quota for AI inference threads below a preset threshold and block non-urgent voice broadcasts and screen pop-up interactions. The restrictions on resource usage and interactive feedback intensity are lifted, including: lifting the central processing unit quota restrictions and allowing full voice broadcasting, screen display, and message push interaction.

[0008] Preferably, acquiring task data specifically includes: The system receives user commands via an in-vehicle terminal or via a mobile terminal bound to the vehicle, assigns a unique identifier to the user commands, and generates structured task data. The structured task data is stored in a task queue to form an intent record pool, and the task status is initialized to pending processing. Based on a preset task decomposition strategy, the structured task data is semantically parsed to split the structured task data into at least one subtask, and the type of each subtask is marked; the types include pure computation subtasks and physical control subtasks. Establish a dependency tree between subtasks, and update and store the task data with subtask type tags and dependency relationships into the intent record pool.

[0009] Preferably, the task data is executed in either background silent mode or active calculation mode, specifically including: Read subtasks with a pending status from the intent recording pool; Based on the type of the subtask read and the current vehicle status, determine the set of subtasks that can be executed, as well as the execution timing of the subtasks in the set; wherein, in the background silent mode, the execution of subtasks involving vehicle movement in the physical control subtasks is prohibited, while the execution of pure calculation subtasks is allowed; in the active calculation mode, the execution of all types of subtasks is allowed. For physical control subtasks involving vehicle motion that are allowed to be executed, convert them into vehicle control protocol frames; After reading vehicle sensor data and confirming that the safety execution conditions are met, the protocol frame is sent to the corresponding vehicle domain controller to execute the corresponding physical action.

[0010] Preferably, the safe execution conditions are confirmed to be met, specifically including: Data on the vehicle's surrounding environment is collected using radar or camera sensors. When the surrounding environment data indicates that the distance to obstacles is greater than a preset safe distance threshold, and no pedestrians or animals are detected on the travel path, it is determined that the safe execution conditions are met.

[0011] Preferred options also include: When a task being executed is interrupted due to the vehicle state switching to driving state, the task is marked as suspended and updated in the intent record pool. Once the vehicle status switches to parked, the task in the suspended state is read from the intent recording pool and automatically resumed execution.

[0012] Preferred options also include: After the task is completed, an execution report is generated, and the execution results are synchronized to the user's bound terminal device; Receive user feedback data on the execution results, including satisfaction ratings or modification actions on the task results; The user preference model weights are updated based on the feedback data, and the parsing priority coefficients in the preset task decomposition strategy are adjusted based on the updated user preference model weights, or the threshold for switching between the background silent mode and the active calculation mode is adjusted.

[0013] Preferably, the vehicle status signal further includes a charging gun connection status signal; When the vehicle speed signal indicates that the vehicle speed is zero, the gear signal indicates that the gear is park, and the charging gun connection status signal indicates that the charging gun is connected, the vehicle is determined to be in a charging state, and the task data is executed in the active calculation mode.

[0014] Secondly, an adaptive execution system for in-vehicle hybrid artificial intelligence tasks is provided, comprising: The task receiving module is used to acquire task data; The status perception module is used to acquire vehicle status signals and determine whether the vehicle is currently in a driving state or a parked state based on the vehicle status signals. The scheduling and execution module is used to execute the task data in a background silent mode if the vehicle is determined to be in motion, and to execute the task data in an active calculation mode if the vehicle is determined to be parked. In the background silent mode, execution of physical control sub-tasks involving vehicle movement is prohibited, and resource consumption and interactive feedback intensity of artificial intelligence inference operations are limited. In the active calculation mode, execution of physical control sub-tasks involving vehicle movement is permitted, and the restrictions on resource consumption and interactive feedback intensity are lifted.

[0015] The beneficial effects of the technical solutions provided in this application include: By establishing a dynamic binding relationship between the vehicle's physical state and computation scheduling strategies, the conflict between vehicle computing resources and driving safety in existing technologies is resolved. While in motion, a forced background silent mode is implemented, eliminating the distraction of screen pop-ups and voice announcements from the driver's attention, significantly improving driving safety. When parked or charging, the system switches to active computing mode, transforming idle onboard high-performance computing chips into high-performance computing nodes, fully utilizing hardware resources to handle demanding AI tasks. This adaptive mechanism avoids sacrificing computing power utilization for safety, and also prevents sacrificing safety for computing power utilization, achieving an optimal balance between computing resources and driving safety. It maximizes the economic and safety value of onboard hardware, ensuring safety while fully utilizing idle computing power during parking and charging, thus improving hardware utilization. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating the general flow of the adaptive execution method for in-vehicle hybrid artificial intelligence tasks proposed in this application; Figure 2 This is a schematic diagram of the task data acquisition and processing flow for vehicle-mounted hybrid artificial intelligence tasks in this application; Figure 3 This is a schematic diagram illustrating the vehicle state switching and task breakpoint resume process for in-vehicle hybrid artificial intelligence tasks in this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] This application relates to the fields of intelligent connected vehicles, large-scale artificial intelligence models, edge computing, and human-machine collaboration. Specifically, it relates to a system and method that treats a car as a mobile intelligent agent capable of independently performing AI calculations (such as large-scale model inference, content generation, and data analysis) and possessing physical control capabilities. This system supports users to delegate, schedule, and iterate multiple AI tasks across multiple terminals, including mobile phones, computers, and in-vehicle systems. The system autonomously determines the timing and order of execution and performs task calculations and feedback differently depending on whether the vehicle is in motion or parked.

[0019] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0020] In-vehicle hybrid AI tasks refer to composite tasks formed by logically linking "pure computational subtasks" (such as text generation and data analysis, which only consume CPU / GPU computing power) and "physical control subtasks" (such as controlling car windows and moving the vehicle, which require calling the vehicle control interface).

[0021] AI computing entities: These refer to vehicles that are upgraded from simple means of transportation into system units with independent large-scale model inference capabilities, data generation capabilities, and physical control, equivalent to mobile phones or computers. They possess general large-scale model inference capabilities (built-in or cloud-based, supporting text generation, code writing, data analysis, etc.) and physical control capabilities (achieving vehicle movement, door and window control, etc. through onboard drive-by-wire, sensors, and actuators).

[0022] Intent Recording Pool: A cross-device task queue buffer. It stores user-inputted task commands that are not immediately executed. It supports task queuing, persistent storage, status marking (e.g., pending, suspended, completed), and priority adjustment. Users can input work content requiring AI processing at any time on any device (mobile phone, computer, in-vehicle system), forming a continuously accumulating intent record. Input formats include text, voice clips, images, file attachments, and to-do lists.

[0023] Background silent mode: While the vehicle is in motion, AI tasks consume computing power but do not interfere with the driving interface or generate strong interactive feedback. Features include limited resource usage and blocking non-emergency interactions.

[0024] Active computing mode: When the vehicle is parked or idle, the system autonomously wakes up computing resources, actively executes tasks and pushes the results like a server. Features include removing resource restrictions and allowing physical vehicle control.

[0025] Pre-defined task decomposition strategy: The system's built-in business logic rule library guides the large model on how to break down user instructions into subtasks. For example, a rule can stipulate that "instructions involving vehicle movement must be marked as physical control subtasks".

[0026] User preference model weights: system configuration parameters used to quantify user habits. In this application, they are essentially parameter values ​​that affect business logic rules (such as parsing priority coefficients and mode switching thresholds), rather than simply weights within the algorithm model.

[0027] Vehicle control protocol frame: refers to the conversion of AI decision commands into signal frames (such as SOME / IP signals) that can be recognized by the vehicle bus (such as CAN bus, Ethernet) and sent to the domain controller.

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0029] Firstly, see Figures 1-3 This application provides an adaptive execution system for in-vehicle hybrid artificial intelligence tasks, the core of which lies in establishing a dynamic binding relationship between vehicle state and computation scheduling. Structurally, the system is divided into three core modules, each integrating specific functional units to support the various functions outlined in the technical disclosure, specifically including: The task receiving module is used to acquire task data; The internal integration unit of the task receiving module is: a multi-terminal task delegation and iteration unit and an intent recording pool unit.

[0030] Implementation details: Users can assign tasks to the vehicle at any time via a unified account through a mobile app, computer web / client, and in-vehicle infotainment screen. Multiple input methods are supported, including text, voice, and file attachments. After receiving an instruction, the module assigns a unique identifier, generates structured task data, and stores it in an intent recording pool. Multi-task queue management (priority adjustment, serial / parallel execution) and task iteration (adding instructions, modifying requirements, multi-turn conversational iteration) are supported. Task status is synchronized to all terminals in real time.

[0031] The status perception module is used to acquire vehicle status signals and determine whether the vehicle is currently in a driving or parked state based on the vehicle status signals. The internal integration unit of the state awareness module is an engine that integrates state awareness and execution timing judgment.

[0032] Implementation details: The system reads vehicle status signals (vehicle speed, gear position, handbrake, charging gun connection status, etc.) and computing resource load (vehicle chip load, cloud quota remaining) in real time via CAN bus or vehicle Ethernet gateway. An internal state machine is established, with intelligent judgment logic including: driving (vehicle speed > 0 or not in P gear), parked (vehicle speed = 0, in P gear, and handbrake engaged), and charging (charging gun connected). The judgment results are directly output to the scheduling execution module.

[0033] The scheduling and execution module is used to execute task data in a silent background mode if the vehicle is determined to be in motion, and in an active calculation mode if the vehicle is determined to be parked. In the silent background mode, execution of physical control subtasks involving vehicle movement is prohibited, and resource consumption and interactive feedback intensity for AI inference calculations are limited. In the active calculation mode, execution of physical control subtasks involving vehicle movement is permitted, and the restrictions on resource consumption and interactive feedback intensity are lifted.

[0034] The internal integration units of the scheduling and execution module are: an abstraction layer for automotive AI computing entities, a driving / parking adaptive computing unit, a task scheduling and plan execution engine, and a continuous learning and task memory unit.

[0035] Specific implementation: AI capability support: The car is defined as an AI computing entity with a built-in hybrid task orchestration engine that can link "information computing → physical action" into a composite task.

[0036] Mode switching: Based on the output of the status awareness module, automatically switch between background silent mode and active calculation mode.

[0037] Task execution: Supports time-triggered, condition-triggered, and sequentially dependent tasks. Tasks are read from the intent recording pool, and semantic decomposition and security verification are performed. Radar / camera data is read before physical actions to confirm safety.

[0038] Feedback and Learning: Results are pushed out upon task completion. User tasks are recorded long-term, and task scheduling strategies are optimized (such as adjusting parsing priority coefficients) based on execution success rates and user feedback to achieve continuous learning.

[0039] Secondly, embodiments of this application provide an adaptive execution method for in-vehicle hybrid artificial intelligence tasks, addressing the conflict between vehicle computing resources and driving safety, and providing the following specific steps: Step 100: Acquire task data and vehicle status signals; Step 200: Determine the vehicle's status based on the vehicle status signal.

[0040] Step 300: If it is determined that the vehicle is in motion, execute the task data in the background silent mode.

[0041] If the vehicle is determined to be parked, the task data is executed in active calculation mode.

[0042] In the background silent mode, physical control subtasks involving vehicle movement are prohibited from being executed, and the resource consumption and interactive feedback intensity of artificial intelligence inference operations are limited.

[0043] In active computing mode, physical control subtasks involving vehicle motion are allowed to be executed, and the limitations on resource consumption and interaction feedback intensity are removed.

[0044] The vehicle status signals mentioned above include at least the vehicle speed signal, gear signal, and handbrake status signal. The specific determination method is as follows: When the vehicle speed signal is greater than zero, or the gear position signal indicates that the gear is not the parking gear (P gear), it is determined to be in a driving state.

[0045] When the vehicle speed signal is zero, the gear position signal indicates that the gear is park, and the handbrake status signal indicates that the handbrake is engaged, the vehicle is considered to be in a parked state.

[0046] The vehicle status signals also include the charging gun connection status signal. When the vehicle speed signal indicates that the vehicle speed is zero, the gear signal indicates that the gear is in park, and the charging gun connection status signal indicates that the charging gun is connected, the vehicle is determined to be in charging mode, and task data is executed in active calculation mode.

[0047] Examples of its application scenarios: A user is driving to work and assigns three tasks to their car via their mobile phone: Task 1. "Help me generate a 5-page quarterly report PPT outline, highlighting sales growth." Task 2. "Analyze last month's driving data and identify the dates with the most rapid accelerations." Task 3. "Upon arrival at the company, if the remaining battery level is below 30%, automatically search for three nearby fast charging stations and compare their prices." The system detects that the vehicle is in motion and automatically puts all tasks into a silent background computing mode. Tasks 1 and 2 call upon large models on the vehicle or cloud for inference, without occupying the central control screen, only consuming chip computing power. The driver's dashboard remains unaffected, and navigation and music continue normally. Task 2 completes after 5 minutes, and the system provides a brief voice prompt: "The day with the most rapid acceleration last month was March 12th; details have been sent to your phone." The user does not need to view this and can continue driving. Task 1 continues to generate during the journey and automatically completes upon arrival at the destination. After the user parks, a prompt appears on the vehicle's screen: "The PPT outline has been generated; you can view it or continue to modify it." Task 3 checks the battery level (28%) upon arrival at the company, automatically calculates the ratings, prices, and distances of three nearby fast charging stations, and pushes them to the user's phone.

[0048] The above method uses the CAN bus or vehicle Ethernet gateway to read sensor signals in real time and establish a state machine. The state machine output is directly mapped to the execution strategy table.

[0049] By establishing a dynamic binding relationship between the vehicle's physical state and computational scheduling strategies, the above approach resolves the conflict between vehicle computing resources and driving safety in existing technologies. When in motion, a forced background silent mode eliminates the distraction to the driver caused by screen pop-ups and voice announcements, significantly improving driving safety. When parked or charging, it switches to active computing mode, transforming idle onboard high-performance computing chips into high-performance computing nodes, fully utilizing hardware resources to handle demanding AI tasks. This adaptive mechanism avoids sacrificing computing power utilization for safety, and also prevents sacrificing safety for computing power utilization, achieving an optimal balance between computing resources and driving safety. It maximizes the economic and safety value of onboard hardware, ensuring safety while fully utilizing idle computing power during parking and charging, thus improving hardware utilization.

[0050] It should be noted that the resource occupancy intensity in this application embodiment refers to the degree of consumption of onboard computing hardware resources during the execution of artificial intelligence tasks. Specific measurement indicators include, but are not limited to: CPU utilization rate, GPU computing power utilization rate, RAM utilization, and network bandwidth utilization rate. For example, limiting resource occupancy intensity can be achieved by limiting CPU utilization rate to no more than a preset threshold (such as 30%), or by limiting memory usage to no more than a specific size.

[0051] In this application's embodiments, the intensity of interactive feedback refers to the degree of interference when the in-vehicle system outputs task results to the user or performs interactions. Specific metrics include, but are not limited to: the frequency of interactive feedback (e.g., the number of pop-ups per unit time) and the modality of interactive feedback (e.g., using only silent log recording, reducing voice broadcast volume, or simplifying screen display content). For example, in resource-constrained or security-sensitive situations, reducing the intensity of interactive feedback can manifest as pausing voice broadcast, recording task results only through background logs, or reducing the number of times the screen is turned on.

[0052] In this embodiment, the current state of the vehicle is simplified and classified into driving state and parking state. It should be noted that the parking state here is a broad concept, which includes not only the state where the vehicle is in park (P) gear and the handbrake is engaged, but also the state where the vehicle is connected to a charging facility (regardless of the gear, as long as the vehicle is stationary and connected to a charging facility).

[0053] Specifically, when the system detects that the vehicle is in a charging state, it logically classifies it as a specific scenario of a parked state, and thus executes the same active computing mode (i.e., low resource constraint mode) as in the parked state. This design is because in the charging state, the vehicle's power battery is connected to an external power source, computing resources are relatively abundant, and there is no driving safety risk to the vehicle, which is consistent with the characteristics of the parked state. Therefore, the implementation of the parked state includes the detection and processing logic for the charging state.

[0054] In some preferred embodiments, the specific technical means for limiting and removing restrictions on resource consumption and interactive feedback are detailed below: Limit the CPU usage of AI inference threads below a preset threshold (e.g., 30%) and disable non-urgent voice announcements and on-screen pop-ups. Only allow feedback via status bar icons or weak prompts.

[0055] Removes central processing unit quota restrictions, allowing the use of high-performance NPU / GPU for heavy inference, and enables full voice broadcasting, screen display, and message push interaction.

[0056] The above approach limits resource quotas for specific processes through the operating system-level resource scheduler and intercepts interaction requests through the HMI manager. Specifically, the collaborative work of the operating system-level resource scheduler and the HMI manager enables fine-grained resource and interaction control. While in motion, the CPU quota for AI inference threads is limited to below a preset threshold to ensure the computing power priority for core safety functions such as navigation and driver assistance, preventing safety risks caused by system lag; simultaneously, non-emergency interactions are disabled to reduce the driver's cognitive load. When parked, resource restrictions are lifted and high-performance NPU / GPUs are utilized, enabling the vehicle's infotainment system to execute large-scale model inference tasks at the cloud level. This differentiated resource allocation strategy ensures safety and execution efficiency in different scenarios from the system's underlying layer, ensuring that critical driving functions are not interfered with while releasing idle computing power potential, preventing task execution from preempting the computing power of navigation or driver assistance systems, and eliminating visual and auditory interference.

[0057] In some preferred embodiments, the following description is provided to illustrate the process of acquiring and preprocessing task data: Multi-terminal reception: Receive user commands via the vehicle-mounted terminal, or receive user commands sent by a mobile terminal bound to the vehicle.

[0058] Pooling process: A unique identifier (ID) is assigned to each user command to generate structured task data. The structured task data is stored in a task queue to form an intent record pool, and the task status is initialized to pending processing.

[0059] Semantic decomposition: Based on a preset task decomposition strategy, semantic parsing is performed on structured task data. The structured task data is split into at least one subtask, and the type of each subtask is marked (pure computation subtask or physical control subtask).

[0060] Dependency establishment: Establish a dependency tree between subtasks and update the task data with subtask type tags and dependency relationships into the intent record pool.

[0061] Application scenario example: Users can input the work content that needs to be processed by AI at any time on any terminal, forming a continuously accumulating "intent record pool".

[0062] Example inputs include: "Remind me to get my car serviced next Wednesday", "Analyze the fuel price data for the past 3 years when you have time", "Calculate the cost-effectiveness of different charging stations next time you charge your car", "Organize all my itineraries from last week and generate a business trip expense report", and "AI generates a report on the prospects of AI applications".

[0063] The context understanding and task decomposition unit performs semantic parsing of the user's natural language records, automatically identifying task types, dependencies, and estimated execution time. It breaks down ambiguous intents into executable subtasks. For example: "When you have time, help me analyze this month's fuel consumption data" → Subtask 1: Wait for the vehicle to have sufficient parking time; Subtask 2: Read fuel consumption API data; Subtask 3: Generate an analysis report. The sequence scheduling and feedback unit automatically arranges tasks from the intent pool into the main task queue based on the judgment engine's output and sets the execution order. After each task is completed, the results are automatically pushed to all of the user's devices. Users can view the current status of all tasks in the "intent record pool" at any time through any device.

[0064] The above uses a database queue to achieve asynchronous storage of tasks and a large model interface to perform semantic slot filling and intent recognition.

[0065] Results: This solution addresses the limitations of time and space in task execution and the insufficient processing capacity for complex tasks. The intent pool enables cross-device delegation and asynchronous execution of tasks. Specifically, this embodiment breaks the traditional time and space limitations of in-vehicle tasks, which must be initiated and completed instantly within the vehicle, by introducing an intent recording pool and a task decomposition mechanism. Users can delegate tasks at any time via mobile phones, computers, and other devices. The system achieves time decoupling between task initiation and execution through structured storage and dependency tree establishment. This not only supports cross-device task continuity and state synchronization but also enables the system to handle complex hybrid tasks involving "information retrieval + physical vehicle control." By semantically parsing fuzzy intents into executable sub-task sequences, the system's ability to orchestrate complex workflows and its processing success rate are significantly improved, allowing users to flexibly schedule vehicle computing power as if using a computer.

[0066] In some preferred embodiments, the following description is provided to illustrate the specific execution logic of task scheduling and security loop: Reading and Scheduling: Read subtasks with a pending status from the intent record pool. Based on the type of the read subtask and the current vehicle status, determine the set of subtasks that can be executed, and the execution timing of the subtasks in the set.

[0067] Differentiated execution modes: In background silent mode, execution of subtasks involving vehicle movement within the physical control subtasks is prohibited, while execution of pure computational subtasks is permitted; in active computation mode, execution of all types of subtasks is permitted.

[0068] Physical control link: For physical control subtasks involving vehicle motion that are allowed to be executed, they are converted into vehicle control protocol frames.

[0069] Safety verification: Read vehicle sensor data, and after confirming that the safety execution conditions are met, send the protocol frame to the corresponding vehicle domain controller to execute the corresponding physical action.

[0070] The criteria for determining whether the safe operation conditions are met include: collecting environmental data about the vehicle's surroundings using radar or camera sensors. If the environmental data indicates that the distance to obstacles is greater than a preset safe distance threshold, and no pedestrians or animals are detected on the travel path, the safe operation conditions are deemed met.

[0071] Application scenario example: Before going to sleep at home, users can assign a series of overnight tasks to their cars via their computers: 22:00: "Help me transcribe the transcripts of all today's meeting recordings (attached)." 23:00: "Generate a three-day road trip itinerary, including routes, accommodation recommendations, and charging station planning." The next day at 07:00: "Check vehicle tire pressure, fuel level / battery level, and generate a health report." The following day at 07:30: "If the temperature is below 0 degrees Celsius, turn on the seat heaters in advance." Execution process: The vehicle is parked in the garage, and the system enters low-power active computing mode. At 22:00, speech-to-text and summary generation begin on time and are automatically saved upon completion. At 23:00, the system calls a large model to generate a self-driving tour guide, taking 15 minutes, and the results are pushed to the user's mobile phone and computer. The following day at 07:00, the vehicle automatically wakes up the sensors, generates a health report, and pushes it. At 07:30, a temperature of -2°C is detected, and the seat heaters are automatically turned on. Throughout the entire process, the user does not need to enter the car; the car autonomously completes the task like a reliable AI computer.

[0072] The above addresses the technical challenge of the disconnect between general AI inference capabilities and vehicle physical control capabilities. It achieves a closed loop from AI decision-making to vehicle hardware control, and ensures the safety of physical control through specific sensor logic judgments, avoiding the risks of blind vehicle control. Specifically, it constructs a complete closed-loop link from AI digital decision-making to vehicle physical actions, resolving the disconnect between general AI inference and vehicle hardware control capabilities. By converting tasks into vehicle control protocol frames and sending them to the domain controller, it enables direct AI-driven vehicle hardware. In particular, the introduction of safety verification logic based on radar and camera data before executing physical actions ensures that actions are only performed when obstacle distance is safe and there are no pedestrians. This mechanism not only endows the car with the ability to autonomously execute physical tasks but also avoids the risks of blind vehicle control through multiple safety checks, increasing user trust in AI-controlled vehicle hardware and achieving truly intelligent autonomous services.

[0073] In some preferred embodiments, regarding task interruption and resume, the task processing mechanism when the vehicle state changes dynamically is described below, specifically including: Interruption handling: When a task being executed is interrupted due to a change in vehicle state to driving state (e.g., from parked to driving), the task is marked as suspended and updated in the intent record pool.

[0074] Resume execution: After the vehicle status changes to parked, read the suspended tasks from the intent record pool and automatically resume execution.

[0075] Application scenario example: The user assigns a task on their phone: "Write a short article about new energy vehicle battery technology, around 800 words." While driving, a draft is generated in the background. The user enters the car and uses the in-car voice system to request: "Change the third paragraph to compare lithium iron phosphate and ternary lithium batteries, and add a table." The system iterates and modifies the code based on the context. After the user gets out of the car, they view the final version on their computer and add, "Translate it into English." The system then translates it again while the car is parked and pushes the translation to their phone. The entire process is seamlessly synchronized.

[0076] In addition, when a task being executed is interrupted due to the vehicle's status changing to a driving state, the task is marked as suspended and updated in the intent record pool; once the vehicle's status changes to a parked state, the suspended task is read from the intent record pool and execution is automatically resumed.

[0077] The task state machine listens for vehicle status signal changes, triggers state transition logic, and persists the task context. This further addresses the spatiotemporal limitations of task execution, ensuring tasks are not lost due to vehicle status changes and improving task continuity and user experience. Specifically, by listening for vehicle status change events through the task state machine, breakpoint resumption and context persistence are achieved during task execution. When the vehicle status changes from parked to moving, the system automatically suspends the task and saves it to the intent recording pool to prevent task interruption or data loss due to sudden state changes; when the vehicle parks again, execution automatically resumes. This mechanism ensures that long-running tasks (such as report generation and data analysis) can be completed continuously across different vehicle operation stages without requiring users to repeat commands. It greatly improves the continuity and reliability of task execution and optimizes the user's interactive experience in dynamic vehicle usage environments.

[0078] In some preferred embodiments, please refer to the following description regarding user feedback and system adaptive optimization: Results Synchronization: After the task is completed, an execution report is generated, and the execution results are synchronized to the user's bound terminal device.

[0079] Feedback collection: Receive user feedback data on the execution results, including satisfaction ratings or modifications made to the task results.

[0080] Parameter adjustment: Update the user preference model weights based on feedback data, and adjust the parsing priority coefficients in the preset task decomposition strategy based on the updated user preference model weights, or adjust the judgment threshold for switching between background silent mode and active calculation mode.

[0081] Application scenario example: Users often assign tasks to their cars on Friday nights to "plan weekend trips".

[0082] After the system learns, it proactively pops up a suggestion at 5 pm on Friday (when the vehicle is parked): "It has been detected that you plan your weekend itinerary every Friday. Do you want to execute it now? This time, the recommended destination is Xishan Hot Spring. The route has been planned and tickets have been booked for you." After user confirmation, the system automatically completes multiple sub-tasks such as booking, route planning, and in-vehicle atmosphere preset.

[0083] This section emphasizes the optimization of business logic rules. For example, if a user repeatedly cancels long voice broadcasts while driving, the system will lower the "voice broadcast threshold while driving" parameter; if a user prefers to receive long reports while parked, the priority coefficient of the "report generation" task in the task decomposition strategy will be adjusted. Here, "model weight" refers to the numerical value that affects system configuration parameters.

[0084] The above addresses the system's lack of adaptive evolution capabilities. It enables the system to optimize scheduling strategies based on user habits, demonstrating its intelligence and evolutionary capabilities. Specifically, by collecting user feedback data and updating preference model weights, the system gains adaptive evolutionary capabilities, solving the problem of existing in-vehicle systems having fixed rules and being unable to adapt to user habits. The system can dynamically adjust the parsing priority coefficients and mode switching thresholds in the task decomposition strategy based on user satisfaction ratings or modified behavior. For example, it can automatically reduce the frequency of voice broadcasts while driving or adjust task queuing priorities. This optimization mechanism based on business logic parameters allows the system to better understand user habits over time, reducing invalid interactions and achieving personalized and intelligent evolution of scheduling strategies, significantly improving long-term user experience satisfaction.

[0085] Thirdly, embodiments of this application provide an adaptive execution device for in-vehicle hybrid artificial intelligence tasks. This adaptive execution device can be a personal computer (PC), laptop, server, in-vehicle domain controller, or smart cockpit host, or any other device with data processing capabilities. The device is deployed in the cloud, in the vehicle, or on a user terminal, and interacts with the vehicle and other terminals through a communication network to jointly implement the technical solution of this application.

[0086] In this embodiment, the adaptive execution device for in-vehicle hybrid artificial intelligence tasks may include a processor, a memory, a communication interface, and a communication bus.

[0087] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0088] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal devices within the adaptive execution device for in-vehicle hybrid AI tasks, as well as interfaces used for interconnecting the adaptive execution device for in-vehicle hybrid AI tasks with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0089] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0090] The processor can be a general-purpose processor, which can call an adaptive execution program for in-vehicle hybrid artificial intelligence tasks stored in memory and execute the adaptive execution method for in-vehicle hybrid artificial intelligence tasks provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the adaptive execution program for in-vehicle hybrid artificial intelligence tasks is called can refer to the various embodiments of the adaptive execution method for in-vehicle hybrid artificial intelligence tasks in this application, and will not be repeated here.

[0091] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0092] The present application provides a computer-readable storage medium storing an adaptive execution program for in-vehicle hybrid artificial intelligence tasks, wherein when the adaptive execution program for in-vehicle hybrid artificial intelligence tasks is executed by a processor, it implements the steps of the adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described above.

[0093] The method implemented when the adaptive execution program for in-vehicle hybrid artificial intelligence tasks is executed can be referred to in various embodiments of the adaptive execution method for in-vehicle hybrid artificial intelligence tasks in this application, and will not be repeated here.

[0094] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0095] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0096] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0097] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0098] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0099] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0100] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An adaptive execution method for in-vehicle hybrid artificial intelligence tasks, characterized in that, It includes: Acquire task data and vehicle status signals, and determine the vehicle's status based on the vehicle status signals; If the vehicle is determined to be in motion, the task data will be executed in background silent mode. If the vehicle is determined to be parked, the task data is executed in active calculation mode; In the background silent mode, physical control subtasks involving vehicle movement are prohibited from execution, and the resource consumption and interactive feedback intensity of artificial intelligence inference operations are limited. In the active computing mode, physical control subtasks involving vehicle movement are allowed to be executed, and the restrictions on resource consumption and interactive feedback intensity are lifted.

2. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 1, characterized in that: The vehicle status signals include at least the vehicle speed signal, gear signal, and handbrake status signal; The step of determining whether the vehicle is currently in a driving or parked state based on the vehicle status signal includes: When the vehicle speed signal is greater than zero, or when the gear position signal indicates that the gear is not the parking gear, it is determined to be the driving state; When the vehicle speed signal is equal to zero, the gear position signal indicates that the gear is parking, and the handbrake status signal indicates that the handbrake is engaged, the parking state is determined.

3. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 1, characterized in that: Limiting the resource consumption and interactive feedback intensity of artificial intelligence inference operations, including: Limit the CPU quota for AI inference threads below a preset threshold and block non-urgent voice broadcasts and screen pop-up interactions. Removing the restrictions on resource usage and interactive feedback intensity includes: Remove the central processing unit quota limit and allow full voice broadcasting, screen display, and message push interaction.

4. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 1, characterized in that, Obtain task data, specifically including: The system receives user commands via an in-vehicle terminal or via a mobile terminal bound to the vehicle, assigns a unique identifier to the user commands, and generates structured task data. The structured task data is stored in a task queue to form an intent record pool, and the task status is initialized to pending processing. Based on a preset task decomposition strategy, the structured task data is semantically parsed to split the structured task data into at least one subtask, and the type of each subtask is marked; the types include pure computation subtasks and physical control subtasks. Establish a dependency tree between subtasks, and update and store the task data with subtask type tags and dependency relationships into the intent record pool.

5. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 4, characterized in that, The task data is executed in either background silent mode or active computing mode, specifically including: Read subtasks with a pending status from the intent recording pool; Based on the type of the subtask read and the current vehicle status, determine the set of subtasks that can be executed, as well as the execution timing of the subtasks in the set; wherein, in the background silent mode, the execution of subtasks involving vehicle movement in the physical control subtasks is prohibited, while the execution of pure calculation subtasks is allowed; in the active calculation mode, the execution of all types of subtasks is allowed. For physical control subtasks involving vehicle motion that are allowed to be executed, convert them into vehicle control protocol frames; After reading vehicle sensor data and confirming that the safety execution conditions are met, the protocol frame is sent to the corresponding vehicle domain controller to execute the corresponding physical action.

6. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 5, characterized in that, Confirm that the conditions for safe execution are met, specifically including: Data on the vehicle's surrounding environment is collected using radar or camera sensors. When the surrounding environment data indicates that the distance to obstacles is greater than a preset safe distance threshold, and no pedestrians or animals are detected on the travel path, it is determined that the safe execution conditions are met.

7. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 5, characterized in that, Also includes: When a task being executed is interrupted due to the vehicle state switching to driving state, the task is marked as suspended and updated in the intent record pool. Once the vehicle status switches to parked, the task in the suspended state is read from the intent recording pool and automatically resumed execution.

8. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 4, characterized in that, Also includes: After the task is completed, an execution report is generated, and the execution results are synchronized to the user's bound terminal device; Receive user feedback data on the execution results, including satisfaction ratings or modification actions on the task results; The user preference model weights are updated based on the feedback data, and the parsing priority coefficients in the preset task decomposition strategy are adjusted based on the updated user preference model weights, or the threshold for switching between the background silent mode and the active calculation mode is adjusted.

9. The adaptive execution method for in-vehicle hybrid artificial intelligence tasks as described in claim 2, characterized in that: The vehicle status signal also includes the charging gun connection status signal; When the vehicle speed signal indicates that the vehicle speed is zero, the gear signal indicates that the gear is park, and the charging gun connection status signal indicates that the charging gun is connected, the vehicle is determined to be in a charging state, and the task data is executed in the active calculation mode.

10. An adaptive execution system for in-vehicle hybrid artificial intelligence tasks, characterized in that, It includes: The task receiving module is used to acquire task data; The status perception module is used to acquire vehicle status signals and determine whether the vehicle is currently in a driving state or a parked state based on the vehicle status signals. The scheduling and execution module is used to execute the task data in a background silent mode if it is determined that the vehicle is in motion. If the vehicle is determined to be parked, the task data is executed in active computing mode. In the background silent mode, physical control subtasks involving vehicle movement are prohibited from execution, and the resource consumption and interactive feedback intensity of artificial intelligence inference operations are limited. In the active computing mode, physical control subtasks involving vehicle movement are allowed to be executed, and the restrictions on resource consumption and interactive feedback intensity are lifted.

Images