MULTIPROCESSOR SYSTEM FOR MANAGING DEVICES IN A HOME
A multiprocessor network in a home uses a transceiver configured to detect and establish communication between a processor in the network and a new device brought near or into the home. The device is connected to the network and a data manager identifies a type of data used by the new device. The multiprocessor network identifies software in the network that processes the same type of data as the new device, and transfers control and operation of the new device over to the multiprocessor network in the home.
This application is a Continuation of patent application Ser. No. 12/483,214 filed Jun. 11, 2009 Titled—METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM, which is a continuation of U.S. Pat. No. 7,778,739 Issued Jul. 28, 2010 Titled—METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM, which is a continuation of U.S. Pat. No. 7,146,260 Issued Dec. 5, 2006 Titled—METHOD AND APPARATUS FOR DYNAMIC CONFIGURATION OF MULTIPROCESSOR SYSTEM and this application incorporates by reference U.S. Pat. No. 6,629,033, Issued Sep. 30, 2003 Titled—OPEN COMMUNICATION SYSTEM FOR REAL-TIME MULTIPROCESSOR APPLICATIONS.
REFERENCES CITED U.S. Patent Documents
- U.S. Pat. No. 4,829,434 May 1989; Karmel et al.
- U.S. Pat. No. 5,581,462 December 1996; Rogers
- U.S. Pat. No. 5,786,998 July 1998; Neeson et al.
- U.S. Pat. No. 6,161,071 December 2000; Shuman et al.
- U.S. Pat. No. 6,181,994 January 2001; Colson et al.
- U.S. Pat. No. 6,182,006 January 2001; Meek
- U.S. Pat. No. 6,243,450 June 2001; Jansen et al.
- U.S. Pat. No. 6,505,100 January 2003; Stuempfle et al.
- U.S. Pat. No. 6,622,083 September 2003; Knockeart et al.
- WO96/24229 August, 1996 WO
- WO99/08436 February, 1999 WO
- WO99/57662 November, 1999 WO
- WO99/65183 December, 1999 WO
- WO01/30061 April, 2001 WO
- WO01/58110 August, 2001 WO
Product description of Raytheon RT Secure, “Embedded Hard Real-Time Secure Operating System”, Copyright 2000, pp. 1-2. cited by other.
Product description of Raytheon RT Secure, Copyright 2001, pp. 1-2. cited by other.
Product description of Raytheon RT Secure, “Development Environment”, Copyright 2001, pp. 1-2. cited by other.
Product description of Raytheon Electronic Systems (ES), Copyright 2002, pp. 1-2. cited by other.
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. cited by other.
A. Das, R. Fierro, V. Kumar, J. Ostrowski, J. Spletzer, and C. Taylor, “A Framework for Vision Based Formation Control”, IEEE Transactions on Robotics and Automation, vol. XX, No. Y, 2001, pp. 1-13. cited by other.
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. cited by other.
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 Philosophy in Electrical Engineering, Raleigh, N.C., 1997, pp. 1-5. cited by other.
M. Chantler, G. Russel, and R. Dunbar, “Probabilistic Sensor Fusion for Reliable Workspace Sensing”, pp. 1-14. cited by other.
ISIS Project: Sensor Fusion, Linkoping University Division of Automatic Control and Communication Systems in cooperation with SAAB (Dynamics and Aircraft), 18 pages. cited by other.
Hitachi Automated Highway System (AHS), Automotive Products, Hitachi, Ltd., Copyright 1994-2002, 8 pages. cited by other.
Vehicle Dynamics Lab, University of California, Berkeley, funded by BMW, current members: D. Caveney and B. Feldman, “Adaptive Cruise Control”, 17 pages. cited by other.
Counterair: The Cutting Edge, Ch. 2 “The Evolutionary Trajectory The Fighter Pilot-Here to Stay?” AF2025 v3c8-2, December 1996, pp. 1-7. cited by other.
Counterair: The Cutting Edge, Ch. 4 “The Virtual Trajectory Air Superiority without an “Air” Force?” AF2025 v3c8-4, December 1996, pp. 1-12. cited by other.
TNO FEL Annual Review 1998: Quality works, 16 pages. cited by other.
Boeing News Release, “Boeing Demonstrates JSF Avionics Multi-Sensor Fusion”, Seattle, Wash., May 9, 2000, pp. 1-2. cited by other.
Boeing Statement, “Chairman and CEO Phil Condit on the JSF Decision”, Washington, D.C., Oct. 26, 2001, pp. 1-2. cited by other.
Ada 95 Transition Support—Lessons Learned, Sections 3, 4, and 5, CACI, Inc.—Federal, Nov. 15, 1996, 14 pages. cited by other.
Joint Strike Fighter Terrain Databaste, ets-news.com “Simulator Solutions” 2002, 3 pages. cited by other.
MSRC Redacted Proposal, 3.0 Architecture Development, pp. 1-43. cited by other.
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. cited by other.
Green Hills Software, Inc., “The AdaMULTI 2000 Integrated Development Environment”, Copyright 2002, 7 pages. cited by other.
Luttge, Karsten: “E-Charging API: Outsource Charging to a Payment Service Provider”; IEEE; 2001 (pp. 216-222). cited by other.
BACKGROUNDCars include many different electromechanical 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 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.
Cars include many different electro-mechanical and electronic systems. 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 has to provide a separate standalone operating system. 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 some 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 an interface on the dashboard 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 all the car systems selected for the car. A car owner can not later incorporate new systems into the existing car. For example, a car may not originally come with a car navigation system. An after market navigation system from another manufacturer cannot be integrated into the 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.
The present invention addresses this and other problems associated with the prior art.
SUMMARY OF THE INVENTIONA 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.
A communication system for a mobile vehicle, home, or office environment includes multiple processors. The multiple processors each run an Open Communication system that controls how data is transferred between processors based on data content as opposed to the links that connect the processors together. The open communication system enables data or messages to be effectively transferred and processed for real-time applications or other server based applications that may be running on the multiple processors in a secure environment regardless of processors, locations, or data links.
The processors 6014, 6016, 6018 and 6020 all include software that run a Dynamic Configuration (DC) system 6010 that enables new processors or devices to be automatically added and removed from the car multiprocessor system 6008. The DC system 6010 also automatically reconfigures the applications running on different processors according to application failures and other system processing requirements.
For example, the processor 6020 may currently be running a high priority brake control application. If the processor 6020 fails, the DC system 6010 can automatically download the braking application to another processor in car 6012. The DC system 6010 automatically identifies another processor with capacity to run the braking control application currently running in processor 6020. The DC system 6010 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 6010 may replace a non-critical application running on another processor. For example, the DC system 6010 may cause the display processor 6016 to terminate a current non-critical application and then download the brake control application along with any stored critical data.
The DC system 6010 also automatically incorporates new processors or applications into the multiprocessor system 6008. For example, a laptop computer 6038 can communicate with the engine monitor processor 6034 through a hardwired link 6034 or communicate to the display processor 6016 through a wireless link 6036. The DC system 6010 automatically integrates the laptop computer 6038, or any other processor or device, into the multiprocessor system 6008. After integrated into the multiprocessor system 6008, not only can the laptop computer 6038 transfer data with other processors, but the laptop computer may also run car applications normally run by other processors in car 6012.
The DC system 6010 allows the car driver to manage how different applications are processed in the car 6012. As described above, a car operator may have to run an aftermarket navigation system through a GPS transceiver attached to the laptop computer 6038. The car driver has to place the laptop computer 6038 in the passenger's seat and then operate the laptop computer 6038 while driving.
The DC system 6010 in the display computer 6016 can automatically detect the navigation application running on the laptop computer 6038. The display computer 6016 notifies the car operator through the user interface 6026 that the navigation application has been detected. The car operator can then control the navigation application through the user interface 6026. Since the user interface 6026 is located in the dashboard of car 6012, 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 6010. Any single or multiprocessor system located either inside or outside of car 6012 can communicate and exchange data using the OC system 6010. It should also be understood that the DC system 6010 can be used in any real-time environment such as between processors in different home or office appliances and different home and office computers.
In one example, sensors 6052 feed sensor data to processor 6040. 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 6052 are coupled to processor 6040 through a link 6054, such as a proprietary bus. A Compact Disc (CD) player 6050 is coupled to the processor 6040 through another link 6048, such as a Universal Serial Bus (USB). Graphical User Interface (GUI) 6056 displays the data associated with sensors 6052 and CD player 6050. The GUI 6056 displays the outputs from sensors 6052 using an icon 6060 to identify temperature data and an icon 6062 to identify car speed. The processor displays the CD player 6050 as icon 6062.
The processor 6040 is located in car 6012 (
The DC system 6010 then automatically displays the newly detected DVD player 6086 on GUI 6056 as icon 6096. If capable, the car operator by selecting the icon 6096 can then display a video stream output from the DVD player 6086 over GUI 6056. The DVD player 6086 can now be controlled from the GUI 6056 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 6086 from another location in the car, such as from the passenger seat.
Other processors or devices can also be incorporated into the multiprocessor system 6008 in car 6012. In another example, the car 6012 drives up to a drive-in restaurant 6090. The drive-in 6090 includes a transmitter 6092 that sends out a wireless Blue tooth signal 6094. The processor 6040 includes a Blue tooth transceiver that allows communication with transmitter 6092. The DC system 6010 recognizes the signals 6094 from transmitter 6092 and then incorporates the drive-in 6090 into the multiprocessor system 6008 (
Referring to
Processor A includes a memory 6065 that stores the other recognized processors B, C and D. The data managers 6046 also identify any applications that may be running on the identified processors. For example, memory 6065 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.
One of the device managers 6046 in the multiprocessor system 6008 checks the signals from processor E checks to determine if the signals are encrypted in a recognizable protocol in block 6076. 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 6076. 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 6080.
If all these data parameters are verified, the device managers 6046 in one or more of the processors A, B, C and D add the new processor E to their processor arrays in block 6082. For example, processor A adds processor E to the processor array in memory 6065. After being incorporated into the multiprocessor system 6008, the processor E or the applications running on the processor E may be displayed on a graphical user interface in block 6084.
The processor D displays an icon 60120 on GUI 60118 that represents the navigation system 60110 running in processor A. An icon 60124 represents the audio application running in processor B and an icon 60122 represents the ABS application 60114 running in processor C.
The memory 60128 stores copies of the navigation application 60110, audio application 60112, ABS application 60114 and display application 60116. The memory 60128 can also store data associated with the different applications. For example, navigation data 60130 and audio data 60132 are also stored in memory 60128. The navigation data 60130 may consist of the last several minutes of tracking data obtained by the navigation application 60110. The audio data 60132 may include the latest audio tracks played by the audio application 60112.
The memory 60128 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 60128 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.
One or more of the configuration managers 6044 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 60128 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 60128 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 6044 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 6044 first tries to identify a processor that has extra processing capacity to run the failed application in block 60136. For example, there may be a backup processor in the multiprocessor system where the ABS application 60114 can be downloaded. If extra processing resources are available, the ABS application 60114 is downloaded from the memory 60128 (
There may also be data associated with the failed application that is stored in memory 60128. For example, the brake commands for the ABS application 60114 may have been previously identified for logging in memory 60128 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 60142.
If no backup processing resources can be identified in block 60136, the configuration manager 6044 identifies one of the processors in the multiprocessor system that is running a non-critical application. For example, the configuration manager 6044 may identify the navigation application 60110 in processor A as a non-critical application. The configuration manager 6044 in block 60140 automatically replaces the non-critical navigation application 60110 in processor A with the critical ABS application 60114 in memory 60128. The processor A then starts running the ABS application 60114.
In block 60154 the configuration manager 6044 for one of the processors determines if there is extra capacity in one of the other processors for running the failed navigation application 60110. If there is another processor with extra processing capacity, the navigation application is downloaded from memory 60128 to that processor with extra capacity along with any necessary navigation data in block 60156. 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 60110, the configuration manager 6044 displays the failed processor or application to the user in block 60158. For example, the GUI 60118 in
The configuration manager in block 60160 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 6044 in block 60164 displays other non-critical applications to the user. For example, the GUI 60118 only displays the audio application icon 60124 in processor B and not the ABS application icon 60122 (
If the car operator selects the audio icon 60124 in block 60166, the configuration manager in block 60168 cancels the audio application 60112 in processor B and downloads the navigation application 60110 from memory 60128 into processor B. A logging manager in processor A may have labeled certain navigation data for logging. That navigation data 60130 may include the last few minutes of position data for the car while the navigation application 60110 was running in processor A. The logged navigation data 60130 is downloaded from memory 60128 along with the navigation application 60110 into processor B. The navigation icon 60120 in GUI 60118 then shows the navigation application 60110 running on processor B. At the same time the audio application icon 60124 is removed from GUI 60118.
Referring back to
One or more of the data managers 6042, identifies the device by its data and the data, if applicable, is displayed on the graphical user interface in block 60172. The data manager then identifies any devices in the multiprocessor system that can output or transmit data to the new device in block 60174. For example, a newly detected audio source may be output from a car speaker. The data manager monitors for any user selections in block 60176. 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 60178.
The A/V output devices in the car are shown in the lower portion of GUI 60180. For example, icons 60192, 60194, 60196, 60200, and 60204 show car audio speakers. An in-dash video display is represented by icon 60190 and a portable monitor is represented by icon 60198.
Currently, a car operator may be listening to the radio 60186 over speakers 60192, 60194, 60196, 60200 and 60204. However, a passenger may move into the backseat of the car carrying an MP3 player. The MP3 player runs the DC system 6010 described in
One of the data managers 6042 determines the MP3 player outputs a MP3 audio stream and accordingly generates the icon 60182 on the GUI 60180. The data manager 6042 also identifies a speaker in the MP3 player as a new output source and displays the speaker as icon 60202. The car operator sees the MP3 icon 60182 now displayed on GUI 60180. The car operator can move the MP3 icon 60182 over any combination of the speaker icons 60192, 60194, 60196, 60200 and 60204. 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 60202 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 60184 or the radio 60186 icons over the speaker icon 60202. If the car operator, for example, moves the radio icon 60186 over the MP3 player speaker icon 60202 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,
Typical networks, such as in an office network environment, enable multiple computers to communicate with each other. Applications such as printing jobs can be launched from any one of the networked computers. If one of the networked computers crashes or is busy, a user must manually send the job to another computer. The other computer then handles the task like any other locally received task.
In a car environment, tasks must be processed with different priorities in real-time. For example, the braking tasks in the brake processor 3320 have to be processed with a high priority while a radio selection task performed in the display processor 16 can be processed with a relatively low priority. The processors 3314, 3316, 3318 and 3320 all include software that runs an Open Communication (OC) system 3310 that enables the multiple processors to transfer data and exchange messages for performing these real-time car applications.
If the processor 3320 currently running the high priority braking application fails, the OC system 3310 allows the braking tasks to be offloaded to another processor in car 3312, such as the display processor 3316. The OC system 3310 automatically assigns a high priority to the braking tasks that allow the braking tasks to override lower priority tasks, such as the radio application, that are currently being performed in display processor 3316.
The OC system 3310 also ensures that data in each processor is processed in a secure manner for the car environment. The security portion of the OC system 3310 prevents unauthorized devices from accessing the different car applications. The OC system 3310 also includes a logging portion that allows data in the car system to be automatically logged. This is important for accident reconstruction purposes. The OC system 3310 also allows different processors to communicate over different communication protocols and hardware interfaces. Any processor that includes an OC system 3310 can be integrated in the system shown in
The description below gives only a few examples of the different processors and different applications that can implemented using the OC system 3310. However, any single or multiprocessor system located either inside or outside of car 3312 can communicate and exchange data using the OC system 3310. It should also be understood that the OC system 3310 can be used in any real-time network environment such as between processors used in appliances and computers in the home.
A car interface manager 46 operates as an Application Programmers Interface (API) that can be implemented in any variety of different languages such as Java, C++, Extensible Markup Language (XML) or HyperText Markup Language (HTML), etc. The car interface manager 3346 enables applications 3348 to be written in any variety of different languages. This prevents the applications 3348 from having to be written specifically for the car environment or for a specific communication protocol. Thus, applications written for other systems can be reused in the car system described below. The car interface manager 3346 reads basic processing and data transfer commands needed to transfer data and messages between different processors and storage mediums inside or outside the car 3312.
For clarity the terms ‘message’ and ‘data’ are used interchangeably below. After a message passes through the car interface manager 3346, a priority manager 3344 determines a priority value for the message that determines how the message is processed both in the local processor 3350 and in other processors such as processor 3352. Referring to
In block 3364, the priority manager 3344 compares the priority value for the outgoing message with the priority values for other messages in the processor. The priority manager 3344 ranks the outgoing message with respect to the other messages and then sends the message to the logging manager 3342 in block 3366 (
In block 3368, the priority manager 3344 reads the priority labels for incoming messages. If the priority of the message is not high enough to run on the processor in block 3370, the data or message is rejected in block 3376. The priority manager 3344 may send out a message to the sending processor indicating the message has been rejected. In some situations, the message or data may have such a low priority that an acknowledge message does not have to be sent back to the sending processor. For example, inside temperature data from a temperature sensor may be sent to one or more processors with no requirement that the processor accept or acknowledge the data. In this case the temperature data is sent with a very low priority value that indicates to the priority manager 3344 that no message needs to be sent back to the temperature sensor even if the data is rejected.
The priority manager 3344 in block 3372 ranks the priority of the incoming message in relation to the priorities of all the other messages in the processor. The priority manager in block 3374 decides according to the ranking whether the message should be put in a queue or sent directly to the application for immediate processing. For example, a crash indication message may have a high enough priority to cause the priority manager 3344 to delay all data currently being processed by all other applications in the same processor. The priority manager 3344 directs all the applications to wait while the current high priority crash indication message is processed. The other data and messages are queued in the processor and processed after the crash indication message has been completed.
Referring to
The logging manager 3342 receives either an incoming message over a communications link for sending to a local application 3348 or receives an outgoing message from one of the local applications 3348 for sending out over the communications link to another processor in block 3380. The logging manager 3342 reads a logging label in the message in block 3382. If the logging label indicates that no logging is required, the message is sent on to the next communication manager in block 3388. If it is an outgoing message it is sent to the security manager 3340 (
The logging manager 3342 in each processor, provides the OC system 3310 with the unique ability to track when and where messages are sent and received at different processors in the multiprocessor car system. This is important in accident reconstruction allowing the logging managers 3342 to identify which processors and applications failed and also the sequence in which the different processors and associated applications failed.
The logging manager 3342 can also track unauthorized messages and data that may have caused any of the processors in the car to crash. For example, an audio processor that handles audio applications in the car may crash due to unauthorized downloading of MP3 music from a laptop computer. The logging manager 3342 can log the unauthorized data received from the laptop MP3 player. The logging manager 3342 logs any data that does not have a particular security or priority label value. A system administrator can then down load the MP3 data to identify what caused the audio processor to crash.
Referring to
The security manager 3340 in block 3390 reads a message either received from an application on the same processor or received over a communication link from another processor. The security manager 3340 determines if there is a security value associated with the message in block 3392. If there is no security value associated with the data, the security manager 3340 may drop the data in block 33100. However, some applications, such as a processor that plays audio data may not require a security label. In this case, the security manager in block 3394 allows the data to be passed on to the application in block 3398.
In other instances the data or message may have a security value, but that security value is not sufficient to allow processing on the present applications. For example, data for car security monitoring may be sent to a processor that controls air bag deployment and an automatic braking system. The two currently running applications may set a minimum security level for receiving data. If data received from other processors do not have that minimum security level in block 3396, the data is dropped in block 33100. Otherwise, the data or message is passed on to the next communication layer for further processing in block 3398. Thus the security manager 3340 prevents unauthorized data or messages from effecting critical car applications.
Referring back to
The hardware/link interface 3336 includes the software and hardware necessary for interfacing with different communication links 3354. For example, the two processors 3350 and 3352 may communicate over a Ethernet link, 802.11 wireless link, or hardwired Universal Serial Bus link, etc. The software necessary for the two processors to communicate over these different interfaces is known to those skilled in the art and is therefore not described in further detail.
The radar sensor 33104 in combination with the radar processor 33106 generates Radar Track Reports (RTRs) 33130 that are sent to the fusion processor 33114. The IR sensor 33110 in combination with the IR processor 33112 generate Infrared Track Reports (ITRs) 33128 that are sent to the fusion processor 33114.
Referring to
The track reports 33128 and 33130 include Open Communication (OC) labels 33133 for performing the OC operations described above. A security label 33134 is used by the security manager for preventing unauthorized data from being downloaded into one of the car processors and disrupting applications. A logging label 33136 is used by the logging manager to identify data that needs to be logged in a local memory. The priority label 33138 is used by the priority manager for scheduling messages or data to the applications run by the processors. The link headers 33132, security label 33134, logging label 33136 and priority label 33138 are all part of the data 33131 used by the open operating system 33131.
The radar processor 33106 and IR processor 33112 also send a time of measurement 33140 and other data 33142 from the radar sensor 33104 and IR sensor 33110, respectively. The data 33142 can include kinematic states of objects detected by the sensors. The time of measurement data 33140 and other sensor data 33142 is referred to as application data 33139 and is the actual data that is used by the application.
The applications described below are all performed by the OC system 3310 thus preventing the applications from having to handle the tasks. This allows the applications to be written in a completely portable fashion with no knowledge of the network hardware, security, priority and logging operations. This greatly reduces the cost of creating applications.
An image processing application in the processor 33106 identifies the object 33154 as a small far away object in block 33158. The image and kinematic data for the object is output by the OC system 3310 as a radar track report 33130. The security manager 3340 (
The OC system 3310 then formats the radar track report in block 33168 according to the particular link used to send the report 33130 to the fusion processor 33114. For example, the operating system 3338 and the hardware/link interface 3336 (
Referring next to
The OC system 3310 reads the security label in block 33186 to determine if the track report has authority to be processed by the fusion processor 33114. If the track report passes the security check performed by the security manager in block 33186, the logging manager in block 33188 checks to see if either the received radar data needs to be logged. In this example, the image processing application in the radar processor identified the object 33154 (
Because the image 33150 was identified as non-critical, the priority label 33138 (
Different applications in the fusion processor 33114 may or may not be performed depending on the track report. For example, the object 33154 may be sent to a video display in block 33194. However, the fusion processor 33114 will not send a brake command in block 33196 to the car braking system 33123. This is because the image has been identified as non-critical. Similarly, no audio warning is sent to the car audio system in block 33198 because the object has been identified as non-critical.
Referring back to
Because the IR track report 33128 has been identified as critical data, the priority manager 3344 in the IR processor 33112 assigns a high priority label value 33138. This high priority value is read by the operating system 3338 and interface hardware 3336 (
Referring again to
The security manager 3340 in the fusion processor 33114 confirms there is an acceptable value in the security label in block 33186 and then passes the IR track report 33128 to the logging manager in block 33188. The logging manager 3342 in the fusion processor 33114 reads the logging label and accordingly logs the image data in a local nonvolatile memory. This provides a history of the image 33156 that was detected by the IR sensor 33110.
The logged image data may then be used in subsequent accident analysis. For example, an accident reconstruction specialist can download the logged image data or message in both the IR processor 33112 and in the fusion processor 33114 to determine when the image data 33140 and 33142 was first detected. It can then be determined whether the image data was sent by the IR processor 33112 and received by the fusion processor 33114.
The priority manager reads the priority label 33138 in block 33190 and determines that the IR track report has a high priority. Accordingly, the track report is immediately sent to different applications in block 33192. The priority manager 3344 may first send the track report to the brake control application in block 33196. The brake control application immediately sends a brake command 33125 (
The logging manager 3342 in the fusion processor 33114 adds a logging label 33136 to the outgoing brake command 33125. Both the fusion processor 33114 and the brake control processor 33122 will then both log the brake command 33125. Thus, not only is the sequence of transmissions of the image data and messages logged in both the IR processor 33112 and fusion processor 33114 but also the sequence of the brake message 33125 from the fusion processor 33114 to the brake processor 33122. This further adds to any accident analysis data that may need to be obtained from the car if an accident occurs.
The IR data may also be sent to an audio application in block 33198 that immediately sends out an audio alarm over the car stereo system or out over a car horn. This automatically warns both the car driver and the object 33156 in front of car 33102 of a possible collision. In a third application, the fusion processor 33114 may send the IR image data to an image display 33118 in block 33194.
The OC system 33208 includes a control table 33212 that includes several parameters associated with a SENSOR REPORT 33210. For example, the SENSOR REPORT 33210 may need to include a priority label, a security label or a logging label. The security label also includes one or more locations where the SENSOR REPORT 33210 should be sent. The IR application 33202 includes a CONNECT TO SEND (SENSOR REPORT) command that the OC 3310 then uses to establish a slot in memory for the SENSOR REPORT. When IR data is received from the IR sensor 33200, the IR application 33202 generates sensor data (
The OC system 3310 attaches a security label 33134, logging label 33136 and priority label 33138 to the SENSOR REPORT 33210 as described previously in
The fusion application 33220 works in a similar manner and initiates a CONNECT TO RECEIVE (SENSOR REPORT) command to the OC system 3310 running in the same processor B. The OC system 3310 reserves a slot in local memory for any received SENSOR REPORTs 33210. The fusion application 33220 issues a WAIT ON (SENSOR REPORT) command that continuously waits for any SENSOR REPORTs 33210 sent by the IR application 33202. The OC system 3310 control table 33214 also identifies from the SENSOR REPORT data type the communication link 33211, hardware interface 33215 and other associated communication protocols used for receiving the SENSOR REPORT 33210.
Whenever a SENSOR REPORT 33210 is received, the OC system 3310 in processor B performs the security, logging and priority management operations described above based on the labels 33134, 33136 and 33138 in the sensor report 33210 (
The communication link between the fusion application 33220 and the brake application may be completely different than the link between the IR application 33202 and the fusion application 33220. However, the fusion application 33220 outputs the SENSOR REPORT and the BRAKE REPORT in the same manner. The OC system 3310 then uses stored link information in the control table 33214 to communicate to the IR application 33202 and the brake application over different links.
Thus, the IR application 33202 and the fusion application 33220 do not need to know anything about the physical links, address, or any of the other operations that are used to transmit data over different communication links.
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.
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.
Claims
1. A system having multiple processors configured to operate within a home, comprising:
- one or more of the multiple processors coupled together through multiple links into a multiprocessor network, wherein the multiprocessor network is configured to:
- operate a transceiver configured to detect and establish communication between at least one processor in the multiprocessor network and at least one new device brought in or proximate to the home;
- selectively connect the new device to the multiprocessor network;
- use a data manager to identify a particular type of data used in the new device and processed with a first software application controlled and operated by the new device;
- identify a second software application from among multiple different software applications located in the multiprocessor network, wherein the second software application is currently not configured to operate the new device, and wherein the second software application is configured to process the same particular type of data processed by the first software application controlled and operated by the new device;
- automatically configure and run the second software application in the multiprocessor network, wherein running the automatically configured second software application causes a particular one of the processors to take over control and operation of the new device; and
- initiate transfer of data from the new device to the particular one of the processors and initiate processing of the particular type of data received from the new device with the second software application running on the particular one of the processors.
2. The system of claim 1 wherein: the detected new device is a source that generates streaming audio or streaming video data; and the second software application is configured to output the streaming audio data to a home speaker or output the streaming video data to a home display.
3. The system of claim 1 wherein the multiprocessor network is configured to:
- detect a second new device that generates streaming data;
- selectively disconnect the streaming data generated from the first one of the detected new devices currently connected to the output device; and
- selectively connect streaming data generated from the second one of the detected new devices to the output devices according to inputs received on the home display coupled to the multiprocessor network.
4. The system of claim 2 wherein the detected new device has an integrated display screen.
5. The system of claim 4 wherein at least a portion of content displayed on the display screen of one of the detected new devices is represented on a home display in the multiprocessor network.
6. The system of claim 1 wherein one of the detected new devices comprises a data storage device selected from the group of a hard disk drive, solid state device, or compact disk.
7. The system of claim 1 wherein one of the detected new devices is a wired or wireless audio output device.
8. The system of claim 1 wherein one of the detected new devices includes wireless speakers or wireless headphones.
9. The system of claim 1 wherein a data storage coupled to the multiprocessor network includes a readable and writeable data storage media selected from the group of solid state device, hard disk drive, or compact disk.
10. The system of claim 1 wherein the display in the multiprocessor network is coupled to an audio control system.
11. The system of claim 10 wherein the audio control system receives signals from multiple RF transmitters.
12. The system of claim 11 wherein the audio control system is wired to home speakers.
13. The system of claim 1 wherein one of the detected new devices runs a global positioning system application.
14. The system of claim 1 including an external memory, and wherein one of the multiple on-board processors is configured to:
- detect a data source when the new device is connected to one of the multiple processors in a home;
- identify the detected data source; and
- communicate the identity of the detected data source to a display in the multiprocessor network for indication on the display.
15. The system of claim 1 wherein a display in the multiprocessor network includes a user interface that includes a touch screen.
16. The system of claim 15 wherein the user interface initiates control operations carried out by one or more of the home processors in the multiprocessor network.
17. The system of claim 15 wherein the user interface generates feedback to a user, which feedback is derived from information displayed on the display.
18. A method for configuring multiple processors within a home, comprising:
- operating the multiple processors in a multi-processor system, the multiprocessor system configured to: operate a transceiver configured to detect and establish communication between at least one processor in the multiprocessor network and at least one new device brought in or proximate to the home; wirelessly connect the new device to the multiprocessor system; selectively connect the new device to the multiprocessor network; use a data manager to identify a particular type of data used in the new device and processed with a first software application controlled and operated by the new device; identify a second software application from among multiple different software applications located in the multiprocessor network, wherein the second software application is currently not configured to operate the new device, and wherein the second software application is configured to process the same particular type of data processed by the first software application controlled and operated by the new device; automatically configure and run the second software application in the multiprocessor network, wherein running the automatically configured second software application causes a particular one of the processors to take over control and operation of the new device; and initiate transfer of data from the new device to the particular one of the processors and initiate processing of the particular type of data received from the new device with the second software application running on the particular one of the processors.
19. The method of claim 1 wherein: the detected new device is a source that generates streaming audio or streaming video data; and the second software application is configured to output the streaming audio data to a home speaker or output the streaming video data to a home display.
20. The method of claim 1 wherein the multiprocessor network is configured to:
- detect a second new device that generate streaming data;
- selectively disconnect the streaming data generated from the first one of the detected new devices currently connected to the output device; and
- selectively connect streaming data generated from the second one of the detected new devices to the output devices according to inputs received on the home display coupled to the multiprocessor network.
21. The method of claim 19 wherein the detected new device has an integrated display screen.
22. The method of claim 21 wherein at least a portion of content displayed on the display screen of one of the detected new devices is represented on a home display in the multiprocessor network.
23. The method of claim 18 wherein one of the detected new devices comprises a data storage device selected from the group of a hard disk drive, solid state device, or compact disk.
24. The method of claim 18 wherein one of the detected new devices is a wired or wireless audio output device.
25. The method of claim 18 wherein one of the detected new devices includes wireless speakers or wireless headphones.
26. The method of claim 18 wherein a data storage coupled to the multiprocessor network includes a readable and writeable data storage media selected from the group of solid state device, hard disk drive, or compact disk.
27. The method of claim 18 wherein the display in the multiprocessor network is coupled to an audio control system.
28. The method of claim 27 wherein the audio control system receives signals from multiple RF transmitters.
29. The method of claim 28 wherein the audio control system is wired to home speakers.
30. The method of claim 18 wherein one of the detected new devices runs a global positioning system application.
31. The method of claim 18 including an external memory, and wherein one of the multiple on-board processors is configured to:
- detect a data source when the new device is connected to one of the multiple processors in a home;
- identify the detected data source; and
- represent the identity of the detected data source on a display in the multiprocessor network.
32. The method of claim 18 wherein a display in the multiprocessor network includes a user interface that comprises a touch screen.
33. The method of claim 32 wherein the user interface selectively initiates control operations carried out by one or more of the home processors in the multiprocessor network.
34. The method of claim 33 wherein the user interface generates feedback to a user, which feedback is derived from one of information represented on the display or information represented by audio data.
35. A method of configuring a video display processing system operating in a home multiprocessor system, comprising:
- configuring a plurality of processors to operate as a local network, wherein at least one processor in the local network operates a transceiver configured to detect wireless signals from a new device not currently coupled to the multiprocessor system, wherein the new device comes in or proximate to the home;
- reading data codes transmitted in the wireless signals indicating a type of data being processed in the new device;
- determining from the data codes whether the type of data being processed by the new device is compatible;
- responsive to the data codes indicating compatibility with the selected running application or compatibility with the selected application stored in memory in the home multiprocessor system, selecting a running software application from among multiple different software applications operating in a particular one of the processors in the home multiprocessor system or selecting a stored application in memory in the home multiprocessor system;
- dynamically configuring or downloading and dynamically configuring the software application selected in a particular one of the processors in the multiprocessor system, wherein the software application is dynamically configured to process the same data type processed by the new device;
- responsive to detecting the signals from the new device and determining from the data codes in the wireless signals that the data being processed in the new device is compatible with at least one application in the multiprocessor system, take over control of the new device, receive the data from the new device, and take over processing of the data from the new device.
Type: Application
Filed: Mar 28, 2012
Publication Date: Jul 26, 2012
Patent Grant number: 8386113
Inventor: Dan A. Preston (Bainbridge Island, WA)
Application Number: 13/433,068
International Classification: G06F 15/16 (20060101);