Vehicle component generation deployment system and method based on multi-stage pipeline

Abstract

This application relates to the field of vehicle component generation and deployment technology, and discloses a vehicle component generation and deployment system and method based on a multi-stage pipeline. The method includes: acquiring user-input requirement text and performing semantic parsing; matching the parsing results with a pre-built vehicle capability model to generate a first functional requirement including functional description and interface constraints; generating first component code and simulating the operation of the first component code to detect vehicle violations, optimizing the code, and obtaining second component code; receiving the hardware fingerprint of the target vehicle and determining the target compilation parameters according to a preset compilation configuration strategy; compiling the second component code using the target compilation parameters to obtain a target component package; calculating a deployment security index; and if the deployment security index is within a preset deployment range, distributing the target component package to the target vehicle. This application can avoid generating unusable components and improve the efficiency and security of the vehicle component deployment process.

Description

Technical Field

[0001] This application relates to the field of vehicle component generation and deployment technology, and more specifically to a vehicle component generation and deployment system and method based on a multi-stage pipeline. Background Technology

[0002] Currently, with the increasing intelligence of automobiles, car owners' demands for personalized cabin functions are evolving from factory-installed pre-installed features to on-demand customization. Typical requirements include adding specific data display cards to the main in-vehicle screen, adding quick control switches, or combining multiple vehicle functions into a single operation entry point. These in-vehicle components are usually embedded in the main screen as widgets, obtaining data or issuing control commands by calling the service interface of the vehicle's electronic control unit. Component development involves multiple stages, including requirements communication, interface adaptation, code writing, multi-vehicle compatibility testing, security review, and version release, which are currently mainly completed manually item by item. The interface specifications of the vehicle's electronic control unit vary depending on the vehicle model, year, and hardware configuration. The same functional component needs to be re-adapted, compiled, and signed for different vehicle models. The distribution and installation of components also need to consider the safety constraints of the vehicle's driving status, and the update process should not affect normal driving operations.

[0003] The existing technology has the following problems: In the process of converting requirements into code, after users submit functional requirements via text or voice, developers manually interpret the requirements, consult vehicle interface documents, write code, and test each item, resulting in a long response cycle and difficulty in meeting timeliness requirements; the standards for manual code review and repair processes vary, leading to poor repair results; different vehicle models have different operating systems, processor architectures, and screen resolutions, resulting in inconsistent compilation parameters and system call interfaces, requiring manual configuration of compilation options for each vehicle model, which is inefficient; To solve at least one of the above problems, this application proposes a vehicle component generation and deployment system and method based on a multi-stage pipeline. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this application is to provide a system and method for the production and deployment of automotive components based on a multi-stage pipeline, which can effectively solve the problems in the background technology. The specific technical solution of this application is as follows:

[0005] A multi-stage pipeline-based method for generating and deploying automotive components includes:

[0006] The system acquires the user's input requirement text and performs semantic parsing. The parsing result is then matched with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints. The vehicle capability model includes the service interfaces and access restrictions provided by the vehicle electronic control unit.

[0007] The first component code is generated based on the first functional requirements, and the first component code is simulated to detect vehicle violations. The code is then optimized based on the violation type and violation code snippet to obtain the second component code.

[0008] The hardware fingerprint of the target vehicle is received, and the target compilation parameters are determined according to the preset compilation configuration strategy. The second component code is compiled using the target compilation parameters to obtain the target component package.

[0009] Based on the real-time status information of the target vehicle and the security level of the corresponding component in the target component package, the deployment security index is calculated. If the deployment security index is within the preset deployment range, the target component package is sent to the target vehicle for vehicle component deployment.

[0010] Specifically, the process involves obtaining the user-inputted requirement text, performing semantic parsing, and then matching the parsing results with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints, including:

[0011] Acquire the user's voice input and convert it into the required text;

[0012] Perform syntactic analysis and named entity recognition on the requirement text to extract the functional intent description and operation object entity;

[0013] The functional intent description and the entity to be operated are matched with the service interfaces in the pre-built vehicle capability model. Functional descriptions and interface constraints with similarity greater than a preset matching threshold are selected to obtain the first functional requirement.

[0014] Specifically, the code optimization based on the violation type and the violation code snippet to obtain the second component code includes:

[0015] The violation type is converted into a first embedding vector, a code semantic vector is generated according to the violation code fragment, the code is repaired, and the first repaired code is obtained.

[0016] The code is optimized based on the first repair code, and the running behavior of the optimized code is simulated to obtain the code for the second component.

[0017] Specifically, the process of converting the violation type into a first embedding vector, generating a code semantic vector according to the violation code fragment, and repairing the code to obtain the first repaired code includes:

[0018] Convert the violation type into the first embedding vector;

[0019] Extract the abstract syntax tree of the illegal code snippet, perform structural encoding on the abstract syntax tree, and generate a code semantic vector;

[0020] The code semantic vector is concatenated with the first embedding vector, and then input into a preset code repair model to repair the code, thereby obtaining the first repaired code.

[0021] Specifically, the second component code is obtained by optimizing the code based on the first repair code and simulating the operation of the optimized code, including:

[0022] Replace the violating code snippet with the first corrected code to obtain the candidate component code;

[0023] The candidate component code is simulated and the vehicle violation is detected. If the vehicle violation is eliminated, the candidate component code is used as the second component code. If a vehicle violation is detected, the violation information of the candidate component code is input into the code repair model for repair until the vehicle violation is eliminated, and the second component code is obtained.

[0024] Specifically, the process involves receiving the hardware fingerprint of the target vehicle, determining target compilation parameters based on a preset compilation configuration strategy, and compiling the second component code using these parameters to obtain a target component package, including:

[0025] The hardware fingerprint is matched against the pre-defined compilation configuration strategy to filter out the target compilation parameters;

[0026] Based on the compilation options in the target compilation parameters, the code of the second component is compiled, and the interfaces that are not in the system call pruning whitelist in the target compilation parameters are filtered out and replaced to obtain the target component package.

[0027] Specifically, the process of matching hardware fingerprints within a pre-defined compilation configuration strategy to filter out target compilation parameters includes:

[0028] The hardware fingerprint is compared with the historical hardware fingerprint records stored in the pre-configured compilation strategy, where each historical hardware fingerprint record is associated with a set of compilation parameters.

[0029] If a historical hardware fingerprint record that matches the hardware fingerprint exists, extract the corresponding associated compilation parameters as the target compilation parameters;

[0030] If no historical hardware fingerprint record matches the hardware fingerprint, select historical hardware fingerprint records with the same operating system type and processor architecture as the hardware fingerprint from multiple historical hardware fingerprint records to obtain a candidate record set; in the candidate record set, select the compilation parameters associated with the record whose screen resolution is closest to the screen resolution of the hardware fingerprint, and use them as the target compilation parameters.

[0031] Specifically, the second component code is compiled according to the compilation options in the target compilation parameters, and interfaces not in the system call pruning whitelist in the target compilation parameters are filtered out and replaced to obtain the target component package, including:

[0032] The second component code is compiled using the compilation options in the target compilation parameters to generate intermediate platform code;

[0033] Scan the system call interfaces called in the intermediate platform code, replace system calls not in the system call pruning whitelist with equivalent system calls supported by the target vehicle, and obtain the target component package.

[0034] Specifically, the step of distributing the target component package to the target vehicle for onboard component deployment includes:

[0035] The target component package is downloaded to the shadow partition of the target vehicle, and a silent installation is triggered in the shadow partition to perform a smoke test.

[0036] If the smoke test passes, the installed components in the shadow partition will be activated and made visible to the user;

[0037] If the smoke test fails, delete the installation contents in the shadow partition and report a silent deployment failure status code.

[0038] A multi-stage pipeline-based vehicle component production and deployment system is used to implement the multi-stage pipeline-based vehicle component production and deployment method, including:

[0039] The functional requirements analysis module acquires the user-input requirement text and performs semantic parsing. It then matches the parsing results with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints. The vehicle capability model includes the service interfaces and access restrictions provided by the vehicle electronic control unit.

[0040] The code optimization module generates the first component code based on the first functional requirement, simulates the operation of the first component code to detect vehicle violations, and optimizes the code based on the violation type and violation code snippet to obtain the second component code;

[0041] The component compilation module receives the hardware fingerprint of the target vehicle, determines the target compilation parameters according to the preset compilation configuration strategy, and compiles the second component code using the target compilation parameters to obtain the target component package;

[0042] The component deployment module calculates the deployment security index based on the real-time status information of the target vehicle and the component security level corresponding to the target component package. If the deployment security index is within the preset deployment range, the target component package is sent to the target vehicle for vehicle component deployment.

[0043] The beneficial effects of this application are as follows: the interface constraints of the vehicle capability model enable interface compatibility pre-checks to be completed during the requirements analysis phase, which can prevent the generation of unusable components in advance; the code repair model uses violation types and abstract syntax tree encoding for multi-round iterative repair, which eliminates violations while maintaining the integrity of the code structure and avoids introducing new problems during the repair process; the hierarchical degradation matching compilation configuration strategy enables the hardware configuration of new vehicle models to automatically obtain usable compilation parameters and call mapping replacement to eliminate cross-platform compatibility issues; the deployment process of shadow partitioning combined with smoke testing enables components to complete installation verification without the user's awareness, improving the efficiency and security of the vehicle component deployment process. Attached Figure Description

[0044] Figure 1 This is a flowchart illustrating the process of the vehicle component generation and deployment method based on a multi-stage pipeline in this application embodiment.

[0045] Figure 2 This is a schematic diagram of the structure of the vehicle component generation and deployment system based on a multi-stage pipeline in the embodiments of this application. Detailed Implementation

[0046] The present application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0047] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0048] Hereinafter, the terms "first," "second," and other generic terms are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0049] refer to Figure 1 The image shows a specific implementation of the vehicle component generation and deployment method based on a multi-stage pipeline of this application, including:

[0050] S101. Obtain the user-inputted requirement text and perform semantic parsing. Match the parsing result with the pre-built vehicle capability model to generate a first functional requirement including functional description and interface constraints. The vehicle capability model includes the service interface and access restrictions provided by the vehicle electronic control unit.

