Context-filtered intelligent generation system and method for vehicle-mounted components

Abstract

This invention discloses an intelligent generation system and method for in-vehicle components based on context filtering, belonging to the field of in-vehicle component generation technology. The system includes: collecting multi-dimensional context data of the target in-vehicle scenario and generating initial in-vehicle component task instructions; performing three-layer progressive filtering on the multi-dimensional context data to output three layers of effective context data; generating hierarchical in-vehicle tags based on the three layers of effective context data and assembling them to generate standardized in-vehicle prompts; iteratively optimizing the initial in-vehicle components using a self-healing network model until the initial in-vehicle components meet the AEC-Q100 automotive-grade compliance rate and hardware compatibility standards, and outputting an effective component generation signal; disassembling the compliant components into executable subtasks for asynchronous execution, and dynamically correcting the state of the executable subtasks by comparing context data in real time. This invention achieves accurate, compliant, and efficient generation of in-vehicle components, ensuring operational stability and adapting to various in-vehicle application scenarios.

Description

Technical Field

[0001] This invention belongs to the field of automotive component generation technology, specifically a context-filter-based intelligent generation system and method for automotive components. Background Technology

[0002] With the rapid development of intelligent vehicle technology, the complexity of in-vehicle electronic systems continues to increase. The rapid and compliant generation of in-vehicle components has become a key requirement. Currently, in-vehicle component generation technologies mostly rely on manual coding or simple template matching, which has certain shortcomings. First, the context data processing is crude, directly using raw driving behavior, vehicle status, and road environment data, resulting in data redundancy and a large amount of abnormal data, leading to component requirement deviations and low development efficiency. Second, there is a lack of systematic filtering mechanisms, making it difficult to balance automotive-grade safety, data privacy compliance, and hardware compatibility. Generated components often have insufficient compliance rates and hardware interface incompatibility issues, requiring repeated debugging. Third, after component generation, they are mostly deployed as a whole, which cannot adapt to the asynchronous concurrent operation requirements of in-vehicle systems. Moreover, during operation, inconsistencies in context states and abnormal resource consumption are prone to occur, resulting in poor stability and weak adaptability.

[0003] In summary, existing technologies are insufficient to meet the requirements of intelligent vehicles for accurate, compliant, efficient, and stable generation of in-vehicle components. There is an urgent need for an intelligent generation solution for in-vehicle components based on context filtering to address pain points such as data redundancy, insufficient compliance adaptation, and unstable operation. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes an intelligent vehicle component generation system and method based on context filtering. The system collects multi-dimensional context data of the target vehicle scenario and generates initial vehicle component task instructions. It then performs three-layer progressive filtering on the multi-dimensional context data, outputting three layers of valid context data. Based on this valid context data, it generates hierarchical vehicle tags and assembles them to generate standardized vehicle prompts. A self-healing network model is then used to iteratively optimize the initial vehicle component until its AEC-Q100 automotive compliance rate and hardware compatibility meet the standards, at which point a valid component generation signal is output. The compliant component is then decomposed into executable subtasks for asynchronous execution, with the executable subtask status dynamically corrected based on real-time comparison of context data. This invention achieves accurate, compliant, and efficient generation of vehicle components, ensuring operational stability and adapting to various vehicle application scenarios.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A context-filter-based intelligent generation method for in-vehicle components includes:

[0007] S1: Collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions based on the multi-dimensional context data;

[0008] S2: Based on the initial vehicle component task instruction, perform three-layer progressive filtering on the multi-dimensional context data and output three layers of valid context data accordingly.

[0009] S3: Generate hierarchical vehicle tags based on the three layers of effective context data, and assemble scene adaptation prompt words based on the hierarchical vehicle tags to generate standardized vehicle prompt words;

[0010] S4: Based on the standardized vehicle prompt words, and combined with the three layers of effective context data, perform multi-layer self-repair optimization on the initial vehicle components until the AEC-Q100 automotive compliance rate and hardware compatibility of the initial vehicle components meet the standards, and output an effective component generation signal.

[0011] S5: Based on the effective component generation signal, the preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks. The executable sub-tasks are deployed and executed asynchronously. During the asynchronous operation of the executable sub-tasks, context state consistency data and function adaptation data are collected in real time and compared with the three-layer effective context data. The asynchronous operation execution state of each executable sub-task is dynamically corrected based on the comparison results.

[0012] Specifically, the steps of S1 include:

[0013] Real-time acquisition of driving behavior parameters, vehicle operating status parameters, and road environment parameters based on vehicle bus network and vehicle sensor group, and summarization of the driving behavior parameters, vehicle operating status parameters, and road environment parameters into multi-dimensional context data;

[0014] Based on a preset component requirement mapping table, the multidimensional context data is used to extract requirement features to obtain the corresponding component functional requirement features and component performance requirement features.

[0015] The component functional requirement features and component performance requirement features are mapped to a component logic flow sequence based on the time-series matching algorithm, and the component logic flow sequence is encapsulated into an initial vehicle component task instruction according to a preset instruction template.

[0016] Specifically, the steps of S2 include:

[0017] Based on the initial vehicle component task instructions, abnormal and redundant data in the multidimensional context data are filtered to generate first intermediate filtered data.

[0018] Based on the principal component analysis algorithm, the first intermediate filtered data is subjected to decorrelation and dimensionality reduction to obtain pure demand context data;

[0019] Based on the pure demand context data, query the preset vehicle compliance rule library, extract the safety compliance items and data privacy compliance items associated with the current scenario, and integrate the safety compliance items and the data privacy compliance items into compliance constraint context data;

[0020] Based on the compliance constraint context data, hardware feasibility verification is performed on the pure demand context data, and feature data that does not match the current vehicle hardware resources is removed to obtain effective execution context data.

[0021] The pure requirement context data, the compliance constraint context data, and the valid execution context data are concatenated to obtain three layers of valid context data.

[0022] Specifically, the generation of hierarchical vehicle tags based on the three layers of valid context data includes:

[0023] Based on a pre-trained text classification model, label prediction is performed on each layer of data in the three layers of effective context data to obtain the first-level requirement label corresponding to the pure requirement context data, the second-level constraint label corresponding to the compliance constraint context data, and the third-level execution label corresponding to the effective execution context data; the text classification model includes a requirement feature extraction branch, a constraint feature extraction branch, and an execution feature extraction branch.

[0024] The first-level requirement label, the second-level constraint label, and the third-level execution label are filled into a preset label structure according to their level to generate hierarchical vehicle labels.

[0025] Specifically, based on the hierarchical vehicle-mounted tags, scenario-adaptive prompt words are assembled to generate standardized vehicle-mounted prompt words, including:

[0026] Based on the first-level demand tag in the hierarchical vehicle tag, a preset scenario template library is queried to obtain a basic prompt word structure that matches the current vehicle scenario; the basic prompt word structure contains at least one field to be constrained and at least one field to be executed.

[0027] The label values ​​of the second-level constraint labels are filled into the field to be constrained in the basic prompt word structure to generate a prompt word intermediate with constraints.

[0028] The tag value of the third-level execution tag is filled into the parameter field to be executed in the constrained prompt word intermediate to generate a standardized vehicle prompt word.

[0029] Specifically, the specific steps of S4 include:

[0030] The standardized in-vehicle prompts and the three layers of effective context data are input into the pre-trained self-healing network model. At the same time, the initial in-vehicle component task instructions are parsed into initial in-vehicle components to be optimized, and the initial in-vehicle components to be optimized are used as the target operation objects of the self-healing network model.

[0031] The self-healing network model uses the standardized in-vehicle prompts as the repair target guidance vector and the three layers of effective context data as the repair constraint basis matrix. Based on the repair target guidance vector and the repair constraint basis matrix, it performs layer-by-layer traversal detection on the internal logic nodes of the initial in-vehicle component to be optimized, identifies logic nodes that do not conform to automotive standards as logic nodes to be repaired, and identifies resource configuration nodes that do not match the in-vehicle hardware abstraction layer interface definition file as resource nodes to be adjusted.

[0032] For the identified logical nodes to be repaired, a corresponding logical correction patch is generated; for the identified resource nodes to be adjusted, a corresponding resource remapping patch is generated; the logical correction patch and the resource remapping patch are merged into a comprehensive repair patch; and the comprehensive repair patch is embedded into the initial vehicle component to be optimized to generate the first optimized component.

[0033] Specifically, the steps of S4 further include:

[0034] The first optimized component is verified item by item based on a preset automotive compliance test rule library. The ratio of the number of code modules in the first optimized component that meet automotive standards to the total number of code modules is calculated. The ratio is used as the AEC-Q100 automotive compliance rate. The degree of matching of the first optimized component to each hardware interface is detected based on the in-vehicle hardware abstraction layer interface definition file. The degree of matching is quantified as hardware adaptability.

[0035] If the AEC-Q100 automotive compliance rate is greater than or equal to a preset compliance threshold and the hardware compatibility is greater than or equal to a preset compatibility threshold, then the current first optimized component is marked as a compliant component, and a valid component generation signal is generated based on the compliant component.

[0036] If the AEC-Q100 automotive compliance rate is less than the compliance threshold or the hardware compatibility is less than the compatibility threshold, then the current first optimized component is used as the updated initial in-vehicle component to be optimized, and the step of inputting the standardized in-vehicle prompts and the three layers of effective context data into the pre-trained self-healing network model is re-executed for iterative optimization until the qualified component is generated.

[0037] Specifically, based on the effective component generation signal, a preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks, including:

[0038] The effective component generation signal is sent as a trigger command to the task scheduling center embedded in the vehicle operating system. After receiving the effective component generation signal, the task scheduling center reads the binary executable file corresponding to the qualified component from the vehicle non-volatile memory, performs control flow analysis on the binary executable file, extracts the jump relationship and call relationship between the basic blocks in the qualified component, and organizes the jump relationship and the call relationship into the control flow graph of the qualified component according to the graph structure.

[0039] The task scheduling center inputs the control flow graph to a preset multi-task splitting mechanism. The multi-task splitting mechanism traverses each basic block node in the control flow graph, identifies basic block nodes that do not contain any branch jump instructions as serial execution code blocks, and identifies basic block nodes that contain conditional branch instructions or parallel prefetch instructions as parallel execution code blocks.

[0040] All identified serially executed code blocks are encapsulated into a first subtask according to their original execution order in the control flow graph. All identified parallel executed code blocks are grouped according to the data dependencies in the control flow graph, and a second subtask with an independent entry point is generated for each group.

[0041] The multi-task splitting mechanism outputs the first subtask and each of the second subtasks as the splitting result, resulting in multiple executable subtasks.

[0042] Specifically, the executable subtask is deployed and executed asynchronously. During the asynchronous execution of the executable subtask, context state consistency data and functional adaptation data are collected in real time, including:

[0043] Multiple executable subtasks are input into the task scheduler of the vehicle operating system, the priority weight of each executable subtask is calculated, and the estimated resource consumption of each executable subtask is calculated based on the number of lines of code and the complexity of the loop structure contained in each executable subtask.

[0044] Based on the calculated priority weights and estimated resource consumption of each executable subtask, each executable subtask is assigned to a pre-defined asynchronous task execution queue in the vehicle operating system, and each executable subtask is triggered to execute asynchronously and concurrently on the corresponding processor core.

[0045] During the asynchronous concurrent execution of each executable subtask, a preset resource monitoring probe in the vehicle operating system is activated. The resource monitoring probe collects the actual occupancy rate of the target hardware resources during the execution of each executable subtask in real time. The actual occupancy rate is compared with the expected occupancy rate in the vehicle hardware abstraction layer interface definition file to generate functional adaptation data.

[0046] Specifically, the executable subtask is deployed and executed asynchronously, and context state consistency data and functional adaptation data are collected in real time during the asynchronous execution of the executable subtask, further including:

[0047] During the asynchronous concurrent execution of each executable subtask, a pre-set periodic polling monitoring service in the vehicle operating system is started, which captures the current input data and current output data of each executable subtask in real time.

[0048] The current input data is compared field by field with the predefined subtask standard input data in the effective execution context data within the three-layer effective context data. If the field values ​​are the same, a first consistency tag is generated and marked as true. If the field values ​​are different, a first consistency tag is generated and marked as false. The first consistency tags of all fields are summarized to obtain the first consistency tag set.

[0049] The current output data is compared field by field with the predefined subtask standard output data in the effective execution context data within the three-layer effective context data. If the field values ​​are the same, a second consistency flag is generated and marked as true. If the field values ​​are different, a second consistency flag is generated and marked as false. The second consistency flags of all fields are summarized to obtain the second consistency flag set.

[0050] The first set of consistency tags and the second set of consistency tags are merged into context state consistent data.

[0051] Specifically, the asynchronous execution state of each executable subtask is dynamically adjusted based on the comparison results, compared with the three layers of valid context data, including:

[0052] Based on the first consistency marker and the second consistency marker, locate the mismatched subtask corresponding to the false marker;

[0053] The execution of the mismatched subtask is paused by invoking a preset rollback recovery mechanism, and an initial configuration snapshot of the three-layer valid context data corresponding to the mismatched subtask is retrieved from the preset checkpoint storage area.

[0054] Based on the initial configuration snapshot, the input port configuration and output port configuration of the mismatched subtask are reset, a port reset instruction is generated, and the operation of the mismatched subtask is restored based on the port reset instruction. At the same time, the running status of the mismatched subtask is marked as corrected.

[0055] When the actual occupancy rate deviates from the expected occupancy rate and the deviation exceeds a preset deviation threshold, based on the function adaptation data, the resource allocation ratio or execution priority of each executable subtask in the asynchronous task execution queue is adjusted.

[0056] A context-filter-based intelligent generation system for in-vehicle components includes:

[0057] The instruction generation module is used to collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions.

[0058] The three-layer progressive filtering module is used to perform three-layer progressive filtering on multi-dimensional context data and output three layers of valid context data;

[0059] The prompt word assembly module is used to generate standardized vehicle prompt words. It predicts hierarchical vehicle labels from three layers of effective context data through a pre-trained text classification model. Then, it queries the scenario template library based on the hierarchical vehicle labels to obtain the basic prompt word structure and fills in the constraint label and execution label in sequence to generate standardized vehicle prompt words.

