Development and Implementation of a Mission Data-Handling Algorithm for an Automatic Flight Guidance System

Abstract

This paper presents a mission data-handling algorithm that provides a data link interface between a flight control computer (FCC) and a ground control station (GCS) using the protocol standard STANAG 4586, AEP-84 Volume II. A subset of defined messages is used for the transmission of mission and area definition data. Functions for decoding uplink messages, processing received data, and encoding downlink messages are developed. Due to a modular software architecture, these functions can be used both for the onboard FCC, as well as for the GCS using additional logic, to invert the transmission direction. Furthermore, high level consistency and validation checks are performed on the transmitted data before forwarding the mission to the flight guidance functions. Successful transmission of mission and area data between the FCC and the GCS is performed using a high-fidelity model-in-the-loop simulation of a demo mission for a medical evacuation eVTOL aircraft.

1. Introduction

In recent years unmanned aerial vehicles (UAVs) have attracted much attention, both in academia and industry. One of the reasons is the increasing demand for automated missions [1]. Compared to manned aerial systems, UAVs allow for higher payload and endurance since human factors do not need to be considered and related cockpit infrastructure is not needed. Especially for battery-powered vehicles, this is an important factor. Furthermore, efficiency can be greatly increased since remote operators are able to control and monitor multiple UAVs. Moreover, remote and hazardous areas are accessible without risking human life [2]. This, for example, plays a crucial role in search and rescue missions in difficult terrain [3]. These advantages make UAVs highly attractive to integrate into existing infrastructure, such as rescue and evacuation chains [4]. In order to execute automatic missions, means of the transmission of mission data between the GCS and FCC are required to allow the ground operator to plan and monitor the vehicle’s mission.

The automatic flight guidance system is designed to be used on a wide range of UAVs as a result of which a high degree of interoperability between air and ground segments is needed for communication. Communication protocols such as MAVLink [5] are mainly developed for the operation of small drones in line-of-sight. STANAG 4586, however, is better suited for larger UAVs that are operated beyond visual line-of-sight (BVLOS) in non-segregated airspace. Both communication standards, STANAG 4586 and MAVLink, share conceptual similarities, such as the waypoint upload. However, the attributes assigned to each waypoint differ in both standards. The communication protocols are limited for highly autonomous missions due to the definition of waypoint-based mission profiles [6]. This, however, is not restrictive for this work since a ground operator defines and monitors the fully automated mission. Moreover, STANAG 4586 is a NATO standard and commonly used in the military domain to ensure interoperability of UAVs from different countries [7]. Since the application at hand is a medical evacuation drone that is developed to be integrated in the rescue chain of the military, the STANAG 4586 protocol is the natural choice for transmitting mission data [8,9].

This paper proposes a mission data-handling algorithm based on the communication standard STANAG 4586 using AEP-84 Volume II [8]. It extends the work of Hochstrasser et al. [10] who developed a vehicle-specific module (VSM) that converts mission data between data link messages and a customized interface to the control functions. However, regarding guidance-related mission data, they only cover the transmission of position waypoints to the VSM. This work is an extension to their work that also handles vehicle-specific waypoints, route properties, and area data to define fly- and no-fly-zones (FZ/NFZ). This allows for the planning of fully automated missions from take-off until landing instead of only cruise flight. Moreover, these features allow for more detailed and accurate mission planning. For instance, routes can be defined as bidirectional, and leg types can not only be specified as track-to-fix but also as radius-to-fix. The definition of airspace restrictions is required to operate the UAV in non-segregated airspace. Furthermore, a mission data-handling module for the GCS is developed in addition to the VSM deployed on the FCC.

Frazzetta et al. [11] describe the general concept of the STANAG 4586 communication protocol. They highlight the benefit of using the protocol due to the high degree of interoperability between different GCS and UAVs, also for civil applications. A significant part of their work is the discussion of the contingency waypoint handling to define emergency flight plans, for example, in link loss situations. They define the emergency flight path to lead to a loiter zone where the UAV is trying to reacquire the data link. In this regard, the loiter waypoint is also discussed in detail. However, complete missions from take-off until landing are not covered. Furthermore, implementation details and specific results of their application to land surveillance are not provided.

