Method and apparatus for recording vehicle bus fault, and device and storage medium

Abstract

Provided in the present application are a method and apparatus for recording a vehicle bus fault, and a device and a storage medium. The method comprises: after an ECU is woken up, sending a wake-up record message to a master-domain control node of the ECU on the basis of a preset period; when it is detected that a vehicle sleep fault detection condition is met, the master-domain control node receiving the wake-up record message sent by at least one ECU under control; and storing the wake-up record message of the at least one ECU in a memory of a vehicle. When abnormal battery depletion occurs in a vehicle, a troubleshooter can find a specific wake-up cause of the vehicle by means of a wake-up record message, thereby improving the efficiency of solving the battery depletion problem of the vehicle.

Description

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

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on November 29, 2023, with application number 2023116390779 and application name “Method, device, equipment and storage medium for recording vehicle bus faults”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of vehicle technology, and in particular to a method, device, equipment, and storage medium for recording vehicle bus faults. Background Art

[0003] In recent years, vehicle energy conservation has received considerable attention, and reducing unnecessary power loss is a very effective approach. To reduce power consumption and prevent excessive battery drain that can cause the vehicle to become unable to start due to a low battery, partial network management (PN) is often used. This approach uses virtual function clusters (VFCs) and partial network clusters (PNCs) to achieve orderly sleep and wakeup of the vehicle's electronic control unit (ECU). This allows the ECU to sleep when there's no communication need and wake up when communication is required, thereby conserving battery power.

[0004] However, as the vehicle's electronic and electrical systems become more and more complex, the number of electronic control units that are powered by batteries is also increasing, and the problem of vehicle power outage is inevitable.

[0005] In related technologies, once a vehicle has a low battery problem, the method of locating the problem consumes a large amount of personnel resources, vehicle resources, and equipment resources, and checks the electronic control units one by one by reproducing the problem, resulting in low efficiency in solving the vehicle low battery problem.

[0006] Summary of the Invention

[0007] The present application provides a method, device, equipment and storage medium for recording vehicle bus faults, which can improve the efficiency of solving vehicle power outage problems.

[0008] In a first aspect, the present application provides a method for recording vehicle bus faults, which is applied to any primary domain control node in a vehicle, and the method includes:

[0009] When a vehicle dormancy fault detection condition is detected, the primary domain control node receives a wake-up record message sent by at least one electronic control unit ECU under its control; the wake-up record message sent by each ECU includes a field indicating an identifier of the ECU and a field indicating a wake-up reason of the ECU;

[0010] The wake-up record message of the at least one ECU is stored in a memory of the vehicle.

[0011] In one possible implementation, the method further includes:

[0012] According to a preset data upload cycle, the wake-up record message of at least one ECU that has not been uploaded and stored in the memory is uploaded to the cloud server.

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

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

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

[0016] If the primary domain control node is in the awake state and the vehicle is not in the charging state after the vehicle switch is powered off and the vehicle is armed for a first preset period of time, it is determined that the vehicle sleep fault detection condition is met.

[0017] In one possible implementation, the method further includes:

[0018] If a first signal indicating that the vehicle is charging is received from a power domain node, determining that the vehicle is in a charging state;

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

[0020] 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, and the method comprises:

[0021] After the ECU is awakened, a wake-up record message is sent to the primary 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 reason for the ECU to wake up.

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

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

[0024] In a third aspect, the present application provides a vehicle bus fault recording device, the device comprising:

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

[0026] A storage module is used to store the wake-up record message of the at least one ECU in the memory of the vehicle.

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

[0028] The uploading module is used to upload the wake-up record message of at least one ECU that has not been uploaded and stored in the memory to the cloud server according to a preset data upload cycle.

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

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

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

[0032] The first determination module is used to determine that the vehicle sleep fault detection condition is met if the primary domain control node is in the awake state and the vehicle is not in the charging state after the vehicle switch is powered off and the vehicle is armed for a first preset time.

