Practical, redundant, failure-tolerant, self-reconfiguring embedded system architecture

A method for self-reconfiguring an architecture, the architecture comprising a module status message residing on a communication backbone, two or more processors connected to the backbone, and two or more software modules, wherein for each software module the method comprises:

• a) running the software module on one of the processors as a primary module;
• b) loading the software module as a backup module on at least one other processor;
• c) representing a functional state of the primary module in the module status message;
• d) monitoring the module status message, by the backup module;
• and,
• e) activating the backup module when the module status message indicates the functional state of the primary module is inactive.

A distributed self-reconfiguring architecture for activating redundant modules in a distributed computing system, comprising:

• a) a communication backbone;
• b) two or more processors, each processor connected to the communication backbone;
• c) two or more software modules, each software module residing on one processor as a primary module and residing on at least one other processor as a backup module, the primary module and backup modules each having a functional state;
• and,
• d) a module status message residing on the communication backbone, the module status message comprising the functional state of the primary module, the module status message monitored by the backup module, the backup module being activated when the module status message indicates the functional state of the primary module is inactive.

A mobile self-reconfiguring architecture for activating redundant modules in a mobile computing system, comprising:

• a) a communication backbone;
• b) two or more processors, each processor connected to the communication backbone;
• c) two or more software modules, each software module residing on one processor as a primary module and residing on at least one other processor as a backup module, the primary module and backup modules each having a functional state;
• and,
• d) a module status message residing on the communication backbone, the module status message comprising the functional state of the primary module, the module status message monitored by the backup module, the backup module being activated when the module status message indicates the functional state of the primary module is inactive.