1. Introduction
Recent trends in aviation demonstrate an industry-wide shift towards climate-neutral solutions, with Hybrid-Electric Regional Architecture (HERA) positioned at the forefront of next-generation short-range air transport. The move towards hybrid-electric architectures introduces an unprecedented level of complexity, far surpassing that of traditional aircraft systems. Comparative analyses indicate that hybrid-electric powertrains may require handling over twice the number of parameters and several times more combinations than conventional systems [
1]. This complexity necessitates innovative methodologies for the design and certification of such aircraft.
Responding to these challenges, the EU-financed ODE4HERA project [
2]—initiated in January 2024—aims to accelerate the development of HERA models, realizing a 50% increase in cost-effectiveness and a 50% reduction in development lead times with respect to the 2020 state of the art. This will be achieved with the development of an Open Digital Platform (ODP), a tool-agnostic environment integrating software and methods with Model-Based System Engineering (MBSE), exchanging data through SysML v2 language [
3], and providing design, optimization, and virtual verification and validation (V&V) processes. The integrated V&V phase will allow us to virtually test the entire system and its subsystem with high-fidelity methods before the aircraft is manufactured, anticipating design flaws before their occurrence in experimental tests or flight operations.
The application case 1 of the project aims to: develop behavioral models of aircraft systems; integrate such models into a co-simulation environment; execute the V&V process; and perform multi-disciplinary optimization (MDO). This paper presents the development of a flight dynamics module aiming at the simulation of a typical flight mission of the reference hybrid-electric aircraft within a co-simulation environment.
Flight simulation can be mainly modeled with either point mass or 3–6 degrees of freedom (DOF) models. The former offers computational efficiency and sufficient accuracy for long-range, minimally maneuvered profile analysis, making them ideal for mission planning and fuel estimation. The latter deliver greater fidelity for dynamic maneuvers, control system performance evaluation, and training applications, but with higher modeling complexities and at higher computational costs. It was shown that a point mass model coupled with performance-based climb and descent modules can accurately reproduce mission performance within 3% error for regional transports [
4].
The project consortium expects high-fidelity simulations to demonstrate the capability of the ODP to perform the integrated V&V phase with realistic models of the system of interest. Ideally, a behavioral model of a human pilot, at least for longitudinal (3-DOF) aircraft control, would be preferred. An example of such kind of controller is the Total Energy Control System (TECS), introduced by Lambregts in the early 1980s [
5,
6,
7]. TECS acts like a human pilot, coordinating flight path and airspeed control by simultaneously controlling elevator and throttle. Some examples are given in [
8,
9,
10,
11,
12,
13,
14,
15,
16], while an application in a hybrid-electric regional aircraft was performed by the authors in [
17].
In the remainder of the paper, a detailed description of the point mass model and its implementation will be given. The results of the co-simulation with other subsystems will be presented, followed by a short discussion on the issues in moving towards the TECS model. Conclusions will recap the main findings of this work.
2. Flight Dynamics Model
The development of the flight dynamics module has been performed in MATLAB/Simulink R2024b. Its integration in the co-simulation environment, which gathers the modules developed by project partners—propulsive plant, electric machines, mission control—is done in Simcenter Amesim or Simcenter System Architect. Although the latter provides the possibility of directly integrating a Simulink file, a Functional Mock-up Interface (FMI) is needed to keep a solution-neutral architecture. FMI is an open, tool-independent standard for exchanging and integrating dynamic simulation models between different software tools packaged as Functional Mock-up Units (FMUs), which substantially are black boxes containing the solver, the model’s parameters, and input/output ports [
18]. Thus, at the end of its development, the flight dynamics module is converted into an FMU.
While the FMU provides a standardized package to integrate the simulation model in a co-simulation environment, the flight dynamicist must develop such a model considering the available input and the expected output signals. In our case, the thrust vector and fuel consumption are provided by the propulsive module and the attitude is controlled by the commanded signal of the angle of attack. Additional variables could be provided for MDO activities. The required output signals are kinematic variables in the inertial North–East–Down (NED) reference frame, attitude angles (bank, flight path, heading), true airspeed, altitude, and air data (static and total pressure and temperature). To preliminarily validate the performance of the reference aircraft and to keep compatibility with the available modules and signals, it was decided to initiate the development and integration activities with a point mass model.
The aircraft motion is described by the Nonlinear Aircraft Performance Equations (NAPE), relating the true airspeed
V, flight path angle
, and heading angle
to lift
L, drag
D, thrust
T, mass
m, and bank angle
. The NAPE describe the three-dimensional translation of a point mass, representing the center of gravity of the aircraft. They are valid under the assumptions of no sideslip and thrust aligned with the velocity vector. They were adapted from [
19] and listed here
where
g is the gravitational constant fixed to 9.81 m/s
2, with the hypothesis of a flat Earth. The time integration of (
1) to (
3) is not sufficient to completely describe the aircraft motion. Additional kinematic equations are necessary to relate the flight dynamics variables to the inertial coordinates
where
,
, and
h are the North, East, and altitude distances, respectively, of the aircraft center of gravity with respect to an arbitrary origin on the Earth surface. However, only the longitudinal variables are needed to simulate a mission profile in our context. Therefore, the bank angle
is null and the heading angle
is an undefined constant assumed null for simplicity. Equations (
1)–(
6) are therefore reduced as follows
The adoption of the point-mass formulation, restricted here to purely longitudinal motion with zero bank and heading angles, inherently neglects lateral–directional dynamics such as Dutch roll, roll–yaw coupling, and sideslip effects. As a consequence, the model cannot capture phenomena associated with asymmetric thrust, crosswind conditions, or roll control activity, and it cannot be used to assess handling qualities or lateral stability margins. Moreover, transient manoeuvres involving strong coupling between attitude, angular rates, and translational motion (e.g., aggressive step commands) are only approximated through the evolution of flight path angle and speed, without resolving attitude dynamics or control surface deflections. These simplifications are acceptable in the present context, where the focus is on mission-level performance, energy consumption, and compatibility with the ODE4HERA V&V workflow, but they limit the validity of the results to non-aggressive, near-trim flight segments.
Equations (
7)–(
10) are integrated in Simulink and constitute the core of the flight dynamics module. The main Simulink mask is shown in
Figure 1. It is made up of the three subsystems, Aerodynamics, NAPE, and Air Data. The first two are shown in
Figure 2 and
Figure 3, respectively. The aerodynamic model was provided by the HERA consortium [
20] through a Cooperation Agreement and cannot be disclosed. However, the reference aircraft—named UERA—is based on the ATR-72, with a slightly larger wing aspect ratio and a hybrid-electric powerplant with thermal engines and batteries.
Finally, a co-simulation FMU 2.0 version is generated. When exporting the Simulink model as an FMU 2.0 for co-simulation, care must be taken to avoid discontinuities in the internal blocks, since most FMI-based environments assume continuous right-hand sides and version 2.0 cannot handle events to manage switch or if–else logic. In our first implementation, the standard Simulink ISA block caused small discontinuities, likely due to piecewise definitions of the atmospheric layers, and similar issues may arise from conditional aerodynamic lookup tables, engine deck ratings, and logical switches in controller blocks. To mitigate this, the tropospheric ISA model was recast as a smooth MATLAB function, discontinuous constructs were removed or replaced by continuously differentiable approximations, and algebraic loops where avoided by inserting delays (memory block) on feedback paths. This ensured a numerically robust FMU suitable for integration into Simcenter Amesim and other FMI-compliant tools.
The representation of the FMU as imported into Simcenter Amesim 2310 is illustrated in
Figure 4, where all the vector quantities are expanded, explicitly showing the three scalar components of thrust, acceleration, velocity, position, and attitude angles—bank, flight path, and heading. Lateral-directional variables are set to zero.
3. Results and Discussion
The co-simulation setup adopts a master algorithm in Simcenter Amesim 2310, which advances all subsystems with a fixed time step of 0.01 s. The same value is applied to the FMU, with an automatic selection of the solver. At each communication instant, the propulsive module provides the three-component thrust vector and instantaneous fuel flow to the flight dynamics FMU, and receives back total forces, kinematic states, and air data required for its performance maps. In parallel, the controller block—made of two single-input single-output (SISO) controllers, autopilot and autothrottle—reads altitude and true airspeed from the flight dynamics FMU and outputs commanded angle of attack and fuel flow modulation, which are routed respectively to the aerodynamic model (through the flight dynamics FMU) and to the propulsive system.
The integration of the FMU into Simcenter Amesim 2310 is shown in
Figure 5. There are some features that required a custom-made interface. For instance, the propulsive module has ports that share multiple input and output signals. Also, each port may be of a different nature (e.g., mechanical) and it is not possible to simply demux the signals. In this respect, Siemens provided a connector to link the mechanical port of the propulsive module to the scalar ports of the flight dynamics FMU.
The test case here presented shows the integration of the flight dynamics module developed by the authors into a Simcenter Amesim file prepared by Leonardo Aircraft (LDO). Contributions of other partners are not visible at this stage. The integration of all the modules is out of the scope of this paper.
The mission profile is a sequence of climb, cruise, and descent phases, including an alternate route. Take-off and landing are not simulated. Results for such a mission are shown in
Figure 6, where the actual (real) signals are compared with the target signals defined in the flight mission block. These two set of signals are almost completely overlapped, confirming the successful implementation of the flight dynamics module. Thus, such a model can be exploited later for the integrated V&V analysis.
However, in the first descent segment, the real airspeed exhibits a modest overshoot and a noticeable delay with respect to the target profile, while the altitude tracking remains accurate. This behaviour is consistent with the intrinsic coupling between flight path and speed in longitudinal motion: as the SISO altitude controller commands a negative flight path angle to initiate the descent, the available excess thrust momentarily accelerates the aircraft before the airspeed controller compensates through throttle reduction. The absence of a coordinated, energy-based allocation between elevator and thrust implies that altitude tracking is prioritised while speed is corrected with some lag, which explains why the phenomenon does not appear uniformly across all descent segments. Given the small magnitude of the overshoot and the mission-level focus of the present study, this performance has been deemed acceptable for preliminary V&V activities, although it clearly motivates the future implementation of the TECS control laws to achieve more pilot-like coordination of flight path and airspeed.