Method and device for determining control strategy, and vehicle

Abstract

The application discloses a kind of control strategy determination method, device and vehicle.Therein, the method comprises: obtaining the target data of target vehicle, wherein the target data is used to reflect the running state of multiple function domains of target vehicle and the driving state of target object for controlling target vehicle;Determine the digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of target object from target data in multiple dimensions;Adopt digital twin model to determine the control strategy corresponding to driving intention, wherein the control strategy is used to cooperatively control multiple function domains of target vehicle;Control strategy is issued to the domain controller corresponding to multiple function domains respectively.The application solves the technical problem that the vehicle adaptive control learning based on static learning logic used in the related art only covers a few isolated functions such as air conditioning and driving mode, resulting in a serious disconnection between the control strategy and the real driving demand, and a low vehicle control accuracy.

Description

Technical Field

[0001] This application relates to the field of automotive driving technology, and more specifically, to a method, apparatus, and vehicle for determining a control strategy. Background Technology

[0002] Regarding vehicle adaptive control technology, the vehicle adaptive control learning based on static learning logic only covers a few isolated functions such as air conditioning and driving modes, resulting in a serious disconnect between the control strategy and real driving needs, and low vehicle control accuracy.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, apparatus, and vehicle for determining a control strategy, which at least solves the technical problem that the vehicle adaptive control learning based on static learning logic used in related technologies only covers a few isolated functions such as air conditioning and driving modes, resulting in a serious disconnect between the control strategy and real driving needs and low vehicle control accuracy.

[0005] According to one aspect of the embodiments of this application, a method for determining a control strategy is provided, comprising: acquiring target data of a target vehicle, wherein the target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of a target object controlling the target vehicle; determining a digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions; using the digital twin model to determine a control strategy corresponding to the driving intention, wherein the control strategy is used to perform coordinated control of multiple functional domains of the target vehicle; and distributing the control strategy to the domain controllers corresponding to the multiple functional domains respectively.

[0006] In this embodiment, a multi-source data fusion and digital twin modeling approach is adopted. By collecting the operating status of multiple functional domains of the target vehicle and the driving status data of the target object, a digital twin model that can map driving intentions in multiple dimensions is constructed. Based on this model, a control strategy for collaborative execution of multiple functional domains is automatically generated and uniformly distributed to each domain controller for execution. This achieves the goal of accurately identifying the user's real driving intentions and realizing dynamic adaptation of the whole vehicle's full-domain strategy. This achieves the technical effect of high matching between control strategy and driving needs and multi-domain linkage response. It also solves the technical problem of related technologies that use vehicle adaptive control learning based on static learning logic, which only covers a few isolated functions such as air conditioning and driving mode, resulting in a serious disconnect between control strategy and real driving needs and low vehicle control accuracy. Attached Figure Description

[0007] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0008] Figure 1 This is a hardware structure block diagram of a computer terminal for a method of determining a control strategy according to an embodiment of this application.

[0009] Figure 2 This is a flowchart of a method for determining a control strategy according to an embodiment of this application;

[0010] Figure 3 This is a system architecture diagram of a method for determining a control strategy according to an embodiment of this application;

[0011] Figure 4 This is an iterative flowchart of a digital twin model for a method of determining a control strategy according to an embodiment of this application;

[0012] Figure 5 This is a flowchart illustrating the control strategy evolution and verification process of a control strategy determination method according to an embodiment of this application.

[0013] Figure 6 This is an OTA co-evolution decoupling flowchart of a control strategy determination method according to an embodiment of this application;

[0014] Figure 7 This is a flowchart illustrating the extreme scenario strategy generalization and adaptation of a control strategy determination method according to an embodiment of this application.

[0015] Figure 8 This is a schematic diagram of a control strategy determination device according to an embodiment of this application. Detailed Implementation

[0016] 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 should fall within the scope of protection of the present application.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0019] User digital twin: In the field of industrial and intelligent systems, it refers to the construction of a dynamic, high-fidelity mapping model of a physical entity in the digital space by collecting multi-dimensional data of the physical entity, in order to reflect the entity's state, behavior, and evolution trend in real time. In the embodiments of this application, the user digital twin is a four-dimensional coupled model constructed based on four types of data: vehicle domain, user behavior, scene environment, and physiological state, used to continuously fit the user's driving intentions, preferences, and state changes.

[0020] Whole-Vehicle Domain Coordinated Control (WVDCC): In this embodiment, it refers to the unified planning and synchronous execution of control logic for multiple independent functional domains such as powertrain, chassis, thermal management, intelligent driving, body control, and energy management within the automotive electronic and electrical architecture, in order to achieve optimal system-level performance. WVDCC achieves timing matching and conflict-free coordination of strategies across the six functional domains through SOA (Service-Oriented Architecture), breaking the limitations of traditional fragmented single-function control and ensuring consistent and coherent response to user preferences throughout the entire vehicle.

[0021] OTA Co-evolution: refers to the mechanism in which the basic system strategy released by the OEM and the user's personalized model remain decoupled and evolve collaboratively during the vehicle remote upgrade (Over-the-Air Update) process. In the embodiments of this application, OTA co-evolution uses strategy decoupling and model fusion technology to enable the OEM to only update the underlying logic and not cover the user's personalized data during the upgrade.

[0022] Current adaptive control technologies in mass-produced vehicles all employ shallow learning logic—single-function, fragmented, static, closed-loop, and lacking iterative evolution capabilities. They can only memorize fixed rules for single functions such as air conditioning, seats, and driving modes. The learning logic is based on preset, fixed algorithms, failing to cover the entire vehicle's control capabilities. Furthermore, they cannot continuously evolve with changes in the user's driving ability, usage scenarios, physical condition, and preferences throughout their lifecycle, and they cannot achieve collaborative iteration with OEM OTA strategies. Specifically, these technologies suffer from the following shortcomings:

[0023] (1) Fragmented learning dimensions and lack of vehicle-wide collaborative adaptation capability: The existing adaptive learning only covers a few isolated functions such as air conditioning and driving mode. It has not achieved collaborative adaptation of the six core domains of power, chassis, thermal management, intelligent driving, body control and energy management, and cannot achieve vehicle-level user preference matching. For example, if a user prefers aggressive driving, only the sport mode can be switched. It cannot simultaneously adapt to the collaborative adjustment of chassis suspension stiffness, steering feel, braking response, battery discharge rate and thermal management strategy, resulting in fragmented vehicle control logic.

[0024] (2) The learning logic is static and fixed, and there is no ability to iterate throughout the entire life cycle: The learning logic of related technologies can only fit the behavioral data of users in short-term fixed scenarios and cannot continuously evolve with the changes of users throughout their entire life cycle. For example, when a user grows from a novice driver to a skilled driver, his driving habits and scenario requirements change fundamentally, but the system still uses the learning model from the novice period; when a user changes from commuting in the city to long-distance operation, adds family members, or changes in physical condition, the system cannot actively adapt and the user still needs to manually adjust the settings repeatedly.

[0025] (3) No functional safety and compliance dynamic locking mechanism, and no boundary evolution: The adaptive learning of related technologies does not have strict safety boundary control. The control strategy after self-learning is prone to exceed the limits of the vehicle design, does not meet compliance requirements, and cannot meet functional safety requirements. For example, if the user drives aggressively for a long time, the system will increase the torque output without limit, exceeding the safe working range of the battery and motor, and causing the risk of thermal runaway. The self-evolved intelligent driving strategy does not meet the national standard requirements for the classification of vehicle driving automation.

[0026] (4) No OTA collaborative evolution mechanism, conflict between OEM updates and user personalization: OTA upgrades of related technologies are full-coverage updates. After the OEM releases a new vehicle control strategy, it will directly cover the user's previous personalized learning data, causing the user's habit adaptation to fail. If the user does not update, he / she cannot enjoy the OEM's strategy optimization results, forming an industry deadlock of "upgrading and losing personalization, not upgrading and losing performance".

[0027] (5) No ability to generalize to abnormal scenarios and zero adaptability to extreme scenarios: The learning model of the relevant technology can only fit the user behavior of regular commuting scenarios and cannot generalize to sudden or extreme scenarios such as rain, snow, ice, mountain curves, and emergency avoidance. It cannot predict and adapt to the user's driving habits and emergency operation preferences in extreme scenarios. The control logic in extreme scenarios is seriously inconsistent with the user's expectations and is prone to causing safety accidents.

[0028] (6) Lack of user physiological state adaptation capability and lack of human-centered design: The relevant technologies do not incorporate user physiological state data (fatigue, attention, mood, age, physical disability), and cannot dynamically adjust the control strategy according to the user's real-time physiological state. For example, if user fatigue driving is detected, it cannot automatically switch to a conservative power strategy, improve braking warning sensitivity, or tighten the seat belt; for elderly users, it cannot automatically slow down the steering and braking response speed, or increase the intervention intensity of the assisted driving.

[0029] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.

[0030] The method for determining the control strategy provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a method for determining control strategies is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0032] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the control strategy determination method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned control strategy determination method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0033] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0034] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0035] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware components (including circuitry), software components (including computer code stored on a computer-readable medium), or a combination of both hardware and software components. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0036] In the above operating environment, this application provides an embodiment of a method for determining a control strategy. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] Figure 2 This is a flowchart of a method for determining a control strategy according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0038] Step S202: Obtain target data of the target vehicle, wherein the target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle.