[0051] S102. Generate the first component code based on the first functional requirements, and simulate the operation of the first component code to detect vehicle violations. Optimize the code based on the violation type and violation code snippet to obtain the second component code.

[0052] S103. Receive the hardware fingerprint of the target vehicle, determine the target compilation parameters according to the preset compilation configuration strategy, and compile the second component code using the target compilation parameters to obtain the target component package;

[0053] S104. Based on the real-time status information of the target vehicle and the component security level corresponding to the target component package, calculate the deployment security index. If the deployment security index is within the preset deployment range, send the target component package to the target vehicle to deploy the vehicle-mounted components.

[0054] In this embodiment, a method for generating and deploying in-vehicle components based on a multi-stage pipeline runs on a cloud server or a computing cluster connected to a vehicle networking platform. It automatically converts user natural language requirements into safe, compliant, and multi-platform compatible in-vehicle components and completes silent deployment when the vehicle status allows.

[0055] In this embodiment, the vehicle capability model is a graph describing the external service interfaces and calling constraints of each vehicle's electronic control unit (ECU). It is constructed by extracting the service interfaces of each ECU from the OEM's ECU interface specification document, recording the interface name, parameter list, return value type, prerequisite calling conditions, and mutual exclusion relationships with other interfaces as graph nodes and edges. Taking the air conditioning control interface as an example, the prerequisites for this interface include the vehicle's power status being ON and the remaining battery charge being higher than 10%. Its mutual exclusion relationship points to the low-charge protection power reduction mode of the battery management system; when the latter is activated, the air conditioning control interface is locked and cannot be called. All model data originates from the vehicle's factory configuration and ECU firmware definitions, without relying on online learning or dynamic updates.

[0056] After obtaining user input, the input format is determined. If it is a speech signal, it is converted into a text-based requirement text using the speech recognition module. Dependency parsing and named entity recognition are then performed on the requirement text. Parsing identifies the predicate verbs corresponding to the user's intent, such as "display," "adjust," and "increase." Named entity recognition extracts the operation objects, such as "remaining battery life," "air conditioning temperature," and "seat heating." The functional intent and the operation object are combined to form intent-entity pairs.

[0057] Specifically, the intent-entity pair text is matched with the semantic descriptions of each service interface in the vehicle capability model based on similarity. This embodiment uses a pre-trained language model to encode both the intent-entity pair text and the interface semantic description text, generating sentence vectors for each. The cosine similarity between the two sentence vectors is then calculated. A preset matching threshold of 0.85 is used. When the cosine similarity exceeds this value, the service interface and its calling constraints are included in the structured requirements specification; if no interface exceeds the threshold, a clarification prompt is generated and returned to the user.

[0058] Furthermore, the structured requirement specification is organized using key-value pairs. The functional description field records the requirement summary after word segmentation and intent extraction. The interface constraint field lists the matched ECU interface names, parameter mapping relationships, and mutual exclusion conditions in a list format. Taking the user input "display remaining driving range and add an air conditioning switch" as an example, after parsing, two intent-entity pairs are obtained: "display-remaining driving range" and "add-air conditioning switch". The matching results match the instrument display service interface and the air conditioning control service interface, respectively. The interface constraint specifies that the air conditioning control interface must be available when the engine is running.

[0059] Specifically, code generation employs a combination of template filling and generative models. For highly standardized components such as interface layout and simple data binding, corresponding templates are selected from the widget template library based on the functional description, and then used to fill in ECU interface call statements and variable bindings. For complex logic involving multiple conditional branches and timing interactions, the structured requirement specifications are transformed into natural language description text and fed into a pre-trained code generation model based on the Transformer architecture. This model uses CodeT5 as its foundation, taking the requirement description text as input and outputting component code snippets written in an intermediate representation language. The generation process involves autoregressive word-by-word prediction until an end marker is displayed. All generated code is declared as a platform-independent intermediate representation, using an abstract widget tree to describe the interface structure and encapsulating ECU interface calls with standardized vehicle service call primitives.

[0060] After generating the initial component code, it is run and tested in a cloud-based automotive-grade simulation environment. This simulation environment consists of a virtual instance of the target vehicle operating system and a vehicle bus signal simulation module. The simulation module replays pre-recorded CAN bus messages and ECU status signals, allowing the component code to execute in a context close to real vehicle operating system conditions. Violation detection is achieved through a combination of static analysis and dynamic instrumentation: static analysis uses PC-lint to load the MISRA-C 2012 rule set and scans it line by line, marking the line number and rule number of the violated rule; dynamic instrumentation inserts timing and memory monitoring probes at the component entry and exit functions, recording the execution time of the main thread function and the peak heap memory allocation. Automotive-grade violations include, but are not limited to, MISRA-C rule violations, main thread single execution time exceeding sixteen milliseconds, and memory usage exceeding the widget sandbox allocation limit of fifty megabytes. Each violation records the violation type label and the start and end line numbers of the violating code fragment.

[0061] Specifically, code repair employs a Transformer-based sequence-to-sequence model. The training data is constructed as follows: open-source automotive software component code and historical component code authorized by car manufacturers are collected. The aforementioned static analysis tools are used to scan for violation locations and types. Engineers with automotive software experience write repair patches, forming triplets of "violation code fragment - violation type - repair code," totaling approximately 150,000 entries. During training, the abstract syntax tree of the violation code fragments is parsed, and the path representation from the root node to the leaf node is extracted as structural encoding. This is then used by the encoder to generate code semantic vectors. Violation types are converted into violation type embedding vectors through an embedding layer. Both are concatenated along the channel dimension and fed into the decoder, which generates repair code word by word using an autoregressive approach. The loss function is cross-entropy loss, the optimizer uses Adam, the learning rate is 0.0001, the batch size is 32, and the training run is 50 epochs.

[0062] During the inference phase, an abstract syntax tree (AST) of the violating code fragment is extracted and structurally encoded to obtain a code semantic vector. The violation type is converted into a first embedding vector. The two are concatenated and input into the model, outputting candidate repair code. The candidate repair code replaces the original violating code fragment, generating candidate component code, and the detection is run again in the simulation environment. If the violation has been eliminated, the candidate component code is determined to be compliant component code; if the violation has not been eliminated, new violation information is fed back to the model for iterative repair until the violation is eliminated or a preset limit of five iterations is reached.

[0063] In an optional implementation, the termination condition for iterative repair can also be adjusted in conjunction with the severity of the violation: for violations involving driving safety, the maximum number of iterations is increased to eight; for violations purely related to code style, the maximum number of iterations is reduced to three.

[0064] Furthermore, when the target vehicle's infotainment system registers for cloud services for the first time or detects a change in hardware configuration, it reports a hardware fingerprint, which includes seven fields: operating system type, operating system version number, processor architecture, graphics framework name and version, screen resolution width, screen resolution height, and security chip model.

[0065] Specifically, the compilation configuration strategy is stored in the cloud as a relational data table. Each record contains the seven hardware fingerprint fields mentioned above and a set of compilation parameters. The compilation parameters include the compiler name, a list of compilation optimization options, a system call pruning whitelist, a signature certificate identifier, and a packaging format. Initially, the maintenance personnel enter the corresponding compilation parameters for known vehicle models into this data table. Subsequently, after each adaptation compilation for a new vehicle model, the correspondence between the hardware fingerprints used and the compilation parameters is appended and written.

[0066] Specifically, the process of determining the target compilation parameters involves hierarchical matching. All seven fields of the target vehicle infotainment system's hardware fingerprint are matched against each historical record in the table. If a historical record with identical fields exists, the corresponding compilation parameters are directly extracted. If no complete match exists, records with the same operating system type and processor architecture are selected as candidate records. The absolute value of the difference between the screen resolution of each record in the candidate record set and the target vehicle infotainment system's screen resolution in terms of the total number of pixels is calculated. The compilation parameters corresponding to the record with the smallest absolute difference are taken as the target compilation parameters.

[0067] After determining the compilation parameters, cross-compile the compliant component code using the compiler name and compilation optimization options to generate ARM binary object files or DEX bytecode. After compilation, check if the compilation parameters include a system call pruning whitelist. If so, scan all system call instructions in the intermediate platform code and compare them one by one with the whitelist. For system calls not in the whitelist, find equivalent replacements using a pre-configured system call mapping table. The mapping table is manually compiled based on the API documentation of each vehicle's operating system; for example, Linux kernel's epoll_wait is mapped to QNX Neutrino's MsgReceive. If no equivalent call is found in the mapping table, insert an empty implementation stub function and record a downgrade processing flag.

[0068] Furthermore, the digital signature packaging selects the signature strength based on the impact on component functional safety. The ECU interfaces called in the compliant component code are scanned; if an interface is marked as a driving control class in the vehicle capability model, the corresponding code line is marked as control function code. The proportion of control function code lines to the total number of compliant component code lines is calculated, with a preset threshold of 15%. If this proportion is exceeded, the component package manifest file is signed using the SM2 elliptic curve private key from the hardware security module; otherwise, a standard RSA-2048 signature is used. After signing, the package is packaged according to the OTA standard format.

[0069] Specifically, real-time vehicle status information is reported by the onboard T-Box at fixed intervals, including driving status, power mode, network signal quality, processor load rate, and remaining battery percentage. Before calculating the deployment safety index, a safety condition pre-check is performed: the driving state must be in Park (P) gear, the remaining battery charge must be above 20%, and the processor load rate must be below 70%. If any condition is not met, the deployment safety index calculation is paused, a five-minute delay is initiated, the vehicle's real-time status information is retrieved again, and the pre-check is performed again. If three consecutive pre-checks fail, the deployment request is marked as failed.

[0070] After the pre-inspection is passed, the deployment safety index is calculated. The deployment safety index is the sum of the driving state risk value, the power supply risk value, and the component safety level risk increment. The lower the value, the safer it is. The driving state risk value is zero in P gear and 100 in other gears. The power supply risk value is divided into segments according to the remaining battery charge: zero when it is not less than 80%, 30 in the 50% to 80% range, and 60 in the 20% to 50% range. The component safety level risk increment is determined according to the component category: zero for pure interface components and 50 for components involving vehicle control. The allowable deployment range is a deployment safety index not exceeding 60.

