Data backtracking method and device, storage medium and program product

Abstract

The invention provides a data backtracking method and device, a storage medium and a program product. The method comprises the steps that CAN data of a vehicle and middleware data generated when service logic is executed through the CAN data are collected and stored; if the execution process of the service logic is abnormal, performing backtracking analysis on the execution process of the service logic according to the service logic, the CAN data and the middleware data to obtain a backtracking result; and analyzing the backtracking result according to a preset rule, and determining a reason for abnormality in the execution process of the service logic. According to the embodiment of the invention, by collecting and storing the CAN data in real time and the middleware data generated when the CAN data is used for executing the business logic, backtracking analysis can be directly carried out according to the reliable CAN data and the middleware data, and the efficiency and accuracy of business logic anomaly analysis are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and specifically to a data backtracking method, device, storage medium, and program product. Background Technology

[0002] With the rapid development of vehicle networking technology, remote real-time monitoring, fault diagnosis, and data management of vehicles have become crucial for ensuring vehicle operation safety and improving maintenance efficiency.

[0003] In practical applications, the in-vehicle remote processing terminal (such as TBox) acts as a bridge between the vehicle and the cloud platform. It is responsible for collecting the vehicle's underlying operating data through the Controller Area Network (CAN) protocol and transmitting it to the Remote Telemetry Monitoring (RTM) platform via a wireless communication module. The RTM platform is then responsible for performing business logic processing on the collected CAN data (such as parsing, processing, storing, and forwarding) to achieve functions such as vehicle status monitoring, fault warning, and remote diagnostics.

[0004] In related technologies, when anomalies such as message loss, unidentified alarms, or data parsing failures occur during monitoring, it is usually necessary to filter the CAN data of the target vehicle from historical logs to verify the completeness and validity of the data collection. Simultaneously, it is also necessary to retrieve the middleware data used by the monitoring platform to execute business logic using the CAN data in order to accurately determine the cause of the anomaly. However, middleware data is continuously updated during business logic execution. When a business logic is completed, the middleware data corresponding to the CAN data that triggered that logic may have been overwritten by subsequent business requests. Therefore, anomaly analysis can only rely on reverse engineering the middleware data, which has low reliability and severely impacts the accuracy and efficiency of anomaly analysis.

[0005] It should be noted that the information disclosed in the background section of this application is intended only to enhance the understanding of the general background of this application, and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] This application provides a data backtracking method, device, storage medium, and program product to help solve the problem of low accuracy and efficiency in business logic anomaly analysis caused by the lack of reliable middleware data in the prior art.

[0007] In a first aspect, embodiments of this application provide a data backtracking method, including: Collect and store the vehicle's CAN data and the middleware data generated when using the CAN data to execute business logic; If an anomaly occurs during the execution of the business logic, a backtracking analysis is performed on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain the backtracking results. The backtracking results are analyzed according to preset rules to determine the reasons for the abnormality in the execution process of the business logic.

[0008] In one possible implementation, The data structure of the CAN data includes a vehicle identification field, a timestamp field, and a data content field; The middleware data structure includes a vehicle identification field, a timestamp field, and a data content field.

[0009] In one possible implementation, the step of performing backtracking analysis on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain backtracking results includes: Obtain the list of logical entities corresponding to the business logic, as well as the middleware access entity and variable entity corresponding to each logical entity in the list of logical entities; Based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list, the CAN data, and the middleware data, the execution process of the business logic is backtracked and analyzed to obtain the backtracking results.

[0010] In one possible implementation, obtaining the list of logical entities corresponding to the business logic includes: Obtain the first logical entity corresponding to the business logic; The second logical entity is determined based on the preceding relationship of the first logical entity; The first logical entity and the second logical entity are combined to obtain a list of logical entities corresponding to the business logic.

[0011] In one possible implementation, obtaining the middleware access entity and variable entity corresponding to each logical entity in the logical entity list includes: Based on the dependencies of each logical entity in the logical entity list, obtain the middleware access entity and variable entity corresponding to each logical entity in the logical entity list; Based on the inclusion relationship of each logical entity in the logical entity list, obtain the variable entity corresponding to each logical entity in the logical entity list.

[0012] In one possible implementation, the step of performing backtracking analysis on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain backtracking results includes: A backtracking script is generated based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list; The backtracking script is filled in based on the CAN data and the middleware data to generate an executable backtracking script; Run the executable backtracking script to obtain the backtracking results.

