State control method and system for a controller

Abstract

Embodiments of the present application provide a state control method and system of a controller, and relate to the technical field of new energy vehicle charging. The method combines local wake-up and network wake-up to achieve flexible switching between the sleep state and standby state of the controller. The state control method of the controller is applied to a first controller unit of a state control system of the controller. The state control system of the controller further includes a vehicle control unit (VCU). The first controller unit includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit. The method includes: when the first controller unit collects a connection signal between a power supply device and the local through the OBC, sending a network management message to the second controller through the OBC to wake up the second controller; and after the second controller enters the standby state in response to the network management message, feeding back a local state mechanism to the VCU, and feeding back a message signal to the VCU.

Description

[Technical Field]

[0001] This application relates to the field of new energy vehicle charging technology, and in particular to a controller state control method and system. [Background Technology]

[0002] As new energy vehicles become more functional and their network architecture becomes more complex, network communication and interaction between controllers are becoming more frequent. Taking the charging process of new energy vehicles as an example, there are many controllers involved in the charging process with different functions. If the controllers remain in the wake-up state for a long time, the energy consumption of the whole vehicle will increase. If the controllers cannot be woken up after they go into sleep mode, some functions of the whole vehicle will not be able to be realized. Therefore, it is necessary to flexibly switch the controllers between sleep and standby states.

[0003] The problem of the vehicle's controllers failing to wake up after going into sleep mode manifests as follows: when the vehicle is in the OFF position and charging is plugged in, the vehicle often fails to wake up and cannot charge. Alternatively, the vehicle may fail to go into sleep mode after charging has stopped or ended, leading to issues such as the vehicle running out of power. [Summary of the Invention]

[0004] This application provides a controller state control method and system that uses a combination of local wake-up and network wake-up to enable each controller to flexibly switch between sleep state and standby state.

[0005] In a first aspect, embodiments of this application provide a state control method for a controller, applied to a first controller unit of a controller's state control system. The controller's state control system further includes a vehicle control unit (VCU). The first controller unit includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit. The method includes: when the first controller unit collects a connection signal between the power supply equipment and the local area through the OBC, it sends a network management message to the second controller through the OBC to wake up the second controller; and after the second controller responds to the network management message and enters a standby state, it feeds back a message signal to the VCU through a local state mechanism.

[0006] The controller state control method proposed in this application is based on the information interaction between the OBC and the charging device. It wakes up the OBC by identifying the connection signal. Based on the second controller's support for message wake-up with a unified architecture between the OBC and the second controller, it wakes up the second controller via network wake-up. Based on the mechanism that the second controller sends a message to the VCU when it enters standby mode, the VCU is woken up by a message sent by any controller, allowing the VCU to monitor the status of each controller. Finally, through the mechanism of the VCU and the second controller, other controllers are hard-wired to wake up, enabling the switching of multiple controllers participating in the charging process from sleep to standby mode. The entire process is based on the original mechanisms of each controller to wake up controllers participating in the charging process when the vehicle is in OFF mode, reducing the vehicle's energy consumption problem caused by controllers remaining in an awake state for extended periods. This avoids the need for a large battery solution, reduces vehicle development costs, solves the limitations of network management and vehicle function development caused by local network management solutions, and improves the overall development of vehicle functions.

[0007] In one possible implementation, the second controller includes an interleaved parallel bidirectional converter (BDC). After sending network management messages to the second controller, the method further includes:

[0008] By controlling the closure of the accessory relay of the BDC, a hard-wired wake-up signal is sent to the third controller to wake up the third controller; the third controller is at least one of the automotive heater PTC and the clutch controller CCU.

[0009] In one possible implementation, the second controller includes: a battery management system (BMS), a DC-DC converter, a vehicle display instrument IC, a remote communication terminal (Tbox), and an interleaved parallel bidirectional converter (BDC); through a local state mechanism that allows the second controller to enter standby mode in response to the network management message and then feed back message signals to the vehicle controller (VCU), including:

[0010] The target controller sends a message signal back to the VCU; the target controller is any one or more controllers among the BMS, the DC-DC, the IC, the Tbox, and the BDC.

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

[0012] When the first controller unit fails to detect a connection signal between the power supply equipment and the local area through the OBC, it stops sending network management messages through the OBC and begins executing a local hibernation program through the OBC.

[0013] If the network management message is not received through the second controller, the local hibernation procedure is started through the second controller.

[0014] In one possible implementation, the second control includes a battery management system (BMS) and a DC-DC converter. When the network management message is not received by the second controller, the second controller initiates a local hibernation procedure, including:

[0015] When the BMS or the DC-DC does not receive the network management message through the OBC and receives a power-down command sent by the vehicle controller (VCU), it enters a sleep state.

[0016] Secondly, embodiments of this application provide a state control method for a controller, applied to the VCU of a controller's state control system. The controller's state control system further includes a first controller unit, which includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit. The method includes:

[0017] When the VCU receives a message signal from any of the second controllers, it begins to execute the local program to enter standby mode.

[0018] The message signal is generated by the second controller after entering standby mode in response to the network management message sent by the OBC; the OBC sends the network management message to the second controller when it collects the connection signal between the power supply equipment and the local area.

[0019] In one possible implementation, after the local program for entering standby mode begins execution, the method further includes:

[0020] The system controls the closure of the local accessory relay and sends a hard-wired wake-up signal to the fourth controller to wake it up; the fourth controller includes a motor controller MCU and a generator controller GCU.

