Vehicle bus fault recording method and device, equipment and storage medium

Abstract

The invention provides a vehicle bus fault recording method and device, equipment and a storage medium. The method comprises the steps that after the ECU is awakened, an awakening record message can be sent to a main domain control node of the ECU according to a preset period, and when it is detected that a vehicle dormancy fault detection condition is met, the main domain control node receives the awakening record message sent by at least one ECU controlled by the main domain control node and stores the awakening record message of the at least one ECU into a storage of a vehicle. When abnormal power shortage occurs in the vehicle, a problem checking worker can find the specific wake-up reason of the vehicle through the wake-up record message, so that the efficiency of solving the power shortage problem of the vehicle is improved.

Description

Technical Field

[0001] This application relates to the technical field of vehicles, and in particular, to a method, device, equipment, and storage medium for recording vehicle bus faults. Background Art

[0002] In recent years, the energy-saving problem of vehicles has attracted much attention, and reducing unnecessary power consumption is a very effective method. To reduce power consumption and avoid the vehicle being unable to start due to excessive power consumption of the battery, a local network management method is mostly adopted to realize the orderly sleep and wake-up of the vehicle's electronic control units through virtual function clusters and local network clusters. The units sleep when there is no communication requirement and wake up when communication is needed, thereby saving the power of the vehicle's battery.

[0003] However, as the vehicle's electronic and electrical systems become more and more complex, the number of electronic control units constantly powered by the battery is also increasing, and the problem of vehicle power loss will inevitably occur.

[0004] In the related art, once the vehicle has a power loss problem, the way to locate the problem is to consume a large amount of human resources, vehicle resources, and equipment resources, and check the electronic control units one by one through the way of problem reproduction, resulting in low efficiency in solving the vehicle power loss problem. Summary of the Invention

[0005] This application provides a method, device, equipment, and storage medium for recording vehicle bus faults, which can improve the efficiency of solving the vehicle power loss problem.

[0006] In a first aspect, this application provides a method for recording vehicle bus faults, which is applied to any main domain control node in a vehicle. The method includes:

[0007] When detecting that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one electronic control unit (ECU) under its control; each wake-up record message sent by an ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

[0008] Store the wake-up record messages of the at least one ECU in the vehicle's memory.

[0009] In a possible implementation manner, the method further includes:

[0010] According to a preset data upload period, upload the un-uploaded wake-up record messages of at least one ECU stored in the memory to a cloud server.

[0011] In a possible implementation manner, the wake-up record message further includes: a field indicating the current network state and a field indicating the local network cluster (PNC).

[0012] In a possible implementation manner, the field in the wake-up record message indicating the wake-up reason of the ECU is used to indicate the virtual function cluster VFC that triggers the wake-up of the ECU.

[0013] In a possible implementation manner, the method further includes:

[0014] If after a first preset duration after the vehicle switch is powered off and the vehicle is armed, 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.

[0015] In a possible implementation manner, the method further includes:

[0016] If a first signal indicating that the vehicle is charging sent by the power domain node is received, it is determined that the vehicle is in a charging state;

[0017] Otherwise, it is determined that the vehicle is not in a charging state.

[0018] In a second aspect, the present application provides a method for recording vehicle bus faults, which is applied to any electronic control unit ECU in a vehicle. The method includes:

[0019] After the ECU is awakened, a wake-up record message is sent to the main domain control node of the ECU according to a preset period. The wake-up record message includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

[0020] In a possible implementation manner, the wake-up record message further includes: a field indicating the current network state, and a field indicating the partial network cluster PNC.

[0021] In a possible implementation manner, the field in the wake-up record message indicating the wake-up reason of the ECU is used to indicate the virtual function cluster VFC that triggers the wake-up of the ECU.

[0022] In a third aspect, the present application provides a device for recording vehicle bus faults. The device includes:

[0023] A receiving module, configured to, when detecting that the vehicle sleep fault detection condition is met, receive a wake-up record message sent by at least one electronic control unit ECU controlled by the main domain control node; the wake-up record message sent by each ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU;

[0024] A storage module, configured to store the wake-up record messages of the at least one ECU in a memory of the vehicle.

[0025] In a possible implementation, the device further includes:

[0026] An upload module, configured to upload at least one wake-up record message of an ECU stored in the memory to a cloud server according to a preset data upload period.

[0027] In a possible implementation, the wake-up record message further includes: a field indicating the current network status, and a field indicating a local network cluster PNC.

[0028] In a possible implementation, the field in the wake-up record message indicating the wake-up reason of the ECU is used to indicate a virtual function cluster VFC that triggers the wake-up of the ECU.