[0013] In one possible implementation, the step of analyzing the backtracking results according to preset rules to determine the cause of the abnormality in the execution process of the business logic includes: The backtracking results are input into a large language model, which analyzes the backtracking results according to the preset rules and outputs the reason for the abnormality in the execution process of the business logic.

[0014] Secondly, embodiments of this application provide an electronic device, including: processor; Memory; And a computer program, wherein the computer program is stored in the memory, and when the computer program is executed by the processor, causes the electronic device to perform the method described in any one of the first aspects.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0016] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0017] Compared with existing technologies, the embodiments of this application, by collecting and storing CAN data in real time and middleware data generated when executing business logic using CAN data, can directly perform backtracking analysis based on reliable CAN data and middleware data, which significantly improves the efficiency and accuracy of business logic anomaly analysis. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a data backtracking method provided in an embodiment of this application; Figure 2 A schematic diagram illustrating a process for acquiring and storing CAN data and middleware data, provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for determining backtracking results provided in an embodiment of this application; Figure 4 A flowchart illustrating a method for obtaining a list of logical entities provided in an embodiment of this application; Figure 5 An entity relationship diagram provided for an embodiment of this application; Figure 6 A flowchart illustrating another method for determining backtracking results provided in an embodiment of this application; Figure 7 A flowchart illustrating another data backtracking method provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0021] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0023] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] The in-vehicle remote processing terminal (such as TBox) acts as a bridge between the vehicle and the cloud platform. It is responsible for collecting underlying vehicle operating data via the Controller Area Network (CAN) protocol. This data includes key information such as powertrain parameters (e.g., engine speed, battery status), chassis control data (e.g., vehicle speed, braking status), and fault alarm signals. After collection, the TBox transmits the data to the Remote Telemetry Monitoring (RTM) platform via a wireless communication module. The RTM platform is responsible for performing business logic processing on the collected CAN data (e.g., parsing, processing, and storage) to achieve functions such as vehicle status monitoring, fault warning, and remote diagnostics. Ultimately, it generates monitoring messages that conform to industry standards (e.g., GB / T 32960), which can be further forwarded to nodes such as the vehicle manufacturer's maintenance backend to achieve real-time monitoring of vehicle status.

[0025] In related technologies, when anomalies such as message loss, unidentified alarms, or data parsing failures occur during monitoring, it is typically necessary to filter the CAN data of the target vehicle from historical logs to verify the completeness and validity of the data collection. Simultaneously, it is also necessary to retrieve middleware data from the monitoring platform when executing business logic using CAN data, such as TBox acquisition success rate, cache status, communication module signal strength, transmission retransmission count, RTM platform decoding success rate, error codes, and write status of storage components (such as MySQL, Redis, and MongoDB). Only by simultaneously analyzing the CAN data and the associated middleware data can the accuracy of anomaly analysis in the business logic execution process be guaranteed.

[0026] However, some middleware used by RTM platforms (such as Redis) are designed to achieve high-concurrency, low-latency data processing. This characteristic means that the data stored internally is dynamic and constantly being overwritten. When a business logic is completed, the middleware data corresponding to the CAN data that triggered that business logic may have already been updated or cleared by thousands of other business requests.

[0027] In simple terms, middleware data is constantly updated during the execution of business logic. When a business logic completes, the middleware data corresponding to the CAN data that triggered that logic may have been overwritten by subsequent business requests. During anomaly analysis, the only recourse is to infer the middleware data—that is, to deduce the data that might have existed in the middleware at that time based on the existing business logic code and the final result. However, the reliability of this process cannot be guaranteed, and it is time-consuming, severely impacting the accuracy and efficiency of anomaly analysis.

[0028] To address the aforementioned issues, this application provides a data backtracking method. By collecting and storing CAN data and associated middleware data in real time, backtracking analysis can be performed directly based on reliable CAN data and middleware data, significantly improving the efficiency and accuracy of business logic anomaly analysis.

[0029] See Figure 1 This is a flowchart illustrating a data backtracking method provided in an embodiment of this application. Figure 1 As shown, the method specifically includes the following steps.

[0030] Step S101: Collect and store the vehicle's CAN data and the middleware data generated when using the CAN data to execute business logic.