[0039] In step S202 above, the target data refers to the comprehensive data set collected to support the evolution of the vehicle control strategy, which fully reflects the operating status of multiple functional domains of the target vehicle and the driving behavior of the target object (i.e., the driver). This data includes, but is not limited to, vehicle domain data (such as motor torque output, battery SOC, suspension stiffness, steering assist, braking response, and air conditioning operating parameters), user behavior data (such as steering wheel angle, accelerator and brake pedal travel, vehicle operation log, and line of sight distribution), scene environment data (such as road type, weather, slope, and traffic signs), and user physiological state data (such as fatigue, attention concentration, heart rate, and emotional fluctuations).

[0040] In automotive electronic and electrical architecture, a functional domain refers to a highly integrated set of hardware and software subsystems designed to achieve specific vehicle control functions. Its internal components work collaboratively with the control unit via a dedicated communication bus, providing a unified control interface and functional services to the outside world. It serves as the basic organizational unit for achieving intelligent and modular vehicle control. In some embodiments of this application, multiple functional domains refer to multiple independent but highly coupled subsystems that implement vehicle control functions, including the power domain (drive motor and electronic control), chassis domain (suspension, steering, braking), thermal management domain (battery, motor, cabin temperature control), intelligent driving domain (perception, planning, decision-making), body domain (doors, lighting, seats), and energy domain (battery management system and energy recovery). It should be noted that these functional domains do not respond to commands independently, but rather act as execution units for collaborative control, receiving a unified strategy package generated by a digital twin model to achieve a fully interconnected control effect.

[0041] In some embodiments of this application, the target data includes operational data of multiple functional domains of the target vehicle, driving behavior data of the target object, environmental data of the target vehicle, and physiological state data of the target object. Specifically, a multi-source data acquisition system encompassing the vehicle, cloud, and wearable devices can be constructed, based on a high-precision time synchronization protocol, to ensure that the spatiotemporal synchronization error of all data is less than a preset error (e.g., ≤1ms), providing full data support for digital twin modeling. Specifically, the target data may include:

[0042] (1) Vehicle domain data: Real-time collection of full operating data in six domains: power, chassis, thermal management, intelligent driving, body and energy, including motor torque output, battery SOC / SOH, suspension stiffness, steering feel, braking response, air conditioning parameters, intelligent driving intervention status, etc., with a sampling frequency of 100Hz;

[0043] (2) User behavior data: Data such as user driving habits, vehicle system usage preferences, eye distribution, and emergency operation behavior are collected through steering wheel angle sensor, accelerator / brake pedal travel sensor, vehicle system operation log, and eye-tracking camera;

[0044] (3) Scene environment data: Collect scene data such as road conditions (highway / congestion / mountain / rain and snow), weather, temperature, altitude, traffic rules, and surrounding environment through navigation maps, intelligent driving sensors, and environmental sensors;

[0045] (4) User physiological status data: Collect user physiological status data such as fatigue, attention, heart rate, mood, age, and physical impairment through in-vehicle DMS camera, millimeter-wave vital signs radar, and user wearable devices (smartwatch / bracelet).

[0046] Step S204: Determine the digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions.

[0047] In step S204 above, a digital twin model refers to a digital mapping body constructed from multidimensional real-time data of a physical entity that is highly consistent with its dynamic behavior, state evolution, and interaction characteristics. For example, it can be a four-dimensional coupled digital twin model of the user's entire life cycle, which covers four interrelated sub-models: user static attributes (such as age, driving experience, physical condition), dynamic behavior (such as acceleration / braking / steering preferences), scenario preferences (such as strategy tendencies under different working conditions such as high speed, rain and snow, and night), and physiological state (such as fatigue, attention, and emotional fluctuations).

[0048] In some embodiments of this application, the digital twin model is not a static configuration table, but a dynamic evolution system that iteratively optimizes based on continuously collected target data at preset trigger times (such as once every 24 hours). It transforms the originally fragmented and unstructured vehicle and user data into a semantic expression of driving intentions that can be understood by the system, thereby realizing a complete closed loop from data collection to intention inference to strategy generation.

[0049] Multiple dimensions refer to the independent yet interconnected analytical perspectives that the digital twin model relies on when interpreting a user's driving intentions. These can include static attribute dimensions (inherent user characteristics), dynamic behavior dimensions (operation habits), scenario preference dimensions (environmental adaptability), and physiological state dimensions (real-time physical reactions). These four dimensions together constitute a three-dimensional user profile, avoiding strategy bias caused by misjudgment from a single dimension.

[0050] In some embodiments of this application, a digital twin model corresponding to target data can be determined in the following ways: extracting attribute data of the target object from the target data and determining a first sub-model based on the attribute data, wherein the first sub-model is used to determine the safety boundary of the digital twin model; extracting behavioral data of the target object from the target data and determining a second sub-model based on the behavioral data, wherein the second sub-model is used to reflect the driving behavior pattern of the target object; extracting scene preference data of the target object from the target data and determining a third sub-model based on the scene preference data, wherein the third sub-model is used to construct a control strategy preference matrix of the target object in multiple driving scenarios; extracting physiological data of the target object from the target data and determining a fourth sub-model based on the physiological data, wherein the fourth sub-model is used to reflect the physiological state of the target object; and determining a digital twin model based on the first, second, third, and fourth sub-models.

[0051] Specifically, a four-dimensional coupled digital twin model of the user's entire lifecycle can be constructed based on multi-source collected data, realizing a full-dimensional digital mapping of user attributes, behaviors, preferences, and physiological states. The model iteration cycle is ≤24 hours, where:

[0052] (1) User static attribute sub-model (i.e., the first sub-model): Stores static attributes such as user's age, gender, driving experience, physical condition, driver's license type, and core car use needs, providing the basic boundary for the model;

[0053] (2) User dynamic behavior sub-model (i.e., the second sub-model): Based on the Transformer time series model, it fits the user's driving operation habits (acceleration / braking / steering preferences), vehicle system usage habits, and emergency operation behaviors to achieve accurate digital mapping of user driving behavior, with a fitting accuracy ≥98%;

[0054] (3) Scene preference sub-model (i.e., the third sub-model): Based on graph neural network (GNN), construct the user's control strategy preference matrix in different scenarios (highway / city / off-road / rain / snow / night) to achieve accurate strategy adaptation in different scenarios;

[0055] (4) Physiological state adaptation sub-model (i.e., the fourth sub-model): Based on the multimodal fusion algorithm, the user's fatigue, attention, emotions, physical discomfort and other states are identified in real time, and the physiological state and control strategy adaptation mapping relationship is constructed to realize humanized dynamic adjustment.

[0056] After obtaining the first, second, third, and fourth sub-models, a weighted fusion decision architecture can be adopted. Before each strategy generation, consistency analysis and dynamic weight allocation are performed on the output results of the four sub-models. The weights are adaptively calculated by the system based on the current driving situation: for example, when the physiological state is abnormal, the weight of the fourth sub-model is increased to more than 50%; when entering extreme scenarios, the weight of the third sub-model is given priority; when the user is a novice or elderly person, the first sub-model serves as a hard constraint; in other cases, the second sub-model dominates strategy generation.

[0057] Figure 4 This is an iterative flowchart of a digital twin model for a method of determining a control strategy according to an embodiment of this application, as shown below. Figure 4 As shown, in some embodiments of this application, the digital twin model iteration includes:

[0058] S402: Multi-source spatiotemporal data acquisition. Specifically, a comprehensive data acquisition network is constructed through vehicle-mounted sensors, in-vehicle communication systems, user wearable devices, and environmental perception units. For example, operational status data (such as motor torque, suspension damping, battery SOC, braking pressure, and air conditioning settings) for the vehicle's six functional domains (powertrain, chassis, thermal management, intelligent driving, body, and energy) are acquired at a high frequency of 100Hz; user behavior data is obtained through steering wheel angle sensors, pedal travel encoders, eye-tracking cameras, and vehicle operation logs; scene environment data comes from high-precision maps, navigation systems, rain sensors, and meteorological modules; and user physiological status is monitored in real time through in-vehicle DMS cameras and millimeter-wave vital signs radar to detect fatigue, attention, heart rate, and emotional fluctuations. All data are aligned with a unified high-precision timestamp using PTP (Precise Time Protocol) to ensure that the spatiotemporal synchronization error does not exceed 1 millisecond, providing an unbiased, traceable, and correlateable raw data foundation for subsequent modeling.

[0059] S404: Data Preprocessing and Feature Extraction. Specifically, before the raw data is input into the model, the system performs multi-level data cleaning and structuring processing. First, outliers (such as instantaneous sensor jumps and communication packet loss) are filtered using a sliding window and a cubic σ criterion for removal. Second, unstructured data (such as video images and voice interactions) undergoes semantic parsing to extract key behavioral features (such as the duration of gaze focus and the rate of change of pedal acceleration). Third, multi-source heterogeneous data undergoes semantic normalization, unifying it into a computable numerical vector form.

[0060] S406: User Multidimensional Sub-model Feature Input. Specifically, the preprocessed features are input into a four-dimensional coupled sub-model system: the static attribute sub-model receives fixed labels such as user age, driving experience, and physical disability as policy boundary constraints; the dynamic behavior sub-model receives the temporal sequence of steering wheel and pedal operations, uses the Transformer architecture to capture long-term dependencies, and identifies personalized acceleration / braking / steering patterns; the scene preference sub-model receives environmental features such as road condition type, weather, terrain, and traffic rules, and constructs a "scene-control strategy preference" correlation matrix through a graph neural network; the physiological state adaptation sub-model receives physiological signals (eyelid closure rate, heart rate, skin conductance), and uses a multimodal fusion algorithm to establish a nonlinear mapping relationship between physiological indicators and control requirements.

