(12)
`
`United States Patent
`Preston et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,146.260 B2
`Dec. 5, 2006
`
`USOO7146260B2
`
`(54) METHOD AND APPARATUS FOR DYNAMIC
`CONFIGURATION OF MULTIPROCESSOR
`SYSTEM
`(75) Inventors: Dan Alan Preston, Bainbridge Island,
`WA (US); Robert Pierce Lutter,
`Tacoma, WA (US)
`(73) Assignee: Medius, Inc., Bainbridge Island, WA
`(US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 835 days.
`
`(21) Appl. No.: 09/841,915
`
`(22) Filed:
`
`Apr. 24, 2001
`O
`O
`Prior Publication Data
`US 20O2/O154605 A1
`Oct. 24, 2002
`
`(65)
`
`(51) Int. Cl.
`(2006.01)
`GOIC 22/00
`(2006.01)
`G05B 23/02
`(52) U.S. Cl. .......................................... 701/24; 340/3.1
`(58) Field of Classification Search ..................... None
`See application file for complete search history.
`References Cited
`
`(56)
`
`WO
`WO
`WO
`WO
`
`WO99,57662
`WO99,651.83
`WOO1/30061
`WOO1,58110
`
`11, 1999
`12/1999
`4/2001
`8, 2001
`
`OTHER PUBLICATIONS
`
`Product description of Raytheon RT Secure, "Embedded Hard
`Real-Time Secure Operating System”. Copyright 2000, pp. 1-2.
`Product description of Raytheon RT Secure, Copyright 2001, pp.
`1-2.
`Product description of Raytheon RT Secure, “Development Envi
`ronment”. Copyright 2001, pp. 1-2.
`Product description of Raytheon Electronic Systems (ES), Copy
`right 2002, pp. 1-2.
`H. Chung, L. Ojeda, and J. Borenstein, “Sensor Fusion for Mobile
`Robot Dead-reckoning with a Precision-calibrated Fiber Optic
`Gyroscope', 2001 IEEE International Conference on Robotics and
`Automation, Seoul, Korea, May 21-26, pp. 1-6.
`Continued
`(Continued)
`Primary Examiner Duc Ho
`Assistant Examiner Phuongchau Ba Nguyen
`(74) Attorney, Agent, or Firm Marger Johnson &
`McCollom, P.C.
`(57)
`
`ABSTRACT
`
`J. W. J.
`
`a C a
`
`- - - -
`
`
`
`U.S. PATENT DOCUMENTS
`A multiprocessor system used in a car, home, or office
`environment includes multiple processors that run different
`... TO1.59
`4,829.434 A *
`5/1989 Karmel et al. ..
`real-time applications. A dynamic configuration system runs
`5,581.462 A * 12/1996 Rogers .......................... TO1/3
`2. : 3.S. SR
`- - - SC on the multiple processors and includes a device manager,
`6,181,994 B1
`1/2001 Colson et al. ................ TO1/33
`agittag, d
`g T
`s
`6,182,006 B1
`1/2001 Meek ......................... too
`ager automatically detects and adds new devices to une
`6,243,450 B1
`6/2001 Jansen et al.
`multiprocessor system, and the configuration manager auto
`6,505,100 B1* 1/2003 Stuempfleet al. ............. 70 1/1
`matically reconfigures which processors run the real-time
`6,622,083 B1* 9/2003 Knockeart et al. .......... 701/202
`applications. The data manager identifies the type of data
`generated by the new devices and identifies which devices in
`the multiprocessor System are able to process the data.
`
`FOREIGN PATENT DOCUMENTS
`WO96/24229
`8, 1996
`WO99,08436
`2, 1999
`
`WO
`WO
`
`12 Claims, 12 Drawing Sheets
`
`S8
`y
`<>))
`20
`
`S4
`
`22
`
`A
`ENGINE
`- Mor
`
`24-
`
`Dc
`
`8
`
`10
`
`-
`12
`DISPLAY-16 'E'
`security
`oc
`SECURITY
`28
`D
`
`10
`INTERFACE
`is
`
`O
`
`SO
`
`AHM, Exh. 1012, p. 1
`
`

