Method, apparatus, equipment, and storage medium for recording vehicle and bus malfunctions.

Abstract

This application provides a method, apparatus, device, and storage medium for recording vehicle bus failures. The method involves sending wake-up recording messages to the main domain control node of an ECU at a predetermined interval after the ECU has been woken up. When it is detected that the vehicle sleep failure detection conditions have been met, the main domain control node receives wake-up recording messages sent from at least one ECU under its control and stores the wake-up recording messages of at least one ECU in the vehicle's memory. If an abnormal battery shortage occurs in the vehicle, a problem investigator can use the wake-up recording messages to identify the specific cause of the vehicle's wake-up, thereby improving the efficiency of resolving the vehicle's battery shortage problem.

Description

Technical Field

[0001] This application relates to the field of vehicle technologies, and particularly to a method, apparatus, device, and storage medium for recording vehicle bus failures.

Background Art

[0002] In recent years, the energy-saving problem of vehicles has attracted attention, and reducing unnecessary power consumption is a very effective method. To suppress power consumption and avoid battery shortage and inoperability of the vehicle due to excessive consumption of battery power, the Partial Network (PN) method is adopted, and through the Virtual Function Cluster (VFC) and the Partial Network Cluster (PNC), orderly sleep and wake-up of the electronic control units (ECUs) of the entire vehicle are realized. When there is no communication requirement, it enters the sleep state, and wakes up when communication is needed, thus saving the power of the vehicle battery. nine( Partial NetWork, PN) management However, as the vehicle's electronic and electrical systems become increasingly complex, the number of electronic control units constantly powered by the battery has also increased, and the vehicle's battery shortage problem is inevitable.

[0003]

[0004] In related technologies, when a battery shortage problem occurs in a vehicle, the method of identifying the cause consumes a large amount of human resources, vehicle resources, and device resources, and checks each electronic control unit one by one through problem reproduction, resulting in a decrease in the efficiency of solving the vehicle's battery shortage problem.

Summary of the Invention

Problems to be Solved by the Invention

[0005] This invention provides a method, apparatus, device, and storage medium for recording vehicle bus failures that can improve the efficiency of solving the problem of insufficient vehicle battery power. [Means for solving the problem]

[0006] In a first aspect, the present invention provides a method for recording vehicle bus failures applied to any main domain control node within a vehicle, the method being: When it is detected that the vehicle sleep failure detection conditions are met, the main domain control node receives a wake-up recording message transmitted from at least one electronic control unit (ECU) under its control; The process includes the step of storing the wake-up recording message of the at least one ECU in the vehicle's memory, The wake-up log message sent from each ECU includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

[0007] In one possible embodiment, the method is The further step includes uploading wake-up log messages for at least one ECU stored in the memory that have not yet been uploaded to a cloud server, according to a predetermined data upload cycle.

[0008] In one possible embodiment, the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0009] In one possible embodiment, the field in the wake-up log message indicating the cause of the ECU wake-up is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0010] In one possible embodiment, the method is The further step includes determining that the vehicle sleep fault detection condition is met if, after a first predetermined time has elapsed since the power to the vehicle's switch was cut off and the vehicle security mode was activated, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

[0011] In one possible embodiment, the method is When a first signal indicating that the vehicle is being charged is received from the powertrain domain node, the step of determining that the vehicle is in a charging state, Otherwise, the further step includes determining that the vehicle is not in a charging state.

[0012] In a second aspect, the present invention provides a method for recording vehicle bus faults applicable to any electronic control unit (ECU) in a vehicle, the method being: The process includes the step of sending a wake-up record message to the main domain control node of the ECU at a predetermined interval after the ECU has been woken up, the wake-up record message including a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

[0013] In one possible embodiment, the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0014] In one possible embodiment, the field in the wake-up log message indicating the cause of the ECU wake-up is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0015] In a third aspect, the present application provides a vehicle bus failure recording device, the device is When it is detected that the vehicle sleep failure detection conditions are met, a receiving module for receiving a wake-up log message sent from at least one electronic control unit (ECU) under the control of the main domain control node, The system includes a storage module for storing the wake-up recording message of at least one ECU in the vehicle's memory, The wake-up log message sent from each ECU includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

[0016] In one possible embodiment, the apparatus is The system further includes an upload module for uploading wake-up record messages of at least one ECU stored in the memory that have not yet been uploaded to a cloud server, according to a predetermined data upload cycle.

[0017] In one possible embodiment, the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0018] In one possible embodiment, the field in the wake-up log message indicating the cause of the ECU wake-up is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0019] In one possible embodiment, the apparatus is The system further includes a first determination module for determining that the vehicle sleep failure detection condition is met if, after a first predetermined time has elapsed since the power to the vehicle's switch was cut off and the vehicle security mode was activated, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

[0020] In one possible embodiment, the apparatus further comprises a second determination module, and the second determination module is configured to when a first signal indicating that the vehicle is being charged, which is transmitted from a power train domain node, is received, determine that the vehicle is in a charging state; otherwise, determine that the vehicle is not in a charging state. It is used for this.

[0021] In a fourth aspect, the present application provides a recording device for vehicle bus faults, and the device comprises a processing module for transmitting a wake-up record message to a main domain control node of the ECU according to a predetermined period after the ECU is woken up, and the wake-up record message includes a field indicating an identifier of the ECU and a field indicating a wake-up cause of the ECU.