[0061] S408: Digital Twin Model Fitting and Training. Specifically, based on the independent training of the four-dimensional sub-models, the system employs a joint optimization algorithm to semantically fuse the outputs of the four sub-models, constructing a unified user digital twin model. The training process uses historical driving data as samples, with "user driving satisfaction," "driving safety," "riding comfort," and "energy efficiency" as the comprehensive reward function. It continuously adjusts the internal parameter weights of each sub-model through a combination of offline simulation and online learning. For example, in simulating the transition from a novice to a skilled driver, the system automatically adjusts the slope of the power response curve and the steering assist gain until the model's output control strategy highly matches the user's actual operating preferences. The training process automatically starts every 24 hours to ensure the model evolves synchronously with user behavior.

[0062] S410: Model Accuracy Verification. Specifically, after model training, the system uses a cross-validation mechanism to quantitatively evaluate its prediction accuracy. Verification methods include:

[0063] (1) Use the driving behavior data of the last 7 days as the test set and compare the similarity between the strategy output predicted by the model and the user's actual operation (using cosine similarity and dynamic time warping algorithm).

[0064] (2) Conduct special verification of the strategy adaptability in extreme scenarios (such as icy roads and emergency obstacle avoidance) to ensure that the transfer learning effect meets the standards;

[0065] (3) Check whether the output of the sub-model meets the preset physical boundaries (such as maximum output torque, maximum steering angle rate).

[0066] In some embodiments of this application, the accuracy evaluation indicators include: driving intention recognition accuracy, strategy matching degree, abnormal scene response rate, etc. The model can only enter the next stage when the overall accuracy reaches 95% or more.

[0067] S412: Accuracy not met, feature optimization and model parameter tuning. Specifically, if model validation fails to meet the standards, the system automatically initiates a diagnostic and optimization process. The system first analyzes the source of error: if the physiological data is too noisy, the filtering algorithm order is increased; if the scene preference fitting deviation is caused by a bias, the range of adjacent nodes in the graph neural network is expanded; if the behavioral sequence modeling is distorted, the Transformer attention window length is adjusted; if the data samples are insufficient (e.g., in rare extreme scenarios), the cloud-based collaborative training mechanism is invoked to introduce anonymized data from similar users for reinforcement learning. The system automatically performs parameter fine-tuning, feature engineering optimization, and model structure fine-tuning until the accuracy threshold is met, ensuring that the model evolution process remains within a controllable, interpretable, and verifiable range.

[0068] S414: Accuracy met, output user digital twin model. Specifically, once the model passes accuracy verification, the system solidifies it as the current version of the user digital twin model, marks it as "available," and synchronously uploads it to the strategy generation engine. This model serves as the sole basis for generating the vehicle control strategy, carrying a complete digital mapping of user identity, behavioral habits, scenario preferences, and physiological responses.

[0069] S416: Control Strategy Generation and Execution. Specifically, based on the validated digital twin model, the system invokes a dual-track algorithm combining deep reinforcement learning and transfer learning to generate collaborative control strategies covering six functional domains: powertrain, chassis, thermal management, intelligent driving, body, and energy. For example, when the model identifies a user preference for high-speed cruising and the current weather is clear, the system will simultaneously improve power response sensitivity, reduce suspension damping, optimize battery discharge rate, tighten seatbelt pretensioners, and activate energy-saving air conditioning mode. Furthermore, after all strategies undergo dual safety and compliance verification (functional safety boundary locking and compliance verification), they are distributed to each domain controller for execution via an SOA service architecture, achieving precise, latency-free, and conflict-free responses across all domains.

[0070] S418: Execution feedback data collection. Specifically, after the control strategy is executed, the system continuously collects the user's actual response data to the strategy, including: operation feedback (whether manual intervention is required), system alarm log (whether redundant backup is triggered), energy consumption changes, driving stability indicators (such as lateral acceleration fluctuations), and user voice evaluation (such as feedback through the vehicle system saying "too sensitive" or "too sluggish").

[0071] S420: Model Iterative Optimization. Specifically, the execution feedback data and the original target data together form a new training sample set, triggering a new round of iterations from S402 to S418.

[0072] In some embodiments of this application, the following steps may also be performed: determining the physiological state of the target object based on the fourth sub-model; matching the physiological state with a preset state to obtain a matching result; and adjusting the control strategy based on the physiological state when the matching result indicates that the physiological state conforms to the preset state.

[0073] It should be noted that the fourth sub-model is the physiological state adaptation sub-model, one of the four core dimensions of the user digital twin model. It is specifically used to dynamically capture and quantify the driver's real-time physiological state, including non-obvious physiological indicators such as fatigue level, concentration level, emotional fluctuations, heart rate changes, and skin conductance. Preset states refer to a set of safety and comfort control thresholds predefined by the system that correspond to the driver's physiological state. Each threshold corresponds to a specific control strategy response level. These states are not fixed but are scientifically categorized based on ergonomic research, medical reference standards, and user group surveys, such as "normal state," "mild fatigue," "moderate fatigue," "high tension," and "distracted attention."

[0074] Specifically, the system presets multiple physiological state levels and their corresponding numerical ranges. For example, "mild fatigue" is defined as a fatigue score of 0.4–0.6, a heart rate variability reduction of more than 15%, and an increase in skin conductance fluctuation of 20%. The system performs fuzzy matching between the comprehensive physiological index output by the fourth sub-model and each level range, uses a membership function to calculate the probability of it belonging to each state, and finally selects the state with the highest probability that exceeds the threshold (such as 0.7) as the matching result.

[0075] As an example, when the matching result is "moderate fatigue", the system immediately activates the "safety enhancement strategy package": the power domain limits the maximum torque output to 70% and slows down the throttle response slope; the chassis domain increases the intervention sensitivity of the Electronic Stability Program (ESP) and reduces the steering assist gain to reduce the handling burden; the intelligent driving domain enhances the intervention intensity of lane keeping and forward collision warning and shortens the warning time; the thermal management domain activates seat ventilation and air conditioning cooling to improve comfort; and the body domain automatically tightens the seat belt pretensioner and turns off unnecessary entertainment prompts to reduce distraction.

[0076] Step S206: A digital twin model is used to determine the control strategy corresponding to the driving intention, wherein the control strategy is used to coordinate the control of multiple functional domains of the target vehicle.

[0077] In step S206 above, the control strategy refers to a set of coordinated execution instructions automatically generated by the system to achieve a specific driving intention and oriented towards multiple functional domains (power, chassis, thermal management, intelligent driving, body, energy) of the target vehicle. This strategy is not an adjustment of a single function, but a joint solution for synchronous optimization of parameters of multiple domains.

[0078] In some embodiments of this application, the control strategy corresponding to the driving intention can be determined by: obtaining an objective function, wherein the objective function is used to reflect the target object's satisfaction with using the target vehicle from multiple dimensions; using a digital twin model as the state space and the objective function as the reward function to generate control parameters corresponding to multiple functional domains respectively; and determining the control strategy based on the control parameters.

[0079] It should be noted that the objective function refers to a comprehensive quantitative evaluation system used to comprehensively evaluate the overall impact of vehicle control strategies on user experience from multiple core dimensions such as user driving satisfaction, driving safety, ride comfort and energy efficiency. This function is not a single indicator, but a multi-objective optimization function constructed by weighted integration of multiple observable and measurable behavioral and physical parameters. Its essence is to transform the user's implicit subjective preferences into objective evaluation standards that the system can calculate.

[0080] The state space specifically refers to a multidimensional dynamic variable set composed of all contextual information represented by the user's digital twin model, including four-dimensional coupled features such as static attributes (e.g., age, driving experience), dynamic behaviors (e.g., steering preferences, braking habits), scenario preferences (e.g., tendency to slow down in rainy weather), and physiological states (e.g., fatigue, attention). This state space is not a static snapshot, but a real-time state stream that is continuously updated during the driving process. In the policy generation process, the state space serves as the input environment for deep reinforcement learning, enabling the system to dynamically adjust the policy output based on the current user's personalized characteristics.

[0081] Control parameters refer to the specific execution parameter values ​​that can be independently adjusted in multiple functional domains such as power, chassis, thermal management, intelligent driving, body, and energy to achieve specific control objectives. These parameters include the maximum output torque of the motor, suspension damping coefficient, braking pressure gradient, energy recovery intensity, steering assist gain, and air conditioning temperature setting. These parameters are the execution instructions for the final implementation of the control strategy. Their values ​​are obtained by reinforcement learning algorithms through joint optimization of the objective function and state space. They are not preset fixed values, but rather continuous variables that are dynamically generated as the user's intentions evolve.

[0082] Specifically, by collecting user behavior feedback data under different control strategies over a long period of time (such as whether manual intervention is required, whether the mode is adjusted, voice evaluation content, and vehicle system satisfaction rating), and combining it with physical data (such as acceleration fluctuations, energy consumption curves, and braking distance), a multi-objective preference prediction model can be trained using machine learning methods. This model decomposes satisfaction into multiple quantifiable sub-objectives, and through weighted summation and normalization, forms the final objective function expression.