[0031] In this embodiment, CAN data is typically uploaded from the vehicle-mounted TBox to the RTM platform. The RTM platform receives the CAN data and can therefore store it directly upon reception. To avoid delays, storage can be completed within a first preset time (e.g., 100ms) after RTM reception is complete. Middleware data, being transient data dynamically generated by the RTM platform when executing business logic using CAN data, cannot be retrieved retrospectively through simple database queries. It can only be actively captured and recorded at a second preset time (e.g., 300ms) after key nodes in the business logic execution (e.g., CAN parsing, national standard data assembly, etc.) to ensure data synchronization with the business logic.

[0032] It should be noted that the RTM platform and TBox described above are merely exemplary descriptions. Those skilled in the art can adjust the monitoring platform and vehicle-mounted intermediate according to actual needs, and the embodiments of this application do not impose specific limitations in this regard.

[0033] One possible implementation involves using Aspect-Oriented Programming (AOP) technology to embed and store middleware data. Specifically, by defining aspects and pointcuts, data probes are embedded in business logic methods. When the business logic executes these methods, the probes are triggered, automatically capturing middleware data and encapsulating it into structured data for storage. This achieves non-intrusive, automated capture of middleware data, providing a data foundation for subsequent backtracking analysis.

[0034] Another possible implementation involves leveraging runtime bytecode enhancement techniques to embed middleware data. Specifically, mechanisms such as Java Agent or .NET Profiling API can be used to dynamically modify the bytecode of business logic classes during application startup or class loading. Without modifying the source code, data capture logic can be inserted before and after specified business logic methods, automatically triggering data recording during method execution. This improves the flexibility of data embedding and storage, enabling the handling of complex scenarios that are difficult to cover with AOP techniques.

[0035] See Figure 2 This is a schematic diagram illustrating a process for collecting and storing CAN data and middleware data, provided in an embodiment of this application. Figure 2 As shown, the system first receives CAN data sent by the vehicle and stores it within 100ms after receiving it. Then, the monitoring platform uses the CAN data to execute business logic. By embedding data points in the business logic methods, the middleware data generated during the execution of the method can be stored.

[0036] In practical applications, after collecting CAN data and middleware data generated when using CAN data to execute business logic, the above data needs to be stored for subsequent analysis when business logic exceptions occur. Therefore, it is necessary to constrain the data format of CAN data and middleware data to provide a data foundation for subsequent rapid retrieval and analysis.

[0037] Therefore, in one possible implementation, the data structure of CAN data includes a vehicle identification field, a timestamp field, and a data content field; the data structure of middleware data includes a vehicle identification field, a timestamp field, and a data content field.

[0038] The vehicle identification field uniquely identifies the vehicle to which the data belongs, and can use the Vehicle Identification Number (VIN) as the vehicle identification field. The timestamp field records the time the data was generated, ensuring alignment of different data on the timeline. Since RTM platforms receive massive amounts of data per unit time, second-level timestamps are typically used to guarantee real-time performance. The data content field stores structured data content. CAN data can contain raw message information, while middleware data can contain operation context information. For example, the data structure for CAN data is (VIN, second-level timestamp, data content (e.g., payload data)), and the data structure for middleware data is (VIN, second-level timestamp, middleware type, data content, service tag).

[0039] Understandably, a unified data structure allows for the association of previously isolated CAN data and middleware data from the perspective of VIN or timestamps, transforming the data into an event sequence with VIN as the spatial dimension and timestamp as the temporal dimension. This provides a solid data foundation for rapid and accurate automated backtracking analysis when business logic anomalies occur.

[0040] Step S102: If an anomaly occurs during the execution of the business logic, a backtracking analysis is performed on the execution process of the business logic based on the business logic, CAN data, and middleware data to obtain the backtracking results.

[0041] In the embodiments of this application, an abnormality in the execution process of business logic refers to the fact that after the RTM platform executes business logic using CAN data, the result or execution process is inconsistent with expectations, causing the system behavior to deviate from the intended function.

[0042] In practical applications, anomalies in the execution of business logic mainly include functional anomalies, process anomalies, and data anomalies. Functional anomalies refer to the failure of business logic to execute correctly, such as missed alarms or false alarms. Process anomalies refer to business logic not following the preset process, such as interrupted data forwarding. Data anomalies refer to unreasonable processed data, such as CAN data parsing errors or inconsistent data states. Therefore, simply relying on CAN data for data backtracking is insufficient; a comprehensive analysis combining CAN data with associated middleware data is also necessary.

