Automatic driving model updating method based on operation design domain and electronic device

Abstract

This application provides a method and electronic device for updating autonomous driving models based on operational design domains. The method includes: a sampling step: acquiring vehicle driving data in long-tail autonomous driving scenarios; constructing an event package when a risk event is detected; extracting its feature vector to determine operational design domain units; selecting representative samples and uploading them to the cloud; updating the quantized numerical set of operational design domain units and candidate autonomous driving models based on feedback data; evaluating candidate autonomous driving models to obtain evaluation results and uploading them; when the evaluation results exceed a preset threshold, adding the operational design domain units to a gating matrix whitelist to allow candidate autonomous driving models to participate in vehicle control within the operational design domain units; if an anomaly is detected, using a baseline autonomous driving model to participate in vehicle control and returning to the sampling step. This application can solve the problems of sample duplication and high safety risks in long-tail autonomous driving scenarios.

Description

Technical Field

[0001] This application relates to the field of autonomous driving, and in particular to an autonomous driving model update method and electronic device based on an operational design domain. Background Technology

[0002] The long-tail scenario of autonomous driving has three typical characteristics that distinguish it from the closed-loop data of general machine learning: First, risk events occur suddenly and in clusters in time, and the same accident or danger will generate a large number of adjacent and highly similar consecutive frames and control logs within a few seconds window; Second, the sample distribution is strongly correlated with the Operational Design Domain (ODD), and there are significant non-independent identically distributed differences between different ODD units such as sunny urban areas during the day, ramps on rainy nights, and construction detours; Third, model updates must not only pursue overall accuracy improvement, but also avoid safety degradation in certain specific ODD units.

[0003] Currently, the industry has technical needs for data compliance, traceability, and model safety governance. However, existing closed-loop systems for autonomous driving data typically rely on a basic paradigm that combines high-uncertainty sample screening, federated learning aggregation, and offline evaluation followed by online deployment. This paradigm encounters new technical obstacles in long-tail scenarios: First, directly screening high-uncertainty samples frame by frame can easily lead to the simultaneous selection of a large number of nearly duplicate frames within the same hazard window, resulting in the repeated consumption of bandwidth, annotation, and local training resources. Second, while the cloud may achieve overall metric improvements, candidate models in certain ODD units may still experience localized degradation such as missed detections, trajectory deviations, or increased mishandling of systems. Third, traditional whole-model canary releases and whole-model rollbacks are too coarse-grained, failing to ensure that candidate models are only released within validated ODD units while retaining baseline models for other scenarios. Fourth, the lack of consistent version binding and audit correlation between samples, model versions, shadow evaluations, and rollbacks leads to high costs for subsequent supervision and dispute tracing. Summary of the Invention

[0004] In view of this, embodiments of this application provide an autonomous driving model update method and electronic device based on the operating design domain, so as to eliminate or improve one or more defects existing in the prior art.

[0005] The first aspect of this application provides a method for updating an autonomous driving model based on a runtime design domain, the method comprising: Sampling steps: Acquire vehicle driving data in long-tail scenarios of autonomous driving; when a risk event is detected, construct an event package; the data in the event package includes data within a continuous time window of the risk trigger time in the vehicle driving data; The feature vectors of the event packets are extracted to determine the operational design domain units; representative samples are selected from the event packets based on the operational design domain units, and the representative samples are uploaded to the cloud; the local set of quantitative values ​​of operational design domain units and candidate autonomous driving models are updated based on the feedback data from the cloud; the candidate autonomous driving models are evaluated according to the operational design domain units to obtain evaluation results; and the evaluation results are uploaded to the cloud. When the value of the evaluation result exceeds a preset threshold, the operation design domain unit is written into the gating matrix whitelist to allow the candidate autonomous driving model to participate in vehicle control within the operation design domain unit; If an anomaly is detected in the candidate autonomous driving model, a preset baseline autonomous driving model is used to participate in vehicle control within the operation design domain unit based on the rollback list in the feedback data, and the sampling step is returned to be executed; if automatic emergency braking is triggered, an anomaly record is generated and uploaded to the cloud.

[0006] In some embodiments of this application, it also includes: An audit log is generated and sent to the cloud; wherein the audit log includes an event package identifier, a running design domain unit identifier, a model version identifier, an evaluation decision identifier, and a rollback identifier, and is stored in a hash chain manner.

[0007] In some embodiments of this application, the step of obtaining representative samples from the event packet based on the runtime design domain unit includes: Search within the locally stored set of quantized values ​​for the runtime design domain unit to obtain the quantized value corresponding to the runtime design domain unit for the event packet; Extract the feature vector of the event package to determine the running design domain unit and generate the scene prototype token; The sample value score is obtained by calculating the uncertainty, out-of-distribution degree, risk severity, redundancy, and quantified values ​​of the scenario prototype token joint calculation model; wherein, the operation design domain unit is obtained by discretization according to preset dimensions, which include road type, weather, lighting, speed range, and regional level system. Representative samples are obtained by filtering the data in the event package based on the sample value score and the preset sampling threshold.

[0008] In some embodiments of this application, before uploading the representative sample to the cloud, the method further includes: The representative samples are de-identified and encrypted before being uploaded to a cloud or local annotation platform for annotation.

