c12) United States Patent
`Millsap et at.
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006484082Bl
`US 6,484,082 B1
`Nov. 19, 2002
`
`(10) Patent No.:
`(45) Date of Patent:
`
`(54)
`
`IN-VEHICLE NETWORK MANAGEMENT
`USING VIRTUAL NETWORKS
`
`(75)
`
`Inventors: Arnold W. Millsap, Leonard; Thomas
`Michael Forest, Southfield, both of MI
`(US); Peter H. G. Hansson, Grastorp
`(SE); Anthony Anderson, Warren;
`G eorge D Nakis, Holly, both of Ml
`(US)
`
`(73) Assignee: General Motors Corporation, Detroit,
`MI (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of tbis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) AppL No.: 09/578,213
`
`May 24, 2000
`
`(22) Filed:
`Int. CJ.7
`.......... ... ... ... .... .. ...... ...... ...... .... . B60R 22/00
`(51)
`(52) U.S. Cl. ............................. 701/48; 701133; 701136;
`701!49
`(58) Field of Seat·ch ................................ 701/36, 48, 1;
`340/438, 439, 825.22, 825.16, 825.06, 458,
`462; 709/221, 224, 233, 245, 100, 106,
`200, 201; 710/107, 110; 307/10.1, 9.1;
`370/241, 242, 245, 254, 257; 702/182,
`183
`
`(56)
`
`References C ited
`
`U.S. PATENT DOCUMENTS
`
`4,715,031 A * 12/1987 Crawford et at. .. ... ...... 370/462
`4,825,362 A * 4/1989 Minami et al. .... ... ...... 700/233
`4,924,391 A * 5/1990 Hirano et al . ................. 701/33
`5,046,041 A * 9/1991 Lecocq et al. .. ...... ...... .. 710/42
`5,132,905 A * 711992 Takai et al .................... 701/33
`5,467,272 A * 11/1995 Yoshida et al. ................ 701/1
`5,483,230 A * 1/1996 Mueller ................. 340/825.06
`5,486,817 A • 1/1996 lna ........................ 340/825.16
`5,588,123 A * 12/1996 Loibl
`......................... 710/107
`5,594,646 A * 1/1997 !lob et al ...................... 701/35
`
`5,659;702 A * 8/1997 Hashimoto et al. ......... 700/245
`• 11/1998 Yoshida et al. ............... 701/29
`5,832,397 A
`3/1999 Funtta ................ ...... ..... 701/1
`5,890,078 A
`• 4.12000 Iihoshi et al. ................. 701/36
`6,052,632 A
`• 6!2000 Abe et at. ................... 340/438
`6,075,438 A
`
`FOREIGN PATENT DOCUMENTS
`
`DE
`JP
`
`19515194 A1 • 4/1996
`2000006738 A
`• 1/2000
`
`........... B60R!16/02
`........... B60R/ 16/02
`
`* cited by examiner
`
`Primary Examiner- Jacques H. Louis-Jacques
`(74) Attorney, Agellf, or Firm-Kathryn A. Marra
`
`(57)
`
`ABSTRACT
`
`A network mam1gemenl approach for use in a vehicle lo
`control activation of electronic control units (ECUs) net(cid:173)
`worked together throughout the vehicle. The ECUs are
`grouped together by function into virtual networks, with
`each virtual network including those ECUs used in carrying
`out a particular control task, such as controlling power
`windows or automatic headlights. The virtual networks are
`activated using a messaging protocol that specifies which
`virtual network is being activated. Periodic messages speci(cid:173)
`fying the virtual network are also used to maintain it active.
`T his permits the ECUs to be maintained in a low power
`quiescent state when the control functions are not needed,
`while allowing only those needed for a particular control
`task to be awakened and maintained in an activated state to
`carry out their associated control task. An ECU can activate
`one of the virtual networks by transmitting a wake-up signal
`followed by a message identifying the virtual network. Each
`of the ECUs receive this message and, if it is a member of
`the virtual network being initialized, maintains itself in an
`active state to carry out the control task associated with the
`virtual network. The other ECUs return to the quiescent
`state. Using this approach, an ECU is able to activate only
`the nece~'>ary ECUs for a particular control task without
`having to know which or how many ECUs are involved in
`performing the task.
`
`34 C laims, 6 Drawing S heets
`
`Wtual Nelwo<l<s:
`§ Powe< Window$ 22
`~ Hooted Seat 23
`~ Power Mirrors 24
`
`PAGE 1 OF 18
`
`BMW EXHIBIT 1015
`
`

