An automobile OTA upgrade access control method, device, equipment and medium

Abstract

The application provides an automobile OTA upgrade access control method, device, equipment and medium, effectively solves the problem that the prior art lacks a systematic technical solution that can establish a dynamic behavior baseline, actively explore unknown risks, and automatically control the safety access of automobile software based on multi-dimensional quantitative data. The method comprises the following steps: obtaining a candidate software version, running the candidate software version under a preset standard scene set and a generalization scene set, and obtaining standard test results and driving behavior entropy; multi-dimensionally evaluating the standard test results and the driving behavior entropy and the dynamic safety baseline profile of the currently deployed software version of the automobile to obtain evaluation results, and fusing the evaluation results and the quantitative decision rule to obtain access evaluation results; based on the access evaluation results, deploying the candidate software version on the automobile, and obtaining the driving behavior entropy and the driver intervention entropy after deployment to determine the OTA access of the candidate software version.

Description

Technical Field

[0001] This application relates to the field of automotive software upgrade technology, and more specifically, to a method, device, equipment, and medium for automotive OTA upgrade access control. Background Technology

[0002] With the rapid development of intelligent connected vehicles, continuous iterative upgrades of intelligent driving systems via Over-the-Air (OTA) software upgrades have become the norm. However, this "continuous evolution" model brings safety challenges that traditional static certification systems cannot address.

[0003] First, there is a lack of dynamic safety benchmarks and a single evaluation dimension. Existing vehicle type approvals or simple regression tests mainly target fixed software versions and fixed high-level functional performance indicators (such as lateral error and time-to-collision (TTC)). This approach cannot establish dynamically evolving safety benchmarks for each OTA update, nor does it provide micro-monitoring of the continuous underlying control behavior patterns of the system. Upgrades may lead to hidden degradation risks in long-tail scenarios, where "performance indicators appear to be acceptable, but control behavior has become rigid, oscillating, or unpredictable."

[0004] Secondly, there are limitations to the testing methods. Current pre-upgrade testing is mostly based on limited, known scenario libraries for "retrospective" verification, essentially a review of known capabilities. This makes it difficult to effectively assess the generalization ability and behavioral robustness of data-driven algorithm models when facing "unknown scenarios" outside the training data distribution. Some potential risks only become apparent when the model encounters "inflection point" scenarios near its decision boundary.

[0005] Secondly, there is a lack of objective, quantifiable entry standards and forward-looking risk assessment tools. Upgrade decisions often rely on engineers' subjective experience or the pass rate of limited tests, lacking a mechanism to quantify the uncertainty of system decisions and make automated, evidence-based safety judgments. Existing technologies also lack effective methods for proactively exploring these "inflection point" scenarios before upgrades.

[0006] For example, the existing patent "A Software Upgrade Management Method, Apparatus, Readable Storage Medium, Computer Program Product, and Autonomous Vehicle for Autonomous Vehicles" (Application No.: 202511430934.3) provides a software upgrade management method for autonomous vehicles, but it still fails to solve the problem of proactively and quantitatively assessing the software's ability to generalize to unknown scenarios before the upgrade. Therefore, there is an urgent need for a systematic technical solution that can establish dynamic behavioral baselines, proactively explore unknown risks, and perform automated safety access control based on multi-dimensional quantitative data. Summary of the Invention

[0007] In view of this, the purpose of this application is to provide a method, device, equipment and medium for access control of automotive OTA upgrades, which effectively solves the problem that the existing technology lacks a systematic technical solution that can establish dynamic behavioral baselines, actively explore unknown risks and perform automated safety access control of automotive software based on multi-dimensional quantitative data.

[0008] In a first aspect, embodiments of this application provide a method for controlling access to automotive OTA upgrades, the method comprising: Obtain candidate software versions for the vehicle to be upgraded, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy; The standard test results and driving behavior entropy are evaluated from multiple dimensions based on the dynamic safety baseline profile of the current software version deployed in the vehicle to obtain the evaluation results. The evaluation results and quantitative decision rules are then integrated to obtain the access evaluation results. Based on the access evaluation results, the candidate software version is deployed on the vehicle, and the driving behavior entropy and driver intervention entropy after deployment are obtained, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

[0009] In conjunction with the first aspect, this application provides a first possible implementation of the first aspect, wherein the standard test results and driving behavior entropy are evaluated from multiple dimensions based on a dynamic safety baseline profile of the currently deployed software version of the vehicle to obtain evaluation results, including: The evidence chain based on results, behavior, and risk includes multi-dimensional evaluation dimensions such as functional performance evaluation, behavioral similarity evaluation, and driving behavior entropy comparison evaluation. Perform each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile.

[0010] In conjunction with the first aspect, this application provides a second possible implementation of the first aspect, wherein evaluating the standard test results, driving behavior entropy, and dynamic safety baseline profile includes: Under a preset set of standard scenarios, functional metrics of the currently deployed software version in the vehicle are collected based on real driving data and / or fully validated closed-loop simulation test data. Behavioral feature vectors that characterize control behavior patterns are extracted synchronously and integrated with the functional indicators to form a dynamic safety baseline profile.