[0009] In some embodiments of this application, after updating the local set of quantized values ​​for the operational design domain units and the candidate autonomous driving model based on the feedback data from the cloud, the method further includes: The sampling threshold and the weights used when calculating the sample value score are adjusted based on the set of quantized values ​​of the operational design domain unit.

[0010] The second aspect of this application provides a method for updating an autonomous driving model based on a runtime design domain, executed in the cloud, including: The system receives representative samples uploaded by each vehicle terminal, trains a local autonomous driving model corresponding to the operation design domain unit based on each representative sample, and obtains a parameter set corresponding to each representative sample. The representative samples are obtained by the vehicle terminal from the event packet based on the operation design domain unit. The event packet is data within a continuous time window containing the risk trigger time in the vehicle driving data, constructed when the vehicle terminal detects a risk event. The vehicle terminal is used to execute the aforementioned autonomous driving model update method based on the operation design domain. Based on local storage, the local model parameters in each parameter set are aggregated to obtain a candidate autonomous driving model and generate a set of quantized values ​​for the operational design domain unit. The candidate autonomous driving model and the set of quantized values ​​for the operational design domain unit are sent to the vehicle so that the vehicle can evaluate and determine that the candidate autonomous driving model participates in vehicle control within its corresponding operational design domain unit. Receive audit records uploaded by the vehicle terminal, and summarize and store the audit records as evidence.

[0011] In some embodiments of this application, the parameter set includes: trained local model parameters, coverage gain information, quality gain information, regression penalty, and contribution information.

[0012] In some embodiments of this application, the aggregation of local model parameters from each parameter set based on locally stored operational design domain units to obtain candidate autonomous driving models and generate a set of quantized numerical values ​​for operational design domain units includes: For multiple local model parameters belonging to the same operational design domain unit, the aggregation weight is calculated based on the coverage gain information, quality gain information, regression penalty and contribution information uploaded by the vehicle to obtain candidate autonomous driving models; A set of quantized values ​​for each runtime design domain unit is generated based on the evaluation results of each runtime design domain unit stored locally.

[0013] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the aforementioned autonomous driving model update method based on a running design domain.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the described method for updating an autonomous driving model based on a runtime design domain.

[0015] The fifth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the described method for updating an autonomous driving model based on a runtime design domain.

[0016] This application provides a method for updating an autonomous driving model based on an operational design domain. The method includes: a sampling step: acquiring vehicle driving data in a long-tail scenario of autonomous driving; constructing an event package when a risk event is detected; the data in the event package includes data within a continuous time window of the risk trigger moment in the vehicle driving data; extracting feature vectors from the event package to determine operational design domain units; selecting representative samples from the event package based on the operational design domain units, and uploading the representative samples to the cloud; updating the local set of quantitative values ​​of operational design domain units and candidate autonomous driving models based on feedback data from the cloud; evaluating the candidate autonomous driving models according to the operational design domain units to obtain evaluation results; uploading the evaluation results to the cloud; when the value of the evaluation result exceeds a preset threshold, writing the operational design domain unit into a gating matrix whitelist to allow the candidate autonomous driving model to participate in vehicle control within the operational design domain unit; If an anomaly is detected in the candidate autonomous driving model, a preset baseline autonomous driving model is used to participate in vehicle control within the operational design domain unit based on the rollback list in the feedback data, and the sampling steps are returned to be executed. If automatic emergency braking is triggered, an anomaly record is generated and uploaded to the cloud. By first constructing an event window and then performing prototype coding, and selecting samples according to causal event packages and scenario prototypes, the proportion of nearly duplicated samples within the same hazard window can be significantly suppressed, avoiding waste of bandwidth and annotation resources. The sample value score is scored using ODD unit quantization numerical sets, thereby making sampling resources more focused on real vulnerable scenarios. Updating the autonomous driving model through the ODD unit adapter can improve the capability for long-tail scenarios while reducing the damage to baseline stability. The candidate model only takes over control within the verified ODD unit, while the other units continue to use the baseline model, significantly reducing the safety risk of local scenario degradation. At the same time, rollback operations are used to enhance rollback security and audit traceability.

[0017] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0018] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a first autonomous driving model update method based on a runtime design domain in one embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating a second autonomous driving model update method based on a runtime design domain in one embodiment of this application.

[0021] Figure 3 This is a schematic diagram of the vehicle-side architecture of the autonomous driving model update method based on the runtime design domain in an application example of this application.

[0022] Figure 4 This is a schematic diagram of the cloud architecture of the autonomous driving model update method based on the runtime design domain in an application example of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0024] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0025] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0026] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0027] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0028] Therefore, to address the issues of sample duplication and high safety risks in long-tail autonomous driving scenarios, embodiments of this application provide a first autonomous driving model update method based on an operational design domain, a second autonomous driving model update method based on an operational design domain, an electronic device, a computer-readable storage medium, and a computer program product, respectively, to reduce the proportion of duplicate samples and the safety risks of incremental model updates.

[0029] The following examples will provide a detailed description.

