A vehicle-cloud integrated control system, method and readable storage medium

Abstract

The application provides a vehicle-cloud integrated control system, method and readable storage medium. A cloud configuration module generates a configuration file suitable for adapting a vehicle-mounted controller and a terminal according to vehicle state data, to ensure that the instructions are consistent with the actual operating state of the vehicle. A vehicle-end service processing module differentiates and processes static and dynamic configuration items. After the static configuration items are parsed, the first cross-domain control instructions are generated directly or landed; the dynamic configuration items are triggered and executed by a scene processing module in real time based on equipment signals to generate the second cross-domain control instructions, solving the problems of insufficient real-time performance and difficulty in adapting to dynamic adjustment of the vehicle in the traditional system configuration. An RC module serves as the core of the cross-domain instructions, uniformly calls an interface to distribute the two types of instructions, and realizes collaborative configuration of the domain and the terminal, greatly improving the cross-domain linkage efficiency. Through clear division of labor and efficient flow, the architecture improves the configuration management efficiency, supports cross-domain control and dynamic scene driving functions, and matches the development direction of vehicle intelligence and networking.

Description

Technical Field

[0001] This application relates to the field of vehicle-cloud integration technology, and in particular to a vehicle-cloud integrated control system, method, and readable storage medium. Background Technology

[0002] Against the backdrop of rapid development in automotive intelligence and connectivity, and with the widespread application of various in-vehicle terminals such as TBOX (Telematics Box) and VCU (Vehicle Control Unit), higher demands are being placed on the flexibility and reliability of current in-vehicle system configuration distribution and task execution. However, existing in-vehicle systems have significant shortcomings in configuration management of in-vehicle controllers and terminals. The core issues are insufficient real-time configuration updates, making it difficult to meet the immediate configuration adjustment needs during dynamic vehicle operation; cross-domain collaborative operation faces technical bottlenecks, with low efficiency in configuration linkage between different terminals and domains. These overlapping technical problems not only lead to low efficiency in configuration management of various in-vehicle controllers and terminals, but also hinder the implementation of cross-domain control, dynamic scene driving, and remote collaborative management functions in vehicle-cloud integrated scenarios, failing to match the development direction of vehicle intelligence and connectivity. Summary of the Invention

[0003] To address the aforementioned issues, this application provides a vehicle-cloud integrated control system, method, and readable storage medium.

[0004] The embodiments of this application disclose the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a vehicle-cloud integrated control system, including: a cloud configuration center and a vehicle execution system, wherein the cloud configuration center includes a cloud configuration module, and the vehicle execution system includes a service processing module, a scene processing module, an RC module, and multiple vehicle controllers and multiple vehicle terminals;

[0006] The cloud configuration module is used to generate a vehicle configuration file based on the vehicle status data from the vehicle execution system; the vehicle status data is used to characterize the real-time status parameters of each vehicle controller and each vehicle terminal.

[0007] The service processing module is used to parse the configuration task of the vehicle configuration file to obtain static configuration items and dynamic configuration items, and generate a first cross-domain control instruction when there is a cross-domain action indication in the static configuration item; the static configuration item is a configuration item that does not depend on the real-time state of the vehicle; the dynamic configuration item is a configuration item that depends on the real-time state of the vehicle.

[0008] The scene processing module is used to execute the action sequence in the dynamic configuration item based on the real-time signals of each of the vehicle controllers and each of the vehicle terminals, and generate a second cross-domain control instruction when there is a cross-domain action indication in the dynamic configuration item.

[0009] The RC module is used to call the execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction, and distribute the first cross-domain control instruction and the second cross-domain control instruction to the corresponding vehicle controller or vehicle terminal; wherein, the cross-domain control instruction is used to characterize an instruction that requires multiple vehicle controllers and multiple vehicle terminals to participate in the configuration task.

[0010] In one possible implementation, the scenario processing module includes a scheduling arbitration unit, preset weight calculation rules, and preset scenario classification rules. The weighting factors of the preset weight calculation rules include static priority, security level, urgency, and execution cost. The preset scenario classification rules are used to classify scenario rules into real-time scenarios and time-limited scenarios. The scheduling arbitration unit is specifically used for:

[0011] Obtain all scene rules corresponding to the dynamic configuration item, and determine the weight value and scene type of each scene rule according to the preset weight calculation rule and the preset scene classification standard;

[0012] The scheduling is sorted according to the weight value, scenario type and configuration task deadline of each scenario rule, and scenario rules with conflicting scenario types are divided into the same mutually exclusive group.

[0013] Assign an execution token to each of the aforementioned mutex groups to obtain the execution queue;

[0014] The execution of each scenario rule is triggered sequentially according to the execution queue. The execution of the current scenario rule is determined based on the token holding status of each mutex group. The action sequence corresponding to the successfully executed scenario rule is then output.

[0015] A sequence check is performed on the action sequence corresponding to the executed scenario rule. If there is a cross-domain action indication in the sequence, the second cross-domain control instruction is generated based on the action sequence.

[0016] In one possible implementation, the service processing module includes a mapping registry, which predefines a mapping tuple corresponding to each configuration key; the mapping tuple includes: target domain, target parameter address, data transformation rule, and data writing strategy;

[0017] The service processing module includes a configuration file parsing unit, which is specifically used for:

[0018] Based on the top-level module of the vehicle configuration file, the vehicle configuration file is divided into multiple key space subsets; the multiple key space subsets include at least two of the following: power domain key space, information domain key space, and body domain key space;

[0019] Based on the mapping registry, the configuration keys in each of the domain key space subsets are traversed, and the mapping tuples corresponding to each configuration key are determined through the mapping registry.

[0020] Based on the data transformation rules in the mapping tuples corresponding to each configuration key, data change and constraint verification are performed on the configuration data corresponding to each configuration key to obtain valid configuration data that has been transformed and verified.

[0021] Based on the data writing strategy in the mapping tuples corresponding to each configuration key, the valid configuration data is classified to obtain the static configuration items and the dynamic configuration items.

[0022] In one possible implementation, the scene processing module is further configured to:

[0023] The conditional expression corresponding to each scenario rule in the dynamic configuration item is compiled into a decision directed acyclic graph containing shared sub-expressions, and a corresponding signal subscription set is established for each scenario rule;

[0024] Based on the signal subscription set, subscribe to the corresponding real-time signals of each of the vehicle controllers and the vehicle terminals. Only when the real-time signals in the signal subscription set are updated, perform incremental evaluation on the affected nodes in the decision directed acyclic graph to obtain the incremental evaluation result.

[0025] The corresponding event timestamp is updated by storing the signal in a ring buffer, and a time window judgment is performed based on the incremental evaluation result to obtain a first matching result that meets the preset timing requirements.

[0026] According to a preset threshold, the corresponding real-time signals of each vehicle controller and the vehicle terminal are compared to obtain a second matching result;

[0027] Based on the first matching result and the second matching result, determine whether the scene triggering condition of the meal in the dynamic configuration item is met, and execute the corresponding action sequence when it is determined that the condition is met;

[0028] If the dynamic configuration item contains a cross-domain action indication, the second cross-domain control instruction is generated based on the action sequence.

[0029] In one possible implementation, the cloud configuration module and the service processing module achieve differential distribution and robust transmission of the vehicle-side configuration file through a preset secure channel. The process of the cloud configuration module distributing the vehicle-side configuration file includes the following steps:

[0030] The vehicle-side configuration file to be issued is subjected to block hashing to construct a Merkle tree for the corresponding configuration version;

[0031] Based on the Merkle trees corresponding to the latest vehicle configuration version and the current vehicle configuration version, generate version difference data between the two versions;

[0032] Add a cyclic redundancy check code and block index information to each block of the version difference data, add a version tag and the deadline for the configuration to take effect, and then send the version difference data with the added information to the vehicle-side execution system.

[0033] In one possible implementation, the vehicle-side execution system further includes a diagnostic processing module; the diagnostic processing module is specifically used for:

[0034] Map the configuration execution results of the static configuration items and the dynamic configuration items to the corresponding diagnostic parameters or fault codes;