[0011] In conjunction with the first aspect, embodiments of this application provide a third possible implementation of the first aspect, wherein each evaluation dimension is performed to evaluate the standard test results, generalization test results, and dynamic security baseline profile, including: Calculate the dynamic time warping distance between the control signal sequences corresponding to the behavioral feature vectors of the candidate version and the currently deployed version under the same standard scenario; The dynamic time warping distance is calculated based on a preset dynamic time warping distance reference value to obtain a behavioral similarity evaluation score.

[0012] In conjunction with the first aspect, embodiments of this application provide a fourth possible implementation of the first aspect, wherein performing each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile further includes: For each functional performance evaluation dimension, a non-inferiority test is performed, and the statistic is calculated. Based on the aforementioned statistics, the non-inferiority test was determined to be passed, and the final functional performance evaluation score was determined.

[0013] In conjunction with the first aspect, this application provides a fifth possible implementation of the first aspect, wherein the admission evaluation result is obtained by integrating the evaluation result and the quantitative decision rule, including: The functional performance evaluation score, behavioral similarity evaluation score, and driving behavior entropy evaluation score in the evaluation results are each assigned a corresponding dynamic weight. The evaluation result is obtained based on the performance evaluation score of the dynamic weight fusion function, the behavior similarity evaluation score, and the driving behavior entropy evaluation score, and the admission evaluation result is obtained based on the quantitative judgment rule.

[0014] In conjunction with the first aspect, this application provides a sixth possible implementation of the first aspect, wherein obtaining the admission evaluation result based on the quantitative judgment rule includes: Based on the type of the software to be upgraded, determine whether the software to be upgraded is a software with strong security associations; If so, a new evaluation standard is selected to re-evaluate the evaluation results and obtain the final access evaluation results.

[0015] Secondly, embodiments of this application provide an automotive OTA upgrade access control device, the device comprising: The acquisition module is used to acquire candidate software versions of the software to be upgraded for the vehicle, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy. The evaluation module is used to evaluate the standard test results and driving behavior entropy from multiple dimensions based on the dynamic safety baseline profile of the currently deployed software version of the vehicle, obtain the evaluation results, and integrate the evaluation results and quantitative decision rules to obtain the admission evaluation results. The deployment module is used to deploy the candidate software version on a vehicle based on the access evaluation results, and to obtain the driving behavior entropy and driver intervention entropy after deployment, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

[0016] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of any of the automotive OTA upgrade access control methods described above are performed.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of any of the automotive OTA upgrade access control methods described in the present application.

[0018] This application provides a method for OTA upgrade access control in automobiles. The method first obtains candidate software versions of the software to be upgraded for the vehicle. Under preset standard scenario sets and generalized scenario sets, the candidate software versions are run to obtain standard test results and driving behavior entropy. Then, based on the dynamic safety baseline profile of the currently deployed software version in the vehicle, the standard test results and driving behavior entropy are evaluated from multiple dimensions to obtain an evaluation result. This evaluation result is then fused with quantitative decision rules to obtain an access evaluation result. Finally, based on the access evaluation result, the candidate software version is deployed on the vehicle, and the driving behavior entropy and driver intervention entropy after deployment are obtained. The OTA access of the candidate software version is determined based on these driving behavior entropy and driver intervention entropy. Based on this method, this application breaks through the limitations of traditional OTA upgrades that rely on static functional indicators and known scenario verification, and pioneers a dual-track evaluation paradigm of "dynamic behavior baseline + driving behavior entropy". By constructing a three-dimensional quantitative evaluation system covering functional performance, underlying behavioral characteristics, and decision uncertainty in generalized scenarios, it is possible to accurately identify hidden risks such as oscillations, mutations, and pattern drift that are qualified in terms of indicators but exhibit abnormal control behaviors. Utilizing high-value scenario-oriented generalization and quantitative modeling of driving behavior entropy, it enables forward-looking exploration of algorithm robustness in long-tail and edge scenarios. Combining functional performance evaluation dimensions, behavioral similarity evaluation dimensions, and driving behavior entropy comparison evaluation dimensions, it ensures that access decisions possess statistical significance, behavioral comparability, and risk traceability. Based on the access evaluation results and the closed-loop monitoring mechanism jointly determined by driving behavior entropy and driver intervention entropy after deployment, it balances safety baselines with evolutionary flexibility, fully meeting the core requirements of the evidence chain for expected functional safety, dynamic adaptability, and human-machine collaboration credibility. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating an OTA upgrade access control method for automobiles provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating the multi-dimensional evaluation process provided in an embodiment of this application is shown; Figure 3 A schematic diagram illustrating the process of obtaining admission evaluation results provided in an embodiment of this application is shown; Figure 4 This paper shows a structural block diagram of an automotive OTA upgrade access control device provided in an embodiment of this application; Figure 5 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0022] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0023] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0024] Existing technologies lack a systematic approach to OTA upgrade access for automobiles, which can establish dynamic behavioral baselines, proactively detect unknown risks, and implement automated security access control based on multi-dimensional quantitative data.

[0025] Based on this, embodiments of this application provide a method, apparatus, device, and medium for controlling access to automotive OTA upgrades, which are described below through embodiments.