[0030] Based on this, embodiments of this application provide a first autonomous driving model update method based on a runtime design domain that can be executed on the vehicle side, see [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Sampling Step: Acquire vehicle driving data in long-tail scenarios of autonomous driving; when a risk event is detected, construct an event package; the data in the event package includes data within a continuous time window of the risk trigger time in the vehicle driving data.

[0031] Specifically, the method can employ in-vehicle electronic devices or in-vehicle intelligent computing devices installed on the vehicle to continuously maintain a multimodal circular cache with a length equal to the sum of the preset risk precursor duration and risk consequence duration. Vehicle driving data in long-tail autonomous driving scenarios includes at least perception results, target trajectory, map context, vehicle status, control commands, driver takeover status, and the current baseline model output. When any of the following conditions are detected: Automatic Emergency Braking (AEB) triggering, Time to Collision (TTC) falling below a threshold, another vehicle suddenly and rapidly entering the vehicle's lane, insufficient planning safety margin, lane keeping violation, driver takeover, or rule engine alarm, a causal event window is constructed centered on the trigger time t_0, thereby constructing an event package.

[0032] Understandably, to ensure that the window can fully express the warning signs, the event itself, and the consequences of the event, and to calculate causal completeness, at least forward sample coverage, backward sample coverage, and sensor time synchronization integrity must be considered. If the forward coverage is below a threshold, the backward coverage is below a threshold, or the time drift of a key sensor exceeds a preset threshold, the window will be marked as an incomplete event package that is only audited and not directly trained.

[0033] Step 200: Extract the feature vector of the event package to determine the operation design domain unit; based on the operation design domain unit, select representative samples from the event package and upload the representative samples to the cloud; update the local operation design domain unit quantization value set and candidate autonomous driving model based on the feedback data from the cloud; evaluate the candidate autonomous driving model according to the operation design domain unit to obtain the evaluation result; upload the evaluation result to the cloud.

[0034] It should also be noted that, based on the event package, multimodal scene prototype encoding and ODD unit mapping are performed. Then, nonlinear sample value scores are calculated, representative samples are selected and uploaded to the cloud, and the local set of quantized values ​​for the running design domain unit and candidate autonomous driving models are updated based on the feedback data returned from the cloud. The evaluation results are then calculated. Notably, when the vehicle is parked or charging, and the onboard computing resources meet preset conditions, training can also be performed locally to obtain the parameter set.

[0035] Understandably, upon receiving a candidate adapter package, i.e., a candidate autonomous driving model, it is run in parallel with the current baseline model. The candidate autonomous driving model only outputs prediction results and control suggestions, without directly driving vehicle control. Shadow evaluation is performed within the ODD unit, rather than simply using global averaging. The following metrics are calculated within the ODD unit: risk stakeholder consistency. Consistency of planned trajectory Risk scenario recall gains Increase in false alarms Takeover triggers incremental and inference latency increment Furthermore, construct the shadow evaluation results: in, to c represents the preset non-negative weight coefficient; c represents the current ODD cell; and Consistency score (positive benefit item); This is the recall gain (positive revenue item); , , All are penalty items; This indicates the count of safety violations (high-weighted penalty items).

[0036] Step 300: When the value of the evaluation result exceeds a preset threshold, the operation design domain unit is written into the gating matrix whitelist to allow the candidate autonomous driving model to participate in vehicle control within the operation design domain unit.

[0037] It should be noted that an ODD unit is added to the gating matrix whitelist only when the evaluation result is greater than or equal to the shadow release threshold and there are no safety violations in M ​​consecutive trips or L consecutive kilometers of evaluation. Gray-scale takeover is not a full-vehicle, full-scenario release, but rather a phased rollout based on the risk level of the ODD unit. The preferred release order is: low-speed closed parks / daytime / sunny days, ordinary urban areas / daytime / sunny days, highways / ramps, nighttime or rainy days, and complex intersections / construction zones. This allows for priority validation of candidate autonomous driving models in low-risk ODD units before gradually expanding to more complex scenarios.

[0038] Step 400: If an anomaly is detected in the candidate autonomous driving model, a preset baseline autonomous driving model is used to participate in vehicle control within the operating design domain unit based on the rollback list in the feedback data, and the sampling step is returned to be executed; if automatic emergency braking is triggered, an anomaly record is generated and uploaded to the cloud.

[0039] Specifically, if an abnormal output is detected from the candidate autonomous driving model, a graded safety degradation strategy is triggered: the candidate model is immediately prohibited from participating in vehicle control, and control is returned to the baseline autonomous driving model; if it is determined to be a serious safety anomaly or violation, the Minimum Risk Maneuver (MRM) or Automatic Emergency Braking (AEB) is triggered first to establish a physical safety state, and then the candidate model version is locked and rolled back based on the rollback list sent from the cloud, and an anomaly record is generated and reported to the cloud.

[0040] As described above, the first autonomous driving model update method based on the operational design domain provided in this application significantly suppresses the proportion of nearly duplicated samples within the same hazard window by first constructing an event window and then performing prototype coding, and by selecting samples according to causal event packages and scene prototypes, thus avoiding waste of bandwidth and annotation resources; it uses ODD unit quantization numerical sets to score sample value, thereby making sampling resources more focused on real vulnerable scenarios; updating the autonomous driving model through ODD unit adapters can improve the capability for long-tail scenarios while reducing the damage to baseline stability; the candidate model only takes over control within verified ODD units, while other units continue to use the baseline model, significantly reducing the safety risk of local scene degradation; at the same time, rollback operations are used to enhance rollback security and audit traceability.

[0041] To further reduce the proportion of duplicate samples and the security risks of incremental model updates, the first autonomous driving model update method based on the operational design domain provided in this application embodiment includes the following content after step 400: Step 500: Generate audit logs and send them to the cloud; wherein, the audit logs include event package identifiers, running design domain unit identifiers, model version identifiers, evaluation decision identifiers, and rollback identifiers, and are stored in a hash chain manner. Specifically, a unified audit log is generated, which may include: audit trail identifier, event package identifier, scenario prototype identifier, runtime design domain unit identifier, sample value score, threshold configuration identifier, baseline model identifier, candidate model identifier, gating decision, rollback code, compatibility hash, contribution credential, timestamp, and preceding audit hash. Each audit log can be stored in a chain using hash chains, and daily summaries can be anchored to a regulatory platform or blockchain when necessary.

[0042] To further reduce the proportion of duplicate samples and the security risks of incremental model updates, in a first autonomous driving model update method based on a runtime design domain provided in this application embodiment, step 200, in which the representative samples are obtained by the runtime design domain unit from the event packet, specifically includes the following: Step 210: Search in the locally stored set of quantized values ​​of the runtime design domain unit to obtain the quantized value corresponding to the runtime design domain unit of the event package.

[0043] Step 220: Extract the feature vector of the event package to determine the running design domain unit and generate the scene prototype token.

[0044] Step 230: Calculate the uncertainty, out-of-distribution degree, risk severity, redundancy, and quantified values ​​of the scenario prototype token joint calculation model to obtain the sample value score; wherein, the operation design domain unit is obtained by discretization according to preset dimensions, and the preset dimensions include road type, weather, illumination, speed range, and regional level system.

[0045] Step 240: Based on the sample value score and the preset sampling threshold, filter the data in the event package to obtain representative samples.

[0046] Specifically, firstly, visual / point cloud intermediate features are extracted from the frozen perceptual backbone network, respectively. Extract trajectory intent features from planning branches The context parsing module extracts contextual features such as road type, weather, lighting, speed range, and region level. And compare the above characteristics with event types Summary of Key Participant Set Concatenate into prototype representation vector Key stakeholders are dynamic targets that pose a potential risk to the autonomous vehicle or have significant interactions with it in autonomous driving scenarios, including motor vehicles, non-motor vehicles, pedestrians, and other dynamic obstacles.

[0047] Secondly, the current scene is discretized and mapped to ODD units, where each ODD unit can be represented as a set of road type, weather, lighting, speed range, and region level. Subsequently, scene prototype tokens are generated, specifically including: event package identifier, runtime design domain unit identifier, prototype representation vector, event type, time span, and a summary of key participant sets. A local prototype library is maintained within each ODD unit. The prototype library is preferably updated using a streaming k-medoids or streaming k-center strategy to maintain representative sample centers under limited vehicle-side resources.

[0048] Finally, for each scenario prototype token, the following four core metrics are calculated: model uncertainty U, out-of-distribution degree O, risk severity R, and redundancy D. Uncertainty U can be composed of the sensor head output entropy, Monte Carlo Dropout trajectory variance, and the decision discrepancy between the baseline model and the rule engine. Out-of-distribution degree O is preferably the minimum distance between the current prototype vector h and the historical prototype center of its ODD unit, obtained after scale normalization. Risk severity R can be calculated by combining the reciprocal of TTC, minimum relative distance, AEB trigger flag, takeover trigger flag, lateral and longitudinal acceleration anomalies, and rule violation flags. Redundancy D can be characterized by the cosine similarity between the current prototype and the selected prototypes, as well as the temporal overlap rate within the same event window. A nonlinear gating method is used to calculate the sample value score. Where i represents the sample. It is a hard-gated factor, only if the causal completeness is... and The value is 1 if the condition is met, otherwise it is 0. This represents the value of the ODD cell weakness heatmap transmitted from the cloud in ODD cell c. , , Adaptive weights associated with ODD units; and The parameter is positive. This nonlinear form avoids the problem of a high-risk dimension being averaged out by other low-risk dimensions. It prioritizes samples that simultaneously possess high uncertainty, high novelty, or high risk, and have low redundancy. In the representative sample selection phase, local maxima of sample value scores are first found along the time axis within a single event window. Then, within the same ODD unit, class center samples are selected based on streaming clustering, thereby suppressing near-duplicate frames of the same risk. The system preferably retains M representative samples per event window, where M can be a configurable positive integer from 1 to 5. To further reduce the proportion of duplicate samples and the security risks of incremental model updates, in a first autonomous driving model update method based on a runtime design domain provided in this application embodiment, step 200, before uploading the representative sample to the cloud, specifically includes the following: Step 250: After de-identifying and encrypting the representative sample, upload it to the cloud or local annotation platform for annotation.

[0049] Specifically, for representative samples, when the multi-sensor consistency score is higher than the threshold and the rule engine risk score is lower than the threshold, local weak labels are generated as a regular replay set; when the multi-sensor consistency score is lower than the threshold, or there is a significant discrepancy between the rule engine and the baseline model output, it is determined to be a high-value long-tail sample, a collaborative annotation request is generated, and desensitized data fragments are extracted and uploaded to the cloud; otherwise, a lightweight annotation request is generated, uploading only the desensitized cropped fragments, trajectory fragments, and scene prototype token summaries for manual or cloud-based collaborative annotation. Desensitization processing preferably includes blurring or masking facial, license plate, and in-vehicle identity features; encrypted storage preferably uses a device key to locally encrypt event packets on the vehicle side. If the local training path is taken, the authorized training process temporarily decrypts the data in memory and immediately erases the plaintext after training is completed; if the collaborative annotation upload path is taken, only the minimum necessary desensitized fragments are encrypted and uploaded using a session key, and the cloud will not access the un-desensitized original data.

[0050] In the research, development, training, and testing processes of the technical solution in this application, the following strict safeguards were adopted when processing personal images and identity information from public places: 1) All image and identity information collection activities in public places are primarily and solely for the purpose of maintaining public safety (e.g., preventing and investigating illegal and criminal activities, and responding to public safety emergencies).

