Vehicle communication fault source determination method and related equipment

Abstract

The invention discloses a vehicle communication fault source determination method and related equipment, and relates to the technical field of vehicle communication, the method comprises the following steps: obtaining communication operation information of a plurality of processing levels in a vehicle communication system, the plurality of processing levels comprising a hardware layer, a middle layer, a security layer and a network layer; based on a preset log format, recording the communication operation information, and generating an encrypted log; and performing fault root cause analysis on the encrypted log through a preset fault tree model to obtain a target fault source. Through multi-level log acquisition and fault tree analysis, in combination with a structured format and encrypted storage, vehicle communication fault diagnosis with accurate and efficient fault positioning, data traceability, safety and credibility can be realized.

Description

Technical Field

[0001] The present application relates to the field of vehicle communication technology, and more specifically, to a method for determining the source of a vehicle communication fault and related equipment. Background Art

[0002] With the rapid development of automotive electronic architecture and the continuous advancement of intelligent connected technologies, the stability and reliability of in-vehicle communication systems, as the core foundation for the coordinated operation of multiple Electronic Control Units (ECUs) and intelligent vehicle control, are attracting widespread industry attention. In-vehicle communication involves multiple key aspects such as perception, control, safety, and remote interaction. It typically encompasses a multi-layered interaction mechanism spanning the hardware layer (such as sensors and actuators), the middle layer (such as data preprocessing and protocol encapsulation), the security layer (such as encryption and authentication), and the network layer (such as Ethernet / CAN transmission protocols).

[0003] However, as the structure of in-vehicle communication systems becomes increasingly complex and their functions become more diverse, the types of communication failures are becoming more diverse and cross-cutting, and traditional troubleshooting methods can no longer meet the current system-level troubleshooting needs. In existing technologies, the source of the fault is often located by relying on log information or static message analysis of a single node. However, due to the lack of systematic observation and correlation analysis of each processing level of the communication link, only the results of the failure can be observed, and it is difficult to restore the dynamic behavior and causal path of each link in the communication process. This information fragmentation leads to low efficiency and poor accuracy in fault diagnosis. Especially when faced with complex problems caused by cross-level and multi-module problems, traditional methods are difficult to effectively support problem location and root cause tracing. In other words, there are technical problems in the relevant technologies such as poor accuracy, slow speed, and non-traceable positioning of communication failures. Summary of the Invention

[0004] The Summary of the Invention section of this application introduces a series of simplified concepts that will be further described in detail in the Detailed Description of the Invention section. The Summary of the Invention section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The vehicle communication fault source determination method and related equipment provided in this application can achieve vehicle communication fault diagnosis with accurate and efficient fault location, traceable data, and security and reliability through multi-level log collection and fault tree analysis, combined with structured format and encrypted storage.

[0006] In the first aspect, the present application provides a method for determining the source of a vehicle communication fault, comprising: obtaining communication operation information of multiple processing levels in a vehicle communication system, wherein the multiple processing levels include a hardware layer, an intermediate layer, a security layer, and a network layer; based on a preset log format, recording the communication operation information to generate an encrypted log; performing a root cause analysis of the encrypted log through a preset fault tree model to obtain a target fault source, wherein the preset fault tree model includes the fault modes and log parameter mapping rules of the multiple processing levels.

[0007] In some implementations, the communication operation information includes a function call sequence, data access permission status, a storage address, and an event triggering timestamp.

[0008] In some embodiments, the communication operation information is recorded based on a preset log format to generate an encrypted log, including: structuring the function call sequence, the data access permission status, the storage address, and the event trigger timestamp based on the preset log format to obtain an original log data block; encrypting the original log data block using a preset block encryption algorithm to obtain the encrypted log, wherein the key of the preset block encryption algorithm is dynamically generated by a hardware security module in the vehicle communication system based on a physically unclonable function; storing the encrypted log in a preset memory isolation buffer, and restricting unauthorized processes from reading and writing the encrypted log.

[0009] In some embodiments, the function call sequence, the data access permission status, the storage address and the event trigger timestamp are structured based on a preset log format to obtain an original log data block, including: assigning hierarchical labels to the function call sequence, the data access permission status, the permission address mapping relationship and the event trigger timestamp according to the multiple processing levels to obtain a hierarchical function call sequence, a hierarchical data access permission status, a hierarchical permission address mapping relationship and a hierarchical event trigger timestamp, wherein the hierarchical label is used to identify the processing level to which the communication operation information belongs; mapping the hierarchical function call sequence, the hierarchical data access permission status, the hierarchical permission address mapping relationship and the hierarchical event trigger timestamp to the data segment field of the preset log format to obtain an original log data block.

[0010] In some embodiments, the root cause analysis of the encrypted log is performed using a preset fault tree model to obtain a target fault source, including: generating a cross-level event timing diagram based on the encrypted log; matching the event timing diagram based on the fault mode and log parameter mapping rules of the preset fault tree model to obtain an abnormal event chain in the event timing diagram; and determining the target fault source based on the triggering sequence and hierarchical association relationship of the abnormal event chain.

[0011] In some embodiments, the method for determining the source of a vehicle communication fault further includes: in response to the determination result of the target fault source, triggering a cross-level verification test instruction set, wherein the verification test instruction set includes hardware layer signal loopback detection, security layer key synchronization verification, intermediate layer cache consistency verification, and network layer packet loss simulation test associated with the target fault source; and updating the log parameter mapping rules of the preset fault tree model based on the execution result of the verification test instruction set.

