Claims:1. A system (200) for managing at least one Electronic Control Unit (201) from a plurality of slave ECUs in an electric vehicle, the system (200) comprising:
a master ECU (102) connected to the at least one ECU (201), wherein the at least one ECU (201) comprises:
a CAN transceiver (206) connected to an oscillator (212); and
a microcontroller (209) coupled to the CAN transceiver (206), wherein the microcontroller (209) is configured to:
determine if the master ECU (102) is present;
determine if a High Voltage (HV) input is available for operating the at least one ECU (201)if the master ECU (102) is absent, when a failure occurs in one or more of the plurality of slave ECUs, wherein the at least one ECU (201) runs independent of the master ECU (102), on determining that the HV input is available; and
reset the microcontroller (209) based on a feedback mechanism.
2. The system (200) as claimed in claim 1, wherein the at least one ECU (201) runs normally based on instructions provided by the master ECU (102), on the microcontroller determining that the HV input is absent.
3. The system (200) as claimed in claim 1, wherein the microcontroller (209) comprises one or more timers to count one or more faults of the at least one ECU (201).
4. The system (200) as claimed in claim 1, wherein the at least one ECU (201) is a power converter.
5. The system (200) as claimed in claim 1, wherein the microcontroller (209) is configured to reset, on performing pre-sleep operation and initialization.
6. The system (200) as claimed in claim 5, wherein the microcontroller (209) is configured to:
perform the pre-sleep operation by enter into a pre-sleep state, when the CAN transceiver (206) receives a sleep command from the master ECU (102); and
send sleep commands to the CAN transceiver (206), on completing pre-state sleep operations.
7. The system as claimed in claim 1, wherein the CAN transceiver (206) is configured to power the microcontroller (209), on the CAN transceiver (206) receiving at least one of a wake-up command from one of a master ECU (102) and a hardware wake up command from an output of the oscillator (212).
8. The system as claimed in claim 5, wherein the microcontroller (209) is configured to perform the initialization by checking if a master ECU (102) is present, on the CAN transceiver (206) receiving the wake-up command.
9. The system as claimed in claim 5, wherein the microcontroller (209) is configured to perform the initialization by:
controlling the at least one ECU (201) based on instructions provided by the master ECU (102), if one of the master ECU (102) is present and if an input High Voltage (HV) is present;
Determining if the input HV is present, if the master ECU (102) is not present;
Controlling the at least one ECU (201) independently and powering a plurality of slave ECUs other than the at least one ECU (201) if the input HV is available and if the master ECU (102) is not present after a pre-defined time; and
entering to a sleep state on determining that the input HV and the master ECU (102) are not present.
10. The system as claimed in claim 1, wherein the microcontroller (209) is configured to reset the microcontroller (209) by:
sending a plurality of frames on a CAN bus to a master ECU (102);
receiving the plurality of frames from the master ECU (102) through a CAN bus; and
sending a sleep command to the CAN transceiver (206) for performing an initialization, if one of at least one frame receiving timeout is noticed after a threshold timeout and if the plurality of frames is not received from a master ECU (102).
11. The system as claimed in claim 10, wherein, on detecting that a code is stuck and on detecting that an internal watchdog timer is unable to act, the microcontroller (209) is configured to reset the microcontroller (209) by:
incrementing a first counter in at least one independent timer in the microcontroller (209);
incrementing a second counter in a run scheduler in the micro controller (209); and
sending the sleep command to the CAN transceiver (206) for performing an initialization, if a comparison of the first counter of the at least one independent timer and the second counter of the run scheduler are above a reset threshold.
12. A method for managing at least one Electronic Control Unit (201) from a plurality of slave ECUs in an electric vehicle, the method comprising:
determining, by a microcontroller (209), if a master ECU (102) is present;
determining, by the microcontroller (209), if a High Voltage (HV) input is available for operating the at least one ECU (201), if the master ECU (102) is absent, when a failure occurs in one or more of the plurality of slave ECUs, wherein the at least one ECU (201) runs independent of the master ECU (102), on determining that the HV input is available; and
resetting, by the microcontroller (209), the microcontroller (209) based on a feedback mechanism.
13. The method, as claimed in claim 12, wherein the resetting is performed after pre-sleep operation and initialization.
14. The method, as claimed in claim 13, wherein, performing the pre-sleep operation comprises:
entering, by the microcontroller (209), into a pre-sleep state, when a CAN transceiver (206) receives a sleep command from a master ECU (102); and
sending, by the microcontroller (209), sleep commands from the master ECU (102) to the CAN transceiver (206), on completing pre-state sleep operations.
15. The method, as claimed in claim 13, wherein, the initialization comprises:
controlling, by the microcontroller (209), the at least one ECU (201) based on instructions provided by the master ECU (102), if one of the master ECU (102) is present and if an input High Voltage (HV) is present;
determining, by the microcontroller (209), whether the input HV is present, if the master ECU (102) is not present;
controlling, by the microcontroller (209), the at least one ECU (201) independently and powering a plurality of slave ECUs other than the at least one ECU (201) if the input HV is present and if the master ECU (102) is not present after a pre-defined time; and
entering, by the microcontroller (209), into a sleep state on determining that the input HV and the master ECU (102) are not present.
16. The method as claimed in claim 12, wherein the resetting comprises:
sending a plurality of frames on a CAN bus to the master ECU (102);
receiving the plurality of frames from the master ECU (102) through a CAN bus; and
sending a sleep command to the CAN transceiver (206) for performing an initialization, if one of at least one frame receiving timeout is noticed after a threshold timeout and if the plurality of frames is not received from a master ECU (102).
17. The method as claimed in claim 12, wherein, on detecting that a code is stuck and an internal watchdog timer is unable to act, the resetting comprises:
incrementing a first counter in at least one independent timer in the microcontroller (209);
incrementing a second counter in a run scheduler in the micro controller (209); and
sending the sleep command to the CAN transceiver (206) for performing an initialization, if a comparison of the first counter of the at least one independent timer and the second counter of the run scheduler are above a reset threshold.
, Description:TECHNICAL FIELD
[001] Embodiments disclosed herein relate to electric vehicles, and more particularly to fault management of at least one ECU present in electric vehicles.