[0083] Furthermore, a deep reinforcement learning algorithm is employed, using the real-time output of the digital twin model (such as a four-dimensional coupled feature vector) as the state input, the set of control parameters from multiple functional domains as the action space, and the output value of the objective function as the immediate reward. In an offline simulation environment, the system simulates millions of driving scenarios, continuously adjusting the combination of control parameters through a policy network (such as SAC or PPO algorithms) to maximize the cumulative reward. For example, if the system discovers that "increasing suspension stiffness + enhancing steering feel" significantly improves the user's satisfaction score in corners while only slightly increasing energy consumption, this parameter combination is retained as the optimal strategy. After training, this policy network is deployed to the vehicle to achieve the mapping between real-time state and parameters.

[0084] To accelerate policy convergence and improve generalization ability, a transfer learning-assisted training mechanism can be introduced. Specifically, the "similar intent group" policy from the historical data of tens of millions of users aggregated in the cloud is used as prior knowledge to initialize the local policy network. For example, if the system detects that the current user is highly similar to a certain type of "young professional driver" in terms of behavioral characteristics, the optimized control parameters of that group are directly loaded as initial values, and then fine-tuned based on the vehicle's data, which greatly shortens the training cycle and improves the efficiency of policy generation.

[0085] After obtaining the control parameters, the control strategy can be determined as follows: obtain the parameter thresholds corresponding to multiple functional domains; compare the control parameters of each functional domain with the corresponding parameter thresholds to obtain the comparison results; if the comparison results indicate that the control parameters of multiple functional domains are all less than the parameter thresholds, determine the initial control strategy based on the control parameters; perform compliance verification on the initial control strategy to obtain the verification results; if the verification results indicate that the verification passed, the control strategy is obtained.

[0086] It should be noted that parameter thresholds refer to the set of hard operating boundary values ​​set for each functional domain to ensure the safety of the vehicle and not exceed the limits of the hardware design.

[0087] Specifically, a static safety threshold library determined by the engineering design team can be pre-installed when the vehicle leaves the factory. For example, the maximum peak torque of the motor is 1800 N·m, and the upper limit of the battery discharge rate is 3C (these values ​​are for illustrative purposes only). These thresholds serve as a basic protection layer. Subsequently, a parallel computing architecture is used to perform millisecond-level synchronous comparisons between the control parameters and thresholds of the six functional domains. Only when the control parameters of all functional domains pass the safety boundary verification does the system package the parameters of each domain into an initial control policy, assigning it a timestamp and version identifier, and handing it over to the compliance verification module for processing. Further, the compliance verification module semantically matches each parameter action in the initial policy with the clauses in the rule base. Once the initial policy passes all compliance verifications, the system marks it as the "final control policy," writes it into the execution queue, and synchronously distributes it to the six functional domain controllers through an SOA service architecture.

[0088] It is understandable that the control strategy includes target control parameters corresponding to multiple functional domains. To avoid safety risks caused by component aging, the following steps can also be performed: obtain feature vectors corresponding to multiple functional domains, where the feature vectors are used to characterize the health status of the functional domains; determine the health score corresponding to the feature vectors; if the health score is less than a preset score, reduce the threshold of the corresponding functional domain, where the threshold is used to limit the safe range of the target control parameters.

[0089] It should be noted that the threshold here refers to the parameter threshold mentioned above, which is the maximum allowable upper limit of the target control parameters set for each functional domain to ensure the safe operation of the whole vehicle.

[0090] Specifically, operational data is continuously collected through high-precision sensor networks built into each functional domain. All raw data is filtered, normalized, and feature-extracted, resulting in a 12–20 dimensional feature vector specific to each domain. Subsequently, a multi-layer neural network health assessment model is used, inputting the feature vector into a pre-trained regression network to output a health score. This model has been trained using thousands of sets of long-term real-vehicle operating data (including fault samples) before leaving the factory and is capable of identifying non-linear degradation patterns. Furthermore, by preset multiple health threshold levels, for example, when the power domain health drops to 82%, the system automatically lowers the maximum torque output threshold from 1800 N·m to 1620 N·m (-10%), while simultaneously reducing the upper limit of the battery discharge rate to prevent thermal runaway caused by motor overload.

[0091] Figure 5 This is a flowchart illustrating the control strategy evolution and verification process of a control strategy determination method according to an embodiment of this application, as shown below. Figure 5 As shown, in some embodiments of this application, the control strategy is determined through the following steps:

[0092] S502: User Digital Twin Model Input. Specifically, the user digital twin model, constructed from multi-dimensional data fusion, serves as the state input, comprehensively representing the user's static attributes, dynamic behavioral patterns, scenario preference characteristics, and real-time physiological state.

[0093] S504: Deep Reinforcement Learning Policy Training. Specifically, based on the user intent expressed by the digital twin model, a deep reinforcement learning framework guided by a multi-objective reward function is constructed. This process, supported by both offline simulation environment and online driving data, continuously iterates and optimizes through the policy network to find the optimal combination of control parameters that achieves a balance among multiple dimensions such as user satisfaction, driving safety, ride comfort, and energy efficiency, thus realizing end-to-end autonomous learning from behavior observation to policy generation.

[0094] S506: Generation of multi-domain collaborative candidate strategies. Specifically, based on the parameters output by deep reinforcement learning, the system further integrates the collaborative constraints of six functional domains: power, chassis, thermal management, intelligent driving, body, and energy, to generate multiple sets of candidate control strategies. This stage emphasizes the temporal consistency and action coupling of the control logic of each domain to ensure that the strategy has overall collaborative capability at the functional level and avoids system imbalance caused by optimization of a single domain.

[0095] S508: Offline simulation evaluation of strategy effectiveness. Specifically, to screen candidate strategies with practical optimization potential, the system conducts large-scale simulation tests on each group of candidate strategies in a high-fidelity virtual environment. The system evaluates their comprehensive performance under various typical and extreme driving scenarios through quantitative indicators. The evaluation results are used to eliminate inefficient, unstable, or experience-degraded strategies, and only candidate solutions with better performance than the current strategy are retained for subsequent verification, ensuring that strategy evolution has positive iterative characteristics.

[0096] S510: Evaluation passed, functional safety boundary lock-up verification. Specifically, the strategy evaluated through simulation enters the functional safety verification stage. Based on the vehicle design limits and component load-bearing capacity, the system presets dynamic safety thresholds for each functional domain. In this stage, hard boundary comparisons are performed on the strategy parameters to ensure that all control commands do not exceed the system's physical safety boundaries, and the safety margin is automatically reduced under component performance degradation conditions.

[0097] S512: Verification passed, international compliance verification. Specifically, after functional safety verification is passed, the strategy enters the compliance verification stage. Through the built-in national and industry mandatory standard rule library, semantic-level comparison is performed on the logical behavior, intervention timing, and functional boundaries of the control strategy to ensure that it fully complies with the requirements and to prevent any automated control behavior that may violate road traffic safety regulations.

[0098] S514: Verification passed, policy is issued to the vehicle domain for execution. Specifically, the policy that has been double-verified to ensure safety and compliance will serve as the final control command and will be synchronously issued to the six functional domain controllers in a highly reliable and low-latency manner through a service-oriented architecture (SOA) to achieve coordinated execution across the entire domain.

[0099] S516: If S510 or S512 fails the verification, the strategy parameters are rolled back and adjusted. Specifically, if any verification step fails, the system immediately activates the strategy rollback mechanism, dynamically trimming or reconstructing parameters that exceed the boundaries or violate compliance based on preset correction rules, generating a new compliant subset, and re-entering the simulation evaluation process.

[0100] S518: Execution feedback data closed-loop optimization. Specifically, after the strategy is executed, the system continuously collects vehicle operation data and user operation feedback to build a database of execution effects in real driving scenarios. This data is then fed back to the digital twin model and reinforcement learning training framework to correct model parameters and optimize reward function weights, thereby improving the accuracy and adaptability of subsequent strategy generation.

[0101] The above process constructs a closed-loop, controllable, and traceable strategy evolution system through five mechanisms: intelligent generation, simulation prediction, security locking, compliance verification, and execution feedback. This system ensures personalized user experience while fully meeting functional safety and mandatory regulatory requirements.

[0102] In some specific embodiments of this application, based on the user digital twin model, a dual-track evolutionary algorithm combining deep reinforcement learning (DRL) and transfer learning is used to generate a fully coordinated control strategy for all six domains of the vehicle, achieving seamless self-evolution:

[0103] (1) Deep reinforcement learning training unit: Using user driving satisfaction, driving comfort, driving safety and energy utilization efficiency as reward functions and user digital twin model as environmental input, offline and online joint training is carried out to generate collaborative control strategies covering six core domains. For example, if the user's preference for aggressive driving is identified, a vehicle-level collaborative strategy of "sport mode power output, hard suspension support, fast steering response, high-rate battery discharge and aggressive thermal management strategy" is generated simultaneously, rather than a single function adjustment.

[0104] (2) Transfer learning generalization unit: In some embodiments of this application, the training model of the regular scenario can also be generalized to extreme scenarios such as rain and snow, ice, mountain bends, and emergency avoidance through transfer learning based on the extreme scenario data of massive users in the cloud, so as to solve the model adaptation problem of small sample extreme scenarios and the extreme scenario strategy adaptation degree ≥95%.

[0105] (3) Multi-domain collaborative strategy generation unit: In some embodiments of this application, the collaborative generation and timing matching of six domain control strategies can also be realized based on SOA service architecture to ensure that the control logic of each domain is free from conflict and fragmentation.

[0106] (4) Strategy effect evaluation unit: In some embodiments of this application, the generated candidate strategies can also be evaluated offline through simulation. Only when the strategy effect is better than the current strategy will it enter the next level of verification to ensure that the evolved strategy experience is continuously optimized.