`

`,--1o
`
`d .
`00 .
`
`RFM
`RF Mirror
`
`f---+ Mirror
`Motor
`
`RFWI---+ Window
`RF Window
`Motor
`.___ _____ _j~ Window
`Switch
`
`RRW ~Window
`RR Window
`Motor
`......._ _____ ____J~ Window
`Switch
`
`15 \
`Mirror .--.r-------1...---~
`LF Mirror LFZ
`Motor
`LF Window
`Window._.
`Motor
`......._ _____ _ _j
`
`4 Window
`Switches,~ ... ------~
`Windows ocP
`Heated Seat
`Mirrors
`'-----r..------=---_j
`" 14
`
`Heated
`Seat Switch____,
`2 Mirror /
`Switches
`
`16-.......
`r-------1. \ ___ __,
`Window
`Motor ._.
`LR Window LRw...,__.
`W indow -----.
`Switch
`.____ ______ _j
`
`PAGE 2 OF 18
`
`.
`DHS
`D
`nver's Seat
`
`H !.
`
`eat1ng
`Coil
`
`Fig. 1
`
`

`

`,_-10
`
`12
`
`18
`
`19
`
`DHS
`
`Heating
`Coil
`
`Fig. 2
`
`. rJ). .
`
`Mirror
`Motor
`
`Window
`Motor
`Window
`Switch
`
`Window
`Motor
`Window
`Switch
`
`15
`
`LF Mirror
`LF Window
`
`Mirror
`Motor
`
`Window
`Motor
`
`4 Window
`Switches
`
`Heated
`Seat Switch
`2 Mirror
`Switches
`
`16
`
`g LR Windows~ ....
`
`LRW
`
`Window
`Motor
`Window
`Switch
`
`Virtual Networks:
`§ Power Windows 22
`~ Heated Seat 23
`~ Power Mirrors 24
`
`PAGE3 OF 18
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 3 of 6
`
`US 6,484,082 Bl
`
`Receive Control
`Task Request
`
`Wake-up ECUs
`on Vehicle Bus
`
`30
`
`32
`
`Send Virtual Network
`Message (VNM)
`
`34
`
`Reset & Start Timer
`
`36
`
`End
`
`No
`
`Yes
`
`Send Follow-up VNM
`
`42
`
`Fig. 3
`
`PAGE40F18
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 4 of 6
`
`US 6,484,082 Bl
`
`Receive Wake-up
`Request
`
`50
`
`54
`
`>-~
`
`Switch from Quiescent
`State to Active State
`
`56
`
`No
`
`No
`
`Begin Performing
`Control Task
`
`72
`
`Reset & Start Timer
`
`66
`
`Return to
`Quiescent State
`
`64
`
`Continue in
`Active State
`
`Fig. 4
`
`PAGE50F18
`
`

`

`8o,
`
`_,--82
`
`Frame 10
`
`I
`
`~ 84
`
`I
`
`Byte 0
`
`Constant ECUID
`"11000"
`b10- b6
`
`b5- bO
`
`Unused and
`Reserved
`b?- b1
`
`Initialize/
`Continue Flag
`bO
`
`Byte 1 - Byte 7
`
`~ 86
`
`7
`
`Virtual Network ID Bits
`
`d •
`rJj
`•
`
`96
`
`Fig. 5
`
`98
`
`Fig. 6
`
`BCM
`
`100
`
`PAGE 6 OF 18
`
`('j
`rJJ
`~
`).
`QO
`
`.&;.. = QO
`
`N
`~
`~
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 6 of 6
`
`US 6,484,082 Bl
`
`Fig. 7
`
`118
`
`Remote
`Network
`
`Other On-Board
`Network
`
`134
`
`132
`
`Fig. 8
`
`Network
`130 Management
`
`Transport
`Node
`Layer Management
`Data Link Layer
`Physical Layer: Communications
`Hardware
`
`122
`
`126
`
`Vehicle Bus
`
`12
`
`Application B
`
`r- G1
`Gateway
`
`Application A
`
`Communication Kernel
`
`140_.) l
`-
`Sub NetA
`
`,_.}
`110
`
`PAGE 7 OF 18
`
`Kernel
`140_;
`
`1
`
`Comm. I Comm.
`I \._ 142
`\._ 112
`Fig. 9
`
`Kernel
`
`Communication Kernel
`
`I
`
`'- 142
`
`
`
`S b-Net B u
`
`

`

