I wanted to see what it takes to build a conjunction assessment system from scratch. I wrote an orbit propagator, a screening pipeline, and a 3D globe to visualise the results. The screening algorithm matches the TraCSS answer key (spherical hard-body test cases), and the whole thing runs in the browser.

Cosmos 1408

On November 15, 2021, Russia destroyed the Cosmos 1408 satellite with a missile. The debris cloud (over 1,500 trackable fragments) passed through the ISS orbit repeatedly. The crew sheltered in their escape capsules.

ISS (blue) and Cosmos 1408 debris (red) on November 15, 2021. Orbital elements are approximate (for illustration, not operational use). The animation starts 30 minutes before closest approach and runs at 60x speed. Drag to rotate, scroll to zoom.

This is the kind of event conjunction assessment exists to predict. Two objects in low Earth orbit approach each other at 10-15 km/s. Ground stations track both, but no position estimate is exact. Each one comes with an uncertainty envelope: not "the satellite is here", but "the satellite is probably within this region". Collision prediction takes those two uncertain positions at the moment of closest approach and computes a probability: how likely is it that the objects actually overlap? If the probability exceeds a threshold (typically 1 in 10,000), the operator fires thrusters to move out of the way.

The maths for computing that probability are well understood (a 2D integral over projected uncertainties, first published by Foster and Estes in 1992). The hard part is not the algorithm. It is knowing whether your implementation is correct. Getting a number is easy. Trusting the number requires open specifications you can read, and test data you can run your code against. Until recently, neither was easy to get.

Five components, one pattern

A conjunction assessment system needs five things:

Orbit propagation. Given a satellite's orbital elements (published as Two-Line Element sets on Space-Track and other catalogues), predict where it will be at any future time. The standard algorithm is SGP4 (Spacetrack Report #3), designed by NORAD in the 1980s and still the baseline for all catalogued objects. Vallado's Revisiting Spacetrack Report #3 is the modern reference; the TraCSS verification dataset provides test vectors.

Coordinate transforms. The propagator outputs positions in one reference frame, the collision geometry needs another, and the visualisation needs a third. Each conversion involves Earth rotation models and is easy to get subtly wrong. The IAU SOFA library documents the standard algorithms; Vallado's Fundamentals of Astrodynamics and Applications covers the practical implementation.

Message parsing. Collision warnings arrive as Conjunction Data Messages (CDMs), defined in CCSDS 508.0-B-1. A CDM contains the predicted time of closest approach, the miss distance, the relative speed, the uncertainty envelopes for both objects, and metadata about the data source. The CDM format is another CCSDS standard, similar to the ones I described in the wire formats post. There are at least three serialisation variants in active use (CSV from TraCSS, JSON from Space-Track, and the CCSDS text standard).

Probability computation. Project the two 3D uncertainty envelopes onto the plane where collisions happen (perpendicular to the relative velocity), then integrate the overlapping region. The result is a single number: the probability of collision. Foster and Estes (1992) describes the 2D method; the TraCSS dataset includes spherical test cases with expected results for validation.

Visualisation. Render the orbital geometry so an operator can see what is happening. Two satellites converging at 14 km/s look identical in a spreadsheet; on a globe, the crossing geometry is obvious. For an operator deciding whether to manoeuvre in a window of minutes, visual context matters.

The five components are standalone: I can test each one against its own reference data before connecting them. Without Vallado's test vectors I would not know if my propagator is correct; without the TraCSS dataset I would not know if my probability code gives the right answer. We learnt this in the MirageOS community when we built an email parser and had to release a corpus of a million messages because nobody had public test data. Open standards need open test data.

ssa.space

The result is ssa.space, a conjunction assessment dashboard. It loads the TraCSS verification dataset, propagates every tracked object, computes the collision probability for each close approach, and renders the results on a 3D globe. Close approaches are colour-coded by risk: red for dangerous, orange for watch-list, green for low. Click one to zoom in and see the orbital geometry at the moment of closest approach.

This runs on test data today (the TraCSS dataset includes difficult cases but is not live operational data). The entire stack is pure OCaml with no system dependencies, so it runs in the browser (via js_of_ocaml), on a server, and could run as a MirageOS unikernel on a satellite (the same architecture I described in the ASPLOS post). That is the direction we are pursuing with SpaceOS.

Today, collision avoidance runs through ground stations. A conjunction warning arrives 24-72 hours before closest approach, but the ground loop (downlink, screening, decision, command uplink) can consume most of that window. If the satellite runs the same screening algorithm on board, it can flag close approaches and pre-compute candidate manoeuvres before the next ground contact. The ground still approves, but time to first assessment drops to seconds.

What comes next