[0026] Example 1 To facilitate understanding of this embodiment, a detailed description of the automotive OTA upgrade access control method disclosed in this application embodiment will be provided first. For example... Figure 1 The diagram shows a flowchart of a method for controlling access to an over-the-air (OTA) upgrade for automobiles. This application provides a method for controlling access to an OTA upgrade for automobiles, the method comprising: S101. Obtain candidate software versions for the vehicle to be upgraded, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy. S102. Based on the dynamic safety baseline profile of the currently deployed software version of the vehicle, evaluate the standard test results and driving behavior entropy from multiple dimensions to obtain the evaluation results, and integrate the evaluation results and quantitative decision rules to obtain the access evaluation results. S103. Based on the access evaluation results, deploy the candidate software version on the vehicle and obtain the driving behavior entropy and driver intervention entropy after deployment, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

[0027] In step S101, this application first obtains candidate software versions of the software to be upgraded for the vehicle, and loads the candidate software versions of the software to be upgraded onto a standardized test platform (which may be Hardware-in-the-Loop (HIL), Vehicle-in-the-Loop (VIL), or a high-fidelity simulation environment). On this platform, a preset set of standard scenarios is run. The set of standard scenarios covers typical operating conditions of intelligent driving systems, including no less than 50 core scenarios screened by functional safety analysis, such as highway lane centering, urban traffic jam following, unprotected left turns, detours in construction zones, and low-light nighttime recognition. In each scenario, functional performance indicators are automatically collected and structuredly recorded, such as the mean and standard deviation of lateral deviation, braking response time, target detection recall rate, curvature continuity of the planned path, and behavioral feature vectors represented by the underlying continuous control signal sequence, such as at least one of steering wheel angle, yaw rate, and longitudinal acceleration. Based on the functional performance indicators and behavioral feature vectors, structured standard test results are formed. Simultaneously, a generalized scenario evaluation process for candidate software versions is initiated: based on historical accident data and high-value real-world driving segments collected using shadow patterns, such as sharp bends and slippery roads, sudden pedestrian appearances and strong glare, and multi-objective game intersections, key parameters such as curvature, light intensity, target relative speed, and road adhesion coefficient are extracted. Within its physically feasible range, orthogonal sampling and combination mutation are performed to generate a generalized scenario subset of over 2000 scenarios covering the training distribution. The candidate software version is then run through this generalized scenario set one by one, outputting a complete control behavior sequence within a unit time window for each scenario. The corresponding driving behavior entropy is calculated based on this sequence. The driving behavior entropy comprehensively reflects the frequency, intensity, and spectral disorder of the system's control commands in this unfamiliar scenario, serving as a core quantitative representation of its decision robustness and predictability. Standard test results and driving behavior entropy together constitute a "two-dimensional behavioral profile" of the candidate software version, providing complete, comparable, and reproducible empirical input for subsequent multi-dimensional comparisons with dynamic safety baselines. The driving behavior entropy is calculated using the following formula: DBE = α * (N abrupt / T) + β* S abrupt + γ * H spectral ; Where, N abrupt S is the number of times the change in the control signal exceeds a preset abrupt change threshold within a time window T. abrupt H is the sum of the absolute values ​​of all signal changes exceeding the mutation threshold within the time window. spectralThe information entropy of the control signal power spectrum within the time window is defined as follows: a stable and predictable candidate software version typically has its control signal power spectrum concentrated in a few frequency bands (low entropy); while an oscillating or unstable candidate software version has its power dispersed across many frequency bands (high entropy). α, β, and γ are normalized weight coefficients obtained through historical data regression analysis or expert experience calibration, used to quantify the contributions of mutation frequency, mutation intensity, and signal pattern disorder to decision uncertainty, respectively. One method for obtaining α, β, and γ is calibration through historical data analysis: collecting a large amount of driving segment data labeled with "normal driving," "aggressive driving," and "system failure precursors," calculating the three entropy components of each segment, and using classification algorithms such as logistic regression and support vector machines, training the model with the three components as features and driving state as the label. The feature coefficients of the trained model, after normalization, can be used as reference values ​​for the weights α, β, and γ. This ensures that the DBE index has a strong correlation with the actual risk state. Another approach is to allocate based on expert experience and security objectives. For example, if more attention is paid to sudden, large fluctuations, the weight of β can be appropriately increased.

[0028] The extraction of behavioral feature vectors specifically involves: in terms of time domain features, including but not limited to mean, standard deviation, kurtosis, skewness; statistical characteristics of the first-order difference (rate of change) of the signal; zero-crossing rate; autocorrelation features, etc.; in terms of frequency domain features, calculating the power spectral density or its energy proportion of the signal in a specific frequency band (such as 0.1-2Hz reflecting the driver's operating frequency, or a higher frequency band reflecting the oscillation of the control system) through fast Fourier transform; and in terms of nonlinear features, in more complex embodiments, neural networks such as automatic encoders can be used to encode a sequence of control signals over a period of time, and the output of the intermediate layer (latent space) of the encoder can be used as the behavioral feature vector. This method can automatically learn deeper levels of behavioral pattern representation.

[0029] Example: For a lane centering control scenario, the "0.1-1Hz frequency band energy ratio (smoothness index)" and "kurtosis of the steering angle change rate (characterizing whether the steering is smooth or abrupt)" of the steering wheel angle signal in the current version under a smooth straight road scenario can be extracted to form a two-dimensional behavioral feature vector [PSD]. ratio Kurtosis dθ / dt ].

