Vehicle group layered risk portrait internet of vehicles change release layered acceptance method and system

Abstract

The application discloses a kind of vehicle group layered risk portrait's internet of vehicles change release layered acceptance method, comprising: obtaining the target vehicle set corresponding to target change task;Collect the basic data and historical data of target vehicle set;Based on preset layered rule or layered model, the target vehicle is layered;For each vehicle group generates multidimensional risk portrait;According to risk portrait generation layered acceptance control rule;According to vehicle group level, change release is executed in batches, and the acceptance index data of corresponding vehicle group is collected in real time;Compare acceptance index with the control rule of corresponding vehicle group, dynamically execute expansion release, pause or local rollback;Release result is back-priming to risk portrait data set, and subsequent layered strategy is optimized.The application also discloses a kind of vehicle group layered risk portrait's internet of vehicles change release layered acceptance system.The application can more accurately match the difference of different vehicle groups in connection stability, compatibility and recovery ability, reduce the probability that high-risk vehicle group is caused by batch exception by being put in too fast.

Description

Technical Field

[0001] This invention belongs to the field of vehicle networking technology, specifically a method and system for layered acceptance of vehicle networking change release based on vehicle group layered risk profiling. Background Technology

[0002] As the scale of connected vehicle services continues to expand, the frequency of software, configuration, and policy changes for vehicles has increased significantly. Existing connected vehicle companies typically need to continuously update in-vehicle terminal programs, configuration parameters, diagnostic strategies, network access parameters, and remote control rules to support new feature launches, bug fixes, operational optimizations, and security hardening.

[0003] In real-world applications, target vehicles are not in homogeneous environments. Different vehicles exhibit significant differences in vehicle platform, TBOX version, communication module version, carrier access status, regional network quality, and historical online stability. When the same change release task is applied to different vehicle groups, its success rate, fault type, impact scope, and recovery difficulty often vary. Therefore, change releases in connected vehicle scenarios must not only consider the general patterns of platform-side software releases but also address unique challenges such as weak vehicle-side networks, limited remote reach, large-scale batch impact, and high rollback costs.

[0004] Existing continuous delivery and canary release solutions typically employ a unified release process: before release, the target objects are identified, and the release is gradually rolled out in a predetermined manner. Operational monitoring metrics are collected, and then a unified threshold is used to determine whether to continue scaling up, pause the release, or perform a rollback. This type of solution is highly applicable to internet services, cloud services, and general software delivery scenarios.

[0005] In the context of connected vehicles, existing practices typically follow the same approach: treating vehicles as a unified release target, distributing them in batches using a gray-scale rollout method, and using metrics such as online rate, upgrade success rate, heartbeat recovery status, and number of fault alarms as acceptance criteria. Some solutions add a simple risk assessment before release, such as basic screening based on vehicle version or region, before performing unified observation and unified acceptance.

[0006] Existing solutions typically use a uniform acceptance threshold and a uniform deployment path, which do not fully reflect the differences between different vehicle groups in terms of connection stability, version compatibility, regional weak network characteristics, and recovery capabilities. This can easily lead to problems such as low-risk vehicle groups deploying too slowly and high-risk vehicle groups deploying too quickly.

[0007] The risk assessment in existing solutions is usually represented by a single score or simple screening, lacking a multi-dimensional risk profile that can directly drive release control, and making it difficult to generate differentiated acceptance indicators, observation durations and rollback conditions for different vehicle groups.

[0008] When the target vehicle fleet is large and the network environment is complex, a unified acceptance strategy may easily mask the problems of local high-risk vehicle groups, leading to the concentrated exposure of release anomalies in specific regions, specific operators, or specific terminal versions, increasing the risk of mass disconnection, remote unreachability, and rollback failure.

[0009] Existing technologies often only implement overall suspension or rollback after acceptance testing fails, lacking hierarchical control measures for different vehicle groups, resulting in a wider impact, increased rollback costs, and insufficient precision in operation and maintenance decisions.

[0010] Therefore, to address the above issues, a method and system for layered acceptance of vehicle network change releases based on vehicle group layered risk profiling is provided. Summary of the Invention