[0012] In some embodiments, the method for determining the source of a vehicle communication failure also includes: when the processing level corresponding to the target fault source is the hardware layer or the security layer, shortening the time interval threshold for generating the encrypted log to a preset emergency duration; when the processing level corresponding to the target fault source is the network layer or the middle layer, expanding the preset memory isolation buffer and enabling a log rolling overwrite mechanism to retain the encrypted log of the network layer or the middle layer.

[0013] On the second aspect, the present application also provides a device for determining the source of a vehicle communication fault, including: an information acquisition unit, used to obtain communication operation information of multiple processing levels in a vehicle communication system, wherein the multiple processing levels include a hardware layer, an intermediate layer, a security layer, and a network layer; a log generation unit, used to record the communication operation information based on a preset log format and generate an encrypted log; a fault analysis unit, used to perform a root cause analysis of the encrypted log through a preset fault tree model to obtain a target fault source, wherein the preset fault tree model includes the fault modes and log parameter mapping rules of the multiple processing levels.

[0014] In a third aspect, the present application further provides an electronic device comprising: a memory and a processor, wherein the processor is configured to implement the steps of the method for determining the source of a vehicle communication fault as described in the first aspect when executing a computer program stored in the memory.

[0015] In a fourth aspect, the present application further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method for determining the source of a vehicle communication failure described in the first aspect.

[0016] In a fifth aspect, the present application also provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, the method for determining the source of a vehicle communication fault provided in an embodiment of the present application is implemented.

[0017] In summary, the present application can quickly identify the specific level and link where the fault occurs by collecting and analyzing logs of communication operations at different levels, avoiding the problem that in traditional methods, only the fault results can be seen but the process is difficult to restore; through the structured log format and the parameter mapping rules of the fault tree, logical deduction and fault attribution analysis can be automatically performed, significantly improving the diagnostic efficiency and accuracy, and reducing the reliance on manual troubleshooting; the unified log recording method and standardized data structure enable engineers to efficiently read, export and analyze data streams in time series, simplify the maintenance process, and improve the problem handling response speed; all logs are stored in encrypted form, and an access control mechanism is set to effectively prevent the logs from being illegally tampered with or deleted, thereby ensuring the objectivity and audit validity of the fault records. In summary, the vehicle communication fault source determination method provided by the present application can achieve vehicle communication fault diagnosis with accurate and efficient fault location, traceable data, and security and reliability through multi-level log collection and fault tree analysis, combined with structured format and encrypted storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present description. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0019] Figure 1 A flow chart of a method for determining the source of a vehicle communication fault provided in an embodiment of the present application;

[0020] Figure 2 A schematic diagram of the structure of a preset log format provided in an embodiment of the present application;

[0021] Figure 3 A schematic diagram of the structure of a vehicle communication fault source determination device provided in an embodiment of the present application;

[0022] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] Terms in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," and the like (if any), are used to distinguish between similar objects, rather than to describe a particular order or precedence. Therefore, it is understood that these terms can be used interchangeably where appropriate, so that the embodiments described can be implemented in a different order, unless otherwise specified in the drawings or descriptions. In addition, the terms "is" and "has" and any variations thereof in this application are intended to cover all possible constituent elements on a non-exclusive basis. For example, a process, method, system, product, or apparatus that includes several steps or units is not necessarily limited to the steps or units that are explicitly listed, but may also include other steps or units that are not explicitly listed, or steps or units that are inherent to the process, method, product, or apparatus.

[0024] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (such as processing circuits or memories), or a combination of the two. One or more processors or memories can implement one or more modules or units. At the same time, each module or unit can also be part of a larger module or unit.

[0025] The technical solutions in this application will be described in detail below in conjunction with the accompanying drawings in the embodiments. It should be noted that the embodiments described are only part of this application, not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0026] Figure 1 This is a flow chart of a method for determining the source of a vehicle communication fault provided by an embodiment of the present application. Figure 1 The method for determining the source of a vehicle communication fault provided in an embodiment of the present application may include the following steps 101 to 103:

[0027] Step 101, obtaining communication operation information of multiple processing layers in a vehicle communication system, wherein the multiple processing layers may include a hardware layer, an intermediate layer, a security layer, and a network layer;

[0028] In some examples, the vehicle communication system refers to a system that exchanges information between on-board controllers through a bus protocol, which is used to coordinate the collaborative work of various subsystems of the vehicle, such as the power system, advanced driver assistance system (ADAS), body control system, etc. The bus protocol can be Controller Area Network (CAN), Ethernet or Local Interconnect Network (LIN), etc. Multiple processing levels refer to the different functional modules or processing stages involved in the vehicle communication process. From data acquisition, processing, encryption to transmission, they can be logically divided into four levels: hardware layer, middle layer, security layer and network layer; the hardware layer is responsible for the acquisition and output of physical signals, including sensor data acquisition, data conversion of analog-to-digital converter (ADC) or digital-to-analog converter (DIC), input / output (IO) control, etc.; the middle layer refers to the layer for pre-processing operations such as filtering, conversion, and protocol encapsulation of raw data; the security layer is the layer for processing operations such as encryption, integrity authentication, and security label generation of communication data, which usually relies on hardware security modules (HSM) for implementation; the network layer is the network protocol processing and driver layer responsible for encapsulating data and actually transmitting it through protocols such as TCP / IP and CAN.

[0029] Exemplarily, during the implementation of step 101, a hierarchical log collection module may be provided in an embedded operating system or a communication stack to perform non-invasive collection on key functions of each of the above-mentioned processing levels, and align events at different levels through a unified timestamp; for example, when the vehicle braking system triggers signal collection, the system will record the entire process information from ADC sampling function call, filtering calculation, encryption processing, to CAN message sending.