[0051] 2) In the information collection area, clear and prominent signs have been set up to clearly inform the public of the collection area, purpose, information type and responsible agency, so as to protect the public's right to know.

[0052] 3) All information collected will be used solely for the aforementioned public safety purposes and will not be used for any commercial marketing, personalized recommendations, or other purposes unrelated to maintaining public safety.

[0053] 4) All information is stored in a dedicated system or controlled experimental environment with high-level security protection, and strict access control and operation auditing are implemented.

[0054] 5) In research scenarios involving non-real-time security operations such as model training and algorithm verification for the technical solutions of this application, the original data has been thoroughly anonymized or de-identified to ensure that it cannot be identified or associated with any specific natural person.

[0055] To further reduce the proportion of duplicate samples and the security risks of incremental model updates, in a first autonomous driving model update method based on a runtime design domain provided in this application embodiment, after updating the local runtime design domain unit quantization value set and candidate autonomous driving models based on the feedback data from the cloud in step 200, the following content is also specifically included: Step 260: Adjust the sampling threshold and the weights used when calculating the sample value score based on the set of quantized values ​​of the running design domain unit.

[0056] Specifically, the sampling threshold and the weights used to calculate the sample value score are adjusted based on the adaptive weights, sampling thresholds, and shadow release thresholds related to the ODD unit uploaded from the cloud.