[0021] In one possible implementation, the second controller includes a battery management system (BMS) and a DC-DC converter; the method further includes:

[0022] When no working status message is received from any controller, an instruction to enter sleep mode is sent to the BMS, the DC-DC, the MCU, and the GCU.

[0023] When it detects that all controllers have stopped sending message signals, it begins to enter sleep mode.

[0024] In one possible implementation, after executing the program to enter standby mode, the method further includes:

[0025] The first online message is sent via the CAN bus to the OBC, the second controller, the motor controller MCU, and the generator controller GCU.

[0026] If no second online message is received from any specific controller, a fault alert is output to that specific controller.

[0027] Thirdly, embodiments of this application provide a state control system for a controller, which includes a first controller unit and a vehicle controller (VCU); the first controller unit includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit.

[0028] The OBC is used to collect the connection signal between the power supply equipment and the local area. When the connection signal between the power supply equipment and the local area is collected, it enters the standby state and sends a network management message to the second controller.

[0029] The second controller is used to enter a standby state and send a message signal back to the VCU when it receives the network management message;

[0030] When the VCU receives a message signal from any second controller, it enters a standby state and sends a hard-wired wake-up signal to the fourth controller.

[0031] It should be understood that the second and third aspects of the embodiments of this application are consistent with the technical solutions of the first aspect of the embodiments of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be described again. [Attached Image Description]

[0032] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a schematic diagram of the state control system of the controller proposed in the embodiments of this application;

[0034] Figure 2 This is a schematic diagram illustrating the information interaction between controllers during state switching in an example controller-based state control system according to this application.

[0035] Figure 3This is a flowchart of the state control method for the controller proposed in the embodiments of this application;

[0036] Figure 4 This is an information flow diagram of an example OBC executing a program to enter standby mode according to this application;

[0037] Figure 5 This is an information flow diagram of an example of a second controller executing a program to enter a standby state according to this application;

[0038] Figure 6 This is another flowchart of the controller state control method proposed in the embodiments of this application;

[0039] Figure 7 This is an information flow diagram of an example BDC executing a program to enter standby mode according to this application;

[0040] Figure 8 This is an information flow diagram of an example of a third controller executing a program to enter a standby state according to this application;

[0041] Figure 9 This is an information flow diagram of an example VCU executing a program to enter standby mode according to this application;

[0042] Figure 10 This is an information flow diagram of an example of a fourth controller executing a program to enter a standby state according to this application;

[0043] Figure 11 This is a flowchart of another step of the controller state control method proposed in the embodiments of this application;

[0044] Figure 12 This is an example of an OBC entering a dormant state information flow diagram according to this application;

[0045] Figure 13 This is an example information flow diagram of a BMS entering a dormant state according to this application;

[0046] Figure 14 This is an example of an information flow diagram of a DC-DC entering a dormant state according to this application;

[0047] Figure 15 This is an example of an information flow diagram of a BDC entering a dormant state according to this application;

[0048] Figure 16 This is an example of an information flow diagram of a Tbox entering a dormant state according to this application;

[0049] Figure 17 This is an information flow diagram of an example IC entering a dormant state according to this application;

[0050] Figure 18This is an example of the information flow diagram of a VCU entering a dormant state according to this application;

[0051] Figure 19 This is an example of the information flow diagram of a third controller entering a sleep state according to this application;

[0052] Figure 20 This is an example of the information flow diagram of the fourth controller entering a dormant state according to this application.

Detailed Implementation Methods

[0053] To better understand the technical solutions in this specification, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0054] It should be understood that the described embodiments are merely some, not all, of the embodiments in this specification. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without inventive effort are within the scope of protection of this specification.

[0055] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0056] To address the issue that controllers cannot sleep or wake up during the vehicle's OFF charging mode, this application proposes a controller state control system that can switch controllers involved in the charging process between sleep and standby states when the vehicle is not powered on, thereby reducing the energy consumption of the vehicle when controllers remain in a wake-up state for extended periods.

[0057] Figure 1 This is a schematic diagram of the state control system of the controller proposed in the embodiments of this application, as shown below. Figure 1 As shown, the controller's state control system includes a first controller unit and a vehicle control unit (VCU); the first controller unit includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit.

[0058] In one example of this application, the OBC and the second controller can communicate based on a multi-master automotive open system architecture (AutosarCAN, AUTOSAR).

[0059] The OBC is used to collect the connection signal between the power supply equipment and the local area. When the connection signal between the power supply equipment and the local area is collected, it enters the standby state and sends a network management message to the second controller.

[0060] In one example of this application, the power supply equipment can be a charging pile. The charging gun of a new energy vehicle is inserted into the charging pile. When the power supply equipment establishes a connection with the new energy vehicle, the OBC can detect a connection signal, which includes a CC resistance value and a CP signal. The OBC detecting the CC resistance value signal indicates that the cable connection between the charging gun and the charging pile is complete. The OBC detecting the CP signal is a pulse signal, which can indicate the capacity of the power supply equipment. Therefore, the OBC collecting both the CC and CP signals indicates that a connection has been established with the power supply equipment.

[0061] In response to the acquired connection signal, the OBC begins executing its local standby mode entry program, transitioning from hibernation to standby mode. The second controller's hardware and underlying architecture support AUTOSAR network management message wake-up, sending network management messages to the second controller via the mechanism of the OBC sending network management messages after entering standby mode.

[0062] The second controller may include a battery management system (BMS), a DC-DC bidirectional converter, a vehicle display instrument IC, a telematics box (Tbox), and a bi-directional DC-DC converter (BDC).

