Luck Is Not Random, Luck Is Preparation Meeting Opportunity
How FDIR Prepares a CubeSat Camera for the Moment That Matters
- September 18, 2026
- CAVU Aerospace UK
For a CubeSat Earth-observation mission, this idea has a very practical meaning on target, right on time. A satellite may spend days or weeks waiting for the right imaging opportunity. The spacecraft needs to be correctly positioned, the target needs to be visible, illumination needs to be suitable and the camera needs to be ready. A Camera with well recovery plans & mature FDIR, bad luck is minimized.
When that moment arrives, there is no time to discover that the camera’s image sensor has stopped responding, a memory location has been corrupted, an interface has lost synchronisation or the processing pipeline has suffered a radiation-induced upset. The camera has to be prepared before the opportunity arrives. Preparation means mature FDIR. This is the philosophy behind the Fault Detection, Isolation and Recovery (FDIR) architecture of the CAVU SLDU345 CubeSat camera. Rather than simply identifying what can go wrong, the FDIR design asks five practical questions for every important subsystem:
How do we detect the failure?
How do we know that it has happened?
Can we recover automatically?
What happens if recovery fails?
How do we protect the mission until the spacecraft can intervene?
The result is a camera designed not only to acquire images, but to protect its ability to acquire them when the opportunity finally appears.
Preparation begins with understanding how things can fail, FMEA
The SLDU345 FDIR analysis covers the camera at subsystem level, identifying specific failure modes, their criticality, observable symptoms, onboard detection parameters, detection thresholds, recovery actions and compensating provisions.
This includes the camera’s Power regulation, PolarFire SoC processing unit, image sensor, LPDDR4 image-frame memory, DDR4 processing memory, Dual eMMC image storage, Dual QSPI boot/firmware storage, LVDS interface, MIPI CSI-2 sensor interface & FPGA image-processing pipeline.
The important point is that these are not simply theoretical failure lists. For each failure, the design establishes a specific response. That is what turns FDIR into preparation.
The processing unit is based on the Microchip PolarFire SoC, combining RISC-V processing with FPGA fabric. One of the key failure modes is execution deviation: the processor stops executing correctly, becomes trapped or experiences an unexpected exception.
The recovery is autonomous. The FPGA fabric initiates a RISC-V soft reset and the firmware re-initialises from the available boot image. Before the reset, the event is latched into MRAM, allowing engineers to understand what happened after recovery. But the system does not blindly reset forever. If three consecutive resets occur within 60 seconds, the camera transitions towards a safe state and raises a safe-mode indication to the spacecraft through CAN. This is another important FDIR principle, Recovery attempts are useful only when the system knows when to stop attempting recovery.
Not every failure result in a completely dead camera. Radiation and ageing can gradually affect CMOS image sensors through increased dark current, hot pixels and fixed-pattern noise. The SLDU345 therefore also monitors image quality itself. The FPGA image-processing system can analyse Image histograms, Dark-frame mean, Pixel defect count, Fixed-pattern noise & Pixel-level outliers.
For example, the FDIR design defines limits such as More than 500 hot pixels, Dark-frame mean exceeding the calibrated baseline by 3σ, Histogram standard deviation exceeding defined limits, Fixed-pattern noise exceeding 1% of full-scale. When degradation is detected, the camera does not necessarily declare the sensor unusable. Instead, it can compensate. The FPGA can update the pixel-defect map and perform real-time bad-pixel replacement using neighbouring pixels. Dark-frame subtraction can be applied in the processing pipeline.
The camera can also perform sensor recalibration during eclipse periods, updating dark-current, gain and offset parameters. The pixel-defect map is stored in QSPI Flash so that corrections can be retained between operations. This is an important distinction: FDIR is not always about recovering from failure. Sometimes it is about maintaining acceptable performance despite degradation.
Radiation-induced memory errors: detect, correct, preserve
The camera contains substantial memory for image acquisition and processing, and radiation makes memory integrity particularly important. For LPDDR4 frame-buffer memory, the PolarFire SoC’s EDAC/ECC mechanisms can identify and correct single-bit errors.
The FDIR monitors Single-bit ECC errors, Multi-bit ECC errors, Corrected-error accumulation & Image-frame CRC failures. A single-bit error can be corrected automatically.
A more serious multi-bit error can trigger additional recovery actions, including memory scrubbing and re-acquisition of an affected image frame. Persistent error accumulation can cause a memory segment to be marked as problematic and reallocated. The camera also transfers mission-critical image data to eMMC storage after acquisition rather than leaving important data unnecessarily exposed in volatile memory.
For DDR4 processing memory, the same philosophy is applied. A corrupted processing result can be regenerated from the original image data in LPDDR4. If necessary, the affected image can be processed again. So the recovery chain becomes Detect corruption → correct if possible → recover data → re-process → reacquire if necessary.
Storage failure: protect the image after it has been captured
Taking a perfect image is not enough. If the image is corrupted before it reaches non-volatile storage, the mission may still lose the result. The SLDU345 therefore treats eMMC storage corruption as one of its highest-criticality storage failures, with a criticality rating of 9 in the FDIR analysis. The camera uses two eMMC devices.
The FDIR system monitors Internal eMMC ECC errors, File-level CRC errors, Device health, Bad-block accumulation & Write/read verification. For critical image data, the camera can perform write verification. If a write does not verify correctly, it can attempt the write again. If the primary eMMC becomes unusable, the system can switch to the redundant eMMC. The result is particularly important for an imaging mission:
A failure of one storage device does not automatically mean the loss of the image. The architecture has already prepared another place for the data to go.
In FDIR of each product, we list all failure mods & go to bottom of recovery plans to minimize risk of losing opportunity.
From failure detection to mission resilience
When all these mechanisms are considered together, the SLDU345 FDIR architecture can be viewed as a series of concentric protection layers.
Layer 1 — Prevent: Hardware protection, ECC, write protection, authenticated firmware and radiation-aware design reduce the probability that a fault becomes a mission failure.
Layer 2 — Detect: Watchdogs, CRCs, ECC flags, frame counters, link-lock signals, image statistics and health monitoring identify abnormal behaviour.
Layer 3 — Recover: The camera can reset sensors, retrain interfaces, reinitialise processors, scrub memory, reprocess images, replace bad pixels and switch to redundant storage or firmware.
Layer 4 — Compensate: The system can continue operating in a degraded condition where the mission objective remains achievable.
Layer 5 — Escalate: If autonomous recovery is unsuccessful, the camera reports the condition to the spacecraft and transitions towards a defined safe state rather than repeatedly attempting an unsuccessful recovery.
This is what makes FDIR much more than a list of possible failures. It is a strategy for preserving mission capability.
Now return to the original scenario. The CubeSat approaches its target. The spacecraft attitude is correct. The target is illuminated. The camera receives the command to capture. At that moment, everything that was designed into the FDIR architecture suddenly matters. A memory error has already been corrected. A previous sensor synchronisation problem has already been recovered. A firmware anomaly has already been detected by the watchdog. A degraded pixel has already been identified and compensated. A failed storage device can be bypassed. A corrupted boot image can be replaced by its redundant copy. A CSI-2 error can trigger frame re-acquisition. An FPGA processing upset can be scrubbed or the affected pipeline can be reset. The camera does not have to hope that everything works.
It has been designed to prepare for the possibility that something will not work. And that is the real meaning of: Luck is not random. Luck is when preparation meets opportunity.
For a CubeSat camera, the opportunity is the target passing through the field of view. The preparation is every FDIR mechanism designed long before that moment. Because in space imaging, mission success should never depend on being lucky. It should depend on being ready.