[0043] Backtracking analysis refers to associating and aligning anomaly-related CAN data with middleware data to construct an event chain tracing back from the final anomaly result to the CAN data. For example, backtracking analysis can be performed by using a unified vehicle identifier and timestamp to associate the anomaly-causing business logic with CAN data and middleware data.

[0044] During the backtracking analysis, the complete execution flow of the business logic is reconstructed, and CAN data and middleware data are integrated to generate a specific backtracking log as the result of the backtracking analysis. By analyzing the backtracking results, the cause of the anomaly can be located.

[0045] Step S103: Analyze the backtracking results according to preset rules to determine the reasons for the abnormality in the execution process of the business logic.

[0046] After obtaining the backtracking results based on the above steps, the backtracking results can be analyzed using preset rules as a reference, thereby locating the specific abnormal business logic method and determining the cause of the abnormality during the execution of the business logic.

[0047] In this embodiment, by collecting and storing CAN data and associated middleware data in real time, backtracking analysis can be performed directly based on reliable CAN data and middleware data, which significantly improves the efficiency and accuracy of business logic anomaly analysis.

[0048] In related technologies, the analysis of the execution process of business logic is usually performed manually, which leads to low efficiency and a high risk of errors in anomaly analysis. Therefore, to improve the efficiency of backtracking analysis when business logic anomalies occur, a complete and automated business logic analysis process is needed.

[0049] See Figure 3 This is a flowchart illustrating a method for determining backtracking results provided in an embodiment of this application. Figure 3 As shown, the method specifically includes the following steps.

[0050] Step S301: Obtain the list of logical entities corresponding to the business logic, as well as the middleware access entity and variable entity corresponding to each logical entity in the list.

[0051] In this embodiment, the logical entities, middleware access entities, and variable entities associated with the business logic are first obtained. The logical entity refers to the backtracking code execution unit corresponding to the business logic, defining the boundaries and processes of the business function and serving as a major component in backtracking analysis. For example, business logic entities include CAN parsing, national standard data assembly, and login / logout determination. The middleware access entity refers to the interaction process between the business logic and its dependent external data persistence carriers or communication components during execution. For example, middleware access entities include Redis and MongoDB. The variable entity refers to the data unit within the logical entity that carries key status information, reflecting the state of the business logic. For example, variable entities include alarm levels and whether an alarm has been triggered.

[0052] Understandably, since they are entities, they will have corresponding attributes and relationships. For example, the attributes of a logical entity include the logical name, method fragment, and logical description; the attributes of a middleware access entity include the middleware access name and middleware category; and the attributes of a variable entity include the variable name, attention signal, and row number. Furthermore, the middleware access entity and variable entity have corresponding dependencies on the logical entities.

[0053] In practical applications, associated logical entities can be obtained through business logic tags. Since business logic is usually a stage in the execution process, multiple related logical entities within this stage can be obtained, and a list of logical entities can be generated by combining them.

[0054] Furthermore, by traversing each logical entity in the list of logical entities, the relevant variable entities and middleware access entities can be obtained. For example, when a logical entity begins execution, a temporary execution context can be created for it. During the lifetime of this context, all variable accesses and middleware operations that occur will be automatically identified and attributed to this context.

[0055] Step S302: Based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list, the CAN data, and the middleware data, perform a backtracking analysis on the execution process of the business logic to obtain the backtracking results.

[0056] In this embodiment, the process begins with an externally triggered event. Through code call relationships or AOP aspects, the first directly triggered logical entity is identified. Then, starting from this logical entity, all variable entities and middleware access entities directly called by it are collected sequentially along its code execution path. If the logical entity calls the next logical entity during execution, the process continues, traversing the entire call tree recursively or using a depth-first search. Finally, all collected events are combined with CAN data and middleware data in the order they were discovered in the code call chain to generate a backtracking log as the backtracking result. For example, the backtracking result can be a structured report including a timeline, methods, lines of code, variable values, signals, and middleware states.

[0057] In practical applications, after obtaining the logical entities corresponding to the business logic, it is also necessary to obtain a list of logical entities. The order of the elements in the list of logical entities usually affects the final backtracking process, so it is necessary to constrain the process of obtaining the list of logical entities.

[0058] See Figure 4 This is a flowchart illustrating a method for obtaining a list of logical entities provided in an embodiment of this application.

[0059] Step S401: Obtain the first logical entity corresponding to the business logic.