[0063] The OBC (Over-Battery Controller) determines the status of the charging station and feeds back the result to the BMS (Battery Management System). The BMS then determines whether the battery needs charging. The DC-DC converter is used to convert the high-voltage DC power output from the power supply equipment into low-voltage DC power for use by the electronic system. The BDC (Browser Controlled Controller) is used to bidirectionally regulate the output and input of the circuit.

[0064] The second controller is used to enter a standby state and send a message signal back to the VCU when it receives the network management message;

[0065] Since the second controller sends a message signal to the VCU whenever it enters standby mode, the VCU wake-up mechanism is configured such that the VCU enters standby mode when it receives a message signal from any second controller or the OBC. The VCU can also monitor the status of the second controllers based on the message information they send. The message signal sent by the OBC to the VCU is not a network management message, but rather a message signal indicating its own operating status.

[0066] Simultaneously, after entering standby mode, the VCU can send a hard-wired wake-up signal to the fourth controller. The fourth controller includes a motor control unit (MCU) and a generator control unit (GCU). The MCU receives vehicle driving control commands from the VCU, controls the motor to output the specified torque and speed, drives the vehicle, and converts the DC power from the power battery into the required high-voltage AC power to drive the motor to output mechanical energy. The GCU is the core component of the range-extended electric vehicle, used to start the engine and convert engine energy into electrical energy to charge the battery; therefore, the MCU and GCU also need to be woken up during the charging process.

[0067] In the above wake-up methods, the original mechanisms and interaction habits of each controller are adopted. The OBC is woken up through local wake-up, the second controller is woken up through the network management message sent by the OBC, and the original working mode of the second controller feeding back the message signal to the VCU is used to wake up the VCU. The VCU can then wake up the fourth controller through a hard-wired signal, thus realizing the state switching of the controllers participating in the charging process in the power-off state.

[0068] Another embodiment of this application proposes a method for waking up a third controller, which is a positive temperature coefficient (PTC) or a clutch control unit (CCU), or both a PTC and a CCU.

[0069] After the BDC in the second controller enters standby mode, it can send a hard-wired wake-up signal to the third controller, so that the third controller switches from sleep mode to standby mode.

[0070] Another embodiment of this application proposes that after the second controller enters standby mode, it will send a message signal to the VCU. After the VCU responds to the message signal sent by the second controller and enters standby mode, the second controller, OBC, MCU, GCU, PTC, and CCU will continuously send a second online message to the VCU. The VCU can monitor whether each controller is online based on the received second online message. If the VCU does not detect the signal of the GCU and MCU, the VCU will determine that the MCU and GCU are faulty and will prohibit the vehicle from working normally. The VCU will also send a first online signal to the OBC, the second controller, the MCU, and the GCU so that the OBC, the second controller, the MCU, and the GCU can determine whether they are online and output an alarm prompt in a timely manner when the VCU is offline.

[0071] The state control system of the controller proposed in this application embodiment further includes an OBC used to stop sending network management messages through the OBC and start executing a local sleep program when no connection signal between the power supply equipment and the local system is detected. For the BDC, Tbox, and IC, if no network management message is received, the program to enter sleep mode is executed. If the BDC, Tbox, or IC meets other judgment criteria, it enters sleep mode. After the BDC enters sleep mode, the PTC and CCU can no longer receive the hard-wired wake-up signal sent by the BDC, and the PTC and CCU start executing the local sleep mode entry program.

[0072] After the OBC enters sleep mode, it stops sending network management messages to the second controller. The second controller, not detecting any network management messages, begins executing its local sleep program. Once in sleep mode, the second controller no longer sends message signals back to the VCU. When the VCU detects that any controller is not sending a message signal locally, it determines that the charging program has malfunctioned and sends a sleep mode command to the BMS, DC-DC, MCU, and GCU. The VCU enters sleep mode when it detects that none of the controllers are sending message signals. For the DC-DC and BMS, upon receiving the sleep mode command from the VCU, they begin executing their local sleep programs. The local sleep programs for the DC-DC and BMS include: detecting whether a network management message has been received and meeting other judgment criteria. Therefore, for the DC-DC and BMS, when the BMS or DC-DC does not receive the network management message through the OBC and receives a power-down command from the vehicle controller (VCU), and other judgment criteria are met, it enters sleep mode.

[0073] One example of this application provides a method for the VCU to send an instruction to the MCU and GCU to enter a sleep state by disconnecting the auxiliary relay that wakes up the MCU, so that the MCU can no longer receive a hard-wired wake-up signal.

[0074] Figure 2 This is a schematic diagram illustrating the information interaction between controllers during state switching in an example controller-based state control system according to this application, as shown below. Figure 2As shown, the OBC detects the CC resistance or CP signal in sleep mode and wakes up to enter standby mode. After waking up, the OBC sends network management messages to the DC-DC, IC, Tbox, BDC, and BMS via the CAN line. The DC-DC, IC, Tbox, BDC, and BMS respond to the network management messages transmitted via the CAN line and switch from sleep to standby mode. In standby mode, the OBC, DC-DC, IC, Tbox, BDC, and BMS will send a second online message back to the VCU via the CAN line. The VCU in sleep mode receives the message signal from any of the controllers OBC, DC-DC, IC, Tbox, BDC, and BMS and begins to execute the local program to enter standby mode. After the BDC wakes up, it wakes up the PTC and CCU via a signal transmitted via hardwire. After the VCU wakes up, it wakes up the MCU and GCU via a signal transmitted via hardwire.

