Electronic control unit ECU sleep method, ECU, system and vehicle

Abstract

The present application provides a sleep method for an electronic control unit (ECU), an ECU, a system, and a vehicle. The method is applied to a vehicle comprising a controller area network (CAN) and a gateway, wherein the CAN comprises a CAN bus and an ECU, and the ECU is connected to the gateway via the CAN bus. The method comprises: the ECU receiving a power-off signal from the gateway; the ECU determining the presence of a service process in the ECU; the ECU identifying the type of service being executed by the service process; the ECU determining, based on the service type, that the service is abnormal; and the ECU terminating the service process and executing a sleep mode. In an embodiment of the present application, when a service in the ECU is abnormal, the ECU can terminate the service process and execute a sleep mode, thereby reducing vehicle power consumption and conserving vehicle battery power.

Description

Technical Field

[0001] The embodiments of the present application relate to communication technology, and in particular to a sleep method for an electronic control unit (ECU), an ECU, a system, and a vehicle. Background Art

[0002] Vehicles contain multiple electronic control units (ECUs), each with its own unique functionality. For example, the air conditioning ECU controls the vehicle's temperature, while the engine ECU controls the engine's air intake, fuel injection, and ignition timing to control vehicle speed.

[0003] Currently, when a vehicle's power is turned off, if the ECU is not actively processing, it can enter sleep mode, minimizing power consumption and conserving battery life. However, if the data network is abnormal or the ECU fails, this can cause ECU service anomalies, forcing the ECU to remain active, further consuming the vehicle's power. Summary of the Invention

[0004] The present application provides a sleep method for an electronic control unit (ECU), an ECU, a system, and a vehicle, which can reduce vehicle power consumption.

[0005] In a first aspect, the present application provides an ECU hibernation method, which is applied to a vehicle. The vehicle includes a controller area network (CAN) and a gateway. The CAN includes a CAN bus and an ECU, and the ECU is connected to the gateway via the CAN bus. The method includes: when the vehicle's power is turned off, the gateway may send a power-off signal to each ECU in the CAN. This application uses ECUs in the CAN as an example for illustration. Upon receiving the power-off signal from the gateway, the ECU may detect whether a service process exists in the ECU. If no service process exists, the ECU may enter hibernation. If a service process exists, the ECU may enter hibernation after the service process completes execution. If a service in the ECU is abnormal, the ECU cannot enter hibernation. In this application, the ECU may identify the type of service executed by the service process and, based on the service type, determine that the service is abnormal. If the service is abnormal, the ECU terminates the service process and enters hibernation. Terminating a service process can also be understood as shutting down the service process. While a service process normally releases the service process after completing its service, in this application, when a service is abnormal, the service process is terminated, eliminating the service process from the ECU, allowing the ECU to enter hibernation.

[0006] In this application, when the business in the ECU is abnormal, the ECU can terminate the business process and execute hibernation, thereby reducing the vehicle's power consumption and saving the vehicle's battery power.

[0007] The following describes how the ECU determines service anomalies and terminates the service process based on the type of service in the ECU:

[0008] In the first method, the service includes a service that relies on the CAN bus to transmit messages. Because this service relies on the CAN bus to transmit messages, the ECU can detect whether the CAN is dormant within a first preset time period to detect whether the service is abnormal. Specifically, when the ECU receives a power-off signal from the gateway, it can start a timer to detect whether the CAN is dormant within the first preset time period. If the CAN is not dormant within the first preset time period, it indicates that the service has been executed and the service is abnormal. If the CAN is dormant within the first preset time period, it indicates that the service is executed normally and the service is normal. In this application, when the CAN bus transmits a message within a second preset time period, the CAN can be dormant. Therefore, in this application, the ECU can detect whether the CAN bus transmits a CAN message within the second preset time period to determine whether the CAN is dormant. Specifically, if the CAN bus does not transmit a CAN message within the second preset time period, the ECU determines that the CAN is dormant. If the CAN bus transmits a CAN message within the second preset time period, the ECU determines that the CAN is not dormant. The first preset time period can be greater than the second preset time period.

[0009] In this manner, the ECU can terminate the service process by restarting. If there are no service processes in the ECU after the restart, the ECU can send a sleep request to the gateway. Upon receiving a sleep response from the gateway, the ECU can enter sleep mode. The timer duration is the first preset duration.

[0010] In this way, the ECU includes a service that relies on the CAN bus to transmit messages. The ECU can start a timer when receiving a power-off signal from the gateway. If the CAN does not go into sleep mode within a first preset time period, the ECU determines that the service is abnormal and then performs sleep mode by restarting to reduce vehicle power consumption and save vehicle battery power.

[0011] In this application, the ECU is not forced to sleep, but rather restarted, to prevent the gateway from mistakenly identifying the ECU as faulty. Because the service relies on the CAN bus, the normal sleep process for the ECU is to send a sleep request to the gateway. However, if the ECU is forced to sleep without requesting sleep from the gateway, the gateway will determine that the ECU has not executed the normal sleep process and, therefore, that the ECU is faulty, resulting in an incorrect judgment.

[0012] In this method, if the CAN is dormant within a first preset duration, it indicates that the service that relies on the CAN bus to transmit messages is normal. In one possible implementation, the ECU may also contain services that do not rely on the CAN bus to transmit messages. The ECU may detect whether the service that does not rely on the CAN bus to transmit messages is abnormal by: when the ECU detects that the CAN is dormant within the first preset duration, the ECU detects whether the ECU has completed the service that does not rely on the CAN bus to transmit messages within the first preset duration; if the ECU has completed the service that does not rely on the CAN bus to transmit messages within the first preset duration, it is determined that the service that does not rely on the CAN bus to transmit messages is normal; if the ECU has not completed the service that does not rely on the CAN bus to transmit messages within the first preset duration, it is determined that the service that does not rely on the CAN bus to transmit messages is abnormal. When the service that does not rely on the CAN bus to transmit messages is normal, the ECU may enter dormancy. When the service that does not rely on the CAN bus to transmit messages is abnormal, the ECU may terminate the service process and enter dormancy.

[0013] In this way, the ECU includes a service that does not rely on the CAN bus to transmit messages. The ECU can start a timer when the CAN is in sleep mode. If the ECU fails to complete the service within the first preset time period, the ECU determines that the service is abnormal and then forces the service to go into sleep mode, i.e., terminate the service process to reduce vehicle power consumption and save vehicle battery power.

[0014] The second way: the business is a business that relies on the CAN bus to transmit messages. In this way, the ECU can detect that the CAN is dormant, and the ECU starts a timer to determine whether the ECU has completed the execution of the business within a first preset time length, and then determines whether the business is abnormal. Wherein, if the ECU completes the execution of the business within the first preset time length, the business is determined to be normal; if the ECU does not complete the execution of the business within the first preset time length, the business is determined to be abnormal. Wherein, the duration of the timer is the first preset time length. The way for the ECU to detect CAN dormancy can be: the ECU detects that the CAN bus has not transmitted a message within a second preset time length, determines that the CAN is dormant, and the second preset time length is less than the first preset time length.

[0015] In this way, if the business in the ECU is not dependent on the CAN bus to transmit messages, the ECU can start a timer when the CAN is in sleep mode. If the ECU fails to complete the business within the first preset time period, the ECU determines that the business is abnormal and then forces the execution of sleep mode, i.e., terminates the business process to reduce vehicle power consumption and save vehicle battery power.

[0016] In a second aspect, the present application provides an ECU hibernation method, which is applied to a vehicle, wherein the vehicle includes a controller area network (CAN) and a gateway, the CAN includes a CAN bus and an ECU, and the ECU is connected to the gateway through the CAN bus. The method includes: the ECU receives a power-off signal from the gateway; the ECU determines that there is a business process in the ECU; the ECU identifies the type of business executed by the business process; the ECU determines whether the business is abnormal based on the type of business; if the business is normal, the ECU executes hibernation; if the business is abnormal, the ECU terminates the business process and executes hibernation.

