An ai model real-time scheduling method based on a classic autosar architecture and a related device thereof

Abstract

The application provides an AI model real-time scheduling method based on a classic AUTOSAR architecture and related equipment, and relates to the technical field of domain controllers. By constructing a cross-level data processing mechanism in the classic AUTOSAR architecture of a power domain controller, unified reception and standardized conversion of original control intention data of AI models of different deployment levels such as cloud-side and vehicle-side intelligent driving domains and on-board coprocessors are realized. Heterogeneous data is parsed and mapped into a signal group conforming to the AUTOSAR standard through a protocol abstraction conversion module in an application layer software component, high-reliability target execution instructions are generated in combination with a dynamic check arbitration mechanism of a vehicle operating state, and finally, the AI model decision result can enter an actuator control channel with millisecond-level precision, relying on deep coupling of a runtime environment interface and a real-time operating system task scheduling queue, so that the strict requirements of the classic AUTOSAR architecture on functional safety are met, and the collaborative efficiency and response real-time performance of multi-source AI models in complex vehicle control scenarios are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of domain controller technology, and in particular to a real-time scheduling method for AI models based on the classic AUTOSAR architecture and related equipment. Background Technology

[0002] With the rapid development of internet technology, the integration and application of artificial intelligence in vehicle control is gradually deepening. However, the current industry status quo mainly remains at the simple application level of conventional artificial intelligence models, where the model directly makes decisions to execute or not execute after inference, aiming to initially achieve the combination of artificial intelligence and vehicle control. But this extensive integration approach has significant technical bottlenecks. Due to the inherent black-box nature of artificial intelligence models and the unavoidable latency issues during inference, they lack transparency and predictability when processing critical control commands. This makes it difficult for existing application solutions to fully meet the stringent functional safety requirements of national standards. At the same time, this direct coupling approach also performs poorly in terms of compatibility, especially with limited adaptability to real-time operating systems running on domain controllers. It is difficult to effectively support complex vehicle control tasks while ensuring real-time system response, thus restricting the improvement of the safety and reliability of intelligent travel experiences. Summary of the Invention

[0003] The purpose of this invention is to provide a real-time scheduling method for AI models based on the classic AUTOSAR architecture and related equipment, so as to solve one or more technical problems existing in the prior art, and at least provide a beneficial option or create conditions to achieve efficient collaboration and accurate scheduling of multi-level AI models such as cloud, vehicle-side intelligent driving domain and onboard coprocessor in real-time operating system under the premise of meeting high functional safety requirements.

[0004] On the one hand, this application provides a real-time scheduling method for AI models based on the classic AUTOSAR architecture, applied to the power domain controller of a vehicle, wherein the power domain controller is deployed with the classic AUTOSAR architecture, and the method includes: Through the communication interface of the classic AUTOSAR architecture, raw control intent data from AI models at least two different deployment levels are received; the different deployment levels include the cloud, the vehicle-side intelligent driving domain, and the onboard coprocessor. Within the application layer software component of the classic AUTOSAR architecture, the original control intent data is abstracted and transformed according to the protocol, and parsed and mapped into a signal group that conforms to the AUTOSAR standard. Based on the vehicle's current operating status, the mapped signal group is validated and arbitrated to generate the target execution command; The target execution instructions are sent to the task scheduling queue of the real-time operating system through the runtime environment interface of the classic AUTOSAR architecture to control the underlying executor.

[0005] Furthermore, within the application layer software component of the classic AUTOSAR architecture, the original control intent data undergoes protocol abstraction and transformation, including: The application layer software component calls a pre-built parsing logic library to perform format verification and semantic parsing on the original control intent data, generating standardized interface data.

[0006] Furthermore, the rationality verification and arbitration of the mapped signal group based on the vehicle's current operating state includes: When a vehicle is detected to be in a transient state, the signal group priority of the AI ​​model at the corresponding level of the onboard coprocessor is increased according to a preset priority strategy, and non-real-time instructions from the cloud are blocked.

[0007] Furthermore, the rationality verification includes: Acquire the current sensor data of the vehicle and determine whether the execution action corresponding to the mapped signal group exceeds the current physical limit of the vehicle. The physical limit includes the vehicle chassis dynamic stability boundary or the actuator saturation threshold. If the signal exceeds the limit, the signal group is truncated or modified to generate a modified target execution instruction.

[0008] Furthermore, the method also includes: The AI ​​instruction parsing middleware in the application layer software component encapsulates non-standard AI protocol data packets into AUTOSAR communication layer signals, which are then transmitted and received via the controller area network bus or Ethernet interface.

[0009] Furthermore, the method also includes: The application layer software component sends a reverse wake-up command to the AI ​​model to trigger the AI ​​model in a dormant state to perform data inference.

[0010] Furthermore, the method also includes: The execution result of the target execution instruction is fed back to the corresponding AI model to optimize the inference logic of the AI ​​model.

[0011] On the other hand, this application provides a real-time scheduling system for AI models based on the classic AUTOSAR architecture, the system comprising: The power domain controller includes a multi-core processor, communication interface, and bus transceiver; A real-time operating system is deployed on the power domain controller; The classic AUTOSAR architecture, deployed on top of the real-time operating system, includes an application layer and a runtime environment; The application layer includes at least one AUTOSAR software component, which is configured to perform the steps of the aforementioned real-time scheduling method for AI models based on the classic AUTOSAR architecture.