[0060] The multi-layer self-healing optimization module is used to iteratively optimize the initial vehicle components until they meet the standards. It inputs standardized vehicle prompts and three layers of effective context data into a pre-trained self-healing network model, identifies the logic nodes to be repaired and the resource nodes to be adjusted, generates and embeds a comprehensive repair patch to obtain the first optimized component, and achieves iterative optimization through vehicle compliance rate and hardware adaptability verification, outputting the qualified component and effective component generation signals.

[0061] The asynchronous scheduling correction module is used to decompose compliant components and dynamically correct the running status of executable subtasks. It collects context state consistency data and function adaptation data in real time, locates mismatched subtasks by comparing the results, and rolls them back and resets them.

[0062] Compared with the prior art, the beneficial effects of the present invention are:

[0063] 1. This invention addresses the pain points of chaotic multidimensional contextual data, numerous anomalies and redundancies, lack of compliance constraints, and insufficient hardware compatibility in in-vehicle scenarios. It proposes a three-layer progressive filtering mechanism, sequentially completing anomaly and redundancy removal, principal component analysis dimensionality reduction, in-vehicle compliance rule matching, and hardware feasibility verification, forming three layers of effective contextual data and achieving a systematic improvement in data quality. Based on this, a pre-trained text classification model generates hierarchical in-vehicle tags, and a scenario template library is used to assemble standardized in-vehicle prompts. This provides precise, compliant, and executable target guidance for the generation of in-vehicle components, reducing requirement deviations from the source, improving the accuracy, standardization, and hardware compatibility of component generation, reducing the time and manpower costs associated with manual intervention and repeated debugging, and effectively improving the development efficiency and delivery quality of in-vehicle components.

[0064] 2. This invention relies on a pre-trained self-healing network model, guided by standardized in-vehicle prompts and based on three layers of effective context data. It detects logical nodes and resource configuration nodes layer by layer, generates logic correction patches and resource remapping patches, and iteratively optimizes them until the AEC-Q100 automotive compliance rate and hardware compatibility reach a preset threshold, ensuring that the generated components meet the requirements of in-vehicle safety and hardware interfaces. At the same time, a multi-task splitting mechanism is introduced to decompose the compliant components into serial and parallel executable subtasks, which run asynchronously and concurrently in the in-vehicle operating system. Context state consistency data and functional adaptation data are collected in real time. Through dynamic rollback reset, adjustment of resource allocation and execution priority, it effectively avoids operational anomalies, state mismatches, and resource overflows, achieving stable, reliable, and efficient operation of in-vehicle components and enhancing the system robustness and dynamic adaptability in complex in-vehicle scenarios. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of the intelligent generation method for vehicle components based on context filtering according to the present invention;

[0066] Figure 2 This is a flowchart illustrating the principle of the intelligent generation method for vehicle components based on context filtering according to the present invention.

[0067] Figure 3 This is a diagram of the intelligent generation system architecture for vehicle components based on context filtering, as described in this invention. Detailed Implementation

[0068] Example 1:

[0069] Please see Figure 1 and Figure 2 The present invention provides an embodiment of an intelligent generation method for in-vehicle components based on context filtering, comprising the following steps:

[0070] S1: Collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions based on the multi-dimensional context data;

[0071] S2: Based on the initial vehicle component task instruction, perform three-layer progressive filtering on the multi-dimensional context data and output three layers of valid context data accordingly.

[0072] S3: Generate hierarchical vehicle tags based on the three layers of effective context data, and assemble scene adaptation prompt words based on the hierarchical vehicle tags to generate standardized vehicle prompt words;

[0073] S4: Based on the standardized vehicle prompt words, and combined with the three layers of effective context data, perform multi-layer self-repair optimization on the initial vehicle components until the AEC-Q100 automotive compliance rate and hardware compatibility of the initial vehicle components meet the standards, and output an effective component generation signal.

[0074] Furthermore, AEC-Q100 is a stress testing and certification standard based on failure mechanisms for automotive integrated circuits.

[0075] S5: Based on the effective component generation signal, the preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks. The executable sub-tasks are deployed and executed asynchronously. During the asynchronous operation of the executable sub-tasks, context state consistency data and function adaptation data are collected in real time and compared with the three-layer effective context data. The asynchronous operation execution state of each executable sub-task is dynamically corrected based on the comparison results.

[0076] The specific steps of S1 include:

[0077] S1.1: Real-time acquisition of driving behavior parameters, vehicle operating status parameters, and road environment parameters based on the vehicle bus network and vehicle sensor group, and summarization of the driving behavior parameters, vehicle operating status parameters, and road environment parameters into multi-dimensional context data;

[0078] Furthermore, the specific process of real-time acquisition of driving behavior parameters, vehicle operating status parameters, and road environment parameters based on the vehicle bus network and vehicle sensor group includes: The vehicle bus network adopts a distributed data transmission architecture, which can simultaneously receive and forward operating signals output by multiple electronic control units inside the vehicle. After the operating signals are processed by the signal analysis module, they are converted into standardized vehicle operating status parameters, covering real-time operating information of core vehicle components such as engine speed, transmission gear position, battery voltage, braking system pressure, steering system angle, headlight operating status, and air conditioning operating mode; The vehicle sensor group is divided into a driving behavior perception subgroup and a road environment perception subgroup according to different perception functions; The driving behavior perception subgroup captures the driver's steering wheel turning action, accelerator pedal force and frequency, brake pedal timing and force, gear shifting operation, and other behavioral information in real time, and converts it into corresponding driving behavior parameters; The road environment perception subgroup uses cameras, radar, lidar, and other devices to collect real-time environmental information such as obstacle information, lane line information, traffic light status, road sign information, surrounding vehicle distribution, pedestrian dynamics, weather conditions, light intensity, and road surface smoothness in front of, to the side, and behind the vehicle, and generates road environment parameters.

[0079] Furthermore, the specific process of summarizing driving behavior parameters, vehicle operating status parameters, and road environment parameters into multi-dimensional context data includes: receiving vehicle operating status parameters parsed from the vehicle bus network, driving behavior parameters output by the driving behavior perception subgroup, and road environment parameters collected by the road environment perception subgroup; firstly, performing timestamp alignment processing to ensure that different dimensions of parameters collected at the same time node can accurately correspond, avoiding data association errors caused by time sequence deviations; then, performing format standardization conversion to unify data types, data precision, and data encoding methods, eliminating data format differences caused by different sensors and different bus protocols; finally, combining the standardized driving behavior parameters, vehicle operating status parameters, and road environment parameters in sequence to form multi-dimensional context data containing driving behavior dimension, vehicle status dimension, and road environment dimension, which can comprehensively and accurately reflect the actual situation of the current vehicle scenario.

[0080] For example, in this embodiment, the driver drives at a moderate speed on urban roads, smoothly controls the steering wheel, intermittently lightly presses the accelerator to maintain the speed, and does not frequently use the brakes. At this time, the driving behavior parameters will record characteristics such as smooth changes in steering wheel angle, stable accelerator opening, and low braking trigger frequency; the vehicle operation status parameters will show that the vehicle speed is maintained within a reasonable range, the engine speed is stable, the battery voltage is normal, and there are no fault alarms in each system; the road environment parameters will capture information such as sufficient daylight, dry and flat road surface, clear lane lines, appropriate distance between vehicles in front, no sudden obstacles, and normal traffic lights. After being summarized, a complete multi-dimensional contextual data is formed, which accurately describes the in-vehicle scenario of driving at a constant speed on urban roads.

[0081] S1.2: Extract requirement features from the multidimensional context data based on the preset component requirement mapping table to obtain the corresponding component functional requirement features and component performance requirement features;

[0082] Furthermore, the pre-defined component requirement mapping table is a structured database built on a large amount of in-vehicle scenario data and in-vehicle component development experience. Its core is to directly map in-vehicle scenarios and contextual data features to the functions and performance requirements of components. The component requirement mapping table predefines the correspondence between different in-vehicle scenarios, different contextual data features and in-vehicle component requirements, covering the functional attributes and performance indicators required by components in various typical in-vehicle scenarios. The component requirement mapping table adopts a hierarchical and classified organization form. The top layer is the scenario type, the middle layer is the combination of contextual data features, and the bottom layer is the corresponding functional and performance requirements. Each combination of middle-level contextual data features corresponds to a set of bottom-level functional and performance requirements, which can achieve accurate matching of multi-dimensional contextual data to component requirement features.

[0083] Further, the specific process of extracting requirement features from the multi-dimensional context data to obtain the corresponding component functional requirement features and component performance requirement features includes: firstly, reading a preset component requirement mapping table and loading the corresponding mapping relationship between vehicle scene type, context data feature combination and component functional requirement features and component performance requirement features in the component requirement mapping table. The corresponding mapping relationship refers to the pre-fixed matching entries between any vehicle scene type, any context data feature combination in the component requirement mapping table, and any set of component functional requirement features and any set of component performance requirement features. Then, feature parsing is performed on the multi-dimensional context data. Context data dimension features are extracted from the multi-dimensional context data according to three dimensions: driving behavior, vehicle operating state, and road environment. Context data dimension features refer to key information that can be quantified or qualitatively described in each dimension. For example, driving behavior dimension features include operational smoothness and operation frequency characteristics; vehicle operating state dimension features include vehicle speed range and system load level; and road environment dimension features include lighting conditions, road type, and environmental complexity. The extracted context data dimension features are combined to form a real-time context. The data feature combination is then performed. Next, the real-time context data feature combination is compared one by one with the pre-stored context data feature combinations in the component requirement mapping table. The matching degree between the two sets of feature combinations is calculated, and the target mapping relationship that best fits the current in-vehicle scenario is selected according to the feature matching degree from high to low. Here, the matching degree refers to the similarity between the real-time context data feature combination and the pre-stored context data feature combination in the component requirement mapping table, calculated using the cosine similarity formula. The cosine similarity formula is existing technology in this field and is not an inventive solution of this application, so it will not be elaborated here. Finally, based on the selected target mapping relationship, the corresponding component functional requirement features and component performance requirement features are extracted from the component requirement mapping table. The component functional requirement features specify the specific functions that the in-vehicle component needs to implement, such as data acquisition, instruction parsing, logic control, hardware adaptation, exception handling, and data interaction. The component performance requirement features specify the performance indicators that the in-vehicle component must meet, such as response speed, operational stability, resource utilization, data processing accuracy, concurrent processing capability, and fault tolerance capability, ensuring that the extracted requirement features accurately match the actual usage requirements of the current in-vehicle scenario.

[0084] For example, in this embodiment, the multi-dimensional context data reflects the characteristics of uniform speed driving on urban roads, smooth driving operation, moderate vehicle operating load, and moderate road environment complexity. After matching these characteristics with the component requirement mapping table, the extracted component functional requirement characteristics include real-time data reception, driving behavior analysis, vehicle status monitoring, environmental information parsing, control command generation, hardware interface adaptation, data anomaly verification, and real-time status feedback. The component performance requirement characteristics include millisecond-level response speed, low CPU and memory usage, over 99.9% operational stability, data processing error below the preset range, support for multi-task concurrent processing, and the ability to self-recover from minor faults. These requirement characteristics accurately match the functional and performance requirements of the vehicle components under normal driving scenarios on urban roads.

[0085] S1.3: Based on the timing matching algorithm, the component functional requirement features and the component performance requirement features are mapped into a component logic flow sequence, and the component logic flow sequence is encapsulated into an initial vehicle component task instruction according to a preset instruction template.

[0086] Furthermore, the timing matching algorithm is a pattern recognition and sequence mapping algorithm for timing feature data. It can identify the timing relationship, logical dependency relationship and execution order between component functional requirement features and component performance requirement features, and transform discrete requirement features into component logic flow sequences with clear execution logic and timing order.

[0087] Furthermore, the specific process of mapping the component functional requirement features and the component performance requirement features to a component logic flow sequence based on the time-series matching algorithm includes:

[0088] (1) Obtain the functional requirements features of the components, sort out the execution order of the functional requirements features of each component according to the operation process of the vehicle components, determine the temporal sequence constraint relationship between the functional requirements features of adjacent components, and form a functional requirement temporal chain;

[0089] (2) Perform logical dependency analysis on the component performance requirement characteristics, take the functional requirement sequence chain as input, establish the association mapping relationship between the component performance requirement characteristics and the component functional requirement characteristics execution links, clarify the functional execution nodes corresponding to each component performance requirement characteristics, and form a performance requirement association mapping table.

[0090] (3) Load the preset standard logic flow pattern library. The standard logic flow pattern library stores standard logic flow templates corresponding to the functional requirements and performance requirements of components in various vehicle scenarios. Taking the performance requirement association mapping table as input, the similarity calculation is performed between the functional requirement sequence chain and performance requirement association mapping relationship in the current scenario and the standard logic flow template in the standard logic flow pattern library to obtain the optimal standard logic flow template matching result. The similarity calculation adopts the cosine similarity formula.

[0091] (4) Based on the optimal standard logic flow template matching result, the functional requirement sequence chain is used as the basis to arrange the component functional requirement features in the order of time sequence. At the same time, the component performance requirement features are embedded into the corresponding functional execution link as execution constraints according to the performance requirement association mapping table, so as to generate a component logic flow sequence with clear structure, logical coherence and clear time sequence.

[0092] Furthermore, the preset instruction template is a standardized encapsulation template designed based on the vehicle control system instruction specifications. The instruction template includes a fixed structure such as an instruction header, scene identifier, logic flow field, performance constraint field, verification field, and instruction tail. The instruction template features strong compatibility, good scalability, and convenient parsing, adapting to the task instruction encapsulation requirements of different types of vehicle components. This ensures that the encapsulated instructions have a unified format, complete information, and can be directly recognized and parsed by the vehicle system. In this embodiment, scene type information is filled into the scene identifier field, the entire component logic flow sequence is filled into the logic flow field, performance constraint indicators are filled into the performance constraint field, and an instruction verification code is generated and filled into the verification field. This ensures the integrity and correctness of the instruction transmission and parsing process. After completing the filling and splicing of all fields, a standardized and structured initial vehicle component task instruction is generated, which can be directly recognized by the vehicle system.

[0093] The specific steps of S2 include:

[0094] S2.1: Based on the initial vehicle component task instruction, filter the abnormal and redundant data in the multidimensional context data to generate the first intermediate filtered data;

