A diagnostic method, gateway, and storage medium for a vehicle controller node loss

Abstract

The present application relates to the technical field of fault diagnosis, in particular to a kind of vehicle controller node loss diagnosis method, gateway and storage medium.The method includes after the vehicle is powered on, the fault code variable of each controller node is registered, and timeout information table is initialized;Using the timeout information table, the loss message of each controller node to be diagnosed is counted, and the first fault state of the controller node is determined according to the count value;The first fault state includes loss state and non-loss state;Using the fault code variable, the first fault state in the timeout information table is read, and the second fault state of the controller node is determined according to the change of the first fault state;The second fault state includes current loss fault and historical loss fault.The present application can identify whether loss fault is historical occurrence or current occurrence, so that the controller can be maintained pertinently.

Description

Technical Field

[0001] This invention relates to the field of fault diagnosis technology, and more specifically, to a diagnostic method, gateway, and storage medium for vehicle controller node loss. Background Technology

[0002] Most existing vehicle chassis control systems implement zone control. With the large-scale popularization of new energy vehicles, in-vehicle communication terminals (TBOX) have become standard equipment, and big data analysis and vehicle status confirmation have become commonplace. Fault diagnosis has become an important safety assurance solution to ensure the normal operation of domain controllers.

[0003] Currently, diagnostic solutions applicable to traditional distributed controllers are no longer suitable for fault diagnosis of chassis domain controllers. When a domain controller node loss fault is diagnosed, only the state of the fault can be detected, but it is impossible to determine whether the fault is new or historical, which makes the maintenance of controller nodes difficult.

[0004] In view of this, the present invention is hereby proposed. Summary of the Invention

[0005] The purpose of this invention is to provide a diagnostic method, gateway, and storage medium for vehicle controller node loss, which can identify whether the loss fault occurred in the past or is currently occurring, thereby enabling targeted maintenance of the controller.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for diagnosing the loss of a vehicle controller node, comprising:

[0008] After the vehicle is powered on, register the fault code variables for each controller node and initialize the timeout information table;

[0009] Using the timeout information table, the lost packets of each controller node to be diagnosed are counted, and the first fault state of the controller node is determined based on the count value; the first fault state includes a lost state and a non-lost state.

[0010] The first fault status in the timeout information table is read using the fault code variable, and the second fault status of the controller node is determined based on the changes in the first fault status; the second fault status includes current loss faults and historical loss faults.

[0011] In a second aspect, the present invention provides a gateway, comprising:

[0012] At least one processor, and a memory communicatively connected to at least one of the processors;

[0013] The memory stores instructions that can be executed by at least one of the processors to enable at least one of the processors to perform a diagnostic method for the loss of any vehicle controller node.

[0014] Thirdly, the present invention provides a computer-readable storage medium storing computer instructions for causing the computer to execute a diagnostic method for any vehicle controller node loss.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0016] This invention diagnoses lost faults by using a gateway to diagnose all connected controllers, facilitating a systematic approach to fault diagnosis. By counting lost packets using a timeout information table, the loss status of controller nodes can be captured promptly. The fault status is read through fault code variables to track and analyze changes in the fault status, thereby identifying whether the lost fault is currently occurring or has occurred historically, enabling targeted maintenance of the controller. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a diagnostic method for vehicle controller node loss provided in an embodiment of the present invention;

[0019] Figure 2 This is a flowchart of diagnosing the first fault state of a controller node based on a timeout information table, provided in an embodiment of the present invention.

[0020] Figure 3 This is a flowchart provided by an embodiment of the present invention for determining changes in fault status based on fault code variables;

[0021] Figure 4 This is a schematic diagram of the gateway structure provided in an embodiment of the present invention. Detailed Implementation

[0022] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0023] Example 1

[0024] This embodiment provides a diagnostic method for vehicle controller node loss, applicable to situations where loss fault diagnosis is required for controller nodes mounted on a vehicle. The method provided in this embodiment can be executed by a gateway, which can diagnose loss faults in all controller nodes connected to it.

[0025] Figure 1 This is a flowchart of a diagnostic method for vehicle controller node loss provided by an embodiment of the present invention. The specific operations are as follows:

[0026] S110. After the vehicle is powered on, register the fault code variables for each controller node and initialize the timeout information table.