[0033] In a possible implementation, the apparatus further includes: a second determining module, wherein the second determining module is configured to:

[0034] If a first signal indicating that the vehicle is charging is received from a power domain node, determining that the vehicle is in a charging state;

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

[0036] In a fourth aspect, the present application provides a vehicle bus fault recording device, the device comprising:

[0037] The processing module is used to send a wake-up record message to the primary domain control node of the ECU according to a preset period after the ECU is awakened, wherein the wake-up record message includes a field indicating the identifier of the ECU and a field indicating the reason for the ECU to wake up.

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

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

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

[0041] The memory stores computer-executable instructions;

[0042] The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method as described in any one of the first aspect or the second aspect.

[0043] In a sixth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method described in either the first aspect or the second aspect.

[0044] In the seventh aspect, an embodiment of the present invention provides a chip, which includes a memory and a processor, wherein the memory stores code and data, the memory is coupled to the processor, and the processor runs the program in the memory so that the chip is used to execute the method described in any one of the first or second aspects above.

[0045] In an eighth aspect, an embodiment of the present invention provides a program product, comprising: a computer program, which, when the program product is run on a computer, enables the computer to execute the method described in any one of the first or second aspects above.

[0046] In a ninth aspect, an embodiment of the present invention provides a computer program, which, when executed by a processor, is used to execute the method described in any one of the first or second aspects above.

[0047] The vehicle bus fault recording method, apparatus, device, and storage medium provided in this application can, after the ECU is awakened, send a wake-up record message to the ECU's primary domain control node according to a preset period. When it is detected that the vehicle sleep fault detection conditions are met, the primary domain control node receives the wake-up record message sent by at least one ECU under its control and stores the wake-up record message of at least one ECU in the vehicle's memory. In the above process, the vehicle's memory can store the wake-up record message sent by the ECU. By searching the ECU wake-up reason in the wake-up record message, the cause of the vehicle's low battery problem can be accurately located, thereby improving the efficiency of resolving the vehicle's low battery problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. The drawings here are incorporated into the specification and constitute a part of this specification, and are used together with the specification to explain the principles of the present application.

[0049] FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0050] FIG2 is a flow chart of a method for recording a vehicle bus fault provided by an embodiment of the present application;

[0051] FIG3 is a schematic diagram of a local network cluster division provided by an embodiment of the present application;

[0052] FIG4 is a flow chart of another method for recording vehicle bus faults provided by an embodiment of the present application;

[0053] FIG5 is a flowchart of a process of recording a wake-up record message by a primary domain control node according to an embodiment of the present application;

[0054] FIG6 is a schematic structural diagram of a vehicle bus fault recording device provided by an embodiment of the present application;

[0055] FIG7 is a schematic structural diagram of another vehicle bus fault recording device provided in an embodiment of the present application;

[0056] FIG8 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.

[0057] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0058] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0060] The ECU can send a wake-up record message to the primary domain control node, which can record the wake-up record message and store it in the memory. The wake-up record message can be used to accurately locate the cause of the vehicle's low power problem.

[0061] During the vehicle development and design process, in order to reduce power consumption and avoid the vehicle being unable to start due to excessive battery power consumption, partial network management (PN) was introduced. When functional scenarios require it and there is a need to exchange information with the outside world, a network communication channel is established. Only when PN is turned on will there be a concept of communication on the network. It is a method of grouping and controlling network communications. On the premise of meeting the functional implementation, a path for minimizing the wake-up of the controller is found to realize the sleep and wake-up of the entire vehicle. PN can be implemented through virtual function clusters (VFC) and partial network clusters (PNC). VFCs group signals that communicate between one or more vehicle functions. VFC development is conducted concurrently with subsystem design, and each VFC defines specific functions. Signals required to interact within these functions are mapped to specific VFCs. Power modes establish unified requirements for vehicle function availability, translating user intent into vehicle-recognizable, guiding function execution when available. Modes include standby, rest, limited functionality (where only certain low-energy functions are in a pending state and require user activation for function activation), and post-operational functionality. PNCs focus on network signaling and identify groupings of signals across multiple ECUs to support vehicle functions. Each group, called a PNC, is a signal grouping. Its essence is to wake up and hibernate necessary nodes based on their functions, thereby reducing power consumption. As vehicle electronic and electrical systems become increasingly complex, the number of ECUs powered by the battery increases, inevitably leading to battery depletion.