[0029] In a possible implementation, the device further includes:

[0030] A first determination module, configured to determine that the vehicle sleep fault detection condition is met if, after a first preset duration after the vehicle switch is powered off and the vehicle is armed, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

[0031] In a possible implementation, the device further includes: a second determination module, and the second determination module is configured to:

[0032] If a first signal indicating that the vehicle is charging sent by a power domain node is received, determine that the vehicle is in a charging state;

[0033] Otherwise, determine that the vehicle is not in a charging state.

[0034] In a fourth aspect, the present application provides a recording device for vehicle bus faults, and the device includes:

[0035] A processing module, configured to send a wake-up record message to the main domain control node of the ECU according to a preset period after the ECU is woken up, and the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

[0036] In a possible implementation, the wake-up record message further includes: a field indicating the current network status, and a field indicating a local network cluster PNC.

[0037] In a possible implementation, the field in the wake-up record message indicating the wake-up reason of the ECU is used to indicate a virtual function cluster VFC that triggers the wake-up of the ECU.

[0038] In a fifth aspect, the present application provides an electronic device, including: a processor, a memory, and a communication interface;

[0039] The memory stores computer-executable instructions;

[0040] The processor executes the computer-executable instructions stored in the memory, such that the processor executes the method according to any one of the first aspect or the second aspect.

[0041] In a sixth aspect, the present application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the method according to any one of the first aspect or the second aspect when executed by a processor.

[0042] In a seventh aspect, the present application provides a computer program product including a computer program, which implements the method according to any one of the first aspect or the second aspect when executed by a processor.

[0043] The method, device, equipment, and storage medium for recording vehicle bus faults provided by the present application can, after the ECU is awakened, send a wake-up record message to the main domain control node of the ECU according to a preset period. When detecting that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one ECU under its control and stores the wake-up record messages of the at least one ECU in the vehicle's memory. During the above process, the wake-up record messages sent by the ECU can be stored in the vehicle's memory. By searching for the ECU wake-up reasons in the wake-up record messages, the reasons causing the vehicle power loss problem can be accurately located, improving the efficiency of solving the vehicle power loss problem. Description of the Drawings

[0044] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. Here, the drawings are incorporated into the specification and constitute a part of the specification, and are used together with the specification to explain the principles of the present application.

[0045] Figure 1 It is a schematic diagram of the application scenario provided by the embodiment of the present application;

[0046] Figure 2 It is a flowchart of a method for recording vehicle bus faults provided by the embodiment of the present application;

[0047] Figure 3 It is a schematic diagram of PNC division provided by the embodiment of the present application;

[0048] Figure 4 It is a flowchart of another method for recording vehicle bus faults provided by the embodiment of the present application;

[0049] Figure 5 This is a flowchart of the process for the master domain control node to record the wake-up record message provided by the embodiment of the present application;

[0050] Figure 6 This is a schematic structural diagram of a recording device for vehicle bus faults provided by the embodiment of the present application;

[0051] Figure 7 This is a schematic structural diagram of another recording device for vehicle bus faults provided by the embodiment of the present application;

[0052] Figure 8 This is a schematic structural diagram of an electronic device provided by the embodiment of the present application.

[0053] Through the above-mentioned drawings, the clear embodiments of the present application have been shown, and there will be more detailed descriptions hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. Specific Embodiments

[0054] To make the objectives, technical solutions, and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with the specific embodiments and corresponding drawings of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the scope of protection of the present application.

[0055] Figure 1 This is a schematic diagram of the application scenario provided by the embodiment of the present application. Please refer to Figure 1 , a vehicle may be provided with an ECU (Electronic Control Unit), a master domain control node, and a memory.

[0056] The ECU may send a wake-up record message to the master domain control node, and the master domain control node may record the wake-up record message and store it in the memory. The reason for the vehicle's dead battery problem can be accurately located through the wake-up record message.

