Vehicle accident processing method, device, equipment and vehicle

Abstract

Embodiments of the present application provide a vehicle accident processing method, device and equipment, and a vehicle. The method comprises: after determining that a vehicle has an accident, determining a target accident level of the vehicle based on accident-related state data in the vehicle; the target accident level is used to indicate the severity of the current accident of the vehicle; obtaining evidence data of the vehicle according to vehicle state data within a preset time window before and after the accident; the vehicle state data comprises the accident-related state data; determining a target processing step sequence matched with the target accident level and the integrity of the evidence data according to a pre-established candidate step library; and executing the target processing step sequence. The method is used to realize more accurate and intelligent vehicle accident processing, thereby achieving the effect of improving the safety experience and use satisfaction of the user after the accident.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more particularly to a method, apparatus, equipment, and vehicle for handling vehicle accidents. Background Technology

[0002] With the rapid development of intelligent connected vehicles, intelligent handling of vehicle accidents has become a key aspect of improving user safety experience.

[0003] Current vehicle accident emergency response solutions mostly involve initiating an emergency call to a pre-set external organization according to a fixed script or through manual configuration after an accident is detected. This results in a relatively simple and rigid overall response mechanism that cannot be accurately adapted to actual accident scenarios, leading to poor accident response effectiveness and seriously affecting the overall user experience.

[0004] Therefore, there is an urgent need for a more intelligent accident handling technology. Summary of the Invention

[0005] This application provides a method, apparatus, device, and vehicle for handling vehicle accidents, which enables more accurate and intelligent handling of vehicle accidents, thereby improving the user's safety experience and satisfaction after an accident.

[0006] In a first aspect, embodiments of this application provide a method for handling vehicle accidents, including:

[0007] After determining that a vehicle accident has occurred, a target accident level for the vehicle is determined based on accident-related status data in the vehicle; the target accident level is used to indicate the severity of the current accident involving the vehicle.

[0008] Based on vehicle status data within a preset time window before and after the accident, obtain evidence data of the vehicle; the vehicle status data includes the accident-related status data.

[0009] Based on a pre-established candidate step library, a sequence of target processing steps that matches the target accident level and the integrity of the evidence data is determined.

[0010] Execute the target processing step sequence.

[0011] In one possible implementation, executing the sequence of target processing steps includes:

[0012] The target processing step sequence is instantiated as a state machine, and the state machine is used to automate the execution of the target processing step sequence.

[0013] In one possible implementation, determining the target processing step sequence that matches the target incident level and the integrity of the evidence data based on a pre-established candidate step library includes:

[0014] Based on the target accident level and the evidence data, a set of step constraints is constructed; the set of step constraints includes mandatory handling steps corresponding to the target accident level and evidence supplementation steps corresponding to the evidence data.

[0015] Based on the candidate step library, at least one candidate processing step sequence that satisfies the set of step constraints is determined;

[0016] For each candidate processing step sequence, the total cost of the candidate processing step sequence is calculated based on the total execution time of the candidate processing step sequence and the degree of human intervention.

[0017] The candidate processing step sequence with the minimum total cost is determined as the target processing step sequence.

[0018] In one possible implementation, the set of step constraints further includes at least one of the following: communication method constraints corresponding to vehicle network conditions, interface availability constraints of different associated agencies, and user reachability constraints; the associated agencies include at least one of rescue agencies, traffic police agencies, and insurance agencies.

[0019] In one possible implementation, the accident-related status data includes at least one of the vehicle's speed, collision acceleration, airbag deployment status, and vehicle posture data.

[0020] In one possible implementation, the method further includes:

[0021] The evidence data is subjected to a reliable solidification process to obtain an evidence package;

[0022] The trusted solidification process includes encrypting the evidence data using a cryptographic hash algorithm.

[0023] In one possible implementation, determining the target accident level of the vehicle based on the vehicle's accident association status data includes:

[0024] Based on the accident-related status data, a preset level determination rule and / or a pre-trained inference model are used to obtain the initial accident level of the vehicle and the confidence level of the initial accident level; the level determination rule and the inference model are used to evaluate the accident level of the vehicle based on the accident-related status data.

[0025] The target accident level of the vehicle is determined based on the initial accident level, the confidence level, and the preset determination strategy; the preset determination strategy includes target level determination strategies corresponding to different confidence levels.

[0026] In one possible implementation, the target processing step sequence includes sending a request message to a target associated organization, which may be a rescue organization, a traffic police organization, or an insurance organization.

[0027] The automated execution of the target processing step sequence using the state machine includes:

[0028] The system uses a pre-configured external interface adapter to convert the organization's call request into a standardized request that conforms to the interface protocol of the target associated organization.

[0029] The standardization request is sent to the target associated organization, and upon receiving a confirmation message from the target associated organization, the state machine is driven to enter the next step in the target step processing sequence.

[0030] In one possible implementation, the method further includes:

[0031] If, after sending the standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization, the state machine is driven to transition the state of the current step to execution failure, and an alternative scheme is used to execute the current step.

[0032] The alternative solutions include any of the following: sending a request message to the target associated organization via SMS; sending a request message to the target associated organization via telephone; caching the request message in the local storage area and automatically synchronizing and sending the request message to the target associated organization after the network is restored.

[0033] In one possible implementation, the agency call request includes a target sub-evidence package corresponding to the target associated agency;

[0034] Before converting the organization call request into a standardized request conforming to the interface protocol of the target associated organization through a pre-configured external interface adapter, the method further includes:

[0035] According to the data requirements of the target associated institution, the evidence package is trimmed into the minimum dataset;

[0036] The minimum dataset is anonymized to obtain the target sub-evidence package corresponding to the target associated institution; the data requirements include the data content requirements and data field format requirements of the target associated institution.

[0037] Based on the target sub-evidence package, obtain the agency call request.

[0038] In one possible implementation, the method further includes:

[0039] During the operation of the state machine, the execution-related information of the target processing step sequence is displayed in the cockpit interface in real time according to the state vector corresponding to the current state node of the state machine; the execution-related information includes the current execution step, the execution status of the current execution step, and the corresponding user prompt information;

[0040] The state vector includes the step identifier and step execution status corresponding to the state node.

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

[0042] Based on the preset constraint rules and the state vector corresponding to the current state node of the state machine, the user prompt words to be displayed in the cockpit interaction interface are verified for compliance, and the user prompt words are displayed in the cockpit interaction interface only when the verification is successful.

[0043] The constraint rules are used to indicate the preconditions under which different user prompts are allowed to be displayed, and / or the disabling conditions under which different user prompts are prohibited from being displayed.

[0044] Secondly, embodiments of this application provide a vehicle accident handling device, comprising:

[0045] The rating determination module is used to determine the target accident rating of a vehicle based on accident-related status data in the vehicle after an accident is determined to have occurred; the target accident rating is used to indicate the severity of the current accident involving the vehicle.

[0046] The evidence acquisition module is used to acquire evidence data of the vehicle based on vehicle status data within a preset time window before and after the accident; the vehicle status data includes the accident-related status data.

[0047] The step determination module is used to determine the target processing step sequence that matches the target accident level and the integrity of the evidence data based on a pre-established candidate step library;

[0048] An execution module is used to execute the target processing step sequence.

[0049] In one possible implementation, the execution module is specifically used for:

[0050] The target processing step sequence is instantiated as a state machine, and the state machine is used to automate the execution of the target processing step sequence.

[0051] In one possible implementation, the step determining module is specifically used for:

[0052] Based on the target accident level and the evidence data, a set of step constraints is constructed; the set of step constraints includes mandatory handling steps corresponding to the target accident level and evidence supplementation steps corresponding to the evidence data.

[0053] Based on the candidate step library, at least one candidate processing step sequence that satisfies the set of step constraints is determined;

[0054] For each candidate processing step sequence, the total cost of the candidate processing step sequence is calculated based on the total execution time of the candidate processing step sequence and the degree of human intervention.

[0055] The candidate processing step sequence with the minimum total cost is determined as the target processing step sequence.

[0056] In one possible implementation, the set of step constraints in the step determination module further includes at least one of the following: communication method constraints corresponding to vehicle network conditions, interface availability constraints of different associated agencies, and user reachability constraints; the associated agencies include at least one of rescue agencies, traffic police agencies, and insurance agencies.

