Method for multi-tasking multiple Java virtual machines in a secure environment

• US 7,178,049 B2
• Filed: 04/24/2002
• Issued: 02/13/2007
• Est. Priority Date: 04/24/2002
• Status: Expired due to Term

• Current Assignee: MicroPairing Technologies LLC (Micropairing Technologies Ltd.)
• Original Assignee: Medius Inc
• Inventors: Lutter, Robert Pierce
• Primary Examiner(s): LE, DIEU MINH T
• Application Number:
  US10/132,886
• Publication Number:
  US 20030204550A1
• Time in Patent Office: 1,756 Days
• Field of Search: 718100-103, 718/1, 718/104, 718106-107, 714 1- 3, 714/10, 714/13
• US Class Current: 714/1
• CPC Class Codes: G01S 19/37 Hardware or software details of the signal processing chain
• CPC Class Codes: G06F 9/468 Specific access rights for resources, e.g. using capability register
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources

Abstract

The present invention allows construction of a secure, real-time operating system from a portable language such as Java that appears to be a Java virtual machine from a top perspective but provides a secure operating system from a bottom perspective. This allows portable languages, such as Java, to be used for secure embedded multiprocessor environments.

Claims

1. A portable processing system for controlling operations in a vehicle, comprising:

multiple processors located in the vehicle that transmit and receive messages over a wired or wireless network located within the vehicle, the processors executing different vehicle applications associated with critical operations associated with primary vehicle functions used for driving and controlling the vehicle and non-critical operations associated with providing and controlling driver ergonomic functions not required for operating the primary vehicle driving and control functions;

at least one of the processors operating as an executive that dynamically initiates the execution of the applications on different processors according to processor availability and the critical and noncritical operations associated with the vehicle applications so that identified failure of at least one of the vehicle applications associated with one of the critical operations is automatically transferred to a selected at least one of the processors currently executing non-critical operations thereby dynamically reassigning the selected at least one of the processors as a backup processor for one or more of the processors executing critical operations.

2. A portable processing system according to claim 1 wherein the vehicle applications are implemented using a Java or C++ operating language.

3. A portable processing system according to claim 1 wherein the executive identifies failure of a first processor executing one of the vehicle applications associated with one of the critical operations and in response to the identified failure automatically initiating the vehicle application on a second processor that is executing an application associated with one of the non-critical operations.

4. A portable processing system according to claim 1 wherein the vehicle applications are used for controlling real-time vehicle braking, driving or object detection operations.

5. A portable processing system according to claim 4 wherein the non-critical operations include operation of a car stereo.

6. A portable processing system according to claim 1 wherein the executive assigns priority values to the messages according to the critical and non-critical operations sending and receiving the messages.

7. A portable processing system according to claim 6 wherein the executive assigns priority preemption to messages and tasks for controlling how different applications communicate with each other.

8. A portable processing system according to claim 1 wherein the executive automatically archives vehicle data during vehicle operation for use in accident reconstruction or vehicle maintenance.

9. A portable processing system according to claim 1 including:

a first processor operating a first critical operation;

a second processor operating one of the non-critical operations;

wherein the executive detects a failure of the first processor, or failure in the critical operation on the first processor; and

in response to the failure detection the executive identifying the second processor as available as a backup processor for running the critical operation and accordingly directing the second processor to start operating the first critical operation while transferring data obtained from the first processor while operating the first critical operation to the second processor such that the second processor operates one of the non-critical operations and also provides redundancy for the failed first critical operation.

10. A portable processing system according to claim 1 wherein the executive further includes a message manager configured to control how messages are received and transmitted between different vehicle applications operating on different processors.

11. A portable processing system according to claim 10 wherein the executive further includes a security manager configured to control what data and messages are allowed to be received and transmitted between the different vehicle applications operating on the different processors.

12. A portable processing system according to claim 11 wherein the security manager prevents non-critical operations and messages from non-critical operations from being loaded onto processors running critical operations.

13. A portable processing system according to claim 1 wherein the executive further comprises a critical data manager that identifies critical operations and periodically stores data associated with the identified critical operations.

14. A portable processing system according to claim 13 wherein the critical data manager manages the retention of data generated by a sensor fusion application operating on a first processor by transferring the data to a second processor that takes over operation of the sensor fusion application when a failure is identified with the first processor.

15. A portable processing system according to claim 1 wherein the multiple different processors each operate multiple different configuration managers and one of the configuration managers operates as a master configuration manager,

the multiple different configuration managers configured to periodically send operating signals and the master configuration manager reassigning vehicle applications associated with the processors that fail to periodically send the operating signals.

16. A portable processing system according to claim 15 wherein a priority scheme is used to dynamically reassign the master configuration manager to another processor when a failure is identified with the processor currently operating the master configuration manager.

17. A portable processing system according to claim 1 wherein one or more of the processors operate as a task manager, a configuration manager, and a critical data manager;

the task manager operating one or more sensors for capturing sensor data and then controlling transfer of the captured sensor data between the processors for subsequent processing;

the configuration manager monitoring communications between the processors to detect processor failures; and

the critical data manager retaining at least some of the sensor data and directing the retained sensor data and any new sensor data to the different processors according to any processor failures identified by the configuration manager.

18. An application management system comprising:

modular processors linked over a network for operating different vehicle applications that control or monitor associated critical and non-critical vehicle operations;

at least one of the processors operating as an executive that control which processors operate the applications according to the associated critical and non-critical vehicle operations and according to different vehicle conditions and priorities associated with data and messages exchanged between the processors, wherein the executive directs one of the processors operating one of the non-critical applications to take over operation for one of the critical applications when the processor operating the critical application fails; and

sensors that provide input to a primary processor or a backup processor according to instructions provided by the executive, wherein the backup processor operates one of the non-critical applications when not operating as a backup to the primary processor.

19. An application management system according to claim 18 wherein the applications are associated with different hardware protocols.

20. An application management system according to claim 18 wherein the input is prioritized according to which of the sensors is used as the input.

21. An application management system according to claim 18 wherein the input is prioritized according to a type of input associated with the data or messages.

22. An application management system according to claim 18 wherein the executive cannot be manipulated by the applications.

23. An application management system according to claim 18 wherein the executive controls the exchange of data and messages between processors and further controls when the applications are initiated by the processors.

24. An application management system according to claim 18 wherein the executive initiates one or more of the processors in a lock-step mode.

25. An application management system according to claim 24 wherein the lock-step mode is used to determine a system failure or a sequence of events.

26. An application management system according to claim 25 wherein the lock-step mode is used for automotive accident reconstruction or system diagnostics.

27. An application management system according to claim 18 wherein the executive controls the order that messages are received and transmitted by the applications.

28. An application management system according to claim 27 wherein the messages have associated priorities that identify critical and non-critical vehicle operations, the executive processing the data and messages according to the associated priorities.

29. A method for configuring real-time vehicle applications in a distributed multi-processor system operating in a vehicle, comprising:

identifying vehicle applications running on different processors in the multiprocessor system;

operating a task manager that obtains different data and state information associated with the different vehicle applications;

operating a configuration manager that notifies the task manager upon detecting a failure running one of the identified vehicle applications in the multiprocessor system;

using the task manager for automatically identifying another processor in the multiprocessor system for running the identified vehicle application and redirecting the vehicle application associated with the detected failure to the other identified processor in the vehicle;

using the configuration manager to redirect the data and state information to the other identified processor in the vehicle after detecting the failure; and

initiating the identified application in the identified other processor.

30. A method according to claim 29 including replacing one or more of the vehicle applications successfully running in the multiprocessor system with the identified application when there is no extra processing capacity in the multiprocessing system for running the identified application in another processor.

31. A method according to claim 30 including identifying critical and non-critical vehicle applications running in the multiprocessor system and replacing one of the identified non-critical vehicle applications with the identified application.

32. A method according to claim 29 including:

identifying a new device that is not currently coupled to the multiprocessor system;

coupling the new device to the multiprocessor system when output signals from the new device conform to a communication protocol used in the multiprocessor system;

detecting new vehicle applications running on the new device; and

adding the new vehicle applications running on the new device to a stored list of all applications running in the multiprocessor system.

33. A method according to claim 32 including:

identifying a data type used by the new device;

identifying output devices in the multiprocessor system that uses the same data type;

displaying on a graphical interface the new device and the identified output devices; and

outputting data from the new device to the output devices selected on the graphical interface.

34. A method according to claim 29 including:

identifying a failed vehicle application to a car operator;

identifying non-critical vehicle applications that can be replaced by the failed vehicle application;

detecting one of the non-critical vehicle applications selected by a car operator;

replacing the selected non-critical vehicle application with a copy of the failed application; and

running the copy of the failed vehicle application.

35. A method according to claim 29 including:

storing a critical vehicle application in memory;

storing data generated by the critical vehicle application in memory; and

downloading the stored critical vehicle application and the stored critical data to another processor when the vehicle application fails.

36. A method according to claim 29 including:

moving a portable transmitting device within communication range of the multi-processor system;

detecting a protocol used by the portable device;

automatically configuring the portable device into the multiprocessor system when the protocol conforms with one of the protocols used in the multiprocessor system;

displaying an application running on the portable device from an in-dash display coupled to the multiprocessor system; and

operating the application on the portable device from the in-dash display.

37. A method according to claim 36 including using different wireless and hardwired communication protocols to communicate between different processors in the multiprocessor system.

38. A method according to claim 37 including controlling car braking, car airbag deployment, car sensor monitoring, and car audio processing with the multiprocessing system.

39. A method for operating multiple processors in a vehicle, comprising:

operating a task manager that obtains different Global Positioning System (GPS) data from a first processor operating a GPS application and obtains sensor fusion data from one or more second processors operating sensor applications;

operating a configuration manager that detects failure of the GPS application operating in the first processor or failure of the sensor applications operating in the second processors, the configuration manager notifying the task manager of the detected failure and the task manager redirecting the GPS or sensor applications associated with the detected failure to a third processor in the vehicle;

operating a critical data manager that manages the storage of data and state information from the GPS and sensor applications; and

using the configuration manager to redirect the stored data and state information to the GPS or sensor applications operating on the third processor after a detected failure on the first or second processors.

40. The method according to claim 39 including:

operating a message manager that determines a priority for messages containing the data and state information associated with the GPS and sensor applications; and

transferring the messages between the first, second and third processors according to the determined priority.