[0057] During the development and design process of a vehicle, in order to reduce power consumption and prevent the vehicle from failing to start due to excessive battery power consumption, PN (Partial NetWork) is introduced. When the functional scenario requires and there is a need to interact with external information, a network communication channel is established. Only when PN is turned on, there is a concept of communication on the network. It is a method of grouping and controlling network communication. On the premise of meeting the functional implementation, a path with minimized controller wake-up is found to achieve vehicle sleep and wake-up. PN can be implemented through VFC (Virtual Function Cluster) and PNC (Partial Network Cluster). Among them: VFC is used for grouped communication of the interaction signals (Signals) between one or more vehicle functions. The development work of VFC is synchronized with the subsystem design, and each VFC has a defined specific function. If interaction signals are required under these functions, they need to be mapped in a specific VFC. Through the power mode, a unified requirement for the effectiveness of vehicle functions is established, converting the user's intention into something recognizable by the vehicle, and guiding function execution when the function is available; the standby mode, rest, limited functions, and only some low-power consumption functions are in a pending activation state, and need to be activated by the user to be functionally effective, and the post-operation functions are available. PNC focuses on the network signal level and is a grouping of signals that cross multiple vehicle ECUs identified to support vehicle functions. Each group is called a PNC. Its essence is to wake up and sleep the necessary nodes according to the function implementation, so as to achieve the purpose of reducing power consumption. As the vehicle's electronic and electrical system becomes more and more complex, there are more and more ECUs constantly powered by the battery, and the problem of vehicle power shortage will inevitably occur.

[0058] In the related art, once the vehicle has a power shortage problem, most of them are occasional problems. The way to locate the problem is to consume a large amount of human resources, vehicle resources, and equipment resources, and check each ECU one by one through the way of problem reproduction, resulting in low efficiency in solving the vehicle power shortage problem.

[0059] In the embodiment of the present application, after the ECU is awakened, a wake-up record message can be sent to the main domain control node of the ECU according to a preset period. When it is detected that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one ECU under its control and stores the wake-up record messages of at least one ECU in the vehicle's memory. The reason for the vehicle's power shortage problem can be accurately located by finding the reason for the ECU wake-up in the wake-up record message, improving the efficiency of solving the vehicle power shortage problem.

[0060] Next, the technical solutions shown in this application will be described in detail through specific embodiments. It should be noted that the following several embodiments can exist independently or be combined with each other. For the same or similar content, it will not be repeated in different embodiments.

[0061] Figure 2 The flowchart of a method for recording vehicle bus faults provided by an embodiment of this application is shown. Please refer to Figure 2 This method may include:

[0062] S101. After the ECU is awakened, send a wake-up record message to the main domain control node of the ECU according to a preset period.

[0063] When the vehicle has abnormal dormancy and abnormal wake-up, it is because the ECU in the vehicle is in the wake-up state. After the ECU is awakened, an abnormal wake-up message can be sent to the main domain control node at a specific time interval. Among them, each wake-up record message sent by the ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

[0064] In a specific implementation manner, multiple main domain control nodes can be set in the vehicle to record different bus faults. For example, the set main domain control nodes can be a cockpit domain control node, an intelligent driving domain control node, a power domain control node, and a body domain control node.

[0065] Optionally, different ECUs can be divided into the cockpit domain, intelligent driving domain, power domain, body domain, and chassis domain of the vehicle. For example, the ECUs in the body domain may include: ECU1, ECU2, ECU3, and ECU4. Among them, ECU1 can be an air-conditioning control module, ECU2 can be an in-vehicle lighting control module, ECU3 can be a battery management module, and ECU4 can be a seat control module.

[0066] Optionally, the sources of wake-up can be divided into active wake-up and passive wake-up. Active Wakeup: The ECU acts as the main wake-up node. When it detects an active wake-up source input signal, it actively wakes itself up and tries to wake up other ECUs by sending an NMFrame (NM frame), which is a request from inside the module to the network; Passive Wakeup: The ECU acts as a slave wake-up node and cannot wake itself up actively. It can only wake itself up by receiving a network management message sent by other ECUs.

[0067] In a specific embodiment, each wake-up record message may include 8 Bytes (bytes), and each byte may correspond to 8 Bits (bit positions). Among them, Byte0 corresponds to the source node identifier. Each ECU will be assigned a unique identifier to inform the receiving node which node sent this NM PDU (NM Protocol Data Unit). The format of the NM PDU can be as shown in Table 1:

[0068] Table 1

[0069]

[0070] In a specific embodiment, the wake-up record message further includes: a field indicating the current network status, and a field indicating the PNC. For example, in the wake-up record message, the field indicating the current network status is Byte1, and Byte1 corresponds to the Control Bit Vector (CBV), which may contain 8 Bits. Among them: Bit0 corresponds to the repeated message request. If this bit is set to 0, it represents the state of not requesting a repeated message; if this bit is set to 1, it represents the state of requesting a repeated message; Bit4 corresponds to the active wake-up bit. If this bit is set to 0, it represents that the node has not woken up the network, i.e., passive wake-up; if this bit is set to 1, it represents that the node has woken up the network, i.e., active wake-up; Bit 3 corresponds to the network management sleep coordination bit; Bit6 corresponds to the partial network information bit; the remaining Bits 1, 2, 5, and 7 can be reserved and defined according to user requirements.