[0071] When the index falls within the allowable range, the target platform component package is distributed to the target vehicle system in blocks via the OTA channel, with each block accompanied by a verification code. After receiving the package, the vehicle system verifies its integrity. If the verification passes, the component package is written to an independent shadow partition of the storage. This partition is isolated from the currently running partition, and the writing does not affect existing components.

[0072] A silent installation is triggered within the shadow partition. After installation, a smoke test is performed to check for any anomalies in component process startup initialization, ECU interface return data format, and UI rendering. If all three checks pass, an activation command is sent to the system framework to register the shadow partition component as available and make it visible to the user; the original version is then backed up. If any check fails, all installation files in the shadow partition are deleted, and a silent deployment failure status code, including the failed check number and timestamp, is returned to the cloud. The entire process is seamless for the user.

[0073] In an optional implementation, the data format verification of the ECU interface returned by the smoke test can be achieved by comparing pre-recorded interface response samples. If there is a discrepancy, the test is deemed to have failed and a rollback is triggered.

[0074] The interface constraints of the vehicle capability model in this application enable interface compatibility pre-checks during the requirements analysis phase, preventing the generation of unusable components in advance. The code repair model utilizes violation types and abstract syntax tree encoding for multi-round iterative repairs, eliminating violations while maintaining code structure integrity and avoiding the introduction of new problems during the repair process. The hierarchical degradation matching compilation configuration strategy enables the hardware configuration of new vehicle models to automatically obtain usable compilation parameters, calling mapping replacements to eliminate cross-platform compatibility issues. The deployment process of shadow partitioning combined with smoke testing enables components to complete installation verification without the user's awareness, improving the efficiency and security of the vehicle component deployment process.

[0075] Furthermore, the user-input requirement text is obtained and semantically parsed. The parsing results are then matched with a pre-built vehicle capability model to generate the first functional requirement, which includes a functional description and interface constraints.

[0076] S201. Obtain the user's voice input signal and convert it into the required text;

[0077] S202. Perform syntactic analysis and named entity recognition on the requirement text to extract the functional intent description and operation object entity;

[0078] S203. Perform similarity matching between the functional intent description and the operation object entity and the service interface in the pre-built vehicle capability model, and filter out the functional descriptions and interface constraints with similarity greater than the preset matching threshold to obtain the first functional requirement.

[0079] In this embodiment, the user input includes either a voice signal or text. When the input is a voice signal, it is converted into the desired text format. The voice signal is a time-domain waveform sampling sequence with a sampling rate of 16kHz, a bit depth of 16bit, and a single channel. The system's built-in speech recognition module adopts a streaming end-to-end architecture, consisting of an acoustic encoder and a text decoder connected in series.

[0080] Specifically, the acoustic encoder receives a sequence of sampled speech waveform points as input, frames the waveform with a window width of 25 milliseconds and a frame shift of 10 milliseconds, and extracts 80-dimensional Mel-frequency cepstral coefficient features frame by frame. The feature sequence undergoes multiple layers of one-dimensional convolution and downsampling operations with a stride of 2, compressing the time dimension layer by layer and expanding the channel dimension layer by layer, outputting a hidden state sequence. Downsampling makes the time step of the encoder output approximately 40 milliseconds, reducing the computational load of the subsequent decoder while maintaining sufficient temporal resolution.

[0081] Furthermore, the text decoder predicts the text word sequence from the hidden state sequence in an autoregressive manner. At each prediction step, the decoder receives the word embedding vector from the previous step as input, combines it with the hidden state sequence output by the encoder to calculate the conditional probability distribution for the current step, and selects the word with the highest probability in the vocabulary dimension as the output for the current step, until an end-of-output marker is added. Internally, the decoder uses multiple Transformer decoding layers, each containing two sub-layers: masked self-attention and cross-attention. The cross-attention sub-layer uses the encoder's hidden state as key-value pairs in the computation.

[0082] Specifically, the training dataset for the speech recognition module comes from real driving speech collected by microphones at multiple locations inside the vehicle. The collection environment covers idling, constant speed, and acceleration conditions; windows fully closed, half-open, and fully open; and air conditioning off, low, and high settings, creating various noise superposition conditions. Approximately 8,000 hours of speech were collected, all of which were manually transcribed into text with annotations. During training, the acoustic encoder and text decoder are jointly optimized. The single loss function is the cross-entropy loss of the text sequence, which calculates the cross-entropy between the predicted probability distribution and the true words at each prediction step and takes the average value of each step in the sequence. The optimizer uses AdamW, and the learning rate scheduling adopts a preheating plus cosine annealing method: in the first 20,000 training steps, the learning rate increases linearly from zero to 0.001 and then decays according to a cosine curve to one-tenth of 0.001. The training hardware is a GPU cluster, which calculates gradients synchronously on multiple GPU cards in a data-parallel manner and then updates parameters. The required text for conversion is stored in UTF-8 encoded string format. If the user input itself is text, speech conversion is skipped and the process proceeds directly to S202.

[0083] Furthermore, dependency parsing and named entity recognition are performed in parallel on the requirement text. After aligning the results of the two analyses, the functional intent description and the entity of the operation object are extracted. Dependency parsing uses a biaffine dependency parser based on a pre-trained language model. The requirement text is segmented and input into the language model, which outputs a context representation vector for each word. On two independent multilayer perceptrons, head node scores and dependency relation type scores are calculated for each pair of words. The head node score represents the probability that one word is the syntactic core of another word, and the dependency relation type score represents the dependency relation category between two words. The scores of all word pairs are jointly decoded, and the Eisner algorithm is used to search for the maximum spanning tree on the matrix to output the dependency relation tree between words.

[0084] Specifically, named entity recognition is based on a sequence labeling architecture built on top of the same language model output layer. A linear classification layer follows the word representation vectors generated by the language model to predict entity labels for each word. The labels use the BIO labeling system: B represents the entity start word, I represents an internal word, and O represents a non-entity word. Entity categories include two types: functional operation categories and in-vehicle object categories. Functional operation categories cover verbal entities such as display, adjust, switch, turn on, and turn off; in-vehicle object categories cover nounal entities such as remaining range, air conditioning temperature, seat heating, and navigation destination.

[0085] Furthermore, all arcs in the dependency tree are traversed. If an arc connects a functional operation entity and a vehicle object entity, and the functional operation term is a syntactic core word, then the two entities are combined into an intent-entity pair. For example, in the requirement text "Display remaining range and add an air conditioning switch", after parsing, the dependency tree contains a verb-object relationship arc from "display" to "range" and a verb-object relationship arc from "add" to "switch". Entity recognition marks "display" and "add" as functional operation classes, and "remaining range" and "air conditioning switch" as vehicle object classes, combining them into two intent-entity pairs based on the syntactic arcs: display-remaining range and add-air conditioning switch. If there are no direct dependency arcs in the syntactic tree, but the two entities are adjacent in the sequence and there are no other entities in between, they are also included as candidates.

[0086] Furthermore, using intent-entity pairs and a pre-built vehicle capability model as input, corresponding service interfaces are filtered through semantic vector similarity matching to generate the first functional requirement, which includes functional descriptions and interface constraints. The vehicle capability model is stored in a cloud-based relational database in a graph structure. Nodes in the graph represent service interfaces exposed by each ECU, and node attributes include interface name, parameter list, parameter type, return value type, and interface semantic description text. Edges represent relationships between interfaces, including dependency and mutual exclusion. Taking the mutual exclusion relationship between the air conditioning control interface and the battery management system's low-charge protection interface as an example, this edge records that the air conditioning control interface cannot be called when the battery management system activates the low-charge protection mode.

[0087] Specifically, the matching process includes: concatenating the text of the intent-entity pair with the entity of the operation object to form the query text, and using the semantic description text of each service interface in the vehicle capability model as the matched text. The query text and the matched text are respectively input into a pre-trained language model for encoding, and the mean pooling result of the last hidden state of the model in the sequence length dimension is taken as the sentence vector, which is denoted as the query vector and the interface vector, respectively.

[0088] Calculate the cosine similarity between the query vector and each interface vector. The cosine similarity is the quotient of the inner product of the two vectors divided by their respective moduli, and the value ranges from negative one to one. The closer the value is to one, the closer the two vectors are in the vector space, and the higher the semantic consistency.

[0089] Each cosine similarity is compared with a preset matching threshold of 0.85. The threshold is determined as follows: during the system development phase, 5,000 labeled samples are constructed. Each sample contains a list of correct matching interfaces for a natural language requirement and manual annotation. The samples are randomly divided into a training validation set and a test set. On the training validation set, the candidate thresholds are traversed from 0.5 to 0.95 with a step size of 0.05. The recall and precision corresponding to each candidate threshold are calculated. The value with the highest precision under the condition that the recall is not less than 95% is selected as the matching threshold.

[0090] For interfaces with a cosine similarity exceeding 0.85, the interface name and parameter mapping are extracted, and the mutually exclusive interface identifiers associated with this interface are read from the edge information of the vehicle capability model and added to the interface constraint list. The function description field is filled with a text summary of the intent-entity pair. All interface constraints and function descriptions are combined into a key-value pair structure, i.e., the first functional requirement. If no interface exceeds the threshold, a clarification prompt is generated to provide feedback to the user. The prompt includes the semantic descriptions of the three candidate interfaces with the highest similarity, allowing the user to restate their requirements.

[0091] Furthermore, based on the violation type and the violation code snippet, code optimization is performed to obtain the second component code, including:

[0092] S301. Convert the violation type into a first embedding vector, generate a code semantic vector according to the violation code fragment, repair the code, and obtain the first repaired code;

[0093] S302. Optimize the code based on the first repair code and simulate the running of the optimized code to obtain the second component code.

