A DSSAD data extraction method, medium and computer device

CN122618719BActive Publication Date: 2026-11-03BEIJING CATARC DATA TECH CENT
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202610717941.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-05-22
Publication Date
2026-11-03
Estimated Expiration
2046-05-22

AI Technical Summary

Technical Problem

现有取证设备大多仅支持一种模式,缺乏自适应识别与差异化提取能力

Benefits of technology

本发明的主流程严格遵循“自动识别接口→检测是否存在II型系统→若存在则按编号提取连续记录数据;若不存在则先选时间范围再提取I型事件数据”这一逻辑,与一线办案人员的实际取证思考过程高度一致,易于理解和实施。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122618719B_ABST
    Figure CN122618719B_ABST
Patent Text Reader

Abstract

The application discloses a DSSAD data extraction method, a medium and computer equipment, and the method comprises the following steps: automatically identifying a vehicle diagnosis interface type and establishing a network connection, detecting whether a type II system exists, extracting data of the type II system, detecting and extracting data of a type I system, detecting a DSSAD system authority and dynamically adapting, checking data integrity and recovering from an exception, encapsulating and storing evidence, and completing data extraction. The application can automatically identify a DSSAD type, adaptively adapt an authority, and ensure the integrity of data extraction under an abnormal working condition.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of electronic data forensics technology for intelligent connected vehicles, and more specifically to a DSSAD data extraction method, medium, and computer equipment. Background Technology

[0002] Vehicles equipped with autonomous driving capabilities are gradually being deployed on a large scale. When an autonomous driving system is activated, the driving responsibility shifts from the human to the system, and the determination of liability in traffic accidents relies heavily on the objective data recorded by the vehicle. The Data Storage System for Automated Driving (DSSAD), as a legally mandated onboard data recording device, continuously monitors and stores vehicle status, driving behavior, system operation information, and driving environment data, serving as core evidence for determining liability in accidents.

[0003] However, the following technical challenges currently exist in extracting DSSAD data: First, the DSSA system is designed with strict access control. To meet data security requirements, DSSAD typically incorporates secure boot and anti-tampering mechanisms, and data access requires a proprietary authorization token or dynamic key from the vehicle manufacturer. Law enforcement officers lack the necessary authorization software and hardware at the accident scene and can only request data from the vehicle manufacturer afterward, a process that can take weeks and severely hinders case processing efficiency.

[0004] Second, DSSAD employs two completely different data organization models. Depending on the vehicle category, DSSAD can be divided into event-triggered systems (hereinafter referred to as "Type I systems") and continuous recording systems (hereinafter referred to as "Type II systems"). Type I systems store data in discrete events (collision events, timestamp events); Type II systems store data as a continuous time series. The data reading methods, indexing logic, and extraction strategies of the two types of systems are drastically different. Most existing forensic equipment only supports one model and lacks adaptive recognition and differentiated extraction capabilities.

[0005] Third, vehicles at accident scenes often suffer from varying degrees of physical damage or power supply abnormalities. Extreme conditions such as collisions, fires, and water immersion can cause instability in the DSSAD communication interface, frame loss in data transmission, or file incompleteness. Conventional one-time reads cannot obtain complete data, seriously affecting the value of evidence. Summary of the Invention

[0006] The present invention provides a DSSAD data extraction method, medium, and computer equipment that can automatically identify DSSAD types, adaptively adapt permissions, and ensure data integrity under abnormal working conditions, which can at least solve one of the above-mentioned technical problems.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A DSSAD data extraction method includes the following steps: S1. After the data extraction device physically connects with the target vehicle, it automatically identifies the diagnostic interface type of the target vehicle in order to establish a communication link between them. S2. On the established diagnostic communication link, the data extraction device sends a DSSAD type detection command to the vehicle bus, analyzes the response of the target vehicle to determine whether there is an event-triggered system or a continuous recording system, and extracts data according to the DSSAD type. S3. During the data extraction process, synchronously detect whether the system corresponding to the current DSSAD type has set read permission restrictions; S4. Perform systematic integrity checks on all extracted raw data, and implement automatic recovery when anomalies are detected. Package the valid data that passes the integrity check in a unified format to complete the data extraction.

[0008] Furthermore, in step S1, after establishing a physical connection, the data extraction device automatically initiates an interface type detection process, including: S1.1 The data extraction device sends a test activation command conforming to the vehicle diagnostic standard to the diagnostic interface, and automatically determines the communication link type supported by the current vehicle based on the response characteristics of the target vehicle's diagnostic interface: S1.1.1 If a diagnostic response message based on the Controller Area Network bus is received within the predetermined timeout period, it is determined that the current vehicle uses the CAN bus diagnostic interface, and subsequent communication will be based on the CAN transmission protocol. S1.1.2 If an Ethernet-based diagnostic response message is received, it is determined that the current vehicle uses the Ethernet diagnostic interface, and subsequent communication will use the Ethernet physical layer and transport layer protocols. S1.2 When the target vehicle is determined to have an Ethernet diagnostic interface, a communication session is established according to the Ethernet diagnostic communication protocol specification: S1.2.1 Port Negotiation and Binding: The data extraction device opens a dynamic port locally and sends a connection request to the diagnostic interface address of the target vehicle; S1.2.2 Vehicle Declaration Acquisition: After the connection is established, the target vehicle actively broadcasts or responds to the request, sending its own vehicle identification information. The data extraction device receives and parses the vehicle identification information for subsequent identity association and evidence encapsulation. S1.2.3, Route Activation: The data extraction device sends a route activation request based on the received and parsed vehicle identification information. The target vehicle verifies the request and returns a route activation confirmation message after successful verification. S1.2.4 Transmission Parameter Negotiation: To ensure communication efficiency and stability, the data extraction device and the target vehicle exchange their respective transmission layer parameters; S1.3 When it is determined that the target vehicle is conducting diagnostic communication based on the Controller Area Network (CAN) bus, the adapter mode is adopted: the data extraction device automatically activates the internal protocol conversion module to convert the Ethernet diagnostic communication protocol request into a CAN bus request, and re-encapsulates the CAN response of the target vehicle into an Ethernet diagnostic message format, so that the upper-layer DSSAD extraction logic does not need to be aware of the differences in the underlying physical link. S1.4 After the communication link is successfully established, the data extraction device periodically sends a keep-alive command to prevent the vehicle diagnostic network from automatically disconnecting due to timeout.

