Patent Publication Number: US-11639142-B2

Title: Electronic control module wake monitor

Description:
TECHNICAL FIELD 
     The present disclosure is generally related to an in-vehicle network monitoring system. More specifically, the present disclosure is related to a vehicle system for monitoring an in-vehicle network for controller activities. 
     BACKGROUND 
     Modern vehicles are provided with various electronic control units (ECUs) to monitor and perform various vehicle features including telecommunication, powertrain controls, vehicle body function for instance. Due to the complexity of the vehicle features, some ECUs are configured to wake up to perform features when the vehicle is turned off. Sometimes, an ECU can wake up the entire in-vehicle network when the vehicle is in an OFF state which may consume a lot of battery power. The ECU wakeup may be normal by design. However, sometimes it may also be a caused by a hardware failure (e.g. short circuit), or a software glitch. 
     SUMMARY 
     In one or more illustrative embodiment of the present disclosure, a vehicle includes a controller powered by a controller power source independent from a vehicle power supply, programmed to responsive to detecting an in-vehicle network wakeup initiated by an electronic controller unit (ECU) requesting to communicate during a vehicle OFF state, record an ECU communication via the in-vehicle network; and responsive to detecting a vehicle ON state, send the recorded ECU communication to a server. 
     In one or more illustrative embodiment of the present disclosure, a vehicle system includes one or more controllers, programmed to responsive to detecting the vehicle enters an OFF state, activate a wake monitor connected to an in-vehicle network to monitor for activities; responsive to detecting the in-vehicle network switches from a sleep mode into a wakeup mode initiated from an electronic controller unit (ECU) requesting to communicate, record an ECU communication via the in-vehicle network and store the ECU communication in a storage of the wake monitor; and responsive to detecting vehicle enters one of an ON state or an accessory (ACC) state, load the ECU communication from the storage and send the ECU communication to a server. 
     In one or more illustrative embodiment of the present disclosure, a method for a vehicle includes responsive to detecting the vehicle enters an OFF state, activating a wake monitor connected to an in-vehicle network to monitor for activities; responsive to detecting the in-vehicle network switches from a sleep mode into a wakeup mode initiated from an electronic controller unit (ECU), recording an ECU communication via the in-vehicle network into a storage of the wake monitor; and responsive to detecting vehicle enters one of an ON state or an accessory (ACC) state, sending the ECU communication to a server. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       For a better understanding of the invention and to show how it may be performed, embodiments thereof will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: 
         FIG.  1    illustrates an example block topology of a vehicle system of one embodiment of the present disclosure; 
         FIG.  2    illustrates an example flow diagram for a process of one embodiment of the present disclosure; and 
         FIG.  3    illustrates an example data flow diagram for a process of one embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention. 
     The present disclosure generally provides for a plurality of circuits or other electrical devices. All references to the circuits and other electrical devices, and the functionality provided by each, are not intended to be limited to encompassing only what is illustrated and described herein. While particular labels may be assigned to the various circuits or other electrical devices, such circuits and other electrical devices may be combined with each other and/or separated in any manner based on the particular type of electrical implementation that is desired. It is recognized that any circuit or other electrical device disclosed herein may include any number of microprocessors, integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof) and software which co-act with one another to perform operation(s) disclosed herein. In addition, any one or more of the electric devices may be configured to execute a computer-program that is embodied in a non-transitory computer readable medium that is programmed to perform any number of the functions as disclosed. 
     The present disclosure, among other things, proposes an in-vehicle network monitoring system. More specifically, the present disclosure proposes a vehicle system for monitoring an in-vehicle network (e.g. a controller area network (CAN)) for controller activities when the vehicle is in an OFF state. 
     Referring to  FIG.  1   , an example block topology of a vehicle system  100  of one embodiment of the present disclosure is illustrated. A vehicle  102  may include various types of automobile, crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane, or other mobile machine for transporting people or goods. In many cases, the vehicle  102  may be powered by an internal combustion engine. As another possibility, the vehicle  102  may be battery electric vehicle (BEV), a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or move electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel/series hybrid vehicle (PSHEV), a boat, a plane or other mobile machine for transporting people or goods. As an example, the system  100  may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Mich. It should be noted that the illustrated system  100  is merely an example, and more, fewer, and/or differently located elements may be used. 
     As illustrated in  FIG.  1   , a computing platform  104  may include one or more processors  112  configured to perform instructions, commands, and other routines in support of the processes described herein. For instance, the computing platform  104  may be configured to execute instructions of vehicle applications  108  to provide features such as navigation, telecommunications or the like. Such instructions and other data may be maintained in a non-volatile manner using a variety of types of computer-readable storage medium  106 . The computer-readable medium  106  (also referred to as a processor-readable medium or storage) includes any non-transitory medium (e.g., tangible medium) that participates in providing instructions or other data that may be read by the processor  112  of the computing platform  104 . Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C #, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL. 
     The computing platform  104  may be provided with various features allowing the vehicle occupants/users to interface with the computing platform  104 . For example, the computing platform  104  may receive input from human-machine interface (HMI) controls  118  configured to provide for occupant interaction with the vehicle  102 . As an example, the computing platform  104  may interface with one or more buttons (not shown) or other HMI controls configured to invoke functions on the computing platform  104  (e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls, etc.). 
     The computing platform  104  may also drive or otherwise communicate with one or more displays  116  configured to provide visual output to vehicle occupants by way of a video controller  114 . In some cases, the display  116  may be a touch screen further configured to receive user touch input via the video controller  114 , while in other cases the display  116  may be a display only, without touch input capabilities. The computing platform  104  may also drive or otherwise communicate with one or more speakers  122  configured to provide audio output to vehicle occupants by way of an audio controller  120 . 
     The computing platform  104  may also be provided with navigation and route planning features through a navigation controller  126  configured to calculate navigation routes responsive to user input via e.g., the HMI controls  118 , and output planned routes and instructions via the speaker  122  and the display  116 . Location data that is needed for navigation may be collected from a global navigation satellite system (GNSS) controller  124  configured to communicate with multiple satellites and calculate the location of the vehicle  102 . The GNSS controller may be configured to support various current and/or future global or regional location systems such as global positioning system (GPS), Galileo, Beidou, Global Navigation Satellite System (GLONASS) and the like. Map data used for route planning may be stored in the storage  106  as a part of the vehicle data  110 . Navigation software may be stored in the storage  116  e.g. as one of the vehicle applications  108 . 
     The computing platform  104  may be configured to wirelessly communicate with a mobile device  140  of the vehicle users/occupants via a wireless connection  184  through a wireless transceiver  136 . The mobile device  140  may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other device capable of communication with the computing platform  104 . The wireless transceiver  136  may be in communication with a Wi-Fi controller  128 , a Bluetooth controller  130 , a radio-frequency identification (RFID) controller  132 , a near-field communication (NFC) controller  134 , and other controllers such as a Zigbee transceiver, an IrDA transceiver (not shown), and configured to communicate with a compatible wireless transceiver (not shown) of the mobile device  140 . 
     The computing platform  104  may be further configured to communicate various electronic control units (ECUs)  152  via one or more in-vehicle network  150 . The in-vehicle network  150  may include, but is not limited to, one or more of a CAN, an Ethernet network, and a media-oriented system transport (MOST), as some examples. 
     The ECUs  152  may include a telematics control unit (TCU)  154  configured to control telecommunication between vehicle  102  and a cloud  190  through a wireless connection  180  using a modem (not shown). Additionally or alternatively, the computing platform  104  may be configured to communicate with the cloud  190  via the mobile device  140  through a wireless connection  186 . The computing platform  104  may be further configured to directly communicate with the cloud  190  via the wireless transceiver  136  using compatible protocols through a wireless connection  182 . The cloud  190  may include one or more servers, or computers connected via various types of wired or wireless networks. It is noted that the term cloud is used as a general term throughout the present disclosure and may refer to any cloud-based services involving multiple servers, computers, devices and the like. 
     As a few non-limiting examples, the ECUs  152  may further include a powertrain control module (PCM)  156  configured to monitor and control the powertrain operation of the vehicle  102 . For instance, the PCM  156  may include a vehicle immobilizer (not shown) configured to control the operating state of the vehicle  102 . The PCM  156  may be configured to switch the vehicle  102  between an ON state and an OFF state. In the ON state, the vehicle  102  may have both the vehicle engine (or an electric motor) and the transmission active and the vehicle  102  ready to drive. The ECUs  152  and the in-vehicle network  150  may be in a wakeup mode to fully perform vehicle functions. In the OFF state, ECUs  152  and the in-vehicle network  150  may be put into a sleep mode to save power, while some ECUs  152  are allowed to perform limited operations according the vehicle features. For instance, a body control module (BCM)  158  (to be discussed below) may be configured to stay partially active to receive remote input (e.g. door lock/unlock) when the vehicle  102  is in the OFF state. The PCM  156  may be further configured to provide an accessory (ACC) state in which the vehicle engine is not running but some ECUs  152  and the in-vehicle network  150  are waken up to provide limited vehicle features (e.g. radio, telecommunication or the like). 
     The ECUs  152  may further include the BCM  156  configured to monitor and control body operations of the vehicle  102 . For instance, the BCM  156  may be configured to control and monitor body functions such as door lock/unlock, remote controls, lighting or the like. The ECUs  152  may further include a heating, ventilation, and air conditioning (HVAC) controllers  160  configured to monitor and control the heating, air conditioning and/or climate operations of vehicle  102 . The ECUs  152  may further include an autonomous driving controller (ADC)  164  configured to monitor and control the autonomous driving features of the vehicle  102 . Some autonomous driving feature may include lane keep assist, safe distance from other vehicles, cruise control, autobraking, brake mitigation or the like. It is noted that the ECUs  152  illustrated with reference to  FIG.  1    are merely examples and the vehicle  102  may including more ECUs  152  connected to the in-vehicle network  150  or other vehicle network configurations to perform various features described or not described herein. 
     The ECUs  152  may further include a wake monitor  164  configured to monitor the in-vehicle network  150  for ECU activities when the vehicle  102  is in the OFF state. The wake monitor  164  may be provided with processing power by a processor  166  configured to perform instructions, commands, and other routines in support of the processes described herein using software  168  stored locally in a storage. The wake monitor  164  may be powered by a power source  170  independent from the power supply for the vehicle  102 . For instance, the power source may be rechargeable lithium-ion battery or an electric capacitor located inside or attached to the wake monitor  164  to supply power to the wake monitor when the vehicle  102  is in the OFF state. When the vehicle  102  is switched to the ON state or ACC state and power is supplied to ECUs  152  including the wake monitor  164 , the wake monitor  164  may be configured to charge the power supply  170  using the power received from the battery or power supply of the vehicle  102 . The wake monitor  164  may be configured to enter an active mode responsive to detecting the vehicle  102  is in the OFF state to monitor the in-vehicle network  150  for activities to find out which ECUs  152 , if any, are waking up the in-vehicle network  150  from the sleep mode. The wake monitor  164  may record the activities occurred on the in-vehicle network  150  for future analysis to find the cause. Responsive to detecting the vehicle  102  switching out of the OFF state and entering the ON or ACC state, the wake monitor  164  may be configured to enter an inactive mode to stop monitoring the in-vehicle network  150 . 
     Referring to  FIG.  2   , an example flow diagram for a process  200  of one embodiment of the present disclosure is illustrated. With continuing reference to  FIG.  1   , at operation  202 , the wake monitor  164  detects the vehicle  102  enters the OFF state e.g. using signals received from the in-vehicle network  150  or by detecting the power supply from the vehicle  102  is cut off. The in-vehicle network  150  may be configured to enter the sleep mode responsive to the vehicle  102  entering the off mode. Responsive to detecting the vehicle  102  has entered the off mode, the wake monitor activates the wake monitor feature and detect signals transmitted via the in-vehicle network  150 . Since the vehicle  102  is in the OFF state and the in-vehicle network  150  is in the sleep mode, there should be no communication between ECUs  152  via the in-vehicle network  150  most of the time. As the wake monitor  164  continues to monitor for any activity on the in-vehicle network  150  at operation  206 , if an in-vehicle network wakeup is detected at operation  208 , the process proceeds to operation  210  and the wake monitor  164  records the wakeup activity detected as a wakeup record in the storage for future analysis. For instance, the wakeup record may include information about the time and the trigger of the wakeup detection. The wake monitor  164  may detect which ECU  152  is waking up the in-vehicle network  150  and what cause the ECU  152  to wake up the in-vehicle network  150  by recording the data on the in-vehicle network  150 . 
     At operation  212 , the wake monitor  164  detects if the vehicle  102  enters the ON state such as when a user starts to use the vehicle  102 . If the answer is a no, the process returns to operation  206  and the wake monitor continues to monitor the in-vehicle network  150 . Otherwise, if the wake monitor  164  detects the vehicle  102  has entered the ON state, the process proceeds to operation  214  and the wake monitor  164  deactivates the monitor feature and sends the recorded wakeup record to computing platform  104  and/or the TCU  154  to send out to the cloud for analysis. As an example, the computing platform  104  may serve an enhanced central gateway to coordinate the telecommunication and data report. At operation  216 , the wake monitor  164  charges the power supply  170  using the power received from the vehicle  102 . 
     The operations of the process  200  may be applied to various situations. For instance, referring to  FIG.  3   , an example data flow diagram  300  of one embodiment of the present disclosure is illustrated. At operation  302 , the vehicle  102  turns off and enters the OFF state. In responsive, the in-vehicle network  150  enters a sleep mode to save power. Responsive to detecting the in-vehicle network  150  enters the sleep mode, the wake monitor  164  activates the monitor feature and starts to monitor the in-vehicle network  150  for activities at operation  304 . Depending on the configurations of the ECUs  152 , some ECUs may perform internal operations when the vehicle is in the OFF state. For instance, the BCM  158  may perform some internal operations  306  without communicating with other components of the vehicle  102  via the in-vehicle network  150  at operation  306 . Similarly, the computing platform  104  may also perform internal operation  306 . Such internal operations may not be detectable by the wake monitor because the in-vehicle network  150  is still asleep. 
     At operation  308 , the BCM sends a signal to the in-vehicle network  150  to communicate with other ECUs/components of the vehicle  102  at operation  312 . Responsive to receiving the signal from the BCM  158 , at operation  310 , the in-vehicle network  150  wakes up from the sleep mode to perform/facilitate the signal communication between the BCM  158 , the PCM  156  and the computing platform  104 . At operation  314 , responsive to detecting the in-vehicle network  150  wakes up, the wake monitor  164  records activities on the in-vehicle network  150 . For instance, the wake monitor  164  may record the time of each signal communication  308  and  312 . Additionally, the wake monitor  164  may record the identity of the ECUs  152  involved in the transaction, especially the identity of the source ECU initiating the signal communication, which in the present example, is the BCM  158 . Although the in-vehicle network  150  is in the wakeup mode, the vehicle  102  is still in the OFF state. The wake monitor  164  may detect the vehicle  102  the vehicle  102  is still in the OFF state through various means such as the power supply or the like. The wake monitor  164  may be configured to save the activity record and not send the record out until later when the vehicle  102  enters the ON or ACC state, to save power and avoid contaminating the signals on the in-vehicle network  150  during the vehicle OFF state. 
     At operation  316 , the vehicle  102  is turned on and enters the ON (or ACC) state. In response, the wake monitor  164  sends the activity record to the TCU  154  (or the computing platform  104 ) via the in-vehicle network  150  at operations  318  and  322 . The wake monitor  164  deactivates the monitor feature at operation  320 . Since the vehicle  102  is turned on and other ECUs  152  are activated, there will be many signals on the in-vehicle network  150  and keep monitoring will not be very useful. 
     At operation  324 , responsive to receiving the activity record form the wake monitor  164 , the TCU  154  sends the activity record to the cloud  190  for analysis to identify patterns of unnecessary or abnormal ECU activities. Alternatively, the activity record may be sent to the cloud  190  via the mobile device  140  or the wireless transceiver  136  wirelessly connected to the cloud. The analysis operation  326  in the cloud may be automatically performed by a server using a pre-defined algorithm. Additionally or alternatively, the analysis  326  may be performed manually by engineers and technician associated with the cloud  190 . At operation  328 , responsive to determining any unnecessary or abnormal ECU activities, the cloud  190  sends a software update and/or an instruction to the TCU  154  to address the issue. For instance, cloud may detect the abnormal ECU activities to be caused by a software glitch and can be fixed by a software update. Alternatively, responsive to determining the abnormal activities may be caused by a hardware failure (e.g. a short circuit) or the issue needs to be further examined, the cloud may send an instruction to the vehicle  102  to advise the vehicle user to take the vehicle  102  to a dealer for further examination. 
     While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.