[0035] Monitor the execution status of the static and dynamic configuration items, and trigger a rollback operation when an abnormal configuration execution is detected.

[0036] In one possible implementation, the vehicle-side execution system further includes a non-volatile storage module that interacts with the diagnostic processing module. The non-volatile storage module is used to store the configuration data, configuration execution results, and corresponding status information of the vehicle-side configuration file. The data structure of the non-volatile storage module is consistent with the configuration model of the cloud configuration center.

[0037] Secondly, embodiments of this application provide a vehicle-cloud integrated control method, applied in a vehicle-cloud integrated control system. The vehicle-cloud integrated control system includes: a cloud configuration center and a vehicle-side execution system. The cloud configuration center includes a cloud configuration module, and the vehicle-side execution system includes a service processing module, a scene processing module, an RC module, multiple vehicle controllers, and multiple vehicle terminals. The method includes:

[0038] The cloud configuration module is controlled to generate a vehicle configuration file based on the vehicle status data from the vehicle execution system; the vehicle status data is used to characterize the real-time status parameters of each vehicle controller and each vehicle terminal.

[0039] The service processing module is controlled to parse the configuration task of the vehicle-side configuration file to obtain static configuration items and dynamic configuration items. If there is a cross-domain action indication in the static configuration item, a first cross-domain control instruction is generated. The static configuration item is a configuration item that does not depend on the real-time state of the vehicle. The dynamic configuration item is a configuration item that depends on the real-time state of the vehicle.

[0040] The scene processing module is controlled to execute the action sequence in the dynamic configuration item based on the real-time signals of each vehicle controller and each vehicle terminal, and to generate a second cross-domain control instruction when there is a cross-domain action indication in the dynamic configuration item.

[0041] The RC module is controlled to call the execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction, and distribute the first cross-domain control instruction and the second cross-domain control instruction to the corresponding vehicle controller or vehicle terminal; wherein, the cross-domain control instruction is used to characterize an instruction that requires multiple vehicle controllers and multiple vehicle terminals to participate in the configuration task.

[0042] In one possible implementation, the scene processing module includes preset weight calculation rules and preset scene classification rules. The weighting factors of the preset weight calculation rules include static priority, security level, urgency, and execution cost. The preset scene classification rules are used to divide scene rules into real-time scenes and time-limited scenes.

[0043] The generation process of the second cross-domain control instruction includes:

[0044] Obtain all scene rules corresponding to the dynamic configuration item, and determine the weight value and scene type of each scene rule according to the preset weight calculation rule and the preset scene classification standard;

[0045] The scheduling is sorted according to the weight value, scenario type and configuration task deadline of each scenario rule, and scenario rules with conflicting scenario types are divided into the same mutually exclusive group.

[0046] Assign an execution token to each of the aforementioned mutex groups to obtain the execution queue;

[0047] The execution of each scenario rule is triggered sequentially according to the execution queue. The execution of the current scenario rule is determined based on the token holding status of each mutex group. The action sequence corresponding to the successfully executed scenario rule is then output.

[0048] A sequence check is performed on the action sequence corresponding to the executed scenario rule. If there is a cross-domain action indication in the sequence, the second cross-domain control instruction is generated based on the action sequence.

[0049] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any possible vehicle-cloud integrated control method in the second aspect.

[0050] Compared to existing technologies, this application offers the following advantages: This application provides a vehicle-cloud integrated control system, method, and readable storage medium. The cloud configuration module in the cloud configuration center generates configuration files adapted to multiple vehicle controllers and vehicle terminals based on vehicle status data, ensuring a high degree of matching between configuration commands and the actual operating state of the vehicle. Subsequently, the vehicle-side service processing module separates static and dynamic configuration items and processes them differently. Static configuration items, after parsing, can be directly implemented or generate a first cross-domain control command. Dynamic configuration items are triggered and executed by the scene processing module based on real-time signals from various devices, generating a second cross-domain control command. This achieves the dual goals of rapid static configuration activation and precise dynamic configuration response, solving the problems of insufficient real-time configuration updates in traditional systems and difficulty in meeting the immediate adjustment needs during dynamic vehicle operation. Simultaneously, the RC module, as the cross-domain command distribution hub, accurately distributes the two types of cross-domain control commands to target devices through a unified execution interface, breaking down barriers between different terminals and domains, significantly improving the linkage efficiency of cross-domain configuration, and effectively overcoming the technical bottleneck of cross-domain collaborative operation. The overall architecture, through clear module division of labor and efficient instruction flow, can not only improve the configuration management efficiency of each vehicle controller and vehicle terminal, but also support the implementation of advanced functions such as cross-domain control, dynamic scene driving, and remote collaborative management in the vehicle-cloud integrated scenario, thereby matching the development direction of vehicle intelligence and connectivity. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a schematic diagram of the structure of a vehicle-cloud integrated control system provided in an embodiment of this application;

[0053] Figure 2 A flowchart illustrating a configuration file parsing method provided in an embodiment of this application;

[0054] Figure 3 A schematic diagram of the execution flow of a scheduling arbitration unit provided in an embodiment of this application;

[0055] Figure 4This is a schematic diagram of another vehicle-cloud integrated control system provided in an embodiment of this application. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and accompanying drawings. It should be particularly noted that the embodiments described in this application are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0057] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0058] As described earlier, against the backdrop of rapid development in automotive intelligence and connectivity, and with the widespread application of various in-vehicle terminals such as TBOX (Telematics Box) and VCU (Vehicle Control Unit), higher demands are placed on the flexibility and reliability of current in-vehicle system configuration distribution and task execution. However, existing in-vehicle systems have significant shortcomings in the configuration management of in-vehicle controllers and terminals. The core issues are insufficient real-time configuration updates, making it difficult to meet the immediate configuration adjustment needs during dynamic vehicle operation; cross-domain collaborative operation faces technical bottlenecks, and the efficiency of configuration linkage between different terminals and domains is low. These technical problems overlap, not only leading to low efficiency in configuration management of various in-vehicle controllers and terminals, but also hindering the implementation of cross-domain control, dynamic scene driving, and remote collaborative management functions in vehicle-cloud integrated scenarios, failing to match the development direction of vehicle intelligence and connectivity.

[0059] Based on this, this application provides a vehicle-cloud integrated control system, method, and readable storage medium. The cloud configuration module in the cloud configuration center generates configuration files adapted to multiple vehicle controllers and vehicle terminals based on vehicle status data, ensuring a high degree of matching between configuration commands and the actual operating state of the vehicle. Subsequently, the vehicle-side service processing module separates static and dynamic configuration items and processes them differently. Static configuration items, after parsing, can be directly implemented or generate a first cross-domain control command. Dynamic configuration items are triggered and executed by the scene processing module based on real-time signals from various devices, generating a second cross-domain control command. This achieves the dual goals of rapid static configuration activation and precise dynamic configuration response, solving the problems of insufficient real-time configuration updates in traditional systems and difficulty in meeting the immediate adjustment needs during dynamic vehicle operation. Simultaneously, the RC module, as the cross-domain command distribution hub, accurately distributes the two types of cross-domain control commands to target devices through a unified execution interface, breaking down barriers between different terminals and domains, significantly improving the linkage efficiency of cross-domain configuration, and effectively overcoming the technical bottleneck of cross-domain collaborative operation. The overall architecture, through clear module division of labor and efficient instruction flow, can not only improve the configuration management efficiency of each vehicle controller and vehicle terminal, but also support the implementation of advanced functions such as cross-domain control, dynamic scene driving, and remote collaborative management in the vehicle-cloud integrated scenario, thereby matching the development direction of vehicle intelligence and connectivity.

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

[0061] See Figure 1 The figure is a schematic diagram of the structure of a vehicle-cloud integrated control system provided in an embodiment of this application. As can be seen from the figure, the vehicle-cloud integrated control system in this embodiment of the application includes a cloud configuration center and a vehicle execution system. The cloud configuration center includes a cloud configuration module 100, and the vehicle execution system includes a service processing module 200, a scene processing module 300, an RC module 400, as well as multiple vehicle controllers and multiple vehicle terminals.

