Aerolang: A Dimensionally-Aware Domain-Specific Language for Real-Time Flight Control with Integrated Morphing Wing Physics

DSLs have a rich history in aerospace for improving the safety, correctness, and abstraction level of mission-critical software.

The Architecture Analysis and Design Language (AADL) provides a formal notation for describing embedded real-time system architectures, enabling the analysis of timing properties and resource consumption before deployment [15]. AADL targets architectural concerns – partitioning, scheduling, communication – rather than the continuous-time physics of a control law. Similarly, NASA’s SCR method and related tabular specification languages address the formal specification of mode-logic and mode-transition conditions in flight management systems [16], but do not address dimensional correctness of the underlying arithmetic.

The Lustre and SCADE languages, in turn, take a synchronous dataflow approach to reactive and real-time control software [17,18]. These languages have strong industrial adoption in avionics (Airbus uses SCADE for flight-control software generation) and provide strong formal guarantees about determinism and schedulability. However, their data types remain physically uninterpreted; a signal is typed as a floating-point number, not as a quantity in meters per second.

Domain-specific languages in robotics, a domain closely related to UAV control, include the Robot Operating System (ROS) message definition language and the Orocos Toolchain’s Real-Time Toolkit specification language. These provide useful structuring mechanisms but similarly lack physical dimension tracking [19].

AeroLang takes a complementary approach: it focuses on the physical interpretation of quantities rather than on synchronous scheduling, and the two approaches could in principle be combined in a future multi-paradigm extension.

The idea of encoding physical dimensions in a type system dates back at least to the early work of Kennedy [20], who showed that a simple type system based on rational exponents over base dimensions can be incorporated into a typed functional language with no runtime cost. Kennedy’s subsequent implementation of Units of Measure in F# [9,21] remains the most mature industrially-relevant example of compile-time dimensional analysis. The F# system represents a dimension as a product of base dimensions raised to rational exponents; unit information is erased after type checking, yielding the same runtime representation as undecorated floating-point numbers. AeroLang adopts this same design philosophy.

Alternative approaches enforce units at runtime. Python’s Pint library [22] and the PhysicalQuantities library both track units as metadata on numeric objects, catching mismatches during execution. This approach is valuable for interactive scientific computing and post-processing but is unsuitable for real-time control loops where every operation carries overhead. AeroLang requires explicit annotations, accepting the cost in programmer effort in exchange for a formal soundness guarantee.

Morphing-wing aircraft exploit shape-changing mechanisms – variable sweep, span extension, camber adjustment, or twist – to adapt their aerodynamic configuration to the demands of different flight phases [23,24]. The aerodynamic benefits of morphing are well-established. Ninian [7] demonstrated that a variable-camber wing achieved a 17% improvement in lift-to-drag ratio over a fixed-geometry baseline. Wei et al. [8] analysed the effects of wing morphing on stability and energy harvesting in small UAVs, finding that morphing significantly expands the viable flight envelope. In a landmark study, Jeger et al. [6] demonstrated autonomous insect-inspired flight in which both wing and tail morphing were exploited simultaneously, achieving approximately 11.5% in-flight energy savings through Bayesian optimisation over the morphing state space.

The aerodynamic modelling of morphing wings presents particular challenges. Panel methods such as the vortex lattice method (VLM) are computationally tractable in real time and capture the dominant effects of planform changes on lift and induced drag [25]. Free-vortex wake methods extend panel methods by tracking the rollup and convection of the shed wake, capturing unsteady aerodynamic effects relevant to gust response and the transition between morphing states [26]. The Biot-Savart law, which relates vortex filament strength and geometry to the induced velocity field, is the foundation of both approaches.

Aeroelastic coupling – the interaction between aerodynamic loads and structural deformation – is critical for accurate modelling of flexible morphing wings [27,28]. Even in relatively stiff configurations, aerodynamic loads induce spanwise bending and chordwise twist that alter the effective angle of attack and thus the aerodynamic load distribution, creating a feedback loop. The Euler-Bernoulli beam theory provides a computationally efficient structural model capturing bending and torsion of slender wing sections [29].