[0022] In one possible embodiment, the wake-up record message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0023] In one possible embodiment, the field indicating the wake-up cause of the ECU in the wake-up record message is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0024] In a fifth aspect, the present application provides an electronic device comprising a processor, a memory and a communication interface, wherein the memory stores computer-executable instructions, when the processor executes the computer-executable instructions stored in the memory, the processor executes the method according to any one of the first aspect or the second aspect.

[0025] In a sixth aspect, the present invention provides a computer-readable storage medium in which computer execution instructions are stored, and when the computer execution instructions are executed by a processor, the method according to either the first or second aspect is realized.

[0026] In a seventh aspect, an embodiment of the present invention provides a chip comprising a memory and a processor, wherein the memory stores code and data, the memory is coupled with the processor, and when the processor executes a program in the memory, the chip performs the method according to either the first or second aspect described above.

[0027] In the eighth aspect, an embodiment of the present invention provides a program product comprising a computer program, wherein when the program product is executed on a computer, the computer performs the method according to either the first or second aspect described above.

[0028] In the ninth aspect, an embodiment of the present invention provides a computer program, and when the computer program is executed by a processor, the method according to either the first or second aspect is performed. [Effects of the Invention]

[0029] The vehicle bus fault recording method, apparatus, device, and storage medium provided in this application transmit wake-up recording messages to the main domain control node of an ECU according to a predetermined period after the ECU has been woken up. When it is detected that the vehicle sleep fault detection conditions have been met, the main domain control node receives wake-up recording messages transmitted from at least one ECU under its control and stores the wake-up recording messages of at least one ECU in the vehicle's memory. In this process, wake-up recording messages transmitted from the ECU can be stored in the vehicle's memory. By investigating the cause of the ECU wake-up in the wake-up recording messages, the cause of the vehicle's battery depletion problem can be accurately identified, improving the efficiency of resolving the vehicle's battery depletion problem. [Brief explanation of the drawing]

[0030] To more clearly illustrate the embodiments of this application or the solutions of the prior art, the drawings that may be used in the descriptions of the embodiments or the prior art are briefly described below. Naturally, the drawings shown below are some embodiments of this application, and those skilled in the art can create other drawings based on these without requiring any creative effort. The drawings shown herein are incorporated into the specification and constitute part of this specification, and together with the specification, they explain the principles of this application. [Figure 1] This is a schematic diagram of an application scenario provided by the embodiments of the present application. [Figure 2] This is a flowchart of the vehicle bus malfunction recording method provided by the embodiment of the present invention. [Figure 3] This is a schematic diagram of the partitioning of a partial network cluster provided by the embodiment of the present invention. [Figure 4] This is a flowchart of a method for recording another vehicle bus malfunction provided by an embodiment of the present invention. [Figure 5] This is a flowchart of the procedure for recording wake-up recording messages at the main domain control node provided by the embodiment of the present application. [Figure 6] This is a schematic diagram of the structure of a vehicle bus failure recording device provided by an embodiment of the present invention. [Figure 7] This is a schematic diagram of the structure of another vehicle bus fault recording device provided by an embodiment of the present invention. [Figure 8] This is a schematic diagram of the structure of the electronic device provided by the embodiment of the present application. [Modes for carrying out the invention]

[0031] Clear embodiments of the present invention are shown through the above drawings, and a detailed description will follow. These drawings and descriptions are not intended to limit the scope of the concept of the present invention in any way, but are provided as a reference for those skilled in the art to understand the concept of the present invention by referring to specific embodiments.

[0032] To clarify the purpose, technical solutions, and advantages of the embodiments of this application, the technical solutions will be described clearly and completely below with reference to the embodiments and related drawings of this application. Naturally, the embodiments described are only a part of the embodiments of this application, not all of them. All other embodiments obtained by a person skilled in the art without creative work based on the embodiments of this application are all within the scope of protection of this application.

[0033] Figure 1 is a schematic diagram of an application scenario provided by an embodiment of the present invention. As shown in Figure 1, the vehicle can be equipped with an electronic control unit (ECU), a main domain control node, and memory.

[0034] The ECU can send a wake-up recording message to the main domain control node, which can record the wake-up recording message and store it in memory. Through the wake-up recording message, the cause of the vehicle's battery depletion problem can be accurately identified.