[0057] In one possible implementation, the accident-related status data in the level determination module includes at least one of the vehicle speed, collision acceleration, airbag triggering status, and vehicle posture data.

[0058] In one possible implementation, the device further includes:

[0059] The processing module is used to perform credible solidification processing on the evidence data to obtain an evidence package;

[0060] The trusted solidification process includes encrypting the evidence data using a cryptographic hash algorithm.

[0061] In one possible implementation, the level determination module is specifically used for:

[0062] Based on the accident-related status data, a preset level determination rule and / or a pre-trained inference model are used to obtain the initial accident level of the vehicle and the confidence level of the initial accident level; the level determination rule and the inference model are used to evaluate the accident level of the vehicle based on the accident-related status data.

[0063] The target accident level of the vehicle is determined based on the initial accident level, the confidence level, and the preset determination strategy; the preset determination strategy includes target level determination strategies corresponding to different confidence levels.

[0064] In one possible implementation, the target processing step sequence includes sending a request message to a target associated organization, which may be a rescue organization, a traffic police organization, or an insurance organization.

[0065] The execution module is specifically used for:

[0066] The system uses a pre-configured external interface adapter to convert the organization's call request into a standardized request that conforms to the interface protocol of the target associated organization.

[0067] The standardization request is sent to the target associated organization, and upon receiving a confirmation message from the target associated organization, the state machine is driven to enter the next step in the target step processing sequence.

[0068] In one possible implementation, the execution module is further specifically used for:

[0069] If, after sending the standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization, the state machine is driven to transition the state of the current step to execution failure, and an alternative scheme is used to execute the current step.

[0070] The alternative solutions include any of the following: sending a request message to the target associated organization via SMS; sending a request message to the target associated organization via telephone; caching the request message in the local storage area and automatically synchronizing and sending the request message to the target associated organization after the network is restored.

[0071] In one possible implementation, the agency call request includes a target sub-evidence package corresponding to the target associated agency;

[0072] The execution module is also specifically used for:

[0073] According to the data requirements of the target associated institution, the evidence package is trimmed into the minimum dataset;

[0074] The minimum dataset is anonymized to obtain the target sub-evidence package corresponding to the target associated institution; the data requirements include the data content requirements and data field format requirements of the target associated institution.

[0075] Based on the target sub-evidence package, obtain the agency call request.

[0076] In one possible implementation, the device further includes:

[0077] The display module is used to display the execution-related information of the target processing step sequence in the cockpit interaction interface in real time according to the state vector corresponding to the current state node of the state machine during the operation of the state machine; the execution-related information includes the current execution step, the execution status of the current execution step, and the corresponding user prompt information;

[0078] The state vector includes the step identifier and step execution status corresponding to the state node.

[0079] In one possible implementation, the method further includes:

[0080] The verification module is used to perform compliance verification on the user prompt words to be displayed in the cockpit interaction interface according to the preset constraint rules and the state vector corresponding to the current state node of the state machine, and only display the user prompt words in the cockpit interaction interface when the verification is successful.

[0081] The constraint rules are used to indicate the preconditions under which different user prompts are allowed to be displayed, and / or the disabling conditions under which different user prompts are prohibited from being displayed.

[0082] Thirdly, embodiments of this application provide a processing device, including: a memory and a processor;

[0083] The memory stores computer-executed instructions;

[0084] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0085] Fourthly, embodiments of this application provide a vehicle, including a vehicle body and the processor described in the third aspect.

[0086] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0087] In a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0088] The vehicle accident handling method, apparatus, equipment, and vehicle provided in this application embodiment determine the target accident level based on vehicle accident-related status data, collect vehicle status data before and after the accident to form evidence data, and determine and execute the target handling step sequence according to the accident level and the completeness of evidence. This allows the accident handling process to dynamically adapt to the actual severity of the accident and the completeness of the evidence, breaking away from the limitations of the single and fixed handling methods of traditional methods. At the same time, this solution significantly reduces manual judgment and operation by users through automatic step arrangement, reducing the operational burden and psychological pressure after an accident occurs. Thus, this solution can improve the accuracy and intelligence of accident handling, thereby optimizing the user's experience in emergency response to vehicle accidents. Attached Figure Description

[0089] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0090] Figure 1 This is a flowchart illustrating a method for handling vehicle accidents provided in Embodiment 1 of this application.

[0091] Figure 2 This is a schematic diagram of the structure of a vehicle accident handling device provided in Embodiment 4 of this application;

[0092] Figure 3 This is a schematic diagram of the structure of a vehicle accident handling device provided in Embodiment 5 of this application;

[0093] Figure 4 A schematic diagram of the processing device provided in this application.

[0094] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0095] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0096] To facilitate understanding of the technical content of this solution, the background technology is described in detail below:

[0097] With the rapid development of intelligent connected vehicles, intelligent post-accident handling has become a key aspect of enhancing user safety experience. Currently, in-vehicle accident handling technology mainly revolves around emergency call triggering (such as emergency call (eCall) or breakdown call (bCall)) and the reliability of accident information collection and transmission. The core objective is to expedite the issuance of alarm signals and the reporting of basic information after an accident.

[0098] However, most existing methods only initiate emergency calls to preset external agencies according to fixed scripts or through manual configuration after an accident is detected. This results in a relatively simple and rigid overall handling mechanism that cannot be accurately adapted to actual accident scenarios, leading to poor handling of accidents and seriously affecting the overall user experience.

[0099] To address the problems in the background technology, the inventors discovered during their research that, after an accident occurs, the system can autonomously rely on accident-related status data in the vehicle (such as airbag deployment status) to determine the severity of the accident (i.e., the accident level), and simultaneously retain vehicle status data before and after the accident as evidence data. Then, based on the severity of the current accident and the completeness of the retained evidence data, the system automatically arranges and executes a sequence of processing steps. This achieves dynamic adaptation between the accident handling process and the actual severity of the accident and the completeness of the evidence, resulting in more accurate and intelligent vehicle accident handling, thereby improving the user's safety experience and satisfaction after an accident.

[0100] It should be noted that this application applies to accident handling scenarios for intelligent connected vehicles, specifically including automated responses after traffic accidents such as vehicle collisions and rollovers. This solution can be implemented in the vehicle's processing equipment, such as the vehicle's onboard central processing unit or onboard edge computing device. This application does not impose any restrictions on the specific selection of processing equipment.

[0101] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0102] Figure 1 This is a flowchart illustrating a method for handling vehicle accidents provided in Embodiment 1 of this application, as shown below. Figure 1 As shown, the vehicle accident handling method provided in this embodiment includes:

[0103] S101. After determining that a vehicle accident has occurred, determine the target accident level of the vehicle based on the accident-related status data in the vehicle.

[0104] The target accident level is used to indicate the severity of the accident that has occurred. In practical applications, accident levels can be divided into four categories: minor accident (L1), general accident (L2), serious accident (L3), and critical accident (L4).

[0105] In this step, after a traffic accident is detected, the vehicle will determine the target accident level based on the accident-related status data collected in the vehicle and the severity of the accident.

[0106] Accident-related status data refers to various data that reflect the characteristics of an accident and are displayed by the vehicle before and after the accident. In practical applications, accident-related data can be collected using sensors installed in the vehicle.

[0107] In one possible implementation, the accident-related state data includes at least one of the following: vehicle speed, collision acceleration, airbag deployment status, and vehicle attitude data.

[0108] Among these metrics, vehicle speed represents the speed at which a vehicle is traveling at the moment of an accident. Generally, the higher the speed, the greater the impact force generated during a collision, and the more severe the damage may be. It can be used as an indicator for assessing the accident level. Collision acceleration refers to the magnitude of the acceleration of a vehicle at the moment of collision. It represents how quickly the vehicle's speed changes during the collision. The greater the collision acceleration, the stronger the impact force on the vehicle, and the higher the severity of the accident. Airbag deployment status refers to whether each airbag installed in the vehicle is deployed during an accident and the specific details of deployment. It can directly reflect the severity of the collision. If the airbags are deployed, it indicates that the collision is relatively severe. Vehicle posture data refers to information such as the vehicle's tilt angle and rollover state after an accident. Abnormal vehicle posture often indicates a more severe accident.