[0075] Figure 3 This is a flowchart of the state control method steps for a controller proposed in an embodiment of this application. It is applied to the first controller unit in the state control system of a controller proposed in other embodiments of this application. The state control system of the controller further includes a vehicle controller (VCU). The first controller unit includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit. Figure 3 As shown, the steps include:

[0076] Step S31: When the first controller unit collects the connection signal between the power supply equipment and the local area through the OBC, it sends a network management message to the second controller through the OBC to wake up the second controller.

[0077] When the OBC of the first controller unit acquires the connection signal, it begins to execute the program to enter standby mode. After the OBC enters standby mode, the first controller unit can send network management messages to the second controller through the OBC.

[0078] The second controller includes: BMS, DC-DC, IC, Tbox, and BDC.

[0079] Step S32: After the second controller enters the standby state in response to the network management message, it feeds back a message signal to the vehicle controller (VCU) through the local state mechanism, so that the VCU responds to the message signal and executes the program to enter the standby state.

[0080] The second controller includes: a battery management system (BMS), a DC-DC converter, a vehicle display instrument IC, a remote communication terminal (Tbox), and an interleaved parallel bidirectional converter (BDC); it feeds back message signals to the vehicle controller (VCU) through a local status mechanism after the second controller enters standby mode in response to the network management message, including:

[0081] The target controller sends a message signal back to the VCU; the target controller is any one or more controllers among the BMS, the DC-DC, the IC, the Tbox, and the BDC.

[0082] This application provides an example of the process by which the OBC executes a program to enter standby mode after acquiring a connection signal. Figure 4 This is an information flow diagram of an example OBC executing a program that enters standby mode, as described in this application. Figure 4 As shown, the process from when OBC starts executing the program to enter standby mode to when it enters standby mode includes:

[0083] K41: Determines whether the CC resistance or CP signal is detected through a hard wire;

[0084] K42: If no CC resistance or CP signal is detected, continue detection; if a CC resistance or CP signal is detected, the OBC starts the wake-up program to determine whether local initialization is complete.

[0085] K43: If OBC initialization is complete, send network management messages to BMS, DC-DC, IC, Tbox, and BDC, and send a second online message to VCU. The second online message sent by OBC contains the following data: OBC's working mode is no working mode, and OBC's working status is standby. If OBC initialization is not complete, check if the waiting time exceeds 200ms.

[0086] K44: If the waiting time does not exceed 200ms, return to K43; if the waiting time exceeds 200ms, OBC outputs an initialization failure message.

[0087] This application provides an example of the process by which a BMS, IC, Tbox, and DC-DC collect network management messages and execute a program to enter standby mode. Figure 5 This is an information flow diagram of an example of a second controller executing a program to enter a standby state, as described in this application. Figure 5 As shown, the process from when the BMS, IC, Tbox, and DC-DC start executing the program to enter standby mode to when they actually enter standby mode includes:

[0088] K51: Determines whether a wake-up signal has been detected by checking whether a network management message has been received;

[0089] K52: If a wake-up signal is detected, wake-up begins. BMS, IC, Tbox, and DC-DC determine whether local initialization is complete. If no network management message is received, the detection continues.

[0090] K53: If the initialization of BMS, IC, Tbox, and DC-DC is complete, feedback is sent to the VCU via the second online message. The second online message sent by BMS, IC, Tbox, and DC-DC contains the data that the working status of BMS, IC, Tbox, and DC-DC is standby. If the initialization of BMS, IC, Tbox, and DC-DC is not complete, it is determined whether the waiting time exceeds 200ms.

[0091] K54: If the waiting time does not exceed 200ms, return to K53; if the waiting time exceeds 200ms, display a message indicating that the initialization of BMS, IC, Tbox, and DC-DC outputs has failed.

[0092] Figure 6 This is another flowchart of the controller state control method proposed in the embodiments of this application, as follows: Figure 6 As shown, the state control method of the controller includes the following steps:

[0093] Step S61: When the first controller unit collects the connection signal between the power supply equipment and the local area through the OBC, it sends a network management message to the second controller through the OBC.

[0094] Step S62: After the second controller enters the standby state in response to the network management message, it feeds back a message signal to the vehicle controller (VCU) through the local state mechanism.

[0095] Step S63: By controlling the closing of the accessory relay of the BDC, a hard-wired wake-up signal is sent to the third controller to wake up the third controller; the third controller is at least one of the automotive heater PTC and the clutch controller CCU.

[0096] After the BDC in the second controller enters standby mode, the first controller unit can send a hard-wired wake-up signal to the third controller PTC and CCU via the BDC's accessory relay. The PTC and CCU respond to the hard-wired wake-up signal and execute their local standby mode entry procedures.

[0097] This application provides an example of the process by which a BDC collects network management messages and executes a program to enter standby mode. Figure 7 This is an information flow diagram of an example BDC executing a program to enter standby mode, as described in this application. Figure 7 As shown, the process from when BDC starts executing the program to enter standby mode to when it enters standby mode includes:

[0098] K71: Determines whether a network management message has been received;

[0099] K72: If a network management message is received, the BDC determines whether local initialization is complete; if no network management message is received, the detection continues.

[0100] K73: If BDC initialization is complete, BDC outputs a hard-wired wake-up signal to PTC and CCU;

[0101] K74: Feedback is sent to the VCU via the second online message. The second online message sent by the BDC contains data: the working status of the BDC.