[0009] Furthermore, in step S2, the analysis process of the data extraction device on the target vehicle's response includes: S2.1 If a response indicating support for continuous recording mode is received, it is determined that the current vehicle is equipped with a continuous recording system. Then, the DSSAD data extraction process of the continuous recording system is executed, and after the data extraction is completed, the detection and data extraction of the event-triggered system are continued. S2.2 If the received response indicates that continuous recording mode is not supported, or if a valid response containing continuous recording features is not received within the timeout period, it is determined that the current vehicle does not have a continuous recording system, and the detection and data extraction of the event-triggered system are directly executed.

[0010] Furthermore, in S2, the continuous recording system organizes data in a continuous time series manner. The data storage is divided into multiple consecutive storage spaces, each with a unique data number associated with a segment of continuous time series data. The DSSAD data extraction process of the continuous recording system includes: S2.a.1 Detect the list of data numbers stored in the continuous recording system; A data number index retrieval instruction is sent to the continuous recording system. This instruction does not include any time or range parameters, but only requests the system to return all data numbers stored internally. After receiving the instruction, the continuous recording system traverses its storage medium, organizes the numbers of all valid storage spaces into a list according to the order of storage time, and returns it to the data retrieval device. In addition to a unique identifier, each data number also includes the start timestamp and end timestamp corresponding to the storage space. The data retrieval device temporarily stores the above information. S2.a.2, Return a list of data numbers for selection; The data extraction device displays the received data number list and its corresponding time range in chronological order on the operation interface. Based on the estimated time of the accident, select one or more data numbers that best match the accident time from the list. If no selection is made manually, the data number containing the accident time point will be automatically selected. S2.a.3. Extract the corresponding set of consecutive records based on the selected data number; The data extraction device sends a data reading instruction by number to the continuous recording system. The instruction parameter is one or more selected data numbers. After receiving the instruction, the continuous recording system locates the starting address of the storage space corresponding to each data number and reads all the data in the storage space continuously. The data extraction device organizes the read data into a continuous binary data stream and temporarily stores it in the internal cache. S2.a.4, Merging of multiple data numbers; If multiple consecutive data numbers are selected, the data extraction device will stitch the multiple storage spaces into a complete, seamless time-series data set in chronological order. During stitching, it checks whether the timestamps of two consecutive storage spaces are continuous. If there are small gaps, linear interpolation is used to fill them in. If the gaps are too large, they are marked as missing data areas.

[0011] Furthermore, in S2, the event-triggered system organizes data in discrete events, including timestamp events and time period events. The process of detecting the existence of the event-triggered system includes: S2.3 If a response indicating support for event-triggered mode is received, it is determined that an event-triggered system exists; S2.4 If no valid response is received, or if the response explicitly indicates that the event-triggered mode is not supported, then it is determined that there is no event-triggered system.

[0012] Furthermore, in S2, for event-triggered systems, data is extracted according to a strategy of first selecting a time range and then checking if there is a value. The process includes: S2.b.1 Select the time range of the accident point; Based on the known or estimated time of the accident, a time window for data to be extracted is set, which is defined by two parameters: start time and end time. S2.b.2 Detect whether there is valid data in the selected time range of the event-triggered system; The data extraction device sends an instruction to the event-triggered system to query the existence of events by time range. The instruction carries the start time and end time set in S2.b.1. The event-triggered system internally compares the trigger timestamps of each event to quickly determine whether at least one event's timestamp falls within the window. S2.b.3 Extract the set of timestamp event data and the single timestamp event frame data object within the event range; The event-triggered system extracts the data of all timestamp events within the time window and organizes them into a data set in chronological order. For each timestamp event, the following data is extracted: the basic metadata of the event, the data set of a single timestamp event, and the single frame data object corresponding to the event. All extracted event data are arranged in ascending order according to the event trigger timestamp and stored in the temporary buffer of the data extraction device.

[0013] Furthermore, in S3, the read permission detection method involves sending a standard read command and then analyzing the system's response code corresponding to the DSSAD type. If normal data is returned, it is determined that no additional permission is required, and the original extraction process continues. If an error code such as "Access Denied" or "Insufficient Permissions" is returned, it is determined that authorization credentials are required. At this time, the data extraction device automatically calls the built-in authorization service interface and initiates a credential request to the authorization server through a pre-established secure channel. After the authorization server verifies the credentials, it returns a time-sensitive device-level access credential. After obtaining the credential, the data extraction device attaches it to the read command and resends it. The system corresponding to the DSSAD type verifies the validity of the credential and grants data read permissions.

