A method, apparatus and vehicle for upgrading vehicle software

Abstract

This application provides a method, apparatus, and vehicle for upgrading vehicle software to solve the problem of upgrade failure or vehicle malfunction caused by compatibility issues in existing technologies. The method includes: constructing a version difference map based on the current software version and the target upgrade version of the target vehicle; using the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to a pre-set differential model to predict the risk type and test requirement suggestions for the current upgrade; automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and test requirement suggestions; the differential package refers to an upgrade package containing difference data between the current software version and the target upgrade version; automatically constructing a compatibility test case set based on the test requirement suggestions and performing automated testing on the differential package; and pushing the differential package to the target vehicle for upgrade execution after the automated testing passes.

Description

Technical Field

[0001] This application relates to the field of remote vehicle upgrades, specifically a method, apparatus, and vehicle for upgrading vehicle software. Background Technology

[0002] In current over-the-air (OTA) upgrade processes for vehicles, software version updates typically rely on manual analysis of compatibility risks between old and new versions. Engineers use their experience to determine if there are issues such as protocol changes or missing dependencies, and then manually write test cases for verification. However, with the increasing number of automotive electronic control units and the accelerated pace of software version iterations, manual analysis is insufficient to fully identify hidden compatibility issues between versions. Test case writing is inefficient and has limited coverage, and the generated upgrade packages cannot be tailored to specific vehicle configurations. When compatibility issues are exposed after the upgrade, they often lead to upgrade failure or vehicle malfunctions, severely impacting user experience and upgrade security. Summary of the Invention

[0003] This application provides a method, apparatus, and vehicle for upgrading vehicle software to solve the problem of upgrade failure or vehicle malfunction caused by compatibility issues in the prior art.

[0004] The technical solution of this application is as follows:

[0005] This application provides a method for upgrading vehicle software, including:

[0006] Based on the current software version and target upgrade version information of the target vehicle, a version difference map is constructed; the version difference map uses version number as a node, upgrade path as an edge, and ECU type and dependent component list as node attributes;

[0007] The attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map are used as input to a pre-set difference model, so that the pre-set difference model can predict the risk type and test requirement suggestions for this upgrade.

[0008] Based on the risk type and the test requirement suggestions, an upgrade package adapted to the current configuration of the target vehicle is automatically generated; the upgrade package refers to an upgrade package containing the difference data between the current software version and the target upgrade version.

[0009] Based on the aforementioned test requirements, a set of compatibility test cases is automatically constructed, and automated testing is performed on the differential package.

[0010] Once the automated test passes, the differential package is pushed to the target vehicle for the target vehicle to perform the upgrade.

[0011] By constructing a version difference graph with version number as the node and ECU type and dependent component list as node attributes, the originally scattered and unstructured version information is transformed into computer-recognizable graph structure data. Based on this version difference graph, the differences between the current version and the target version in ECU composition and dependent components can be automatically located and extracted, providing a clear input basis for subsequent automated risk analysis and eliminating subjective reliance on human experience. A pre-configured differential model, as a pre-configured analysis tool, can directly map input attribute differences to specific risk types and corresponding test requirements, achieving end-to-end automated processing from version differences to risk identification and test planning. Its effect is that a direct correspondence is formed between risk types and test requirement suggestions, with test requirements precisely targeting identified risks, avoiding judgment delays and coverage blind spots that may occur during manual item-by-item analysis. Since the package creation process is based on both risk types and test requirement suggestions, the content of the differential package maintains inherent consistency with the subsequent test verification objectives. The differential package is generated specifically for identified risks and is much smaller than the full package, resulting in higher transmission and installation efficiency, while eliminating compatibility issues with vehicle configurations at the structural level. Since the test case set is built directly based on the test requirement suggestions, which in turn come from the analysis of version differences, test execution can focus on scenarios that are highly relevant to the risks of this upgrade; test verification directly covers the key change points in the differential package, which can avoid redundant tests or test omissions that may be generated by general test templates, and achieve high verification accuracy at a lower cost.

[0012] Once the automated tests pass, the differential package is pushed to the target vehicle for upgrade execution. Because the differential package has already undergone automated testing based on test requirements suggestions before being pushed, the probability of failure or functional abnormalities due to compatibility issues during the actual upgrade process is significantly reduced. The effect is that by using test passing as a prerequisite for push, a complete closed loop is formed from risk identification, targeted package creation, precise testing to secure upgrade, improving the overall success rate of OTA upgrades.

[0013] In one possible embodiment, the step of constructing a version difference map based on the target vehicle's current software version and the target upgrade version information includes:

[0014] Each version number is created as a node in the graph;

[0015] Create directed edges between nodes in ascending order of version number;

[0016] The list of ECU types and dependent components associated with each version number are stored as attribute tags for the corresponding node.

[0017] By creating each version number as a node, establishing directed edges from low to high version numbers, and storing the ECU type list and dependent component list as node attribute labels, the version difference graph is constructed as a fully connected directed graph structure. Therefore, a reachable path exists between any two version nodes. When performing an upgrade from any current version to any target version, the complete upgrade path information between the two nodes can be automatically obtained from the graph without pre-configuration or manual specification of the upgrade path, thus providing a complete topological foundation for subsequent path selection and differential packet generation.

[0018] In one possible embodiment, the step of using the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to a pre-set difference model, so that the pre-set difference model can predict the risk type and test requirement suggestions for this upgrade, includes:

[0019] The differences in ECU type and dependent components between the node corresponding to the current software version and the node corresponding to the target upgrade version are encoded into feature vectors;

[0020] The feature vector is input into the preset difference model; the preset difference model adopts a graph attention network architecture and is trained based on historical OTA upgrade data;

[0021] The pre-defined differential model outputs risk types and test requirement suggestions; wherein, the risk types include one or more of protocol changes, missing dependencies, configuration conflicts, hardware compatibility, and timing dependencies; and the test requirement suggestions correspond to a predefined set of test scenarios.

