FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See Section 10; rule 13)
TITLE OF THE INVENTION Optimization of Controller Area Network Architecture with Hardwired Wake-up
Capability
APPLICANTS
TATA MOTORS LIMITED, an Indian company
having its registered office at Bombay House,
24 Homi Mody Street, Hutatma Chowk,
Mumbai 400 001 Maharashtra, India
INVENTOR Dibyendu Palai
All Indian nationals
of TATA MOTORS LIMITED,
an Indian company having its registered office
at Bombay House, 24 Homi Mody Street, Hutatma Chowk,
Mumbai 400 001 Maharashtra, India
PREAMBLE TO THE DESCRIPTION The following specification particularly describes the invention.

FIELD OF INVENTION
The present invention relates to vehicular communication networks where different electronic control units (ECUs) communicate with each other over controller area network (CAN) protocol and, more particularly, such network provides co-ordination of wake-up and sleep for optimization of network architecture for controller area networks.
BACKGROUND OF INVENTION
With the advent of distributed control functionalities the need has arisen for optimized communication network systems where different electronic control units (ECUs) are connected with each other through controller area network (CAN network) buses for sharing hundreds of critical signals. Typical applications of such network systems are widely seen in automotive domain, where in-vehicle networks are used as the backbone of all distributed control functions. So, optimization of such network architecturs is of utmost importance for vehicle manufacturers to improve reliability and reduce engineering effort and cost of development.
Typically to execute different functionality, only a subset of the ECUs in the network is required to operate with each other; always the entire network is not required to operate. The proposed invention also talks about how to synchronise the wake-up of a sub-set of ECUs which are necessary to execute the target function in the network so that other un-necessary ECUs are not needed to operate. The proposed invention also talks about how to synchronise the sleep (or power-down) of a sub-set of ECUs which are not necessary to execute any target function in the network. This will minimize the power consumption of the vehicle because only the necessary sub-set of ECUs are operational to deliver a target function and un-necessary ECUs are in sleep mode.

Most common and existing method to wake-up ECUs and to command ECUs to go to sleep is based on completely hardwired architecture, where separate wires are routed from all the switch inputs to all necessary ECUs. There are many drawbacks of this method. This method increases the complexity and weight of wiring harness because different combinations of wires need to be routed for wake-up and sleep of different ECUs from different switches. This also increases the number of input and output pins in the ECU connectors to accommodate different switch inputs and thus cost and complexity are increased.
Other method suggests complete elemination of hardwired lines to control wake-up and sleep of different ECUs and recommends the wake-up and sleep of ECUs to be controlled by CAN network. As different ECUs are connected over Controller Area Network (CAN) to realize different vehicle functions, the same CAN network is used to co-ordinate wake-up and sleep of different ECUs. Typically these types of CAN networks are widely used in automotive vehicles, plant automations, etc. This invention is applicable in all such applications where controller area network is used as backbone electrical architecture for sharing electrical signals.
EP 1,158,718 discloses about a method of wake-up and sleep using CAN network where different ECUs needed to execute a target function by forming a virtual network. ECUs that comprise virtual network are operable together to perform a control task and are each identified using a code that is associated with each virtual network. Each virtual network can be activated using respective CAN message that they receive over the CAN bus. Once activated, a virtual network is then operable to perform its associated control task. Preferably, the messages include one or more of the codes used to identify the ECUs in a particular virtual network. In this way, an ECU can wake-up other ECUs out of their standby mode without having to know which ECUs are parts of the virtual network used to implement a particular control

task. This patent application also provides a method for ECUs to be switched between and active state and a low power quiescent state. The method includes the steps of: receiving a signal request for activating a control task; waking up the ECUs out of the low power quiescent state; and sending a message to the ECUs that includes a code associated with the control task. This message is received by some or all of the ECUs in the CAN network and, for each of these ECUs, if the code included with the message corresponds to a control task associated with the ECU, then the ECU enters into an active state in which the ECU is operable to perform the control task together with other ECUs associated with the control task. However, if the code included with the message does not correspond to a control task associated with the ECU, then it enters into the low power quiescent state.
EP 0773650 discloses about similar method of wake-up and sleep of different ECUs or nodes using CAN network by a sleep determining unit, a signalling or notifying unit and a switching unit in the CAN network. The sleep determining unit makes a decision as to whether or not an operating state of its own node can be shifted to a sleep state having less power consumption than a normal state. When it is determined by the sleep determining unit that the corresponding node is not able to shift to the sleep state, the notifying unit transmits a signaling signal for notifying all other nodes of the result of determination referred to above by the sleep determining unit. Further, the switching unit switches the operating state of its own node to the sleep state when it is determined that the signaling signals sent from other nodes are continuously not received for a predetermined time interval or more where the sleep determining unit determines that the corresponding node is able to shift to the sleep state. At least one of the plurality of nodes includes a start condition determining unit and a first starting unit in the multiplex communication system. The start condition determining unit determines whether predetermined start conditions for starting the system have been established when its own node is in the sleep state. If it is determined by the start