[0071] Optionally, the PNC can define the boundary of the PNC according to the network segment and power consumption, and divide the domain controllers of the vehicle into different PNCs for wake-up. Then, Byte2 - Byte5 in the wake-up record message can correspond to different PNC bits. Among them, in versions 4.0.3 and 4.2.2 of the Automotive Open System Architecture (Autosar), the corresponding positions of the PNC bits in Byte2 - Byte5 can be as shown in Table 2:

[0072] Table 2

[0073]

[0074] Optionally, in the Autosar 4.2.2 version, the valid PNC bits in Byte2 are PNC16 - PNC23. If the value corresponding to PNC16 is 1, it represents that PNC16 is effective; if it is 0, then PNC16 is ineffective.

[0075] To further illustrate the relationship among the ECU, PNC, and VFC, in combination with Figure 3 , the ECU, PNC, and VFC corresponding to the bus are described in detail.

[0076] Figure 3 FIG. Figure 3 shows a schematic diagram of PNC division provided by an embodiment of the present application. Refer to

[0077] , ECU1, ECU2, ECU3, and ECU4 are connected through a bus. The bus can be one of a CAN bus, a CANFD bus, and an FR daisy chain bus. Functionally differentiated, ECU1 and ECU2 can be grouped into one group, and ECU3 and ECU4 can be grouped into one group. That is, the actual physical bus can be divided into two independent network groups, PNC1 and PNC2, to achieve the same sleep and wake states of group members. The VFC is used to implement port-level communication between software components required for one or more vehicle functions. Connecting the ports between the software components required for implementing vehicle functions forms the VFC network.

[0078] Table 3

[0079]

[0080]

[0081] In a specific embodiment, Byte6-Byte7 is used as the ECU wake-up reason bit to record the wake-up reasons of each ECU. Each wake-up reason occupies one coding (bit), with a maximum of 256 in total. When this ECU actively wakes up when meeting the corresponding VFC activation condition, the corresponding wake-up reason can be set. Among them, the wake-up reason ID and Coding can be as shown in Table 3:

[0082] For example, in a specific embodiment, the field indicating the ECU wake-up reason in the wake-up record message is used to indicate the VFC that triggers the ECU wake-up. For example, ECU1 and ECU2 form a local network cluster PNC1. This local network cluster PNC1 can correspond to the seat comfort function, identified by VFC1. The seat comfort function can be numbered for the wake-up reason ID, and the numbering result can be: wake-up reason_667949, which corresponds to the bit value 0x0000 in the wake-up reason field.

[0083] S102. When detecting that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record message sent by at least one ECU under its control.

[0084] The main domain control node is woken up by the wake-up record message sent by the ECU during the sleep cycle. It can determine which ECU actively wakes up the network by identifying the active wake-up bit corresponding to Bit4 in the wake-up record message and the active wake-up bit of the main domain control node itself. When it is detected that the vehicle currently meets the sleep fault, it can receive the wake-up record messages sent by at least one ECU controlled on the bus.

[0085] Optionally, the vehicle sleep fault detection condition can be: after the body domain control node is woken up by the wake-up record message in the sleep state, the power domain node does not send a signal that the vehicle is charging.

[0086] For example, if the body domain control node is woken up by ECU1 during the sleep cycle and it is detected that the power domain node does not send a signal that the vehicle is charging, it can receive the wake-up record message sent by ECU1 controlled on the CAN bus.

[0087] S103. Store the wake-up record messages of at least one ECU in the vehicle's memory.

[0088] When the main domain control node receives the wake-up record message of the ECU, it can store the wake-up record message in a newly added EEPROM (Electrically Erasable Programmable Read Only Memory).

[0089] Optionally, the EEPROM can store the data that causes abnormal vehicle sleep and abnormal wake-up. Among them, the space of the EEPROM required to store the data that causes abnormal vehicle sleep can be 5.36 Kbit (kilobit), and the space of the EEPROM required to store the data that causes abnormal vehicle wake-up can be 2.16 Kbit.

[0090] For example, when the body domain control node receives the wake-up record message of ECU1, it can store the wake-up record message in the newly added EEPROM.

[0091] In the embodiment of the present application, after the ECU is woken up, the wake-up record message can be sent to the main domain control node of the ECU according to a preset period. When it is detected that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one ECU it controls and stores the wake-up record messages of at least one ECU in the vehicle's memory. The reason for the vehicle's power loss problem can be accurately located by searching for the ECU wake-up reason in the wake-up record message, improving the efficiency of solving the vehicle's power loss problem.

[0092] Next, on the basis of the Figure 2 shown embodiment, in combination with Figure 4, a detailed description of the above vehicle bus fault recording method will be given.