[0027] The fault code variable and timeout information table are structures at the software code level, containing multiple variables, various fault data, and related executable code. During subsequent diagnostics, it is necessary to traverse the fault code variable and timeout information table for each controller node to perform diagnostic and fault statistics operations.

[0028] After the vehicle is powered on, all fault codes will be registered. This embodiment focuses on registering fault codes for node loss. Specifically, S110 includes the following S111 to S113.

[0029] S111. After the vehicle is powered on, construct a table of node loss fault codes and timeout information for each controller node.

[0030] Node loss fault codes are represented as s_can_errcode. The configuration table for s_can_errcode includes a frame timeout configuration table and node loss fault code configuration information for each controller node. The frame timeout configuration table includes the number of identifier IDs for timeout frames. Configuration information includes the CAN channel number of the / message, the frame ID value, the minimum frame period value, the fault code value, and the fault level.

[0031] The controllers include at least the following: APA (Automatic Parking Assist) controller, Camera Monitoring System (CMS) controller, wireless charging controller, HUD (Head-Up Display) controller, Engine Management System (EMS), ECAS (Electronic Controlled Air Suspension), GCU (Generator Control Unit), MPC (Model Predictive Control), MRR (Mid-Range Radar Controller), MRR_R (Automotive Short-Range Radar) controller, DSCU (Dynamic Stability Control), PSCU (Power Steering Control Unit), PTC_BAT (Dynamic Stability Control Battery), CCU (Charging Control Unit), POT (Power Operated Tailgate) controller, and GSM (Global System for Mobile Communications) controller. The controllers include: Global System for Mobile Communications (GSM), Battery Management System (BMS), Electronic Speed ​​Controller (ESC), Wire-Controlled Brake System (WCBS), Inertial Measurement Unit (IMU), Electric Power Steering Controller (EPS), Body Control Module (BCM), Interior and Exterior Temperature Control System (ABM), and Integrated Circuit (IC).

[0032] It should be noted that after the vehicle is powered on, the parameters in the node loss fault code and timeout information table are all in an initialized state.

[0033] The following is a partial code example of a node loss fault code:

[0034]

[0035]

[0036] The timeout information table s_can_timeout is a global variable, which includes the fault code value, CANID value (i.e., the ID value of the CAN message), message transmission cycle value, fault status, message loss count, CAN channel number of the message, fault level, frame timeout detection parameters, and the number of controller nodes lost.

[0037] The structure of this global variable is as follows:

[0038]

[0039]

[0040] The frame timeout detection parameter is used to indicate how many frame timeout fault codes there are.

[0041] S112. Extract the fault information from the node loss fault code s_can_errcode into the timeout information table s_can_timeout.

[0042] The fault information in the node loss fault code includes information from the frame timeout configuration table and the node loss fault code configuration information for each controller node. This allows the association of the message-related information for each controller in the node loss fault code s_can_errcode with the node loss-related information, thus obtaining the timeout information table for each controller. In the initial state of the timeout information table, the fault state state = FALSE (no loss) and the message loss count cnt = 0.

[0043] S113. Construct a fault detection callback function based on the fault status in the timeout information table, and register the callback function, along with the fault code and fault level in the timeout information table, into the fault code variable.

[0044] When this callback function is called, the fault status s_can_timeout.code[cnt].state in the timeout information table is read to detect whether the current controller node is lost.

[0045] The registered fault code variable s_dem_regtbl includes: lost fault code, fault level, fault status, fault occurrence count, fault recovery count, and fault detection callback function. The structure of s_dem_regtbl is as follows:

[0046] typedef struct

[0047] {

[0048] uint32_t code; / * Missing fault code * /

[0049] uint8_t level; / * Fault level * /

[0050] uint8_t status; / * Fault status * /

[0051] uint8_t occucnt; / * Fault occurrence count * /

[0052] uint8_t resetcnt; / * Fault recovery count * /

[0053] boolean(*function)(uint32_t code); / * Callback function for fault detection * /

[0054] }dtc_regtbl_t;

[0055] In the initialization state, the fault code variable has the current fault status = FASLE (not lost), the fault occurrence count occucnt = 0, and the fault recovery count resetcnt = 0.

[0056] It should be noted that before reading the fault status s_can_timeout.code[cnt].state, the callback function needs to confirm the following prerequisites: the controller is powered on, the ignition switch is in the ON position for 2 seconds; the gateway's fault diagnosis function has recovered for 500ms; the non-bus off state; and the gateway and controller are within the normal voltage range.