[0062] Specifically, the cloud configuration module 100 is used to generate a vehicle configuration file based on the vehicle status data from the vehicle execution system; the vehicle status data is used to characterize the real-time status parameters of each vehicle controller and each vehicle terminal.

[0063] The vehicle configuration file generated by the cloud configuration module originates from the vehicle status data fed back by the vehicle execution system. The vehicle status data represents the real-time operating status parameters of multiple in-vehicle controllers, such as the VCU vehicle controller, CCU central computing unit, BCM body controller, and multiple in-vehicle terminals, such as the TBOX telematics terminal and IVI in-vehicle infotainment system. It covers core control indicators such as the controller's power output parameters, load operating status, and hardware operating thresholds, as well as key operating data such as the function activation status, network connection quality, and software version information of the in-vehicle terminals, forming a full-dimensional status data set covering all domains of the vehicle and multiple devices.

[0064] After receiving the real-time vehicle status data, the cloud configuration module integrates, verifies, and matches the data to operating conditions using a pre-defined configuration strategy framework. This identifies the current vehicle's operating scenario, equipment status, and potential configuration requirements. Then, based on a unified management logic for multi-vehicle and multi-version configurations, it generates standardized vehicle configuration files (in JSON format). These files not only contain personalized configuration content adapted to the current vehicle status but also clearly define the core information required for subsequent vehicle parsing through a structured design. This provides a solid data foundation for configuration file parsing. This step enables the linkage between real-time vehicle status and cloud configuration strategies, avoiding the limitations of traditional configuration files and ensuring a high degree of alignment between configuration content and actual vehicle operating conditions. Furthermore, the unified configuration model provides a standardized basis for subsequent functions such as cross-domain collaboration and dynamic scenario-driven operations, thereby supporting the intelligent and efficient configuration management under the integrated vehicle-cloud architecture.

[0065] Specifically, when the cloud configuration module distributes the vehicle-side configuration file to the vehicle-side service processing module, it needs to use a preset secure channel to achieve differential distribution and robust transmission under weak network conditions. The process of the cloud configuration module distributing the vehicle-side configuration file is implemented through the following three steps:

[0066] Step 1: Perform block hashing on the vehicle-side configuration file to be issued to construct the Merkle tree corresponding to the configuration version.

[0067] The vehicle-side configuration files to be distributed typically contain multi-domain configuration rules and parameters. Direct full transmission not only consumes bandwidth but may also affect transmission efficiency in weak network environments due to the large data volume. Therefore, the cloud configuration module first splits the configuration file into multiple data blocks according to a preset size, performs a hash operation on each block to generate a unique hash value, and then uses these block hash values ​​as leaf nodes to build a hierarchical Merkle tree layer by layer upwards. The hash value of each level node is calculated by combining the hash values ​​of its next-level child nodes, ultimately forming the root hash value corresponding to the current configuration version. This processing method achieves both structured splitting of the configuration file and ensures the integrity of each block's data through the uniqueness of the hash value. Subsequently, only the node hash values ​​of different versions of the Merkle tree need to be compared to quickly locate the differing blocks, avoiding the resource waste caused by full distribution.

[0068] Step 2: Generate version difference data between the latest vehicle configuration version and the current vehicle configuration version based on their respective Merkle trees.

[0069] After the Merkle tree is constructed, the cloud simultaneously retrieves the Merkle tree corresponding to the latest configuration version to be deployed and compares it layer by layer with the Merkle tree of the currently effective configuration version on the vehicle. Traversing downwards from the root node, branches with inconsistent hash values ​​are quickly identified by comparing the hash values ​​of each level of nodes. The leaf nodes corresponding to these branches are the difference data blocks between the two versions. Based on the differential calculation method of the Merkle tree, only these difference blocks need to be extracted and integrated to form version difference data, without transmitting the complete configuration file. For example, when only a few parameters of the power domain are updated, the difference data only contains the corresponding blocks, significantly reducing the amount of data transmitted. This saves vehicle-cloud communication bandwidth and shortens transmission time, especially adapting to scenarios with fluctuating network environments during vehicle operation, providing technical support for efficient transmission under weak network conditions.

[0070] Step 3: Add a cyclic redundancy check code and block index information to each block of the version difference data, add a version tag and the deadline for the configuration to take effect, and send the version difference data with the added information to the vehicle-side execution system.

[0071] To ensure the reliability of transmission and the standardization of configuration activation in weak network environments, the cloud configuration module supplements the version difference data with multi-dimensional information before distribution. First, a Cyclic Redundancy Check (CRC) code is added to each difference block. This is used by the vehicle-end to verify whether the block data has been tampered with or lost due to transmission interference. If the verification fails, the abnormal block can be accurately located. Block index information is also attached, clearly indicating the position of each difference block in the complete configuration file, facilitating rapid merging and reassembly by the vehicle-end after reception. If transmission is interrupted, it can resume from the breakpoint based on the index, avoiding duplicate transmission of successfully received blocks. Second, a version tag is added to the difference data, clearly identifying the currently distributed configuration version number, making it easier for the vehicle-end to distinguish between old and new configurations and avoiding execution errors caused by version confusion. A deadline for configuration activation is also set, explicitly requiring the vehicle-end to complete reception and activation within the specified time limit. Combined with the vehicle-end's deadline-aware backoff strategy, this ensures that critical configurations do not exceed the effective time due to weak network delays, guaranteeing the real-time requirements of configuration distribution.

[0072] The service processing module 200 is used to parse the configuration task of the vehicle-side configuration file to obtain static configuration items and dynamic configuration items, and generate a first cross-domain control instruction when there is a cross-domain action indication in the static configuration item; the static configuration item is a configuration item that does not depend on the real-time state of the vehicle; the dynamic configuration item is a configuration item that depends on the real-time state of the vehicle.

[0073] The execution of the service processing module begins with the parsing and task decomposition of the vehicle-side configuration file. During the parsing phase, the module treats the configuration file as a unified key space and, based on whether it depends on the vehicle's real-time status, divides all configuration items into static and dynamic configuration items. Static configuration items are those that take effect stably after being set, requiring no real-time signal triggering, such as the VCU's torque limit parameter, the IVI's default interface brightness, and the TBOX's communication heartbeat interval. Their execution does not depend on dynamic data such as vehicle speed, SOC, or sensor status. Dynamic configuration items, on the other hand, must rely on the vehicle's real-time operating status to trigger execution. For example, the scenario rule of "adjusting the energy recovery intensity when the vehicle speed is ≥100km / h and the wipers are on" requires continuous acquisition of real-time signals and meeting preset conditions to take effect. Simultaneously, the service processing module's built-in mapping registry binds a unique mapping tuple to each configuration key in a predefined manner. This mapping tuple contains four dimensions: target domain, target parameter address, data transformation rules, and data writing strategy, forming a complete guide for configuration execution. The target domain clearly defines the functional category to which the configuration belongs (such as the powertrain domain, infotainment domain, body domain, etc.), directly determining the execution path of the instructions. The target parameter address precisely points to the specific location where the configuration takes effect, which can be the register address of the vehicle controller, the functional parameter identifier of the vehicle terminal, or the DID data identifier in the diagnostic protocol. The data transformation rules are responsible for completing the adaptation and conversion of the configuration data, including unit conversion, boundary clipping, calibration curve mapping, etc., to ensure that the general configuration issued by the cloud can match the parameter format requirements of the target device. The data writing strategy defines the execution priority and persistence rules of the configuration, covering various types such as strong real-time execution, deferred execution, confirmation feedback required, and dual-write NVM storage, providing flexible adaptation for the configuration implementation in different scenarios.