[0035] In the vehicle development and design process, in order to reduce power consumption and avoid starting failure due to excessive depletion of battery power, partial network nine( Partial Network (PN) management The following features have begun to be introduced. A network communication channel is established when necessary, taking into account the requirements of the functional scenario and when information exchange with the outside is required. This is a concept in which network communication is only established when PN is enabled, and it is a method for grouping and controlling network communication. Assuming functional implementation, the sleep state and wake-up of the entire vehicle are achieved by finding a path that minimizes controller wake-up. PN can be implemented through a Virtual Function Cluster (VFC) and a Partial Network Cluster (PNC). A VFC groups and communicates mutual signals between one or more vehicle functions, and VFC development work is carried out in parallel with subsystem design. Each VFC has a specific function defined, and in order to exchange mutual signals under these functions, it is necessary to map to a specific VFC. Through power modes, unified requirements regarding the functional effectiveness of the entire vehicle are established, user intentions are translated into a form that the vehicle can recognize, and functions are instructed to be executed when they are available. A standby mode is defined, and in the hibernation state, functional limitations are applied, and only some low-power functions are in standby mode. User activation is required, and after activation, functionality can be enabled and subsequent operations can be performed. A PNC is a signal group spanning multiple ECU signals, focused on network signal levels and identified to support the functionality of the entire vehicle. Each group is called a PNC, referring to the grouping of signals. Its essence lies in reducing power consumption by enabling the wake-up and sleep of necessary nodes according to their function. As the electronic and electrical systems of vehicles become more complex, the number of ECUs that are constantly powered from the battery increases, making it inevitable that vehicle battery depletion problems will occur.

[0036] In related technologies, when vehicle battery depletion problems occur, they are mostly accidental. However, identifying these problems consumes a large amount of human, vehicle, and device resources, and involves inspecting each ECU one by one through problem reproduction, thus reducing the efficiency of resolving vehicle battery depletion problems.

[0037] In the embodiment of the present invention, after an ECU is woken up, it sends a wake-up record message to the ECU's main domain control node according to a predetermined period. When it is detected that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record message sent from at least one ECU under its control and stores the wake-up record message of at least one ECU in the vehicle's memory. By investigating the cause of the ECU wake-up in the wake-up record message, the cause of the vehicle's battery depletion problem can be accurately identified, improving the efficiency of resolving the vehicle's battery depletion problem.

[0038] The technical measures presented in this application will be described in detail below through specific embodiments. Note that the following embodiments may exist individually or in combination with each other, and identical or similar content will not be repeated in different embodiments.

[0039] Figure 2 is a flowchart of a vehicle bus failure recording method provided by an embodiment of the present invention. As shown in Figure 2, this method may include steps S101 to S103.

[0040] In S101, after the ECU is woken up, a wake-up record message is sent to the ECU's main domain control node according to a predetermined cycle.

[0041] Abnormal sleep and wake-up of a vehicle are caused by the vehicle's ECU being in a wake-up state. After the ECU wakes up, it can send an abnormal wake-up message to the main domain control node at specific time intervals. The wake-up log message sent from each ECU includes a field indicating the ECU identifier and a field indicating the cause of the ECU wake-up.

[0042] In certain embodiments, multiple main domain control nodes can be configured within the vehicle to record different bus failures. For example, the main domain control nodes that can be configured include a cabin domain control node, an intelligent driving domain control node, a powertrain domain control node, and a body domain control node.

[0043] Selectively, different ECUs can be classified into the vehicle's cabin domain, intelligent driving domain, powertrain domain, body domain, and chassis domain. For example, an ECU in the body domain may include electronic control unit 1 (ECU1), electronic control unit 2 (ECU2), electronic control unit 3 (ECU3), and electronic control unit 4 (ECU4). Of these, ECU1 may be the air conditioning control module, ECU2 the interior lighting control module, ECU3 the battery management module, and ECU4 the seat control module.

[0044] Selectively, wake-up sources can be classified into active wake-up and passive wake-up. Active wake-up: The ECU acts as the primary wake-up node and actively wakes up when it detects an input signal from an active wake-up source. Network ManagementThe ECU attempts to wake up other ECUs by sending a frame (NM Frame). This is a request from within the module to the network. Passive Wake up: As a dependent wake-up node, the ECU cannot actively wake up on its own and only wakes up by receiving a network management message sent from another ECU.

[0045] In certain embodiments, each wake-up log message may contain 8 bytes, with each byte corresponding to 8 bits. Byte0 corresponds to the Source Node identifier, and each ECU is assigned a unique identifier that notifies the receiving node of the source node of the NM PDU (NM Protocol Data Unit). Table 1 shows examples of NM PDU formats. [Table 1]

[0046] In certain embodiments, the wake-up log message further includes a field indicating the current network state and a field indicating the PNC. For example, in the wake-up log message, the field indicating the current network state is Byte1, which corresponds to the Control Bit Vector (CBV) and can contain 8 bits. Bit0 corresponds to the duplicate message request; a value of 0 indicates that no duplicate message is requested, and a value of 1 indicates that a duplicate message is requested. Bit4 corresponds to the active wake-up bit; a value of 0 indicates that the network has not been woken up at the node (i.e., passive wake-up), and a value of 1 indicates that the network has been woken up at the node (i.e., active wake-up). Bit3 corresponds to the network management sleep adjustment bit. Bit6 corresponds to the partial network information bit. The remaining Bits 1, 2, 5, and 7 are reserved and can be defined by the user as needed.

[0047] Selectively , Ne Based on network segments and power consumption, PNC boundaries can be clearly defined, allowing the vehicle's domain controllers to be divided into different PNCs and woken up accordingly. In this case, Bytes 2 through 5 in the wake-up log message can be mapped to different PNC bits. In Automotive Open System Architecture (Autosar) versions 4.0.3 and 4.2.2, Table 2 shows examples of the corresponding positions of Bytes 2 through 5 for PNC bits. [Table 2]

[0048] Selectively, in Autosar version 4.2.2, the valid PNC bits within Byte2 are PNC16 to PNC23. A value of 1 for PNC16 indicates that PNC16 is valid, while a value of 0 indicates that it is invalid.

[0049] To further clarify the relationship between the ECU, PNC, and VFC, the ECU, PNC, and VFC corresponding to the bus will be described in detail with reference to Figure 3.

[0050] Figure 3 is a schematic diagram of the division of a partial network cluster provided by an embodiment of the present invention. As shown in Figure 3, electronic control units 1, 2, 3, and 4 are connected via a bus. The bus can be a CAN bus, a CANFD bus, or an FR daisy-chain bus. From the viewpoint of functional implementation, electronic control units 1 and 2 can be divided into one set, and electronic control units 3 and 4 into another set. That is, the actual physical bus can be divided into two independent network subgroups, partial network cluster 1 (PNC1) and partial network cluster 2 (PNC2), enabling synchronous sleep and wake-up of subgroup members. The virtual function cluster is used to realize port-level communication between software components necessary to implement one or more vehicle functions. The virtual function cluster network is configured by connecting ports between software components necessary to implement vehicle functions.

[0051] In certain embodiments, Bytes 6 to 7 record the wake-up cause for each ECU as the ECU wake-up cause bit. Each wake-up cause occupies one coding (bit), and there can be up to 256. When the corresponding VFC activation conditions are met and the ECU actively wakes up, the corresponding wake-up cause can be set as a bit. Examples of wake-up cause IDs and codings are shown in Table 3. [Table 3]

[0052] In certain embodiments, the field indicating the ECU wake-up cause in the wake-up log message is used to indicate the VFC that triggers the ECU wake-up. For example, if ECU1 and ECU2 constitute PNC1, this PNC1 corresponds to the seat comfort function and is identified in Virtual Function Cluster 1 (VFC1). Assigning a wake-up cause ID number to the seat comfort function results in wake-up_cause_667949, which corresponds to the bit value 0x0000 in the wake-up cause field.

[0053] For example, when ECU1 is activated after being woken up, it sends a wake-up log message to the body domain control node at 500ms intervals.

[0054] In S102, when it is detected that the vehicle sleep failure detection conditions are met, the main domain control node receives a wake-up log message sent from at least one ECU under its control.

[0055] The main domain control node is woken up by a wake-up log message sent from the ECU during the sleep cycle. By identifying the active wake-up bit corresponding to Bit 4 in the wake-up log message, and the active wake-up bit of the main domain control node itself, it is possible to determine which ECU has actively woken up the network. The vehicle is currently vehicle Sleep mode failure Detection conditions If the condition is detected, it can receive wake-up log messages sent from at least one ECU connected to and controlled by the bus.

[0056] Selectively, the vehicle sleep failure detection condition can be the condition in which the body domain control node has been woken up by a wake-up recording message while in sleep mode, and the powertrain domain node has not sent a signal indicating that the vehicle is charging.

[0057] For example, if the body domain control node is woken up by ECU1 during the sleep cycle, and no signal indicating that the vehicle is charging is being sent from the powertrain domain node, a wake-up record message sent from ECU1, which is connected to and controlled by the CAN bus, can be received.

[0058] In the S103, the wake-up recording message of at least one ECU is stored in the vehicle's memory.

[0059] When the main domain control node receives a wake-up message from the ECU, the wake-up message can be stored in a newly added electrically erasable programmable read-only memory (EEPROM).

[0060] Selectively, the EEPROM can store data that caused the vehicle to go into abnormal sleep mode and wake up abnormally. The required EEPROM capacity for storing data that caused the vehicle to go into abnormal sleep mode is 5.36 Kbit, and the required EEPROM capacity for storing data that caused the vehicle to wake up abnormally may be 2.16 Kbit.

[0061] For example, when a wake-up recording message for ECU1 is received in the body domain control node, the wake-up recording message can be stored in a newly added EEPROM.

[0062] In the embodiment of the present invention, after an ECU is woken up, it sends a wake-up record message to the ECU's main domain control node according to a predetermined period. When it is detected that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record message sent from at least one ECU under its control and stores the wake-up record message of at least one ECU in the vehicle's memory. By investigating the cause of the ECU wake-up in the wake-up record message, the cause of the vehicle's battery depletion problem can be accurately identified, improving the efficiency of resolving the vehicle's battery depletion problem.

[0063] The method for recording vehicle bus malfunctions will be described in detail below, based on the embodiment shown in Figure 2 and with reference to Figure 4.

[0064] Figure 4 is a flowchart of another vehicle bus failure recording method provided by an embodiment of the present invention. As shown in Figure 4, this method may include S201 to S206.

[0065] In S201, after the ECU is woken up, a wake-up record message is sent to the ECU's main domain control node according to a predetermined cycle.

[0066] For details on the execution process of step S201, please refer to the specific execution process of step S101. It will not be explained again here.

[0067] In S202, if the vehicle's power switch is turned off and a first predetermined time has elapsed since the vehicle security mode was activated, and the main domain control node is in a wake-up state and the vehicle is not in a charging state, then it is determined that the vehicle sleep fault detection condition is met.

[0068] When the main domain control node determines that it is necessary to record a wake-up message, the vehicle vehicle Sleep mode failure detection The first step is to determine that the conditions are met. Specifically, when implementing this, it is necessary that the main domain control node is in a wake-up state, the vehicle is not in a charging state, and at the same time, the timer activation conditions are met and a first predetermined time has elapsed since the vehicle security mode was activated.

[0069] In certain embodiments, there are two scenarios in which the vehicle meets the sleep failure conditions:

[0070] Scenario 1: In the main domain control node, with the vehicle power off, i.e., the engine ignition (IGN) switch off (IGN15 OFF), the sleep fault detection timer is activated after receiving a security signal (AlrmSts=0x1) via remote control of the entire vehicle, and the wake-up time of the main domain control node is longer than a first predetermined time elapsed since the vehicle security mode was activated.

[0071] Scenario 2: The main domain control node is woken up from sleep by a wake-up recording message, the main domain control node determines that the vehicle is powered off, i.e., the engine ignition switch is off (IGN15 OFF), and after receiving a security signal (AlrmSts=0x1) from the remote control of the entire vehicle, it activates the abnormal wake-up timer, and the wake-up time of the main domain control node is the first predetermined time.

[0072] Furthermore, in scenario 1 or scenario 2, the sleep failure detection timer or wake-up failure detection timer can be canceled if any of the following conditions are met. Condition 1: A vehicle-wide non-security signal (AlrmSts≠0x1) is being transmitted from the body domain control note. Condition 2: The vehicle's engine ignition switch is ON (IGN15 ON).

[0073] In S203, if a first signal indicating that the vehicle is charging is received from the powertrain domain node, the system determines that the vehicle is in a charging state.

[0074] When the main domain control node acquires a wake-up log message, it is necessary to determine whether the vehicle is charging, thereby preventing the main domain control node from being woken up due to the vehicle being in a charging state. Specifically, when the main domain control node receives a first signal from the powertrain domain node indicating that the vehicle is charging, it can be determined that the vehicle is in a charging state, and conversely, it can be determined that the vehicle is not in a charging state.

[0075] For example, if a vehicle is powered off and a security signal is transmitted via remote control of the entire vehicle, the powertrain domain node will transmit a first signal, ChrgnSts=0x1, indicating that it is charging, meaning the vehicle is charging. If the body domain control node receives the first signal, ChrgnSts=0x1, indicating that the vehicle is charging, it can be determined that the vehicle is charging. Conversely, if the body domain control node does not receive the first signal, ChrgnSts=0x1, indicating that the vehicle is charging, it means the vehicle is not charging.

[0076] In S204, when it is detected that the vehicle sleep failure detection conditions are met, the main domain control node receives a wake-up log message sent from at least one ECU under its control.

[0077] Currently, the vehicle is in the main domain control node vehicle Sleep mode failure detection If the conditions are detected to be met, a wake-up log message sent from at least one ECU connected to the bus can be received.

[0078] In Scenario 1, if the vehicle meets the sleep failure conditions, i.e., the main domain control node is continuously woken up and the duration exceeds a first predetermined time, the main domain control node records a wake-up log message for the ECU that is currently maintaining network wake-up within the predetermined time. The time signal is the time signal of the last received frame, and the time value follows the recording format of year, month, day, hour, minute, second, with the time signal transmitted from the body domain controller as the reference. If no time signal is received, the last frame transmitted from the body domain controller is used as the reference.

[0079] This wake-up cycle ends when the vehicle's engine ignition switch is turned on, when the entire vehicle is not in security mode, or when the sleep fault detection timer has timed out.

[0080] To more clearly illustrate the procedure for recording wake-up log messages on the main domain control node, refer to Figure 5 to explain the conditions that must be met when recording wake-up log messages on the main domain control node.

[0081] Figure 5 is a flowchart of the procedure for recording a wake-up recording message at the main domain control node provided by the embodiment of the present invention. As shown in Figure 5, this procedure includes S301 to S307.

[0082] In S301, it is determined whether the vehicle is powered off, i.e., (IGN15=OFF). If so, execute S302; otherwise, execute S307.

[0083] In S302, it is determined whether the entire vehicle is in security mode, i.e., (AlrmSts=0x1). If so, execute S303; otherwise, execute S307.

[0084] S303 initiates sleep failure detection.

[0085] S304 determines whether the main domain control node has been continuously woken up for more than 10 minutes. If so, S 305 Execute that, otherwise execute S307.

[0086] In S305, it is determined whether or not the first signal (ChrgnSts=0x1) has been transmitted from the powertrain domain node. If so, execute S306; otherwise, execute S307.

[0087] S306 records a wake-up message.

[0088] S307 does not record wake-up message.

[0089] For example, if a vehicle meets sleep failure conditions, and the body domain control node is continuously woken up for a duration exceeding 10 minutes, the body domain control node records a wake-up log message sent from ECU1, which is currently maintaining network wake-up, within 2 seconds. The recorded time value is the time signal when the last frame transmitted from the body domain controller was received, and the time signal can be set to 10:10:10 on May 18, 2020.

[0090] In scenario 2, the main domain control node is woken up from sleep by a wake-up recording message, and wakes up within a predetermined first time. The main domain control node identifies which ECU actively woke up the network by identifying the active wake-up bit corresponding to Bit 4 in all wake-up recording messages of the ECUs, increments the abnormal wake-up count of the main domain control node by 1, and records the wake-up recording message of the corresponding node when the time exceeds a predetermined second time. Simultaneously, the number of wake-ups of the main domain control node within one sleep cycle can be accumulated, and by setting an upper limit, if the number of wake-ups of the main domain control node within one sleep cycle reaches the set upper limit, the main domain control node can record all wake-up recording messages sent from the ECUs of the main domain control node that were woken up within that sleep cycle.

[0091] Specifically, when determining which ECU has actively woken up the network by identifying all ECUs at the main domain control node, the step also includes identifying the active wake-up bit of the main domain control node itself.

[0092] Selectively, the second predetermined time measures the time the ECU remains in the wake-up state after being woken up, and each time the second predetermined time is reached, the main domain control node can record a wake-up record message for the ECU. For example, the predetermined second time can be 30 minutes.

[0093] Selectively, the configurable upper limit refers to the maximum number of wake-ups for the main domain control node within a single sleep cycle. If the number of wake-ups for the main domain control node within a single sleep cycle reaches the configurable upper limit, wake-up log messages sent from the ECUs of all main domain control nodes that were woken up during that sleep cycle can be recorded. For example, the configurable upper limit can be set to 15 times.

[0094] This sleep cycle ends when the vehicle's engine ignition switch is turned on, when the entire vehicle is not in security mode, or when the wake-up count of the main domain control node reaches its maximum limit.

[0095] For example, if a body domain control node sleeps and is woken up by a wake-up recording message, and the wake-up occurs within 1 second, and the body domain control node determines that ECU1 has actively woken up the network by identifying Bit 4 in all ECU wake-up recording messages, the abnormal wake-up count of the body domain control node is incremented by 1, and when the time exceeds 30 minutes, the wake-up recording message for the corresponding ECU1 can be recorded. Simultaneously, the number of wake-ups of the body domain control node within a single sleep cycle can be accumulated, and when the upper limit of 15 wake-ups is reached, the body domain control node can record all wake-up recording messages sent from ECU1, ECU2, and ECU3 that woke up the body domain control node within that sleep cycle.

[0096] In the S205, the wake-up recording message from at least one ECU is stored in the vehicle's memory.

[0097] The vehicle vehicle Sleep mode failure detectionAfter the conditions are met and a wake-up recording message for at least one ECU is recorded in the main domain control node, the wake-up recording message can be analyzed to obtain the information contained in Byte0, Byte6, and Byte7 of the message, combine the information, and store it in the vehicle's EEPROM.

[0098] Optionally, a diagnostic module can be added to memory to store the wake-up log messages after analysis. The diagnostic module is divided into two areas. Area 1 can be configured with five groups to store abnormal wake-up fault codes, designated as Group 1, Group 2, ..., and Group 5, each storing 54 bytes of abnormal wake-up fault codes. Area 2 can also be configured with five groups to store abnormal sleep fault codes, designated as Group 1, Group 2, ..., and Group 5, each storing 134 bytes of abnormal sleep fault codes. Group 1 stores the most recently occurring fault information, and Group 5 stores the oldest fault information. Whenever new fault information occurs, it is stored in Group 1, and the original Group 1 data is moved to Group 2. This process is repeated until the fault information of the last group is pushed out of the queue.

[0099] For example, the 54 bytes of Group 1 in area 1 of the diagnostic module can be used to monitor the location corresponding to each network segment of the ECU and store the information of Byte 0, Byte 6, and Byte 7 after parsing the wake-up log message. Some examples of bytes and the ECU locations to be monitored are shown in Table 4. [Table 4]

[0100] In S206, according to a predetermined data upload cycle, wake-up log messages for at least one ECU stored in memory that have not yet been uploaded are uploaded to the cloud server.

[0101] When recording the wake-up log messages of the analyzed ECUs in memory, if the memory storage capacity reaches its limit, at least one ECU wake-up log message that has not yet been uploaded and is currently stored in memory can be uploaded to the cloud server via a remote communication terminal (Telematics Box, TBOX). If an abnormal condition occurs throughout the vehicle, the problem investigator can obtain vehicle-wide abnormality data via the cloud. After obtaining the abnormality data, the specific wake-up cause can be identified using bus data in combination with predefined network management messages and wake-up cause coding codes.

[0102] Selectively, the predetermined data upload cycle can be the number of post-analysis wake-up message entries recorded in memory. For example, the upload operation to the cloud can be performed every time memory records five post-analysis wake-up message entries.

[0103] In certain embodiments, the cause that triggered the wake-up of the main domain control node can be identified from predefined network management messages using an ID corresponding to the wake-up cause. Each VFC's activation condition is a single wake-up cause (ID). Examples of predefined network management messages are shown in Table 5. [Table 5]

[0104] For example, when recording five ECU wake-up message records after analysis in memory, once the memory storage capacity reaches its limit, the five ECU wake-up message records stored in memory that have not yet been uploaded can be uploaded to the cloud server via TBOX. If an abnormal condition occurs throughout the vehicle, the problem investigator can retrieve the vehicle-wide abnormality data from the cloud. The coding code obtained here can be 0x0000, which indicates that the wake-up cause is 667949. By referring to the predefined network management messages and checking the ECU wake-up cause (ID) and wake-up maintenance cause, it can be identified that the cause corresponding to wake-up cause_667949 is a wake-up caused by the seat comfort function. This makes it possible to quickly identify that the cause of the vehicle's inability to sleep is an abnormality in the seat comfort function related to the body domain control node.

[0105] In the embodiment of the present invention, after an ECU is woken up, it can send a wake-up record message to the ECU's main domain control node according to a predetermined period. After a first predetermined time has elapsed since the power to the vehicle's switch was turned off and the vehicle security mode was activated, if the main domain control node is in a wake-up state and the vehicle is not in a charging state, it is determined that the vehicle sleep fault detection condition is met. If a first signal indicating that the vehicle is charging is received from the powertrain domain node, it is determined that the vehicle is in a charging state. When it is detected that the vehicle sleep fault detection condition is met, the main domain control node receives wake-up record messages sent from at least one ECU under its control, stores the wake-up record messages of at least one ECU in the vehicle's memory, and uploads the wake-up record messages of at least one ECU that have not yet been uploaded, which are stored in memory, to the cloud server according to a predetermined data upload period. In the above process, if an abnormal battery shortage occurs in the vehicle, the problem investigator can obtain vehicle-wide abnormality data via the cloud. After acquiring abnormal data, the bus data can be used to identify the specific cause of the wake-up using the wake-up cause coding code, thereby improving the efficiency of resolving vehicle battery depletion problems.

[0106] Figure 6 is a schematic diagram of the structure of a vehicle bus fault recording device provided by an embodiment of the present invention. As shown in Figure 6, the vehicle bus fault recording device 10 is When it is detected that the vehicle sleep failure detection conditions are met, the main domain control node has a receiving module 11 for receiving a wake-up recording message sent from at least one ECU under its control, The system includes a storage module 12 for storing the wake-up recording message of at least one ECU in the vehicle's memory, The wake-up log message sent from each ECU includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

[0107] The vehicle bus failure recording device provided by the embodiment of the present application is capable of implementing the technical measures shown in the embodiment of the above method, and its implementation principle and beneficial effects are similar and therefore will not be described again here.

[0108] In one possible embodiment, the vehicle bus failure recording device 10 is The system further includes an upload module 13 for uploading wake-up record messages of at least one ECU stored in the memory that have not yet been uploaded to a cloud server, according to a predetermined data upload cycle.

[0109] In one possible embodiment, the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0110] In one possible embodiment, the field in the wake-up log message indicating the cause of the ECU wake-up is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0111] In one possible embodiment, the vehicle bus failure recording device 10 is The system further includes a first determination module 14 for determining that the vehicle sleep failure detection condition is met if, after a first predetermined time has elapsed since the power to the vehicle's switch was cut off and the vehicle security mode was activated, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