[0062] In related technologies, once a vehicle has a low battery problem, most of the time it is an occasional problem. The way to locate the problem is to consume a lot of personnel resources, vehicle resources, and equipment resources, and check the ECUs one by one by reproducing the problem, resulting in low efficiency in solving the vehicle low battery problem.

[0063] In an embodiment of the present application, after an ECU is awakened, a wakeup log message can be sent to the ECU's primary domain control node according to a preset period. Upon detecting that a vehicle sleep fault detection condition is met, the primary domain control node receives the wakeup log message sent by at least one of the ECUs under its control and stores the wakeup log message of the at least one ECU in the vehicle's memory. By searching the wakeup log message for the ECU wakeup reason, the cause of the vehicle's battery loss can be accurately located, improving the efficiency of resolving vehicle battery loss issues.

[0064] The technical solutions shown in this application are described in detail below through specific embodiments. It should be noted that the following embodiments can exist independently or in combination with each other, and the same or similar contents will not be repeated in different embodiments.

[0065] FIG2 is a flow chart of a method for recording a vehicle bus fault according to an embodiment of the present application. Referring to FIG2 , the method may include:

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

[0067] Abnormal sleep and wakeup in a vehicle are caused by the vehicle's ECU being awake. After waking up, the ECU can send abnormal wakeup messages to the master domain control node at specific intervals. The wakeup record message sent by each ECU includes a field indicating the ECU's identity and a field indicating the reason for the ECU's wakeup.

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

[0069] Optionally, different ECUs can be divided into the vehicle's cockpit domain, intelligent driving domain, power domain, body domain, and chassis domain. For example, the ECUs 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). ECU1 may be the air conditioning control module, ECU2 may be the interior lighting control module, ECU3 may be the battery management module, and ECU4 may be the seat control module.

[0070] Optionally, the wakeup source can be divided into active wakeup and passive wakeup. Active Wakeup: The ECU acts as the master wakeup node. When it detects the active wakeup source input signal, it actively wakes itself up and attempts to wake up other ECUs by sending NM Frames. This is a request from the module to the network. Passive Wakeup: The ECU acts as a slave wakeup node. It cannot actively wake itself up and can only wake itself up by receiving network management messages from other ECUs.

[0071] In a specific embodiment, each wake-up record message may include 8 bytes, and each byte may correspond to 8 bits. Byte 0 corresponds to the source node identifier. Each ECU is assigned a unique identifier to inform the receiving node which node sent the NM PDU (NM Protocol Data Unit). The NM PDU format may be as shown in Table 1:

[0072] Table 1

[0073] In a specific embodiment, the wake-up record message also 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 can contain 8 bits. Among them: Bit0 corresponds to the repeat message request. If the position is 0, it means that the repeat message state is not requested. If the position is 1, it means that the repeat message state is requested; Bit4 corresponds to the active wake-up bit. If the position is 0, it means that the node has not woken up the network, that is, passive wake-up; if the position is 1, it means that the node has woken up the network, that is, active wake-up; Bit 3 corresponds to the network management sleep coordination bit; Bit 6 corresponds to part of the network information bit; the remaining Bits 1, Bit 2, Bit 5, and Bit 7 can be reserved and defined according to user needs.