[0057] Based on the embodiments and / or application examples of the first autonomous driving model update method based on the above-described operational design domain, this application also provides an embodiment of a second autonomous driving model update method based on the operational design domain, see [link to embodiment]. Figure 2 The second autonomous driving model update method based on the operational design domain specifically includes the following: Step 500: Receive representative samples uploaded by each vehicle terminal, train a local autonomous driving model corresponding to the operation design domain unit based on each representative sample, and obtain a parameter set corresponding to each representative sample; wherein, the representative samples are obtained by the vehicle terminal from the event package based on the operation design domain unit, and the event package is data within a continuous time window containing the risk trigger time in the vehicle driving data, constructed by the vehicle terminal when it detects a risk event; the vehicle terminal is used to execute the first autonomous driving model update method based on the operation design domain.

[0058] Step 600: Aggregate the local model parameters in each parameter set based on the locally stored operation design domain units to obtain a candidate autonomous driving model and generate a set of quantized values ​​for the operation design domain units; send the candidate autonomous driving model and the set of quantized values ​​for the operation design domain units to the vehicle terminal so that the vehicle terminal can evaluate and determine that the candidate autonomous driving model participates in vehicle control within its corresponding operation design domain unit.

[0059] Step 700: Receive the audit records uploaded by the vehicle terminal, and summarize and store the audit records as evidence.

[0060] Specifically, the method can employ electronic devices such as cloud servers located in the cloud. The cloud uses representative samples to train local autonomous driving models corresponding to the operational design domain units to obtain parameter sets. Parameter sets belonging to the same ODD unit are aggregated to obtain candidate autonomous driving models. Simultaneously, a set of quantized numerical values ​​for the operational design domain units and the data for each parameter are generated and sent to the vehicle along with the candidate autonomous driving models.

[0061] As described above, the second autonomous driving model update method based on the operational design domain provided in this application significantly suppresses the proportion of nearly duplicated samples within the same hazard window by first constructing an event window and then performing prototype coding, and by selecting samples according to causal event packages and scene prototypes, thus avoiding waste of bandwidth and annotation resources; it uses ODD unit quantization numerical sets to score sample value, thereby making sampling resources more focused on real vulnerable scenarios; updating the autonomous driving model through ODD unit adapters can improve the capability of long-tail scenarios while reducing the damage to baseline stability; the candidate model only takes over control within the verified ODD units, while the remaining units continue to use the baseline model, significantly reducing the safety risk of local scene degradation; at the same time, rollback operations are used to enhance rollback security and audit traceability.

[0062] To further reduce the proportion of duplicate samples and the security risks of incremental model updates, in a first autonomous driving model update method based on a runtime design domain provided in this application embodiment, the parameter set in step 200 specifically includes the following: The local model parameters, coverage gain information, quality gain information, regression penalty, and contribution information after training.