The application is live at ssa.space. The underlying libraries (sgp4, coordinate, cdm, collision, globe, cam) are work in progress and will be properly open-sourced when a full review is completed (currently validating against GMAT, NASA's General Mission Analysis Tool). The immediate goal is live data from TraCSS, Stargaze, or EUSST. If you have ephemeris data or screening results, get in touch.

That meant porting Tailwind's CSS generation to OCaml. To make sure the port was correct, I needed to compare its CSS output against the JavaScript original. The existing CSS diff tools are either abandoned or limited to CSS 2/3, and none of them handle @layer, container queries, nesting, or the modern colour spaces that Tailwind v4 generates. So I started writing one. Which needed a complete parser. Which grew into a typed AST and an optimiser, and ended up being useful on its own.

The result is Cascade, a 30,000-line OCaml library for parsing, generating, optimising, and diffing CSS. One of the tools it ships is cssdiff, a structural CSS comparison tool. Since Cascade is pure OCaml, it can be compiled to JavaScript via js_of_ocaml and run in the browser. Try it, or pick one of the examples below:

The toolkit

Cascade parses CSS strings into a typed AST, and provides a small eDSL to build the same AST from OCaml code. From that AST, it can render (pretty-print or minify), optimise (deduplicate and merge rules), and structurally diff two stylesheets. The parser uses hand-written recursive descent (does Claude have hands?) covering CSS Syntax Level 3 through Level 4 and 5 (modern selectors, colour spaces, @layer, container queries, nesting).

let css = Cascade.Css.of_string {|
  .btn {
    display: inline-block;
    background-color: #3b82f6;
    color: white;
    padding: 0.5rem;
  }
  .btn {
    background-color: #2563eb;
  }
|}

open Cascade.Css

let btn = Selector.class_ "btn"

let rules =
  [ rule ~selector:btn
      [ display Inline_block
      ; background_color (hex "#3b82f6")
      ; color (hex "#ffffff")
      ; padding (Rem 0.5) ]
  ; rule ~selector:btn
      [ background_color (hex "#2563eb") ] ]

.btn {
  display: inline-block;
  background-color: #3b82f6;
  color: #fff;
  padding: 0.5rem;
}
.btn {
  background-color: #2563eb;
}

.btn {
  display: inline-block;
  background-color: #2563eb;
  color: #fff;
  padding: 0.5rem;
}

The .btn example uses a few properties, but the library has 100+ typed constructors covering layout (box model, flexbox, grid), visual (typography, transforms, animations, filters), and logical properties.

Testing against Tailwind

How do you know a CSS parser is correct? The usual answer is "read the spec", and the W3C test suite covers parsing for individual features. But those tests check that browsers apply CSS correctly, not that a tool can safely transform it. How do you know that merging two rules across cascade layers or deduplicating a property does not change what the page looks like?

One approach that I found works well in practice is differential comparison against a reference implementation. For instance, to port Tailwind to OCaml, I run the JavaScript Tailwind CLI on the same input, then run the OCaml port, and compare the two CSS outputs byte for byte. The comparison is strict: same characters, same order, same whitespace. Not "structurally equivalent" (that would hide bugs in the comparison tool itself).

When the outputs diverge (and they do, constantly, during development), I need to know which rule changed and how. A 50,000-line string diff is unreadable. That is what cssdiff is for: a structural diff that says "rule .mt-4 changed margin-top from 1rem to 16px" is actionable. It works at the AST level, so a rule that moved from line 10 to line 200 shows as reordered, not as a deletion plus an addition. It handles @media, @layer, @supports, and @container blocks. This is the same tool running in the demo above.

The byte-for-byte target also keeps the optimiser honest. It would be easy to produce "correct" CSS that differs in harmless ways (different property order, different hex capitalisation). But allowing those differences means the diff tool would need to know which differences are harmless, which is exactly the kind of subtle bug that hides semantic errors. Matching the reference output exactly eliminates that class of problems.

Getting started

Two CLI tools ship with the library: cascade (format, minify, optimise CSS files) and cssdiff (structural comparison).

brew install samoht/tap/cascade

Or via opam:

opam pin add cascade https://github.com/samoht/cascade.git

The library requires OCaml 4.14 or later. The README has the full API overview and CSS specification coverage table.

I wrote Cascade because I needed it for my blog. It turned out to be useful beyond that: any OCaml project that generates, parses, or compares CSS now has a typed alternative to string manipulation. The source is on GitHub.

EverParse has a good answer to that problem, for on-earth software. It generates C validators and parsers with proofs of memory safety, arithmetic safety, double-fetch freedom, and correctness. It is part of Microsoft's Project Everest, which ran from 2016 to 2021 around F* (a dependently typed language from the ML family) and produced software that ended up in the Windows kernel, Hyper-V, Linux, Firefox, and Python.

The EverParse compiler seems like a perfect fit for embedded satellite software. I wanted to try it, but I did not want to write .3d files by hand (how do you maintain those? and how do you write serialisers from them?). So I wrote ocaml-wire, a combinator library that lets me describe a format once in OCaml, automatically write zero-allocation (when possible) parser and serialiser codecs, and generate the .3d schema and C glue from the same description.

I will use CCSDS Space Packets as the running example, because they are small, bitfield-heavy, and annoying to parse by hand.

EverParse

For a CCSDS Space Packet header, the .3d format is already close to the specification:

module SpacePacket

typedef struct SpacePacket {
  UINT16BE Version:3;
  UINT16BE Type:1;
  UINT16BE SecHdrFlag:1;
  UINT16BE APID:11;
  UINT16BE SeqFlags:2;
  UINT16BE SeqCount:14;
  UINT16BE DataLength;
} SpacePacket;

You can read this as two 16-bit words of bitfields, followed by a 16-bit DataLength field. EverParse turns this into a C validator you could link into flight software. The guarantees are useful: memory safety, arithmetic safety, double-fetch freedom, and correctness with respect to the .3d specification. They do not prove that the .3d file matches the blue book, nor that the C extraction from F* or the C compiler are bug-free. Still, this is exactly the kind of low-level code where mistakes hurt.

What .3d does not give me is the OCaml side. I would still need separate code for decoding, encoding, and field access.

The Same Header in OCaml

ocaml-wire lets me describe the same header once in OCaml, then use it directly in OCaml and project it to EverParse .3d. It can also generate the OCaml/C glue to call the verified validator. So, for the Space Packet primary header at least, I get an OCaml codec and a C validator from the same source.

Define named fields with Field.v, bind them to record projections with $, and assemble a codec with Codec.v:

open Wire

type packet = {
  version : int; type_ : int; sec_hdr : int; apid : int;
  seq_flags : int; seq_count : int; data_len : int;
}

let f_version   = Field.v "Version"    (bits ~width:3  U16be)
let f_type      = Field.v "Type"       (bits ~width:1  U16be)
let f_sec_hdr   = Field.v "SecHdrFlag" (bits ~width:1  U16be)
let f_apid      = Field.v "APID"       (bits ~width:11 U16be)
let f_seq_flags = Field.v "SeqFlags"   (bits ~width:2  U16be)
let f_seq_count = Field.v "SeqCount"   (bits ~width:14 U16be)
let f_data_len  = Field.v "DataLength"  uint16be

(* Bind fields before building the codec. The same bound fields are then
   reused for get/set. *)
let bf_version   = Codec.(f_version   $ fun p -> p.version)
let bf_type      = Codec.(f_type      $ fun p -> p.type_)
let bf_sec_hdr   = Codec.(f_sec_hdr   $ fun p -> p.sec_hdr)
let bf_apid      = Codec.(f_apid      $ fun p -> p.apid)
let bf_seq_flags = Codec.(f_seq_flags $ fun p -> p.seq_flags)
let bf_seq_count = Codec.(f_seq_count $ fun p -> p.seq_count)
let bf_data_len  = Codec.(f_data_len  $ fun p -> p.data_len)

let packet_codec =
  let open Codec in
  v "SpacePacket"
    (fun version type_ sec_hdr apid seq_flags seq_count data_len ->
      { version; type_; sec_hdr; apid; seq_flags; seq_count; data_len })
    [ bf_version;
      bf_type;
      bf_sec_hdr;
      bf_apid;
      bf_seq_flags;
      bf_seq_count;
      bf_data_len ]

The generated .3d is a projection of that OCaml description. It is not a second source of truth:

entrypoint
typedef struct _SpacePacket(mutable WireCtx *ctx)
{
   UINT16BE Version : 3 {:act WireSetU16BE(ctx, (UINT32) 0, Version); };
   UINT16BE Type : 1 {:act WireSetU16BE(ctx, (UINT32) 1, Type); };
   UINT16BE SecHdrFlag : 1 {:act WireSetU16BE(ctx, (UINT32) 2, SecHdrFlag); };
   UINT16BE APID : 11 {:act WireSetU16BE(ctx, (UINT32) 3, APID); };
   UINT16BE SeqFlags : 2 {:act WireSetU16BE(ctx, (UINT32) 4, SeqFlags); };
   UINT16BE SeqCount : 14 {:act WireSetU16BE(ctx, (UINT32) 5, SeqCount); };
   UINT16BE DataLength {:on-success WireSetU16BE(ctx, (UINT32) 6, DataLength);
                         return true; };
} SpacePacket;

The annotations in the output show how EverParse uses the codec at validation time. :act writes each validated field value into an output structure (via the WireSet* callbacks); :on-success is the longer form that can conditionally fail. So the generated C parser validates and extracts in a single pass.

The same codec also gives zero-copy field access on the OCaml side:

(* Stage once, reuse the closure *)
let get_apid = Staged.unstage (Codec.get packet_codec bf_apid)
let set_seq  = Staged.unstage (Codec.set packet_codec bf_seq_count)

let apid = get_apid buf 0        (* zero allocation for int fields *)
let () = set_seq buf 0 42        (* read-modify-write for bitfields *)

(* Full record decode/encode when needed *)
let pkt = Result.get_ok (Codec.decode packet_codec buf 0)
let () = Codec.encode packet_codec pkt buf 0

The Space Packet header has a fixed layout, but many formats have variable-length payloads. For those, dependent sizes use Field.ref to let one field's value determine the size of another:

let f_len  = Field.v "Length" uint16be
let f_data = Field.v "Data" (byte_array ~size:(Field.ref f_len))

Testing against C

The same description drives testing against the C path:

let schema = Everparse.schema packet_codec
let () = Wire_3d.run ~outdir:"schemas" [ schema ]
let () = Wire_stubs.generate ~schema_dir:"schemas" ~outdir:"."
           [ C packet_codec ]

Wire_3d.run writes the .3d files, invokes EverParse, and produces C validators. Wire_stubs.generate writes the OCaml/C FFI glue (external declarations and C stubs) so OCaml code can call the verified validators directly.

The fuzz/ tests use Crowbar to check that the OCaml codec does not crash on random input. Separately, test/diff/ generates random schemas, runs EverParse to produce C validators, and checks that OCaml and C agree on every random input. One OCaml description defines the codec, the schema, and the test oracle.

Performance

Describing a format is one thing; the question is whether the generated codec stays fast enough for real-time packet processing. The benchmarks below measure three common operations (routing, frame reassembly, status polling) and compare the Wire OCaml path with C loops built on EverParse validators (generated from the same OCaml codecs). The protocols come from CCSDS (Space Packets, TM Frames, CLCW words), which travel over SpaceWire links at up to 200 Mbit/s.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Versi|T|S|        APID         |Seq|         SeqCount          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          DataLength           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |C|CLC|Statu|COP|   VCID    |Spare|N|N|L|W|R|FAR|  ReportValue  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ver|       SCID        |VCID |O|    MCCount    |    VCCount    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |S|S|P|Seg|     FirstHdrPtr     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The chart below shows wall-clock time per operation (lower is better). Each benchmark has two bars: the C baseline (blue, using EverParse validators) and the Wire OCaml path (orange). The ratio column shows how much slower (or faster) Wire is compared to C. A ratio below 1.0 means Wire wins.

Reading the chart from top to bottom: packet routing is 2.6x slower than C, which sounds like a lot until you note that 14.1 ns per packet gives 71 Mpkt/s (a SpaceWire link at 200 Mbit/s with 128-byte packets carries roughly 200 kpkt/s, so Wire has 350x headroom). Frame reassembly is at parity. And status polling is the surprise: Wire is faster than C.

One caveat: the C baseline uses EverParse validators that extract all fields (7 for a Space Packet, 13 for a CLCW word), while the OCaml path uses Staged.unstage (Codec.get ...) to read only the fields it needs. That makes the comparison slightly unfair to C, but it reflects how the two paths would be used in practice. Wire wins on CLCW precisely because it loads the 4-byte word once and extracts only the 4 fields the polling loop needs.

Additional per-field micro-benchmarks confirm the pattern. Reading an 11-bit bitfield like SpacePacket.apid takes 3.4 ns with zero allocation. Writing a bitfield (read-modify-write) runs at 2–3 ns.

The remaining 2.5x gap in routing comes from three sources of overhead in OCaml's runtime:

• Function dispatch. The staged field readers are closures, not inlined code. Each call goes through an indirect dispatch (about 11 extra instructions per call).
• Thread-safety barriers. OCaml 5 inserts memory barriers on every mutable write to support multicore. C writes are plain stores.
• Register pressure. The compiler cannot keep state in registers across closure calls, so it spills to the stack between reads.

None of this is specific to Wire. It is the cost of OCaml 5's runtime model. OxCaml would address all three (unboxed closures, thread-local stores, better register allocation across calls), but that is the story for another post.

Getting started

To try the examples from this post, clone the repo and build:

git clone https://github.com/parsimoni-labs/ocaml-wire.git
cd ocaml-wire
opam install . --deps-only
dune build

The library requires OCaml 5.1 or later. The codec definitions from this post are in examples/space (Space Packet, CLCW, TM Frame); examples/net does the same for Ethernet, IPv4, TCP, and UDP. Generating .3d files works out of the box; compiling them into verified C needs EverParse (3d.exe in PATH).

Satellite protocols have many binary formats: Space Packets, TM frames, CLCW words, telecommand segments, and more. I do not want to write C parsers and serialisers for each of them by hand. I want to describe the format once in OCaml, get a codec I can use and compose the layers directly, and generate the EverParse .3d and C glue from the same source. ocaml-wire is still experimental, but I already find it quite useful (if only to get ASCII art diagrams of packet headers :-). With OxCaml closing the remaining routing gap, the C side might matter even less (apart from differential testing against a formally verified parser). If you want to try it, the repo is here.

Last month I spent a week in Southern California visiting the people who build satellites. One morning I dropped my daughter at pre-school and walked to the building next door, where fifteen satellites were in simultaneous integration at different stages of assembly. That is what the LA space industry looks like: it is just there, woven into the neighbourhood. Another factory nearby was targeting high-volume production with a backlog of over forty spacecraft. A space avionics manufacturer we have since partnered with, whose hardware has flown on dozens of missions over twenty years. Engineers at NASA/JPL developing a reusable flight software framework. Teams from Techstars Space building ground segment tooling and application software that will run on other people's satellites. All of this within an hour's drive of each other. And the questions were different from 2022 -- not "could this work?" but "how big is the binary, what RTOS do you replace, how do you handle OTA updates, what does your security compliance story look like?"

Launch costs are falling and production volumes are rising, and how you produce space software at scale has to keep up. Ideas I have spent years on (library operating systems, building software that is correct by construction) are turning out to be well-timed. I am looking forward to sending more OCaml code to space this year. Ping me if you are interested ;-)

