A Domain-specific Language for High-reliability Software used in the JUICE SWI Instrument - The hO Language Manual

hO is a custom restricted dialect of Oberon, developed at the Max-Planck Institute for Solar System Research in G"ottingen and used in the SWI flight software for the JUICE mission. hO is applied to reduce the possibility of syntactically valid but incorrect code, provide better means of statically analyzing source code, is more readable than C and gives syntactic support for the software architecture used in the SWI instrument software. By using a higher-level, application-specific notation a whole range of possible errors is eliminated and source code size is reduced, while making the code itself easier to understand, review and analyze.

💡 Research Summary

The paper presents the design, implementation, and application of hO, a domain‑specific language (DSL) created for the high‑reliability flight software of the SWI instrument on ESA’s JUICE mission. hO is a deliberately restricted dialect of Oberon, chosen for its syntactic simplicity and well‑defined runtime model. By stripping Oberon of strings, floating‑point numbers, multi‑dimensional arrays, record inheritance, the WITH clause, and most loop constructs, the language eliminates many sources of bugs that are common in C, the traditional language for space‑flight software.

The authors first motivate the need for a new language. While C is ubiquitous and supported by the Gaisler toolchain used on the mission’s hardware, its low‑level features (pointer arithmetic, unchecked casts, manual memory management) make it error‑prone in safety‑critical contexts. Existing high‑integrity languages such as Ada, FORTH, and Ivory were evaluated, but each presented drawbacks: lack of expertise (Ada), incompatibility with the existing toolchain (FORTH), or immature implementations (Ivory). Consequently, the team decided to develop a language tailored to the SWI software architecture while still generating C code that can be compiled with existing optimizers and hardware work‑arounds.

The SWI software architecture is built around a cyclic executive that periodically invokes a set of modules. Each module contains a set of public (exported) and private variables, runs to completion, and never performs unbounded loops or recursive calls. Communication between modules is achieved through zero‑copy message passing using a special “port” type that can hold a single raw byte array (max 4096 bytes). Ports are either empty or contain one message; sending to an occupied port or from an empty port is a no‑op, which prevents queue overflow and simplifies memory management. Message buffers are allocated from a fixed‑size pool of 4 KB blocks; the runtime provides NEW and DISPOSE primitives for allocation and reclamation.

In hO, a module is declared with the MODULE keyword, followed by variable declarations and a BEGIN … END block. Modules may be instantiated multiple times using the * suffix (e.g., MODULE spw*; creates spw0 and spw1). Public variables are accessed from other modules via the IMPORT statement and dot notation (mod.var). All module variables are zero‑initialized, and ports start empty. The language enforces that every module returns control; because unbounded loops are not permitted, a “runaway” module cannot occur.

Message passing is expressed with the built‑in SEND(msg, mod.port) primitive. The language guarantees that messages are never copied; the source port becomes empty and the destination port holds the same buffer. This design eliminates the need for explicit memory copies and reduces the risk of buffer overruns.

Procedures and functions are supported but are always inlined, encouraging small, side‑effect‑free code. Arrays must have a compile‑time known length, and the only allowed numeric types are fixed‑size integers (u8, u16, u32, s8, s16, s32) and booleans. The language also incorporates a lightweight Design‑by‑Contract system: contracts are boolean functions defined at the top level and invoked with REQUIRE, PROVIDE, or INVARIANT statements at the start or end of any statement sequence (module, procedure, conditional, or loop). Contracts cannot use VAR parameters, ensuring they remain pure predicates.

The hO compiler is written in Scheme, using the Silex lexer generator and a custom PEG parser. It performs static type checking, enforces the language’s safety constraints, and emits ANSI C99 code that relies on GNU extensions (local inline functions, statement expressions). The generated C code is compiled with options -fno-strict-aliasing -fwrapv -std=gnu99 to preserve the intended semantics. The compiler can also emit Graphviz dot files that visualise inter‑module message flows, and it offers a “interface‑only” mode to resolve circular module dependencies without full validation.

By construction, hO eliminates many classes of undefined behavior present in C. The generated code contains no NULL pointer dereferences, no pointer arithmetic, no signed integer overflow (assuming appropriate compiler flags), no signed right‑shifts, no division‑by‑zero, and no use of uninitialized variables. Runtime checks for division by zero, out‑of‑bounds port access, and other contract violations are reported via a UART debug interface or telemetry, and fatal violations trigger a reboot.

Empirical results show that translating a functional prototype of the SWI software from C to hO reduced source lines from 33 636 LOC to 2 853 LOC—a reduction of roughly 91 %—while preserving or improving readability and maintainability. The language’s strict syntax automatically satisfies 116 of the 200 MISRA‑C:2004 rules and renders nine of the ten “Power of 5 Ten” guidelines obsolete.

In summary, hO demonstrates that a carefully crafted, domain‑specific language can provide substantial safety, verification, and productivity benefits for high‑reliability embedded systems, especially in the demanding context of space missions where deterministic behavior, minimal runtime overhead, and rigorous static analysis are paramount.