[0030] Through the implementation of step 101, multiple key communication processing links such as the hardware layer, middle layer, security layer and network layer are covered, which can realize data collection and process perception of the entire vehicle communication link. This multi-level information collection method breaks the limitations of the previous fragmentation and localization of fault information, helps to identify potential problems in the entire process from source to output, and improves the integrity of fault problem restoration and the possibility of root cause tracing.

[0031] Step 102: Record the communication operation information based on a preset log format and generate an encrypted log;

[0032] In some examples, a preset log format refers to a uniformly defined log structure template that standardizes how communication operation information is recorded at different processing levels, ensuring the consistency, integrity, and parsability of the logs during time series analysis and fault tracing. This can be defined and delivered to the data collection process through a pre-compiled structure template, a configuration file defined in JSON / XML format, or a log service interface. An encrypted log is the log information generated by encrypting the log content using an encryption algorithm after the communication operation log is generated, to prevent the log information from being illegally tampered with or leaked during transmission or storage.

[0033] Exemplarily, during the implementation of step 102, independent log collection agents may be configured for each processing level. These agents will capture key operation calls and generate structured data packets based on the centrally configured log format template. The generated log data will call the encryption service module before being written locally or uploaded, and perform real-time encryption processing on the log content, with an integrity check field attached.

[0034] Through the implementation of step 102, the unified preset log format ensures that data of different processing levels and different types are recorded in a consistent and structured manner, facilitating subsequent efficient retrieval and automated analysis; the log content is protected by encryption and combined with an access control mechanism to prevent key debugging data from being maliciously tampered with or leaked, thereby ensuring the authenticity, integrity and security of the log data and having a high degree of audit reliability.

[0035] Step 103: Perform fault root cause analysis on the encrypted log using a preset fault tree model to obtain a target fault source, wherein the preset fault tree model may include fault modes and log parameter mapping rules at multiple processing levels;

[0036] In some examples, a pre-built, multi-level fault tree model is a systematic analysis method used to deduce the various possible causes of system failures through logical relationships. Pre-built fault tree models can be constructed by engineers based on previous experience, standard diagnostic processes, and actual test cases, and stored in the system in a structured manner. For example, node A (data encryption failure) is derived from the logical OR of nodes A1 (key acquisition failure) or A2 (encryption timeout). Failure modes refer to the types and manifestations of anomalies that may occur in each function or processing link during a failure. They are the basic elements for constructing a pre-built fault tree model and can be extracted from Failure Modes and Effects Analysis (FMEA), historical failure case databases, or expert rule bases. Log parameter mapping rules are a set of rules that establish a correspondence between structured fields in the log (such as function name, status code, data content, and access rights) and fault mode nodes, supporting automated analysis. For example, if the field SecOC_Decrypt() in the log returns an error code 401, it is mapped to the "Authentication Tag Tampered" node. The root cause analysis process uses a fault tree model to match conditions and perform logical deduction on collected encrypted logs, locating the true root cause of the fault from among numerous possibilities. The target fault source is the specific cause node ultimately diagnosed as most likely to cause the current communication anomaly or failure, including its hierarchy and triggering conditions. An analysis algorithm is used to select the path end with the highest matching probability from the leaf nodes at the end of the fault tree.

[0037] For example, in the implementation process of step 103, the encrypted log can be first decrypted and parsed, and then the parsed log fields can be matched one by one with the mapping rules defined in the preset fault tree model to construct a "fault propagation path"; then, the fault tree is traversed from top to bottom in chronological order and logical relationship, and the paths that do not meet the conditions are eliminated, and the deepest and most accurate leaf nodes are gradually located as the "target fault source"; for example, in a communication anomaly, by identifying combinations such as "encryption time anomaly + CPU load is too high + log level is ERROR", it is deduced that "security layer computing resource conflict" is the root cause of the fault, which greatly improves the diagnostic efficiency and accuracy.

[0038] By implementing step 103, the pre-built fault tree model enables logical reasoning and systematic diagnosis of complex faults. This not only improves the accuracy and automation of fault location, but also significantly reduces the burden of manual analysis and accelerates troubleshooting response. Furthermore, the structured model supports continuous expansion and optimization, adapting to vehicle communication systems across multiple models and architectures.

[0039] In summary, the embodiments of the present application can quickly identify the specific level and link where the fault occurs by collecting and analyzing logs of communication operations at different levels, avoiding the problem that in traditional methods, only the fault results can be seen but the process is difficult to restore; through the structured log format and the parameter mapping rules of the fault tree, logical deduction and fault attribution analysis can be automatically performed, significantly improving the efficiency and accuracy of diagnosis and reducing the reliance on manual troubleshooting; the unified log recording method and standardized data structure enable engineering personnel to efficiently read, export and analyze data streams in time series, simplify maintenance processes, and improve the response speed of problem handling; all logs are stored in encrypted form, and an access control mechanism is set to effectively prevent the logs from being illegally tampered with or deleted, thereby ensuring the objectivity of the fault records and the audit validity. In summary, the method for determining the source of vehicle communication faults provided by the embodiments of the present application can achieve accurate and efficient fault location, traceable data, and secure and reliable vehicle communication fault diagnosis through multi-level log collection and fault tree analysis, combined with structured format and encrypted storage.

[0040] In some embodiments, the aforementioned communication operation information may include a function call sequence, data access permission status, a storage address, and an event triggering timestamp.