[0012] On the other hand, this application provides an electronic device, including: One or more processors; Memory, used to store one or more computer programs; When the one or more computer programs are executed by the one or more processors, the electronic device implements the aforementioned real-time scheduling method for AI models based on the classic AUTOSAR architecture.

[0013] On the other hand, this application provides a vehicle including the aforementioned real-time scheduling system for AI models based on the classic AUTOSAR architecture.

[0014] The beneficial effects of this invention are as follows: This application provides a real-time scheduling method for AI models based on the classic AUTOSAR architecture. By constructing a cross-level data processing mechanism within the classic AUTOSAR architecture of the power domain controller, it achieves unified reception and standardized transformation of raw control intent data from AI models deployed at different levels, including cloud-based vehicle-side intelligent driving domains and onboard coprocessors. This not only breaks down the data barriers caused by the dispersed model deployment in traditional vehicle control systems, but also uses a protocol abstraction and conversion module within the application layer software components to parse and map heterogeneous data into signal groups conforming to the AUTOSAR standard. Combined with a dynamic verification and arbitration mechanism for vehicle operating status, it generates highly reliable target execution instructions. Finally, relying on the deep coupling between the runtime environment interface and the real-time operating system task scheduling queue, it ensures that the AI ​​model decision results can enter the actuator control channel with millisecond-level precision. This not only meets the stringent functional safety requirements of the classic AUTOSAR architecture, but also significantly improves the collaborative efficiency and real-time response of multi-source AI models in complex vehicle control scenarios. This application also provides related equipment for the above method. The beneficial effects of the related equipment are similar to those of the above method, and will not be elaborated here.

[0015] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0016] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation on the technical solutions of the present invention.

[0017] Figure 1 This is a flowchart of the real-time scheduling method for AI models based on the classic AUTOSAR architecture provided in this application; Figure 2 This is a schematic diagram of the logic principle for determining the feasible state of implementing AI scheduling, provided in this application. Figure 3 This is a schematic diagram of the execution logic of the AI ​​scheduling decision results provided in this application; Figure 4 This is a structural diagram of the real-time scheduling system for AI models based on the classic AUTOSAR architecture provided in this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0019] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0020] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] In the current process of automotive intelligence, with the continuous advancement of internet technology, the application of artificial intelligence (AI) technology in vehicle control is gradually being promoted. However, existing technical solutions mainly remain at the level of directly deciding whether to execute or not after conventional AI model inference, with the aim of initially realizing the integrated application of AI in vehicle control. While this simple integration method has achieved intelligence to a certain extent, it has exposed obvious limitations in practical applications.

[0023] First, due to the black-box nature of AI models and inference latency, existing technical solutions cannot fully meet the high requirements of national standard functional safety. Vehicle control is a field with extremely high safety requirements; the execution of any decision requires rigorous logical verification and safety assessment. However, existing AI models' direct decision-making mode lacks real-time monitoring and rationality verification of the vehicle's current operating state, failing to ensure safe and reliable decisions under various complex vehicle operating conditions. For example, when the control intent output by the AI ​​model conflicts with the vehicle's current physical limits, existing systems may fail to identify and correct this in a timely manner, leading to safety hazards.

[0024] Secondly, existing technical solutions have limited compatibility with real-time operating systems running on domain controllers. With the evolution of automotive electronic and electrical architectures, core components such as powertrain domain controllers typically deploy the classic AUTOSAR architecture to ensure system real-time performance and stability. Classic AUTOSAR (Classic Platform AUTOSAR, or CP for short) is the earliest established open standard software architecture in the automotive electronics field, specifically designed for embedded control units such as engines, transmissions, and chassis, which have extremely high requirements for real-time performance and functional safety. Its core lies in its rigorous layered architecture, successfully decoupling upper-layer application software from the underlying microcontroller hardware by introducing a "runtime environment" as middleware. This allows software components to be ported and reused across different hardware platforms. The classic AUTOSAR architecture mainly consists of an application layer, a runtime environment layer, a basic software layer, and a microcontroller layer. The basic software layer is further subdivided into a service layer, an ECU abstraction layer, and a microcontroller abstraction layer. This standardized design not only significantly reduces the complexity of software development but also solves the interoperability problem between different vendors through standardized interfaces and configuration methods, serving as the cornerstone for the stable operation of modern automotive electronic systems.

[0025] However, existing AI models suffer from compatibility issues with the classic AUTOSAR architecture, hindering efficient real-time interaction and collaborative control. This limits the application of AI models in vehicle control, preventing them from fully leveraging their decision-making advantages in complex scenarios. Furthermore, existing solutions are inadequate in the collaborative control of multiple AI models. In practical applications, vehicles may need to simultaneously run multiple AI models from different levels, including the cloud, the vehicle's intelligent driving domain, and onboard coprocessors. These models differ in scale, real-time requirements, and functional positioning. Existing systems lack a unified scheduling mechanism, failing to intelligently coordinate the control intentions of different AI models based on the vehicle's current operating status and conditions. This results in poor collaboration between multiple AI models, failing to meet the diverse needs of users in different scenarios.

