Method for processing vehicle fault log data and related device

Abstract

This application discloses a method and related equipment for processing vehicle fault log data. The method includes: acquiring vehicle fault log data and performing standardized preprocessing on the vehicle fault log data to generate a structured log dataset; parsing a preset signal matrix file to extract metadata of each vehicle communication signal and generating a signal metadata database; based on the signal metadata database, filtering log records including vehicle communication protocol messages from the log dataset, wherein the vehicle communication protocol messages include payload data; performing service matching and signal decoding on the vehicle communication protocol messages to convert the original signal values ​​in the payload data into physical values ​​with business semantics, generating a signal time series dataset; and based on the signal time series dataset, extracting signal state change points for time series visualization. The technical solution provided by this application can improve the analysis efficiency of vehicle fault log data.

Description

Technical Field

[0001] The present application belongs to the technical field of vehicle and log data processing thereof, and in particular relates to a processing method for vehicle fault log data and related equipment. Background Art

[0002] With the rapid evolution of automotive electronic architecture towards domain-centric integration, the body domain integrates dozens of electronic control unit nodes including lights, seats, doors and windows, windscreen wipers, air conditioners, etc. The richness and intelligence level of vehicle functions continue to improve, which can provide users with a more complete driving experience. However, the exponential increase in vehicle function complexity also greatly increases the difficulty of fault diagnosis. At present, the troubleshooting of body domain function faults mainly relies on vehicle fault log data output by each electronic control unit. Functional status signals are mostly encapsulated in in-vehicle communication protocol messages. Existing analysis tools can only implement basic log format conversion, which requires engineers to manually compare the signal matrix to screen messages line by line, decode signals and check status, which not only has extremely low analysis efficiency and high labor cost, but also has problems such as high adaptation cost for new models and lack of visual linkage analysis capability, making it difficult to meet the demand for rapid fault location of mass-produced vehicles.

[0003] Based on this, how to improve the analysis efficiency of vehicle fault log data has become an urgent technical problem to be solved. Summary of the Invention

[0004] Embodiments of the present application provide a processing method, an apparatus, a computer program product, a computer-readable storage medium and an electronic device for vehicle fault log data, which can at least improve the analysis efficiency of vehicle fault log data to a certain extent.

[0005] Other features and advantages of the present application will become apparent from the following detailed description, or may be partially learned through practice of the present application.

[0006] According to a first aspect of embodiments of the present application, there is provided a processing method for vehicle fault log data, the method comprising: acquiring vehicle fault log data, and performing standardized preprocessing on the vehicle fault log data to generate a structured log data set; parsing a preset signal matrix file to extract metadata of each in-vehicle communication signal, and generating a signal metadata database; based on the signal metadata database, screening log records including in-vehicle communication protocol messages from the log data set, wherein the in-vehicle communication protocol messages include payload data; performing service matching and signal decoding on the in-vehicle communication protocol messages, so as to convert original signal values in the payload data into physical values with business semantics, and generate a signal time series data set; based on the signal time series data set, extracting signal state change points for time-series visual display.

[0007] In some embodiments of this application, based on the aforementioned scheme, obtaining vehicle fault log data includes: establishing a secure connection from the vehicle network service platform and pulling the corresponding vehicle fault log compressed package according to the vehicle identification code and fault time interval, decompressing and storing the package after completing the breakpoint resume and integrity verification to obtain the vehicle fault log data; or, importing local vehicle fault log files or compressed packages, performing integrity verification and deduplication before storing the package to obtain the vehicle fault log data.

[0008] In some embodiments of this application, based on the foregoing scheme, the standardization preprocessing of the vehicle fault log data to generate a structured log dataset includes: synchronizing and parsing the vehicle fault log data according to diagnostic log and tracking standards to extract the timestamp, electronic control unit identifier, application identifier, context identifier, log level, and payload data of each log record, and filtering invalid log records; and performing timeline alignment and ascending sorting of the log records of multiple electronic control units to generate the structured log dataset.

[0009] In some embodiments of this application, based on the aforementioned scheme, the step of parsing a preset signal matrix file to extract metadata of each vehicle communication signal and generating a signal metadata database includes: parsing the signal matrix file to extract metadata of vehicle communication services, events, and signals, wherein the metadata includes signal identifier, signal name, start bit, length, data type, precision, offset, electronic control unit to which it belongs, value range, and enumerated value; performing legality verification on the metadata to mark signals with duplicate identifiers, bit width overflow, or abnormal value range and generating alarm information; and managing the verified metadata by vehicle model and electronic control unit version to generate the signal metadata database.

[0010] In some embodiments of this application, based on the foregoing scheme, the service matching and signal decoding of the vehicle communication protocol message includes: identifying and filtering log records containing the vehicle communication protocol message from the log dataset; extracting the service identifier and event identifier from the message header of the vehicle communication protocol message to match it with the service and signal definitions in the signal metadata database; and parsing the payload data bit by bit according to the start bit, length, and data type in the matched metadata to extract the original signal value.

[0011] In some embodiments of this application, based on the foregoing scheme, the step of converting the original signal values ​​in the payload data into physical values ​​with business semantics to generate a signal time series dataset includes: converting the original signal values ​​into physical values ​​with business semantics according to the precision, offset, and enumeration values ​​in the metadata; establishing a full-link mapping relationship for each log record, including log record, signal instance, physical value, and timestamp, to generate the signal time series dataset, and marking abnormal signal values ​​that exceed the value range.

[0012] In some embodiments of this application, based on the foregoing scheme, the step of extracting signal state change points based on the signal time series dataset includes: processing the signal time series dataset according to the time axis to extract the numerical jump points of the same vehicle communication signal; filtering out duplicate and unchanged data, and recording the timestamp, value before change, value after change and corresponding log identifier of each change point to generate a signal state change event set.