[0063] Specifically, a training structure that freezes the backbone network and ODD unit adapters can be adopted, updating only the low-rank adaptation (LoRA) parameters, side module parameters, or incremental head parameters related to the current ODD unit. The training loss function can be written as: in, , , The weight hyperparameter represents the weights that balance the loss terms. The task loss is represented on the sample. This is used to constrain candidate models from shifting too much relative to the baseline model on regular samples; Used to ensure that the safety margin does not decrease; This is used for replay constraints on the local stable sample buffer. If a local safe drift is detected after training that exceeds the budget, the local update round is aborted and the result is marked as non-aggregable. The adapter incremental parameters obtained during training are transmitted using a compression method combining 8-bit quantization, top-k sparsity, and error feedback. In addition to parameter differencing, the transmitted message also includes the ODD cell identifier, representative sample count, audit trail identifier, coverage gain information, quality gain information, regression penalty, and contribution information.

[0064] To further reduce the proportion of duplicate samples and the security risks of incremental model updates, in a first autonomous driving model update method based on a runtime design domain provided in this application embodiment, in step 600, the local model parameters in each parameter set of each runtime design domain unit based on local storage are aggregated to obtain a candidate autonomous driving model and generate a quantized numerical set of runtime design domain units, specifically including the following: Step 610: For multiple local model parameters belonging to the same operational design domain unit, calculate the aggregation weight based on the coverage gain information, quality gain information, regression penalty and contribution information uploaded by the vehicle to obtain candidate autonomous driving models and generate a rollback list.

[0065] Step 620: Generate a set of quantized values ​​for each runtime design domain unit based on the evaluation results of each runtime design domain unit stored locally.

[0066] Specifically, for those belonging to the same ODD unit Multiple local model parameters for the vehicle end The uploaded parameters are used to calculate the unnormalized aggregate weights. : Subsequently, normalization is performed using the Softmax function to obtain the final aggregate weights. : in, To cover gain information; For quality gain information; For regression penalty terms; For contribution information; to To balance the preset non-negative hyperparameters of each feature dimension, candidate autonomous driving models are ultimately obtained, and a rollback list is generated. The rollback list records the stable version identifier, allowed rollback range, rollback priority, signature, and failure conditions, thus avoiding model version confusion or incompatibility with vehicle configuration after rollback. Based on the results of the most recent rounds of shadow evaluation, a set of quantified values ​​for the Operation Design Domain (ODD) unit is generated, including at least the risk scenario recall rate decrease, false positive increment, takeover frequency increment, inference latency increment, and sample coverage missing value. Subsequently, a new adaptive weight configuration related to the ODD unit (i.e., ...) is generated based on this. , , ), sampling threshold, and shadow release threshold.

[0067] To further illustrate the embodiments of the first autonomous driving model update method and the second autonomous driving model update method based on the operational design domain described above, this application also provides a specific application example of a dual-interaction autonomous driving model update method based on the operational design domain.

[0068] Existing technologies disclose a federated learning method for vehicle-to-everything (V2X) networks based on active learning and semi-supervised learning. A global model is trained in the cloud and distributed to autonomous vehicles via roadside units. Vehicles update the teacher-student network based on unlabeled data. The cloud then actively aggregates the data based on information evaluation, diversity evaluation, and loss evaluation to obtain a new global model. Another type of existing technology discloses solutions for smart contract verification, blockchain notarization, and access control within a TEE (Trusted Entity Environment). Existing technologies have the following drawbacks: First, existing frame-by-frame uncertainty screening cannot distinguish between nearly duplicated samples and truly scarce novel long-tail causal samples within the same hazard window, leading to duplicate uploads, duplicate annotations, and duplicate training. Second, existing combinations of active learning and federated learning mostly remain at the client selection or sample scoring level, lacking a closed-loop mechanism that uses shadow pattern degradation information to adjust sampling thresholds, training weights, and aggregation weights. Third, existing whole-model shadow evaluation and whole-model gray-scale release are too coarse-grained, failing to address the unique safety issues of autonomous driving where overall performance improves but local ODD units degrade. Fourth, existing rollback solutions often only describe restoring the previous version, without clearly defining the strong binding relationship between the baseline version, adapter version, vehicle configuration compatibility, and rollback list, easily leading to version confusion or incompatibility after rollback. Fifth, if the audit solution only records general log hashes without binding event packets, ODD units, gating decisions, and rollback reasons, it is difficult to support subsequent compliance audits and accountability.

[0069] To address the aforementioned shortcomings, the purpose of this application example is: 1. Construct a joint selection mechanism of causal event window and scenario prototype for long-tail scenarios of autonomous driving, and prioritize the retention of high-value long-tail samples that are truly causally representative under the same bandwidth and annotation budget.

[0070] 2. Construct a nonlinear sample value scoring and ODD unit-level federated aggregation mechanism driven by the quantized numerical set of the design domain unit, so that sample selection, local training and cloud aggregation are optimized around weak ODD units.

[0071] 3. Construct a gating mechanism that allows candidate adapters to take over control only within ODD units that pass shadow verification, and provide a rollback list that is strongly bound to the compatibility vector to reduce the security risks of incremental model deployment.

[0072] 4. Establish a consistent audit chain between samples, model versions, gating decisions, and rollback actions to meet the compliance requirements for autonomous driving data security and model governance.