condition determining unit that the start conditions have been established, the first starting unit switches the operating state of its own node from the sleep state to the normal state and transmits twice a start signal for notifying a start-up of its own node to all other nodes. All other nodes detect the start signal and come out of sleep state.
Although these methods mentioned in prior arts, eleminate the need of routing separate wiring harness for controlling wake-up and sleep of different ECUs, there are many drawbacks associated with these methods as explained below.
- Direct Network Management as per OSEK/VDX Network Management requirements needs to be implemented in all ECUs in CAN network, if wake-up and sleep of ECUs are controlled by CAN network. Implementation and validation of these OSEK/VDX requirements in all ECUs in the CAN network leads to huge increase in engineering effort and cost.
- To realize wake-up on CAN feature in any ECU, normal CAN transceivers can not be used. These calls for additional implementations inside CAN transceivers to support wake-up on CAN feature with excellent on-chip energy management to cut-off power supply from micro-controller during sleep state. Examples of such CAN transceivers with wake-up on CAN feature are: TJA1041, TJA1041A from M/s NXP, and TLE6251G from M/s Infinion, etc. The cost of these CAN transceivers is much higher than the nomal CAN transceivers (without wake-up on CAN feature).
- The reliability of this method of wake-up on CAN in the field is not good due to indeterministic property of CAN network.
- The vehicle level quiescent current also increases because the CAN transceivers used shall also draw current while in sleep mode to perform the CAN frame monitoring functionality.
- Also, if wake up of sleep ECUs is not achieved properly it may lead to battery discharge.

To resolve these drawbacks stated above the present invention proposes new network architecture for co-ordination of wake-up and sleep of any ECUs in the network. The detailed strategy of co-ordination of wake-up and sleep using the Hardwired Wake-up Line (HWL) for all ECUs connected over CAN network is proposed in the present invention. The advantages of present invention over prior arts are as follows:
- As wake-up and sleep are not directly controlled by CAN network, CAN transceivers with wake-up on CAN functionality are not needed within any ECU in the network. So, normal CAN transceivers (without wake-up on CAN feature) can be used in all ECUs. This will result in huge cost reduction for the overall network system. Examples of such CAN transceivers (without wake-up on CAN feature) are: TJA1050, TJA1040 from M/s NXP, and TLE6250G from M/s Infinion, etc.
- There is no need to implement Direct Network Management in any of the Sleep ECUs. Network Management requirements for IGN ECUs need to be modified to suit Network Management for Sleep ECUs. This change is very minimal compared to implementation of Direct Network Management in Sleep ECUs. Hence, the engineering effort and cost is much lower.
- The vehicle level quiescent current is also minimized since the CAN Transceivers used are active only when there CAN communication is active. The Controller Area Network (CAN) Transceivers do not consume any load current during Sleep Mode. Note that there is no direct battery supply line going to CAN Transceivers of Active and Passive Wake-up ECUs (refer Figure 6 and 7).
- This method provides excellent fail-safe strategy by allowing Passive Wake-up ECUs to go to Sleep Mode even during CAN Network Fault conditions (i.e. CAN short circuit or open circuit fault conditions).
- There is no need to provide Ignition line input to all Passive Wake-up ECUs. It is sufficient to provide Ignition input only to Active Wake-up ECU. In the event of Ignition ON, Active Wake-up ECU will wake up first and then in turn wakes up other