[0030] In step S102, this application also pre-establishes a dynamic safety baseline profile for the current system software version of the vehicle's infotainment system that has historical accident events and the system software deployed for the first time. The dynamic safety baseline profile includes at least functional performance indicators under a preset scenario set, behavioral feature vectors extracted from the continuous control signals at the system's bottom layer to characterize the control behavior pattern, and driving behavior entropy. Then, based on the dynamic safety baseline profile of the current software version of the vehicle, the standard test results and driving behavior entropy are evaluated from multiple dimensions, including functional performance evaluation, behavioral similarity evaluation, and driving behavior entropy comparison evaluation. That is, the candidate software version and the currently deployed version are evaluated in a comprehensive and quantitative manner to obtain the evaluation results. The evaluation results and quantitative judgment rules are then integrated to obtain the admission evaluation results. The admission evaluation results include "red light", "yellow light", or "green light", where "red light" indicates that deployment is prohibited, "green light" indicates that full deployment is allowed, and "yellow light" indicates that deployment is allowed under functional restrictions and triggers a user notification and confirmation process. In the specific implementation of step S102, one embodiment is as follows: Figure 2 As shown, the evaluation results are obtained by using a dynamic safety baseline profile based on the current software version deployed in the vehicle to evaluate the standard test results and driving behavior entropy from multiple dimensions, including: S10211. The evidence chain based on results, behavior, and risk includes multi-dimensional evaluation dimensions such as functional performance evaluation, behavioral similarity evaluation, and driving behavior entropy comparison evaluation. S10212. Perform each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile.

[0031] In steps S10211-S10212, this application constructs a three-layer evidence chain evaluation system with "result-behavior-risk" as the logical main line to ensure that the access decision has the triple support of functional verifiability, behavioral comparability, and risk quantification. The first layer is functional performance evaluation, focusing on whether the candidate software version of the vehicle infotainment system meets the basic safety requirements: the functional performance indicators obtained by the candidate software version in the preset standard scenario set, such as lateral control accuracy, braking distance, and target recognition accuracy, are compared item by item with the historical measured average and fluctuation range of the corresponding scenario in the dynamic safety baseline file, focusing on identifying whether there is statistically significant degradation, especially paying attention to key indicators that directly affect driving safety in the chassis control domain and intelligent driving domain; the second layer is behavioral similarity evaluation, which delves into the execution level of the vehicle infotainment system: extracting the underlying values ​​such as steering wheel angle and yaw rate generated by the candidate software version and the baseline version in the same standard scenario. The control signal sequence is evaluated using the Dynamic Time Warping (DTW) algorithm to calculate its temporal matching distance, assessing the inherent consistency between the two in terms of control rhythm, response mode, and dynamic characteristics, thus avoiding the hidden risk of "qualified indicators but abnormal behavior." The third layer is driving behavior entropy comparison and evaluation, providing forward-looking warnings for unknown risks: the driving behavior entropy values ​​calculated by the candidate software version in various scenarios of the generalized scenario set are compared with the historical entropy distribution of the currently deployed version in the same generalized scenario. This not only detects the existence of local high-entropy clusters (indicating violent oscillations or unpredictability in specific edge scenarios) but also analyzes the degree of deviation in the overall entropy distribution (reflecting systemic changes in the robustness of system behavior). These three evaluation dimensions corroborate each other and progress in layers, together forming a complete chain of evidence covering "usability, stability, and risk."

[0032] In a specific implementation of step S10212, one embodiment includes: evaluating the standard test results, driving behavior entropy, and dynamic safety baseline profile, including: A1. Under a preset standard scenario set, collect functional indicators of the currently deployed software version of the vehicle based on real driving data and / or fully verified closed-loop simulation test data. A2. Simultaneously extract behavioral feature vectors to characterize control behavior patterns, and integrate them with the functional indicators to form a dynamic safety baseline profile.