[0026] In summary, existing technical solutions have significant shortcomings in functional safety, real-time operating system compatibility, and multi-AI model collaborative control, failing to meet the current demands of intelligent vehicle development for high safety, high real-time performance, and multi-scenario collaborative control. Therefore, a new technical solution is urgently needed to achieve real-time collaborative control of multiple AI models within the classic AUTOSAR architecture, ensuring the safety and reliability of vehicle control.

[0027] To address the aforementioned issues, this application proposes a multi-AI cross-domain software real-time collaborative method based on the classic AUTOSAR architecture. Its core lies in deploying a dedicated software component within the application layer of the classic AUTOSAR architecture of the power domain controller, serving as an intermediate layer for AI instruction parsing and scheduling. This method receives raw control intent data from AI models at different levels, including the cloud, the intelligent driving domain, and onboard coprocessors. It performs protocol abstraction, conversion, and rationality verification, and arbitrates signal groups based on the vehicle's real-time operating status and preset priority strategies. Finally, it generates target execution instructions that meet functional safety standards and sends them to the underlying actuators. This technical solution achieves interoperability between non-standard AI protocols and standard AUTOSAR signals, supports real-time collaboration and reverse wake-up of multiple AI models, effectively resolving the contradiction between the black-box inference latency of AI models and the high real-time performance and safety requirements of vehicle control in existing technologies, and improving the intelligent collaborative control capabilities of the entire vehicle under complex operating conditions.

[0028] First, the real-time scheduling method for AI models based on the classic AUTOSAR architecture provided in this application will be described in detail below with reference to the accompanying drawings. The method is applied to the power domain controller of a vehicle, which is equipped with the classic AUTOSAR architecture.

[0029] Reference Figure 1 The implementation of the real-time scheduling method for AI models based on the classic AUTOSAR architecture provided in this application includes, but is not limited to, the following steps.

[0030] Step S110: Receive raw control intent data from at least two different deployment levels of AI models through the communication interface of the classic AUTOSAR architecture.

[0031] The different deployment levels include cloud, vehicle-side intelligent driving domain, and onboard coprocessor.

[0032] In step S110, the closed nature of traditional vehicle control systems is broken, and a unified communication entry point capable of accommodating multi-source heterogeneous AI model inputs is constructed. In actual vehicle operating environments, decision sources are diverse. Cloud-based large models excel at processing long texts and complex scene planning, vehicle-side intelligent driving domain models focus on real-time environmental perception and driving strategies, while onboard coprocessors are responsible for rapid response to underlying transient conditions. By utilizing the existing communication interfaces of the classic AUTOSAR architecture, the system can simultaneously access the raw control intent data output by these AI models distributed at different levels. This design not only achieves cross-domain data fusion, converging macro-level strategies from the cloud, meso-level perception from intelligent driving, and micro-level execution instructions from the onboard onto the same processing platform, but also lays the data foundation for subsequent unified scheduling, enabling the vehicle to comprehensively consider intelligent decision suggestions from different dimensions, thereby achieving a higher level of collaborative control.

[0033] Step S120: Within the application layer software component of the classic AUTOSAR architecture, the original control intent data is abstracted and transformed according to the protocol, and parsed and mapped into a signal group that conforms to the AUTOSAR standard.

[0034] In step S120, since the data formats, semantic definitions, and communication protocols output by different AI models often differ and typically do not conform to the stringent AUTOSAR standards of the automotive industry, direct execution poses a significant compatibility risk. Therefore, protocol abstraction and conversion within the application-layer software components can clean and standardize these non-standard, messy raw control intent data. By calling a pre-built parsing logic library, the system parses the raw data into standardized interface data and maps it to signal groups that the AUTOSAR communication layer can recognize. This process not only eliminates the semantic gap between the AI ​​model and the vehicle's underlying hardware, ensuring data readability and consistency, but also enables the AI's intelligent decision-making to be seamlessly embedded into the existing automotive electronic and electrical architecture, providing a unified data carrier for subsequent logical processing.

[0035] Step S130: Based on the current operating status of the vehicle, perform rationality verification and arbitration on the mapped signal group, and generate the target execution command.

[0036] In step S130, after receiving the mapped standard signal group, the system does not execute blindly. Instead, it combines the vehicle's current real-time sensor data to perform a rigorous rationality check on the instructions. This includes determining whether the executed action exceeds the vehicle chassis dynamic stability boundary or actuator saturation threshold, and detecting whether there are multi-model instruction conflicts. For example, when an instruction issued by the cloud AI conflicts with an instruction from the onboard coprocessor, or when the acceleration required by the instruction exceeds the range allowed by the current road surface adhesion, the system will arbitrate according to a preset priority strategy. For example, in transient conditions, the priority of the onboard coprocessor may be increased and non-real-time cloud instructions may be blocked, or signals exceeding physical limits may be truncated and corrected. Through this process, the system can generate target execution instructions that both conform to the AI's decision-making intent and absolutely meet the vehicle's physical limitations and safety standards, effectively preventing dangerous operations caused by the black-box nature or misjudgments of the AI ​​model.

[0037] Step S140: The target execution instruction is sent to the task scheduling queue of the real-time operating system through the runtime environment interface of the classic AUTOSAR architecture to control the underlying executor.

