1 Introduction

Motion sickness is a phenomenon which can lead to a variety of symptoms including cold sweat, nausea and vomiting. It is caused by a discrepancy of perceived motion between different sensory channels or perceived motion and expected motion [1]. In aircraft, motion sickness can be caused by various effects, for example the aircraft’s motion itself [2] or the use of new technology in the cabin, for example an artificial outside view [3]. As the passenger’s well-being might be a relevant criterion when choosing an airline, it is of interest to investigate effects of new technology on the development of motion sickness. However, research in an actual aircraft is expensive or even impossible for aircraft that do not yet exist. The use of a simulator with a motion base, a full flight simulator, can be a solution [4].

Such research is also conducted at German Aerospace Center, using its simulator environment Air Vehicle Simulator (AVES). It consists of a motion system with six degrees of freedom in the form of a Stewart platform as well as an interchangeable cockpit or cabin module. Available modules are a cockpit for the EC135 helicopter, a cockpit for the commercial airliner Airbus A320 and the Advanced Future Cabin (AFC). For motion sickness research, the AFC is used. The AFC is a realistic replica of a passenger aircraft cabin [3, 5, 6].

Typically, a simulation model of the aircraft which shall be simulated (for example the Airbus A320), developed in-house using Matlab Simulink, is used to replicate the aircraft’s flight-physical behavior. Among other parameters, it calculates the aircraft motion based on pilot input in the cockpit in a pilot-in-the-loop simulation. These data are then used by the simulator systems, such as audio, visual and motion system, to provide an adequate impression within the simulator. The motion system uses a motion control algorithm (MCA) to translate the received aircraft motion into a motion of the Stewart platform. Different MCAs are available and can be interchanged. Their parameters can be modified as well. Additionally, specialized software is used at an instructor station within the simulator to configure and control environmental effects, such as the weather (e.g., current turbulence strength).

Although using a simulator can be a solution to conduct motion sickness research, the use of a simulator can itself have an impact on the development of motion sickness which has to be taken into account. For example, the subjectively felt realism [3] and motion, especially in the range from 0.1 to 0.5 Hz [7], influence the development of motion sickness. It is therefore important that the simulator systems lead to a realistic representation of the real visual and motion in the aircraft. As the MCA translates the incoming motion data into a motion of the Stewart platform which is then felt by the occupants, the selected MCA, its implementation and parameters as well as the quality of the input data have a direct influence on the resulting motion of the motion platform and therefore the development of motion sickness.

Furthermore, good standardization of the test conditions is required to ensure validity [8]. As multiple repetitions of the same simulator experiment may be required to achieve statistically meaningful participant numbers, the resulting simulator motion should ideally be exactly the same each repetition. While the MCA and its parameters can easily be kept the same, reproducing the exact same input data for multiple repetitions is impossible to achieve using pilot-in-the-loop simulation, especially for complex flight profiles.

In a first step to mitigate this problem, the aircraft simulation model has been replaced with a software capable of replaying recordings of flight profiles. The flight profiles are recorded in advance using pilot-in-the-loop simulation, then replayed each time the experiment is conducted in the simulator, leading to the same input to the simulator systems for all repetitions. This approach greatly improved reproducibility for complete flight profiles.

However, problems arise if, for example to mitigate ordering effects, multiple flight profiles are required which shall exactly reproduce parts, or segments, of each other. Consider two flight profiles, each consisting of the two segment types A and B, but with the different segment orders AB and BA. Using a pilot-in-the-loop simulation, it will be impossible to exactly recreate the segment types A and B both times. It can be argued that the first profile could be recorded and the second then artificially be created from it. While this approach would keep the content of the segments constant, problems can arise in the transitions between the segments, leading to jerks in the data. These, in turn, can be detrimental to MCA and motion system performance, leading to undesirable false motion cues. However, these false cues should be avoided as much as possible, as they might influence the results of studies such as those described for motion sickness.

As a solution, a toolbox was developed which automates the recording process. It replaces previously manual inputs by the pilot (e.g., inputs to the auto flight system) and inputs to the environment simulation from the instructor station (e.g., the current turbulence strength) with automated inputs. Among the benefits is improved input precision, leading to better reproducibility of segments of flight profiles across multiple recordings. Complete flight profiles are easier to reproduce as well. Additionally, the required manual effort to produce recordings is greatly reduced.