[0102] Figure 8 This is an information flow diagram of an example of a third controller executing a program to enter a standby state, as described in this application. Figure 8 As shown, the process from when the PTC and CCU start executing the program to enter standby mode to when they actually enter standby mode includes:

[0103] K81: Upon receiving the hard-wired wake-up signal, the wake-up process begins, and it is determined whether local initialization is complete.

[0104] K82: If PTC and CCU initialization is complete, feedback is sent to VCU in the second online message. The second online message sent by PTC and CCU contains the data: OBC's working state is standby. If PTC and CCU initialization is not complete, it is determined whether the waiting time exceeds 300ms.

[0105] K83: If the waiting time does not exceed 300ms, return to K82; if the waiting time exceeds 300ms, PTC and CCU will output an initialization failure message.

[0106] according to Figure 4 , Figure 5 , Figure 7 , Figure 8 In the controller wake-up example shown, the controller sends a message signal to the VCU. Figure 9 This is an information flow diagram of an example VCU executing a program to enter standby mode, as described in this application. The wake-up process of the VCU upon receiving a message signal from any controller is as follows: Figure 9 As shown:

[0107] K91: The VCU determines whether a wake-up signal has been detected by detecting whether it receives a message signal sent by any controller;

[0108] K92: If a wake-up signal is detected, start the wake-up process, determine whether local initialization is complete, and continue detection if no message signal is detected.

[0109] K93: If initialization is complete, the VCU outputs a wake-up signal to the MCU and GCU via the main relay hardwire; if initialization is not complete, it checks whether the waiting time exceeds 200ms. If the waiting time does not exceed 200ms, it returns to K92; if the waiting time exceeds 200ms, the VCU outputs an initialization failure message.

[0110] K94: After VCU initialization is complete, mode recognition is performed to determine whether the current mode is charging.

[0111] K95: If it detects that the mode is not charging, the VCU switches to another mode. If it detects that the mode is charging, it sends the first online message to other controllers via the CAN bus. Other controllers may include OBC, BDC, DC-DC, IC, Tbox, etc.

[0112] This application provides an example of the process by which a fourth controller (MCU) and a GCU collect network management messages and execute a program to enter standby mode. Figure 10 This is an information flow diagram of an example of a fourth controller executing a program to enter a standby state, as described in this application. Figure 10 As shown, the process from the MCU and GCU starting to execute the program to enter standby mode to entering standby mode includes:

[0113] K101: When the MCU and GCU receive the wake-up signal sent by the VCU via hardwired, they start the wake-up process and determine whether local initialization is complete. If initialization is complete, they send a second online message to the VCU via the CAN line. The second online message sent by the MCU and GCU includes the following data: Initialization completion flag = Initialization passed; If initialization is not complete, they determine whether the waiting time exceeds 300ms.

[0114] K102: If the waiting time does not exceed 300ms, return to K101; if the waiting time exceeds 300ms, the MCU and GCU will output an initialization failure message.

[0115] Figure 11 This is a flowchart illustrating another step of the controller state control method proposed in this application embodiment, applied to the first controller unit in the controller state control system proposed in other embodiments of this application, such as... Figure 11 As shown, the steps include:

[0116] Step S111: Determine whether the connection signal between the power supply equipment and the local area has been collected;

[0117] Step S112: When the first controller unit collects the connection signal between the power supply equipment and the local area through the OBC, it sends a network management message to the second controller through the OBC to wake up the second controller.

[0118] Step S1121: After the second controller enters the standby state in response to the network management message, it feeds back a message signal to the vehicle controller (VCU) through the local state mechanism, so that the VCU responds to the message signal and executes the program to enter the standby state.

[0119] Step S113: When the first controller unit fails to detect the connection signal between the power supply equipment and the local area through the OBC, it stops sending network management messages through the OBC and starts executing the local hibernation program through the OBC;

[0120] Step S1131: When no network management message is received through the second controller, the local hibernation procedure is started through the second controller.

[0121] In the second controller, the BMS and DC-DC determine whether to enter a sleep state based on network management messages and instructions sent by the VCU. When the BMS or DC-DC does not receive the network management message through the OBC but receives a power-down instruction from the vehicle controller (VCU), it enters a sleep state.

[0122] If the OBC fails to detect a connection signal between the power supply equipment and the local area, it will execute its local sleep program and stop sending network management messages to the second controller. The second controller's BDC, IC, and Tbox, upon detecting the lack of network management messages, will then begin executing their local sleep programs.

[0123] After the second controller completes its local sleep program and enters sleep mode, it stops sending feedback messages to the VCU. When the VCU does not receive any feedback messages from any controller, it begins to execute its local sleep program, which includes sending instructions to the BMS, the DC-DC, the MCU, and the GCU to enter sleep mode. When the VCU does not receive feedback messages from all controllers, it completes its local sleep program and enters sleep mode.

[0124] If the MCU and GCU cannot detect the hard-wired wake-up signal sent by the VCU, they will start executing the local sleep program. If the PTC and CCU cannot detect the hard-wired wake-up signal sent by the BDC, they will start executing the local sleep program.

[0125] This application provides an example of the process by which an OBC executes a local hibernation procedure. Figure 12 This is an example of an information flow diagram of an OBC entering a dormant state, as described in this application. Figure 12 As shown, the process from when OBC starts executing the program to enter standby mode to when it enters standby mode includes:

[0126] K121: Determines whether the CC resistance value or CP signal has been acquired;