[0074] After completing configuration parsing and mapping matching, the service processing module enters the instruction generation and distribution preparation stage, generating the first cross-domain control instruction for the cross-domain requirements of static configuration items. For the parsed static configuration items, the service processing module determines their execution scope through the target domain field of the mapping registry: if the configuration item only applies to a single domain (e.g., only adjusting the volume parameters of the IVI), the configuration is directly applied to the basic services of the corresponding vehicle terminal or controller based on the target parameter address and data writing strategy, without cross-domain scheduling. If the static configuration item contains cross-domain action instructions (e.g., simultaneously enabling the IVI welcome screen TBOX network connection when the vehicle starts, involving the infotainment domain and the connectivity domain), the service processing module generates a standardized first cross-domain control instruction based on the complete information of the mapping tuple, clearly defining the target device, parameter conversion rules, and execution requirements of the instruction. In this process, the mapping registry ensures the consistency and accuracy of cross-domain instructions. After identifying cross-domain scenarios by the target domain field, the execution nodes of each domain are located by combining the target parameter address. The unified adaptation of multi-domain parameters is completed by using data transformation rules. Then, the execution priority and feedback requirements of the instruction are clarified according to the data writing strategy. Finally, the first cross-domain control instruction is transmitted to the RC module through a standardized interface, which completes cross-domain routing and execution scheduling.

[0075] Next, with reference to the accompanying drawings of a specific process implementation, we will introduce the file parsing process of the vehicle-side configuration file in the service processing module. The specific file parsing process of the configuration file in this module is executed through its built-in configuration file parsing unit.

[0076] See Figure 2 This figure is a schematic flowchart of a configuration file parsing method provided in an embodiment of this application. The configuration file parsing process described below is executed by the configuration file parsing unit and specifically includes the following steps:

[0077] S2011: Based on the top-level module of the vehicle configuration file, the vehicle configuration file is split into multiple domain key space subsets; the multiple key space subsets include at least two of the following: power domain key space, information domain key space, and body domain key space.

[0078] In this embodiment, the vehicle configuration file distributed from the cloud is typically presented in JSON format. Its top-level module corresponds to different functional domains of the vehicle. Based on this structured design, the parsing unit divides the complete configuration key space into multiple independent subsets of domain key spaces, covering the power domain key space, information domain key space, and body domain key space. In one possible implementation, it can also be extended to other functional domains such as the connectivity domain and diagnostic domain, depending on the vehicle configuration requirements. Specifically, the power domain key space centrally carries configuration content related to vehicle power control, corresponding to the operating parameters of onboard controllers such as the VCU; the information domain key space focuses on the configuration rules of the IVI in-vehicle infotainment system and the TBOX remote communication terminal; and the body domain key space contains configurations related to windows, lighting, and door locks, primarily controlled by the BCM body controller. This logical division based on vehicle functional domains effectively avoids mutual interference between different domain configurations, ensuring that the generation of cross-domain control commands can quickly locate the target domain, thus improving the efficiency of the entire configuration execution chain.

[0079] S2022: Based on the mapping registry, traverse the configuration keys in each of the domain key space subsets, and determine the mapping tuple corresponding to each configuration key through the mapping registry.

[0080] After the splitting is complete, the parsing unit sequentially traverses all configuration keys within each subset of the domain key space. Regardless of whether the configuration key is used for a single domain function or involves cross-domain collaborative operations, it will be searched through the mapping registry to determine its corresponding mapping tuple. The mapping registry, as a data-driven rule base, pre-binds a four-tuple mapping tuple containing the target domain, target parameter address, data transformation rule, and data writing strategy for each possible configuration key. This fixed association pattern allows the parsing process to avoid relying on complex underlying logic derivation; the execution path and rules can be clearly defined simply by looking up the table. The target domain field further confirms the scope of the configuration key, ensuring that subsequent data processing and instruction distribution do not deviate from the preset domain. The target parameter address points to the specific location where the configuration takes effect; this could be the register address of the vehicle controller, the functional parameter identifier of the vehicle terminal, or the DID data identifier in the diagnostic protocol. The data transformation rule and data writing strategy provide clear guidance for subsequent data adaptation processing and configuration item classification, giving each configuration key a complete execution specification. This matching method not only significantly improves the parsing efficiency of configuration files, but also has strong scalability. When adding new configuration items or adapting to new car models, there is no need to modify the core logic of the parsing unit. Only the corresponding entries need to be expanded in the mapping registry, which effectively solves the problems of low reusability and high adaptation cost of traditional configuration models.

[0081] S2023: Based on the data transformation rules in the mapping tuples corresponding to each configuration key, perform data change and constraint verification on the configuration data corresponding to each configuration key to obtain valid configuration data that has been transformed and verified.

[0082] After completing the mapping tuple matching, the parsing unit performs data transformation and constraint verification operations on the original configuration data for each configuration key. The data transformation process follows the data transformation rules defined in the mapping tuple, performing multi-dimensional adaptation processing based on the parameter format requirements of the target device. For configuration data with inconsistent units, standardized unit conversion is performed to ensure the data can be directly recognized by the target controller or terminal. For values ​​exceeding the device's tolerance range, boundary clipping is performed to prevent device malfunctions due to excessive data. For parameters that need to conform to actual operating conditions, calibration curve mapping converts general data into personalized adaptation data, making the configuration more suitable for vehicle operation requirements.

[0083] After the data transformation is complete, the parsing unit will initiate a dual constraint verification mechanism. Firstly, it checks whether the transformed data falls within the preset valid domain [Lk, Uk] of the configuration key, using the following formula to perform the final data filtering:

[0084] ;

[0085] In the formula, This represents the final effective configuration data for the k-th configuration key after data transformation and boundary constraint verification. This represents the original configuration data corresponding to the k-th configuration key. This indicates the preset data transformation rule corresponding to the k-th configuration key for the original configuration data. After processing, the intermediate configuration data is obtained. This represents the lower bound of the valid values ​​for the configuration data corresponding to the k-th configuration key. This represents the upper limit of the legal values ​​for the configuration data corresponding to the k-th configuration key.

[0086] On the other hand, for configuration data with logical relationships, compatibility checks are performed. For example, it verifies whether key logical relationships such as "maximum torque ≥ minimum torque" and "charging power ≤ battery rated power" are valid, forming a constraint set C. If any incompatibility exists (ci=false), the configuration submission process is immediately blocked, triggering a rollback or correction operation. This series of operations abandons the "direct reuse" mode of the original configuration data. Through data adaptation and strict verification, it ensures that each set of configuration data can accurately match the requirements of the target device, while avoiding system risks caused by logical conflicts.

[0087] S2024: Based on the data writing strategy in the mapping tuples corresponding to each configuration key, the valid configuration data is classified to obtain the static configuration item and the dynamic configuration item.

[0088] In the final stage of the parsing process, the data writing strategy, as the core definition of configuration execution requirements, clarifies the effective method, triggering conditions, and persistence requirements of each set of valid configuration data. Among them, the writing strategy corresponding to static configuration items is usually a type that does not depend on the real-time state of the vehicle, such as strong real-time execution, delayed execution, or dual-write NVM. These configuration items themselves do not involve real-time scenario triggering and can be effective stably for a long time after being set. Examples include the power output threshold of VCU, the default display brightness of IVI, and the communication heartbeat interval of TBOX. Their execution does not need to wait for dynamic signals such as vehicle speed, SOC, and sensor status. After parsing, they can be directly delivered to the service engine for application to the corresponding service, or the first cross-domain control command can be generated when there is a cross-domain action indication.

[0089] The write strategies for dynamic configuration items are mostly scenario-triggered execution, time-sensitive execution, and other types that rely on real-time states. These configuration items must meet specific vehicle operating scenarios to take effect, such as "adjusting energy recovery intensity when vehicle speed ≥ 100km / h and windshield wipers are on." Their execution requires continuously acquiring real-time vehicle signals and matching conditions. Therefore, they are categorized and passed to the real-time core scenario engine, waiting for the trigger conditions to be met before executing the corresponding action sequence. This write strategy-based categorization method allows the service engine and the real-time core scenario engine to perform their respective functions, ensuring both the rapid activation of static configuration items and the real-time response of dynamic configuration items, thereby ensuring the high-efficiency operation of the entire configuration distribution and execution system.

[0090] The scene processing module 300 is used to execute the action sequence in the dynamic configuration item based on the real-time signals of each of the vehicle controllers and each of the vehicle terminals, and to generate a second cross-domain control instruction when there is a cross-domain action indication in the dynamic configuration item.