This manuscript will present the developed toolbox and results of tests conducted to validate it. First, an overview of the concepts and ideas involved in the implementation of the toolbox will be given. This will be followed by a description of the tests conducted to validate the resulting toolbox, including the results and a discussion of these.

Although important for the resulting motion of the motion platform, MCAs, their parametrization and tuning as well as motion fidelity are outside of the scope of this manuscript.

2 Implementation

This section will give an initial overview of the employed design concepts of the toolbox, followed by a more detailed description of the implementation in the following subsections. The implementation of the toolbox can be divided into two major parts: the implementation of the toolbox itself and the required modifications to the used aircraft simulation models.

The script-based toolbox is implemented in Matlab. To allow easy expansion of the toolbox’s capabilities later on, it is designed to use specialized modules. So far, the toolbox consists of two modules, the configuration generator and the recording generator.

The configuration generator packages the user input (from a Matlab script) and further data into a standardized format, readable by the other modules. The recording generator creates the flight profile recordings based on this configuration. To allow the easy addition of any aircraft simulation model to the toolbox without requiring changes to the recording generator module, a wrapper function-based approach is used. The wrapper functions act as a generalized interface to the aircraft simulation model-based control functions, e.g., for model initialization, as details thereof may differ between simulation models. Additionally, this also allows the use of models not implemented in Simulink, as long as their model-specific control functions can be controlled from the wrapper functions.

The requirement for usability of a simulation model with the toolbox is that functions can be implemented that replace the input from pilot-in-the-loop simulations with input from functions, which in turn can be called by the wrapper functions of the recording generator. This required changes to the existing aircraft simulation models used for recording generation so far. As of now, only the simulation model of the Airbus A320, implemented in Matlab Simulink, has been modified accordingly.

2.1 Toolbox

The script-based, modularized toolbox implements each module with a main function, which calls a set of further helper functions implementing the module’s functionality. All modules are called from a user-defined main script. The flight profiles to be recorded are also defined within this script. Additionally, configuration data directly concerning the profiles to be generated, such as the aircraft simulation models and seat positions to use, are defined here. Furthermore, general configuration data to enable the use of these models, such as file system paths to the aircraft simulation models and their specific control functions, are defined in this script. A simplified example of such a main script can be found in Listing 1.

Listing 1
figure a

Example of a user-defined main script with the call to the configuration generator module

Full size image

The configuration generator module takes these data as parameters and packages everything into a standardized format understood by all toolbox modules. A visual representation of this restructuring process is given in Fig. 1, showing the restructuring process for two flight profiles, two seat positions, two aircraft simulation models to use and the general configuration parameters.

Fig. 1
figure 1

Visual representation of the restructuring process of the configuration generator parameters into the recording configuration and general configuration MAT-files

Full size image

Flight profiles, aircraft simulation models and seat positions to use are rearranged into recording configurations with one flight profile and one simulation model each, together with all of the seat positions to use. The resulting structs are stored within a cell array, which is in turn finally saved to a MAT-file. The general configuration parts are saved within a separate MAT-file. The steps of the recording generation process described so far can be seen in Fig. 2, which shows the first of two parts of a flowchart describing the events of the recording process.

Fig. 2
figure 2

Simplified flowchart of steps involved in the recording generation process, part 1

Full size image

The recording generator module takes the paths to the configuration MAT-files as parameter and uses these paths to load the configuration files. Based on the loaded configuration data, it calls the specified aircraft simulation model through wrapper functions.

For each recording to be generated, the flight profile definition is passed on to the simulation-model-specific model control functions through the wrapper functions. These then generate the required lookup tables for the flight profile and initialize the aircraft simulation model (details on the lookup tables will be given in Sect. 2.2). Then, the simulation is run. After the simulation is finished, these control functions return the resulting time series of position, velocity and acceleration in all six degrees of freedom in the center of gravity (CG). The recording generator then recalculates velocities and accelerations for all required seat positions.