[0038] In step S140, the final leap from logical decision-making to physical execution is completed, ensuring the high real-time performance and determinism of control commands. The target execution command generated after processing in the preceding steps is precisely injected into the task scheduling queue of the real-time operating system through the AUTOSAR standard runtime environment interface. This scheduling mechanism based on the classic AUTOSAR architecture leverages the real-time operating system's strict management of task priorities to ensure that control commands are processed and issued within millisecond-level time windows. This not only meets the stringent low-latency requirements of vehicle power domain control, guaranteeing smooth driving and responsiveness, but also decouples application-layer software components from underlying hardware through standard interface specifications. Ultimately, the commands are accurately transmitted to underlying actuators such as the engine, motor, or braking system, realizing the precise implementation of AI intelligent decision-making in the physical world and providing users with a safe and intelligent travel experience.

[0039] In some embodiments of this application, step S120 involves protocol abstraction and transformation of the raw control intent data within the application layer software component of the classic AUTOSAR architecture. This includes: calling a pre-built parsing logic library through the application layer software component to perform format verification and semantic parsing on the raw control intent data, generating standardized interface data. Thus, this application solves the compatibility problem between heterogeneous AI model outputs and traditional automotive electronic control standards, building a common language bridge between intelligent decision-making and vehicle actuators.

[0040] Specifically, because cloud-based large-scale models, vehicle-side intelligent driving domain models, and onboard coprocessor models often employ their own independent non-standard communication protocols and data formats, these raw control intent data cannot be recognized and processed when directly input into a vehicle control system that strictly adheres to the AUTOSAR standard. By calling a pre-built parsing logic library within the application-layer software components, the system can perform deep format verification on these messy raw data, eliminating noise and erroneous data packets during transmission, and simultaneously perform semantic parsing, transforming the AI ​​model's unique logical language into engineering quantities that the controller can understand.

[0041] This process maps multi-source heterogeneous AI outputs into standardized interface data, which not only eliminates the technical barriers between different AI models and realizes the fusion processing of multi-model data, but also ensures that subsequent control commands can pass smoothly through the AUTOSAR communication layer, laying a solid data foundation for vehicles to achieve safe and efficient cross-domain collaborative control in complex embodied intelligence scenarios.

[0042] In some embodiments of this application, step S130 involves performing rationality verification and arbitration on the mapped signal group based on the vehicle's current operating state. This includes: when the vehicle is detected to be in a transient operating condition, prioritizing the signal group of the AI ​​model at the corresponding level of the onboard coprocessor according to a preset priority strategy, and blocking non-real-time instructions from the cloud. Thus, this application constructs a dynamic priority scheduling mechanism based on operating condition awareness to ensure that the vehicle can prioritize the most timely and reliable control instructions in extreme or rapidly changing driving scenarios, thereby ensuring driving safety and control stability.

[0043] Specifically, transient conditions typically refer to moments when a vehicle experiences rapid changes in its physical state, such as acceleration, deceleration, steering, or sudden changes in road surface adhesion. During these situations, vehicle control demands extremely high real-time performance; even the slightest communication delay can lead to control failure or instability. While cloud-based AI models possess powerful computing capabilities and global planning abilities, they are inevitably subject to significant communication delays due to network transmission limitations. Consequently, their commands often exhibit lag during transient conditions, and forcibly executing them could result in loss of vehicle control.

[0044] Therefore, by monitoring vehicle status in real time, the system immediately triggers arbitration logic upon identifying transient conditions, proactively prioritizing the AI ​​model signals deployed on the onboard coprocessor. The onboard coprocessor, directly integrated within the domain controller, possesses ultra-low latency inference capabilities at the nanosecond or microsecond level, and its output control commands perfectly match the current transient physical changes. By shielding non-real-time commands from the cloud, the system effectively blocks potential sources of lag interference, ensuring that the local model with the best real-time response capabilities takes over control at critical moments, achieving an optimal balance between cloud-based macro-level strategies and local micro-level real-time security.

[0045] In some embodiments of this application, the aforementioned rationality verification includes the following steps: acquiring the vehicle's current sensor data, determining whether the execution action corresponding to the mapped signal group exceeds the vehicle's current physical limits, including the vehicle chassis dynamics stability boundary or actuator saturation threshold; if it exceeds, then truncating or correcting the signal group to generate a corrected target execution command. In this way, the system establishes a hard safety barrier based on the vehicle's physical characteristics for the AI ​​model's black-box decision-making, ensuring that regardless of the control intent output by the AI ​​model, the final execution action must be strictly limited to the vehicle's controllable physical space.

[0046] Specifically, because AI models may employ overly aggressive strategies or make misjudgments due to biases in training data during the inference process, the control commands they generate may require the vehicle to make sharp turns beyond the tire adhesion limit at the current speed, or require the actuators to output torque and stroke exceeding the maximum allowable by their mechanical structure. Once these commands are executed, they will directly lead to vehicle instability or even danger.

[0047] Therefore, by acquiring real-time sensor data of the vehicle, the system can accurately construct a dynamic profile of the vehicle, such as determining the chassis dynamic stability boundary based on vehicle speed and yaw rate, or determining the saturation threshold of actuators based on their current temperature and position. The system compares the mapped AI signal set with these physical boundaries in real time. Once an instruction is found to exceed the limit, a correction mechanism is immediately activated, truncating or smoothing the signal set to constrain the instruction within a safe range. This process not only effectively avoids safety hazards caused by the uninterpretability of AI models but also ensures the controllability of the vehicle under extreme conditions, achieving a perfect integration of intelligent decision-making and mechanical physical safety.