[0011] To address the aforementioned problems in existing technologies, this invention provides a method and system for layered acceptance of vehicle network change releases based on vehicle group layered risk profiling. This method can more accurately match the differences in connection stability, compatibility, and recovery capabilities among different vehicle groups, reducing the probability of batch anomalies caused by excessively rapid release of high-risk vehicle groups.

[0012] The technical solution to achieve the above objectives is: One of the present inventions is a method for layered acceptance of vehicle network change release based on vehicle group layered risk profiling, comprising: Step S1: Obtain the set of target vehicles corresponding to the target change task, and configure the change type, target vehicle range, effective time, version information and rollback plan; Step S2: Collect basic and historical data of the target vehicle set; Step S3: Based on clustering algorithms or graph models, preset hierarchical rules or hierarchical models are used to hierarchically classify the target vehicles to form at least two vehicle groups with different risk levels. Step S4: Generate a multi-dimensional risk profile for each vehicle group through rule calculation, statistical model or machine learning model, including a set of parameters for connectivity risk, compatibility risk, operational risk and recovery risk; Step S5: Generate tiered acceptance control rules based on the risk profile, including the initial release ratio, acceptance observation duration, set of acceptance indicators, indicator thresholds, conditions for expanding release, conditions for suspending release, and rollback trigger conditions. Step S6: Execute the change release in batches according to the vehicle group level, and collect the acceptance indicator data of the corresponding vehicle group in real time; Step S7: Compare the acceptance indicators with the control rules of the corresponding vehicle group, and dynamically execute expanded release, pause or partial rollback; Step S8: Feed the published results back into the risk profile dataset to optimize subsequent stratification strategies.

[0013] Preferably, in step S1, the operation and maintenance personnel create a change task on the release platform, configure the change type, target vehicle range, effective time, version information and rollback plan, and filter the target vehicle set according to the target vehicle tags, regions, vehicle models and version conditions.

[0014] Preferably, in step S2, the basic data includes, but is not limited to, vehicle attribute data, terminal version data, network connection data, and regional distribution data, while the historical data includes, but is not limited to, historical online stability data, historical release success rate data, and historical anomaly data.

[0015] Preferably, in step S3, the vehicle group hierarchy includes low-risk vehicle group, medium-risk vehicle group, high-risk vehicle group, and observation vehicle group.

[0016] Preferably, in step S4, the risk parameter set is connected. Including adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate ; Then connect the risk parameter set Represented as: ; In the formula, , , and Adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate The weighting coefficients satisfy: ; Compatibility risk parameter set Including the probability of dependency conflicts between the target version and the current terminal version Probability of configuration inconsistency Historical compatibility anomaly trigger rate ; Then the set of compatibility risk parameters Represented as: ; In the formula, , and These represent the probability of dependency conflicts between the target version and the current terminal version. Probability of configuration inconsistency Historical compatibility anomaly trigger rate The weighting coefficients satisfy: ; Set of operational risk parameters Including the probability of offline increment after release , probability of triggering functional abnormality alarm Upgrade failure rate ; Then run the risk parameter set Represented as: ; In the formula, , and The offline incremental probability after release , probability of triggering functional abnormality alarm Upgrade failure rate The weighting coefficients satisfy: ; Recovery risk parameter set Including remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate ; Then restore the set of risk parameters Represented as: ; In the formula, , and Remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate The weighting coefficients satisfy: ; Further connect the risk parameter set Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set By integrating the data, we obtain the overall risk profile value of the target vehicle group. : ; In the formula, , , and These are the sets of connection risk parameters. Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set The image fusion weight, and satisfying .

[0017] Preferably, in step S5, the comprehensive control level is calculated based on the set of parameters. ,Right now: ; In the formula, This represents the control rule mapping function and the control level. It is represented as a set of control template identifiers, used to select the corresponding control rules.

[0018] Preferably, in step S6, the acceptance indicators include, but are not limited to, changes in online rate, heartbeat recovery rate, upgrade success rate, number of abnormal alarms, increase in connection interruption, and remote reachability.