[0093] Figure 4 It is a flowchart of another vehicle bus fault recording method provided by an embodiment of this application.

[0094] Please refer to Figure 4 , this method may include:

[0095] S201. After the ECU is awakened, send a wake-up record message to the main domain control node of the ECU according to a preset period.

[0096] It should be noted that the specific execution process of step S201 can refer to the specific execution process of step S101, which will not be elaborated here.

[0097] S202. If after the first preset duration after the vehicle switch is powered off and the vehicle is armed, the main domain control node is in the wake-up state and the vehicle is not in the charging state, it is determined that the vehicle sleep fault detection condition is met.

[0098] When the main domain control node determines that it is necessary to record the wake-up record message, it is necessary to first determine that the vehicle has met the sleep fault condition. In specific implementation, the main domain control node needs to be in the wake-up state, the vehicle is not in the charging state, and it is necessary to meet the start condition of the timer and reach the first preset duration after the vehicle is armed.

[0099] In a specific implementation, the vehicle meeting the sleep fault includes the following two situations.

[0100] Situation 1: The main domain control node starts the sleep fault detection timer after the vehicle is powered off, that is, the ignition (IGN) switch is turned off (IGN15 OFF), and receives the vehicle remote control arming signal (AlrmSts = 0x1), and the wake-up time of the main domain control node is greater than the first preset duration after the vehicle is armed.

[0101] Situation 2: The main domain control node is awakened by the wake-up record message during sleep. The main domain control node determines that the vehicle is in the powered-off state, that is, the ignition switch is turned off (IGN15 OFF); and after receiving the vehicle remote control arming signal (AlrmSts = 0x1), it starts the abnormal wake-up timer, and the wake-up time of the main domain control node is the first preset duration.

[0102] It should be noted that for situation 1 and situation 2, when any of the following conditions is met, the sleep fault detection timer or the wake-up fault detection timer can be cancelled:

[0103] Condition 1: The body domain control issues a vehicle disarming signal (AlrmSts ≠ 0x1);

[0104] Condition 2: The vehicle is in the state where the engine ignition switch is turned on (IGN15 ON).

[0105] S203. If a first signal indicating that the vehicle is charging is received from the power domain node, it is determined that the vehicle is in the charging state.

[0106] Since the main domain control node needs to judge whether the vehicle is in the charging situation when obtaining the wake-up record message, so as to exclude the wake-up of the main domain control node caused by the vehicle being in the charging state. In the specific implementation, if the main domain control node receives a first signal indicating that the vehicle is charging sent by the power domain node, it can be judged that the vehicle is in the charging state; otherwise, it is determined that the vehicle is not in the charging state.

[0107] For example, when the vehicle is in the power-off state and sends the vehicle remote control arming signal, the first signal for charging sent by the power domain node is: ChrgnSts = 0x1, which means that the charging state of the vehicle is in the process of charging. When the body domain control node receives the first signal that the vehicle is charging: ChrgnSts = 0x1, it can be determined that the vehicle is in the charging state; otherwise, if the body domain control node does not receive the first signal that the vehicle is charging: ChrgnSts = 0x1, it means that the vehicle is not in the charging state.

[0108] S204. When it is detected that the vehicle meets the vehicle sleep fault detection conditions, the main domain control node receives the wake-up record messages sent by at least one ECU under control.

[0109] When the main domain control node detects that the current vehicle meets the sleep fault conditions, it can receive the wake-up record messages sent by at least one ECU connected to the bus.

[0110] For case 1: When the vehicle meets the sleep fault, that is, when the main domain control node is continuously awakened and the time is greater than the first preset time, the main domain control node records the wake-up record messages of the ECU that currently maintains the network wake-up within the preset time. The time signal is equal to the time signal of the last frame received. The time value is recorded in the format of year, month, day, hour, minute, and second, based on the time signal sent by the body domain controller. If the time signal is not received, the last frame sent by the body domain controller is used as the reference.

[0111] It should be noted that when the vehicle is in the state where the engine ignition switch is turned on or the vehicle is not in the armed state or the sleep fault detection timer is in the timeout state, this wake-up cycle ends.

[0112] To better reflect the process of the main domain control node recording the wake-up record messages, combined with Figure 5 , the conditions satisfied by the main domain control node for recording the wake-up record messages are described.

[0113] Figure 5 This is a flowchart of the process for the main domain control node to record the wake-up record message provided by the embodiments of the present application. Please refer to Figure 5 , and the process includes:

[0114] S301. Whether the vehicle is in a power-off state, i.e., (IGN15 = OFF).