[0107] In some embodiments of this application, a dual protection mechanism of functional safety boundary locking and national standard compliance verification can be constructed to ensure that all self-evolutionary strategies always remain within the safety and compliance boundaries and meet functional safety requirements.

[0108] (1) Functional safety boundary locking unit: preset the design safety limit threshold of each system of the vehicle (such as the maximum output torque of the motor, the maximum discharge rate of the battery, the suspension stiffness limit, the steering ratio range, and the intelligent driving functional safety boundary). All parameters of the self-evolution strategy must not exceed the threshold. At the same time, a dynamic boundary is set. When battery aging, motor attenuation, or brake system wear is detected, the safety boundary is automatically contracted to avoid safety risks caused by component aging.

[0109] (2) National standard compliance verification unit: It has a built-in rule library for running security technical conditions and other related rules. All self-evolution strategies must pass the compliance verification to ensure that they meet the requirements.

[0110] (3) Strategy Redundancy Backup Unit: In some embodiments of this application, the original factory basic strategy can also be stored as a redundant backup. When the self-evolution strategy fails the verification or an abnormality occurs during the execution process, it can immediately and seamlessly switch to the original factory basic strategy to ensure that the vehicle driving safety is uninterrupted.

[0111] Step S208: The control policy is distributed to the domain controllers corresponding to the multiple functional domains.

[0112] In step S208 above, a domain controller refers to a dedicated electronic control unit in the vehicle that independently undertakes the calculation and execution of control logic for a specific functional domain. These domain controllers correspond to the powertrain domain controller, chassis domain controller, thermal management domain controller, intelligent driving domain controller, body domain controller, and energy domain controller, respectively. Each domain controller has independent sensor inputs, actuator outputs, and local algorithm processing capabilities. Its function is to receive control strategy instructions from the central computing platform and convert them into specific electrical signals, mechanical actions, or energy distribution instructions within its respective functional domain, thereby achieving precise control of physical quantities such as motor torque, suspension damping, air conditioning power, braking pressure, and steering assist.

[0113] In some embodiments of this application, a service-oriented architecture is adopted, encapsulating each functional domain parameter in the control strategy as an independent service request and binding it to a unique identifier and execution time window of the target domain controller. The central computing platform sends service call instructions to each domain controller in parallel through a standardized communication bus (such as CAN FD or Ethernet TSN), ensuring that the instructions arrive synchronously under a unified time base. Each domain controller only receives service content related to its responsibilities; for example, the power domain only processes parameters such as torque output and battery discharge rate, and the chassis domain only receives instructions such as suspension stiffness, steering assist, and ESP intervention intensity.

[0114] To ensure millisecond-level coordination of policy commands across multiple domains, a precise clock synchronization protocol and execution feedback confirmation mechanism can be introduced during the distribution process. Each control command carries a high-precision timestamp. After receiving the command, the domain controller must complete local parsing and execution preparation within a preset response window and return a "received" or "executed" confirmation signal to the central platform. If a domain fails to confirm within the specified time, the system automatically initiates a retransmission mechanism and marks the controller as "response abnormal." At the same time, a redundant policy degradation contingency plan is activated to ensure that the overall control link is not interrupted due to a single point of failure.

[0115] OTA upgrades can be implemented in the following ways: receiving a basic strategy published by the development team, whereby the basic strategy is used to update the underlying control logic of the target vehicle; updating the underlying control logic of the target vehicle based on the basic strategy to obtain the target basic strategy, whereby the basic strategy is decoupled from the digital twin model; and merging the target basic strategy with the digital twin model.

[0116] It should be noted that the basic strategy refers to a standardized set of control instructions released by the OEM's development team to uniformly optimize the underlying control logic of the entire vehicle. This includes baseline algorithms covering core functional modules such as power response characteristics, energy recovery strategies, thermal management logic, and intelligent driving intervention logic. Decoupling refers to the physical and logical isolation at the system architecture level between the OEM's basic strategy and the user's personal digital twin model in terms of data storage, computational logic, and update mechanisms, ensuring that the two do not interfere with or affect each other.

[0117] Specifically, OEMs push structured basic policy update packages to the vehicle's central computing platform via an encrypted OTA channel. These packages contain the new version's control algorithm parameters, logical rule descriptions, security boundary definitions, and version numbers. Upon receiving the basic policies, the OEM loads the control logic from the basic policy package into the central computing platform's independent policy engine as a modular service. This engine only processes the baseline logic defined by the OEM, and its operating environment is completely isolated from the training and inference environment of the user's digital twin model. The update process only replaces the underlying algorithm modules and does not touch the user behavior data storage area, ensuring the integrity and security of the user's personalized model.

[0118] Furthermore, the fusion process adopts a "baseline overlay + preference priority" mechanism. The system uses the target basic strategy as a unified control benchmark and uses the user preference parameters (such as steering feel preference value, braking response delay setting, and energy recovery intensity weight) stored in the digital twin model as personalized fine-tuning parameters, which are dynamically overlaid on the output of the basic strategy.

[0119] Through the above embodiments, users can maintain their original driving style and operating habits after each OTA upgrade without having to manually reset them. At the same time, the underlying improvements such as safety optimizations, energy efficiency enhancements, and compliance released by OEMs can be implemented without loss.

[0120] Figure 6 This is a flowchart of an OTA co-evolution decoupling method for determining a control strategy according to an embodiment of this application, as shown below. Figure 6 As shown, in some embodiments of this application, OTA upgrades are implemented through the following steps:

[0121] S1: The OEM's OTA platform sends an OTA upgrade package to the vehicle's OTA collaborative evolution layer. Specifically, the OEM sends a structured upgrade package containing new version control logic, algorithm parameters, function update instructions, and version identifier to the target vehicle's central computing platform through a secure and encrypted channel.

[0122] S2: The vehicle-side OTA collaborative evolution layer performs a full backup of the user model to the user's personalized model library. Specifically, before the upgrade starts, the system performs a complete encrypted backup of all parameters, feature weights, and historical evolution records of the current user's digital twin model, storing them in an independent, protected user personalized model library.

[0123] S3: The vehicle-side OTA collaborative evolution layer upgrades the underlying logic of the original factory basic strategy to the original factory basic strategy library. Specifically, the new basic strategy in the received OTA upgrade package is loaded into the original factory basic strategy library in a modular manner, replacing the original version.

[0124] S4: The vehicle-side OTA collaborative evolution layer performs offline simulation compatibility verification. Specifically, in a local simulation environment, based on the new basic strategy and combined with the user-personalized model backed up in S2, a virtual driving scenario is constructed for large-scale offline verification. This process evaluates the stability, safety, and consistency of the integrated control strategy under various typical and extreme conditions, determines whether there are logical conflicts, response mismatches, or performance degradation, and ensures that the upgraded system behavior meets expectations, avoiding deployment risks.

[0125] S5: The vehicle-side OTA collaborative evolution layer extracts personalized user features. Specifically, it extracts core personalized feature parameters from the backed-up user model, including key dimensions such as behavioral preference weights, scene response patterns, and physiological state adaptation mapping relationships.

[0126] S6: The vehicle-side OTA collaborative evolution layer integrates the new basic strategy with the user model. Specifically, based on the personalized features extracted by S5, it uses a semantic consistency alignment and parameter weighting superposition mechanism to intelligently embed user preferences into the control framework of the new basic strategy.

[0127] S7: The vehicle-side OTA collaborative evolution layer distributes the integrated collaborative control strategy to the vehicle domain execution layer. Specifically, the final control strategy after integration is formatted and encapsulated, and then synchronously distributed to the six functional domain controllers of powertrain, chassis, thermal management, intelligent driving, body, and energy through a service-oriented architecture (SOA) in a highly reliable and low-latency manner.

[0128] S8: Vehicle Domain Execution Layer Execution Feedback and Effect Verification. Specifically, during the execution of new strategies, each domain controller continuously collects actual operating data and user operation feedback, including execution accuracy, response latency, system load, and abnormal events, and transmits this real-time feedback information back to the OTA collaborative evolution layer.

[0129] S9: The vehicle-side OTA collaborative evolution layer returns upgrade completion and adaptation feedback to the OEM OTA platform. Specifically, it sends a structured upgrade report to the OEM OTA platform, including upgrade status (success / failure), user model adaptation score, key strategy fusion results, and abnormal event statistics.

[0130] In some embodiments of this application, in order to achieve full-scenario adaptive evolution, the following steps may also be performed: determining the target scenario in which the target vehicle is located from the target data, wherein the target scenario includes driving scenarios under extreme conditions; acquiring historical driving data corresponding to the target scenario, and driving behavior data of the target object in non-target scenarios, wherein the driving behavior data serves as prior knowledge; and determining the target control strategy of the target object in the target scenario based on the driving behavior data and historical driving data.

[0131] It should be noted that the target scenario refers to driving situations with significant environmental specificity and operational complexity that the vehicle encounters in actual operation, especially driving scenarios under extreme conditions, such as rainy or snowy roads, icy curves, continuous mountain slopes, low visibility at night, and sudden obstacle avoidance—non-daily commuting environments. Extreme conditions refer to atypical driving environments that exceed normal usage conditions encountered by the vehicle during actual operation. These conditions are usually formed by the combined effects of extreme weather, complex terrain, sudden obstacles, or special road conditions, placing stringent requirements on multiple functional domains of the vehicle that far exceed design benchmarks.