[0094] In this embodiment, the violation type label is a classification identifier generated during the violation detection phase. The system maintains a violation type index table, which includes 47 violation types. Each violation label is mapped to an integer index, ranging from 0 to 46. Violation types include MISRA-C rule violations, main thread timeout blocking, memory exceedances, etc., where MISRA-C rule violations are further subdivided into different rule numbers, each corresponding to an index. After mapping the violation type label to an integer index, the integer index is converted into a fixed-dimensional first embedding vector through an embedding matrix. The embedding matrix is ​​a floating-point matrix with a shape of 47 rows by 256 columns, randomly initialized during the code repair model training phase and updated during the training process. The embedding operation retrieves the first embedding vector by taking the row vector corresponding to the integer index of the matrix.

[0095] Specifically, the code semantic vector generation path includes: parsing the abstract syntax tree of the violating code fragment, and extracting the path representation from the root node to each leaf node. The parsing process uses a language front-end parser to convert the violating code fragment into a concrete syntax tree, and then back into an abstract syntax tree. Each node in the abstract syntax tree records its node type, including function call nodes, assignment statement nodes, conditional branch nodes, etc., and also records the edge type from that node to its parent node. All paths from the root node to the leaf node are expanded into a sequence of alternating node and edge types. A path vocabulary maps each node and edge type to an integer number, converting the path sequence into an integer sequence. This integer sequence is input into the encoder, which consists of three stacked Transformer encoding layers, each containing a multi-head self-attention network and a feedforward network. The encoder outputs the hidden state at each position, and the hidden state at the first position of the sequence is taken as the code semantic vector, with a dimension of 256. The encoder is jointly trained with the embedding matrix and other components during the model training phase.

[0096] The first embedding vector and the code semantic vector are concatenated along the channel dimension to obtain a 512-dimensional joint vector. This joint vector is input to the decoder. The decoder employs a stack of six Transformer decoding layers, each containing three sub-layers: masked self-attention, cross-attention, and a feedforward network. The cross-attention sub-layer uses the joint vector as a key-value pair in the computation. The decoder generates the repair code word by word in an autoregressive manner, generating one term per step. The term comes from a code vocabulary of approximately 50,000 terms, covering programming language keywords, operators, delimiters, and common identifiers. During each generation step, the decoder calculates the probability distribution on the vocabulary and outputs the term with the highest probability. This term is then used as input to the decoder in the next step until the output end marker is reached. The term sequence output by the decoder is then mapped back to the code text via an inverse vocabulary mapping to obtain the first repair code.

[0097] Specifically, the training data construction process for the code repair model includes: collecting approximately 200,000 source code files from open-source automotive software component code repositories and historical component code licensed by car manufacturers; scanning each file using the static analysis tools and dynamic instrumentation tools described in S102 to record the location and type of violations; for each violation, an engineer with an automotive software background writes a repair patch to eliminate the violation without changing the original code's functional intent; organizing the violating code snippets, violation type labels, and the repaired code into triplet samples, constructing approximately 150,000 valid samples, which are then randomly divided into training, validation, and test sets at a ratio of 80%, 10%, and 10%, respectively.

[0098] During training, a forward computation is performed on each training sample. The encoder outputs a code semantic vector, and the embedding matrix outputs the first embedding vector. These are concatenated and input into the decoder, which predicts the repair code word by word. The loss function is the cross-entropy loss between the predicted word sequence and the actual repair code word sequence. The average of the cross-entropy between the predicted probability distribution at each position in the sequence and the actual word is taken. The optimizer uses Adam with a learning rate of 0.0001 and a batch size of 32 triples. Training is performed on the training set for 50 epochs. After each epoch, the loss is evaluated on the validation set, and the model parameters with the lowest validation loss are retained for inference.

[0099] Preferably, violation types are encoded using embedding vectors, ensuring that semantically similar violation types are close together in the embedding space. This allows the model to generalize to low-frequency violation types in the training set. Code semantic vectors are extracted using abstract syntax tree path encoding, preserving code structure information and syntactic hierarchy relationships, and capturing dependencies spanning long code distances, such as constraints between variable declarations and their multiple usage locations. The embedding vectors and code semantic vectors are concatenated and jointly decoded, ensuring the repair process is simultaneously constrained by both the violation correction target and the original code context. The generated repair code eliminates violations while maintaining interface compatibility with surrounding code.

[0100] Furthermore, the first repair code replaces the corresponding position of the original violating code fragment in the candidate component code, with the replacement range determined by the start and end line numbers recorded during the violation detection phase. During replacement, the original code's indentation level and preceding and following blank lines are maintained, generating candidate component code. The candidate component code is then re-entered into the cloud-based automotive-grade simulation environment for execution, maintaining the same running conditions as the initial detection phase, using the same operating system virtual instance and CAN bus data playback. Static analysis and dynamic instrumentation tools perform a full-scale detection of the candidate component code again, covering all 47 types of automotive-grade violations.

[0101] Specifically, after the detection is completed, branch processing is performed based on the detection results. If all violation type detection results are negative, meaning the original violation has been eliminated and no new violation has been introduced, the current candidate component code is determined as the second component code. If violations are still detected, regardless of whether the original violation type has not been completely eliminated or a new violation type has been introduced, the newly detected violation type labels and violation code fragments in the current candidate component code are extracted and fed back to the S301 code repair model as input for the next round of repair for iterative repair. During the iteration process, the number of violations in each round of detection is compared with the previous round. If the number of violations decreases in each round, the iteration continues. If the number of violations does not decrease in two consecutive rounds, the iteration is paused and the component is marked as requiring manual review. The maximum number of iterations is set to five. If all violations are not eliminated after exceeding the limit, it is also marked as requiring manual review. The second component code is output in the form of a programming language source code file as input for the S103 compilation stage.

[0102] As an alternative implementation, the upper limit of the number of iterations can be dynamically adjusted according to the classification of the violation type: the upper limit is increased to eight for violations involving driving safety, and reduced to three for code style violations, so that computing resources are tilted towards violations with high security risks.

[0103] Preferably, the repair model does not end with a single code generation, but rather uses simulated test results as feedback signals to drive multiple rounds of optimization. This closed-loop mechanism allows the repair model to correct its output biases during the inference phase using real feedback from the detection tools. Compared to single-step repairs that rely solely on the training data distribution, it also has the ability to correct for violations not covered in the training set. An upper limit on the number of iterations and a manual review fallback mechanism control computational resource consumption when automatic repair fails to converge. The final output of the second component code has undergone repeated verification, and its automotive-grade compliance is supported by multiple rounds of confirmation from the detection tools, reducing the probability of compilation failures or the generation of unsafe target code due to code defects during the downstream compilation stage.

[0104] Furthermore, the violation type is converted into a first embedding vector, a code semantic vector is generated according to the violation code fragment, the code is repaired, and the first repaired code is obtained, including:

[0105] S401. Convert the violation type into the first embedding vector;

[0106] S402. Extract the abstract syntax tree of the illegal code fragment, perform structural encoding on the abstract syntax tree, and generate a code semantic vector;

[0107] S403. Concatenate the code semantic vector with the first embedding vector, input the preset code repair model, repair the code, and obtain the first repaired code.

[0108] In this embodiment, violation type labels are recorded in string format. For example, a MISRA-C rule violation is labeled as MISRA_10_1, a main thread timeout blocking is labeled as TIMEOUT_BLOCK, and a memory limit exceeding the limit is labeled as MEMORY_OVERFLOW. The system has a pre-built violation type index table, which is constructed before training the code repair model. This table is constructed by extracting all violation type labels from the training data, removing duplicates, and sorting them in descending order of frequency of occurrence, assigning index numbers starting from integer 0. This embodiment includes 47 violation types, with an index range of 0 to 46.

[0109] Specifically, the embedding matrix is ​​one of the parameters of the code-fixing model. It is a two-dimensional floating-point array with 47 rows and 256 columns, initialized at the start of training by random sampling from a normal distribution with a mean of zero and a standard deviation of 0.02. During S401, the integer index corresponding to the violation type label is used as the row number, and the 256 floating-point numbers for that row are extracted from the embedding matrix to form the first embedding vector. The embedding matrix is ​​updated through backpropagation during model training. After training, the row vectors corresponding to semantically similar violation types are close to each other in the vector space. For example, different MISRA-C rule violations belonging to the same memory operation class have high cosine similarity between their embedding vectors.

[0110] Preferably, this transformation maps discrete labels to continuous vectors, enabling the semantic relationships between violation types to be expressed in the vector space. Compared to the shortcomings of one-hot encoding, where each violation type is pairwise orthogonal and cannot reflect similarity, embedding vectors allow the model to obtain similar repair behavior priors from neighboring high-frequency violation types in the embedding space when encountering low-frequency violation types in the training set, thus improving the generalization ability to low-frequency violations.

[0111] Furthermore, the violation code snippet is extracted from the initial component code using the start and end line numbers recorded during the violation detection phase. This snippet is then parsed using a language front-end parser corresponding to the component code's programming language, generating a concrete syntax tree and then transforming it into an abstract syntax tree. The abstract syntax tree retains nodes related to code semantics, including function call nodes, assignment statement nodes, conditional branch nodes, loop statement nodes, variable declaration nodes, binary operation nodes, and literal nodes, while discarding purely syntactic marker nodes such as parentheses and semicolons. Edges between nodes represent parent-child relationships, pointing from a parent node to a child node.

[0112] Specifically, the structural encoding starts from the root node of the abstract syntax tree and traverses to each leaf node, resulting in several paths from the root to the leaf. Each path consists of alternating node and edge types along the way. The path vocabulary is constructed on the training data, including node and edge types that appear at least 5 times, totaling 128 node types and 64 edge types, each mapped to an integer number. The length of the integer sequence for each path is not fixed; paths shorter than the preset maximum path length of 120 integers are padded with zeros at the end, while paths exceeding the maximum length are truncated in the middle.

[0113] The integer sequence of each path is input into the encoder, which consists of three stacked Transformer encoding layers. Each layer contains a multi-head self-attention network and a feedforward network. The self-attention network has 8 heads, and the feedforward network has a hidden layer dimension of 1024. The encoder encodes each path independently and outputs a sequence of hidden states. The hidden state at the first position of the sequence is taken as the path vector for that path. The element-wise average of all path vectors is then calculated to obtain a 256-dimensional code semantic vector.