[0014] Furthermore, in step S4, the integrity verification process for the extracted raw data includes: S4.1, Length and continuity dual verification; Length check: The effective payload length of all received data frames is accumulated and compared with the total effective length of the first frame. If they are equal, the length check passes; otherwise, the data is considered incomplete. Frame sequence number continuity check: Check frame by frame whether the frame sequence number is strictly increasing and without missing. If all frame sequence numbers are consecutive, the continuity check passes. If sequence number jumps, repetitions, or premature termination are found, it is determined that there is frame loss or transmission interruption. S4.2 For cases where continuity verification fails, dynamic flow control adjustments are made, including reducing the number of frames requested by a single data extraction command, extending the interval between two consecutive requests, and resending the same data extraction command to the system corresponding to the DSSAD type. S4.3 For scenarios where multiple reads are incomplete but different segments are lost, redundant data fusion is performed. This involves aligning the data frames read each time according to their frame numbers before performing the fusion operation, including: For each frame sequence number, select one from the frames that appear in at least two reads, prioritizing the copy with the correct checksum. If a frame number does not appear in all reads, it is marked as permanently missing and noted in the final evidence; S4.4, dual consistency check; After a successful read, the data extraction device immediately executes the exact same data extraction command again to obtain a second, independently read data. The data obtained in the first read is then compared byte by byte with the data obtained in the second read. If the two sets of data are exactly the same, the data consistency is deemed valid and the evidence is credible. If any discrepancies exist, the retransmission mechanism is triggered, the cached data is cleared, and two new independent reads are performed again. If the discrepancies are still not consistent after three rounds, the data with the largest discrepancy between the two reads, along with the discrepancy description, is retained and marked.

[0015] A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the DSSAD data extraction method described above.

[0016] A computer device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the DSSAD data extraction method described above.

[0017] The beneficial effects of this invention are reflected in: 1. Fully cover the key judgment points in accident scene evidence collection The main process of this invention strictly follows the logic of "automatic interface identification → detection of the existence of a Type II system → if it exists, extract continuous record data by number; if it does not exist, select a time range first and then extract Type I event data", which is highly consistent with the actual evidence collection thinking process of front-line case handlers and is easy to understand and implement.

[0018] 2. A differentiated extraction strategy based on type II priority detection was implemented. This invention prioritizes determining whether a vehicle is equipped with a Type II continuous recording system, because the Type II system has a large amount of data and continuous time, making it suitable for direct location based on data number; if a Type II system is not present, it switches to a Type I event system and adopts a strategy of first selecting a time range and then checking if there is a value, thus avoiding the inefficiency caused by scanning all event numbers.

[0019] 3. A multi-level data integrity assurance system was designed to address communication instability after an incident. By employing a series of methods, including dual verification of length and frame sequence number, dynamic flow control adjustment, redundancy fusion, and dual consistency comparison, the probability of successfully extracting complete DSSAD data from vehicles under abnormal operating conditions has been significantly improved, ensuring the judicial usability of the evidence. Attached Figure Description

[0020] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0021] Figure 1 This is a schematic diagram of the overall process of the DSSAD data extraction method according to an embodiment of the present invention.

[0022] Figure 2 This is a schematic diagram of the data structure of the Type II system according to an embodiment of the present invention.

[0023] Figure 3 This is a schematic diagram of the data structure of a Type I system according to an embodiment of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It should be noted that the meaning of "and / or" throughout the text includes three parallel solutions. Taking "A and / or B" as an example, it includes solution A, solution B, or a solution that simultaneously satisfies A and B. Furthermore, "multiple" refers to two or more. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0026] See Figure 1 This invention provides a DSSAD data extraction method, comprising the following steps: S1. After the data extraction device physically connects with the target vehicle, it automatically identifies the diagnostic interface type of the target vehicle in order to establish a communication link between them. S2. On the established diagnostic communication link, the data extraction device sends a DSSAD type detection command to the vehicle bus (this detection command uses the "Read Data Identifier" service in the standard diagnostic session, but uses a specific parameter identifier dedicated to DSSAD system type query). Based on the response analysis of the target vehicle, it analyzes whether there is an event-triggered system (Type I system) or a continuous recording system (Type II system), and performs data extraction according to the DSSAD type. S3. During the data extraction process, synchronously detect whether the system corresponding to the current DSSAD type has set read permission restrictions; S4. Perform systematic integrity checks on all extracted raw data, and implement automatic recovery when anomalies are detected. Package the valid data that passes the integrity check in a unified format to complete the data extraction.

[0027] In this embodiment, during step S1, when the data extraction device performs the data extraction operation, it should first make a physical connection with the diagnostic interface of the target vehicle through a standard vehicle diagnostic connection cable. It should be noted that the data extraction device mentioned in this application is a hardware device used to implement the DSSAD data extraction method. Its specific assembly structure, size, model, etc. are not the focus of protection of this application. Any hardware device that can implement the DSSAD data extraction method to be protected by this application falls within the protection scope of this application. The diagnostic interface of the target vehicle is usually in the form of an OBD interface, located below the dashboard in the vehicle's cockpit. The connection cable should support both physical layer signals, namely bus communication based on the controller area network and diagnostic communication based on Ethernet, in order to adapt to the interface definitions of different vehicle platforms.