[0022] By encoding the differences in ECU type and dependent components between the current and target version nodes into feature vectors, the structural differences between versions are transformed into numerical inputs. A pre-built difference model, trained on historical OTA upgrade data using a graph attention network architecture, can identify feature combinations related to historical success or failure modes from the feature vectors, and output specific risk types and corresponding test requirement suggestions. Thus, ECU type and dependent component differences are directly mapped to identifiable risk categories such as protocol changes, missing dependencies, configuration conflicts, hardware compatibility, and timing dependencies. Each risk category has a corresponding set of test scenarios for verification, establishing a clear correspondence between risk identification results and test execution content, avoiding potential risks missed during manual analysis and mismatches between test plans and risks.

[0023] In one possible embodiment, the step of automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestion; wherein the differential package refers to an upgrade package containing difference data between the current software version and the target upgrade version includes:

[0024] Based on the risk type, add or remove the corresponding compatibility patch in the differential package;

[0025] Based on the aforementioned test requirements, the range of ECU upgrade modules included in the differential package should be adjusted.

[0026] Based on the current configuration of the target vehicle, upgrade data blocks that are irrelevant to the target vehicle are removed, and a differential package containing only the upgrade data required by the target vehicle is generated.

[0027] By adding or removing corresponding compatibility patches in the differential package based on the type of risk, the content of the differential package is targeted to address the specific risks identified by the model, avoiding issues such as upgrade failures due to missing necessary patches or increased package size due to the inclusion of irrelevant patches in a generic differential package. By adjusting the scope of ECU upgrade modules according to test requirements, the upgrade modules included in the differential package are consistent with the goals of subsequent testing and verification, ensuring that all modules that have actually changed in the differential package are included in the test coverage. By trimming irrelevant upgrade data blocks according to the current configuration of the target vehicle, the differential package no longer contains data content unrelated to the target vehicle's hardware configuration and optional features. Through the combined effect of these three adjustment steps, the final differential package is functionally capable of addressing identified risks, aligned with test and verification goals in terms of scope, and retains only the data actually needed by the current vehicle in terms of size. This eliminates compatibility risks at the differential package structure level and reduces resource consumption for transmission and installation.

[0028] In one possible embodiment, the step of performing automated testing on the differential package includes:

[0029] Based on the aforementioned test requirements, retrieve the minimum matching test action from the predefined test action library;

[0030] The retrieved minimum test actions are combined in sequence to generate an executable test script;

[0031] The test script is executed in a simulation environment to simulate vehicle status, network conditions, and abnormal scenarios.

[0032] Collect logs and results data during test execution to generate automated test results.

[0033] By retrieving matching minimum test actions from a predefined test action library based on test requirements, test case construction is limited to operations directly related to the risks of this upgrade, avoiding testing of irrelevant functions or scenarios. By combining minimum test actions sequentially to generate executable test scripts, discrete individual operations are organized into a complete test sequence capable of simulating the real upgrade process. Executing test scripts in a simulation environment simulates changes in vehicle status, network fluctuations, and various abnormal scenarios, ensuring the differential package undergoes environmental verification similar to or even more stringent than actual upgrade conditions before push. By collecting logs and result data during test execution and generating automated test results, test execution status is quantified into evaluable data for determining pass / fail. Test execution precisely focuses on scenarios highly relevant to risk, test scripts are automatically generated without manual writing, and simulation verification avoids the costs and risks of testing on real vehicles, ultimately achieving low-cost, high-coverage, and automated verification of differential package compatibility.

[0034] In one possible embodiment, the method further includes:

[0035] The results of the automated test are fed back to the preset difference model;

[0036] The pre-set differential model is incrementally trained based on the test results, and the model parameters are updated.

[0037] The results of automated testing are fed back to the pre-built differential model. Successful cases and problems exposed during the test execution are transformed into training data that the model can learn from. The pre-built differential model performs incremental training and updates the model parameters based on the test results, so that the model can further learn the information from the actual test feedback in this upgrade based on the original training data.

[0038] In one possible embodiment, when multiple intermediate versions exist between the current software version and the target upgrade version, the step of automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestion includes:

[0039] Based on the historical success rate of each upgrade path in the version difference map, select the upgrade path with the highest success rate from the current software version to the target upgrade version, and generate a differential package based on the selected upgrade path.

[0040] When multiple intermediate versions exist, it can automatically avoid paths with historically low success rates and select the most reliable jump method to generate differential packages, thereby reducing the probability of upgrade failure in advance at the path selection level and improving the overall success rate of cross-version upgrades.

[0041] In one possible embodiment, the method further includes:

[0042] When the automated test fails, a test failure report is generated;

[0043] Based on the reasons for test failure recorded in the test failure report, re-execute at least one of the following steps:

[0044] Regenerate the differential packet;

[0045] Re-execute the automated test.

[0046] A test failure is not a termination signal, but rather a trigger for targeted correction. Re-packaging the package based on the cause of failure can specifically address the defects in the differential package. Re-executing the test can verify whether the corrected differential package has eliminated the defect. Thus, test failure becomes a direct input for differential package optimization, avoiding the inefficient approach of abandoning the upgrade process or requiring manual intervention due to a single test failure.

[0047] This application also provides a vehicle software upgrade device, including:

[0048] The version difference map construction module is used to construct a version difference map based on the current software version of the target vehicle and the target upgrade version information. The version difference map uses version number as a node, upgrade path as an edge, and ECU type and dependent component list as node attributes.

[0049] The model prediction module is used to take the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to the preset difference model, so that the preset difference model can predict the risk type and test requirement suggestions for this upgrade.

[0050] The differential package generation module is used to automatically generate a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestions; the differential package refers to an upgrade package containing the difference data between the current software version and the target upgrade version;

[0051] The testing module is used to automatically build a set of compatibility test cases based on the test requirements and to perform automated testing on the differential package.

[0052] The upgrade module is used to push the differential package to the target vehicle after the automated test passes, so that the target vehicle can perform the upgrade.

[0053] This application also provides a vehicle on which a differential package is deployed according to the above-described vehicle software upgrade method. Attached Figure Description

[0054] Figure 1This is a flowchart illustrating the vehicle software upgrade method in the embodiments of this application;

[0055] Figure 2 This is a structural block diagram of the vehicle software upgrade device in the embodiments of this application. Detailed Implementation

[0056] Reference Figure 1 This application provides a method for upgrading vehicle software, including:

[0057] S101, construct a version difference map based on the current software version and target upgrade version information of the target vehicle; the version difference map uses version number as a node, upgrade path as an edge, and ECU type and dependent component list as node attributes;

[0058] S102, the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map are used as input to the preset difference model, so that the preset difference model can predict the risk type and test requirement suggestions for this upgrade.

[0059] S103, Based on the risk type and the test requirement suggestion, automatically generate a differential package adapted to the current configuration of the target vehicle; the differential package refers to an upgrade package containing the difference data between the current software version and the target upgrade version;

[0060] S104. Based on the test requirement suggestions, automatically construct a set of compatibility test cases and perform automated testing on the differential package;

[0061] S105, after the automated test passes, the differential package is pushed to the target vehicle for the target vehicle to perform the upgrade.

[0062] In step S101, the current software version information of the target vehicle is obtained from the vehicle software list reported by the vehicle. This list records the software version number, ECU type identifier, and list of currently installed dependent components for each electronic control unit (ECU) currently installed in the vehicle. The target upgrade version information is obtained from the version release management system of the OTA platform. This information includes the version number of the target version, the list of ECU types involved in the version, and the list of components required for the normal operation of the version.

[0063] When constructing the version difference graph, software version numbers are used as nodes, with each version number registered on the OTA platform corresponding to an independent node in the graph. After node creation, the list of ECU types and dependent components associated with that version number are attached as attribute tags to the node. An upgrade path refers to a feasible jump relationship from one version number to another, represented by directed edges pointing from a lower version number to a higher version number.

[0064] The upgrade path is determined by pre-configured allowed upgrade paths and successfully executed upgrade paths extracted from historical OTA upgrade records. The completed version difference graph is stored in the OTA platform server. Each node stores its version number identifier, ECU type list, dependent component list, and set of edges. Each edge stores its source node, target node, and statistical data such as historical execution count and success count.

[0065] In other words, in this embodiment of the application, the step S101 of constructing a version difference map based on the current software version and target upgrade version information of the target vehicle includes:

[0066] Each version number is created as a node in the graph;

[0067] Create directed edges between nodes in ascending order of version number;

[0068] The list of ECU types and dependent components associated with each version number are stored as attribute tags for the corresponding node.

[0069] In step S102, the node corresponding to the current software version and the node corresponding to the target upgrade version are located from the version difference map constructed in S101. The attribute labels of the two nodes are read, including the list of ECU types and the list of dependent components associated with each node.

[0070] The calculation method for ECU type differences is as follows: Traverse the ECU type list of the target version node and check if each ECU type exists in the ECU type list of the current version node. If it exists, mark it as an existing ECU; otherwise, mark it as a newly added ECU. Conversely, traverse the ECU type list of the current version node and check if any ECU types that have been deleted from the target version node exist. Finally, output the list of newly added ECUs and the list of deleted ECUs as the ECU type difference vector.

[0071] The dependency component differences are calculated as follows: For each component in the dependency component list of the target version node, check if a component with the same name and version number meets the requirements exists in the dependency component list of the current version node. If the component name does not exist, it is marked as a new dependency; if the component name exists but the version number is lower than the required version, it is marked as a dependency version upgrade; if the component name exists and the version number meets the requirements, it is marked as a dependency satisfied; if a dependency exists in the current version but is no longer needed in the target version, it is marked as a redundant dependency. The final output includes a list of new dependencies, a list of dependency version upgrades, and a list of redundant dependencies, serving as the dependency component difference vector.

[0072] The ECU type difference vector and dependent component difference vector are numerically encoded to generate a fixed-dimensional feature vector. The encoding method is as follows: ECU type differences use multi-hot encoding. A global vocabulary containing all possible ECU types (e.g., 32 ECU types) is preset. The list of newly added ECUs and the list of deleted ECUs are mapped to two 32-dimensional binary vectors, where each dimension indicates whether the corresponding ECU type is newly added or deleted. These two vectors are concatenated to obtain a 64-dimensional ECU difference code. Dependent component differences use a similar encoding method. A global vocabulary containing all possible dependent components (e.g., 32 dependent components) is preset. New dependencies, dependency version upgrades, and redundant dependencies are mapped to three 32-dimensional binary vectors, respectively. These three vectors are concatenated to obtain a 96-dimensional dependency difference code. The 64-dimensional ECU difference code and the 96-dimensional dependency difference code are concatenated to obtain a 160-dimensional original feature vector. If it is necessary to match the standard input dimension of a pre-defined difference model (e.g., 256 dimensions), the 160-dimensional feature vector is padded with zeros to expand to 256 dimensions, or other auxiliary information such as version number features is added during the encoding stage.

[0073] The encoded feature vector is input into a pre-defined difference model. This model employs a graph attention network architecture and has been trained offline. The graph attention network architecture consists of an input layer, three graph attention layers, and an output layer. The input layer receives a 256-dimensional feature vector. The three graph attention layers progressively extract higher-order patterns and implicit associations from the features. Each layer includes a multi-head attention mechanism (4 attention heads), employing residual connections and layer normalization, with a dropout rate set to 0.3. The output layer is a fully connected network, containing a 64-dimensional hidden layer, a 32-dimensional hidden layer, and an 18-dimensional output layer.

[0074] The forward computation process of the graph attention network architecture is as follows: the feature vector is transformed through three graph attention layers in sequence. Each layer calculates the attention weights between nodes and aggregates neighborhood information, finally outputting an 18-dimensional original output vector. This 18-dimensional vector corresponds to three prediction tasks: the first 3 dimensions are used for risk level classification (high risk, medium risk, low risk), which are normalized to a probability distribution by the Softmax function; the middle 5 dimensions are used for multi-label classification of risk types (protocol change, dependency missing, configuration conflict, hardware compatibility, temporal dependency), which are mapped to the independent probability of each risk type by the Sigmoid function; the last 10 dimensions are used for multi-label classification of test requirements (corresponding to 10 predefined test scenarios), which are mapped to the recommendation probability of each test scenario by the Sigmoid function.