[0048] In some embodiments of this application, the method further includes: encapsulating non-standard AI protocol data packets into AUTOSAR communication layer signals through AI instruction parsing middleware in the application layer software component, and transmitting and receiving them through the controller area network bus or Ethernet interface. In this way, the system achieves bidirectional interoperability between the AI ​​model and the vehicle's traditional electronic control network, constructing a universal data channel connecting isolated intelligent algorithms with the vehicle's communication bus.

[0049] Specifically, in practical applications, AI models typically use custom, non-standard protocols for data transmission. The format of these data packets differs fundamentally from the AUTOSAR communication standard strictly adhered to by in-vehicle networks, and direct access can lead to communication failures or data loss. By deploying a dedicated AI instruction parsing middleware within the application-layer software components, the system can perform deep semantic stripping and structural reorganization of these non-standard AI protocol data packets, encapsulating them into a signal format compliant with the AUTOSAR standard. This encapsulation process not only overcomes the technical barriers of protocol incompatibility, enabling the AI's control intentions to be recognized and processed by other controllers in the vehicle network, but also achieves efficient data transmission and reception through standardized controller area network buses or Ethernet interfaces.

[0050] Therefore, whether it is sending macro-level strategy commands from the cloud to the power domain or transmitting real-time status data from the vehicle back to the intelligent driving domain, this middleware plays the dual role of translator and router, ensuring smooth information flow between multiple AI models and the vehicle control system, and providing a solid foundation for communication to achieve cross-domain real-time collaborative control.

[0051] In some embodiments of this application, the method further includes: sending a reverse wake-up command to the AI ​​model through an application layer software component to trigger the AI ​​model in a dormant state to perform data inference.

[0052] Specifically, by actively triggering a process to break the passive dormancy state of AI models, the system ensures that their inference resources can be activated on demand to support critical control tasks. In automotive embedded systems, to reduce static power consumption and optimize computing resource allocation, some non-core or non-real-time AI models are typically placed in a low-power sleep mode when there are no tasks. However, this prevents them from immediately responding to data processing requests when needed. By actively sending a reverse wake-up command through application-layer software components, the system can accurately notify the target AI model in a dormant state to restore its context and immediately start the data inference process.

[0053] This mechanism not only avoids delays in control command generation caused by model dormancy, ensuring the real-time and continuous collaborative work of multiple AI models, but also effectively balances system power consumption and performance requirements through the on-demand wake-up strategy, enabling AI models to achieve agile responses to vehicle dynamic control needs with minimal resource consumption while ensuring functional safety.

[0054] In some embodiments of this application, the method further includes: feeding back the execution result of the target execution instruction to the corresponding AI model to optimize the inference logic of the AI ​​model.

[0055] Specifically, a closed-loop model self-evolution mechanism is constructed. By tracing the actual execution effects in the physical world back to the algorithm layer, the AI ​​model is driven to optimize its inference logic online or offline. In open-loop control mode, the AI ​​model is only responsible for outputting instructions and cannot perceive the actual deviations after instruction execution. This makes it difficult for it to adapt to control errors caused by component aging, sudden environmental changes, or limitations of its own algorithm during long-term vehicle operation. By accurately feeding back the actual execution results of the target instruction on the underlying actuator, such as the vehicle's actual acceleration, steering angle, or powertrain response curve, to the corresponding AI model that issued the instruction, the system provides the model with valuable "empirical data." The model uses this feedback data to compare and analyze with the expected output, enabling it to identify weaknesses or sources of deviation in its decision-making logic. It can then correct its internal parameters and inference strategies through online fine-tuning or offline retraining.

[0056] This process not only significantly improves the accuracy and robustness of AI models in predicting future control commands, enabling them to adapt to subtle changes in vehicle characteristics as vehicle usage time increases, but also fundamentally solves the domain offset problem between model training and actual deployment, achieving a qualitative leap for intelligent decision-making systems from "static rule execution" to "dynamic experience learning".

[0057] In some embodiments of this application, reference is made to Figure 2 The logic provided in this application for determining the feasible state of implementing AI scheduling includes the following steps.

[0058] First, the AI ​​model is activated, possibly due to mutual scheduling between AIs, activation by user scenarios such as apps, or direct activation by the driver's voice in the cockpit. The AI ​​sends a command packet that meets the data format requirements to the AI ​​cross-domain software real-time collaborative system at the power domain control end, constrained by user prompts and system prompts. At this time, the AI ​​cross-domain software real-time collaborative system starts up and receives information such as the AI ​​model ID and authentication information.

[0059] Then, the model type is determined based on the model ID, and the owner ID, driving status and other information are obtained based on the authentication information. The model ID distinguishes the instructions sent by the onboard coprocessor of the cloud, intelligent driving domain control, cockpit domain control or power domain control. For example, when communication is not smooth, cloud model instructions are rejected and feedback is given. In the lock mode of specific driving conditions, instructions such as power system optimization control from the onboard coprocessor of power domain control are rejected and feedback is given to the cloud.