Software for flight-critical systems is governed by standards such as DO-178C [30], which specifies software development assurance levels (DALs) A through E based on the consequences of failure. Level A (catastrophic failure condition) demands the most rigorous development and verification process, including structural coverage analysis at the Modified Condition/Decision Coverage (MC/DC) level. A C code generator for AeroLang would need to produce code amenable to DO-178C Level A certification, which motivates the @EMBEDDED discipline’s prohibition of dynamic memory allocation – a requirement shared by coding standards such as MISRA C:2012 [31] and CERT C [32].

Worst-case execution time (WCET) analysis is a complementary requirement for hard real-time systems. WCET tools such as AbsInt aiT analyse binary code to derive tight upper bounds on execution time under all possible inputs and cache states [33]. AeroLang’s code generator is designed to emit structurally simple Python (and in future, C) that facilitates WCET analysis by avoiding recursion, complex data structures, and dynamic dispatch.

The AeroLang compiler is built on classical compiler construction foundations. LALR(1) parsing, employed in AeroLang’s front end, offers a good balance between generality and parsing speed; the parser generator infrastructure is provided by the Lark library for Python [34]. The theory of type systems [10,35] provides the formal foundation for the dimensional type checker. The Hindley-Milner type inference algorithm [35,36] offers a possible path toward inferring units for unannotated expressions, though AeroLang currently requires explicit annotations for clarity.

Formal verification of software properties beyond type safety requires more powerful tools. SMT solvers such as Z3 [37] and CVC5 [38] can discharge proof obligations about program correctness automatically, given a suitable encoding of the program semantics. The generation of SMT verification conditions from AeroLang programs is a primary direction of the AeroLang roadmap.

The modern theory of dimensional analysis originates with Fourier [11], who introduced the principle of dimensional homogeneity: a physically valid equation must be dimensionally consistent, meaning that both sides must have the same physical dimension. Maxwell [12] systematised this in his treatment of electromagnetism, and Buckingham [39] formulated the Π theorem, which provides the most general statement of how dimensional analysis constrains the form of physical laws.

Formally, let B = {L, M, T, I, Θ, N, J} denote the set of seven SI base dimensions (length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity). Any physical dimension D can be expressed as a product of powers of base dimensions:

1 D=La·Mb·Tc·Id·Θe·Nf·Jg ,where a,b,c,d,e,f,g∈ℤ {\bf{D}} = {{\bf{L}}^a}\cdot{{\bf{M}}^b}\cdot{{\bf{T}}^c}\cdot{{\bf{I}}^d}\cdot{\Theta ^e}\cdot{{\bf{N}}^f}\cdot{{\bf{J}}^g}{\rm{,where}}a,b,c,d,e,f,g \in

The set of all physical dimensions forms a free abelian group under multiplication, with the dimensionless quantity 1 as the identity element. This algebraic structure is precisely what AeroLang’s unit type system formalises: dimensions are elements of ℤ⁷, addition of exponent vectors corresponds to multiplication of dimensions, and negation of the exponent vector corresponds to dimensional inversion.

AeroLang’s unit system is built upon the seven base SI units {m, kg, s, A, K, mol, cd} corresponding to the seven base dimensions. Every unit U in AeroLang is represented internally as an immutable seven-tuple of integer exponents (p_m, p_kg, p_s, p_A, p_K, p_mol, p_cd). For example:

The multiplication and division operators on units are defined as componentwise addition and subtraction of the exponent tuples:

2 U1×U2:=U1+U2(component-wise) {{\bf{U}}_{\bf{1}}} \times {{\bf{U}}_{\bf{2}}}: = {{\bf{U}}_{\bf{1}}} + {{\bf{U}}_{\bf{2}}}{\rm{ }}({\bf{component}} - {\bf{wise}}){\rm{ }}