[0112] In one possible embodiment, the vehicle bus failure recording device 10 further comprises a second determination module 15, the second determination module 15 is When a first signal is received from the powertrain domain node indicating that the vehicle is being charged, it is determined that the vehicle is in a charging state, and Otherwise, it is used to determine that the vehicle is not in a charging state.

[0113] The vehicle bus failure recording device provided by the embodiment of the present application is capable of implementing the technical measures shown in the embodiment of the above method, and its implementation principle and beneficial effects are similar and therefore will not be described again here.

[0114] Figure 7 is a schematic diagram of the structure of another vehicle bus fault recording device provided by an embodiment of the present application. As shown in Figure 7, the vehicle bus fault recording device 20 is After the ECU is woken up, a processing module 21 is provided for sending a wake-up record message to the main domain control node of the ECU according to a predetermined period, the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

[0115] In one possible embodiment, the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

[0116] In one possible embodiment, the field in the wake-up log message indicating the cause of the ECU wake-up is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

[0117] The vehicle bus failure recording device provided by the embodiment of the present application is capable of implementing the technical measures shown in the embodiment of the above method, and its implementation principle and beneficial effects are similar and therefore will not be described again here.

[0118] Figure 8 is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. As shown in Figure 8, the electronic device 30 may include a processor 31, memory 32, and a communication interface 34. Exemplarily, the processor 31, memory 32, and communication interface 34 are interconnected via a bus 33.