BACKGROUND
[002] Electric vehicles typically comprise a plurality of Electronic Control Units (ECUs). The plurality of ECUs comprises a single master ECU which provides instructions to the other ECUs (referred to herein as the Slave ECUs). FIG. 1A illustrates a system level architecture for ECUs in vehicles. In order to reduce power consumption in electric vehicles during idle mode, a master ECU 102 instructs all the slave ECUs 104-1, 104-2, …, 104-N to get into sleep mode. This means that, only the master ECU 102 is awake in idle condition and the slave ECUs 104-1, 104-2, …, 104-N get into sleep mode. Minimum circuits are powered on effectively, thereby reducing current drawn from an auxiliary (AUX) battery 106 that supplies power to all the ECUs. The master ECU 102 monitors vehicle conditions and sends a Wakeup command to wake up the necessary slave ECUs.
[003] Under certain conditions, the master ECU 102 may not send Wakeup commands after SLEEP. Examples of the conditions are: 1) when master ECU/ Slave ECU goes missing from CAN bus 108, 2) Loose signal wiring issues, and 3) Errors in software logic. Such conditions can cause critical ECUs, such as DC-DC converters and Motor Control Units from performing their intended operations and therefore can cause vehicle immobilization.
[004] One of the slave ECUs can be, for example, a DC-DC converter. If the AUX battery 106 goes below a threshold voltage, the master ECU 102 sends a command to wake up the DC-DC converter in order to charge the auxiliary battery 106. The DC-DC converter or the power converter may not receive the wake up command from the master ECU 102 in following conditions: 1. When master ECU or the power converter goes missing from the CAN bus, 2. Loose signal wiring issues, and 3. Software logic issues. In case of any faults in the system, the DC-DC converter has to function independent of the master ECU 102, as the DC-DC converter is a critical ECU for powering the other slave ECUs and for charging the AUX battery 106.
[005] FIG. 1B illustrates an overall architecture of a conventional slave ECU, such as, a power converter ECU or a power converter 104 with vehicle high voltage and low voltage power supply. Power converter can be interchangeably referred to as the DC-DC converter. The power converter 104 comprises a power converter hardware 108. The power converter hardware 108 receives a power input 110 and outputs a power output 112. The power converter hardware 108 is connected to a control module 114. The control module 114 comprises an internal low power supply 116, a microcontroller 118, and a CAN transceiver 120. Internally, the CAN transceiver 120 controls power supply for a CAN controller (not shown in FIG. 1B) and the microcontroller 118. The CAN transceiver 120 communicates to the microcontroller 118 coupled to the CAN transceiver 120, through communication lines and wakes up only on receiving a particular message, such as a wake up command, from the master ECU 102. When the master ECU 102 sends a sleep command through the CAN bus 108 (shown in FIG. 1A), the power converter 104 senses the sleep command and sends a message to the CAN transceiver 120 to go to sleep, through the communication lines. Before sending the command to sleep, the power converter 104 makes sure that the CAN transceiver 120 is configured to correct wake up triggers, i.e., CAN wake up messages, from the master ECU 102.
[006] In existing techniques, operations that fail in the slave ECUs, due to CPU overload, RAM overload, scheduler error, or timer fault, go undetected by the Master ECU 102. A microcontroller, such as the microcontroller 118, is used in such circumstances for managing such faults. If the faults go undetected, the vehicle can immobilize. However, currently, a manual intervention of the microcontroller, such as a reset, is required to resume normal operation of the ECUs, and hence the vehicle.