`

`US 7,146.260 B2
`Page 2
`
`OTHER PUBLICATIONS
`A. Das, R. Fierro, V. Kumar, J. Ostrowski, J. Spletzer, and C. Taylor,
`“A Framework for Vision Based Formation Control', IEEE Trans
`actions on Robotics and Automation, vol. XX, No. Y. 2001, pp.
`1-13.
`J. Takezaki, N. Ueki, T. Minowa, H. Kondoh, “Support System for
`Safe Driving—A Step Toward ITS Autonomous Driving '.
`Hitachi Review, vol. 49, No. 3, 2000, pp. 1-8.
`S.G. Goodridge, “Multimedia Sensor Fusion for Intelligent Camera
`Control and Human-Computer Interaction”. Dissertation submitted
`to the Graduate Faculty of North Carolina State University in partial
`fulfillment of the requirements for the degree of Doctor of Philoso
`phy in Electrical Engineering, Raleigh, NC, 1997, pp. 1-5.
`M. Chantler, G. Russel, and R. Dunbar, “Probabilistic Sensor Fusion
`for Reliable Workspace Sensing', pp. 1-14.
`ISIS Project: Sensor Fusion, Linkoping University Division of
`Automatic Control and Communication Systems in cooperation
`with SAAB (Dynamics and Aircraft), 18 pages.
`Hitachi Automated Highway System (AHS), Automotive Products,
`Hitachi, Ltd., Copyright 1994-2002, 8 pages.
`Vehicle Dynamics Lab, University of California, Berkeley, funded
`by BMW, current members: D. Caveney and B. Feldman, "Adaptive
`Cruise Control', 17 pages.
`Counterair: The Cutting Edge, Ch. 2 “The Evolutionary Trajectory
`The Fighter Pilot-Here to Stay?” AF2025 v3c8-2, Dec. 1996, pp.
`1-7.
`
`Counterair: The Cutting Edge, Ch. 4 “The Virtual Trajectory Air
`Superiority without an “Air Force?” AF2025 v3c8-4, Dec. 1996,
`pp. 1-12.
`TNO FEL Annual Review 1998: Quality works, 16 pages.
`Boeing News Release, “Boeing Demonstrates JSF Avionics Multi
`Sensor Fusion'. Seattle, WA. May 9, 2000, pp. 1-2.
`Boeing Statement, “Chairman and CEO Phil Condit on the JSF
`Decision', Washington, D.C., Oct. 26, 2001, pp. 1-2.
`Ada 95 Transition Support Lessons Learned, Sections 3, 4, and 5.
`CACI, Inc. -Federal, Nov. 15, 1996, 14 pages.
`Joint Strike Fighter Terrain Databaste, ets-news.com “Simulator
`Solutions' 2002, 3 pages.
`MSRC Redacted Proposal, 3.0 Architecture Development, pp. 1-43.
`Powerpoint Presentation by Robert Allen Boeing Phantom Works
`entitled “Real-Time Embedded Avionics System Security and
`COTS Operating Systems”. Open Group Real-Time Forum, Jul. 18.
`2001, 16 pages.
`Green Hills Software, Inc., “The AdaMULTI 2000 Integrated
`Development Environment”. Copyright 2002, 7 pages.
`Luttge, Karsten: “E-Charging API: Outsource Charging to a Pay
`ment Service Provider”; IEEE: 2001 (pp. 216-222).
`* cited by examiner
`
`AHM, Exh. 1012, p. 2
`
`

`