[0073] The dual-interaction autonomous driving model update method based on the runtime design domain provided in this application example specifically includes the following: Vehicle-side data usage and model iteration must balance privacy, security, traceability, and explainability. Therefore, simply stacking active learning, federated learning, shadow mode, canary releases, and audit logs side-by-side is insufficient to support truly feasible and licensable technical solutions for long-tail autonomous driving scenarios. This application example features two coupled closed loops: the first loop comprises causal event window construction, scene prototype encoding, nonlinear value scoring, and ODD unit adapter training, addressing the problem of near-repeating samples overwhelming effective samples in long-tail scenarios; the second loop involves ODD unit shadow evaluation, gating matrix whitelist takeover, rollback operations, and the reverse-driving of the next round of sampling using the quantized numerical set of the running design domain units, addressing the issue of overall improved performance but still exhibiting safety degradation in specific ODD units. This application example is a dedicated closed-loop solution designed to address two unique technical obstacles in long-tail autonomous driving scenarios: the repetitive bursts of samples within event windows and localized safety degradation at the ODD unit level.

[0074] It should also be noted that the vehicle-side architecture diagram is as follows: Figure 3 As shown, the cloud architecture diagram is as follows: Figure 4As shown. The vehicle-side device may include seven core modules: 101 Risk Triggering and Causal Event Window Construction Module, 102 Multimodal Prototype Encoding Module, 103 Nonlinear Value Scoring and Streaming Clustering Module, 104 Labeling Collaboration Module, 105 Sample Reporting and Update Interaction Module, 106 Shadow Gating Assessment and Gray-Scale Takeover Module, and 107 Rollback and Storage Module. The cloud-based device may include: 201 Adapter Aggregation Module, 202 ODD Unit Quantization Numerical Set Generation Module, 203 Configuration Distribution Module, and 204 Audit Traceability Module.

[0075] The system comprises the following modules: a risk triggering and causal event window construction module, used to construct an event package when a risk event is detected; a multimodal prototype encoding module, used to extract feature vectors from the event package to determine the operating design domain unit and generate a scene prototype token; a nonlinear value scoring and streaming clustering module, used to jointly calculate the sample value score based on the scene prototype token and filter the data in the event package to obtain representative samples; a labeling collaboration module, used to anonymize and encrypt the representative samples and upload them to a cloud or local labeling platform for labeling; a sample reporting and update interaction module, used to interact with the cloud for data exchange; a shadow gating evaluation and gray-scale takeover module, used to determine whether the candidate autonomous driving model is allowed to participate in vehicle control within the operating design domain unit based on the evaluation results; a rollback and storage module, used to perform a rollback if an anomaly is detected; an adapter aggregation module, used to aggregate local model parameters in each parameter set to obtain a candidate autonomous driving model; an ODD unit quantized value set generation module, used to generate an operating design domain unit quantized value set; a configuration distribution module, used to send the candidate autonomous driving model and the operating design domain unit quantized value set to the vehicle; and an audit traceability module, used to summarize and store the audit records uploaded by the vehicle.

[0076] The application examples of this application have at least the following advantages: 1. The sampling method has been upgraded from frame-by-frame sampling to sampling based on causal event packets and scene prototypes. By first constructing a causal event window and then performing prototype encoding and class center selection, the proportion of nearly duplicated samples within the same hazard window can be significantly suppressed, avoiding waste of bandwidth and annotation resources.

[0077] 2. The scoring method has been upgraded from static scoring to nonlinear scoring driven by a set of quantified numerical values ​​of ODD units. The sample value is no longer a fixed linear weight, but is coupled with the weakness and redundancy of ODD units, thereby making the sampling resources more focused on real weak scenarios.

[0078] 3. Upgrade from whole model update to ODD unit adapter update. By freezing the backbone network and applying drift budget constraints, it is possible to improve long-tail scene capabilities while reducing the impact on baseline stability.

[0079] 4. The model has been upgraded from whole-model shadow evaluation to ODD unit-level gating and release. The candidate model can take over control only within the ODD units that pass the shadow verification, while the remaining units continue to use the baseline model, which significantly reduces the safety risk of overall performance improvement but local scene degradation.

[0080] 5. The rollback process has been upgraded from a general rollback to a rollback operation with compatibility vectors. This solution not only restores the previous stable version but also ensures that the rolled-back version remains consistent with the current vehicle configuration, tagging system, and software dependencies.

[0081] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the first autonomous driving model update method based on the operational design domain and / or the second autonomous driving model update method based on the operational design domain mentioned in the above embodiments. The processor and the memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and the memory via wired or wireless means.

[0082] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0083] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the first autonomous driving model update method based on the runtime design domain and / or the second autonomous driving model update method based on the runtime design domain in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the first autonomous driving model update method based on the runtime design domain and / or the second autonomous driving model update method based on the runtime design domain in the above method embodiments.

[0084] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0085] The one or more modules are stored in the memory, and when executed by the processor, they execute the first autonomous driving model update method based on the running design domain and / or the second autonomous driving model update method based on the running design domain in the implementation embodiment.

[0086] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0087] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0088] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0089] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the aforementioned first autonomous driving model update method based on an operational design domain and / or the second autonomous driving model update method based on an operational design domain. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0090] This application also provides a computer program product, specifically comprising a computer program that, when executed by a processor, implements the steps of the first autonomous driving model update method based on the operating design domain and / or the second autonomous driving model update method based on the operating design domain mentioned in the foregoing embodiments.