[0028] In this embodiment, in step S1, after establishing a physical connection, the data extraction device automatically initiates the interface type detection process, including: S1.1 Activate diagnostic communication and identify link type The data extraction device sends a test activation command conforming to vehicle diagnostic standards to the diagnostic interface. This command uses a universal session initiation format and does not carry any brand-specific parameters. Based on the response characteristics of the target vehicle's diagnostic interface, it automatically determines the communication link type supported by the current vehicle. (1) If a diagnostic response message based on the controller area network bus is received within the predetermined timeout period (usually 500 milliseconds), it is determined that the current vehicle uses the CAN bus diagnostic interface, and subsequent communication will be based on the CAN transmission protocol. (2) If an Ethernet-based diagnostic response message is received (especially a “routing activation” confirmation message that conforms to the Ethernet diagnostic communication protocol specification), it is determined that the current vehicle uses the Ethernet diagnostic interface and subsequent communication will use the Ethernet physical layer and transport layer protocol.

[0029] S1.2 Establish an Ethernet diagnostic communication session (for Ethernet interfaces) When the target vehicle is determined to have an Ethernet diagnostic interface, a communication session is established according to the Ethernet diagnostic communication protocol specification: (1) Port negotiation and binding: The data extraction device opens a dynamic port locally and sends a connection request to the diagnostic interface address of the target vehicle. All diagnostic messages use the predefined default port number 13400 as the target port. This port number is the standard diagnostic port agreed upon by all vehicle control systems that support Ethernet diagnostic communication. (2) Vehicle Declaration Acquisition: After the connection is established, the target vehicle actively broadcasts or responds to the request and sends its own vehicle identification information, including: the vehicle's unique identification code (VIN code), the name or code of the vehicle manufacturer, and the current vehicle's diagnostic function address list. The data extraction device receives and parses the vehicle identification information for subsequent identity association and evidence encapsulation. (3) Route activation: The data extraction device sends a route activation request based on the received and parsed vehicle identification information. The target vehicle verifies the request (such as checking the validity of the source address and the validity of the session ID). After the verification is successful, a route activation confirmation message is returned. At this time, a dedicated virtual diagnostic communication channel is established between the data extraction device and the vehicle diagnostic gateway. All subsequent DSSAD data extraction instructions are transmitted in this channel. (4) Transmission parameter negotiation: To ensure communication efficiency and stability, the data extraction device and the target vehicle exchange their respective transmission layer parameters, including: maximum transmission unit size, flow control token interval, data transmission timeout, etc. The data extraction device can dynamically adjust these parameters according to the needs of subsequent steps.

[0030] S1.3, Handling compatibility issues with non-Ethernet interfaces When it is determined that the target vehicle is conducting diagnostic communication based on the Controller Area Network (CAN) bus (common in older models or vehicles without Ethernet diagnostic capabilities), the adapter mode is adopted: the data extraction device automatically activates the internal protocol conversion module to convert the Ethernet diagnostic communication protocol request into a CAN bus request, and re-encapsulates the CAN response of the target vehicle into an Ethernet diagnostic message format, so that the upper-layer DSSAD extraction logic does not need to be aware of the differences in the underlying physical link. If any error occurs during the connection process (such as no response, verification failure, version mismatch, etc.), the data extraction device will automatically retry multiple times (up to 3 times, with an interval of 1 second each time). If it still fails after exceeding the number of retries, it will return a clear error message, and the operator will check the physical connection or the vehicle power supply status.

[0031] S1.4 After the communication link is successfully established, the data extraction device sends a keep-alive command periodically (e.g., every 2 seconds) to prevent the vehicle diagnostic network from automatically disconnecting due to timeout. The keep-alive command uses a minimum length no-operation diagnostic service and does not affect the normal operation of the DSSAD system.

[0032] After the operation described in S1, a stable and reliable communication link is established between the data extraction device and the target vehicle, meeting the requirements for all subsequent DSSAD data extraction command interactions. Once the link is successfully established, the process proceeds to S2.

[0033] In this embodiment, the analysis process of the data extraction device's response to the target vehicle in step S2 includes: S2.1 If a response is received that clearly indicates support for continuous recording mode (e.g., the response message contains characteristic fields such as "continuous storage capability" and "time range read support"), it is determined that the current vehicle is equipped with a Type II system. Then, the DSSAD data extraction process of the Type II system is executed, and after the data extraction is completed, the detection and data extraction of the Type I system are continued. S2.2 If the received response indicates that continuous recording mode is not supported (e.g., the response message contains features such as "event-triggered mode"), or if a valid response containing continuous recording features is not received within the timeout period, it is determined that the current vehicle does not have a Type II system, and the detection and data extraction of the Type I system are directly executed.

[0034] It should be noted that regardless of whether the Type II system is present, the Type I system testing procedure must be performed, because the target vehicle may be equipped with both systems or only the Type I system.

[0035] In this embodiment, in S2, the Type II system organizes data as a continuous time series. The data storage is divided into multiple consecutive storage spaces (or "data blocks"), each storage space having a unique data number associated with a segment of continuous time series data. The DSSAD data extraction process of the Type II system includes: S2.a.1 Detect the list of data numbers stored in the Type II system; A data number index retrieval instruction is sent to the Type II system. This instruction does not include any time or range parameters, but only requests the system to return all data numbers stored internally. After receiving the instruction, the Type II system traverses its storage media, organizes the numbers of all valid storage spaces into a list in chronological order of storage time, and returns it to the data retrieval device. In addition to a unique identifier, each data number also includes the start and end timestamps (with millisecond precision and using Coordinated Universal Time) corresponding to the storage space. The data retrieval device temporarily stores the above information.