[0060] Secondly, obtain the current inference state of the model, execute instructions that are not in inference, and wait for the inference result to be fully generated before executing instructions for the model that is in inference, so as to prevent the AI ​​from adjusting the final execution decision instructions based on real-time status feedback.

[0061] Then, the system quickly determines whether there is a conflict based on the ID of the decision control command. For example, if two AIs with different IDs send execution commands in opposite directions to the same control command ID at the same time, the system feeds back the situation to the higher-priority AI for re-decision based on the ID priority.

[0062] Furthermore, the software component unpacks the specific format instruction packets sent by the AI, and after disassembly, it can identify the execution time and the target executor and sensor. The software component has built-in logic that can determine whether the current AI instruction may be related to other AI models supported by the software component. If a relationship exists, after obtaining the executor and sensor results, it packages the instruction execution status, sensor status, and executor execution status and sends them to the related AI. After being sent to the related AI, it can trigger other AIs to perform inference, thus realizing multi-AI scheduling.

[0063] Furthermore, in the event of a conflict in instructions, the execution result of this software component within its cycle is converted into an AI with a high-privilege ID to make a new decision. The determination of "high privilege" changes dynamically according to the user scenario and model type. For example, in an entertainment scenario, cloud AI is used as the high-privilege AI, while in a driving scenario, high-real-time AI such as onboard coprocessors is used as the high-privilege AI for power-related functions.

[0064] Furthermore, while the AI ​​model is in the process of inference, the cycle of that software component is skipped, and the cycle is executed immediately after the inference result is generated.

[0065] Finally, once the feasible state of AI scheduling is identified, the corresponding AI model with the ID of the AI ​​scheduling system software component is activated. The feedback information includes the executable state determination result and forwards the state to other AI models that are identified as relevant.

[0066] In some embodiments of this application, reference is made to Figure 3 The AI ​​scheduling decision result execution logic provided in this application includes the following steps.

[0067] First, when AI scheduling is identified as available, the AI ​​control instruction package is received and formally parsed. Then, it is determined whether delayed execution is necessary. Further, it is determined whether the instruction is suitable for immediate execution. Further, it is determined whether the instruction is suitable for scheduled execution, i.e., automatic execution after a set time. Further, scheduled execution is performed, and if it matches the target execution time after a set time, it continues. Further, the control instruction is executed, activating relevant software components, actuators, and sensors. In addition, other software components can be invoked by pre-execution instructions, and some other software components also reserve some interfaces that can passively or autonomously invoke AI inference to proceed to the next step; Furthermore, it receives requests from other software components that need to trigger AI inference, packages them uniformly as forwarding channels, and finally packages and forwards the content to the AI ​​as needed, adaptively analyzes which AIs need to be sent, and executes the sending to trigger the next step of inference in the AI ​​model. Secondly, this application provides a real-time scheduling system for AI models based on the classic AUTOSAR architecture. The system includes a dynamic domain controller, a real-time operating system, and the classic AUTOSAR architecture.

[0068] The power domain controller, comprising a multi-core processor, communication interfaces, and a bus transceiver, serves as the physical core of the entire system. It provides a high-performance computing foundation and reliable hardware communication channels for the real-time scheduling of AI models. The multi-core processor handles complex computational tasks from different AI models in parallel, ensuring high-frequency control command generation even under transient conditions. The communication interface and bus transceiver together form the data interaction hub between the controller and the external environment. By supporting mainstream automotive network protocols such as Controller Area Network (CAN) bus or Ethernet, it enables efficient data transmission and reception with the cloud, the vehicle-side intelligent driving domain, and the onboard coprocessor. This ensures that the original control intent data of multi-level AI models can enter the system with low latency, providing a solid hardware platform support for subsequent real-time scheduling and fusion control.

[0069] A real-time operating system, deployed on the power domain controller, ensures deterministic response capabilities and provides strict time constraints and resource management mechanisms for the real-time scheduling of AI models. On top of multi-core processor hardware resources, the real-time operating system ensures that high-priority control tasks can be responded to within milliseconds or even microseconds through precise task scheduling algorithms, priority preemption mechanisms, and interrupt management. Especially in transient conditions or emergency arbitration scenarios, it guarantees that the generation and issuance of core control commands will not be blocked by low-priority tasks, thereby avoiding control instability caused by system latency and providing a stable and predictable execution environment for the entire AUTOSAR architecture and its upper-layer applications.

[0070] The classic AUTOSAR architecture is deployed on top of a real-time operating system and includes an application layer and a runtime environment.

[0071] Specifically, the classic AUTOSAR architecture, as a standard software framework connecting underlying hardware resources and upper-layer AI application logic, achieves software-hardware decoupling and seamless integration of cross-vendor components. By standardizing the application layer and runtime environment, the system can flexibly deploy and configure different AI model scheduling strategies without relying on a specific hardware platform. The runtime environment, acting as middleware for communication between software components, manages the flow of data between different AI models, sensors, and actuators, ensuring reliable signal transmission and event triggering. This architecture not only inherits the traditional advantages of high reliability in automotive electronic systems but also provides an open and standardized software ecosystem for the introduction of AI technology, enabling complex intelligent decision-making algorithms to be deeply integrated with traditional vehicle control functions.