[0095] Furthermore, abnormal data refers to data that deviates from the normal distribution pattern of in-vehicle scenario data, exceeds the reasonable value range, has contradictory timing logic, or is formatted incorrectly. Examples include negative vehicle speed values, engine speed exceeding the limit range, steering wheel angles being extreme at the same timestamp, and missing or garbled sensor data. This type of data is generated by sensor malfunctions, signal transmission interference, and abnormal acquisition equipment, and has no practical reference value, and will interfere with subsequent data processing. Redundant data refers to data that is repeatedly collected in multi-dimensional context data, is highly similar, is unrelated to the current in-vehicle component task instructions, or can be replaced by other data. Examples include the same environmental information being repeatedly collected by multiple sensors, environmental data from areas other than the current driving area, vehicle backup system data unrelated to the current component function, and repeatedly repeated state parameters. This type of data occupies storage resources, increases the data processing burden, and has no substantial meaning.

[0096] S2.2: Based on the principal component analysis algorithm, the first intermediate filtered data is subjected to decorrelation and dimensionality reduction processing to obtain pure demand context data. The principal component analysis algorithm is the prior art in this field and is not an inventive solution of this application, so it will not be described in detail here.

[0097] Further, the specific steps of S2.2 include: receiving the first intermediate filtered data and performing standardized preprocessing to obtain standardized first intermediate filtered data, eliminating the influence of differences in the dimensions and numerical ranges of data from different dimensions, and ensuring that the contribution of each dimension of data to the dimensionality reduction result is balanced; then calculating the covariance matrix of the standardized first intermediate filtered data, which can clearly reflect the correlation strength between the data of each dimension. The stronger the correlation, the larger the covariance value; solving the eigenvalues ​​and eigenvectors of the covariance matrix, where the eigenvalues ​​represent the amount of data information contained in the corresponding principal components, and the eigenvectors determine the direction of the principal components; then screening the principal components in descending order of eigenvalues, selecting the top N principal components whose cumulative information content reaches a preset threshold of 0.95, and eliminating redundant dimensions with extremely low information content and containing only minor noise information to achieve data dimensionality reduction, where 5≤N≤16; finally, restoring the screened principal components to feature data strongly related to the requirements of automotive components. These data variables are independent of each other, have no redundant correlation, and completely retain the core information related to the functional and performance requirements of the components in the first intermediate filtered data, which is the pure requirement context data.

[0098] For example, in this embodiment, the first intermediate filtered data still contains multiple correlated dimensions, such as vehicle speed and acceleration, ambient light and headlight status, steering wheel angle and lane line deviation, etc. These dimensional data have overlapping information. After the principal component analysis algorithm performs decorrelation and dimensionality reduction processing, the original dozens of dimensions are simplified to more than ten core dimensions, eliminating redundant correlations and secondary noise information between variables. The final pure demand context data focuses on core demand characteristics such as driving behavior smoothness, vehicle operation stability, road environment complexity, and data reliability.

[0099] S2.3: Based on the pure demand context data, query the preset vehicle compliance rule base, extract the safety compliance items and data privacy compliance items associated with the current scenario, and integrate the safety compliance items and the data privacy compliance items into compliance constraint context data;

[0100] Furthermore, the pre-defined vehicle compliance rule base is a standardized rule database built based on national vehicle electronic device safety standards, automotive industry technical specifications, vehicle data security regulations, and personal information protection regulations. The vehicle compliance rule base adopts a hierarchical and classified architecture. The top layer is divided into a safety compliance sub-base and a data privacy compliance sub-base. The safety compliance sub-base covers rules related to the operational safety of vehicle components, ISO 26262 functional safety, electrical safety, mechanical safety, and automotive standards. The data privacy compliance sub-base contains privacy protection rules for vehicle data collection, transmission, storage, use, sharing, and destruction. Each rule in the vehicle compliance rule base clearly indicates the applicable scenario, compliance conditions, constraints, consequences of violations, and priority, and can cover the compliance requirements of various vehicle types, such as passenger cars, commercial vehicles, and new energy vehicles, under different vehicle scenarios.

[0101] Furthermore, the specific process of extracting safety compliance items and data privacy compliance items related to the current scenario based on the pre-set vehicle compliance rule library query of the pure demand context data includes: First, parsing the pure demand context data to extract key features of the current vehicle scenario, including vehicle type, driving scenario, data type, data purpose, and data scope, forming scenario feature query conditions; then, inputting the scenario feature query conditions into the retrieval engine of the vehicle compliance rule library, and the retrieval engine performs precise matching retrieval in the safety compliance sub-library and the data privacy compliance sub-library respectively. The safety compliance sub-library matches the safety rules that vehicle components must meet in terms of operation, function, and electrical aspects under the current scenario, and the data privacy compliance sub-library matches the privacy protection rules that must be followed in the current scenario for vehicle data collection, use, and transmission; next, the retrieval engine filters out all rule items that are completely matched or highly adapted to the current scenario features, and removes unsuitable or irrelevant rules; finally, the filtered rule items are prioritized and retained, with mandatory and high-priority compliance items retained first, to obtain safety compliance items and data privacy compliance items, ensuring that the extracted rule items are all core compliance requirements that vehicle components must strictly comply with under the current vehicle scenario.

[0102] Furthermore, the specific process of integrating the security compliance entries and the data privacy compliance entries into compliance constraint context data includes: receiving security compliance entries and data privacy compliance entries; firstly, performing structured parsing on the two types of entries to extract key information such as compliance conditions, constraint parameters, execution requirements, and verification standards for each rule; then classifying and organizing them according to security constraint dimensions and privacy constraint dimensions, eliminating duplicate and conflicting rule entries, and logically associating related rules; finally, orderly combining the organized security compliance information and data privacy compliance information to form compliance constraint context data that is structurally clear, content-complete, and has clearly defined constraints.

[0103] For example, in this embodiment, the clean demand context data corresponds to the normal driving scenario of passenger vehicles on urban roads. After querying the vehicle compliance rule base, the extracted safety compliance items include: the operation of vehicle components must meet automotive-grade reliability standards, the component control logic must comply with the ISO 26262 functional safety standard, the electrical interface must meet the vehicle low-voltage system safety specifications, data transmission must have anti-interference and anti-tampering capabilities, and a safety protection mechanism must be triggered under abnormal conditions, etc.; the data privacy compliance items include: the collection of driving behavior data must be authorized by the user, personal biometric data must not be collected, vehicle location data must be stored in encryption, data transmission must use a secure encryption protocol, unnecessary data must not be uploaded to the cloud, and data destruction must comply with privacy protection specifications, etc.; then these safety compliance items and data privacy compliance items are integrated to form compliance constraint context data.

[0104] S2.4: Based on the compliance constraint context data, perform hardware feasibility verification on the pure demand context data, remove feature data that does not match the current vehicle hardware resources, and obtain effective execution context data;

[0105] Furthermore, current vehicle hardware resources include onboard processors, memory, storage devices, communication modules, sensor interfaces, power modules, bus bandwidth, computing power resources, hardware interface types, and other hardware devices and resource parameters actually configured in the vehicle. The core purpose of hardware feasibility verification is to ensure that the generated onboard components can operate normally under the existing hardware resource environment of the vehicle, avoiding problems such as insufficient hardware resources, interface incompatibility, computing power mismatch, and insufficient storage capacity that prevent execution. The verification process is based on compliance constraint context data and combined with the actual hardware configuration parameters of the vehicle. It performs feasibility screening on the feature data in the pure demand context data, eliminating feature data that exceeds the hardware carrying capacity or is incompatible with the hardware interface, and retaining valid feature data that the hardware can support and adapt to.

[0106] Furthermore, the specific steps of S2.4 include: First, reading the compliance constraint context data and extracting the compliance constraint requirements related to hardware adaptation, such as hardware interface type compliance, computing power resource usage compliance, memory usage compliance, storage capacity compliance, power consumption compliance, etc., as the constraint benchmark for hardware feasibility verification; then reading the current on-board hardware resource configuration parameters of the vehicle, including processor model and computing power, memory capacity and read / write speed, storage device capacity and type, communication module bandwidth, hardware interface type and quantity, power output power, bus transmission rate, etc., to form a hardware resource configuration table; then, matching each feature data in the clean requirement context data with the hardware resource configuration... The table and compliance constraints are compared and verified one by one. The verification dimensions include the matching degree of computing power requirements, memory usage matching degree, storage capacity matching degree, hardware interface compatibility, power consumption adaptability, bus bandwidth adaptability, etc., to determine whether the component function or performance requirements corresponding to the feature data are within the capacity of existing hardware resources and whether they meet the compliance constraints. Finally, feature data that fails verification, does not match the current vehicle hardware resources, or exceeds the hardware capacity are removed. Valid feature data that passes verification, is hardware-supported, and is compliant are retained. The component function and performance requirements corresponding to these valid feature data can be executed smoothly in the existing hardware environment, which is the valid execution context data.

[0107] S2.5: The clean requirement context data, the compliance constraint context data, and the effective execution context data are concatenated to obtain three layers of effective context data. The concatenation is carried out in an orderly manner according to the logical order of requirement data-constraint data-execution data, maintaining the integrity and correlation of the internal characteristics of each layer of data, and not disrupting the internal logical structure of the data.

[0108] Based on the three layers of valid context data, a hierarchical vehicle tag is generated, including:

[0109] S3.1: Based on the pre-trained text classification model, label prediction is performed on each layer of data in the three layers of effective context data to obtain the first-level requirement label corresponding to the pure requirement context data, the second-level constraint label corresponding to the compliance constraint context data, and the third-level execution label corresponding to the effective execution context data; the text classification model includes a requirement feature extraction branch, a constraint feature extraction branch, and an execution feature extraction branch;

[0110] Furthermore, the pre-trained text classification model is a multi-branch deep neural network model trained on a large amount of in-vehicle scene context data and label sample data. It adopts a three-branch parallel architecture, corresponding to three main functions: demand feature extraction, constraint feature extraction, and execution feature extraction. Each of the demand feature extraction, constraint feature extraction, and execution feature extraction branches contains five fully connected layers, with the number of neurons in each layer set to 512, 256, 128, 64, and 32 respectively. The activation function is uniformly set to a linear rectified function, and the dropout probability between layers is set to 0.3. Each branch independently processes the context data of its corresponding dimension, extracts its own features, and completes label prediction. Information complementarity is achieved between branches through a feature fusion layer, improving the accuracy of label prediction. The output layer consists of three independent classification output units, corresponding to the first-level demand label, the second-level constraint label, the third-level constraint label, and the fourth-level constraint label. The output of the bundle label and the third-level execution label are all implemented using the softmax activation function to ensure that the output results are normalized label probabilities. The training dataset consists of a large number of labeled vehicle-mounted three-layer effective context data samples, with a total sample size of 100,000. The training epochs are set to 50, the batch size to 32, the optimizer is the adaptive moment estimation optimizer, the initial learning rate is set to 0.001, the learning rate decay coefficient is set to 0.95, and the loss function is the cross-entropy loss function. During training, the validation set ratio is set to 20% to monitor the model training effect and prevent overfitting. Finally, a pre-trained text classification model is obtained after training. The deep neural network model, linear rectified function, softmax activation function, and cross-entropy loss function are all existing technologies in this field and are not inventive solutions of this application, and will not be described in detail here.

[0111] Furthermore, the specific functions of the requirement feature extraction branch, constraint feature extraction branch, and execution feature extraction branch of the text classification model include: the requirement feature extraction branch receives clean requirement context data and automatically mines core semantic features, key information features, and related features related to the functional and performance requirements of vehicle components through a multi-layer feature extraction network, filtering out irrelevant noise information and focusing on core requirement features; the constraint feature extraction branch receives compliance constraint context data and extracts rule features, constraint condition features, and compliance requirement features related to safety compliance and data privacy compliance, accurately capturing core compliance constraint information; the execution feature extraction branch receives valid execution context data and extracts hardware features, execution parameter features, and feasibility features related to hardware resources, execution capabilities, and operating conditions, focusing on core hardware execution information; the three branches work in parallel and independently extract core features of their respective dimensions.

[0112] Furthermore, the specific steps of S3.1 include: loading the trained text classification model, reading three layers of valid context data, extracting clean requirement context data, compliance constraint context data, and valid execution context data respectively, inputting the clean requirement context data into the requirement feature extraction branch, the compliance constraint context data into the constraint feature extraction branch, and the valid execution context data into the execution feature extraction branch; each branch performs feature extraction, feature filtering, and feature fusion on the input data, and outputs the core feature vector of the corresponding dimension; the output layer receives the core feature vectors output by each branch and performs label matching on the feature vectors of the three dimensions respectively; finally, it outputs the first-level requirement label corresponding to the clean requirement context data, the second-level constraint label corresponding to the compliance constraint context data, and the third-level execution label corresponding to the valid execution context data.

[0113] For example, in this embodiment, after the pure demand context data input demand feature extraction branch, the first-level demand labels predicted by the model include: urban road scenario, constant speed driving, smooth driving, routine data processing, real-time status monitoring, control logic generation, basic interactive functions, low-latency response, stable operation, and minor fault recovery, etc.; after the compliance constraint context data input constraint feature extraction branch, the second-level constraint labels predicted by the model include: AEC-Q100 automotive compliance, ISO 26262 functional safety, data acquisition authorization compliance, encrypted data transmission, privacy data protection, electrical interface security, data tampering prevention, low power consumption compliance, and anomaly security protection, etc.; after the effective execution context data input execution feature extraction branch, the third-level execution labels predicted by the model include: standard processor computing power, routine memory configuration, standard storage capacity, general hardware interface, vehicle bus adaptation, low power operation, basic environmental perception, routine data accuracy, medium concurrency processing, and hardware compatibility adaptation, etc.; the three-level labels accurately summarize the core requirements, compliance constraints, and hardware execution parameters of the vehicle components in the current vehicle scenario.

[0114] S3.2: Fill the first-level requirement label, the second-level constraint label, and the third-level execution label into the preset label structure according to their level to generate a hierarchical vehicle label.

