This figure overviews the outcomes of the team effort to build a cloud-based UTM (UAS Traffic Management) system. This system integrates efforts in pre-departure dynamic geofencing, en-route traffic alerting, emergency landing, and contingency management for intelligent low-altitude airspace UAS traffic management.

Iowa State University's (ISU's) \href{https://www.aere.iastate.edu/~pwei/people.html}{Intelligent Aerospace System's Lab (IASL)} led the effort to develop the UTM's conflict detection logic, as well as the UTM's interface and database framework.  The predeparture flight planning module is the first line of defense to ensure safety between flight plans. There are two main components to the predeparture flight planner; (1) server interaction and (2) conflict detection with dynamic geofencing. While the pre-departure dynamic geofence is meant to be the main way conflicts are detected and avoided, the en-route traffic alerting mechanism is necessary to detect the unforeseen conflicts that are possible during flight. Examples of such conflicts are: wrong flight plan execution, slower than expected cruise speed, and unexpected turbulence. To detect such conflicts, an en-route traffic alerting functionality was added to the UTM to monitor and predict the flight paths of all UAS in the air and determine if any predicted path intersect. If a conflict is detected, the UTM alerts both parties of the conflict.

University of Iowa's \href{https://hfdata.opl.uiowa.edu/opl/}{Operator Performance Laboratory (OPL)} directed the integration effort between the cloud-based UTM and the Vapor 55 UAS. OPL developed ground control station software for transmitting telemetry data from the UAS and negotiating the flight plans for normal and emergency operations. To ensure safety, the pilot in command (PIC) has full control and discretion over aircraft operation while airborne. A flight plan includes the takeoff time, duration, ground speed, waypoints, and any proposed actions taken at each waypoint such as wait periods or payload actions.  The UTM software evaluates a proposed flight plan against other submitted flight plans and checks for conflicts. Conflicts result in rejection of the flight plan, possibly accompanied with a reason. Once a flight plan gets accepted, the UTM software tracks the progress of the flight using a numerical identifier and checks for conflicts during flight. If a conflict occurs in flight, the ground control station issues a  warning to the PIC, who must submit a conflict-free flight plan for approval  In a simulated emergency situation the ground control station can accept an emergency flight plan at any time, directing the UAS to the nearest safe landing zone.

University of Michigan's \href{https://a2sys.engin.umich.edu/}{Autonomous Aerospace Systems Lab} oversaw the development and integration of the emergency landing and contingency planning module into the GCS for the Vapor 55. The team presented and discussed an Emergency Landing Planner (ELP) in terms of its algorithm, practical implementation in OPL's environment, and in system-level emergency landing tests.  The emergency landing planner was implemented as a client with bi-directional data link with the GCS server. Simulations were conducted to establish the efficacy of the presented planner.

\href{https://www.mosaicatm.com/}{Mosiac ATM}  designed and developed user interfaces to support situational awareness and planning for traffic management. The Traffic Management Human-Machine Interface (TM-HMI) provides 4D, integrated view of flight plans, vehicle activity, and predicted conflicts within the IUTM system. The TM-HMI is a custom software application built on node.js which reads and displays information from the core IUTM data store (a PostgreSQL database).  It is a read-only interface in that it provides situational awareness to traffic management users, but it does not modify data for the rest of the system. The team performed numerous joint integration tests to verify whole-system interoperability and identify issues prior to the final flight test.

ISU's \href{http://temporallogic.org/research/}{Laboratory for Temporal Logic} led the integration of the runtime verification (RV) tool \href{http://temporallogic.org/research/R2U2/}{R2U2} across the three different layers of an actual UTM implementation: on-board the individual UAS, in conjunction with each operator's GCS, and embedded into a centralized, cloud-based UTM server. By validating and releasing over 100 runtime Mission-time Linear Temporal Logic (MLTL) specifications, two sets of recorded traces from test flights of a real-life UTM implementation, and the results of checking those formulas, we contribute a large benchmark suite. This suite is useful for verification of the algorithms and implementations of future RV tools, providing both nominal and faulty traces and realistic sensor noise and outlier readings that challenge RV engines. We demonstrated real-time performance of extending MLTL formulas with a single first-order operator, where we validate whether a specification holds for all UAS or if there exists a UAS that violates a specification. To ensure we did not miss covering unstated assumptions, we used coverage metrics to brainstorm our list of 124 specifications: variable coverage (every variable appears in at least one specification) and pattern coverage (specifications follow each pattern from previous work). Flight tests (both real and simulated) revealed scenarios such as when sensor noise and outliers triggered false positives; we were able to establish patterns to eliminate all identified false positives.

Last Modified: 04/12/2022
Modified by: Kristin Y Rozier