[0017] In one possible implementation, the business includes a business that relies on the CAN bus to transmit messages; the ECU determines whether the business is abnormal based on the type of the business, including: the ECU detects whether the CAN is dormant within the first preset time period; if the CAN is dormant within the first preset time period, it is determined that the business is normal; if the CAN is not dormant within the first preset time period, it is determined that the business is abnormal.

[0018] In a possible implementation, the ECU is restarted. In a possible implementation, after the ECU is restarted, the method further includes: the ECU sending a sleep request to the gateway; and the ECU receiving a sleep response from the gateway.

[0019] In a possible implementation, before the ECU detects whether the CAN is dormant within the first preset time period, the method further includes: the ECU starting a timer, where the timer has a duration equal to the first preset time period.

[0020] In one possible implementation, the service is a service that does not rely on the CAN bus to transmit messages, and the ECU determines whether the service is abnormal based on the type of the service, including: when the ECU detects that the CAN is dormant within the first preset time period, the ECU detects whether the ECU has completed executing the service that does not rely on the CAN bus to transmit messages within the first preset time period; if the ECU completes executing the service that does not rely on the CAN bus to transmit messages within the first preset time period, it is determined that the service that does not rely on the CAN bus to transmit messages is normal; if the ECU does not complete executing the service that does not rely on the CAN bus to transmit messages within the first preset time period, it is determined that the service that does not rely on the CAN bus to transmit messages is abnormal.

[0021] In one possible implementation, the service is a service that does not rely on the CAN bus to transmit messages, and the ECU determines whether the service is abnormal based on the type of the service, including: the ECU detecting whether the ECU has completed executing the service within a first preset time period; if the ECU has completed executing the service within the first preset time period, determining that the service is normal; if the ECU has not completed executing the service within the first preset time period, determining that the service is abnormal.

[0022] In a possible implementation, before the ECU detects whether the ECU has completed executing the service within a first preset time period, the method further includes: when the ECU detects that the CAN is dormant, the ECU starts the timer.

[0023] In a possible implementation, the method further includes: the ECU detecting that the CAN bus has not transmitted any message within a second preset time period, determining that the CAN is dormant, and the second preset time period is less than the first preset time period.

[0024] In the third aspect, the present application provides an ECU, which is arranged in a vehicle, the vehicle includes a controller area network CAN and a gateway, the CAN includes a CAN bus and the ECU, the ECU is connected to the gateway through the CAN bus, and the ECU includes a signal detection module, a power management module and a process management module: the signal detection module is used to receive a power-off signal from the gateway; the power management module is used to determine the existence of a business process in the ECU, and to identify the type of business executed by the business process; according to the type of the business, the business is determined to be abnormal; the process management module terminates the business process and controls the ECU to perform sleep.

[0025] In a possible implementation, the service includes a service that relies on the CAN bus to transmit messages; the power management module is specifically configured to detect that the CAN bus has not been in sleep mode within a first preset time period, and determine that the service is abnormal.

[0026] In one possible implementation, the power management module is specifically used to control the ECU to restart so that the process management module terminates the business process; the signal detection module is also used to send a sleep request to the gateway and receive a sleep response from the gateway.

[0027] In a possible implementation, the power management module is further configured to start a timer before detecting that the CAN has not gone into sleep mode within a first preset time period, where the timer has a duration equal to the first preset time period.

[0028] In one possible implementation, the service is a service that does not depend on the CAN bus to transmit messages; the power management module is specifically used to detect whether the service that does not depend on the CAN bus to transmit messages is completed within the first preset time when the CAN is dormant within the first preset time; if the service that does not depend on the CAN bus to transmit messages is completed within the first preset time, it is determined that the service that does not depend on the CAN bus to transmit messages is normal; if the service that does not depend on the CAN bus to transmit messages is not completed within the first preset time, it is determined that the service that does not depend on the CAN bus to transmit messages is abnormal.

[0029] In a possible implementation, the service is a service that does not rely on the CAN bus to transmit messages; the power management module is specifically configured to detect that the ECU has not completed executing the service within a first preset time period, and then determine that the service is abnormal.

[0030] In a possible implementation, the power management module is further configured to detect that the ECU has not completed executing the service within a first preset time period, and when it is detected that the CAN is in sleep mode, start a timer, the timer duration being the first preset time period.

[0031] In a possible implementation, the power management module is further configured to detect that the CAN bus has not transmitted any message within a second preset time period, and determine that the CAN is in sleep mode, wherein the second preset time period is less than the first preset time period.

[0032] In a fourth aspect, the present application provides an ECU, which is arranged in a vehicle, the vehicle including a controller area network (CAN) and a gateway, the CAN including a CAN bus and the ECU, the ECU being connected to the gateway through the CAN bus, and the ECU including a signal detection module, a power management module and a process management module: the signal detection module is used to receive a power-off signal from the gateway; the power management module is used to determine whether there is a business process in the ECU, and to determine whether the business is abnormal based on the type of the business; if the business is normal, the ECU is controlled to perform sleep; if the business is abnormal, the process management module is used to terminate the business process and control the ECU to perform a sleep operation.

[0033] In one possible implementation, the business includes a business that relies on the CAN bus to transmit messages; the power management module is specifically used to detect whether the CAN is dormant within a first preset time period; if the CAN is dormant within the first preset time period, the business is determined to be normal; if the CAN is not dormant within the first preset time period, the business is determined to be abnormal.

[0034] In one possible implementation, the power management module is specifically used to control the ECU to restart so that the process management module terminates the business process; the signal detection module is also used to send a sleep request to the gateway and receive a sleep response from the gateway.

[0035] In a possible implementation, the power management module is further configured to start a timer before detecting whether the CAN is dormant within a first preset time period, where the timer has the first preset time period.

[0036] In one possible implementation, the service is a service that does not rely on the CAN bus to transmit messages; the power management module is specifically used to detect whether the service is completed within a first preset time period; if the service is completed within the first preset time period, the service is determined to be normal; if the service is not completed within the first preset time period, the service is determined to be abnormal.

[0037] In a possible implementation, the power management module is specifically configured to detect whether the service is completed within a first preset time period, and when the CAN is detected to be in sleep mode, start a timer, the timer duration being the first preset time period.

[0038] In a possible implementation, the power management module is further configured to detect that the CAN bus has not transmitted any message within a first preset time period, and determine that the CAN is in sleep mode, wherein the first preset time period is less than the first preset time period.

[0039] In a fifth aspect, the present application provides a hibernation system for use in a vehicle. The hibernation system includes a gateway and a controller area network (CAN), wherein the CAN includes a CAN bus and the ECU described in the third aspect, the fourth aspect, and each possible implementation. The ECU is connected to the gateway via the CAN bus, and the gateway is configured to send a power-off signal to the ECU.

[0040] In a sixth aspect, the present application provides a vehicle comprising the hibernation system according to the fifth aspect above.

[0041] In a seventh aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method in the first or second aspect above.

[0042] In an eighth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method in the first or second aspect above.

[0043] The beneficial effects of the possible implementations of the second to eighth aspects can be found in the beneficial effects brought about by the first aspect and the possible implementations of the first aspect, and are not elaborated here.

[0044] The present application provides a sleep method for an electronic control unit (ECU), an ECU, a system, and a vehicle. The method is applied to a vehicle comprising a controller area network (CAN) and a gateway, wherein the CAN comprises a CAN bus and an ECU, and the ECU is connected to the gateway via the CAN bus. The method comprises: the ECU receiving a power-off signal from the gateway; the ECU determining the presence of a business process in the ECU; the ECU identifying the type of business being executed by the business process; the ECU determining a business anomaly based on the business type; and the ECU terminating the business process and executing a sleep mode. In the present application, when a business anomaly in the ECU occurs, the ECU can terminate the business process and execute a sleep mode, thereby reducing vehicle power consumption and conserving vehicle battery power. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 A schematic diagram of a network structure in a vehicle;

[0046] Figure 2 A structural diagram of ECU;

[0047] Figure 3 A schematic diagram of a process of ECU sleep;

[0048] Figure 4A This is another structural diagram of the ECU;

[0049] Figure 4B For Figure 4A Corresponding interactive process diagram;

[0050] Figure 5 This is a schematic diagram of ECU state switching;

