Can Julia land on the Moon? On the development of a GNC simulation framework for the Argonaut lunar lander

1 Introduction

• High-fidelity closed-loop simulations support GNC design assessment, performance evaluation, uncertainty characterization, and engineering decisions across the lander’s development.ESA also requires independent simulation capability to support the industrial prime contractor.Source: §1 · p. 1
• Julia was selected to explore whether a different programming language could address simulation-speed needs in large trade-off, robustness, and verification campaigns.Its performance claims motivated selection, while its MATLAB- and Python-familiar syntax was expected to ease adoption by GNC engineers.Source: §1 · p. 2
• ATLAS is a closed-loop Argonaut simulation framework developed entirely in Julia, with an assessment of Julia’s advantages and limitations for GNC simulation and analysis.The evaluation covers software architecture, workflow, debugging, performance optimization, and usability.Source: §1 · p. 2

2.1 GNC and simulation architecture

• The closed-loop architecture separates GNC, sensors, actuators, and vehicle dynamics while incorporating realistic execution rates, timing, and delays.The simulation covers descent from 30 km altitude and feeds imperfect sensor observations back to GNC through the modeled system.Source: §2.1 · p. 2, Figure 3 · p. 4
• GNC combines mission management, six-degree-of-freedom error-state Schmidt–Kalman navigation, phase-specific guidance, four SISO control channels, and actuator-level command allocation.The lateral channels use cascaded position and attitude loops; guidance algorithms vary by mission phase.Source: §2.1 · pp. 2–3
• The actuator models capture engine and RCS dynamics, delays, limits, and thrust realization, while propulsion commands run at 4 Hz and thrust is propagated continuously.RCS models support PWM and the computationally efficient PAM approximation.Source: §2.1 · p. 3
• The DKE represents six-degree-of-freedom vehicle motion with propellant depletion, time-varying mass properties, and sloshing models for four main-engine tanks.The sensor suite includes baseline vision, inertial, star-tracker, and LIDAR-based hazard-detection models, with additional sensors for trade studies.Source: §2.1 · pp. 3–4

2.2 Software architecture

• ATLAS uses custom Julia structs to compose modules and submodels, with caches for intermediate values and preallocated buffers that reduce runtime heap allocations.Module-level logging interfaces collect post-processing variables separately from core computation.Source: §2.2 · pp. 4, 6, Figure 4 · p. 5
• Periodic simStep! callbacks execute subsystem outputs in a deterministic order at a timestep based on the greatest common divisor of module rates and delays.Module triggers and FIFO buffers support asynchronous rates and model processing delays; scenario-dependent callbacks can stop integration at touchdown, propellant exhaustion, or sloshing limits.Source: Figure 5 · p. 5, §2.2 · p. 6, Figure 6 · p. 6

3 Julia advantages and limitations

• The assessment is limited to open-source Julia packages, and its observations may not reflect Julia’s latest ecosystem changes because ATLAS development began several years ago.The scope excludes commercial products and Julia-based industrial platforms such as Dyad.Source: §3 · p. 7

3.1 Ecosystem maturity, licensing, portability

• MATLAB’s mature, integrated ecosystem supports long-term engineering work, but licensing costs and floating pools can restrict practical access.Access friction can occur even when a simulation framework has no technical limitation.Source: §3.1 · p. 7
• Julia removes licensing constraints and offers strong numerical-computing packages, but uneven maintenance, testing, and support may create long-term risks.The paper highlights DifferentialEquations.jl and notes that some libraries may become inactive.Source: §3.1 · p. 7
• Julia’s open-source workflow can make simulation tools more portable and reproducible, easing collaboration, independent validation, and integration with broader development pipelines.The paper names continuous integration and digital-twin modelling as examples.Source: §3.1 · p. 7

3.2 Language semantics

• Julia passes most mutable objects, especially arrays, by reference, so functions typically operate on the original data unless it is explicitly copied.This avoids unnecessary memory allocations but requires attention to data sharing.Source: §3.2 · p. 8
• In closed-loop simulations, inadvertent aliasing can silently corrupt state and produce incorrect results without immediate failures.Such errors can be difficult to trace and debug.Source: §3.2 · p. 8
• Compared with MATLAB’s copy-on-write behavior, Julia places more responsibility on developers to manage data ownership, making it less forgiving but more flexible.In MATLAB, modifications inside a function do not affect the original variable unless explicitly returned and reassigned.Source: §3.2 · p. 8

3.3 Prototyping speed: coding approach

• MATLAB-like Julia code can prototype clearly and compactly, but dynamic types, generic containers, and implicit allocations can hinder compiler optimization.In some cases, such coding patterns may run slower than interpreted environments.Source: §3.3 · p. 8
• C-like performance generally requires type stability, concrete data structures, preallocation, and in-place operations rather than a purely MATLAB-like style.These practices can improve execution efficiency without requiring C++-level verbosity or manual memory management.Source: §3.3 · p. 8
• Figures 7 and 8 show naive and optimized implementations of a Kalman-filter update function.The paper uses the examples to illustrate the effect of coding approach on execution time.Source: Figure 7 · p. 8, §3.3 · p. 8, Figure 8 · p. 9
• The optimized Julia function kalman! performs significantly better than comparable MATLAB code, while MATLAB beats the naive Julia implementation.The paper attributes reduced memory footprint to minimizing allocations and reusing existing variables.Source: §3.3 · p. 9
• Julia allows developers to refine performance-critical sections of the same codebase after prototyping, shifting the expressiveness–performance trade-off into coding style.Profiling can identify bottlenecks so only relevant sections need performance-oriented refactoring.Source: §3.3 · p. 9