`US 6,484,082 Bl
`
`1
`IN-VEHICLE NETWORK MANAGEMENT
`USING VIRTUAL NETWORKS
`
`TECHNICAL FIELD
`
`The present invention relates to networks used in vehicles
`to provide distributed control of various vehicle functions
`and, more particularly, to such networks which utilize dif(cid:173)
`ferent groupings of electronic control units (ECUs) to carry
`out different control tasks.
`
`BACKGROUND OF THE INVENTION
`
`2
`"on-demand" start-up operations. This severely reduces
`their effectiveness because the start-up process must be done
`quickly enough to keep the occupant from detecting delays
`following a button press that requires the ECUs to perform
`control operations. If this cannot be done, then the only other
`option is to keep the ECUs awake any time that an occupant
`may want to use their functionality.
`The electrical power consumption in contemporary
`vehicles is approaching the limits for what can be economi-
`10 cally provided by the existing vehicle electrical infrastruc(cid:173)
`ture. One method for reducing the consumption is to place
`ECUs that are not actively controlling vehicle functionality
`into a low power "standby", or "sleep" state. For example,
`window and seat control ECUs are used infrequently and
`can usually be placed in standby. From a network manage(cid:173)
`ment perspective, vehicle systems with ECUs in standby
`introduce considerable complexity. In these systems, it is
`desirable to synchronize start up and shut down of arbitrary
`subsets of the vehicle's ECU population while letting other
`20 ECUs "sleep". Furthermore, a robust network design should
`be able to start ECU sets on demand without disrupting the
`control operations being performed by the ECUs which are
`already awake. Lastly, in order for an ECU to be used in
`multiple vehicle platforms, the ECU should be able to start
`25 up its signal providers even though the signals may be
`provided by different ECUs on each platform.
`It is therefore a general object of this invention to provide
`an on-board vehicle network which utilizes a network man(cid:173)
`agement strategy that permits distributed ECUs on the
`network to activate other ECUs in a platform-independent
`manner using a common communication strategy which
`permits the ECUs to be maintained in a low power quiescent
`mode until needed.
`
`In contemporary vehicles, electronic control units (ECUs)
`are distributed throughout the vehicle to perform a variety of
`different vehicle functions. These vehicle functions can be 15
`operator-controlled or automated and are referred to herein
`generally as control tasks. These control tasks can include,
`for example, controlling vehicle door locks, seat position,
`cruise control, entertainment system devices (tuners, CD
`players, etc.), HVAC, intrusion alarms, interior and exterior
`lighting, electric window position, engine and vehicle sys(cid:173)
`tem diagnostics, and, more recently, tasks such as seat
`heating and reverse sensing.
`A common misconception is that each of the ECUs used
`in the vehicle is dedicated to a specific task. While some
`ECUs, including powertrain control modules and anti-lock
`brake system controllers, tend to be dedicated to a single
`control task, this is generally not the case for most other
`ECUs. Many control tasks are performed by several ECUs 30
`working in unison and coordinating their operation via a
`data link. A typical ECU may contain a portion of the control
`logic for several unrelated vehicle control tasks, and may not
`contain the complete control logic for any single control
`task.
`The ECUs are typically connected together via one or
`more vehicle buses, which are generally implemented as
`serial communication buses in the form of a local area
`network. In addition to the basic mechanisms for transfer(cid:173)
`ring signals between ECUs over the vehicle bus, any reliable
`communication strategy must also ensure that a number of
`other ancillary tasks are performed. One of these tasks is
`called network management and is used to provide a system(cid:173)
`wide common approach to handling such things as: orderly
`start up (activation) of communication capabilities; orderly
`shut down (deactivation) of communication capabilities; and
`predictable recovery from detectable communication errors.
`Mechanisms to perform orderly start up and shut down
`are important so that ECUs can synchronize their signal
`reception expectations with the other ECUs signal transmis(cid:173)
`sion availability. If this synchronization does not occur, an
`ECU may interpret the lack of signal transmissions as the
`failure of one of the other ECUs and adopt safe default
`signal values that may be perceived by the occupant as
`improper vehicle operation. For example, headlights may 55
`default "on" if the day /night sensor signal is not transmitted
`in a timely manner.
`Existing vehicle network management strategies are rela(cid:173)
`tively simple. This simplicity stems from the fact that all
`ECUs in a vehicle are activated and deactivated simulta- 60
`neously. As a result, the only complicating factor is that
`some ECUs may activate slower than others. There exists
`vehicle network schemes which permit an ECU to activate
`other ECUs, but not in a manner that is independent of
`vehicle platform and that allows multiple ECUs to activate
`the same collection of ECUs. Furthermore, they are not as
`responsive in the manner in which they perform their
`
`35
`
`SUMMARY OF THE INVENTION
`
`The present invention provides an on-board vehicle net(cid:173)
`work and method for operating the network which permits
`an ECU to activate the other ECUs used for a particular
`40 vehicle control task without having to know in advance what
`ECUs are utilized in performing the control task. The
`network comprises a plurality of on-board vehicle electronic
`control units (ECUs) connected together via at least one
`network bus, with the network being arranged into a plu-
`45 rality of virtual networks that each comprise a group of the
`ECUs that together perform a vehicle control task. Thus, the
`ECUs that together comprise a first one of the virtual
`networks are operable together to perform a first control task
`and are each identified using a first code that is associated
`50 with the first virtual network. Similarly, the ECUs that
`comprise the second virtual network are operable together to
`perform a second control task and are each identified using
`a second code that is associated with the second virtual
`network. The first and second virtual networks can be
`activated using respective first and second messages that
`they receive over the vehicle 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 a part of the virtual network used to implement a
`particular control task.
`In accordance with another aspect of the invention, there
`65 is provided a method of managing an on-board vehicle
`network that utilize ECUs that can be switched between and
`active state and a low power quiescent state. The network
`
`PAGE 8 OF 18
`
`

`

`US 6,484,082 Bl
`
`3
`includes at least one group or subset of the ECUs on the
`network, with the group of ECUs being operable together to
`perform a particular vehicle control task. The method
`includes the steps of: receiving a signal request for activat(cid:173)
`ing 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
`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 10
`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.
`'
`If necessary, the messages to the ECUs can be preceded
`by a wake-up signal which switches all of the quiescent
`ECUs to the active state. Once the ECUs are awakened, they
`each monitor the network for receipt of a message contain(cid:173)
`ing a code associated with one of the control tasks for which 20
`they are used. If no code is received within a period of time
`following the wake-up signal, they switch back to their low
`power quiescent state. If a code is received, then each ECU
`checks to see whether it is associated with the received code·
`if so, it enters into a program mode in which it operates with 25
`the other appropriate ECUs to carry out the associated
`control task. If not, the ECU switches back to the quiescent
`state. In this way, any ECU on the network can be used to
`activate other ECUs associated with a particular control task,
`and can do so without having to know which or how many 30
`other ECUs are involved. This permits system designs in
`which a particular ECU can be used on different vehicle
`platforms, even if the function is performed differently on
`each platform.
`
`15
`
`4
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`Referring first to FIG. 1, there is shown an on-board
`vehicle network 10 of the present invention. As in a con(cid:173)
`ventional network design, the network 10 includes a number
`of electronic control units (ECUs) connected to each other
`by way of an in-vehicle network bus 12, which can be a
`serial communication bus or other suitable datalink. In
`particular, the illustrated network 10 includes a total of seven
`ECUs which support the following control tasks:
`1. power windows-a given vehicle door window can be
`el~ctrically operated by a switch at the door, and the
`dnver can operate any of the (four) power windows
`from a cluster of switches at the driver's door;
`2. heated driver's seat-the heating coil in the driver's
`seat can be turned on or off from a switch on the
`driver's switch cluster;
`3. power mirrors--either of the two vehicle side mirrors
`can be moved by the driver using switches in the
`driver's switch cluster.
`Neither the individual vehicle systems nor their sensors and
`actuators are illustrated; however, the design of such sys(cid:173)
`tems and integration with the distributed ECUs is well
`within the level of skill in the art. Also, it will be appreciated
`that the illustrated network is just a fragment of a typical
`on-board vehicle network and is shown for the purposes of
`illustrating the construction and operation of the present
`invention. Numerous other ECUs and control tasks could
`and normally would be included in the network shown in
`FIG. 1.
`As depicted in FIG. 1, the network 10 includes the
`following ECUs. A driver's control panel (DCP) ECU 14 is
`used to manage the driver's switch bank that includes
`window, mirror and heated seat switches. A left front zone
`35 (LFZ) ECU 15 is used to manage the left front window and
`mirror motors. The remaining five modules are each dedi(cid:173)
`cated to a single task. In particular, the left rear window
`(LRW) ECU 16, right rear window (RRW) ECU 17, and
`right front window (RFW) ECU 18 manage their corre-
`40 sponding window switches and motors. The driver's heated
`seat (DHS) ECU 19 manages the seat heating coil and the
`right front mirror (RFM) ECU 20 manages the correspond(cid:173)
`ing mirror motor.
`The following table lists the different ECUs and their
`45 associated vehicle functions (control tasks). As noted above,
`some of the ECUs are used to carry out more than one
`control task, whereas others are dedicated to a single task.
`Thus, for example, the driver control panel (DCP) ECU is
`used in performing all three control tasks, whereas the
`50 driver's heated seat (DHS) ECU is dedicated to warming of
`the driver's seat and does not play a role in any other vehicle
`function.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`Preferred exemplary embodiments of the present inven(cid:173)
`tion will hereinafter be described in conjunction with the
`appended drawings, wherein like designations denote like
`elements, and:
`FIG. 1 is a block diagram showing the physical layout of
`a first exemplary on-board vehicle network of the present
`invention;
`FIG. 2 is a block diagram of the network of FIG. 1
`showing it organized into three virtual networks according
`to a preferred embodiment of the invention;
`FIG. 3 is a flow chart showing the process carried out by
`an ECU to activate one of the virtual networks and maintain
`it active until its associated control task is complete;
`FIG. 4 is a flow chart showing the process carried out by
`each of the ECUs on the vehicle bus when one of the virtual
`networks is activated by another ECU on the bus;
`FIG. 5 depicts the layout of the messages used to activate
`the virtual networks of FIG. 2;
`FIG. 6 is a block diagram showing a second exemplary
`on-board vehicle network of the present invention organized
`into three virtual networks;
`FIG. 7 is a block diagram showing the use of gateways to
`provide communication access from the network of FIG. 2
`to other on-board and remote networks;
`FIG. 8 is a conceptual model of a communication kernel
`used by an ECU to communicate over the network of FIG.
`1; and
`FIG. 9 is an overview block diagram showing how the 65
`gateways of FIG. 6 are used to provide communication
`between ECUs on different networks.
`
`55
`
`60
`
`Control Task
`
`ECU
`
`Power Windows
`
`Heated Seat
`
`Power Mirrors
`
`LFZ
`DCP
`DHS
`LRW
`RRW
`RFW
`RFM
`
`,/
`,/
`
`,/
`,/
`,/
`
`,/
`,/
`
`,/
`,/
`
`,/
`
`In accordance with one aspect of the invention, the
`illustrated ECUs 14-20 on network 10 are separated into
`
`PAGE 9 OF 18
`
`

`

`US 6,484,082 Bl
`
`5
`three virtual networks---{)ne for each of the three control
`tasks noted above. Thus, as shown in FIG. 2, the seven
`ECUs can be separated into a power windows virtual
`network 22, a heated seat virtual network 23, and a power
`mirrors virtual network 24. The window virtual network 22
`includes the driver control panel ECU 14 as well as the four
`ECUs 15-18 used to control the motors for the four win(cid:173)
`dows. The heated driver's seat virtual network 23 includes
`the driver control panel ECU 15 and driver's heated seat
`ECU 19. The power mirrors virtual network 24 includes the
`left front zone ECU 14, the driver control panel ECU 15, and
`the right front mirror ECU 20. A primary advantage of the
`separation of the network into these virtual networks accord(cid:173)
`ing to the various control tasks is that the ECUs on the
`vehicle bus 12 can be maintained in a low power quiescent
`state when not in use and then only those ECUs needed for
`a particular control task need be woken up and maintained
`in an activated state.
`For example, moving the left mirror requires communi(cid:173)
`cation between the driver control panel and left front zone 20
`ECUs because the mirror control switch is connected to the
`driver control panel ECU 14 while the left mirror motor is
`controlled by the left front zone ECU 15. Thus, a switch
`activation from the driver to move the left mirror is detected
`by driver control panel ECU 14, which activates the power
`mirror virtual network 24. This activation includes waking
`up the ECUs from their standby state (assuming some or all
`of them are not already awake and performing some other
`function) and then executing the appropriate control logic to
`perform the function. This control logic can be programmed
`into the various ECUs so that they communicate together
`properly to implement the particular control task-in this
`case, movement of the left mirror.
`As another example, the control input for the driver's
`heated seat is to an ECU (the driver control panel ECU 14)
`that is different than the ECU used to activate the seat
`warmer (the driver's heated seat ECU 19). Thus, the heated
`seat virtual network 23 is activated whenever the appropriate
`switch on the driver's control panel is selected. The activa(cid:173)
`tion of a virtual network to perform a particular control task
`need not originate from one of the ECUs 14-20; rather, they
`can come from another source such as another ECU on the
`vehicle bus 12. An example of this is the use of yet another
`ECU (not shown) which is connected to receive inputs from
`the ignition system so that, upon detecting a personalized
`key unique to the driver, a signal is sent by this other ECU
`to ECUs 14, 15, and 20 to activate the mirror virtual network
`and move the mirrors to a preset position that has previously
`been stored in memory for this particular driver. In this
`example, the extra ECU would be included in the mirror
`virtual network 24. Similarly, activation of this virtual
`network to move the side mirrors to a preset position could
`come from yet another ECU not shown) that is part of a
`remote communication system that receives signals from a
`key fob or other remote transmitter.
`In the network shown in FIG. 2, each of the three virtual
`networks is activated anytime one of its associated switch
`inputs is selected. Thus, for example, when the right front
`window switch is depressed, the window virtual network 22
`is activated via the ECU 18 which senses the keypress.
`However, not all functions performed by a member of a
`virtual network require activating the virtual network. For
`example, the right front window ECU 18, although a part of
`the window virtual network 22 that includes five of the
`ECUs, may be implemented in a manner that does not 65
`require any network communication when the front right
`door window switch is activated, since both that switch and
`
`6
`the associated right front window motor are controlled by
`the same ECU. Conversely, where the driver control panel
`(DCP) switch for the right front door window is depressed
`by the driver, different ECUs are used for detecting the
`switch event and activating the window motor. Accordingly,
`the window virtual network is activated, including both
`those ECUs used to accomplish the right front window
`control function and those ECUs in the virtual network (such
`as the left and right rear window ECUs) that are not involved
`10 in the particular window activation.
`A significant advantage of this use of virtual networks is
`that the network management strategy permits the activation
`of the necessary ECUs to perform a control task without the
`various ECUs involved having to know which or how many
`15 other ECUs are required for the particular task. This permits
`the many control tasks to be implemented using multiple
`ECUs in a modular, distributed manner while allowing a
`greater degree of independence of the control logic for a
`particular ECU between different vehicle platforms. This
`aspect of the invention is discussed next.
`The network management of the virtual networks 22-24
`uses a messaging protocol over the vehicle bus 12 that
`permits all ECUs within a particular virtual network to be
`activated and maintained in an operational state until the
`25 associated control task is complete. The activation of the
`ECUs within a virtual network is typically initiated by one
`of the ECUs in the virtual network, although other triggers
`and sources can be used.
`A preferred method of activating one of the virtual
`30 networks is shown generally in FIG. 3 and the processing of
`wake-ups and messages relating to the virtual networks is
`shown in FIG. 4. In general, activation of a virtual network
`involves waking up the ECUs on the vehicle bus in response
`to a control task request (such as a button activation by the
`35 driver), sending a message over the bus to activate the
`virtual network associated with that control task, and then
`sending periodic messages to keep the ECUs in the virtual
`network active until the control task is complete.
`More specifically, as indicated at block 30 of FIG. 3, the
`40 process begins upon receipt of a signal request to activate a
`control task. This signal request can originate from a switch
`activated by the driver or other vehicle occupant, or can be
`automatically generated either by a sensor or as the result of
`some vehicle software process. This request is received by
`45 one of the ECUs which responds at block 32 by sending a
`wake-up signal over the vehicle bus to the other ECUs. This
`wake-up signal can be a high-voltage wake-up as defined in
`SAE 12411 "Single Wire CAN Network for Vehicle
`Applications-Recommended Practice." The ECU that
`50 transmits the wake-up is considered the master ECU for this
`control event and is responsible for activating the virtual
`network associated with the requested control task. In this
`regard, different ECUs can simultaneously be the master for
`different, concurrent control tasks and a single ECU can be
`55 a master for more than one concurrent control task. For
`example, if the seat heater switch on the driver control panel
`is selected, the heated seat virtual network 23 is activated,
`with ECU 14 being the master. If, while the seat heating
`process is being carried out, the driver selects the front right
`60 door window switch, the window virtual network 22 is
`activated with ECU 18 being the master and the other ECUs
`on that virtual network being the slaves. Thus, ECU 14
`would simultaneously be a master for purposes of the seat
`heating virtual network 23 and a slave for purposes of the
`window virtual network 22.
`Returning back to the wake-up signal transmitted at block
`32, those ECUs in the low power quiescent state respond to
`
`PAGE 10 OF 18
`
`