[0114] Preferably, the abstract syntax tree path encoding captures the hierarchical structure of the violation code fragment and the long-distance dependencies across nodes. Compared with directly inputting the code text as a sequence of terms, path encoding does not rely on variable naming and formatting, and produces similar vector representations for code fragments with the same semantics but different syntax. The root-to-leaf path traversal explicitly encodes the role of the violation position in its syntactic context, and average pooling integrates the information from each path, taking into account both the local syntactic environment and global structural constraints.

[0115] Specifically, the first embedding vector and the code semantic vector are each 256-dimensional, concatenated along the channel dimension to obtain a 512-dimensional joint vector. This joint vector serves as the external key-value pair input to the decoder. The decoder consists of six stacked Transformer decoding layers, each containing a masked self-attention sublayer, a cross-attention sublayer, and a feedforward network sublayer. The cross-attention sublayer uses the joint vector as the key-value pair, with the query vector coming from the output of the masked self-attention. The feedforward network sublayer contains two fully connected layers with a hidden layer dimension of 2048 and the activation function being GELU.

[0116] It should be noted that the decoder generates the repair code in an autoregressive manner, starting with an initial marker word. In each generation step, the decoder processes the generated word sequence through masked self-attention, then interacts with the joint vector in a cross-attention sublayer. After passing through a feedforward network, it is projected onto the code vocabulary dimension via linear mapping. The code vocabulary has a size of 51,200 words, covering programming language keywords, operators, delimiters, and common identifiers from the training data. A softmax operation is applied to the projection result to obtain the probability distribution of the current step. The word corresponding to the maximum probability is output, and this word is concatenated to the end of the generated sequence in the next step and fed back into the decoder. This process is repeated until the end marker word is output or the maximum generation length of 512 words is reached. The word sequence output by the decoder is restored to the code text through inverse vocabulary mapping, resulting in the first repair code.

[0117] Specifically, the training data for the code repair model was collected from two sources: approximately 120,000 open-source automotive software component code repositories and approximately 80,000 historical automotive component code files licensed by car manufacturers. For each file, static analysis and dynamic instrumentation tools in S102 were used to scan for violations, recording the violation type and start and end line numbers. Repair patches were written by engineers with experience in automotive embedded software development to eliminate violations while maintaining functionality. Each violation code snippet, violation type, and repair code constituted a triplet sample, totaling approximately 150,000 samples. These samples were randomly divided into training, validation, and test sets at 80%, 10%, and 10% respectively, with samples from the same source code file grouped into the same set.

[0118] During training, forward computations S401 and S402 are performed on each sample to generate the first embedding vector and the code semantic vector. These are then concatenated and input into the decoder to predict the repair code word by word. The loss function is the mean of the cross-entropy between the predicted sequence and the true repair sequence at each position. The optimizer uses Adam with a learning rate of 0.0001, a batch size of 32, and is trained for 50 epochs. After each epoch, the loss is evaluated on the validation set, and the model parameters with the lowest validation loss are retained.

[0119] Preferably, the joint vector enables the decoder to perceive two constraint sources simultaneously at each generation step: violation type and violation code structure. Through a cross-attention mechanism, the decoder adaptively selects the most relevant part from the two information sources: when generating function call replacement code, the attention weight tends to focus on the path vector of the call node in the abstract syntax tree; when completing compliance check statements, the attention weight tends to focus on the violation type embedding vector. The repair code output by this fusion method eliminates violations while maintaining syntactic consistency and interface compatibility with the surrounding code, reducing the probability of introducing new violations through repair.

[0120] Furthermore, based on the first fix code, code optimization is performed, and the running behavior of the optimized code is simulated to obtain the second component code, including:

[0121] S501. Replace the violating code snippet with the first repair code to obtain the candidate component code;

[0122] S502. Simulate the running of the candidate component code and detect vehicle violations. If the vehicle violation is eliminated, the candidate component code is used as the second component code. If a vehicle violation is detected, the violation information of the candidate component code is input into the code repair model for repair until the vehicle violation is eliminated, and the second component code is obtained.

[0123] In this embodiment, the start and end line numbers of the violating code fragment are recorded during the violation detection phase in S102, and this line number location information is saved along with the violation type label. The first repair code output in S301 is a piece of source code text that conforms to the syntax rules and corresponds to the violating code fragment. When performing the replacement, the initial component code file is opened, the area where the violating code is located is located according to the start and end line numbers, all original code lines from the start line number to the end line number are deleted, and all code lines of the first repair code are inserted at that position. During insertion, the indentation level is kept consistent: the number of leading whitespace characters in the original code lines is counted, and the leading whitespace characters in each line of the first repair code are replaced with the same number of whitespace characters. After the replacement is completed, the syntax connection before and after the insertion position is checked: if the original code ends with a left curly brace before the violating code fragment and the first line of the first repair code does not start with a left curly brace, a newline and corresponding indentation are automatically added; if the original code begins with a right curly brace after the violating code fragment and the last line of the first repair code does not end with a right curly brace, a newline and indentation are also automatically added. After the above replacement and format alignment, a complete source code file is generated, and the candidate component code is obtained.

[0124] Preferably, the replacement is precisely located using line numbers, and the repair operation only applies to the non-compliant code areas marked by the detection tool, without modifying other verified non-compliant parts of the component code, thus avoiding the introduction of new defects through global refactoring. Indentation level preservation and syntax connectivity checks ensure that the candidate component code remains compilable at the lexical level, preventing subsequent simulation runs from failing and exiting during syntax parsing due to indentation errors or mismatched brackets, ensuring that the repair code can be correctly loaded and executed in the simulation environment.

[0125] Furthermore, after the candidate component code is generated, it is sent to a cloud-based vehicle-scale simulation environment for execution. This simulation environment uses the same instance as the initial code detection phase, including a virtualized running instance of the target vehicle operating system and a vehicle bus signal simulation module. The operating system virtual instance loads the candidate component code and allocates sandbox runtime resources, with a sandbox memory limit of 50 megabytes. The vehicle bus signal simulation module replays the same CAN bus message log file as in the initial detection phase. This file contains approximately thirty minutes of real driving data, covering the entire process of engine start-up, idling, acceleration, constant speed, and engine shutdown, ensuring that the candidate component code runs under a consistent vehicle operating condition sequence. Static analysis tools and dynamic instrumentation tools simultaneously perform full-scale violation detection, covering all 47 types of automotive-grade violations recorded by the system. The static analysis tool scans the code line by line and compares it against the MISRA-C rule set, while the dynamic instrumentation tool records execution time and memory allocation at function entry and exit points. After the detection is completed, a violation list for this round is output, with each record containing a violation type label and the start and end line numbers of the violation code fragment.

[0126] Specifically, branching is performed based on the detection results. If the violation list is empty, it indicates that the first repair code generated by S301 has eliminated the original violation and has not introduced any new violations. The candidate component code passes all automotive-grade tests, and this candidate component code is determined as the second component code, output to S103 in the form of a programming language source code file. If the violation list is not empty, it indicates that there are still violations in the candidate component code. This may be a partial remnant of the original violation type, or it may be that the repair operation has introduced a new type of violation. At this time, all violation type labels and violation code fragments recorded in the violation list are extracted and fed back to S301 as input for a new round of repair. S301 re-executes the complete process from S401 to S403: converting the new violation type label into a first embedding vector, extracting the abstract syntax tree of the new violation code fragment and encoding it into a code semantic vector, concatenating them and inputting them into the code repair model to generate a new round of first repair code; the new round of first repair code is then replaced by S501 to generate new candidate component code, which is sent to S502 for simulation and testing, forming a closed-loop iteration between S301 and S302.

[0127] Specifically, there are two exit conditions for the iteration: Exit condition one: After a certain iteration, the violation list of the S502 detection result is empty, the repair goal is achieved, and the current candidate component code is output as the second component code. Exit condition two: If the violation list is still not empty after the preset limit of 5 iterations, the iteration stops, the component is marked as requiring manual review, an exception log is written, and the operations and maintenance personnel are notified. A stagnation detection mechanism is also set during the iteration process: If the number of violation items in the violation list is the same in two consecutive iterations, it is determined that the code repair model cannot produce an effective repair for the current violation mode, the iteration is terminated in advance, and it is marked as requiring manual review.

[0128] As an optional implementation, the maximum number of iterations is dynamically adjusted based on the classification of the violation type. The system divides 47 violation types into three levels according to their safety impact: Level 1 includes violations related to driving safety, such as main thread timeout blocking and memory overruns (2 types), with the iteration limit increased to 8 times; Level 2 includes violations related to functional safety, such as MISRA-C mandatory rule violations (18 types), with the iteration limit remaining at 5 times; Level 3 includes violations related to code style and maintainability (27 types), with the iteration limit reduced to 3 times. Each iteration round determines the applicable iteration limit based on the highest-level violation type in the current violation list.

[0129] Preferably, the remediation and verification processes are organized into a closed loop. The remediation model not only relies on the remediation patterns learned during training but also utilizes the results of simulated environment detection as real feedback signals, enabling it to adapt to violation combinations not seen in the training set. The iterative closed loop allows code segments involving multiple types of overlapping violations to receive multiple rounds of correction opportunities, with each round further approaching full compliance based on the previous round's remediation results. A stagnation detection mechanism and a tiered iteration cap strike a balance between remediation effectiveness and computational cost: more remediation attempts are given to violation types with high security impact, while the number of iterations is limited for low-impact violation types to control pipeline latency. The second component code, output after multiple rounds of verification and convergence, provides reliable input for downstream compilation and deployment.

[0130] Furthermore, the hardware fingerprint of the target vehicle is received, and the target compilation parameters are determined according to a preset compilation configuration strategy. The second component code is then compiled using the target compilation parameters to obtain the target component package, which includes:

[0131] S601. Match the hardware fingerprint in the preset compilation configuration strategy to filter out the target compilation parameters;