`U.S. Patent
`
`US 7,146.260 B2
`
`
`
`
`BNIS) NIE
`?JO LINO W
`
`
`AHM, Exh. 1012, p. 3
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 2 of 12
`
`US 7,146.260 B2
`
`DYNAMIC
`CONFIGURATION (DC)
`SYSTEM
`
`- - - - - - - - - - - - - - - - - - - - - - - - - - -
`
`DATA
`MANAGER
`CONFIGURATION
`MANAGER
`DEVICE
`MANAGER
`
`
`
`
`
`
`
`
`
`52
`
`SENSORS
`
`AHM, Exh. 1012, p. 4
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 3 of 12
`
`US 7,146,260 B2
`
`12
`
`86
`
`88 2.
`
`- 1
`
`44
`
`
`
`
`
`DYNAMIC
`CONFIGURATION (DC)
`SYSTEM 10
`
`DATA
`MANAGERS
`RECONFIGURATION
`MANAGER
`DEVICE
`MANAGER
`
`9 O
`
`CD
`SENSORS
`DVD
`
`GUI
`
`AHM, Exh. 1012, p. 5
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 4 of 12
`
`US 7,146,260 B2
`
`96S,NVQOL3NOO13M
`JIano0G oOv$HAOUNGE
`00°I$V¥109OS'e$3595HD
`
`
`
`
`
`
`00°1$433598100d
`
`NSNDIHO
`
`Ysa9YNg
`
`
`
`SUNIYGSSHOIMGNVS
`
`YZLN3SS3Y¥dN3HLSW3LT193735
`
`
`
`
`
`
`
`
`
`MOGNIMLXSNOLJAOWASVIId
`
`
`
`os'y$IvLOl
`
`yOld
`
`AHM, Exh. 1012, p. 6
`
`AHM, Exh. 1012, p. 6
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet S of 12
`
`US 7,146.260 B2
`
`
`
`
`
`APPLICATION i 1
`
`DEVICE MANAGER
`
`CPUB-APP #2
`-- CPU C
`CPU D-APP #4
`CPU E-NEW APP J
`- - - - - - - - - - - - - -
`
`
`
`
`
`G PROCESSOR B 46
`
`
`
`
`
`APPLICATION #2
`
`DEVICE MANAGER
`
`PROCESSOR C
`
`
`
`
`
`46
`
`DEVICE MANAGER
`
`70
`
`46
`
`PROCESSORD
`
`
`
`APPLICATION #4
`
`ETHERNET
`
`DEVICE MANAGER
`
`PROCESSOR E
`
`AHM, Exh. 1012, p. 7
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 6 of 12
`
`US 7,146.260 B2
`
`
`
`DETECT SIGNAL
`FROM NEW DEVICE
`ON COMMON LINK
`
`CHECK ENCRYPTION
`PROTOCOL FROM
`NEW DEVICE
`
`CHECK DATA CODES
`FOR NEW DEVICE
`
`CHECK ID FROM
`NEW DEVICE
`
`ADD NEW DEVICE
`TO PROCESSOR
`ARRAY
`
`DISPLAY ANY NEW
`APPLICATIONS OR
`DEVICES TO USER
`
`FIG.6
`
`AHM, Exh. 1012, p. 8
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 7 of 12
`
`US 7,146.260 B2
`
`m - - - - - - - - - - - - - - - -
`
`- - - - - -
`
`- - - -
`
`- - - - --------------------------------
`
`/1
`
`-N
`
`128
`
`MEMORY
`
`CPU A
`
`NAV 11 O
`AUDIO 112
`ABS 114
`
`DISPLAY 1 16
`
`NAV DATA 1 JO
`
`AUDIO DATA 132
`
`DOWNLOAD
`NAVIGATION CRITICAL DATA
`
`11 O
`
`44 - CONFIG. MGR.
`
`CPU B
`
`112
`
`AUDIO
`
`44- CONFIG. MGR. FAILURE
`CPU C -
`
`114
`
`ABS
`
`4. 4.
`
`CONFIG. MGR.
`
`CPU D
`
`116
`
`DISPLAY
`
`44
`
`CONFIG. MGR.
`120
`124
`
`
`
`118
`
`AUDIO
`CPU B FAILURE
`
`:
`
`:
`:
`
`:
`
`AHM, Exh. 1012, p. 9
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 8 of 12
`
`US 7,146.260 B2
`
`1 J4
`
`
`
`CRITICAL
`APPLICATION FAILURE
`
`
`
`1 J5
`
`
`
`138
`
`140
`
`
`
`
`
`
`
`
`
`
`
`
`
`PROCESSING CAPACITY y
`AVAILABLE IN
`ANOTHER PROCESSOR
`
`DOWNLOAD CRITICAL
`APPLICATION AND
`APPLICATION DATA
`TO IDENTIFIED
`PROCESSOR
`
`IDENTIFY PROCESSOR
`WITH NONCRITICAL
`APPLICATION
`
`
`
`RETURN
`
`REPLACE NONCRITICAL
`APPLICATION WITH
`CRITICAL APPLICATION
`AND CRITICAL
`APPLICATION DATA
`
`
`
`RETURN
`
`FIG.8
`
`AHM, Exh. 1012, p. 10
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 9 of 12
`
`US 7,146.260 B2
`
`8
`
`\
`
`FAILURE
`1.
`
`CPU A
`
`128
`MEMORY
`APPLICATIONS
`NAVIGATION
`FUSION
`ABS
`
`44
`
`112
`
`CPU B
`NAV
`
`NAV
`
`NAV DATA
`
`13O
`
`FUSION
`PROCESSOR -111
`
`44-N CONFIG. MGR,
`
`CONFIG. MGR. N-44
`
`CPU C
`
`14
`
`ABS
`
`44-N CONFIG. MGR.
`
`CPU D
`
`116
`
`DISPLAY
`
`44 N CONFIG. MGR.
`2O
`124
`
`
`
`12s. 8
`
`NAV
`
`GUI
`
`AHM, Exh. 1012, p. 11
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 10 of 12
`
`US 7,146.260 B2
`
`156
`
`y
`
`DIRECT OTHER
`PROCESSOR
`TO DOWNLOAD
`APPLICATION AND
`APPLICATION DATA
`
`FIG.10
`
`150
`
`DISPLAY APPLICATIONS
`TO USER
`
`152 PROCESSOR7APPLICATION
`FAILURE DETECTED
`
`154
`
`Y
`PROCESSING CAPACITY
`AVAILABLE ON
`OTHER PROCESSOR
`
`158
`
`SHOW FAILED
`PROCESSOR/APPLICATIONS
`TO USER
`
`160
`
`162
`
`164
`
`
`
`USER REO UESTS
`RECONFIG. TO RELOAD
`FAILED APPLICATION
`Y
`OTHER PROCESSORS
`RUNNING NONCRITICAL
`APPLICATIONS
`
`DISPLAY NONCRITICAL
`APPLICATIONS TO USER
`THAT CAN BE REPLACED
`
`166 NONCRITICAL APPLICATIONS
`SELECTED BY USER
`FOR CANCELLATION
`
`168
`
`
`
`
`
`
`
`CANCEL SELECTED
`NONCRITICAL APPLICATIONS
`AND DIRECT PROCESSOR
`TO DOWNLOAD FAILED
`APPLICATION AND
`APPLICATION DATA
`
`AHM, Exh. 1012, p. 12
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 11 of 12
`
`US 7,146.260 B2
`
`IDENTIFY DATA
`STANDARD ASSOCIATED
`WITH NEW APPLICATION
`
`170
`
`172
`
`174
`
`176
`
`178
`
`DATA
`MANAGER
`42
`
`
`
`R
`
`FIG.11
`
`AHM, Exh. 1012, p. 13
`
`

