Content area
Purpose
The purpose of this paper is to present research on the flight demonstration of avionics technology for CS-23 commuter category aircraft. The Integrated Mission Management System (IMMS) is designed to reduce pilot workload by aggregating hazard information from multiple domains (airspace, traffic, weather and terrain) and automatically prefiltering this data to display only hazards relevant to the flight plan, from origin to destination. This paper details the design of the IMMS, along with the process of the integration on aircraft and flight demonstration results.
Design/methodology/approach
The IMMS integrates several technologies, including the Advanced Weather Awareness System, Tactical Separation System, Compact Computing Platform and Flight Reconfiguration System. Hazards are consolidated in a Unified Hazard Database (UHD) and assigned severity levels, providing automated hazard filtering and path planning.
Findings
Simulations and flight tests demonstrated that the IMMS effectively reduces the information displayed to pilots in real-time without loss of critical safety data. Feedbacks from test pilots on IMMS usage, as well as suggestions for improving the multi-source Graphical User Interface, are also discussed.
Research limitations/implications
Limitations of the UHD were identified, offering insights into potential expansions to support more efficient automatic flight planning. The technology was validated through extensive laboratory testing and real-world flight trials, achieving Technology Readiness Level 5. This validation demonstrated how the severity of hazards can be linked to their transparency level on the display, with the aim of reducing information overload.
Practical implications
The IMMS shows potential to be ground-breaking system in the CS-23 aircraft category, autonomously supporting route planning and flight execution while adapting to in-flight weather changes and ensuring tactical separation from other aircraft. It also shows that multi-domain hazard information can be processed on limited on-board avionics systems.
Originality/value
This study highlights the importance of Hardware-In-The-Loop testing in verifying new technologies and mitigating risks related to software reliability, flight demonstrations and system integration.
= Automatic Dependent Surveillance – Broadcast;
= Air Traffic Control;
= Airspace User Plan;
= Advanced Weather Awareness System;
= Compact Computing Platform;
= Cost Affordable Avionics System;
= European Union Aviation Safety Agency;
= Electronic Flight Instrument System;
= Evektor EV-55 aircraft;
= Evolved Advanced Weather Awareness System;
= Evolved Tactical Separation System;
= Flight Management System;
= Flight Reconfiguration System;
= Scalable Global Navigation Satellite System Receiver;
= Graphical User Interface;
= Hardware-In-The-Loop;
= Human–Machine Interface;
= International Civil Aviation Organisation;
= Integrated Modular Avionics;
Integrated Mission Management System;
= Meteorological AviaTIon Supporting SystEm;
= Multi-Criteria Decision-Making;
= Multi-function Display;
= Low-Cost Integrated Navigation System;
= Near-real time;
= Integrated Primary Flight Display;
= Pressure setting of altimeter according to given on field/aerodrome elevation;
= Pressure setting of altimeter according to pressure given on the sea level;
= Pressure setting of altimeter to standard pressure of 1,013.25 hPa;
= Affordable Surveillance System;
= Temporary Reserved Area;
= Technology Readiness Level;
= Tactical Separation System;
= Unified Hazard Database; and
= User Interface.
1. Introduction
The aircraft industry faces challenges driven by the trend towards decarbonisation. It is reasonable to assume that extending the usage period of already-produced aircraft could significantly reduce overall resource consumption related to their production. While aircraft structures can endure many years of use if properly maintained, operational costs are strongly influenced by route planning and its execution. As noted in Chilton et al. (2017) and Della Vecchia et al. (2022), with advances in integrated modular avionics, basic six instruments in general aviation are increasingly being replaced by integrated displays, which enhance flight planning and reduce route execution costs.
When analysing available flight products for planning and route execution, it is observed that some systems are intended to run on separate tablets not connected to aircraft systems (e.g. SkyDemon and Jeppesen Mobile FlightDeck VFR) (SkyDemon, 2024; Jeppesen, 2024), with information occasionally updated via GSM networks (unreliable at higher altitudes). Although these systems have the advantage of not requiring updates to aircraft systems, they are limited, as data such as air traffic information from ADS-B are not processed. Another trend is the installation of Integrated Modular Avionics devices, such as the Garmin G3X Touch (FAA, 2024; Garmin, 2024), in the cockpits of CS-23 aircraft connecting them to the aircraft installations.
None of analysed systems offers explicit information on prefiltering methods intended for reduction of hazard number displayed to the pilot. Methods generally involve layered hazard displays, visual information reduction based on map area or manual pilot settings of hazards based on their origin (e.g. air traffic display). While pre-flight information, such as terrain hazards or airspace information is valid for the flight’s duration, dynamic factors like weather changes can necessitate in-flight route diversions. For hazards that arise mid-flight, pilots must process this information correctly, but errors may occur because of either insufficient data from on-board equipment or pilot oversight, potentially caused by information overload (FAA, 2024; Wickens et al., 2023). The dynamic change in the number of displayed hazards may cause some of them to flicker, drawing the pilot’s attention similarly to how warning lights in the cockpit do. This highlights the need for effective automatic data processing to reduce the amount of information pilots must manage directly without attracting attention.
The Clean Aviation COAST project is dedicated to developing cost-effective avionics tailored for small aircraft, particularly those in the EASA CS-23 category (Clean Aviation, 2024). The project focuses on addressing operational costs, reducing pilot workload and enhancing safety, with the goal of paving the way for future single-pilot operations. These technologies were developed within a multinational consortium spanning the Czech Republic, Italy and Poland, starting in 2016 (Di Vito et al., 2017; Lucky et al., 2024), all aimed at significantly improving operational efficiency and safety standards. To facilitate understanding, descriptions of each contributing technology are provided, along with related references:
Tactical Separation System: An ADS-B-based self-separation system enhances traffic situational awareness and suggests manoeuvres to maintain required separation, emphasising affordability and compatibility with air traffic control standards (Di Vito et al., 2021a; Di Vito et al., 2022b; Di Vito et al., 2022c; Di Vito et al., 2023).
Advanced Weather Awareness System: It involves furnishing comprehensive weather information to pilots, including observed and forecasted data, to aid in avoiding hazardous weather conditions through an on-board application, graphical interface, ground element and integrated satellite communications (Montesarchio et al., 2021; Montesarchio et al., 2022; Zollo et al., 2023).
Flight Reconfiguration System: This is an emergency flight path management system capable of deployment in cases of pilot incapacitation, collaborating with navigation systems, flight controls and additional sensors, potentially incorporating further advisory functions (Grzybowski and Szpakowska-Peas, 2020).
Compact Computing Platform: This is a scalable, reusable platform for advanced cockpit functions in CS-23 category aircraft, featuring compact hardware design, innovative software architecture and straightforward customisation options for different aircraft platforms (Zaykov et al., 2021).
Low-Cost Integrated Navigation System: It is a navigation system designed for the final phases of flight, approach and landing in the small aircraft transport segment, offering affordability and seamless integration support (Vaispacher et al., 2022).
Affordable Surveillance System: It addresses operational needs for low-altitude operations and threat detection in the small aircraft transport segment with cost-effective surveillance technology (Kanovsky et al., 2022).
Scalable Global Navigation Satellite System Receiver: A dual-frequency, multiple constellation GNSS receiver offers improved accuracy, integrity and reliability through innovative hardware and software paradigms, accommodating signals from various satellite constellations.
Integrated Mission Management System: This is an affordable system automating tactical separation, weather awareness, trajectory planning and tracking guidance tasks during flight, aimed at reducing pilot workload and enhancing operational efficiency (Di Vito et al., 2021b; Di Vito et al., 2022a).
Each stage of technology maturity was verified through appropriate tests, which included:
preliminary algorithm verification in a simulation environment (2016–2018);
Software-In-The-Loop testing of the algorithm for route diversion in a real-life simulation (2018–2019);
Hardware-In-The-Loop (HIL) testing of the algorithm deployed to the hardware FRS unit and connected to the simulation laboratory stand for route diversion (landing with autopilot in simulation) (2019–2021);
first flight demonstration–verification of the FRS unit's ability to define an emergency solution using multi-criteria decision-making (MCDM) methods and calculate a trajectory based on the signals available on-board the aircraft, TSS and AWAS technology verification (June 2021);
Pilot-In-The-Loop testing of the HMI guiding the pilot to the chosen FRS destination–simulation trials (2021–2022); and
second flight demonstration–verification of the FRS unit's advisory function on-board, aiding the pilot (September 2022).
Given that contributing technologies were successfully tested, the decision was made to merge the functionalities of TSS, AWAS, FRS and embed them in the Compact Computing Platform as previously described Integrated Mission Management System (IMMS) concept. This required unifying data within the Unified Hazard Database (UHD), developed under this project.
It was expected that this approach, which facilitates real-time data exchange between on-board systems and IMMS algorithms, would allow NRT updates of information displayed to the pilot, even with limited computational power derived from CCP hardware limitations. Data from multiple sources were processed by algorithms that provided route planning support and automatic hazard detection, affecting both the planned route and real-time aircraft position. With this capability, several additional benefits could be achieved, such as providing the pilot with automatic updates on weather hazards emerging at the destination airport (even beyond the line of sight), extending the time available for deciding whether to continue according to the flight plan or to search for an alternate destination. It could also assist the pilot during the flight planning phase by aiding in automatic route definition and checking the minimum conditions for the origin and destination runway (e.g. determining if the crosswind on the runway complies with the aircraft’s performance limits).
To verify the IMMS technology up to Technology Readiness Level 5 (TRL 5), both simulation trials and real-world demonstrations were to be conducted.
2. Methodology
As the IMMS is a technology developed to assist pilots during single-pilot operations by reducing the information processing workload and performing automated path diversions in case new hazards emerge, the following requirements have been established for the system:
It must be capable of gathering on-board signals and data concerning hazards during flight.
It must be capable of filtering hazards, displaying only those that are determined as potentially hazardous to flight.
It must be able to detect new hazards affecting the route and promptly inform the pilot.
It must be capable of suggesting route diversions in the event of new hazards.
The IMMS's interaction with the pilot must undergo in-flight testing for technology verification.
To facilitate the development of the IMMS, a UHD format was designed, enabling the processing of hazard data from various sources (Figure 1).
This data would be used for both route planning and monitoring and assigning severity parameters to reduce pilot workload associated with processing multiple hazards. A notable feature of the format was the introduction of bounding cylinders containing prisms, describing each hazard (with vertices defining the bases of the prisms), along with the minimal and maximal altitudes corresponding to both the cylinders’ and prisms’ bases.
Introducing these parameters significantly reduced the computational power required to identify which hazards are near the aircraft or planned route. For instance, comparing the cylinder radius to the distance between the cylinder’s centre and either the aircraft’s position or the route segment required less computation than checking if the aircraft’s position is within the polygon constituting the prism’s base or if the path segment is crossing the prism.
The IMMS algorithm defines a subset B of hazards affecting the route, from the complete set A containing all hazards. By defining this subset B, calculations can be performed at different frequencies. The complete set A is used when processing user input (e.g. defining origin and destination airports or route changes induced by the pilot), while the subset B is used for calculations related to flight monitoring and reconfiguration running at a frequency of 10 Hz.
To define subset B of hazards affecting the route or the aircraft, a severity parameter was included, ranging between 0 and 1, corresponding to the risk of either damage to the aircraft when entering the prism volume or the risk of violating aviation regulations (0 indicating no risk and 1 indicating certainty). The idea of this was defined as an experimental parameter that would be beneficial for marking hazards that must be considered for route planning and must be displayed to the pilot. During simulation trials under the COAST project, it became evident that using a static value to define severity was insufficient to achieve a noticeable reduction in the number of hazards displayed. Therefore, a method was proposed to assign severity values based on the flight state: where:
S – hazard severity <0,1>;
Si – initial hazard severity from the UHD <0,1>;
Sd – hazard severity dependent on the subset (0 for hazards not in subset B and 1 for hazards in subset B); and
Sh – hazard severity based on the aircraft’s altitude relative to the hazard and the hazard type <0,1>.
The last parameter (Sh) in the equation was defined for specific hazard types based on heuristic knowledge, aircraft altitude and data on cylinder/prism bases stored in the UHD. These were defined according to the following set of equations: where:h – airplane GNSS altitude;hhazard bottom – the cylinder/prism minimal altitude;
hhazard top – the cylinder/prism maximal altitude;
hguard bottom – bottom guard altitude value; and
hguard top – top guard altitude value.
Figure 2 shows the Sh parameter for a TRA-type hazard, where all TRA hazards have been assigned values of hguard bottom = 1,000 ft and hguard top = 1,000 ft. The authors’ intention was to avoid informing the pilot about hazards for which the severity would be calculated as 0 (i.e. those not impacting the route, not in the vicinity of the aircraft or sufficiently separated vertically). The area marked in red indicates altitudes where Sh = 1, while the blue areas represent heuristic transition altitudes designed to prevent hazard display flickering as the aircraft changes altitude approaching the red zone.
As shown in Figure 3, there are different shapes of hazard severity in the case of precipitation. In this example, for hguard top = 1,000 ft and above and hhazard top = 8,000 ft, it was considered safe to fly; however, it was considered unfavourable to fly below the rain cloud, so hhazard bottom = 0 ft and hguard bottom = 0 ft.
All types of hazards in the database were analysed and subjected to description with severity parameter similarly using heuristic knowledge from flight experience to determine when the interaction with it constitutes a threat. For the software implementation before flight demonstration, such approach was considered satisfactory, as the idea emerged within the project, but from the higher TRL’s altitudes of guards, this was considered as an important factor that would need to be included in the updated UHD format.
The proposed methods were coded into the IMMS software and implemented within the application running on the CCP. Following the successful integration with the CCP, a test campaign was conducted, which included:
HIL testing of the IMMS software running on the Compact Computing Platform (April 2023); and
a third flight demonstration to verify the IMMS's ability to enhance pilot situational awareness and enable route diversion (June 2023).
The IMMS application tests included:
gathering data from the CCP’s inputs, such as instantaneous weather information (from the MATISSE system), traffic data from the SURV unit, GNSS-provided aircraft position using ARINC429 data buses and static pre-flight data related to airspace, terrain, available airports and aircraft limitations;
processing data from multiple sources and forming a UHD;
automatically selecting optimised departure and arrival runways based on wind conditions and aircraft limitations;
testing the Graphical User Interface, including displaying data from multiple sources and performing automatic dynamic pre-filtering of hazards relevant to the aircraft's state to be displayed on a tablet;
testing an algorithm that automatically detects whether hazards emerging during flight interfere with the planned path, destination airport or the aircraft itself; and
testing an algorithm that proposes route diversions and optimises the trajectory.
The EV-55 aircraft was used for the flight demonstration, with two dedicated flights conducted over the Czech Republic to verify compliance with IMMS requirements.
3. The Integrated Mission Management System technology design, development and results
The development of IMMS software began with the division into two essential components: the backend app and the frontend app, both executed on the CCP. The backend app was coded using the C++ programming language, while the frontend app was crafted using Javascript/HTML and accessed through a mobile device, particularly a tablet. It is noteworthy that the initial version of the frontend app was built upon the AWAS and TSS technologies, serving as its foundational framework. To ensure smooth communication between the frontend and backend apps, a dedicated protocol was meticulously designed and subsequently implemented. The software running is developed as an application running simultaneously with other applications on the CCP, sharing resources (e.g. access to the information collected from the digital data busses like ARINC 429’s, computational power and memory).
Update on the hazards incoming from weather source (Evo-AWAS) and traffic (Evo-TSS) was realised in the interrupt service routine, as soon as new information was available. For weather hazards, server was providing new data each 5 min, and for traffic, hazards with the frequency of 10 Hz were provided independently of IMMS application.
Because of complexity of software development for the CCP, a decision was made to handwrite the IMMS code and UHD component rather than rely on automatic code generation. This approach allowed for the development of custom “connectors” for the various interfaces allowing smooth operation of the IMMS backend part, especially related to data interchange essential for the flight monitoring phase of the algorithm.
The creation of these databases, particularly for airspaces, presented challenges. National Air Navigation Services provide their Airspace Use Plan (AUP) in a non-standardised format, necessitating the development of a dedicated script to process online AUP data into the IMMS standard format for storage in CCP memory. Furthermore, additional functions were introduced to calculate the centroid and radius of the circumcircle of a polygon, as the UHD requires more information than that provided by the AUP alone. Also, information about aircraft performance (maximal take off distance, maximal allowed crosswind and maximal allowed speed on the ground) was stored in the CCP.
The IMMS backend application was divided into three core parts that were running dependent on the users’ choice, namely: flight planning routine, flight monitoring routine and flight reconfiguration routine which were to be executed in the CCP with the frequency of 2 Hz (Figure 4).
Flight planning
For flight planning purposes (intended to be used while still on-ground), the user-provided origin and destination airports ICAO code that underwent validation against an internal airport database. If incorrect data was defined (such as an e.g. incorrect ICAO code of departure or destination airport) or parameters that could impede a flight, then the pilot was alerted with an appropriate prompt. Following this, the algorithm evaluated whether the wind conditions at these airports were compatible with the operational capabilities of the aircraft. Only runways of selected airports with suitable wind conditions and runways lengths were deemed viable options for either the origin or destination of the flight and for further considerations in flight plan. For this purpose, user input wind direction and speed at origin and destination were casted along the runways directions to compute front-wind component and cross-wind component. If for a given runway either wind components exceeded ones from aircraft performance model or the runway was too short for take-off or landing, then such runway was disregarded for the path planning. Such approach allowed for saving computational power for calculating routes between multiple origin runways and destinations limiting calculations to those that runways that could be used for operations. Next, for each runway, IMMS algorithm defined a departure point as well as final approach fix point used for path planning function. By integrating the information about these points with the information on hazards from UHD, a path was generated for combinations of origin and destination airports. All paths were considered by the IMMS algorithm as potential routes.
To define the single proposed path to the pilot, the MCDM implementation was used similarly as in the method used in the FRS (Grzybowski and Szpakowska Peas, 2020). The decision-making algorithm was assigning points for route lengths (shorter route – higher score), route difficulty (less turns higher score) and combining it with runway suitability. Possible pairs of origin and destination runways were sorted by points to pick the best possible connection. Figure 5 depicts the simulation trails for definition of Kunovice (LKKU) airport as a departure and Prague airport (LKPR) as a destination.
As the MCDM method has taken into account several factors, including path length, runway conditions and the complexity of executing the path (determined by the number of turns en-route and number of possible hazards en-route crossing straight line path), the best possible route was sent to the IMMS frontend application to be displayed to the pilot (Figure 6).
Additionally, the pilot was able to verify the entered data using a table summarising the input data, the proposed route length and the number of expected turns. To prevent accidental overwriting of entered data, actions such as approving a new flight plan or confirming a proposed flight plan reconfiguration require an additional confirmation step with the use of dedicated button “Accept flight plan”. If the pilot was not satisfied with the solution, then a “Decline” button should be pressed allowing for restarting flight planning process. Upon pilot acceptance, the algorithm transitions to the second phase: flight monitoring.
Flight monitoring
Within flight monitoring, the data within the UHD were subjected to processing dependent on the aircraft state. For each hazard, severity S was calculated. For the purpose of the reduction of the pilot effort and improvement of situational awareness, this parameter was used as input for the function within IMMS frontend application associating it with hazard transparency on the display. Figure 7a depicts the information display change related to the severity (S < 1) parameters for three weather hazards, while on Figure 7b, it can be seen similar situation where for all hazards S = 1. A notable change in colour intensity can be noticed. For S = 0, hazards would not be displayed.
The hazards appeared as if they were emerging from the fog, with severe ones being more prominent and fading back into it as their severity decreased. This minimised the flickering effect when reducing the number of hazards displayed in the dynamic environment. Given the fact that the method of displaying hazards was experimental one, the application allowed to switch between showing all hazards in the database or to show only one with S in the range of (0, 1).
Finally, given the subset B of potential hazards, a subroutine was called that was responsible for prompting the pilot to meet conditions for reconfiguration. If the possible route was significantly shorter than the remaining original route or if the destination airport was within the weather hazard polygon or if the original path from origin to destination collided with hazards that appeared during flight, then the subroutine would send a reconfiguration request to the IMMS HMI to be displayed to the pilot. In parallel, the new route was defined using one of three implemented route planning algorithms to be verified:
a straight-line flight from the departure point to the final approach fix (automatically defined path as the reference optimal path, which could also serve as an emergency route);
a user-predefined alternate route (predefined before the flight); or
a customised adaptation of line-of-sight algorithm (automatic route planning) (Nash and Koenig, 2013).
Flight reconfiguring
During the flight reconfiguration phase, as a result of ongoing flight monitoring, the pilot may be prompted with a revised flight path. Upon the acceptance of proposed path by clicking the “Route Reconfiguration Available” button, the proposed path replaced the planned flight path, and the algorithm resumed flight monitoring based on the updated trajectory. An example of this approach is shown in Figure 8, where the IMMS HMI proposes a reconfigured path (grey) defined by the line-of-sight route planning algorithm, which is a shorter route than the planned path (green).
As shown in the figure, the IMMS HMI was designed to display hazards from different domains (airspace, traffic, terrain and weather) on a single screen. It is to be noticed that analysing multiple hazards from different domains may be challenging based solely on the graphics, especially in cases where shapes overlap. For this reason, automatic hazard pre-filtering based on severity was a primary research focus, demonstrating that although a single screen is used, the number of displayed hazards can be reduced effectively without compromising safety.
4. The Integrated Mission Management System integration and Hardware-In-The-Loop testing for pre-flight validation
Flight demonstrations are typically the most expensive and risky part of the validation process. By using the HIL testing methodology, the COAST team was able to simulate real-world conditions in a controlled environment, ensuring the system’s readiness for flight testing. To achieve this, a laboratory stand comprising essential components, as depicted in Figure 9, was designed. System elements that would be installed on-board the aircraft are marked in green, while blue dots represent the power supply and information connections available during the flight demonstration from the aircraft installations. It was assumed that the interaction between the user or pilot and display would resemble an EFIS, but with the displays not permanently installed in the cockpit like PFDs and MFDs, but operated using tablets.
The laboratory stand was required to simulate aircraft flight and the signals originating from aircraft systems. To simulate aircraft dynamics and environmental conditions, the X-Plane flight simulator was used, embedded in the Flight Dynamics PC running a dedicated model of the EV-55 Outback. The data from the simulation was converted into ARINC429 words, a step facilitated by the ARINC429 Converter. This device, developed specifically for the COAST project, allowed for the conversion of data received via the UDP connection from X-Plane into ARINC429 words of user-defined content and frequency. This data was then transmitted through one of the eight ARINC429 transmission lines of the converter. For the simulation, four ARINC429 lines were used, mimicking the GNSS receiver, AHRS, Radio Altimeter and Air Data Computer. The information sent to the CCP included aircraft latitude, longitude, time, date, ground speed, track, north velocity, east velocity (GNSS data bus), altitudes relative to QFE, QNE, QNH, vertical velocity and airspeed (Air Data Computer data bus).
Additionally, the HIL laboratory stand was complemented by a software development PC, which allowed constant monitoring of parameters on the CCP, identification of software errors and fine-tuning of algorithms. This setup enabled conclusions to be drawn during testing. The SURV unit, during HIL tests, transmitted previously recorded air traffic information to the CCP, used by the Evo-TSS application. Real-time weather data, used by the Evo-AWAS and IMMS, was delivered from the MATISSE server, located over 1,500 km away, via the internet.
The HIL tests of the IMMS running on the CCP provided valuable insights into the software’s behaviour under various scenarios, enabling the identification and resolution of potential issues before flight tests. The IMMS successfully created a portion of the UHD, incorporating terrain and airspace hazards from data stored in the CCP’s internal memory. It was also confirmed that the database of airports and aircraft performance was processed correctly. However, during the creation of the UHD for weather and air traffic hazards, minor software errors were encountered, which initially prevented data exchange between applications running on the CCP. A debugging session revealed that the Evo-TSS and Evo-AWAS applications required additional ARINC429 frames related to date and time, which were not yet implemented in the ARINC429 converter. After addressing this issue, a remote connection to the MATISSE server was successfully established, and the SURV unit provided data correctly. At this stage, the IMMS software was able to create a complete UHD by merging data from various sources.
The HIL laboratory stand facilitated simulated flights, with the purpose of testing various IMMS functions, including user interaction, hazard analysis, route planning and route reconfiguration.
Initial challenges, such as communication speed issues between frontend and backend applications, were resolved through intensive debugging sessions, improving application performance and enabling information updates on the screen at a frequency of 10 Hz. Solutions were implemented to ensure effective communication and data presentation (Figure 10).
Further verification flights using the HIL stand confirmed the robustness of the IMMS software in processing data from ARINC429 buses and using this data for algorithm execution. The IMMS backend application analysed the aircraft’s state in relation to hazards sourced from both the CCP and external applications. These simulated flights validated the software’s ability to process data accurately, generating essential structures for IMMS algorithms to facilitate route planning, monitoring and reconfiguration. Notably, the IMMS demonstrated its capability to identify and mark weather, traffic, terrain and airspace hazards that could impact the planned trajectory or be in the vicinity of the aircraft equipped with IMMS.
In the flight planning function, the IMMS successfully computed routes, ensuring proper navigation for the aircraft, though, as with all route planning algorithms, it could benefit from better alignment with pilot input. In the event of changing conditions during flight, the backend communicated with the frontend application, providing the pilot with necessary information for route reconfiguration. This allowed timely adjustments to the flight path, optimising both safety and efficiency throughout the flight. Moreover, hazards dynamically adjusted their appearance based on their severity relative to the aircraft’s altitude, enhancing operators’ situational awareness in simulated flights. Importantly, this data was independent of visual cues and remained consistent between simulations and real-life scenarios, making it a reliable foundation for IMMS flights under both Visual Flight Rules and Instrument Flight Rules.
The operation of the HIL laboratory stand was crucial for assessing the IMMS software’s capabilities on the CCP and identifying improvements before flight tests. One proposed improvement was to modify the IMMS frontend application to accommodate multiple users, specifically pilots and flight engineers, to enhance collaboration during flight operations. Considering that good weather might prevail during the test flights and that real-time weather download had already been tested in the HIL environment, it was decided that a flight engineer operating a tablet in the back of the aircraft could request predefined weather conditions from the MATISSE server. This would ensure that both the trajectory and destination airport were affected. Upon such a request, the MATISSE server responded with packets processed by the Evo-AWAS application, transmitted to the IMMS and displayed to the pilot.
5. Flight demonstration of the Integrated Mission Management System
The flight demonstration took place near Kunovice Airport (Czech Republic) using the EV-55 aircraft. The aircraft is designed to meet the certification requirements of CS-23/FAR Part 23 and was prepared in advance for integration with systems developed under the COAST project (Figure 11).
Figure 12 shows the system setup used during the flight demonstration. A key difference from the HIL structure (shown in Figure 9) is that inputs from the ARINC 429 converter were connected to the on-board avionics, including the AHRS, Air Data Computer, GNSS Receiver and Radio Altimeter. The power source was switched to the on-board 24V DC, and the MATISSE server was connected via SATCOM. Additionally, no Software Development PC was available on board. Software updates, such as algorithm tuning or hazard display modifications, could only be performed on the ground.
Although favourable weather was expected for the demonstration, one of the primary objectives was to test the IMMS’s ability to detect weather hazards. To support this, the software on the flight test engineer’s tablet was modified to request simulated weather data from the MATISSE server at different times, ensuring the destination airport and flight route would be affected by simulated hazards sent remotely.
The flight demonstration focused on three main aspects: the IMMS’s ability to gather on-board data from multiple sources and generate a UHD, its capacity to assess hazard severity based on the aircraft’s state (using data from Evo-FRS, as seen in Figure 12, with the purpose of the information overload reduction) and its capability to detect deviations or intrusions in the planned route and propose alternatives.
During the pre-flight briefing, two test pilots from Evektor, the aircraft manufacturer, were introduced to the IMMS interface (the Pilot’s tablet installed in the cockpit). For each flight, pilots and engineers reviewed the planned scenarios outlined on test cards. The flights followed these predetermined scenarios, with all pilot inputs recorded throughout the flights. Pilots executed the test card scenarios under the supervision of the flight test engineer, while a second engineer managed and monitored the system’s operation. All flights were coordinated with ATC, and the Flight Readiness Review, along with the safety review, was conducted with the aircraft manufacturer before conducting flights.
In the initial flight, pilots flew a route from Kunovice (LKKU) to Vyskov (LKVY) and back. During this flight, the IMMS’s ability to update the flight plan in response to changing weather conditions was tested. The system performed successfully, meeting all objectives and ensuring a safe return to LKKU with a total flight time of 18 min. Importantly, the flight confirmed the reliable data exchange capabilities of the integrated IMMS technology, including Evo-AWAS and Evo-TSS. Real-time weather data from the MATISSE server in Capua aided the algorithms in defining optimal flight paths and evaluating hazard severity, resulting in enhanced displays on the cockpit interface (Figure 13).
Second flight focused on testing hazard prefiltering using automatically assigned severity parameter based on aircraft altitude and position. Concluding, a significant reduction of the visible hazard presence on the map was observed (from over 500 hazards including weather, traffic, terrain and airspace hazards, to just a few in vicinity of the aircraft). Notably, airspace hazards situated high above the aircraft’s altitude were effectively filtered out from the pilot’s view, streamlining the data processing effort required during the flight (Figure 14). It is also worth mentioning that when dealing with air traffic pilots tended to first notice the hazards on the tablet and verify the traffic visually afterwards. No situation of the IMMS not informing about hazardous traffic was observed.
The third flight involved diverting the IMMS planned route in response to beyond line-of-sight changes in weather detected by AWAS. For this purpose, during the air operation, flight test engineer used the tablet to request weather information from the MATISSE server that would affect planned path and destination airport in Prague (LKPR). Once information on the weather phenomena impacting the planned route was received, the IMMS software responded by proposing an alternative route (calculated using the route planning algorithm designed for the FRS).
Post-flight analysis of screen recordings of Pilot’s tablet allowed to analyse the behaviour of the IMMS display. Examples on Figure 14 are comparing information provided in “all hazards mode” near the aircraft and only the severe ones when the pilot switched to “Severe hazards mode”. A significant reduction in displayed hazards can be observed, with the number dropping from 65 hazards to just 13, as identified by the algorithm as severe. Also, the hazards flickering was not present during display with severity being associated with their transparency.
An analysis of video recordings of the pilot’s inputs revealed a preference for viewing all hazards during take-off and landing, while favouring the prefiltered severe hazard mode during the cruise phase of the flight. This feedback highlights the importance of offering pilots customizable hazard display options to improve situational awareness and flight safety.
After the flights, pilots provided valuable insights during the debriefing session. While the route representation was considered satisfactory for providing essential navigation information, concerns were raised regarding the usability of the user interface (UI). Turbulence during the flights made interacting with the tablet touchscreen challenging, particularly when trying to press buttons and navigate the interface. Pilots suggested enlarging the interface and relocating buttons to the bottom of the screen for easier access, with an emphasis on optimising the map display area. Additionally, it was noted that the right-hand column of the UI remained unused during the flight, suggesting opportunities for streamlining and optimising the interface layout. Several minor issues were noted during the flight test, including ambiguity surrounding the functionality of the “Refresh” (hazards) button, as pilots reported difficulty in determining whether the IMMS was busy loading the database. This highlighted the need for clearer on-screen messaging.
Despite these UI challenges, the flights were deemed successful, meeting all predetermined success criteria. Although pilots reported minor inconveniences with the UI, their feedback indicates that incorporating these preferences should not require major changes to the overall IMMS structure. This presents a promising opportunity to address usability concerns while maintaining the IMMS system’s backend, which performed flawlessly.
Given that the prefiltering of hazards was active for most of the flight, the system’s functionality in adjusting the transparency of displayed hazards based on severity was considered effective. Furthermore, it was demonstrated that hazards from various sources – such as weather, traffic, airspace and terrain – can be displayed on a single screen without overwhelming the pilot, especially when automatic hazard prefiltering is enabled.
6. Conclusions
The paper presented a segment of the verification process for the IMMS technology, focusing specifically on the flight demonstration phase. The pilots conducting the tests effectively processed integrated information from the IMMS, which included weather conditions, traffic data, path planning, airspace information and terrain data. Despite existing hardware limitations, the UHD played a crucial role in fulfilling operational requirements. The IMMS successfully identified hazards that conflicted with the planned trajectory, were in the aircraft’s vicinity or affected the destination airport. Providing pilots with this hazard information extended decision-making time during necessary path alterations, especially when new weather hazards rendered the destination airport unavailable. Furthermore, the automatic prefiltering of relevant hazard information enhanced situational awareness and reduced information overload. Test pilots provided positive feedback regarding the IMMS; however, they suggested minor modifications to the GUI to improve usability.
While automated path planning algorithms exhibited limitations when using information from the UHD, the methods developed to reduce the overall set of hazards and detect new ones based on the severity parameter demonstrated promise for future applications in automated path planning for aircraft.
Regarding future research, it is recommended to formalise the UHD structure further. The current format lacks information on data obsolescence and does not include timestamps for hazard activation and deactivation. Future efforts should focus on refining hazard avoidance strategies and path planning based on hazard prioritisation while considering the aircraft’s configuration. Additionally, exploring methods to mitigate overlapping hazards from different domains, such as Temporary Restricted Airspace intersecting with icing weather conditions, is crucial, particularly under aircraft equipment limitations, such as the absence of anti-icing capabilities.
Finally, the IMMS behaviour in real-life scenarios was consistent with observations from Hardware-In-The-Loop simulations, which validated the methodology used during the project and contributed to achieving Technology Readiness Level 5 (TRL5).
Cost Optimised Avionics SysTem (COAST) project has received funding from the Clean Sky 2 Joint Undertaking (Clean Aviation), under the European Union’s Horizon 2020 research and innovation programme (Grant Agreement Number 945535).
Figure 1Example of the unified hazard database format and visualisation for TMA hazards
Figure 2Visual representation of example temporary reserved area hazard severity depended on the altitude
Figure 3Visual representation of precipitation hazard severity depended on the altitude
Figure 4The Integrated Mission Management System software dataflow
Figure 5Result of multi-criteria decision-making application prompting on debugging console possible routes between Kunovice airport “LKKU” and Prague airport “LKPR”
Figure 6The Integrated Mission Management System human–machine interface displaying the current planned route on the map, with its parameters in the flight plan table
Figure 7The Integrated Mission Management System severity influence on weather hazards dependent on altitude
Figure 8The Integrated Mission Management System frontend application displaying the planned path and a proposed path for reconfiguration
Figure 9The human–machine interface laboratory stand structure used for Integrated Mission Management System testing
Figure 10The Integrated Mission Management System planning path avoiding weather hazards and temporary reserved area
Figure 11The EV-55 before flight testing the Integrated Mission Management System
Figure 12The system structure used for in-flight Integrated Mission Management System demonstration
Figure 13Tablets running Integrated Mission Management System application during flight demonstration
Figure 14Example screenshots of hazards displayed on the Integrated Mission Management System human–machine interface tablet captured during the flight demonstration
© Emerald Publishing Limited.