Damilano et al. [12] developed a mission planning tool embedded in a GCS. They designed a mission concept that structures several elements, such as route plans, taxi plans, and airframe plans, that define the mission plan together. The mission plan is also based on the STANAG 4586 protocol standard. However, the focus is on the mission planning tool, an interactive tool for the ground operator to define and validate a mission, rather than on the data transmission process. The framework proposed in this work decouples the mission planning tool from the mission data-handling module on the GCS to allow for easier integration of the module with different mission planning tools. Furthermore, this work develops a mission data-handling module for the FCC and utilizes the modular software architecture to deploy the same functions in an inverted manner on the GCS.

The remaining sections are structured as follows: Section 2 introduces the system architecture of the medical evacuation eVTOL and the GCS, and how the mission data-handling modules are integrated. In Section 3, two mission data-handling modules are discussed, one executed on the FCC and a second one executed on the GCS. Section 3.1 introduces a set of functions that are used for mission and area upload/download capabilities and their working principle when deployed on the FCC. Section 3.2 explains, how an additional state logic allows for the re-usability of these functions on the GCS. In Section 4, the mission data-handling modules are discussed based on the results of a demo mission of a medical evacuation eVTOL. Section 5 summarizes the paper and suggests possible directions for future work.

2. Automated Mission Concept and Its System Architecture

Figure 1 shows the system architecture of the GCS and the FCC to perform a fully automated mission. It consists of the GCS and the FCC. A mission planning tool provides an interface to the GCS such that the operator can intuitively define the required mission.

2.1. Mission Planning Tool

The mission planning tool is an interactive map to intuitively specify missions based on waypoints, fly-zones, and no-fly-zones. The mission data are transmitted to the safety gateway of the GCS before uploading to the vehicle.

2.2. Safety Gateway

The safety gateway ensures that the mission defined by the operator is feasible. The mission is validated pre-flight on the GCS and only uploaded to the FCC if all checks succeed. The gateway considers different types of constraints. Checks on the environment ensure the aircraft is only operated in acceptable atmospheric conditions, e.g., within wind and temperature limits. The geographic checks guarantee that the aircraft is only operated in safe airspace, meaning it stays in the fly-zone and avoids no-fly-zones. A battery check ensures that the available energy for the mission is sufficient. Furthermore, flight control and performance limitations are taken into account, mainly originating from the trajectory generation and ATOL module [13].

2.3. Mission Data Handling

The focus of this work is on the mission data handling in order to transmit mission data between the GCS and the FCC according to the AEP-84 protocol [8]. The mission handling submodule decodes uplink messages, processes the mission data to be used by the subfunctions of the unified trajectory module, and encodes downlink messages. Due to a modular implementation, the subfunctions of the mission data handling can be used both on the FCC and the GCS. These subfunctions are complemented with the GCS logics to provide the required functionality of the data handling on the GCS. A detailed description of the functions and the implementation of the mission data handling is provided in Section 3.

2.4. Voting and Monitoring

The monitoring function checks for signal integrity and validity. All incoming signals of the FCC are monitored before forwarding them to the functions of the unified trajectory module and the inner loop controller. Generally, two independent data links, a direct link and an LTE link, using different technology are available such that signal voting can be performed. The voting function only forwards valid data to the subsequent functions. It selects the newest information of both data links according to the message timestamp. If the message timestamp on the direct link and the LTE link is identical, the direct link is prioritized due to its higher transmission speed.

2.5. System Automation

The system automation ensures that all functions are operated according to the procedural requirements. Most importantly it activates and deactivates the FCC functions. Based on operational sequence diagrams, it provides the moding such that the FCC functions are executed according to the concept of operations [14].

2.6. Automatic Take-Off and Landing (ATOL) and Trajectory Generation

Depending on the flight phase either the ATOL or the trajectory generation system is active: For take-off, the ATOL system performs a vertical climb to the take-off height that is specified by the operator. When reaching the take-off height, the transition into forward flight is performed. Therefore, the aircraft accelerates to the required minimum forward velocity before the trajectory generation module takes over for the cruise phase. When reaching the last waypoint, the ATOL system is activated again for the automatic landing maneuver to decelerate and transition to hover before vertical descent until the aircraft safely reaches the ground [15,16,17,18].