If, for example, a flight profile recording is required for three different seat positions, this only requires one simulation for the CG, still resulting in three recordings, with one for each seat position after recalculation. This saves time, as a separate simulation for each seat position is more time consuming than the recalculation of the resulting velocities and accelerations for each seat position. Each recording is finally saved as a separate MAT-file. In the end, the recording generator returns the names of these files. This part of the recording generation process is shown in Fig. 3 which shows part two of the flowchart describing the recording generation process.

Fig. 3
figure 3

Simplified flowchart of steps involved in the recording generation process, part 2

Full size image

2.2 Modification of the Airbus A320 simulation model for recording

The flight-physical model of an Airbus A320 used in the AVES simulator environment was modified to be usable with the developed toolbox, automating all previously manual inputs. This includes signals of the flight controls, especially autopilot (AP) modes and setpoints as well as signals concerning the environment and weather.

The flight profile segments contained in the configuration file can be characterized by the combination of used autopilot modes and respective setpoints, or by manual inputs on the aircraft’s control elements (such as the thrust lever or the sidestick). Segments can additionally be grouped in those solely depending on time and those also depending on other variables, e.g., reaching a certain altitude. Different approaches have been selected for the implementation of these two types of segments to translate the simplified segment definitions into the automated setting of the required control commands.

For segments solely depending on time, AP modes and setpoints only change depending on time. For example, this is the case for a slalom flight with a change of turn direction every 15 s. This allows a simplified definition of these segments as a lookup table, using time as input parameter. Within this lookup table for control commands, the required commands are stored together with the time at which they shall be set. When that point in time is reached, the corresponding control command values are set as output and feed the respective signals until the next point in time in the lookup table is reached.

A function for the generation of these lookup tables (“Function - Generate Lookup Tables” in Fig. 4) is called during simulation model initialization and is given the list of structures describing each of the flight profile’s segments as parameter. These structures are then processed consecutively. Depending on the segment type contained in the structure, a corresponding function is called, which generates the lookup table part for the segment. These functions are implemented beforehand for each type of segment required. An additional lookup table is generated containing information about the sequence and type of segments within the flight profile. This lookup table will be explained later.

Fig. 4
figure 4

Flowchart of the control commands lookup table generation process. Colors orange, blue and gray are used for easier association with segment types

Full size image

Input data to each specific segment generation function are the structure containing the segment definition from the list of structures describing the flight profile as well as the last column vector of the lookup table generated so far. The input data are used to generate column vectors containing the required control commands and points in time when they shall be set. These are appended to each other, resulting in a matrix. The resulting process is shown in Fig. 4.

In the first step (.1), the segment definition is loaded from the flight profile. Based on this, the generation function corresponding to the segment type is called in the second step (.2). Using the input data, it generates and returns a corresponding part of the lookup table (step .3). Thereafter (step .4), the returned part is appended to the previously generated parts of the lookup table. The last column vector of the lookup table is then extracted and used as input data for the generation function call for the next segment (step .5). Using this procedure, the complete lookup table for control commands can be created easily and quickly.

An example of a (simplified) lookup table is given in Fig. 5. It shows a lookup table for the use of the two AP modes heading (HDG) and altitude hold (ALT HOLD) for a 60 s cruise segment and a 105 s turns segment. As can be seen, both modes are enabled the whole time. As the aircraft shall fly at the same level during the whole flight profile, the target value for the ALT HOLD mode (Target ALT) also remains constant, so does the target value for the HDG mode (Target HDG) during the cruise segment, to maintain the flight direction of 180 degrees. Therefore, the cruise segment only requires two entries in the lookup table, one for the start and one for the end of the cruise segment. However, the target HDG periodically changes during the turns segment, requiring a lookup table entry for each change of the target HDG. The turns segment is finalized by a 15 s period, maintaining the target HDG of the last change so that the simulated aircraft has enough time to assume the last target HDG and stabilize in straight-and-level flight. This is done by adding a final column in the lookup table while kee** the target values of the previous column.

Fig. 5
figure 5

Example of a lookup table of a 60 s cruise and a 105 s turns segment with signals resulting from it

Full size image

With the current implementation, this final column is added by the lookup table generation function for the turns segment. Although the same result could be achieved by adding a 15 s cruise segment in the flight profile definition after each turns segment, this alternative solution may lead to a missing stabilization period if the user forgets to add it in the flight profile definition. Therefore, the implemented solution is preferred, as it guarantees the stabilization period in a way that it cannot be forgotten.