So I wrote ofpp to test this idea. It parses the complete FPP grammar and generates MirageOS wiring code from FPP topology files. The generated code compiles against the real MirageOS libraries, and NASA's reference fpp-check tool accepts the same .fpp files unchanged. FPP's dependency graph maps directly to OCaml functors, so the rest of the post walks through that mapping.

ofpp is a prototype, not a replacement for the mirage tool or for Functoria -- I built it to explore what a shared architecture language between F Prime and MirageOS could look like.

The mapping

Here is UnixHelloKey, a unikernel that takes a --hello command-line flag (source):

passive component Unikernel {
  async input port start: serial
  param hello: string default "Hello World!"
}

instance unikernel: Unikernel base id 0

topology UnixHelloKey {
  instance unikernel
}

let hello_0 =
  let doc = Cmdliner.Arg.info ~doc:"hello" ["hello"] in
  Mirage_runtime.register_arg
    Cmdliner.Arg.(value & opt string "Hello World!" doc)

let start = lazy (Unikernel.start ~hello:(hello_0 ()))

let () =
  let t =
    let open Lwt.Syntax in
    (* Mirage_runtime init ... *)
    let* _ = Lazy.force start in
    Lwt.return ()
  in
  Unix_os.Main.run t; exit 0

The FPP instance unikernel resolves to the OCaml module Unikernel by convention (capitalised). The param hello declaration generates a Cmdliner term (hello_0) that becomes the --hello command-line flag, passed as a labelled argument to Unikernel.start.