[0075] The 18-dimensional vector output by the model is parsed into readable risk types and test requirement suggestions. The rule for determining risk types is as follows: for each of the five risk types, if its sigmoid output probability is greater than a preset threshold (e.g., 0.5), then the upgrade is considered to involve that type of risk; if the probabilities of all risk types are below the threshold, then there is no definite risk. The rule for determining test requirement suggestions is as follows: for each of the ten test scenarios, if its sigmoid output probability is greater than a preset threshold (e.g., 0.6), then that test scenario is included in the test requirement suggestion list for this upgrade.

[0076] The output is passed to subsequent steps in the form of structured data. The risk type list is used in step SS103, the packaging stage, to determine which compatibility patches need to be added or removed. The test requirement suggestion list is used both in step S103, the packaging stage, to adjust the scope of the ECU upgrade module, and in step S104, the testing stage, to build the compatibility test case set.

[0077] The training of the pre-built differential model was completed before step S102. Training data was derived from historical upgrade records on the OTA platform. Each historical upgrade record contained information on the source version, target version, ECU type differences, dependent component differences, the actual risk type of the upgrade (manually or automatically labeled based on upgrade failure logs), the actual test scenario executed for the upgrade, and the final upgrade result (success or failure). The differential features in the historical records were encoded into feature vectors as training samples, and the corresponding risk type labels and test scenario labels were used as supervision signals. A weighted cross-entropy loss function was used to jointly optimize the three prediction tasks. After training, the model parameters were fixed and used for online inference in step S102. The model can be incrementally trained periodically using newly added upgrade records to continuously improve prediction accuracy.

[0078] In the above manner, step S102 automatically transforms the differences in ECU type and dependent components between the current version and the target version into specific risk types and test requirement suggestions, realizing end-to-end automated processing from version differences to risk identification and then to test planning.

[0079] The pre-built differential model needs to be trained offline before use. The training process aims to enable the model to learn the mapping relationship between version differences and compatibility risks from historical OTA upgrade data. The training process is described in detail below.

[0080] The training data comes from the historical upgrade record database of the OTA platform. Each historical upgrade record corresponds to a completed OTA upgrade task and includes the following information:

[0081] Source version information: The software version number of the vehicle before the upgrade, the list of ECU types associated with this version, and the list of dependent components associated with this version.

[0082] Target version information: Upgrade target version number, list of ECU types associated with this version, and list of dependent components associated with this version.

[0083] Upgrade result information: Whether the upgrade was successful. If the upgrade fails, record the specific reasons for the failure, including protocol changes not being adapted, missing dependent components, configuration conflicts, hardware incompatibility, timing errors, etc.

[0084] Test log information: A list of test scenarios executed before the upgrade was pushed out, and whether each test scenario passed.

[0085] For each historical upgrade record, the differences in ECU type and dependent components between the source and target versions are encoded into feature vectors as described in S102, serving as input features for training samples. Specifically, the list of newly added ECUs and the list of deleted ECUs between the source and target versions are calculated and mapped to a 64-dimensional ECU difference encoding; the list of newly added dependencies, the list of dependent version upgrades, and the list of redundant dependencies are calculated and mapped to a 96-dimensional dependency difference encoding; these two are concatenated and padded with zeros or pruned to 256 dimensions to form the input feature vector.

[0086] Each training sample has two labels: a risk type label and a test requirement label.

[0087] The risk type labels are generated as follows: For each historical upgrade record, the actual risk type of the upgrade is determined based on the reason for the upgrade failure. For example, if an upgrade fails due to a communication protocol mismatch, the protocol change label for that sample is 1; if an upgrade fails due to a missing neural network driver library, the dependency missing label for that sample is 1; if an upgrade has multiple failure reasons, the corresponding risk type labels for all of them are 1. For samples that successfully upgrade, all their risk type labels are 0. This generates a 5-dimensional risk type label vector, with each dimension corresponding to one of the following risk types: protocol change, dependency missing, configuration conflict, hardware compatibility, and time-series dependency.

[0088] The test requirement tags are generated as follows: For each historical upgrade record, a 10-dimensional test requirement tag vector is generated based on the test scenarios actually executed before the upgrade was pushed out. If a test scenario is executed and passes, or if a problem is found during execution, the corresponding dimension is marked as 1; otherwise, it is marked as 0. The test requirement tags reflect the set of test scenarios that were actually considered necessary to execute in the historical upgrade.

[0089] Risk level labels can be calculated based on the distribution of risk type labels: if any risk type label is 1 and the risk causes the upgrade to fail, it is marked as high risk; if a risk type label is 1 but the upgrade is ultimately successful (resolved through patches or other measures), it is marked as medium risk; if all risk type labels are 0 and the upgrade is successful, it is marked as low risk.

[0090] The constructed training sample set is divided into training, validation, and test sets according to a predetermined ratio. Typically, 70% of the samples are used for training, 15% for validation, and 15% for testing. A stratified sampling strategy is used during the partitioning to ensure that the distribution ratio of each risk type is roughly the same across the datasets, avoiding insufficient predictive power for a few categories due to imbalanced samples.

[0091] The pre-defined differential model adopts a graph attention network architecture, with the following structure: The input layer receives a 256-dimensional feature vector; three graph attention layers, each with 128-dimensional node features, four attention heads, and LeakyReLU activation function (negative slope set to 0.2). Residual connections and LayerNorm layers are added after each layer for normalization, and the dropout rate is set to 0.3; the output layer is a fully connected network, containing a 64-dimensional hidden layer (ReLU activation) and a 32-dimensional hidden layer (ReLU activation), ultimately outputting 18 dimensions.

[0092] The loss function consists of a weighted sum of three parts. The first part is the risk level classification loss, which uses the cross-entropy loss function to calculate the difference between the model's predicted risk level probability distribution and the actual risk level labels. The second part is the risk type multi-label classification loss, which uses the binary cross-entropy loss function to calculate the difference between the predicted probability and the actual label for each of the five risk types, and then sums these five losses. The third part is the test demand multi-label classification loss, which also uses the binary cross-entropy loss function to calculate the difference between the predicted probability and the actual label for each of the ten test demands, and then sums these ten losses. The overall loss function is expressed as: L_total = α * L_risk_level + β * L_risk_type + γ * L_test_demand, where α, β, and γ are the weight coefficients of the three loss terms, typically set to α = 0.2, β = 0.4, and γ = 0.4 to highlight the importance of risk type and test demand predictions in model training.