[0051] Figure 6 It is the state transition diagram of ECU;

[0052] Figure 7A For Figure 3 A sleep timing diagram of the corresponding ECU;

[0053] Figure 7B For Figure 7A The corresponding timing diagram of the ECU being unable to sleep when the business is abnormal;

[0054] Figure 7C For Figure 3 Another sleep timing diagram of the corresponding ECU;

[0055] Figure 7D For Figure 7CThe corresponding timing diagram of the ECU being unable to sleep when the business is abnormal;

[0056] Figure 8A A flowchart of an embodiment of the ECU sleep method provided in an embodiment of the present application;

[0057] Figure 8B A flowchart of another embodiment of the ECU sleep method provided in an embodiment of the present application;

[0058] Figure 9 For Figure 8B The corresponding ECU sleep timing diagram;

[0059] Figure 10 A flowchart of another embodiment of the ECU sleep method provided in an embodiment of the present application;

[0060] Figure 11 For Figure 10 A sleep timing diagram of the corresponding ECU;

[0061] Figure 12 For Figure 10 Another sleep timing diagram of the corresponding ECU;

[0062] Figure 13 A flowchart of another embodiment of the ECU sleep method provided in the embodiment of the present application. DETAILED DESCRIPTION

[0063] Figure 1 This is a schematic diagram of a network structure in a vehicle. Figure 1 As shown, the vehicle includes a gateway (GW) and a controller area network (CAN). The CAN may include, but is not limited to, a body CAN, a chassis CAN, a powertrain CAN, a diagnostic CAN, and an infotainment CAN. Each CAN includes a CAN bus and at least one electronic control unit (ECU). ECUs in the same CAN are connected via the CAN bus in that CAN, and each CAN is connected to the gateway via its own CAN bus. Figure 1In the figure, the dashed box represents the controller area network, and the solid line represents the CAN bus. It should be understood that the CAN bus in the body controller area network can be called the body control bus, the CAN bus in the chassis controller area network can be called the chassis control bus, the CAN bus in the powertrain controller area network can be called the powertrain bus, the CAN bus in the diagnostic controller area network can be called the diagnostic control bus, and the CAN bus in the entertainment system controller area network can be called the entertainment system bus.

[0064] The body controller area network (BCAN) may include, but is not limited to, the air conditioner (AC) ECU, tire pressure monitoring system (TPMS) ECU, and body control module (BCM) ECU. ECUs in the BAN are connected via the BCB. The chassis controller area network (CCN) may include, but is not limited to, the antilock brake system (ABS) ECU, electronic stability program (ESP) ECU, and electric power steering (EPS) ECU. ECUs in the CCAN are connected via the CCB. The powertrain controller area network (PCN) may include, but is not limited to, the engine control module (ECM) ECU, supplemental restraint system (SRS) ECU, and electronic parking brake (EPB) ECU. ECUs in the PCN are connected via the PCB. The diagnostic controller area network (DCN) may include, but is not limited to, the telematics box (T-Box) ECU. The entertainment system controller area network may include but is not limited to: a video audio entertainment system (VAES) ECU and an instrument pack (IPK) ECU. The ECUs in the entertainment system controller area network are connected via a powertrain bus.

[0065] The gateway is the core control device in the vehicle, used to coordinate different CANs, as well as protocol conversion, data exchange, fault diagnosis, and other tasks between the CANs and the data networks (DN). The gateway can receive network signals at different transmission rates from each CAN. The gateway can process the network signals according to preset processing rules and then transmit them to the CAN via each CAN bus. If an ECU in the CAN subscribes to this network signal, the ECU can parse the network signal and perform corresponding processing. The ECU in the CAN can interact with the gateway through the corresponding CAN bus, thereby enabling the ECU in one CAN to interact with the ECU in another CAN through the gateway. ECUs in the same CAN can interact through the CAN bus in that CAN.

[0066] ECU can be called "driving computer" or "on-board computer". ECU can be connected to sensors in the vehicle, and ECU can control the vehicle based on data from the sensors. Sensors in the vehicle may include but are not limited to temperature sensors, speed sensors, and image sensors. Different ECUs can be connected to different sensors, and the functions of different ECUs can be different. Exemplarily, T-Box ECU can receive data from ECUs in other controller area networks through the diagnostic control bus, such as T-Box ECU can receive data from air-conditioning ECU and tire pressure monitoring system ECU, and then upload these data to the server. T-Box ECU can extend the remote control function to the terminal device based on the server, thereby enabling the terminal device to display and control vehicle data. Exemplarily, the air-conditioning ECU can control the temperature in the vehicle based on data from the temperature sensor. The engine control module ECU can control the engine's air intake, fuel injection, ignition timing, etc., thereby controlling the engine's operating efficiency, power, and torque. In the embodiments of the present application, Figure 1 The functions of the ECU shown in FIG will not be described in detail. It should be understood that in other embodiments of the present application, the vehicle may include Figure 1 More or fewer components, or combining or splitting some components, or arranging ECUs in different controller area networks, Figure 1 It does not constitute a restriction on the structure of the vehicle.

[0067] Figure 2 This is a structural diagram of ECU. Figure 2As shown, the ECU may include: an input circuit, an analog / digital converter (A / D converter), a microcomputer, an output circuit, and a power supply circuit. The input circuit can be connected to sensors in the vehicle (such as speed sensors or temperature sensors, etc.), the A / D converter is respectively connected to the input circuit and the microcomputer, and the microcomputer is connected to the output circuit. The power supply circuit is respectively connected to the vehicle's power supply module, input circuit, A / D converter, microcomputer, and output circuit. The output circuit can be connected to mechanical modules in the vehicle, such as engines, solenoid valves, air-conditioning systems, etc. The communication circuit can be connected to a microcomputer. The microcomputer may include a microcontroller unit (MCU), a memory, and an input / output interface. Among them, the MCU includes a plurality of pins, the pins are used to connect the ECU to the control circuit, and the control circuit is used to implement the processing functions of the ECU, such as wake-up functions, incoming call functions, etc. It should be understood that Figure 2 The specific structure of the microcomputer is not shown. Figure 2 The following description takes the engine control module ECU as an example.

[0068] The input circuit receives signals from the sensor and processes them, such as removing noise, before converting them into voltage signals for input to the microcomputer. It should be noted that the sensor signals can be analog signals. Although these signals are converted into voltage signals after being processed by the input circuit, they cannot be directly processed by the microcomputer. Instead, they must be converted into digital signals via an A / D converter before being input to the microcomputer. The microcomputer can perform operations on the digital signals from the A / D converter and send control instructions to the output circuit based on the results. The output circuit converts the control instructions from the microcomputer into control signals to control the operation of the various mechanical modules. The communication circuit connects the microcomputer to the data network.

[0069] The following describes the terms in the embodiments of the present application in conjunction with the structure of the ECU:

[0070] ECU hibernation: The microcontroller unit includes a wakeup pin that can be connected to a wakeup control circuit. This wakeup control circuit is used to wake the ECU. Specifically, the wakeup control circuit uses the wakeup pin to enable the ECU to transition from hibernation to active mode. When the ECU is hibernating, the wakeup pin and timer module within the ECU can be active, while other pins and components within the ECU can be in hibernation. The timer module is used for timing.

[0071] ECU shutdown: When the ECU is shut down, all components and pins in the ECU are in a dormant state.

[0072] ECU Services: Each ECU has different functions and can execute different services. For example, the air conditioning ECU can perform temperature adjustment, while the central control ECU can perform navigation and music playback. ECU service execution can be understood as the ECU launching its own business processes to execute the service.

[0073] Among them, the services in the ECU may include: services that rely on the CAN bus and services that do not rely on the CAN bus. Services that rely on the CAN bus refer to: the ECU sends and receives CAN messages through the CAN bus to obtain data from other ECUs, and then executes services based on the acquired data. For example, when the T-Box ECU executes remote control services, it needs to obtain data from ECUs in other controller area networks through the diagnostic control bus. Services that do not rely on the CAN bus refer to: the ECU executes services through the programs therein and does not need to send and receive CAN messages through the CAN bus. For example, the telephone service in the central control ECU is a service that does not rely on the CAN bus. The services in each ECU may include services that rely on the CAN bus and / or services that do not rely on the CAN bus. In the following embodiments, the services that do not rely on the CAN bus are described as the first services and the services that rely on the CAN bus are described as the second services.