$ dune exec examples/mirage/tutorial/hello-key/main.exe
2026-03-04T13:52:57-08:00: [INFO] [application] Hello World!
...
$ dune exec examples/mirage/tutorial/hello-key/main.exe -- \
    --hello='Bonjour\ MirageOS!'
2026-03-04T13:53:08-08:00: [INFO] [application] Bonjour MirageOS!
...

ofpp handles wiring only. Type safety comes from the OCaml module system: the generated functor applications must type-check against the MirageOS library signatures, so a miswired topology is a compile error.

config.ml vs config.fpp

In MirageOS, each unikernel has a config.ml that describes its device dependencies using Functoria combinators. In FPP, each unikernel has a config.fpp that describes the same dependencies as a connection graph. Here is the network example -- a unikernel that needs a TCP/IP stack:

open Mirage

let main =
  main "Unikernel.Main" (stackv4v6 @-> job)
let stack = generic_stackv4v6 default_network
let () = register "network" [ main $ stack ]

module Unikernel {
  passive component Main {
    async input port start: serial
    output port stack: serial
  }
}

instance unikernel: Unikernel.Main base id 0

topology UnixNetwork {
  import SocketStack
  instance stackv4v6
  instance unikernel

  connections Start {
    unikernel.stack -> stackv4v6.connect
  }
}

The Functoria DSL hides the stack implementation behind generic_stackv4v6. The FPP topology makes it explicit: import SocketStack pulls in a sub-topology that wires Udpv4v6_socket and Tcpv4v6_socket into Stackv4v6.Make. The connection unikernel.stack -> stackv4v6.connect declares that the unikernel depends on the stack.

The FPP version is more verbose. Functoria's combinators are more concise for pure OCaml projects, and generic_stackv4v6 picks the right implementation for each target automatically (FPP makes you spell that out). The payoff is that the topology is a standalone graph, not embedded in OCaml. The same .fpp files can drive C++ code generation, and the connection graph is available for visualisation and tooling.

The device catalogue

Device components live in a shared mirage.fpp. Here are three of the devices used in the UnixPing6 topology shown below:

module Vnetif {
  passive component Make {
    import Mirage_net.S
    output port backend: serial
  }
}

module Ethernet {
  passive component Make {
    import Ethernet.S
    output port net: serial
  }
}

module Ipv6 {
  passive component Make {
    import Tcpip.Ip.S
    async input port connect: Ipv6Connect
    output port net: serial
    output port eth: serial
  }
}

Each FPP construct maps to a specific OCaml concept.

Output ports are functor arguments. Vnetif.Make has one output port (backend), so its generated functor takes one argument: Vnetif.Make(Backend). Ipv6.Make has two (net and eth), so its functor takes two: Ipv6.Make(Net)(Ethernet). The topology connections decide which instance fills each argument.

import declarations are module type constraints. import Mirage_net.S on Vnetif.Make tells ofpp to generate module type Net = Mirage_net.S in the output. The OCaml compiler then checks that the concrete module satisfies that signature.

Port types encode connect signatures. Ipv6Connect is defined elsewhere in mirage.fpp as port Ipv6Connect(conf: Ipv6Conf), so Ipv6.connect takes a labeled ~conf argument. Positional parameters (like _0: string) generate positional arguments instead.