[0109] As a specific example, the vehicle's speed sensor, acceleration sensor, airbag controller, body posture sensor, and positioning module can be used to simultaneously collect multi-source data from the vehicle, and the accident level of the current accident can be determined by jointly using the multi-source data.

[0110] The method provided in this implementation uses vehicle speed, collision acceleration, airbag deployment status, and vehicle posture data as accident-related state data to determine the accident level. This method accurately identifies key data related to the accident within the vehicle, providing a more reliable data foundation for accurately determining the target accident level. It is understood that the method of relying on multi-source accident-related state data for target level determination in some scenarios of this application can effectively avoid judgment errors caused by inaccurate sensor data from single-source data, thereby further improving the accuracy of target level determination.

[0111] In one possible implementation, the determination of whether an accident has occurred can be based on real-time collected accident-related data. For example, the vehicle can collect data such as vehicle speed, collision acceleration, airbag deployment status, and vehicle posture in real time. If any data source shows an abnormality (such as a sudden change in vehicle speed, airbag deployment, abnormal vehicle posture, or collision acceleration exceeding a preset acceleration threshold), an accident is determined. Accordingly, after determining that an accident has occurred, the target accident level determination action, as in step S101, will be initiated.

[0112] This implementation method uses real-time collection of vehicle accident-related data and multi-dimensional indicator anomalies to make accident judgments, enabling accident detection to respond to real collision scenarios in a timely and accurate manner, avoiding misjudgments or omissions, thereby improving the real-time performance and reliability of accident identification, and providing accurate triggering opportunities for subsequent level determination and emergency response.

[0113] In one possible implementation, the method provided in steps 1.1 to 1.2 can be used to determine the target accident level based on accident-related status data in the vehicle:

[0114] Step 1.1: Based on the accident-related status data, use the preset level determination rules and / or pre-trained inference models to obtain the initial accident level of the vehicle and the confidence level of the initial accident level.

[0115] Among them, the rating determination rules and reasoning models are used to evaluate the accident rating of vehicles based on accident-related status data.

[0116] In this step, the accident level matching the accident association status data will be evaluated separately using either a level determination rule or an inference model, and this will be used as the initial accident level; alternatively, the accident level matching the accident association status data will be evaluated jointly using both the level determination rule and the inference model, and this will be used as the initial accident level. At the same time, the confidence level of the corresponding initial accident level needs to be determined based on the accident association status, and this confidence level is used to indicate the credibility of the evaluated initial accident level.

[0117] As a concrete example, the initial accident level and confidence level can be determined solely by the grading rules. Specifically, in this example, the grading rules include judgment conditions built based on collision acceleration, airbag deployment status, vehicle speed, and vehicle posture data, established for different accident levels. Each judgment condition carries a preset confidence level. For example, the grading rules include: if the collision acceleration is ≥15g and the airbags deploy, the accident level is determined to be a critical accident with a confidence level of 1; if the vehicle posture data indicates slight vibration and no other abnormalities, the accident level is determined to be a minor accident with a confidence level of 0.7. Accordingly, in practical applications, after an accident occurs, the current accident-related status data can be matched against each of the above rules, and the matched level can be used as the initial accident level, with the preset score in the corresponding rule serving as the confidence level.

[0118] As another concrete example, the initial accident level and confidence level can be determined solely by an inference model. Specifically, in this example, the inference model can be a classification model pre-trained using a large amount of historical accident data. The input to this model is accident-related state data, including multi-dimensional features such as collision acceleration, airbag status, vehicle speed, and vehicle posture data. The output is the probability distribution of each accident level. The classification model can be a neural network model, support vector machine model, decision tree model, random forest model, or gradient boosting tree model, etc. This application does not limit the specific type of classification model. Accordingly, in practical applications, after an accident occurs, the vehicle's current accident-related state data can be input into the model to obtain probability values ​​corresponding to different accident levels. The level with the highest probability can be used as the initial accident level, and this highest probability value can be used as the confidence level of the initial accident level.

[0119] As another concrete example, the initial accident level and confidence level can be determined collaboratively using grading rules and inference models. Specifically, in this example, the grading rules include threshold grading rules designed for accident-related data from different sources. Taking collision acceleration as an example, the grading rules include accident levels corresponding to different collision accelerations. For instance, when the collision acceleration is less than or equal to 3g, the accident level is determined to be a minor accident; when the collision acceleration threshold is greater than 3g and less than or equal to 5g, the accident level is determined to be a general accident; when the collision acceleration threshold is greater than 5g and less than 8g, the accident level is determined to be a serious accident; and when the collision acceleration is greater than 8g, the accident level is determined to be a critical accident. In addition, the rules can also indicate the accident level corresponding to different airbag deployment states. For example, when all airbags in the vehicle are deployed, the accident level corresponding to the airbag deployment state is determined to be a serious accident; the rules can also include the accident level corresponding to different vehicle rollover angles. For example, when the vehicle rollover angle exceeds 45°, the accident level corresponding to the vehicle posture data is determined to be critical. In this example, the inference model is used to output the fused accident level and confidence score based on the accident levels corresponding to the accident association data from different input sources. The inference model can be implemented using methods such as weighted voting, Bayesian fusion, or lightweight neural networks for fusion computation.

[0120] Accordingly, in practical applications, after an accident occurs, the accident level corresponding to data from different sources can be determined according to the level judgment rules. The accident levels corresponding to each source are then used as input to the inference model, allowing the model to fuse and output an accident level and its corresponding confidence score. The model fusion output process, for example, involves pre-configuring a weight for each data source, statistically analyzing each level through weighted voting, determining the level with the highest score as the initial accident level, and using the total score corresponding to this level as the confidence score. This confidence score reflects the consistency between the accident levels corresponding to data from different sources.

[0121] Step 1.2: Determine the target accident level of the vehicle based on the initial accident level, confidence level, and preset determination strategy.

[0122] Among them, the preset determination strategy includes the target level determination strategy corresponding to different confidence levels.

[0123] In this step, to ensure that the determined target incident level has high credibility, the target level determination strategy will be determined based on the confidence level corresponding to the initial incident level.

[0124] For example, the preset determination strategy includes: if the confidence level is greater than or equal to a first preset threshold, the initial accident level is directly determined as the target accident level; if the confidence level is greater than or equal to a second preset threshold and less than the first preset threshold, a confirmation request is pushed to the user through the cockpit interface, and after receiving the user's confirmation response, the initial accident level is determined as the target accident level; if the confidence level is less than the second preset threshold, a manual intervention path is forcibly entered, and the accident level actively entered by the user is determined as the target accident level. The first and second preset thresholds can be determined based on historical false alarm and false negative rates for determining the initial accident level. This application does not restrict their specific values. For example, it is required that the false alarm rate corresponding to the first preset threshold should be less than α (e.g., 5%), and the false negative rate corresponding to the second preset threshold should be less than β (e.g., 2%).

[0125] The method provided in this implementation obtains the initial accident level and confidence level by combining rules and models, and adopts differentiated target level determination strategies according to different confidence levels. This makes the accident level determination both highly accurate and adaptable to different reliability scenarios. Under high confidence, the process can be automatically advanced to improve emergency response efficiency, while under low confidence, manual intervention can be used to constrain and avoid misjudgment and misoperation. This balances the automation efficiency and operational safety of accident handling, achieving a balance between automation and judgment accuracy.

[0126] S102. Obtain vehicle evidence data based on vehicle status data within a preset time window before and after the accident.

[0127] In this step, the vehicle status data within a preset time window before and after the accident needs to be cached and stored as evidence data for subsequent accident liability determination and insurance claims.

[0128] Vehicle status data includes accident-related status data. Optionally, vehicle status data may also include vehicle status snapshots and trajectory data. Specifically, vehicle status data refers to the set of instantaneous vehicle operating states collected at key time points within the time window, including but not limited to gear position, braking status, steering angle, throttle opening, seat belt status, and vehicle stability system status; trajectory data refers to data that indicates the vehicle's spatial location at key time points within the time window, such as Global Positioning System (GPS) positioning data.

[0129] In one possible implementation, the method provided in this embodiment further includes: performing trusted solidification processing on the evidence data to obtain an evidence package. The trusted solidification processing includes encrypting the evidence data using a cryptographic hash algorithm.