[0132] S602. Compile the code of the second component according to the compilation options in the target compilation parameters, filter out the interfaces that are not in the system call clipping whitelist in the target compilation parameters, and replace them to obtain the target component package.

[0133] In this embodiment, the target vehicle infotainment system reports its hardware fingerprint upon initial registration with the cloud service. The hardware fingerprint consists of seven fields: operating system type, operating system version number, processor architecture, graphics framework name and version, screen resolution width, screen resolution height, and security chip model. The compilation configuration strategy is stored in a relational data table in the cloud database. Each record in the table contains the aforementioned seven hardware fingerprint fields and a set of compilation parameters, including the compiler name, a list of compilation optimization options, a system call pruning whitelist, a signature certificate identifier, and a packaging format. This data table is initially entered by maintenance personnel based on the compilation adaptation parameters for known vehicle models. Subsequently, after each adaptation compilation for a new vehicle infotainment model, the correspondence between the hardware fingerprint and the compilation parameters used is appended as a new record.

[0134] Specifically, the matching process is divided into three levels. The first level is full-field equality matching: the seven fields of the target vehicle hardware fingerprint are compared one by one with the corresponding fields of each historical record in the table. If a record exists where all fields are identical, the compilation parameters associated with that record are directly extracted as the target compilation parameters. The second level of matching is triggered when the first level fails: records with the same operating system type and processor architecture as the target vehicle are selected from the table to form a candidate record set; if the candidate record set is empty, the requirement is relaxed to only have the same processor architecture. The third level of matching performs the closest screen resolution calculation on the candidate record set: the screen resolution width and height of each candidate record are read, and the total number of pixels is calculated as width multiplied by height; the total number of pixels is also calculated for the target vehicle hardware fingerprint; the absolute value of the difference between the two total pixel counts is taken to obtain the total pixel count difference; the candidate record set is traversed, and the compilation parameters corresponding to the record with the smallest total pixel count difference are taken as the target compilation parameters.

[0135] Preferably, the mapping from hardware fingerprints to compilation parameters is organized into a hierarchical degradation matching method: full-field equivalence matching allows already adapted vehicle models to directly reuse verified compilation parameters; operating system type and processor architecture serve as secondary matching anchors to ensure that the instruction set and system calls output by the compilation are compatible with the underlying layer of the target vehicle system; and screen resolution closest matching selects the compilation configuration with the smallest interface layout difference based on the satisfaction of the first two constraints, reducing interface misalignment caused by resolution mismatch. Hierarchical matching enables new vehicle system hardware configurations that are not fully registered in the strategy table to obtain usable compilation parameters, providing automatic adaptation capabilities for new vehicle models.

[0136] Furthermore, a list of compilation options is extracted from the target compilation parameters, including the compiler name and compilation optimization options. The compiler name points to the cross-compilation toolchain deployed in the cloud, and the compilation optimization options include optimization levels and macro definition parameters. This compilation toolchain is then invoked to perform cross-compilation on the second component code, and the compilation output is intermediate platform code, in the form of ARM64 architecture binary object files or DEX bytecode.

[0137] After compilation, the system call pruning whitelist is read from the target compilation parameters. The system call pruning whitelist is a list of strings, each entry representing a system call function name. This whitelist is determined based on the platform API compliance documentation provided by the vehicle infotainment system manufacturer, and only lists system calls publicly available in the target vehicle infotainment system kernel that have passed functional safety certification. If this field is not included in the target compilation parameters, pruning is skipped, and the process proceeds directly to signing and packaging.

[0138] If this field is included, perform a static scan on the intermediate platform code: use a disassembler to parse the symbol table and relocation table of the intermediate platform code, extract all imported system call function names, and compare them one by one with the system call trimming whitelist. Calls that exist in the whitelist are retained. For calls that are not in the whitelist but have equivalent calls in the preset system call mapping table, replace the call instructions for that function in the intermediate platform code with equivalent system call instructions, and adjust the parameter passing method and return value processing logic to match the number and type of parameters of the equivalent call. The system call mapping table is a key-value pair lookup table, manually compiled according to the API difference documents of each vehicle operating system. For calls that are neither in the whitelist nor in the mapping table, insert an empty implementation stub function in the intermediate platform code. The function signature of the stub function is consistent with the original system call, and the function body only returns the default value or success status code to prevent undefined symbol errors during the linking stage. A log output statement with a degradation processing mark is inserted at the entry point of the stub function.

[0139] Specifically, the signing and packaging process selects the signature algorithm based on the proportion of control function code in the second component code. It scans the call statements of each ECU interface in the second component code; if the called interface is marked as a driving control interface in the vehicle capability model, then that line of code is marked as control function code. The proportion of control function code lines to the total number of lines in the second component code is calculated and compared to a preset control proportion threshold of 15%. If the proportion exceeds the threshold, the cloud-based hardware security module is invoked, and the signature value is calculated using the SM2 elliptic curve algorithm and the module's private key to the component package manifest file. If the proportion does not exceed the threshold, the signature value is calculated using the RSA-2048 algorithm and a software key. The signature value is written to the component package signature block and packaged into a target platform component package according to the OTA standard format.

[0140] Preferably, at the system call level, whitelist filtering and mapping replacement are used to process all paths in the intermediate platform code that call uncertified system calls. Components will not be rejected by the kernel or trigger security exceptions due to illegal system calls during runtime. The equivalent replacement driven by the mapping table ensures that functional logic is preserved within compliance boundaries. At the signature level, the signature strength is dynamically selected based on the proportion of control function code. Components involved in vehicle control receive signature protection at the hardware security module level to prevent the component package from being tampered with during transmission or storage and then injected into the vehicle system. Pure interface components use RSA signatures with lower computational overhead to control compilation latency.

[0141] Furthermore, the hardware fingerprint is matched against a pre-defined compilation configuration strategy to filter out target compilation parameters, including:

[0142] S701. Compare the hardware fingerprint with the historical hardware fingerprint records stored in the preset compilation configuration strategy, wherein each historical hardware fingerprint record is associated with a set of compilation parameters.

[0143] S702. If a historical hardware fingerprint record that matches the hardware fingerprint exists, extract the corresponding associated compilation parameters as the target compilation parameters.

[0144] S703. If there is no historical hardware fingerprint record that matches the hardware fingerprint, select the historical hardware fingerprint record with the same operating system type and processor architecture as the hardware fingerprint from multiple historical hardware fingerprint records to obtain a candidate record set; in the candidate record set, select the compilation parameters associated with the record whose screen resolution is closest to the screen resolution of the hardware fingerprint, and use them as the target compilation parameters.

[0145] In this embodiment, the compilation configuration strategy is stored in a cloud database as a relational data table. Each record in the table corresponds to a successfully adapted vehicle infotainment system hardware configuration and includes seven hardware fingerprint fields and a set of compilation parameters. The seven hardware fingerprint fields are: operating system type, operating system version number, processor architecture, graphics framework name and version, screen resolution width, screen resolution height, and security chip model. The compilation parameters include compiler name, a list of compilation optimization options, a system call trimming whitelist, signature certificate identifier, and packaging format. This data table is entered by maintenance personnel in the initial stage of system deployment based on the compilation adaptation parameters of known vehicle models. Subsequently, after each adaptation compilation for a new vehicle infotainment system model, the hardware fingerprint and compilation parameters used are appended as a new record.

[0146] Specifically, when the target vehicle's infotainment system registers with the cloud service for the first time, it reports its hardware fingerprint, with the same field structure as the historical records. Each of the seven fields of the target system's hardware fingerprint is compared one by one with the corresponding field in each historical record in the compilation configuration strategy table, recording the match or non-match result for each field. This field-by-field comparison of the hardware fingerprint with the strategy table provides the data foundation for subsequent tiered matching. The seven fields cover the complete technology stack from the underlying instruction set to upper-level graphics rendering and security hardware, enabling the selection of compilation parameters to evaluate the similarity between the target vehicle's infotainment system and historically adapted vehicle models across multiple dimensions.

[0147] Specifically, after the comparison is completed, it is determined whether there is a record in the strategy table whose seven fields all match the target vehicle system hardware fingerprint. A complete match means that all seven fields are the same: operating system type, operating system version number, processor architecture, graphics framework name and version, screen resolution width, screen resolution height, and security chip model.

[0148] When a record with all matches exists, the compilation parameter group associated with that record is read, and the compiler name, compilation optimization option list, system call trimming whitelist, signature certificate identifier, and packaging format are all extracted and output as the target compilation parameters. The matching process ends, and S703 is no longer executed.

[0149] Preferably, the compilation parameters are precisely reused for already adapted vehicle models. Full-field equivalence matching ensures that the hardware environment of the target vehicle system is completely consistent with a previously verified successful compilation adaptation. The extracted compilation parameters have been practically verified, and the compatibility and performance of the compiled component packages on this vehicle model have been confirmed. Precise reuse avoids re-inferring parameters for each compilation, saving computational resources and eliminating compilation failures or runtime compatibility issues caused by incorrect parameter inference. The strategy table continuously expands as the number of adapted vehicle models increases, gradually broadening the coverage of adapted vehicle models and improving the full-field hit rate.

[0150] When no single historical record in the strategy table matches all seven fields of the target vehicle hardware fingerprint, a tiered degradation matching process is triggered. Level 1 degradation: Records in the strategy table whose operating system type and processor architecture are identical to the target vehicle hardware fingerprint are selected to form a candidate record set. The operating system type determines the system call interface and executable file format, while the processor architecture determines the instruction set encoding; these two fields are fundamental to binary compatibility in compilation output. If the candidate record set is empty, the process degrades to selecting only by processor architecture, reconstructing the candidate record set. Level 2 degradation: A closest screen resolution matching process is performed on the candidate record set. For each record in the candidate record set, its screen resolution width and height are read, and the total number of pixels (width multiplied by height) is calculated. The same calculation is performed on the target vehicle hardware fingerprint. The absolute value of the difference between the two total pixel counts is taken to obtain the total pixel count difference. The candidate record set is traversed, and the compilation parameters corresponding to the record with the smallest total pixel count difference are taken as the target compilation parameters. If multiple records have the same total pixel count difference, the record with the most recent write time in the strategy table is selected.