[0057] This embodiment constructs a timeout information table and fault code variables for each controller node, and associates the message-related information, fault-related information and timeout-related information of each controller node, providing underlying code support for subsequent fault detection and tracking of changes in fault status.

[0058] S120. Using the timeout information table, count the lost messages of each controller node to be diagnosed, and determine the first fault state of the controller node based on the count value.

[0059] This embodiment can perform loss fault diagnosis on all controller nodes connected to the gateway, or it can perform loss fault diagnosis on a specified subset of controller nodes. The controller nodes that support loss fault diagnosis are called the controller nodes to be diagnosed, and subsequent operations are all performed on the controller nodes to be diagnosed.

[0060] The controller node periodically sends messages to the gateway. These messages must match the CAN channel number and CANID specified in the timeout information table, such as message A. If the gateway does not receive message A within a specified time, it considers the message to have timed out or lost. A count is kept of consecutively lost messages. When the count value cnt is greater than or equal to a preset value (10 times), the controller node is considered lost; otherwise, it is considered not lost. The current fault state is assigned to s_can_timeout.code[cnt].state in the timeout information table.

[0061] It should be noted that the timeout information table for each controller node is used to diagnose packet loss faults for the corresponding controller node. This packet loss fault diagnosis can be repeated every first cycle. After each execution, the fault status s_can_timeout.code[cnt].state and the packet loss count cnt need to be updated, so that when the timeout information table is accessed externally, the latest fault status s_can_timeout.code[cnt].state can be read.

[0062] S130. Use the fault code variable to read the first fault state in the timeout information table, and determine the second fault state of the controller node based on the changes in the first fault state.

[0063] S120 essentially records the loss faults of each controller node in real time. S130 reads out the loss faults of each controller node and tracks and analyzes their changes.

[0064] The gateway can read the first fault state from the timeout information table at second intervals, which is the value of s_can_timeout.code[cnt].state, where cnt is the index of the registered lost packet. The fault code variable also contains the fault state variable status. As time progresses, the controller node may switch between lost and non-lost states, and this change is captured through the fault code variable to identify the second fault state of the controller node.

[0065] The second fault status includes current loss faults and historical loss faults. This procedure applies to any controller node to be diagnosed and specifically includes the following operations:

[0066] 1. If the first fault state of a controller node is updated from the non-lost state to the lost state, the controller node is determined to be currently lost.

[0067] After the vehicle is powered on, the first fault status in the timeout information table is read as the non-lost status, i.e., s_can_timeout.code[cnt].state = FALSE. Then it changes to the lost status, i.e., s_can_timeout.code[cnt].state = TRUE. Then the second fault status of the controller node is the current lost fault, s_dem_regtbl[i].status = 0x90.

[0068] 2. If the first fault state of a controller node is updated from lost state to not lost state, the controller node is determined to be a historical lost fault.

[0069] After the vehicle is powered on, the first fault status in the timeout information table is read as a lost status, i.e., s_can_timeout.code[cnt].state = TRUE. Then it is changed to a non-lost status, i.e., s_can_timeout.code[cnt].state = FALSE. Then the second fault status of the controller node is a historical lost fault, s_dem_regtbl[i].status = 0x80.

[0070] Compared with the prior art, this embodiment has the following technical effects:

[0071] This invention diagnoses lost faults by using a gateway to diagnose all connected controllers, facilitating a systematic approach to fault diagnosis. By counting lost packets using a timeout information table, the loss status of controller nodes can be captured promptly. The fault status is read through fault code variables to track and analyze changes in the fault status, thereby identifying whether the lost fault occurred recently or in the past, enabling targeted maintenance of the controllers.

[0072] Furthermore, this embodiment records the changes in the fault state after power-on in the fault code variable, thereby capturing whether the loss fault of the controller node is a historical occurrence or a current occurrence. In other words, the fault type can be identified through the fault code variable. The method is simple, effective, and low-cost.

[0073] Example 2

[0074] Based on the above embodiments, this embodiment refines the process of determining the controller node to be diagnosed and the process of diagnosing the first fault state according to the timeout information table.

[0075] Before the aforementioned S120, the process also includes: parsing the configuration word written by the Unified Diagnostic Services (UDS) to obtain the value of each bit; and determining the controller node whose bit value meets the enable requirement based on the correspondence between each bit and the controller node, which is then used as the controller node to be diagnosed.