[0091] The scene processing module serves as the carrier for executing dynamic configuration on the vehicle side. Its role is to rely on the real-time signals from various vehicle controllers and vehicle terminals to implement the action sequence in the dynamic configuration items, while efficiently handling cross-domain collaboration requirements.

[0092] Dynamic configuration items rely on real-time operational data such as vehicle speed, SOC, sensor status, and network quality, and cannot take effect directly like static configuration items. Therefore, the scene processing module needs to continuously subscribe to the real-time signal streams of each domain of the vehicle and achieve rapid matching of trigger conditions through periodic scheduling. During operation, the scene processing module monitors signal changes in real time. When a real-time signal is detected to meet a preset threshold or logical relationship (e.g., vehicle speed ≥ 100km / h and windshield wipers continuously on for 3 seconds), the corresponding action sequence execution process is immediately initiated. The action content may be parameter adjustment within a single domain (e.g., VCU adjusting energy recovery intensity) or may involve multi-domain collaborative operations (e.g., simultaneously adjusting power strategy, triggering IVI interface prompts, and controlling vehicle lighting). If the action sequence contains cross-domain action instructions, i.e., multiple vehicle controllers or vehicle terminals need to participate collaboratively, the scene processing module generates a standardized second cross-domain control instruction, specifying the target device, action requirements, and execution priority of the instruction. This instruction is then passed to the RC module through a standardized interface, which performs cross-domain routing and execution monitoring to ensure that multi-domain devices can respond collaboratively at a unified pace, avoiding action execution disconnects or conflicts.

[0093] Specifically, the scheduling and arbitration unit built into the scene processing module ensures the orderly execution of multiple concurrent triggers by using preset weight calculation rules and scene classification rules, ensuring the system maintains determinism and security even under complex operating conditions. The preset weight calculation rules are based on multi-dimensional weighting factors to construct a priority evaluation system. These weighting factors cover four dimensions: static priority, safety level, urgency, and execution cost. Static priority is the pre-configured basic priority, clearly defining the inherent importance of different scenarios; the safety level is based on the vehicle's ASIL level mapping, assigning higher weights to safety-related scenarios (such as emergency braking assist configuration) to prioritize driving safety; urgency is calculated using a countdown or slack time calculation for scenario expiration, ensuring timely response to time-sensitive scenarios (such as parameter adjustments before charging deadlines); and execution cost considers the negative impacts of switching jitter and resource consumption caused by action execution, preventing frequent triggering of high-interference scenarios from affecting system stability. The scheduling and arbitration unit comprehensively calculates the weights of each factor using a weight function to obtain the final weight for each scenario, thus forming a full-order execution queue to resolve priority conflicts among multiple scenarios.

[0094] The pre-defined scenario classification rules divide all dynamic scenario rules into real-time scenarios and time-limited scenarios, employing differentiated scheduling strategies for each type. Real-time scenarios (such as safety-related power parameter adjustments) use fixed-priority preemptive scheduling, ensuring that the highest-priority scenario can interrupt lower-priority tasks for immediate execution. Time-limited scenarios (such as non-urgent comfort configuration adjustments) use EDF (Earliest Deadline First) scheduling, prioritizing tasks with deadlines approaching. The collaborative application of these two rules ensures both the principles of safety and real-time priority while balancing the execution needs of different scenarios through flexible scheduling strategies. This effectively avoids action conflicts and resource contention during concurrent execution across multiple scenarios, supporting the efficient and orderly execution of dynamic configuration items.

[0095] Next, the execution flow of the scheduling arbitration unit described above will be explained in detail with reference to the accompanying drawings of a specific process implementation. See also... Figure 3 The figure is a schematic diagram of the execution flow of a scheduling arbitration unit provided in an embodiment of this application, which specifically includes the following steps:

[0096] S3011: Obtain all scene rules corresponding to the dynamic configuration item, and determine the weight value and scene type of each scene rule according to the preset weight calculation rule and the preset scene classification standard.

[0097] Acquiring and determining the types of all scenario rules within the dynamic configuration items is a prerequisite for achieving orderly scheduling. The scenario rules in the dynamic configuration items cover various configuration requirements that need to be dynamically responded to during vehicle operation, such as coordinated adjustment of power and lighting in high-speed rainy weather, and energy consumption control when the battery is low. The scheduling arbitration unit first extracts these scenario rules in batches, and then completes two determinations based on preset weight calculation rules and preset scenario classification standards. On the one hand, each rule is quantitatively evaluated through a multi-factor weight function. Based on the aforementioned weighting factors, a unique weight value for each rule is obtained through weighted calculation, providing a quantitative basis for priority ranking. On the other hand, according to the preset scenario classification standards, all scenario rules are divided into real-time scenarios and time-limited scenarios. The clear division of these two types of scenarios lays the foundation for subsequent differentiated scheduling strategies.

[0098] S3012: The scheduling is sorted according to the weight value, scenario type and configuration task deadline of each scenario rule, and scenario rules with conflicting scenario types are divided into the same mutual exclusion group.

[0099] After determining the basic attributes for each scenario, the scheduling arbitration unit enters the scheduling sorting and conflict rule grouping phase, aiming to solve the problem of "execution order and conflict avoidance when multiple rules are concurrent." During the sorting process, the scheduling arbitration unit considers three core criteria: weight value is the primary sorting standard, with rules having higher weights gaining priority in execution; the scenario type determines the differences in sorting logic, with real-time scenarios using a fixed-priority preemption mechanism to ensure that security-related rules are not interfered with by other tasks, while time-limited scenarios use an EDF strategy to prioritize tasks with closer deadlines; and the configured task deadline is used as a supplementary criterion, with rules having earlier deadlines taking precedence when multiple rules have the same weight value and scenario type. While sorting, the scheduling arbitration unit will perform conflict detection on all scenario rules. The core criterion for conflict determination is whether the action corresponding to the rule involves the same physical execution unit (such as window motor or power controller) or shared resources (such as bus bandwidth). If the execution of two or more rules may cause device conflict or action interference (such as controlling window lifting and door lock opening and closing at the same time, occupying the same vehicle body control resources), they will be assigned to the same mutual exclusion group. Conflict avoidance will be achieved through subsequent token control to ensure that only one rule can be executed in the same mutual exclusion group at the same time.

[0100] S3013: Assign an execution token to each of the aforementioned mutex groups to obtain an execution queue.

[0101] After conflict grouping is completed, the scheduling arbitration unit assigns a unique execution token to each mutex group, thus forming an ordered execution queue. The execution token is the core carrier controlling the execution permissions of rules within a mutex group; each mutex group corresponds to only one execution token, and the token's holding status directly determines whether a rule can be executed. When allocating tokens, the scheduling arbitration unit considers the prior ordering results, prioritizing mutex groups containing high-priority rules to the front of the execution queue while ensuring the queue's integrity. The queue includes rules executed within a single domain as well as rules requiring cross-domain collaboration, and all rules are arranged sequentially according to a comprehensive ranking result of "weight value, scenario type, and deadline." The introduction of execution tokens fundamentally solves the problem of concurrent conflicts among rules within mutex groups. At any given time, only one rule can hold a token in the same mutex group; other rules must wait for the token to be released or acquire it through a preemption mechanism. This design avoids abnormal vehicle behavior caused by multiple conflicting rules executing simultaneously, ensuring the determinism of system execution.

[0102] S3014: Trigger the execution of each scene rule in sequence according to the execution queue, determine whether the current scene rule is allowed to be executed according to the token occupancy status of each mutex group, and output the action sequence corresponding to the scene rule that has been executed.

[0103] After the execution queue is formed, the scheduling arbitration unit triggers the execution of scene rules sequentially according to the queue order. During execution, the scheduling arbitration unit reads the scene rules in the execution queue one by one, and for each rule, it first checks the token status of its mutex group. If the token is idle and the current rule has a higher priority than subsequent rules in the queue, the token is directly allocated and the rule execution is triggered. If the token is occupied by another rule, the weight of the rule occupying the token needs to be further determined. If the weight of the current rule is higher than that of the rule occupying the token, a preemption mechanism can be triggered to seize the token and interrupt the execution of the original rule (only applicable to real-time scenarios; preemption is not supported in time-limited scenarios). If the weight of the current rule is lower, it enters the queuing state or is skipped directly to avoid unnecessary waiting. At the same time, for rules involving physical execution units, the scheduling arbitration unit also limits the execution rate through shapers such as token buckets to avoid hardware jitter caused by frequent actions. After the rule execution is successful, the scheduling arbitration unit extracts its corresponding action sequence. These action sequences may be parameter adjustments within a single domain or composite actions involving multi-domain collaboration, preparing for the generation of subsequent cross-domain instructions.

