Communication fault detection method and device and computer program product

Abstract

The invention relates to a communication fault detection method and device and a computer program product, and the method comprises the steps: an application module reports original fault events to first fault management middleware when detecting a communication fault, and the first fault management middleware records the fault events in a fault processing module, and periodically checking whether the fault events have been solved. For unsolved fault events, the middleware combines related fault events into a combined fault event, and records information of the combined fault event in a fault processing module, the information comprises an event ID, a state and a fault code, so that repeated recording of the fault code is reduced, and more effective fault tracking and management are realized.

Description

Technical Field

[0001] The present application relates to the field of vehicle electronic control technology, and in particular to a communication fault detection method, device and computer program product. Background Art

[0002] like Figure 1 As shown in FIG. 1 , in AUTOSAR (AUTomotive Open System ARchitecture), the application module detects communication faults according to preset functional requirements. When the fault condition is detected, the application module calls the interface of the AUTOSAR diagnostic event management module (DEM) and writes the fault status of the fault event (Event) into the diagnostic event management module (DEM). After receiving the fault status of the fault event, the diagnostic event management module (DEM) records the corresponding communication fault and its fault code (DTC) and other information. The AUTOSAR function inhibition module (FIM) configures the function inhibition state according to the communication fault state recorded by the diagnostic event management module (DEM) to prevent the further expansion of the fault or affect the safety performance of the vehicle. The application module reads the function inhibition state (FID) and performs function inhibition according to the function inhibition state (FID). On the data link, a one-to-one correspondence is formed between the fault event (Event), the fault code (DTC) and the function inhibition state (FID). Each fault event has a unique fault code and a corresponding function inhibition strategy.

[0003] The domain controller unit is the core control unit of the whole vehicle. It integrates the functions of multiple traditional controllers into one controller for development. However, the functions of the integrated subsystems (application modules) are relatively independent, and their fault detection and function degradation are also relatively independent. Each application module defines the communication fault event and the corresponding function degradation FID according to its own functional requirements. For example, the application module SWC1 defines the communication fault X1 and the function inhibition state FID_X1 when the message Message1 is lost, and defines the communication fault X2 and the function inhibition state FID_X2 when the messages Message2 and Message3 are lost. At the same time, the application module SWC2 defines the communication fault Y1 and the function inhibition state FID_Y1 when the messages Message1 and Message2 are lost, and defines the communication fault Y2 and the function inhibition state FID_Y2 when the message Message3 is lost. Therefore, if the fault code is recorded directly according to the fault event reported by the application module, there is a defect of repeated recording of the fault code, which affects the product quality and is not conducive to the analysis and location of the fault problem, because there will be a large amount of repeated information that needs to be screened and analyzed. Summary of the invention

[0004] The purpose of the present application is to provide a communication fault detection method and device, and a computer program product to avoid repeated recording of fault codes.

[0005] To achieve the above object, according to a first aspect of the present application, a communication fault detection method is provided, comprising:

[0006] When any application module detects a communication failure, it reports the original failure event to the first fault management middleware;

[0007] The first fault management middleware writes the original fault events reported by each application module into the fault processing module;

[0008] The fault processing module records the event ID and status information of the original fault event according to the original fault event reported by each application module;

[0009] The first fault management middleware periodically obtains all original fault events recorded by the fault processing module, detects whether the faults of all original fault events have been eliminated, merges at least two original fault events whose faults have not been eliminated to obtain at least one merged fault event, and writes the at least one merged fault event into the fault processing module; wherein the merged fault event includes at least two related original fault events;

[0010] The fault processing module records the event ID, state information and fault code of the at least one merged fault event according to the at least one merged fault event.

[0011] According to a second aspect of the present application, a communication fault detection device is provided, the device comprising a module for executing the method described in the first aspect of the present application.

[0012] According to a third aspect of the present application, a computer program product is provided, comprising computer program instructions, wherein the computer program instructions instruct a computer device to perform operations corresponding to the method according to the first aspect of the present application.

[0013] The present application proposes a communication fault detection method and device, and a computer program product, which have the following beneficial effects:

[0014] By introducing the first fault management middleware, related fault events can be merged to obtain a combined fault event, and only the fault code of the combined fault event is recorded, rather than recording the fault code separately for the fault events reported by each application module. This can reduce the situation of repeated recording of fault codes, improve product quality, and reduce a large amount of repeated information screening and analysis work when analyzing and locating fault problems, thereby improving the efficiency of fault analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0016] Figure 1 It is a principle diagram of a communication fault detection method disclosed in the background technology.

[0017] Figure 2 A flow chart of a communication fault detection method in an embodiment of the present application.

[0018] Figure 3 This is a schematic diagram of a communication fault detection method in one embodiment of the present application.

[0019] Figure 4 This is a schematic diagram of a communication fault detection method in another embodiment of the present application. DETAILED DESCRIPTION

[0020] The detailed description of the drawings is intended as an illustration of the current embodiment of the present application, and is not intended to represent the only form in which the present application can be implemented. It should be understood that the same or equivalent functions can be accomplished by different embodiments intended to be included in the spirit and scope of the present application.

[0021] See also Figure 2 An embodiment of the present application provides a communication fault detection method, comprising the following steps:

[0022] Step S10: When any application module detects a communication failure, it reports the original failure event to the first fault management middleware.

[0023] Specifically, the application module refers to a software component that implements a specific function, such as a power system control module, a body control module, an air-conditioning control module, etc. The functions of each application module are independent of each other, and a communication fault event is defined according to its own functional requirements. Each application module will detect whether there is a communication fault during operation. If so, the original fault event is reported to the first fault management middleware; it should be noted that the original fault event here refers to the fault event reported by the application module. In order to distinguish it from the combined fault event in step S40, it is named the original fault event; the information of the original fault event includes the event ID and status information (Status) corresponding to the fault event (Event), and the status information (Status) should indicate the existence of a fault.

[0024] Step S20: the first fault management middleware writes the original fault events reported by each application module into the fault processing module.

[0025] Specifically, the fault processing module provides a predefined interface, and the first fault management middleware communicates with the fault processing module by calling the interface, and writes the original fault events reported by each application module into the fault processing module.

[0026] Step S30: the fault processing module records the event ID and status information of the original fault event according to the original fault event reported by each application module.

[0027] Specifically, when processing the original fault events reported by each application module, the fault processing module only records the event ID and status information of the original fault event, but does not record information such as the fault code and freeze frame.

[0028] Step S40, the first fault management middleware periodically obtains all original fault events recorded by the fault processing module, detects whether the faults of all the original fault events have been eliminated, merges at least two original fault events that have not eliminated the faults to obtain at least one combined fault event, and writes the at least one combined fault event into the fault processing module; wherein the combined fault event includes at least two related original fault events.

[0029] Specifically, the first fault management middleware will query all original fault events recorded by the fault processing module at a preset time interval (for example, every few seconds or minutes). This periodic check ensures the real-time and dynamic nature of the fault management system and can respond to changes in fault events in a timely manner. After obtaining all original fault events recorded by the fault processing module, the first fault management middleware will check the current status of each original fault event to determine whether the fault has been resolved or eliminated. If an original fault event has been resolved or eliminated, the original fault event no longer needs to be further processed. For those original fault events that have not been resolved or eliminated, the first fault management middleware will analyze whether there is a correlation between them. If at least two original fault events are found to be related (for example, they may be caused by the same root cause), the first fault management middleware will merge these original fault events into a merged fault event. The purpose of the merger is to reduce redundant information, simplify the fault diagnosis process, and improve the efficiency of fault processing. The first fault management middleware calls the interface of the fault processing module and writes the merged merged fault event into the fault processing module. The merged fault event includes event ID and status information (for example, expressed as FAILD).

[0030] For example, application module SWC1 defines communication fault X1 and function inhibition state FID_X1 when message Message1 is lost, and defines communication fault X2 and function inhibition state FID_X2 when messages Message2 and Message3 are lost; at the same time, application module SWC2 defines communication fault Y1 and function inhibition state FID_Y1 when messages Message1 and Message2 are lost, and defines communication fault Y2 and function inhibition state FID_Y2 when message Message3 is lost; when message Message1 is lost, application module SWC1 reports communication fault X1 (original fault event), and application module SWC2 reports communication fault Y1 (original fault event), but these two original fault events both point to the event of message Message1 being lost, and therefore, they can be merged;