[0115] Furthermore, the preset tag structure is a standardized structured template designed for hierarchical vehicle tags. The structure adopts a hierarchical organizational structure, divided into three levels from top to bottom, corresponding to the first level of requirement tags, the second level of constraint tags, and the third level of execution tags. The hierarchical order strictly follows the logical priority of requirement-constraint-execution, with requirement tags as the top-level core, constraint tags as the middle-level restrictions, and execution tags as the bottom-level implementation. Each level area in the structure reserves a fixed number of tag filling positions, supporting the orderly arrangement of multiple tags. It also includes auxiliary information such as tag priority identifiers, tag confidence fields, and tag type fields to ensure that the filled hierarchical vehicle tag structure is standardized, hierarchical, and information-complete.

[0116] Based on the hierarchical vehicle-mounted tags, scene-adaptive prompt words are assembled to generate standardized vehicle-mounted prompt words, including:

[0117] S3.3: Based on the first-level demand tag in the hierarchical vehicle tag, query the preset scenario template library to obtain the basic prompt word structure that matches the current vehicle scenario; the basic prompt word structure contains at least one field to be constrained and at least one field to be executed.

[0118] Furthermore, the preset scenario template library is a standardized template database built on a large number of in-vehicle scenario types, demand tag combinations, and prompt word structure samples. The standardized template database is classified and stored according to in-vehicle scenario type and first-level demand tag combinations. Each scenario category corresponds to multiple basic prompt word structures that adapt to different demand priorities and different functional focuses.

[0119] In this embodiment, the core of the first-level requirement label of the hierarchical vehicle tag is urban road, constant speed driving, smooth driving, routine data processing, real-time monitoring, and stable operation. After querying the scenario template library based on this, the basic prompt word structure obtained by matching is: "Please generate a vehicle component that is compatible with [A], which must meet the compliance requirements of [B], achieve [C], and the operating performance must meet the hardware conditions of [D], ensuring that the component is AEC-Q100 automotive grade compliant, hardware compatible, stable and reliable, and functionally compliant". This basic prompt word structure contains one field to be constrained (B) and one field to be executed (D), while reserving fields such as scenario A and required function C. The structure is simple, the logic is clear, the field reservation is reasonable, and it is compatible with the current vehicle scenario requirements.

[0120] S3.4: Fill the tag value of the second-level constraint tag into the field to be constrained in the basic prompt word structure to generate a constrained prompt word intermediate;

[0121] Furthermore, the specific process of filling the tag values ​​of the second-level constraint tags into the fields to be constrained in the basic prompt word structure includes: first, parsing the fields to be constrained in the basic prompt word structure to clarify the filling position, format requirements, tag quantity limits, and semantic connection rules of the fields; then, extracting the second-level constraint tags from the hierarchical vehicle tags and filtering out the core constraint tag values ​​that are strongly related to the current vehicle scenario and have high priority; next, filling the filtered constraint tag values ​​into the fields to be constrained in an orderly manner, with standard delimiters connecting the constraint tag values ​​to ensure that the text is semantically fluent, grammatically correct, and clearly defines the constraint requirements after filling; during the filling process, the field format is automatically adapted and the tag description is adjusted to ensure that it is naturally connected with the context of the basic prompt word structure; finally, after the filling is completed, the basic prompt word structure incorporates compliance constraint information, generating a prompt word intermediate with constraints, clarifying the compliance constraint requirements that the generation of vehicle components must comply with, making the prompt word information more complete and the constraints more explicit.

[0122] In this embodiment, the field to be constrained in the basic prompt word structure is located at "must meet [B] compliance requirements"; the core tag values ​​in the second-level constraint tags are extracted: AEC-Q100 automotive compliance, ISO 26262 functional safety, data acquisition authorization compliance, encrypted data transmission, privacy data protection, electrical interface safety, and low power consumption compliance; after these tag values ​​are filled into the field to be constrained in an orderly manner, the generated prompt word intermediate is: "Please generate an on-board component that is compatible with [A], which must meet the compliance requirements of AEC-Q100 automotive compliance, ISO 26262 functional safety, data acquisition authorization compliance, encrypted data transmission, privacy data protection, electrical interface safety, and low power consumption compliance, achieve [C], and the operating performance must meet the hardware conditions of [D], ensuring that the component is AEC-Q100 automotive compliance, hardware compatibility, stable and reliable, and functionally compliant"; this intermediate has clearly defined the compliance constraint requirements, and the prompt word information is further improved.

[0123] S3.5: Fill the tag value of the third-level execution tag into the parameter field to be executed in the constrained prompt word intermediate to generate a standardized vehicle prompt word.

[0124] Furthermore, the specific process of filling the tag values ​​of the third-level execution tags into the field of the parameter to be executed in the constrained prompt word intermediate includes: first, parsing the field of the parameter to be executed in the constrained prompt word intermediate to clarify the field filling position, format requirements, parameter expression specifications, and semantic connection rules; then, extracting the third-level execution tags from the hierarchical vehicle tags, selecting core execution tag values ​​that are strongly related to the current hardware environment and component execution capabilities and have high priority, and eliminating secondary and irrelevant execution tags; next, according to the principles of technical expression specifications and semantic fluency and coherence, orderly filling the selected execution tag values ​​into the field of the parameter to be executed, with standard separators connecting the tag values, adjusting the expression method to make it naturally connected with the context, ensuring that the prompt word text is logically clear, the technical parameters are clear, and there is no ambiguity after filling; during the filling process, the parameter expression is automatically optimized to avoid redundancy and repetition, ensuring that the prompt word is concise and accurate; finally, after the filling is completed, the prompt word intermediate integrates hardware execution parameter information to generate standardized vehicle prompt words. The standardized vehicle prompt words completely include scenario information, requirement information, compliance constraint information, and hardware execution parameter information, with standardized structure, clear semantics, and clear instructions.

[0125] In this embodiment, the parameter field to be executed in the prompt word intermediate is located at "Running performance must meet [D] hardware conditions"; the core tag values ​​in the third-level execution tag are extracted: standard processor computing power, conventional memory configuration, general hardware interface, vehicle bus adaptation, low power operation, basic environmental perception, and conventional data accuracy; after these tag values ​​are filled into the parameter field to be executed in an orderly manner, the generated standardized vehicle prompt word is: "Please generate vehicle components adapted to the uniform speed driving and smooth driving scenarios on urban roads, which must meet the compliance requirements of AEC-Q100 automotive grade compliance, ISO 26262 functional safety, data acquisition authorization compliance, data encryption transmission, privacy data protection, electrical interface safety, and low power compliance, and realize conventional data processing, real-time status monitoring, control logic generation, and basic interactive functions. The running performance must meet the hardware conditions of standard processor computing power, conventional memory configuration, general hardware interface, vehicle bus adaptation, low power operation, basic environmental perception, and conventional data accuracy, to ensure that the component is AEC-Q100 automotive grade compliant, hardware adapted, stable and reliable, and functionally compliant."

[0126] The specific steps of S4 include:

[0127] S4.1: Input the standardized vehicle prompt words and the three layers of effective context data into the pre-trained self-healing network model. At the same time, parse the initial vehicle component task instructions into the initial vehicle component to be optimized, and use the initial vehicle component to be optimized as the target operation object of the self-healing network model.

[0128] Furthermore, the construction and training process of the self-healing network model includes:

[0129] (1) Select a large number of vehicle component operation records, automotive standard clauses, hardware interface parameters and component defect cases under different vehicle scenarios, and summarize them to form a basic dataset for model construction. The total amount of data is set to 150,000 records, which includes normal component operation data, various automotive non-compliant data, hardware mismatch data and component repair success case data, to ensure that the data covers various vehicle working conditions and component abnormality types.

[0130] (2) Divide the 150,000 basic data into model building training data and model verification test data in an 8:2 ratio. The training data is used for the model to learn the repair rules, and the verification test data is used to check the accuracy of model recognition and repair.

[0131] (3) Set the core parameters for model construction. The model adopts deep nonlinear fitting logic. The initial learning rate is set to 0.005, the learning rate decay coefficient is set to 0.98, the number of training rounds is set to 60, the batch size of data processed in each training round is set to 16, and the model convergence judgment threshold is set to 0.001.

[0132] (4) Based on the operating logic of vehicle components, automotive-grade constraints, and hardware adaptation rules, establish the internal data conversion and association mapping logic of the model so that the model can automatically associate the input vehicle prompt information, context data, and component status information and identify the logical errors, resource configuration deviations, and compliance defects of the components, forming a basic identification and repair logic framework.

[0133] (5) Input the training data into the model in batches. The model learns the component defect features, automotive-grade constraints, hardware adaptation requirements and corresponding repair methods in the data repeatedly. It gradually establishes defect identification rules, compliance verification rules, hardware matching logic and patch generation strategy, continuously optimizes the internal correlation mapping relationship, and improves the identification accuracy and repair effectiveness.

[0134] (6) After each round of training, the model's defect identification, compliance verification, hardware matching and patch generation capabilities are comprehensively tested using validation test data. If the identification accuracy and repair success rate do not meet the standards, training continues and the internal logic is optimized until the model performance reaches the preset standards. In this embodiment, the preset standards are: defect identification accuracy ≥ 98%, automotive compliance verification accuracy ≥ 97%, hardware matching identification accuracy ≥ 97%, and patch repair success rate ≥ 95%. All four indicators must be met simultaneously.

[0135] (7) After the model performance is stable and meets the standard, lock all internal correlation mapping relationships, parameter configurations and repair strategies, complete the model solidification, and obtain a pre-trained self-healing network model that can be directly used for vehicle component detection and repair.

[0136] Furthermore, the specific process of parsing the initial vehicle component task instructions into the initial vehicle component to be optimized includes: receiving the initial vehicle component task instructions, performing structured parsing on the initial vehicle component task instructions, and extracting core information such as component function definitions, logic flow sequences, performance requirements, interface definitions, and resource configurations from the initial vehicle component task instructions; then, in accordance with the vehicle component development specifications, converting the parsed instruction information into an executable, detectable, and repairable initial vehicle component code framework and configuration file. The code framework includes the component's core logic nodes, functional modules, interface functions, resource call statements, etc., and the configuration file defines the component's hardware resource usage, interface parameters, and running parameters, etc.

[0137] S4.2: The self-healing network model uses the standardized in-vehicle prompt words as the repair target guidance vector and the three-layer effective context data as the repair constraint basis matrix. Based on the repair target guidance vector and the repair constraint basis matrix, it performs layer-by-layer traversal detection on the internal logic nodes of the initial in-vehicle component to be optimized, identifies logic nodes that do not conform to automotive standards as logic nodes to be repaired, and identifies resource configuration nodes that do not match the in-vehicle hardware abstraction layer interface definition file as resource nodes to be adjusted.

[0138] Furthermore, the specific steps in S4.2 include:

[0139] (1) When the self-healing network model is running, it reads the repair target guidance information converted from the standardized vehicle prompt words, and at the same time reads the repair constraint basis information obtained by organizing the three layers of effective context data. The repair target guidance information clarifies the compliance goals and functional requirements that the component repair needs to achieve, and the repair constraint basis information includes all constraint contents such as automotive standards, hardware parameters, and execution conditions.

[0140] (2) The repair target guidance information is processed according to the vehicle semantic mapping logic built into the self-healing network model. The vehicle semantic mapping logic is a fixed conversion logic that is pre-established based on the correspondence between vehicle prompt words and repair targets when the model is built. It is used to convert textual prompt information into a structured vector that the model can recognize, forming a repair target guidance vector. The dimension of the repair target guidance vector is set to 512, and each position corresponds to a repair target requirement. The repair constraint basis information is processed according to the vehicle constraint organization logic built into the self-healing network model. The vehicle constraint organization logic is a fixed organization logic that is pre-established based on the correspondence between three layers of effective context data and constraint conditions when the model is built. It is used to convert multi-dimensional context data into a structured matrix that the model can recognize, forming a repair constraint basis matrix. The number of rows and columns of the matrix is ​​set to 256×256, and each position corresponds to a constraint condition.

[0141] (3) The self-healing network model reads the initial vehicle components to be optimized, and determines the traversal order of all internal logical nodes and resource configuration nodes according to the execution flow order of the components. The logical nodes include execution links such as data processing, status judgment, instruction generation, and exception handling, and the resource configuration nodes include resource-related links such as memory allocation, processor call, interface initialization, and bus configuration.

[0142] (4) Visit the logical nodes one by one in the traversal order. The traversal step size is fixed at one logical node. The traversal order is advanced according to the execution order of the components. During the detection process, check the execution logic, judgment conditions and processing flow of each logical node against the automotive standard content in the repair constraint basis information to see if they comply with the regulations. The detection judgment threshold is set to 0.85. If the matching degree between the node logic and the automotive standard is less than 0.85, it is judged to be non-compliant with the automotive standard.

[0143] (5) During the traversal detection process, all logical nodes with a matching degree lower than 0.85 are identified and recorded one by one, marked as logical nodes to be repaired, and detailed information such as node location, logical type, and violation clause are recorded.

[0144] (6) After completing the logical node traversal, access the resource configuration nodes one by one in the same traversal order. The traversal step size is kept to be one resource configuration node. During the detection process, check the parameter settings, interface format, and resource occupation of each resource configuration node against the content of the vehicle hardware abstraction layer interface definition file in the repair constraint basis information. The interface matching judgment threshold is set to 0.9. If the matching degree between the node configuration and the interface definition is less than 0.9, it is judged as a mismatch.

[0145] (7) During the traversal detection process, all resource configuration nodes with a matching degree lower than 0.9 are identified and recorded one by one, marked as resource nodes to be adjusted, and detailed information such as node location, resource type, and mismatch parameters are recorded.

[0146] (8) After all the traversal and detection are completed, summarize all the logic nodes to be repaired and the resource nodes to be adjusted to form a complete defect identification result.

[0147] S4.3: Generate a corresponding logic correction patch for the identified logic node to be repaired, generate a corresponding resource remapping patch for the identified resource node to be adjusted, merge the logic correction patch and the resource remapping patch into a comprehensive repair patch, and embed the comprehensive repair patch into the initial vehicle component to be optimized to generate the first optimized component;

[0148] Furthermore, the specific process of generating corresponding logical correction patches for the identified logical nodes to be repaired includes:

[0149] (1) The self-healing network model reads the relevant data of the logical node to be repaired, including the node location information, error type information, violation standard information and operation impact range information of the logical node to be repaired;

[0150] (2) Call the repair target guidance vector and repair constraint basis matrix obtained from the previous data processing;