`

`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 12 of 12
`
`US 7,146.260 B2
`
`
`
`
`
`
`
`
`
`
`
`21 O
`
`
`
`SPEED
`CONTROL
`
`AIRBAG
`CONTROL
`
`ENGINE
`CONTROL
`
`SENSOR
`
`AUDIO
`CONTROL
`
`218
`
`222
`
`216
`
`22O
`
`FIG.13
`
`AHM, Exh. 1012, p. 14
`
`

`

`US 7,146,260 B2
`
`1.
`METHOD AND APPARATUS FOR DYNAMIC
`CONFIGURATION OF MULTIPROCESSOR
`SYSTEM
`
`BACKGROUND
`
`Cars include many different electromechanical and elec
`tronic applications. Examples include braking systems, elec
`tronic security systems, radios, Compact Disc (CD) players,
`internal and external lighting systems, temperature control
`systems, locking systems, seat adjustment systems, speed
`control systems, mirror adjustment systems, directional indi
`cators, etc. Generally the processors that control these
`different car systems do not talk to each other. For example,
`the car radio does not communicate with the car heating
`system or the car braking system. This means that each one
`of these car systems operate independently and do not talk
`to the other car systems. For example, separate processors
`and separate user interfaces are required for the car tem
`perature control system and for the car audio system. Many
`of these different car processors may be underutilized since
`they are only used intermittently.
`Even when multiple processors in the car do talk to each
`other, they are usually so tightly coupled together that it is
`impossible to change any one of these processors without
`disrupting all of the systems that are linked together. For
`example, Some cars may have a dashboard interface that
`controls both internal car temperature and a car radio. The
`car radio cannot be replaced with a different model and still
`work with the dashboard interface and the car temperature
`controller.
`Integration of new systems into a car is also limited. Car
`systems are designed and selected well before the car is ever
`built. A custom wiring harness is then designed to connect
`only those car systems selected for the car. A car owner
`cannot incorporate new systems into the existing car. For
`example, a car may not originally come with a navigation
`system. An after market navigation system from another
`manufacturer cannot be integrated into the existing car.
`Because after market devices can not be integrated into
`car control and interface systems, it is often difficult for the
`driver to try and operate these after market devices. For
`example, the car driver has to operate the after market
`navigation system from a completely new interface. Such as
`the keyboard and screen of a laptop computer. The driver
`then has to operate the laptop computer not from the front
`dashboard of the car, but from the passenger seat of the car.
`This makes many after market devices both difficult and
`dangerous to operate while driving.
`The present invention addresses this and other problems
`associated with the prior art.
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`SUMMARY OF THE INVENTION
`
`A multiprocessor System used in a car, home, or office
`environment includes multiple processors that run different
`real-time applications. A dynamic configuration system runs
`on the multiple processors and includes a device manager,
`60
`configuration manager, and data manager. The device man
`ager automatically detects and adds new devices to the
`multiprocessor system, and the configuration manager auto
`matically reconfigures which processors run the real-time
`applications. The data manager identifies the type of data
`generated by the new devices and identifies which devices in
`the multiprocessor System are able to process the data.
`
`65
`
`2
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a diagram of a car that has multiple processors
`that each run a Dynamic Configuration (DC) system.
`FIG. 2 is a detailed diagram of the dynamic configuration
`system shown in FIG. 1.
`FIGS. 3 and 4 are diagrams showing an example of how
`the DC system operates.
`FIGS. 5 and 6 are diagrams showing how a device
`manager in the DC system operates.
`FIGS. 7–10 are diagrams showing how a reconfiguration
`manager in the DC system operates.
`FIGS. 11 and 12 are diagrams showing how a data
`manager in the DC system operates.
`FIG. 13 is a diagram showing different multiprocessor
`systems that can use the DC DC system.
`
`DETAILED DESCRIPTION
`
`FIG. 1 shows a car 12 that includes a car multiprocessor
`system 8 having multiple processors 14, 16, 18 and 20. An
`engine monitor processor 14 monitors data from different
`sensors 22 and 24 in the car engine. The sensors 22 and 24
`can be any sensing device Such as sensors that monitor water
`temperature, oil temperature, fuel consumption, car speed,
`etc. A brake control processor 20 monitors and controls an
`Automatic Braking System (ABS) 28. A display processor
`16 is used to control and monitor a graphical user interface
`26. A security processor 18 monitors and controls latches
`and sensors 30 and 32 that are used in a car security system.
`The processors 14, 16, 18 and 20 all include software that
`run a Dynamic Configuration (DC) system 10 that enables
`new processors or devices to be automatically added and
`removed from the car multiprocessor system 8. The DC
`system 10 also automatically reconfigures the applications
`running on different processors according to application
`failures and other system processing requirements.
`For example, the processor 20 may currently be running
`a high priority brake control application. If the processor 20
`fails, the DC system 10 can automatically download the
`braking application to another processor in car 12. The DC
`system 10 automatically identifies another processor with
`capacity to run the braking control application currently
`running in processor 20. The DC system 10 then automati
`cally downloads a copy of the braking control application to
`the identified processor. If there is no extra reserve process
`ing resources available, the DC system 10 may replace a
`non-critical application running on another processor. For
`example, the DC system 10 may cause the display processor
`16 to terminate a current non-critical application and then
`download the brake control application along with any
`stored critical data.
`The DC system 10 also automatically incorporates new
`processors or applications into the multiprocessor system 8.
`For example, a laptop computer 38 can communicate with
`the engine monitor processor 34 through a hardwired link34
`or communicate to the display processor 16 through a
`wireless link36. The DC system 10 automatically integrates
`the laptop computer 38, or any other processor or device,
`into the multiprocessor system 8. After integrated into the
`multiprocessor System 8, not only can the laptop computer
`38 transfer data with other processors, but the laptop com
`puter may also run car applications normally run by other
`processors in car 12.
`The DC system 10 allows the car driver to manage how
`different applications are processed in the car 12. As
`described above, a car operator may have to run an after
`
`AHM, Exh. 1012, p. 15
`
`

`