[0036] S2.a.2. Return a list of data numbers for operators to select from; The data extraction device displays the received data number list and its corresponding time range in chronological order on the operation interface. The operator selects one or more data numbers from the list that best match the time of the accident based on the estimated time of the accident. If the operator does not manually select, the device will automatically select the data number that contains the time of the accident.

[0037] S2.a.3. Extract the corresponding set of consecutive records based on the selected data number; The data extraction device sends a data reading instruction by number to the Type II system. The instruction parameter is one or more selected data numbers. After receiving the instruction, the Type II system locates the starting address of the storage space corresponding to each data number and reads all the data in the storage space continuously. The data extraction device organizes the read data into a continuous binary data stream and temporarily stores it in the internal cache. The read data set contains the following: (1) All raw frame data objects in the continuous time series within this storage space; (2) Timestamp interval information between frame data objects; (3) Integrity verification information of storage space.

[0038] S2.a.4, Merging of multiple data numbers; If multiple consecutive data numbers are selected (e.g., the incident time spans the boundary of two storage spaces), the data extraction device will stitch the multiple storage spaces into a complete, seamless time-series data set in chronological order. During stitching, it checks whether the timestamps of the two storage spaces are continuous. If there are small gaps (e.g., less than 100 milliseconds), linear interpolation is used to fill them in. If the gaps are too large, they are marked as missing data areas.

[0039] After the data extraction for the Type II system is completed, the results are temporarily saved, and the detection and data extraction for the Type I system are continued.

[0040] In this embodiment, in step S2, the Type I system organizes data in discrete events, including timestamp events and time period events, and sends a Type I system detection command to the vehicle bus. This command differs from the detection command in step S2, focusing on querying event triggering capabilities. After sending, the response is analyzed. The process of detecting the existence of the Type I system includes: S2.3 If a response indicating support for the event-triggered mode is received (e.g., the response message contains features such as "timestamped event list" or "event number index"), then it is determined that a Type I system exists. S2.4 If no valid response is received, or the response explicitly indicates that the event-triggered mode is not supported, it is determined that there is no Type I system. In this case, if data from a Type II system has been extracted before, evidence encapsulation will proceed directly; if no data has been extracted before (i.e., neither Type II nor Type I), the extraction process will end directly.

[0041] In this embodiment, in step S2, for event-triggered systems, data is extracted according to the strategy of "first selecting a time range, then checking if there is a value". The process includes: S2.b.1 Select the time range of the accident point; Based on the known or estimated time of the accident, a time window for extracting data is set. This window is defined by two parameters: start time and end time (for example, if the accident time is 14:32:10, the window is set to 30 seconds before and after, i.e., from 14:31:40 to 14:32:40), with a time precision of milliseconds.

[0042] Since each event in a Type I system is recorded with a precise trigger timestamp, this time window will be used for subsequent event filtering.

[0043] S2.b.2 Detect whether there is valid data in the selected time range of the event-triggered system; The data extraction device sends an instruction to the event-triggered system to query the existence of events by time range. The instruction carries the start time and end time set in S2.b.1. The event-triggered system internally compares the trigger timestamps of each event to quickly determine whether at least one event's timestamp falls within the window. (1) If there are no events: return the “No valid data” flag. At this time, the data extraction device will prompt “No data records in the selected time range” on the operation interface and suggest that the operator reselect the time range. If the operator refuses to reselect, then: if the Type II system data has been extracted before, the evidence will be sealed directly. If no data has been extracted, the extraction process will end directly. (2) If one or more events exist: return the “valued” flag and then proceed to the next step.

[0044] S2.b.3 Extract the set of timestamp event data and the single timestamp event frame data object within the event range; The event-triggered system extracts data from all timestamped events within the time window and organizes them into a dataset in chronological order. For each timestamped event, the following data is extracted: (1) Basic meta-information of the event (event type identifier, triggering conditions, credibility at the time of triggering, etc.); (2) Data set of a single timestamp event (including vehicle speed, acceleration, steering wheel angle, brake pedal force, autonomous driving activation status, driver intervention signal, etc. at that moment); (3) The single frame data object corresponding to the event.

[0045] For time-segment events that exist simultaneously within a time window (such as collision events), this invention also extracts their complete data (including the continuous frame sequence before and after the event start point within a specified time period, a single time-segment event data object, and each frame object), but at least the timestamp event data must be extracted.

[0046] All extracted event data are sorted in ascending order by event trigger timestamp and stored in a temporary buffer of the data extraction device. The data for each event retains its original encoding format without any decoding or conversion.

[0047] After the data extraction of the Type I system is completed, permission adaptation verification is performed (if it has not been performed during the extraction process), and then integrity verification is performed.

[0048] The extraction strategies and data characteristics of Type II and Type I systems are shown in Table 1 below.

[0049] Table 1. Comparison of Extraction Strategies and Data Characteristics between Type II and Type I Systems

[0050] In addition, the data structures of Type II system and Type I system are as follows: Figure 2 and Figure 3 As shown.