[0130] It should be noted that, in order to ensure that accident evidence is not tampered with, forged, or illegally destroyed during the collection, storage, and transmission processes, the evidence data needs to undergo a trusted solidification process. This trusted solidification process refers to using cryptographic algorithms to protect the integrity and authenticity of the evidence data, thus creating a trustworthy data structure that is immutable, verifiable, and traceable.

[0131] Specifically, the trusted solidification process includes using a cryptographic hash algorithm to perform hash calculations on the evidence data, generating a unique hash value, and storing the hash value in association with the original evidence data to achieve tamper-proof protection of the evidence data.

[0132] The method provided in this implementation employs a cryptographic hash algorithm to encrypt and solidify the evidence data, thereby enabling the evidence data to possess the characteristics of being tamper-proof, verifiable, and traceable during its generation, storage, and transmission. This effectively guarantees the authenticity and legality of the evidence data, enhances the credibility and legal validity of accident evidence, and ensures the smooth progress of subsequent accident handling procedures.

[0133] S103. Based on the pre-established candidate step library, determine the target processing step sequence that matches the target accident level and the integrity of the evidence data.

[0134] The candidate step library refers to a pre-configured set of steps containing various accident handling-related operations, such as: evidence collection, sending request messages to rescue agencies, sending action prompts to users, sending request messages to traffic police agencies, and sending request messages to insurance agencies. In addition, the candidate step library also contains multiple implementation methods preset for each step to determine the sub-steps corresponding to the steps, such as multiple request message sending channels such as SMS, telephone, and communication interfaces.

[0135] In this step, based on the target accident level determined in step S101, the standard handling procedures required for that level will be matched; at the same time, the steps to be executed will be adaptively adjusted in combination with the completeness of the evidence data, and finally, a target handling step sequence that is suitable for the current accident level and the completeness of the evidence will be selected and combined.

[0136] For example, the target handling steps sequence for a critical accident needs to include sending a request message to a rescue organization, while the target handling steps sequence for a minor accident does not need to include sending a request message to a rescue organization. For another example, if the current accident is a minor accident, the determined target handling steps sequence includes sending a request message to an insurance company, and the request message needs to carry on-site photos, but the currently retained evidence data does not include on-site photos, then a step of "supplementing on-site photos" needs to be added to the target handling steps.

[0137] In one possible implementation, step S103 can be implemented using steps 3.1 to 3.4, including:

[0138] Step 3.1: Based on the target accident level and evidence data, construct a set of step constraints.

[0139] The set of step constraints includes mandatory handling steps corresponding to the target accident level and evidence supplementation steps corresponding to the evidence data.

[0140] In detail, the set of step constraints refers to the set of constraints used to screen and limit candidate handling steps, which are used to clarify the mandatory, optional, and prohibited handling steps in the subsequent handling process; the mandatory handling step constraints corresponding to the target accident level refer to the mandatory execution requirements set for the handling process based on the accident severity represented by the target accident level, which are used to clarify the handling actions that match the current accident level and must be implemented; the evidence supplementation step constraints corresponding to the evidence data refer to the evidence-related execution requirements set for the handling process based on the completeness, validity, and submission requirements of the evidence data and external institutions, which are used to clarify whether it is necessary to collect relevant evidence data in the subsequent handling steps.

[0141] Optionally, the set of step constraints may also include at least one of the following: communication method constraints corresponding to vehicle network conditions, interface availability constraints of different associated agencies, and user reachability constraints; associated agencies include at least one of rescue agencies, traffic police agencies, and insurance agencies.

[0142] Specifically, the communication mode constraints corresponding to vehicle network conditions refer to the communication mode execution requirements set for subsequent processing procedures based on the vehicle's current network signal quality, network type, and communication link status. These constraints limit the message sending, data transmission, and call establishment methods that can be used in the current network environment.

[0143] Interface availability constraints for different related organizations refer to the organizational interaction execution requirements set for subsequent handling processes based on the connectivity and service capabilities of the corresponding data receiving interfaces of organizations such as rescue organizations, traffic police organizations, and insurance organizations. These constraints are used to limit the external organizations that can directly send requests through data communication interfaces.

[0144] User accessibility constraints are human-computer interaction execution requirements set for the handling process based on user accessibility (i.e., whether the user has responsiveness). These constraints limit whether subsequent handling processes should include steps requiring user access. In practice, user accessibility can be determined as follows: After an incident occurs, an accessibility confirmation prompt can be sent to the user (e.g., via a prompt message sent through the cockpit interface). Upon receiving confirmation from the user, it is determined that the user has responsiveness and meets the accessibility requirement. For example, if the user does not have responsiveness, the user accessibility constraint will indicate that no steps requiring user access should be added to the subsequent handling process.

[0145] The method provided in this implementation, because the set of constraints for the constructed steps also includes vehicle network conditions, availability of associated agency interfaces, and user reachability, enables the final determined sequence of target processing steps to be deeply adapted to the real-time communication status of the vehicle, the service status of external agencies, and the user interaction status. This further enhances the adaptability and robustness of the solution to complex accident scenarios, ensuring that the handling process can be executed stably, reasonably, and efficiently under different network environments, different agency interface states, and different user reachability conditions.

[0146] Step 3.2: Based on the candidate step library, determine at least one candidate processing step sequence that satisfies the step constraint set.

[0147] In this step, one or more candidate processing step sequences that can satisfy the constraints in the step constraint set will be compiled from the candidate step library.

[0148] In practical applications, an orchestration engine can be used to orchestrate at least one sequence of candidate processing steps that satisfies the set of step constraints based on the candidate step library.

[0149] Step 3.3: For each candidate processing step sequence, calculate the total cost of the candidate processing step sequence based on the total execution time of the candidate processing step sequence and the degree of human intervention.

[0150] Step 3.4: Determine the candidate processing step sequence with the minimum total cost as the target processing step sequence.

[0151] In the specific implementation of this scheme, if there is only one candidate processing step sequence, then the candidate processing step sequence can be directly determined as the target processing step sequence; if there is more than one candidate processing step sequence, then the total cost of each candidate processing step sequence needs to be calculated, and the candidate processing step sequence with the smallest total cost is determined as the target processing step sequence.

[0152] In detail, for each candidate processing step sequence, the total time required to execute the candidate processing step sequence can be calculated, and the user's participation in the execution of the candidate processing step sequence can be quantified (for example, the number of steps in the candidate processing step sequence that require human intervention is counted) to obtain the degree of human intervention; the total execution time and the degree of human intervention are weighted and summed according to a preset weight ratio to obtain the total cost corresponding to the candidate processing step sequence.

[0153] The method provided in this implementation constructs a set of step constraints by combining the target accident level and evidence data. This allows for precise limitation of the selection range of handling steps, ensuring that the candidate handling step sequence conforms to the accident level requirements and the completeness of evidence, thereby improving the rationality and standardization of the handling process. Furthermore, by selecting candidate handling step sequences that meet the constraints from the candidate step library and calculating the total cost by combining the total execution time and the degree of human involvement, a quantitative evaluation and optimal selection of the handling process can be achieved. Under the premise of ensuring compliance and accuracy of handling, it effectively balances execution efficiency and human costs, making the final determined target handling step sequence more intelligent, more efficient, and more adaptable to actual accident handling scenarios.

[0154] S104, Execute the target processing step sequence.

[0155] In this step, the aforementioned target processing steps will be executed sequentially in order to achieve efficient, reliable, and realistic handling of vehicle accidents.

[0156] The vehicle accident handling method provided in this application determines the target accident level based on vehicle accident-related status data, collects vehicle status data before and after the accident to form evidence data, and determines and executes the target handling step sequence based on the accident level and the completeness of evidence. This allows the accident handling process to dynamically adapt to the actual severity of the accident and the completeness of the evidence, overcoming the limitations of traditional, rigid handling methods. Furthermore, this solution significantly reduces manual judgment and operation by the user through automatic step arrangement, lowering the operational burden and psychological stress after an accident. Therefore, this solution improves the accuracy and intelligence of accident handling, thereby optimizing the user's experience in emergency response to vehicle accidents.

[0157] This application provides a method for handling vehicle accidents in Embodiment 2. Based on the above embodiments, Embodiment 2 aims to describe in detail the specific implementation of the aforementioned step S104, including:

[0158] The target processing step sequence is instantiated as a state machine, and the state machine is used to automate the execution of the target processing step sequence.

[0159] In detail, each step in the selected target processing step sequence is first broken down into several discrete states with clear execution logic and sequential relationships, resulting in multiple state nodes corresponding to the steps; at the same time, the switching conditions, triggering rules and exception handling logic between each state node are defined, and a state machine adapted to the current accident scenario is instantiated accordingly.

[0160] The state machine pre-stores the execution logic, input and output parameters, and state transition rules of each state node in each step of the target processing sequence. During execution, the state machine will start from the initial state node of the first step and automatically transition to the next corresponding state node after the current state is completed and the preset switching conditions are met, and so on, until all steps are completed and all states are finished.

[0161] In practical applications, the state nodes for each step in a state machine can include states such as: initialization (INIT), request sent (REQUEST_SENT), receipt of acknowledgment (ACK_RECEIVED), timeout (TIMEOUT), and retry (RETRYING).

[0162] Optionally, to ensure that the sequence of target processing steps can be completed coherently, stably, and automatically, the state nodes for each step in the state machine may also include, for example, degradation, manual intervention, and conflict resolution.

[0163] Specifically, during the execution of the target processing steps sequence, when the state machine detects that the current state node meets the preset exception rules in the state transition rules, it will automatically trigger the state transition to degraded execution, manual intervention, or conflict resolution, thereby further reducing manual intervention while improving the execution efficiency and reliability of the handling process.

[0164] The preset exception rules include, for example, that when a conflict is detected between the user's input and the system's judgment result, the step status node will be transferred to conflict resolution; the logic for executing the conflict resolution state is, for example, to trigger a second confirmation operation by the user or for the system to regenerate the judgment result. Another example is that when the current step's status node indicates that the task retries have reached the preset maximum number of retries but has continued to fail, the step status node will be transferred to degradation or manual intervention; the logic for the degradation state is to execute the step according to a pre-set alternative plan.

[0165] In the specific implementation of the solution, the target processing steps typically include sending a request message to the target-related organization, which may be a rescue organization, traffic police organization, or insurance organization.

[0166] Accordingly, in one possible implementation, during the automated execution of the target processing step sequence using a state machine, when the step of "sending a request message to the target-related organization" is executed, it may specifically include the methods provided in steps 4.1 to 4.2 as follows:

[0167] Step 4.1: Convert the organization call request into a standardized request that conforms to the interface protocol of the target associated organization through a pre-configured external interface adapter.

[0168] It should be understood that, considering that traditional accident handling techniques typically use a point-to-point, hard-coded approach to initiate calls or reports to pre-defined external agencies, this approach suffers from poor adaptability, weak scalability, high maintenance costs, and difficulty in compatibility with multiple agency interfaces. Therefore, this solution is designed to send request messages to any associated agency through an external interface adapter. This external interface adapter is a pre-configured adaptation module used to uniformly encapsulate and convert the interface protocols of different external agencies. It transforms the agency call requests within the vehicle-side system into standardized requests conforming to the target associated agency's interface specifications, thereby achieving decoupling and adaptation with different agency interfaces.

[0169] In this step, the organization call request to be sent to the target associated organization will be converted into a standardized request that conforms to the target associated organization's interface specification through a pre-configured external interface adapter.

[0170] Among them, the agency call request is used to initiate accident handling-related requests to the corresponding target associated agency, such as requesting rescue or reporting an insurance claim.

[0171] Optionally, the agency's request may also include a target sub-evidence package corresponding to the target associated agency. This target sub-evidence package is used to provide the target associated agency with structured evidence data related to the accident handling process, enabling the agency to handle acceptance, verification, dispatch, damage assessment, or filing.

[0172] Accordingly, before performing the step "send a request message to the target associated organization", the following steps a to c are also included:

[0173] Step a: According to the data requirements of the target related institutions, trim the evidence package into the smallest dataset.

[0174] The data requirements include the data content requirements of the target related institutions and the data field format requirements.

[0175] In this step, based on the data content requirements and data field format requirements of different target related agencies such as rescue, traffic police, and insurance for the actual reporting of accident evidence, the necessary evidence data of the agency is extracted and retained from the complete evidence package, and irrelevant, redundant or excessive data content is removed to form the minimum usable evidence set (i.e., the minimum dataset) that meets the current agency's acceptance, verification and handling requirements.

[0176] Step b: De-identify the smallest dataset to obtain the target sub-evidence package corresponding to the target associated institution.

[0177] In this step, based on the minimum dataset obtained according to the institution's needs, content involving user privacy, vehicle sensitive information, etc., will be hidden, encrypted, or replaced. This will prevent the leakage of sensitive information without affecting the institution's normal acceptance, verification, and damage assessment, and ultimately form a target sub-evidence package that is both compliant and meets the institution's needs.

[0178] Step c: Obtain the agency call request based on the target sub-evidence package.

[0179] In this step, after the evidence package is trimmed and desensitized to obtain a target sub-evidence package that is only applicable to the current target associated institution, the target sub-evidence package is used as the data content of the request to be sent to obtain the institution call request.

[0180] It should be understood that the method provided in steps a to c above, by trimming the evidence package into the smallest dataset according to the data requirements of the target related institution, and generating the corresponding target sub-evidence package after anonymizing it, and then encapsulating the target sub-evidence package into the institution's call request, can not only accurately meet the actual business needs of different institutions for data content and format, improve the effectiveness of evidence transmission and the efficiency of institution acceptance, but also reduce redundant data transmission and communication overhead. At the same time, the anonymization process effectively protects user privacy and vehicle sensitive information, improves the security and compliance of data interaction, and achieves a unity of practicality, security and standardization of accident evidence in the process of cross-institutional reporting.

[0181] Step 4.2: Send a standardized request to the target associated organization, and upon receiving a reply message from the target associated organization, drive the state machine to enter the next step in the target step processing sequence.

[0182] In this step, a standardization request for format conversion needs to be sent to the target associated structure so that the target associated structure can return a receipt message to the vehicle after receiving the standardization request. Accordingly, when the vehicle receives the receipt message, it indicates that the step "send request message to target associated structure" has been completed, and the state machine will be driven to enter the next step in the target step processing sequence.

[0183] It should be understood that the methods provided in steps 4.1 and 4.2 above convert the agency call request into a standardized request that adapts to the target associated agency interface protocol through a pre-configured external interface adapter. This breaks down the barriers of heterogeneity of different agency interface protocols, enabling unified adaptation and flexible connection for multiple types of agencies such as rescue, traffic police, and insurance. This can reduce the development and maintenance costs of cross-agency connection. At the same time, the receipt-driven state transition mechanism enables the request status to be tracked throughout the process, ensuring that the handling process is executed in an orderly and controllable manner.

[0184] Optionally, to further ensure the smooth execution of the target processing steps, the method provided in the implementation also includes the following step 4.3:

[0185] Step 4.3: If, after sending a standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization, the driving state machine will transition the state of the current step to execution failure and execute the current step using an alternative solution.

[0186] The retry count refers to the cumulative number of times the system automatically resends the request because no response was received on the first request. For example, the preset counts may be 3 or 4, and this application does not impose specific restrictions on the selection of this value.

[0187] In this step, if after sending a standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization before the countdown ends, the request sending operation is deemed to have failed, and the execution of the alternative solution is triggered.

[0188] In practical applications, the waiting time for each retry can be dynamically adjusted according to network conditions. For example, if the network environment is poor, the waiting time for that attempt can be appropriately increased to dynamically adapt the retry situation to the environment. The waiting time for each attempt can be selected within a range of 5 to 15 seconds.

[0189] For the step "send a request message to the target related organization", the alternative solutions include any of the following:

[0190] (1) Send a request message to the target related organization by sending a text message.