[0019] Preferably, in step S7, based on the comparison results, dynamically performing expanded release, pause, or partial rollback specifically includes: If a vehicle group meets the conditions for expanding the release, the release scope of that vehicle group or the next level vehicle group will be further expanded. If a vehicle group does not meet the conditions for expanding the release or has not reached the rollback threshold, then keep it under observation or suspend the release of that layer. If a vehicle group meets the rollback trigger condition, a partial rollback will be performed on that vehicle group without affecting other vehicle group levels that have passed the acceptance test.

[0020] Preferably, in step S8, after the release is completed, the actual release success rate, anomaly type, rollback trigger record and recovery result of each vehicle group are written back to the risk profile database to optimize the vehicle group stratification and acceptance rules for subsequent similar change tasks.

[0021] A second invention relates to a vehicle-to-everything (V2X) network change release and acceptance system based on a vehicle group layered risk profiling model, comprising: The data acquisition module is used to collect vehicle attribute data, terminal version data, network connection data, regional distribution data, historical operation data, and historical release result data of the target vehicle set; The vehicle grouping module is used to cluster, group, or divide the target vehicle set according to multiple risk-related dimensions to form vehicle groups with at least two different risk levels. The risk profiling module is used to generate multi-dimensional risk profiles for each vehicle group, including a set of parameters for connectivity risk, compatibility risk, operational risk, and recovery risk. The rule generation module is used to generate hierarchical acceptance control rules corresponding to each vehicle group based on the risk profile of that vehicle group. The release execution module is used to execute batch releases according to vehicle group level and corresponding rules; The acceptance judgment module is used to collect acceptance indicators during the release process, compare the acceptance indicators with the acceptance rules of the corresponding vehicle group, and output the acceptance results. The control decision module is used to execute expanded release, maintain observation, pause release, or partial rollback based on the acceptance results. The results feedback module is used to write back the acceptance results released in this round to the risk profile dataset to optimize the hierarchical control strategy for subsequent similar change tasks.

[0022] Compared with the prior art, the beneficial effects of the present invention are: 1) This invention first forms multiple risk-level vehicle groups based on factors such as vehicle type, terminal version, communication module, operator, region and weak network characteristics, and then sets differentiated control rules for different vehicle groups. Therefore, it can more accurately match the differences in connection stability, compatibility and recovery capability of different vehicle groups, and reduce the probability of high-risk vehicle groups being caused by excessively rapid volume release to cause batch anomalies. 2) This invention constructs a multi-dimensional risk profile, rather than using only a single risk score, so that risk information can be directly mapped to the first batch release ratio, observation period, acceptance indicator threshold and rollback conditions, thereby improving the pertinence and enforceability of acceptance control rules and reducing misjudgments and omissions caused by uniform threshold strategies. 3) During the release process, the present invention independently performs dynamic acceptance and control decisions for different vehicle groups. When a high-risk vehicle group fails the acceptance, only the release of that vehicle group can be paused or partially rolled back, instead of terminating the release of all vehicle groups. Therefore, it can reduce the scope of the anomaly, reduce the overall rollback cost, and improve the release efficiency. 4) This invention supports feeding the actual results of this round of release back into the risk profile library to optimize the hierarchical rules and acceptance rules for subsequent similar changes. Therefore, it can continuously improve the accuracy of release control and enhance the stability and controllability of the continuous delivery scenario of the Internet of Vehicles. Attached Figure Description

[0023] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a method for layered acceptance of vehicle network change release based on a vehicle group layered risk profile according to the present invention; Figure 2 This is a flowchart of a vehicle network change release and acceptance system based on a vehicle group hierarchical risk profiling method, according to the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] like Figure 1 As shown, a layered risk profiling method for vehicle-to-everything (V2X) change release and acceptance is applied to V2X release management and control platforms, operation and maintenance release platforms, or V2X DevOps platforms. It is suitable for scenarios involving remote change releases of vehicle-side software packages, configuration parameters, network access parameters, and business policy rules. Specifically, it includes: Step S1: Obtain the set of target vehicles corresponding to the target change task, and configure the change type, target vehicle range, effective time, version information, and rollback plan.