[0051] In this embodiment, in step S3, the read permission detection method is to analyze the system response code corresponding to the DSSAD type after sending a standard read command: (1) If normal data is returned, it is determined that there are no additional permission requirements, and the original extraction process continues; (2) If an error code such as "Access Denied" or "Insufficient Permissions" is returned, it is determined that an authorization credential is required. At this time, the data extraction device automatically calls the built-in authorization service interface and initiates a credential request to the authorization server through a pre-established secure channel (the request information includes the unique identifier of this extraction operation, the target vehicle identification number, and the DSSAD system serial number, etc.). After the authorization server verifies the credential, it returns a time-sensitive device-level access credential. After the data extraction device obtains the credential, it attaches it to the read command and resends it. The system corresponding to the DSSAD type verifies the validity of the credential and grants the data read permission.

[0052] In this embodiment, in step S4, since an accident may cause fluctuations in vehicle power supply, poor communication line contact, or unstable operation of the DSSAD itself, the extracted data after obtaining data through step S5 may still have problems such as frame loss, packet interruption, and discontinuous frame sequence numbers. Therefore, the integrity verification of the extracted original data includes the following process: S4.1, Length and Continuity Dual Check When DSSAD transmits data back (regardless of whether it is a Type II system or a Type I system), the data packets follow a unified transmission protocol format: ① The first frame of data declares the total effective length (number of bytes) of this transmission; ② Each subsequent data frame carries an incrementing frame sequence number (starting from 1).

[0053] (1) Length check: The effective payload length of all received data frames is accumulated and compared with the total effective length of the first frame data. If they are equal, the length check passes; otherwise, the data is determined to be incomplete. (2) Frame sequence number continuity check: Check whether the frame sequence number is strictly increasing and without missing frames. If all frame sequence numbers are consecutive (e.g., 1, 2, 3, ..., N), the continuity check passes. If the sequence number is found to jump, repeat, or terminate prematurely, it is determined that there is frame loss or transmission interruption.

[0054] S4.2 Dynamic flow control adjustment (for continuity check failures) If the continuity check fails, it indicates that the DSSAD device has insufficient responsiveness or the communication channel is unstable. The data extraction device will automatically execute a dynamic flow control adjustment strategy. (1) Reduce the number of frames requested in a single data fetch command (e.g., reduce from 100 frames per request to 20 frames per request). (2) Increase the interval between two consecutive requests (e.g., from the default 10 milliseconds to 100 milliseconds). (3) Resend the same data extraction command to DSSAD.

[0055] Dynamic flow control adjustments can be iterated step by step (each time further reducing the number of frames or increasing the interval) until the data integrity check passes or the preset maximum number of retries is reached (e.g., 5 times). If it still fails, the redundant data fusion strategy is switched to.

[0056] S4.3 Redundant Data Fusion (for cases where multiple reads are incomplete but different missing segments) In extreme cases (such as severe fluctuations in vehicle power), a single data read may lose different frame fragments, but the union of multiple independent reads can cover all frames. The data extraction device will automatically perform up to three independent complete reads, each using the same instruction parameters. The data frames read each time are aligned according to their frame sequence numbers, and then a fusion operation is performed, including: (1) For each frame number, select one from the frames that appear in at least two reads, and give priority to the copy with the correct checksum; (2) If a frame number does not appear in all reads, it is marked as permanently missing and noted in the final evidence.

[0057] The fused dataset generates a dataset that is as complete as possible, and includes an integrity report that indicates which frames were recovered through redundancy and which frames were permanently lost.

[0058] S4.4, Dual Consistency Check After a successful read (or fusion to obtain a complete dataset), the data extraction device immediately repeats the exact same data extraction command (without changing any parameters) to obtain the second independently read data. The data obtained the first time (or the fused data) is then compared byte by byte with the data obtained the second time. (1) If the two sets of data are exactly the same, the data consistency is deemed valid and the evidence is credible; (2) If any discrepancy exists, the retransmission mechanism is triggered, the cached data is cleared, and two new independent reads are performed again (up to 3 rounds can be repeated). If the discrepancy is still not resolved after three rounds, the data with the largest discrepancy between the two reads, along with the discrepancy description, is retained and marked as "Consistency check failed, manual review required".

[0059] In addition, the system's integrity verification also includes special handling for file-type interfaces (if the DSSAD provides data in file format via USB or other serial ports). Since some older or specially designed DSSADs may provide data via USB mass storage devices in an emulation manner, the data is copied in file format. The integrity verification method for this is as follows: (1) Confirm that the number of files matches the number declared in DSSAD; (2) Check whether the size of each file is within the reasonable deviation range of the average file size (e.g., not exceeding ±10% of the average). If the size of a file is abnormally small, it is preliminarily judged to be incomplete. (3) Open the file and check its internal timestamp records to see if they are continuous with the timestamps of adjacent files. If the timestamps are broken (for example, the last record of the previous file is 14:00:00 and the first record of the next file is 14:00:05, with a 5-second gap that is not within a reasonable boundary), then the file is determined to be incomplete. (4) For incomplete files, repeat the copy operation, and re-verify after each copy until the file is complete or the retry limit is reached.

[0060] Data that passes the system integrity check will proceed to the next step: encapsulation. The encapsulation process includes: (1) Identification of the data extractor; (2) Vehicle Identification Number (VIN); (3) DSSAD type identifier (Type II / Type I) and serial number; (4) Data extraction device serial number; (5) Extract timestamp (UTC); (6) Original data payload; (7) Integrity verification report.

[0061] After encapsulation, it is stored locally with encryption.

[0062] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the DSSAD data extraction method described above.