[0191] For example, when the state machine triggers the SMS backup plan, it can call the SMS sending interface of the vehicle communication module to automatically encapsulate the simplified core accident information (such as the accident time, vehicle location, vehicle model, contact person's mobile phone number, etc.) into a fixed format SMS content and send it to the dedicated SMS receiving number pre-registered by the rescue organization.

[0192] In practical applications, since it is impossible to obtain a clear institutional response, after sending the SMS, the state machine will be directly driven to the next step in the target step processing sequence.

[0193] (2) Send a request message to the target related organization by making a phone call.

[0194] For example, when the state machine triggers the telephone alternative, the vehicle-mounted voice communication module can be used to automatically dial the number of the pre-stored target associated organization, and after the connection is established, it can automatically broadcast key accident information (such as the time of the accident, vehicle location, vehicle type, accident level, etc.) through pre-recorded voice broadcast.

[0195] (3) Cache the request message in the local storage area and automatically synchronize and send the request message to the target associated institution after the network is restored.

[0196] For example, when the vehicle is detected to be in an area with no network or weak network, the state machine will trigger the local caching alternative scheme. At this time, the data to be sent in the current execution step can be stored in a local storage area such as a designated cache directory of the vehicle's local flash memory or hard disk, and marked as "to be sent". At the same time, the network status is detected in real time by the vehicle network monitoring module, and after the network is detected to be restored, the request message in the cache directory is automatically read and the request message is resent to the target associated organization.

[0197] It should be understood that the method provided in step 4.3, by driving the state machine to transfer the current step to execution failure and enabling alternative solutions when a preset maximum number of retries are triggered by sending a standardized request to the target associated institution and no response is received, can ensure that there are still available alternative processing paths in abnormal situations such as interface failure and network interruption, effectively avoiding the problem of interruption of the handling process caused by the failure of a single communication method; combined with diverse alternative solutions such as sending SMS, making telephone calls, and sending synchronously after local caching and network recovery, the request delivery method can be flexibly switched according to the actual scenario, which greatly improves the success rate of delivering request messages to the target associated institution and further ensures the smooth execution of the target incident handling sequence.

[0198] Based on the descriptions in steps 4.1 to 4.3 above, as a specific example, for the step of "sending a request message to the target associated organization," when executed using a state machine, the progression of its state nodes includes, for example, the following:

[0199] During the request format conversion and sending phase, the corresponding state node for this step is "Request Sending". After the request is sent, it automatically transitions to "Waiting for Receipt". While waiting for the target associated institution to return a receipt message, the state node remains in "Waiting for Receipt". Upon receiving the receipt message, the state machine will automatically enter the initial state node corresponding to the subsequent step of the current step. In addition, if the current state node is "Waiting for Receipt" and no receipt message is received from the target associated institution within a preset time, the state node switches to "Timeout" and automatically transitions to "Retry". If the number of retries reaches a preset threshold and still times out, the state node will be actively switched to "Degradation Processing" or "Manual Intervention" (i.e., executing the current step using an alternative solution).

[0200] In another possible implementation, during the automated execution of the target processing step sequence using a state machine, the method provided in this embodiment includes:

[0201] During the operation of the state machine, the execution information of the target processing step sequence is displayed in the cockpit interface in real time based on the state vector corresponding to the current state node of the state machine.

[0202] It should be understood that, in order to improve the transparency of the execution process of the target processing steps and thereby increase user trust, this solution will display information related to the execution of the steps on the cockpit interface in real time, so that users can intuitively and in real time grasp the current progress, status, and corresponding actions that need to be taken in the current handling process.

[0203] Among them, execution-related information refers to natural language information that is directly related to the execution process of the target processing step sequence and is visualized for cockpit users, including the current execution step, the execution status of the current execution step, and the corresponding user prompt information; the state vector refers to a structured data set that represents the core attributes of the current state node of the state machine, including the step identifier (step_id) and the execution status (status) of the current execution step.

[0204] In detail, the step identifier refers to the unique technical number assigned to each processing step in the state machine, which is used to accurately locate the currently executing step; such as step_01 and step_08, etc.; the step execution status is a standardized identifier that indicates the running status of the step, such as INIT, EQUEST_SENT, ACK_RECEIVED, TIMEOUT, RETRYING.

[0205] In addition, the currently executing step refers to the name of the step that the state machine is currently executing automatically. It can be determined based on the step identifier in the corresponding state vector. For example, if the step identifier in the state vector is step_01, then the currently executing step shown is the step name corresponding to step_01 (such as sending a rescue request to the rescue organization).

[0206] The execution status of the current execution step refers to an easily understandable state description obtained by mapping the execution status of the step in the state vector. For example, the execution status of the step may be not started, in progress, completed, failed, downgraded, or requires manual intervention.

[0207] User prompts refer to guiding action prompts or informing statements pushed to users based on the current step and execution status. For example, the displayed prompts might include action prompts displayed during the "supplement on-site photo data" step, such as "Please take photos of the scene and upload them"; or, in practical applications, the receipt message may encapsulate relevant information from the organization's response. Accordingly, the displayed prompts might include: displaying relevant information from the organization's response after receiving the receipt message, such as: "The estimated arrival time of the rescue organization at the accident site," "The traffic police's liability determination," and "The insurance company's compensation amount," etc.

[0208] Optionally, to further improve users' understanding of the incident's progress, the relevant information may also include: the number of retries that have been triggered, the next steps to be performed, and the remaining time to perform the current step.

[0209] Optionally, when the network is unavailable, locally executable steps can be displayed only through the cockpit interface, with synchronization delayed after the network is restored.

[0210] The method provided in this implementation, by displaying the execution information of the target processing step sequence in real time on the cockpit interface based on the state vector corresponding to the current state node during the state machine operation, achieves intelligent mapping from internal step state vectors to interface progress display. This efficiently transforms the complex and abstract internal state of the system into intuitive and easy-to-understand execution steps, processing status, and action prompts for users. This allows users to clearly grasp the handling rhythm and expected timeliness, significantly improving the transparency and controllability of the entire accident handling process, reducing the psychological burden on users under high-pressure conditions after an accident, and thus effectively enhancing users' trust in the system's automated handling capabilities and optimizing the overall cockpit interaction experience.

[0211] In one possible implementation, before each intended display of user prompts through the cockpit interface, the method provided in this embodiment further includes:

[0212] Based on the preset constraint rules and the state vector corresponding to the current state node of the state machine, the user prompts to be displayed in the cockpit interaction interface are verified for compliance, and the user prompts are only displayed in the cockpit interaction interface when the verification is successful.

[0213] Among them, the constraint rules are used to indicate the preconditions under which different user prompt words are allowed to be displayed, and / or the disabling conditions under which different user prompt words are prohibited from being displayed.

[0214] Accordingly, in practical applications, if the user prompt text to be displayed fails compliance verification, it will no longer be displayed through the cockpit interface. Optionally, for cases where the user prompt text to be displayed fails compliance verification, a violation code (constraint_violation_code) and a recommended transition direction (recommended_transition) can be generated. The violation code and recommended transition direction are written as event payloads into the state machine, so that after receiving the payload, the state machine completes the state node transition according to the recommended direction (e.g., transition to manual intervention, downgrade, or conflict resolution states), and triggers the corresponding processing steps. For example, for the prompt text "Responsibility has been determined" that fails compliance verification, the state node transition can be triggered to downgrade, and the downgraded steps can be executed, i.e., a safe and neutral prompt text (such as "Evidence is being verified, responsibility cannot be determined at this time") can be displayed.

[0215] For example, the constraint rules may include: only after receiving a receipt message from the corresponding target associated agency, the prompt "the target associated agency has received the request" is allowed to be displayed; or, the prompt "responsibility has been determined" is prohibited when the conditions "the confidence level of the initial accident level is greater than or equal to the second preset threshold" or "the evidence is complete" are not met, and the prompt "return to the vehicle and wait" is prohibited when the target accident level is a critical event.

[0216] Optionally, the conditions in the constraint rules can be stored in the form of Boolean expressions or Domain-Specific Language (DSL). Correspondingly, in practical applications, the constraint engine's interpreter can read the Boolean expressions or DSL rules from the constraint rule library, substitute the actual field values ​​of the event handling situation (e.g., target accident level, state vector of the current state node, etc.) into the rule for evaluation, and then determine whether the proposed prompt word passes compliance verification based on the output calculation result. For example, if the proposed prompt word is "Return to vehicle and wait," and the rule is "risk_level != L4," then if the current accident risk level is L4 (critical event), the interpreter's evaluation result will be "not satisfied," meaning the prompt word verification fails.

[0217] The method provided in this implementation performs compliance verification on the user prompts to be displayed on the cockpit interaction interface based on preset constraint rules and the state vector corresponding to the current state node of the state machine. The prompts are only displayed after the verification is passed. This enables the constraint engine to perform real-time verification during runtime, effectively avoiding the output of misleading prompts when there is insufficient evidence, incomplete information, or insufficient confidence. This eliminates the interference of incorrect prompts on the user's judgment from the source, thereby reducing the legal risks caused by improper prompts and improving the rigor, security, and credibility of cockpit interaction information.

[0218] The vehicle accident handling method provided in this application instantiates the target handling step sequence into a state machine and realizes automated execution based on the state machine. This enables the handling process to operate stably in a structured, standardized, and flowable manner, achieving the orderly advancement of the entire accident handling process without human intervention. This reduces the cost of human intervention while significantly improving handling efficiency and execution reliability.

[0219] Embodiment 3 of this application provides two specific implementation examples of this solution, specifically including:

[0220] Example 1: A rear-end collision occurs at low speed.

[0221] After confirming the accident, the acceleration sensor detected a 4g impact, the airbags did not deploy, and the vehicle's posture remained normal. Based on the classification rules and inference model, the initial accident level of the current vehicle was determined to be L1 (minor accident), with a confidence level C = 0.85. Since C is greater than the first preset threshold, the initial accident level was determined as the target accident level. Vehicle status data (including driving data, screenshots of the moment of collision, etc.) were captured for 30 seconds before and after the accident to obtain evidence data. The evidence data was then encrypted using an encrypted hash algorithm to obtain an evidence package. Based on the pre-established candidate step library, and under the constraints of the evidence data and the target accident level, the target processing step sequence with the minimum total cost was determined. This target processing step sequence is "upload photos of the other party's vehicle → send a request to the insurance company". The target processing step sequence was instantiated as a state machine and executed. During execution, the process begins by sending a prompt to the user via the cockpit interface: "Please take a photo of the other vehicle and upload it." Then, according to the insurance institution's data content and field format requirements, the evidence package containing the other vehicle photo is trimmed to a minimum dataset and anonymized to obtain the target sub-evidence package. An institutional call request carrying the target sub-evidence package is then constructed. The department uses a pre-configured external interface adapter to convert the institutional call request into a standardized request conforming to the insurance institution's interface protocol. After the initial send, a receipt message from the insurance institution is received before the countdown ends, at which point the process concludes. Furthermore, during execution, the cockpit interface displays real-time execution information related to the target processing step sequence based on the state vector corresponding to the current state node of the state machine.

[0222] Example 2: A high-speed collision involving vehicles.

[0223] After an accident is confirmed, the accelerometer detects a 12g impact, multiple airbags are deployed, and the vehicle tilts 35°. Based on the classification rules and inference model, the initial accident level of the vehicle is determined to be L3 (serious accident) with a confidence level C = 0.95. Since C is greater than the first preset threshold, the initial accident level is determined as the target accident level. Vehicle status data is captured for 30 seconds before and after the accident to obtain evidence data, which is then encrypted using an encrypted hash algorithm to obtain an evidence package. Based on a pre-established candidate step library, and under the constraints of the evidence data and the target accident level, the target processing step sequence with the minimum total cost is determined. This target processing step sequence is: "Send an alarm request to the traffic police → Send a rescue request to the rescue organization → Send a claim request to the insurance organization → The user confirms the liability determination information". The target processing step sequence is instantiated as a state machine and executed. During execution, the execution information of the target processing step sequence will be displayed in real time on the cockpit interface according to the state vector corresponding to the current state node of the state machine. In addition, during the execution process, due to the lack of photos of the injured, in order to meet the condition of "complete evidence", the display of prompts such as "accident liability has been determined" will be prohibited in the cockpit interface throughout the entire process.

[0224] Therefore, the two specific examples provided in this embodiment, through multi-source sensor fusion, output an accident level determination with confidence. Then, based on the accident level, the system automatically selects the target processing step sequence with the lowest cost under the constraint set. Next, a state machine is used to manage the execution of steps and exception handling. When the relevant steps are sent for execution request, cross-organizational standardized docking and closed-loop tracking of receipts are achieved through an external interface adapter. The constraint engine is used to perform runtime verification of user prompts to prevent misleading output. At the same time, the processing progress and intelligent action prompts are clearly displayed on the cockpit interaction interface. This makes the whole solution form a closed-loop accident handling system of "perception-decision-execution-feedback", which achieves more accurate and intelligent vehicle accident handling and effectively improves the user's safety experience and user satisfaction after an accident.

[0225] Figure 2 This is a schematic diagram of the structure of a vehicle accident handling device provided in Embodiment 4 of this application, as shown below. Figure 2 As shown, the vehicle accident handling device 20 provided in this embodiment includes:

[0226] The rating determination module 201 is used to determine the target accident rating of a vehicle based on accident-related status data in the vehicle after an accident has been determined. The target accident rating is used to indicate the severity of the current accident.

[0227] The evidence acquisition module 202 is used to acquire vehicle evidence data based on vehicle status data within a preset time window before and after the accident; the vehicle status data includes accident-related status data.

[0228] The step determination module 203 is used to determine the target processing step sequence that matches the target accident level and the integrity of the evidence data based on a pre-established candidate step library.

[0229] Execution module 204 is used to execute the target processing step sequence.

[0230] The vehicle accident handling device 20 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0231] Figure 3 This is a schematic diagram of the structure of a vehicle accident handling device provided in Embodiment 5 of this application, as shown below. Figure 3 As shown, based on the above embodiments, the vehicle accident handling device 20 provided in this embodiment further includes:

[0232] Processing module 205 is used to perform credible solidification processing on evidence data to obtain an evidence package;

[0233] Trustworthy solidification processing includes encrypting evidence data using a cryptographic hash algorithm.

[0234] The display module 206 is used to display the execution-related information of the target processing step sequence in the cockpit interaction interface in real time according to the state vector corresponding to the current state node of the state machine during the operation of the state machine; the execution-related information includes the current execution step, the execution status of the current execution step, and the corresponding user prompt information;

[0235] The state vector includes the step identifier corresponding to the state node and the step execution status.

[0236] The verification module 207 is used to perform compliance verification on the user prompt words to be displayed in the cockpit interaction interface according to the preset constraint rules and the state vector corresponding to the current state node of the state machine, and only display the user prompt words in the cockpit interaction interface when the verification is successful.

[0237] Constraint rules are used to indicate the preconditions under which different user prompts are allowed to be displayed, and / or the disallowed conditions under which different user prompts are prohibited from being displayed.

[0238] In one possible implementation, execution module 204 is specifically used for:

[0239] The target processing step sequence is instantiated as a state machine, and the state machine is used to automate the execution of the target processing step sequence.

[0240] In one possible implementation, the step determining module 203 is specifically used for:

[0241] Based on the target accident level and evidence data, a set of step constraints is constructed. The set of step constraints includes mandatory handling steps corresponding to the target accident level and evidence supplementation steps corresponding to the evidence data.

[0242] Based on the candidate step library, at least one candidate processing step sequence that satisfies the set of step constraints is determined;

[0243] For each candidate processing step sequence, the total cost of the candidate processing step sequence is calculated based on the total execution time of the candidate processing step sequence and the degree of human involvement.

[0244] The candidate processing step sequence with the minimum total cost is determined as the target processing step sequence.

[0245] In one possible implementation, the set of step constraints in the step determination module 203 may also include at least one of the following: communication mode constraints corresponding to vehicle network conditions, interface availability constraints of different associated agencies, and user reachability constraints; associated agencies include at least one of rescue agencies, traffic police agencies, and insurance agencies.

[0246] In one possible implementation, the accident-related status data in the rating determination module 201 includes at least one of the following: vehicle speed, collision acceleration, airbag triggering status, and vehicle posture data.

[0247] In one possible implementation, the level determination module 201 is specifically used for:

[0248] Based on the accident-related status data, the initial accident level of the vehicle and the confidence level of the initial accident level are obtained by using the preset level determination rules and / or the pre-trained inference model; the level determination rules and inference model are used to evaluate the accident level of the vehicle based on the accident-related status data.

[0249] The target accident level of the vehicle is determined based on the initial accident level, confidence level, and preset determination strategy; the preset determination strategy includes target level determination strategies corresponding to different confidence levels.