[0013] In some embodiments of this application, based on the foregoing scheme, the method further includes: establishing a hierarchical structure of vehicle body domain functional modules, wherein the vehicle body domain functional modules include main modules and sub-modules; filtering target vehicle communication signals from the signal element database by tags, electronic control units, or keywords; binding the target vehicle communication signals to the corresponding vehicle body domain functional modules, and configuring the display alias, unit, alarm threshold, and display style of the target vehicle communication signals to generate a functional signal binding relationship table; and saving the configured vehicle body domain functional modules and signal binding relationships as a reusable analysis template.

[0014] In some embodiments of this application, based on the aforementioned scheme, the timing visualization display includes: loading all vehicle communication signals bound to the target functional module according to the functional signal binding relationship table; displaying switch-type signals using a ladder diagram with time as the horizontal axis and signal physical value as the vertical axis, and displaying analog signals using a line graph; overlaying and rendering the timing change curves of multiple vehicle communication signals in the same visualization view, configuring independent vertical axis scales for each vehicle communication signal, and distinguishing the timing change curves of each vehicle communication signal using different colors; establishing a bidirectional association between signal change points and original log records, and displaying the corresponding original log record content when a signal change point is selected in the visualization view; and locating and marking the time position of the corresponding signal in the visualization view when a log record is selected in the original log list.

[0015] According to a second aspect of the embodiments of this application, a vehicle fault log data processing apparatus is provided. The apparatus includes: an acquisition unit, configured to acquire vehicle fault log data and perform standardized preprocessing on the vehicle fault log data to generate a structured log dataset; a parsing unit, configured to parse a preset signal matrix file to extract metadata of each vehicle communication signal and generate a signal metadata database; a filtering unit, configured to filter log records including vehicle communication protocol messages from the log dataset based on the signal metadata database, wherein the vehicle communication protocol messages include payload data; a conversion unit, configured to perform service matching and signal decoding on the vehicle communication protocol messages to convert the original signal values ​​in the payload data into physical values ​​with business semantics, generating a signal time series dataset; and a display unit, configured to extract signal state change points based on the signal time series dataset for time series visualization display.

[0016] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the first aspects above.

[0017] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation as described in any of the first aspects above.

[0018] According to a fifth aspect of the present application, an electronic device is provided, the electronic device including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0019] Based on the technical solution proposed in this application, by performing standardized preprocessing on vehicle fault log data and generating a structured log dataset, the original scattered unstructured logs can be transformed into regular and searchable data. This automatically filters invalid data and aligns the timelines of multi-source logs, replacing the repetitive work of manually organizing logs frame by frame. This provides a standard data foundation for subsequent automated analysis and reduces the drag on analysis efficiency caused by redundant data. By parsing the signal matrix file to extract vehicle communication signal metadata and generating a signal metadata database, signal parsing rules can be managed in a structured manner, decoupling the parsing rules from the processing logic. This provides a unified rule basis for subsequent automated decoding, eliminating the tedious process of manually checking each signal matrix. Based on the signal metadata database, vehicle communication protocol messages are automatically filtered and service matching and signal decoding are completed. The original values ​​in the payload are converted into physical values ​​with business semantics. Message decoding can be completed without manual intervention, replacing the high-intensity work of manual line-by-line decoding, significantly shortening log parsing time, and reducing alignment errors and calculation deviations that are prone to occur during manual operation. Finally, by extracting signal state change points, a time-series visualization is achieved, transforming abstract text logs into an intuitive time-series view. This helps analysts quickly pinpoint the temporal correlation between signal changes and faults. Overall, this application enables fully automated processing of fault log analysis, reducing the manual costs and professional barriers to fault diagnosis, and effectively improving the efficiency of vehicle fault log data analysis. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a method for processing vehicle fault log data according to an embodiment of this application is shown; Figure 2 A block diagram of a vehicle fault log data processing device according to an embodiment of this application is shown; Figure 3 A schematic diagram of the structure of an electronic device in an embodiment of this application is shown. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0023] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should also be noted that, for the sake of simplicity, certain components in the drawings that do not affect the interpretation of the technical solution of this application have been appropriately omitted.

[0024] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined. Therefore, the actual execution order may change depending on the actual situation.

[0025] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0026] This application proposes a vehicle fault log data processing scheme to improve the efficiency of vehicle fault log data analysis. In practical applications, the proposed scheme can be applied to fault diagnosis and log analysis scenarios in the vehicle body domain. The corresponding execution device can be a locally deployed diagnostic analysis terminal, a cloud-based analysis service platform, or a dedicated analysis device integrated into the R&D and testing environment of an automaker. As automotive electronic architecture evolves towards domain centralization, the vehicle body domain integrates dozens of electronic control units such as lights, seats, doors and windows, wipers, and air conditioning, leading to continuously increasing functional complexity and consequently, increased difficulty in fault diagnosis. The scheme in this application is primarily designed for the automated parsing and signal visualization requirements of vehicle body domain diagnostic logs, but it can also be extended and adapted to log analysis scenarios in other vehicle domains such as the powertrain domain, chassis domain, and intelligent driving domain.

[0027] Next, this application will elaborate on the proposed vehicle fault log data processing scheme. (Refer to...) Figure 1 The flowchart illustrates a method for processing vehicle fault log data according to an embodiment of this application. Figure 1 As shown, the method includes at least steps 110 to 150, which are described in detail below: In step 110, vehicle fault log data is acquired, and the vehicle fault log data is standardized and preprocessed to generate a structured log dataset.

[0028] In this application, step 110 mainly completes the access and preliminary standardization processing of the raw log data. The vehicle fault log data is primarily Diagnostic Log and Trace (DLT) format data conforming to the automotive open system architecture standard. This type of log is the core operational record output by various electronic control units in the vehicle body domain during operation, containing complete operational information such as device operating status, communication messages, and error reports, serving as the core data basis for fault diagnosis. Raw DLT logs are typically stored in hexadecimal format, which cannot be directly used for fault analysis at the business level. Therefore, standardization preprocessing is required to convert them into a structured dataset, providing a unified data foundation for subsequent signal analysis and visualization.