[0132] Historical driving data refers to actual driving behavior records from a large number of anonymous users aggregated by a cloud system in a target scenario. This includes operational inputs (such as steering angle and braking pressure), vehicle responses (such as lateral acceleration and ESP intervention frequency), environmental parameters (such as road surface adhesion coefficient and temperature), and the final safety outcome. This data does not contain personally identifiable information and is a de-identified collection of collective experience. Driving behavior data refers to highly individualized operational habit data accumulated over a long period by the target individual in routine driving scenarios (such as urban commuting, highway cruising, and daily parking). This data includes acceleration rhythm, braking timing, steering preferences, and vehicle-machine interaction methods. This data is continuously stored and updated by the user's digital twin model, forming the baseline of their personalized behavior.

[0133] Specifically, the current environmental state can be identified in real time through multi-source sensor fusion. By combining navigation map data, environmental perception systems (such as millimeter-wave radar and cameras), and vehicle dynamic signals, a scene classification model can be constructed. Subsequently, a group historical driving dataset matching the current target scene label is downloaded from the cloud security server. At the same time, the local digital twin model retrieves the user's regular driving behavior data accumulated over the past three months. The two types of data are then spatiotemporally aligned and feature normalized. The operating parameters (such as steering angle rate and braking pressure gradient) in the historical data and the behavioral patterns (such as acceleration smoothness and braking delay) in the user's prior data are uniformly mapped to the same feature space.

[0134] Furthermore, a transfer learning framework is employed, using user driving behavior data in normal scenarios as "source domain knowledge" and historical extreme scenario data from the cloud as "target domain knowledge." Through feature space mapping and parameter fine-tuning, an extreme scenario control strategy adapted to the user is generated. In addition, a confidence-weighted mechanism can be introduced during the fusion process, dynamically adjusting the weights of the two types of data based on the similarity score of the user's historical behavior in such scenarios: if the user has never driven in a similar extreme scenario before, the system assigns higher weight to historical data, prioritizing group experience; if the user has not personally experienced the scenario but their routine behavior is highly consistent (e.g., consistently conservative driving), the system assigns higher weight to prior data.

[0135] Figure 7 This is a flowchart illustrating the extreme scenario strategy generalization and adaptation of a control strategy determination method according to an embodiment of this application, such as... Figure 7 As shown, in some implementations of this application, the generalization of extreme scenarios can be achieved through the following steps:

[0136] S702: User Model Training for Regular Scenarios. Specifically, based on multi-dimensional behavioral data accumulated by users in regular driving scenarios (such as urban commuting, highway cruising, and suburban driving), a high-precision user digital twin model is constructed. This model accurately fits the user's driving habits, vehicle system usage preferences, and response rhythm through Transformer temporal modeling and multimodal fusion technology, forming an individualized behavioral baseline.

[0137] S704: Cloud-based Extreme Scene Dataset. Specifically, it acquires anonymized driving data of vehicles under extreme conditions (such as icy roads, mountain curves, and night driving in heavy rain) through a cloud platform, forming a large-scale group behavior database covering various extreme scenarios. This dataset includes raw sensor signals, vehicle dynamic responses, environmental parameters, and operating trajectories, covering different regions, vehicle models, and driving styles.

[0138] S706: Transfer Learning Feature Mapping. Specifically, in the offline phase, the system employs a transfer learning algorithm to align high-dimensional behavioral features (such as acceleration smoothness, braking delay distribution, and steering angular velocity patterns) extracted from the user model in regular scenarios with typical response features from the cloud-based extreme scenario dataset. Through feature sharing and parameter mapping mechanisms in deep neural networks, the system constructs an implicit correlation between behavioral patterns and safety responses, enabling the driving style developed by users in regular scenarios to be reasonably transferred to the physical constraints of extreme scenarios.

[0139] S708: Real-time scene recognition. Specifically, the vehicle integrates navigation maps, environmental perception sensors (millimeter-wave radar, cameras, temperature and humidity sensors), vehicle dynamic signals (wheel speed, lateral acceleration, yaw rate), and vehicle-to-everything (V2X) environmental information to construct a semantic perception of the current driving environment in real time. Based on a pre-trained multimodal scene classification model, the collected data is classified with high precision to determine whether it has entered a predefined extreme condition category such as "low-adhesion curve", "strong wind canyon", or "dense fog at night".

[0140] S710: Determine if it is an extreme scenario. Specifically, compare the scenario label output by S708 with the preset extreme condition judgment threshold. If the recognition result meets the multi-dimensional feature combination conditions of an extreme scenario (such as road surface adhesion coefficient less than 0.2, radius of curvature less than 40 meters, ambient temperature less than -5℃), it is judged as an "extreme scenario" and the transfer generalization process is triggered; if it is a normal environment, the trained normal strategy continues to be used.

[0141] S712: Yes, extreme scenario user model generalization. Specifically, after being identified as an extreme scenario, the system calls the transfer learning mapping relationship established in S706 to dynamically adapt the user's personalized behavior model formed in normal scenarios to the physical constraints and safety boundaries of the current extreme situation, generating a user-specific extreme scenario adaptation model.

[0142] S714: No, execute the normal scenario strategy. Specifically, if the extreme scenario is not identified, the system directly calls the normal control strategy generated by the user's digital twin model.

[0143] S716: Extreme Scenario Collaborative Strategy Generation. Specifically, after the user model for extreme scenarios is generalized, the system initiates a multi-domain collaborative control strategy generation mechanism. Based on the output of the generalized model, it synchronously coordinates the control parameters of six functional domains: power, chassis, thermal management, intelligent driving, body, and energy, forming a unified, conflict-free, and time-matched collaborative instruction set.

[0144] S718: Dual verification of safety and compliance. Specifically, the generated extreme scenario strategy must pass two mandatory verifications: the first is the functional safety boundary locking verification, which ensures that all control parameters are within the design physical limits and dynamic safety thresholds of each domain; the second is the compliance verification, which ensures that the strategy complies with mandatory standards and eliminates any behavior that may violate the driving automation classification or safety technical conditions.

[0145] S720: Verification passed, extreme scenario policy execution. Specifically, policies that have been double-verified to ensure security and compliance are synchronously distributed to each domain controller for execution via Service-Oriented Architecture (SOA), and a high-priority response mode is initiated.

[0146] S722: User Operation Feedback Collection. Specifically, during extreme scenario execution, the system continuously collects the user's actual operation behavior (such as whether to actively intervene in braking or correct steering) and vehicle response data (such as actual deceleration, roll angle, and system intervention frequency) to form closed-loop data in the real world.

[0147] S724: Real-time iterative optimization of the model. Specifically, the collected user feedback data and execution results in extreme scenarios are sent back to the cloud for incremental training of the transfer learning model, optimizing feature mapping relationships and policy generation weights. Simultaneously, the vehicle-side digital twin model updates the user's behavioral preferences in extreme environments based on the interaction results, enabling the system to be more adaptable when encountering similar scenarios again.

[0148] In some embodiments of this application, in order to achieve vehicle-cloud collaborative evolution, the following steps may also be performed: obtaining local digital twin models corresponding to multiple vehicles respectively; uploading the target parameters of the multiple local digital twin models to the cloud, wherein the target parameters are used for joint training in the cloud; receiving the optimized parameters obtained from the joint training in the cloud, and updating the local digital twin models based on the optimized parameters.

[0149] Specifically, the central computing platform of each vehicle continuously collects user behavior data during daily driving. Combining this data with environmental, physiological, and scenario information, it uses multimodal fusion algorithms and Transformer temporal modeling to build and continuously update an individualized digital twin model locally. Subsequently, based on preset parameter extraction rules, only high-value, low-sensitivity target parameters, such as behavioral preference weights, strategy optimization directions, and scenario response mapping functions, are extracted from the local model. Raw data that can trace user identity (such as timestamps, location coordinates, and voice recordings) is removed. After being encrypted using national cryptographic algorithms, the data is uploaded to a secure cloud data pool in batches, on a scheduled basis, and in a low-frequency manner.

[0150] Furthermore, based on the target parameters uploaded by multiple vehicles, the cloud uses distributed gradient aggregation or model averaging algorithms for joint training to generate global optimization parameters. This parameter set is encrypted and distributed to each vehicle via a secure channel. The vehicle system only replaces the corresponding parameter modules in the local model, such as the weights of the reinforcement learning reward function and the feature alignment coefficients of transfer learning, while keeping the rest of the structure unchanged, ensuring that the update process is lightweight and low-risk.

[0151] The above embodiments enable each vehicle to learn from the driving experience of tens of thousands or even hundreds of thousands of users without disclosing the user's original data, significantly improving the generalization ability, strategy stability and behavior prediction accuracy in extreme scenarios.

[0152] Through steps S202 to S208, multi-source data fusion and digital twin modeling are employed. By collecting operational status data of multiple functional domains of the target vehicle and driving status data of the target object, a digital twin model capable of mapping driving intentions in multiple dimensions is constructed. Based on this model, a control strategy for collaborative execution across multiple functional domains is automatically generated and uniformly distributed to each domain controller for execution. This achieves the goal of accurately identifying the user's true driving intentions and realizing dynamic adaptation of the whole vehicle's full-domain strategy. As a result, the technical effect of highly matching the control strategy with driving needs and multi-domain linkage response is achieved. This solves the technical problem of related technologies that use vehicle adaptive control learning based on static learning logic, which only covers a few isolated functions such as air conditioning and driving modes, resulting in a serious disconnect between the control strategy and real driving needs and low vehicle control accuracy.