[0031] For another example, two application modules SWC3 and SWC4 are responsible for different subsystems of the vehicle respectively. When the application module SWC3 detects that the message Message4 on the controller area network (CAN) bus is lost, the communication fault Z1 and the functional inhibition state FID_Z1 are defined. Similarly, if the message Message5 is lost, the communication fault Z2 and the functional inhibition state FID_Z2 are defined. When the application module SWC4 detects that the message Message4 and the message Message5 are lost at the same time, the communication fault W1 and the functional inhibition state FID_W1 are defined. When the message Message4 is lost, the application module SWC3 will report the communication fault Z1 (original fault event). At the same time, since both the messages Message4 and Message5 are lost, the application module SWC4 will report the communication fault W1 (original fault event). In this case, although the communication faults Z1 and W1 are two different fault events, they both involve the loss of the message Message4, which indicates that they may have a common fault source. Therefore, these two original fault events can be merged.

[0032] The above is only an example, and the merging of fault events is not limited to the above method.

[0033] Step S50: the fault processing module records the event ID, state information and fault code of the at least one combined fault event according to the at least one combined fault event.

[0034] Specifically, the fault processing module receives at least one combined fault event from the first fault management middleware, and the fault processing module assigns a fault code to the combined fault event according to its characteristics, and records the event ID, status information and fault code of the at least one combined fault event, which helps technicians quickly identify the fault type and possible causes. Furthermore, for some fault events, the fault processing module can trigger the lighting of a warning light according to the severity of the combined fault event.

[0035] In summary, the method of the embodiment of the present application introduces the first fault management middleware to merge related fault events to obtain a combined fault event, and only records the fault code of the combined fault event, rather than recording the fault code separately for the fault event reported by each application module. This can reduce the situation of repeated recording of fault codes, improve product quality, and reduce a large amount of repeated information screening and analysis work when analyzing and locating fault problems, thereby improving the efficiency of fault analysis.

[0036] In some embodiments, Figure 3 As shown, the method of the embodiment of the present application also includes:

[0037] Step S60: the first fault management middleware obtains a freeze frame and fault process data of the original fault event included in the at least one merged fault event, and writes the freeze frame and fault process data into the fault processing module (DEM).

[0038] Specifically, after identifying and merging the relevant original fault events, the first fault management middleware will further obtain the freeze frames and fault process data associated with these original fault events from each application module. The freeze frame data usually includes the sensor readings and environmental conditions at the time of the fault, while the fault process data records the system behavior before and after the fault occurs. The first fault management middleware passes the collected freeze frames and fault process data to the fault processing module through a preset interface. After receiving the data, the fault processing module will store it in a local or external memory. Local memory refers to the vehicle's built-in storage system, such as non-volatile memory (NVM) or flash memory (FlashMemory), which is a storage method that facilitates fast access and data protection. External memory, such as a cloud server or an external diagnostic device, is a storage method that facilitates data backup and remote diagnosis. Maintenance technicians can access these stored data through diagnostic tools to analyze the cause of the fault more deeply and take corresponding maintenance measures. In this way, the fault processing module not only records the fault event itself, but also retains detailed environmental information when the fault occurs, greatly improving the accuracy and efficiency of fault diagnosis.

[0039] In some embodiments, Figure 4As shown, the method of the embodiment of the present application also includes:

[0040] Step S70, the first fault management middleware obtains the freeze frame and fault process data of the original fault event included in the at least one merged fault event, and synchronizes the freeze frame and fault process data to the second fault management middleware;

[0041] The second fault management middleware stores the freeze frame and fault process data in a memory.

[0042] Specifically, the first fault management middleware is arranged on the M core (Microcontroller Core), the second fault management middleware is arranged on the A core (Application Processor Core), and the data forwarding engine is used to efficiently and securely transmit data between different cores.