[0029] In such Figure 1 In step 110 shown, obtaining vehicle fault log data can be performed according to the following steps 111 to 112: Step 111: Based on the vehicle identification number and the fault time interval, establish a secure connection from the vehicle network service platform and retrieve the corresponding vehicle fault log compressed package. After completing the breakpoint resume and integrity verification, decompress and store the package to obtain the vehicle fault log data. Alternatively, Step 112: Import the local vehicle fault log file or compressed package, complete the integrity verification and deduplication, and then store it to obtain the vehicle fault log data.

[0030] This application provides two log access methods to adapt to different use cases. The cloud-based retrieval method described in step 111 is primarily suitable for remote fault diagnosis of mass-produced vehicles. The Vehicle Identification Number (VIN) is a unique identifier for each vehicle, allowing for precise location of the target vehicle's log data storage path. The fault time interval can be set by the user based on the actual time of the fault occurrence. The system can retrieve only log data before and after the fault period to reduce data transmission volume and improve analysis efficiency.

[0031] In this application, the vehicle networking service platform typically refers to the vehicle manufacturer's Telematics Service Provider (TSP) platform. Before retrieving data, the system can complete identity verification through authentication credentials and establish an encrypted secure connection to ensure the security of vehicle data transmission. The breakpoint resume mechanism can handle abnormal situations such as network interruptions, resuming transmission from the point of interruption after network recovery without retransmitting all data, making it suitable for transmitting large log files in the GB range. Integrity verification can be performed using the Message Digest Algorithm Version 5 (SDA5). By comparing the hash value of the log compressed package, it is confirmed that the file has not been damaged or tampered with during transmission. Decompression is only performed after verification, ensuring the integrity and accuracy of the accessed log data.

[0032] In this application, the local import method described in step 112 is mainly applicable to scenarios where logs cannot be obtained online, such as R&D testing and offline maintenance. The system can support the import of single log files with the .dlt extension, as well as compressed packages in .zip or .7z format, to meet different file storage requirements. Integrity checks can also be performed during the local import process to confirm that the files are not corrupted. Furthermore, duplicate imported log files can be deduplicated to avoid storing the same data repeatedly and occupying local storage space, and to prevent duplicate data from interfering with the analysis results during subsequent parsing.

[0033] This application offers two access modes: cloud retrieval and local import. This covers various use cases such as remote diagnostics, offline testing, and repair station troubleshooting, enhancing the solution's adaptability. Furthermore, combined with features like resume capability, integrity verification, and deduplication, it improves the efficiency of accessing large log files while ensuring data accuracy and completeness. This prevents file corruption or duplicate data from affecting the accuracy of subsequent parsing results, providing a reliable data entry point for fully automated analysis.

[0034] In such Figure 1 In step 110, the standardization preprocessing of the vehicle fault log data to generate a structured log dataset can be performed according to steps 113 to 114 as follows: Step 113: Synchronize and parse the vehicle fault log data according to the diagnostic log and tracking standards to extract the timestamp, electronic control unit identifier, application identifier, context identifier, log level and payload data of each log record, and filter out invalid log records.

[0035] Step 114: Time-axis alignment and ascending sorting of the log records of multiple electronic control units are performed to generate the structured log dataset.

[0036] In this application, step 113 mainly involves completing the frame parsing and field extraction of the original hexadecimal DLT log. The diagnostic log and tracing standard, namely the AUTOSARDLT standard, is a common log format standard in the automotive industry. DLT logs output by Electronic Control Units (ECUs) from different manufacturers all follow the frame structure specifications of this standard. The system can perform frame synchronization according to the standard frame format, identify each independent log record, and then parse and extract the core fields of the log frame by frame. The timestamp is used to mark the precise time of log record generation, which is the basis for subsequent time-series analysis; the ECU identifier is used to mark which ECU node the log originated from; the application identifier and context identifier are used to mark the application process and context environment to which the log belongs, facilitating subsequent log filtering by application dimension; the log level is used to distinguish the log type, typically including different levels such as information, warning, error, and fatal error, which can help users quickly locate abnormal errors; the payload data is the core business data carried in the log frame. Vehicle communication protocol messages are usually encapsulated in the payload data and are the core object for subsequent signal decoding.

[0037] During the parsing process, the system can synchronously filter invalid log records, including frames with cyclic redundancy check (CR) errors, invalid heartbeat frames, and duplicate log frames. CR error log frames indicate that the data has been corrupted during transmission or storage and are not valuable for analysis; they can be directly filtered. Invalid heartbeat frames are periodic messages used by the ECU for status reporting without any business meaning; they do not contain valid fault-related information, and filtering them can significantly reduce the size of the dataset and improve subsequent processing efficiency. Duplicate log frames are usually caused by repeated transmissions during log collection; filtering them can prevent duplicate data from interfering with the analysis results.

[0038] In this application, step 114 primarily unifies the timeline of multi-source logs. Since the vehicle domain contains multiple ECU nodes, the local clocks of different ECUs may have slight deviations, and the output log timestamps may not be perfectly aligned. The system can perform timeline alignment calibration on the logs of multiple ECUs using a unified time base, and then sort all log records in ascending order according to their timestamps, ultimately forming a unified and ordered structured log dataset. The structured dataset can be stored in the form of database tables, with each log record corresponding to a data entry, and each field corresponding to a column in the database table, facilitating rapid retrieval and filtering of log records that meet the criteria in subsequent steps.