[0041] In some examples, a function call sequence refers to the sequential chain of function calls executed during the communication process, reflecting the internal execution process and call logic of the system. Data access permission status refers to the access permission status of a certain segment of memory, variable or resource during the communication operation, such as read-only, writable, visible to kernel mode, invisible to user mode, etc. The storage address refers to the specific storage location of data in physical memory or virtual address space during the communication process, which helps to analyze the data flow path and anomalies. It can be obtained from the memory allocation record (such as the memory mapping table) of the operating system or embedded system, or by the developer outputting debugging information in the driver. The event trigger timestamp refers to the specific time point when each operation or event occurs during the communication process. It is usually recorded in a high-precision timer (such as milliseconds or microseconds) for timing analysis. It can be recorded each time an event is triggered by calling the gettimeofday() function, the clock_gettime() function or a dedicated hardware timer.

[0042] For example, the following communication operation information can be collected for different processing levels in the vehicle communication system: At the hardware layer, function calls include ADC initialization (such as ADC_Init()), channel data reading (such as ADC_ReadChannel()), and DAC configuration output (such as HAL_DAC_SetValue() and HAL_DAC_Start()); data is written to the buffer via DMA, which is only accessible in kernel mode. The typical storage address is 0x20000000, corresponding to the raw sampling signal. The event trigger period is 10ms. Possible faults include hardware damage, driver configuration errors, and missing calibration data. At the middle layer, function calls involve filtering (Filter_Apply()), sensor data conversion (Sensor_Calibrate()), and serialization processing of the SOME / IP protocol (SomeIp_Serialize()); memory addresses such as 0x20001000 to 0x20002000 are shared buffers that require mutually exclusive access. Common faults include serialization errors and memory leaks. At the security layer, this includes reading keys from the hardware security module (HSM_GetKey()) and performing encryption authentication (SecOC_Encrypt(), SecOC_Decrypt()). These involve isolated memory areas protected by the MPU, such as 0x20003000 (plaintext temporary storage area) and 0x20004000 (ciphertext sending area). The event triggering period is approximately 5ms, and common faults include key injection failure, resource competition, and out-of-bounds access. At the network layer, logging involves sending ciphertext (send()) and receiving decrypted data (SecOC_Decrypt()) via socket. The kernel buffer address is 0x20005000, and the application layer accesses it through IPC. Typical faults include packet loss, inconsistent key versions, and authentication tag tampering. In addition, at other layers, communication anomaly information such as encryption calculation timeouts or network jitter can also be collected to further enhance the diagnosis and tracing capabilities of communication link failures.

[0043] Through the implementation of the above embodiments, multi-dimensional data elements such as function call sequence, data access permission status, storage address and event trigger timestamp are introduced, so that fault analysis is transformed from static recording to dynamic behavior chain reconstruction.

[0044] In some embodiments, the aforementioned step 102 may include: performing structured processing on the function call sequence, data access permission status, storage address and event trigger timestamp based on a preset log format to obtain an original log data block; performing an encryption operation on the original log data block using a preset block encryption algorithm to obtain an encrypted log, wherein the key of the preset block encryption algorithm is dynamically generated by a hardware security module in the vehicle communication system based on a physically unclonable function; storing the encrypted log in a preset memory isolation buffer, and restricting unauthorized processes from reading and writing the encrypted log.

[0045] In some examples, a raw log data block refers to log unit data generated by structuring and integrating communication operation information such as function call sequences, data access permission status, storage addresses, and event trigger timestamps according to a preset log format. This data can be accessed in real time through the operating system's system call interceptor, middleware hook functions, or communication protocol stack logging modules, and assembled into structured data by field, such as JSON or binary encoding format. A preset block encryption algorithm refers to an encryption method that segments raw log data blocks into fixed or dynamic block sizes and encrypts them separately, ensuring that even if partial data is leaked, the entire content is difficult to restore. Symmetric encryption algorithms such as AES-GCM and ChaCha20 can be used, combined with encryption block strategies such as fixed-length (e.g., 512B) or content-aware (e.g., by event interval) segmentation. A hardware security module is an embedded chip or dedicated hardware unit used for security-related operations such as secure key storage and cryptographic operations. A physically unclonable function (PUF) generates a unique and unpredictable physical response value based on microscopic process variations during chip manufacturing, which is used to dynamically generate keys. The pre-set memory isolation buffer is a data cache area dedicated to storing encrypted logs. This area is logically isolated from regular memory and equipped with access control mechanisms. Unauthorized processes, including user applications and potentially malicious code, are processes or threads that are not authorized by the system or have not obtained specific permissions. These processes can be identified by comparing process IDs, access permission tables, and key authentication records. Access control policies prevent unauthorized processes from accessing or modifying log data, ensuring data integrity and confidentiality.

[0046] For example, a log monitoring module can be set up based on the vehicle operating system to capture key function calls and status information of each layer of communication components; the structured processing module fills the information into the log template according to the communication level, such as marking the sendPacket() call as a network layer event and attaching a timestamp; then, the dynamic key generated by the PUF is retrieved in real time through the hardware security module to encrypt each log data block in segments; finally, the encryption result is written to the allocated isolation buffer, and an access whitelist is set through the kernel hook to allow only the authentication module to access the data, thus forming a complete, trusted and secure log processing closed loop.

[0047] Through the implementation of the above embodiments, the structured log format and encryption mechanism are utilized to improve the standardization and security credibility of logs; block encryption combined with a physically unclonable function to generate dynamic keys can enhance the ability to resist physical attacks and data tampering; log isolation storage and permission control avoid unauthorized access, ensuring the integrity and auditability of fault data.