[0127] K122: If a CC resistance value or CP signal is acquired, determine whether the timer wait exceeds 5 minutes. If the timer wait exceeds 5 minutes, the OBC stops sending network management messages to the second controller and checks whether a CC resistance value or CP signal can still be acquired. If a CC resistance value or CP signal can still be acquired, power on again to enter standby mode. If a CC resistance value or CP signal cannot be acquired, the OBC enters sleep mode.

[0128] K123: If the CC resistance value or CP signal cannot be acquired, check if the waiting timer exceeds 10 seconds. If the waiting timer exceeds 10 seconds, the OBC stops sending network management messages to the second controller and checks if the CC resistance value or CP signal can still be acquired. If the CC resistance value or CP signal can continue to be acquired, power on again to enter standby mode. If the CC resistance value or CP signal cannot continue to be acquired, the OBC enters sleep mode.

[0129] This application provides an example of the process by which a BMS executes a local hibernation procedure. Figure 13 This is an example of an information flow diagram of a BMS entering a dormant state, as described in this application. Figure 13 As shown, the process from when the BMS starts executing the program to enter standby mode to when it enters standby mode includes:

[0130] K131: Receives a power-down command from VCU. The power-down command includes the data: Battery enable = None. BMS feeds back the current status data to VCU and determines whether a wake-up signal has been detected by checking whether a network management message has been received.

[0131] K132: If a network management message is received, determine whether the local wake-up condition is met. If the wake-up condition is met, power on again and enter standby mode. If the wake-up condition is not met, return to K131 to determine whether a network management message has been received.

[0132] K133: If no network management message is received, check if the timer wait exceeds 1 second. If the timer wait does not exceed 1 second, return to K131 to check if a network management message has been received. If the timer wait exceeds 1 second, check if a network management message is still not received to determine whether network management messages should be stopped. A threshold for the number of times a network management message cannot be received can be preset.

[0133] K134: If it is determined that network management messages have stopped being sent, the BMS enters a sleep state. If it is determined that network management messages have not stopped being sent, return to K133 to check whether network management messages are still not being received.

[0134] This application provides an example of the process by which a DC-DC executes a local hibernation procedure. Figure 14This is an example of an information flow diagram of a DC-DC converter entering a dormant state, as described in this application. Figure 14 As shown, the process from when the DC-DC starts executing the program to enter standby mode to when it enters standby mode includes:

[0135] K141: Receives a power-down command from the VCU. The power-down command includes the following data: DC-DC disabled. When the DC-DC detects that it is locally disabled, it stops outputting and feeds back the current status data to the VCU. It also determines whether to stop sending network management messages by detecting whether network management messages are continuously unreceived. A threshold for the number of times network management messages are continuously unreceived can be preset.

[0136] K142: If it is determined that network management messages have stopped being sent, the DC-DC enters a sleep state. If it cannot be determined that network management messages have stopped being sent, return to K141 to check whether network management messages are still not being received.

[0137] This application provides an example of the process by which a BDC executes a local hibernation procedure. Figure 15 This is an example of an information flow diagram of a BDC entering a dormant state, as described in this application. Figure 15 As shown, the process from when BDC starts executing the program to enter standby mode to when it enters standby mode includes:

[0138] K151: Determines whether a wake-up signal has been detected by checking whether network management messages have been collected;

[0139] K152: If no network management message is detected, stop outputting the hard-wired wake-up signal of the accessory relay to the PTC and CCU, and determine whether the BDC meets the sleep conditions by detecting whether the network management message is continuously not received.

[0140] K153: If the hibernation conditions are met, the BDC enters hibernation mode. If the hibernation conditions are not met, return to K152 to determine whether the BDC meets the hibernation conditions by checking whether network management messages are continuously not received.

[0141] This application provides an example of the process by which a Tbox executes a local hibernation procedure. Figure 16 This is an example of an information flow diagram of a Tbox entering a dormant state, as described in this application. Figure 16 As shown, the process from when the Tbox starts executing the program to enter standby mode to when it enters standby mode includes:

[0142] K161: Determines whether a wake-up signal has been detected by checking whether a network management message has been received;

[0143] K162: If a wake-up signal is detected, the local conditions are checked to determine whether the conditions for another wake-up are met. If the conditions for another wake-up are met, Tbox is re-executed. Figure 5The program shown enters standby mode locally; if the condition is not met and the program is woken up again, it returns to K161.

[0144] K163: If no wake-up signal is detected, determine whether network management messages have stopped being sent by checking whether wake-up signals are continuously collected. If it is determined that network management messages have stopped being sent, Tbox determines whether the data has been sent completely. If it cannot be determined that network management messages have stopped being sent, continue to try to collect network management messages.

[0145] K164: If data transmission is complete, the Tbox enters sleep mode; if data transmission is incomplete, the Tbox continues to transmit data.

[0146] This application provides an example of the process by which an IC executes a local sleep procedure. Figure 17 This is an example of an IC entering a sleep state, as shown in the information flow diagram of this application. Figure 17 As shown, the process from the IC starting to execute the program to enter standby mode to entering standby mode includes:

[0147] K171: Determines whether a wake-up signal has been detected by checking whether a network management message has been received;

[0148] K172: If a wake-up signal is detected, the IC determines whether the conditions for re-wake-up are met by judging local conditions. If the conditions for re-wake-up are met, the IC re-executes. Figure 5 The program shown enters standby mode locally; if the condition is not met and the device is woken up again, it returns to K171.

[0149] K173: If no wake-up signal is detected, the IC determines whether network management messages have stopped being sent by judging whether a wake-up signal is continuously collected. If it is determined that network management messages have stopped being sent, the IC determines whether the data has been sent completely. If it cannot be determined that network management messages have stopped being sent, the IC continues to try to collect network management messages.