[0151] (3) Call the pre-trained self-healing network model to perform the repair strategy matching operation. During the self-healing network model operation phase, take the obtained information of the logic node to be repaired and the loaded repair constraint data as input, match and call the same type of error repair strategy and logic optimization method that are consistent with the current logic error type, and complete the design work of the targeted logic correction scheme.

[0152] (4) Based on the generated logic correction scheme, strictly follow the unified vehicle component code specification and vehicle component logic writing standard, and generate standardized correction content in batches. Specifically, it includes the deletion code of the original erroneous logic, the addition code of the compliant correction logic, the optimization code of the logic judgment condition, the supplementary code of the operation exception handling, and the improvement code of the operation data verification.

[0153] (5) According to the inherent code format of the initial vehicle component, the generated correction code content is uniformly adapted and integrated to generate a standardized logic correction patch that is fully compatible with the code format of the initial vehicle component. This logic correction patch can be directly embedded into the node position corresponding to the logic node to be repaired, and complete the accurate replacement and correction of the erroneous logic of the initial vehicle component.

[0154] (6) After the logic node is corrected by embedding a logic correction patch, the corrected logic node fully meets the requirements of automotive standards, ensuring that the operating logic of the vehicle components is rigorous and standardized.

[0155] Furthermore, the specific process of generating corresponding resource remapping patches for the identified resource nodes to be adjusted includes:

[0156] (1) Read the relevant data of the resource node to be adjusted. The data includes the node location information, hardware mismatch project information, hardware standard parameter information, node current configuration information and corresponding affected hardware device information of the resource node to be adjusted.

[0157] (2) The repair target guidance vector and the repair constraint basis matrix obtained by calling the self-healing network model;

[0158] (3) Call the pre-trained self-healing network model to perform resource adaptation scheme matching operation. During the self-healing network model operation phase, take the obtained information of the resource nodes to be adjusted and the loaded hardware adaptation constraint data as input, match and call the resource remapping strategy that is consistent with the current hardware mismatch type, and complete the design of the targeted resource remapping scheme.

[0159] (4) Based on the generated resource remapping scheme, and in combination with the standard configuration requirements of the vehicle hardware abstraction layer interface definition file, the core configuration content of the resource node to be adjusted is adjusted in a targeted manner. The resource occupancy parameters, standardized interface call format and bus protocol adaptation configuration of the node are corrected in a key way to obtain the optimized resource configuration parameters. Ensure that all adjusted parameters comply with the vehicle hardware resource upper limit specification, the interface format matches the hardware general interface definition, and the communication protocol adapts to the vehicle hardware bus standard.

[0160] (5) Based on the optimized resource configuration parameters, strictly follow the unified vehicle component configuration file specification and component resource calling standard, and generate standardized resource correction content in batches, including memory parameter correction configuration, interface format conversion code, resource upper limit limit configuration, protocol adaptation update code and hardware call optimization code;

[0161] (6) In accordance with the inherent configuration file format and code writing format of the initial vehicle component, the generated standardized resource correction content is uniformly adapted and integrated to generate a standardized resource remapping patch that is fully compatible with the initial vehicle component. This resource remapping patch can be directly embedded into the node position corresponding to the resource node to be adjusted, so as to complete the precise adjustment of the resource configuration of the initial vehicle component.

[0162] (7) After the resource node adjustment is completed by embedding the resource remapping patch, the adjusted resource node fully conforms to the vehicle hardware abstraction layer interface definition specification, so as to realize reasonable and controllable component hardware resource occupation.

[0163] Furthermore, the specific process of merging the logic correction patch and the resource remapping patch into a comprehensive repair patch, and embedding the comprehensive repair patch into the initial vehicle component to be optimized to generate the first optimized component includes: receiving the logic correction patch and the resource remapping patch, firstly performing compatibility verification to check whether there are code conflicts, configuration conflicts, logic conflicts, etc. between the patches. If conflicts exist, adaptation adjustments are made to ensure that the patches can work together; then, according to the order of the patch embedding positions, the two patches are merged into a complete comprehensive repair patch, with the embedding position, function description, and effective logic marked inside the patch; next, the initial vehicle component to be optimized is read, and according to the embedding position marked by the comprehensive repair patch, the patch code and configuration information are accurately embedded into the corresponding logic node and resource node positions of the component, covering the original erroneous logic and unreasonable configuration; after the embedding is completed, the component code and configuration file are checked for syntax, format, and logical coherence to ensure that the component has no syntax errors, standard format, logical coherence, and complete functionality after the patch is embedded; finally, the first optimized component after preliminary repair and optimization is generated.

[0164] S4.4: Based on the preset automotive compliance test rule library, the first optimized component is checked item by item. The ratio of the number of code modules in the first optimized component that meet the automotive standards to the total number of code modules is calculated. The ratio is used as the AEC-Q100 automotive compliance rate. Based on the vehicle hardware abstraction layer interface definition file, the degree of matching of the first optimized component to each hardware interface is detected. The degree of matching is quantified as hardware adaptability.

[0165] Furthermore, the pre-set automotive compliance testing rule base is a standardized testing database built based on national automotive electronic equipment safety standards, the automotive industry ISO 26262 functional safety standard, and automotive data compliance standards. The rule base includes AEC-Q100 automotive compliance testing items, testing methods, judgment criteria, weight allocation, etc., covering the compliance testing requirements of all code modules, logic nodes, and functional units of automotive components. The rule base is weighted according to the importance of compliance, with core safety modules and data processing modules having higher weights and auxiliary function modules having lower weights, ensuring that the compliance rate statistics can objectively reflect the overall compliance level of the components.

[0166] Furthermore, the specific steps of S4.4 include:

[0167] (1) Read the first optimized component generated after logic patch repair and resource patch adjustment, and load the system's pre-built automotive compliance test rule library and vehicle hardware abstraction layer interface definition file. The automotive compliance test rule library is a complete set of rules pre-organized and solidified by the system according to automotive industry standards, which is used to provide the basis for component logic compliance verification. The vehicle hardware abstraction layer interface definition file is a hardware interface standard file pre-set by the system, which is used to provide the basis for component hardware interface matching verification.

[0168] (2) According to the code hierarchy classification standard of vehicle components, the overall code structure of the first optimized component is decomposed layer by layer to obtain all the independent code modules contained in the first optimized component. The number of all the decomposed code modules is counted to obtain the total number of code modules corresponding to the first optimized component.

[0169] (3) Call all the automotive compliance verification rules that are fixed in the automotive compliance test rule library, and perform compliance comparison verification on each code module obtained by splitting the first optimization component. The compliance verification algorithm used in this embodiment is fixed with a matching verification threshold of 0.93 during the construction stage to determine whether a single code module meets the automotive standard requirements.

[0170] (4) During the verification process, the actual number of all code modules that meet the automotive standard requirements is counted one by one. The ratio of the number of code modules that meet the automotive standard to the total number of code modules of the first optimization component is calculated to obtain the quantified automotive compliance rate. The automotive compliance rate is used to characterize the degree of automotive compliance of the first optimization component as a whole.

[0171] (5) Based on the standard interface parameters, calling format, communication protocol and resource adaptation requirements recorded in the vehicle hardware abstraction layer interface definition file, the hardware interface calling logic and resource configuration parameters inside the first optimization component are compared and detected one by one. The hardware matching detection algorithm used in this embodiment sets the interface matching judgment threshold to 0.95 in the construction stage to determine whether a single interface call matches the hardware standard definition.

[0172] (6) Based on the matching and verification results of all hardware interfaces, and taking into account the matching degree of all interfaces, uniformly quantify and generate the hardware adaptability corresponding to the first optimized component. The hardware adaptability is used to characterize the matching degree of the first optimized component and the standard interface system of the vehicle hardware abstraction layer, and complete the compliance and adaptability quantitative detection of the first optimized component.

[0173] S4.5: If the AEC-Q100 automotive compliance rate is greater than or equal to a preset compliance threshold and the hardware adaptability is greater than or equal to a preset adaptability threshold, then the current first optimized component is marked as a compliant component, and a valid component generation signal is generated based on the compliant component; the valid component generation signal includes key information such as component identifier, scenario information, compliance rate, adaptability, compliance status, and deployment instructions; in this embodiment, the compliance threshold is set to 0.95 or higher, and the adaptability threshold is also set to 0.95 or higher;

[0174] S4.6: If the AEC-Q100 automotive compliance rate is less than the compliance threshold or the hardware compatibility is less than the compatibility threshold, then the current first optimized component is used as the updated initial in-vehicle component to be optimized, and the step of inputting the standardized in-vehicle prompts and the three layers of effective context data into the pre-trained self-healing network model is re-executed for iterative optimization until the qualified component is generated.

[0175] Based on the effective component generation signal, a preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks, including:

[0176] S5.1: The effective component generation signal is sent as a trigger command to the task scheduling center embedded in the vehicle operating system. After receiving the effective component generation signal, the task scheduling center reads the binary executable file corresponding to the qualified component from the vehicle non-volatile memory, performs control flow analysis on the binary executable file, extracts the jump relationship and call relationship between the basic blocks in the qualified component, and organizes the jump relationship and the call relationship into the control flow graph of the qualified component according to the graph structure.

[0177] It should be noted that the task scheduling center embedded in the vehicle operating system is the core scheduling and management module of the vehicle system. It is responsible for receiving task triggering instructions, reading component files, performing control flow analysis, calling the splitting mechanism, allocating task resources, scheduling asynchronous operation, monitoring task status, and performing dynamic correction. It has the characteristics of high real-time performance, high reliability, high scheduling efficiency, and strong fault tolerance, and is adapted to the needs of multi-task parallel operation of the vehicle system.

[0178] Furthermore, the specific process by which the task scheduling center reads the binary executable file corresponding to the qualified component from the on-board non-volatile memory after receiving the valid component generation signal includes:

[0179] (1) The on-board system’s built-in task scheduling center continuously monitors the output status of the component optimization generation link and waits for the output of the effective component generation signal. When the effective component generation signal is generated, the task scheduling center captures and receives the effective component generation signal in real time.

[0180] (2) After receiving the valid component generation signal, the task scheduling center automatically calls the built-in storage accurate reading verification algorithm. The storage accurate reading verification algorithm completes the fixed parameter configuration during the construction phase. Among them, the storage address matching threshold is set to 0.92 and the data integrity verification coefficient is set to 0.95. The whole set of parameters are fixed configuration parameters for the vehicle storage reading scenario, which are used to ensure the accuracy and integrity of subsequent component file reading.

[0181] (3) Relying on the address matching logic of the storage read verification algorithm, the system retrieves the preset vehicle storage partition mapping relationship. The vehicle storage partition mapping relationship records the corresponding binding relationship between the qualified components and the vehicle non-volatile memory storage partition in advance. Combined with the output of the unique identifier information of the qualified components, the exclusive storage partition storing the data of the qualified components is accurately located.

[0182] (4) Based on the fixed parameters configured by the storage read verification algorithm, perform data validity verification on the dedicated storage partition that has been located. Determine the compliance of partition address matching according to the storage address matching threshold of 0.92. At the same time, verify the integrity of the stored data in the partition according to the data integrity verification coefficient of 0.95, and eliminate problems such as missing storage data, address offset and data abnormality.

[0183] (5) After the data validity verification is passed, the task scheduling center reads the binary executable file corresponding to the qualified component stored in the partition according to the accurately located storage partition path and the vehicle standard file reading protocol, and obtains the complete component execution file that can be directly used for loading and running in the vehicle system.

[0184] Furthermore, the specific process of performing control flow analysis on the binary executable file, extracting the jump relationships and call relationships between the basic blocks in the compliant component, and organizing the jump relationships and call relationships into a control flow graph of the compliant component according to a graph structure includes:

[0185] (1) Read the binary executable file corresponding to the qualified component and use the binary executable file as the sole input data source for this control flow analysis;

[0186] (2) Call the built-in binary control flow parsing algorithm. The binary control flow parsing algorithm has a fixed instruction parsing matching threshold of 0.94, a basic block partitioning confidence threshold of 0.90, and an association relationship identification weight coefficient of 0.70 during the construction phase. The above parameters are all fixed configuration parameters for the binary file analysis scenario of vehicle components, which are used to standardize the parsing accuracy and structural partitioning standards of binary instructions.

[0187] (3) Based on the fixed parameter standard of the binary control flow parsing algorithm, the loaded binary executable file is parsed line by line. According to the program execution logic and instruction jump rules, the continuous and uninterrupted set of execution instructions is divided into independent program basic blocks. All the basic blocks obtained together constitute the basic execution unit set of the qualified component. The division result of the basic blocks fully complies with the 0.90 basic block division confidence threshold judgment standard.

[0188] (4) Based on the instruction parsing and matching threshold of 0.94, the tail instructions and jump instructions of each independent basic block are identified one by one, the direct jump logic and branch jump logic between different basic blocks are sorted out, the corresponding association between the preceding basic block and the following basic block corresponding to each legal jump is fully recorded, and the jump relationship of all basic blocks inside the qualified component is summarized.

[0189] (5) Identify the weight coefficient based on the association relationship of 0.70, identify the function call and component interface call behavior contained in the binary instruction, sort out the function call hierarchy and interface call dependency between different basic blocks, clarify the source basic block that initiates the call and the target basic block that is called, and summarize the call relationship of all basic blocks inside the qualified component.

[0190] (6) Using all the basic blocks that have been divided as nodes of the graph structure, and the extracted basic block jump relationship and basic block call relationship as the basis for edge connection of the graph structure, according to the sequential logic and dependency logic of the program execution, all nodes and related relationships are organized in an overall structured manner, and finally a control flow graph that fully covers all execution logic of the qualified components is formed.

[0191] S5.2: The task scheduling center inputs the control flow graph to a preset multi-task splitting mechanism. The multi-task splitting mechanism traverses each basic block node in the control flow graph, identifies basic block nodes that do not contain any branch jump instructions as serial execution code blocks, and identifies basic block nodes that contain conditional branch instructions or parallel prefetch instructions as parallel execution code blocks.

[0192] Furthermore, the pre-defined multi-task splitting mechanism is an automated splitting algorithm designed based on the control flow characteristics of in-vehicle components, hardware parallel capabilities, and task dependencies. The core of the mechanism is to identify serially executed code blocks and parallelly executed code blocks. Serially executed code blocks have no branches, no dependencies, and are executed sequentially, requiring single-threaded serial operation; parallelly executed code blocks contain branches, have no strong dependencies, and can be executed independently, supporting multi-threaded parallel operation. The splitting mechanism features precise splitting, accurate dependency analysis, reasonable parallel granularity, adaptability to the number of hardware cores, and high splitting efficiency, which can maximize the multi-core parallel capabilities of the in-vehicle processor and improve component operating efficiency.