Using the lookup table Simulink block with the simulation time as input, signals as shown in the plot of Fig. 5 result and are fed into the AP, leading to the desired flight profile being flown.

In contrast to the segments solely depending on time, for those not solely depending on time, changes to the required control commands are also required depending on other variables and corresponding events. An example is the retraction of the landing gear during take-off, which is typically done when reaching a defined minimum altitude. Although it is theoretically possible to calculate a point in time for such events, this is disadvantageous because any change affecting such an event would require a recalculation of all time points. For example, for the reaching of a target altitude during climb after take-off, a new, higher target altitude would lead to a later point in time a level off is required.

In consequence, segments depending on variables other than time are not implemented using lookup tables as described before. Instead, they are directly implemented in the aircraft simulation model in Simulink, using a combination of logic blocks to check the required conditions and switch blocks to select adequate control commands.

The control commands are implemented as constant blocks, containing the control commands as column vectors. The switch blocks are fed with the logic blocks’ output signal. The logic blocks check for the required condition (e.g., the reaching of a specific altitude). This way it is possible to automatically switch between and thus select the appropriate control commands. This method of implementation is not used for solely time-dependent segments, as it requires a lot more implementation effort when adding new types of segments, compared to the implementation of lookup table generation functions.

Overall, the only requirement for a segment to be able to be generated is that it must be flyable using the available flight controls, AP modes and further signals available within the aircraft simulation model. For example, for the described level-off at a target altitude after the take-off, a signal containing the current aircraft altitude must be available. If this requirement is fulfilled, a way to implement the generation of the segment can be found and it can then be used with the toolbox.

To be able to generate all segments of a flight profile within one run of the aircraft simulation model, a method for switching between non-solely and solely time-dependent segments is required. It is implemented within the aircraft simulation model in Simulink. A simplified view of the relevant part of the model schematic can be seen in Fig. 6. The switching functionality is implemented using an additional lookup table, which is generated by the lookup tables generation function.

Fig. 6
figure 6

Simplified schematic of the implemented switch between non-solely time-dependent and solely time-dependent segments. Light blue: subsystem containing control signal generation for solely time-dependent segments; orange: subsystem containing control signal generation for non-solely time-dependent segments; magenta: lookup table, outputs current segment type (1 if solely time dependent, 0 if not); red: switch

Full size image

In contrast to the lookup table containing the aircraft control signals, it is not fed with the simulation time, but the number of the segment which shall currently be simulated in the sequence of segments of the flight profile. The current segment number is calculated by adding the number of segments for which the simulation is already completed and one. Depending on the resulting number, the lookup table outputs the type of the segment which shall currently be simulated, i.e., if the segment is solely time dependent or not. Using this signal, a simple switch block switches between the output of the subsystems generating the control signals for solely and non-solely time-dependent segments.

Additionally, the signal is used to switch the mentioned subsystems on and off using enable blocks within those subsystems. The current implementation of the switching functionality also uses memory blocks, which introduce a delay of one simulation time step of the numerical solver used in the aircraft simulation model.

In addition to the switching process during simulation, the initialization of each segment following a transition between solely and non-solely time-dependent segments has to be handled, similar to when the last column vector of the control command lookup table is used to obtain initial data for the generation of the next segment during the generation of multiple consecutive solely time-dependent segments as described earlier.

If a solely time-dependent segment follows after a non-solely time-dependent segment, the non-solely time-dependent segment’s last used commands column vector is read by the lookup tables’ generation function and then provided to the solely time-dependent segment’s segment-specific generation function as the parameter. This is possible even before simulation, as the control commands and setpoints used are known and only the time when they will be set is unknown. As timing is handled by the switching functionality in Simulink, the command and setpoint information contained in the commands column vector is enough for initialization of the solely time-dependent segment. This way, a cruise segment following a take-off segment can be provided with the level-off altitude of the take-off segment, at which the cruise segment shall be flown.

If a non-solely time-dependent segment follows after a solely time-dependent segment, the lookup table’s last column vector belonging to the solely time-dependent segment is used to initialize the first commands column vector for the non-solely time-dependent segment.

3 Tests