[0026] In this embodiment, operations and maintenance personnel create change tasks on the release platform, configuring the change type, target vehicle range, effective time, version information, and rollback plan. They then filter the target vehicle set based on target vehicle tags, region, vehicle type, and version conditions. The platform provides the following functions: (1) Change task creation interface: Enter the change name, change type, target vehicle range, expected effective time and rollback plan; (2) Vehicle group layering interface: Displays multiple vehicle group layers divided by vehicle type, TBOX version, module version, operator, region, weak network characteristics, historical online stability, etc. (3) Risk profile interface: Displays the connection risk, compatibility risk, operational risk and recovery risk parameters corresponding to each vehicle group level; (4) Layered acceptance interface: Displays the initial release ratio, acceptance observation duration, acceptance indicator set, indicator threshold, expanded release conditions, pause conditions, and rollback trigger conditions for different vehicle groups; (5) Release control interface: Real-time display of release progress, acceptance results and current control actions of each vehicle group, including continue to release, keep observing, pause release or partial rollback.

[0027] Step S2: Collect basic and historical data of the target vehicle set.

[0028] In this embodiment, basic data includes, but is not limited to, vehicle attribute data, terminal version data, network connection data, and regional distribution data, while historical data includes, but is not limited to, historical online stability data, historical release success rate data, and historical anomaly data.

[0029] Step S3: Based on clustering algorithms or graph models, preset hierarchical rules or hierarchical models are used to hierarchically classify the target vehicles, forming vehicle groups with at least two different risk levels.

[0030] For example, the first level of classification can be based on vehicle type and TBOX version, the second level can be based on communication module version and operator type, and the third level can be further subdivided by combining regional weak network distribution and historical online stability, ultimately forming multiple levels such as low-risk vehicle groups, medium-risk vehicle groups, high-risk vehicle groups, and observation vehicle groups.

[0031] Step S4: Generate a multi-dimensional risk profile for each vehicle group through rule calculation, statistical model or machine learning model, including a set of parameters for connectivity risk, compatibility risk, operational risk and recovery risk.

[0032] In this embodiment, in step S4, the set of connection risk parameters is... Including adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate ; Then connect the risk parameter set Represented as: ; In the formula, , , and Adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate The weighting coefficients satisfy: ; For example, in connection stability scenarios, the following can be set: ; This means that the heartbeat interruption rate and the weak network reconnection rate have a greater impact on connection risk, and therefore are given higher weights. Compatibility risk parameter set Including the probability of dependency conflicts between the target version and the current terminal version Probability of configuration inconsistency Historical compatibility anomaly trigger rate ; Then the set of compatibility risk parameters Represented as: ; In the formula, , and These represent the probability of dependency conflicts between the target version and the current terminal version. Probability of configuration inconsistency Historical compatibility anomaly trigger rate The weighting coefficients satisfy: ; Set of operational risk parameters Including the probability of offline increment after release , probability of triggering functional abnormality alarm Upgrade failure rate ; For example, in compatibility scenarios, the following can be set: ; Among them, the version dependency conflict rate can be obtained through version dependency graph analysis. If there are unmet dependencies between the target version and the current terminal version, module version, and configuration template, they are included in the conflict sample. Then run the risk parameter set Represented as: ; In the formula, , and The offline incremental probability after release , probability of triggering functional abnormality alarm Upgrade failure rate The weighting coefficients satisfy: ; For example, in operational scenarios, the following can be set: ; Recovery risk parameter set Including remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate ; Then restore the set of risk parameters Represented as: ; In the formula, , and Remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate The weighting coefficients satisfy: ; For example, in a restorative scenario, we can set: ; Further connect the risk parameter set Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set By integrating the data, we obtain the overall risk profile value of the target vehicle group. : ; In the formula, , , and These are the sets of connection risk parameters. Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set The image fusion weight, and satisfying ; For example, ; Then according to The range of values ​​is used to divide the vehicle group into different risk levels, so that different initial release ratios, observation durations and acceptance thresholds can be configured for each level.