[0093] The Adam optimizer is used to update model parameters. The initial learning rate is set to 0.001, and it decays by multiplying by 0.9 every 10 training epochs. The batch size is set to 32, meaning that 32 training samples are processed in each batch. The maximum number of training epochs is set to 100.

[0094] In each training epoch, samples from the training set are input into the model in batches. The forward propagation results are calculated, the loss value is calculated according to the loss function, backpropagation is performed to calculate the gradient, and the Adam optimizer is used to update the model parameters. After each epoch, the model performance is evaluated using the validation set, and the loss value on the validation set and the average accuracy of risk type prediction are calculated. If the loss value on the validation set no longer decreases after 10 consecutive epochs, training is terminated early to prevent overfitting.

[0095] After training, the model is finally evaluated on the test set. Evaluation metrics include: average accuracy of risk type prediction (the proportion of correctly predicted risk types out of all risk types), average recall (the proportion of correctly predicted actual risk types), and average F1 score (the harmonic mean of accuracy and recall). Simultaneously, the accuracy of risk level classification and the average precision of test requirement prediction are calculated. The model parameters that best perform on the test set are saved as the final version for online inference in step S102.

[0096] After the model is deployed in practice, each completed OTA upgrade task provides version difference information, risk type prediction results, actual test results, and the final upgrade result, all of which can be used as new training samples. Every preset period (e.g., monthly), these new samples are added to the training set, and the model is incrementally trained according to the above training process to update the model parameters. Incremental training can use a small learning rate (e.g., one-tenth of the initial learning rate) to avoid drastic perturbations to the original parameters. The updated model replaces the old version and is used for subsequent upgrade risk predictions, thus ensuring that the model's prediction accuracy continuously improves with increased usage.

[0097] In summary, step S102 includes:

[0098] The differences in ECU type and dependent components between the node corresponding to the current software version and the node corresponding to the target upgrade version are encoded into feature vectors;

[0099] The feature vector is input into the preset difference model; the preset difference model adopts a graph attention network architecture and is trained based on historical OTA upgrade data;

[0100] The pre-defined differential model outputs risk types and test requirement suggestions; wherein, the risk types include one or more of protocol changes, missing dependencies, configuration conflicts, hardware compatibility, and timing dependencies; and the test requirement suggestions correspond to a predefined set of test scenarios.

[0101] In step S103, the differential package refers to an upgrade package containing data showing the differences between the current software version and the target upgrade version. Its core content includes binary code blocks, configuration files, resource files, etc., that have changed between the two versions. Unlike the full upgrade package, the differential package only contains the changed parts and does not include the parts that are the same in both versions. Therefore, the package size is much smaller than the full package, the transmission time is shorter, and it occupies less vehicle storage space.

[0102] The basic method for generating a difference package is as follows: A binary difference tool is used to compare the target file of the current version with the corresponding file of the target version, calculate the differences between the two files, and generate binary difference files. The difference files of all differing files, along with necessary metadata information, are then packaged to form a basic difference package. This basic difference package contains all the difference data required to upgrade from the current software version to the target upgrade version, but it has not yet been customized based on risk type, testing requirements, and vehicle configuration.

[0103] Obtain the specific risk types present in this upgrade from the risk type list output in step S102, and decide whether to add or remove the corresponding compatibility patch in the differential package based on each risk type.

[0104] The risk of protocol change indicates a change in the communication protocol format or interaction process between the current version and the target version. In this case, a protocol adaptation layer patch is added to the differential package. This patch is installed on the gateway or relevant ECU of the target vehicle during the upgrade process. It is responsible for converting requests of the old protocol into the new protocol format, or converting responses of the new protocol into a format that the old protocol can recognize, ensuring that the old and new protocols can coexist and interoperate during and after the upgrade.

[0105] The risk of missing dependencies indicates that the target version requires dependent components that the current version does not have. In this case, a patch for the missing dependent component is added to the differential package. This patch contains the binary file and configuration file of the dependent component. During the upgrade process, the missing dependent component is installed first, and then the main program of the target version is installed to ensure that the main program has a complete dependency environment to support it when it runs.

[0106] The risk of configuration conflicts indicates that the configuration parameters of the target version conflict with the current vehicle's hardware or software configuration. In this case, a configuration adaptation layer patch is added to the differential package. This patch detects the actual configuration of the target vehicle during the upgrade process and dynamically adjusts the configuration parameters of the target version to make it compatible with the actual vehicle configuration.

[0107] The hardware compatibility risk indicates that the target version of the software driver is incompatible with the current vehicle's hardware model. In this case, a hardware abstraction layer patch should be added to the differential package, or the driver version should be replaced with one compatible with the current hardware.

[0108] The risk of timing dependencies indicates that the upgrade order of multiple ECUs during the upgrade process is dependent. In this case, a timing control script is added to the differential package to trigger the upgrade process of each ECU in a preset order during the upgrade process, ensuring that the dependent ECU is upgraded before the dependent ECU is upgraded.

[0109] If the model determines that a certain risk type does not exist, the compatibility patch corresponding to that risk type needs to be removed from the differential package to avoid package redundancy and invalid installation.

[0110] Obtain the test scenario type required for this upgrade from the test requirement suggestion list output by S102, and adjust the range of ECU upgrade modules included in the differential package according to the ECU type corresponding to the test scenario.

[0111] Specifically, if the test requirement suggestion includes test scenarios strongly related to a particular ECU (such as multi-ECU collaborative testing, functional consistency verification, etc.), it indicates that the upgrade content for that ECU has a high verification priority, and in this case, the upgrade module for that ECU should be retained in the differential package. If the test requirement suggestion does not involve any test scenarios for a particular ECU, and the upgrade content for that ECU is only a non-functional change (such as log optimization, performance fine-tuning, etc.), then the upgrade module for that ECU can be removed from the differential package to further reduce the package size.

[0112] Adjusting the scope of ECU upgrade modules is performed on top of the basic differential package. It does not change the core differences within the differential package; it only determines which ECUs' difference data will be included in the final released differential package. For removed ECU upgrade modules, their upgrade content will be delayed until the next upgrade task for unified processing, or pushed out separately as a small patch package.