[0074] ECU restart: The ECU executes the restart procedure to terminate the business process in the ECU. Terminating the business process can also be understood as shutting down the business process.

[0075] Figure 3 It is a flowchart of ECU sleep. It should be understood that in the following embodiments, the first ECU belongs to the first CAN, the bus in the first CAN is the first CAN bus, the first ECU is connected to the gateway via the first CAN bus, the second ECU belongs to the second CAN, the bus in the second CAN is the second CAN bus, the second ECU is connected to the gateway via the second CAN bus. Figure 3 As shown, the ECU sleep process may include:

[0076] S301: The second ECU receives a power-off signal from a gateway.

[0077] The first ECU detects that the vehicle's power is turned off, and the first ECU can send a power-off signal to the gateway via the first CAN bus. The vehicle's power off includes normal and abnormal shutdowns. A normal shutdown can be caused by the user triggering the "one-button start" button or the user operating the car key to turn off the vehicle's power. Abnormal shutdowns can be caused by engine failure, poor oil pump operation, intake pipe failure, etc. The first ECU is an ECU that can detect when the vehicle is turned off. The first ECU can be, but is not limited to, a body control ECU or an engine control module ECU.

[0078] Exemplarily, the body control ECU can detect whether the user clicks the "one-button start" button to determine that the vehicle's power is turned off. Alternatively, the body control ECU detects that the vehicle key position is switched from the on (ON) position to the off (OFF) position, and can determine that the vehicle's power is turned off. Exemplarily, the engine control module ECU can detect the operating status of the engine to determine whether the vehicle's power is turned off due to an engine failure. In an embodiment of the present application, the first ECU detects that the vehicle's power is turned off, and the first ECU can send a power-off signal to the gateway via the first CAN bus, and the gateway can notify other ECUs that the vehicle's power is turned off.

[0079] The gateway can send a power-off signal to a second ECU in the second CAN via the second CAN bus. In this embodiment, the second CAN can represent each CAN in the vehicle, and the second ECU can represent each ECU in the second CAN. The second CAN can be the first CAN, and the second ECU can be the first ECU.

[0080] After receiving the power-off signal, the gateway can send a power-off signal to the second ECU in the second controller area network through the second CAN bus to make the second ECU in the working state enter sleep mode, thereby reducing the vehicle's power consumption and saving the vehicle's battery power.

[0081] S302: The second ECU determines whether there is any business process, and if so, executes S303; if not, executes S304.

[0082] The process of the second ECU judging whether there is any business process can refer to the following Figure 4A-4B Related description in .

[0083] S303: The second ECU executes the service, and then executes S304 after the service execution is completed.

[0084] When the second ECU determines that there are still service processes, the second ECU continues to execute the service, for example, service process 1 and / or service process 2 may continue to execute the service until service process 1 and / or service process 2 completes the service.

[0085] S304 , the second ECU enters sleep mode.

[0086] In one possible implementation, if the business executed by the second ECU is the first business, the second ECU can execute hibernation as follows: the power management module receives the hibernation approval information of all business processes, and the power management module can send hibernation information to other modules (such as signal detection module, wireless communication module, process management module), so that each module in the second ECU is hibernated, that is, the second ECU executes hibernation.

[0087] In one possible implementation, if the business executed by the second ECU is the second business, the second ECU may execute hibernation as follows: the second ECU sends a hibernation request to the gateway through the second CAN bus to request hibernation, and when the second ECU receives a hibernation response from the gateway, the second ECU executes hibernation.

[0088] Figure 4A This is another structural diagram of ECU. Figure 4A As shown, the ECU may include an application layer, a service layer, an abstraction layer, and an interface layer. When the ECU executes a service, the application layer can initiate at least one service process, such as service process 1 or service process 2. Each service process can execute one or more services, or multiple service processes can jointly execute a service. The service layer is used to provide services to the ECU, such as signal detection services, network communication and management services, power management services, and process management services. For example, the service layer may include, but is not limited to, a signal detection module, a power management module, a wireless communication module, and a process management module. The signal detection module provides signal detection services for service processes, the power management module provides power management services for service processes, the wireless communication module provides network communication and management services for service processes, and the process management module provides process management services for service processes. The abstraction layer includes drivers for mechanical modules, such as motors and solenoid valves. The interface layer includes pre-configured application programming interfaces (APIs), which service processes in the application layer can call to execute services.

[0089] In the above Figure 4A Based on the following Figure 4B The interaction process of each module in the ECU is described. The interaction process of each module in the ECU may include:

[0090] The process management module starts the service process. When the second ECU executes the service, the process management module can start the service process to execute the service. For example, Figure 4AAs shown, the process management module starts business process 1 to execute business 1, and starts business process 2 to execute business 2. When the process management module starts business process 1 and business process 2, the process management module may mark the status of business process 1 and business process 2 as working status.

[0091] S401: The wireless communication module receives service data from a data network.

[0092] The wireless communication module is used to interact with the data network to obtain the business data required by the business process when executing the business, and send the business data to the business process, so that the business process executes the business based on the received business data.

[0093] S402: The wireless communication module sends service data to the service process.

[0094] The business process receives business data and can execute business based on the business data.

[0095] S403: The signal detection module receives a power-off signal from the gateway.

[0096] The signal detection module interacts with the gateway via the CAN bus. For example, the signal detection module can receive a power-off signal from the gateway.

[0097] S404: The signal detection module sends a power-off signal to the service process.

[0098] S405: The business process feeds back sleep voting information to the power management module.

[0099] After receiving the power-off signal, the business process can provide sleep voting information to the power management module. This sleep voting information can include both sleep-yes and sleep-no votes. For example, if the business process is still executing business, the business process can provide sleep-no votes to the power management module. When the business process completes its business and is released normally, the business process can provide sleep-yes votes to the power management module.

[0100] S406 , the power management module determines whether the ECU is in sleep mode based on the sleep voting information from the business process.

[0101] The power management module can determine whether the ECU can enter sleep mode based on sleep voting information from business processes. If the power management module receives sleep voting information from all business processes, the ECU can determine that no business processes are among them and enter sleep mode. If the power management module does not receive sleep voting information from all business processes, the ECU can determine that there are still business processes executing business tasks and the ECU will not enter sleep mode.

[0102] Exemplarily, when the signal detection module in the second ECU receives a power-off signal from the gateway, it can send a power-off signal to business process 1 and business process 2. Business process 1 and business process 2 can feedback sleep voting information to the power management module in the second ECU based on the business status therein. Among them, if business process 1 and business process 2 have both completed their business, they can both cast sleep approval votes to the second ECU. If the power management module in the second ECU receives sleep approval votes from all business processes, the second ECU determines that there are no business processes therein. If business process 1 and / or business process 2 have not completed their business, they can cast sleep disapproval votes to the second ECU. If the power management module in the second ECU does not receive sleep approval votes from all business processes, the second ECU determines that there are still business processes therein.

[0103] Figure 5 This is a schematic diagram of ECU state switching. Figure 5 As shown, the second ECU can determine whether the ECU enters the working state, the sleeping state or the shutdown state based on the vehicle's power status, the status of the second controller local area network, the business operation status in the second ECU, the sleep time and the vehicle power consumed by the second ECU. Figure 6 is the state transition diagram of ECU. Figure 6 As shown, when the second ECU is in the working state, if the second ECU determines that the power state of the vehicle is off (OFF), the second controller area network is dormant, and there is no business process in the second ECU, the second ECU switches from the working state to the dormant state. If the second ECU receives a power-off signal from the gateway, it can be determined that the power state of the vehicle is off; if the second ECU receives a power-on signal from the gateway, it can be determined that the power state of the vehicle is on (ON). The way in which the second ECU determines that the second controller area network is dormant can be: the second ECU detects whether the second CAN bus transmits a CAN message within a second preset time length. If the second ECU detects that the second CAN bus does not transmit a CAN message within the second preset time length, it determines that the second controller area network is dormant; if the second ECU detects that the second CAN bus transmits a CAN message within the second preset time length, it determines that the second controller area network is in an active state. The second preset time length can be 10s.

