ARIS — Propellant Control Board

ARIS — the Akademische Raumfahrt Initiative Schweiz — is the aerospace student association at ETH Zürich, where teams of more than fifty students design, build and test rockets and the propulsion systems that fly them.

Within the ARIS electronics team, my work is on the Propellant Control Board and the embedded firmware it runs, for the Asteria liquid-propellant propulsion system. I designed the board; Carl Fabian Ceccucci reviewed the layout and reorganised parts of it. Asteria is a large team effort; this board is the part of it I work on.

A liquid engine is only controllable through its plumbing. Something has to read the pressures and temperatures in the tanks and at the engine, decide what is safe, and open or close the valves that let propellant move. That is what this board does.

The Propellant Control Board is a 4-layer PCB built around an STM32G4, designed so that one board can serve three different positions in the propulsion system: at the engine, on the liquid-oxygen run tank, and on the fuel run tank. One design in three roles keeps spares, documentation and firmware manageable across a test campaign.

Sensing and actuation sit on the same board. Isolated CAN carries commands and telemetry without tying the board’s ground to the rest of the vehicle. Pressure is read both over RS485 and as analog inputs, thermocouples are read for temperature, and four solenoid channels drive the valves — each with current sensing, behind a 24 V arming path so nothing can actuate unless the system has deliberately been armed.

Isolation and current sensing are the two decisions the rest of the design leans on. Isolation keeps a fault at one tank from propagating down the bus; current sensing is what turns a valve from something you command into something you can actually observe.

Carl Fabian Ceccucci reviewed the layout and reorganised parts of it. On a board that puts isolated CAN, analogue pressure sensing and 24 V solenoid switching on the same four layers, placement is not a cosmetic question — it decides how much switching noise ends up in the measurements.

I wrote the board’s firmware in Rust, covering sensor acquisition, actuation and fault-state management — reading the pressure and thermocouple channels, driving the solenoids, and deciding what the board should do when a reading goes out of range or a command cannot be honoured.

Fault handling is most of the interesting work. Propellant hardware fails in ways that are expensive and occasionally dangerous, so the useful question is not what the board does when everything is nominal, but which state it falls into when a sensor drops out mid-sequence — and whether that state is the one a test director would have chosen.

Solenoid switching and current sensing were validated on the bench before going anywhere near propellant: commanding the channels, measuring what the current sense actually reports, and confirming that the arming path does what the schematic claims.

Bench validation is the modest end of aerospace testing and the part that decides whether the rest of a campaign is possible. A valve channel that misreports its current is a problem you want to find at a desk, not at a test stand.