[0039] This application automates the parsing and field extraction of DLT logs by following standard protocols, replacing manual frame-by-frame log parsing and significantly improving log preprocessing efficiency. Simultaneously, by filtering invalid frames and redundant data, the dataset size can be reduced, decreasing the computational load for subsequent signal analysis. Timeline alignment and sorting of multi-ECU logs integrates scattered multi-source logs into a unified time-series dataset, providing a consistent time reference for subsequent communication message filtering and signal timing analysis. This avoids signal timing discrepancies caused by time asynchrony and ensures the accuracy of subsequent fault timing analysis.

[0040] Continue to refer to Figure 1 In step 120, a preset signal matrix file is parsed to extract metadata of each vehicle communication signal and generate a signal metadata database.

[0041] In this application, step 120 primarily involves the structured management of the vehicle communication signal definitions, providing a rule-based basis for subsequent signal decoding. The vehicle communication signals mainly refer to functional status signals transmitted based on the Scalable Service-Oriented Middleware over IP (SOME / IP) protocol. These signals are the core carriers for transmitting functional status between various ECUs in the vehicle domain, such as the status of lights on / off, seat gear, window position, and air conditioning temperature, all of which are exchanged via SOME / IP signals. The signal matrix file is a configuration file defining the SOME / IP signal rules, essentially a rule dictionary for signal decoding. All signal encoding rules and physical meanings are defined in the signal matrix file. By parsing the signal matrix file, the system extracts the scattered signal definitions into structured metadata and stores it uniformly as a signal metadata database, achieving centralized and versioned management of signal parsing rules.

[0042] In such Figure 1In step 120, the step of parsing the preset signal matrix file to extract metadata of each vehicle communication signal and generating a signal metadata database can be performed according to steps 121 to 123 as follows: Step 121: Parse the signal matrix file to extract metadata of vehicle communication services, events, and signals. The metadata includes signal identifier, signal name, start bit, length, data type, precision, offset, electronic control unit to which it belongs, value range, and enumeration value.

[0043] Step 122: Perform a validity check on the metadata to mark signals of duplicate identifiers, bit width overflow, and abnormal value range, and generate alarm information.

[0044] Step 123: The verified metadata is versioned according to vehicle model and electronic control unit version to generate the signal element database.

[0045] In this application, step 121 mainly completes the extraction of full metadata from the signal matrix file. In the SOME / IP protocol architecture, a service is the basic unit of functionality; a service can contain multiple events, and each event can contain multiple specific signals. When the system parses the signal matrix file, it can extract the metadata level by level according to the service, event, and signal hierarchy, thus obtaining complete definition information for each signal. The signal identifier is a unique numerical code for each signal, used to identify the corresponding signal in the message; the signal name is the service name of the signal, making it easier for users to understand the meaning of the signal; the start bit refers to the starting bit position of the signal in the message payload, and the length refers to the number of bits occupied by the signal. The two together determine the position and space occupied by the signal in the message and are the core basis for bit-by-bit decoding; the data type refers to the data type of the original value of the signal, such as unsigned integer, signed integer, floating-point number, etc.; precision and offset are the calculation parameters for converting the original value into the physical value; the associated electronic control unit indicates which ECU node sent the signal; the value range limits the legal range of the signal's physical value, and signal values ​​outside the range can be judged as abnormal values; the enumerated value is used for switch-type and status-type signals, defining the service semantics corresponding to different original values, such as 0 corresponding to the off state, 1 corresponding to the on state, 2 corresponding to the automatic mode, etc.

[0046] In this application, step 122 primarily verifies the legality of the extracted metadata to ensure the accuracy of the signal metadata database. During the verification process, the system can check whether the definition of each signal conforms to the specifications. For example, it checks whether two different signals use the same signal identifier; if so, it marks them as duplicate identifiers. It also checks whether the sum of the signal's start bit and length exceeds the total bit width of the message; if so, it marks it as a bit width overflow. Furthermore, it checks whether the signal's value range matches the calculation results of the data type, precision, and offset; if there is a logical conflict, it marks it as a value range error. For all verified abnormal signals, the system can generate corresponding alarm information to prompt the user to check and correct them, avoiding errors in subsequent decoding results due to incorrect signal definitions.

[0047] In this application, steps 123 primarily complete the versioning management and database generation of metadata. Since the signal matrices differ across vehicle models and ECU software versions, the system can categorize and store the verified metadata according to vehicle model and ECU version. Each set of vehicle model and ECU version corresponds to an independent set of signal metadata. Ultimately, the signal metadata for all versions is uniformly stored in the signal metadata database. When users subsequently analyze logs for a specific vehicle model, they can directly select the corresponding version's signal metadata without repeated importing and parsing. The signal metadata database can be stored using a lightweight relational database, facilitating rapid retrieval and matching of corresponding signal definitions.

[0048] In this application, the preset signal matrix file may include an automotive open system architecture description file and a spreadsheet matrix file.

[0049] In this application, the automotive open system architecture description file, namely the Automotive Open System Architecture Extensible Markup Language (ARXML) file, is a signal definition file conforming to the automotive open system architecture standard. It is also a commonly used standard signal matrix format in automotive development. These files are written in Extensible Markup Language format, featuring high standardization and strong compatibility. Spreadsheet matrix files, typically in Excel format, are a commonly used signal definition delivery format between automakers and suppliers, characterized by high readability and ease of editing. The system supports importing both formats, adapting to different development processes and delivery scenarios. Users can directly use existing signal matrix files without format conversion, reducing usage costs.

[0050] In this application, step 124 may also be performed: Step 124: After importing the new signal matrix file, update the signal element database according to the signal mapping and parsing rules. Signal parsing adaptation for new vehicle models or new electronic control unit versions can be completed without modifying the code.