[0060] The first logical entity is the logical entity directly related to the business logic. For example, if the business logic is alarm identification, then the first logical entity is the alarm identification entity.

[0061] Step S402: Determine the second logical entity based on the preceding relationship of the first logical entity.

[0062] In the embodiments of this application, when an anomaly occurs in the execution flow of business logic, the cause can usually be traced back to the execution context of the abnormal logical entity and its preceding logical entity. The logical entities located after the abnormal logical entity obviously have no direct impact on the current logical entity, that is, they do not have a direct causal relationship with the formation of the anomaly, and therefore can be excluded from the scope of backtracking analysis.

[0063] Step S403: Combine the first logical entity and the second logical entity to obtain a list of logical entities corresponding to the business logic.

[0064] In practical applications, since the execution of business logic is ordered, logical entities can be combined based on the order to generate a list of logical entities that can represent the execution sequence of the logical entities.

[0065] Similarly, the process of determining the corresponding variable entities and middleware access entities based on the logical entity list also needs to be constrained.

[0066] In this embodiment of the application, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list are obtained according to the dependency relationship of each logical entity in the logical entity list.

[0067] As is understandable, the middleware access entity is usually a behavioral characteristic of a logical entity. It defines the interaction method between the logical entity and the middleware. Therefore, the middleware access entity can be obtained directly based on the dependency relationship of the logical entity, thus obtaining the middleware access entity quickly and accurately.

[0068] In this embodiment of the application, the variable entity corresponding to each logical entity in the logical entity list is obtained according to the inclusion relationship of each logical entity in the logical entity list.

[0069] As is understandable, variable entities are typically the internal states of logical entities, reflecting data changes during execution and serving as the core basis for business logic judgments and flows. Therefore, the corresponding variable entities can be obtained based on the inclusion relationships of logical entities, thus enabling quick and accurate retrieval of variable entities.

[0070] To facilitate understanding of the relationships between entities, the following explanation will be provided in conjunction with specific examples.

[0071] See Figure 5 This is an entity relationship diagram provided in an embodiment of this application. Figure 5 As shown in the figure, the relationship between logical entities, variable entities, and middleware access entities is illustrated.

[0072] It should be noted that "the previous step" in the diagram refers to the preceding relationship mentioned above.

[0073] Assuming the first logical entity corresponding to the business logic is alarm identification, then the list of logical entities includes alarm identification and all preceding logical entities. Specifically, it includes ["Alarm Identification", "Real-time Reissue Identification", "Login / Logout Identification", "National Standard Data Assembly", "CAN Parsing", "CAN Query"]. Among these, the variable entities corresponding to alarm identification are alarm level and whether an alarm has been triggered; the middleware entity corresponding to alarm identification is Redis; the middleware access entities corresponding to real-time reissue identification are MongoDB and Redis; and the middleware access entity corresponding to login / logout identification is Redis.

[0074] Understandably, by using preset entity relationships, logical entities, variable entities, and middleware access entities can be automatically retrieved based on different relationships, significantly improving the efficiency of anomaly analysis. Furthermore, entity relationships can be modified according to scenario requirements, thereby achieving flexible adaptation to different business scenarios and system architectures, solving the data traceability problem that developers cannot solve under multiple heterogeneous data sources and large volumes of data.

[0075] In practical applications, the powerful code generation capabilities of large language models can be leveraged to automatically generate the relevant code for the logical entities, variable entities, and middleware access entities based on preset prompt word templates, thereby enabling the rapid construction of backtracking analysis models.

[0076] See Figure 6 This is a flowchart illustrating another method for determining backtracking results provided in an embodiment of this application. Figure 6 As shown, the method specifically includes the following steps.

[0077] Step S601: Generate a backtracking script based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list.

[0078] In this embodiment, the generated backtracking script is not a final executable file, but a backtracking script that defines the execution logic. Based on the list of logical entities, the overall execution flow of the script (such as the corresponding code) is constructed. The variable entity corresponding to each logical entity can be declared as a variable to be assigned a value in the script; its corresponding middleware access entity is converted into a call to the simulated interface, and the call parameters are set as the parameters to be filled. Therefore, step S601 does not directly generate an executable script, but rather provides the foundation for subsequent middleware data and CAN data filling.

[0079] Of course, those skilled in the art can also directly populate the middleware access entity and variable entity with data, and this application does not impose specific restrictions on this.

[0080] Step S602: Fill the backtracking script with CAN data and middleware data to generate an executable backtracking script.