[0033] In steps A1-A2, the construction of the dynamic safety baseline profile in this application uses real-world operational data from the currently stable deployed software version as the sole reliable source, thereby ensuring the authenticity, representativeness, and verifiability of the data source. Its data acquisition encompasses two complementary paths: first, continuous, non-interventional data collection in a real road environment via vehicle shadow mode. This involves synchronously recording the vehicle's perception inputs (raw data from cameras / radar, positioning information), decision outputs (planned trajectory, control commands), and execution feedback (underlying signals such as steering wheel angle, yaw rate, and longitudinal acceleration) without altering the vehicle's actual control logic, covering typical driving scenarios across multiple climates, road conditions, and time periods nationwide; second, high-fidelity closed-loop simulation test data obtained through a standardized testing platform. This simulation environment has undergone real-vehicle data calibration and scenario coverage verification to ensure its ability to reproduce key boundary conditions. Under a pre-defined set of standard scenarios (such as high-speed lane changes, roundabout traffic, and pedestrian lurking, among 50+ functional safety-driven scenarios), two core elements are structurally extracted from the aforementioned fused data: First, functional indicators, including quantifiable and comparable performance parameters such as the mean and dispersion of lateral deviation, braking response time distribution, target detection miss rate, and frequency of curvature abrupt changes in the planned path; second, behavioral feature vectors, which, through feature engineering, condense the essential attributes representing behavioral patterns from continuous control signals, such as the energy proportion of the steering wheel angle signal in the 0.1–1Hz frequency band (reflecting operational smoothness), the kurtosis of the acceleration rate of change (reflecting the aggressiveness of the response), and the low-dimensional representation of the latent space obtained by compression via an automatic encoder (capturing nonlinear behavioral fingerprints). These two types of elements are strictly spatiotemporally aligned and archived by scenario, together forming a dynamic safety baseline archive with version identifiers, timestamps, and data traceability markers.

[0034] In the specific implementation of step S10212, another embodiment is as follows: Perform each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile, including: B1. Calculate the dynamic time warping distance between the control signal sequences corresponding to the behavioral feature vectors of the candidate version and the current deployment version in the same standard scenario; B2. Calculate the dynamic time warping distance based on the preset dynamic time warping distance reference value to obtain the behavioral similarity evaluation score.

[0035] In steps B1-B2, this application uses s2 to represent the behavioral similarity evaluation score obtained from the behavioral similarity evaluation dimension, which is specifically calculated based on the following formula: s2 = exp[-dtwd(b,c) / dtwd] ref ]; Where s2 is the behavioral similarity evaluation score; dtwd(b,c) is the dynamic time warping distance between the timing control signals of the candidate software version and the current deployment version; dtwd ref The DTW distance is a reference value for dynamic time warping, confirmed by referencing behavioral differences between historical versions. Dynamic time warping allows for flexible scaling of the timeline, finding the optimal matching path between two sequences and handling sequences of varying lengths and rhythmic differences. The DTW distance is calculated using a dynamic programming algorithm to find the path with the minimum cumulative distance among all paths satisfying the constraints. The scoring uses an exponential decay function s², where a score of 1 is assigned when the distance is 0, and the score decreases as the distance increases. ref This serves as a reference value for dynamic time-normalized distance, confirmed based on behavioral differences data between historical versions.

[0036] In the specific implementation of step S10212, another embodiment exists: performing each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile, further including: C1. For each functional performance evaluation dimension, perform a non-inferiority test and calculate the statistic. C2. Based on the aforementioned statistics, the non-inferiority test is determined to be passed, and the final functional performance evaluation score is determined.

[0037] In steps C1-C2, this application uses s1 to represent the functional performance evaluation score obtained from the functional performance evaluation dimension, and the specific calculation formula is as follows: s1 = (1 / m) × ]; Where s1 represents the functional performance evaluation result, and m represents the total number of functional performance indicators; Z i The non-inferiority test statistic (Z) i = [( i - i ) + Δ i ] / ), Z i Convert to (0, 1) values; Δ i This is the non-inferiority threshold for the i-th indicator; i and i s²b is the sample mean of the i-th metric between the current version and the candidate versions; i With s²c i Let n be the sample variance of the i-th metric between the current version and the candidate version; b and n cThis represents the test sample size for the current version and the candidate version. The core idea of ​​the non-inferiority test is to verify that the performance of the candidate software version is "not inferior" to the currently deployed version. This exceeds a preset threshold, and the non-inferiority test statistic Z0 represents this threshold. i = [( i - i ) + Δ i ] / ,in( i - i ) +Δ i This represents the difference between the measured value and the preset threshold value for the candidate software version. When Z... i ≥ Z 1- At α, the non-inferiority test is passed, and the score is Φ(Z). i ), α is generally taken as 0.05; when Z i <Z 1- When α is reached, the test fails, and the score is 0. Finally, s1 is the average of all indicator scores. The non-inferiority margin Δ i The determination can be based on historical data statistics, relative change rate, functional safety level, or expert experience calibration.

[0038] Regarding the driving behavior entropy comparison evaluation dimension, s3 represents the driving behavior entropy comparison evaluation score, which is calculated using the following formula: s3=μ×max(0, 1-λ HESR / θ HESR ) + (1-μ) × max(0, 1-λ BEWD / θ BEWD ); Where μ is the weighting coefficient, which is set according to the content being upgraded; λ HESR For the proportion of high-entropy scenes, λ HESR = (1 / n)× Σ [ec,j>θ high ], where n is the total number of test scenarios; ec,j is the driving behavior entropy value of the candidate software version in the j-th scenario, and θ high As a high entropy threshold, the 95th percentile of the behavioral entropy of the current deployment version is taken. [·] is an indicator function); λ BEWD The Wasserstein distance (λ) for the behavioral entropy distribution BEWD = (1 / n) × Σ |eb,(j) - ec,(j)|, where eb,(j) is the driving behavior entropy of the current version in the j-th scenario; ec,(j) is the driving behavior entropy of the candidate version in the j-th scenario); θ HESR θ is the threshold for the proportion of high-entropy scenes.BEWD is the behavioral entropy distribution distance threshold. HESR is used for tail risk detection, focusing on whether high-risk scenarios exist; BEWD is used for distribution shift detection, focusing on whether the entropy distribution has a significant shift. The two are weighted and fused via a weighting coefficient μ. The scoring adopts the form of max(0, 1 - x / θ): the score is 0 when the index value reaches the threshold, and is truncated to 0 when the index value exceeds the threshold.