[0076] Specifically, after power-on, the diagnostic tool or the vehicle communication terminal TBOX calls the 2E service of the UDS diagnostic protocol to send a configuration word to the gateway. The 2E service allows clients (such as diagnostic tools) to write information to an internal location specified by a given Data Identifier (DID) in the server (such as the gateway). This is an external interface for writing ECU data and can obtain relevant status information from within the software in real time. The number of bits in the configuration word is unlimited; for example, a 32-byte configuration word: FA0007B… Developers need to set the code definition of the configuration word according to business requirements, as shown in the table below.

[0077] Table 1 Code Definition Table for Configuration Words

[0078]

[0079] The gateway parses the configuration word to be written into multiple bits and obtains the value of each bit, as shown in Table 2.

[0080] Table 2 Configuration word splitting to bit table

[0081]

[0082] As shown in Table 2, each bit has a one-to-one correspondence with the controller. See Table 3, where the horizontal axis represents the bit positions and the vertical axis represents the byte numbers of the configuration word. By referring to the same positions in Tables 2 and 3, the controller corresponding to each bit can be obtained.

[0083] Table 3. Controller and Bit Correspondence Table

[0084]

[0085] A value of 1 for the corresponding controller indicates that the controller meets the enable requirements and supports the diagnosis of loss faults, in which case the gateway needs to perform loss fault diagnosis on the controller; a value of 0 for the corresponding controller indicates that the controller does not meet the enable requirements and does not support the diagnosis of loss faults, in which case the gateway does not need to perform loss fault diagnosis on the controller.

[0086] During execution, a global variable s_can_dtclist is set at the code level to parse the configuration words written by the 2E service through bit shifting.

[0087] static uint64_t s_can_dtclist = 0x0000000000000000UL; / * If configuration word writing is detected, set s_can_dtclist to 1 to enable configuration word parsing * /

[0088] The parsing process is as follows:

[0089] / * Store data * /

[0090] s_can_dtclist|=(uint64_t)((pdata[0]&0x20)>>5); / / EMS

[0091] s_can_dtclist|=(uint64_t)((pdata[0]&0x02)>>1)<<1; / / GSM

[0092] s_can_dtclist|=(uint64_t)((pdata[4]&0x10)>>4)<<2; / / MCU

[0093] FO

[0094] s_can_dtclist|=(uint64_t)((pdata[3]&0x02)>>1)<<3; / / BMS

[0095] s_can_dtclist|=(uint64_t)((pdata[5]&0x04)>>2)<<4; / / ESC

[0096] s_can_dtclist|=(uint64_t)((pdata[4]&0x40)>>6)<<5; / / WC

[0097] BS

[0098] s_can_dtclist|=(uint64_t)((pdata[0]&0x04)>>2)<<6; / / IMU

[0099] s_can_dtclist|=(uint64_t)((pdata[5]&0x01)>>0)<<7; / / EPS

[0100] s_can_dtclist|=(uint64_t)((pdata[8]&0x02)>>1)<<8; / / BCM

[0101] s_can_dtclist|=(uint64_t)((pdata[6]&0x01)>>0)<<9; / / AB

[0102] M

[0103] s_can_dtclist|=(uint64_t)((pdata

[12] &0x04)>>2)<<10; / / IC

[0104] Here, `pdata` is the configuration word to be written. The corresponding bit for the controller is retrieved from the configuration word, and its value is assigned to `s_can_dtclist`. For example, if EMS is a controller, its configuration word corresponds to the fifth bit of the first byte. This fifth bit is moved to the least significant bit and then assigned to the 0th bit of `s_can_dtclist`. This process continues until all configuration words have been assigned to `s_can_dtclist`.

[0105] The following details the process of using a timeout information table to record or diagnose the loss status of controller nodes.

[0106] The timeout information table is used to count the lost packets of each controller node to be diagnosed, and the first fault state of the controller node is determined based on the count value. This includes: traversing the timeout information tables of all controller nodes; when traversing the timeout information table of any controller node, determining whether the controller node supports loss fault diagnosis based on the configuration word. That is, retrieving the corresponding bit from s_can_dtclist; if it is 1, loss fault diagnosis is required. Then, the lost packets transmitted by the controller node are counted; if the consecutive count value is greater than or equal to a preset value (e.g., 10 times), the controller node is determined to be in a loss state, and the loss state is recorded in the timeout information table.