[0104] In this embodiment of the present application, if there are no service processes in the second ECU, the second ECU may not send or receive messages via the second CAN bus, and the second Controller Area Network may enter a dormant state. As described in S301-S304 above, if the second ECU receives a power-off signal from the gateway, the second Controller Area Network enters a dormant state, and there are no service processes in the second ECU, the second ECU switches from an active state to a dormant state.

[0105] like Figure 6 As shown, when the second ECU is in a dormant state, if the second ECU determines that the vehicle's power is on, the second Controller Area Network is active, and there is a service process in the second ECU, the second ECU switches from the dormant state to the active state. In one possible implementation, when the second ECU is in the dormant state, the timer module in the second ECU is not in a dormant state. The timer may start counting when the second ECU switches to the dormant state. If the timer determines that the second ECU's dormant time exceeds a preset dormant time, the second ECU switches from the dormant state to the off state. Correspondingly, when the second ECU is in a off state, if the second ECU determines that the vehicle's power is on, the second Controller Area Network is active, and there is a service process in the second ECU, the second ECU switches from the off state to the active state. In one possible implementation, when the second ECU is in an active state, if the second ECU determines that the vehicle's power is off, the second Controller Area Network is dormant, there are no service processes in the second ECU, and the vehicle power consumed by the second ECU exceeds a preset power, the second ECU switches from the active state to the off state. Among them, the power management module in the second ECU can detect the vehicle power consumed by the second ECU, and then determine whether the vehicle power consumed by the second ECU exceeds the preset power, so as to determine whether the ECU switches from the working state to the sleep state or the shutdown state.

[0106] The following combination Figures 7A-7D This section describes the process of the ECU going into sleep mode normally and the process of the ECU failing to go into sleep mode.

[0107] Figure 7A For Figure 3 A sleep timing diagram of the corresponding ECU. Figure 7A In the example, the business executed by the second ECU is referred to as the first business, and the second ECU includes ECU1 and ECU2. Figure 7A As shown, at time t1, the vehicle's power state switches from on to off. The second ECU includes a service process for the first service and is in an active state. Because the second ECU does not need to send or receive CAN messages via the second CAN bus when executing the first service, if the second CAN bus does not transmit CAN messages within a second preset time period, the second Controller Area Network can enter sleep mode at time t2. At time t3, the second ECU completes executing the first service and enters sleep mode. For example, ECU1 and ECU2 enter sleep mode at time t3.

[0108] Figure 7B For Figure 7A The corresponding timing diagram shows that the ECU cannot sleep when the business is abnormal. Figure 7BIn the example, the first business in ECU1 is abnormal and the first business in ECU2 is normal. If the data network is abnormal, the underlying module in ECU1 is abnormal, or the business process is abnormal, the first business in ECU1 will be abnormal. If the data network is abnormal, ECU1 generates a large amount of business data when executing the first business, but it cannot be transmitted to the server through the data network, causing the first business to be suspended. The business process of the first business keeps feeding back sleep objection information to the power management module in ECU1, thus causing ECU1 to be unable to sleep. Figure 7B As shown, because the first service does not rely on the second CAN bus to transmit CAN messages, the second CAN bus goes into hibernation at time t2, similar to 7A above. Because the first service in ECU2 is functioning normally, ECU2 can go into hibernation after completing the first service at time t3. ECU1 should have gone into hibernation at time t3, but the abnormality in the first service causes ECU1 to remain active at that time. This active ECU1 consumes vehicle power and wastes battery charge.

[0109] Figure 7C For Figure 3 Another sleep timing diagram of the corresponding ECU. Figure 7C The second ECU is used as an example to illustrate the second business. Figure 7C As shown, at time t1, the power state of the vehicle switches from on to off. If the second ECU includes a business process of the second business, the second ECU sends and receives CAN messages through the second CAN bus to execute the second business, and the second ECU and the second controller area network are both in working state. At time t2, the second ECU has completed executing the second business, and the second ECU does not send and receive CAN messages through the second CAN bus, then the second controller area network can be dormant. The second ECU determines that the power state of the vehicle is off, the second controller area network is dormant, and there is no business process in the second ECU, then the second ECU can be dormant at time t2. For example, ECU1 and ECU2 can be dormant at time t2. It should be understood that ECU1 and ECU2 can also be dormant at time t3, for the convenience of communication with Figure 7A To make a distinction and comparison, Figure 7C The second ECU is taken to sleep at time t2 as an example.

[0110] Figure 7D For Figure 7C The corresponding timing diagram shows that the ECU cannot sleep when the business is abnormal. Figure 7DThe following example is used to illustrate that the second business in ECU1 is abnormal and the second business in ECU2 is normal. The above description can be referred to at time t1. Because the business in ECU1 is the second business, the second business needs to send and receive messages through the second CAN bus. Therefore, when the second business in ECU1 is abnormal, ECU1 continuously sends and receives messages through the second CAN bus, and the second controller area network is always in an active state. ECU2 in the second controller area network should sleep at time t2, but because ECU2 detects that the second CAN bus has been sending and receiving CAN messages, ECU2 is also in a working state at time t2. Figure 7D At time t2, the second CAN is active, and ECU1 and ECU2 are both active and not in sleep mode. In this scenario, an abnormal second service in ECU1 prevents ECU1 from going into sleep mode, which in turn causes the second CAN and ECU2 to be unable to sleep, further consuming vehicle power.

[0111] In one possible implementation, the correspondence between the cause of ECU business abnormality and the processing method of ECU sleep can be pre-defined in the embodiment of the present application. When the business in the ECU is abnormal, the ECU detects the cause of the business abnormality, and then adopts the processing method of ECU sleep corresponding to the cause of the business abnormality to process it, so that the ECU is sleep-proof to reduce the power consumption of the vehicle. Exemplarily, when the T-Box ECU interacts with the server, it can receive a response code from the server, and the response code can represent the cause of the business abnormality. For example, response code 401 (unauthorized) indicates that the authentication failed, response code 410 (gone) indicates that the resource requested by the ECU has been deleted, and response code 400 (bad request) indicates that the request field is wrong. In the embodiment of the present application, the correspondence between the response code and the processing method of sleep can be pre-defined, as shown in Table 1 below:

[0112] Table 1

[0113] Response Code How to handle hibernation 401 Forced hibernation 410 Forced hibernation 400 Re-request, no more requests after 2 requests, forced sleep

[0114] It should be understood that Table 1 is an example of a format that represents the correspondence between the cause of ECU service abnormality and the processing method of ECU sleep. For example, when the T-Box ECU receives a response code 401 or 410 from the server, the ECU is forced to sleep. When the T-Box ECU receives a response code 400 from the server, the ECU can re-initiate a request to the server. After retrying 2 times, no more requests are made and the ECU is forced to sleep. ECU forced sleep refers to: Figure 4AThe power management module can send a sleep message to the signal detection module, the wireless communication module, and the process management module. Upon receiving the sleep message, the process management module can forcibly terminate the service process. A service process normally completes its service and releases the service process. However, in the implementation of this application, when a service exception occurs, the service process is forcibly terminated, thereby putting the ECU into sleep mode.

[0115] In this approach, the ECU can address the identified cause of the service anomaly and put it into sleep mode. However, due to the complexities of vehicle environments and network signals, the causes of ECU service anomalies vary. If the appropriate sleep mode for each ECU service anomaly is not predefined, or if the ECU cannot identify the cause of the anomaly, the ECU will not be able to sleep.

[0116] An embodiment of the present application provides an ECU sleep method. When the ECU cannot sleep, the ECU can be forced to sleep or sleep after restarting, thereby avoiding the problem of the ECU being unable to sleep, reducing the vehicle's power consumption, and saving the vehicle's battery power.