[0051] In this application, traditional log parsing tools typically hard-code the signal parsing logic into the program code. When a new vehicle model or ECU version is added, developers need to modify the code and recompile and release the tool to complete the adaptation, resulting in a long adaptation cycle and high costs. This embodiment, however, adopts a metadata-driven architecture. All signal parsing rules originate from the signal metadata database, and the program code does not contain any hard-coded logic specific to a particular vehicle model or signal. When adapting to a new vehicle model or ECU version, the user only needs to import the corresponding signal matrix file. The system can automatically parse and extract metadata and update the signal metadata database. After the update, it can be immediately used for log signal parsing of the new vehicle model. The entire process requires no modification to any program code and no restart of the software tool, completing the parsing and adaptation of all signals.

[0052] This application decouples signal parsing rules from program code and adopts a metadata-driven architecture, completely eliminating the adaptation limitations of traditional hard-coded solutions and significantly improving the solution's scalability. Users can complete the adaptation for new car models and new versions simply by importing the signal matrix file, without investing development resources in code modification and version release. This significantly shortens the adaptation cycle, reduces secondary development costs, and enables rapid response to log analysis needs for mass-produced vehicle iterations and new model development. Furthermore, combined with versioned metadata management, it enables unified management of signal rules across multiple car models and versions, avoiding decoding errors caused by confusion between different version rules.

[0053] Continue to refer to Figure 1 In step 130, based on the signal element database, log records including vehicle communication protocol messages are filtered from the log dataset, wherein the vehicle communication protocol messages include payload data.

[0054] In this application, step 130 primarily involves filtering target log records containing SOME / IP communication messages (i.e., vehicle communication protocol messages) from the full structured log dataset, thus narrowing down the processing scope for subsequent signal decoding. The structured log dataset contains various types of log records, including not only SOME / IP communication messages but also ordinary operation logs, error logs, debugging logs, and more. Only log records carrying SOME / IP communication messages contain the functional status signals that need to be decoded. The system can automatically identify SOME / IP protocol messages from the log payload data based on the frame header characteristics of the SOME / IP messages, filtering out the corresponding log records and discarding other logs that do not contain communication messages. The filtering process can be based on the log's context identifier, application identifier, or message header feature fields to ensure accurate identification of all log records containing SOME / IP communication data.

[0055] This application can accurately locate the target data that needs to be decoded from massive amounts of full logs by automatically filtering log records containing vehicle communication protocol messages, which greatly reduces the amount of data processed in subsequent decoding steps, improves the overall efficiency of signal analysis, and at the same time avoids interference from irrelevant logs in the signal decoding process, ensuring the accuracy of the decoding results.

[0056] Continue to refer to Figure 1 In step 140, the vehicle communication protocol message is subjected to service matching and signal decoding to convert the original signal values ​​in the payload data into physical values ​​with business semantics, thereby generating a signal time series dataset.

[0057] In this application, step 140 primarily completes the conversion from raw message data to readable service signal values. The original SOME / IP message is binary encoded data, which cannot directly represent the service meaning. It needs to be combined with the definitions in the signal metadata database, going through three core stages: message matching, bit-by-bit parsing, and physical value conversion, ultimately converting it into physical values ​​with service semantics. These values ​​are then linked with timestamps to form a time-series dataset, providing a data foundation for subsequent visualization analysis. The entire decoding process is fully automated, requiring no manual decoding based on the signal matrix.

[0058] Specifically, in such Figure 1 In step 140, the service matching and signal decoding of the vehicle communication protocol message can be performed according to the following steps 141 to 142: Step 141: Identify and filter log records that include the vehicle communication protocol messages from the log dataset.

[0059] Step 142: Extract the service identifier and event identifier from the header of the vehicle communication protocol message to match them with the service and signal definitions in the signal element database.

[0060] Step 143: Based on the start bit, length, and data type in the matched metadata, the payload data is parsed bit by bit to extract the original signal value.

[0061] In this application, step 141 mainly completes the secondary confirmation and screening of the target log to ensure that all logs processed subsequently contain valid SOME / IP communication messages and to prevent invalid data from entering the decoding process.

[0062] In this application, step 142 primarily completes the matching of messages and signal definitions. The header of a SOME / IP message always contains service identifier and event identifier fields, corresponding to the service and event to which the message belongs, respectively. The system can extract these two identifier fields from the message header and match them one-to-one with the service and event definitions stored in the signal metadata database to find the complete set of signal definitions corresponding to the message. Through this dual matching of service identifier and event identifier, the accurate correspondence between messages and signal definitions can be ensured, avoiding signal matching errors.

[0063] In this application, step 143 mainly completes the bitwise extraction of the original signal value. After matching the corresponding signal definition, the system can locate the corresponding bit range of the signal in the payload data of the message according to the start bit and length parameters of each signal, and then convert the binary data of the range into the corresponding original value according to the data type of the signal. For example, if the start bit of a signal is bit 0, the length is 8 bits, and the data type is an unsigned 8-bit integer, the system can read 8 consecutive bits of data starting from the 0th bit of the payload and convert them into an integer original value between 0 and 255.

[0064] In such Figure 1 In step 140, the conversion of the raw signal values ​​in the payload data into physical values ​​with business semantics to generate a signal time-series dataset can be performed according to steps 144 to 145 as follows: Step 144: Based on the precision, offset, and enumeration values ​​in the metadata, convert the original signal value into a physical value with business semantics.

[0065] Step 145: Establish a full-link mapping relationship for each log record, including log record, signal instance, physical value, and timestamp, to generate the signal time series dataset and mark abnormal signal values ​​that exceed the value range.

[0066] In this application, step 144 mainly completes the conversion from raw values ​​to physical values, transforming raw numerical values ​​without business meaning into numerical values ​​with actual physical meaning or business semantics. For analog signals, such as temperature, voltage, and gear levels, a linear conversion can be performed using precision and offset, and the specific calculation formula is as follows:

[0067] For example, a temperature signal with an accuracy of 0.5 degrees Celsius per unit and an offset of -40 degrees Celsius, and an original value of 100, can be calculated to have a physical value of 10 degrees Celsius. For enumerated signals of status or switch types, the original values ​​can be converted into corresponding business semantic descriptions through the enumeration value mapping table in the metadata. For example, an original value of 0 corresponds to "off," an original value of 1 corresponds to "on," and an original value of 2 corresponds to "automatic mode." After conversion, users can directly understand the business status of the signal without the need for manual translation using a matrix.

[0068] In this application, step 145 mainly completes the establishment of the end-to-end mapping relationship and the generation of the time-series dataset. The system can establish a one-to-one correspondence between the original log record and the signal instance, physical value, and timestamp for each decoded signal value. Each mapping relationship retains the unique identifier of the corresponding original log, ensuring that the signal value can be traced back to the corresponding original log record. After organizing all signal mapping relationships along the timeline, a signal time-series dataset is generated. Each data entry in the dataset contains information such as timestamp, signal name, physical value, and corresponding log ID. Simultaneously, the system can verify the physical value of each signal based on the value range in the metadata, marking signal values ​​exceeding the legal value range as abnormal signal values, facilitating rapid location of abnormal data during subsequent analysis.

[0069] This application utilizes a fully automated decoding chain involving service matching, bitwise parsing, and physical value conversion to automatically complete the conversion of SOME / IP packets into readable service signals. The entire process requires no manual intervention, reducing what would normally take hours of manual decoding to minutes, significantly improving the efficiency of fault log analysis. Furthermore, automatic matching and decoding based on a metadata database avoids decoding errors caused by bitwise misalignment or calculation mistakes during manual decoding, improving the accuracy of signal parsing. The establishment of a complete mapping relationship establishes a connection between the original logs and signal values, providing a data foundation for subsequent bidirectional tracing analysis. Automatic outlier marking helps users quickly identify abnormal signals, further reducing the difficulty of fault diagnosis.

[0070] Continue to refer to Figure 1 In step 150, based on the signal time series dataset, signal state change points are extracted for time series visualization.

[0071] In this application, step 150 mainly completes the visualization and interactive analysis of signal data, converting time-series signal data into an intuitive graphical view to help users quickly identify the temporal correlation between signal state changes and faults. The original signal time-series dataset contains signal values ​​at each sampling time, which contains a large amount of redundant data where the state has not changed. Directly displaying this data would not only result in an excessively large data volume but also hinder users from quickly locating state transition points. Therefore, it is necessary to first extract the signal state change points and then perform visualization rendering to improve the readability and interactive smoothness of the visualization view.

[0072] In such Figure 1 In step 150 shown, the extraction of signal state change points based on the signal time series dataset can be performed according to steps 151 to 152 as follows: Step 151: Process the signal time series dataset according to the time axis to extract the numerical transition points of the same vehicle communication signal.

[0073] Step 152: Filter out duplicate and unchanged data, and record the timestamp, value before change, value after change, and corresponding log identifier for each change point to generate a signal state change event set.

[0074] In this application, steps 151 and 152 can jointly extract signal change events. Specifically, the system can traverse all time-series data points of each independent signal in chronological order, compare the physical values ​​of two adjacent data points, and determine a state transition point if the value changes; otherwise, it is considered redundant data. For the identified transition points, the system can record the timestamp of the transition, the signal value before the transition, the signal value after the transition, and the original log identifier corresponding to the transition point. After summarizing all transition points of all signals, a signal state change event set can be generated. The event set only retains nodes whose states have changed, filtering out all redundant data whose states remain unchanged. For switch-type signals in the vehicle body domain, the frequency of state changes is low; this processing can filter out more than 90% of redundant data, significantly reducing the amount of data for visualization rendering.

[0075] This application can significantly reduce the amount of data for visualization rendering by extracting signal state change points and filtering redundant data, thereby improving the smoothness of view loading and interaction. At the same time, it allows users to more intuitively locate the time points when the signal state changes, avoiding being distracted by a large amount of repetitive and unchanging data, and making it easier to quickly pinpoint the changes in signal state before and after a fault occurs.

[0076] In this application, steps 1531 to 1534 may also be performed: Step 1531: Establish the hierarchical structure of the vehicle body domain functional modules, which include main modules and sub-modules.

[0077] Step 1532: Filter target vehicle communication signals from the signal element database by tag, electronic control unit, or keyword.

[0078] Step 1533: Bind the target vehicle communication signal to the corresponding vehicle body domain function module, and configure the display alias, unit, alarm threshold and display style of the target vehicle communication signal to generate a function signal binding relationship table.

[0079] Step 1534: Save the configured vehicle domain function modules and signal binding relationships as a reusable analysis template.

[0080] In this application, steps 1531 to 1534 enable the organization of signals according to business function dimensions, lowering the barrier to entry for using the tool. Step 1531 primarily establishes a hierarchical framework for functional modules. The system can incorporate standardized functional modules from the vehicle body domain, such as main modules like the external lighting system, interior lighting system, seat adjustment system, door and window control system, wiper system, and air conditioning system. Each main module can also have sub-modules; for example, the external lighting system can have sub-modules like low beam headlights, high beam headlights, turn signals, and daytime running lights. Users can also customize, add, edit, or delete functional modules according to actual business needs, flexibly adjusting the hierarchical structure to adapt to the functional division methods of different vehicle models.

[0081] In this application, step 1532 mainly provides multi-dimensional signal filtering capabilities. Users can quickly filter the target signals they need from the signal element database according to conditions such as the ECU, signal tag, and keywords, without having to search through the full list of signals one by one, thus improving configuration efficiency.

[0082] In this application, step 1533 primarily completes the binding of functional modules and signals. Users can bind selected target signals to corresponding functional modules through visual operations such as dragging and dropping. Users can also configure display aliases for each signal, changing technical signal names to those more easily understood by business personnel; configure signal units, such as degrees Celsius, percentages, or levels; configure alarm thresholds, highlighting signals in the visual view when their values ​​exceed the threshold range; and configure display attributes such as signal color and line style for easier differentiation in multi-signal overlay views. After all configurations are completed, the system generates a functional signal binding relationship table, recording the signal list and configuration parameters corresponding to each functional module.