[0081] In this embodiment, middleware data is filled into the corresponding middleware access entity parameters, and CAN data is also filled in, thereby generating an executable script based on the backtracking script. That is, the static template that originally only defined the execution logic is instantiated into a script that carries complete context information and can run independently.

[0082] Step S603: Run the executable backtracking script to obtain the backtracking results.

[0083] In the steps above, an executable backtracking script has been generated. Therefore, in this step, simply running the executable script will yield the backtracking results (such as a backtracking log). During execution, the script will strictly follow the preset logical order, using the filled data for interaction and calculation, and finally output the backtracking results (such as a backtracking log containing complete state transitions and interaction details).

[0084] In this embodiment, a backtracking script is first generated based on the logical entity, middleware access entity, and variable entity. Then, the backtracking script is populated with middleware data and CAN data to generate an executable backtracking script. Running the script yields the backtracking results. By proceduralizing the backtracking analysis results, the reliability of the backtracking results is effectively improved. Automated execution of the backtracking analysis significantly improves execution efficiency.

[0085] In practical applications, after obtaining the backtracking results, it is also necessary to analyze the backtracking results according to preset rules in order to obtain the reason for the abnormality in the business logic.

[0086] In one possible implementation, to improve the efficiency of the analysis, the backtracking results are input into a large language model. The large language model analyzes the backtracking results according to preset rules and outputs the reasons for the abnormality in the execution process of the business logic.

[0087] Understandably, relying on the powerful semantic understanding capabilities of the large language model and using preset rules as a reference, it is possible to quickly and accurately determine the reasons for anomalies in the execution process of business logic.

[0088] To better illustrate the data backtracking process, we will now explain it using specific examples.

[0089] See Figure 7 This is a flowchart illustrating another data backtracking method provided in an embodiment of this application.

[0090] like Figure 7 As shown, firstly, based on the business logic where the anomaly occurred, the vehicle identification number of the data is determined to be LSV1EDZB1SN000562, with a timestamp from 13:00:00 on 2025-10-10 to 14:00:00 on 2025-10-10, and the business logic tag is alarm identification. Next, the corresponding logical entity is queried based on "alarm identification", and the logical entity list is found based on the "previous step" relationship (i.e., the preceding relationship mentioned above) ["real-time reissue identification", "login / logout identification", "national standard data assembly", "CAN parsing", "CAN query"].

[0091] Based on this, the logical entity list is traversed, and the middleware access entity associated with each logical entity is found according to the "dependency" relationship. For example, alarm recognition depends on the "redis" middleware access entity. Code snippets are generated based on the attributes (keywords) of the middleware access entity. The oldest data in the middleware data range from 2025-10-10 13:00:00 to 2025-10-10 14:00:00 is found as the initial value to populate the middleware entity. Then, the logical entity list is traversed, and the variable entity associated with each logical entity is found according to the "inclusion" relationship. For example, alarm recognition includes ["whether an alarm is triggered", "alarm level"]. In the code snippet of "alarm recognition", monitoring of variables and log output are added through code enhancement, starting with a method and ending with a method.