[0117] The following describes the ECU sleep method provided by the embodiment of the present application in conjunction with specific embodiments. The following embodiments can be combined with each other, and the same or similar concepts or processes will not be repeated. Figure 8A This is a flow chart of an embodiment of the ECU sleep method provided in the embodiment of the present application. Figure 8A As shown, the ECU sleep method provided in the embodiment of the present application may include:

[0118] S801a: The second ECU receives a power-off signal from the gateway.

[0119] The implementation of S801a can refer to the relevant description of S301 above. It should be understood that Figure 8A The first ECU and the gateway are not shown.

[0120] S802a: The second ECU determines whether a service process exists therein.

[0121] The second ECU may determine whether a service process exists by referring to the relevant descriptions in S302 and 4B above.

[0122] S803a: The second ECU identifies the type of service executed by the service process.

[0123] The second ECU can determine the type of service executed by the service process. If the service executed by the service process is not dependent on the CAN bus, the service is a first service. If the service executed by the service process is dependent on the CAN bus, the service is a second service. It should be understood that the first service can be at least one service, and the second service can be at least one service.

[0124] S804a: The second ECU determines whether the service is abnormal based on the service type. If not, the process proceeds to S805a. If so, the process proceeds to S806a.

[0125] It should be understood that the service can be the first service or the second service. If the second ECU fails to complete the service within the first preset time, the service is abnormal. If the second ECU completes the service within the first preset time, the service is normal. In one embodiment, the method for the second ECU to determine whether the service is abnormal can also refer to the following: Figure 8B and Figure 10 Description in .

[0126] S805a: The second ECU goes into hibernation.

[0127] S806a: The second ECU terminates the service process and enters sleep mode.

[0128] When the service is abnormal, the second ECU terminates the service process to perform hibernation. In one embodiment, the second ECU can also terminate the service process in the following manner: Figure 8B and Figure 10 Description in .

[0129] In an embodiment of the present application, when the second ECU receives a power-off signal from the gateway and detects a business abnormality in the second ECU, the second ECU can terminate the business process to execute hibernation, thereby reducing vehicle power consumption and saving vehicle battery power.

[0130] In one embodiment, Figure 8B A flowchart of another embodiment of the ECU sleep method provided in the embodiment of the present application. Figure 8B In this example, the service in the second ECU is the first service. Since the first service is not dependent on CAN, the service abnormality in ECU1 has no effect on ECU2. Figure 8B In the description, the second ECU is used to represent ECU1 and ECU2.

[0131] like Figure 8B As shown, in one possible implementation, the ECU sleep method may include:

[0132] S801: The second ECU receives a power-off signal from the gateway.

[0133] The implementation of S801 can refer to the relevant description of S301 above. It should be understood that Figure 8B The first ECU and the gateway are not shown.

[0134] S802: The second ECU determines whether there is any business process. If yes, and the business process is executing the first business, then S803 is executed; if no, then S804 is executed.

[0135] The second ECU can determine the type of business executed by the business process therein. If the business executed by the business process is a business that does not rely on the CAN bus, the business is the first business. If the business executed by the business process is a business that relies on the CAN bus, the business is the second business. In the embodiment of the present application, if there is a business process in the second ECU and the business executed by the business process is the first business, the second ECU executes S803. If there is no business process in the second ECU, the second ECU executes S804. It should be understood that the second ECU can refer to the relevant description in the above S302 to determine whether there are any business processes therein.

[0136] S803: When the second ECU detects that the second CAN is dormant, it starts a timer to detect whether the second ECU has completed the first service within a first preset time period. If yes, execute S804; if no, execute S805.

[0137] Because the first service is not dependent on the CAN bus, if the second CAN bus does not transmit a message within the second preset duration, the second Controller Area Network can be dormant. Therefore, in the embodiment of the present application, the second ECU can detect whether the second Controller Area Network bus transmits a CAN message within the second preset duration to determine whether the second Controller Area Network is dormant. If the second CAN bus does not transmit a CAN message within the second preset duration, the second ECU determines that the second Controller Area Network is dormant. If the second CAN bus transmits a CAN message within the second preset duration, the second ECU determines that the second Controller Area Network is not dormant.

[0138] To prevent the second ECU from being unable to sleep due to an abnormality in the first service, in an embodiment of the present application, upon detecting that the second Controller Area Network is in sleep mode, the second ECU may start a timer to detect whether the second ECU has completed the first service within a first preset duration. The second ECU may start a power management timer for timing. Optionally, the first preset duration may be greater than the second preset duration. For example, the first preset duration may be 2 hours.

[0139] The second ECU may detect whether the second ECU has completed the execution of the first business within the first preset time period by: determining whether the power management module in the second ECU has received sleep approval vote information fed back from all business processes within the first preset time period. If the power management module in the second ECU has received sleep approval vote information fed back from all business processes within the first preset time period, the second ECU determines that the second ECU has completed the execution of the first business within the first preset time period. If the power management module in the second ECU has not received sleep approval vote information fed back from all business processes within the first preset time period, the second ECU determines that the second ECU has not completed the execution of the first business within the first preset time period.

[0140] S804: The second ECU enters sleep mode.

[0141] If there is no service process in the second ECU, the second ECU enters sleep mode. Alternatively, if the second ECU completes the first service within a first preset time period, the second ECU determines that the first service is normal and enters sleep mode.

[0142] S805: The second ECU terminates the service process and goes into hibernation.

[0143] If the second ECU fails to complete the first service within a first preset time period, the second ECU determines that the first service is abnormal. To prevent the second ECU from being unable to sleep and wasting vehicle power, the second ECU can be forced into sleep mode. It should be understood that forcing the second ECU into sleep mode means that the second ECU terminates the service process and enters sleep mode.

[0144] Figure 9 For Figure 8B The corresponding ECU sleep timing diagram. Figure 7B For comparison, Figure 9 In the example, the second ECU includes ECU1 and ECU2, the timer started by ECU1 is ECU1T, and the timer started by ECU2 is ECU2T. Figure 9As shown, at time t1, the power state of the vehicle switches from on to off. Both ECU1 and ECU2 include the business process of the first business, and ECU1 and ECU2 are in working state. Because ECU1 and ECU2 do not need to send and receive CAN messages through the second CAN bus, if the second CAN bus does not transmit CAN messages within the second preset time period, the second controller area network can be dormant at time t2. When ECU1 and ECU2 detect that the second controller area network is dormant at time t2, the timer can be started at time t2. The first preset time period corresponding to the timer is from time t2 to time t4. At time t3, the timer has not expired, ECU2 has completed the execution of the first business, and ECU2 is dormant. At this time, the ECU2T timing is not completed and the timing can be stopped. At time t4, the timer expires, and ECU1 has not completed the execution of the first business. In the embodiment of the present application, ECU1 is forced to sleep at time t4 to reduce the consumption of vehicle power consumption when the abnormality of the first business causes ECU1 to be unable to sleep.

[0145] In an embodiment of the present application, the second ECU receives a power-off signal from the gateway, and the second ECU includes a business process of the first business, then the second ECU can start a timer when the second controller area network is in sleep mode. If the second ECU completes execution of the first business within the first preset time period, the second ECU goes into sleep mode normally. If the second ECU fails to complete execution of the first business within the first preset time period, the second ECU determines that the first business is abnormal and is forced to go into sleep mode to reduce vehicle power consumption and thereby save vehicle battery power.

[0146] In one embodiment, Figure 10 A flowchart of another embodiment of the ECU sleep method provided in an embodiment of the present application. Figure 10 The second ECU service is used as an example to illustrate the above. Figure 7D As shown, because the second service is a CAN-dependent service, an abnormality in the second service in ECU1 will cause the second controller area network and ECU2 to be unable to sleep. Figure 10 ECU1 and ECU2 are used as examples for explanation.

[0147] like Figure 10 As shown, in one possible implementation, the ECU sleep method may include:

[0148] S1001: The second ECU receives a power-off signal from a gateway.

[0149] The implementation of S1001 may refer to the relevant description of S301 above.

[0150] S1002: The second ECU determines whether there is any business process. If yes, and the business process is the second business, then S1003 is executed; if no, then S1004 is executed.

