A Satellite OBC Is Not Just a Microcontroller Board with a CubeSat Connector

Putting a SAM, STM32, or similar microcontroller on a 96 × 96 mm PCB and adding a 104-pin CubeSat-style connector does not magically convert it into a satellite onboard computer.

There are many things that must be considered, and they are not all solved by simply reading ECSS standards. Standards are important. They tell us what to consider, document, test, and verify. But they do not tell you exactly how to design the architecture.

• They do not magically add ECC to your memory interfaces.
• They do not convert your digital logic into TMR.
• They do not protect your boot flow, memory buses, interfaces, or recovery mechanism from faults.

For these things, device architecture matters.

This is also where end users need to be careful. Today, many companies sell microcontroller-based boards under the label of “OBC”. Some of these boards are useful for education, laboratory testing, and early mission development. But there is a huge difference between a microcontroller board sold as an OBC and a modern FPGA SoC-based onboard computer designed around reliability.

The label is not enough. The architecture behind the label matters.

In my view, the minimum direction for a serious satellite computer is to consider proper memory protection, ECC, fault detection, watchdog architecture, and, where required, TMR and voting logic. This is where FPGAs became important.

I worked on several designs using space-grade Virtex-4 and Virtex-5 FPGAs with embedded dual hard-core PowerPC processors. They were powerful devices, but for many smallsat missions with limited power budgets, they could easily become overkill.

Using SRAM-based FPGAs such as Spartan-6 with LEON soft processors was another step forward. We could implement ECC, TMR, custom interfaces, voting logic, and multi-core soft CPU architectures such as LEON3 and LEON4. We could also customise and protect the architecture in ways that are simply not possible with a basic microcontroller.

But SRAM-based FPGA designs also bring the configuration memory problem. You need scrubbing to detect and correct fabric configuration anomalies. So yes, it is a much better architecture than a simple microcontroller board, but it also brings its own complexity. Then we moved to Actel flash-based FPGAs, now Microchip Technology Inc.

With flash-based FPGA fabric, the configuration scrubbing problem is largely removed. The FPGA is live after power-up, there is no need for external configuration memory, and the flash-based configuration cells are inherently immune to SEU. At the same time, the main benefits of FPGA-based design remain: custom interfaces, parallel processing, ECC, TMR, voting logic, and mission-specific architectures.

We used these devices for several generations of OBC designs, from LEON3 on ProASIC3 to RISC-V architectures on SmartFusion2 and IGLOO-based solutions. Then came PolarFire and PolarFire SoC, with a major upgrade in resources, performance, power efficiency, and software capability.