The generated code for UnixPing6 uses all three:

(* from import declarations *)
module type Backend = Vnetif.BACKEND
module type Net = Mirage_net.S
module type Ethernet = Ethernet.S
module type Ipv6 = Tcpip.Ip.S

(* from topology connections + output ports *)
module Net = Vnetif.Make(Backend)
module Ethernet = Ethernet.Make(Net)
module Ipv6 = Ipv6.Make(Net)(Ethernet)

(* from connect port types + connection order *)
let* backend = Backend.connect () in
let* net = Net.connect backend in
let* ethernet = Ethernet.connect net in
let* ipv6 = Ipv6.connect net ethernet in

If a connection is missing, it does not compile.

A larger example

Here is UnixPing6, an IPv6 ping unikernel wired through a virtual network (source):

module Unikernel {
  passive component Main {
    async input port start: serial
    output port net: serial
    output port eth: serial
    output port ipv6: serial
  }
}

instance unikernel: Unikernel.Main base id 0

topology UnixPing6 {
  instance backend
  instance net
  instance ethernet
  instance ipv6
  instance unikernel

  connections Connect {
    net.backend -> backend.connect
    ethernet.net -> net.connect
    ipv6.net -> net.connect
    ipv6.eth -> ethernet.connect
  }
  connections Start {
    unikernel.net -> net.connect
    unikernel.eth -> ethernet.connect
    unikernel.ipv6 -> ipv6.connect
  }
}

module type Backend = Vnetif.BACKEND
module type Net = Mirage_net.S
module type Ethernet = Ethernet.S
module type Ipv6 = Tcpip.Ip.S

module Net = Vnetif.Make(Backend)
module Ethernet = Ethernet.Make(Net)
module Ipv6 = Ipv6.Make(Net)(Ethernet)
module Unikernel = Unikernel.Main(Net)(Ethernet)(Ipv6)

open Lwt.Syntax

let connect = lazy (
  let* backend = Backend.connect () in
  let* net = Net.connect backend in
  let* ethernet = Ethernet.connect net in
  let* ipv6 = Ipv6.connect net ethernet in
  Lwt.return (net, ethernet, ipv6))

let start = lazy (
  let* (net, ethernet, ipv6) = Lazy.force connect in
  Unikernel.start net ethernet ipv6)

(* Mirage_runtime init, then: *)
let* _ = Lazy.force start in ...

Sub-topology composition

Sub-topologies are shared via import. The DNS example imports the socket stack and wires additional layers on top:

topology UnixDns {
  import SocketStack          @ pulls in Udpv4v6_socket, Tcpv4v6_socket, Stackv4v6
  instance stackv4v6
  instance happy_eyeballs_mirage
  instance dns_client
  instance unikernel

  connections Connect_device {
    happy_eyeballs_mirage.stack -> stackv4v6.connect
  }
  connections Start {
    dns_client.stack -> stackv4v6.connect
    dns_client.happy_eyeballs -> happy_eyeballs_mirage.connect_device
    unikernel.dns -> dns_client.start
  }
}

The generated main.ml chains the socket stack connect, then connect_device for Happy Eyeballs, then start for the DNS resolver -- each connection group becomes a lazy binding that forces its dependencies:

module type Udpv4v6_socket = Tcpip.Udp.S
module type Tcpv4v6_socket = Tcpip.Tcp.S
module type Stackv4v6 = Tcpip.Stack.V4V6
module type Happy_eyeballs_mirage = Happy_eyeballs_mirage.S
module type Dns_client = Dns_client_mirage.S

module Stackv4v6 = Stackv4v6.Make(Udpv4v6_socket)(Tcpv4v6_socket)
module Happy_eyeballs_mirage = Happy_eyeballs_mirage.Make(Stackv4v6)
module Dns_client = Dns_resolver.Make(Stackv4v6)(Happy_eyeballs_mirage)
module Unikernel = Unikernel.Make(Dns_client)

let connect = lazy (
  let* udpv4v6_socket = Udpv4v6_socket.connect ~ipv4_only:false ... in
  let* tcpv4v6_socket = Tcpv4v6_socket.connect ~ipv4_only:false ... in
  Stackv4v6.connect udpv4v6_socket tcpv4v6_socket)

let connect_device = lazy (
  let* stackv4v6 = Lazy.force connect in
  let* happy_eyeballs_mirage = Happy_eyeballs_mirage.connect_device stackv4v6 in
  Lwt.return (stackv4v6, happy_eyeballs_mirage))

let start = lazy (
  let* (stackv4v6, happy_eyeballs_mirage) = Lazy.force connect_device in
  let* dns_client = Dns_client.start stackv4v6 happy_eyeballs_mirage in
  Unikernel.start dns_client)

This is something Functoria's flat combinator model does not express cleanly: named sub-topologies that can be imported and reused across unikernels, with cross-boundary connections wired by the parent topology.

Target switching

In MirageOS, you write your application once and compile it for different platforms without changing application code. mirage configure -t unix wires in the kernel's TCP/IP stack; -t hvt wires in MirageOS's own protocol implementations running on a virtual network device. In FPP, each target is simply a different topology.

Shared sub-topologies (TcpipStack, SocketStack, DnsStack) are imported and reused across variants. The caller picks the target by passing it to ofpp:

ofpp to-ml --topologies UnixHello mirage.fpp tutorial/hello/config.fpp
ofpp to-ml --topologies UnixDns --target unix mirage.fpp applications/dns/config.fpp

The --target flag selects the OS main loop: unix (default), xen, solo5, or unikraft. The codegen emits the appropriate entry point -- Unix_os.Main.run, Xen_os.Main.run, Solo5_os.Main.run, or Unikraft_os.Main.run. Target switching in ofpp is very experimental for now: only the Unix target has been tested end-to-end.

Mixing C++ and OCaml components

ofpp already works for building MirageOS unikernels on the Unix backend: describe the topology in FPP, run ofpp to-ml, compile. The interesting next step is mixing C++ F Prime components with OCaml MirageOS components in the same topology.

Three pieces are missing. First, binary serialisation: ofpp already generates OCaml types from FPP enums, structs, and arrays, but matching C++'s wire format for command, telemetry, and event dispatch is not done yet. Second, FFI stubs: I have early experiments with OCaml components running inside F Prime over caml_callback, but they are not ready to open-source. Third, build integration: I have a working (if ugly) CMake + dune bridge, though a cleaner solution might come from Package Managers à la Carte (pre-print).