[0119] The memory 32 stores computer execution instructions. When the processor 31 executes a computer execution instruction stored in the memory 32, the processor 31 executes the method provided by the embodiment of the above method.

[0120] The electronic device shown in Figure 8 can be implemented in a specific application as any of the main domain control nodes or any of the ECUs in the vehicle in the embodiments of the method described above, and this technical solution is not limited thereto.

[0121] Embodiments of the present application provide a computer-readable storage medium in which computer execution instructions are stored, and when the computer execution instructions are executed by a processor, the method described in any of the embodiments of the above method is realized.

[0122] Embodiments of the present application provide a chip comprising a memory and a processor, wherein the memory stores code and data, the memory is coupled with the processor, and when the processor executes a program in the memory, the chip performs the method according to any embodiment of the above method.

[0123] Embodiments of the present application provide a program product comprising a computer program, wherein when the program product is executed on a computer, the computer performs the method described in any of the embodiments of the above method.

[0124] Embodiments of the present invention provide a computer program which, when executed by a processor, performs the method described in any of the embodiments of the above method.

[0125] Those skilled in the art should understand that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of complete hardware embodiments, complete software embodiments, or embodiments combining software and hardware. Furthermore, the present invention can take the form of a computer program product that runs on one or more computer-available storage media (including, but not limited to, disk storage devices, CD-ROMs, optical storage devices, etc.) containing computer-available program code.

