Building compute hardware for terrestrial edge deployment is a constrained problem. Building it for low Earth orbit is a different category of problem entirely. The constraints don't just add up — they interact. A design decision that solves for radiation tolerance may conflict with power budget requirements. A choice that maximizes processing throughput may make thermal management intractable. The design space for orbit-native compute is genuinely small, and navigating it requires treating the orbital environment not as a list of compliance requirements to check off, but as the primary design input from the first day of architecture.
TILE is designed around three constraints that we treat as non-negotiable: radiation tolerance, deterministic power draw within a tight SWaP budget, and deterministic processing behavior. This post walks through the architecture decisions those constraints drive, and why each one looks the way it does.
Radiation Tolerance: TID, SEE, and the Tradeoff Space
The LEO radiation environment is primarily shaped by trapped electrons and protons in the inner Van Allen belt, with additional contribution from galactic cosmic rays and solar particle events. For a satellite in a circular orbit at 500–600 km altitude in a low-inclination orbit, the annual total ionizing dose accumulated by unshielded electronics is typically in the range of a few krad(Si) — well below the dose that would be acutely damaging to commercial-grade silicon. As orbital altitude increases, or for polar sun-synchronous orbits that pass through the South Atlantic Anomaly more frequently, accumulated TID rises substantially.
TID degradation is gradual: threshold voltage shifts in CMOS transistors, increased leakage current, eventual parameter drift outside acceptable operating range. Single event effects (SEE) are the more immediate concern for compute hardware — specifically single event upsets (SEUs), which flip bits in SRAM and registers, and the more destructive single event latch-up (SEL) and single event burnout (SEB) that can permanently damage a device.
TILE's approach to radiation tolerance is not to rely on fully radiation-hardened-by-process (RHBP) silicon across the entire compute stack. That would be prohibitive from both cost and performance standpoints — the radiation-hardened processor market has not kept pace with commercial silicon performance, and the gap is widening. Instead, TILE uses a layered approach: commercial-grade processors selected for intrinsic SEU cross-section characteristics, combined with error detection and correction (EDAC) logic on all critical memory paths, hardware scrubbing, and watchdog-supervised fault recovery. The power supply and sequencing circuits — where latch-up is the primary concern — use properly shielded, SEL-hardened components.
This is not a novel approach. It reflects current industry practice for commercial LEO smallsats where mission life is in the two-to-five year range and the acceptable risk profile is different from a crewed vehicle or a deep-space probe. We're not saying RHBP is unnecessary; we're saying the appropriate radiation mitigation strategy depends on the specific orbit, the mission life, and the consequences of a compute reset versus a compute failure. TILE is designed for LEO commercial satellite operators, and the architecture reflects that specific use case — not a universal hardness requirement.
Power Budget: SWaP as a First-Class Design Parameter
A typical 6U CubeSat bus has a total power generation capacity in the range of 15–30 W from body-mounted solar panels, with a proportion allocated to compute-adjacent functions. A slightly larger 12U or ESPA-class bus operates with more margin. In either case, the power available for a secondary compute payload — one that is not the primary mission instrument — is constrained. Allocating 8–12 W to an edge compute module is feasible on most modern smallsat buses; allocating 25 W is not.
TILE's target operating power is designed to fit within this envelope. The processor selection, clock frequency, and memory architecture are all influenced by the power constraint. This means the raw FLOPS available to an onboard inference task are far lower than what a data center inference accelerator provides. The implication is that models intended to run on TILE must be designed and quantized appropriately — full-precision, large-parameter models that run well in the cloud will not simply port to the orbital edge. This is a design constraint we communicate explicitly to customers during early integration conversations.
Power also drives thermal behavior. TILE has no active thermal control — no thermoelectric coolers, no heat pipes, no pump-driven loops. Passive thermal management through conductive coupling to the satellite bus structure and careful component placement on the PCB is the only option. This constrains the instantaneous power dissipation during active inference and means that duty cycle management is part of how TILE operates in practice. Not all missions need continuous inference; for most use cases, processing during the nadir-pointing imaging window is sufficient, and the thermal architecture is sized for that duty cycle.
Deterministic Processing: Why Predictability Matters More Than Throughput
In terrestrial compute contexts, occasional latency spikes are acceptable. A batch processing job that usually completes in 10 seconds but occasionally takes 12 seconds is not a failure. In an orbital compute context, where processing must complete within the window between sensor acquisition and downlink buffer submission, non-determinism is a reliability risk.
TILE is designed to execute inference tasks with bounded, predictable latency. This influences both the hardware selection and the software runtime environment. The hardware avoids microarchitectural features that introduce latency variance — out-of-order execution depths, branch prediction structures, and speculative prefetch mechanisms that benefit average-case throughput but increase worst-case latency. The software runtime does not use dynamic memory allocation during inference execution; all buffers are pre-allocated and their addresses are fixed. The result is that inference latency for a given model is bounded: the operator can know, before launch, that a particular detection pipeline will complete within a defined time window on every orbit.
This matters for mission architecture. If an operator's pipeline calls for TILE to complete an inference pass before the downlink window opens — so that detection results can be prioritized in the downlink queue — that timing requirement must be predictable. A processor that can run the model in 800 ms on average but spikes to 2,000 ms under certain conditions is not a suitable basis for that mission architecture. Determinism is a first-class design requirement, not a nice-to-have.
Form Factor and Integration
TILE is designed as a modular add-on to an existing satellite bus rather than as a custom bus architecture. The target form factor aligns with standard PC/104 stackable or CubeSat module bay dimensions, with electrical interfaces via SpaceWire and standard serial buses for command and telemetry. The intent is that TILE can be integrated into a satellite design without requiring the satellite bus vendor or the mission integrator to redesign their platform.
Model loading and updating is supported prior to launch via standard bus communication paths. Post-launch model updates are architecturally possible through the command uplink, but the bandwidth constraints and verification requirements make pre-launch model configuration the preferred path for most missions. The software interface for configuring inference pipelines is defined at the ONNX model level — operators bring their own trained model, and TILE's runtime handles the quantization and execution scheduling.
The architecture reflects a judgment that the orbital compute hardware problem is primarily a systems integration problem, not a silicon design problem. The relevant advances in commercial ML accelerator silicon are not being replicated in space-grade RHBP silicon, and the gap between commercial and space-grade performance is likely to widen further over the next decade. TILE's path is to bridge that gap through robust system-level design — hardening at the system level, not the transistor level — while making the satellite's onboard compute accessible to the operators who have the domain knowledge to use it well.