[0043] After receiving the freeze frame and fault process data, the second fault management middleware stores them in the local storage or external storage according to the Json file format. Json (JavaScript Object Notation) is a lightweight data exchange format that is easy for people to read and write, and is also easy for machines to parse and generate. The configuration of the Json file includes the maximum number of frozen frame / fault process data to be stored. When the stored data exceeds this maximum number, the earliest data will be overwritten according to the first-in-first-out (FIFO) principle. This mechanism ensures the rational use of storage space while ensuring the preservation of the latest fault data. In this way, the system can effectively manage fault data and provide a structured format to store and transmit this data for subsequent analysis and processing.

[0044] In some embodiments, the method of the present application further includes:

[0045] The first fault management middleware periodically obtains all merged fault events recorded by the fault processing module, detects whether at least two related original fault events contained in each merged fault event have eliminated the faults, and if so, updates the status information of the merged fault event and writes it into the fault processing module.

[0046] Specifically, the first fault management middleware will query the fault processing module at a preset time interval (for example, every few seconds or minutes) to obtain all recorded merged fault events. For each merged fault event, the first fault management middleware will check whether at least two related original fault events contained therein have been eliminated. If it is detected that all related original fault events of a merged fault event have been eliminated, the first fault management middleware will update the status information of the merged fault event, for example, marking the status information of the merged fault event as "resolved", "cleared" or a similar status, for example, represented by PASSED. The updated status information of the merged fault event will be written back to the fault processing module to ensure that the information in the fault processing module is up to date, so that the fault processing module can provide accurate fault history records to facilitate future fault analysis and vehicle maintenance.

[0047] For example, assuming that the merged fault event C1 contains the original fault events Z1 and W1, the first fault management middleware finds in the periodic check that Z1 and W1 no longer trigger the fault code. The first fault management middleware updates the status of C1 to "solved" and writes the updated status information to the fault processing module. The fault processing module then updates its internal records to reflect the latest status of C1. Through this step, the system can effectively track the resolution of faults and maintain the accuracy of fault records.

[0048] In some embodiments, the step S30 includes:

[0049] The fault processing module obtains the anti-shake parameters corresponding to the original fault events reported by each application module, and determines whether the original fault events reported by each application module occur according to the anti-shake parameters. If so, the event ID and status information of the original fault event are recorded; if not, no record is made.

[0050] Specifically, when the application module detects a potential fault, it will simultaneously report an original fault event and the anti-shake parameters associated with it, or the fault handling module pre-stores the anti-shake parameters corresponding to each fault event. The anti-shake parameters are a set of parameters used to determine whether a fault actually occurs, such as fault duration, fault occurrence threshold, etc.

[0051] After receiving the original fault event, the fault processing module will evaluate whether the fault actually occurred based on the corresponding anti-shake parameters. For example, if the anti-shake parameters specify that a fault must last for more than 5 seconds to be considered real, the fault processing module will monitor whether the fault event meets this condition. If the fault processing module determines that the fault event meets the requirements of the anti-shake parameters, that is, the fault is real, it will record the event ID and status information of the original fault event. If the fault event does not meet the requirements of the anti-shake parameters, such as the fault duration is too short or the number of occurrences is insufficient, the fault processing module will not record the event, thereby avoiding recording false alarms or temporary faults. In this way, the fault processing module can effectively filter out false alarms and ensure that the recorded fault events are real and need attention, thereby improving the accuracy and efficiency of fault diagnosis.

[0052] In some embodiments, Figure 3 and 4 As shown, the method of the embodiment of the present application also includes:

[0053] Step S90: the fault processing module (DEM) sends the event ID and status information of the currently recorded original fault event to the function inhibition module (FIM).

[0054] Specifically, the fault processing module sends the event ID and status information of the currently recorded original fault event to the function inhibition module, notifying the function inhibition module which fault events are occurring so that it can decide whether to inhibit or downgrade the vehicle's function.

[0055] Step S100: the function suppression module obtains function suppression status information according to the event ID and status information of the currently recorded original fault event.