[0048] In some embodiments, the aforementioned structured processing of the function call sequence, data access permission status, storage address and event trigger timestamp based on the preset log format to obtain the original log data block may include: assigning hierarchical labels to the function call sequence, data access permission status, permission address mapping relationship and event trigger timestamp according to multiple processing levels to obtain a hierarchical function call sequence, hierarchical data access permission status, hierarchical permission address mapping relationship and hierarchical event trigger timestamp, wherein the hierarchical label is used to identify the processing level to which the communication operation information belongs; mapping the hierarchical function call sequence, hierarchical data access permission status, hierarchical permission address mapping relationship and hierarchical event trigger timestamp to the data segment field of the preset log format to obtain the original log data block.

[0049] In some examples, a unique layer identifier or tag can be assigned to the communication operation information based on the processing layer to which it belongs in the vehicle communication system, such as the hardware layer, intermediate layer, security layer, and network layer. The processing layer can be automatically determined by analyzing the function call source module, communication protocol type, or drive path. For example, the module name CAN_DRV in the call stack is mapped to the hardware layer, and the module name TLS_STACK is mapped to the security layer; for example, the layer label SEC_LAYER is assigned to the function encryptPacket() to identify it as a security layer communication operation. The hierarchical function call sequence is a function execution process sequence with hierarchical labels attached to the function call sequence. It is used to clarify the system processing level to which each function call belongs. It can be implemented by combining system call tracing, log instrumentation, and module name mapping. The hierarchical data access permission status is a description of the permission status after the access control record (such as read / write permission changes, permission verification results) is attached with the level information. The permission change event can be obtained through the kernel access control interface or process control module, and the level can be judged in combination with the call context. The hierarchical permission address mapping relationship represents the correspondence between the permission allocation of a certain address segment and the logical module to which it belongs in a certain processing level. The hierarchical event trigger timestamp is a precise timestamp marked for each communication operation event, and the processing level information is attached to facilitate time series tracing and cross-level analysis. The data segment field refers to the data structure field defined in the preset log format and used to carry specific types of communication information. The field can be set according to the log specification or data structure definition, such as the field name of JSON or the offset field of the binary log.

[0050] For example, the built-in communication monitoring module can be used to capture function call information in vehicle communications in real time. Before each record enters the log system, the classification engine will first automatically identify the processing level to which it belongs based on rules such as module source and data path, and attach hierarchical labels such as NET_LAYER and HW_LAYER; then, various types of operation data will be allocated to the corresponding log structure fields according to the hierarchical dimension to achieve structured and hierarchical management of data; finally, these structured information will be organized into raw log data blocks, ready to enter the encryption and storage process.

[0051] For example, Figure 2As shown, the preset log format can be composed of four parts: a log header, an identification block, a data segment, and a checksum block. The log header includes a timestamp (5 bytes) and a device number (13 bytes), which are used to record the log generation time and identify the log source device, respectively. The identification block is used to describe the basic attributes of the log, including the event ID (4 bytes, used to uniquely identify the log event), version (2 bytes, indicating the log format version), field inversion (2 bytes, used for logical processing or security enhancement), log type (1 byte, such as error log, operation log), request method (1 byte, such as GET, POST and other network request methods), counter (2 bytes, used to record the number of events), log category (2 bytes), log level (2 bytes, such as DEBUG, INFO, WARN, ERROR), privacy level (1 byte, used to identify the sensitivity of the log data), heartbeat or response flag (1 byte, indicating the heartbeat or response status), data type (2 bytes, describing the attributes of the data content), and DLC (Data Length Code, 2 bytes, used to indicate the valid length of the data segment). The data segment is a variable-length Payload field (maximum 1997 bytes), which is used to carry actual log data related to communication operations. The check block is used to ensure the integrity and traceability of the log data, including the reserved word 0xFFFF (2 bytes, used for expansion), the recording method (1 byte, indicating the log recording method), the extended reserved word (4 bytes), and the CRC check code (4 bytes, using a 32-bit cyclic redundancy check mechanism to detect errors in data transmission or storage). The overall structural design takes into account data integrity, structural clarity, and future scalability, which facilitates standardized storage, efficient parsing, and security verification of logs, and improves system operation and maintenance and fault tracing capabilities.

[0052] By implementing the above embodiments, processing level labels are introduced in the log structuring process, which enables hierarchical awareness and dimensional mapping of logs. Accurately classifying various types of communication data into specific processing levels is beneficial for cross-layer positioning in subsequent fault analysis.

[0053] In some embodiments, the aforementioned step 103 may include: generating a cross-level event sequence diagram based on the encrypted log; matching the event sequence diagram based on the fault mode and log parameter mapping rules of the preset fault tree model to obtain an abnormal event chain in the event sequence diagram; determining the source of the target fault based on the triggering sequence and hierarchical association relationship of the abnormal event chain.

[0054] In some examples, a cross-level event sequence graph refers to a multi-level event flow diagram constructed in chronological order based on event information recorded at different processing levels in a vehicle communication system. This diagram reflects the actual operation process and interaction chain of the vehicle communication system over a specific period of time. Event records with hierarchical labels and timestamps can be extracted from encrypted logs, sorted by time, and associated with upstream and downstream call relationships to construct an event sequence graph. The generated sequence graph can then be pattern-matched using the predefined failure modes in the fault tree model and the parameter mapping relationship between events and log fields to identify potential failure paths. Using graph traversal or pattern recognition algorithms, the event chains in the sequence graph are compared with the abnormal paths defined in the fault tree model. An abnormal event chain is a series of consecutive events found in the sequence graph that conform to a specific failure mode. These events typically include a triggering event, abnormal manifestations, and unrecoverable actions, forming a logical chain of failure occurrence. The process of determining the source of the target fault based on the triggering sequence and hierarchical association of the abnormal event chain refers to analyzing the execution sequence and processing level of each event in the abnormal event chain, combining logical causal reasoning, and determining the key node where the first abnormality occurred as the source of the fault. Algorithms such as causal graph reasoning and trigger graph construction can be used to combine event timestamps, call sequence and system dependencies to determine the earliest source of the abnormality.