[0083] The main step 1534 primarily enables the template-based reuse of configurations. Users can save the configured functional modules and signal binding relationships as analysis templates. For vehicles of the same model or platform, the division of functional modules and the correspondence between signals are basically consistent. During subsequent analysis, the saved templates can be directly called, eliminating the need to repeatedly build functional modules and bind signals, thus significantly reducing the workload of repetitive configuration.

[0084] This application establishes a binding mechanism between functional modules and signals, mapping underlying technical signals to business-level functional modules. Users do not need to understand specific signal names and technical definitions; they only need to select the corresponding functional module to view all related signals. This significantly lowers the barrier to entry for the tool, allowing testing and maintenance personnel unfamiliar with underlying communication protocols to independently perform signal-level fault analysis. The template-based reuse mechanism reduces repetitive configuration work, improves the efficiency of batch log analysis for the same vehicle model, and further reduces usage costs.

[0085] In such Figure 1 In step 150, the time-series visualization can be performed according to steps 154 to 157 as follows: Step 154: Load all vehicle communication signals bound to the target functional module according to the functional signal binding relationship table.

[0086] Step 155: Using time as the horizontal axis and the physical value of the signal as the vertical axis, a ladder diagram is used to display switch signals, and a line graph is used to display analog signals.

[0087] Step 156: Overlay and render the timing curves of multiple vehicle communication signals in the same visualization view, configure independent vertical axis scales for each vehicle communication signal, and use different colors to distinguish the timing curves of each vehicle communication signal.

[0088] Step 157: Establish a bidirectional association between signal change points and original log records. When a signal change point is selected in the visualization view, the corresponding original log record content is displayed. When a log record is selected in the original log list, the time position of the corresponding signal is located and marked in the visualization view.

[0089] In this application, step 154 ​​mainly completes the loading of the target signal. After the user selects the target functional module to be analyzed, the system can automatically query the functional signal binding relationship table and load the timing data of all signals bound under the module, without requiring the user to select signals one by one, thus simplifying the operation process.

[0090] In this application, step 155 primarily determines the type of visualization chart and the coordinate axis settings. The visualization view uses time as the horizontal axis to uniformly display the temporal changes of all signals; and uses the physical value of the signal as the vertical axis to display the numerical magnitude of the signal. Different chart formats are used for different types of signals. For discrete signals such as switch-type and state-type signals, a ladder diagram is used to clearly show the time points of signal state transitions and their sustained states, which conforms to the change characteristics of state signals. For continuously changing analog signals such as temperature and voltage, a line chart is used to intuitively show the continuous change trend of the signal value. Through differentiated chart formats, the change characteristics of different types of signals can be clearly presented, improving the readability of the view.

[0091] In this application, step 156 mainly implements the simultaneous display of multiple signals on the same screen. The system can overlay and render the timing curves of multiple signals under the same functional module in the same visualization view. Users can compare and view the timing changes of multiple signals on the same time axis, which is convenient for analyzing the logical relationship and sequence between different signals. Since the numerical ranges and units of different signals are different, the system can configure an independent vertical axis scale for each signal, which can be displayed on the left and right sides of the view or in separate sections, to avoid the inability to clearly display the trend of some signals due to large differences in numerical range. At the same time, each signal curve is distinguished by a different color, and with the help of illustrations, users can quickly identify the signal corresponding to each curve.

[0092] In this application, step 157 primarily achieves bidirectional linkage and tracing between signals and raw logs, which is the core interactive capability of visual analysis. Based on the previously established end-to-end mapping relationship, the system bidirectionally binds signal change points in the visual view to raw log records. When a user clicks on any signal change point in the visual view, the system can automatically locate and display the details of the corresponding raw log record. The user can directly view the complete log context at that moment, confirming the cause of the signal change and other accompanying log information. Conversely, when a user selects a log record in the raw log list, the system can automatically locate the corresponding time position in the visual view and highlight it, making it easy for the user to view the status of each signal at that moment.

[0093] This application utilizes a time-series visualization view to transform abstract text log data into intuitive graphical time-series curves. This allows users to quickly grasp signal trends and transition timing, intuitively identifying the temporal correlation between signal anomalies and faults. Compared to pure text log analysis, this significantly improves the efficiency of fault location. The simultaneous overlay of multiple signals and the independent vertical axis design support the linked comparative analysis of multiple signals, facilitating the understanding of signal logic relationships within complex functions. The bidirectional linkage tracing mechanism breaks down the barriers between the visualization view and the original logs. Users can quickly trace abnormal signals back to the original logs to confirm details, or reverse-engineer the signal state at the corresponding moment from suspicious logs. This enables end-to-end analysis from signal changes to the original log text and then to the root cause of the fault, effectively improving the accuracy and efficiency of fault root cause location.

[0094] The following describes an embodiment of the apparatus described in this application, which can be used to execute the vehicle fault log data processing method described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the vehicle fault log data processing method described above in this application.

[0095] See Figure 2 The diagram shows a block diagram of a vehicle fault log data processing device according to an embodiment of this application.

[0096] like Figure 2 As shown, the vehicle fault log data processing device 200 according to an embodiment of this application includes: an acquisition unit 201, a parsing unit 202, a filtering unit 203, a conversion unit 204, and a display unit 205.

[0097] The system includes: an acquisition unit 201 for acquiring vehicle fault log data and performing standardized preprocessing on the data to generate a structured log dataset; a parsing unit 202 for parsing a preset signal matrix file to extract metadata of each vehicle communication signal and generate a signal metadata database; a filtering unit 203 for filtering log records including vehicle communication protocol messages from the log dataset based on the signal metadata database, wherein the messages include payload data; a conversion unit 204 for performing service matching and signal decoding on the messages to convert the original signal values ​​in the payload data into physical values ​​with business semantics, generating a signal time series dataset; and a display unit 205 for extracting signal state change points from the time series dataset for time series visualization.