Both, the ATOL system and the trajectory generation continuously compute the error dynamics and the feedforward commands required by the trajectory controller. Depending on which module is active, the respective signals are forwarded to the trajectory controller.

2.7. Trajectory and Inner Loop Control

A unified trajectory controller is used for both hover and cruise flight phases when either the ATOL ststem or the trajectory generation is active. Based on the error dynamics and feedforward commands it tracks the desired trajectory [19]. The inner loop controller receives the commands by the trajectory controller and controls the rotational and thrust dynamics of the aircraft. The respective specific moments are computed and translated into the effector or propulsion commands by the control allocation.

3. Mission Data-Handling Algorithm

The mission data handling is responsible for the communication between the GCS and the FCC. The communication protocol is based on STANAG 4586 using AEP-84 Volume II [8]. The STANAG standard defines many messages that are useful for different applications. The mission data handling discussed in this work supports the subset of messages depicted in

Table 1. Supported STANAG messages in the mission data handling.

Message Identifier	Message Name	Description
#13000	mission transfer command	specifies an action, e.g., mission clear, mission transmit, and mission receive
#13001	UA route	specifies the route ID, the initial waypoint number, and the bidirectionality of a route
#13002	UA position waypoint	specifies the waypoint location, speed, and additional properties, such as the leg type
#13006	vehicle specific waypoint	used for the transmission of the take-off height and the circle center of radius-to-fix waypoints
#14000	mission upload/download status	used to indicate mission download success/failure
#4001	FROM-TO-NEXT waypoint states	dowlink message providing the current FROM, TO and NEXT waypoint
#2011	area transmission command	triggers an area upload/download and indicates the completion of an area upload/download
#2012	area polygon loop segment message	specifies the vertices of FZs and NFZs
#3012	area status alert message	reports success/failure of an area upload
#3013	area transmission status	downlink status message specifying the number of areas and the safety offset
#17000	message acknowledgement	used for handshake between GCS and FCC reporting transmission success/failure

. The messages #13000–#14000, #4001 are used for the mission transfer, while the messages #2011–#3013 are used for the area transfer. The #17000 message is used for both—mission and area transmission.

Two modules are developed: One module is executed on the FCC, the other one on the GCS. The core functions of both modules are the same. Section 3.1 thoroughly introduces these functions and explains how the functions are used on the FCC to receive and transmit the mission data. In Section 3.2, it is discussed how these functions are used on the GCS for receiving and transmitting mission data.

3.1. Mission Data Handling on the FCC

This section explains the functionalities of the mission data handling executed on the FCC. According to Figure 1, it receives STANAG 4586 messages from the GCS that were passed through the voting and monitoring module. The voting and monitoring function that separates the mission data handling on the GCS side and the FCC side only checks the signal integrity and validity. On the FCC, the proposed algorithm supports mission upload, mission download, mission clear, area upload, and area download functionalities. We refer to an upload when data are transmitted from the GCS to the FCC. Download is defined as a transmission from the FCC to the GCS. The mission data include waypoints and their attributes, such as leg-type or turn maneuver. The area data define FZs and NFZs and their attributes, such as their shape, e.g., polygonal or circular. Note that introducing circular airspace definitions is not intended by the AEP-84 standard. This is a custom feature that is introduced for the application discussed in this work.

Figure 2 shows the system architecture of the mission data-handling module executed on the FCC. Note, that the system structure is similar for both the waypoint and the area handling. Structuring the mission data-handling module in the proposed subfunctions results in a modular software architecture that allows the reuse of the functions developed for the FCC on the GCS. The individual subfunctions of the module are explained in detail in the subsequent sections.

3.1.1. Message Sampling