[0055] For example, event data with timestamps and hierarchical labels can first be extracted from encrypted logs, and a complete cross-level event time series graph can be constructed through sorting and dependency mapping; then, the event time series graph is input into the fault diagnosis module, and automatically matched with the fault path in the preset fault tree model to identify the abnormal event chain therein; finally, combined with the time sequence and hierarchical dependencies in the event chain, such as the network call relying on the middle-layer scheduling, the key node where the first abnormality occurred is automatically derived, and it is located as the source of the target fault, to achieve fast and accurate root cause analysis.

[0056] Through the implementation of the above embodiments, a cross-level event time series graph is constructed, which helps to reveal the hidden abnormal paths distributed between different levels; through the matching of abnormal event chains and the reconstruction of trigger relationships, the real trigger points behind complex faults can be accurately inferred; it can significantly improve the automation, systematicness and accuracy of fault location, and is particularly suitable for complex and frequent fault scenarios.

[0057] In some embodiments, the aforementioned method for determining the source of vehicle communication failure may further include: in response to the determination result of the aforementioned target fault source, triggering a cross-level verification test instruction set, wherein the verification test instruction set may include hardware layer signal loopback detection, security layer key synchronization verification, intermediate layer cache consistency verification and network layer packet loss simulation test associated with the target fault source; based on the execution result of the verification test instruction set, updating the log parameter mapping rules of the preset fault tree model.

[0058] In some examples, a cross-layer verification test instruction set refers to a set of functional verification test instructions designed for different processing layers that are automatically or semi-automatically triggered based on the identified fault source. These functional verification test instructions cover key modules of the communication system, verifying their operating status or whether the problem is reproduced, and are used to further confirm the root cause of the fault. Hardware layer signal loopback detection sends a test signal to the bus or interface and verifies whether it can be correctly transmitted back, which is used to detect the integrity of the physical link. Security layer key synchronization verification checks whether the keys between master and slave nodes are consistent to prevent encryption / decryption failures caused by key asynchrony. Middle layer cache consistency verification verifies whether the send / receive cache data of the communication middleware is consistent to prevent cache loss or mismatch. Network layer packet loss simulation testing verifies the system's ability to handle exceptions by constructing network packet loss or abnormal delay scenarios. Feeding back test results such as abnormal response, normal transmission, and delay information to the preset fault tree model can be used to optimize the mapping relationship between log parameters and fault modes, enhancing the preset fault tree model's ability to identify similar problems in the future.

[0059] For example, after determining the source of the target fault, the test strategy library associated with the fault node can be automatically consulted to generate a set of cross-level verification test instructions. This instruction set is then sent to the corresponding processing level of the vehicle communication system for execution, and the resulting response results, abnormal characteristics, and other information are uniformly reported. Then, based on these results, the mapping rules between parameters and faults in the original fault tree model are updated, enabling self-learning and dynamic optimization of the preset fault tree model, thereby locating similar faults more efficiently and accurately in the future. For example, if a network packet loss simulation test finds that the retransmission mechanism is not correctly triggered, the preset fault tree model will map this behavior as a key diagnostic signal, enhancing the ability to identify "packet loss and retransmission anomalies."

[0060] Through the implementation of the above embodiments, a verification test mechanism is introduced to perform real-time closed-loop verification of the root cause analysis results, thereby improving the credibility of the determination of the target fault source; the verification instruction set covers multiple processing levels, supports differentiated diagnostic strategies, and can enhance system resilience and robustness; at the same time, the preset fault tree model is dynamically updated based on the test results, which contributes to the long-term optimization of the preset fault tree model.

[0061] In some embodiments, the aforementioned method for determining the source of vehicle communication failure may also include: when the processing level corresponding to the target fault source is the hardware layer or the security layer, shortening the time interval threshold for generating encrypted logs to a preset emergency duration; when the processing level corresponding to the target fault source is the network layer or the middle layer, expanding the preset memory isolation buffer and enabling the log rolling overwrite mechanism to retain the encrypted logs of the network layer or the middle layer.

[0062] In some examples, when the target fault source determined by analysis is located in the hardware layer or security layer that has a greater impact on the safety and stability of the vehicle communication system, in order to improve the real-time performance of subsequent monitoring and recording, the original time interval threshold for generating encrypted logs (for example, 5 seconds) is shortened to a smaller preset emergency time (such as 1 second or 500 milliseconds) to capture more detailed operational changes. When the fault is located in the network layer or the middle layer, since such problems are often related to high-frequency communication, cache accumulation, message delays, etc., it is necessary to save logs within a larger time range for timing analysis. Therefore, the memory buffer for storing encrypted logs can be dynamically expanded, and a log rolling overwrite mechanism can be introduced to ensure that the latest log data is retained as much as possible under limited storage resources. The log rolling overwrite mechanism is a dynamic log management strategy. When the buffer capacity reaches the upper limit, the newly generated log data will overwrite the earliest written log to ensure continuous writing capability and give priority to retaining the latest records. It is suitable for communication-intensive or time-sensitive scenarios.

