This paper presents a continuation of the previous research on the interaction between a human traffic manager and the UATMS. In particular, we focus on the automation of the process of handling a vertiport outage, which was partially covered in the previous work. Once the manager reports that a vertiport is out of service, which means landings for all corresponding agents are prohibited, the air traffic system automates what it has to handle for this event. The entire process is simulated using Knowledge Representation and Reasoning to describe the detailed process of reasoning about UAM operations. Moreover, two distinct perspectives are respected for the human supervisor and the management system, and related ontologies and rules are introduced. We believe that applying non-monotonic reasoning can verify each step of the process and explain how the system works. After a short introduction with related works, this paper continues with problem formulation, primary solution, discussion, and conclusions.
Urban Air Mobility (UAM) is a novel and rapidly expanding mode of transportation. Utilizing urban airspace is viewed as a crucial solution to trafcfi problems in densely populated areas. The concept of a vertical airport, or vertiport for short, allows small aircraft to take off and land without runways around tiny structures. There is increased pressure to standardize the UAM air traffic management system, or UATM for short, despite its increasing popularity as a new mode of transportation. At the same time, this becomes problematic because it is difficult to accommodate everyone’s desires. Introducing a new system into an established environment sounds like a challenge. Specifically, the airspace should be shared with the existing aircraft system. By dividing the required altitude, potential conflicts between the two methods are avoided. We aim to have this new transportation system operational by 2035, despite the difcfiulties associated with low-altitude travel and heavy air traffic. This study investigates how each vertiport and the UATM communicate with one another. We are primarily interested in discussing what vertiport administrators and the UATM do and how they respond to incidents. By constructing a graphbased model of the traffic system, we simply characterize the system and provide an illustration of a common occurrence at a vertiport. In the previous paper, we took the initial step toward our objective. The primary difference between the previous one and this one is that the previous one believed certain corridors should be avoided when determining where the plane should go, whereas this one believes the current target should be avoided. This implies that the route must be altered.
The papers [1, 2, 3, 4] give an in-depth examination of UAM technology, regulatory context, possible advantages, and obstacles. Recently the article in [5] suggests a layered system for managing airspace for UAM vehicles, with different layers defined based on the type of vehicle, level of automation, and altitude. The paper [6] discusses a variety of ATM projects in German Aerospace Center (DLR) initiatives. The paper [7] suggests a collision risk assessment model between a vehicle and obstacles. The paper [8] discusses state-of-the-art Deep Learning (DL) solutions for ATM in depth.
However, none of previous attempts to avoid crashes based on ATM systems are ready to be widely adopted because of complex UATM systems, various stakeholders, mass agent activities, and possibly catastrophic events. Considering multiple stakeholders, our initial work [9] was to detour agents’ route, avoiding particular corridors. In that paper, nonmonotonic reasoning was used in the operation of the complex UATM system to describe how to control unexpected cases or easily changeable information.
In this regard, the paper [10] serves as a valuable guide for the explanation of complex systems— explainable AI (or XAI for short). To validate the complex system, their proposed epistemological model is based on knowledge representation and reasoning in particular. However, their approach is philosophical. Hence, as a concrete, motivating use case that can be easily adapted to our case, it was not sufficient.
The paper [11] examines a method for developing automatic classifiers capable of offering explanations based on an ontology. The paper [12] briefly reviews vfie approaches based on association rule mining, formal concept analysis, inductive logic programming, computational learning theory, and neural networks, and provides how to build descriptive logic (DL) ontologies. Even though these papers provide a basis on which reasoning can be linked to the ontology, the use of their approaches in our system has not been a practical solution.
For the practical point of view, the paper [13] provides a framework for intra-logistics problems based on ASP. The papers [14, 15] propose to perform task assignment and vehicle routing by means of ASP for automated guided vehicles (AGVs). While they concentrate on showing how to calculate their path and give a series of subtasks, we concentrate on the logic utilized in the process of interaction between a human manager and the system, as well as across systems.
The paper [16] provides a systematic survey for projects at the intersection of ontologies and autonomous robotics and compares them according to what terms are defined in their ontologies, how these terms are used to support different cognitive capabilities of a robot, and in which application domain they are used. However, the authors indicate that ontologies for behaviors and interaction have been relatively less focused than other terms in several scopes.1 In order 1For more details, see Table 1 in [16]. to illustrate the interaction, rather than solely conceptualizing in ontologies, we chose a hybrid approach (as the approach introduced in [17]) combining the ontology with the reasoning process by ASP. While the paper [17] focuses on the user-centered explanation and the generalization itself, we focus on the trace of reasoning to provide facts collected by each agent’s information in real time, which is dynamically changeable.2
As an illustration, we present a destination-changing scenario that may occur frequently in UAM environments. Then, we elaborate on our demonstration of nonmonotonic reasoning and explainability.
In the following sections, we describe the problem formulation, provide the solution, continue discussions, and conclude this paper.
Examine the graph depicted in Fig. 1. Each vertex denotes a vertiport, while the edges denote corridors. Large circles represent UAM Air Trafcfi Management (UATM) systems covering these vertiports. These corridors transport agents between this network’s vertiports. UATMs can communicate directly with agents within their coverage area. This study presumes that the ‘UATM Network’ possesses a communication relaying protocol that enables UATMs to relay messages to one another. Upon the agent’s departure from this UATM Network, direct communication becomes impossible.
Each agent typically commences a voyage as follows: It begins in a vertiport, where preparations for flight are made. This agent requests departure from the vertiport traffic manager. After receiving permission, the agent enters the airspace.
The destination and route are configured prior to flight. The agent uses UATMs to update its velocity, GPS coordinates, and other information as it travels through corridors to the destination vertiport. UATMs can then supervise the agent while considering traffic.
The agent requests landing from the vertiport traffic manager when close.
Typically, the traffic manager directs it to the vertipad after confirmation. This traffic system operates autonomously. Managers of human traffic are in control of each vertical airport. Monitoring traffic, vertiports, and legacy traffic systems is their responsibility. They improve the system’s adaptability.
The human manager’s perspective: While a human manager in vertiport 6 (or vp6 for short) monitored landing some agents, he or she found that there was a safety issue. It appears that
approving landing requests from the following agents would be risky. Hence, he or she reported this status to the UATM (here, UAT M2). In particular, the vp6 is temporarily closed, so it is required for all vp6 heading agents to change their destination to vp5, which is the candidate vertiport of the vp6.
The UAT M2’s perspective: The UAT M2 received a report that the vp6 is closed. Since all vp6 heading agents should detour their route to the new destination, it should find all the related agents. While finding them, it also looks up other UATMs. Once it finds all, it checks the vp6’s candidate vertiport. We assume that the candidate vertiports are carefully chosen, depending on previous records, including congestion, landing turnover ratio, and capacity. After getting the candidate vertiport and computing the route to the new destination, it sends to all these agents the replaced path, which has the newly appended route at the end. Once all these agents’ paths are changed, the UAT M2 replies back to the vp6 human manager.
This section presents our hybrid approach depicted in Fig. 2. This approach consists of the following two steps: 1. The problem is declared in Answer Set Programming. Goals and rules are defined, and each interaction is addressed. 2. Composed ontology is used in this problem. As a semantic layer, we develop the ontology model against a unified data source. Class and property information for essential classes such as Human Trafcfi Managers, Agents, and UATMs provide additional information for reasoning in this layer. Then, relations are constructed for these classes based on the predicates used in the ASP area.
The flow we covered in the scenario is as follows: Once the human manager reports the vertiport closure, the reasoning component computes the necessary process and returns the detailed result. The result is then updated in the ontology component. Then a human manager can trace the result through the ontology.
The whole approach begins with two common settings for the world and the agents. Due to the page limitation, we here only introduce the used predicates in Table 1.3
In order to make the contents more structured, we will enumerate the queries with the codes first and then provide the results. We note that each code is generalized. Hence, when executing the 3The complete code listings are available as a technical report: https://arxiv.org/abs/2307.03558. We note that, for simplicity, we now intentionally omit the arity part for each predicate. For example, we will write edge_range/3 to edge_range. code, instead of vp6, other vertiports can be specified. 4
Find all vp6 heading agents within the UATM network: In order to answer this query, there is an initial predicate covered_agent in Code 1. This rule is essential for determining whether each agent is covered by the UATM network. Additionally, it searches only agents whose target is vp6. Then, as shown in Table 2, covered_by_uatm2 and covered_by_other present vfie agents: 3, 5, 6, 1, and 2.
Code 1: Find all vp6 heading agents within the UATM network covered_uatm(TM) :- cover(TM, V1), V1 == vp. covered_agent(A, TM) :- loc(A, T, U, V, WP), covered_wp(U, V, TM, WP), target(A, T, V1), V1 == vp. covered_by_target_uatm(A) :- covered_agent(A, TM), covered_uatm(TM). covered_by_other(A) :- loc(A, T, U, V, _), covered_agent(A, TM), covered_uatm(TM1), TM != TM1. trigger_query :- covered_agent(A, TM). covered :- 1 <= #count{A: covered_by_target_uatm(A); A:covered_by_other(A)}. :- trigger_query, not covered. #show loc/5. #show covered_uatm/1. #show covered_by_target_uatm/1. #show covered_by_other/1.
Change the destination of the agents we found: Since we already found these agents from Code 1, the next procedure for the UAT M2 has the followings: • it finds the candidate vertiport for the vp6, • it creates the new plans for the relayed agents: Here, relayed agents include agents covered by other UATMs as well as agents covered by UAT M2, • it appends the new plan to the end of the existing plan for these agents, • it sends target change requests to other UATMs, and • once the plan is ready and target change requests are received, UATMs do the target change for these agents.
The vp6 human manager, then, is known by the target_change as shown in the Table 2.
Handle a landing request from agent 4: Consider the vp6 human manager received a landing
request from agent 4 shortly after he or she informed the target_change. The agent 4 was in
waypoint 2 (or wp2 for short) in Fig. 1 when UAT M2 searched all the vp6 heading agents. We
remark that even though every inch in each corridor is guaranteed to be within the coverage of
the UATM network, relaying the message for each agent may take some time, and some of the
agents may send the landing request before their targets are changed. Shortly after the search, let
us assume that agent 4 moves closer to vp6 and into coverage. In particular, suppose it is located
at loc(
Code 2: Change the destination of the found agents relayed(A) :- covered_by_target_uatm(A). related(A) :- covered_by_other(A). new_plan(A, T+1, V, V1) :- plan(A, T, U, V), target(A, T, V), V == vp, relayed(A), ↪→ candidate_vp(V, V1), step(T+1), not new_plan(A, T, V, V1). target_change_request(A, T) :- relayed(A), new_plan(A, T, V, V1). plan(A, T+1, V, V1) :- plan(A, T, U, V), target(A, T, V), new_plan(A, T+1, V, V1), step(T+1). plan(A, T+1, U, V) :- plan(A, T, U, V), step(T+1). target_change(A, T) :- plan(A, T, U, V), new_plan(A, T, U, V), target_change_request(A, T). :- not target_change(A, T), new_plan(A, T, U, V), target_change_request(A, T). #show relayed/1. #show new_plan/4. #show target_change_request/2. #show target_change/2.
Code 3: Handle the landing request from agent 4 vp_heading_agent_number(N) :- N = #count{A:target(A, T, V), V==vp}. covered_wp(U, V, TM, WP). landing_request(A, T+1, V) :- not target(A, T+1, _), target(A, T, V), loc(A, T+1, U, V, WP), V == ↪→ vp, covered_wp(U, V, TM, WP). new_plan(A, T+1, V, V1) :- plan(A, T, U, V), landing_request(A, T, V), candidate_vp(V, V1), ↪→ step(T+1), not new_plan(A, T, V, V1). plan(A, T+1, V, V1) :- plan(A, T, U, V), landing_request(A, T, V), new_plan(A, T+1, V, V1), ↪→ step(T+1). target_change_request(A, T+1) :- landing_request(A, T, V), new_plan(A, T+1, V, V1). plan(A, T+1, V, V1) :- plan(A, T, U, V), landing_request(A, T, V), new_plan(A, T+1, V, V1), ↪→ target_change_request(A, T+1), step(T+1). - not target_change(A, T+1), landing_request(A, T, V), step(T+1). #show vp_heading_agent_number/1. #show target_change_request/2. #show target_change/2. #show landing_request/3.
In the vp6 manager’s perspective, the landing request would not be welcome. However, after checking that its target hasn’t been updated, he or she can just report to the UAT M2 that the vp6 is closed again.
In the UAT M2’s perspective, since agent 4 is in the coverage of UAT M2 now, handling the
landing_request in Code 3 is not much different from what we have seen in Code 1 and
Code 2. The target_change(
Nonmonotonicity: Through the entire program, the initial background knowledge given is that
vertiport 6 is temporarily closed. Hence, this is a given fact. In order to illustrate the nature of
nonmonotony, agents’ locations can vary. However, due to the unified demonstration of the codes
and the result, the locations of each agent are not selectable while running the system model.
covered_by_other(
Explainability: The query asking whether ’Changing the destination of the agents we found’ is successful is represented as the predicate target_change and its supporting rule just followed by the predicate. The answer shows that target_change(A, T) is true when it is satisfiable. In this query, the validation of the explanation is checked by the combination of the predicate, target_change, which is regarded as a fact when the body of the rule is true, and the safe rule, which ensures the fact’s consistency. Assuming that all the derived rules and relationships lead to the body of the rule as true, the logical consequence makes the predicate target_change by also being connected, and this justifies the answer to the query. We note that the explanation is somewhat abstract depending on the ontological features, and the deeper explanation is desirable.
Future Directions: The research related in the explanation of the complex system is in early stage yet. More scenarios are necessary. Agent movement should be considered more carefully, and the scenario can be reactively simulated with proper foundations. We hope to deliver a comprehensive air traffic management system in the near future.
We have described a scenario involving UATMs. Through knowledge representation and reasoning, the scenario was simulated by expressing the predicates in ontology. Applying the Answer Set Programming framework, queries and their responses were examined from two distinct perspectives: those of a human manager and the UATM system. The discussion then turned to nonmonotonicity and explainability.
This work is supported by the Korea Agency for Infrastructure Technology Advancement(KAIA) grant funded by the Ministry of Land, Infrastructure and Transport (Grant RS-2022-00143965). [11] G. Bourguin, A. Lewandowski, M. Bouneffa, A. Ahmad, Towards ontologically explainable classifiers, in: I. Farkaš, P. Masulli, S. Otte, S. Wermter (Eds.), Artificial Neural Networks and Machine Learning – ICANN 2021, Springer International Publishing, Cham, 2021, pp. 472–484. [12] A. Ozaki, Learning description logic ontologies: Five approaches. where do they stand?,
KI - Künstliche Intelligenz (2020) 1–11. [13] M. Gebser, P. Obermeier, T. Otto, T. Schaub, O. Sabuncu, V. Nguyen, T. C. Son, Experimenting with robotic intra-logistics domains, TPLP 18 (2018) 502–519. [14] M. Gebser, P. Obermeier, T. Schaub, M. Ratsch-Heitmann, M. Runge, Routing driverless transport vehicles in car assembly with answer set programming, TPLP 18 (2018) 520–534. [15] V. Nguyen, P. Obermeier, T. C. Son, T. Schaub, W. Yeoh, Generalized target assignment and path finding using answer set programming, in: IJCAI, ijcai.org, 2017, pp. 1216–1223. [16] A. Olivares-Alarcos, D. Beßler, A. Khamis, P. Goncalves, M. K. Habib, J. Bermejo-Alonso, M. Barreto, M. Diab, J. Rosell, J. Quintas, J. Olszewska, H. Nakawala, E. Pignaton, A. Gyrard, S. Borgo, G. Alenyà Ribas, M. Beetz, H. Li, A review and comparison of ontology-based approaches to robot autonomy, The Knowledge Engineering Review 34 (2019) e29. doi:10.1017/S0269888919000237. [17] S. Chari, O. Seneviratne, D. M. Gruen, M. A. Foreman, A. K. Das, D. L. McGuinness, Explanation ontology: A model of explanations for user-centered ai, in: J. Z. Pan, V. Tamma, C. d’Amato, K. Janowicz, B. Fu, A. Polleres, O. Seneviratne, L. Kagal (Eds.), The Semantic Web – ISWC 2020, Springer International Publishing, Cham, 2020, pp. 228–243.