[0193] Furthermore, the specific steps in S5.2 include:

[0194] (1) The task scheduling center uses the control flow graph as input data and passes it to the multi-task splitting mechanism pre-deployed in the vehicle operating system, which is specifically used to analyze the control flow characteristics of vehicle components and identify the execution type of different basic block nodes;

[0195] (2) After receiving the control flow graph, the multi-task splitting mechanism first performs overall structure analysis on the control flow graph to determine the total number of all basic block nodes contained in the control flow graph and the jump relationship and call relationship between each basic block node. Each basic block node in the control flow graph represents a sequence of continuously executed instructions in the target component. There are no branch jumps inside the sequence of continuously executed instructions. All branch jump instructions only appear at the end of the basic block. The multi-task splitting mechanism assigns a unique node number to each basic block node according to the natural arrangement order of the basic blocks in the control flow graph. The number starts from the number 1 and increases sequentially until it covers all basic block nodes.

[0196] (3) The multi-task splitting mechanism starts from the entry basic block and visits each basic block node in sequence according to the natural flow of program execution. It will not skip any nodes or repeat the nodes that have already been processed. During the traversal, for the basic block node that is currently being visited, the multi-task splitting mechanism extracts one or more instructions at the end of the basic block and focuses on analyzing whether it contains branch jump instructions.

[0197] (4) For the basic block node currently being analyzed, the multi-task splitting mechanism performs instruction parsing and type determination operations. Specifically, the multi-task splitting mechanism has a built-in binary control flow parsing algorithm. During the construction phase, the binary control flow parsing algorithm sets the instruction parsing matching threshold to 0.94, the basic block partitioning confidence threshold to 0.90, and the association recognition weight coefficient to 0.70. When analyzing a basic block node, the multi-task splitting mechanism first checks the type of the last instruction at the end of the basic block. If the last instruction is not a jump instruction, or if the last instruction is an unconditional instruction... If a direct jump instruction points to the next sequential basic block, then the multitasking mechanism determines that the basic block does not contain any branch jump instructions, meaning that the basic block node is a purely serial execution code block. If the tail instruction is a conditional branch instruction, such as a conditional jump instruction, a comparison jump instruction, or a branch judgment instruction, or if the tail instruction contains instructions that support parallel execution, such as parallel prefetch instructions or multiplexed instructions, then the multitasking mechanism determines that the basic block node contains branch jump instructions or parallel prefetch instructions, and the basic block node is marked as a parallel execution code block.

[0198] (5) After the multi-task splitting mechanism completes the type determination of the current basic block node, it records the determination result in a temporary type mapping table. The type mapping table uses the node number as the primary key. Each row of records corresponds to a basic block node. The recorded content includes the node number, the node type mark, and the position information of the node in the control flow graph. The node type mark adopts a binary mark method, where 0 represents a serially executed code block and 1 represents a parallel executed code block. For basic block nodes that are determined to be parallel executed code blocks, the multi-task splitting mechanism will further record the branch instruction type or the specific type of the parallel prefetch instruction contained in the node.

[0199] (6) The multi-task splitting mechanism repeats (3)-(5) according to the traversal order of the control flow graph until all basic block nodes in the control flow graph are visited and the type determination is completed;

[0200] (7) After the multi-task splitting mechanism completes the type determination of all basic block nodes, it sorts all serial execution code blocks marked as 0 according to their original execution order in the control flow graph based on the records in the type mapping table, forming an ordered serial execution code block sequence; at the same time, it extracts all parallel execution code blocks marked as 1 separately to form a set of parallel execution code blocks to be grouped. Each parallel execution code block in the set of parallel execution code blocks is accompanied by its branch instruction type information and data dependency information.

[0201] S5.3: Encapsulate all identified serially executed code blocks into a first subtask according to their original execution order in the control flow graph; group all identified parallelly executed code blocks according to the data dependencies in the control flow graph; and generate a second subtask with an independent entry point for each group.

[0202] Furthermore, the specific steps in S5.3 include:

[0203] (1) After completing the traversal and identification of all basic block nodes in the control flow graph, all the identified serial execution code blocks are first summarized and organized. According to the original execution order in the control flow graph, each serial execution code block is read in sequence. The reading process strictly follows the traversal order set when the control flow graph is constructed.

[0204] (2) Verify each of the completed serial execution code blocks one by one, and check in turn whether there are branch jump instructions, cross-block data dependency conflicts, and execution order disorder in each serial execution code block; set two fixed judgment thresholds in the verification process: serial timing consistency threshold 0.90 and data dependency matching threshold 0.85. The serial timing consistency threshold is used to measure the degree of matching between the execution order of the code block and the standard timing of the original control flow graph. The data dependency matching threshold reuses the 0.85 dependency judgment standard used in the parallel execution code block grouping above; only when the timing matching degree of the serial execution code block is ≥0.90 and the data dependency matching degree is ≥0.85, and there are no abnormal situations, will it be included in the encapsulation scope of the first subtask. Code blocks that fail the verification are marked and excluded.

[0205] (3) According to the original execution order in the control flow diagram, all the serial execution code blocks that have passed the verification are sequentially spliced ​​and integrated. After splicing, a unique subtask identifier is assigned to the overall code block set. At the same time, a unified task entry address and task exit address are generated. Finally, all serial execution code blocks are encapsulated as an independent first subtask. The encapsulation process will not change the instruction content and execution logic inside any serial execution code block. Only the overall integration and identifier configuration are completed.

[0206] (4) After completing the encapsulation of the first subtask, all the identified parallel execution code blocks are uniformly summarized and classified. Each parallel execution code block is traversed, and the data read address, data write address, shared memory access identifier and external interface call information inside the code block are extracted. The data input source and data output destination of each parallel execution code block are completely sorted out, and the data dependency relationship type and the degree of dependency between different parallel execution code blocks are clarified.

[0207] (5) All parallel execution code blocks are grouped. The grouping process strictly follows the principle of minimum coupling of data dependencies. Parallel execution code blocks with direct data dependencies and a dependency tightness higher than the 0.85 judgment threshold are divided into the same group. Parallel execution code blocks without direct data dependencies or with a dependency tightness lower than the 0.85 judgment threshold are divided into different groups. During the grouping process, code blocks with strong dependencies will not be forcibly split, nor will code blocks without dependencies be merged arbitrarily. This ensures that the parallel execution code blocks in each group can maintain the integrity and correctness of data logic when running independently.

[0208] (6) Each group of parallel execution code blocks is independently encapsulated. The encapsulation process is as follows: First, the interface format, data transmission protocol and resource call parameters of all parallel execution code blocks in the group are checked for consistency. After the check is passed, each group is allocated an independent memory space and task scheduling resources. At the same time, a unique and independent task entry address is generated according to the address offset parameter of 1024 bytes to ensure that each group can be scheduled and run as an independent executable unit. Finally, each group of parallel execution code blocks is encapsulated into a second subtask with an independent entry point. All second subtasks are independent of each other and do not interfere with each other, and can support asynchronous concurrent execution.

[0209] S5.4: The multi-task splitting mechanism outputs the first subtask and each second subtask as the splitting result, resulting in multiple executable subtasks.

[0210] The executable subtask is deployed and executed asynchronously. During the asynchronous execution of the executable subtask, context state consistency data and functional adaptation data are collected in real time, including:

[0211] S5.5: Input multiple executable subtasks into the task scheduler of the vehicle operating system, calculate the priority weight of each executable subtask, and calculate the estimated resource consumption of each executable subtask based on the number of lines of code and the complexity of the loop structure contained in each executable subtask.

[0212] Furthermore, the specific steps of S5.5 include:

[0213] (1) The task scheduler of the vehicle operating system receives all the executable subtasks that have been generated and checks whether the task header information, code segment format, task identifier encoding and resource description field of each executable subtask conform to the vehicle operating system specifications. Only when they meet all the requirements will they be officially entered into the task queue of the task scheduler.

[0214] (2) The task scheduler performs basic information parsing on each executable subtask in the task queue to be processed, and sequentially reads the task type identifier, functional safety level, real-time level, associated vehicle component priority label and runtime sequence constraint information inside each executable subtask, and organizes the extracted attribute information into a structured set of subtask basic attributes.

[0215] (3) Extract the three core attributes of security level, real-time level and function priority from the basic attribute set of subtasks, and then calculate the weight score of each attribute according to the preset weight coefficient. Add the three scores to get the priority weight value of each executable subtask. The weight coefficient of security level is set to 0.45, the weight coefficient of real-time level is set to 0.35, and the weight coefficient of function priority is set to 0.20.

[0216] (4) After completing the priority weight calculation, scan the code segment content of each executable subtask line by line, filter out comments, blank lines and invalid instruction lines, and only count the number of code lines containing valid execution instructions. The statistical result is used as the first basic parameter of the estimated value of computing resource usage.

[0217] (5) Traverse the code logic structure of each executable subtask, identify all code blocks containing loop instructions, calculate the nesting depth and average number of iterations per run for each loop structure, calculate the complexity score of a single loop structure according to the preset weight coefficient, and sum the complexity scores of all loop structures in the same executable subtask to obtain the overall loop structure complexity value of the subtask. The nesting depth weight is set to 0.6, and the average number of iterations per run weight is set to 0.4.

[0218] (6) The number of lines of code of the effective execution instructions and the overall loop structure complexity value are weighted and summed according to the corresponding weight coefficients to obtain the estimated resource consumption value of each executable subtask, wherein the weight of the number of lines of code of the effective execution instructions is set to 0.55 and the weight of the overall loop structure complexity value is set to 0.45.

[0219] S5.6: Based on the calculated priority weights and estimated resource consumption of each executable subtask, each executable subtask is assigned to a preset asynchronous task execution queue in the vehicle operating system, and each executable subtask is triggered to be executed asynchronously and concurrently on the corresponding processor core. The asynchronous task execution queue arranges each executable subtask in descending order of priority weight.

[0220] Furthermore, the specific steps in S5.6 include:

[0221] (1) The task scheduler of the vehicle operating system first summarizes and organizes the priority weight values ​​and resource consumption estimates of all executable subtasks, and performs parameter integrity verification to obtain executable subtasks that pass the parameter verification.

[0222] (2) Read all executable subtasks that have passed parameter verification, sort them according to the priority weight values ​​of each executable subtask, and when there are multiple executable subtasks with the same priority weight values, perform auxiliary sorting according to the order of subtask generation time, and finally generate an ordered subtask sequence with priority from high to low.

[0223] (3) Read the asynchronous task execution queue information preset by the vehicle operating system, confirm whether the current remaining capacity of the queue can accommodate all the subtasks to be assigned, and then match and compare the executable subtasks in the ordered subtask sequence with the queue resource configuration information. When the estimated resource occupation of the executable subtask and the matching degree of the remaining resources of the queue reach the queue resource matching tolerance threshold of 0.8 or above, it is determined that the matching is successful. The matching subtasks will be moved into the asynchronous task execution queue until the queue reaches the capacity limit of 128 subtasks or all executable subtasks are assigned.

[0224] (4) Read the current load status and core function identification information of each core of the vehicle processor, and then calculate the load matching score and affinity matching score for each executable subtask in the asynchronous task execution queue. The load matching score ranges from 0 to 1 and is used to characterize the degree of adaptation between the resource occupation requirements of the subtask and the remaining load of the processor core. The calculation is based on the maximum safe load threshold of the processor core of 0.85. The adaptation difference is obtained by subtracting the estimated resource occupation value of the subtask from the remaining load of the processor core. When the difference is greater than 0, the difference is divided by 0.85 to obtain the load matching score. When the difference is less than or equal to 0, the load matching score is set to 0. Affinity The matching score ranges from 0 to 1 and is used to characterize the compatibility between the subtask's business function and the processor core's dedicated function positioning. It is assigned by looking up a pre-built function tag mapping table. If the subtask's function tag and the core function identifier match completely, the score is 1; if they match partially within the same category, the score is 0.5; and if they are completely unrelated in the business domain, the score is 0. The load matching score corresponding to the estimated resource consumption of the executable subtask is multiplied by a preset load balancing weight of 0.7, and then the affinity matching score corresponding to the executable subtask's function attribute is multiplied by a preset affinity matching weight of 0.3. The optimal processor core corresponding to each subtask is determined based on the sum obtained.

[0225] (5) According to the order of the asynchronous task execution queue, send the execution trigger instruction to the optimal processor core corresponding to each executable subtask in turn. When sending the instruction, strictly follow the 10-millisecond task trigger delay parameter to avoid signal conflict caused by multiple instructions being sent at the same time. After receiving the trigger instruction, the optimal processor core starts the asynchronous concurrent execution process of the corresponding executable subtask according to the 5-millisecond core task scheduling interval parameter to ensure that all subtasks can run independently on their respective allocated processor cores without interfering with each other.

[0226] (6) After triggering the asynchronous execution of all subtasks, the task scheduler reads the running status information of each subtask in the asynchronous task execution queue every 20 milliseconds, and synchronously updates the order of subtasks and associated resource occupancy information in the queue to ensure that the asynchronous task execution queue always maintains the priority from high to low, while ensuring the stability of the mapping relationship between the processor core and the subtasks.

[0227] S5.7: During the asynchronous concurrent execution of each executable subtask, the preset resource monitoring probe in the vehicle operating system is started. The resource monitoring probe collects the actual occupancy rate of the target hardware resources during the execution of each executable subtask in real time. The actual occupancy rate is compared with the expected occupancy rate in the vehicle hardware abstraction layer interface definition file to generate functional adaptation data.

[0228] Furthermore, the specific steps in S5.7 include:

[0229] (1) When all executable subtasks begin asynchronous concurrent execution on the corresponding processor cores, the vehicle operating system triggers the initialization verification of the preset resource monitoring probe. The verification process verifies the physical connection status between the probe and the bus interface of the vehicle processor memory controller and the storage controller one by one, and at the same time confirms that the data acquisition channel is unblocked and without abnormalities. Only when both verification indicators meet the standards can the resource monitoring probe complete the initialization and enter the ready state to execute the data acquisition task.