[0151] Preferably, the operating system type and processor architecture serve as the first-level degradation anchor point, ensuring that the compiled instruction set and system calls are compatible with the target vehicle infotainment system's underlying layer. This is a prerequisite for the component to start and run on the target vehicle infotainment system. For screen resolution matching, based on satisfying the first two constraints, the compilation parameters corresponding to the historical adaptation record that is closest to the pixel scale of the target vehicle infotainment system's screen are selected. The interface layout parameters and graphics buffer configuration in these compilation parameters have the smallest deviation from the target vehicle infotainment system's screen size, resulting in the least degree of stretching, cropping, or whitespace in the component interface. The total number of pixels, as a measure of screen resolution difference, comprehensively considers the deviations in width and height, providing a more comprehensive comparison than comparing only a single dimension.

[0152] Furthermore, based on the compilation options in the target compilation parameters, the code of the second component is compiled, and interfaces not in the system call pruning whitelist in the target compilation parameters are filtered out and replaced to obtain the target component package, including:

[0153] S801. Using the compilation options in the target compilation parameters, compile the code of the second component to generate intermediate platform code;

[0154] S802. Scan the system call interfaces called in the intermediate platform code, replace system calls not in the system call trimming whitelist with equivalent system calls supported by the target vehicle, and obtain the target component package.

[0155] In this embodiment, the target compilation parameters include a list of compilation options, which consists of a compiler name and compilation optimization options. The compiler name is a string pointing to a specific cross-compilation toolchain deployed in a cloud-based compilation cluster. This toolchain compiles the source code into executable code using the ARM64 instruction set and links it to the system libraries of the target vehicle operating system. The compilation optimization options include optimization level parameters and macro definition parameters.

[0156] Specifically, the optimization level parameters are determined based on the target vehicle infotainment system's hardware specifications: for systems with a processor clock speed below 1GHz or memory capacity less than 2GB, the Os optimization level is selected, aiming to minimize code size; for systems with a processor clock speed of at least 1GHz and memory capacity of at least 2GB, the O2 optimization level is selected, aiming to optimize execution speed. Macro definition parameters specify compile-time constants in key-value pair form. For example, the screen resolution width macro takes the screen resolution width value from the target vehicle infotainment system's hardware fingerprint, and the screen resolution height macro takes the screen resolution height value.

[0157] During compilation and execution, the cloud-based compilation cluster creates a sandboxed compilation container, passing the source code files of the second component and a list of compilation options into the container. The compilation toolchain first performs a preprocessing stage, expanding all macro definitions and replacing corresponding constant values, and processing conditional compilation directives. The preprocessed code undergoes lexical and syntax analysis to generate an intermediate representation. The backend compilation module converts the intermediate representation into ARM64 assembly instructions, the assembler converts it into binary machine code, and the linker links the compiled object files with the system libraries and runtime libraries of the target vehicle operating system to generate executable intermediate platform code. The specific format of the intermediate platform code depends on the type of the target vehicle operating system.

[0158] Preferably, the optimization level is adaptively selected based on the target vehicle infotainment system's hardware specifications. Low-resource vehicle infotainment systems employ volume optimization to reduce storage footprint and transmission bandwidth, while high-resource vehicle infotainment systems employ speed optimization to improve runtime responsiveness. Macro-defined parameters inject hardware parameters such as screen resolution into the component code as compile-time constants, enabling the component to adapt to the target screen size during the compilation phase. At runtime, there is no need to perform resolution detection and dynamic layout calculations, reducing initialization time and runtime memory overhead.

[0159] Furthermore, the system call pruning whitelist is read from the target compilation parameters. The system call pruning whitelist is a string array, where each element is a system call function name. This whitelist is determined based on the platform API compliance documentation provided by the target vehicle infotainment system manufacturer, listing only system calls publicly available in the operating system kernel that have passed functional safety certification. If this field is not included in the target compilation parameters, the pruning step is skipped, and the process proceeds directly to signing and packaging.

[0160] If this field is included, perform a static scan on the intermediate platform code. Use a disassembler to parse the symbol table and relocation table of the intermediate platform code, traverse all symbol entries in the relocation table that require dynamic relocation, extract the symbol name of each entry, and obtain a list of all system call function names imported by the intermediate platform code. Perform a full string match comparison between each system call function name in the list and the entries in the system call pruning whitelist.

[0161] Specifically, the comparison results are handled in three ways: First, if the system call function name exists in the whitelist, the call is retained unchanged; second, if the system call function name is not in the whitelist, but there is a corresponding entry in the preset system call mapping table, the system call mapping table is a collection of key-value pairs, which is manually compiled line by line according to the API difference documents of each vehicle operating system. The key is the source system call function name, and the value is the equivalent system call function name and parameter mapping rules in the target vehicle operating system. During replacement, the symbol table and relocation table of the intermediate platform code are modified, replacing the symbol names of the original system calls with the symbol names of the equivalent system calls. At the same time, parameter conversion code is inserted at the call location according to the parameter mapping rules, and the number and order of parameters are adjusted to match the calling convention. The third method is to insert an empty implementation stub function in the intermediate platform code when the system call function name is neither in the whitelist nor in the mapping table. The function signature of the stub function is completely consistent with the original system call, and the function body only returns the default value or success status code. A log output statement is inserted at the function entry point to record the timestamp of the call and the name of the original system call function. After the stub function is compiled, it is linked into the intermediate platform code, and the relocation of the original call location points to the address of the stub function.

[0162] After all system calls not in the whitelist have been processed, the modified symbol table and relocation table are written back to the intermediate platform code file, resulting in the trimmed and replaced intermediate platform code.

[0163] As an optional implementation, for the stub function inserted in the third case, degradation logic can also be added to the stub function body. When the function of the original system call can be partially replaced, the stub function calls other legitimate API combinations provided by the target vehicle operating system to achieve an approximate effect, rather than simply returning the default value.

[0164] Specifically, after the trimming and replacement are completed, the target component package is digitally signed and encapsulated in the OTA standard format using the signature certificate identifier and packaging format determined by S601.

[0165] Preferably, all system call paths that have not passed functional safety certification are identified through whitelist filtering, ensuring that the component is not intercepted by kernel security policies or triggers abnormal termination when running on the target vehicle system. The equivalent replacement driven by the mapping table ensures that the functional logic is preserved within the compliance boundary, and the core business logic of the component is not lost due to the unavailability of system calls; the insertion of stub functions provides lossless degradation for system calls for which no equivalent replacement can be found, without errors during the linking stage, and runtime calls to stub functions only log without crashing. Operation and maintenance personnel can discover degraded calls through log auditing and add corresponding mapping rules in subsequent versions; the processed target platform component package has eliminated the platform system call compatibility risks.

[0166] Furthermore, the target component package is distributed to the target vehicle for onboard component deployment, including:

[0167] S901. Deploy the target component package to the shadow partition of the target vehicle, trigger a silent installation within the shadow partition, and perform a smoke test.

[0168] S902. If the smoke test passes, activate the installed components in the shadow partition and make them visible to the user;

[0169] S903. If the smoke test fails, delete the installation contents in the shadow partition and report a silent deployment failure status code.

[0170] In this embodiment, after the deployment security index is calculated and falls within the allowable deployment range, the target platform component package is sent to the target vehicle infotainment system via the OTA channel. The sending is performed in chunks, with each data block being 256 kilobytes in size, and a CRC32 checksum appended to the end of each block. The vehicle infotainment system's OTA receiving module verifies the integrity of each block. If a block fails verification, it requests a retransmission of that block from the cloud, with a maximum of three retransmissions. If this limit is exceeded, the deployment is terminated, and a transmission failure status code is returned. After all data blocks pass verification, the OTA receiving module reassembles the blocks according to their sequence numbers to reconstruct the target platform component package file.

[0171] The vehicle's infotainment system storage chip has an independent shadow partition, which is logically isolated from the system partition and user data partition currently running on the vehicle's infotainment system. It has its own independent inode table and data block mapping. The target platform component package is written to the shadow partition, and the writing is performed sector by sector. After each sector is written, it is read back for verification to ensure that the storage medium is written without errors.

[0172] After writing is complete, a silent installation process is triggered within the shadow partition. Silent installation means that the installation process does not pop up dialog boxes, does not request user confirmation, and does not display progress in the notification bar; it completes unpacking, file extraction, and component manifest updates in the background. During the installation process, processor usage is monitored. If the processor usage exceeds 85% and remains above 5 seconds, the installation process is actively slowed down, and the file extraction interval is adjusted to a 100-millisecond sleep after each file extraction, freeing up processor time slices for currently running vehicle-related processes.

[0173] Specifically, a smoke test is performed immediately after installation in the shadow partition. The smoke test includes three checks. Check 1 is component process startup detection: the system sends a startup command to the component's entry function and waits for the component process PID to return. If a valid PID is returned within the preset timeout period of 10 seconds, the test passes; otherwise, it fails if the timeout expires or an error code is returned. Check 2 is ECU interface return value format verification: after the component starts, it sequentially calls all its bound ECU service interfaces. After each interface call, it waits for a return value and compares it with the return value type and value range defined in the vehicle capability model. If the JSON key name, data type, and value range of the return value all conform to the definition, the test passes; otherwise, it fails. Check 3 is interface rendering anomaly detection: the system captures the first frame of the component's rendering buffer and compares it pixel-by-pixel with a pre-stored standard layout screenshot in the cloud. If the percentage of differing pixels is less than 5% of a preset threshold, the test passes; otherwise, it fails. The execution results of the three checks form a smoke test report. Each result includes the check item number, pass / fail status, and an error description for failure.

[0174] Preferably, distribution, installation, and testing are confined to the shadow partition, without touching any data in the vehicle's currently running partition, so that the user is unaware of it in the front-end interface; block transmission with CRC32 checksum ensures the integrity of component packets during wireless transmission, and a retransmission mechanism handles transmission interruptions when signal coverage is weak. Smoke testing completes functional verification before the component becomes visible to the user. The three checks cover the process lifecycle, ECU communication correctness, and interface rendering quality, constituting a layered verification from the bottom layer operation to the top layer display.