[0098] Based on the same inventive concept, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor so as to cause a computer device having the processor to perform operations performed by the vehicle fault log data processing method described above.

[0099] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operations performed by the vehicle fault log data processing method described above.

[0100] Based on the same inventive concept, this application also provides an electronic device, see reference. Figure 3 The diagram shows a schematic of the structure of an electronic device in an embodiment of this application. The electronic device includes one or more memories 304, one or more processors 302, and at least one computer program (computer program instruction) stored in the memory 304 and executable on the processor 302. When the processor 302 executes the computer program, it implements the vehicle fault log data processing method as described above.

[0101] Among them, Figure 3 In this document, a bus architecture (represented by bus 300) is used. Bus 300 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 302 and memory represented by memory 304. Bus 300 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 305 provides an interface between bus 300 and receiver 301 and transmitter 303. Receiver 301 and transmitter 303 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 302 is responsible for managing bus 300 and general processing, while memory 304 can be used to store data used by processor 302 during operation.

[0102] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0104] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0105] When the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

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

Claims

1. A method for processing vehicle fault log data, characterized in that, The method includes: Obtain vehicle fault log data and perform standardized preprocessing on the vehicle fault log data to generate a structured log dataset; The preset signal matrix file is parsed to extract metadata for each vehicle communication signal and generate a signal metadata database. Based on the signal element database, log records including vehicle communication protocol messages are filtered from the log dataset, and the vehicle communication protocol messages include payload data; Service matching and signal decoding are performed on the vehicle communication protocol messages to convert the original signal values ​​in the payload data into physical values ​​with business semantics, thereby generating a signal time series dataset; Based on the aforementioned signal time series dataset, signal state change points are extracted for time series visualization.

2. The method according to claim 1, characterized in that, The acquisition of vehicle fault log data includes: Based on the vehicle identification number and the fault time interval, a secure connection is established from the vehicle network service platform, and the corresponding vehicle fault log compressed package is retrieved. After completing the breakpoint resume and integrity verification, the package is decompressed and stored to obtain the vehicle fault log data; or, Import the local vehicle fault log file or compressed package, perform integrity verification and deduplication, and then store it to obtain the vehicle fault log data.

3. The method according to claim 1, characterized in that, The standardization preprocessing of the vehicle fault log data to generate a structured log dataset includes: The vehicle fault log data is synchronized and parsed according to the diagnostic log and tracking standards to extract the timestamp, electronic control unit identifier, application identifier, context identifier, log level and payload data of each log record, and invalid log records are filtered out. The log records of multiple electronic control units are time-axis aligned and sorted in ascending order to generate the structured log dataset.

4. The method according to claim 1, characterized in that, The process of parsing a preset signal matrix file to extract metadata for each vehicle communication signal and generating a signal metadata database includes: The signal matrix file is parsed to extract metadata for vehicle communication services, events, and signals. The metadata includes signal identifier, signal name, start bit, length, data type, precision, offset, electronic control unit to which it belongs, value range, and enumerated value. The metadata is validated to mark duplicate identifiers, bit width overflow, and abnormal value range signals and generate alarm information. The verified metadata is versioned according to vehicle model and electronic control unit version to generate the signal metadata database.

5. The method according to claim 1, characterized in that, The process of performing service matching and signal decoding on the vehicle communication protocol messages includes: Identify and filter log records that include the vehicle communication protocol messages from the log dataset; Extract the service identifier and event identifier from the header of the vehicle communication protocol message to match them with the service and signal definitions in the signal element database; The payload data is parsed bit by bit based on the start bit, length, and data type in the matched metadata to extract the original signal value.

6. The method according to claim 5, characterized in that, The step of converting the raw signal values ​​in the payload data into physical values ​​with business semantics to generate a signal time-series dataset includes: Based on the precision, offset, and enumeration values ​​in the metadata, the original signal value is converted into a physical value with business semantics; For each log record, establish a full-link mapping relationship including log record, signal instance, physical value, and timestamp to generate the signal time series dataset and mark abnormal signal values ​​that exceed the value range.

7. The method according to claim 1, characterized in that, The step of extracting signal state change points based on the signal time series dataset includes: The signal time series dataset is processed according to the time axis to extract the numerical transition points of the same vehicle communication signal; Filter out duplicate and unchanged data, and record the timestamp, the value before the change, the value after the change, and the corresponding log identifier for each change point to generate a set of signal state change events.

8. The method according to claim 1, characterized in that, The method further includes: A hierarchical structure for the vehicle body domain functional modules is established, wherein the vehicle body domain functional modules include main modules and sub-modules; Target vehicle communication signals are filtered from the signal element database by label, electronic control unit, or keyword. The target vehicle communication signal is bound to the corresponding vehicle body domain function module, and the display alias, unit, alarm threshold and display style of the target vehicle communication signal are configured to generate a function signal binding relationship table; Save the configured vehicle domain function modules and signal binding relationships as a reusable analysis template.

9. The method according to claim 8, characterized in that, The time-series visualization includes: According to the functional signal binding relationship table, load all vehicle communication signals bound to the target functional module; With time on the horizontal axis and signal physical value on the vertical axis, a ladder diagram is used to display switch signals, and a line graph is used to display analog signals. The timing variation curves of multiple vehicle communication signals are overlaid and rendered in the same visualization view. Each vehicle communication signal is assigned an independent vertical axis scale, and the timing variation curves of each vehicle communication signal are distinguished by different colors. Establish a two-way association between signal change points and original log records. When a signal change point is selected in the visualization view, the corresponding original log record content is displayed. When a log record is selected in the original log list, the time position of the corresponding signal is located and marked in the visualization view.

10. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 9.

Images