[0230] (2) After the resource monitoring probe enters the ready state, it loads the vehicle hardware abstraction layer interface definition file, extracts the expected utilization rate values ​​of the four target hardware resources, namely processor core utilization rate, memory utilization rate, bus bandwidth utilization rate and peripheral interface utilization rate, one by one from the vehicle hardware abstraction layer interface definition file, organizes the extracted expected utilization rate data into a structured set of benchmark parameters, and stores it in the internal cache area of ​​the probe.

[0231] (3) Collect real-time data on the processor core, memory, bus bandwidth and peripheral interface usage of each executable subtask that is being executed asynchronously and concurrently at a time interval of 10 milliseconds.

[0232] (4) The collected real-time occupancy data is converted into units according to a unified conversion factor, and then the values ​​are normalized according to the preset precision retention digits. Finally, the original data is converted into a standardized actual occupancy rate value. The unified conversion factor for data units is set to 100, and the precision retention digits parameter for occupancy rate calculation is set to two digits.

[0233] (5) Read the expected occupancy rate values ​​of each item in the reference parameter set from the internal cache area, and compare them one by one with the actual occupancy rate values ​​of the corresponding items after conversion. The comparison process allows for an error tolerance range of no more than 0.01. Record the difference data between the actual occupancy rate and the expected occupancy rate of the four resources: processor core, memory, bus bandwidth and peripheral interface.

[0234] (6) The four hardware resource difference data recorded during the comparison process are structured and integrated according to the vehicle adaptation format, and the sub-task identifier collection timestamp and resource type information are supplemented to generate complete functional adaptation data. Then, the functional adaptation data is stored in a temporary cache area of ​​512kbit for the vehicle operating system to read and analyze.

[0235] S5.8: During the asynchronous concurrent execution of each executable subtask, a pre-set periodic polling monitoring service in the vehicle operating system is started. The periodic polling monitoring service captures the current input data and current output data of each executable subtask in real time. In this embodiment, the polling period is set to 5 milliseconds.

[0236] S5.9: Compare the current input data with the predefined subtask standard input data in the effective execution context data within the three-layer effective context data field by field. If the field values ​​are the same, generate a first consistency flag and mark it as true. If the field values ​​are different, generate a first consistency flag and mark it as false. Summarize the first consistency flags of all fields to obtain the first consistency flag set.

[0237] Furthermore, the specific steps in S5.9 include:

[0238] (1) After the periodic polling listening service completes the capture and temporary storage of the current input data, the vehicle operating system reads the predefined subtask standard input data from the valid execution context data within the three-layer valid context data in the internal fixed storage area;

[0239] (2) The current input data and the subtask standard input data are split into fields respectively. The splitting process is based on the field boundaries defined by the data, and the data type and field identifier of each field are identified. Finally, the two sets of data are decomposed into field sequences with completely corresponding structures.

[0240] (3) Based on the field identifier and field order, match the field sequence after the current input data is decomposed with the field sequence after the subtask standard input data is decomposed one by one to obtain the field correspondence after alignment and matching, so as to ensure that fields with the same meaning can be accurately aligned and avoid misalignment due to differences in field order;

[0241] (4) According to the field correspondence after alignment and matching, the field values ​​of the current input data are compared with the field values ​​of the subtask standard input data one by one. The comparison process is allowed to have an error range of no more than 0.0001. If the field values ​​are completely consistent within the error range, they are judged as field matching. If they exceed the error range, they are judged as field mismatch.

[0242] (5) Based on the judgment result of the field value comparison algorithm, generate a corresponding first consistency mark for each field that has been compared. When the field is judged to match, generate a first consistency mark marked as true. When the field is judged to not match, generate a first consistency mark marked as false. The generated marks are uniformly stored in the temporary mark cache area.

[0243] S5.10: Compare the current output data with the predefined subtask standard output data in the valid execution context data within the three-layer valid context data field by field. If the field values ​​are the same, a second consistency flag is generated and marked as true. If the field values ​​are different, a second consistency flag is generated and marked as false. The second consistency flags of all fields are summarized to obtain the second consistency flag set.

[0244] Furthermore, the specific steps of S5.10 include:

[0245] (1) After the periodic polling listening service completes the capture and temporary storage of the current output data, the vehicle operating system reads the predefined subtask standard output data from the valid execution context data within the three-layer valid context data in the internal storage area;

[0246] (2) Perform field splitting on the current output data and the standard output data of the subtask respectively. The splitting process is based on the field boundaries defined by the data, identifies the data type and field identifier of each field, and finally decomposes the two sets of data into field sequences with completely corresponding structures.

[0247] (3) Based on the field identifier and field order, match the field sequence after the current output data is decomposed with the field sequence after the subtask standard output data is decomposed one by one to ensure that the fields with the same meaning in the two sets of data can be accurately aligned and avoid misalignment due to differences in field order.

[0248] (4) According to the field correspondence after alignment and matching, compare the current output data field value with the subtask standard output data field value one by one. The comparison process is allowed to have an error range of no more than 0.0001. If the field value is completely consistent within the error range, it is determined to be a field match. If it exceeds the error range, it is determined to be a field mismatch.

[0249] (5) Based on the judgment result of the output field value comparison algorithm, generate a corresponding second consistency mark for each field that has been compared. When the field is judged to match, generate a second consistency mark marked as true. When the field is judged to not match, generate a second consistency mark marked as false. The generated marks are uniformly stored in the temporary mark cache area.

[0250] S5.11: Based on the unique identifier of the subtask and the data capture timestamp, the first consistency tag set and the second consistency tag set are matched one-to-one. The matched first consistency tag set and the second consistency tag set are then sequentially spliced ​​and integrated to obtain context state consistent data.

[0251] The asynchronous execution state of each executable subtask is dynamically adjusted based on the comparison results, by comparing it with the three layers of valid context data, including:

[0252] S5.12: Based on the first consistency marker and the second consistency marker, locate the mismatch subtask corresponding to the marker being false;

[0253] Furthermore, the specific process of locating the mismatched subtasks corresponding to the false flags includes: receiving context state consistency data, traversing all first consistency flags and second consistency flags in the context state consistency data, and checking the flag values ​​one by one; filtering out all abnormal flags with false flag values, and extracting the subtask identifier, abnormal type, and abnormal location corresponding to each abnormal flag; summarizing all subtasks containing abnormal flags, removing duplicate subtask identifiers, and finally accurately locating all mismatched subtasks with inconsistent input and output data and mismatched context states.

[0254] S5.13: Invoke the preset rollback recovery mechanism to suspend the execution of the mismatch subtask, and retrieve the initial configuration snapshot of the three-layer valid context data corresponding to the mismatch subtask from the preset checkpoint storage area;

[0255] Furthermore, the specific steps in S5.13 include:

[0256] (1) After the vehicle operating system locates the mismatched subtask marked as false based on the context state consistency data, it confirms that the abnormal level of the mismatched subtask has reached the rollback triggering standard, and verifies that the current operation has legal rollback execution permission. After both verifications are passed, the rollback recovery mechanism enters the activated ready state.

[0257] (2) After the rollback recovery mechanism enters the ready state, it first sends a pause execution instruction to the processor core corresponding to the mismatched subtask. After the pause execution instruction is sent, it waits for 5 milliseconds to ensure that the instruction is delivered and effective. Then, it completely saves the current running state of the mismatched subtask, including register state, program counter value, temporary variable data and resource usage information. The state saving process strictly follows the integrity threshold requirement of 0.95 to ensure that the running state of the task is not lost or disordered when it is paused.

[0258] (3) After completing the mismatch subtask pause and site protection, verify that the access permission is the highest level, accurately locate the physical storage path of the checkpoint storage area, confirm that there is no read / write lock or access blockage in the storage area, and establish a stable data reading channel.

[0259] (4) Extract the unique identifier information and initial running timestamp of the mismatched subtask, perform weighted matching calculation according to the subtask identifier matching weight of 0.8 and the timing matching weight of 0.2, and retrieve the initial configuration snapshot of the three-layer valid context data that is completely corresponding to the current mismatched subtask from the checkpoint storage area;

[0260] (5) Perform integrity verification and format parsing on the retrieved initial configuration snapshot. The verification process confirms that the snapshot data is complete and undamaged and that the format conforms to the three-layer valid context data definition specification. Then, fully read the clean requirement context data, compliance constraint context data and valid execution context data contained in the snapshot to complete the snapshot data retrieval work.

[0261] (6) Store the retrieved three-layer valid context data initial configuration snapshot into a temporary cache area with a specified capacity of 1024kbit to ensure that the snapshot data remains complete and available within a 30-second validity period, thus completing the entire process of this rollback pause and snapshot retrieval.

[0262] S5.14: Based on the initial configuration snapshot, reset the input port configuration and output port configuration of the mismatched subtask, generate a port reset instruction, and restore the operation of the mismatched subtask based on the port reset instruction, while marking the operation status of the mismatched subtask as corrected.

[0263] Furthermore, the specific steps in S5.14 include:

[0264] (1) After the rollback recovery mechanism retrieves the initial configuration snapshot of the three-layer valid context data and stores it in the temporary cache area, it accurately extracts the input port configuration parameters and output port configuration parameters corresponding to the mismatched subtask from the initial configuration snapshot, including port address, port data format, port transmission protocol, port buffer size and port permission identifier, and verifies that all configuration parameters are complete and in a standardized format, providing a baseline configuration basis for port reset;

[0265] (2) Compare the standard port configuration parameters in the initial configuration snapshot with the current port configuration parameters of the mismatched subtask item by item. The comparison process allows for an error range of no more than 0.0001. Accurately identify all configuration items that differ between the input and output ports and form a list of port difference configurations.

[0266] (3) Based on the port difference configuration list, and taking the standard port configuration parameters in the initial configuration snapshot as the benchmark, the input port register and output port register of the mismatch subtask are written one by one. The reset process is executed with the highest priority. Each parameter is verified after being written to ensure that the writing result is completely consistent with the standard configuration, and the configuration reset of the input port and output port is completed.

[0267] (4) Integrate the port reset completion status information, the unique identifier of the mismatch subtask, the port configuration reset item list and the instruction execution permission information, perform structured encoding according to the vehicle control instruction standard format, and generate instruction check codes based on a generation coefficient of 0.95 to generate complete and valid port reset instructions.

[0268] (5) Send the generated port reset command to the processor core corresponding to the mismatched subtask, wait 3 milliseconds to ensure that the command takes effect, then retrieve the running environment data saved when the task is paused, and restore the register state, program counter value, temporary variable data and resource usage information in full according to the integrity threshold requirement of 0.95, and complete the preparation for the restoration of the task running environment.

[0269] (6) Send a task restart execution instruction to the processor core to trigger the mismatched subtask to continue asynchronous concurrent execution from the paused position. At the same time, in accordance with the vehicle task status coding standard, update the running status of the mismatched subtask and mark it as corrected. The marking information is synchronously stored in the vehicle operating system task status management table, completing the entire process of port reset instruction execution, task resumption and status marking.

[0270] S5.15: When the actual occupancy rate deviates from the expected occupancy rate and the deviation exceeds the preset deviation threshold based on the function adaptation data, the resource allocation ratio or execution priority of each executable subtask in the asynchronous task execution queue is adjusted.

[0271] Furthermore, the specific steps in S5.15 include:

[0272] (1) After the vehicle operating system reads the function adaptation data generated by the resource monitoring probe, it extracts the actual occupancy rate and expected occupancy rate of each executable subtask from the function adaptation data, calculates the absolute value of the difference between the actual occupancy rate and the expected occupancy rate as the deviation range, and determines the deviation direction based on the positive or negative value of the difference. When determining the deviation direction, an error range of no more than 0.0001 is allowed.

[0273] (2) Compare the calculated deviation of each subtask with the preset deviation threshold of 0.1. If the deviation is greater than 0.1, it is determined that the resource occupancy is abnormal. Based on the confidence threshold of 0.95 for the collected data, the validity of the judgment result is verified. Only when the confidence of the data collected by the resource monitoring probe is not less than 0.95, the judgment result is valid and recorded in the list of abnormal resource occupancy. If the confidence of the data is less than 0.95, the comparison result is discarded and the hardware occupancy data is collected again for comparison. If the deviation is less than or equal to 0.1, it is determined that the resource occupancy is normal.

[0274] (3) Based on the deviation direction, abnormal subtasks are divided into resource over-limit and resource under-limit categories. Resource over-limit refers to the actual occupancy rate being higher than the expected occupancy rate, and resource under-limit refers to the actual occupancy rate being lower than the expected occupancy rate. At the same time, the classification and marking are completed in combination with the subtask priority attributes to clarify the adjustment direction of different abnormal types.

[0275] (4) For sub-tasks with excessive resources, the resource allocation ratio shall be gradually reduced in a fixed step of 5%, ensuring that the allocation ratio is not lower than 10% during the reduction process; for sub-tasks with insufficient resources, the resource allocation ratio shall be gradually increased in a fixed step of 5%, ensuring that the allocation ratio is not higher than 80% during the increase process.

[0276] (5) For severely abnormal subtasks with a deviation exceeding 0.15, the priority is directly increased or decreased by one level; for general abnormal subtasks with a deviation between 0.1 and 0.15, the priority adjustment is calculated using 0.3 as the resource deviation correlation weight coefficient to achieve smooth fine-tuning. The priority adjustment is equal to the resource deviation multiplied by 0.3. A small adjustment mode is adopted to avoid large changes in priority; the priority adjustment process strictly follows the three-level gradient rule to avoid scheduling chaos caused by priority jumps.

[0277] (6) Update the adjusted resource allocation ratio and execution priority to the asynchronous task execution queue. Rearrange the subtasks in the queue in order of priority from high to low. After the update is completed, wait two milliseconds to ensure that the configuration takes effect. At the same time, check the matching consistency between the queue local storage parameters and the processor underlying scheduling configuration. Use 0.98 as the consistency check threshold. Only when the overall matching consistency is not lower than 0.98 is the configuration synchronization completed. Finally, the resource allocation ratio or execution priority adjustment is completed.

[0278] Example 2:

[0279] Please see Figure 3 Another embodiment of the present invention provides: a context-filtered intelligent generation system for in-vehicle components, comprising:

[0280] The instruction generation module 10 is used to collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions. Based on the vehicle bus network and vehicle sensor group, it collects driving behavior, vehicle operating status and road environment parameters in real time to form multi-dimensional context data. Then, it extracts the requirement features through the component requirement mapping table, uses the time sequence matching algorithm to map it into a component logic flow sequence and encapsulates it into initial vehicle component task instructions.

[0281] The three-layer progressive filtering module 20 is used to perform three-layer progressive filtering on multi-dimensional context data and output three layers of effective context data. First, it filters abnormal and redundant data to generate the first intermediate filtered data. Then, it uses the principal component analysis algorithm to reduce the relevance and obtain pure demand context data. Next, it queries the vehicle compliance rule library to integrate compliance constraint context data. Finally, it obtains effective execution context data through hardware feasibility verification, thereby realizing data purification, compliance constraint and hardware adaptation screening.

[0282] The prompt word assembly module 30 is used to generate standardized vehicle prompt words. It predicts hierarchical vehicle labels from three layers of effective context data through a pre-trained text classification model. Then, it queries the scenario template library based on the hierarchical vehicle labels to obtain the basic prompt word structure. It then fills in the constraint labels and execution labels in sequence to generate standardized vehicle prompt words, providing a target guide for component optimization.

[0283] The multi-layer self-healing optimization module 40 is used to iteratively optimize the initial vehicle components until they meet the standards. It inputs standardized vehicle prompt words and three layers of effective context data into the self-healing network model, traverses and detects the logic nodes to be repaired and the resource nodes to be adjusted, generates and embeds a comprehensive repair patch to obtain the first optimized component, and achieves iterative optimization through vehicle compliance rate and hardware compatibility verification, outputting the compliant component and effective component generation signal.

[0284] The asynchronous scheduling correction module 50 is used to decompose compliant components and dynamically correct the running status of executable subtasks. After receiving the signal generated by the valid components, it analyzes the binary executable file to generate a control flow graph, splits serial and parallel code blocks into executable subtasks, schedules the subtasks to run asynchronously, and collects context state consistency data and functional adaptation data in real time. By comparing the results, it locates mismatched subtasks and rolls them back and resets them. At the same time, it dynamically adjusts resource allocation and execution priority to ensure the stable and efficient operation of components.

[0285] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

Claims

1. A method for intelligent generation of in-vehicle components based on context filtering, characterized in that, include: S1: Collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions based on the multi-dimensional context data; S2: Based on the initial vehicle component task instruction, perform three-layer progressive filtering on the multi-dimensional context data and output three layers of valid context data accordingly. S3: Generate hierarchical vehicle tags based on the three layers of effective context data, and assemble scene adaptation prompt words based on the hierarchical vehicle tags to generate standardized vehicle prompt words; S4: Based on the standardized vehicle prompt words, and combined with the three layers of effective context data, perform multi-layer self-repair optimization on the initial vehicle components until the AEC-Q100 automotive compliance rate and hardware compatibility of the initial vehicle components meet the standards, and output an effective component generation signal. S5: Based on the signal generated by the effective component, a preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks. The executable sub-tasks are deployed and executed asynchronously. During the asynchronous operation of the executable sub-tasks, context state consistency data and function adaptation data are collected in real time and compared with the three-layer effective context data. The asynchronous operation execution state of each executable sub-task is dynamically corrected based on the comparison results.

2. The context-filtered in-vehicle component intelligent generation method of claim 1, wherein, The specific steps of S1 include: Real-time acquisition of driving behavior parameters, vehicle operating status parameters, and road environment parameters based on vehicle bus network and vehicle sensor group, and summarization of the driving behavior parameters, vehicle operating status parameters, and road environment parameters into multi-dimensional context data; Based on a preset component requirement mapping table, the multidimensional context data is used to extract requirement features to obtain the corresponding component functional requirement features and component performance requirement features. The component functional requirement features and component performance requirement features are mapped to a component logic flow sequence based on the time-series matching algorithm, and the component logic flow sequence is encapsulated into an initial vehicle component task instruction according to a preset instruction template.

3. The context-filtered in-vehicle component intelligent generation method of claim 2, wherein, The specific steps of S2 include: Based on the initial vehicle component task instructions, abnormal and redundant data in the multidimensional context data are filtered to generate first intermediate filtered data. Based on the principal component analysis algorithm, the first intermediate filtered data is subjected to decorrelation and dimensionality reduction to obtain pure demand context data; Based on the pure demand context data, query the preset vehicle compliance rule library, extract the safety compliance items and data privacy compliance items associated with the current scenario, and integrate the safety compliance items and the data privacy compliance items into compliance constraint context data; Based on the compliance constraint context data, hardware feasibility verification is performed on the pure demand context data, and feature data that does not match the current vehicle hardware resources is removed to obtain effective execution context data. The pure requirement context data, the compliance constraint context data, and the valid execution context data are concatenated to obtain three layers of valid context data.

4. The context-filtered in-vehicle component intelligent generation method of claim 3, wherein, Based on the three layers of valid context data, a hierarchical vehicle tag is generated, including: Based on a pre-trained text classification model, label prediction is performed on each layer of data in the three layers of effective context data to obtain the first-level requirement label corresponding to the pure requirement context data, the second-level constraint label corresponding to the compliance constraint context data, and the third-level execution label corresponding to the effective execution context data; the text classification model includes a requirement feature extraction branch, a constraint feature extraction branch, and an execution feature extraction branch. The first-level requirement label, the second-level constraint label, and the third-level execution label are filled into a preset label structure according to their level to generate hierarchical vehicle labels.

5. The context-filtered in-vehicle component intelligent generation method of claim 4, wherein, Based on the hierarchical vehicle-mounted tags, scene-adaptive prompt words are assembled to generate standardized vehicle-mounted prompt words, including: Based on the first-level demand tag in the hierarchical vehicle tag, a preset scenario template library is queried to obtain a basic prompt word structure that matches the current vehicle scenario; the basic prompt word structure contains at least one field to be constrained and at least one field to be executed. The label values ​​of the second-level constraint labels are filled into the field to be constrained in the basic prompt word structure to generate a prompt word intermediate with constraints. The tag value of the third-level execution tag is filled into the parameter field to be executed in the constrained prompt word intermediate to generate a standardized vehicle prompt word.

6. The context-filtered in-vehicle component intelligent generation method of claim 5, wherein, The specific steps of S4 include: The standardized in-vehicle prompts and the three layers of effective context data are input into the pre-trained self-healing network model. At the same time, the initial in-vehicle component task instructions are parsed into initial in-vehicle components to be optimized, and the initial in-vehicle components to be optimized are used as the target operation objects of the self-healing network model. The self-healing network model uses the standardized in-vehicle prompts as the repair target guidance vector and the three layers of effective context data as the repair constraint basis matrix. Based on the repair target guidance vector and the repair constraint basis matrix, it performs layer-by-layer traversal detection on the internal logic nodes of the initial in-vehicle component to be optimized, identifies logic nodes that do not conform to automotive standards as logic nodes to be repaired, and identifies resource configuration nodes that do not match the in-vehicle hardware abstraction layer interface definition file as resource nodes to be adjusted. For the identified logical nodes to be repaired, a corresponding logical correction patch is generated; for the identified resource nodes to be adjusted, a corresponding resource remapping patch is generated; the logical correction patch and the resource remapping patch are merged into a comprehensive repair patch; and the comprehensive repair patch is embedded into the initial vehicle component to be optimized to generate the first optimized component.

7. The context-filtered, in-vehicle component intelligent generation method of claim 6, wherein, The specific steps of S4 also include: The first optimized component is verified item by item based on a preset automotive compliance test rule library. The ratio of the number of code modules in the first optimized component that meet automotive standards to the total number of code modules is calculated. The ratio is used as the AEC-Q100 automotive compliance rate. The degree of matching of the first optimized component to each hardware interface is detected based on the in-vehicle hardware abstraction layer interface definition file. The degree of matching is quantified as hardware adaptability. If the AEC-Q100 automotive compliance rate is greater than or equal to a preset compliance threshold and the hardware compatibility is greater than or equal to a preset compatibility threshold, then the current first optimized component is marked as a compliant component, and a valid component generation signal is generated based on the compliant component. If the AEC-Q100 automotive compliance rate is less than the compliance threshold or the hardware compatibility is less than the compatibility threshold, then the current first optimized component is used as the updated initial in-vehicle component to be optimized, and the step of inputting the standardized in-vehicle prompts and the three layers of effective context data into the pre-trained self-healing network model is re-executed for iterative optimization until the qualified component is generated.

8. The context-filtered, in-vehicle component intelligent generation method of claim 7, wherein, Based on the effective component generation signal, a preset multi-task splitting mechanism is invoked to decompose the self-healing and optimized vehicle component into multiple executable sub-tasks, including: The effective component generation signal is sent as a trigger command to the task scheduling center embedded in the vehicle operating system. After receiving the effective component generation signal, the task scheduling center reads the binary executable file corresponding to the qualified component from the vehicle non-volatile memory, performs control flow analysis on the binary executable file, extracts the jump relationship and call relationship between the basic blocks in the qualified component, and organizes the jump relationship and the call relationship into the control flow graph of the qualified component according to the graph structure. The task scheduling center inputs the control flow graph to a preset multi-task splitting mechanism. The multi-task splitting mechanism traverses each basic block node in the control flow graph, identifies basic block nodes that do not contain any branch jump instructions as serial execution code blocks, and identifies basic block nodes that contain conditional branch instructions or parallel prefetch instructions as parallel execution code blocks. All identified serially executed code blocks are encapsulated into a first subtask according to their original execution order in the control flow graph. All identified parallel executed code blocks are grouped according to the data dependencies in the control flow graph, and a second subtask with an independent entry point is generated for each group. The multi-task splitting mechanism outputs the first subtask and each of the second subtasks as the splitting result, resulting in multiple executable subtasks.

9. The context-filtered in-vehicle component intelligent generation method of claim 8, wherein, The executable subtask is deployed and executed asynchronously. During the asynchronous execution of the executable subtask, context state consistency data and functional adaptation data are collected in real time, including: Multiple executable subtasks are input into the task scheduler of the vehicle operating system, the priority weight of each executable subtask is calculated, and the estimated resource consumption of each executable subtask is calculated based on the number of lines of code and the complexity of the loop structure contained in each executable subtask. Based on the calculated priority weights and estimated resource consumption of each executable subtask, each executable subtask is assigned to a pre-defined asynchronous task execution queue in the vehicle operating system, and each executable subtask is triggered to execute asynchronously and concurrently on the corresponding processor core. During the asynchronous concurrent execution of each executable subtask, a preset resource monitoring probe in the vehicle operating system is activated. The resource monitoring probe collects the actual occupancy rate of the target hardware resources during the execution of each executable subtask in real time. The actual occupancy rate is compared with the expected occupancy rate in the vehicle hardware abstraction layer interface definition file to generate functional adaptation data.

10. The context-filtered in-vehicle component intelligent generation method of claim 9, wherein, The executable subtask is deployed and executed asynchronously. During the asynchronous execution of the executable subtask, context state consistency data and functional adaptation data are collected in real time, and the process also includes: During the asynchronous concurrent execution of each executable subtask, a pre-set periodic polling monitoring service in the vehicle operating system is started, which captures the current input data and current output data of each executable subtask in real time. The current input data is compared field by field with the predefined subtask standard input data in the effective execution context data within the three-layer effective context data. If the field values ​​are the same, a first consistency tag is generated and marked as true. If the field values ​​are different, a first consistency tag is generated and marked as false. The first consistency tags of all fields are summarized to obtain the first consistency tag set. The current output data is compared field by field with the predefined subtask standard output data in the effective execution context data within the three-layer effective context data. If the field values ​​are the same, a second consistency flag is generated and marked as true. If the field values ​​are different, a second consistency flag is generated and marked as false. The second consistency flags of all fields are summarized to obtain the second consistency flag set. The first set of consistency tags and the second set of consistency tags are merged into context state consistent data.

11. The context-filtered in-vehicle component intelligent generation method of claim 10, wherein, The asynchronous execution state of each executable subtask is dynamically adjusted based on the comparison results, by comparing it with the three layers of valid context data, including: Based on the first consistency marker and the second consistency marker, locate the mismatched subtask corresponding to the false marker; The execution of the mismatched subtask is paused by invoking a preset rollback recovery mechanism, and an initial configuration snapshot of the three-layer valid context data corresponding to the mismatched subtask is retrieved from the preset checkpoint storage area. Based on the initial configuration snapshot, the input port configuration and output port configuration of the mismatched subtask are reset, a port reset instruction is generated, and the operation of the mismatched subtask is restored based on the port reset instruction. At the same time, the running status of the mismatched subtask is marked as corrected. When the actual occupancy rate deviates from the expected occupancy rate and the deviation exceeds a preset deviation threshold, based on the function adaptation data, the resource allocation ratio or execution priority of each executable subtask in the asynchronous task execution queue is adjusted.

12. A context-filtered in-vehicle component intelligent generation system for implementing the context-filtered in-vehicle component intelligent generation method of any one of claims 1-11, characterized in that, include: The instruction generation module is used to collect multi-dimensional context data of the target vehicle scene and generate initial vehicle component task instructions. The three-layer progressive filtering module is used to perform three-layer progressive filtering on multi-dimensional context data and output three layers of valid context data; The prompt word assembly module is used to generate standardized vehicle prompt words. It predicts hierarchical vehicle labels from three layers of effective context data through a pre-trained text classification model. Then, it queries the scenario template library based on the hierarchical vehicle labels to obtain the basic prompt word structure and fills in the constraint label and execution label in sequence to generate standardized vehicle prompt words. The multi-layer self-healing optimization module is used to iteratively optimize the initial vehicle components until they meet the standards. It inputs standardized vehicle prompts and three layers of effective context data into a pre-trained self-healing network model, identifies the logic nodes to be repaired and the resource nodes to be adjusted, generates and embeds a comprehensive repair patch to obtain the first optimized component, and achieves iterative optimization through vehicle compliance rate and hardware adaptability verification, outputting the qualified component and effective component generation signals. The asynchronous scheduling correction module is used to decompose compliant components and dynamically correct the running status of executable subtasks. It collects context state consistency data and function adaptation data in real time, locates mismatched subtasks by comparing the results, and rolls them back and resets them.

Images