In order to mitigate data loss of event-based messages sent asynchronously between different devices, one message is sent multiple times to ensure the messages are transmitted successfully. The data only need to be processed once. Processing the same message several times would increase computational effort and could lead to undesired behavior. Therefore, based on the timestamp of a message, the message sampling function determines whether the message has already been processed. Redundant messages are transmitted with the same time stamp. If a message is received ($update\_flg=1$), the timestamp specified in that message is checked. If the timestamp remains the same, the message has already been processed, otherwise it has yet to be processed. As the STANAG protocol is designed to send only one message at a time, this defines a unique processing scheme which increases the robustness for data transmission. This also reduces the likelihood of timeouts during the transmission process, which could abort the mission transfer and would require a new transmission trial from the beginning.

3.1.2. Preprocessing of Waypoint and Area Data

The preprocessing is responsible for decoding the received STANAG messages. This includes both incoming waypoint and area data. From the decoded data, the internal moding is determined. It is evaluated which task needs to be performed, e.g., which of the core functions (mission upload/download or area upload/download) is called. The decoded data are forwarded and afterwards processed by that respective function. In the case of waypoint transmission, a #13000 is received containing the mission mode, e.g., the information whether to call the mission upload, mission download, or mission clearance function. The mission mode transmit mission triggers an update of the waypoint list, meaning the waypoint list is assembled and, if valid, forwarded to the trajectory generation and ATOL function. The clear mission mode deletes the active waypoint list and the receive mission mode initiates the download of all waypoints from the FCC to the GCS. According to the STANAG protocol, the #13006 message can be used for multiple purposes: In the application discussed here, either the take-off height or, in case of a radius-to-fix waypoint, the center of the radius-to-fix is extracted from the message. The #2011 message defines the transfer mode, meaning it determines whether to call the upload function (e.g., transfer mode is initiate upload), the area download function (e.g., transfer mode is initial download), or indicate the completion of an area upload (e.g., transfer mode is upload complete).

3.1.3. Acknowledgement

According to the STANAG protocol each message is acknowledged when it is received from the FCC or the GCS. This handshake ensures that data transmission is only continued if the previous message has successfully been processed. Messages are mostly acknowledged by a #17000 message. This message contains the message type, e.g., the message ID of the message to be acknowledged and the acknowledgment type, meaning the information whether the message was accepted or rejected. A rejection can be caused for multiple reasons, for example, if the voting and monitoring function (see Figure 1) identifies the signal to be invalid or the internal message validity checks fail. These checks, for example, include constraints on the maximum number of waypoints or areas (FZs, NFZs). In addition to its own timestamp, the #17000 message also contains the timestamp of the message to be acknowledged. Note that in a few cases an acknowledgment is not transmitted via a #17000 message. These cases are specifically mentioned in this work. If not stated otherwise, an acknowledgment refers to a #17000 message.

3.1.4. Timeout and Rejected Messages

A timeout defines the worst case transmission time for a message to be acknowledged. Generally, if a message is not received by the FCC/GCS within the defined time frame, the GCS/FCC re-sends the message a second time. If the message is still not received, the transmission is aborted. This increases the robustness as a successful upload and download sequence depends on the transmission of all messages. If a message is rejected, as indicated by the acknowledgment type, the message is also re-sent a second time. The GCS/FCC re-sends the message with an updated timestamp and waits again for the acknowledgment. If the FCC does not respond after the second try, the mission transfer is aborted.

3.1.5. Mission Upload

This section introduces the message sequence for the mission upload. Recall that a mission upload is defined as the transmission of waypoint data from the GCS to the FCC. The sequence of STANAG messages we propose for uploading a mission prior to flight is depicted in Figure 3. Note that each message received by the FCC is acknowledged by a #17000 message.

According to Figure 3, a #13000 message is received by the FCC with the instruction to clear the existing mission. This deletes all waypoints from the waypoint buffer and also the waypoint list. Note that for safety reasons, this command is only executed if the trajectory generation system is inactive as an invalid flight plan results in unpredictable and unsafe flight conditions. Once the message has been processed, the FCC responds with an acknowledgment message and indicates the success or failure of the requested command.

In order to perform an automatic take-off maneuver, the desired height for the initial take-off climb is transmitted using a custom #13006 message. The take-off height is defined as the above-ground-level (AGL) height which is required by the ATOL module for the vertical take-off maneuver. The FCC acknowledges the message with the information of success or failure.