OBJECTS
[007] The principal object of embodiments herein is to disclose methods and systems for fault management in ECUs, such as, but not limited to power converters, in electric vehicles.
[008] Another object of embodiments herein is to disclose methods and systems for switching on at least one power converter independent of a master ECU so that the vehicle does not get immobilized.
[009] Another object of embodiments herein is to disclose methods and systems for giving output power to the at least power converter, when a fault is suspected, irrespective of the presence of the master ECU, if a high voltage is present, so that the vehicle does not immobilize.
[0010] Another object of embodiments herein is to disclose methods and systems to render a microcontroller intelligent enough to reset itself in case of errors or faults occurring in the slave ECUs.
[0011] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
[0012] Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0013] FIG. 1A illustrates a system level architecture for electronic control units (ECUs) in a vehicle;
[0014] FIG. 1B illustrates an Overall Architecture of a Slave ECU and the interaction of the slave ECU with Vehicle High Voltage and Low Voltage Power Supply;
[0015] FIG. 2 illustrates a system for fault management, according to embodiments as disclosed herein;
[0016] FIG. 3 illustrates a flow chart showing a difference between a normal wake up and a hardware (HW) wake up, according to embodiments as disclosed herein;
[0017] FIG. 4 illustrates an intelligent feedback mechanism for efficient fault management, according to embodiments as disclosed herein;
[0018] FIG. 5 illustrates resetting operation by the microcontroller, according to embodiments as disclosed herein; and
[0019] FIG. 6 illustrates timing results, according to embodiments as disclosed herein.