Two tests were conducted to validate the resulting toolbox. As a basis, functions for the generation of four types of segments were implemented: take-off with light turbulence (take-off), cruise with light turbulence (cruise), cruise with strong turbulence (turbulence) and turning flight with periodically changing target directions (turns) and light turbulence. The periodically changing target direction leads to a slalom-like flight profile during the turns segment. Cruise was additionally used as intermediate segment.

All generated flight profiles start with a take-off segment. Thereafter, intermediate segments and three test segments (cruise, turbulence, turns) follow in alternating order. The result are six flight profiles, each representing one possible order of the three test segments (see Table 1). All segments (except for the take-off) have a target duration of 240 s. The take-off segment instead has a target altitude and is a segment of the type not solely depending on time.

3.1 Test methods

To verify the reproducibility of a complete flight profile, flight profile 1 (see Table 1) with the test segments in the order cruise–turns–turbulence is recorded ten times and then compared. This is achieved by running the toolbox ten times using the same profile definition in the user-defined main script calling the toolbox.

Table 1 Order of test segments in the different flight profile variants
Full size table

To verify the reproducibility of the test segments and their properties, all flight profiles are recorded and compared. To achieve this, the six profiles as described in the previous section and Table 1 were defined in the user-defined main script, then the toolbox was run to generate all of the respective recordings.

As the two separate toolbox runs used separate configurations and different settings for the turbulence strengths during the turbulence segments, results are compared separately for both tests. Different turbulence strength settings were used to add an additional test point for the reproducibility of individual turbulence strength settings.

3.2 Results

3.2.1 Multiple recordings of the same flight profile

As can be seen exemplarily in Fig. 7 for the specific force’s component in the vertical direction, in the take-off segment and in Fig. 8 for the yaw rate in the turns segment, the amplitudes of the specific force components and angular rates agree very well across the flight profiles. However, deviations in time develop during the take-off segments, so that their end times do not match. These deviations can be seen very well in Fig. 9, which shows a magnified view of Fig. 7. The earliest and latest end times of the take-off segments differ by 0.66 s (see Table 2).

Fig. 7
figure 7

Specific force in the vertical direction, take-off segment and multiple recordings of flight profile 1

Full size image
Fig. 8
figure 8

Yaw rate, turns segment, and multiple recordings of flight profile 1

Full size image
Fig. 9
figure 9

Specific force in vertical direction, take-off segment detail, multiple recordings of flight profile 1

Full size image
Table 2 Duration of each segment type during different recordings of flight profile 1
Full size table

To be able to compare the agreement of the remaining segments, the data are shifted so that their start times match and correspond to zero. No deviations in time can be seen for the shifted data of the remaining segments. For example, this can be seen in Fig. 8 for the yaw rate in the turns segment. As can be seen from Table 2, only the duration of the first intermediate segments and the turns segments differs from the target duration of 240 s. The duration of the first intermediate segment of all recordings is exactly 240.01 s. The difference in the target duration is 0.01 s, which corresponds to the numerical solver’s step time used in the aircraft simulation model. The duration of all turns segments is exactly 225 s and is thus 15 s shorter than the target duration.

Two approaches are selected to compare the magnitudes of the specific force components and angular rates each across the different recordings. The take-off and the turns segments can well be characterized by the absolute values of specific force components and angular rates during the individual segment motion, e.g., the acceleration during the take-off run or the angular rate in yaw during a turn. Therefore, it makes sense to look at the absolute differences between each of the specific force components and angular rates and their mean across recordings.

The resulting absolute differences are small, which can be seen exemplarily for the specific force in the vertical direction during the take-off segments in Fig. 9 with a maximum difference of the peak values from the mean of less than 0.1 m/s2. For the angular rates, absolute differences are also small, which can be seen exemplarily for the yaw rate in the turns segment in Fig. 8 with a maximum difference of the peak values from the mean of less than 0.001 rad/s.

In contrast, the specific force components and angular rates during the cruise and turbulence segments are best characterized by the random accelerations and angular rates of the added turbulence. As it is randomly generated anew during each recording process, the comparison of absolute values with a mean is not meaningful. However, the acceleration’s root mean square (RMS) value should be approximately the same across all recordings. Therefore, the strength of turbulence during the cruise and turbulence segments is evaluated using the acceleration’s RMS value during the segment. Each segment’s acceleration RMS value is then compared to the mean of all acceleration RMS values, resulting in Table 3. As can be seen in the table, the maximum absolute difference to the overall mean of the cruise segments is 7.2243% and 6.1397% for the turbulence segments.