[0153] This application also provides a vehicle, including a sensor network, a central computing platform, and a domain controller. The sensor network, connected to the central computing platform, is used to collect target data of the target vehicle. The target data reflects the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle. The central computing platform, connected to both the sensor network and the domain controller, is used to determine a digital twin model corresponding to the target data and to determine a control strategy using the digital twin model. The digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions, and the control strategy is used to coordinate the control of multiple functional domains of the target vehicle. The domain controller, connected to the central computing platform, is used to execute the control strategy.

[0154] It should be noted that the aforementioned central computing platform is used to execute... Figure 2 The method for determining the control strategy shown is therefore Figure 2 The explanations and descriptions regarding the determination of control strategies in the above-mentioned central computing platform also apply, and will not be repeated here.

[0155] Figure 3 This is a system architecture diagram of a method for determining a control strategy according to an embodiment of this application, as shown below. Figure 3 As shown, in some embodiments of this application, the system includes:

[0156] The full-dimensional data acquisition layer 302 includes: vehicle domain data acquisition unit, user behavior data acquisition unit, scene environment data acquisition unit, user physiological state data acquisition unit, and spatiotemporal synchronization and preprocessing unit.

[0157] Specifically, this layer is responsible for collecting raw data in real time and with high precision from four dimensions: vehicle, user, environment, and physiology. It collects four-dimensional data synchronously through four sub-units and processes the data through spatiotemporal synchronization and preprocessing units.

[0158] (1) Vehicle domain data acquisition unit: acquires the operating parameters of the six domains of power, chassis, thermal management, intelligent driving, body and energy from CAN / Ethernet at a preset frequency, and constructs a real-time snapshot of the vehicle status;

[0159] (2) User behavior data collection unit: Based on steering wheel angle, pedal travel, vehicle operation log and eye tracking, capture user operation sequence and interaction habits;

[0160] (3) Scene environment data acquisition unit: integrates high-precision maps, positioning and environmental sensors to identify dynamic environmental elements such as road type, weather, lighting and traffic rules;

[0161] (4) User physiological state data acquisition unit: continuously monitor physiological indicators such as fatigue, attention, heart rate, mood and physical impairment through DMS camera, millimeter-wave radar and wearable device;

[0162] (5) Spatiotemporal synchronization and preprocessing unit: The PTP protocol is used to achieve sub-millisecond alignment of all heterogeneous data, complete cleaning, noise reduction, format standardization and initial feature extraction, and form a full input of a unified spatiotemporal reference.

[0163] The user digital twin model layer 304 includes: user static attribute sub-model, user dynamic behavior sub-model, scenario preference sub-model, physiological state adaptation sub-model, and model iteration optimization unit.

[0164] Specifically, (1) User static attribute sub-model: solidify invariant features such as age, driving experience, and physical condition as the initial boundary for strategy generation;

[0165] (2) User dynamic behavior sub-model: Based on the Transformer network, the operation sequence of acceleration, braking, steering, etc. is modeled to achieve high-precision temporal mapping of behavioral features;

[0166] (3) Scene preference sub-model: Graph neural network (GNN) is used to learn the user's strategy preferences in different road conditions and environments, and form a "scene-control" correlation matrix;

[0167] (4) Physiological state adaptation sub-model: Through multimodal fusion algorithm, establish dynamic response functions of physiological indicators such as fatigue and attention with control parameters (such as braking sensitivity and power smoothness);

[0168] (5) Model Iteration Optimization Unit: Based on newly collected data, the parameters of the four sub-models are automatically updated daily to achieve continuous online evolution of the user behavior model.

[0169] The vehicle control strategy evolution layer 306 includes: a deep reinforcement learning training unit, a transfer learning generalization unit, a multi-domain collaborative strategy generation unit, and a strategy effect evaluation unit.

[0170] Specifically, (1) Deep reinforcement learning training unit: using user satisfaction, safety, comfort and energy efficiency as composite reward functions, and digital twin model as environmental state, to carry out offline and online joint training and autonomously optimize strategies;

[0171] (2) Transfer learning generalization unit: Using extreme scenario data in the cloud, the conventional strategy is transferred to low-sample scenarios such as icing, rainstorm, and emergency obstacle avoidance to achieve cross-scenario capability generalization;

[0172] (3) Multi-domain collaborative strategy generation unit: Based on SOA architecture, it uniformly schedules control commands of six domains: power, chassis, thermal management, intelligent driving, body and energy, to ensure consistent response timing and no logical conflicts;

[0173] (4) Strategy effect evaluation unit: The candidate strategy is subjected to multi-scenario stress test in the simulation environment. Only when the overall performance is better than the current strategy is it allowed to enter the verification process to ensure the positive evolution.

[0174] The OTA co-evolution layer 308 includes: OTA strategy decoupling unit, canary release adaptation unit, and model cloud-based collaborative training unit.

[0175] Specifically, (1) OTA strategy decoupling unit: completely separates the basic strategy in the OEM upgrade package from the user's personalized model in terms of storage, computing and logic. The upgrade only updates the original OEM base and does not disturb the user model.

[0176] (2) Gray release adaptation unit: Based on the characteristics of the user's digital twin model (such as driving style, region, vehicle model), intelligently match the OTA gray release version and verify compatibility in advance;

[0177] (3) Model cloud collaborative training unit: Upload desensitized parameters to the cloud, participate in cross-vehicle joint training, extract the group's optimal generalization ability, and then safely transmit the optimized parameters back to the vehicle, so as to realize the bidirectional enhancement of individual evolution on the vehicle and group evolution on the cloud.

[0178] The security and compliance dual verification layer 310 includes: a functional safety boundary locking unit, an international compliance verification unit, and a policy redundancy backup unit.

[0179] Specifically, (1) Functional safety boundary locking unit: preset the physical limits of each system (such as maximum torque, battery rate, steering ratio), and dynamically tighten the threshold as the components age to prevent the strategy from going out of bounds;

[0180] (2) International compliance verification unit: Built-in rule base, automatically verifies whether the strategy meets mandatory standards;

[0181] (3) Strategy Redundancy Backup Unit: Permanently retain the original factory basic strategy. When the self-evolution strategy verification fails or execution is abnormal, it seamlessly switches to the original factory strategy to ensure uninterrupted driving safety.

[0182] The vehicle domain collaborative execution layer 312 includes: a power domain controller adapter unit, a chassis domain controller adapter unit, a thermal management domain controller adapter unit, an intelligent driving domain controller adapter unit, and a body / energy domain controller adapter unit.

[0183] Specifically, (1) the power domain controller adaptation unit: executes torque output, energy recovery intensity, and acceleration response curve commands to achieve personalized matching of power characteristics;

[0184] (2) Chassis domain controller adapter unit: controls suspension stiffness, steering assist, ESP intervention logic and brake pressure distribution, so that the dynamic response matches the user's handling expectations;

[0185] (3) Thermal management domain controller adapter unit: Links battery preheating / cooling, motor heat dissipation and air conditioning load to achieve coordinated optimization of energy consumption and performance;

[0186] (4) Intelligent driving domain controller adaptation unit: Adjusts the intensity of assisted driving intervention, perception threshold and trajectory planning preference to make intelligent driving behavior conform to the user's psychological expectations;

[0187] (5) Body / Energy Domain Controller Adaptor Unit: Executes commands such as door locking, seat heating, ambient lighting, and energy distribution to improve comfort and user experience;

[0188] All domain controllers receive instructions through a highly reliable communication bus and transmit execution accuracy, response latency, and abnormal events back in real time, providing closed-loop feedback to the model layer to drive continuous optimization.

[0189] It should be noted that the above system is used to execute Figure 2 The method for determining the control strategy shown is therefore Figure 2 The explanations and descriptions regarding the method for determining the control strategy also apply to the above system, and will not be repeated here.

[0190] To facilitate understanding of the method for determining the above control strategy, the following explanation is provided in conjunction with some specific embodiments.

[0191] Example 1: The application scenario involves a novice driver who has just obtained their license, has only one month of driving experience, and primarily commutes in congested urban areas. Their driving skills are inexperienced, with frequent sudden acceleration and braking, and they are unfamiliar with vehicle control. The original equipment manufacturer's (OEM) strategy cannot adapt to the learning process of a novice driver. The execution process includes:

[0192] The system collects static attributes (25 years old, 1 month of driving experience, C2 driver's license), dynamic behavior data (80 starts and stops per day, large fluctuations in accelerator pedal travel, delayed braking operation), and scenario data (90% of driving in urban congestion) to construct a digital twin model of the user during the novice period. The strategy evolution layer generates vehicle-wide collaborative strategies adapted for novice drivers: in the power domain, the maximum torque output is limited to 60%, slowing down throttle response to avoid sudden acceleration; in the chassis domain, the suspension is softened, steering assist is increased, and steering effort is reduced; in the intelligent driving domain, the intervention sensitivity of AEB automatic emergency braking and lane keeping assist is improved, and 360-degree panoramic imaging is automatically triggered; in the thermal management domain, air conditioning is automatically activated. The system adjusts to a comfort mode to reduce manual operation by the user; the safety verification layer performs double verification of the strategy to ensure that all parameters are within the safety boundaries and meet national standards before being sent to the various domain controllers of the vehicle for execution; as the user's driving experience increases, the system continuously collects user behavior data and iterates the digital twin model every 24 hours. After 6 months, the user's driving skills become proficient, the frequency of rapid acceleration and braking decreases by 80%, and the accuracy of vehicle control is greatly improved; the system automatically evolves the vehicle control strategy, gradually removes power torque limitations, adjusts steering and braking response speeds to match the user's proficient driving habits, and requires no manual adjustment of any settings by the user throughout the entire process, achieving seamless adaptation throughout the entire lifecycle.

[0193] Example 2: The application scenario involves an OEM releasing an OTA (Over-The-Air) upgrade package for the entire vehicle, optimizing the powertrain response logic, battery thermal management strategy, and NOA (Noise, Arrival, and Override) efficiency of the intelligent driving system. According to current technology, the OTA upgrade will overwrite the user's previous personalized settings, causing the user's habitual aggressive driving strategies to become ineffective. Its execution process includes:

[0194] The OTA co-evolution layer receives the upgrade package from the OEM and, through the strategy decoupling unit, completely separates the underlying update logic of the original manufacturer's basic strategy from the user's personalized evolution model. Before the upgrade, the system backs up the user's personalized model and simultaneously performs offline simulation to verify the compatibility between the new basic strategy and the user's model, ensuring no conflicts after the upgrade. After the vehicle completes the OTA upgrade, the system automatically integrates the user's personalized evolution model with the new basic strategy, retaining the user's preferred aggressive power output, stiff suspension support, and fast steering response, while also overlaying the OEM's optimized power response logic and improved thermal management efficiency. After the upgrade, the user's driving experience retains their own habits and preferences while also enjoying the OEM's strategy optimization results, completely resolving the conflict between OTA upgrades and user personalization.

[0195] Example 3: The application scenario is a user's daily commuting in the city. The system has learned the user's regular driving habits. In winter, when the user drives to the mountains and encounters extreme scenarios such as icy roads and continuous curves, the existing technology cannot adapt to the user's driving preferences in this scenario, and the control logic does not match the user's expectations. Its execution flow includes:

[0196] The system identifies extreme scenarios such as icy mountain roads and continuous curves by using navigation maps, environmental sensors, and vehicle stability system data. A transfer learning generalization unit, based on massive amounts of user driving data on icy roads in the cloud, generalizes the user's driving model from regular scenarios to the current extreme scenario, fitting the user's braking and steering preferences on low-traction surfaces. The strategy evolution layer generates a vehicle-wide collaborative strategy adapted to this scenario: the chassis domain activates snow mode and adjusts the intervention logic of the ESP vehicle stability system to match the user's braking habits; the power domain limits torque output and slows throttle response to prevent wheel slippage; the intelligent driving domain enhances the intervention intensity of anti-skid and lane-keeping functions while matching the user's steering preferences. The system collects user feedback in real time and continuously iterates and optimizes the strategy to ensure that the vehicle control logic fully matches the user's expectations in extreme scenarios, significantly improving driving safety.

[0197] Figure 8 This is a structural diagram of a control strategy determination device according to an embodiment of this application, such as... Figure 8 As shown, the device includes:

[0198] The acquisition module 802 is used to acquire target data of the target vehicle, wherein the target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle.

[0199] The determination module 804 is used to determine the digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions;

[0200] The control module 806 is used to determine the control strategy corresponding to the driving intention using a digital twin model, wherein the control strategy is used to coordinate the control of multiple functional domains of the target vehicle.

[0201] The distribution module 808 is used to distribute control policies to the domain controllers corresponding to multiple functional domains.

[0202] It should be noted that, Figure 8 The control strategy determination device shown is used to execute Figure 2 The method for determining the control strategy shown is therefore Figure 2 The relevant explanations in the method for determining the control strategy also apply to Figure 8 The device for determining the control strategy shown will not be described in detail here.

[0203] This application also provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the steps of determining the control strategy method implemented in the various embodiments of this application.

[0204] This application also provides a non-volatile storage medium including a stored computer program, wherein the device containing the non-volatile storage medium executes the steps of the control strategy determination method in various embodiments of this application by running the computer program.

[0205] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the control strategy determination method in various embodiments of this application.

[0206] This application also provides a computer program that, when executed by a processor, implements the steps of the control strategy determination method in various embodiments of this application.

[0207] 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.

[0208] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0209] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0210] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated unit 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 application, in essence, or the part that contributes to the prior art, or all or 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 instructions 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0213] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining a control strategy, characterized in that, include: Acquire target data of the target vehicle, wherein the target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle; Determine a digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions; The digital twin model is used to determine a control strategy corresponding to the driving intention, wherein the control strategy is used to coordinate the control of multiple functional domains of the target vehicle; The control strategy is distributed to the domain controllers corresponding to the multiple functional domains.

2. The method according to claim 1, characterized in that, Determining the digital twin model corresponding to the target data includes: The target object's attribute data is extracted from the target data, and a first sub-model is determined based on the attribute data, wherein the first sub-model is used to determine the security boundary of the digital twin model; The behavioral data of the target object is extracted from the target data, and a second sub-model is determined based on the behavioral data, wherein the second sub-model is used to reflect the driving behavior pattern of the target object; The scene preference data of the target object is extracted from the target data, and a third sub-model is determined based on the scene preference data, wherein the third sub-model is used to construct the control strategy preference matrix of the target object in multiple driving scenarios; Physiological data of the target object are extracted from the target data, and a fourth sub-model is determined based on the physiological data, wherein the fourth sub-model is used to reflect the physiological state of the target object; The digital twin model is determined based on the first sub-model, the second sub-model, the third sub-model, and the fourth sub-model.

3. The method according to claim 1, characterized in that, Determining the control strategy corresponding to the driving intention using the digital twin model includes: Obtain a target function, wherein the target function is used to reflect the target object's satisfaction with using the target vehicle from multiple dimensions; Using the digital twin model as the state space and the objective function as the reward function, control parameters corresponding to the multiple functional domains are generated respectively. The control strategy is determined based on the control parameters.

4. The method according to claim 3, characterized in that, Determining the control strategy based on the control parameters includes: Obtain the parameter thresholds corresponding to the multiple functional domains respectively; The control parameters of each functional domain are compared with the corresponding parameter thresholds to obtain the comparison results; If the comparison results indicate that the control parameters of the multiple functional domains are all less than the parameter threshold, an initial control strategy is determined based on the control parameters. The initial control strategy is subjected to compliance verification, and the verification results are obtained; If the verification result indicates that the verification passed, the control strategy is obtained.

5. The method according to claim 1, characterized in that, The method further includes: Receive basic strategies published by the development team, wherein the basic strategies are used to update the underlying control logic of the target vehicle; The underlying control logic of the target vehicle is updated based on the basic strategy to obtain the target basic strategy, wherein the basic strategy is decoupled from the digital twin model. The target-based strategy is integrated with the digital twin model.

6. The method according to claim 2, characterized in that, After determining the control strategy corresponding to the driving intention using the digital twin model, the method further includes: The physiological state of the target object is determined based on the fourth sub-model; The physiological state is matched with a preset state to obtain a matching result; If the matching result indicates that the physiological state conforms to the preset state, the control strategy is adjusted based on the physiological state.

7. The method according to claim 1, characterized in that, The method further includes: The target scenario in which the target vehicle is located is determined from the target data, wherein the target scenario includes driving scenarios under extreme conditions; Acquire historical driving data corresponding to the target scenario, as well as driving behavior data of the target object in non-target scenarios, wherein the driving behavior data serves as prior knowledge; The target control strategy for the target object in the target scenario is determined based on the driving behavior data and the historical driving data.

8. The method according to claim 1, characterized in that, The target data includes: operational data of multiple functional domains of the target vehicle, driving behavior data of the target object, environmental data of the target vehicle, and physiological state data of the target object.

9. The method according to claim 1, characterized in that, The method further includes: Obtain local digital twin models for each of the multiple vehicles; The target parameters of multiple local digital twin models are uploaded to the cloud, wherein the target parameters are used for joint training in the cloud. Receive the optimized parameters obtained from the cloud-based joint training, and update the local digital twin model based on the optimized parameters.

10. The method according to claim 1, characterized in that, The control strategy includes target control parameters corresponding to the multiple functional domains; the method further includes: Obtain feature vectors corresponding to the plurality of functional domains respectively, wherein the feature vectors are used to characterize the health status of the functional domains; Determine the health score corresponding to the feature vector; If the health score is less than a preset score, the threshold of the corresponding functional domain is reduced, wherein the threshold is used to limit the safe range of the target control parameter.

11. A vehicle, characterized in that, This includes sensor networks, a central computing platform, and domain controllers, among which... The sensor network is connected to the central computing platform and is used to collect target data of the target vehicle. The target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle. The central computing platform is connected to the sensor network and the domain controller respectively, and is used to determine the digital twin model corresponding to the target data, and to determine the control strategy using the digital twin model. The digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions, and the control strategy is used to coordinate the control of multiple functional domains of the target vehicle. The domain controller is connected to the central computing platform and is used to execute the control strategy.

12. A device for determining a control strategy, characterized in that, include: The acquisition module is used to acquire target data of the target vehicle, wherein the target data is used to reflect the operating status of multiple functional domains of the target vehicle and the driving status of the target object controlling the target vehicle. A determining module is used to determine a digital twin model corresponding to the target data, wherein the digital twin model is used to extract the driving intention of the target object from the target data in multiple dimensions; A control module is used to determine a control strategy corresponding to the driving intention using the digital twin model, wherein the control strategy is used to coordinate the control of multiple functional domains of the target vehicle. The distribution module is used to distribute the control strategy to the domain controllers corresponding to the multiple functional domains respectively.

13. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute a method for determining a control strategy according to any one of claims 1 to 10.

14. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the method for determining the control strategy according to any one of claims 1 to 10 by running the computer program.

15. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the method for determining the control strategy according to any one of claims 1 to 10.

Images