[0063] For example, once an anomaly is located at the hardware layer or security layer through fault tree analysis, in order to prevent the problem from expanding, the log collection frequency will be immediately increased to the "emergency level", for example, from collecting once every 5 seconds to every 1 second, which will help to record anomalies that may develop further in a more fine-grained manner; and when the fault occurs in the network layer or the middle layer, more memory space will be dynamically allocated for log caching, and a rolling overwrite mechanism will be enabled to ensure that data in critical time periods can still be retained during high-traffic or high-frequency communications, avoiding the omission of important diagnostic information due to log overflow.

[0064] Through the implementation of the above embodiments, the log collection frequency and storage strategy are dynamically adjusted according to the fault level to achieve flexibility and responsiveness in resource scheduling; the sampling frequency is increased for emergency levels (such as the hardware layer and the security layer) to effectively capture transient anomalies; the cache space is expanded for non-emergency levels (such as the network layer and the middle layer) and a rolling mechanism is enabled to avoid log loss and ensure continuous analysis.

[0065] In some embodiments, the method for determining the source of vehicle communication failure also includes: building a real-time cross-level correlation analysis engine based on encrypted logs to dynamically identify abnormal propagation paths between levels; the correlation analysis engine evaluates the abnormal contribution of events at each level through a preset weight model, generates a fault heat map and triggers adaptive diagnostic strategy adjustments.

[0066] In some examples, the real-time cross-layer correlation analysis engine uses a streaming data processing framework (such as Apache Flink or an embedded CEP engine) to aggregate real-time event streams from the hardware, middle, security, and network layer logs. A pre-set weighting model builds a multi-dimensional scoring matrix based on historical fault statistics and key layer indicators (such as a weight of 0.3 for security layer encryption failure and a weight of 0.2 for network layer packet loss), dynamically calculating the relevance of each event to the current communication anomaly. For example, when a hardware layer ADC sampling anomaly (weight 0.25) and a security layer encryption delay (weight 0.35) are triggered consecutively within 50ms, the engine automatically increases the diagnostic priority and generates a cross-layer fault heat map, marking high-contribution nodes.

[0067] Through the implementation of the above embodiments, real-time causal correlation analysis of multi-level abnormal events can be achieved, which can break through the delay bottleneck of traditional offline analysis; based on dynamic weight evaluation, key fault propagation paths can be accurately focused, so that diagnostic resources are prioritized in high-contribution links, which can shorten the average fault location time from hours to minutes, and at the same time enhance the intuitiveness of problem tracing through heat map visualization.

[0068] Furthermore, as an implementation of the aforementioned method embodiment, the present application also provides a vehicle communication fault source determination device for implementing the aforementioned method embodiment. This device embodiment corresponds to the aforementioned method embodiment. For ease of reading, the present vehicle communication fault source determination device embodiment will no longer describe the details of the aforementioned method embodiment one by one, but it should be clear that the device in the embodiment of the present application can correspond to and implement all the contents of the aforementioned method embodiment. Figure 3 As shown, the vehicle communication fault source determination device 20 includes: an information acquisition unit 201, a log generation unit 202 and a fault analysis unit 203, wherein the information acquisition unit 201 is used to obtain communication operation information of multiple processing levels in the vehicle communication system, and the aforementioned multiple processing levels may include a hardware layer, an intermediate layer, a security layer and a network layer; the log generation unit 202 is used to record the aforementioned communication operation information based on a preset log format and generate an encrypted log; the fault analysis unit 203 is used to perform a root cause analysis of the encrypted log through a preset fault tree model to obtain the target fault source, wherein the preset fault tree model may include fault modes and log parameter mapping rules for multiple processing levels.

[0069] In some embodiments, the aforementioned communication operation information includes a function call sequence, data access permission status, a storage address, and an event triggering timestamp.

[0070] In some embodiments, the log generation unit 202 is also used to perform structured processing on the function call sequence, data access permission status, storage address and event trigger timestamp based on a preset log format to obtain the original log data block; use a preset block encryption algorithm to perform encryption operations on the original log data block to obtain an encrypted log, wherein the key of the preset block encryption algorithm is dynamically generated by the hardware security module in the vehicle communication system based on a physically unclonable function; store the encrypted log in a preset memory isolation buffer, and restrict unauthorized processes from reading and writing the encrypted log.

[0071] In some embodiments, the log generation unit 202 is also used to assign hierarchical labels to the function call sequence, data access permission status, permission address mapping relationship and event trigger timestamp according to multiple processing levels, to obtain a hierarchical function call sequence, a hierarchical data access permission status, a hierarchical permission address mapping relationship and a hierarchical event trigger timestamp, wherein the hierarchical label is used to identify the processing level to which the communication operation information belongs; the hierarchical function call sequence, the hierarchical data access permission status, the hierarchical permission address mapping relationship and the hierarchical event trigger timestamp are mapped to the data segment field of the preset log format to obtain the original log data block.

[0072] In some embodiments, the fault analysis unit 203 is also used to generate a cross-level event timing diagram based on the encrypted log; based on the fault mode and log parameter mapping rules of the preset fault tree model, the event timing diagram is matched to obtain the abnormal event chain in the event timing diagram; according to the triggering sequence and hierarchical association relationship of the abnormal event chain, the target fault source is determined.

[0073] In some embodiments, the vehicle communication fault source determination device 20 also includes a fault testing unit for triggering a cross-level verification test instruction set in response to the determination result of the target fault source, wherein the verification test instruction set includes hardware layer signal loopback detection, security layer key synchronization verification, intermediate layer cache consistency verification and network layer packet loss simulation test associated with the target fault source; based on the execution result of the verification test instruction set, the log parameter mapping rules of the preset fault tree model are updated.