[0126] The present invention will be described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products based on embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. By providing these computer program instructions to the processor of a general-purpose computer, a dedicated computer, an embedded processor, or other programmable data processing device, it is possible to provide a machine in which instructions executed by the processor of a computer or other programmable data processing device generate apparatus for implementing one or more processes in a flowchart and / or one or more blocks in a block diagram.

[0127] These computer program instructions can also be stored in a computer-readable storage device that can direct a computer or other programmable data processing device to operate in a particular manner, and the instructions stored in this computer-readable storage device generate a product having an instruction unit that implements functions specified in one or more processes of a flowchart and / or one or more blocks of a block diagram.

[0128] These computer program instructions can also be loaded into a computer or other programmable data processing device, which then executes a series of operational steps on the computer or other programmable device to generate computer-generated processing. Thus, the instructions executed on the computer or other programmable device provide steps for implementing one or more processes in a flowchart and / or one or more blocks in a block diagram.

[0129] In a typical configuration, a computing device comprises one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0130] Memory can take various forms, including non-persistent storage devices in computer-readable media, such as random-access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

[0131] Computer-readable media include persistent and non-persistent, portable and non-portable media, and information can be stored by any method or technique. Information may be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only disks, read-only memory (CD-ROM), digital multi-purpose disks (DVDs) or other optical disk storage, tapes, disk storage or other magnetic storage devices, or other non-transmission media that can be used to store computer-accessible information. As defined herein, computer-readable media does not include transient computer-readable media such as modulated data signals or carrier waves.

