`
`a2) United States Patent
`US 7,146,260 B2
`(0) Patent No.:
`Dec. 5, 2006
`(45) Date of Patent:
`Preston et al.
`
`(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 ofthis
`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
`
`(65)
`
`Prior Publication Data
`
`US 2002/0154605 Al
`
`Oct. 24, 2002
`
`(51)
`
`Int. Cl.
`(2006.01)
`GOIC 22/00
`(2006.01)
`GOSB 23/02
`(52) U.S. Che ccc cseecteeeceteneeeeensees 701/24; 340/3.1
`(58) Field of Classification Search ......0.000000.. None
`See application file for complete search history.
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`.. 701/59
`...
`5/1989 Karmelet al.
`4,829,434 A *
`eeeeeeee 701/3
`5,581,462 A * 12/1996 Rogers wee
`340/3.1
`5,786,998 A *
`7/1998 Neeson et al
`701/48
`6,161,071 A * 12/2000 Shuman et al.
`6,181,994 B1*
`1/2001 Colson et al. we. 701/33
`6,182,006 BL*
`1/2001 Meek wee 701/200
`6,243,450 Bl
`6/2001 Jansen et al.
`6,505,100 B1*
`1/2003 Stuempfle et al. 0.00000... 70/1
`6,622,083 B1*
`9/2003 Knockeart et al.
`.......... 701/202
`
`
`
`FOREIGN PATENT DOCUMENTS
`
`WO
`WO
`
`WO096/24229
`W099/08436
`
`8/1996
`2/1999
`
`WO
`WO
`WO
`WO
`
`WO099/57662
`WO099/65 183
`WO01/30061
`WO01/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)
`
`Primary Examiner—Duc Ho
`Assistant Examiner—Phuongchau Ba Nguyen
`(74) Attorney, Agent, or Firm—Marger
`McCollom, P.C.
`
`Johnson &
`
`(57)
`
`ABSTRACT
`
`A multiprocessor system used in a car, home, or office
`environmentincludes multiple processors that run different
`real-time applications. A dynamic configuration system runs
`on the multiple processors and includes a device manager,
`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 andidentifies which devices in
`the multiprocessor system are able to process the data.
`
`12 Claims, 12 Drawing Sheets
`
`SySe)at N)
`fey ee|oc|C1
`
`20
`
`14
`22
`rd
`ENGINE
`L}—-
`Monitor A
`oO
`A Fe
`
`AHM, Exh. 1012, p. 1
`
`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-ComputerInteraction”, 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,
`CACTI,Inc. -Federal, Nov. 15, 1996, 14 pages.
`Joint Strike Fighter Terrain Databaste, ets-news.com “Simulator
`Solutions” 2002, 3 pages.
`MSRCRedacted Proposal, 3.0 Architecture Development, pp. 1-43.
`Powerpoint Presentation by Robert Allen—Boeing Phantom Works
`entitled “Real-Time Embedded Avionics System Security and.
`COTSOperating Systems”, Open Group Real-Time Forum,Jul. 18,
`2001, 16 pages.
`Inc., “The AdaMULTI 2000 Integrated.
`Green Hills Software,
`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
`
`AHM, Exh. 1012, p. 2
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 1 of 12
`
`US 7,146,260 B2
`
`||oa|9
`gq9Z‘AW1dSIQ
`Ol)
`{{9a|—\\
`Ce|Ly
`
`3OV4N3LNIoav2cfgLPasaava|gz|oaFO
`
`OL
`
`02
`
`Old
`
`al
`
`AHM, Exh. 1012, p. 3
`
`AHM, Exh. 1012, p. 3
`
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 2 of 12
`
`US 7,146,260 B2
`
`DYNAMIC
`CONFIGURATION (DC)
`SYSTEM
`prc ceoeee
`
`TA
`DA
`MANAGER
`
`CONFIGURATION
`MANAGER
`
`
`
`
`
`
`
`
`DEVICE
`MANAGER
`
`52
`
`Toe SENSORS
`
`AHM, Exh. 1012, p. 4
`
`AHM, Exh. 1012, p. 4
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 3 of 12
`
`US 7,146,260 B2
`
`21
`
`90
`
`oO
`
`co
`
`ao”
`N©+
`
`
`
` 50|}0zOr<<my=LezoOo
`
`OQ
`
`Oo
`
`on
`
`wr
`
`DYNAMIC
`
`Gril&<lalEO
`
`Zown
`
`DEVICE MANAGER
`
`RECONFIGURATION
`MANAGER
`
`GUI
`
`FIG.3
`
`AHM, Exh. 1012, p. 5
`
`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 5 of 12
`
`US 7,146,260 B2
`
`PROCESSOR C
`
`PROCESSOR D
`
`DEVICE MANAGER
`
`70
`
`PROCESSOR E
`
`AHM, Exh. 1012, p. 7
`
`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
`
`AHM, Exh. 1012, p. 8
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 7 of 12
`
`US 7,146,260 B2
`
`(
`PO14.~C~C~C”~C~CSO \
`
`
`
`NAV 110
`110 NAVIGATION|CRITICAL DATA
`AUDIO 112
`
`CPU A
`
`MEMORY
`
`44
`
`112
`
`44~|
`
`114
`
`{ ™\
`128
`DOWNLOAD
`
`
`
`Aupto DATA?
`
`CONFIG. MGR.
`
`CPU B
`
`AUDIO
`
`ABS 114
`
`DISPLAY 116
`
`NAV DATA 130
`
`CONFIG. MGR. rane
`
`CPU C
`
`ABS
`
`44
`
`CONFIG. MGR.
`
`CPU D
`
`116
`
`DISPLAY
`
`AUDIO
`
`44
`
`CONFIG. MGR.
`120
`124
`
`"8
`
`CPU B] FAILURE
`
`AHM, Exh. 1012, p. 9
`
`AHM, Exh. 1012, p. 9
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 8 of 12
`
`US 7,146,260 B2
`
`
`
` CRITICAL
`APPLICATION FAILURE
`
`194
`
`
`DOWNLOAD CRITICAL
`APPLICATION AND
`PROCESSING CAPACITY|y
`APPLICATION DATA
`AVAILABLE IN
`136
`TO IDENTIFIED
`ANOTHER PROCESSOR
`PROCESSOR
`
`
`
`
`
`
`RETURN
`
`
`IDENTIFY PROCESSOR
`
`WITH NONCRITICAL
`
`APPLICATION
`
`1358
`
`140
`
`
`
`REPLACE NONCRITICAL
`APPLICATION WITH
`
`
`CRITICAL APPLICATION
`
`
`AND CRITICAL
`
`
`APPLICATION DATA
`
`
`
`
`
`FIG.8
`
`RETURN
`
`AHM, Exh. 1012, p. 10
`
`AHM, Exh. 1012, p. 10
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 9 of 12
`
`US 7,146,260 B2
`
`128
`
`MEMORY
`
`APPLICATIONS
`
`NAVIGATION
`FUSION
`
`ABS
`DISPLAY
`
` FAILURE
`
`4
`
`110
`
`id
`
`CPU A
`
`NAVIGATION
`
`CPU B
`
`NAV
`
`110
`
`44
`
`;
`M2
`
`NAV
`
`NAV DATA
`
`130
`
`FUSION
`PROCESSOR
`
`[~1"!
`
`44~1
`
`CONFIG. MGR.
`
`CONFIG. MGR.~-44
`
`CPUC
`
`114
`
`> @ ”
`
`44—~
`
`CONFIG. MGR.
`
`CPU D
`
`116
`
`DISPLAY
`
`44—~
`
`CONFIG. MGR
`120
`
`124
`
`125 118
`
`FIG.9
`
`GUI
`
`AHM, Exh. 1012, p. 11
`
`AHM, Exh. 1012, p. 11
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 10 of 12
`
`US 7,146,260 B2
`
`130
`
`
`
`DISPLAY APPLICATIONS
`TO USER
`
`
`152[PROCESSOR/APPLICATION
`156
`FAILURE DETECTED
`
`154
`
`158
`
`160
`
`162
`
`164
`
`Y
`
`DIRECT OTHER
`PROCESSING CAPACITY
`PROCESSOR
`Y
`TO DOWNLOAD
`AVAILABLE ON
`
`OTHER PROCESSOR
`APPLICATION AND
`APPLICATION DATA
`
`
`
`SHOW FAILED
`
`PROCESSOR/APPLICATIONS
`TO USER
`
`
`
`USER REQUESTS
`
`RECONFIG. TO RELOAD
`FAILED APPLICATION
`
`Y
`
`OTHER PROCESSORS
`RUNNING NONCRITICAL
`APPLICATIONS
`
`DISPLAY NONCRITICAL
`APPLICATIONS TO USER
`THAT CAN BE REPLACED
`
`FIG.10
`
`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
`
`AHM, Exh. 1012, p. 12
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 11 of 12
`
`US 7,146,260 B2
`
`
`
`IDENTIFY DATA
`170
`STANDARD ASSOCIATED
`
`WITH NEW APPLICATION
`
`172
`
`
`
`174
`
`
`[DISPLAY DATA OUTPUT
`DEVICES ON GUI
`
`
`176
`USER SELECTS
`
`OUTPUT FOR DATA
`
`
`
`
`
`178
`OUTPUT DATA ON
`
`
`
`SELECTED OUTPUT
`
`FIG.12
`
`AHM, Exh. 1012, p. 13
`
`AHM, Exh. 1012, p. 13
`
`
`
`U.S. Patent
`
`Dec. 5, 2006
`
`Sheet 12 of 12
`
`US 7,146,260 B2
`
`210
`
`SPEED
`CONTROL
`
`AIRBAG
`
`AUDIO
`CONTROL
`
`ENGINE
`CONTROL
`
`SENSOR
`
`CONTROL
`220
`
`
`
`
`
`218
`
`222
`
`214
`
`216
`
`
`FIG.13
`
`AHM, Exh. 1012, p. 14
`
`AHM, Exh. 1012, p. 14
`
`
`
`US 7,146,260 B2
`
`2
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`1
`METHOD AND APPARATUS FOR DYNAMIC
`CONFIGURATION OF MULTIPROCESSOR
`SYSTEM
`
`BACKGROUND
`
`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
`Cars include many different electromechanical and elec-
`the DC system operates.
`tronic applications. Examples include braking systems, elec-
`FIGS. 5 and 6 are diagrams showing how a device
`tronic security systems, radios, Compact Disc (CD)players,
`manager in the DC system operates.
`internal and external lighting systems, temperature control
`FIGS. 7-10 are diagrams showing howareconfiguration
`systems, locking systems, seat adjustment systems, speed
`manager in the DC system operates.
`control systems, mirror adjustment systems, directional indi-
`FIGS. 11 and 12 are diagrams showing how a data
`cators, etc. Generally the processors that control
`these
`manager in the DC system operates.
`different car systems do not talk to each other. For example,
`FIG. 13 is a diagram showing different multiprocessor
`the car radio does not communicate with the car heating
`systems that can use the DC DC system.
`system or the car braking system. This means that each one
`of these car systems operate independently and do nottalk
`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 thatit 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 modelandstill
`work with the dashboard interface and the car temperature
`controller.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`Integration of new systemsinto a car is also limited. Car
`systemsare 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 notoriginally 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
`dashboardofthe 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 priorart.
`
`SUMMARY OF THE INVENTION
`
`A multiprocessor system used in a car, home,or office
`environmentincludes multiple processors that run different
`real-time applications. A dynamic configuration system runs
`on the multiple processors and includes a device manager,
`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 andidentifies which devices in
`the multiprocessor system are able to process the data.
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`DETAILED DESCRIPTION
`
`FIG. 1 shows a car 12 that includes a car multiprocessor
`system § 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 downloadsa 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 hardwiredlink 34
`or communicate to the display processor 16 through a
`wireless link 36. 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
`
`AHM, Exh. 1012, p. 15
`
`
`
`US 7,146,260 B2
`
`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 throughthe 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 longerhasto 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 homeoroffice 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
`movesapplications 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
`maybring a Digital Video Disc (DVD)player 86 into the car
`12. The DVD 86sends 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.
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`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 DVDplayer 86 can nowbe 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 anotherlocation in
`the car, such as from the passengerseat.
`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 operatorselects 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 amountofthe orderis calculated and sent backto 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 sametime, 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.
`Anew device 72 is brought into the multiprocessor system
`8 either via a hardwiredlink 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 connectedto 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
`
`AHM, Exh. 1012, p. 16
`
`
`
`US 7,146,260 B2
`
`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 ofthe processors A, B, C and D add
`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 orthe 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 sametime 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 consistof the last
`several minutes of tracking data obtained by the navigation
`application 110. The audio data 132 may includethelatest
`audio tracks played by the audio application 112.
`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 occursin a critical application, such asa 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
`movesthe application to another processor.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`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.Ifa failure is detected, the configuration
`manager initiates the reconfiguration routine.
`When reconfiguration is required, one of the reconfigu-
`ration managers 44first 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 processorin 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
`A then 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 processorA,or in one of the other
`processors B, C, or D detects the navigation failure. Alter-
`natively, a fusion processor 111 is coupled to someorall 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 determinesif 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 128to 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
`
`AHM, Exh. 1012, p. 17
`
`
`
`US 7,146,260 B2
`
`7
`the GUI 118 in FIG. 9 starts
`block 158. For example,
`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 the failed navigation
`application to another processor. If there is no user request,
`the configuration managers return to monitoring for other
`failures. If the user requests reconfiguration, the configura-
`tion manager 44 in block 164 displays other non-critical
`applications to the user. For example, the GUI 118 only
`displays the audio application icon 124 in processor B and
`not the ABS application icon 122 (FIG. 7). This is because
`the audio application is a non-critical application and the
`ABS application 114 is a critical application that cannot be
`cancelled.
`
`If the car operator selects the audio icon 124 in block 166,
`the configuration manager in block 168 cancels the audio
`application 112 in processor B and downloadsthe navigation
`application 110 from memory 128 into p