[0074] Optionally, the PNC can define PNC boundaries based on network segments and power consumption, dividing the vehicle's domain controllers into different PNCs for wakeup. In the wakeup record message, Byte 2-Byte 5 can correspond to different PNC bits. In Automotive Open System Architecture (AUTOSAR) versions 4.0.3 and 4.2.2, the corresponding positions of the PNC bits in Byte 2-Byte 5 can be shown in Table 2:

[0075] Table 2

[0076] Optionally, in Autosar 4.2.2, the valid PNC bits in Byte2 are PNC16-PNC23. If the value corresponding to PNC16 is 1, it means that PNC16 is effective, otherwise it is 0 and PNC16 is invalid.

[0077] In order to further illustrate the relationship among the ECU, PNC, and VFC, the ECU, PNC, and VFC corresponding to the bus are described in detail with reference to FIG3 .

[0078] Figure 3 is a schematic diagram of the division of a local network cluster provided in an embodiment of the present application. Please refer to Figure 3, the electronic control unit 1, the electronic control unit 2, the electronic control unit 3, and the electronic control unit 4 are connected by a bus. The bus can be one of the CAN bus, the CANFD bus, and the FR daisy chain bus. From the perspective of functional implementation, the electronic control unit 1 and the electronic control unit 2 can be divided into one group, and the electronic control unit 3 and the electronic control unit 4 can be divided into one group, that is, the real physical bus can be divided into two independent network groups, the local network cluster 1 (PNC1) and the local network cluster 2 (PNC2), so that the group members can sleep and wake up together. The virtual function cluster 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 to implement vehicle functions forms a virtual function cluster network.

[0079] In a specific implementation, Byte6-Byte7 are used as ECU wakeup reason bits to record the wakeup reason of each ECU. Each wakeup reason occupies one coding bit, with a maximum of 256 bits. When the ECU actively wakes up when the corresponding VFC activation condition is met, the corresponding wakeup reason can be set. The wakeup reason ID and coding can be shown in Table 3:

[0080] Table 3

[0081] In one specific implementation, the field indicating the ECU wakeup reason in the wakeup record message is used to indicate the VFC that triggered the ECU wakeup. For example, ECU1 and ECU2 form a PNC1, which can correspond to the seat comfort function and be identified by virtual function cluster 1 (VFC1). The seat comfort function can be assigned a wakeup reason ID, such as Wakeup Reason_667949, corresponding to the bit value 0x0000 in the Wakeup Reason field.

[0082] For example, after ECU1 is awakened, it will send a wake-up record message to the vehicle body domain control node at an interval of 500ms.

[0083] S102: When it is detected that a vehicle sleep failure detection condition is met, the primary domain control node receives a wake-up record message sent by at least one ECU under its control.

[0084] The primary domain control node is awakened by the wake-up record message sent by the ECU during the sleep cycle. The active wake-up bit corresponding to Bit4 in the wake-up record message and the active wake-up bit of the primary domain control node itself can be identified to determine which ECU actively wakes up the network. When it is detected that the vehicle currently meets the sleep fault, the wake-up record message sent by at least one ECU connected to the bus can be received.

[0085] Optionally, the vehicle dormancy fault detection condition may be: after the body domain control node is awakened by the awakening record message in the dormant state, the power domain node does not send a signal that the vehicle is charging.

[0086] For example, the body domain control node is awakened by ECU1 during the sleep cycle and detects that the power domain node has not sent a signal that the vehicle is charging. It can then receive the wake-up record message sent by ECU1 connected to the CAN bus.

[0087] S103: Store the wake-up record message of at least one ECU in a memory of the vehicle.

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

[0089] Optionally, the EEPROM may store data causing the vehicle to go into abnormal sleep or wake up abnormally. The EEPROM space required to store the data causing the vehicle to go into abnormal sleep may be 5.36 Kbits (kilobits), and the EEPROM space required to store the data causing the vehicle to wake up abnormally may be 2.16 Kbits.

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