[0039] In the specific implementation of step S102, there is another embodiment: as shown in Figure 3 , fusing and evaluating the evaluation result and the quantitative decision rule to obtain an admission evaluation result comprises: S10221: assigning corresponding dynamic weights respectively to the functional performance evaluation score, the behavior similarity evaluation score and the driving behavior entropy evaluation score in the evaluation results; S10222: fusing the functional performance evaluation score, the behavior similarity evaluation score and the driving behavior entropy evaluation score based on the dynamic weights to obtain the evaluation result, and obtaining an admission evaluation result based on the quantitative judgment rule.

[0040] In steps S10221-S10222, the present application performs fusion evaluation based on the analytic hierarchy process. First, a judgment matrix A = [a ij is constructed (wherein, a ij represents the importance degree of the i-th dimension relative to the j-th dimension, which can be assigned by the 1-9 scaling method: a ij = 1 indicates equal importance, a ij = 3 indicates slightly important, a ij = 5 indicates obviously important, a ij = 7 indicates strongly important, a ij = 9 indicates extremely important, and a ji = 1 / a ij ). The relative importance of three dimensions including functional performance, behavior similarity and driving behavior entropy is established, and the weight values λ1, λ2 and λ3 corresponding to each evaluation dimension are calculated by an eigenvalue method, and then substituted to calculate the multi-dimensional comprehensive score S = λ1× s1 + λ2× s2 + λ3× s3. That is, the multi-dimensional comprehensive score S is the final evaluation result. Judgment is performed according to a preset threshold: when S ≥ θ1, it is determined as "green light", and full deployment is allowed; when θ2 < S < θ1, it is determined as "yellow light", and deployment is allowed under function limiting conditions; when S ≤ θ2, it is determined as "red light", and deployment is prohibited. An admission evaluation result is obtained by integrating the obtained evaluation result and the quantitative judgment rule.

[0041] In the specific implementation of step S10222, there is an embodiment: obtaining an admission evaluation result based on the quantitative judgment rule comprises: D1. Based on the type of the software to be upgraded, determine whether the software to be upgraded is a software with strong security association; D2. If so, select a new evaluation standard to re-evaluate the evaluation results and obtain the final access evaluation results.

[0042] In steps D1-D2, the quantitative judgment rules and evaluation results are integrated to obtain the following: If the candidate software version contains upgrades strongly related to safety (including upgrades in the chassis control domain such as braking system, steering system, power system, chassis control system, and intelligent driving domain such as environmental perception, behavior planning, automatic emergency braking, lane keeping assist, etc.), and any of the following conditions are met, the software is judged as "red light": (a) The functional performance indicators show statistically significant degradation and the degradation exceeds the first threshold; (b) The similarity of the behavioral feature vector is lower than the second threshold; (c) In the generalized scenario, the cluster of scenarios where the driving behavior entropy value exceeds the risk threshold, namely (a), (b), and (c) above, are the new evaluation criteria; if it is only an upgrade content that is weakly related to safety (including infotainment system, voice assistant, navigation system, air conditioning control in the cockpit domain and lighting control, window control, door lock control, etc. in the body domain), and the behavior feature vector pattern has not drifted, and the driving behavior entropy distribution in the generalized scenario is not abnormal, then it is judged as "yellow light"; if the evaluation results of all dimensions meet the preset admission criteria, then it is judged as "green light".

[0043] In step S103, based on the "green light" and "yellow light" in the admission evaluation results, the candidate software version is deployed on the vehicle. When it is a "yellow light", a user notification and confirmation process is triggered. The user notification and confirmation process includes: generating explanatory information describing specific functional limitations, performance changes and suggested precautions, and pushing the explanatory information to the user through the in-vehicle human-machine interface before the candidate software version is activated. Deployment can only be performed after obtaining explicit confirmation from the user. The system acquires the post-deployment driving behavior entropy and driver intervention entropy. Specifically, the driving behavior entropy is continuously calculated using the above method. First, it acquires various variables involved in the post-deployment driving behavior entropy, and then calculates the driving behavior entropy according to the above formula. In addition, it collects parameters such as post-deployment driver takeover behavior (takeover frequency, takeover duration, emergency takeover ratio) and correction operations (steering wheel correction amplitude, accelerator / brake intervention frequency) to calculate the driver intervention entropy. The system combines the driving behavior entropy and driver intervention entropy to determine whether the "green light" and "yellow light" access judgment results need to be adjusted. After adjustment, it implements OTA access for the candidate software version. For software versions that obtain "green light" or "yellow light" judgments and are successfully deployed, it collects their actual operating data, updates and stores it as a new dynamic safety baseline file for that version, so that the safety baseline evolves intelligently along with the software update.

[0044] The driver intervention entropy (DIE) is used to quantify the deviation between the control decision results of the intelligent driving system and the driver's expectations, as well as the uncertainty and safety risks of human-machine collaborative behavior. It is calculated based on the following formula: DIE=α d ·(N inter / T)+β d ·Σ|I| critical +γ d ·H inter ; Where, N inter Σ|I| represents the weighted number of effective driver intervention events during the time window T when the intelligent driving function is activated. critical H is the sum of the absolute values ​​of all single intervention intensities exceeding the preset intervention threshold within the time window. inter Let α be the information entropy of the distribution of driver intervention events within the time window under a preset scenario set, and T be a unit time window that is completely consistent with the calculation of driving behavior entropy. d β d γ d The normalized weight coefficients obtained through regression analysis of historical real-vehicle data or calibration based on expert experience satisfy α. d +β d +γ d =1, which are used to quantify the contributions of intervention frequency, intervention intensity, and intervention mode disorder to the uncertainty of human-machine collaborative decision-making.

[0045] This application also includes an audit trail and reporting function to record the system's operation logs, intermediate data, and judgment basis for the software to be upgraded, and to generate an unalterable audit trail report.

[0046] Compared with the prior art, this application has the following significant advantages: 1. It pioneered a new paradigm of "behavioral baseline" monitoring: by introducing behavioral feature vectors as the core of the baseline, it realizes continuous tracking and digital profiling of the micro-pattern of system control behavior, and can keenly discover hidden behavioral drifts that traditional performance KPIs cannot reflect, providing deeper insights for safety assessment.

[0047] 2. It enables proactive detection of unknown risks: By combining "targeted generalization in high-value scenarios" with "quantitative assessment of driving behavior entropy", the testing objective is shifted from "whether the function is implemented" to "whether the behavior is robust". This allows for efficient and targeted discovery of weaknesses in the algorithm's generalization ability and high uncertainty in decision-making in unknown or marginal scenarios.

[0048] 3. An objective and calculable automated access standard has been established: subjective security decisions are transformed into a quantitative calculation process based on statistical testing, feature similarity measurement, and entropy distribution analysis, eliminating the arbitrariness and inconsistency of human judgment, and making the upgrade access "measurable and based on evidence".

[0049] 4. A complete and credible chain of evidence and traceability mechanism has been established: The digital recording and tamper-proof audit logs throughout the entire process naturally meet the stringent requirements of functional safety and expected functional safety standards for traceability and verifiability, providing key technical tools for quality auditing and compliance supervision.

[0050] 5. A balanced management of technological innovation and security risks has been achieved: The "red / yellow / green" three-level judgment mechanism, while safeguarding the absolute bottom line of safety (red light), provides a standardized channel for transparent, controlled, and user-informed functional evolution (yellow light), thus promoting the coordinated development of technological innovation and product safety.

[0051] 6. Achieved dynamic closed-loop adjustment after deployment: By continuously monitoring driving behavior entropy and driver intervention entropy, potential risks can be identified and adjusted in a timely manner in the early stage of deployment, forming a complete closed loop from assessment to deployment to monitoring.

[0052] Example 2 This application also provides a vehicle OTA upgrade access control device, such as... Figure 4 The diagram shows a block diagram of an automotive OTA upgrade access control device. This device performs functions corresponding to the steps of executing an automotive OTA upgrade access control method on a terminal device as described above. The device can be understood as a server component including a processor. The automotive OTA upgrade access control device described in this application includes: The acquisition module 401 is used to acquire candidate software versions of the software to be upgraded for the car, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy. Evaluation module 402 is used to evaluate the standard test results and driving behavior entropy from multiple dimensions based on the dynamic safety baseline profile of the currently deployed software version of the vehicle, obtain evaluation results, and integrate the evaluation results and quantitative decision rules to obtain access evaluation results; The deployment module 403 is used to deploy the candidate software version on a vehicle based on the access evaluation results, and to obtain the driving behavior entropy and driver intervention entropy after deployment, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

[0053] In one feasible implementation, the evaluation module includes: The evidence chain based on results, behavior, and risk includes multi-dimensional evaluation dimensions such as functional performance evaluation, behavioral similarity evaluation, and driving behavior entropy comparison evaluation. Perform each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile.

[0054] In one feasible implementation, the evaluation module further includes: Under a preset set of standard scenarios, functional metrics of the currently deployed software version in the vehicle are collected based on real driving data and / or fully validated closed-loop simulation test data. Behavioral feature vectors that characterize control behavior patterns are extracted synchronously and integrated with the functional indicators to form a dynamic safety baseline profile.

[0055] In one feasible implementation, the evaluation module also includes: Calculate the dynamic time warping distance between the control signal sequences corresponding to the behavioral feature vectors of the candidate version and the currently deployed version under the same standard scenario; The dynamic time warping distance is calculated based on a preset dynamic time warping distance reference value to obtain a behavioral similarity evaluation score.

[0056] In one feasible implementation, the evaluation module further includes: For each functional performance evaluation dimension, a non-inferiority test is performed, and the statistic is calculated. Based on the aforementioned statistics, the non-inferiority test was determined to be passed, and the final functional performance evaluation score was determined.

[0057] In one feasible implementation, the evaluation module further includes: The functional performance evaluation score, behavioral similarity evaluation score, and driving behavior entropy evaluation score in the evaluation results are each assigned a corresponding dynamic weight. The evaluation result is obtained based on the performance evaluation score of the dynamic weight fusion function, the behavior similarity evaluation score, and the driving behavior entropy evaluation score, and the admission evaluation result is obtained based on the quantitative judgment rule.

[0058] In one feasible implementation, the evaluation module further includes: Based on the type of the software to be upgraded, determine whether the software to be upgraded is a software with strong security associations; If so, a new evaluation standard is selected to re-evaluate the evaluation results and obtain the final access evaluation results.

[0059] Example 3 This application also provides an electronic device, such as Figure 5As shown, it includes: a processor 601, a memory 602, and a bus 603. The memory 602 stores machine-readable instructions that can be executed by the processor 601. When the electronic device is running, the processor 601 and the memory 602 communicate through the bus 603. When the machine-readable instructions are executed by the processor 601, the steps of any one of the automotive OTA upgrade access control methods are performed.

[0060] Example 4 This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any one of the automotive OTA upgrade access control methods described herein.

[0061] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0062] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0064] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for controlling access to automotive OTA upgrades, characterized in that, The method includes: Obtain candidate software versions for the vehicle to be upgraded, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy; The standard test results and driving behavior entropy are evaluated from multiple dimensions based on the dynamic safety baseline profile of the current software version deployed in the vehicle to obtain the evaluation results. The evaluation results and quantitative decision rules are then integrated to obtain the access evaluation results. Based on the access evaluation results, the candidate software version is deployed on the vehicle, and the driving behavior entropy and driver intervention entropy after deployment are obtained, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