[0115] If so, execute S302; if not, execute S307.

[0116] S302. Whether the vehicle is in a vehicle-wide anti-theft state, i.e., (AlrmSts = 0x1).

[0117] If so, execute S303; if not, execute S307.

[0118] S303. Start the sleep fault detection.

[0119] S304. Whether the continuous wake-up of the main domain control node is greater than 10 minutes.

[0120] If so, execute S304; if not, execute S307.

[0121] S305. Whether the power domain node sends out the first signal (ChrgnSts = 0x1).

[0122] If so, execute S306; if not, execute S307.

[0123] S306. Record the wake-up record message.

[0124] S307. Do not record the wake-up record message.

[0125] For example, when the vehicle meets the sleep fault, the body domain control node is continuously woken up and the time is greater than 10 minutes. The body domain control node records the wake-up record message sent by the ECU1 that currently maintains the network wake-up within 2 seconds. The recorded time value is the time of the last frame of the time signal sent by the body domain controller. The time signal can be: 10:10:10 on May 18, 2020.

[0126] For Scenario 2: The main domain control node is woken up by a wake-up record message and wakes up within a preset first time period. The main domain control node identifies the active wake-up bit corresponding to Bit4 in the wake-up record messages of all ECUs to determine which ECU actively woke up the network, and increments the abnormal wake-up count of the main domain control node by 1. When the time exceeds the preset second time period, the wake-up record message of the corresponding node is recorded. At the same time, the number of times the main domain control node is woken up within a sleep cycle can be accumulated. By setting a maximum upper limit, if the number of times the main domain control node is woken up within a sleep cycle reaches the set maximum upper limit, the main domain control node can record the wake-up record messages sent by all ECUs that woke up the main domain control node within that sleep cycle.

[0127] Specifically, when the main domain control node identifies all ECUs to determine which ECU actively woke up the network, it also includes identifying the active wake-up bit of the main domain control node itself.

[0128] Optionally, the second preset time period is a measure of the time an ECU remains in a wake-up state after being woken up. Whenever the second preset time period is reached, the main domain control node can record the wake-up record message of that ECU. For example, the preset second time period can be 30 minutes.

[0129] Optionally, setting the maximum upper limit means the upper limit on the number of times the main domain control node is woken up within a sleep cycle. Whenever, within a sleep cycle, the number of times the main domain control node is woken up reaches the set maximum upper limit, the wake-up record messages sent by all ECUs that woke up the main domain control node within that sleep cycle can be recorded. For example, the set maximum upper limit is 15 times.

[0130] It should be noted that when the vehicle's engine ignition switch is on, or the vehicle is not in an armed state, or the number of times the main domain control node is woken up reaches the upper limit, this sleep cycle ends.

[0131] For example, the body domain control node is woken up by a wake-up record message and wakes up within 1 second. The body domain control node determines that it is ECU1 that actively woke up the network by identifying Bit4 in the wake-up record messages of all ECUs, and increments the abnormal wake-up count of the body domain control node by 1. When the time exceeds 30 minutes, the wake-up record message of the corresponding ECU1 can be recorded. At the same time, the number of times the body domain control node is woken up within a sleep cycle can be accumulated. When it reaches the maximum upper limit of 15 times, the body domain control node can record the wake-up record messages sent by all ECUs, namely ECU1, ECU2, and ECU3, that woke up the body domain control node within that sleep cycle.

[0132] S205. Store the wake-up record messages of at least one ECU in the vehicle's memory.

[0133] When the vehicle meets the sleep fault condition and the main domain control node records the wake-up record messages of at least one ECU, the wake-up record messages can be parsed to obtain the information contained in Byte0, Byte6, and Byte7 in the messages, and the information is combined and stored in the vehicle's EEPROM.

[0134] Optionally, a diagnostic module can be added to the memory to store the parsed wake-up record messages. The diagnostic module can be divided into two areas. In area 1, 5 groups (Groups) are set to store abnormal wake-up fault codes, namely Group1, Group2,..., and Group5. Each group stores abnormal wake-up fault codes with a length of 54 Bytes. In area 2, 5 groups can be set to store abnormal sleep fault codes, namely Group1, Group2,..., and Group5. Each group stores abnormal sleep fault codes with a length of 134 Bytes. The fault information generated most recently is stored in Group1, and the fault information generated farthest is stored in Group5. Each time new fault information is generated, it is put into Group1, and the original Group1 data is put into Group2, and so on. The last group of fault information will be crowded out by the queue.