[0150] This application provides an example of the process by which a VCU executes a local hibernation procedure. Figure 18 This is an example of an information flow diagram for a VCU entering a dormant state, as described in this application. Figure 18 As shown, the process from when the VCU starts executing the program to enter standby mode to when it enters standby mode includes:

[0151] K181: The system determines whether the BMS is in standby mode by detecting whether it receives a message from the BMS indicating that its working status is "standby". It also determines whether the DC-DC is in standby mode by detecting whether it receives a message from the DC-DC indicating that its working status is "standby". Figure 13 and Figure 14As shown, the BMS and DC-DC receive the command to enter sleep mode from the VCU and start executing the local standby mode program. When the VCU does not receive any working status message from any controller, it sends a command to enter sleep mode to the BMS and DC-DC. This command to enter sleep mode can be a low-voltage standby command.

[0152] K182: If the BMS and DC-DC are in standby mode, determine whether a wake-up signal has been detected by checking whether all controller feedback messages have been received; if the BMS and DC-DC are not in standby mode, determine whether the waiting time of the last feedback message from the BMS and DC-DC exceeds 500ms. If it exceeds 500ms, determine whether a wake-up signal has been detected by checking whether all controller feedback messages have been received. If it does not exceed 500ms, return to K181.

[0153] K183: If a wake-up signal is detected, according to... Figure 9 The process shown determines whether the conditions for another wake-up are met. If the conditions for another wake-up are met, the VCU executes the program to enter the standby state. If the conditions for another wake-up are not met, it returns to K172.

[0154] K184: If no wake-up signal is detected, determine whether the time since the wake-up signal was not detected exceeds 0.1s. If it does not exceed 0.1s, continue to detect whether a wake-up signal is acquired. If it exceeds 0.1s, stop outputting the hard-wired wake-up signal to the MCU and GCU.

[0155] K185: Determines whether network management messages have stopped by continuously collecting all the message signals fed back by the controllers. If it is determined that network management messages have stopped, the VCU enters a sleep state.

[0156] This application provides an example of the process by which a third controller, PTC, and CCU execute a local hibernation program. Figure 19 This is an example of an information flow diagram of a third controller entering a sleep state, as described in this application. Figure 19 As shown, the process from when the PTC and CCU start executing the program to enter standby mode to when they actually enter standby mode includes:

[0157] K191: Determines whether a wake-up signal has been detected by detecting whether a hardwired signal sent by the BCD has been received;

[0158] K192: If a wake-up signal is detected, return to K191. If no wake-up signal is detected, determine whether the duration of no wake-up signal detection exceeds 0.1s. If it exceeds 0.1s, PTC and CCU enter sleep mode.

[0159] This application provides an example of the process by which the fourth controller, MCU, GCU, executes a local sleep program. Figure 20This is an example of an information flow diagram of the fourth controller entering a sleep state, as described in this application. Figure 20 As shown, the process from the MCU and GCU starting to execute the program to enter standby mode to entering standby mode includes:

[0160] K201: Determines whether a wake-up signal has been detected by detecting whether a hardwired signal sent by the VCU has been received;

[0161] K202: If a wake-up signal is detected, return to K201. If no wake-up signal is detected, determine whether the duration of no wake-up signal detection exceeds 0.2s. If it exceeds 0.2s, the MCU and GCU enter sleep mode.

[0162] The controller state control method provided in the above embodiments is used to execute the technical solution of the above method embodiments. Its implementation principle and technical effect can be further referred to the relevant description in the controller state control system embodiments, and will not be repeated here.

[0163] Another embodiment of this application proposes a state control method for a controller applied to a VCU, which is applied to a VCU of a controller state control system proposed in other embodiments of this application. The controller state control system further includes a first controller unit, which includes an on-board charger (OBC) and a second controller that communicates with the OBC based on the architecture of the first controller unit. The method includes:

[0164] When the VCU receives a message signal from any of the second controllers, it begins to execute the local program to enter standby mode.

[0165] The message signal is generated by the second controller after entering standby mode in response to the network management message sent by the OBC; the OBC sends the network management message to the second controller when it collects the connection signal between the power supply equipment and the local area.

[0166] Optionally, after starting the local program for entering standby mode, the method further includes:

[0167] The system controls the closure of the local accessory relay and sends a hard-wired wake-up signal to the fourth controller to wake it up; the fourth controller includes a motor controller MCU and a generator controller GCU.

[0168] Optionally, the second controller includes a battery management system (BMS) and a DC-DC converter; the method further includes:

[0169] When no working status message is received from any controller, an instruction to enter sleep mode is sent to the BMS, the DC-DC, the MCU, and the GCU.

[0170] When it detects that all controllers have stopped sending message signals, it begins to enter sleep mode.

[0171] Optionally, after executing the procedure for entering standby mode, the method further includes:

[0172] The first online message is sent via the CAN bus to the OBC, the second controller, the motor controller MCU, and the generator controller GCU.

[0173] If no second online message is received from any specific controller, a fault alert is output to that specific controller.

[0174] Optional examples of the state control method of the controller in this application have been described in the embodiment applied to the first controller unit side, and the embodiment on the VCU side will not repeat the same content.

[0175] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0176] In the description of the embodiments in this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0177] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this specification, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0178] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this specification includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which the embodiments of this specification pertain.