[0033] For example: when 0≤ When <0.3, it is judged as low risk; when 0.3≤ When <0.6, it is classified as medium risk; when 0.6≤ If the value is ≤1, it is classified as a high-risk layer.

[0034] In another embodiment, version dependencies and anomaly propagation paths can also be represented by knowledge graphs or graph computing methods.

[0035] Step S5: Generate tiered acceptance control rules based on the risk profile, including the initial release ratio, acceptance observation duration, set of acceptance indicators, indicator thresholds, conditions for expanding release, conditions for suspending release, and conditions for rollback triggering.

[0036] In this embodiment, the overall control level is calculated based on the set of parameters. ,Right now: ; In the formula, This represents the control rule mapping function and the control level. It can be represented not only as a single score, but also as a set of control template identifiers (the key is to achieve differentiated acceptance control at the vehicle group level through the mapping from risk profiles to control rules), used to select the corresponding tiered acceptance control rules, including the initial release ratio, acceptance observation duration, acceptance indicator set, indicator threshold, expanded release conditions, suspended release conditions, and rollback trigger conditions; for example, a low-risk vehicle group can be set with a higher initial release ratio and a shorter observation duration; a high-risk vehicle group can be set with a lower initial release ratio, a longer observation duration, and a stricter anomaly threshold.

[0037] Step S6: Implement the change release in batches according to the vehicle group level, and collect the acceptance indicator data of the corresponding vehicle group in real time.

[0038] In this embodiment, the execution order is to issue change tasks sequentially according to the vehicle group level. For the same vehicle group, it can be further subdivided into sub-batches according to region or online status to reduce the scope of impact of a single event. Acceptance indicators include, but are not limited to, changes in online rate, heartbeat recovery rate, upgrade success rate, number of abnormal alarms, increase in connection interruption, and remote reachability.

[0039] Step S7: Compare the acceptance indicators with the control rules of the corresponding vehicle group, and dynamically execute expanded release, pause or partial rollback.

[0040] In this embodiment, based on the comparison results, dynamic actions are taken to expand the release, pause, or partially rollback, specifically including: If a vehicle group meets the conditions for expanding the release, the release scope of that vehicle group or the next level vehicle group will be further expanded. If a vehicle group does not meet the conditions for expanding the release or has not reached the rollback threshold, then keep it under observation or suspend the release of that layer. If a vehicle group meets the rollback trigger condition, a partial rollback will be performed on that vehicle group without affecting other vehicle group levels that have passed the acceptance test.

[0041] Step S8: Feed the published results back into the risk profile dataset to optimize subsequent stratification strategies.

[0042] In this embodiment, after the release is completed, the actual release success rate, anomaly type, rollback trigger record and recovery result of each vehicle group are written back to the risk profile database to optimize the vehicle group stratification and acceptance rules for subsequent similar change tasks.

[0043] like Figure 2 As shown, a vehicle-to-everything (V2X) change release and acceptance system for vehicle group layered risk profiling includes: a data acquisition module 1, a vehicle group layering module 2, a risk profiling module 3, a rule generation module 4, a release execution module 5, an acceptance judgment module 6, a control decision module 7, and a result feedback module 8.

[0044] Data acquisition module 1 is used to collect vehicle attribute data, terminal version data, network connection data, regional distribution data, historical operation data, and historical release result data of the target vehicle set.

[0045] Vehicle grouping module 2 is used to cluster, group, or divide the target vehicle set according to multiple risk-related dimensions to form vehicle groups with at least two different risk levels.

[0046] Risk profiling module 3 is used to generate multi-dimensional risk profiles for each vehicle group, including a set of parameters for connectivity risk, compatibility risk, operational risk, and recovery risk.

[0047] Rule generation module 4 is used to generate hierarchical acceptance control rules corresponding to each vehicle group based on the risk profile of each vehicle group.

[0048] The release execution module 5 is used to perform batch releases according to the vehicle group level and corresponding rules.