• Unlike Simulink, Julia lacks a widely used, free, fully integrated graphical modelling environment for assembling closed-loop simulations visually.Simulink-style visual construction allows iteration with less concern for implementation details such as data structures and execution order.Source: §3.4 · p. 9
• Julia requires users to structure simulations, define component interfaces, and manage data flow explicitly, making complex closed-loop development slower and more demanding.The challenge is especially pronounced for architectures with multi-rate and delayed functional elements.Source: §3.4 · p. 10
• Large Simulink block diagrams can become difficult to maintain, with hidden dependencies and implicit execution order obscuring their logic.The passage notes that scaling graphical models to high-fidelity simulations can also challenge readability and data-transfer verification.Source: §3.4 · p. 10
• Code-based development encourages modular, testable components and can produce simulation frameworks more closely aligned with operational GNC software design.The paper describes this as requiring more upfront effort while tending toward more robust and transparent frameworks.Source: §3.4 · p. 10

• Time To First X (TTFX) is the latency from just-in-time compilation when code is executed for the first time.Significant code changes can invalidate compiled methods and trigger compilation again.Source: §3.5 · p. 10
• Repeated compilation after model, parameter, or algorithm changes interrupts the edit–run–analyse cycle and can make early-stage experimentation less responsive.Precompilation and system images can mitigate TTFX but require additional effort and expertise and may not eliminate it.Source: §3.5 · p. 10
• Julia debugging is more code-centric and less integrated than Simulink’s visual signal inspection and block-diagram debugging.Complex call stacks and type-related errors can slow diagnosis, particularly when faults propagate across simulation layers.Source: §3.5 · p. 11

• The speed assessment used 100 descent-and-landing trajectories, fixed-step Tsit5(), and multithreaded runs on two computing stations.Each trajectory represented approximately 900 seconds of simulated flight, and the campaign was repeated across fixed simulation timesteps.Source: §3.6 · p. 11
• At 8 Hz, one trajectory took approximately 100 ms on the laptop and under 60 ms on the workstation; at 16 Hz, runtimes remained below 0.2 seconds per trajectory.The paper estimates that 1,000 runs would take under 2 minutes at 8 Hz and under 3.5 minutes at 16 Hz.Source: §3.6 · p. 11
• No equivalent MATLAB/Simulink simulator was directly tested, so the expected speed advantage over plain MATLAB/Simulink is based on the authors’ experience with comparable Phase B simulators.That expectation excludes MATLAB’s Parallel Computing Toolbox and Coder.Source: §3.6 · p. 11
• Optimization reduced runtime from over 5 seconds to about 1 second and ultimately approximately 0.1 seconds per simulation, with allocation reduction the decisive refactoring focus.The development effort was roughly 20% GNC functions and models, 30% framework development, and 50% reducing simulation allocations; the authors also stress performance-oriented libraries and type stability.Source: §3.6 · pp. 11–12

• ATLAS made large-scale simulations routinely accessible, allowing results to inform design decisions earlier and more frequently.The authors contrast this with campaigns that can take hours or days and force engineers to be selective about analyses.Source: §3.7 · p. 12
• Controller tuning used rapid iterations between classical control design and nonlinear Monte Carlo validation, evaluating candidate parameters through hundreds of simulations.The results could be analyzed and the controller retuned almost interactively.Source: §3.7 · p. 12
• For class-α mission verification, ATLAS runtimes suggest that campaigns of thousands of simulations could shift effort from computational constraints toward uncertainty models and performance metrics.The authors state this could reduce verification effort and shorten development schedules by weeks or months.Source: §3.7 · p. 13
• The reported results used conventional multicore CPUs only; the authors expect additional gains from emerging GPU-based simulation frameworks.They describe GPU support as becoming more mature and accessible in the Julia ecosystem.Source: §3.7 · p. 13

3.8 An industrial perspective

• Industrial value depends on compatibility with flight-software processes and qualification, where established MATLAB/Simulink workflows are deeply embedded.The paper notes that flight software must comply with ECSS standards and, where applicable, safety requirements.Source: §3.8 · p. 13
• Julia-based deployable-code approaches remain largely unproven for spacecraft, and integration with industrial qualification and assurance processes is unclear.Existing investment in Simulink autocoding makes a rapid shift to a different paradigm unlikely.Source: §3.8 · p. 13
• Julia’s likeliest near-term industrial role is pre-development work, with flight software transitioning to a traditional qualification-ready toolchain.Whether Julia can enter operational flight-software development remains open and requires technological and industrial maturation.Source: §3.8 · p. 13

4 Conclusions

• Approximately 0.1 seconds for a complete 900-second landing simulation was achieved by ATLAS using optimized libraries, multithreading, and reduced heap allocations.This runtime supports large-scale GNC analyses.Source: §4 · p. 13
• Achieving high performance required significant software-engineering effort, understanding Julia’s semantics, and coding practices unlike common MATLAB/Simulink practice.The development experience also highlighted challenges associated with the language.Source: §4 · p. 14
• Julia’s software-centric approach produced a modular architecture closer to flight software than block-diagram simulators, but industrial adoption beyond Phase 0/A/B1 remains unproven.Source: §4 · p. 14