[0250] In one possible implementation, the target processing step sequence includes sending a request message to the target associated organization, which may be a rescue organization, a traffic police organization, or an insurance organization.

[0251] Execution module 204 is specifically used for:

[0252] The system uses a pre-configured external interface adapter to convert the organization's call request into a standardized request that conforms to the interface protocol of the target associated organization.

[0253] A standardized request is sent to the target associated organization, and upon receiving a response message from the target associated organization, the state machine is driven to proceed to the next step in the target step processing sequence.

[0254] In one possible implementation, the execution module 204 is further specifically used for:

[0255] If, after sending a standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization, the driving state machine will transition the state of the current step to execution failure and execute the current step using an alternative solution.

[0256] The alternative solutions include any of the following: sending a request message to the target associated organization via SMS; sending a request message to the target associated organization via telephone; caching the request message in the local storage area and automatically synchronizing and sending the request message to the target associated organization after the network is restored.

[0257] In one possible implementation, the agency call request includes a target sub-evidence package corresponding to the target associated agency;

[0258] Execution module 204 is also specifically used for:

[0259] Based on the data requirements of the target related institutions, the evidence package was trimmed into the smallest dataset;

[0260] The minimum dataset is anonymized to obtain the target sub-evidence package corresponding to the target associated institution; the data requirements include the data content requirements and data field format requirements of the target associated institution.

[0261] Based on the target sub-evidence package, obtain the agency call request.

[0262] The vehicle accident handling device 20 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0263] Figure 4 A schematic diagram of the processing equipment provided in this application. Figure 4 As shown, the processing device 30 provided in this embodiment includes at least one processor 301 and a memory 302. Optionally, the device 30 further includes a communication component 303. The processor 301, memory 302, and communication component 303 are connected via a bus 304.

[0264] In a specific implementation, at least one processor 301 executes computer execution instructions stored in memory 302, causing at least one processor 301 to perform the above-described method.

[0265] The specific implementation process of processor 301 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0266] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0267] The memory may include read-only memory and random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0268] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0269] This application also provides a vehicle including a vehicle body and a processing device, the electronic device being used to perform the above-described method.

[0270] This application also provides a computer program product, including a computer program that, when executed, implements the above-described method.

[0271] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed, implement the above-described method.

[0272] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as SRAM, EEPROM, EPROM, PROM, ROM, magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0273] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside within an ASIC. Alternatively, the processor and the readable storage medium can exist as discrete components in a device.

[0274] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0275] The units described as separate components may or may not be physically separate. The components shown as units 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.

[0276] In addition, the functional units in the various embodiments of the present invention 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.

[0277] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. 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.

[0278] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0279] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

[0280] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for handling vehicle accidents, characterized in that, The method includes: After determining that a vehicle accident has occurred, a target accident level for the vehicle is determined based on accident-related status data in the vehicle; the target accident level is used to indicate the severity of the current accident involving the vehicle. Based on vehicle status data within a preset time window before and after the accident, obtain evidence data of the vehicle; the vehicle status data includes the accident-related status data. Based on a pre-established candidate step library, a sequence of target processing steps that matches the target accident level and the integrity of the evidence data is determined. Execute the target processing step sequence.

2. The method according to claim 1, characterized in that, The sequence of execution of the target processing steps includes: The target processing step sequence is instantiated as a state machine, and the state machine is used to automate the execution of the target processing step sequence.

3. The method according to claim 1, characterized in that, The step of determining a target processing step sequence that matches the target accident level and the integrity of the evidence data based on a pre-established candidate step library includes: Based on the target accident level and the evidence data, a set of step constraints is constructed; the set of step constraints includes mandatory handling steps corresponding to the target accident level and evidence supplementation steps corresponding to the evidence data. Based on the candidate step library, at least one candidate processing step sequence that satisfies the set of step constraints is determined; For each candidate processing step sequence, the total cost of the candidate processing step sequence is calculated based on the total execution time of the candidate processing step sequence and the degree of human intervention. The candidate processing step sequence with the minimum total cost is determined as the target processing step sequence.

4. The method according to claim 3, characterized in that, The set of constraints for the steps also includes at least one of the following: communication method constraints corresponding to vehicle network conditions, interface availability constraints of different associated institutions, and user reachability constraints; the associated institutions include at least one of rescue institutions, traffic police institutions, and insurance institutions.

5. The method according to claim 1, characterized in that, The accident-related status data includes at least one of the vehicle's speed, collision acceleration, airbag deployment status, and vehicle posture data.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The evidence data is subjected to a reliable solidification process to obtain an evidence package; The trusted solidification process includes encrypting the evidence data using a cryptographic hash algorithm.

7. The method according to any one of claims 1 to 5, characterized in that, Determining the target accident level of the vehicle based on the vehicle's accident association status data includes: Based on the accident-related status data, a preset level determination rule and / or a pre-trained inference model are used to obtain the initial accident level of the vehicle and the confidence level of the initial accident level; the level determination rule and the inference model are used to evaluate the accident level of the vehicle based on the accident-related status data. The target accident level of the vehicle is determined based on the initial accident level, the confidence level, and the preset determination strategy; the preset determination strategy includes target level determination strategies corresponding to different confidence levels.

8. The method according to claim 2, characterized in that, The target processing step sequence includes sending a request message to the target associated organization, which may be a rescue organization, a traffic police organization, or an insurance organization. The automated execution of the target processing step sequence using the state machine includes: The system uses a pre-configured external interface adapter to convert the organization's call request into a standardized request that conforms to the interface protocol of the target associated organization. The standardization request is sent to the target associated organization, and upon receiving a confirmation message from the target associated organization, the state machine is driven to enter the next step in the target step processing sequence.

9. The method according to claim 8, characterized in that, The method further includes: If, after sending the standardized request to the target associated organization, the number of retries reaches the preset maximum and no acknowledgment message is received from the target associated organization, the state machine is driven to transition the state of the current step to execution failure, and an alternative scheme is used to execute the current step. The alternative solutions include any of the following: sending a request message to the target associated organization via SMS; sending a request message to the target associated organization via telephone; caching the request message in the local storage area and automatically synchronizing and sending the request message to the target associated organization after the network is restored.

10. The method according to claim 9, characterized in that, The request to invoke the organization includes the target sub-evidence package corresponding to the target associated organization; Before converting the organization call request into a standardized request conforming to the interface protocol of the target associated organization through a pre-configured external interface adapter, the method further includes: According to the data requirements of the target associated institution, the evidence package is trimmed into the minimum dataset; The minimum dataset is anonymized to obtain the target sub-evidence package corresponding to the target associated institution; the data requirements include the data content requirements and data field format requirements of the target associated institution. Based on the target sub-evidence package, obtain the agency call request.

11. The method according to any one of claims 2 to 5, characterized in that, The method further includes: During the operation of the state machine, the execution-related information of the target processing step sequence is displayed in the cockpit interface in real time according to the state vector corresponding to the current state node of the state machine; the execution-related information includes the current execution step, the execution status of the current execution step, and the corresponding user prompt information; The state vector includes the step identifier and step execution status corresponding to the state node.

12. The method according to claim 11, characterized in that, The method further includes: Based on the preset constraint rules and the state vector corresponding to the current state node of the state machine, the user prompt words to be displayed in the cockpit interaction interface are verified for compliance, and the user prompt words are displayed in the cockpit interaction interface only when the verification is successful. The constraint rules are used to indicate the preconditions under which different user prompts are allowed to be displayed, and / or the disabling conditions under which different user prompts are prohibited from being displayed.

13. A vehicle accident handling device, characterized in that, The device includes: The rating determination module is used to determine the target accident rating of a vehicle based on accident-related status data in the vehicle after an accident is determined to have occurred; the target accident rating is used to indicate the severity of the current accident involving the vehicle. The evidence acquisition module is used to acquire evidence data of the vehicle based on vehicle status data within a preset time window before and after the accident; the vehicle status data includes the accident-related status data. The step determination module is used to determine the target processing step sequence that matches the target accident level and the integrity of the evidence data based on a pre-established candidate step library; An execution module is used to execute the target processing step sequence.

14. A processing apparatus, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-12.

15. A vehicle, characterized in that, The vehicle includes a vehicle body and the processing equipment as described in claim 14.

Images