[0132] The terms “include,” “contain,” or variations thereof are intended to imply non-exclusive inclusion, meaning that a process, method, product, or apparatus containing a set of elements includes not only those elements but also other elements not explicitly listed, or elements specific to that process, method, product, or apparatus. Unless otherwise specified, an element limited by the phrase “includes one…” does not preclude the existence of another identical element in the process, method, product, or apparatus containing that element.

[0133] The above describes only embodiments of the present application and does not limit it. Those skilled in the art can make various modifications and alterations to the present application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present application should be included within the scope of the claims.

[0134] <Cross-reference of related applications> This application claims priority to the Chinese patent application filed with the China National Intellectual Property Administration on November 29, 2023, with application number 2023116390779 and application title "Method, apparatus, device and storage medium for recording vehicle bus malfunctions," and all contents of the aforementioned Chinese patent application are incorporated into this application by reference.

Claims

1. A method for recording a vehicle bus failure applied to any main domain control node within a vehicle, When it is detected that the vehicle sleep failure detection conditions are met, the main domain control node receives a wake-up recording message transmitted from at least one electronic control unit (ECU) under its control; The process includes the step of storing the wake-up recording message of the at least one ECU in the vehicle's memory, A method for recording vehicle bus malfunctions, characterized in that the wake-up recording message transmitted from each ECU includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