[0151] S1003: The second ECU starts a timer to detect whether the second CAN is dormant within a first preset time period. If so, execute S1004; if not, execute S1005.

[0152] The second business is a business that relies on the second CAN bus, so when the second ECU is executing the second business, the second ECU sends and receives CAN messages through the second CAN bus. The second CAN bus has been transmitting CAN messages, so the second controller area network is in an activated state. In order to avoid the second business abnormality causing the second ECU to be unable to sleep, in an embodiment of the present application, when the second ECU determines that the business process corresponding to the second business is included, it starts a timer to detect whether the second controller area network is dormant within a first preset time period. Optionally, the second ECU can start a network management (NM) timer for timing. The way the second ECU detects whether the second controller area network is dormant can refer to the above-mentioned relevant description. In one embodiment, the duration of the NM timer may be different from the duration of the power management timer.

[0153] If the second Controller Area Network is dormant, this indicates that the second CAN bus has not transmitted any CAN messages within the second preset duration, meaning that the second ECU has completed the second service within the first preset duration. Therefore, S1004 can be replaced by: the second ECU starts a timer to detect whether the second ECU has completed the second service within the first preset duration. If so, S1004 is executed; if not, S1005 is executed. The method for the second ECU to detect whether the second ECU has completed the second service within the first preset duration can be found in the description of the second ECU detecting whether the second ECU has completed the first service within the first preset duration.

[0154] Because the second service relies on the CAN bus, the second CAN bus is constantly transmitting CAN messages, and the second Controller Area Network is active. ECU 2 does not have a service process corresponding to the second service, or after ECU 2 completes the second service, the second CAN bus is continuously transmitting messages because the second Controller Area Network is active, preventing ECU 2 from going into sleep mode and thus remaining active.

[0155] S1004: The second ECU enters sleep mode.

[0156] If there is no service process in the second ECU, the second ECU goes into hibernation. Alternatively, if the second ECU detects that the second controller area network is in hibernation within a first preset time period and the second ECU determines that the second service is normal, the second ECU goes into hibernation.

[0157] S1005: The second ECU restarts.

[0158] If the second ECU detects that the second controller area network has not been in sleep mode within the first preset time period, it determines that the second business is abnormal. The second ECU has been sending and receiving CAN messages through the second CAN bus, and the second controller area network has been in an activated state. In this scenario, the second ECU can be put into sleep mode by restarting. Because the second ECU restarts, all business processes in the second ECU can be terminated. Therefore, when the second ECU restarts, there is no business process in the second ECU, and the second ECU can send a sleep request to the gateway to request sleep. Among them, after ECU1 restarts, it can send a sleep request to the gateway to request sleep. Correspondingly, no CAN message is transmitted on the second CAN bus within the second preset time period, the second controller area network is in sleep mode, and then ECU2 detects that the second controller area network is in sleep mode, and ECU2 also goes into sleep mode.

[0159] In this embodiment of the present application, the second ECU is not forced into sleep mode, but rather is put into sleep mode by restarting. This is to prevent the gateway from mistakenly determining that the second ECU is a faulty ECU. Because the second service relies on the CAN bus, the normal sleep process for the second ECU is to send a sleep request to the gateway. However, if the second ECU is forced into sleep mode without requesting sleep from the gateway, the gateway will determine that the second ECU has not executed the normal sleep process and, therefore, that the ECU is a faulty ECU, resulting in an incorrect judgment. Therefore, when the second service relies on the CAN bus, the second ECU is put into sleep mode by restarting.

[0160] Figure 11 For Figure 10 A sleep timing diagram of the corresponding ECU. Figure 7D For comparison, Figure 11 In the example, the second ECU includes ECU1 and ECU2. The timer started by ECU1 is ECU1T, and the timer started by ECU2 is ECU2T. Figure 11As shown, at time t1, the vehicle's power state switches from on to off. ECU1 and ECU2 both include a service process for the second service. Therefore, both ECU1 and ECU2 transmit and receive CAN messages via the second CAN bus to execute the second service, placing ECU1 and ECU2 in an active state. Furthermore, because the second CAN bus continues to transmit CAN messages, the second Controller Area Network (CAN) is in an active state. If ECU1 and ECU2 receive a power-off signal at time t1, they can start a timer at time t1, with the timer corresponding to a first preset duration from time t1 to time t4. At time t2, the timer has not expired. If ECU2 had completed the second service, it would have gone into hibernation. However, because ECU1 has not yet completed the second service, messages continue to be transmitted on the second CAN bus, indicating that ECU2 is not in hibernation and is in an active state. Accordingly, ECU2T and ECU1T continue timing. At time t4, the timer expires, but the second CAN network is not in hibernation and is still in an active state, indicating that ECU1 has not yet completed the second service. In this embodiment of the present application, ECU1 restarts at time t4. At time t4, because the timer expires but ECU2 is still in operation, the timer ECU2T in ECU2 can be restarted. Because ECU1 has restarted, the timer ECU1T in ECU1 can be stopped. When ECU1 restarts and enters operation, the timer ECU1T in ECU can be restarted. At time t5 after ECU1 restarts, if there are no business processes in ECU1, ECU1 can send a sleep request to the gateway to request sleep. Accordingly, if the second CAN bus does not transmit a CAN message within the second preset time period, the second controller area network, and ECU1 and ECU2 also go into sleep mode. Correspondingly, at time t5, because ECU1 and ECU2 are in sleep mode, ECU1T and ECU2T have not yet completed their time and can be stopped.

[0161] In the embodiment of the present application, in order to illustrate the sleep timing diagram of the ECU in the normal sleep controller local area network and the abnormal sleep controller local area network, the following is combined with Figure 12 For example, ECU1 and ECU2 belong to two different CANs. For example, ECU1 belongs to the second CAN, ECU2 belongs to the third CAN, and the bus in the third CAN is the third CAN bus.

[0162] Figure 12 For Figure 10 Another sleep timing diagram of the corresponding ECU. Figure 12As shown, at time t1, the vehicle's power state switches from on to off. ECU1 and ECU2 both include a service process for the second service. ECU1 then sends and receives CAN messages via the second CAN bus to execute the second service, while ECU2 sends and receives CAN messages via the third CAN bus to execute the second service. ECU1 and ECU2 are in an active state. Because the second and third CAN buses are continuously transmitting CAN messages, the second and third CAN buses are in an active state. If ECU1 and ECU2 receive a power-off signal at time t1, they can start a timer at time t1, with the timer corresponding to a first preset duration from time t1 to time t4. At time t2, the timer has not expired. If ECU2 detects that the third CAN bus is in sleep mode, ECU2 completes the second service, and ECU2 and the third CAN bus go into sleep mode. Accordingly, ECU2T can stop timing if it has not completed. At time t4, the timer expires, but the second CAN bus is not in sleep mode and is still active, meaning that ECU1 has not yet completed the second service. ECU1 then restarts at time t4. At time t5 after ECU1 is restarted, if there is no business process in ECU1, ECU1 can send a sleep request to the gateway to request sleep. Correspondingly, if the second CAN bus does not transmit CAN messages within the second preset time, the second controller area network and ECU1 also sleep. The timing method of ECU1T can refer to Figure 11 Description in .

[0163] In an embodiment of the present application, if a second ECU receives a power-off signal from a gateway and the second ECU includes a second service, the second ECU may start a timer upon receiving the power-off signal. If the second Controller Area Network (CAN) does not enter sleep mode within a first predetermined time period, the second ECU determines that the second service is abnormal and may restart to terminate the service process. After the second ECU restarts, since it no longer has any service processes, it may send a sleep request to the gateway to request sleep. This allows both the ECU and the second Controller Area Network to enter sleep mode, reducing vehicle power consumption and thereby conserving battery power.

[0164] In a possible implementation, after the ECU receives the power-off signal from the gateway, the ECU may include the first service and the second service, and the ECU may execute the above-mentioned Figure 8B and Figure 10 The steps in the embodiment shown in FIG. 1 are performed to put the ECU into sleep mode. Figure 13 As shown, the ECU sleep method may include:

[0165] S1301: Second, receive a power-off signal from a gateway.