[0091] In an embodiment of the present application, after an ECU is awakened, a wakeup log message can be sent to the ECU's primary domain control node according to a preset period. Upon detecting that a vehicle sleep fault detection condition is met, the primary domain control node receives the wakeup log message sent by at least one of the ECUs under its control and stores the wakeup log message of the at least one ECU in the vehicle's memory. By searching the wakeup log message for the ECU wakeup reason, the cause of the vehicle's battery loss can be accurately located, improving the efficiency of resolving vehicle battery loss issues.

[0092] Next, based on the embodiment shown in FIG. 2 and in combination with FIG. 4 , the above-mentioned method for recording vehicle bus faults will be described in detail.

[0093] FIG4 is a flow chart of another method for recording vehicle bus faults provided by an embodiment of the present application. Referring to FIG4 , the method may include:

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

[0095] 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 repeated here.

[0096] S202: If the primary domain control node is in the awake state after the vehicle switch is powered off and the vehicle is armed for a first preset period of time, and the vehicle is not in the charging state, it is determined that the vehicle dormancy fault detection condition is met.

[0097] When the primary domain control node determines that a wake-up record message needs to be recorded, it must first confirm that the vehicle has met the dormant fault conditions. Specifically, the primary domain control node must be awake, the vehicle must not be charging, and the timer start conditions must be met and the first preset time after the vehicle is armed must have expired.

[0098] In a specific implementation, the vehicle meets the dormant fault conditions in the following two situations.

[0099] Case 1: The main domain control node starts the sleep fault detection timer after receiving the vehicle remote control arming signal (AlrmSts=0x1) when the vehicle is powered off, that is, the engine ignition (IGN) switch is turned off (IGN15OFF), and the wake-up time of the main domain control node is greater than the first preset time after the vehicle is armed.

[0100] Case 2: The main domain control node is awakened by the wake-up record message in hibernation. The main domain control node determines that the vehicle is in a power-off state, that is, the engine ignition switch is turned off (IGN15OFF); 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.

[0101] It should be noted that for cases 1 and 2, the sleep fault detection timer or wake-up fault detection timer can be canceled when any of the following conditions are met:

[0102] Condition 1: The vehicle domain control node sends a vehicle unarmed signal (AlrmSts≠0x1);

[0103] Condition 2: The vehicle's ignition switch is on (IGN15ON).

[0104] 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 a charging state.

[0105] Because the primary domain control node needs to determine whether the vehicle is charging when receiving the wake-up record message, it can eliminate the possibility of the primary domain control node being woken up due to the vehicle being in the charging state. In a specific implementation, if the primary domain control node receives the first signal from the power domain node indicating that the vehicle is charging, it can determine that the vehicle is in the charging state; otherwise, it determines that the vehicle is not in the charging state.

[0106] For example, if the vehicle is in a power-off state and sends a vehicle remote control arming signal, the power domain node sends the first charging signal: ChrgnSts = 0x1, which means that the vehicle's charging state is charging. The body domain control node receives the first signal that the vehicle is charging: ChrgnSts = 0x1, then it can be determined that the vehicle is in a charging state; conversely, if the body domain control node does not receive the first signal that the vehicle is charging: ChrgnSts = 0x1, then it means that the vehicle is not in a charging state.

[0107] S204: When it is detected that the vehicle sleep fault detection condition is met, the primary domain control node receives a wake-up record message sent by at least one ECU under its control.

[0108] When the primary domain control node detects that the current vehicle meets the sleep fault condition, it can receive a wake-up record message sent by at least one ECU connected to the bus.

[0109] For situation one: when the vehicle meets the dormancy 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 message of the ECU currently maintaining network wake-up within the preset time. The time signal is equal to the last frame time signal received. The time value is recorded in the form of year, month, day, hour, minute and second, and is based on the time signal sent by the body domain controller. If no time signal is received, the last frame sent by the body domain controller shall prevail.

[0110] It should be noted that when the vehicle's engine ignition switch is turned on or the entire vehicle is not in the armed state or the dormant fault detection timer is in the timeout state, the wake-up cycle ends.