3 U1/U2:=U1-U2(component-wise) {{\bf{U}}_{\bf{1}}}/{{\bf{U}}_{\bf{2}}}: = {{\bf{U}}_{\bf{1}}} - {{\bf{U}}_{\bf{2}}}{\rm{ }}({\bf{component}} - {\bf{wise}}){\rm{ }}

For addition and subtraction, AeroLang enforces the type rule that both operands must have identical unit tuples. Formally, the typing rules are:

4 T-ADD: If Γ⊢e1:F32[u] and Γ⊢e2:F32[u], then Γ⊢e1+e2:F32[u] {\bf{T}} - {\bf{ADD}}:{\rm{If}}\Gamma \vdash {{\rm{e}}_1}:{\rm{F}}32[{\rm{u}}]{\rm{and}}\Gamma \vdash {{\rm{e}}_2}:{\rm{F}}32[{\rm{u}}]{\rm{,then}}\Gamma \vdash {{\rm{e}}_1} + {{\rm{e}}_2}:{\rm{F}}32[{\rm{u}}]

5 T−MUL: If Γ⊢e1:F32[ u1 ] and Γ⊢e2:F32[ u2 ], then Γ⊢e1×e2:F32[ u1×u2 ] {\bf{T}} - {\bf{MUL}}:{\rm{If}}\Gamma \vdash {{\rm{e}}_1}:{\rm{F}}32\left[ {{{\rm{u}}_1}} \right]{\rm{and}}\Gamma \vdash {{\rm{e}}_2}:{\rm{F}}32\left[ {{{\rm{u}}_2}} \right]{\rm{,then}}\Gamma \vdash {{\rm{e}}_1} \times {{\rm{e}}_2}:{\rm{F}}32\left[ {{{\rm{u}}_1} \times {{\rm{u}}_2}} \right]

6 T-DIV: If Γ⊢e1:F32[ u1 ] and Γ⊢e2:F32[ u2 ], then Γ⊢e1/e2:F32[ u1/u2 ] {\bf{T}} - {\bf{DIV}}:{\rm{If}}\Gamma \vdash {{\rm{e}}_1}:{\rm{F}}32\left[ {{{\rm{u}}_1}} \right]{\rm{and}}\Gamma \vdash {{\rm{e}}_2}:{\rm{F}}32\left[ {{{\rm{u}}_2}} \right]{\rm{,then}}\Gamma \vdash {{\rm{e}}_1}/{{\rm{e}}_2}:{\rm{F}}32\left[ {{{\rm{u}}_1}/{{\rm{u}}_2}} \right]

These rules guarantee what is termed dimensional soundness: any well-typed AeroLang expression, when evaluated, produces a quantity of the type and unit prescribed by its type derivation.

A real-time system is one in which the correctness of the system depends not only on the logical result of computation but also on the time at which the result is produced [40]. AeroLang addresses the schedulability dimension of real-time correctness through its LOOP construct. A LOOP declaration specifies a task with a fixed period T and an implicit deadline equal to the period (implicit-deadline periodic task in Liu and Layland’s [41] terminology). The feasibility condition for a set of n such tasks on a single processor, under the Rate Monotonic Scheduling (RMS) algorithm, is given by the utilisation bound:

7 ∑ (Ci/Ti)≤n(2(1/n)-1) \mathop \sum \nolimits^ \left( {{{\bf{C}}_{\bf{i}}}/{{\bf{T}}_{\bf{i}}}} \right) \le {\bf{n}}\left( {{{\bf{2}}^{({\bf{1}}/{\bf{n}})}} - {\bf{1}}} \right)

where C_i is the worst-case execution time and T_i is the period of the i-th task. AeroLang does not currently perform schedulability analysis, but the structured form of the generated code – free of dynamic dispatch and recursive calls – is designed to facilitate WCET analysis by external tools.