`

`US 6,484,082 Bl
`
`7
`this wake-up signal by switching into an active state in
`which they begin monitoring the vehicle bus for messages,
`as will be described below in connection with FIG. 4. Next,
`the master ECU broadcasts a virtual network message
`(VNM) over the vehicle bus 12, as indicated at block 34.
`This VNM is used to identify the virtual network to be
`activated and, thus, the ECUs that should stay in the acti(cid:173)
`vated state to carry out the control task. All other ECUs not
`performing some other control task return to their sleep
`state. The master ECU then starts a countdown timer that can
`be set to, for example, three seconds. This is shown at block
`36. Then, at block 38, a check is made to determine if the
`control task has been completed. If not, the process moves
`to block 40 where the timer is checked. If it has not yet
`expired, then the process returns to block 38 to again check 15
`whether the control task is complete. If the timer has
`expired, then the process moves to block 42 where a
`continuing, or follow-up, VNM is sent over the vehicle bus
`to indicate to the other ECUs in the virtual network that they
`should continue in the active state to continue performing 20
`the control task. The process flow then returns to block 36
`to reset the timer and begin another iteration of this latter
`part of the process. Once the control task is complete, as
`determined at block 38, no more VNMs are sent in support
`of this virtual network and the process ends for this control 25
`task.
`As will be appreciated, the timer is used to send periodic
`follow-up VNMs that notify other ECUs in the virtual
`network that the control task is not yet complete and that
`they should therefore remain in the active state to carry out
`their portion, if any, of the control task logic.
`The process of FIG. 3 is that carried out by a master ECU
`to control the activation of one of the virtual networks.
`Turning now to FIG. 4, there is shown the process used by
`a slave ECU when a wake-up signal and VNM is received.
`Each of the ECUs is either operating in its quiescent state to
`conserve power or its active state in support of a control task.
`As indicated at locks 50, 52, and 54, upon receipt of a
`wake-up signal over the vehicle bus from a master ECU,
`each ECU on the vehicle bus is switched into its active state 40
`if not already operating in that state. Then, a count-down
`timer is started, as indicated at block 56. The purpose of this
`timer is to provide an eight second period of time during
`which the ECU monitors the bus for a VNM indicating
`which virtual network should be initiated. Note that this
`period of time is selected to be longer than the three second
`repeat rate of the timer used in FIG. 3 so that this timer
`should not expire as long as follow-up VNMs are being sent.
`Once the timer begins, a check is made at block 58 for
`receipt of a VNM. If no such message has been received, the
`process moves to block 60 where a check of the timer is
`made to determine if it has expired. If not, the process flow
`moves back to block 58 to again check for a VNM. The
`process of blocks 58 and 60 continue until either a VNM is
`received or the timer times out. If, at block 60, the timer does
`expire, a check is made to determine whether the ECU is
`performing any other task for which it should stay awake.
`This is shown at block 62. If other operations are being
`performed by the ECU, then the ECU is continued in its
`active state to carry out those other operations, as indicated
`at block 64. If no such tasks are being carried out, then the
`process flow instead moves to block 66 where the ECU is
`returned to its low power quiescent state.
`If, at block 58, a VNM is received, then a check is made
`at block 68 to determine whether the virtual network iden(cid:173)
`tified in the message is one in which the ECU is a part. As
`will be discussed below in connection with FIG. 5, this
`
`8
`identification can be accomplished using a code within the
`message that is unique to the virtual network. If the ECU is
`not part of the virtual network identified by the code, then
`the process moves back to block 60 to check the eight
`second timer and either continue monitoring for additional
`VNMs at block 58 or exit out of the loop by way of block
`62, as appropriate. If the ECU is within the identified virtual
`network, then the process moves to block 70 whe