Passive Wake-up ECUs. So, no need to route IGN line to all Passive Wake-up ECUs. Thus, one pin can be saved in all Passive Wake-up ECUs.
- The wake-up of Sleep-ECUs is always deterministic because it takes place through a dedicated hardwired wake-up line.
OBJECT OF INVENTION
The primary object of present invention is to develop a new network architecture wherein the wake-up and sleep of different Electronic Control Units (ECUs) connected over Controller Area Network (CAN) bus are controlled by a dedicated Hardwired Wake-up Line (HWL).
Another object of the present invention is to provide one active wake-up ECU in the network which is provided with global wake-up inputs.
Yet another object of the present invention is to design a network in which there is no need to provide ignition line input to the entire passive wake-up ECUs.
Yet another object of the present invention is to use normal CAN transceivers without wake-up on CAN features in all the ECUs of the network.
SUMMARY OF INVENTION
The present invention relates to a vehicular communication network to put preselected electronic control units (ECUs) into wake-up or sleep mode, when desired, comprises, a plurality of electronic control units connected together via network bus, a first set of said ECUs being configured to be in a ignition mode, a second set of said

ECUs being configured to be in a dormant mode, atleast any one of said second set of ECUs is changed to be in active wake-up mode from the dormant mode in response to a signal received by wake-up inputs, said active wake-up ECU is adapted to generate wake-up signal to stimulate other passive ECUs of the dormant mode, and a common electrical connection provided with all the dormant mode ECUs for transmitting wake-up signal to the passive ECUs in order to synchronize wake-up and sleep of any dormant ECUs for optimizing the network.
According to a preferred embodiment, the network bus is a high speed controller area network (CAN) bus that permits communication between said ECUs.
Preferably, said active wake-up ECU is provided with global wake-up inputs.
According to another preferred embodiment, said common electrical connection established with the entire dormant mode ECUs by hardwired line.
Preferably, said wake signal is a pulse-train transmitted by said active wake-up ECU over hardwired line.
Most preferably, wherein said dormant ECUs have transceivers without wake-up on CAN feature, which are cheaper. The transceiver without wake-up on CAN feature minimize the vehicle quiescent current consumption.
According to a preferred embodiment, an excellent fail-safe strategy is adopted by allowing Passive Wake-up ECUs to go to sleep mode even during CAN fault conditions (i.e. CAN short circuit or open circuit fault conditions) and the drainage of vehicle battery due to any network fault condition will be totally eliminated.
According to another preferred embodiment, an ignition line is not connected to all passive wake-up ECUs and thus one pin can be saved in all passive wake-up ECUs in

the network.
Preferably, said any sleep ECU does not need to implement Direct Network Management requirement as per OSEK/VDX specification (Open Systems and the Corresponding Interfaces for Automotive Electronics).
BRIEF DESCRIPTION OF INVENTION
The invention proposes a new network architecture and method for controlling wake-up and sleep of different ECUs connected over CAN Network. As per the present invention, there is one Active Wake-up ECU in the network. Different wake-up inputs (from door open switch, hazard switch, etc) will be connected to this Active Wake-up ECU in the network. This Active Wake-up ECU in turn wakes up other Passive Wake-up ECUs in the network thourgh a separate and single Hardwired Wake-up Line (HWL). The HWL will be connected to all Sleep ECUs. The invention proposes the new network architecture, detailed wake-up and sleep strategy for all the ECUs, and the realization of Hardwired Wake-up Line.
BRIEF DESCRIPTION OF DRAWINGS
Figure 1 is a block diagram showing the conventional CAN network architecture.
Figure 2 shows functional block diagram of any Sleep ECU with Wake-up on CAN capability.
Figure 3 is a block diagram showing the proposed CAN network architecture with Hardwired Wake-up capability.

Figure 4 is a flow chart showing the detailed operation of Sleep ECUs as per current invention.
Figure 5 shows the Wake-up Pulse-train which shall be transmitted by Active Wake-up ECU to wake the Passive Wake-up ECUs.
Figure 6 is a functional block diagram of any Active Wake-up ECU in conjunction with Hardwired Wake-up capability.
Figure 7 is a functional block diagram of any Passive Wake-up ECU in conjunction with Hardwired Wake-up capability.
DETAILED DESCRIPTION OF INVENTION
Referring to the accompanying drawing, wherein the showings are for the purpose of illustrating a preferred embodiment of the invention only, and not for the purpose of limiting the same.
A typical logical diagram of a conventional Controller Area Network (CAN) network system with wake-up on CAN capability is shown in Figure .1. In the existing conventional approach, the wake-up of Electronic Control Unit (ECUs) connected over CAN network are controlled by the CAN network itself. Six ECUs (101, 102, 103, 104, 105, 106) are connected with high speed CAN bus (107). Out of these six ECUs in the network, ECU1, ECU5 and ECU6 are ignition electronic control units (IGN ECUs). The ECUs which are operational only when ignition is switched ON are termed as IGN ECU. These ECUs are not operational when ignition is switched OFF. ECU2, ECU3 and ECU4 are Sleep ECUs provided with wake-up on CAN capability. ECUs which are operational even when ignition is switched OFF are termed as Sleep