[0104] S3015: Perform a sequence check on the action sequence corresponding to the executed scenario rule. If there is a cross-domain action indication in the sequence, generate the second cross-domain control instruction based on the action sequence.

[0105] After the executed action sequence is output, each successful action sequence is checked step by step to identify whether the action sequence requires the collaborative participation of multiple vehicle controllers or vehicle terminals. If a cross-domain action indication is detected, the scheduling arbitration unit generates a standardized second cross-domain control instruction based on the specific content of the action sequence. The instruction explicitly includes key information such as the target domain identifier, execution parameters for each domain, and action coordination timing requirements. The generated second cross-domain control instruction is transmitted to the RC module through a standardized interface. The RC module, using its cross-domain signal routing capabilities, distributes the instruction to the corresponding domain's vehicle controller or vehicle terminal, ultimately achieving cross-domain collaborative execution. If the action sequence involves only a single domain, there is no need to generate a cross-domain control instruction; the device in the corresponding domain can execute it directly.

[0106] The RC module 400 is used to call the execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction respectively, and distribute the first cross-domain control instruction and the second cross-domain control instruction to the corresponding vehicle controller or vehicle terminal; wherein, the cross-domain control instruction is used to characterize an instruction that requires multiple vehicle controllers and multiple vehicle terminals to participate in the configuration task.

[0107] The RC module, as the central hub for cross-domain control in the vehicle, focuses on the distribution and execution interface adaptation of cross-domain control commands, serving as a bridge connecting the configuration parsing module, the vehicle terminal, and the vehicle controller. This module receives first cross-domain control commands from the service processing module and second cross-domain control commands from the scene processing module. Although these two types of commands originate from different sources and have different triggering scenarios, they both share the characteristic of requiring the coordinated participation of multiple vehicle controllers or vehicle terminals. The first cross-domain control command originates from cross-domain action indications in static configuration items, such as the coordinated configuration of simultaneously activating the IVI welcome interface and TBOX network connection upon vehicle startup. The second cross-domain control command originates from cross-domain action sequences in dynamic configuration items, such as the combined action of simultaneously adjusting VCU power parameters, BCM lighting status, and the IVI prompt interface in a high-speed rainy weather scenario. To ensure accurate command execution, the RC module pre-encapsulates standardized execution interfaces for devices in various domains, covering control interfaces for multiple vehicle controllers and terminals, including the powertrain domain VCU, infotainment domain IVI, body domain BCM, and connectivity domain TBOX. Upon receiving two types of cross-domain control commands, it first precisely matches the corresponding execution interface based on the target domain identifier and device address implicit in the command, avoiding command execution failures due to interface incompatibility. In this way, the RC module does not need to concern itself with the configuration type and triggering logic behind the command; it only needs to focus on interface adaptation and routing, significantly improving the compatibility and efficiency of cross-domain command execution.

[0108] After completing the execution interface call adaptation, the RC module enters the execution distribution phase. Leveraging its cross-domain signal routing capabilities, it directs two types of cross-domain control commands to the corresponding vehicle controllers or terminals, ensuring the orderly implementation of multi-device collaborative actions. During distribution, the RC module parses key information such as the target device list and action timing requirements contained in each cross-domain control command. Based on preset cross-domain routing rules, it breaks down the command into sub-commands recognizable by each device, while ensuring the distribution timing of the sub-commands is consistent with the collaborative logic. For example, the cross-domain command "adjust energy recovery intensity and turn on automatic headlights" will first distribute the power parameter adjustment sub-command to the VCU, and simultaneously distribute the lighting control sub-command to the BCM, ensuring that the two actions are executed almost simultaneously, avoiding timing deviations that could affect the user experience. Furthermore, while distributing commands, the RC module also monitors the command reception status and execution progress of each target device in real time. If a device fails to receive a command or experiences an execution anomaly, it immediately triggers a retry mechanism or sends an error message to the command generation module, providing a basis for subsequent configuration rollback or compensation actions.

[0109] In one possible implementation, the scene processing module can also determine the second cross-domain control instruction through the following six steps:

[0110] Step 1: Compile the conditional expression corresponding to each scenario rule in the dynamic configuration item into a decision directed acyclic graph containing shared sub-expressions, and establish a corresponding signal subscription set for each scenario rule;

[0111] Step 2: Based on the signal subscription set, subscribe to the corresponding real-time signals of each of the vehicle controllers and the vehicle terminals. Only when the real-time signals in the signal subscription set are updated, perform incremental evaluation on the affected nodes in the decision directed acyclic graph to obtain the incremental evaluation result.

[0112] Step 3: Update the corresponding event timestamp by storing the signal in a ring buffer, and perform time window judgment based on the incremental evaluation result to obtain the first matching result that meets the preset timing requirements;

[0113] Step 4: Based on a preset threshold, compare the corresponding real-time signals of each vehicle controller and vehicle terminal to obtain a second matching result;

[0114] Step 5: Based on the first matching result and the second matching result, determine whether the scene triggering condition of the meal in the dynamic configuration item is met, and execute the corresponding action sequence when it is determined that the condition is met;

[0115] Step 6: If there is a cross-domain action indication in the dynamic configuration item, generate the second cross-domain control instruction based on the action sequence.

[0116] The scene processing module improves the execution efficiency of dynamic configuration items by optimizing the condition matching mechanism. Specifically, the module transforms the conditional expression of each scene rule into a directed acyclic graph (DAG) containing shared sub-expressions. By reusing sub-expressions, redundant computations are reduced. Simultaneously, a dedicated signal subscription set is established for each rule, clearly defining the real-time signals of the vehicle controller and terminal to be monitored. The module then subscribes only to real-time signals within this set, avoiding resource waste caused by indiscriminately monitoring all signals. Furthermore, incremental evaluation of the affected nodes in the decision DAG is only performed when a signal in the subscription set is updated, rather than recalculating the entire expression. This significantly reduces the computational complexity of condition judgments and ensures millisecond-level response times.

[0117] Based on this, the module verifies the scene triggering conditions through dual matching and simultaneously handles cross-domain command generation requirements. It utilizes a circular buffer to store the event timestamps updated by the signal, and combines the incremental evaluation results with time window judgments, such as verifying timing logic like "continuous triggering within T seconds," to obtain a first matching result that meets preset timing requirements. Simultaneously, it compares the real-time signal with preset thresholds to confirm whether numerical conditions such as "vehicle speed ≥ 100km / h" are met, forming a second matching result. Combining the two matching results, the module determines whether the scene triggering conditions are fully met; if so, it immediately executes the corresponding action sequence. If the action sequence contains cross-domain action indications, requiring the coordinated participation of multiple vehicle controllers or terminals, it generates a standardized second cross-domain control command based on the action sequence. This provides a basis for subsequent cross-domain distribution and execution by the RC module, ensuring both the accuracy of scene matching and the orderly triggering of cross-domain actions.

[0118] In one possible implementation, the vehicle-side execution system in this embodiment of the application is further provided with a diagnostic processing module, which is specifically used to perform the following two steps:

[0119] Step 1: Map the configuration execution results of the static configuration items and the dynamic configuration items to the corresponding diagnostic parameters or fault codes;

[0120] Step 2: Monitor the execution status of the static configuration items and the dynamic configuration items, and trigger a rollback operation when an execution abnormality is detected.