[0063] This invention also provides a computer device, including a memory and a processor. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the DSSAD data extraction method described above.

[0064] This invention also provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the steps of the DSSAD data extraction method described above.

[0065] It is understood that the system, device and storage medium provided in the embodiments of the present invention correspond to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above DSSAD data extraction method.

[0066] It should be noted that those skilled in the art will understand that all or part of the steps implemented in the embodiments of the present invention can be implemented entirely or partially by software, hardware, firmware, or any combination thereof. When implemented in hardware, it can be implemented entirely or partially by purchasing standard parts or modifications. When implemented in software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid state disks (SSDs)).

[0067] In summary, this invention addresses the technical challenges of existing DSSAD data extraction methods, such as strict access control, different data organization modes, and varying degrees of physical damage or power supply abnormalities in accident vehicles. It provides a data extraction method for Automated Driving Data Recording Systems (DSSAD), enabling automatic identification of DSSAD types, adaptive permission adjustments, and ensuring data integrity extraction under abnormal operating conditions.

[0068] It should be understood that the examples and embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Those skilled in the art can make various modifications or changes based on them. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. A DSSAD data extraction method, characterized in that, Includes the following steps: S1. After the data extraction device physically connects with the target vehicle, it automatically identifies the diagnostic interface type of the target vehicle in order to establish a communication link between them. S2. On the established diagnostic communication link, the data extraction device sends a DSSAD type detection command to the vehicle bus, analyzes the response of the target vehicle to determine whether there is an event-triggered system or a continuous recording system, and extracts data according to the DSSAD type. S3. During the data extraction process, synchronously detect whether the system corresponding to the current DSSAD type has set read permission restrictions; S4. Perform systematic integrity checks on all extracted raw data, and implement automatic recovery when an anomaly is detected. Package the valid data that passes the integrity check in a unified format to complete the data extraction. In step S2, the analysis process of the data extraction device on the target vehicle's response includes: S2.1 If a response indicating support for continuous recording mode is received, it is determined that the current vehicle is equipped with a continuous recording system. Then, the DSSAD data extraction process of the continuous recording system is executed, and after the data extraction is completed, the detection and data extraction of the event-triggered system are continued. S2.2 If the received response indicates that continuous recording mode is not supported, or if a valid response containing continuous recording features is not received within the timeout period, it is determined that the current vehicle does not have a continuous recording system, and the detection and data extraction of the event-triggered system are directly executed. In S2, the event-triggered system organizes data in discrete events, including timestamp events and time period events. The process of detecting the existence of the event-triggered system includes: S2.3 If a response indicating support for event-triggered mode is received, it is determined that an event-triggered system exists; S2.4 If no valid response is received, or if the response explicitly indicates that the event-triggered mode is not supported, then it is determined that there is no event-triggered system.

2. The DSSAD data extraction method as described in claim 1, characterized in that, In step S1, after establishing a physical connection, the data extraction device automatically initiates an interface type detection process, including: S1.1 The data extraction device sends a test activation command conforming to the vehicle diagnostic standard to the diagnostic interface, and automatically determines the communication link type supported by the current vehicle based on the response characteristics of the target vehicle's diagnostic interface: S1.1.1 If a diagnostic response message based on the Controller Area Network bus is received within the predetermined timeout period, it is determined that the current vehicle uses the CAN bus diagnostic interface, and subsequent communication will be based on the CAN transmission protocol. S1.1.2 If an Ethernet-based diagnostic response message is received, it is determined that the current vehicle uses the Ethernet diagnostic interface, and subsequent communication will use the Ethernet physical layer and transport layer protocols. S1.2 When the target vehicle is determined to have an Ethernet diagnostic interface, a communication session is established according to the Ethernet diagnostic communication protocol specification: S1.2.1 Port Negotiation and Binding: The data extraction device opens a dynamic port locally and sends a connection request to the diagnostic interface address of the target vehicle; S1.2.2 Vehicle Declaration Acquisition: After the connection is established, the target vehicle actively broadcasts or responds to the request, sending its own vehicle identification information. The data extraction device receives and parses the vehicle identification information for subsequent identity association and evidence encapsulation. S1.2.3, Route Activation: The data extraction device sends a route activation request based on the received and parsed vehicle identification information. The target vehicle verifies the request and returns a route activation confirmation message after successful verification. S1.2.4 Transmission Parameter Negotiation: To ensure communication efficiency and stability, the data extraction device and the target vehicle exchange their respective transmission layer parameters; S1.3 When it is determined that the target vehicle is conducting diagnostic communication based on the Controller Area Network (CAN) bus, the adapter mode is adopted: the data extraction device automatically activates the internal protocol conversion module to convert the Ethernet diagnostic communication protocol request into a CAN bus request, and re-encapsulates the CAN response of the target vehicle into an Ethernet diagnostic message format, so that the upper-layer DSSAD extraction logic does not need to be aware of the differences in the underlying physical link. S1.4 After the communication link is successfully established, the data extraction device periodically sends a keep-alive command to prevent the vehicle diagnostic network from automatically disconnecting due to timeout.