2. The method according to claim 1, characterized in that, The evaluation results are obtained by multi-dimensionally evaluating the standard test results and driving behavior entropy based on the dynamic safety baseline profile of the currently deployed software version of the vehicle, including: The evidence chain based on results, behavior, and risk includes multi-dimensional evaluation dimensions such as functional performance evaluation, behavioral similarity evaluation, and driving behavior entropy comparison evaluation. Perform each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile.

3. The method according to claim 2, characterized in that, The evaluation of the standard test results, driving behavior entropy, and dynamic safety baseline profile includes: Under a preset set of standard scenarios, functional metrics of the currently deployed software version in the vehicle are collected based on real driving data and / or fully validated closed-loop simulation test data. Behavioral feature vectors that characterize control behavior patterns are extracted synchronously and integrated with the functional indicators to form a dynamic safety baseline profile.

4. The method according to claim 2, characterized in that, Perform each evaluation dimension to evaluate the stated standard test results, generalization test results, and dynamic security baseline profile, including: Calculate the dynamic time warping distance between the control signal sequences corresponding to the behavioral feature vectors of the candidate version and the currently deployed version under the same standard scenario; The dynamic time warping distance is calculated based on a preset dynamic time warping distance reference value to obtain a behavioral similarity evaluation score.

5. The method according to claim 2, characterized in that, Performing each evaluation dimension to evaluate the standard test results, generalization test results, and dynamic security baseline profile also includes: For each functional performance evaluation dimension, a non-inferiority test is performed, and the statistic is calculated. Based on the aforementioned statistics, the non-inferiority test was determined to be passed, and the final functional performance evaluation score was determined.