[0056] Specifically, after receiving the event ID and status information of the fault event, the function suppression module will obtain corresponding function suppression status information based on the event ID and status information. The function suppression status information defines which vehicle functions should be suppressed or downgraded when a specific fault event occurs, and how to implement these measures.

[0057] Step S110: The first fault management middleware periodically obtains the function suppression state information from the function suppression module and sends it to the corresponding application module.

[0058] Specifically, the first fault management middleware periodically obtains the latest function inhibition status information from the function inhibition module, ensuring that the fault management system can respond to fault events in a timely manner and update the functional status of the vehicle.

[0059] Step S120: When any application module receives the function inhibition state information, it inhibits or degrades the vehicle function corresponding to the function inhibition state information.

[0060] Specifically, when any application module receives function inhibition status information, it will inhibit or downgrade the corresponding vehicle function based on this information. Function inhibition means completely disabling a function, while function degradation means that the function runs at a lower efficiency, such as switching from high-performance mode to low-performance mode, thereby inhibiting the performance of the function.

[0061] In some embodiments, the step S100 includes:

[0062] The function suppression module obtains a preset mask of the original fault event according to the event ID of the original fault event, and generates function suppression state information according to the state information of the original fault event and the preset mask.

[0063] Specifically, the function suppression module first queries the corresponding preset mask according to the event ID of the original fault event. The preset mask is a binary number, in which each bit corresponds to a specific function or system state, which is used to determine which functions should be suppressed. The state information of the original fault event is also a binary number. The function suppression module performs a logical AND operation on the state information of the original fault event and the preset mask to obtain the function suppression state information.

[0064] Here is a specific example:

[0065] Assume that there is an original fault event, the event ID is E123, and the binary code of its status information is 10101010. According to the event ID E123, the function suppression module queries the following preset mask 11110000, and the result of the logic and operation is: 10100000, 10100000 is the generated function suppression status information, which means that according to the preset mask, only the functions corresponding to the bits in the status information that are 1 in the mask need to be suppressed. The function suppression module can selectively suppress some functions of the vehicle according to the severity and impact range of the fault event to ensure the safe operation of the vehicle and the safety of the passengers.

[0066] In some embodiments, the step S20 includes:

[0067] The first fault management middleware obtains the voltage mode and network status of the current vehicle, and determines whether to write the original fault events reported by each application module into the fault processing module according to the voltage mode and the network status.

[0068] Specifically, after receiving the original fault event reported by the application module, the first fault management middleware will first check the current voltage mode and network status of the vehicle. The voltage mode usually refers to the state of the vehicle's power system, such as whether the 12-volt battery voltage is stable, whether the vehicle is starting, or whether it is in sleep mode. The network status refers to the health of the vehicle's internal communication network, such as whether the CAN bus is working properly, or whether the network load is too high, which may affect the communication of the application module.

[0069] Specifically, if the voltage pattern is stable and the network status is good, the vehicle system is considered to be operating normally, and the original fault event can be written to the fault processing module for further analysis. If the voltage pattern is unstable (for example, the voltage is too low), the writing of the fault event may be temporarily delayed because the reported fault in this case may be a temporary phenomenon caused by a power supply problem. If the network status is not good (for example, network communication is interrupted or the network load is too high), the first fault management middleware may choose not to write fault events, or mark these events as pending verification, because network problems may lead to erroneous fault reports. In this way, the first fault management middleware can effectively manage fault events, reduce false alarms, and ensure that the fault processing module receives accurate and useful fault information.

[0070] Another embodiment of the present application also provides a communication fault detection device, including a module for executing the communication fault detection method described in the above embodiment. This device can be a hardware device, a software device, or a combination of hardware and software.

[0071] Another embodiment of the present application also provides another communication fault detection device, including:

[0072] A communication interface, used to communicate with other electronic devices;

[0073] a memory for storing computer program instructions;

[0074] The processor is used to execute the computer program instructions to support the communication fault detection device to implement the method described in the above embodiment.