[0179] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0180] It should be noted that the terminals involved in the embodiments of this application may include, but are not limited to, personal computers (PCs), personal digital assistants (PDAs), wireless handheld devices, tablet computers, mobile phones, MP3 players, MP4 players, etc.

[0181] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0182] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0183] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0184] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A state control method of a controller characterized by, The application discloses a first controller unit applied to a state control system of a controller, and the state control system of the controller further comprises a vehicle control unit (VCU). The first controller unit comprises an on-board charger (OBC) and a plurality of second controllers which realize communication based on a multi-master automotive open system architecture (AUTOSAR) with the OBC. The plurality of second controllers comprises a battery management system (BMS), a direct-current-direct-current bidirectional converter (DC-DC), an integrated circuit (IC) of a vehicle display instrument, a remote communication terminal (Tbox) and an interleaved bidirectional converter (BDC). The method comprises the following steps: When the first controller unit collects a connection signal between a power supply device and a local device through the OBC, a network management message is sent to the plurality of second controllers through the OBC to wake up the plurality of second controllers. After any second controller of the plurality of second controllers enters a standby state in response to the network management message, a local state mechanism is fed back to the VCU, a message signal is fed back to the VCU, the message signal indicates that the corresponding second controller has entered the standby state, the VCU is woken up, and a hard-wired wake-up signal is sent to a fourth controller after the VCU enters the standby state, the fourth controller comprises a motor controller (MCU) and a generator controller (GCU).

2. The method of claim 1, wherein, After the network management message is sent to the plurality of second controllers, the method further comprises the following steps: A hard-wired wake-up signal is sent to a third controller by controlling the closing of an accessory relay of the BDC to wake up the third controller, the third controller is at least one of a car heater (PTC) and a clutch controller (CCU).

3. The method of claim 1, wherein, The local state mechanism fed back to the VCU after any second controller of the plurality of second controllers enters the standby state in response to the network management message comprises the following steps: A message signal is fed back to the VCU by a target controller, the target controller is any one or any plurality of controllers in the BMS, the DC-DC, the IC, the Tbox and the BDC.

4. The method of claim 1, wherein, The method further comprises the following steps: When the first controller unit does not collect the connection signal between the power supply device and the local device through the OBC, the network management message is stopped from being sent through the OBC, and a local sleep program is started to be executed through the OBC; When the network management message is not received through any second controller, a local sleep program is started to be executed through the corresponding second controller.

5. The method of claim 4, wherein, When the network management message is not received through any second controller, a local sleep program is started to be executed through the corresponding second controller, comprising the following steps: When the BMS or the DC-DC does not receive the network management message through the OBC and receives a power-off instruction sent by the VCU, a sleep state is entered.

6. A state control method of a controller, characterized by, The VCU applied to the state control system of a controller further comprises a first controller unit, the first controller unit comprises an on-board charger (OBC) and a plurality of second controllers which realize communication with the OBC based on a multi-master automotive open system architecture, the plurality of second controllers comprises a battery management system (BMS), a direct-current-direct-current bidirectional converter (DC-DC), an integrated vehicle display instrument (IC), a remote communication terminal (Tbox) and an interleaved parallel bidirectional converter (BDC), and the method comprises: When the VCU receives a message signal fed back by any of the plurality of second controllers, a local standby state entering procedure is started to be executed; The message signal is generated by any of the plurality of second controllers in response to a network management message sent by the OBC after entering the standby state; and the OBC sends the network management message to the plurality of second controllers when a connection signal of a power supply device with the local is collected; After the local standby state entering procedure is started to be executed, the method further comprises: controlling a local accessory relay to be closed, and issuing a hardwire wake-up signal to a fourth controller to wake up the fourth controller; the fourth controller comprises a motor controller (MCU) and a generator controller (GCU).

7. The method of claim 6, wherein, The method further comprises: when no working state message sent by any of the second controllers is received, sending an instruction to enter a sleep state to the BMS, the DC-DC, the MCU and the GCU; when it is detected that all controllers stop sending message signals, a sleep state is started to be entered.

8. The method of claim 6, wherein, After the standby state entering procedure is executed, the method further comprises: sending a first online message to the OBC, the second controllers, the MCU and the GCU through a CAN bus; when no second online message fed back by any of a plurality of specific controllers is received, outputting a fault reminder to the specific controllers, the plurality of specific controllers comprise the OBC, the second controllers, the MCU, the GCU, an automobile heater (PTC) and a clutch controller (CCU), wherein the PTC and the CCU are woken up by issuing a hardware wake-up signal after being woken up by the BDC.

9. A state control system of a controller characterized by, The state control system of the controller comprises a first controller unit and a vehicle controller (VCU); the first controller unit comprises an on-board charger (OBC) and a plurality of second controllers which realize communication with the OBC based on a multi-master automotive open system architecture, the plurality of second controllers comprises a battery management system (BMS), a direct-current-direct-current bidirectional converter (DC-DC), an integrated vehicle display instrument (IC), a remote communication terminal (Tbox) and an interleaved parallel bidirectional converter (BDC); the OBC is used to collect a connection signal of a power supply device with the local, and when the connection signal of the power supply device with the local is collected, a network management message is sent to the plurality of second controllers in a standby state; Any second controller in the plurality of second controllers is configured to enter a standby state and feed back a message signal to the VCU when receiving the corresponding network management message, the message signal indicating that the corresponding second controller has entered the standby state; The VCU is configured to enter the standby state and issue a hard-wired wake-up signal to a fourth controller when receiving the message signal fed back by any second controller, the fourth controller including a motor controller MCU and a generator controller GCU.

Images