Ariadne : A common-sense thread for enabling provable safety in air mobility systems with unreliable components

Commercial air travel is by far the safest transportation modality available to humanity today. It has achieved this enviable status by deploying thousands of professionals, including pilots, dispatchers, and air traﬃc controllers to operate very reliable air vehicles, bringing them and their passengers safely from origin to destination while managing dangerous weather, other traﬃc and system failures for decades. The air transportation has been undergoing undeni-able and continuous progress and modernization since its inception. Thanks to advances in navigation capabilities, such as satellite-based navigation systems, aircraft can ﬂy increasingly complex trajectories, including ﬁnal approaches. The same aircraft are envisioned to ﬂy in formation relatively soon. More daring moves include the recent introduction of "Free Flight" operations. Despite all these impressive improvements, they remain largely incremental in nature and they hit a "wall of complexity" that makes it somewhat diﬃcult to incorporate more automation, such as the elusive, and perhaps infeasible, goal of achieving fully automated air traﬃc control, and to design and insert autonomous vehicles, small and large, in cities and at high altitudes. We introduce Ariadne , a thread to accelerate the productivity gains achieved by air traﬃc services


C. Ariadne 's inspiration from existing implementations
The number of "Plan B" mechanisms that have been implemented in practice is enormous. While not all of them meet the level of rigor that model-based mathematical analyses afford, they all follow the architecture shown in Fig 1. For example, an elevator is equipped with emergency braking action that is ready to step in as soon as the elevator speed is excessive. A modern, electronic version of the elevator brake is the emergency braking action automatically triggered by road vehicles if a danger is perceived, for example an obstacle in front of the vehicle as shown in Fig. 2. Such automated emergency braking actions operate much faster than their manual equivalent because the time spent by