ECU. So, these ECUs are operational when ignition is ON and also when ignition is OFF. Local wake-up inputs (108) are only connected to each sleep ECUs (102, 103, 104). An ignition line (109) needs to be connected to all of the ECUs in this system. In this network architecture Global Wake-up lines are not used. Global Wake-ups are the wake up signals which are intended for the execution of the functional requirements of all the sleep ECUs. These global wake-up lines are wired to active wake-up ECU only. Only Local Wake-up lines (108) are used and they are connected to respective Sleep ECUs (102,103, 104). Local Wake-ups are the wake up signals which are intended for execution of the functional requirements of any specific sleep ECU only. These local wake-up lines are wired to that specific sleep ECU only. In Figure 1, ECU2 is connected with 2 switch inputs, ECU3 is connected with 3 switch inputs and ECU4 is connected with 2 switch inputs. These switch inputs are acting as Local Wake-up inputs (108) for these ECUs respectively. Whenever, ECU2 or ECU3 or ECU4 senses any local switch input, it will wake up other ECUs (i.e. ECU3 or ECU4) by sending CAN network management frames (as per OSK/VDX Direct Network Management) and will form a logical ring among ECU2, ECU3 and ECU4. After successful logical ring formation, this part of the network will function. Whenever there is Ignition ON, all ECUs need to wake up. Hence, ignition line (109) needs to be connected to all ECUs separately. Network will sleep when all ECUs will confirm that they are not needed to be operational, which means that all the ECUs in the same logical ring need to stay awake as long as ongoing communication takes place, even if few ECUs in this logical ring are not participating in the communication. It is very important to note that if there is a faulty ECU in the logical ring and this faulty ECU fails to acknowledge that it does not need to be operational, then all the ECUs in the logical ring remains alive and the complete CAN bus does not enter in to Sleep Mode. The consequence of this fault is high current consumption by all ECUs even when the car is parked which leads to battery drain and possibly the car cannot be started at the next day due to empty battery.