[0111] In order to better reflect the process of the primary domain control node recording the wake-up record message, the conditions satisfied by the primary domain control node recording the wake-up record message are described with reference to FIG5 .

[0112] FIG5 is a flowchart of a process for recording a wake-up record message by a primary domain control node according to an embodiment of the present application. Referring to FIG5 , the process includes:

[0113] S301: Is the vehicle in a power-off state (IGN15 = OFF)?

[0114] If yes, execute S302; if no, execute S307.

[0115] S302: Is the vehicle in full vehicle defense mode (AlrmSts=0x1)?

[0116] If yes, execute S303; if no, execute S307.

[0117] S303: Start dormancy fault detection.

[0118] S304: Check whether the primary domain control node has been awakened for more than 10 minutes.

[0119] If yes, execute S304; if no, execute S307.

[0120] S305: Whether the power domain node sends a first signal (ChrgnSts=0x1).

[0121] If yes, execute S306; if no, execute S307.

[0122] S306: Record the wake-up record message.

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

[0124] For example, if the vehicle meets the sleep fault condition and the body domain control node is continuously awakened for more than 10 minutes, the body domain control node records the wake-up record message sent by ECU1, which currently maintains network wake-up, within 2 seconds. The recorded time value is the last frame time signal received from the body domain controller. The time signal can be: 10:10:10 on May 18, 2020.

[0125] For the second scenario: the primary domain control node is awakened from sleep by a wake-up record message and wakes up within the preset first duration. The primary domain control node identifies the active wake-up bit corresponding to Bit 4 in the wake-up record messages of all ECUs to determine which ECU actively woke up the network, and increases the abnormal wake-up count of the primary domain control node by 1. When the time exceeds the preset second duration, the wake-up record message of the corresponding node is recorded. At the same time, the number of times the primary domain control node is awakened within a sleep cycle can be accumulated. By setting a maximum upper limit, if the number of times the primary domain control node is awakened within a sleep cycle reaches the set upper limit, the primary domain control node can record the wake-up record messages sent by all ECUs that have awakened the primary domain control node during the sleep cycle.

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

[0127] Optionally, the second preset duration is a measure of how long an ECU remains awake after being awakened. Whenever the second preset duration is reached, the primary domain control node may record a wakeup record message for the ECU. For example, the second preset duration may be 30 minutes.

[0128] Optionally, setting a maximum limit refers to the maximum number of times the primary domain control node can be awakened during a sleep cycle. Whenever the number of times the primary domain control node is awakened reaches the maximum limit during a sleep cycle, all wakeup records sent by the ECUs that woke up the primary domain control node during that sleep cycle can be recorded. For example, the maximum limit can be set to 15 times.

[0129] It should be noted that when the vehicle's engine ignition switch is on or the entire vehicle is not in a fortified state or the number of times the primary domain control node is awakened reaches the upper limit, the sleep cycle ends.

[0130] For example, if a body domain control node is awakened from sleep mode by a wakeup record message and wakes up within 1 second, the body domain control node will identify Bit 4 in all ECU wakeup record messages and determine that ECU1 actively woke up the network. It will then increment the abnormal wakeup count for the body domain control node by 1. If the wakeup time exceeds 30 minutes, it will record the corresponding wakeup record message for ECU1. At the same time, it will accumulate the number of wakeups of the body domain control node within a sleep cycle. When the maximum limit reaches 15, the body domain control node will record all wakeup record messages sent by ECU1, ECU2, and ECU3 that woke up the body domain control node during that sleep cycle.

[0131] S205: Store the wake-up record message of at least one ECU in a memory of the vehicle.

[0132] When the vehicle meets the sleep fault conditions and the master domain control node records the wake-up record message of at least one ECU, it can parse the wake-up record message, obtain the information contained in Byte0, Byte6, and Byte7 in the message, and combine the information and store it in the vehicle's EEPROM.