[0072] The application layer includes at least one AUTOSAR software component, which is configured to perform the steps of the real-time scheduling method for AI models based on the classic AUTOSAR architecture as described above.

[0073] Specifically, these software components encapsulate the complete algorithmic flow from receiving raw control intent data, protocol conversion, rationality verification and arbitration, to generating the final target execution instruction. By calling pre-built parsing logic libraries and AI instruction parsing middleware, the software components can process non-standard AI protocol data and dynamically adjust priorities and perform physical limit protection based on the vehicle's current operating status. As the most intelligent part of the entire system, it directly determines the efficiency and safety of multi-AI model collaborative work and is the core functional unit for realizing closed-loop control from macro-planning in the cloud to micro-execution at the vehicle end.

[0074] In some embodiments of this application, reference is made to Figure 4 The AI ​​model real-time scheduling system based on the classic AUTOSAR architecture provided in this application realizes the generation and scheduling of multi-level AI strategies through cloud AI, intelligent driving domain controller and cockpit domain controller, and performs protocol conversion through AI instruction packets in the power domain controller, and uses onboard coprocessor to provide local computing power support; the core is the multi-AI cross-domain software real-time collaborative software component, which is responsible for arbitrating, verifying and merging various instructions, and finally drives physical actuators through relevant domain control software components, thereby constructing a closed-loop intelligent control architecture from cloud macro decision-making to local real-time execution.

[0075] Specifically, the external AI cloud mainly runs large-scale language models of 100B or more. These language models have better reasoning performance, can handle ultra-long contextual texts such as 256K, and have a certain degree of intelligent emergence capability. With the help of this facility, the complex embodied intelligence requirements of vehicle control can be supported.

[0076] Furthermore, the VLA model of the external AI intelligent driving domain controller, relying on the computing power of the intelligent driving domain controller, can run the VLA model and has a certain degree of real-time performance. In specific action control scenarios, it can issue accurate control commands in combination with external image input, thereby supporting the vehicle-side intelligent scheduling.

[0077] Furthermore, the voice model of the external AI cockpit domain controller and the edge-side LLM model enable the cockpit domain controller to support users' routine intelligent needs, such as converting user voice input into text, processing the text through a language model of less than 10 bytes, and then feeding it back to the user, or processing it into action control commands through specific rules and sending them to the power domain controller, etc.

[0078] Furthermore, the AI ​​instruction package for internal access control of the power domain is sent into the hard real-time system in a constrained specific format. The system then uses this instruction package to perform subsequent work such as feasibility state determination. The AI ​​instruction package can come from an external AI or an onboard coprocessor.

[0079] Furthermore, onboard coprocessors are typically specific AI accelerators that are directly embedded in the hardware for specific models, thereby maximizing the acceleration of the inference speed of those models. They generally run models with the highest real-time AI requirements, such as convolutional neural networks, which can meet the needs of transient control of fuel vehicle engines. In addition, the chip can also support low power consumption and high-speed wake-up.

[0080] Furthermore, the multi-AI cross-domain software real-time collaborative software component, namely the software system described in this invention, runs on a controller with a classic AUTOSAR architecture. As a conventional software component, it can use a model-based development method and interact with control models of other hardware, meeting the functional safety requirements of national standards.

[0081] Furthermore, the relevant domain control software components are mainly device abstraction layer software components running on controllers of the classic AUTOSAR architecture. These software components can interact directly with the vehicle hardware or with the downstream controllers and actuators through methods such as drivers, diagnostics, and data acquisition.

[0082] Furthermore, various actuators throughout the vehicle, such as engine EGR valves, turbochargers, air conditioning, and body lights, are compatible with actuator components of the classic AUTOSAR architecture.

[0083] Furthermore, various sensors throughout the vehicle, such as battery temperature sensors and temperature sensors at various locations in the cabin, are compatible with actuator components based on the classic AUTOSAR architecture.

[0084] In some embodiments of this application, a coprocessor-side AI model operation mode is provided. Specifically, when a user activates Comfort Mode plus Intelligent Driving Mode in the cabin, the cabin AI first performs voice recognition, then cabin LLM analysis and processing, and some instructions are decomposed and transmitted to cloud AI. The cloud AI intelligently calculates the required speed for this segment of the journey in Comfort Mode, as well as the optimal low-cost driving route and plan that balances electricity and fuel costs. It then issues a navigation call, assesses the speed of the target speed, and packages AI instruction packages into multiple parts according to the time sequence for downward transmission. During driving, the vehicle lighting system is dynamically operated through the AI ​​scheduling system. The onboard coprocessor is activated and infers the optimal engine boost strategy and hybrid power system matching strategy under the current operating conditions. These are further distributed to other relevant software components, scheduling actuators, and sensors through the AI ​​scheduling software component of the power domain control.

[0085] Furthermore, embodiments of this application provide an electronic device, including: one or more processors; a memory for storing one or more computer programs; when one or more computer programs are executed by one or more processors, the electronic device enables the aforementioned real-time scheduling method for AI models based on the classic AUTOSAR architecture.

[0086] Furthermore, embodiments of this application provide a vehicle, including the aforementioned real-time scheduling system for an AI model based on the classic AUTOSAR architecture.