The design of AeroLang is guided by four principles. First, dimensional safety: every numeric quantity carries its physical unit as part of its type, and the compiler guarantees that all operations are dimensionally consistent. Second, zero runtime overhead: unit information is erased after type checking, so the generated code is numerically identical to hand-written, unit-free code. Third, embedded suitability: the @EMBEDDED annotation activates a stricter compilation mode that statically forbids dynamic memory allocation, making the generated code amenable to WCET analysis and certification. Fourth, human readability: the syntax is designed to be self-documenting, so that a physical quantity declaration like ALTITUDE: F32@M reads naturally as “altitude is a 32-bit float in meters”.

AeroLang programs are organised into named modules. Within a module, a programmer declares unit aliases, component types, and component instantiations. The core grammar in Extended Backus-Naur Form (EBNF) is as follows:

A complete example implementing a proportional-integral pitch controller is given in Code Listing 1. This example illustrates module declaration, user-defined unit aliases, component parameters with explicit unit types, typed state variables, a procedure with dimensional arithmetic, and a real-time loop specification.

Code Listing 1.

A proportional-integral pitch controller in AeroLang.

The @EMBEDDED annotation activates a stricter compilation discipline designed for real-time, resource-constrained hardware. In embedded mode, the type checker enforces three additional constraints beyond dimensional consistency. First, no dynamic memory allocation is permitted: every data structure must have a statically known, bounded size declared as POOL<T, N> types. Second, no recursive procedure calls are permitted, ensuring that the call stack has a statically bounded depth – a requirement for WCET analysis [33]. Third, loop periods must be positive compiletime constants. These constraints are directly motivated by the requirements of DO-178C [30] and MISRA C:2012 [31].

The AeroLang compiler is a five-stage pipeline that transforms high-level, physically-annotated source code into executable Python. The pipeline is implemented in Python and totals approximately 1,200 lines of source code. The compilation process proceeds through: (1) lexical analysis, (2) LALR(1) parsing via the Lark library [34], (3) AST construction using Python dataclasses, (4) semantic analysis (type checking), and (5) code generation with unit erasure.

The type checker performs a single-pass traversal of the AST, maintaining a symbol table (environment) Γ that maps identifiers to their declared types and units. The algorithm is formalised as Algorithm 1.

The code generator traverses the unit-annotated AST and emits Python source code. The key design decision is unit erasure: unit annotations on types are not emitted to the output. The generated code contains only float arithmetic, with no wrapper objects or metadata. COMPONENT becomes a Python class, STATE variables become instance attributes, PROC declarations become instance methods, and LOOP declarations become step() methods called by the simulation loop.

The control objective is to regulate the wing lift coefficient C_L to a target value C_L^* = 0.8, representative of efficient cruise, by independently commanding wing span b(t) ∈ [*0.7, 1.0] m and camber ratio η(t) ∈ [*0.12, 0.24]. The wind speed V_∞(t) is a slowly varying disturbance with a nominal value of 12 m/s and step changes introduced during the simulation. The wing is modelled as a tapered, linearly elastic beam with span b, root chord c_r = 0.25 m, taper ratio λ = 0.6, and NACA 2412 baseline section profile.

The aerodynamic model uses a free-vortex-wake approach. The induced velocity uind at any point p in the flow field is computed using the Biot-Savart law:

8 uind (p)=Γ/(4π)∫dl×r^/|r|2 {u_{{\bf{ind}}{\rm{ }}}}({\bf{p}}) = {\bf{\Gamma }}/({\bf{4\pi }})\mathop \smallint \nolimits^ {\bf{dl}} \times \widehat {\bf{r}}/|\overrightarrow {\bf{r}} {|^{\bf{2}}}

where Γ is the vortex filament circulation strength, dl is the filament direction element, and r is the displacement vector from the filament element to the field point. The lift and induced drag coefficients are computed from the circulation distribution by application of the Kutta-Joukowski theorem:

9 L=ρ V∞∫Γ(y)dy,Di=ρ V∞∫Γ(y)αi(y)dy {\bf{L}} = {\bf{\rho }}{{\bf{V}}_\infty }\mathop \smallint \nolimits^ {\bf{\Gamma }}({\bf{y}}){\bf{dy}},\quad {{\bf{D}}_{\bf{i}}} = {\bf{\rho }}{{\bf{V}}_\infty }\mathop \smallint \nolimits^ {\bf{\Gamma }}({\bf{y}}){{\bf{\alpha }}_{\bf{i}}}({\bf{y}}){\bf{dy}}

Aerodynamic loads are coupled to structural deflections using an Euler-Bernoulli beam model for the wing spar [29]. The governing equations for spanwise bending deflection w(y) and twist angle φ(y) are:

10 EId4w/dy4=q(y),GJd2φ/dy2=-m(y) {\bf{EI}}\,{{\bf{d}}^{\bf{4}}}{\bf{w}}/{\bf{d}}{{\bf{y}}^{\bf{4}}} = {\bf{q}}({\bf{y}}),\quad {\bf{GJ}}\,{{\bf{d}}^{\bf{2}}}{\bf{\varphi }}/{\bf{d}}{{\bf{y}}^{\bf{2}}} = - {\bf{m}}({\bf{y}})

where E is Young’s modulus, I is the second moment of area, G is the shear modulus, and J is the Saint-Venant torsion constant. These equations are discretised using a second-order finite difference scheme over the spanwise grid and solved as a banded linear system at each time step.

The controller logic is implemented in a 262-line AeroLang source file. It consists of two coupled sub-controllers. A proportional-integral (PI) controller regulates the span b(t) based on the error in lift coefficient C_L, with proportional gain K_P = 0.5 m and integral gain K_I = 0.1 m/s. A proportional camber scheduler maps the wind speed V_∞ to a target camber ratio η*(V_∞) according to a schedule computed offline:

11 η*(V∞)=0.18×(1.0+0.1/((V∞/12.0)2+0.1)) {{\bf{\eta }}^*}\left( {{{\bf{V}}_{_\infty }}} \right) = {\bf{0}}.{\bf{18}} \times \left( {{\bf{1}}.{\bf{0}} + {\bf{0}}.{\bf{1}}/\left( {{{\left( {{{\bf{V}}_{_{_\infty }}}/{\bf{12}}.{\bf{0}}} \right)}^{\bf{2}}} + {\bf{0}}.{\bf{1}}} \right)} \right)

The closed-loop simulation was run for 120 seconds of simulated flight time with a fixed time step of Δt = 0.01 s, using a fourth-order Runge-Kutta integrator. Table 1 summarises the key performance metrics.

The 11.3% improvement in mean lift-to-drag ratio is consistent with the range of 10 —20% reported in the experimental and computational literature [6,7]. The PI span controller achieves a settling time of approximately 4.2 seconds after the wind-speed step disturbances, with a C_L root-mean-square error of 0.031 compared to the target of 0.8. The computational overhead of the generated controller relative to the rigid-wing simulation is 0.3%, confirming the zero-cost abstraction claim.

The most important result is the compiler’s behaviour during development. During the authoring of the 262-line AeroLang controller, the compiler detected and reported seven unit-mismatch errors before any simulation was run. Representative examples are given in Table 2.

While the current implementation utilises a Python backend for rapid prototyping and simulation, the @EMBEDDED discipline is specifically designed to facilitate predictable execution on target hardware. Preliminary analysis of the generated code structure confirms the absence of unbounded recursion and unrestricted dynamic allocation, which are prerequisites for formal Worst-Case Execution Time (WCET) analysis. Empirical WCET measurements and memory footprint profiling are planned as part of the upcoming C backend implementation. This transition will enable the use of industrial-grade static analysis tools, such as AbsInt aiT, to derive tight execution bounds relevant to high-assurance flight-control deployment contexts. At present, no certification-oriented timing analysis has been performed on generated binaries, as the current implementation targets simulation-oriented Python execution.