The end goal: run OCaml components on isolated MirageOS platforms (Solo5, Muen, Unikraft, seL4) inside F Prime deployments, and let MirageOS unikernels integrate with existing C++ flight software.

State machines

FPP also has state machines. ofpp generates typed OCaml modules from them: states become a GADT, signals become a variant, and guards and actions become functor parameters. Here is a toy example:

state machine Door {
  action lock
  guard locked
  signal open
  signal close
  initial enter Closed
  state Closed {
    on open if locked enter Closed
    on open enter Opened
  }
  state Opened {
    on close do { lock } enter Closed
  }
}

type closed
type opened

type _ state =
  | Closed : closed state
  | Opened : opened state

type signal = Open | Close

module type ACTIONS = sig
  type ctx
  val lock : ctx -> unit
end

module type GUARDS = sig
  type ctx
  val locked : ctx -> bool
end

module Make
  (A : ACTIONS)
  (G : GUARDS with type ctx = A.ctx) :
sig
  type t
  val create : A.ctx -> t
  val state : t -> any
  val step : t -> signal -> t
end

Phantom types index the GADT, so pattern matching in step is exhaustive. The caller supplies ACTIONS and GUARDS as functor arguments. ofpp also renders state machines as Graphviz diagrams. In F Prime, components can embed state machine instance declarations that connect a state machine to the component's lifecycle; ofpp does not wire those up fully yet.

ofpp

The tool is called ofpp. I started it in February at the JPL workshop. Rob Bocchino designed FPP with a formal specification and an upstream test suite of 670 .fpp files across 35 categories, which I used to validate the parser. The parser covers the complete FPP grammar (zero conflicts).

The whole thing is about 19k lines of OCaml: 1k for the parser and lexer, 8k for the checker, 2.7k for the code generator, and the rest for tests. ofpp also exports topology graphs to fprime-visual. The example repo covers all of mirage-skeleton: tutorials, device examples, and applications like DNS, DHCP, and Git. Every example has a cram test that builds the unikernel and exercises it.

ofpp is not affiliated with NASA or JPL. It is an independent experiment. If you work with FPP or MirageOS and want to try it:

# macOS
brew tap parsimoni-labs/tap && brew install ofpp

# from source
opam pin add fpp https://github.com/parsimoni-labs/ocaml-fpp.git

ofpp check path/to/file.fpp
ofpp to-ml path/to/file.fpp
ofpp dot path/to/file.fpp | dot -Tsvg -o sm.svg

If you have a MirageOS config.ml, try describing the same topology in FPP and compare the generated main.ml with what Functoria produces. File issues on GitHub.

To understand where the gaps are, it helps to separate the two halves of the stack. Bus software (attitude control, power, thermal) runs on qualified RTOSes and is the satellite manufacturer's domain. Payload software (imaging, communications, data processing) increasingly runs on COTS (commercial off-the-shelf) processors with memory management units (MMUs) perfectly capable of enforcing memory isolation. For LEO missions on COTS hardware, the hardware is there. The software running on it does not use it.

I think three things are missing for anyone wanting to run hosted payloads or patch software in orbit safely:

1. Hardware-enforced memory isolation between payloads and flight software, either through a hypervisor (like Xen or KVM) or a separation kernel (seL4 has a formal proof of functional correctness on specific hardware configurations). Both use the MMU to ensure a compromised payload cannot reach the bus.

2. A standard OTA deployment format so "install this application" means the same thing across different satellites: cryptographically signed, designed for 10-minute LEO pass windows and partial transfers.

3. A metered runtime that enforces resource quotas (CPU, memory, storage, bus bandwidth) so one payload cannot starve the others. Resource requirements should be declarative, embedded in the deployment image, and verified before installation.

The tools to address much of this exist in the terrestrial world: memory-safe languages (roughly 70% of CVEs in large C/C++ codebases are memory-safety issues, a figure consistent across Microsoft, Google, and Android since 2019), verified cryptography, minimal single-purpose OS images. These are not theoretical: Google cut Android memory-safety vulnerabilities by 76% in six years by writing new code in memory-safe languages, and AWS runs millions of serverless workloads on Firecracker, a 50,000-line Rust VMM that boots in under 125 ms. None of these have made it into flight software yet, even as the number of spacecraft in orbit (and the attack surface) has grown sharply. Space Odyssey examined three satellites and found vulnerabilities in all of them, and those are only the ones someone bothered to look for.

Mass launched to orbit (blue) versus publicly disclosed satellite software vulnerabilities (red bars, from CVE/NVD and conference disclosures; data and sources). The gap between the curves is the problem: launch volume has exploded, security scrutiny has barely started.

The evidence is mounting. None of the Space Odyssey satellites had ASLR, stack canaries, or DEP; one had no authentication on its telecommand interface. The Viasat/KA-SAT attack in February 2022 disrupted Ukrainian communications and 5,800 German wind turbines, making the threat operational (Boschetti, Gordon and Falco, ASCEND 2022). At Black Hat 2025, a vulnerability assessment of NASA's core Flight System (cFS) found remote code execution, path traversal, and denial-of-service, all from textbook C memory bugs. NASA's own CryptoLib, the reference implementation of CCSDS encryption, has had recurring buffer overflows in its parsing code (CVE-2025-29909, CVSS 9.8). A memory-safe language eliminates these classes of bug by construction.

The pattern across all of these is consistent: space software engineering has a safety-versus-security bias (Pavur and Martinovic, J. Cybersecur. 2022; Falco, JAIS 2019). Systems are designed for availability and determinism (watchdogs, radiation tolerance, FDIR). Integrity and confidentiality are secondary. This is not irrational: a satellite that loses attitude control is a more immediate problem than one that leaks telemetry. But it leaves software stacks undefended against adversarial threats. Jero et al. (NDSS SpaceSec 2024) proposed a defence-in-depth taxonomy -- secure boot, memory protection, authenticated updates, compartmentalisation -- that overlaps substantially with the three gaps above.