[0107] The following is a detailed explanation of a specific implementation method at the code level. Figure 2 This is a flowchart of diagnosing the first fault state of a controller node based on a timeout information table, provided by an embodiment of the present invention, including the following steps:

[0108] S121, Execute the node loss monitoring timer. The period of this timer is 10ms, which is referred to as the first period in this embodiment.

[0109] After the timer counts for 10ms, the following steps S122 to S1291 are triggered.

[0110] S122. Determine whether the timeout information tables of all node controllers have been traversed. If yes, execute S1291, return to the main program, and wait for the next 10ms before executing the diagnostic operation using the timeout information table. If no, execute S123.

[0111] S123. For the timeout information table of the untraversed node controllers, determine whether the configuration word is 1; if yes, execute S124; otherwise, return to S122.

[0112] S124. Count the lost packets transmitted by the controller node. Execute S125 and S127.

[0113] The lost packets here should be packets counted by S124 and recorded in the timeout information table s_can_timeout. The s_can_timeout.code[cnt].cnt is incremented by 1 only when packets are lost consecutively. The consecutive count value needs to be compared with a preset value in real time. During the continuous counting of lost packets, the gateway needs to check whether the received packet is recorded in the timeout information table s_can_timeout. If it is, the counting is interrupted, and the consecutive count value is checked.

[0114] S125. Determine whether the continuous count value is greater than or equal to the preset value 10. If yes, execute S126; otherwise, return to S122.

[0115] Clear s_can_timeout.code[cnt].cnt to restart counting; at the same time, set it to the state of controller node loss, i.e., s_can_timeout.code[cnt].state = TRUE, and return S122.

[0116] S126. Determine that the controller node is in a lost state, and record the lost state in the timeout information table. Return to S122.

[0117] S127. During the continuous counting of lost messages, if a message is received, the timeout information table of the controller node is traversed.

[0118] S128. Determine if the received message exists in the timeout information table. If it does, execute S129; otherwise, execute S1291.

[0119] S129. Clear the count value in the timeout information table to zero; determine that the controller node is in a non-lost state, and record the non-lost state in the timeout information table. Execute S1291.

[0120] If the message exists in the timeout information table, clear s_can_timeout.code[cnt].cnt and start counting again; if the node controller is not lost, set s_can_timeout.code[cnt].state = FALSE.

[0121] S1291, Return to main program.

[0122] This embodiment uses counting and interrupt operations in the timeout information table to determine faults such as node loss and recovery. The implementation is simple, effective, and low-cost.

[0123] Optionally, after S140, fault data of the controller node can also be reported to the remote controller; wherein, the fault data includes fault code, fault type, fault level, fault occurrence count, and recovery count. It can be seen that this embodiment, by performing diagnostic processing at the gateway, can report node loss faults to the remote server in real time, and can simultaneously obtain all faults under the controller, which is beneficial for systematic fault handling. At the same time, this embodiment utilizes the function of configuration words, meaning that node loss fault detection can be achieved without changing the software code after changing the hardware scenario.

[0124] Example 3

[0125] This embodiment refines the scheme of determining the second fault state using fault code variables, based on the above embodiments. It uses fault code variables to read the first fault state in the timeout information table and determines the second fault state of the controller node based on changes in the first fault state. This includes: when the gateway's fault diagnosis function is enabled, determining whether it is an initial power-on; if not, iterating through the fault code variables of all controller nodes; if it is an initial power-on, reading historical fault data from the memory and iterating through the fault code variables of all controller nodes; while iterating through the fault code variables of any controller node, executing a fault detection callback function to read the first fault state in the timeout information table and determining the second fault state of the controller node based on changes in the first fault state; and storing the fault data of all controller nodes in the memory.

[0126] The following is a detailed explanation of a specific implementation method at the code level. Figure 3 This is a flowchart provided by an embodiment of the present invention for determining changes in fault status based on fault code variables, including the following steps:

[0127] S131. Execute the fault diagnosis timer. The period of this timer is 50ms, which is referred to as the second period in this embodiment.

[0128] After the timer counts for 50ms, the following steps S132 to S138 are triggered.

