mock_uss flight engine design

This page describes the design of the new mock_uss flight engine.

Motivation

Historically, mock_uss has had very basic functionality and all of the flight planning activities have been lumped together. This flexible flight engine is proposed to fulfill the needs of a wider range of jurisdictions/environments with many different flight planning requirements that need to be tested.

Architecture

Engine

mock_uss will have a flight engine responsible for performing all flight-planning-related activities. This engine will be invoked by the APIs which cause flight planning activities to occur -- currently, the legacy SCD injection API and the newer flight_planning API.

Flight condition sets

mock_uss's flight engine will be provided with a collection of "flight condition sets" in its configuration (which is loaded upon startup). Each flight condition set will have:

• Applicability criteria for the flight condition set (e.g., "flight intersects Switzerland")
• Specifications of flight condition instances (see below) to be evaluated for that flight condition set

This will replace our current Locality; each existing locality will instead become a flight condition set with appropriate applicability criteria and appropriate flight conditions specified. For instance, CHE locality will likely become a flight condition set applicable to any flight in Europe, and having flight conditions for both U-space flight authorisation and ASTM F3548-21.

Flight conditions

A flight condition is a condition that must be satisfied for flight and may involve evaluation of criteria and/or performance of actions. Each type of flight condition will implement the interface outlined below, and an instance of a flight condition type will be instantiated using the specification for that flight condition instance (provided via "flight condition sets" configuration).

Expected flight condition types include:

ASTM F3548-21 strategic conflict detection

A flight may only proceed on the condition that mock_uss meets the requirements for the strategic conflict detection service defined in ASTM F3548-21. This includes constructing operational intents, evaluating conflicts between operational intents, and sharing operational intents with other USSs.

U-space flight authorisation via ASTM F3548-21

A flight may only proceed on the condition that U-space flight authorisation requirements have been fulfilled via the use of ASTM F3548-21. This includes the presence of an "ASTM F3548-21 strategic conflict detection" flight condition in the flight condition set, validation of information provided by the user regarding their flight authorisation, and recording of the flight authorisation.

Geoawareness

A flight may only proceed on one or more of these conditions being satisfied (according to flight condition specification):

• The flight, if it's a particular kind, doesn't intersect a particular category of geographical information from a specified geographical data source
• For particular kinds of flights, the user is advised if the flight intersects a particular category of geographical information from a specified geographical data source

Flight planning procedure

When the engine's plan_flight is invoked, the following steps are performed:

1. Flight engine identifies the flight conditions applicable to the flight
2. If execution_style is Hypothetical, just have each flight condition validate whether it would be satisfied. No state associated with the flight plan should be mutated.
   1. For instance, the F3548 flight condition would construct an operational intent for the flight and check whether there were any disallowed conflicts with other operational intents
3. If execution_style is IfAllowed or InReality, attempt to have all flight conditions commit the flight sequentially.
   1. Each flight condition will produce a commit result artifact containing relevant information about the flight used to satisfy that flight condition, and these results will be persisted in the database along with the planning request.
      1. For instance, the F3548 flight condition's commit result would store the full operational intent for the flight.
      2. These commit results will be the basis of performing other functions, such as retrieving operational intent details. When queried for operational intent details, the F3548 flight condition would look through the flights in the database for ones with an F3548 commit result. The operational intent in that matching F3548 commit result would be used to fulfill the request for operational intent details.
   2. Each flight condition's commit will have access to the commit results from previous flight conditions.
   3. Flight conditions may indicate they need more information (for instance, when U-space wants to see a successful F3548 flight condition result). When that happens, the flight engine will finish the remaining flight conditions' commits and then return to the flight conditions that indicated they needed more information.
   4. Committing ends when all flight conditions have committed, or fails when any flight condition rejects/fails the commit, or fails when no flight condition indicating "more information needed" is resolved by a pass through all uncommitted flight conditions.
   5. If the flight was not committed, all flight conditions that successfully committed are instructed to revert their commit.

Implementation plan

We already have the logical functionality for commit for an ASTM F3548-21 flight condition and a U-space flight authorisation condition. This functionality can be refactored into the form of two FlightConditions and called directly (without an engine) initially. Once the FlightCondition functionality is ready (with NotSupported for validate and no action for revert, initially), adding the engine to orchestrate calling that functionality should be a relatively small task. At this point, we will have an MVP flight engine and can begin expansion including (when appropriate) performing appropriate actions for revert and implementing validate.