Figure 2 shows the functional block diagram of any Sleep ECU which are used in conventional CAN network system (example: ECU2 or ECU3 or ECU4 as shown in Figure 1) with wake-up on CAN capability. This shows that to achieve wake-up on CAN capability in any ECU in conventional system, additional control and power supply pins are needed in the CAN transceiver. As the vehicle battery line is connected to the CAN Transceiver , this CAN Transceiver chip inside the ECU is always powered up even when the ECU is in Sleep Mode. Therefore, the conventional Sleep ECU with Wake-up on CAN capability always draws more quiescent current in Sleep Mode. Also, these sleep ECUs need to implement all the requirements of OSK/VDX Direct Network Management which is very much complex.
The present invention proposes a novel approach to eliminate demerits of conventional CAN network architecture. This network architecture of the present invention as shown in fig. 1 consists of IGN ECU (301, 305, 306), Active Wake-up ECU (302), Passive Wake-up ECU (303, 304), Hardwired Wake-up Line (311), etc. A Sleep ECU which wakes up first by different wake-up inputs (from door open switch, hazard switch, etc) and in turn wakes up other Sleep ECUs is termed as Active Wake-up ECU. A Sleep ECU which can be woken up by Active Wake-up ECU is termed as Passive Wake-up ECU.
As per the present invention shown in fig 3, there will be one ECU in the network with active wake-up capability and rest all ECUs in the network will be with passive wake-up capability. ECU with active wake-up capability is able to wake-up other ECUs in the network through a separate and single Hardwired Wake-up line (HWL). The HWL (311) is connected among all ECUs with active and passive wake-up capability. This type of implementation also makes it possible to have the selective wake up capability. A typical logical diagram of a CAN network system with hardwired wake-up capability is shown in Figure 3. Similar to Figure 1, six ECUs (301, 302, 303, 304,

305, 306) are connected with high speed CAN bus (307). Out of these six ECUs in the network, ECU1, ECU5 and ECU6 are IGN ECUs. In present invention, only IGN ECUs are needed to be connected with the Ignition line (309). ECU2, ECU3 and ECU4 are Sleep-ECUs. There is no need to connect Ignition line (309) to the Sleep-ECUs. Out of these three Sleep-ECUs, ECU2 (302) is acting as Active Wake-up ECU and ECU3 and ECU4 are acting as Passive Wake-up ECUs. Here, various wake-up inputs required for ECU2, ECU3 and ECU4 are wired only to Active Wake-up ECU (i.e. ECU2 in this case), and these are termed as Global Wake-up input (308). Similar to figure 1, if ECU2 requires 2 switch inputs, ECU3 requires 3 switch inputs and ECU4 requires 2 switch inputs for their wake-up respectively, then all 7 switch inputs shall be connected to ECU2 who is acting as Active Wake-up ECU.
Figure 4 shows the Flow-chart diagram of the proposed operational sequence for Sleep ECUs using HWL. If any one of the wake up input request signal (i.e. any switch input to ECU2 in Figure 3) becomes active in Global Wake-up, then Active Wake-up ECU (i.e. ECU2 in Figure 3) shall send the wake up request signal in form of Pulse-train over HWL to all sleep ECUs. All Passive Wake-up ECUs (i.e. ECU3 and ECU4 in Figure 3) will receive Pulse-train over HWL and start ECU initialization process. Also, the Active Wake-up ECU (i.e. ECU2 in Figure 3) will start transmitting necessary Application CAN frames within TcANinit time of Global Wake-up detection. These Application CAN Frames also includes the vehicle Power-mode CAN Signal which indicates the Ignition Switch State. After woken up by wake-up signal received over HWL, these Passive Wake-up ECUs (i.e. ECU3 and ECU4 in Figure 3) will check the Power-mode CAN signal transmitted by Active Wake-up ECU (i.e. ECU2 in Figure 3). A valid Power-mode will be detected by Passive Wake-up ECUs if the Power-mode CAN signal is received minimum NPM number of times within TPM time period. If valid vehicle Power-mode is not detected by any Passive Wake-up ECU within

TMessageStart time from receiving Wake-up train over HWL, then the Passive Wake-up

ECU will go to sleep mode. Else, Passive Wake-up ECU will try to determine the actual vehicle Power-mode. If the vehicle Power-mode corresponds to Ignition Switch state IGN ON, then Passive Wake-up ECU continues CAN communication in "Normal CAN Communication Mode without Fault". Else if Ignition Switch is in OFF or accessory, Passive Wake-up ECU continues CAN communication in "Reduced CAN Communication Mode".
In "Normal CAN Communication Mode without Fault", Passive Wake-up ECUs start CAN Message Monitoring after TMessageStart time from logical detection of ignition (IGN) ON condition. Such Message monitoring methods are typically used in IGN ON Power-mode for detection of presence (or absence) of Partner CAN nodes in the network. If any CAN Message Time-out or Missing Message condition is detected in IGN ON Power-mode, then a Passive Wake-up ECU confirms Partner ECU absent fault and operates in "Normal CAN Communication Mode with Partner ECU absent Fault", else it continues in "Normal CAN Communication Mode without Fault". During these operation modes, if change in Power-mode is detected corresponding to IGN OFF or accessory switch state from IGN ON switch state, then Passive Wake-up ECUs transition to "Reduced CAN Communication Mode".
In "Reduced CAN Communication Mode", Passive Wake-up ECUs start CAN Message Monitoring after TMessageStart time from logical detection of IGN OFF or accessory condition. Such Message monitoring methods are typically used in IGN OFF or accessory Switch state for detection of sleep condition. In this communication mode, Active Wake-up ECU decides how long any Sleep ECU is required to continue CAN communication to support any vehicle functionalities. If Active Wake-up ECU (i.e. ECU2 in Figure 3) decides that any particular Passive Wake-up ECU (e.g. ECU3 in Figure 3) is no longer required to realize vehicle functions, then Active Wake-up ECU selectively stops transmission of Application CAN Frames for that particular Sleep ECU (i.e. ECU3 in Figure 3), while it continue transmission of Application