[0129] S132. Determine whether the gateway's fault diagnosis function is enabled. If yes, execute S133; otherwise, execute S138, return to the main program, and wait for the next 50ms before executing the fault diagnosis operation using fault code variables.

[0130] S133. Determine if the vehicle is initially powered on. If yes, proceed to S135; otherwise, proceed to S134.

[0131] The initial power-on here refers to the moment the vehicle is powered on, requiring the retrieval of historical fault data from the memory. Because fault data is retained even after power loss, and power cycles do not affect historical fault data, it is necessary to retrieve this data from memory after power-on. Historical fault data includes fault codes, fault types, fault levels, fault occurrence counts, and recovery counts prior to this power-on.

[0132] S134. Read historical fault data from memory. Continue execution to S135.

[0133] S135. Determine if all fault code variables of the node controllers have been traversed. If yes, proceed to S138. If no, proceed to S136.

[0134] S136. For the fault code variables of the untraversed node controllers, execute the fault detection callback function to read the first fault state in the timeout information table, and determine the second fault state of the controller node based on the changes in the first fault state. Execute S137.

[0135] Specifically, first, the first fault status in the timeout information table is read. If the first fault status is TRUE, it is a lost state, i.e., s_dem_regtbl[i].status = 0x90, indicating a current lost fault. If the first fault status is FALSE, it is a non-lost state. Further, it is determined whether it is a fault recovery, i.e., whether the status before FALSE was TRUE. If so, this is a fault recovery, i.e., s_dem_regtbl[i].status = 0x80, indicating a historical fault; if not, the status before FALSE is still FALSE, indicating no fault, i.e., s_dem_regtbl[i].status = 0x0.

[0136] S137. Store the fault data of all controller nodes in the memory. Execute S138.

[0137] S138, Return to the main program.

[0138] This embodiment provides a solution for diagnosing whether a controller node is currently lost or has been lost in the past using the fault code variable. The second fault status can be easily obtained through the value of the s_dem_regtbl[i].status field. The method is simple and effective.

[0139] Optionally, based on the above embodiments, the method provided in this embodiment further includes: using 19 routines of the unified diagnostic service to query the fault data of each controller node; and using 14 routines of the unified diagnostic service to clear the fault data of each controller node.

[0140] Specifically, through the unified diagnostic service 1901, you can query the number of all registered fault code variables; through the unified diagnostic service 1902, you can query the fault data of all currently registered fault code variables.

[0141] This invention uses a lightweight UDS diagnostic service to query and clear faults, and supports the recording and querying of historical and current faults.

[0142] Example 4

[0143] like Figure 4 As shown, this embodiment provides a gateway, including:

[0144] At least one processor; and

[0145] A memory communicatively connected to at least one of the processors; wherein,

[0146] The memory stores instructions executable by at least one of the processors, which, when executed, enable the processor to perform the described method. Since at least one processor in the gateway is capable of performing the described method, it possesses at least the same advantages as the described method.

[0147] Optionally, the gateway also includes interfaces for connecting the various components, including high-speed and low-speed interfaces. The components are interconnected using different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the gateway, including instructions stored in or on memory to display graphical information for a GUI (Graphical User Interface) on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors can be used with multiple memories, and / or multiple buses can be used with multiple memories, if desired. Similarly, multiple electronic devices (e.g., as a server array, a group of blade servers, or a multiprocessor system) can be connected, each providing some of the necessary operations. Figure 4Take processor 301 as an example.

[0148] The memory 302, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the vehicle controller node loss diagnosis method in this embodiment of the invention. The processor 301 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 302, thereby implementing the aforementioned vehicle controller node loss diagnosis method.

[0149] The memory 302 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on terminal usage. Furthermore, the memory 302 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 302 may further include memory remotely located relative to the processor 301, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0150] The gateway may also include an input device 303 and an output device 304. The processor 301, memory 302, input device 303, and output device 304 can be connected via a bus or other means; the figure shows an example of a connection via a bus.

[0151] Input device 303 can receive input digital or character information, and output device 304 may include a display device, an auxiliary lighting device (e.g., an LED), and a haptic feedback device (e.g., a vibration motor). The display device may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, and a plasma display. In some embodiments, the display device may be a touchscreen.

[0152] Example 5

[0153] This embodiment provides a computer-readable storage medium storing computer instructions for instructing a computer to perform the methods described above. The computer instructions on this computer-readable storage medium, used to instruct a computer to perform the methods described above, thus possess at least the same advantages as the methods described above.