[0121] The diagnostic processing module is a key component for the collaboration between vehicle-side configuration execution and the diagnostic system. Its role is to establish a mapping between configuration execution results and diagnostic data. Whether it is the implementation result of static configuration items or the execution feedback of dynamic configuration items, the module will accurately capture and complete standardized mapping: when execution is successful, the effective configuration will be synchronized to the corresponding diagnostic parameters (following the UDS / OBD protocol), making it convenient for maintenance personnel to read through diagnostic tools; when execution is abnormal, a unique fault code will be generated according to preset rules to clarify the type and cause of the abnormality, completely solving the problem of asynchronous configuration and diagnostic data in traditional systems, and ensuring that the configuration status is traceable and troubleshootable.

[0122] Another function of the module is to monitor the configuration execution status across the entire process, ensuring system stability through a rapid rollback mechanism. It covers the entire process, including configuration parsing, command distribution, terminal execution, and storage writing, monitoring the execution progress and effects of static and dynamic configuration items in real time. Once issues such as excessive data, command routing failures, or abnormal storage writes are detected, a rollback operation is immediately initiated, restoring the configuration to the most recent valid version. Simultaneously, the time, scenario, and handling results of the anomaly are recorded, forming a complete log. This mechanism not only avoids the potential impact of abnormal configurations on vehicle safety but also provides data support for subsequent troubleshooting and configuration optimization, ensuring the reliability of the configuration system.

[0123] In another possible implementation, the vehicle-side execution system in this embodiment further includes a non-volatile storage module, which interacts with the diagnostic processing module; the non-volatile storage module is used to store the configuration data, configuration execution results and corresponding status information of the vehicle-side configuration file, and the data structure of the non-volatile storage module is consistent with the configuration model of the cloud configuration center.

[0124] The non-volatile storage module stores complete configuration data, configuration execution results, and corresponding status information for the vehicle-side configuration file. This ensures that this critical data is fully retained even after the vehicle is powered off and can be quickly loaded and reused upon the next power-on. Crucially, its data structure is consistent with the configuration model of the cloud-based configuration center. This guarantees semantic consistency between vehicle-side stored data, diagnostic data, and cloud-deployed configurations, avoiding configuration synchronization chaos or parsing failures caused by data structure differences. After the diagnostic processing module completes the mapping of configuration execution results, it synchronously writes the relevant data to this storage module, achieving collaborative persistence of configuration data and diagnostic information. When the service processing module starts configuration parsing or the vehicle powers on and initializes, it can quickly read historical configuration data and status information from this module without repeatedly relying on cloud deployments. This improves configuration loading efficiency and ensures the continuity and consistency of configuration execution.

[0125] Furthermore, for details regarding the vehicle-cloud integrated control system described in the embodiments of this application, please refer to... Figure 4 The figure is a schematic diagram of another vehicle-cloud integrated control system provided in an embodiment of this application. In the figure, the service engine is the service processing module of this system, the real-time kernel scene engine is the scene processing module, APP-Diag(E) is the diagnostic processing module, and the NVM storage module is the non-volatile storage module.

[0126] This application provides a vehicle-cloud integrated control system. The cloud configuration module in the cloud configuration center generates configuration files adapted to multiple vehicle controllers and terminals based on vehicle status data, ensuring a high degree of matching between configuration commands and the actual vehicle operating status. Subsequently, the vehicle-side service processing module separates static and dynamic configuration items and processes them differently. Static configuration items, after parsing, can be directly implemented or generate the first cross-domain control command. Dynamic configuration items are triggered and executed by the scene processing module based on real-time signals from various devices, generating the second cross-domain control command. This achieves the dual goals of rapid static configuration activation and precise dynamic configuration response, solving the problems of insufficient real-time configuration updates in traditional systems and difficulty in meeting the immediate adjustment needs during dynamic vehicle operation. Simultaneously, the RC module, as the cross-domain command distribution hub, accurately distributes both types of cross-domain control commands to target devices through a unified execution interface, breaking down barriers between different terminals and domains, significantly improving the linkage efficiency of cross-domain configuration, and effectively overcoming the technical bottleneck of cross-domain collaborative operation. The overall architecture, through clear module division of labor and efficient instruction flow, can not only improve the configuration management efficiency of each vehicle controller and vehicle terminal, but also support the implementation of advanced functions such as cross-domain control, dynamic scene driving, and remote collaborative management in the vehicle-cloud integrated scenario, thereby matching the development direction of vehicle intelligence and connectivity.

[0127] The following describes a vehicle-cloud integrated control system provided by an embodiment of this application. The vehicle-cloud integrated control system described below can be referred to in correspondence with the vehicle-cloud integrated control method described above.

[0128] This application also provides a vehicle-cloud integrated control method, applied in a vehicle-cloud integrated control system. The vehicle-cloud integrated control system includes: a cloud configuration center and a vehicle-side execution system. The cloud configuration center includes a cloud configuration module, and the vehicle-side execution system includes a service processing module, a scene processing module, an RC module, multiple vehicle controllers, and multiple vehicle terminals. The method includes the following steps:

[0129] Step 1: Control the cloud configuration module to generate a vehicle configuration file based on the vehicle status data from the vehicle execution system; the vehicle status data is used to characterize the real-time status parameters of each vehicle controller and each vehicle terminal.

[0130] Step 2: Control the service processing module to parse the configuration task of the vehicle-side configuration file to obtain static configuration items and dynamic configuration items. If there is a cross-domain action indication in the static configuration item, generate a first cross-domain control instruction. The static configuration item is a configuration item that does not depend on the real-time state of the vehicle. The dynamic configuration item is a configuration item that depends on the real-time state of the vehicle.

[0131] Step 3: Control the scene processing module to execute the action sequence in the dynamic configuration item based on the real-time signals of each vehicle controller and each vehicle terminal, and generate a second cross-domain control command if there is a cross-domain action indication in the dynamic configuration item.

[0132] Step 4: Control the RC module to call the execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction, and distribute the first cross-domain control instruction and the second cross-domain control instruction to the corresponding vehicle controller or vehicle terminal; wherein, the cross-domain control instruction is used to characterize an instruction that requires multiple vehicle controllers and multiple vehicle terminals to participate in the configuration task.

[0133] In one possible implementation, the scene processing module includes preset weight calculation rules and preset scene classification rules. The weighting factors of the preset weight calculation rules include static priority, security level, urgency, and execution cost. The preset scene classification rules are used to divide scene rules into real-time scenes and time-limited scenes.

[0134] The generation process of the second cross-domain control instruction includes:

[0135] Obtain all scene rules corresponding to the dynamic configuration item, and determine the weight value and scene type of each scene rule according to the preset weight calculation rule and the preset scene classification standard;

[0136] The scheduling is sorted according to the weight value, scenario type and configuration task deadline of each scenario rule, and scenario rules with conflicting scenario types are divided into the same mutually exclusive group.

[0137] Assign an execution token to each of the aforementioned mutex groups to obtain the execution queue;

[0138] The execution of each scenario rule is triggered sequentially according to the execution queue. The execution of the current scenario rule is determined based on the token holding status of each mutex group. The action sequence corresponding to the successfully executed scenario rule is then output.

[0139] A sequence check is performed on the action sequence corresponding to the executed scenario rule. If there is a cross-domain action indication in the sequence, the second cross-domain control instruction is generated based on the action sequence.

[0140] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a computer-readable storage medium storing computer instructions for causing the computer to execute the vehicle-cloud integrated control method as described in any of the above embodiments.