Table 3 RMS of the acceleration during cruise and turbulence segment of multiple recordings of the flight profile 1
Full size table

3.2.2 Comparison of the segment properties between different flight profiles

The magnitudes of the specific force components and angular rates are again evaluated as described in the previous section. The differences between specific force components during the take-off and between angular rates during the turns segments across the flight profiles are again small. For example, this can be seen in Fig. 10 for the specific force in the vertical direction during the take-off and in Fig. 11 for the yaw rate during the turns segments. For example, the absolute difference from the mean of the specific force in the vertical direction during the take-off segments at the peak at about 73.5 s (see Fig. 12) is again less than 0.1 m/s2. The maximum absolute difference of the yaw rate during the turns segments is small as well with less than 0.001 rad/s.

Fig. 10
figure 10

Specific force in the vertical direction, take-off segment and different flight profiles

Full size image
Fig. 11
figure 11

Yaw rate, turns segment and different flight profiles

Full size image
Fig. 12
figure 12

Specific force in the vertical direction, take-off segment, details and different flight profiles

Full size image

The similarity of the magnitudes between the cruise and all of the turbulence segments is again evaluated using the acceleration’s RMS value. As can be seen in Table 4, the maximum absolute difference of the overall mean of the cruise segments is 4.1825% and 3.1697% for the turbulence segments.

The deviations in time, as described in the previous section, are found again. The same difference between actual and target segment duration, which was observed for multiple recordings of the same flight profile, is found again for the first intermediate and the turns segments. Still, the actual durations of each segment type, except for the take-off segment, remain constant across the different flight profiles (see Table 5). Again, this can be seen very well looking at the yaw rate of the turns segment (see Fig. 11). The data have again been shifted in time as described in the previous section.

Table 4 RMS of the acceleration during cruise and turbulence segment of the different flight profile variants
Full size table
Table 5 Duration of each segment type during all flight profile variants (see Table 1)
Full size table

4 Discussion

Deviations of the actual segment duration from the target duration of the solely time-dependent segments (all types except for the take-off segment, which depends on the target altitude) are only found for the turns and first intermediate segments. The deviation of the turns segments’ duration can be explained with the periodic time of the changes of the autopilot target direction during the segment.

Within the lookup table generation function for the turns segment, the target direction is programmed to change every 30 s, followed by a 15-s period of straight-and-level flight in the end of the segment to allow for stabilization in straight-and-level flight after the last turn. With a segment target duration of 240 s, this leads to a remaining time for turns of 225 s. However, no multiple of the 30 s period is equal to 225 s. Thus, the segment target duration cannot be met.

With the current implementation, the lookup table generation function for the turns segment always selects the multiple of the periodic time resulting in the greatest segment duration lower than or equal to the target time. With a target duration of 240 s the closest achievable duration is 225 s (7 times 30 s for turns plus 15 s stabilization in the end).

This could be improved by automatically changing the periodic time to a duration with which the target duration can be achieved. Still, the segment duration itself remains reproducible very well, as the actual duration remains the same for all generated segments of type turns.

The deviation of the actual from the target duration of each first intermediate segment of 0.01 s is the result of the switching between the previous take-off segment, a segment which is not solely time dependent, to the intermediate segment, which is solely time dependent. Due to the current implementation, the switching itself takes exactly one simulation time step and thus exactly one step size of the numeric solver step time of 0.01 s. This can be avoided by adequately changing the switching implementation. However, this small but exactly reproducible deviation from the target time is deemed neglectable.

The differences of the absolute values of the specific force and angular rate result from the additional turbulence which is generated anew during each recording process. The turbulence generation is based on the filtering of white noise, but also depends on flight-physical quantities, for example the aircraft’s speed. The random noise in combination with the coupling of the flight dynamics results in the generally comparable, but slightly different timelines of specific force and angular rates in both time and magnitude. Still, the absolute differences remain small with a maximum absolute difference to the mean RMS of the acceleration of 7.2243%.