2. The aforementioned method, The method according to claim 1, further comprising the step of uploading to a cloud server a wake-up record message of at least one ECU stored in the memory that has not yet been uploaded, in accordance with a predetermined data upload cycle.

3. The method according to 1 or 2, characterized in that the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

4. The method according to any one of claims 1 to 3, characterized in that the field indicating the cause of the ECU wake-up in the wake-up recording message is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

5. The aforementioned method, The method according to any one of claims 1 to 4, further comprising the step of determining that the vehicle sleep fault detection condition is met if, after a first predetermined time has elapsed since the power to the vehicle's switch was cut off and the vehicle security mode was activated, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

6. The aforementioned method, When a first signal indicating that the vehicle is being charged is received from the powertrain domain node, the step of determining that the vehicle is in a charging state, The method according to any one of claims 1 to 5, further comprising the step of determining that otherwise the vehicle is not in a charging state.

7. A method for recording vehicle bus faults applied to any electronic control unit (ECU) within a vehicle, A method for recording a vehicle bus malfunction, comprising the step of sending a wake-up record message to the main domain control node of the ECU according to a predetermined period after the ECU has been woken up, wherein the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU wake-up.

8. The method according to claim 7, characterized in that the wake-up recording message further includes a field indicating the current network state and a field indicating a partial network cluster (PNC).

9. The method according to 7 or 8, characterized in that the field indicating the cause of the ECU wake-up in the wake-up recording message is used to indicate a virtual function cluster (VFC) that triggers the ECU wake-up.

10. This is a vehicle / bus malfunction recording device, When it is detected that the vehicle sleep failure detection conditions are met, a receiving module for receiving a wake-up log message sent from at least one electronic control unit (ECU) under the control of the main domain control node, The system includes a storage module for storing the wake-up recording message of at least one ECU in the vehicle's memory, A vehicle bus fault recording device, wherein each wake-up recording message transmitted from an ECU includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU's wake-up.

11. This is a vehicle / bus malfunction recording device, A vehicle bus fault recording device comprising a processing module for sending a wake-up record message to the main domain control node of the ECU according to a predetermined period after the ECU has been woken up, wherein the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the cause of the ECU wake-up.

12. An electronic device comprising a processor, memory and a communication interface, The aforementioned memory stores computer execution instructions, An electronic device characterized in that when the processor executes a computer execution instruction stored in the memory, the processor performs the method according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that it stores computer execution instructions, and when the computer execution instructions are executed by a processor, the method according to any one of claims 1 to 9 is realized.

14. A chip comprising memory and a processor, wherein the memory stores code and data, the memory is coupled with the processor, and when the processor executes a program in the memory, the chip performs the method according to any one of claims 1 to 9.

15. A program product comprising a computer program, wherein when the program product is executed on a computer, the computer performs the method described in any one of claims 1 to 9 above.

16. A computer program characterized in that, when executed by a processor, the method described in any one of claims 1 to 9 is performed.

Images