[0049] The acceptance judgment module 6 is used to collect acceptance indicators during the release process, compare the acceptance indicators with the acceptance rules of the corresponding vehicle group, and output the acceptance results.

[0050] Control decision module 7 is used to perform expanded release, maintain observation, pause release, or partial rollback based on the acceptance results.

[0051] The result feedback module 8 is used to write back the acceptance results released in this round to the risk profile dataset to optimize the hierarchical control strategy for subsequent similar change tasks. Specifically, it is used to update control templates, optimize hierarchical rules, or adjust the weights of different risk-related dimensions.

[0052] This invention can be applied not only to the distribution of vehicle terminal software packages, but also to scenarios such as the distribution of configuration parameters, adjustment of communication access parameters, updating of remote diagnostic strategies, adjustment of remote control rules, updating of map data, and updating of security policies.

[0053] Specific application examples: Taking a recent update to vehicle terminal configuration parameters as an example, the target vehicles totaled 100,000. The platform first stratified the vehicles according to vehicle model platform, TBOX version, module version, operator, and region, forming 12 vehicle groups. After risk profiling analysis, three of these vehicle groups were identified as high-risk, mainly due to a high proportion of weak network connections, large historical online fluctuations, and low rollback success rates.

[0054] For the low-risk tier, the platform sets the initial release ratio at 10% and the observation period at 15 minutes.

[0055] For high-risk groups, the platform sets the initial release ratio at 1%, the observation period at 60 minutes, and requires that the heart rate recovery rate and remote reachability both reach preset thresholds before the release can be expanded.

[0056] If the incremental connection interruption of a vehicle group in a certain area of ​​the high-risk layer exceeds the threshold, only the sub-vehicle group in that area will be partially rolled back, while the remaining vehicle groups that have passed the acceptance test will continue to maintain the current version.

[0057] This enables differentiated acceptance and tiered control for different vehicle groups, reducing the risk of batch anomalies caused by a unified release strategy.

[0058] Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for layered acceptance of vehicle network change releases based on layered risk profiling of vehicle groups, characterized in that, include: Step S1: Obtain the set of target vehicles corresponding to the target change task, and configure the change type, target vehicle range, effective time, version information and rollback plan; Step S2: Collect basic and historical data of the target vehicle set; Step S3: Based on clustering algorithms or graph models, preset hierarchical rules or hierarchical models are used to hierarchically classify the target vehicles to form at least two different risk levels of vehicle groups. Step S4: Generate a multi-dimensional risk profile for each vehicle group through rule calculation, statistical model or machine learning model, including a set of parameters for connectivity risk, compatibility risk, operational risk and recovery risk; Step S5: Generate tiered acceptance control rules based on the risk profile, including the initial release ratio, acceptance observation duration, set of acceptance indicators, indicator thresholds, conditions for expanding release, conditions for suspending release, and rollback trigger conditions. Step S6: Execute the change release in batches according to the vehicle group level, and collect the acceptance indicator data of the corresponding vehicle group in real time; Step S7: Compare the acceptance indicators with the control rules of the corresponding vehicle group, and dynamically execute expanded release, pause or partial rollback; Step S8: Feed the published results back into the risk profile dataset to optimize subsequent stratification strategies.

2. The method for hierarchical acceptance of vehicle group risk profiling and vehicle network change release according to claim 1, characterized in that, In step S1, the operations and maintenance personnel create a change task on the release platform, configure the change type, target vehicle range, effective time, version information and rollback plan, and filter the target vehicle set according to the target vehicle tags, regions, vehicle models and version conditions.

3. The method for hierarchical acceptance of vehicle group risk profiling and vehicle network change release according to claim 1, characterized in that, In step S2, the basic data includes, but is not limited to, vehicle attribute data, terminal version data, network connection data, and regional distribution data, while the historical data includes, but is not limited to, historical online stability data, historical release success rate data, and historical anomaly data.

4. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 1, characterized in that, In step S3, the vehicle group is divided into low-risk vehicle group, medium-risk vehicle group, high-risk vehicle group, and observation vehicle group.

5. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 1, characterized in that, In step S4, the risk parameter set is connected. Including adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate ; Then connect the risk parameter set Represented as: ； In the formula, , , and Adhesion failure rate Heart rate interruption Weak network reconnection rate Frequent network switching rate The weighting coefficients satisfy: ； Compatibility risk parameter set Including the probability of dependency conflicts between the target version and the current terminal version Probability of configuration inconsistency Historical compatibility anomaly trigger rate ; Then the set of compatibility risk parameters Represented as: ； In the formula, , and These represent the probability of dependency conflicts between the target version and the current terminal version. Probability of configuration inconsistency Historical compatibility anomaly trigger rate The weighting coefficients satisfy: ； Set of operational risk parameters Including the probability of offline increment after release , probability of triggering functional abnormality alarm Upgrade failure rate ; Then run the risk parameter set Represented as: ； In the formula, , and The offline incremental probability after release , probability of triggering functional abnormality alarm Upgrade failure rate The weighting coefficients satisfy: ； Recovery risk parameter set Including remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate ; Then restore the set of risk parameters Represented as: ； In the formula, , and Remote rollback unreachability Breakpoint recovery failure rate Historical rollback failure rate The weighting coefficients satisfy: ； Further connect the risk parameter set Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set By integrating the data, we obtain the overall risk profile value of the target vehicle group. : ； In the formula, , , and These are the sets of connection risk parameters. Compatibility risk parameter set Set of operational risk parameters and recovery risk parameter set The image fusion weight, and satisfying 。 6. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 5, characterized in that, In step S5, the comprehensive control level is calculated based on the set of parameters. ,Right now: ； In the formula, This represents the control rule mapping function and the control level. It is represented as a set of control template identifiers, used to select the corresponding control rules.

7. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 1, characterized in that, In step S6, the acceptance indicators include, but are not limited to, changes in online rate, heartbeat recovery rate, upgrade success rate, number of abnormal alarms, increase in connection interruption, and remote reachability.

8. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 1, characterized in that, In step S7, based on the comparison results, the system dynamically performs expanded release, pause, or partial rollback, specifically including: If a vehicle group meets the conditions for expanding the release, the release scope of that vehicle group or the next level vehicle group will be further expanded. If a vehicle group does not meet the conditions for expanding the release or has not reached the rollback threshold, then keep it under observation or suspend the release of that layer. If a vehicle group meets the rollback trigger condition, a partial rollback will be performed on that vehicle group without affecting other vehicle group levels that have passed the acceptance test.

9. The method for hierarchical acceptance of vehicle group hierarchical risk profiling and vehicle network change release according to claim 1, characterized in that, In step S8, after the release is completed, the actual release success rate, anomaly type, rollback trigger record and recovery result of each vehicle group are written back to the risk profile database to optimize the vehicle group stratification and acceptance rules for subsequent similar change tasks.

10. A vehicle-to-everything (V2X) change release layered acceptance system based on the vehicle group layered risk profiling method described in claims 1-9, characterized in that, include: The data acquisition module is used to collect vehicle attribute data, terminal version data, network connection data, regional distribution data, historical operation data, and historical release result data of the target vehicle set; The vehicle grouping module is used to cluster, group, or divide the target vehicle set according to multiple risk-related dimensions to form vehicle groups with at least two different risk levels. The risk profiling module is used to generate multi-dimensional risk profiles for each vehicle group, including a set of parameters for connectivity risk, compatibility risk, operational risk, and recovery risk. The rule generation module is used to generate hierarchical acceptance control rules corresponding to each vehicle group based on the risk profile of that vehicle group. The release execution module is used to execute batch releases according to vehicle group level and corresponding rules; The acceptance judgment module is used to collect acceptance indicators during the release process, compare the acceptance indicators with the acceptance rules of the corresponding vehicle group, and output the acceptance results. The control decision module is used to execute expanded release, maintain observation, pause release, or partial rollback based on the acceptance results. The results feedback module is used to write back the acceptance results released in this round to the risk profile dataset to optimize the hierarchical control strategy for subsequent similar change tasks.

Images