[0133] Optionally, a new diagnostic module can be added to the memory to store the parsed wake-up record message. The diagnostic module can be divided into two areas. Five groups (Groups) for storing abnormal wake-up fault codes are set in Area 1, namely Group1, Group2, ..., and Group5. The length of each group storing abnormal wake-up fault codes is 54 bytes; five groups for storing abnormal sleep fault codes can be set in Area 2, namely Group1, Group2, ..., and Group5. The length of each group storing abnormal sleep fault codes is 134 bytes. Group1 stores the most recent fault information, and Group5 stores the most recent fault. Each new fault information is placed in Group1, and the original Group1 data is placed in Group2, and so on. The last group of fault information will be squeezed out of the queue.

[0134] For example, the 54 bytes of Group 1 in the diagnostic module area 1 can be used to monitor the corresponding positions of each ECU segment and store the information in Byte 0, Byte 6, and Byte 7 after parsing the wake-up record message. Among them, some bytes and the monitored ECU positions can be shown in Table 4:

[0135] Table 4

[0136] S206 . Upload the wake-up record message of at least one ECU that has not been uploaded and stored in the memory to the cloud server according to a preset data upload cycle.

[0137] Once the parsed ECU wakeup log messages are recorded in the memory, the remaining ECU wakeup log messages can be uploaded to the cloud server via a telematics box (TBOX) when the memory reaches its storage limit. When the vehicle experiences an abnormality, troubleshooters can access the abnormality data through the cloud. After obtaining the abnormality data, the specific wakeup cause can be identified by combining bus data with the defined network management message and the wakeup cause coding.

[0138] Optionally, the preset data upload period can be the number of times the parsed wake-up record message is recorded in the memory. For example, whenever the memory records 5 parsed wake-up record messages, the upload operation to the cloud can be performed.

[0139] In a specific real-time method, the reason for triggering the primary domain control node to wake up can be found in a pre-defined network management message using the ID corresponding to the wake-up reason. Each VFC activation condition is a wake-up reason (ID). The pre-defined network management message can be shown in Table 5:

[0140] Table 5

[0141] For example, when the memory records the wake-up record messages of 5 parsed ECUs, when the storage space of the memory reaches the upper limit, the 5 parsed ECU wake-up record messages stored in the memory but not uploaded can be uploaded to the cloud server through TBOX. When the vehicle is in an abnormal state, the problem troubleshooter can obtain the abnormal data of the vehicle through the cloud. Among them, the obtained coding code can be 0x0000, which means that the wake-up reason is 667949. By searching the defined network management message to view the ECU wake-up reason (ID) and the maintenance wake-up reason, the reason corresponding to the wake-up reason _667949 can be obtained as the wake-up triggered by the seat comfort function. Therefore, it can be quickly located that the reason that caused the vehicle to not sleep is the abnormality of the seat comfort function associated with the body domain control node.

[0142] In an 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. If the main domain control node is in the awake state and the vehicle is not in the charging state after the vehicle switch is powered off and the vehicle is armed for the first preset period of time, 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 power domain node, it is determined that the vehicle is in the charging state. 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 by at least one ECU under control, stores the wake-up record message of at least one ECU in the vehicle's memory, and uploads the wake-up record message of at least one ECU stored in the memory that has not been uploaded to the cloud server according to a preset data upload cycle. In the above process, when the vehicle has an abnormal power loss, the problem troubleshooter can obtain the abnormal data of the entire vehicle through the cloud. After obtaining the abnormal data, the specific wake-up cause can be found through the wake-up cause coding code through the bus data, thereby improving the efficiency of solving the vehicle power loss problem.

[0143] FIG6 is a schematic diagram of the structure of a vehicle bus fault recording device provided by an embodiment of the present application. Referring to FIG6 , the vehicle bus fault recording device 10 includes:

[0144] The receiving module 11 is configured to receive, when detecting that a vehicle sleep fault detection condition is met, a wake-up record message sent by at least one ECU under the control of the primary 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 reason for the ECU to wake up;

[0145] The storage module 12 is configured to store the wake-up record message of the at least one ECU in a memory of the vehicle.

[0146] The vehicle bus fault recording device provided in the embodiment of the present application can implement the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar and will not be repeated here.

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

[0148] The uploading module 13 is configured to upload the wake-up record message of at least one ECU that has not been uploaded and stored in the memory to the cloud server according to a preset data upload cycle.

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

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

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

[0152] The first determination module 14 is used to determine that the vehicle sleep fault detection condition is met if the primary domain control node is in the awake state and the vehicle is not in the charging state after the vehicle switch is powered off and the vehicle is armed for a first preset time.

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

[0154] If a first signal indicating that the vehicle is charging is received from a power domain node, determining that the vehicle is in a charging state;

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

[0156] The vehicle bus fault recording device provided in the embodiment of the present application can implement the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar and will not be repeated here.

[0157] FIG7 is a schematic diagram of the structure of another vehicle bus fault recording device provided in an embodiment of the present application. Referring to FIG7 , the vehicle bus fault recording device 20 includes:

[0158] The processing module 21 is used to send a wake-up record message to the primary domain control node of the ECU according to a preset period after the ECU is awakened. The wake-up record message includes a field indicating the identifier of the ECU and a field indicating the reason for the ECU to wake up.

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

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

[0161] The vehicle bus fault recording device provided in the embodiment of the present application can implement the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar and will not be repeated here.

[0162] FIG8 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Referring to FIG8 , 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 via a bus 33.

[0163] The memory 32 stores computer-executable instructions;

[0164] The processor 31 executes the computer-executable instructions stored in the memory 32 , so that the processor 31 performs the method provided in the above method embodiment.

[0165] In specific applications, the electronic device shown in FIG8 can be implemented as any primary domain control node or any ECU in the vehicle in the aforementioned method embodiment, and this solution does not impose any limitation on this.

[0166] An embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by a processor, the computer-executable instructions are used to implement the method described in any of the above method embodiments.

[0167] An embodiment of the present application provides a chip, which includes a memory and a processor. The memory stores code and data, and the memory is coupled to the processor. The processor runs the program in the memory so that the chip is used to execute the method described in any of the above method embodiments.

[0168] An embodiment of the present application provides a program product, including: a computer program, which, when executed on a computer, enables the computer to execute the method described in any of the above method embodiments.

[0169] An embodiment of the present application provides a computer program. When the computer program is executed by a processor, it is used to perform the method described in any of the above method embodiments.

[0170] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0171] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0172] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0173] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

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

[0175] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

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

[0177] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0178] The foregoing is merely an embodiment 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 changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all 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 main domain control node 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 or 2, characterized in that, the wake-up record message further includes: a field indicating the current network status and a field indicating the partial network cluster (PNC).

4. The method according to any one of claims 1 to 3, 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 any one of claims 1 to 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 electronically controlled unit (ECU) 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 partial network cluster (PNC).

9. The method according to claim 7 or 8, 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 into a memory of the vehicle.

11. A recording device for vehicle bus faults, the device comprising: 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 woken up, where the wake-up record message includes a field indicating an identifier of the ECU and a field indicating a 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 computer-executable instructions are stored in the computer-readable storage medium, 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.

14. A chip, characterized in that the chip comprises a memory and a processor, code and data are stored in the memory, the memory is coupled to the processor, and the processor runs a program in the memory so that the chip is used to execute the method according to any one of claims 1 to 9 above.

15. A program product, characterized in that it comprises: A computer program, when the program product runs on a computer, causes the computer to execute the method according to any one of claims 1 to 9 above.

16. A computer program, characterized in that when the computer program is executed by a processor, it is used to execute the method according to any one of claims 1 to 9 above.

Images