[0092] Finally, the logical entities are assembled into an executable script based on their order of appearance. After execution, a backtracking log is generated. For example, the backtracking log is shown below: {“CAN parsing”:{“Start”:[“WaC3QU1RnH7wZCEhJYLA9JebhAkOz”],“End”:[{“singleA”:“1”,“singleB”:“20”}]}} {“National Standard Data Assembly”:{“Start”:[{“singleA”:“0”,“singleB”:“20”}],“End”:[“232302FE190223FB”]}} {"Alarm Identification":{"Start":[{"singleA":"0","singleB":"20"}","232302FE190223FB"]","After the fourth line is executed":[{"Alarm Level":0","Whether to Alarm":"false","Cache Status":"false"}]}}.

[0093] Based on the aforementioned backtracking logs, the flow and evolution of data can be clearly tracked. For example, the end state of "CAN parsing" ({"singleA":"1","singleB":"20"}) becomes the input basis for subsequent logical entities.

[0094] Furthermore, by traversing the backtracking log, a preset rule mapping table can be queried based on the logical name in each record, and the output of that record is passed to the corresponding verification script for verification. For example, the correspondence between logical names, rule names, and verification scripts is as follows: "CAN parsing", "signal parsing rule", "funcationdecode()"; "login / logout identification", "login rule", "funcationlogin()"; "alarm identification", "alarm level 1 rule", "funcationlevel1()". By automatically comparing the actual data in the log with the expected results, this embodiment improves the accuracy of anomaly location from the traditional method level to the line-of-code level.

[0095] Taking "alarm recognition" as an example, if the verification script `funcationlevel1()` returns `{result:false,singleA:"0"}` after execution, it indicates that the actual output does not match the expected rules. Based on the execution result of the verification script, it can be determined that there is an error in the uploading process of the `singleA` signal, thus identifying the cause of the abnormality in the execution process of the business logic.

[0096] Corresponding to the above embodiments, this application also provides an electronic device.

[0097] See Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8As shown, the electronic device 800 may include a processor 801, a memory 802, and a communication unit 803. These components communicate via one or more buses. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the embodiments of this application. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0098] The communication unit 803 is used to establish a communication channel, thereby enabling the electronic device to communicate with other devices.

[0099] The processor 801 serves as the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 802, and calls data stored in the memory to perform various functions and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 801 may consist only of a central processing unit (CPU). In this embodiment, the CPU may have a single processing core or include multiple processing cores.

[0100] Memory 802 is used to store the execution instructions of processor 801. Memory 802 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0101] When the execution instructions in memory 802 are executed by processor 801, the electronic device 800 is able to perform some or all of the steps in the above method embodiments.

[0102] Corresponding to the above embodiments, this application also provides a computer-readable storage medium, wherein the computer-readable storage medium may store a program, wherein when the program runs, it can control the device where the computer-readable storage medium is located to execute some or all of the steps in the above method embodiments. In specific implementation, the computer-readable storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0103] Corresponding to the above embodiments, this application also provides a computer program product containing executable instructions that, when executed on a computer, cause the computer to perform some or all of the steps in the above method embodiments.

[0104] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0105] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0107] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A data backtracking method, characterized in that, include: Collect and store the vehicle's CAN data and the middleware data generated when using the CAN data to execute business logic; If an anomaly occurs during the execution of the business logic, a backtracking analysis is performed on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain the backtracking results. The backtracking results are analyzed according to preset rules to determine the reasons for the abnormality in the execution process of the business logic.

2. The method according to claim 1, characterized in that, The data structure of the CAN data includes a vehicle identification field, a timestamp field, and a data content field; The middleware data structure includes a vehicle identification field, a timestamp field, and a data content field.

3. The method according to claim 1, characterized in that, The step of performing backtracking analysis on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain backtracking results includes: Obtain the list of logical entities corresponding to the business logic, as well as the middleware access entity and variable entity corresponding to each logical entity in the list of logical entities; Based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list, the CAN data, and the middleware data, the execution process of the business logic is backtracked and analyzed to obtain the backtracking results.

4. The method according to claim 3, characterized in that, The step of obtaining the list of logical entities corresponding to the business logic includes: Obtain the first logical entity corresponding to the business logic; The second logical entity is determined based on the preceding relationship of the first logical entity; The first logical entity and the second logical entity are combined to obtain a list of logical entities corresponding to the business logic.

5. The method according to claim 3, characterized in that, Retrieving the middleware access entity and variable entity corresponding to each logical entity in the logical entity list, including: Based on the dependencies of each logical entity in the logical entity list, obtain the middleware access entity and variable entity corresponding to each logical entity in the logical entity list; Based on the inclusion relationship of each logical entity in the logical entity list, obtain the variable entity corresponding to each logical entity in the logical entity list.

6. The method according to claim 3, characterized in that, The step of performing backtracking analysis on the execution process of the business logic based on the business logic, the CAN data, and the middleware data to obtain backtracking results includes: A backtracking script is generated based on the logical entity list, the middleware access entity and variable entity corresponding to each logical entity in the logical entity list; The backtracking script is filled in based on the CAN data and the middleware data to generate an executable backtracking script; Run the executable backtracking script to obtain the backtracking results.

7. The method according to claim 1, characterized in that, The step of analyzing the backtracking results according to preset rules to determine the cause of the abnormality in the execution process of the business logic includes: The backtracking results are input into a large language model, which analyzes the backtracking results according to the preset rules and outputs the reason for the abnormality in the execution process of the business logic.

8. An electronic device, characterized in that, include: processor; Memory; And a computer program, wherein the computer program is stored in the memory, and when the computer program is executed by the processor, causes the electronic device to perform the method of any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 7.

Images