[0135] For example, the 54 Bytes of Group1 in the diagnostic module area 1 can be used to monitor the corresponding positions of each network segment of the ECU and store the information in Byte0, Byte6, and Byte7 after parsing the wake-up record messages. Among them, some Bytes and the monitored ECU positions are shown in Table 4:

[0136] Table 4

[0137]

[0138] S206. According to the preset data upload period, upload the un-uploaded wake-up record messages of at least one ECU stored in the memory to the cloud server.

[0139] When the wake-up record messages of the ECU after parsing are recorded in the memory, when the storage space of the memory reaches the upper limit, the un-uploaded wake-up record messages of at least one ECU stored in the memory can be uploaded to the cloud server through the remote communication terminal (Telematics Box, TBOX). When the vehicle is in an abnormal state, the problem troubleshooting personnel can obtain the vehicle abnormal data from the cloud. After obtaining the abnormal data, through the bus data, the specific wake-up reason can be found by combining the defined network management message with the wake-up reason Coding code.

[0140] Optionally, the preset data upload period can be the number of times of waking up and recording message records after parsing and setting in the memory. For example, whenever the memory records 5 parsed wake-up message records, the operation of uploading to the cloud can be executed.

[0141] In a specific real-time manner, the reason for triggering the wake-up of the main domain control node can be found in a pre-defined network management message through the ID corresponding to the wake-up reason. Each VFC activation condition is a wake-up reason (ID). Among them, the pre-defined network management message can be as shown in Table 5:

[0142] Table 5

[0143]

[0144] For example, when 5 parsed wake-up message records of the ECU are recorded in the memory, when the storage space of the memory reaches the upper limit, the 5 un-uploaded parsed wake-up message records of the ECU stored in the memory can be uploaded to the cloud server through the TBOX. When the vehicle has an abnormal state, the problem troubleshooting personnel can obtain the abnormal vehicle data through the cloud. Among them, the obtained Coding code can be 0x0000, which means the wake-up reason is 667949. By looking up the defined network management message to view the ECU wake-up reason (ID) and maintain the wake-up reason, it can be obtained that the reason corresponding to the wake-up reason_667949 is the wake-up triggered by the seat comfort function. Therefore, it can quickly locate that the reason for the vehicle not sleeping is the abnormal seat comfort function associated with the body domain control node.

[0145] In the embodiment of the present application, after the ECU is woken up, a wake-up message record can be sent to the main domain control node of the ECU according to a preset period. If, after the first preset duration after the vehicle switch is powered off and the vehicle is armed, 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 sent by the power domain node is received, 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 the wake-up message records sent by at least one ECU under control, stores the wake-up message records of at least one ECU in the vehicle's memory, and uploads the un-uploaded wake-up message records of at least one ECU stored in the memory to the cloud server according to the preset data upload period. In the above process, when the vehicle has abnormal power loss, the problem troubleshooting personnel can obtain the abnormal vehicle data through the cloud. After obtaining the abnormal data, through the bus data, the specific wake-up reason can be found through the wake-up reason Coding code, improving the efficiency of solving the vehicle power loss problem.

[0146] Figure 6Schematic diagram of a structure of a vehicle bus fault recording device provided by an embodiment of the present application. Please refer to Figure 6 The vehicle bus fault recording device 10 includes:

[0147] A receiving module 11, configured to, when detecting that the vehicle sleep fault detection condition is met, receive wake-up record messages sent by at least one ECU controlled by the main domain control node; each wake-up record message sent by an ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU;

[0148] A storage module 12, configured to store the wake-up record messages of the at least one ECU in the vehicle's memory.

[0149] The vehicle bus fault recording device provided by the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be elaborated here.

[0150] In a possible implementation manner, the vehicle bus fault recording device 10 further includes:

[0151] An uploading module 13, configured to upload the un-uploaded wake-up record messages of at least one ECU stored in the memory to a cloud server according to a preset data uploading period.

[0152] In a possible implementation manner, the wake-up record message further includes: a field indicating the current network state and a field indicating the local network cluster PNC.

[0153] In a possible implementation manner, the field indicating the wake-up reason of the ECU in the wake-up record message is used to indicate the virtual function cluster VFC that triggers the ECU to wake up.

[0154] In a possible implementation manner, the vehicle bus fault recording device 10 further includes:

[0155] A first determination module 14, configured to determine that the vehicle sleep fault detection condition is met if, after a first preset duration after the vehicle switch is powered off and the vehicle is armed, the main domain control node is in a wake-up state and the vehicle is not in a charging state.

[0156] In a possible implementation manner, the vehicle bus fault recording device 10 further includes: a second determination module 15, and the second determination module 15 is configured to:

[0157] If receiving a first signal sent by the power domain node indicating that the vehicle is charging, determine that the vehicle is in a charging state;