The mentioned causal relationship also explains the different end times of the take-off segments. The differing turbulence influence can lead to different points in time when certain conditions are met, for example when a certain altitude has been reached. This leads to the observed deviations in time between different recordings of the take-off segments. However, as the same maneuvers are triggered in all cases, which always lead to the generally same specific forces, the resulting differences of the amplitudes of specific force components and angular rates are very similar.

Still, the deviations in time show a non-optimal reproducibility of the take-off segment. Technically, if the same target altitude is required for all flight profiles to be generated, also using the same environmental conditions such as turbulence strength, it might seem feasible to reuse an existing recording of a take-off segment. If, however, different target altitudes and environmental conditions are required, this approach cannot be used and is therefore more restrictive than the implemented one. Additionally, as described in the introduction, problems may arise in the transition to the following segment. The toolbox avoids these by simulating each complete flight profile as one continuous simulation and thus avoiding jumps in relevant aircraft states and finally the resulting recorded motion profile. As the toolbox was originally implemented for motion sickness research, the existing implementation is favored, as it is more flexible and the variations in time and amplitudes are small, and thus a significant influence on the resulting motion sickness is not expected.

5 Summary

Overall, it can be said that the goal of automation of the recording process of flight profiles for simulator studies on motion sickness could be achieved. The high amount of manual labor previously required to produce such recordings by flying the required flight profiles within a simulator in a pilot-in-the-loop simulation and recording the necessary parameters has successfully been reduced to defining the flight profiles within a user-defined Matlab script and running the implemented toolbox. The toolbox’s capabilities can easily be extended by implementing further modules, adding to the existing configuration generator module and the recording generator module.

A complex simulation model of an Airbus A320, implemented in Simulink, was successfully modified for use with the toolbox. To be able to generate flight profiles for different types of segments, two approaches have been selected and implemented. If the segment depends solely on time, e.g., for a cruise flight of a certain duration, lookup tables are generated containing the necessary AP modes and setpoints to control the simulated aircraft to achieve the required flight maneuver for the segment. For segments not solely depending on time, e.g., a take-off with a level-off at a target altitude, the aircraft simulation model was modified to contain the necessary control commands, activated by the required condition, e.g., the current altitude as trigger for a level-off. Switching between the two types of segments was implemented within the aircraft simulation model as well.

Further aircraft simulation models can be added easily, as the toolbox’s recording generator module calls the aircraft simulation model-specific control functions (used for model initialization and running the simulation) through wrapper functions.

To validate the reproducibility of complete flight profiles and individual segments across different flight profiles, the toolbox was run twice, once generating the same flight profile ten times and a second time generating six flight profiles using the same segment definitions each time, but in varying order. Four different segments were implemented and used in these flight profiles: cruise, turbulence, turns and take-off.

The tests showed that especially the accuracy in time of solely time-dependent segment types is excellent. For these segment types, the only differences between actual and target segment duration are caused by the implementation of the respective segment lookup table generation functions, which can be improved easily. Still, the reproducibility was ideal, as even the deviations from the target duration of these segments were exactly reproducible. Especially when multiple flight profiles are required with as little deviation of the segment properties as possible between flight profiles, this is a clear improvement compared to the previously used manual approach.

The only segment type that not only depends on time, take-off, could also be reproduced very well, although not as exactly as the other segments. Still, only minimal differences in segment duration were observed across recordings. As the differences in duration are small, they are not expected to have a significant influence on the results of motion sickness studies, for which the generated flight profiles are intended.

For all segment types, all specific force components and angular rates were reproducible very well. Only minor absolute differences were found between individual segment’s RMS of the acceleration, specific force components, angular rates and the respective mean over all recordings. The observed differences are considered negligible with respect to their influence on the development of motion sickness.

Finally, it can be said that very good reproducibility of flight profiles and parts thereof across multiple recordings could be achieved.

6 Outlook

As the MCA used also plays a significant role in the finally resulting motion of the motion platform and therefore the felt motion within the simulator, an additional toolbox module simulating the MCA and motion platform can be beneficial to predict the shortcomings of the MCA, the MCA parameter set and the input data from the recording. Additionally, automatic MCA parameter tuning might be included as well to optimize the resulting platform motion with respect to the target motion. Furthermore, a module implementing a graphical user interface may be beneficial in facilitating the use of the toolbox.