- A new PLUTO transpiler converts ECSS-standard spacecraft procedure scripts into clean, runnable Python code.
- The PLUTO transpiler ships with a CLI, a live terminal UI, and a browser playground powered by Pyodide.
- The project started as a Google Summer of Code experiment in 2019 and sat dormant for nearly seven years before being finished.
- GitHub Copilot played a visible role in the resurrection, co-authoring several commits and helping resolve tricky Earley grammar bugs.
- A new PLUTO transpiler converts ECSS-standard spacecraft procedure scripts into clean, runnable Python code.
- The PLUTO transpiler ships with a CLI, a live terminal UI, and a browser playground powered by Pyodide.
- The project started as a Google Summer of Code experiment in 2019 and sat dormant for nearly seven years before being finished.
- GitHub Copilot played a visible role in the resurrection, co-authoring several commits and helping resolve tricky Earley grammar bugs.
What Is the PLUTO Transpiler — and Why Does It Matter?
The PLUTO transpiler, now available as an open-source Python package, does something quietly significant: it takes procedure scripts written in PLUTO — the domain-specific language standardised by the European Cooperation for Space Standardization under ECSS-E-ST-70-32C — and converts them into clean, readable, executable Python. For anyone working in spacecraft testing and ground operations, that’s a meaningful bridge between a specialised aerospace DSL and the most popular general-purpose language in scientific computing.
PLUTO is the language ground operators actually use. When an engineer needs to bring up a star tracker, run a parallel safety sequence, or respond to an on-board event, they write a PLUTO procedure. It’s not a hobbyist curiosity — it’s part of a formal standard used in real satellite operations. But until now, tooling around PLUTO has been thin. The new pluto-ecss package changes that in one pip install.
From a GSoC Experiment to a Working Toolchain
The backstory here is as interesting as the software itself. The project’s creator, Stelios Tzifkas, originally built a rudimentary PLUTO parser during Google Summer of Code in 2019. What he produced then was technically functional in the narrowest possible sense: two Python files, a grammar covering roughly five constructs, and an interpreter so tightly tangled with the parser that they were essentially one incoherent unit. It ran exactly one hard-coded script and threw a NameError on anything else.
The bugs were embarrassingly concrete. A setExecutionSatus typo (note the missing ‘r’). A super.__init__ call missing its parentheses. Types that were referenced but never imported. It wasn’t a foundation — it was a sketch. And so it sat on a dormant branch for nearly seven years, the kind of project you quietly stop mentioning on your CV.
What changed? Tzifkas entered the GitHub Finish-Up-A-Thon, a challenge explicitly designed to get developers to revisit and complete abandoned work. The result is pluto-ecss as it exists today: a proper PLUTO transpiler pipeline that converts source procedures into a parse tree and then emits self-contained Python, a standalone runtime library, a CLI, a terminal UI, and a browser-based playground that requires no installation whatsoever.
What the PLUTO Transpiler Actually Does
The architecture is worth unpacking. Rather than walking a parse tree at runtime — the interpreter approach Tzifkas originally tried — the PLUTO transpiler compiles PLUTO source into Python that you can read, inspect, and run independently. That’s a deliberate and sensible choice. Emitting readable Python means the output is debuggable, auditable, and doesn’t require the runtime to be present at execution time in all cases. It’s the difference between a black box and something you can actually trust in a safety-adjacent context.
The ECSS spec coverage is substantial. Tzifkas implemented steps and sub-bodies (spec section A.1.7), object property requests (A.3.9.8), contextual execution with in the context of (A.3.9.10), reporting and save-context operations (A.3.9.5 and A.3.9.25), refer by references (A.3.9.26 and A.3.9.27), record and array activity arguments (A.3.9.28), and continuation tests covering all seven defined actions plus the A.2.5 defaults (A.3.9.33). That’s not a toy implementation. It covers the constructs that matter in real operational procedures.
On top of that sits a full everyday language layer: if, case, while, for, repeat, wait until, expressions, and a runtime with concurrency primitives including parallel_until_all, wait_for_event, and watchdog support. Parallel execution matters enormously in spacecraft operations — you often need to bring up multiple subsystems simultaneously while monitoring for fault conditions — so the threading model isn’t an afterthought.
The CLI is straightforward: pluto-ecss run your_procedure.pluto executes a procedure and streams activity output to the terminal. There’s also a demo mode that lights up a simulated satellite dashboard as the procedure runs — reaction wheels spinning up, star trackers switching on and off, events firing — which is an unexpectedly compelling way to visualise what a PLUTO transpiler actually produces from a real procedure.
The Grammar Problem Was Harder Than It Sounds
One of the genuinely tricky engineering challenges in building a PLUTO transpiler is the grammar itself. PLUTO identifiers can be multi-word natural-language-style names: Star Tracker2, Reaction Wheel3 of AOC of Satellite. That creates nasty ambiguity for any parser trying to distinguish identifiers from keywords. The 2019 version used brittle negative-lookahead patterns that collapsed on common words — a hack that technically worked for one script and broke on everything else.
Tzifkas rebuilt the grammar with proper keyword-priority handling using an Earley parser, a parsing algorithm well-suited to ambiguous grammars but notoriously fiddly to tune for DSLs with heavy use of multi-token identifiers. He credits GitHub Copilot with surfacing a lexer-priority bug in the Earley implementation that would, in his words, have cost hours to track down alone. That’s a concrete, believable claim — lexer-priority interactions in Earley grammars are exactly the kind of subtle, low-level issue where an AI assistant with broad exposure to parser implementations can genuinely add value.
Copilot as a Collaborator, Not a Crutch
The role of GitHub Copilot in this project deserves honest examination. Several release commits are explicitly co-authored by Copilot, and Tzifkas is transparent about where it helped most: grinding through the repetitive _stmt_* emit methods in the parse-tree walker, drafting boilerplate for the threading and concurrency primitives, and reasoning through grammar priority edge cases. In each of these areas, the PLUTO transpiler benefited from Copilot handling the high-volume, pattern-repetitive work so Tzifkas could focus on the harder design questions.
What he’s equally clear about is what Copilot didn’t do. The architectural decisions — choosing a transpiler over an interpreter, the source directory layout, supporting multiple compile targets, the test design — were his calls. That’s the honest framing most AI-assisted development deserves: the tool is good at high-volume, pattern-repetitive work and at surfacing known bugs in known problem domains. It’s not making design decisions.
But there’s something more interesting Tzifkas notes. He describes Copilot as changing the psychology of returning to old code. The 2019 codebase was littered with bugs that, back then, each felt like a cliff-edge requiring a context switch and a debugging session. With Copilot available, fixing them flowed into the real spec work without the psychological friction of stopping and starting. That’s a subtler benefit than raw productivity — it’s about maintaining momentum on work that’s intrinsically unglamorous.
Who This Is Actually For
The obvious audience is small: aerospace engineers and ground software teams working with ECSS-compliant systems. But the broader implication is worth considering. PLUTO is a formal standard maintained by a European standards body, which means organisations building ground segment software are potentially obligated to support it. Until now, that’s meant proprietary or in-house tooling. A properly packaged, open-source PLUTO transpiler with a pip-installable runtime changes the economics of that significantly — particularly for smaller teams and research institutions that can’t justify building their own from scratch.
There’s also a developer tools angle here. The pluto-ecss playground — fully client-side, running PLUTO compilation and execution in the browser via Pyodide — is a genuinely useful demonstration of what browser-based DSL tooling can look like in 2025. No server, no sign-up, no install. Write a spacecraft procedure and watch the PLUTO transpiler execute it in real time. That’s a low-friction entry point that the aerospace software community hasn’t really had before.
Whether pluto-ecss gets traction beyond the niche it targets depends on whether the ECSS community engages with it — but the fact that a single developer rebuilt a seven-year-old skeleton into a production-quality toolchain in a focused sprint suggests the barrier to meaningful open-source aerospace tooling is lower than most assume. The real question is whether that community will show up to use it.
Source: https://dev.to/stzifkas/pluto-ecss-a-transpiler-and-runtime-for-pluto-procedure-language-5c59