[0158] Otherwise, it is determined that the vehicle is not in a charging state.

[0159] The vehicle bus fault recording device provided by the embodiments of the present application can execute the technical solutions shown in the above method embodiments, and the implementation principles and beneficial effects are similar, so details are not described herein again.

[0160] Figure 7 FIG. is a schematic structural diagram of another vehicle bus fault recording device provided by an embodiment of the present application. Please refer to Figure 7 , the vehicle bus fault recording device 20 includes:

[0161] A processing module 21, configured to send a wake-up record message to the main domain control node of the ECU according to a preset period after the ECU is woken up. The wake-up record message includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

[0162] In a possible implementation manner, the wake-up record message further includes: a field indicating the current network state and a field indicating the local network cluster PNC.

[0163] In a possible implementation manner, the field indicating the wake-up reason of the ECU in the wake-up record message is used to indicate the virtual function cluster VFC that triggers the wake-up of the ECU.

[0164] The vehicle bus fault recording device provided by the embodiments of the present application can execute the technical solutions shown in the above method embodiments, and the implementation principles and beneficial effects are similar, so details are not described herein again.

[0165] Figure 8 FIG. is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Please refer to Figure 8 , the electronic device 30 may include a processor 31, a memory 32, and a communication interface 34. Exemplarily, the processor 31, the memory 32, and the communication interface 34 are interconnected through a bus 33.

[0166] The memory 32 stores computer execution instructions;

[0167] The processor 31 executes the computer execution instructions stored in the memory 32, so that the processor 31 executes the method provided in the above method embodiment.

[0168] Figure 8 In specific applications, the electronic device shown in can be implemented as any main domain control node or any ECU in the vehicle in the foregoing method embodiment, and this solution is not limited thereto.

[0169] Accordingly, an embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, are used to implement the method described in any of the above method embodiments.

[0170] Accordingly, an embodiment of the present application may further provide a computer program product including a computer program that, when executed by a processor, can implement the method described in any of the above method embodiments.

[0171] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0172] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the specified functions in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0173] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the specified functions in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0174] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the specified functions in one Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0175] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0176] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0177] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The information can 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0178] It should also be noted that the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but also other elements not expressly listed, or elements that are inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0179] The above description is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for recording vehicle bus faults, characterized in that, applied to any one of the main domain control nodes in a vehicle, the method includes: When detecting that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one electronically controlled unit (ECU) under its control; each wake-up record message sent by an ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU; Store the wake-up record messages of the at least one ECU in the vehicle's memory.

2. The method according to claim 1, characterized in that, the method further includes: According to a preset data upload period, upload the un-uploaded wake-up record messages of at least one ECU stored in the memory to a cloud server.

3. The method according to claim 1, characterized in that, the wake-up record message further includes: a field indicating the current network status and a field indicating the local network cluster (PNC).

4. The method according to claim 1, characterized in that, the field indicating the wake-up reason of the ECU in the wake-up record message is used to indicate the virtual function cluster (VFC) that triggers the wake-up of the ECU.

5. The method according to any one of claims 1 to 4, characterized in that, the method further includes: If after a first preset duration after the vehicle switch is powered off and the vehicle is armed, 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.

6. The method according to claim 5, characterized in that, the method further includes: If receiving a first signal sent by the power domain node indicating that the vehicle is charging, it is determined that the vehicle is in a charging state; Otherwise, it is determined that the vehicle is not in a charging state.

7. A method for recording vehicle bus faults, characterized in that, applied to any one of the electronically controlled units (ECUs) in a vehicle, the method includes: After the ECU is awakened, send a wake-up record message to the main domain control node of the ECU according to a preset period, and the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

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

9. The method according to claim 7, characterized in that, the field indicating the wake-up reason of the ECU in the wake-up record message is used to indicate the virtual function cluster (VFC) that triggers the wake-up of the ECU.

10. A vehicle bus fault recording device, the device includes: A receiving module, configured to, when detecting that the vehicle sleep fault detection condition is met, the main domain control node receives the wake-up record messages sent by at least one electronically controlled unit (ECU) under its control; each wake-up record message sent by an ECU includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU; A storage module, configured to store the wake-up record messages of the at least one ECU in the vehicle's memory.

11. A recording device for vehicle bus faults, the device comprises: a processing module, configured to send a wake-up record message to a main domain control node of the ECU according to a preset period after the ECU is awakened, where the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the wake-up reason of the ECU.

12. An electronic device, characterized in that it comprises: a processor, a memory and a communication interface; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the processor executes the method according to any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method according to any one of claims 1 to 9.

Images