[0113] Obtain the vehicle's current hardware configuration list and optional features list from the information reported by the target vehicle. The hardware configuration list includes the ECU model, memory capacity, storage space size, and processor model installed in the vehicle. The optional features list includes whether the vehicle is equipped with ADAS, a panoramic imaging system, a premium audio system, and other optional feature modules.

[0114] The hardware configuration list and optional features list of the target vehicle are compared item by item with the upgrade data blocks contained in the differential package. For upgrade data blocks in the differential package related to a certain hardware module or feature module, if the target vehicle does not have that hardware module installed or has not selected that feature module, the upgrade data block is marked as irrelevant data and removed from the differential package. For example, the differential package may contain upgrade data for the ADAS controller by default, but if the target vehicle does not have an ADAS controller installed, the upgrade data block will be removed. Similarly, if the differential package contains an optimization patch for the panoramic imaging system, but the target vehicle does not have the panoramic imaging feature selected, the patch will be removed. The removal operation is achieved by filtering the file list in the differential package metadata, without changing the internal structure of the retained upgrade data blocks. After removal, the differential package only retains upgrade data blocks directly related to the current configuration of the target vehicle, further reducing the package size and avoiding compatibility issues that might arise from pushing upgrade content unrelated to the vehicle's hardware and features.

[0115] The remaining files processed through the above three steps are packaged to generate an upgrade package file in the target format. During packaging, metadata such as the directory structure, file hash values, and file sizes of the files within the package are recorded, and a package manifest file is generated. To ensure the integrity and security of the upgrade package during transmission and installation, digital signature technology is used to sign the packaged differential package. The hash value of the package manifest file is encrypted using the vehicle manufacturer's private key to generate a signature, which is then appended to the end of the differential package. Upon receiving the differential package, the target vehicle verifies the signature using the vehicle manufacturer's public key to confirm that the package has not been tampered with and its origin is trustworthy before proceeding with the installation.

[0116] The generated differential package is stored in the OTA platform's upgrade package repository, along with its corresponding metadata information, including: source version number, target version number, applicable vehicle model code, applicable hardware configuration range, applicable optional functions range, package size, hash value, generation timestamp, list of risk types used, and list of suggested test requirements. This metadata is used for subsequent upgrade task matching and differential package retrieval. When multiple target vehicles have the same current version, target version, and vehicle configuration, the already generated differential package can be reused without repeating this step.

[0117] Through the above method, step S103 integrates information from three dimensions—risk type, test requirement suggestions, and target vehicle configuration—into the differential package generation process. This enables the final output differential package to specifically address identified risks, aligns with test verification objectives in terms of scope, and retains only the data actually needed by the current vehicle in terms of size, thus achieving truly differentiated on-demand package creation.

[0118] In summary, in this embodiment of the application, step S103, which involves automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestion, and the differential package being an upgrade package containing difference data between the current software version and the target upgrade version, includes:

[0119] Based on the risk type, add or remove the corresponding compatibility patch in the differential package;

[0120] Based on the aforementioned test requirements, the range of ECU upgrade modules included in the differential package should be adjusted.

[0121] Based on the current configuration of the target vehicle, upgrade data blocks that are irrelevant to the target vehicle are removed, and a differential package containing only the upgrade data required by the target vehicle is generated.

[0122] In this embodiment of the application, when there are multiple intermediate versions between the current software version and the target upgrade version, the step of automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestion further includes: selecting the upgrade path with the highest upgrade success rate from the current software version to the target upgrade version based on the historical success rate of each upgrade path segment in the version difference map, and generating a differential package based on the selected upgrade path. This step addresses the special scenario where there are multiple intermediate versions between the current software version and the target upgrade version. Based on the original package creation process in S103, a path selection step is added to ensure that the generated differential package is based on the most reliable upgrade path in history.

[0123] When multiple intermediate versions exist between the current software version and the target upgrade version, there are typically multiple reachable paths from the current version node to the target version node. Each path consists of several directed edges connected end-to-end, with each directed edge representing a jump relationship from one version to another. The version difference graph is traversed, enumerating all reachable paths from the current software version node to the target upgrade version node. For graphs with a large number of nodes, a depth-first search algorithm can be used for enumeration, with a maximum path length limit set to avoid combinatorial explosion. For each directed edge in each feasible path, the historical success rate of that upgrade path segment is read from the edge attributes stored in the graph. The historical success rate is calculated by dividing the historical success count of that upgrade path segment by the total number of historical executions, resulting in a success rate value between 0 and 1. If an upgrade path segment has never been executed (i.e., the total number of historical executions is zero), the historical success rate of that path segment is set to a preset default value (e.g., 0.5), indicating a neutral evaluation in the absence of historical data; the path is neither prioritized nor excluded. For each enumerated feasible path, calculate the overall upgrade success rate of that path. The overall success rate of a path is calculated by multiplying the historical success rates of each upgrade segment on that path. The reason for using multiplication instead of averaging is that each upgrade segment on the path must succeed for the entire path to succeed. Therefore, the success rates of each segment constitute a reliability model of a cascaded system, and the product accurately reflects the cumulative success probability of multiple jumps. For example, if a path contains three upgrade segments with historical success rates of 0.95, 0.90, and 0.98, then the overall success rate of the path is 0.95 × 0.90 × 0.98, which equals 0.8379.

[0124] Compare the overall success rates of all feasible paths and select the path with the highest overall success rate as the optimal path for this upgrade. If multiple paths have the same overall success rate, all of which are the maximum, a secondary selection strategy can be adopted, such as selecting a path with a shorter length (i.e., fewer intermediate versions), to reduce the number of installations and failure risks during the upgrade process. After determining the optimal path, generate a differential package that directly upgrades from the current software version to the target upgrade version according to the upgrade jump relationships defined in the selected path. The content of this differential package merges the change data corresponding to all intermediate versions on the path, so that the target vehicle does not need to install each intermediate version step by step, and can upgrade to the target version in one go. The specific operations in the differential package generation method, such as compatibility patch processing, ECU module range adjustment, and data block trimming, are consistent with the process described in S103 and will not be repeated here. Through the above steps, when multiple intermediate versions exist, the upgrade path with the highest historical success rate is automatically selected, and a differential package is generated accordingly, thereby reducing the probability of upgrade failure in multi-version jump scenarios at the path selection level.