Next, the waypoints are sequentially uploaded to the FCC. Each #13002 message contains one waypoint. Each waypoint is defined by the geographic location, the indicated airspeed, the leg type according to ARINC 424, and the type of waypoint transition, e.g., flyby or flyover.

Furthermore, each waypoint has a unique ID and the ID of the subsequent waypoint in the flight plan. This uniquely defines the order of waypoints in the flight plan. Therefore, the order of uploading the waypoints can be arbitrary. If a waypoint’s leg type in a #13002 is defined as a radius-to-fix waypoint, an additional #13006 message is sent from the GCS to the FCC. It specifies the geographic location of the center of the radius-to-fix and the turn direction.

The #13001 message defines the properties of the route. The activity ID indicates whether a route is bidirectional. The trajectory generation system will use this information to determine if the return-to-home function can be activated. This function inverts the flightplan and the aircraft flies back to the starting point. Furthermore, a waypoint flight does not necessarily need to start at the first waypoint in the flight plan. The initial waypoint property in the #13001 message defines at which waypoint the mission starts.

The uploaded waypoint data are stored in a buffer to allow waypoint upload in an arbitrary order. This also allows for efficient editing and deleting of waypoints as only changes in the flight plan need to be transmitted to the FCC instead of uploading the entire flight plan again. In order to convert the data to the required interface of the trajectory generation and ATOL system, the waypoint list assembly is triggered once the upload is complete. Figure 4 shows the interaction between the waypoint buffer and the waypoint list generation function.

After the waypoint list is generated, validity checks are performed that ensure that the expected number of waypoints equals the number of waypoints in the flight plan. Moreover, it is verified that the initial waypoint is part of the waypoint list. Then, the FCC sends an acknowledgment back to the GCS indicating whether the waypoint list is valid or invalid. Only valid waypoint lists are forwarded to the flight guidance functions.

3.1.6. Mission Download

This section describes the download of a waypoint list, meaning the transmission of waypoint data from the FCC to the GCS. The sequence of STANAG messages is depicted in Figure 5 and the corresponding implemented state logic is presented in Figure 6. As for the mission upload, there is always a handshake between the GCS and FCC to ensure that the data are received and accepted.

A mission download is requested by the GCS by sending a #13000 mission transfer command with the property receive mission to the FCC. Then, similar to the mission upload, #13002 messages are transmitted containing the waypoint data. The waypoint information, e.g., latitude, longitude, altitude, indicated airspeed, and leg type are obtained and packed from the onboard waypoint list and sent to the GCS. The waypoints are transmitted in the same order as specified in the flight plan. In case a waypoint is a radius-to-fix waypoint, an additional #13006 is sent to the GCS containing the center of the radius-to-fix. Once all waypoints are successfully transmitted, the mission data handling continues to send the route properties. This includes the initial waypoint and the activity ID which, as for the mission upload, represents if the route is bidirectional.

The sequence is concluded by the transmission of the mission download status to the GCS via a #14000 message and its corresponding acknowledgment. The mission status indicates whether the download was successful, e.g., mission download is completed, or unsuccessful, or mission download is aborted.

3.1.7. FROM-TO-NEXT Waypoint Status

The STANAG 4586 protocol defines the #4001 message to provide the status of the FROM, TO, and NEXT waypoints. The FROM waypoint is the waypoint the aircraft has passed most recently, the TO waypoint is the waypoint the aircraft is currently flying to, and the NEXT waypoint is the subsequent waypoint of the TO waypoint. The #4001 message is an event-based downlink message to transmit the waypoint triple when these waypoints change, e.g., if the aircraft has passed the TO waypoint and flies towards the subsequent waypoint in the flight plan. The information can be visualized on the GCS and helps the operator to monitor the aircraft.

3.1.8. Area Upload

This section introduces the area upload functionality of the mission data-handling module. Analogously to the waypoint upload, we define an area upload as a transmission of area data from the GCS to the FCC. Figure 7 describes the upload sequence of STANAG messages of the transmission process. As shown, the sequence follows the same concept as for the waypoint upload, where each STANAG message is acknowledged before another message is sent from the GCS.