[0154] The medium in this invention can be any combination of one or more computer-readable media. The medium can be a computer-readable signal medium or a computer-readable storage medium. The medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of the medium (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, the medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0155] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0156] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF (Radio Frequency), or any suitable combination thereof.

[0157] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0158] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0159] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for diagnosing vehicle controller node loss, characterized in that, Applicable to a gateway, the method includes: After the vehicle is powered on, register the fault code variables for each controller node and initialize the timeout information table; Using the timeout information table, the lost packets of each controller node to be diagnosed are counted, and the first fault state of the controller node is determined based on the count value; the first fault state includes a lost state and a non-lost state. The first fault state in the timeout information table is read using the fault code variable, and the second fault state of the controller node is determined based on the changes in the first fault state; the second fault state includes current loss fault and historical loss fault. Based on the changes in the first fault state, the second fault state of the controller node is determined, including: If the first fault state of a controller node is updated from the non-lost state to the lost state, the controller node is determined to be currently lost. If the first fault state of a controller node is updated from lost state to not lost state, the controller node is determined to be a historical lost fault; If the first fault state of a controller node is the non-lost state, determine whether it was the lost state before the non-lost state. If so, this is a fault recovery; otherwise, there is no fault.

2. The method according to claim 1, characterized in that, Before using the timeout information table to count the lost packets for each controller node to be diagnosed, the following steps are also included: The configuration words written by the unified diagnostic service are parsed to obtain the value of each bit; Based on the correspondence between each bit and the controller node, the controller node whose bit value meets the enable requirement is identified as the controller node to be diagnosed.

3. The method according to claim 2, characterized in that, The step of using the timeout information table to count the lost packets of each controller node to be diagnosed, and determining the first fault state of the controller node based on the count value, includes: Iterate through the timeout information tables of all controller nodes; When traversing the timeout information table of any controller node, determine whether the controller node supports loss fault diagnosis based on the configuration word; If loss fault diagnosis is supported, the number of lost packets transmitted by the controller node is counted; If the continuous count value is greater than or equal to the preset value, the controller node is determined to be in a lost state, and the lost state is recorded in the timeout information table.

4. The method according to claim 3, characterized in that, Also includes: During the continuous counting of lost messages, if the lost message is received, the count value in the timeout information table is cleared to zero. The controller node is determined to be in a non-lost state, and the non-lost state is recorded in the timeout information table.

5. The method according to claim 1, characterized in that, The step of reading the first fault state from the timeout information table using the fault code variable and determining the second fault state of the controller node based on the changes in the first fault state includes: When the fault diagnosis function of the gateway is enabled, determine whether it is an initial power-on. If it is not an initial power-on, iterate through the fault code variables of all controller nodes; If it is the initial power-on, read historical fault data from memory and iterate through the fault code variables of all controller nodes; When traversing the fault code variables of any controller node, execute the fault detection callback function to read the first fault status in the timeout information table, and determine the second fault status of the controller node based on the changes in the first fault status. The fault data of all controller nodes is stored in the memory.

6. The method according to claim 1, characterized in that, After the vehicle is powered on, the fault code variables for each controller node are registered, and the timeout information table is initialized, including: After the vehicle is powered on, a table of node loss fault codes and timeout information for each controller node is constructed. Extract the fault information from the node loss fault code into the timeout information table; A fault detection callback function is constructed based on the loss status in the timeout information table, and the callback function, along with the fault code and fault level in the timeout information table, are registered to the fault code variable.

7. The method according to claim 1, characterized in that, After determining the second fault state of the controller node based on the changes in the first fault state, at least one of the following operations is also included: The fault data of the controller node is reported to the remote controller; the fault data includes fault code, fault type, fault level, fault occurrence count and recovery count. The 19 routines of the unified diagnostic service were used to query the fault data of each controller node; The 14 routines of the unified diagnostic service are used to clear fault data from each controller node.

8. A gateway, characterized in that, include: At least one processor, and a memory communicatively connected to at least one of the processors; The memory stores instructions executable by at least one of the processors, which enable the at least one processor to perform the diagnostic method for the loss of a vehicle controller node as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The medium stores computer instructions for causing the computer to execute the diagnostic method for the loss of the vehicle controller node as described in any one of claims 1-7.

Images