[0091] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0092] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0093] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0094] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for updating an autonomous driving model based on a runtime design domain, characterized in that, The method, executed on the vehicle side, includes: Sampling steps: Acquire vehicle driving data in long-tail scenarios of autonomous driving; when a risk event is detected, construct an event package; the data in the event package includes data within a continuous time window of the risk trigger time in the vehicle driving data; The feature vectors of the event packets are extracted to determine the operational design domain units; representative samples are selected from the event packets based on the operational design domain units, and the representative samples are uploaded to the cloud; the local set of quantitative values ​​of operational design domain units and candidate autonomous driving models are updated based on the feedback data from the cloud; the candidate autonomous driving models are evaluated according to the operational design domain units to obtain evaluation results; and the evaluation results are uploaded to the cloud. When the value of the evaluation result exceeds a preset threshold, the operation design domain unit is written into the gating matrix whitelist to allow the candidate autonomous driving model to participate in vehicle control within the operation design domain unit; If an anomaly is detected in the candidate autonomous driving model, a preset baseline autonomous driving model is used to participate in vehicle control within the operation design domain unit based on the rollback list in the feedback data, and the sampling step is returned to be executed; if automatic emergency braking is triggered, an anomaly record is generated and uploaded to the cloud.

2. The autonomous driving model update method based on the operational design domain according to claim 1, characterized in that, Also includes: An audit log is generated and sent to the cloud; wherein the audit log includes an event package identifier, a running design domain unit identifier, a model version identifier, an evaluation decision identifier, and a rollback identifier, and is stored in a hash chain manner.

3. The autonomous driving model update method based on the operational design domain according to claim 1, characterized in that, The process of selecting representative samples from the event package based on the operational design domain unit includes: Search within the locally stored set of quantized values ​​for the runtime design domain unit to obtain the quantized value corresponding to the runtime design domain unit for the event packet; Extract the feature vector of the event package to determine the running design domain unit and generate the scene prototype token; The sample value score is obtained by calculating the uncertainty, out-of-distribution degree, risk severity, redundancy, and quantified values ​​of the scenario prototype token joint calculation model; wherein, the operation design domain unit is obtained by discretization according to preset dimensions, which include road type, weather, lighting, speed range, and regional level system. Representative samples are obtained by filtering the data in the event package based on the sample value score and the preset sampling threshold.

4. The autonomous driving model update method based on the operational design domain according to claim 1, characterized in that, Before uploading the representative sample to the cloud, the process also includes: The representative samples are de-identified and encrypted before being uploaded to a cloud or local annotation platform for annotation.

5. The autonomous driving model update method based on the operational design domain according to claim 1, characterized in that, After updating the local set of quantized numerical values ​​for the operational design domain units and the candidate autonomous driving models based on the feedback data from the cloud, the method further includes: The sampling threshold and the weights used when calculating the sample value score are adjusted based on the set of quantized values ​​of the operational design domain unit.

6. A method for updating an autonomous driving model based on a runtime design domain, characterized in that, Executed in the cloud, including: The system receives representative samples uploaded by each vehicle terminal, trains a local autonomous driving model corresponding to the operation design domain unit based on each representative sample, and obtains a parameter set corresponding to each representative sample; wherein, the representative samples are obtained by the vehicle terminal from the event packet based on the operation design domain unit, and the event packet is data within a continuous time window containing the risk trigger time in the vehicle driving data, constructed by the vehicle terminal when it detects a risk event; the vehicle terminal is used to execute the autonomous driving model update method based on the operation design domain as described in any one of claims 1 to 5. Based on local storage, the local model parameters in each parameter set are aggregated to obtain a candidate autonomous driving model and generate a set of quantized values ​​for the operational design domain unit. The candidate autonomous driving model and the set of quantized values ​​for the operational design domain unit are sent to the vehicle so that the vehicle can evaluate and determine that the candidate autonomous driving model participates in vehicle control within its corresponding operational design domain unit. Receive audit records uploaded by the vehicle terminal, and summarize and store the audit records as evidence.

7. The autonomous driving model update method based on the operational design domain according to claim 6, characterized in that, The parameter set includes: trained local model parameters, coverage gain information, quality gain information, regression penalty, and contribution information.

8. The autonomous driving model update method based on the operational design domain according to claim 6, characterized in that, The process of aggregating local model parameters from various parameter sets within each locally stored operational design domain unit to obtain candidate autonomous driving models and generating a set of quantized numerical values ​​for the operational design domain units includes: For multiple local model parameters belonging to the same operational design domain unit, the aggregation weight is calculated based on the coverage gain information, quality gain information, regression penalty and contribution information uploaded by the vehicle to obtain candidate autonomous driving models and generate a rollback list. A set of quantized values ​​for each runtime design domain unit is generated based on the evaluation results of each runtime design domain unit stored locally.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor, when executing the computer program, implements the autonomous driving model update method based on the operational design domain as described in any one of claims 1 to 5.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor, when executing the computer program, implements the autonomous driving model update method based on the operating design domain as described in any one of claims 6 to 8, and is located in the cloud.

Images