[0125] In step S104, the list of test scenarios to be executed in this upgrade is obtained from the test requirement suggestions output in S102. The test requirement suggestions correspond to a predefined set of test scenarios, and each test scenario represents a specific test environment or test condition. Common test scenarios include, but are not limited to: network interruption resume download scenario, low battery upgrade scenario, insufficient storage space scenario, abnormal power outage recovery scenario, functional consistency verification scenario, multi-ECU collaborative upgrade scenario, rollback test scenario, concurrent upgrade scenario, hibernation wake-up scenario, security verification scenario, etc.

[0126] For each recommended test scenario, extract the execution priority and execution parameters from the test requirement suggestions. For example, the scenario of resuming downloads after a network outage needs to specify when the network outage occurs (e.g., when the download progress reaches 50%) and the duration of the outage (e.g., 30 seconds); the scenario of upgrading when the battery is low needs to specify the simulated battery percentage (e.g., 10%); and the scenario of insufficient storage space needs to specify the amount of remaining storage space (e.g., 50MB).

[0127] Each minimal test action in the predefined minimal test action library represents a single, indivisible operation, such as setting a network disconnection, simulating battery depletion, sending an upgrade command, or reading a version number. Based on each test scenario suggested in the test requirements, a set of minimal test actions matching that scenario is retrieved from the test action library. All retrieved minimal test actions are then combined according to their temporal relationship to generate an executable test script.

[0128] The differential package generated by S103 is deployed to a simulation environment. This simulation environment is parameterized according to the actual ECU type and dependent component list of the target vehicle. It can simulate the vehicle's power-on, power-off, hibernation, and wake-up states, as well as network conditions such as 4G, 5G, WiFi, network outage, and weak network. It can also inject abnormal scenarios such as insufficient storage and low battery. Test scripts are executed in the simulation environment. The automated testing framework calls the corresponding test action interfaces sequentially according to the action sequence defined in the script, simulating various situations that the target vehicle may encounter during a real upgrade process.

[0129] During test script execution, the automated testing framework records the execution results of each test action, system logs, and differential package behavior data. After execution, the framework parses the raw data to generate structured automated test results, including the overall test conclusion (pass or fail), the execution status of each test scenario, the specific reasons for failed actions, and resource consumption statistics of the differential package during testing. If all test scenarios pass as expected, the differential package is considered to have passed the automated test; if any test scenario fails or an anomaly occurs, the differential package is considered to have failed the automated test, and the failure information is output for subsequent analysis.

[0130] In other words, step S104, which involves performing automated testing on the differential package, includes:

[0131] Based on the aforementioned test requirements, retrieve the minimum matching test action from the predefined test action library;

[0132] The retrieved minimum test actions are combined in sequence to generate an executable test script;

[0133] The test script is executed in a simulation environment to simulate vehicle status, network conditions, and abnormal scenarios.

[0134] Collect logs and results data during test execution to generate automated test results.

[0135] In this embodiment of the application, the method further includes:

[0136] S106, The results of the automated test are fed back to the preset differential model;

[0137] S107, The preset differential model is incrementally trained based on the test results to update the model parameters.

[0138] The structured data of the automated test results includes: identification information of this upgrade task (current software version number, target upgrade version number, list of ECU types for the target vehicle, and list of dependent components), the risk type list and test requirement suggestion list output by the model in step S102, the overall conclusion of the test execution in step S104 (pass or fail), the specific execution results of each test scenario (pass or fail), descriptions of the failure reasons for failure scenarios (such as failure to resume network transmission after interruption in protocol change test, incorrect loading of dependent components in dependency missing test, etc.), the behavior record of the differential package during the test, and new compatibility problem types discovered during the test but not predicted by the model. This data is organized into key-value pair format and used as input for incremental model training.

[0139] A new training sample is generated based on the test results. The input features of the sample are encoded according to the method in S102, generating a 256-dimensional feature vector based on the differences in ECU type and dependent components between the current software version and the target upgrade version. The label of the sample is determined based on the test results: for risk types output by the model, if the corresponding test scenario passes and the risk is not exposed in the test, the prediction of that risk type is confirmed to be correct; for risk types exposed in the test but not output by the model, the label of that risk type is set to 1, as a new mode that the model needs to learn. The labels suggested by the test requirements are also updated according to the actual execution and results of each test scenario. When the cumulative number of new training samples reaches a preset threshold, the incremental training process is triggered. Incremental training uses the same loss function as the initial training, but uses a smaller initial learning rate to avoid drastic perturbation to the existing parameters of the model. The new samples are mixed with historical training samples at a preset ratio, and the model is trained for a limited number of rounds. After training, if the performance index of the updated model on the validation set is not lower than the level before the update, the new model parameters are saved and the current online pre-set differential model is replaced; if the performance degrades, the original model is retained and the reason for failure is recorded. The updated model is used for risk prediction and test requirement suggestions in subsequent upgrade tasks, so that the model's prediction accuracy can be continuously improved as test data accumulates.

[0140] In this embodiment of the application, the method further includes:

[0141] S108, When the automated test fails, a test failure report is generated;

[0142] S109. Based on the test failure reason recorded in the test failure report, re-execute at least one of the following steps:

[0143] Regenerate the differential packet;

[0144] Re-execute the automated test.

[0145] When an automated test fails, a test failure report is first generated, containing a failure scenario identifier, failure action name, a snapshot of the system state at the time of failure, and a classification of the failure reason. Then, targeted corrections are made based on the failure reasons recorded in the report: if the failure reason is a defect in the differential package content, such as a missing compatibility patch or an inappropriate ECU upgrade module scope, a process of regenerating the differential package is triggered. This involves adjusting the patch configuration or module scope while retaining the original risk type and test requirement suggestions, and then generating a new differential package. If the failure reason is a problem not related to the differential package itself, such as fluctuations in the test environment or occasional timeouts, the current differential package remains unchanged, and the automated test is re-executed. If the failure reason involves multiple of the above situations, the process of regenerating the differential package and re-executing the automated test is executed sequentially. Through this closed-loop correction mechanism, test failure no longer terminates the process but instead becomes a trigger condition for differential package iterative optimization, until the differential package passes the test or reaches the preset retry limit, at which point the process exits.