[0074] In some embodiments, the log generation unit 202 is also used to shorten the time interval threshold for generating encrypted logs to a preset emergency duration when the processing level corresponding to the target fault source is the hardware layer or the security layer; when the processing level corresponding to the target fault source is the network layer or the middle layer, the preset memory isolation buffer is expanded and the log rolling overwrite mechanism is enabled to retain the encrypted logs of the network layer or the middle layer.

[0075] The present application also provides a computer-readable storage medium, which stores computer-executable instructions or computer programs. When the computer-executable instructions or computer programs are executed by a processor, the processor will execute any step of the method for determining the source of vehicle communication failure provided in the present application.

[0076] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be various devices including one or any combination of the above memories.

[0077] In some embodiments, computer-executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0078] In some embodiments, computer-executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (for example, files storing one or more modules, subroutines, or code portions).

[0079] In some embodiments, computer-executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed across multiple sites and interconnected by a communication network.

[0080] like Figure 4 As shown, the present application also provides an electronic device 30, including a memory 310, a processor 320 and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, any step of the above-mentioned method for determining the source of vehicle communication fault is implemented.

[0081] The present application also provides a computer program product, comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the method for determining the source of a vehicle communication fault described above.

[0082] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for determining the source of a vehicle communication fault, characterized in that: include: Obtaining communication operation information of a plurality of processing layers in a vehicle communication system, wherein the plurality of processing layers include a hardware layer, an intermediate layer, a security layer, and a network layer; Record the communication operation information based on a preset log format and generate an encrypted log; The encrypted log is subjected to a fault root cause analysis through a preset fault tree model to obtain a target fault source, wherein the preset fault tree model includes the fault modes of the multiple processing levels and log parameter mapping rules.

2. The method for determining the source of a vehicle communication fault according to claim 1, characterized in that: The communication operation information includes a function call sequence, data access permission status, a storage address, and an event triggering timestamp.

3. The method for determining the source of a vehicle communication fault according to claim 2, wherein: The recording of the communication operation information based on a preset log format to generate an encrypted log includes: Performing structured processing on the function call sequence, the data access permission status, the storage address, and the event triggering timestamp based on a preset log format to obtain an original log data block; Performing an encryption operation on the original log data block using a preset block encryption algorithm to obtain the encrypted log, wherein a key of the preset block encryption algorithm is dynamically generated by a hardware security module in the vehicle communication system based on a physically unclonable function; The encrypted log is stored in a preset memory isolation buffer, and unauthorized processes are restricted from reading and writing the encrypted log.

4. The method for determining the source of a vehicle communication fault according to claim 3, characterized in that: The structured processing of the function call sequence, the data access permission status, the storage address, and the event triggering timestamp based on the preset log format to obtain an original log data block includes: According to the multiple processing levels, hierarchical labels are assigned to the function call sequence, the data access permission status, the permission address mapping relationship, and the event triggering timestamp to obtain a hierarchical function call sequence, a hierarchical data access permission status, a hierarchical permission address mapping relationship, and a hierarchical event triggering timestamp, wherein the hierarchical label is used to identify the processing level to which the communication operation information belongs; The hierarchical function call sequence, the hierarchical data access permission status, the hierarchical permission address mapping relationship and the hierarchical event triggering timestamp are mapped to the data segment field of the preset log format to obtain the original log data block.

5. The method for determining the source of a vehicle communication fault according to claim 1, wherein: The performing fault root cause analysis on the encrypted log using a preset fault tree model to obtain a target fault source includes: Generate a cross-level event time sequence graph based on the encrypted log; Matching the event sequence graph based on the fault mode and log parameter mapping rules of the preset fault tree model to obtain an abnormal event chain in the event sequence graph; The target fault source is determined based on the triggering sequence and hierarchical association relationship of the abnormal event chain.

6. The method for determining the source of a vehicle communication fault according to any one of claims 1 to 5, characterized in that: The method for determining the source of a vehicle communication fault further includes: In response to the determination result of the target fault source, triggering a cross-layer verification test instruction set, wherein the verification test instruction set includes hardware layer signal loopback detection, security layer key synchronization verification, middle layer cache consistency verification, and network layer packet loss simulation test associated with the target fault source; Based on the execution result of the verification test instruction set, the log parameter mapping rule of the preset fault tree model is updated.

7. The method for determining the source of a vehicle communication fault according to any one of claims 3 to 5, characterized in that: The method for determining the source of a vehicle communication fault further includes: When the processing level corresponding to the target fault source is the hardware layer or the security layer, shortening the time interval threshold for generating the encrypted log to a preset emergency duration; When the processing level corresponding to the target fault source is the network layer or the middle layer, the preset memory isolation buffer is expanded, and a log rolling overwrite mechanism is enabled to retain the encrypted logs of the network layer or the middle layer.

8. A device for determining the source of a vehicle communication fault, characterized in that: include: an information acquisition unit, configured to acquire communication operation information of a plurality of processing layers in a vehicle communication system, wherein the plurality of processing layers include a hardware layer, an intermediate layer, a security layer, and a network layer; A log generating unit, configured to record the communication operation information based on a preset log format and generate an encrypted log; A fault analysis unit is used to perform a root cause analysis on the encrypted log using a preset fault tree model to obtain a target fault source, wherein the preset fault tree model includes the fault modes and log parameter mapping rules of the multiple processing levels.

9. An electronic device comprising: A memory and a processor, characterized in that the processor is used to implement the steps of the vehicle communication fault source determination method as described in any one of claims 1 to 7 when executing the computer program stored in the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for determining the source of a vehicle communication fault are implemented as described in any one of claims 1 to 7.

Images