CAN Frames for other Sleep ECUs (i.e. ECU4 in Figure 3). Sleep ECU detects CAN Message Time-out condition, if its ECU specific Application CAN Frames are not received from Active Wake-up ECU continuously for a duration of TMTO. When any Sleep ECU detects CAN Message Time-out in "Reduced CAN Communication Mode", that particular Sleep ECU (i.e. ECU3 in Figure 3) starts ECU Power-down sequence and goes to Sleep Mode. Other Sleep ECUs (i.e. ECU4 in Figure 3) who has not detected CAN Message Time-out in "Reduced CAN Communication Mode", continues its communication in the same mode. Once any Passive Wake-up ECU enters "Sleep Mode", it shall wait in this sleep mode for minimum time duration of Twaitsleep before it is allowed to process next Wake-up Pulse-train over HWL received from Active Wake-up ECU. This will ensure a safe Power-down process for any Passive Wake-up ECU.
In "Reduced CAN Communication Mode", if change in vehicle Power-mode is detected to Ignition Switch state IGN ON, Passive Wake-up ECUs transition to "Normal CAN Communication Mode without Fault".
The current invention also proposes the pattern of this wake-up request signal which is sent by Active Wake-up ECU over HWL to wake up the Passive Wake-up ECUs. If no global wake up input request signal is active, then Active Wake-up ECU shall pull the HWL to Zero volts. Active Wake-up ECU shall send the wake up Pulse-train over HWL within TWK time duration of logical detection of active state of any Global Wake-ups. This wake up request is proposed to be in the form of a pulse train of duration TWakeup with voltage level 12V.The use of pulse train for wake up request is proposed to offer diagnostics advantage. If the HWL gets short to battery, the sleep ECUs (ECU3 and ECU4 in Figure 3) can easily detect this since in this case they all will receive continuous high rather than pulse train input. And therefore the unintended wake up of the sleep ECUs can be avoided. Figure 5 specifies the details of

proposed wake up signal. The Passive Wake-up ECUs shall wake up at first transition from low to high level (edge trigger) of the wake up pulses received over HWL. However, the Active Wake-up ECU (i.e. ECU2 in Figure 3) shall send NWakeuP number of wake up pulses within TWakeup time duration in case the Passive Wake-up ECUs missed the 1st or 2nd pulse. Specifically the voltage transition must be higher than the VWk,th for a valid wake up signal.
When the Ignition Switch state is turned to IGN ON, the HWL shall be pulled to continuous high, so as to enable Passive Wake-up ECUs to detect that Ignition is currently ON. This will provide redundancy, because Passive Wake-up ECUs also receive Ignition Switch state information and Power-mode information from Active Wake-up ECU over CAN bus. This redundancy shall be designed in to the system to ensure fail-safe strategy. This will help any Passive Wake-up ECU in the event of sudden local open circuit fault in the CAN bus. If there is local open circuit fault or short circuit fault in the CAN bus, then that particular Passive Wake-up ECU will not receive CAN frames from other ECUs and thereby will not receive Power-mode CAN signal from Active Wake-up ECU. In this fault condition, the redundant information will help this ECU to go to Sleep Mode as follows. When IGN is turned OFF, then HWL shall be pulled to Zero Volt. Then, that particular Passive Wake-up ECU will transition to "Reduced CAN Communication Mode". As there is local open circuit in CAN bus, the Passive Wake-up ECU will not receive any Application CAN Frame from Active Wake-up ECU and it will detect Message Time-out condition and will go to Sleep Mode. This Fail-safe strategy helps to reduce Battery consumption during CAN short circuit or open circuit fault conditions. Figure 5 shows the pattern of the wake up signal during Ignition ON condition. The wake-up pulse train is transmitted by active wake-up ECU to wake the passive wake-up ECUS.

Figure 6 shows the functional block diagram of an Active Wake-up ECU (for e.g. ECU2 as shown in figure 3) with hardwired wake-up capability. This shows that to achieve hardwired wake-up capability in any ECU, no additional control and power supply pins are needed in the CAN transceiver. It is to be noted that the vehicle battery line does not interface with CAN Transceiver chip. This results in Zero current draw by the ECU when the ECU is in Sleep Mode. The same is also applicable for Passive Wake-up ECUs as shown in Figure 7.
Table 1 specifies the minimum, maximum and typical values of various configurable parameters proposed in this invention.

Parameter Description of the Min Typical Max
Name Parameter value value value
Time duration during
TWakeup which Active Wake-up ECU transmits wake-up pulse train 300 ms 300 ms 500 ms
Minimum number of wake-
NWakeup up pulses which shall be 3 3 5