Initially, an area transmission command is sent via a #2011 message to the FCC with the area transfer mode set to initiate upload. The message also defines the area loop count, which corresponds to the sum of the fly- and no-fly-zones that are about to be transmitted. A consistency check of the loop count ensures that the number of loops do not exceed the maximum number of eleven areas, e.g., one fly-zone and up to ten no-fly-zones. This requirement is introduced due to the limited memory of the FCC and is not restrictive to the problem at hand. However, if required the algorithm can easily be adapted for a larger number of areas.

After the area transmission command is processed, the areas are uploaded to the FCC by a sequence of #2012 messages. Each message defines an area loop, e.g., a fly-zone or a no-fly-zone. According to STANAG 4586, the shape is required to be a polygon which is defined by at least three vertices. The algorithm proposed here introduces an additional custom feature to also support circular-shaped no-fly-zones. In case of a circular NFZ, the number of vertices is two, as a circle is defined by two points. The activity ID in the #2012 message is used to define the shape type of a no-fly-zone. The message defines the number of vertices and their geographic location, e.g., latitude and longitude. Furthermore, it specifies the type of area, e.g., stay in (=FZ) or keep out (=NFZ). The areas are stored in a buffer before the area list is assembled and forwarded to the flight control functions. As for the waypoint buffer, this allows for data conversion to the required format of the flight guidance functions. Additionally, it simplifies editing the fly-zone or no-fly-zones. Note that circular areas are treated fully independently from the polygonal areas and are stored in a separate buffer, according to Figure 8. The rationale behind this is the geofencing function since the area list is generated for the geofencing module, which treats circles and polygons independently.

Once all areas have been transmitted, the GCS sends a #2011 area transmission command message indicating that the upload is complete. This triggers the generation of the area list required by the geofencing function. An area list ready flag indicates whether the uploaded area list is valid or invalid. So far, an area list is considered valid if the number of uploaded areas equals the number of expected area loops specified in the initial #2011 message. The upload sequence is finished by a #3012 area status alert message which, depending on the validity of the area list, informs the operator if the area upload was successful.

3.1.9. Area Download

This section covers the download functionality of an area list. Figure 9 depicts the sequence of STANAG messages used for the download.

Initially, the operator requests the download of the area list. The request is sent from the GCS to the FCC via a #2011 message with the property initiate download. The FCC responds with a #3013 message to indicate to the GCS that areas are about to be transmitted. It also confirms properties of the requested area (specified by the area ID), such as the safety offset and the area loop count. Once acknowledged by the GCS, the area download starts. A sequence of #2012 messages each containing a circular area or polygon is sent to the GCS. The information transmitted by each #2012 message equals the upload information and is described in Section 3.1.8. The individual areas are packed in the same order as stored in the area list. A handshake confirms that the respective area was received by the GCS and allows the FCC to continue sending the next area. When all areas have been transmitted, a confirmation that the download is completed is sent via a #2011 message to the GCS.

The implemented state logic of this sequence is depicted in Figure 10. As mentioned in Section 3.1.4, the GCS re-sends a message a second time if the message is not received before the entire sequence is aborted.

3.2. Mission Data Handling on the GCS

This section discusses the mission data-handling module deployed on the GCS. The functions deployed on the FCC can also be used in an inverted manner on the GCS by reusing the download functions to upload data from the GCS to the FCC. Only an additional state logic, e.g., the GCS logic shown in Figure 1, needs to be introduced. The GCS logic determines the moding for the mission management, which includes the safety gateway for mission validation and the mission data-handling functions for mission and area upload to the FCC. The safety gateway is beyond the scope of this work and is described in detail in [13]. The state machine of the additional GCS logic is shown in Figure 11.

The operator can request a mission validation or a mission upload. A mission validation request only checks for the feasibility of the mission but does not upload the mission to the FCC. A mission upload request, however, first validates the mission and automatically uploads the mission to the FCC in case of successful validation. For safety reasons, a mission cannot be transmitted to the FCC without prior validation.

In the automated mission concept, the operator sends a mission upload request from the mission planning tool.