[0175] Furthermore, when the smoke test report shows that all three checks have passed, the S902 activation process begins. The vehicle system sends an activation command to the component manager, with parameters including the package name and version number of the components already installed in the shadow partition. The component manager maintains a global component registry, storing the package name, version number, installation path, and activation status of all available components in the current system in a key-value pair structure. Upon receiving the activation command, the component manager checks the global component registry for an existing record of a component with the same package name. If it does not exist, the package name, version number, and shadow partition installation path of the new component are written to the registry, and the activation status field is set to active. If an existing record of a component with the same package name exists, the active status of the existing component is set to backup, its installation path is renamed to the backup path, and the package name, version number, and shadow partition installation path of the new component are written to the registry and set to active. Simultaneously, the backup path of the old version component is recorded for subsequent rollback.

[0176] After the registry update is complete, the component manager notifies the vehicle's main screen rendering process to refresh the component list. The main screen rendering process reads all active component records from the global component registry, loads the icon resources and entry configurations for each component one by one, renders the entry icons for each component in the main screen widget area, and binds touch events. The user sees the entry icon of the newly deployed component on the main screen. After clicking the icon, the system loads and displays the full interface of that component from the shadow partition.

[0177] Preferably, new component activation and old component backup are completed through atomic registry updates. The registry writing and activation state switching are performed in the same transaction, avoiding inconsistent intermediate states read by the component manager. The coexistence of new and old versions in backup allows for quick rollback when problems occur with new components, without the need to redeploy the old version component package. The main screen rendering process detects changes in the component list through an event-driven approach, without requiring users to manually refresh or restart the vehicle system.

[0178] Specifically, if any check item in the smoke test report fails, the S903 rollback process is initiated. The vehicle system sends a clear command to the shadow partition management module, specifying the starting address and length of all storage blocks occupied by the deployed components. The shadow partition management module traverses all allocated sectors within this address range, performing a secure erase sector by sector, writing all zeros to each sector to prevent recovery of component content through residual data on the storage medium. After erasure, the corresponding sectors are marked as free and reclaimed into the shadow partition available space pool.

[0179] After the erase is complete, a silent deployment failure status code is sent to the cloud server. The silent deployment failure status code consists of a main status code and sub-status codes connected by a hyphen. The main status code value 2 indicates failure in the smoke test phase. Sub-status codes value 1 indicates component process startup failure, value 2 indicates ECU interface return value verification failure, value 3 indicates UI rendering error, and value 4 indicates multiple checks failed. Following the status code are a timestamp field and a free text field. The timestamp records the vehicle's local time when the failure occurred, and the free text field contains a brief description of the failed checks, such as the specific interface name, expected return value type, and actual return value content when the ECU interface return value verification failed. Upon receiving the failure status code, the cloud server writes it to the deployment log database, triggering the operation and maintenance alarm process.

[0180] As an optional implementation, when the smoke test fails and there is a backup of an older version of the component with the same package name, the system restores the activation status of the older version component in the backup path to active after performing the wipe, and notifies the main screen rendering process to restore the entry point of the older version component, so that the user is unaware of the deployment failure.

[0181] Preferably, a complete cleanup is performed when the smoke test fails, ensuring that no failed deployment component files or configuration items remain in the shadow partition, preventing corrupted component files from occupying storage space or being mistakenly loaded in the next deployment; secure erasure eliminates the risk of data residue at the storage media level; the precise definition of the silent deployment failure status code enables the cloud to distinguish different failure reasons in the smoke test phase, and maintenance personnel can directly locate the problem type based on the sub-status code without having to check the logs on the vehicle terminal.

[0182] like Figure 2 As shown, an in-vehicle component generation and deployment system based on a multi-stage pipeline is used to implement an in-vehicle component generation and deployment method based on a multi-stage pipeline, including:

[0183] The functional requirements analysis module acquires the user-input requirement text and performs semantic parsing. It then matches the parsing results with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints. The vehicle capability model includes the service interfaces and access restrictions provided by the vehicle electronic control unit.

[0184] The code optimization module generates the first component code based on the first functional requirement, simulates the operation of the first component code to detect vehicle violations, and optimizes the code based on the violation type and violation code snippet to obtain the second component code;

[0185] The component compilation module receives the hardware fingerprint of the target vehicle, determines the target compilation parameters according to the preset compilation configuration strategy, and compiles the second component code using the target compilation parameters to obtain the target component package;

[0186] The component deployment module calculates the deployment security index based on the real-time status information of the target vehicle and the component security level corresponding to the target component package. If the deployment security index is within the preset deployment range, the target component package is sent to the target vehicle for vehicle component deployment.

[0187] The above description is merely a preferred embodiment of this application. The scope of protection of this application is not limited to the above embodiments. All technical solutions falling within the scope of this application's concept are within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application should also be considered within the scope of protection of this application.

Claims

1. A method for generating and deploying vehicle-mounted components based on a multi-stage pipeline, characterized in that, include: The system acquires the user's input requirement text and performs semantic parsing. The parsing result is then matched with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints. The vehicle capability model includes the service interfaces and access restrictions provided by the vehicle electronic control unit. The first component code is generated based on the first functional requirements, and the first component code is simulated to detect vehicle violations. The code is then optimized based on the violation type and violation code snippet to obtain the second component code. The hardware fingerprint is compared with the historical hardware fingerprint records stored in the pre-configured compilation strategy, where each historical hardware fingerprint record is associated with a set of compilation parameters. If a historical hardware fingerprint record that matches the hardware fingerprint exists, extract the corresponding associated compilation parameters as the target compilation parameters; If no historical hardware fingerprint record matches the hardware fingerprint, select historical hardware fingerprint records with the same operating system type and processor architecture as the hardware fingerprint from multiple historical hardware fingerprint records to obtain a candidate record set; in the candidate record set, select the compilation parameters associated with the record whose screen resolution is closest to the screen resolution of the hardware fingerprint, and use them as the target compilation parameters. Based on the compilation options in the target compilation parameters, the code of the second component is compiled, and the interfaces that are not in the system call pruning whitelist in the target compilation parameters are filtered out and replaced to obtain the target component package; Based on the real-time status information of the target vehicle and the security level of the corresponding component in the target component package, the deployment security index is calculated. If the deployment security index is within the preset deployment range, the target component package is sent to the target vehicle for vehicle component deployment.

2. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 1, characterized in that, The process involves obtaining the user's input requirement text, performing semantic parsing, and matching the parsing results with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints, including: Acquire the user's voice input and convert it into the required text; Perform syntactic analysis and named entity recognition on the requirement text to extract the functional intent description and operation object entity; The functional intent description and the entity to be operated are matched with the service interfaces in the pre-built vehicle capability model. Functional descriptions and interface constraints with similarity greater than a preset matching threshold are selected to obtain the first functional requirement.

3. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 1, characterized in that, The code optimization based on the violation type and violation code snippet yields the second component code, including: The violation type is converted into a first embedding vector, a code semantic vector is generated according to the violation code fragment, the code is repaired, and the first repaired code is obtained; The code is optimized based on the first repair code, and the running behavior of the optimized code is simulated to obtain the code for the second component.

4. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 3, characterized in that, The process of converting the violation type into a first embedding vector, generating a code semantic vector according to the violation code fragment, and repairing the code to obtain the first repaired code includes: Convert the violation type into the first embedding vector; Extract the abstract syntax tree of the illegal code snippet, perform structural encoding on the abstract syntax tree, and generate a code semantic vector; The code semantic vector is concatenated with the first embedding vector, and then input into a preset code repair model to repair the code, thereby obtaining the first repaired code.

5. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 4, characterized in that, The process of optimizing the code based on the first repair code and simulating the operation of the optimized code to obtain the second component code includes: Replace the violating code snippet with the first corrected code to obtain the candidate component code; The candidate component code is simulated and the vehicle violation is detected. If the vehicle violation is eliminated, the candidate component code is used as the second component code. If a vehicle violation is detected, the violation information of the candidate component code is input into the code repair model for repair until the vehicle violation is eliminated, and the second component code is obtained.

6. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 1, characterized in that, The second component code is compiled according to the compilation options in the target compilation parameters, and interfaces not in the system call pruning whitelist in the target compilation parameters are filtered out and replaced to obtain the target component package, including: The second component code is compiled using the compilation options in the target compilation parameters to generate intermediate platform code; Scan the system call interfaces called in the intermediate platform code, replace system calls not in the system call pruning whitelist with equivalent system calls supported by the target vehicle, and obtain the target component package.

7. The method for generating and deploying vehicle-mounted components based on a multi-stage pipeline according to claim 1, characterized in that, The step of distributing the target component package to the target vehicle for onboard component deployment includes: The target component package is downloaded to the shadow partition of the target vehicle, and a silent installation is triggered in the shadow partition to perform a smoke test. If the smoke test passes, the installed components in the shadow partition are activated and made visible to the user; If the smoke test fails, delete the installation contents in the shadow partition and report a silent deployment failure status code.

8. A vehicle component production and deployment system based on a multi-stage pipeline, used to implement the vehicle component production and deployment method based on a multi-stage pipeline as described in any one of claims 1 to 7, characterized in that, include: The functional requirements analysis module acquires the user-input requirement text and performs semantic parsing. It then matches the parsing results with a pre-built vehicle capability model to generate a first functional requirement that includes a functional description and interface constraints. The vehicle capability model includes the service interfaces and access restrictions provided by the vehicle electronic control unit. The code optimization module generates the first component code based on the first functional requirement, simulates the operation of the first component code to detect vehicle violations, and optimizes the code based on the violation type and violation code snippet to obtain the second component code; The component compilation module receives the hardware fingerprint of the target vehicle, determines the target compilation parameters according to the preset compilation configuration strategy, and compiles the second component code using the target compilation parameters to obtain the target component package; The component deployment module calculates the deployment security index based on the real-time status information of the target vehicle and the component security level corresponding to the target component package. If the deployment security index is within the preset deployment range, the target component package is sent to the target vehicle for vehicle component deployment.

Images