So why does the current stack not provide the three things above? Most small-sat payload software runs on VxWorks, RTEMS, embedded Linux (Yocto, Buildroot), or bare metal. The RTOS path typically runs everything in a single address space: the hardware has an MMU, but most CubeSat missions do not enable memory protection because it requires rethinking memory management, interrupt handling, and DMA buffer allocation. This is exactly the architecture Space Odyssey found vulnerable. Embedded Linux gives you process isolation, but hardening it for multi-tenancy and certifying it for flight remains a substantial undertaking. ESA's OPS-SAT demonstrated deploying new applications before its re-entry in 2024, but it remains the exception.

The isolation and metering techniques are not new. Cloud infrastructure solved analogous problems years ago, and avionics systems (ARINC 653, DO-178C) have their own qualified solutions. The gap is in LEO payload software, where neither stack fits: the cloud stack assumes abundant resources, the avionics stack assumes a single operator and a multi-year qualification budget. I am not going to minimise how much work qualification (under ECSS-Q-ST-80C or equivalent) requires. Calabrese, Kavallieratos and Falco (SCITECH 2024) emulated a cyberattack from a hosted payload on OPS-SAT that compromised the bus, demonstrating why isolation matters. But a real multi-tenant satellite also needs FDIR (Fault Detection, Isolation, and Recovery) integration, thermal management, power budgeting, and link budget allocation. I am focusing on the software infrastructure, but I do not want to pretend the problem ends there.

The regulatory pressure is new. The EU Cyber Resilience Act is pushing toward stronger isolation and update mechanisms. ENISA is calling out the space sector. The White House called for memory-safe languages in critical infrastructure in 2024, a recommendation that applies to flight software as much as to anything on the ground. OCaml, the language Parsimoni and Tarides use, is memory-safe in its default fragment. And the hardware is finally there: radiation-tolerant processors with enough compute for on-board processing are commercially available at CubeSat price points. The missing piece is the software infrastructure.

These are the problems I co-founded Parsimoni to work on. Our payload software platform, SpaceOS, builds on the OCaml ecosystem that Tarides maintains. Our first payload reached orbit on SpaceX Transporter-13 in March 2025. If you are building payload software and running into these constraints, or if you are an operator considering hosted payloads, we would like to hear from you: get in touch.

Five properties fell out of that architecture. None of them are unique to unikernels (a careful Yocto configuration can achieve most of them), but unikernels make them the default. I think they hold up better now than they did in the cloud:

1. Sealed images. The binary is fixed at compile time. No runtime package installation, no configuration files, no shell to log into.
2. Dead code elimination. If the application does not use the filesystem, the filesystem is not in the binary.
3. Single address space. One application, one address space (no internal process isolation, the hypervisor provides isolation between unikernels).
4. Configuration is compilation. Network addresses, TLS certificates, and firewall rules are baked in at build time. No configuration parser at runtime means no configuration parser to exploit.
5. Small trusted computing base. The TCB is the hypervisor plus the application. No general-purpose kernel, no init system, no sshd.

Anil, Balraj and I co-founded Unikernel Systems to bring this to production. Docker acquired us three months later. At Docker, we built Docker Desktop from scratch, adding MirageOS unikernel components to the networking stack via vpnkit (we wrote an ICFP paper about how that works). Millions of developers use it daily. Meanwhile, containers won the cloud and Unikraft took the unikernel deployment model in a POSIX-compatible direction for serverless. The unikernel-as-product did not take over (yet!), but the libraries shipped further than we ever expected.

In 2021, when Tarides joined Cyber@Station F, I pitched unikernels to over thirty internal teams at Thales: cyber, compliance, transport, defence, ... Most were politely interested. The one that clicked was Régis de Ferluc at Thales Alenia Space. His reaction was not "that is interesting" but "that is how we already build embedded systems, but done in a principled way (and where you can safely introduce dynamic behaviour)."

He was right. Satellite flight software ships as fixed binaries, qualified on the ground, no shell access in orbit, no runtime configuration changes. The five properties above are not innovations in space, they are requirements. What satellite software does not have is the type safety, the tooling, and the library ecosystem that OCaml and MirageOS provide.

Régis pushed us to look deeper, introduced us to EU programmes (ORCHIDE via Horizon Europe, CEOS), and SpaceOS was born. Miklos and I co-founded Parsimoni to build it.

The ASPLOS paper asked whether sealed, single-purpose images could improve cloud infrastructure. Twelve years later, I think the more interesting question is whether those same properties matter more in constrained environments (satellites, hardware security modules, embedded controllers) where every kilobyte counts, you cannot ssh in after deployment, and "no unused code" is not an optimisation but a qualification requirement.

F Prime (GitHub) is NASA's open-source framework for building reusable flight software. Before it, most missions started from scratch or copy-pasted code from previous ones. It already flies on Ingenuity (Mars Helicopter), CADRE (autonomous lunar rovers), and Europa Clipper. It is trying to bring standard software engineering practices (modularity, unit testing, reusability, continuous integration) to a domain that has historically resisted them.

The framework has its own modelling language called FPP (F Prime Prime). You describe your system in FPP (components, ports, state machines, topologies) and the toolchain generates thousands of lines of C++ for you (plus a fair amount of CMake glue to wire the build together). That is the point: you write the architecture, not the boilerplate. If you have ever worked with MirageOS, all of this should sound oddly familiar.

For those who do not know, MirageOS (GitHub) is a library operating system where the entire application, from the network stack to the storage layer, is built from OCaml modules wired together by functors. The runtime is minimal (Solo5 provides about ten hypercalls), no general-purpose OS, no libc, just typed interfaces all the way down. Our ASPLOS 2013 paper received the Influential Paper Award in 2025. I think F Prime and MirageOS share a surprising number of ideas. Here is how I see the two relate.

Components are module types. In F Prime, you define a component by declaring its ports, typed interfaces that connect it to the rest of the system. The FPP paper puts it nicely: a port "has a type and a kind; the type is like a function signature." Components have no compile- or link-time dependencies on each other: each component depends only on the types of the ports that it uses.

FPP distinguishes three kinds of components: passive (called synchronously by the caller), queued (has an internal message queue but no thread of its own), and active (has its own thread that drains its queue). This is a concurrency model baked into the component types:

passive component Thermometer {
  sync input port cmdIn: Fw.Cmd
  output port tlmOut: Fw.Tlm
  telemetry Temperature: F32
}