The mission data from the mission planning tool are sent to the GCS in a single message and stored in a waypoint and area buffer. Therefore, the waypoint and area buffer introduced in Section 3.1.5 and Section 3.1.8 is reused on the GCS and the received data from the BMS are written into the waypoint and area buffer. From the buffer, the waypoint and area list is assembled in the same manner as in the mission data-handling module deployed on the FCC.

Once the waypoint and area list are assembled, the safety gateway performs a mission feasibility check to ensure that only feasible missions are uploaded and executed on the FCC. In the event the operator only requests a mission validation, according to Figure 11, the sequence terminates once the validation result is available. This allows for continuous checks of the mission validity to support the operator while planning a mission. If the operator requested a mission upload, the sequence continues and the mission and areas are transmitted to the FCC unless mission validation has failed.

The communication protocol for the waypoint upload is described in Section 3.1.5; the area upload is described in Section 3.1.8. Recall that, according to Figure 3 and Figure 7, the data transmission is based on a sequence of messages where the GCS and the FCC always respond to each other when a message is received. Due to this handshake, the onboard functions can be used in an inverted manner on the GCS. Therefore, the download functions are deployed on the GCS to read out the waypoint and area data, pack them into the corresponding STANAG messages, and transmit the messages to the FCC.

Figure 12 shows the signal flow and summarizes how the upload and download functions are used for the communication between the GCS and the FCC.

Once the operator requests a mission upload, the GCS is triggered to transmit a #13000 message with the property transmit mission. The FCC responds with an acknowledgment message which triggers the mission download function on the GCS. As a result, each waypoint in the flight plan is transmitted to the FCC.

After all the waypoints are successfully uploaded, the areas are transmitted in a similar way: A #2011 message with the property initiate upload triggers the transmission sequence depicted in Figure 9. Each area is packed one after another from the area list and transmitted to the FCC. Note that the last message sent from the FCC to the GCS indicates that the download is complete. Due to the inverted use of the function on the GCS, this message needs to be interpreted as an upload complete.

According to Figure 11, the mission management also reports the corresponding errors in case of failure during the validation and upload process. As described in Section 3.1.4, a timeout is introduced to define a worst case execution time. Therefore, the timeout ensures that the system is reset after a defined time period.

4. Simulation Results

In this section, the mission data-handling algorithm is demonstrated based on high-fidelity simulations of an eVTOL evacuation drone.

As mentioned in Section 2.1, the operator defines the mission in a mission planning tool. The operator specifies the location of the waypoints and defines the allowed airspace, e.g., the FZ and NFZs. Figure 13 shows a demo mission planned in a battle management system (BMS) used by the German armed forces. Initially, the medical evacuation drone (denoted by the cross) is located on a trailer (TROL) depicted by the blue symbols in the bottom-right corner. From there, the operations and logistics are conducted. The drone is then sent to the casualty collection point (CCP), where the patient is loaded into the aircraft and transported to the next hospital [20]. The landing pad and the hospital are labeled as ROLE2 in the top-right corner. The airspace is defined by a single FZ denoted by the dashed, gray rectangle.

Internally, the overall mission, e.g., TROL → CCP → hospital, is divided into two subsequent missions, namely TROL → CCP (mission 1), followed by CCP → hospital (mission 2). Prior to the first mission, only mission 1-related data are transmitted from the GCS to the FCC. Once the mission is successfully validated and uploaded, the mission is executed. Afterwards, when the mission 1 is completed and the patient has been loaded into the medical cabin of the eVTOL, mission 2 is uploaded and executed.

Since the logical sequence of the mission transfer remains the same for mission 1 and 2, only the results of mission 1 are presented in the following.

Figure 14 shows how the implemented state logic from Figure 11 controls the mission management. Recall from Section 3.2 that the operator has the option to only validate a mission by calling a validation request or to validate and transmit a mission to the FCC by calling a mission upload request to ensure that only the current data from the planning tool are considered. Both scenarios are discussed below.