transmitted by Active

Wake-up ECU over HWL
TON On time duration for wake-up pulse 50 ms 50 ms 50 ms
TOFF Off time duration for wake-up pulse 50 ms 50 ms 50 ms
Threshold voltage of wake-
Vwk, th up pulse which shall wake Passive Wake-up ECUs up 6V 6V 6V
Time duration from logical detection of active state of
TwK Global Wake-up input to transmission of wake-up pulse train over HWL 100 ms 100 ms 200 ms
TcANInit Time duration from logical detection of Wake-up input 200 ms 250 ms 300 ms

to transmission of first CAN Frame on CAN Bus
Time duration from logical detection of Wake-up input
T MessageStart to transmission of all periodic CAN Frames at least once on CAN Bus 500 ms 500 ms 700 ms
Number of times Power-mode CAN signal shall be
NPM received in succession to conclude the vehicle Power-mode 3 3 5
Time duration within which Power-mode CAN
TPM signal shall be received in succession to conclude the vehicle Power-mode 100 ms 100 ms 200 ms
Maturation time for 1000
TMTO detection of CAN Message 500 ms 500 ms

Time-Out ms
Minimum time duration during which Passive
TwaitSleep Wake-up ECUs shall NOT process any Wake-up Pulse-train over HWL after it goes to Sleep Mode 300 ms 500 ms 1000 ms
Table 1
The foregoing description is a specific embodiment of the present invention. It should be appreciated that this embodiment is described for purpose of illustration only, and that numerous alterations and modifications may be practiced by those skilled in the art without departing from the spirit and scope of the invention. It is intended that all such modifications and alterations be included insofar as they come within the scope of the invention as claimed or the equivalents thereof.

WE CLAIM:
1. A vehicular communication network to put pre-selected electronic control units
(ECUs) into wake-up or sleep mode, when desired, comprising:
- a plurality of electronic control units (301, 302, 303, 304, 305, 306) connected together via network bus (307),
- a first set of said ECUs (301, 305, 306) being configured to be in a ignition mode,
- a second set of said ECUs (302, 303, 304) being configured to be in a dormant mode,
- atleast any one of said second set of ECUs (302, 303, 304 ) is changed to be in active wake-up mode from the dormant mode in response to a signal received by wake-up inputs (308), said active wake-up ECU (302) is adapted to generate wake-up signal to stimulate other passive ECUs (303, 304) of the dormant mode, and
- a common electrical connection (311) provided with all the dormant mode ECUs (302, 303, 304) for transmitting wake-up signal to the passive ECUs(303,304) in order to synchronize wake-up and sleep of any dormant ECUs for optimizing the network.

2. The vehicular communication network as claimed in claim 1, wherein said network bus is a high speed controller area network (CAN) bus (307).
3. The vehicular communication network as claimed in claim 1, wherein said active wake-up ECU (302) is provided with global wake-up inputs (308).
4. The vehicular communication network as claimed in claim 1, wherein said common electrical connection established with the entire dormant mode ECUs by hardwired line (311).

5. The vehicular communication network as claimed in claim 1, wherein said wake signal is a pulse-train transmitted by said active wake-up ECU (302) over hardwired line (311).
6. The vehicular communication network as claimed in claim 1, wherein said dormant ECUs (302, 303, 304) have transceivers without wake-up on CAN feature, which are cheaper.
7. The vehicular communication network as claimed in claim5, wherein said transceiver without wake-up on CAN feature minimize the vehicle quiescent current consumption.
8. The vehicular communication network as claimed in any of the above claim, wherein fail-safe strategy is adopted by allowing Passive Wake-up ECUs (303, 304) to go to sleep mode even during CAN fault conditions (i.e. CAN short circuit or open circuit fault conditions).
9. The vehicular communication network as claimed in any of the above claim, wherein the drainage of vehicle battery due to any network fault condition will be totally eliminated.

10. The vehicular communication network as claimed in any of the above claim, wherein an ignition line (309) is not connected to all passive wake-up ECUs (303, 304) and thus one pin can be saved in all passive wake-up ECUs (303, 304) in the network.
11. The vehicular communication network as claimed in any of the above claim, wherein said any sleep ECU does not need to implement Direct Network Management

requirement as per OSEK/VDX specification (Open Systems and the Corresponding Interfaces for Automotive Electronics).