6. The method according to claim 1, characterized in that, The evaluation results and quantitative decision rules are integrated to obtain the admission evaluation results, including: The functional performance evaluation score, behavioral similarity evaluation score, and driving behavior entropy evaluation score in the evaluation results are each assigned a corresponding dynamic weight. The evaluation result is obtained based on the performance evaluation score of the dynamic weight fusion function, the behavior similarity evaluation score, and the driving behavior entropy evaluation score, and the admission evaluation result is obtained based on the quantitative judgment rule.

7. The method according to claim 6, characterized in that, The admission evaluation results are obtained based on the aforementioned quantitative judgment rules, including: Based on the type of the software to be upgraded, determine whether the software to be upgraded is a software with strong security associations; If so, a new evaluation standard is selected to re-evaluate the evaluation results and obtain the final access evaluation results.

8. A vehicle OTA upgrade access control device, characterized in that, The device includes: The acquisition module is used to acquire candidate software versions of the software to be upgraded for the vehicle, run the candidate software versions under a preset standard scenario set and a generalized scenario set respectively, and obtain standard test results and driving behavior entropy. The evaluation module is used to evaluate the standard test results and driving behavior entropy from multiple dimensions based on the dynamic safety baseline profile of the currently deployed software version of the vehicle, obtain the evaluation results, and integrate the evaluation results and quantitative decision rules to obtain the admission evaluation results. The deployment module is used to deploy the candidate software version on a vehicle based on the access evaluation results, and to obtain the driving behavior entropy and driver intervention entropy after deployment, so as to determine the OTA access of the candidate software version based on the driving behavior entropy and driver intervention entropy.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the automotive OTA upgrade access control method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the automotive OTA upgrade access control method as described in any one of claims 1-7.

Images