DETAILED DESCRIPTION
[0020] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0021] The embodiments herein describe methods and systems for fault management in ECUs present in the electric vehicle. Referring now to the drawings, and more particularly to FIGS. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0022] FIG. 2 illustrates a system 200 for fault management, according to embodiments disclosed herein. The system 200 provides a power converter 201 that charges the AUX battery 106 and powers other ECUs in the system independent of the master ECU. The system 200 comprises a master ECU 102 and a plurality of Slave ECUs. The plurality of ECUs (not shown in FIG. 2) includes, but not limited to, engine control module (ECM), powertrain control module (PCM), Transmission Control Module (TCM), Brake Control Module (BCM), Central Control Module (CCM), Central Timing Module (CTM), General Electronic Module (GEM), Body Control Module (BCM), Suspension Control Module (SCM), control unit, or control module. An example of the powertrain control module is a DC-DC converter or a power converter 201. The terms “power converter”, “DC-DC converter”, and “slave ECU” mean the same and have been used interchangeably. For the purpose of explanation, a single power converter 201 is described. The system 200 can comprise a plurality of power converters. The power converter 201, according to the embodiments herein, comprises an internal low power supply 202. The power converter 201 is powered by an auxiliary (AUX) battery 106 both in wake up mode and sleep mode. According to the embodiments herein, the internal low power supply 202 is independent of the master ECU 102. Therefore, even when the master ECU 102 fails to wake up, the internal low power supply 202 can function so that the vehicle does not immobilize.
[0023] Internally, in the power converter 201, power supply for a CAN controller is controlled by a CAN transceiver 206. The CAN transceiver 206 communicates signals related to wake up, or sleep mode, to a microcontroller 209, through a plurality of communication lines 224 and 225. The CAN transceiver 206 wakes up only on receiving a pre-defined message from a master node or the master ECU 102. The terms “master ECU” and “master node” have been used interchangeably. When the master ECU 102 sends a sleep command through a Controller Area Network (CAN), the microcontroller 209, senses the command and sends a message to the CAN transceiver 206 to get into sleep mode through the communication lines. The microcontroller 209 ensures that the CAN transceiver 206 is configured for receiving correct wake up triggers from the master ECU 102, before sending the sleep command to the CAN transceiver 206. The waking up of the power converter 201 due to the signal received from the master ECU 102 is hereinafter referred to as “normal wake up”.
[0024] In an embodiment herein, the wake up trigger can be sent to the CAN transceiver 206 using a Wake Pin 227. If any rising edge is sensed on the wake pin 227, the CAN transceiver 206 can wake up automatically. After waking up, the CAN transceiver 206 can enable power supply 229 to the microcontroller 209. The microcontroller 209 can track the sleep trigger in a previous cycle. Based on the sleep trigger in the previous cycle, the microcontroller 209 can take a decision in a consequent cycle after wake up. As the microcontroller 209 is switched off in sleep, data from the previous cycle data is stored in a non-volatile memory 210, such as, but not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM) 210.
[0025] The wake pin 227 of the CAN transceiver 206 is connected to an output of an oscillator 212. In an embodiment herein, the oscillator 212 can be a free running oscillator. When a wake up interrupt is received from the oscillator 212, the CAN transceiver 206 enables a signal through an enable/disable supply 229 of the internal low power supply 202. Input for the power converter 201 is given from an auxiliary (AUX) battery 106. The AUX battery 106 also provides an input power supply to the microcontroller 209 through the enable/disable supply 229. Only when the input power supply is enabled, the internal Power Supply 202 of DC-DC converter 201 converts the power supply (PS) needed for peripherals in CAN Transceiver 206 and Microcontroller 209. PS2 222 is needed for Input Output Peripherals (Vio) and PS3 223 is required to drive Functionality of CAN Transceiver 206 in Wake Up. When module is expected to sleep, the complete supply for the system 200 is disabled by way of the enable/disable supply 229. The microcontroller 209 utilizes the following peripherals in general: a first communication peripheral PS1 221 for configuring the CAN transceiver 206, a second communication peripheral PS2 222 for communicating with non-volatile memory 210; one or more timers, and a General Purpose Input Output (GPIO) to sense high voltage out of limits. The one or more timers and the GPIO are internal to the microcontroller 209. The waking up of the power converter 201 due to the signal received from the oscillator 212 is hereinafter referred to as “hardware wake up”
[0026] According to the embodiments herein, the power converter 201 wakes up periodically and checks for faults present in the system 200. In case of presence of faults, the power converter 201 provides output power to the other slave ECUs and powers the AUX battery 106, irrespective of the presence of master ECU 102, if a High Voltage (HV) is present. If no faults are detected, the power converter 201 goes in to sleep mode.
[0027] A periodic rising edge for a fixed time period is used on the wake pin 227 of the CAN transceiver 206, to wake the CAN transceiver 206. For waking the CAN transceiver 206 at periodic intervals, a pulse width modulation (PWM) of time period Tb is generated by the oscillator 212. The time period Tb depends on the Resistance (R) and Capacitance (C) values. In an example, the time period Tb can be 2.5 seconds.
[0028] In order to differentiate between deliberate wake command from the master ECU 102, i.e., normal wake up, and the wake up trigger through the wake pin 227 of the CAN transceiver 206, i.e., the hardware wake up, a non-volatile memory 210, such as, but not limited to, an EEPROM, is utilized. The microcontroller 209 performs the following set of operations in order to manage faults: 1) a pre-sleep operation, 2) initialization process, and 3) Reset. The microcontroller 209 is programmed to perform the operations for managing faults in the system 200. The programmed microcontroller 209 comprises a fault management module (not shown in FIG. 2) to perform the pre-sleep operation, initialization process, and the reset.
[0029] The microcontroller 209 can operate in the pre-sleep state, when the CAN transceiver 206 receives a sleep command from the master ECU 204. The microcontroller 209 in the pre-sleep state, processes operations, such as, configuration of the CAN transceiver 206 for correct wake up triggers, so that the power converter 201 goes into a full sleep state. The microcontroller 209 stores bit ‘1’ in the non-volatile memory 210, so that, in the next wake up cycle, the microcontroller 209 is aware of the reason for sleep in the previous cycle. On completing the pre-state sleep operations, the microcontroller 209 sends sleep commands to the CAN transceiver 206.
[0030] The CAN transceiver 206 powers the microcontroller 209, on the CAN transceiver 206 receiving the CAN wake up from the master ECU 102, or a hardware wake up command from the output of the oscillator 212. The microcontroller 209 performs the initialization process, on the microcontroller 209 being powered on and by checking the presence of the master ECU 102. If the master ECU 102 is present, the DC-DC converter 201 runs normally based on instructions by the master ECU 102. If the master ECU 102 is not present, the microcontroller 209 checks for an input high voltage (HV). If the input HV is present and the master ECU 102 is not present after a pre-defined time, the DC-DC converter201 functions independently and powers the other ECUs in the system 200. The pre-defined time is the time delay from the oscillator 212. If the input HV is not available, the DC-DC converter 201 runs normally, based on instructions provided by the master ECU 102. If the input HV is not present and if the master ECU 102 is also not present, the DC-DC converter 201 enters back into sleep state concluding that it was an intentional sleep cycle.
[0031] The process that follows the initialization is the reset. The reset process of the microcontroller 209 is based on analyzing faults or failures in the power converter 201 with the help of an intelligent feedback mechanism for the microcontroller 209. Using the feedback mechanism, frames are sent between the microcontroller 209 in the DC-DC converter 201 and the master ECU 102 through the CAN bus 108. If a frame receiving timeout is noticed by the microcontroller 209, after a certain threshold timeout, or if the frames have not been received from the master ECU 102, the microcontroller 209 sends the sleep command to the CAN transceiver 206 and performs the initialization process, based on the wake up command received from the oscillator 212. The system 200 can be reset when there is a code stuck and when an internal watchdog timer is unable to act. A first counter is incremented in one independent timer, such as a CPU timer, in the microcontroller 209. The CPU Timer is Micro controller internal peripheral. Depending on the microcontroller 209, the system 200 can comprise multiple CPU Timers independent of each other. A second counter is incremented in a run scheduler. The run scheduler comprises normal code and the CPU timer comprises logic for the reset process. If the comparison between the first counter and the second counter are above a reset threshold, the microcontroller 209 sends the sleep command to the CAN transceiver 206 and performs the initialization process. The reset threshold depends on how much time total code takes for execution and further depends on application. The reset threshold time can be twice the time taken for total code execution time in non-time critical applications and exact time bound in time critical applications. In an example, the code can take five micro seconds to execute, then the reset threshold value would be 10 micro seconds.
[0032] FIG. 3 illustrates a flow chart showing a difference between a normal wake up and a hardware wake up, according to the embodiments herein. At step 302, the microcontroller 209 checks if the sleep command from the master ECU 204 is high or low. At step 304, on determining that the sleep command from the master ECU 102 is high, the microcontroller 209 enters into a pre-sleep state. At step 306, the microcontroller 209 writes a bit in the non-volatile memory 210 as 1. The microcontroller 209 instructs the CAN transceiver 206 for next wakeup trigger. The microcontroller 209 instructs the CAN transceiver 206 to go to sleep through the communication lines. At step 308, the power converter 201 enters a power-off mode as the transceiver 206 disables the power supply. At step 310, if the sleep command from the master ECU 102 is low, then the system 200 runs in the normal mode.
[0033] At step 312, the master ECU 102 can send a CAN wake up, and the oscillator 212 can send a hardware wake up to the CAN transceiver 206. At step 314, the internal low power supply 202 enters to power on state and the microcontroller 209 starts the initialization process, on receiving the CAN wake up and the hardware wake up. The microcontroller 209 checks if the bit in the non-volatile memory 210 is 1 or 0. The bit value in the non-volatile memory 210 is hereinafter referred to as Sleep_E bit. If the Sleep_E bit is zero, then the DC-DC converter or the power converter 201 runs in normal mode. If the Sleep_E bit is 1, then the microcontroller 209 checks for the presence of a master ECU 102. At step 316, if the master ECU 102 is present, the power converter 201 runs in normal mode. In the normal mode, the power converter 201 can run on instructions from the master ECU 102. If the master ECU 102 is absent, at step 318, the microcontroller 209 checks for presence of High Voltage (HV) at the input. At step 320, if the HV is not present, power converter 201 switches back to the sleep mode. At step 322, if the HV is present, the power converter 201 runs in an independent mode. In the independent mode, the power converter 201 works without any enable instructions from master ECU 102 as it assumes that the master ECU 102 is faulty.
[0034] The microcontroller 209 enters a pre-sleep state, when the CAN transceiver 206 receives a sleep command from the master ECU 102. In the pre-sleep state, the microcontroller 209 processes operations that are needed, before going to a full sleep state. The microcontroller 209 writes a bit in the non-volatile memory as 1, so that, in the next wake up cycle, the microcontroller 209 knows the reason for sleep in the previous cycle. The microcontroller 209 sends sleep commands to the CAN transceiver 206, on completing the pre-state sleep operations. The CAN transceiver 206 powers the microcontroller 209, on the CAN transceiver 206 receiving a wake-up command, i.e., a CAN wake up from the master ECU 102 and a hardware wake-up command from an output of the oscillator 212.
[0035] The microcontroller 209 checks for the presence of the master ECU 102 after performing an initialization process for the sleep cycle.
[0036] FIG. 4 illustrates an intelligent feedback mechanism for efficient fault management, according to the embodiments herein. The intelligent feedback mechanism enables the microcontroller 209 to detect communication outage in vehicle level conditions, and reset by itself. The intelligent feedback mechanism uses one or more critical frames for detecting communication outage in vehicle level conditions. At step 402, the microcontroller 209 sends a frame on a CAN bus. A frame is a message according to the CAN standard, sent between various ECUs or nodes in a control system, through the CAN bus. Frames can be data frames, error frames, remote frames, and overload frames. In an embodiment herein, the frame which is being sent, is configured in “Receive Mailbox”. At step 404, the CAN bus carries the frames and a continuously timer is run to receive the frame being sent. At step 406, if any timeout in frame is noticed after a certain time threshold (Timeout_th), at step 408, the microcontroller 209 sends the sleep command. After a fixed period of time, wake up instructions are received from the oscillator 212. If the frame receiving timeout is noticed after the threshold time (Timeout_th), or if the frames have not been received from the master ECU 102, then the microcontroller 209 sends the sleep command to the CAN transceiver 206. At step 410, the CAN transceiver 206 powers the microcontroller 209, on the CAN transceiver 206 receiving a wake-up command (i.e., CAN Wake-Up) from the master ECU 102 or a hardware wake-up command from an output of the oscillator 212. At step 412, the microcontroller 209 performs the initialization process by checking the presence of the master ECU 102.
[0037] The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.
[0038] FIG. 5 illustrates resetting operation by the microcontroller, according to the embodiments herein. The microcontroller 209 needs to be reset when there is a code stuck and an internal watchdog timer is unable to act. At step 502, a first counter in an independent timer (CPU timer) present in the microcontroller is incremented. At step 504, a second counter in a run scheduler is incremented. The first counter and the second counter are continuously compared in the same independent timer. At step 506, if the difference is above a reset threshold (Reset_Th), at step 508, the microcontroller 209 sends instructions to the CAN transceiver 206 to sleep and the microcontroller 209 is reset. The oscillator 212 wakes power converter 201 up after a fixed period of time. At step 510, the microcontroller 209 checks if one of the CAN wake up and the hardware wake up signals are 1. At step 512, on one of the CAN wake up and the hardware wake up signals being 1, the microcontroller 209 performs the initialization process.
[0039] In order to achieve optimum results, periodic wakeup time is decided in such a way that it does not violate sleep current requirement. The acceptable time period for the oscillator output (Tb) is calculated as per below equation:
Tb (seconds) = T(Init(seconds))*I(Operating(mA))/(I(Req) – I(Sleep))
Wherein,
I (Operating) – Current drawn by the power converter 201 from AUX Battery 106 in operating condition;
I (Sleep) – Current drawn by the power converter 201 from AUX Battery 106 in sleep condition;
I (Req) – Acceptable sleep current from AUX Battery 106 requirement from vehicle perspective;
T (Init) – Initialization time to take decision; and
Tb – Acceptable time period for oscillator output.
[0040] The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.
[0041] FIG. 6 illustrates timing results, according to the embodiments herein. Td is the delay by oscillator 212 for giving the wake up triggers.
[0042] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 2 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[0043] The embodiment disclosed herein describes methods and systems for fault management in ECUs such as, but not limited to power converter. The embodiments herein ensure that the power converter switches on independent of the master ECU and that the vehicle does not immobilize. Further, the embodiments herein ensure that the power converter gives the output power, when a fault is suspected, irrespective of the state of the master ECU. If the fault is not suspected, the ECU goes back to sleep. The embodiments herein provides methods and systems to wake a power converter periodically and to check for faults. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) or Embedded C on microcontroller, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor/Micro controller and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0044] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of embodiments and examples, those skilled in the art will recognize that the embodiments and examples disclosed herein can be practiced with modification within the spirit and scope of the embodiments as described herein.