`3
`market navigation system through a GPS transceiver
`attached to the laptop computer 38. The car driver has to
`place the laptop computer 38 in the passengers seat and then
`operate the laptop computer 38 while driving.
`The DC system 10 in the display computer 16 can
`automatically detect the navigation application running on
`the laptop computer 38. The display computer 16 notifies the
`car operator through the user interface 26 that the navigation
`application has been detected. The car operator can then
`control the navigation application through the user interface
`26. Since the user interface 26 is located in the dashboard of
`car 12, the car operator no longer has to take his eyes off the
`road while operating the navigation application.
`The description below gives only a few examples of the
`different processors, devices and applications that can be
`implemented using the DC system 10. Any single or mul
`tiprocessor system located either inside or outside of car 12
`can communicate and exchange data using the OC system
`10. It should also be understood that the DC system 10 can
`be used in any real-time environment such as between
`processors in different home or office appliances and differ
`ent home and office computers.
`FIG. 2 is a block diagram showing in more detail the
`Dynamic Control (DC) system 10 located in a processor 40
`that makes up part of the multiprocessor system 8 in car 12
`(FIG. 1). The DC system 10 includes a device manager 46
`that establishes communications with new devices that are to
`be incorporated into the multiprocessor System 8. A con
`figuration manager 44 in the processor 40 dynamically
`moves applications between different processors according
`to user inputs and other monitored conditions in the multi
`processor system 8. A data manager 42 identifies a type of
`data input or output by a new processor and identifies other
`processors or devices in the multiprocessor system that can
`output data from the new device or input data to the new
`device.
`In one example, sensors 52 feed sensor data to processor
`40. The sensor data may include engine-monitoring data
`Such as speed, oil temperature, water temperature, tempera
`ture inside the car cab, door open/shut conditions, etc. The
`sensors 52 are coupled to processor 40 through a link 54.
`such as a proprietary bus. A Compact Disc (CD) player 50
`is coupled to the processor 40 through another link 48, such
`as a Universal Serial Bus (USB). Graphical User Interface
`(GUI) 56 displays the data associated with sensors 52 and
`CD player 50. The GUI 56 displays the outputs from sensors
`52 using an icon 60 to identify temperature data and an icon
`62 to identify car speed. The processor displays the CD
`player 50 as icon 62.
`FIGS. 3 and 4 show an example of how two new
`applications are dynamically added to the multiprocessor
`system 8 in car 12 (FIG. 1). In FIG. 2, the DC system 10 in
`processor 40 previously detected a CD player 50 and some
`sensors 56. The CD player 50 was displayed on GUI 56 as
`icon 58 and the temperature and speed data from sensors 56
`were displayed on GUI 56 as icons 60 and 62, respectfully.
`The processor 40 is located in car 12 (FIG. 1). A passenger
`may bring a Digital Video Disc (DVD) player 86 into the car
`12. The DVD 86 sends out a wireless or wired signal 88 to
`the processor 40. For example, the DVD 86 may send out
`signals using a IEEE 802.11 wireless protocol. The proces
`sor 40 includes an IEEE 802.11 interface that reads the
`signals 88 from DVD player 86. If the 802.11 protocol is
`identified as one of the protocols used by processor 40, the
`DC system 10 incorporates the DVD player 86 into a
`processor array 57 that lists different recognized applica
`tions.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,146,260 B2
`
`10
`
`15
`
`4
`The DC system 10 then automatically displays the newly
`detected DVD player 86 on GUI 56 as icon 96. If capable,
`the car operator by selecting the icon 96 can then display a
`video stream output from the DVD player 86 over GUI 56.
`The DVD player 86 can now be controlled from the GUI 56
`on the car dashboard. This prevents the car driver from
`having to divert his eyes from the road while trying to
`operate the portable DVD player 86 from another location in
`the car, such as from the passenger seat.
`Other processors or devices can also be incorporated into
`the multiprocessor System 8 in car 12. In another example,
`the car 12 drives up to a drive-in restaurant 90. The drive-in
`90 includes a transmitter 92 that sends out a wireless Blue
`tooth signal 94. The processor 40 includes a Blue tooth
`transceiver that allows communication with transmitter 92.
`The DC system 10 recognizes the signals 94 from transmit
`ter 92 and then incorporates the drive-in 90 into the multi
`processor system 8 (FIG. 1). The DC system 10 then
`displays the drive-in 90 as icon 98 in GUI 56.
`Referring to FIG. 4, when the car operator selects the icon
`98, a menu 102 for the driver-in 90 is displayed on the GUI
`56. The car operator can then select any of the items
`displayed on the electronic menu 102. The selections made
`by the car operator are sent back to the transceiver 92 (FIG.
`3). The amount of the order is calculated and sent back to the
`processor 40 and displayed on menu 102. Other messages,
`Such as a direction for the car operator to move to the next
`window and pickup the order can also be displayed on the
`GUI 56. At the same time, the drive-in transceiver 92 (FIG.
`3) may send audio signals that are received by the processor
`40 and played out over speakers in car 12.
`FIG. 5 shows in more detail the operation of the device
`manager 46 previously shown in FIG. 2. Multiple processors
`A, B, C and D all include device managers 46. The device
`managers 46 can each identify other devices in the multi
`processor System that it communicates with. For example,
`processors A, B, C and D communicate to each other over
`one or more communication links including a Ethernet link
`64, a wireless 802.11 link 68, or a blue tooth link 70.
`Processor A includes a memory 65 that stores the other
`recognized processors B, C and D. The data managers 46
`also identify any applications that may be running on the
`identified processors. For example, memory 65 for processor
`A identifies an application #2 running on processor B, no
`applications running on processor C, and an application #4
`running on processor D.
`FIGS. 5 and 6 show how a new device is added to the
`multiprocessor system 8. Each of the existing processors A,
`B, C, and D after power-up are configured to identify a set
`or Subset of the processors in the multiprocessor System 8.
`A new device 72 is brought into the multiprocessor system
`8 either via a hardwired link or a wireless link. For example,
`the device E may send out signals over any one or more of
`a 802.11 wireless link 67, Blue tooth wireless link 71 or send
`out signals over a hardwired Ethernet link 69. Depending on
`what communication protocol is used to send signals, one or
`more of the processors A, B, C or D using a similar
`communication protocol detect the processor E in block 74
`(FIG. 6). All of the processors may be connected to the same
`fiber optic or packet switched network that is then used to
`communicate the information from processor E to the other
`processors.
`One of the device managers 46 in the multiprocessor
`system 8 checks the signals from processor E checks to
`determine if the signals are encrypted in a recognizable
`protocol in block 76. The device manager in the processor
`receiving the signals from processor E then checks for any
`
`AHM, Exh. 1012, p. 16
`
`

`