[0075] In this embodiment, the memory mainly includes a program storage area and a data storage area, wherein the program storage area can store an operating device, an application required for at least one function, etc., and the data storage area can store related data, etc. In addition, the memory can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, and a flash card (FlashCard), etc., or the memory can also be other volatile solid-state storage devices.

[0076] The processor may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor. The processor is the control center of the communication fault detection device, and various interfaces and lines are used to connect the various parts of the communication fault detection device.

[0077] An embodiment of the present application also provides a computer program product, including computer program instructions, wherein the computer program instructions instruct a computer device to perform operations corresponding to the method described in the above embodiment.

[0078] Specifically, the computer program product includes a series of computer program instructions, which are codes written in a computer program, and which define how to perform specific operations. These computer program instructions are designed to be loaded onto a computer device and instruct the device to perform specific operations, which refer to the various steps in the communication fault detection method described in the above embodiment. In this way, the computer program product of this embodiment provides a complete software solution, which can be run on various computer devices to implement the communication fault detection method of the above embodiment.

[0079] The embodiments of the present application have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A communication fault detection method, characterized in that: include: When any application module detects a communication failure, it reports the original failure event to the first fault management middleware; The first fault management middleware writes the original fault events reported by each application module into the fault processing module; The fault processing module records the event ID and status information of the original fault event according to the original fault event reported by each application module; The first fault management middleware periodically obtains all original fault events recorded by the fault processing module, detects whether the faults of all original fault events have been eliminated, merges at least two original fault events whose faults have not been eliminated to obtain at least one merged fault event, and writes the at least one merged fault event into the fault processing module; wherein the merged fault event includes at least two related original fault events; The fault processing module records the event ID, state information and fault code of the at least one merged fault event according to the at least one merged fault event.

2. The method according to claim 1, characterized in that Also includes: The first fault management middleware obtains a freeze frame and fault process data of an original fault event included in the at least one merged fault event, and writes the freeze frame and fault process data into the fault processing module.

3. The method according to claim 1, characterized in that Also includes: The first fault management middleware obtains the freeze frame and fault process data of the original fault event included in the at least one merged fault event, and synchronizes the freeze frame and fault process data to the second fault management middleware; The second fault management middleware stores the freeze frame and fault process data in a memory.

4. The method according to claim 1, characterized in that: Also includes: The first fault management middleware periodically obtains all merged fault events recorded by the fault processing module, detects whether at least two related original fault events contained in each merged fault event have eliminated the faults, and if so, updates the status information of the merged fault event and writes it into the fault processing module.

5. The method according to claim 1, characterized in that The fault processing module records the event ID and status information of the original fault event according to the original fault event reported by each application module, including: The fault processing module obtains the anti-shake parameters corresponding to the original fault events reported by each application module, and determines whether the original fault events reported by each application module occur according to the anti-shake parameters. If so, the event ID and status information of the original fault event are recorded; if not, no record is made.

6. The method according to claim 1, characterized in that Also includes: The fault processing module sends the event ID and status information of the current recorded original fault event to the function suppression module; The function suppression module obtains the function suppression state information according to the event ID and state information of the currently recorded original fault event; The first fault management middleware periodically obtains the function suppression state information from the function suppression module and sends it to the corresponding application module; When any application module receives the function inhibition state information, it inhibits or degrades the vehicle function corresponding to the function inhibition state information.

7. The method according to claim 6, characterized in that The function suppression module obtains the function suppression state information according to the event ID and state information of the currently recorded original fault event, including: The function suppression module obtains a preset mask of the original fault event according to the event ID of the original fault event, and generates function suppression state information according to the state information of the original fault event and the preset mask.

8. The method according to claim 1, characterized in that The first fault management middleware writes the original fault events reported by each application module into the fault processing module, including: The first fault management middleware obtains the voltage mode and network status of the current vehicle, and determines whether to write the original fault events reported by each application module into the fault processing module according to the voltage mode and the network status.

9. A communication fault detection device, characterized in that: The device comprises a module for executing the method according to any one of claims 1 to 8.

10. A computer program product, characterized in that The method comprises computer program instructions, wherein the computer program instructions instruct a computer device to execute operations corresponding to the method according to any one of claims 1 to 8.

Images