[0141] The computer-readable media in this application embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0142] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the vehicle-cloud integrated control method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0143] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system, method, and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system, method, and medium embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0144] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle-cloud integrated control system, characterized in that, The application relates to a cloud configuration center and a vehicle-side execution system, wherein the cloud configuration center comprises a cloud configuration module, and the vehicle-side execution system comprises a service processing module, a scene processing module, an RC module, a plurality of vehicle-mounted controllers and a plurality of vehicle-mounted terminals. The cloud configuration module is used for generating a vehicle-side configuration file according to vehicle-side state data from the vehicle-side execution system. The vehicle-side state data is used for representing real-time state parameters of the vehicle-mounted controllers and the vehicle-mounted terminals. The service processing module is used for performing configuration task analysis on the vehicle-side configuration file to obtain static configuration items and dynamic configuration items, and generating a first cross-domain control instruction in the case that cross-domain action instructions exist in the static configuration items; the static configuration items are configuration items that do not depend on real-time states of vehicles; and the dynamic configuration items are configuration items that depend on the real-time states of the vehicles. The scene processing module is used for executing action sequences in the dynamic configuration items based on real-time signals of the vehicle-mounted controllers and the vehicle-mounted terminals, and generating a second cross-domain control instruction in the case that cross-domain action instructions exist in the dynamic configuration items. The RC module is used for calling execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction respectively, and distributing the first cross-domain control instruction and the second cross-domain control instruction to corresponding vehicle-mounted controllers or vehicle-mounted terminals; wherein the cross-domain control instruction is used for representing an instruction that requires a plurality of vehicle-mounted controllers and a plurality of vehicle-mounted terminals to participate in a configuration task. The scene processing module comprises a scheduling arbitration unit, a preset weight calculation rule and a preset scene classification rule; weighting factors of the preset weight calculation rule comprise static priorities, safety levels, urgency degrees and execution costs; the preset scene classification rule is used for dividing scene rules into real-time scenes and time-limited scenes; and the scheduling arbitration unit is specifically used for:

2. The system of claim 1, wherein, acquiring all corresponding scene rules in the dynamic configuration items, and determining weight values and scene types of each scene rule according to the preset weight calculation rule and the preset scene classification standard; performing scheduling sorting according to the weight values, the scene types and configuration task deadlines of each scene rule, and dividing scene rules with the same scene type into the same mutual exclusion group; allocating execution tokens to each mutual exclusion group to obtain an execution queue; sequentially triggering execution of each scene rule according to the execution queue, judging whether the current scene rule is allowed to execute according to a token occupation state of each mutual exclusion group, and outputting an action sequence corresponding to a scene rule that passes the execution; performing sequence checking on the action sequence corresponding to the scene rule that passes the execution, and generating the second cross-domain control instruction according to the action sequence if cross-domain action instructions exist in the sequence. The service processing module comprises a mapping register table, and each configuration key corresponds to a mapping tuple in the mapping register table in advance.

3. The system of claim 1, wherein, The mapping tuple comprises a target domain, a target parameter address, a data transformation rule and a data writing strategy. ​ The service processing module includes a configuration file parsing unit, which is specifically used for: Based on the top-level module of the vehicle configuration file, the vehicle configuration file is divided into multiple domain key space subsets; the multiple domain key space subsets include at least two of the following: power domain key space, information domain key space, and body domain key space; Based on the mapping registry, the configuration keys in each of the domain key space subsets are traversed, and the mapping tuples corresponding to each configuration key are determined through the mapping registry. Based on the data transformation rules in the mapping tuples corresponding to each configuration key, data change and constraint verification are performed on the configuration data corresponding to each configuration key to obtain valid configuration data that has been transformed and verified. Based on the data writing strategy in the mapping tuples corresponding to each configuration key, the valid configuration data is classified to obtain the static configuration items and the dynamic configuration items.

4. The system of claim 1, wherein, The scene processing module is also used for: The conditional expression corresponding to each scenario rule in the dynamic configuration item is compiled into a decision directed acyclic graph containing shared sub-expressions, and a corresponding signal subscription set is established for each scenario rule; Based on the signal subscription set, subscribe to the corresponding real-time signals of each of the vehicle controllers and the vehicle terminals. Only when the real-time signals in the signal subscription set are updated, perform incremental evaluation on the affected nodes in the decision directed acyclic graph to obtain the incremental evaluation result. The corresponding event timestamp is updated by storing the signal in a ring buffer, and a time window judgment is performed based on the incremental evaluation result to obtain a first matching result that meets the preset timing requirements. According to a preset threshold, the corresponding real-time signals of each vehicle controller and the vehicle terminal are compared to obtain a second matching result; Based on the first matching result and the second matching result, determine whether the scene triggering condition of the meal in the dynamic configuration item is met, and execute the corresponding action sequence when it is determined that the condition is met; If the dynamic configuration item contains a cross-domain action indication, the second cross-domain control instruction is generated based on the action sequence.

5. The system of claim 1, wherein, The cloud configuration module and the service processing module achieve differential distribution and robust transmission of the vehicle-side configuration file through a preset secure channel. The process of the cloud configuration module distributing the vehicle-side configuration file includes the following steps: The vehicle-side configuration file to be issued is subjected to block hashing to construct a Merkle tree for the corresponding configuration version; Based on the Merkle trees corresponding to the latest vehicle configuration version and the current vehicle configuration version, generate version difference data between the two versions; Add a cyclic redundancy check code and block index information to each block of the version difference data, add a version tag and the deadline for the configuration to take effect, and then send the version difference data with the added information to the vehicle-side execution system.

6. The system of claim 1, wherein, The vehicle-mounted execution system further includes a diagnostic processing module; the diagnostic processing module is specifically used for: Map the configuration execution results of the static configuration items and the dynamic configuration items to the corresponding diagnostic parameters or fault codes; Monitor the execution status of the static and dynamic configuration items, and trigger a rollback operation when an abnormal configuration execution is detected.

7. The system of claim 6, wherein, The vehicle-side execution system also includes a non-volatile storage module, which interacts with the diagnostic processing module. The non-volatile storage module is used to store the configuration data, configuration execution results, and corresponding status information of the vehicle-side configuration file. The data structure of the non-volatile storage module is consistent with the configuration model of the cloud configuration center.

8. A vehicle-cloud integrated control method characterized by comprising: The method is applied in a vehicle-cloud integrated control system, which includes a cloud configuration center and a vehicle-side execution system. The cloud configuration center includes a cloud configuration module, and the vehicle-side execution system includes a service processing module, a scene processing module, an RC module, multiple vehicle controllers, and multiple vehicle terminals. The cloud configuration module is controlled to generate a vehicle configuration file based on the vehicle status data from the vehicle execution system; the vehicle status data is used to characterize the real-time status parameters of each vehicle controller and each vehicle terminal. The service processing module is controlled to parse the configuration task of the vehicle-side configuration file to obtain static configuration items and dynamic configuration items. If there is a cross-domain action indication in the static configuration item, a first cross-domain control instruction is generated. The static configuration item is a configuration item that does not depend on the real-time state of the vehicle. The dynamic configuration item is a configuration item that depends on the real-time state of the vehicle. The scene processing module is controlled to execute the action sequence in the dynamic configuration item based on the real-time signals of each vehicle controller and each vehicle terminal, and to generate a second cross-domain control instruction when there is a cross-domain action indication in the dynamic configuration item. The RC module is controlled to call the execution interfaces corresponding to the first cross-domain control instruction and the second cross-domain control instruction, and distribute the first cross-domain control instruction and the second cross-domain control instruction to the corresponding vehicle controller or vehicle terminal; wherein, the cross-domain control instruction is used to characterize an instruction that requires multiple vehicle controllers and multiple vehicle terminals to participate in the configuration task.

9. The method of claim 8, wherein, The scene processing module includes preset weight calculation rules and preset scene classification rules. The weighting factors of the preset weight calculation rules include static priority, security level, urgency and execution cost. The preset scenario classification rules are used to divide scenario rules into real-time scenarios and time-limited scenarios; The generation process of the second cross-domain control instruction includes: Obtain all scene rules corresponding to the dynamic configuration item, and determine the weight value and scene type of each scene rule according to the preset weight calculation rule and the preset scene classification standard; The scheduling is sorted according to the weight value, scenario type and configuration task deadline of each scenario rule, and scenario rules with conflicting scenario types are divided into the same mutually exclusive group. Assign an execution token to each of the aforementioned mutex groups to obtain the execution queue; The execution of each scenario rule is triggered sequentially according to the execution queue. The execution of the current scenario rule is determined based on the token holding status of each mutex group. The action sequence corresponding to the successfully executed scenario rule is then output. A sequence check is performed on the action sequence corresponding to the executed scenario rule. If there is a cross-domain action indication in the sequence, the second cross-domain control instruction is generated based on the action sequence.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, When the program is executed by the processor, it implements the vehicle-cloud integrated control method as described in any one of claims 8-9.

Images