[0087] In summary, the real-time scheduling method for AI models based on the classic AUTOSAR architecture and its related equipment provided in this application have the following technical effects.

[0088] This technical solution proposes a multi-AI real-time collaborative control strategy running on the power domain controller. Based on software components of the classic AUTOSAR architecture, this strategy enables unified scheduling and collaborative operation of AI models of different scales on the cloud, edge, and onboard coprocessors within a real-time operating system. As a core intermediate layer between AI and vehicle actuators and sensors, the multi-AI scheduling software component intelligently determines command priority through ID recognition and scene analysis, and utilizes signal interfaces to achieve standardized control command transmission and execution result feedback, thereby constructing a closed-loop control link from cloud-based macro-decision-making to local real-time execution.

[0089] This technical solution effectively addresses the compatibility and real-time challenges between multi-source heterogeneous AI models and traditional vehicle networks by integrating protocol abstraction and conversion, dynamic arbitration, and physical limit verification mechanisms. The system not only seamlessly encapsulates non-standard AI protocols into AUTOSAR standard signals but also supports reverse wake-up and execution feedback loops, enabling online model optimization and low-power management. Under transient conditions, the system automatically masks non-real-time instructions based on preset strategies, prioritizing the local response of the onboard coprocessor, thereby achieving high efficiency and stability in cross-domain collaboration while ensuring functional safety. This solution eliminates the need for large-scale modifications to the existing power domain control software architecture, enabling rapid upgrades of the entire vehicle's functional software to an AI-instruction-compatible embodied intelligent controller, significantly improving the execution efficiency, safety, and response speed of the vehicle's intelligent control.

[0090] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0091] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0092] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of ordinary skill of an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary skill. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0093] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0094] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0095] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or, if necessary, processing in a suitable manner, and then stored in computer memory.

[0096] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0097] In the foregoing description of this specification, the reference to terms such as "one embodiment / implementation," "another embodiment / implementation," or "certain embodiments / implementations," etc., indicates that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in an embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0098] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0099] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. An AI model real-time scheduling method based on a classical AUTOSAR architecture, characterized in that, A power domain controller for a vehicle, the power domain controller being deployed with a classic AUTOSAR architecture, the method comprising: Through the communication interface of the classic AUTOSAR architecture, raw control intent data from AI models at least two different deployment levels are received; the different deployment levels include the cloud, the vehicle-side intelligent driving domain, and the onboard coprocessor. Within the application layer software component of the classic AUTOSAR architecture, the original control intent data is abstracted and transformed according to the protocol, and parsed and mapped into a signal group that conforms to the AUTOSAR standard. Based on the vehicle's current operating status, the mapped signal group is validated and arbitrated to generate the target execution command; The target execution instructions are sent to the task scheduling queue of the real-time operating system through the runtime environment interface of the classic AUTOSAR architecture to control the underlying executor.

2. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, Within the application layer software components of the classic AUTOSAR architecture, the raw control intent data undergoes protocol abstraction and transformation, including: The application layer software component calls a pre-built parsing logic library to perform format verification and semantic parsing on the original control intent data, generating standardized interface data.

3. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, The process of verifying and arbitrating the rationality of the mapped signal group based on the vehicle's current operating status includes: When a vehicle is detected to be in a transient state, the signal group priority of the AI ​​model at the corresponding level of the onboard coprocessor is increased according to a preset priority strategy, and non-real-time instructions from the cloud are blocked.

4. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, The rationality verification includes: Acquire the current sensor data of the vehicle and determine whether the execution action corresponding to the mapped signal group exceeds the current physical limit of the vehicle. The physical limit includes the vehicle chassis dynamic stability boundary or the actuator saturation threshold. If the signal exceeds the limit, the signal group is truncated or modified to generate a modified target execution instruction.

5. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, The method further includes: The AI ​​instruction parsing middleware in the application layer software component encapsulates non-standard AI protocol data packets into AUTOSAR communication layer signals, which are then transmitted and received via the controller area network bus or Ethernet interface.

6. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, The method further includes: The application layer software component sends a reverse wake-up command to the AI ​​model to trigger the AI ​​model in a dormant state to perform data inference.

7. The AI model real-time scheduling method based on a classic AUTOSAR architecture according to claim 1, characterized in that, The method further includes: The execution result of the target execution instruction is fed back to the corresponding AI model to optimize the inference logic of the AI ​​model.

8. An AI model real-time scheduling system based on a classical AUTOSAR architecture, characterized in that, The system includes: The power domain controller includes a multi-core processor, communication interface, and bus transceiver; A real-time operating system is deployed on the power domain controller; The classic AUTOSAR architecture, deployed on top of the real-time operating system, includes an application layer and a runtime environment; The application layer includes at least one AUTOSAR software component, which is configured to perform the steps of the real-time scheduling method for AI models based on the classic AUTOSAR architecture as described in any one of claims 1 to 7.

9. An electronic device, comprising: include: One or more processors; Memory, used to store one or more computer programs; When the one or more computer programs are executed by the one or more processors, the electronic device implements the real-time scheduling method for AI models based on the classic AUTOSAR architecture as described in any one of claims 1 to 7.

10. A vehicle characterized by comprising: This includes the real-time scheduling system for AI models based on the classic AUTOSAR architecture as described in claim 8.

Images