Figure 2 Emergency braking for a Volvo Truck -Illustration. Source: Volvo Trucks
automation from recognizing an obstacle to stopping the vehicle is far shorter, in fact negligible compared with the proven 0.2 second operation delay of human operators due to the speed of neural message transmission from scene reconnaissance to foot action. As a result, the minimum safe distance that must separate a vehicle from the next one ahead for a successful emergency braking action is smaller, with obvious and positive consequences on increasing road capacity safely. The same automated emergency braking actions do, however, suffer from sensing imperfections sometimes causing a vehicle to execute an emergency braking action to avoid colliding with irrelevant or inexistent objects [30], an unpleasant event often called "false alarm".
Inspiration for Ariadne is also prevalent in many aerospace applications [25,[31][32][33]. One well-known case is related to take-off procedures, whereby aircraft, runways, and aircraft take-off procedures are carefully arranged for a "Plan B" to always exist. In particular, a very precise set of airspeeds is identified for each aircraft so that, regardless of a number of adverse events, the aircraft always has a "Plan B" available. For example, past a certain speed 1 , the aircraft should be in a position to take-off despite even in case of one engine failure, while below 1 the aircraft should be able to break on the runway without exceeding the threshold, thus maintaining a "Plan B" available at anytime during take-off. The choice of such speeds is naturally planned assuming the runways have appropriate lengths to enable these "Plan B" to make sense, as will be discussed further below.
Other Ariadne instantiations in Aerospace systems include the Traffic Collision and Avoidance System, TCAS. In essence, TCAS provides a Plan B (a collision avoidance maneuver) every time an aircraft enters a collision course with another aircraft. The avoidance maneuvers (Plan B) are chosen from a simple and finite library (typically altitude change maneuvers) so as to simplify their implementation by human pilots and maximize the efficiency of collision evasion maneuvers. In this case, it is worthy to note that the execution of the Plan B, in this case, not only must account for the relative speeds and maneuvering characteristics of the aircraft involved, but also the uncertainties in pilot actions, such as their reaction time, the amplitude of the maneuvers as implemented by the pilots, and other factors. It must be noted, however, that uncertainties as dramatic as those leading to the Überlingen accident [34] can only be accounted for once they are found to happen: Until that accident, TCAS was rooted in high confidence that TCAS-equipped aircraft/pilot tandems would follow TCAS recommendation. The Überlingen collision showed that was not the case: the TCAS systems worked appropriately and cooperatively, and the accident was due to a difference of priority given to TCAS vs. Air Traffic Control resolution advisories by the pilots of the aircraft that collided. Once this accident happened and the possibility of confusion of priority between air traffic control and TCAS became known, updating TCAS resolution advisories accordingly was done as published in [35] and illustrated in Fig 3.

Figure 3 TCAS before and after Überlingen accident [35]
Further, other collision avoidance systems have been developed, most notably Auto-GCAS, an automatic ground collision avoidance system initially developed for the F-16 fighter aircraft. The system constantly computes the intersection between a hypothetical recovery trajectory (a 5-pull-up maneuver) and the ground. If the intersection is non-empty, then the run-time assurance triggers the pull-up maneuver to avoid the ground. The success of Auto-GCAS has been so great that the US Air Force has posted numerous videos of actual recovery maneuvers on YouTube [36] and the engineering team in charge of developing Auto-GCAS won the Collier Award.
Redundant avionics systems, especially as implemented in Fly-by-Wire commercial aircraft, also form an embodiment of Ariadne , whereby a backup computer is always ready to take over the control activities left by the primary flight computer, should that computer fail.

II. Recent and ongoing research B. Assurance of Ariadne -inspired systems
Plan B assurance is considered to be one of the key tenets of safe autonomy, and constitutes the core object of various programs articulated around the "safe autonomy engineering", funded through multiple current research programs. As such, there are multiple efforts going on and described in a multitude of papers, see [44,45] Probably one of the most interesting developments, independent from designing the Plan B itself, is the safety of the various switching mechanisms that allow the vehicle to "switch" from one mode to another mode, say from "nominal mode" to "backup mode".
In that context, Copilot is a runtime verification framework for real-time embedded systems. Copilot monitors are written in a compositional, stream-based language with support for a variety of logics including Temporal Logics, which results in robust high-level specifications that are easier to understand than their traditional counterparts. The framework translates monitor specifications into C code with static memory requirements, which can be compiled to run on embedded hardware [46,47].
Copilot monitors are software and the researchers, notably at NASA are investigating how to ensure the code generated could be certified say under NASA's level C or B classification. Copilot was intended to minimize the instrumentation of the system so it samples specified system state either C global variables or data provided by middleware software bus.
Galois, through a contract with DARPA's Assured Autonomy program, is leading a small group that is using Copilot to verify the composition of small controllers. They have now integrated SMT solvers into the framework so you can check simple properties of say three monitor specs to make sure they don't miss coverage or interfere with each other.

III. Verification in Ariadne
The issue of verification is central to Ariadne . Indeed, Ariadne aims at formalizing and extending a framework essentially built around a human infrastructure, whose safety has been proven by many years of practice and the intervention of safety specialists, often called Designated Engineering Representatives (DERs), mandated by the FAA to assure the safety of all products built by industry. It is therefore essential that Ariadne 's safety meet the same safety standards as it aims at including automation either in the air, on the ground, of both.

A. Verification vs. Validation vs. Certification
In systems engineering, verification is the step where some element of a system performs according to its specifications. Verification is not sufficient to guarantee that the whole system meets its functional requirements, but it is considered to be a necessary step towards achieving that goal, named validation. Verification is often brought together with validation as part of the overall process of certification. Several differences exist between these steps. Unlike verification, which focuses on individual elements of a system only, validation is about establishing reasonable evidence that the assembled system meets its functional requirements. Verification and Validation are usually highly technical tasks that rely on precise engineering analysis techniques to be established. Certification is the final and official stamp of approval of the Air Navigation Services Provider (ANSP) or similar authority before operational use, based on the foregoing verification and validation steps. Certification is not a technical activity.
Verification is usually done at the component level and may be performed repeatedly at various levels of implementation of that element, from concept to full implementation. In the case of Plan B strategies the concept is typically described by means of block diagrams, whereas implementation might be a mix of software and communication systems. It may also simply be a procedure executed by a human, where the human, together with the procedure form the component to be verified. Several verification procedures exist that are adapted to each kind of component, whether they are structural components, propulsive components, electronic components, or software component. The latter, perhaps with a computer architecture, is that of concern to Ariadne . Component verification is guided by several reference documents published by organizations, such as RTCA (Radio Technical Commission for Aeronautics) and SAE (Society of Automotive Engineers). In the case of airborne software/hardware components, a reference document is SAE's ARP-4761A [48] which pertains to system and subsystems safety assessment [49]. The ARP 4761A then refers to a number of other reference documents [40,48,[50][51][52] that consider lower levels of safety verification and validation shown in Fig. 5. For ground equipment and procedures, guidance documents are fewer. However they do exist, see [53,54] However, it is most often possible to apply guidance documents for airborne equipment to ground-based operations. Indeed, airborne systems usually must meet higher safety requirements than ground-based systems. Other variations include the differing roles of humans in the cockpit rather than those on the ground.

Formal verification in Ariadne : Guaranteeing safety with unproven components
Mathematical formalism paves the way of many engineering projects to success, and aerospace systems are no exception to this fact. Rigorous mathematical formalism is presented in civil aviation and offers a powerful and expressive language to specify not only avionics systems, but also structural and aerodynamic characteristics. In software-intensive components, computer-assisted mathematical verification is named "Formal Methods" and is present as a supplement, RTCA DO-333 [55] to RTCA DO-178C [40]. Formal, mathematical analysis of software/hardware integrated systems at the functional level is less present, other than as they relate to control systems. As a source of inspiration, the document developed by ASTM-F3269-17 [56] offers an approximate pathway to the embodiment of Ariadne in the context of introducing Artificial intelligence and, in general, "unproven algorithms" in air operations. Perhaps one of the most surprising aspects of that embodiment is the significant and genuine possibility of reducing the verification requirements that come with it, in fact far below those expressed in ASTM F3269-17. In essence, two philosophies can be applied to the Plan B mindset.
On the one hand, Plan B may be nominally inactive and be only called upon when it is necessary to do so. In that case, the recommendations present in ASTM F3269-17 do apply, and the backup control strategies discussed there must meet stringent safety requirements and form prime candidates for the exhaustive and formal verification methods commonly seen in "classical" control systems and that are slowly making their way into AI-driven controlled systems.
On the other hand, the proper Ariadne embodiment is one where Plan B is always active and there is always a safe alternative that is ready to step in for each likely failure, including combinations thereof. Moreover, the scenarios leading to triggering the run-time assurance mechanism include cases when whatever algorithm in charge of producing Plan B fails to do so. As a result, it becomes entirely possible to verify Ariadne embodiments, although these embodiments only rely on unverified, and perhaps unverifiable algorithms, such as the numerous black-box algorithms that usually are the preferred product of subcontractors who are keen on keeping control over their industrial property, or organizations that are keen on maintaining human supervision of traffic operations. TO build a concrete idea of how Ariadne is embodied into a verified path planning unit with unverified components, we consider the situation shown in Fig. 6. An aircraft is attempting to pass through a hole in a squall line. The aircraft is shown at times 1 , 2 , and 3 . The aircraft is color-coded with corresponding colors, red for 1 , light blue for 2 and green for 3 . The trajectory followed by the aircraft is shown in purple. The dashed part of the trajectory represents "a future trajectory" and may be unknown. It is assumed that the aircraft has a path planner (either in the mind of a human or installed electronically). This path planner is a "black box", that is, its function is known, but it may or may not return an answer within a prescribed amount of time. It is only assumed that the black box works "most of the time" and requires computations that last only a fraction of the durations 2 − 1 , 3 − 2 , and 4 − 3 . We initially assume the aircraft is at its initial position at time 1 and that a feasible trajectory is available from 1 and 2 , together with a backup trajectory, shown in red. That red trajectory is a "safe" trajectory because it ends in a racetrack pattern, which can be followed as long as the aircraft does not run out of fuel. At time 1 , the nominal trajectory of the vehicle is the segment from 1 to 2 concatenated with the red backup trajectory. The time segment [ 1 2 ] is then used by the pilot (human, but increasingly autonomous) in the case when Visual Flight Rules (VFR) apply or by ground-based Air Traffic Control, in case of Instrument Flight Rules (IFR) apply, to determine whether (i) the segment [ 2 3 ] is flyable and (ii) whether a new trajectory resulting in a safety trajectory ending up with racetrack beginning at 3 can be found, my means of computer or human intellectual effort. If not, then then the aircraft engages into the red backup trajectory. If yes, then the aircraft has obtained its "ticket" to proceed with the point 3 . The same process repeats from then on.
This story, with its imperfect realism, shows what the core mechanism allowing an aircraft to fly safely is. That mechanism is proven safe by means of the way it is constructed: While part of the planned trajectory is "useful" from the perspective of getting to destination, much of the planned trajectory is a safe "recovery trajectory". It is often the case that pilots manually handle the aircraft, in which case a computerized system may have no information available to compute a backup, safe trajectory from a short-term path prediction. One solution to recover some level of trajectory predictability is to narrow the length of the intervals [ 1 2 ], [ 2 3 ] and [ 3 4 ]. The trade-off that needs achieving is then the necessity to increase the "tempo" at which "Plan B"s need computing, which may or my not be possible. However, commercial products, such as Xavion, a tablet app designed to back up the avionics of general aviation aircraft and provide emergency routings to the nearest airport in case of engine failure are a strong indication that the more general concept described in this paper can also be implemented [57]. Many westbound, Europe-America transatlantic flights perfectly embody Ariadne 's philosophy, as shown in Fig. 7. Indeed, these flights initially do not file a flight plan to their final destination, but their final destination is Gander a popular alternate airport located in Newfoundland. Once close to their destination, they then amend the flight plan to continue to their destination. The reason for this procedure is fuel savings: Although most flights are fueled well-enough to reach their final destination, aeronautical regulations do not consider direct flights to their destination to be safe enough with the allotted fuel. That allotted fuel is, however, "legal" to support a flight to Gander and, once close enough, whatever fuel remains usually become "legal" to proceed to destination. This example illustrates particularly well the inverted way of planning, whereby the nominal trajectory is the safety trajectory, and the actual trajectory needs to be "earned" prior to proceeding with it.
From the perspective of the authors' past work, the procedures and guaranteed safety outlined in the foregoing can be traced as far back as 1997 [58], where a procedure to control nonlinear systems was designed by introducing a sequence of Lyapunov functions and corresponding invariant sets, and control from one trim point to another was ensured by aiming at one equilibrium, only to switch to the next equilibrium as soon as getting within its region of attraction, as shown in Fig. 8.
This initial concept, which will undoubtedly remind the reader of Extended Twin-Engine Operations (ETOPS) procedures, was later refined by Frazzoli et al [59] to use the approach for arbitrary path planning tasks using randomized, and therefore eminently unverifiable algorithms, including a safe slew attitude planning for space telescopes [60], see Fig 9. Last, such "Plan B" engineering approaches were implemented in an actual flight test implementing an early version of the "loyal wingman", whereby a manned F-15 and a large sized UAS were operating together. The large UAS was guided by a real-time implementation of a mixed-integer program, and always maintained a "Plan B" backup loitering pattern in case of computational failures, which happened more than once, as shown in Fig. 10.

Starting and ending "Plan B" for aircraft
The way embodiments of Ariadne can be designed to effectively support the air traffic control system system is predicated on common sense, existing air traffic control rules, a few axioms, and accurate mathematical models of aircraft and aircraft control operations. One of the axioms needed for completeness is the existence of a state, or a set of states, where passenger and crew safety can be held indefinitely. We choose the set of states to be the apron, where the aircraft can be safely unloaded/loaded, boarded/de-boarded, serviced, and fueled up. The apron may be close to a boarding gate or not, as is frequently the case in non-US airports. It also provides a good initial condition to insert the aircraft into airspace operations, since it is inherently equipped with a backup trajectory, that is, remaining stopped at the apron. The reader can imagine equivalent "absolutely safe states" for unmanned or remotely operated vehicles. The Ariadne issue as seen from the aircraft cockpit is then to keep earning appropriate "Plan B"s throughout the execution of the flight, from departure apron to arrival apron as shown in Fig. 11. If some parts of the flight do not have a "Plan B" or do not have enough "Plan B"s, that is conceivable as well as long as operators are conscious about the absence of such plans as well and the risk of system failure may be properly quantified.

Validation needs for "Plan B engineering"
The fundamental difficulty of "Plan B engineering", that is, the need for model-based safety validation, has been trivialized by the foregoing. However, there remain significant validation efforts to be done in order to make the "Engineered Plan Bs" appropriate for insertion in the air transportation landscape. For example, one of the most important validation elements is managing the number of false alarms. False alarms are a highly subjective measure of performance that rates the "Plan B" potential to trigger for inappropriate reasons, and, although false alarms do not constitute immediate threats to safety, they can, especially when human operators are present, become the source of multiple frustrations and lower attention that can lead to behaviors that compromise safety. Fortunately, the evaluation of false alarms may not require sophisticated mathematical tools and may be performed via simulations only, possibly with a human in the loop whenever relevant [62].
Another important factor is the development of "Plan B"s that do not contradict existing procedures, especially those applied by humans on existing traffic. One example of conflict between procedures that necessitated reconciliation between several human parties after generating great controversy is "Land and hold short" (LAHSO) operations at busy airports, whereby aircraft are offered to land, under the condition that they hold short of another runway operated for full-length landing or take-off operations, or a busy taxiway with aircraft crossing the active runway, as shown in Fig. 12. During the late 1990s and early 2000s, the FAA entered into contentious discussions with airline pilots about LAHSO in the context of the urgent need to increase airport capacity. This was especially the case for Chicago O'Hare International Airport. Back then, the airport consisted of several crossing runways, and LAHSO [64] was seen as an essential mechanism to improve capacity without "pouring more concrete". American Airlines and its APA pilot union entered into heated discussions with the FAA over the well-foundedness of LAHSO, in particular in the context of how certain LAHSO could de facto remove some of the available "Plan B", such as those necessary to handle rejected landings. Later incidents supported American Airlines' position, see for example [65] where an aborted landing resulted in a near miss in Canada.
It must be noticed that the practice of "sacrificing" available "Plan B"s, as perceived by the APA for the purpose of increasing system capacity is not unique to aviation and it is, in fact, far more frequent in ground transportation: For example, it is difficult for drivers not to remember situations where other vehicle operators engaged in maneuvers and behaviors that clearly demonstrate the absence of Plan B on their part. It is often a lot harder for drivers to realize they, themselves, engaged into such activities without a Plan B in mind. In addition, it is commonplace for highway operators in the US to run road traffic in the emergency lanes during rush hours although these lanes are considered an important resource for drivers to find a safe haven in case of vehicle breakdown, thereby showing that economics sometimes prevails over safety concerns.

B. Clever "Plan B"s architectures that cover many failures, including their own: The Westinghouse breaking system
One of the key attributes of Ariadne is the necessity to make the time of its triggering "Plan B" as small as possible when it becomes necessary and making the probability of its execution as close to one as possible. Thus, and perhaps paradoxically, the system under operation should always be "very close" to triggering "Plan B", close enough that the state of "Plan B" triggering be accessible with as few logical operations as possible, on the one hand, and that be true over the largest number of faulty system states. In other terms, "Plan B" triggering must be "robust" against as many external factors as possible.
The history of emergency braking in railroad systems offers a beautiful example in case, discussed thereafter. For a detailed story, see [66] The preferred braking mechanism for trains is air braking, whereby the locomotive generates pressured air that travels through an elaborate piping system all over the train that directly accesses the individual brakes of every car.
A naive implementation of the air brake system would consist of keeping atmospheric air pressure inside the piping system during cruise operations, resulting into brakes not being applied. During braking and emergency braking, pressure in the pipe system would then go up and brakes would be applied via a pistons connected to the now pressured pipe system. In 1869, George Westinghouse patented a fail-safe train braking system, whereby the normal state of the pneumatic system is to be under high pressure, and the abnormal state is for the same piping system to be at atmospheric pressure. A notional view of the classic vs. Westinghouse brake system is shown in Fig 13. The left arrangement shows how the brake pad is pressed against the wheel when pressure is applied. The right arrangement shows that in the absence of pressure applied to the piston, the brake pad is pressed against the wheel by the spring, which is under tension, and breaking action occurs. Releasing the brake requires pressure to be applied for the brake pad to be released. The actual Westinghouse airbrake is somewhat more complex because the extended spring is replaced by a complementary pneumatic system. The effect, however, is the same. The advantages of the Westinghouse arrangement are not obvious at first. However, Westinghouse brake system offers remarkable safety characteristics, such as the automating triggering of the brake for any event affecting the train integrity. For example, separation between any two train cars will result in damage to the pneumatic line, thus automatically reducing pressure applied to all train brakes and triggering strong braking action. Cornelius Vanderbilt, a train owner and operator opposed the introduction of Westinghouse's invention in the train stock he owned. It is one of history's ironic twists that the university named after him now leads and promotes one of the largest research efforts in autonomous system safety, see [67].
Robust, "built in" safety mechanisms do carry over in aviation applications. For example, the fuselage door system in many Boeing aircraft is arranged so it is passively stable, a feature that is not shared with many Airbus aircraft, whose doors are secured against the fuselage via a more complex system of latches. Other examples include almost all aircraft control surfaces: The "natural equilibrium" of control surfaces mounted on trailing edges of wings , stabilizer and tail fin such as rudder, ailerons, and elevators is about zero deflection angle, which ensures some level of safety that would not be matched by control surfaces mounted at the leading edge of the the same aircraft elements.

C. Adaptability and flexibility in Ariadne
Air transportation specialists, be they air traffic controllers or pilots, often maintain not one, but several backup plans in mind. Sometimes the reason for doing so is for safety: One backup plan alone might not be enough to guarantee safety. For example, pre-flight planning may include the definition of several alternate airports throughout the trip so as to make sure one of them remains accessible despite local convective weather. Another reason might be because of the temporary nature of the safety offered by "safe conditions". For example, consider the safety afforded by introducing a racetrack pattern, such as shown in Fig 6. Racetrack uses often induces pilot concerns about fuel reserves and increased use of radio bandwidth to discuss these concerns. A conceivable approach to handling these concerns is to always include a genuine "forever safety state" in the RTA, such as an alternate landing site, not for the purpose to ever using this site, but in order to address the safety-oriented part of the concern and convince the pilot of a genuinely realistic "last resort solution", as illustrated in Fig. 14

IV. Ariadne and automation
The range of applicability of Ariadne , because it ALREADY pervades the current air transportation system, is very wide. It can be thought of in the context of current operations. It can also be thought of as a healthy basis upon which the future evolution of the air traffic control system may be considered.

A. Initial possibilities
Considering today's air traffic control, Ariadne can be embodied as a mechanism to assist air traffic controllers and pilots with current traffic control and management and decision-making. In its simplest form, Ariadne may simply be embodied as a decision aid , whereby air traffic controllers focus on mission execution, while one embodiment of Ariadne maintains "backup option situational awareness". For example, air traffic control positions could be equipped with supporting software that computes complete safety trajectories in real-time. The same kind of services may be made available to pilots, perhaps as an additional display, and only after a through Human Factors evaluation. When the aircraft is on autopilot, this functionality could act as an alarm system indicating a change in "Plan B". One implicit or loss-of-link. Below a certain reliability threshold, the "Plan B" obligation may then be eliminated.
Ariadne makes it also possible to consider formation flight by a group of commercial aircraft from a rational and implementable perspective. Formation Flight involves aircraft flying in close formation, with aircraft flying precisely into each other's wake for reduced fuel consumption and increased range, which might be critical to the early introduction of all-electric or hydrogen aircraft over medium and long-haul flights. Such operations can be implemented only if appropriate "Plan Bs" can be developed to handle likely failures, such as loss of engine. Such "Plan B"s may be derived from similar procedures currently in use during military formation flight operations.

V. Computational issues
One of the benefits of Ariadne is the attractive computational options that it offers, together with relatively easy software validation requirements. However, the foregoing arguments indicate that, since the default mode of system operation is in "safety mode", the challenge remains with computing the next "ticket" towards achieving a later "guaranteed safe" trajectory. And if available computational time to find the next solution is too short, the vehicle will have to engage in its currently available safe trajectory, keeping in line with the policy that "Plan B" computation failures are treated like any failures and, perhaps surprisingly at first, can be taken care of by the Plan B strategy that already exists. Alternatively, simpler "Plan B" decision spaces may be chosen instead that enable shorter computation times. A good example in point is "last minute" collision avoidance, that falls within the current range of airborne collision avoidance systems. The need for a high refresh rate of "Plan B" trajectories in order to limit the number of safe but premature collision avoidance maneuvers may initially imply reliance on a small maneuver portfolio. As of today, this portfolio consists of a small number of vertical maneuvers that have been optimized, not only for safety, but also for minimizing their impact on the intended trajectory of all aircraft involved. As embedded computer power increases and aircraft fleets modernize following recommended safety management practices such as those discussed in SAE ARP 4761, ARP 4754, and RTCA DO-178C among others, it can be foreseen that collision avoidance will be eventually handled with a much broader array of available maneuvers, possibly using artificial intelligence techniques, but also commercially available models and algorithms from Operations Research, such as mixed-integer linear programming, already demonstrated in part by Feron et al [71] and detailed in Schouwenaars' PhD thesis [72].

VI. Operational challenges and Recommended approach for progressive implementation in current ATM environments
One of the foreseen challenges is the eventual necessity of closer coordination between cockpit, dispatch and air traffic control/management [73].
Indeed, Ariadne is fundamentally based on maintaining a number of safe options for ground and cockpit operators alike. Keeping in mind the importance of ground control in ensuring the smooth flow of traffic and absence of collisions, on the one hand, and pilot ultimate responsibility for aircraft integrity, on the other hand, it could be imagined that these shared responsibilities be integrated somehow in the future, which would then require intense information sharing.
One possibility is to complement the existing ADSB-out system, which is a mechanism for aircraft to communicate with ground control many data, including position data as a replacement for traditional Secondary radar technology. In the United States, there are two methods for achieving ADS-B Out. One is using the next generation of transponders operating on the 1090 MHz band. The other is using a new technology called Universal Access Transceiver (UAT). Another possible information sharing mechanism might be a "safety-critical" version of SWIM, the System-Wide Information Management operation initiated in Europe and adopted by the FAA and ICAO. It is believed that the most natural way to evolve the communication system to meet the needs of Ariadne Conops will be via concurrent evolution of the entire CNS infrastructure, especially as enabled by NextGen in the US and SESAR in Europe.

VII. Operational challenges and Recommended approach for new ATM environments
New ATM environments can be characterized by two different evolutions: First, there are changes in Concepts of Operations. Examples include the transition to Free Flight [74], which is is now implemented in Poland, see [75] and the Maastricht air traffic management center, see [76] The existence of few, but operational implementations makes the two foregoing examples prime locations where Ariadne may be tested experimentally.
Second, there are changes in the type of vehicles involved. In particular, there are very significant efforts currently aimed at urban air mobility, on the one hand, and plain unmanned aviation, on the other hand. Urban air mobility involves a wide-ranging number of vehicles, ranging from minuscule machines, such as DJI's Mavic Mini shown in Fig. 16, on the one hand, to Super Jumbo jets, on the other hand. Nowhere else than in Hong-Kong's old airport is this Figure 16 The DJI Mavic mini is an example of micro-drone capable of high quality imagery situation better illustrated, where large aircraft used to land and take-off in urban environments as shown in Fig. 17. While Kai Tak airport is now closed, slightly less dramatic but similar situations remain at urban airports, such as London City airport in the UK and Reagan National airport in the US.
New environments where large unmanned vehicles interact with classical commercial traffic face several issues, some having to do with vehicle integrity, and some having to do with its interaction with the surrounding environment. In the latter case, unmanned traffic faces unique safety requirements that must be translated into specific Ariadne provisions. Consider for example issues of engine failures, typical of single-engine autonomous aircraft. The requirement for the vehicle not to crash in unequipped areas could be handled by adapting software, such as Xavion.
Consider then issues of loss of communication link: Indeed, most unmanned air vehicles today are in fact remotely piloted vehicles (RPVs), and examples of such systems include General Atomics' Predator and its successors, and autonomous Cessna Caravans developed by Xwing. Communication link integrity currently constitutes one obstacle to certification. Ariadne may, however, offer a valuable option to handle that problem.

VIII. Keeping a systems-oriented approach
One of the key elements of Ariadne is the necessity to follow a comprehensive, system-oriented approach to its multiple embodiments within the air transportation system. Any modification of the concept of operations may result in ripple effects affecting pilots in the cockpit, air traffic management specialists at air traffic control centers, airports and flow control facilities, dispatchers at airline operations centers, and other distinct entities even. We believe that the Ariadne paradigm is capable of not affecting the current arrangement of functions of the air transportation infrastructure. However, we also believe that the implementation of some of the Ariadne functionalities, such as full safety trajectories Figure 17 Hong Kong urban aerial mobility environment included a Boeing 747 when Kai Tak International Airport was operational [77] as illustrated in Fig. 14, may require modifications to the current paradigm. Indeed, a full safety requirement considers not only the aircraft along with airborne "Plan B trajectories", such as S-turns and loiter patterns, but they must be followed by an airport approach and a landing for completeness. On the one hand, this completeness requirement is, we believe, a necessity for such a tool to be implemented. On the other hand, it requires increased cross-communication and joint action (thus multivariable processing) to be implemented in today's air traffic environment. For example, today, loitering patterns are decided at the discretion of the air traffic controller. However, the completion of the safe trajectory up until an alternate landing site would have to be encoded as an alternate flight plan that may need updating in real-time, possibly forcing a tempo and information flow that may be hard for a human operator on the ground to digest. Alternatively, the responsibility for alternate flight plan awareness may fall upon the pilot and the cockpit. But then the cockpit would need to know about the loiter pattern decided upon by the air traffic management. It is worthy to note that using loiter patterns constitute a point of friction between ground control and cockpit in many cases, because pilots DO worry about their fuel autonomy. Thus, rather than raising a new issue unknown to air traffic control today, our framework makes an existing "pain point", and why it is difficult to address, more explicit. Ariadne fully supports other pain points between ATM and the cockpit raised by previous accidents, such as the foregoing Überlingen collision, and the follow-up modifications brought to TCAS, see Fig. 3.

IX. Deterministic vs. probabilistic frameworks and how to handle a stochastic system
In the mathematical world underlying the present discussion, deterministic reasoning is implicitly used for the sole purpose of simplifying the discussion. In actual operations, and even in a very professional and regulated environment, the presence of many uncertainties make it absolutely necessary to consider a probabilistic framework instead. Such a probabilistic framework, coupled with the necessity to collect extensive statistical data, will undoubtedly create considerable challenges to the reliance of Ariadne to support the design of future air transportation operations. These challenges are of the same nature as those encountered by any new development today. However, Ariadne brings forward the quasi certainty that these efforts will lead to a successful conclusion unlike most prior efforts aimed at automating the air transportation system and accepting unmanned aviation, for example.

A. Acts of God
Ariadne is predicated on common sense and a comprehensive knowledge of all past mishaps and corrective actions. However, Ariadne is not predicated on unexpected mishaps, for the authors reject the common belief that intelligent systems may be so smart as to anticipate unknown unknowns, regardless of technological progress in Artificial Intelligence and other disciplines. As a consequence, Ariadne does not claim anything could have been done to TCAS in order to prevent the Überlingen accident. On the other hand, Ariadne would have led to the prevention of the well-known conditions at the air traffic control center (facility under repair, air traffic control position under-staffing and other incriminating factors) the same way as any other process would have, thereby saving the lives of countless passengers and one air traffic controller.

B. Incorporating Lessons learnt: a continuously learning system
Consistent with the foregoing, the best embodiment of Ariadne should include all new "acts of God" as soon as they are identified for the purpose of making them very difficult to occur again. Ideally, the process of incorporating these acts of God into the concepts of operation inspired by Ariadne and determining which operations these acts of God are most relevant to account for should be automated if possible. Certain strong difficulties remain, however. Among them is the translational learning that occurs among many humans, whereby experiences gathered by someone in a given operational environment (eg ground vehicle driving) translates into valuable and proactive experience into another operational environment (eg air transportation operations). Such knowledge transfer, which happens "automatically" in people, still constitutes a research challenge whose solution would enhance the quality of some of the embodiments of Ariadne , but whose absence would not initial development activities.

C. The system in the ecosystem
The implementations of Ariadne should also steadily keep into account the evolution of its surrounding environment. To begin with, the entire existing air traffic management system, including both cockpit-and ground-based systems, should be reviewed in detail to validate Ariadne 's as the thread that drives its operations. Then, Ariadne should evolve according to technical changes in Communication, Navigation, and Surveillance mechanisms, as well as generational changes among pilots, air traffic controllers, and dispatchers. Indeed, the embodiments of Ariadne will always operate in closed-loop with its ecosystem, and any evolutions of the embodiments of Ariadne or its ecosystem may destabilize the resulting closed-loop system.

XI. Conclusion
While Ariadne should underlie any research effort in air transportation operations, it comes only as one element to be incorporated in design considerations, first and foremost human factors, existing procedures, and task partitions across different operational units. Ariadne is essential in that many of the perceived verification needs for Plan B procedure acceptance are trivialized, and the validation requirements do not require as many formal proofs as needed. In essence such needs do not exceed those associated with evaluating the system for false alarms. Ariadne constitutes a flexible, ubiquitous, and adaptable thread that should support any innovation for existing air traffic control operations to handle unmanned traffic and relaxed routing rules, and any design for new air traffic control operations.