module type THERMOMETER = sig
  type t
  val cmd_in : t -> Cmd.t -> unit
  val tlm_out : t -> Tlm.t
  val temperature : t -> float
end

Both say the same thing: anything that calls itself a thermometer must accept commands, emit telemetry, and report a temperature. The ports are the function signatures. The component type is the module type.

The mapping is suggestive, not exact. FPP ports have directionality (input vs output) and invocation kinds (sync, async, guarded) that a flat OCaml signature does not enforce. In MirageOS we used phantom types on device connectors to recover some of this structure (see Radanne, Gazagnaire et al., 2019) but the parallel is clear enough to be useful.

The concurrency story is interesting too. F Prime's active/passive/queued distinction maps loosely to what OCaml has been working through for years. A passive component is a plain function call. An active component has its own thread that drains a message queue. Compare:

active component Logger {
  async input port logIn: Fw.Log
}

module type LOGGER = sig
  type t
  val log_in : t -> Log.t -> unit Lwt.t
end

In FPP, a component is either passive, queued, or active. In OCaml, you can mix synchronous and asynchronous functions in the same module signature: some values return unit, others return unit Lwt.t. The concurrency model is per-function, not per-component. Queued components sit in between, an event loop without a dedicated thread. OCaml has been moving from monadic concurrency (Lwt.t) to effect handlers in OCaml 5, which delegate scheduling to a library like Eio without colouring every type signature. F Prime bakes the concurrency model into the component kind; OCaml delegates it to the application scheduler.

State machines are GADTs. This one is not specific to MirageOS, it is about OCaml's type system more broadly. FPP has built-in state machine support (states, signals, guards, and transitions). Here is a door controller (from the FPP User's Guide):

state machine Door {
  signal open
  signal close
  guard isLocked

  initial enter Closed

  state Closed {
    on open if isLocked enter Closed
    on open enter Open
  }

  state Open {
    on close enter Closed
  }
}

FPP: a door with two states and a guard.

The generated state machine diagram.

In OCaml, you can encode the same transitions as a GADT. The type parameters track which state you are in and which state a signal takes you to:

type closed
type opened

type _ state =
  | Closed : closed state
  | Open : opened state

type (_, _) signal =
  | Open  : (closed, opened) signal
  | Close : (opened, closed) signal

type guard = Locked | Unlocked

let step : type a b. a state -> (a, b) signal -> guard
    -> (b state, a state) result =
  fun state signal guard ->
    match state, signal, guard with
    | Closed, Open, Locked   -> Error state
    | Closed, Open, Unlocked -> Ok Open
    | Open, Close, _         -> Ok Closed

The type (closed, opened) signal means: this signal is only valid from the closed state, and it produces the opened state. Try to close an already-closed door and the compiler rejects it. The guard is a runtime check (just like in FPP), but the result type makes the self-loop explicit: Error state means the guard blocked and you stayed where you were. FPP's state machine compiler does the same checks at the FPP level; the GADT pushes them into OCaml's own type system.

The wiring is where they diverge. How you describe the way all these components connect into a running system is where the two frameworks take different paths.

In F Prime, you define a topology: a wiring diagram that connects component instances through their ports, the way an engineer connects chips on a board. Sub-topologies let you group and reuse partial wirings (think of them as sub-circuits). The FPP compiler checks that port types match, then the autocoder generates C++ and a fair amount of CMake glue. For the final assembly, users customise init sequences, thread priorities, and buffer sizes through C++ templates and build rules. There are many knobs to turn.

topology Mission {
  instance sensor: Sensors.Thermometer
  instance dispatcher: Svc.CmdDispatcher

  connections command {
    dispatcher.compCmdSend -> sensor.cmdIn
  }
}

module Mission
    (Sensor : THERMOMETER)
    (Dispatcher : CMD_DISPATCHER) = struct
  let dispatch sensor cmd =
    Sensor.cmd_in sensor cmd
  let init sensor =
    Dispatcher.register (dispatch sensor)
end

In MirageOS, a functor is a function from modules to modules: you pass a module satisfying some signature, and you get a new module back. The functor is the sub-topology. People write functor applications by hand all the time in OCaml, and it works fine. But in MirageOS we wanted to automate redeployment across different hypervisors and driver sets (Xen, KVM, Solo5, each with their own network and storage stacks), so we built Functoria, an eDSL that describes the assemblage and generates the build rules and functor applications for each target. That is structurally closer to what F Prime's autocoder does: both take a high-level wiring description and produce glue code for a specific target.

Both check that the wiring is type-correct, but in different places: FPP in its own compiler, OCaml in the host language's type system. FPP gives you a graph-oriented model that maps naturally to how electronic engineers think. Functoria gives you composability (functors are first-class language constructs), but the resulting code can get... involved. (Who said Irmin in the back? :p)

The unit of compute seems settled: small typed components, explicit async I/O, function types as interfaces. The global wiring is not. I have seen it spawn build system rules (Makefile spaghetti), domain-specific languages (FPP, Functoria), and language-specific support (functors). Parnas (1972) told us to hide information behind interfaces. Nobody told us how to wire a thousand of them together ;-)

The last couple of weeks have been pretty intense as I've been moving to LA with my family. I am spending six months here, working on Parsimoni and getting closer to the US space industry.

Last week I visited NASA's Jet Propulsion Laboratory (JPL) and saw Voyager 2's control room -- still running after 48 years. Optimism, Perseverance's ground twin, was rolling over Pasadena sand in a test enclosure next door. I also attended the F Prime workshop and completed two workshops on flight software engineering. F Prime is NASA's open-source flight software framework. Over 100 people attended -- university and student teams, internal JPL product teams, and large projects like HPSC. Only a small bunch of us were not from the US.

The recurring theme in every conversation: flying a helicopter on Mars is now routine, but deploying shared payload software to a satellite is still real science fiction (no pressure!).

On the Tarides side, the team continues to maintain and develop the OCaml platform -- opam, Dune, Merlin, odoc -- while I am on a different timezone. Lots of things are happening (see the Tarides blog) and many more are planned for 2026. In a world where people write apps by chatting with AI bots, core language tools are even more important to make sure we keep trust in our software systems (more on this later in this blog, hopefully).

I intend to write here more regularly this year -- about SpaceOS, the OCaml platform, and what happens when you try to put unikernels in orbit. Stay tuned.