[0166] S1302: The second ECU determines whether there is any business process. If yes, and the business process includes the second business, then S1303 is executed; if no, then S804 is executed.

[0167] S1303: The second ECU starts a timer to detect whether the second CAN is dormant within a first preset time period. If so, the process returns to step 1302. If the service being executed by the service process is the first service, steps S803-S805 are executed. If not, step S1304 is executed.

[0168] S1304: The second ECU restarts.

[0169] S1301-S1304, S803-S805 can refer to the relevant description in the above embodiment. Figure 10 The difference between the corresponding embodiments is that, because the second ECU can include the first service and the second service, when the second service in the second ECU is normal, the second controller area network can sleep within the first preset time length. After the second controller area network is dormant, the second ECU still includes the first service. Therefore, the above embodiment of the present application can be executed. Figure 8B S803-S805 in the second ECU are used to ensure that the second ECU can successfully go into sleep mode when it contains the first service and the second service.

[0170] The technical effects in the embodiments of this application can be referred to above Figure 8B and Figure 10 Related description in .

[0171] In one embodiment, the ECU provided in the embodiment of the present application may include: a processor (such as a CPU) and a memory. The memory may include a high-speed random-access memory (RAM) and may also include a non-volatile memory (NVM), such as at least one disk memory. Various instructions may be stored in the memory to complete various processing functions and implement the method steps of the present application. Optionally, the ECU involved in the present application may also include: a power supply, a communication bus and a communication port. The above-mentioned communication port is used to realize connection and communication between the ECU and other peripherals. In the embodiment of the present application, the memory is used to store computer executable program code, and the program code includes instructions; when the processor executes the instructions, the instructions cause the processor of the ECU to perform the actions in the above-mentioned method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0172] It should be noted that the components in the above ECU can be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASICs), one or more microprocessors (digital signal processors, DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented by scheduling program code through a processing element, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0173] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0174] The term "plurality" in this document refers to two or more. The term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the related objects; in a formula, the character " / " indicates a "division" relationship between the related objects.

[0175] It is understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not intended to limit the scope of the embodiments of the present application. In the embodiments of the present application, the order of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Claims

1. A dormancy method for an electronic control unit ECU, characterized in that: The method is applied to a vehicle, the vehicle including a controller area network (CAN) and a gateway, the CAN including a CAN bus and the ECU, the ECU being connected to the gateway via the CAN bus, the method comprising: The ECU receives a power-off signal from the gateway; The ECU determines that a business process exists in the ECU; The ECU identifies the type of business executed by the business process; When the service includes a service that relies on the CAN bus to transmit messages, the ECU starts a timer, and the duration of the timer is a first preset duration; When the ECU detects that the CAN is not in sleep mode within a first preset time period, determining that the service is abnormal; The ECU restarts; When the service is not dependent on the CAN bus to transmit messages, the ECU starts a timer when detecting that the CAN bus is dormant, and the duration of the timer is the first preset duration; When the ECU detects that the ECU has not completed the execution of the service within a first preset time period, determining that the service is abnormal; The ECU terminates the service process and goes into hibernation.

2. The method according to claim 1, characterized in that The method further comprises: The ECU detects that the CAN bus has not transmitted any message within a second preset time period, and determines that the CAN bus is in sleep mode, wherein the second preset time period is less than the first preset time period.

3. A dormancy method for an electronic control unit ECU, characterized in that: The method is applied to a vehicle, the vehicle including a controller area network (CAN) and a gateway, the CAN including a CAN bus and the ECU, the ECU being connected to the gateway via the CAN bus, the method comprising: The ECU receives a power-off signal from the gateway; The ECU determines that a business process exists in the ECU; The ECU identifies the type of business executed by the business process; When the service includes a service that relies on the CAN bus to transmit messages, the ECU starts a timer, and the duration of the timer is a first preset duration; The ECU detects whether the CAN is dormant within a first preset time period; If the CAN is dormant within the first preset time period, it is determined that the service is normal; if the CAN is not dormant within the first preset time period, it is determined that the service is abnormal; If the service is normal, the ECU goes into hibernation; if the service is abnormal, the ECU restarts; When the service is not dependent on the CAN bus to transmit messages, the ECU starts a timer when detecting that the CAN bus is dormant, and the duration of the timer is the first preset duration; The ECU detects whether the ECU has completed the service within a first preset time period; If the ECU completes executing the service within the first preset time period, the service is determined to be normal; if the ECU fails to complete executing the service within the first preset time period, the service is determined to be abnormal; When the ECU detects that the ECU has not completed the execution of the service within a first preset time period, determining that the service is abnormal; If the service is normal, the ECU goes into sleep mode; If the service is abnormal, the ECU terminates the service process and enters sleep mode.

4. The method according to claim 3, characterized in that The method further comprises: The ECU detects that the CAN bus has not transmitted any message within a second preset time period, and determines that the CAN bus is in sleep mode, wherein the second preset time period is less than the first preset time period.

5. An electronic control unit ECU, characterized in that: The ECU is provided in a vehicle, the vehicle including a controller area network (CAN) and a gateway, the CAN including a CAN bus and the ECU, the ECU being connected to the gateway via the CAN bus, and the ECU including a signal detection module, a power management module, and a process management module: The signal detection module is used to receive a power-off signal from the gateway; The power management module is configured to determine whether a service process exists in the ECU and to identify the type of service executed by the service process; When the service includes a service that relies on the CAN bus to transmit messages, the power management module is configured to start a timer, the timer duration of which is a first preset duration; and determine that the service is abnormal when it is detected that the CAN bus does not sleep within the first preset duration; The process management module is used for restarting; When the service is not dependent on the CAN bus to transmit messages, the power management module is configured to detect that the CAN bus is in sleep mode, start a timer, and have a duration of the timer equal to the first preset duration; and determine that the service is abnormal when detecting that the ECU has not completed executing the service within the first preset duration; The process management module is used to terminate the service process and perform hibernation.

6. The ECU according to claim 5, characterized in that The power management module is further configured to detect that the CAN bus has not transmitted any message within a second preset time period, and determine that the CAN is in sleep mode, wherein the second preset time period is less than the first preset time period.

7. An electronic control unit ECU, characterized in that: The ECU is provided in a vehicle, the vehicle including a controller area network (CAN) and a gateway, the CAN including a CAN bus and the ECU, the ECU being connected to the gateway via the CAN bus, and the ECU including a signal detection module, a power management module, and a process management module: The signal detection module is used to receive a power-off signal from the gateway; The power management module is used to determine whether a business process exists in the ECU; When the service includes a service that relies on the CAN bus to transmit messages, the power management module is configured to start a timer, where the duration of the timer is a first preset duration; Detecting whether the CAN is dormant within a first preset time period; If the CAN is dormant within the first preset time period, it is determined that the service is normal; If the CAN does not sleep within the first preset time period, determining that the service is abnormal; A process management module, configured to put the ECU into hibernation if the service is normal; If the service is abnormal, the ECU is restarted; When the service is not dependent on the CAN bus to transmit messages, the power management module is configured to start a timer when detecting that the CAN bus is in sleep mode, and the duration of the timer is the first preset duration; detecting whether the ECU has completed executing the service within a first preset time period; and determining that the service is normal if the ECU has completed executing the service within the first preset time period; If the service is not completed within the first preset time period, determining that the service is abnormal; If it is detected that the ECU has not completed the execution of the service within the first preset time period, determining that the service is abnormal; A process management module, configured to control the ECU to sleep if the service is normal; If the service is abnormal, the service process is terminated and the ECU is controlled to perform a sleep operation.

8. The ECU according to claim 7, wherein: The power management module is further configured to detect that the CAN bus has not transmitted any message within a first preset time period, and determine that the CAN is in sleep mode, wherein the first preset time period is less than the first preset time period.

9. A dormant system, characterized in that: The dormant system includes a gateway and a controller area network (CAN), the CAN includes a CAN bus and the ECU according to any one of claims 5 to 8, and the ECU is connected to the gateway via the CAN bus.

10. A vehicle, characterized in that: The vehicle includes the hibernation system of claim 9.

Images