3. The DSSAD data extraction method as described in claim 1, characterized in that, In step S2, the continuous recording system organizes data into continuous time series. The data storage is divided into multiple consecutive storage spaces, each with a unique data number associated with a segment of continuous time series data. The DSSAD data extraction process of the continuous recording system includes: S2.a.1 Detect the list of data numbers stored in the continuous recording system; A data number index retrieval instruction is sent to the continuous recording system. This instruction does not include any time or range parameters, but only requests the system to return all data numbers stored internally. After receiving the instruction, the continuous recording system traverses its storage medium, organizes the numbers of all valid storage spaces into a list according to the order of storage time, and returns it to the data retrieval device. In addition to a unique identifier, each data number also includes the start timestamp and end timestamp corresponding to the storage space. The data retrieval device temporarily stores the above information. S2.a.2, Return a list of data numbers for selection; The data extraction device displays the received data number list and its corresponding time range in chronological order on the operation interface. Based on the estimated time of the accident, select one or more data numbers that best match the accident time from the list. If no selection is made manually, the data number containing the accident time point will be automatically selected. S2.a.

3. Extract the corresponding set of consecutive records based on the selected data number; The data extraction device sends a data reading instruction by number to the continuous recording system. The instruction parameter is one or more selected data numbers. After receiving the instruction, the continuous recording system locates the starting address of the storage space corresponding to each data number and reads all the data in the storage space continuously. The data extraction device organizes the read data into a continuous binary data stream and temporarily stores it in the internal cache. S2.a.4, Merging of multiple data numbers; If multiple consecutive data numbers are selected, the data extraction device will stitch the multiple storage spaces into a complete, seamless time-series data set in chronological order. During stitching, it checks whether the timestamps of two consecutive storage spaces are continuous. If there are small gaps, linear interpolation is used to fill them in. If the gaps are too large, they are marked as missing data areas.

4. The DSSAD data extraction method as described in claim 1, characterized in that, In step S2, for event-triggered systems, data is extracted according to a strategy of first selecting a time range and then checking if a value exists. The process includes: S2.b.1 Select the time range of the accident point; Based on the known or estimated time of the accident, a time window for data to be extracted is set, which is defined by two parameters: start time and end time. S2.b.2 Detect whether there is valid data in the selected time range of the event-triggered system; The data extraction device sends an instruction to the event-triggered system to query the existence of events by time range. The instruction carries the start time and end time set in S2.b.

1. The event-triggered system internally compares the trigger timestamps of each event to quickly determine whether at least one event's timestamp falls within the window. S2.b.3 Extract the set of timestamp event data and the single timestamp event frame data object within the event range; The event-triggered system extracts the data of all timestamp events within the time window and organizes them into a data set in chronological order. For each timestamp event, the following data is extracted: the basic metadata of the event, the data set of a single timestamp event, and the single frame data object corresponding to the event. All extracted event data are arranged in ascending order according to the event trigger timestamp and stored in the temporary buffer of the data extraction device.

5. The DSSAD data extraction method as described in claim 1, characterized in that, In step S3, the read permission detection method involves sending a standard read command and then analyzing the system response code corresponding to the DSSAD type. If normal data is returned, it is determined that no additional permission is required, and the original extraction process continues. If an error code such as "Access Denied" or "Insufficient Permissions" is returned, it is determined that authorization credentials are required. At this time, the data extraction device automatically calls the built-in authorization service interface and initiates a credential request to the authorization server through a pre-established secure channel. After the authorization server verifies the credentials, it returns a time-sensitive device-level access credential. After obtaining the credential, the data extraction device attaches it to the read command and resends it. The system corresponding to the DSSAD type verifies the validity of the credential and grants data read permissions.

6. The DSSAD data extraction method as described in claim 1, characterized in that, In step S4, the integrity verification process for the extracted raw data includes: S4.1, Length and continuity dual verification; Length check: The effective payload length of all received data frames is accumulated and compared with the total effective length of the first frame. If they are equal, the length check passes; otherwise, the data is considered incomplete. Frame sequence number continuity check: Check frame by frame whether the frame sequence number is strictly increasing and without missing. If all frame sequence numbers are consecutive, the continuity check passes. If sequence number jumps, repetitions, or premature termination are found, it is determined that there is frame loss or transmission interruption. S4.2 For cases where continuity verification fails, dynamic flow control adjustments are made, including reducing the number of frames requested by a single data extraction command, extending the interval between two consecutive requests, and resending the same data extraction command to the system corresponding to the DSSAD type. S4.3 For scenarios where multiple reads are incomplete but different segments are lost, redundant data fusion is performed. This involves aligning the data frames read each time according to their frame numbers before performing the fusion operation, including: For each frame sequence number, select one from the frames that appear in at least two reads, prioritizing the copy with the correct checksum. If a frame number does not appear in all reads, it is marked as permanently missing and noted in the final evidence; S4.4, dual consistency check; After a successful read, the data extraction device immediately executes the exact same data extraction command again to obtain a second, independently read data. The data obtained in the first read is then compared byte by byte with the data obtained in the second read. If the two sets of data are exactly the same, the data consistency is deemed valid and the evidence is credible. If any discrepancies exist, the retransmission mechanism is triggered, the cached data is cleared, and two new independent reads are performed again. If the discrepancies are still not consistent after three rounds, the data with the largest discrepancy between the two reads, along with the discrepancy description, is retained and marked.

7. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, causes the processor to perform the steps of the DSSAD data extraction method as described in any one of claims 1-6.

8. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the DSSAD data extraction method as described in any one of claims 1-6.

Citation Information

Patent Citations

  • Automatic driving data recording method and device, electronic equipment and storage medium

    CN117854175A

  • Vehicle data processing system and method

    CN121547466A

  • Automatic driving record data extraction and analysis system and method

    CN122024350A