Abstract:
A vehicle audio system senses the availability of a wireless audio device in or near a vehicle, and uses logic circuitry to identify a device-specific record from among many records available in a memory. The identified record contains data codes from the available wireless audio device and from a software application running on the device. Upon identifying the data code record, the system downloads a copy of an alternate software application selected from the memory and configures the alternate software application to process data from the wireless audio device. The system provides a user the option to play sound from the vehicle speakers or play sound from the wireless audio device.

Description:
This application is a continuation of U.S. patent application Ser. No. 12/258,215 filed Oct. 24, 2008 now U.S. Pat. No. 8,045,729, which is a continuation of U.S. patent application Ser. No. 11/462,958 filed Aug. 7, 2006, now issued U.S. Pat. No. 7,778,739 issued on Aug. 17, 2010, that is a continuation of U.S. patent application Ser. No. 09/841,915, filed Apr. 24, 2001, now U.S. Pat. No. 7,146,260 issued on Dec. 5, 2006, the disclosures of which are incorporated herein by reference in their entirety. 
    
    
     BACKGROUND 
     Cars include many different electro-mechanical and electronic applications. Examples include braking systems, electronic 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 indicators, 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 temperature 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 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. 
     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, configuration manager, and data manager. The device manager automatically detects and adds new devices to the multiprocessor system, and the configuration manager automatically 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. 
    
    
     
       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 automatically downloads a copy of the braking control application to the identified processor. If there is no extra reserve processing 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 link  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 computer 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 aftermarket 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 multiprocessor 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 different 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 configuration manager  44  in the processor  40  dynamically moves applications between different processors according to user inputs and other monitored conditions in the multiprocessor 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, temperature 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 processor  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 applications. 
     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 transmitter  92  and then incorporates the drive-in  90  into the multiprocessor 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 multiprocessor 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 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 managers  46  in one or more of the 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 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 (UPS) 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 application  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 . 
     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. 
     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 different 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 reconfiguration 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 available, 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 application 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, now U.S. Pat. No. 6,629,033, issued Sep. 30, 2003 which is herein incorporated by reference. The logged brake commands are downloaded to the backup processor of 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 application  110  running in processor A in block  152 . The configuration manager  44  in processor A, or in one of the other processors B, C, or D detects the navigation failure. Alternatively, 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 application  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 reconfiguration 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 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 message  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 configuration 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 downloads the navigation application  110  from memory  128  into processor B. A logging manager in processor A may have labeled certain navigation data for logging. That navigation data  130  may include the last few minutes of position data for the car while the navigation application  110  was running in processor A. The logged navigation data  130  is downloaded from memory  128  along with the navigation application  110  into processor B. The navigation icon  120  in GUI  118  then shows the navigation application  110  running on processor B. At the same time the audio application icon  124  is removed from GUI  118 . 
     Referring back to  FIG. 2 , a processor or application is accepted into the multiprocessor system by one or more of the device managers  46 . The configuration managers  44  in the processors reconfigure the multiprocessor system to incorporate the processor or application. The data manager  42  then detects what type of data is transmitted or received by the new device and determines the different processors and input/output devices in the multiprocessor system that can receive or transmit data to the new application or processor. 
       FIG. 11  shows in further detail how the data manager  42  in  FIG. 2  operates. In block  170 , the data manager for one of the processors determines the data standard for the data that is either transmitted or received by a new device. For example, the new device may be a MP3 player that outputs streaming audio data. In another example, the new device may be a DVD player that outputs streaming video data in a MPEG format. 
     One or more of the data managers  42 , identifies the device by its data and the data, if applicable, is displayed on the graphical user interface in block  172 . The data manager then identifies any devices in the multiprocessor system that can output or transmit data to the new device in block  174 . For example, a newly detected audio source may be output from a car speaker. The data manager monitors for any user selections in block  176 . For example, the car operator may select the output from a portable CD player to be output from the car speakers. The data manager controlling the CD player and the data manager controlling the car speakers then direct the output from the CD player to the car speakers in block  178 . 
       FIG. 12  gives one example of how the data managers  42  in the multiprocessing system operate. A GUI  180  displays the audio or video (A/V) sources in a car. For example, there are three devices detected in or around the car that are A/V sources. A cellular telephone detected in the car is represented by icon  184 , a radio is represented by icon  186 , and a DVD player is represented by icon  188 . 
     The A/V output devices in the car are shown in the lower portion of GUI  180 . For example, icons  192 ,  194 ,  196 ,  200 , and  204  show car audio speakers. An in-dash video display is represented by icon  190  and a portable monitor is represented by icon  198 . 
     Currently, a car operator may be listening to the radio  186  over speakers  192 ,  194 ,  196 ,  200  and  204 . However, a passenger may move into the backseat of the car carrying an MP3 player. The MP3 player runs the DC system  10  described in  FIG. 2  and sends out a signal to any other processors in the multiprocessor system  8  in the car. The device manager  46  and configuration manager  44  in one of the processors verify the data format for the MP3 player and configure the MP3 player into the multiprocessor system. 
     One of the data managers  42  determines the MP3 player outputs a MP3 audio stream and accordingly generates the icon  182  on the GUI  180 . The data manager  42  also identifies a speaker in the MP3 player as a new output source and displays the speaker as icon  202 . The car operator sees the MP3 icon  182  now displayed on GUI  180 . The car operator can move the MP3 icon  182  over any combination of the speaker icons  192 ,  194 ,  196 ,  200  and  204 . The output from the MP3 player is then connected to the selected audio outputs. 
     Audio data can also be moved in the opposite direction. The speaker icon  202  represents the output of the portable MP3 player that the passenger brought into the backseat of the car. The car operator also has the option of moving one or more of the other audio sources, such as the cellular telephone  184  or the radio  186  icons over the speaker icon  202 . If the car operator, for example, moves the radio icon  186  over the MP3 player speaker icon  202  and the MP3 player can output the radio signals, the multiprocessor system redirects the radio broadcast out over the MP3 speaker. 
     It should be understood that the multiprocessor system described above could be used in applications other than cars. For example,  FIG. 13  shows a first GUI  210  that shows different processors and applications that are coupled together using the DC system  10  in an automobile. A GUI  212  shows another multiprocessor system comprising multiple processors in the home. For example, a washing machine is shown by icon  214 . The DC system allows the washing machine processor to communicate and be configured with a television processor  216 , toaster processor  218 , stereo processor  220 , and an oven processor  222 . 
     The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the communication operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. 
     For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or described features can be implemented by themselves, or in combination with other operations in either hardware or software. 
     Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. Claim is made to all modifications and variation coming within the spirit and scope of the following claims.