[0146] Reference Figure 2 This application also provides a vehicle software upgrade device, including:

[0147] The version difference map construction module 201 is used to construct a version difference map based on the current software version of the target vehicle and the target upgrade version information; the version difference map uses version number as a node, upgrade path as an edge, and ECU type and dependent component list as node attributes;

[0148] The model prediction module 202 is used to take the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to the preset difference model, so that the preset difference model can predict the risk type and test requirement suggestions for this upgrade.

[0149] The differential package generation module 203 is used to automatically generate a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestion; the differential package refers to an upgrade package containing the difference data between the current software version and the target upgrade version;

[0150] Test module 204 is used to automatically construct a set of compatibility test cases based on the test requirements suggestions and perform automated testing on the differential package;

[0151] The upgrade module 205 is used to push the differential package to the target vehicle after the automated test passes, so that the target vehicle can perform the upgrade.

[0152] The device achieves the same technical effects as the method described above.

[0153] This application also provides a vehicle on which a differential package is deployed according to the above-described vehicle software upgrade method.

[0154] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims. Those skilled in the art can understand that implementing all or part of the processes of the above embodiments and making equivalent changes according to the claims of this application still fall within the scope of this application.

Claims

1. A method for upgrading vehicle software, characterized in that, include: Based on the current software version of the target vehicle and the target upgrade version information, construct a version difference map; The version difference map uses version number as nodes, upgrade path as edges, and ECU type and dependent component list as node attributes; The attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map are used as input to a pre-set difference model, so that the pre-set difference model can predict the risk type and test requirement suggestions for this upgrade. Based on the risk type and the test requirement suggestions, an upgrade package adapted to the current configuration of the target vehicle is automatically generated; the upgrade package refers to an upgrade package containing the difference data between the current software version and the target upgrade version. Based on the aforementioned test requirements, a set of compatibility test cases is automatically constructed, and automated testing is performed on the differential package. Once the automated test passes, the differential package is pushed to the target vehicle for the target vehicle to perform the upgrade.

2. The vehicle software upgrade method according to claim 1, characterized in that, The steps for constructing a version difference map based on the target vehicle's current software version and the target upgrade version information include: Each version number is created as a node in the graph; Create directed edges between nodes in ascending order of version number; The list of ECU types and dependent components associated with each version number are stored as attribute tags for the corresponding node.

3. The vehicle software upgrade method according to claim 2, characterized in that, The steps for using the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to a pre-set difference model, so that the pre-set difference model can predict the risk type and test requirement suggestions for this upgrade, include: The differences in ECU type and dependent components between the node corresponding to the current software version and the node corresponding to the target upgrade version are encoded into feature vectors; The feature vector is input into the preset difference model; the preset difference model adopts a graph attention network architecture and is trained based on historical OTA upgrade data; The pre-defined differential model outputs risk types and test requirement suggestions; wherein, the risk types include one or more of protocol changes, missing dependencies, configuration conflicts, hardware compatibility, and timing dependencies; and the test requirement suggestions correspond to a predefined set of test scenarios.

4. The vehicle software upgrade method according to claim 3, characterized in that, Based on the risk type and the test requirement suggestions, automatically generate a differential package adapted to the current configuration of the target vehicle; The differential package refers to an upgrade package containing data on the differences between the current software version and the target upgrade version. The steps include: Based on the risk type, add or remove the corresponding compatibility patch in the differential package; Based on the aforementioned test requirements, the range of ECU upgrade modules included in the differential package should be adjusted. Based on the current configuration of the target vehicle, upgrade data blocks that are irrelevant to the target vehicle are removed, and a differential package containing only the upgrade data required by the target vehicle is generated.

5. The vehicle software upgrade method according to claim 1, characterized in that, The steps for performing automated testing on the differential package include: Based on the aforementioned test requirements, retrieve the minimum matching test action from the predefined test action library; The retrieved minimum test actions are combined in sequence to generate an executable test script; The test script is executed in a simulation environment to simulate vehicle status, network conditions, and abnormal scenarios. Collect logs and results data during test execution to generate automated test results.

6. The vehicle software upgrade method according to claim 1, characterized in that, The method further includes: The results of the automated test are fed back to the preset difference model; The pre-set differential model is incrementally trained based on the test results, and the model parameters are updated.

7. The vehicle software upgrade method according to claim 1, characterized in that, When multiple intermediate versions exist between the current software version and the target upgrade version, the step of automatically generating a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestions includes: Based on the historical success rate of each upgrade path in the version difference map, select the upgrade path with the highest success rate from the current software version to the target upgrade version, and generate a differential package based on the selected upgrade path.

8. The vehicle software upgrade method according to claim 1, characterized in that, The method further includes: When the automated test fails, a test failure report is generated; Based on the reasons for test failure recorded in the test failure report, re-execute at least one of the following steps: Regenerate the differential packet; Re-execute the automated test.

9. A vehicle software upgrade device, characterized in that, include: The version difference map construction module is used to construct a version difference map based on the current software version of the target vehicle and the target upgrade version information; The version difference map uses version number as nodes, upgrade path as edges, and ECU type and dependent component list as node attributes; The model prediction module is used to take the attribute differences between the nodes corresponding to the current software version and the nodes corresponding to the target upgrade version in the version difference map as input to the preset difference model, so that the preset difference model can predict the risk type and test requirement suggestions for this upgrade. The differential package generation module is used to automatically generate a differential package adapted to the current configuration of the target vehicle based on the risk type and the test requirement suggestions; the differential package refers to an upgrade package containing the difference data between the current software version and the target upgrade version; The testing module is used to automatically build a set of compatibility test cases based on the test requirements and to perform automated testing on the differential package. The upgrade module is used to push the differential package to the target vehicle after the automated test passes, so that the target vehicle can perform the upgrade.

10. A vehicle, characterized in that, The vehicle is equipped with a differential package issued according to the vehicle software upgrade method described in any one of claims 1-7.

Images