• Validation request: As depicted in Figure 14, the operator initially commands a validation request. The waypoint and area data from the BMS are written into the waypoint and area buffer from where the waypoint and area list are assembled according to Section 3.1.5 and Section 3.1.8. Afterwards, high-level validity checks, such as range checks, are performed on the waypoint and area list to ensure the completeness of the lists. However, the high-level validity checks performed inside the mission data handling do not necessarily result in an overall feasible mission. Additional constraints, such as geographic constraints, power consumption, etc., need to be satisfied, too. Therefore, the feasibility of the entire mission is determined by means of a safety gateway, as shown in Figure 1 and briefly introduced in Section 2.2. The rising signal of the check feasibility flag in Figure 14 triggers the safety gateway and the feasibility success flag confirms the feasibility of the mission. This concludes the validation sequence and the GCS state machine returns into the standby state according to Figure 11.
• Mission upload request: According to Figure 14, the operator files a mission upload request at approximately $t=1.1$ s. As shown in Figure 11, this triggers the mission validation discussed earlier. Furthermore, once validation is successful, e.g., feasibility success flag $=1$, the GCS additionally initiates the waypoint upload, which is shown by the rising flag of the upload waypoint list signal. The messages are transmitted according to the sequence depicted in Figure 3. Subsequently, the upload area list flag initiates the area upload according to the message sequence from Figure 7. The waypoint upload success flag and the area upload success flag confirm that all the waypoints and areas are successfully transmitted to the FCC.

Figure 15 shows the data transmission process in more detail: It takes approximately $t=0.4$ s until the sequence of messages for the mission and area upload is completed. As described in Figure 3, the GCS transmits messages containing the mission and area data as well as route specific information. The FCC responds to each message, acknowledging the message type, e.g., the message identifier, and the acknowledgment type that indicates whether a message is accepted or rejected. The STANAG 4586 protocol defines the acknowledgment type $=2$ as success and the acknowledgment type $=3$ as failure [8]. As can be seen, all the messages are successfully processed and the GCS only transmits a new message after the FCC acknowledges the corresponding message. Note that the last message transmitted from the GCS confirms the completion of the area upload, but does not contain new area-related data as mentioned in Section 3.1.8. Therefore, the FCC responds with a #3012 status message instead of a #17000 acknowledgment message.

According to the STANAG 4586 protocol, the waypoints and areas are transmitted sequentially. Once the transmission process is completed, the waypoint list and area list required by the flight guidance functions are assembled. Recall from Section 3.1.5 that depending on the mission plan mode in the #13000 message, either the mission upload or the waypoint list assembly is triggered. Similarly, the area transfer mode in message #2011 controls whether to upload areas or initiate the area list assembly, as described in Section 3.1.8. The waypoint and area list assembly starts once the mission plan mode $=2$ is set, e.g., transmit mission, and the area transfer mode $=2$ is set, e.g., upload complete. Since mission 1 has only one waypoint and one area, the assembly is already completed and verified in the same execution time step as the assembly request was filed. Figure 16 confirms the validity as a waypoint list valid flag $=1$ and an area list valid flag $=1$. Once the waypoint and area list are successfully verified, they are forwarded to the flight guidance functions. Note that the verification of the waypoint and area list was already performed on the GCS. However, in case of data loss during the transmission process, the waypoint and area list are verified again on the FCC. The take-off height is directly processed from the custom #13006 message and not part of the waypoint list. Therefore, as seen in Figure 16, the take-off height is received earlier than the waypoint list. Furthermore, the latitude and longitude of the only waypoint, e.g., the CCP, in the waypoint list of mission 1 is shown in Figure 16.

5. Conclusions

A mission data-handling algorithm was introduced for the exchange of mission and area data between the GCS and the FCC. Therefore, two modules, one executed on the GCS and one executed on the FCC, were developed. While the mission data-handling module on the FCC supports upload and download functionalities, the module on the GCS only supports the upload functionality at the moment. Future work is anticipated to include the support of multiple missions as it can be useful to define multiple missions prior to flight instead of sequentially transmitting new missions only after the previous mission is completed. Both the mission data-handling modules were tested and verified in high-fidelity simulations. Currently, the modules are also tested in a hardware-in-the loop (HIL) environment. Once HIL testing is completed, flight tests of fully automated missions of the medical evacuation eVTOL aircraft will be performed.