`US 7,146,260 B2
`
`10
`
`15
`
`25
`
`30
`
`35
`
`5
`data codes from the new device signals in block 76. The data
`codes identify data types used in one or more applications by
`processor E. A device ID for processor E is then determined
`from the output signals in block 80.
`If all these data parameters are verified, the device man
`agers 46 in one or more of the processors A, B, C and Dadd
`the new processor E to their processor arrays in block 82.
`For example, processor A adds processor E to the processor
`array in memory 65. After being incorporated into the
`multiprocessor system 8, the processor E or the applications
`running on the processor E may be displayed on a graphical
`user interface in block 84.
`FIG. 7 describes in further detail the operation of the
`reconfiguration manager 44 previously described in FIG. 2.
`In the car multiprocessor System 8 there are four processors
`A, B, C and D. Of course there may be more than four
`processors running at the same time in the car but only four
`are shown in FIG. 7 for illustrative purposes. The processor
`A currently is operating a navigation application 110 that
`uses a Global Positioning System (GPS) to identify car
`location. Processor B currently runs an audio application
`112 that controls a car radio and CD player. The processor
`C runs a car Automatic Braking System (ABS) application
`114 and the processor D runs a display application 116 that
`outputs information to the car operator through a GUI 118.
`The processor D displays an icon 120 on GUI 118 that
`represents the navigation system 110 running in processor A.
`An icon 124 represents the audio application running in
`processor B and an icon 122 represents the ABS application
`114 running in processor C.
`The memory 128 stores copies of the navigation applica
`tion 110, audio application 112, ABS application 114 and
`display application 116. The memory 128 can also store data
`associated with the different applications. For example,
`navigation data 130 and audio data 132 are also stored in
`memory 128. The navigation data 130 may consist of the last
`several minutes of tracking data obtained by the navigation
`application 110. The audio data 132 may include the latest
`audio tracks played by the audio application 112.
`40
`The memory 128 can be any CD, hard disk, Read Only
`Memory (ROM). Dynamic Random Access (RAM)
`memory, etc. or any combination of different memory
`devices. The memory 128 can include a central memory that
`all or some of the processors can access and may also
`include different local memories that are accessed locally by
`specific processors.
`FIG. 8 shows one example of how the configuration
`manager 44 reconfigures the multiprocessor system when a
`failure occurs in a critical application, such as a failure of the
`ABS application 114. The configuration manager 44 for one
`of the processors in the multiprocessor System 8 detects a
`critical application failure in block 134.
`One or more of the configuration managers 44 include a
`watchdog function that both monitors its own applications
`and the applications running on other processors. If an
`internal application fails, the configuration manager may
`store critical data for the failed application. The data for each
`application if stored in the memory 128 can selectively be
`encrypted so that only the car operator has the authority to
`download certain types of data. The configuration manager
`detecting the failure initiates a reboot operation for that
`particular application. The application is downloaded again
`from memory 128 and, if applicable, any stored application
`data. If the application continues to lockup, the configuration
`manager may then initiate a reconfiguration sequence that
`moves the application to another processor.
`
`50
`
`45
`
`55
`
`60
`
`65
`
`6
`Failures are identified by the watchdog functions in one
`example by periodically sending out heartbeat signals to the
`other processors. If the heartbeat from one of the processors
`is not detected for one of the processors, the configuration
`manager 44 for the processor that monitors that heartbeat
`attempts to communicate with the processor or application.
`If the application or processor with no heartbeat does not
`respond, the reconfiguration process is initiated.
`In another example, certain processors may monitor dif
`ferent applications. For example, a sensor processor may
`constantly monitor the car speed when the car operator
`presses the brake pedal. If the car speed does not slow down
`when the brake is applied, the sensor processor may check
`for a failure in either the braking application or the speed
`sensing application. If a failure is detected, the configuration
`manager initiates the reconfiguration routine.
`When reconfiguration is required, one of the reconfigu
`ration managers 44 first tries to identify a processor that has
`extra processing capacity to run the failed application in
`block 136. For example, there may be a backup processor in
`the multiprocessor system where the ABS application 114
`can be downloaded. If extra processing resources are avail
`able, the ABS application 114 is downloaded from the
`memory 128 (FIG. 7) to the backup processor in block 142.
`There may also be data associated with the failed appli
`cation that is stored in memory 128. For example, the brake
`commands for the ABS application 114 may have been
`previously identified for logging in memory 128 using a
`logging label described in co-pending application entitled:
`OPEN COMMUNICATION SYSTEM FOR REAL-TIME
`MULTIPROCESSOR APPLICATIONS, Ser. No. 09/841,
`753 filed Apr. 24, 2001 which is herein incorporated by
`reference. The logged brake commands are downloaded to
`the backup processor in block 142.
`If no backup processing resources can be identified in
`block 136, the configuration manager 44 identifies one of the
`processors in the multiprocessor system that is running a
`non-critical application. For example, the configuration
`manager 44 may identify the navigation application 110 in
`processor A as a non-critical application. The configuration
`manager 44 in block 140 automatically replaces the non
`critical navigation application 110 in processor A with the
`critical ABS application 114 in memory 128. The processor
`Athen starts running the ABS application 114.
`FIGS. 9 and 10 show an example of how the configuration
`manager 44 allows the user to control reconfiguration for
`non-critical applications. The applications currently running
`in the multiprocessor system 8 are displayed in the GUI 118
`in block 150. A failure is detected for the navigation appli
`cation 110 running in processor A in block 152. The con
`figuration manager 44 in processor A, or in one of the other
`processors B, C, or D detects the navigation failure. Alter
`natively, a fusion processor 111 is coupled to some or all of
`the processors A, B, C and D and detects the navigation
`failure.
`In block 154 the configuration manager 44 for one of the
`processors determines if there is extra capacity in one of the
`other processors for running the failed navigation applica
`tion 110. If there is another processor with extra processing
`capacity, the navigation application is downloaded from
`memory 128 to that processor with extra capacity along with
`any necessary navigation data in block 156. This reconfigu
`ration may be done automatically without any interaction
`with the car operator.
`If there is no extra processing capacity for running the
`navigation application 110, the configuration manager 44
`displays the failed processor or application to the user in
`
`AHM, Exh. 1012, p. 17
`
`

`

`US 7,146,260 B2
`
`10
`
`15
`
`7
`block 158. For example, the GUI 118 in FIG. 9 starts
`blinking the navigation icon 120 in possibly a different color
`than the audio application icon 124. A textual failure mes
`sage 125 can also be displayed on GUI 118.
`The configuration manager in block 160 waits for the car
`operator to request reconfiguration of