Redundant OBC Architecture & Supervisor for High-Reliability Spacecraft

One effective approach to improving spacecraft reliability is the implementation of a double OBC architecture, in which two independent OBCs are available to perform the critical spacecraft computing and control functions. However, redundancy alone is not sufficient. The spacecraft also requires an independent and reliable mechanism to control which OBC is active, recover from faults, manage power, and perform a controlled transition from one OBC to the other. This role can be performed by a dedicated Supervisor, providing a simple and deterministic management layer above the two OBCs.

The Supervisor algorithm defines the decision-making and operational logic, while the hardware implementation can be realised either as an add-on card positioned between the two OBCs or as a separate supervisor board connected independently to both OBCs.

 

Dual-OBC Redundancy

In a typical redundant architecture, the spacecraft contains:

• OBC-A
• OBC-B
• A dedicated Supervisor
• Controlled power paths
• Reset and enable signals
• Health-monitoring interfaces
• Communication interfaces between the Supervisor and each OBC

At any given time, one OBC can operate as the Active OBC, responsible for controlling the spacecraft and executing the primary mission or platform software. The second unit can remain in one of several states, depending on the mission requirements:

• Cold redundancy – the backup OBC is completely powered off.
• Warm redundancy – selected circuits or subsystems remain powered, allowing faster activation.
• Hot redundancy – both OBCs are powered and operational, with one designated as the active controller.

The Supervisor provides the mechanism required to manage these states safely and predictably.

The Supervisor is not intended to replace the computational capability of the OBC. Instead, it performs a focused set of critical management functions that remain available even if the active OBC experiences a software or hardware failure.

A key function of the Supervisor is determining which OBC has authority to control the spacecraft. The Supervisor maintains a clear definition of:

• Active OBC
• Standby OBC
• Failed OBC
• Recovery or maintenance state

Only the selected Active OBC should have control authority over critical spacecraft interfaces. Depending on the spacecraft architecture, the Supervisor can control the selection using Enable signals, Multiplexers, Bus switches, GPIO control, Communication routing, Power-domain switching & Interface isolation.

This architecture helps prevent a situation in which both OBCs simultaneously attempt to control the same spacecraft subsystem. During normal operation, the Supervisor may keep OBC-A active and OBC-B in standby. If OBC-A experiences a critical fault, the Supervisor can isolate or power down OBC-A, activate OBC-B, and transfer control to the redundant computer.

 

Health Monitoring

Health monitoring provides the information required by the Supervisor to determine whether an OBC is operating correctly. Typical monitoring mechanisms may include hardware watchdog signals, periodic heartbeat signals, GPIO health indicators, power-good signals, voltage monitoring, current monitoring, Temperature reading, internal error flags, communication status & FPGA or processor status.

For example, the active OBC can periodically generate a heartbeat signal to the Supervisor. As long as the heartbeat arrives within the expected timing window, the Supervisor considers the OBC operational. If the heartbeat is missing, the Supervisor can initiate a predefined recovery sequence.

A typical recovery sequence could be:

1. Detect missing heartbeat from the active OBC.
2. Wait for a defined confirmation period to avoid false fault detection.
3. Issue a reset command to the affected OBC.
4. Monitor whether normal heartbeat operation returns.
5. If recovery fails, perform a power cycle.
6. If the OBC remains unavailable, isolate it.
7. Power ON or activate the redundant OBC.
8. Confirm successful boot and health status.
9. Transfer Active OBC authority to the redundant unit.
10. Report the failure to spacecraft telemetry when communication is available.

This hierarchical recovery approach avoids unnecessary failover while ensuring that a persistent failure can be handled autonomously.

 

Supervisor Algorithm

The Supervisor behaviour can be implemented as a deterministic state machine.

A simplified architecture may include the following states:

Initialisation- After spacecraft power-up, the Supervisor verifies its own power and configuration, determines the initial OBC configuration, and begins the selected startup sequence.

Primary OBC Startup- The Supervisor powers the selected primary OBC and maintains it in reset until all required power rails are stable. The reset is then released, and the Supervisor begins monitoring the OBC health indicators.

Normal Operation- The selected OBC operates as the Active OBC. The Supervisor continuously or periodically monitors Heartbeat, Watchdog, Power status, Temperature & Fault flags. The redundant OBC remains in its configured standby mode.

Fault Detection- If the active OBC fails to satisfy the defined health criteria, the Supervisor enters a fault-handling state. The fault may be classified as Temporary, Recoverable, Persistent & Critical.

Recovery- Depending on the fault classification, the Supervisor can attempt Software reset request, Hardware reset, Peripheral reset & Complete OBC power cycle.

Failover- If recovery is unsuccessful, the Supervisor isolates the failed OBC and activates the redundant OBC. The redundant OBC becomes the new Active OBC.

Continued Operation- The Supervisor continues monitoring the newly active OBC while maintaining the failed unit in a safe state. Depending on the mission requirements, it may periodically attempt to recover the failed OBC and return it to standby availability.

 

Hardware Implementation Option 1: Supervisor as an Add-On Card

One implementation approach is to integrate the Supervisor into an add-on card positioned between the two OBCs. In this architecture, the add-on card provides the electrical and logical connection required to manage both computers.