Urban Air Mobility Situation Awareness From Enterprise Architecture Perspectives

Urban air mobility (UAM) operation is currently under discussion by the industry, authorities, and society, dealing with new concepts, new technologies, and complex challenges. For UAM safety, it is fundamental to strive for high levels of correct decision-making among agents and services. In safety-critical systems like UAM transportation, it is crucial to secure situation awareness (SA). Systems engineers, architects, and organizations must plan for SA acquisition and maintenance from early concept studies to ensure the relevant information is shared, allowing good decision-making. The article proposes a new approach to represent SA in the UAM ecosystem using enterprise architecture (EA) modeling through the unified architecture framework (UAF). To understand the interactions and behaviors committed to SA, decision-making, and safe performance, SA is explored using a process driven by a comprehensive picture of an entire enterprise from the perspectives of designers, providers, and operators. The UAF modeling language and domain metamodel were used as the EA modeling methodology. The model proposed in this article presents a novel and comprehensive representation of SA in the UAM ecosystem. The different views from the model are explored to discuss how the SA can improve the safe accomplishment of UAM missions. The results include views combining people, data, operators, and operational processes showing how an enterprise support SA as a competence.


I. INTRODUCTION
Urban air mobility (UAM) for passenger-carrying operations expect to impact urban transportation by potentially reducing congestion and passenger delay [1]. Vehicles capable of vertical take-off and landing are envisioned to operate for an immediate and flexible air travel demand. The massive discussion about implementing UAM operation is currently the highest challenge for the air transportation market. UAM intends to integrate manned and unmanned aerial vehicles transporting people or cargo in an urban or suburban environment at relatively low altitudes. Control and navigation of such aerial vehicles can be handled by a pilot, a controller from a remote location, on-board automation, or a ground-based centralized, automated system [2]. UAM system of systems (SoS) comprises a significant number of stakeholders, including service operators, service providers, lawmakers, human operators, and the public. The systems integration and human interactions required among UAM components build a complex ecosystem. In addition, the safety-critical aspects of passenger transportation add even more complexity to the UAM SoS. Numerous concepts of operations are being explored throughout industry and research domains aiming for a safe operation for society and efficient transportation for the industry. The technology nuances and emergent behavior of a complex ecosystem like UAM is an abundant source of analysis, approaches, and exploration toward the safe operation. When it comes to UAM safety-related work, there are some thoughtful studies published. However, much of the current research into the safe operation of UAM has dominantly focused on safety assessment techniques, technological constraints, and risk analysis [1], [7], [8], [9], [10]. Although these areas of research are essential to understanding the safety aspects of UAM, research into the Human Systems Integration (HSI) and situation awareness (SA) in UAM is limited [12].
The human operational aspects of the UAM ecosystem are crucial for the safety discussion. HSI is even more critical during the first stages of UAM operation when the vehicle will be piloted, and the traffic management will be human-controlled [4]. Considering the complex and dynamic environment in which pilots and controllers will operate, the process of decision-making is essential for UAM safety performance. Humans can only make the right decisions if they have a good understanding of the environment and are able to avoid unsafe scenarios. SA is "the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning and a projection of their status in the near future" [11]. Supporting SA directly supports the cognitive processes of the operator in complex and constantly evolving environments [13]. In order to design systems that support SA, it is essential to center the design effort on the system user. In that sense, the UAM ecosystem should be organized and operated around the way users process information and make decisions. The human factors (HFs) considerations need to be evaluated in conjunction with the overall systems engineering (SE) [14]. Thus, the best way to support human performance in UAM SoS is to better support the development of high levels of SA.
This article proposes a new approach to represent SA in the UAM ecosystem and provides means to discuss how the SA can improve the safe accomplishment of UAM missions.
The rest of the article is organized as follows. Section II reviews SA literature to understand the concepts applicable to the UAM context. The objective is to identify the critical aspects of SA in the UAM Concept of Operations (ConOps) necessary to understand the problem space. Section III explains the research methodology. After defining the problem of SA in the UAM ecosystem, the chosen approach is justified. The challenges to be mitigated are explored holistically (solution space), a contribution aimed at by this article. Following the modeling methodology applied in this article is presented. Section IV begins the enterprise architecture (EA) development. It introduces UAM ecosystem as an enterprise and proposes model definitions and views to explain how SA exists and interacts as a holistic value. For this reason, enterprise goals, SA capabilities, constraints, requirements, operational concepts, activity, and service views are presented. Section V defines SA as an ecosystem competence and discusses how people, as enterprise components, use and affect this competence. Finally, Section VI concludes this article.

II. SITUATION AWARENESS A. LITERATURE REVIEW
Since early aviation history, the pilot's awareness of what is happening around him has been challenging once his ability to predict problems and perform corrective actions could prevent accidents and save his life. SA comes from the military operation as a strategy of gaining awareness of the enemy before the enemy does the same. The definition of SA was first elaborated on the concern of having a separation between the human understanding of the system status and the actual system status [26]. SA is also important in many other domains, although it sometimes receives different names. For instance, in the world of air traffic management, the air traffic controllers (ATCs) generally refer to SA as the picture, a mental representation of the situation they base their decisions on [13]. Health care and automotive industries are also interested in SA as autonomous systems that play a substantial role in the user's operation. The concept of SA also received attention from the sociotechnical systems agenda, in which the HSI became an essential asset for safety-critical systems. In complex social-technical systems where several agents simultaneously operate at different levels and environments, the interactions between user and system need to be considered when safety is a performance goal.
According to the model of Endsley [20], SA is comprised of three levels. Level 1 SA is called Perception and represents the first step in achieving SA. The user observes the environment, perceives the status, attributes, and dynamics of relevant elements. The set of information to achieve SA for each domain and job type are different. A pilot must perceive the aircraft's attention getting elements, such as the airspace traffic, ground terrain, vehicle system status, warning lights, and sound alerts. In the cockpit, the pilot must keep up with all relevant systems, flight data, navigational data, and communication inputs. An ATC needs to perceive the traffic and the information that comes along with each vehicle's path using displays and communication headset. Level 2 SA is called Comprehension and involves integrating and interpreting critical information. The second step in achieving good SA is understanding what the data perceived means concerning relevant goals and objectives. The user then integrates many pieces of data acquired in the previous step to build a set of information and understand its importance and meaning to fully comprehend the scenario. After observing a set of information in the cockpit, the pilot needs to process the meaning of the data in regards to the operation and access its criticality to understand the scenario. Approximately 19% of SA errors in aviation involve problems with Level 2 SA [21]. When people can see or hear the necessary data (Level 1 SA), it does not mean they are able to understand the meaning of that information correctly. Developing understanding from the many pieces of data perceived is reasonably demanding. It requires a good knowledge base or mental model to put together and interpret disparate pieces of data [20]. The third step is Level 3 SA and is called Projection. It represents the ability to predict the near future considering the elements perceived in level 1 after understanding (level 2) what they mean concerning the mission goal. A pilot can only achieve Level 3 SA by having a good understanding of the situation, the functioning and dynamics of the vehicle, and the operational environment they are working with. Although there is a dependency relation between those levels, the process of acquiring SA is not linear; they instead represent ascending levels of SA [22]. The idea of a simple 1-2-3 progression (data-driven) is not an efficient processing mechanism in a complex and dynamic system, where expertise and goal-driven processing come into play [23].
In aviation, SA is crucial in human information processing and essential in pilots' decision-making processes. Crew and ATCs work actively to project the aircraft's movement and anticipate problems well in advance. By constantly projecting ahead, they are capable of developing a ready set of strategies and responses to events. This allows them to be proactive, avoid many undesirable situations, and also provide a fast response when various events occur. Acquiring and maintaining appropriate levels of SA is critical in aviation environments as it affects all decisions and actions taking place in flights and ATC [19]. Accident statistics indicate that the flight crew is the cause of 70% of air accidents or incidents [24], and many occurrences are due to loss of SA [20], [21], [25].
Currently, the aviation industry has handled SA through HF requirements mainly focused on the cockpit during vehicle design and certification phases and with Crew Resource Management (CRM) during operation. According to the United Kingdom Civil Aviation Authority, the definition of CRM is "A management system which makes optimum use of all available resources (equipment, procedures, and people) to promote safety and enhance the efficiency of flight operations." Used by airlines on the flight crew and other roles in critical safety positions, the CRM aims to enhance flight safety through operational practices and training. According to FAA AC-120-51E, CRM training covers five subjects: SA, communication skills, teamwork, task allocation, and decision-making within a comprehensive framework of standard operating procedures [26]. General aviation has evolved over the past century, learned from accidents, and has well-established safe operational procedures. In this context, SA for general aviation is part of a training and preparation phase and relies on flight decks with mature design and proven HF features.

B. URBAN AIR MOBILITY CONTEXT
UAM is considered a potential alternative for passenger transportation with efficiency benefits and reduced greenhouse emissions [29]. There are currently more than 250 companies working on UAM vehicles, and together with authorities, providers, and the community, different strategies for UAM operation are being addressed [27], [28]. Nonetheless, technical limitations, infrastructure, regulation, and operational constraints, such as safety, security, noise, environment, and public acceptance are potential barriers to the UAM ecosystem [7], [8], [9]. When it comes to the safety aspects of UAM operation for passenger transportation, there are two primary sets of operational considerations: 1) considerations relating to operations occurring in the shared airspace (air operator) and 2) considerations relating to personnel (e.g., pilots, traffic controllers, and maintenance personnel) [30]. These operational considerations can represent additional challenges since UAM operations are expected to occur at relatively low altitudes and in dense urban areas. One of the biggest concerns is the airspace interaction among UAM vehicles, general aviation, and unmanned vehicle systems. The FAA's UAM ConOps [4], [32] describes the envisioned operational environment in phases to support the anticipated growth of flight operations. EmbraerX ConOps [5] also covers this concern with a similar approach, projecting different scenarios with increasing vehicles sharing the airspace and more passengers using UAM transportation. UAM phases were then defined according to the horizons projected. Despite the stage and the infrastructure capacity to handle the UAM traffic control and management, it is expected to have a higher interaction between UAM vehicles and other airspace users. UAM flight profile also affects this interaction in the take-off or landing flight phases. The flight range and time of each flight phase depend on the vehicle design. However, UAM flights' concept expects to transport passengers on short trips, which means more take-off and landing interactions during an operational period. The communication workload of the pilot with other airspace users and traffic controllers is expected to be higher than the current general aviation operation. The ability for UAM to transition from uncontrolled airspace to busy controlled airspace without overwhelming the ATC represents a key unresolved challenge [31]. Likewise, the ability of the UAM pilot to communicate with both general aircraft and unnamed aerial systems (UAS) is also unresolved. Conversely, the ATCs will have a higher workload to manage communication, operational authorization, and guidance. Previous article [12] indicated that medium-and high-density operations were associated with a high workload for the traffic controller. UAM scenarios with increasing levels of traffic density were simulated to be controlled by experienced traffic controllers. Although operational adjustments like route optimization and letter of agreement to reduce communication can reduce workload and increase efficiency, reported workload remained high.

A. PROBLEM SPACE
Increased airspace traffic, augmented need for communication (with other vehicles and with traffic controller), reduced crew, urban terrain proximity adding obstacles, new technologies reducing operator's trust, and new procedures and protocols contribute to a higher workload during UAM operation. UAM SA is strategic and vital for UAM safety operation. Nevertheless, perceiving, comprehending, and projecting scenarios within the UAM ecosystem have not been investigated yet. The workload of UAM operators analyzed in conjunction with SA levels is essential to achieve a safe performance and deserves significant consideration. Understanding the human operator role and responsibilities in UAM is essential to acquire SA and reach the safety performance expected for a passenger transportation system. There is a gap in holistic studies evaluating SA behavior among UAM operators. UAM operational concepts need to explore the degree of involvement of human operators, the functions, tasks, and responsibilities of human operators, and the personnel who will fulfill identified functions.

B. SOLUTION SPACE
Placing SA as a core value of the whole ecosystem allows the first level of requirements to be identified and outspread to promote and secure SA during operation. SA capabilities, ecosystem entities, and behaviors that consume and affect SA must be coherent and consistent. Identifying and exploring HFs issues, such as task demand, associated workload, and performance during an early stage of concept definition, allow for identifying capabilities, potential risks, and associated mitigations of human operator roles.
This article intends to address SA in the UAM ecosystem. The novelty is the holistic approach applied to the conceptual stage to define UAM operation. As mentioned in Section II, SA is mainly focused during the utilization stage, performed by operators providing transportation services and complying with safety standards. The proposal objective is to understand the process of achieving SA from all the ecosystem entities' perspectives and provide means to support a proper SA during concept, design, and operation stages.

C. MODELING METHODOLOGY
Modeling methodologies able to represent a SoSs (UAM ecosystem) was considered a fundamental tool for providing comprehensive material. Modeling eases the burden of dealing with complex systems and provides tools for analyzing behaviors and relationships [40]. Predictive capabilities are also a good value for our approach since the model can be used to predict a system's behavior or process under different conditions. This allows organizations to make informed decisions and plan for potential future scenarios [34]. Other benefits of choosing a modeling methodology include communication and collaboration among stakeholders and cost-effective experimentation. Moreover, aligned with this study's purpose, models can identify potential issues or bottlenecks in a system or process, allowing organizations to address them before they become a problem. Last, modeling can provide a systematic way to represent decision alternatives, evaluate their consequences and trade-offs, and support decision-making processes [40].
EA is a discipline with holistic approach adopted for managing enterprise complexities and aligning enterprise responses to desired business vision and outcomes [33]. An enterprise modeling methodology provides a framework that guides the development and use of models of an enterprise, including its business processes, data, applications, and technology components. EA views aim to provide a comprehensive understanding of the enterprise and its interactions. It supports decision-making and aligns the enterprise with its strategic goals [34].
UAM will be composed of an ecosystem that considers the evolution and safety of the aircraft, the framework for operation, access to airspace, infrastructure development, and community engagement [4]. Although UAM has different use cases, this article will focus on passenger transportation, whose criticality has already been explored in the civil aviation standards and procedures. On-demand aviation ecosystem has many enablers and challenges that can be broadly categorized into market economics, policies and regulation, community acceptance, infrastructure, and innovative and emerging technologies [31]. As a complex SoSs, a wide range of stakeholders are involved in, influenced, or affected by UAM operations. Stakeholders include federal and local authorities, regulatory agencies, infrastructure owners, and operators; service providers; and the public (both users and nonusers).
The UAM ecosystem complexity leads to more significant challenges for organizations that conceive, develop, industrialize, produce, maintain and utilize enterprises, systems, and software, and for various stakeholders impacted by UAM operation. Organizations apply concepts, principles, procedures, and tools to address these challenges and identify opportunities to drive better architecture strategies, make better architecture-related decisions, and create more valuable and effective architectures. EA has a set of views aligned with stakeholders' domains and thence supports decisions at an ecosystem level [33].
Several frameworks can provide a structured approach for designing, planning, and implementing an EA program within an organization. This article uses the unified architecture framework (UAF) for proximity with the modeling language SysML and the ease of integration with other model-based systems. The UAF is a combination of the architecture frameworks from the U.S. Department of Defense Architecture Framework (DoDAF) and the British Ministry of Defence Architecture Framework. It provides fully integrated support from initial concepts all the way to organizational, operational, and implementation details. The UAF is built on top of SysML and is used to define the overall goals, strategies, capabilities, interactions, standards, operational and systems architectures, systems patterns, and so forth [36]. Previous articles have been written using UAF, showing its support of SoS modeling, including [14], [15], [16]. UAF HFs interactions views [17] and service views [18] were also explored, demonstrating the framework's versatility. The holistic approach and capacity to manage complexity place the UAF as a potential and valuable environment to address the SA issue in the UAM context.
The breadth and depth features of different domains of UAF provide a unified environment for defining safety goals, requirements, technical aspects, SA capabilities, and also human interactions, personnel organization, roles, and responsibilities [34]. As an EA framework, the UAF follows EA modeling principles but also offers flexibility and customization. The freedom of creating inconsistent or incoherent elements or architecture poses a limitation in this methodology. Validation is highly encouraged during the process, especially among multidisciplinary teams and stakeholders. Tailoring is another good practice for the modeling effort and improves the quality of the work.
The EA guide for UAF [34] is a method to describe architecture granting processes for conceptualizing and evaluating architecture, as well as being used in support of architecture governance and management activities. The complex and broad views of framing the UAM ecosystem as an EA are valuable tools for holistically exploring SA among all entities, personnel, and services. Placing SA as an enterprise goal and exploring the capabilities of the whole ecosystem is proposed to manage complexity and strategically explore safe operations.
Finally, the purpose of UAF in this article is to create a comprehensive picture of an entire enterprise from the perspectives of designers, providers, and operators, making it able to visualize interactions and behaviors committed to SA, decision-making, and safe performance.

IV. UAM ECOSYSTEM ENTERPRISE
The following sections will describe the architecture components and views using EA modeling methodology in accordance with the UAF standard [34], [36]. After defining SA as an enterprise goal in subsection A, the higher level structure of requirements is established in subsection B. Thenceforth, subsections C-F develop the model's elements usage and definition, starting with SA capabilities and constraints, UAM operational concept, then exploring SA behavior and services required to provide SA.
The authors entirely created the diagrams depicted in this article. The approach using UAF for representing SA in the UAM ecosystem is the result of the authors' work. The views were created following the UAF standard and using concepts defined for SA discussed in Section II. High-level operational concepts were extracted from existing UAM ConOps [5]. All diagrams were validated by experts in the following fields: UAM operation (UAM navigation systems engineer), flight experience (commercial pilot), SA (HF engineer), and architecture modeling (senior model-based system engineer).

A. SITUATION AWARENESS AS AN UAM ECOSYSTEM ENTERPRISE GOAL
Architecture governance is a process that establishes and maintains alignment with enterprise goals, policies, and strategies. It starts with examining and evaluating the current and future enterprise vision. Once the passenger transportation is defined as the UAM ecosystem mission, the enterprise vision is defined by a safe UAM mobility transportation. In the strategic structure (St-Sr) (Fig. 1), it is possible to define the vision statement, vision goals, and utilization phase. In addition to safety purposes, UAM operation also envisions an efficient aviation transportation system in which business success aspects are also important. With the purpose of exploring SA, this article will focus on the safety vision only. Thereby, enterprise goals can be extracted from the enterprise vision.
What makes UAM a safe transportation? The enterprise goals can be defined by answering this question from a high-level perspective. Inspired by the commercial aviation regulation, it is opportune to start with two main ideas: vehicle design and operational aspects. The vehicle shall be designed according to safety standards and shall be able to operate safely (<<EnterpriseGoal>> Id 2). The ecosystem shall provide the appropriate infrastructure to accommodate the operational procedures for safe operation (<<EnterpriseGoal>> Id 3). The first goal (<<Enterprise Goal>> Id 1) proposed in this view is Proper SA: Information about the environment of the UAM flight shall be accurate and available efficiently for all operators. This definition is strategic to explore SA in the UAM ecosystem as proposed by this article. This comprehensive description of the SA goal concerns the emissary and the recipient of the information. The accurate meaning is related to the integrity, validity, and accuracy of what data is available. The efficiently relates to how the data are available. The recipient is the agent for what (or who) the information is efficient. Who receives the information judges the efficiency of the information received based on all the context that impacts the recipient's perception: workload, operational procedures, HFs, and HSI. Understanding how this can be achieved through operators' capabilities, services, personnel structure, roles, and responsibilities is possible through the UAF views.
The enterprise goals represent complex ideas that have integrated or overlap concepts. Although there is a goal specifying SA, the vehicle and the infrastructure/operational procedures are profoundly connected with SA accomplishment. The complexity of systems and the environments in which they operate means the process of achieving a safe operation is not linear. Instead, it is driven by a complex web of relationships and behaviors between humans, technology, and their environment [35]. From a systems perspective, emergent interactions and behaviors are essential to understanding and defining safety operations. Placing SA as an enterprise goal permits scrutinizing the UAM ecosystem under the SA perspective, provided that the next steps for the architecting processes are reasoned on the SA goal. The lifecycle stage intended to be covered by this vision and goals is represented by the element actual enterprise phase. In this article, it is limited to the utilization phase, that is, the flight operation phase, and all the enabling processes directly related to this phase.

B. SITUATION AWARENESS AS AN ENTERPRISE REQUIREMENT
Understanding and planning the architecture requires analyzing stakeholders' needs and defining requirements at a high level. A requirement is a definition of a property that a system or process must be able to perform. As proposed in previous sections, SA is a requirement considering that the enterprise's vision is to provide safe UAM transportation. Moreover, the requirements are coherent with the enterprise goals, including SA, vehicle, infrastructure, and procedures in the high-level structure. The problem statement that binds the requirement definition to the business rationale is "Without accurate situational awareness, the pilot in command (PIC) and the traffic management controllers cannot operate a safe UAM transportation." Defining SA as the top-level requirement aligns with the idea of the UAM ecosystem providing SA as competence (Fig. 2). From that level, it is possible to decompose into three lower requirements. The information available, infrastructure, and operational procedures are the three pillars to achieving a proper level of SA. The significance of SA Level 1 is represented by a dedicated requirement (Id 1.1) to assure that the critical information affecting SA shall be presented correctly and efficiently and be promptly available to the pilot and involved entities. Failure to monitor or observe available information is the most prominent reason for the loss of SA among 262 errors that occurred in 143 incidents [21]. The Information Available requirement "The critical information affecting SA shall be presented correctly and efficiently, and be promptly available to the pilot and involved entities" is then derived into four requirements (Ids 2-5). By specifying behaviors required for the source requirement (Id 1.1) compliance, it is possible to organize the requirement structure to be coherent with the high-level operational concept. Although all requirements exhibited on the diagram represent a high-level definition of the ecosystem, detailed requirements can be organized into a hierarchy using relationships, such as derive, trace, refine, and containment. Satisfying each detailed requirement results in meeting the higher level and ultimately the top-level requirements. The UAF requirement structure and relationship help manage the complexity of large systems. Vehicle Internal Information (Id 2), Vehicle Communication (Id 3), Traffic Controller (Id 4), and Operators (Id 5) are requirements that have comprehensive coverage of topics related to SA and safety operation. From the highlevel requirements depicted on the diagram, it is possible to reach a massive number of requirements, from functional to very detailed low-level components. The requirement definition process is expected to encompass definitions for vehicle design, traffic management, infrastructure, training, safety culture, operators/personnel, and operational standards.
Requirements (Id 7 and Id 8) derived from Required Infrastructure (Id 1.2) are a sample to illustrate how the UAM infrastructure shall be designed to enable SA. The same applies to Operational Procedures (Id 1.3). All three elements (Ids 1.1 to 1.3) are interrelated and constitute a complex web of needs and enabling components. Defining requirements as they are independent and isolated is not possible with SA. The dependency relationship is a constant presence and becomes even more complicated when SA is a product that affects the system that generates it. As explored in the following sections, UAF domains and views can help understand how the elements are integrated toward SA achievement.

C. SITUATION AWARENESS CAPABILITIES AND CONSTRAINTS
Capability is a high-level specification of the enterprise's ability to execute a specified course of action [36]. DoDAF defines capability as the ability to achieve the desired effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities. Capabilities definition is a key point for the architecture conceptualization process because most operational, resources, personnel, and services definitions strongly relate to capabilities. Furthermore, defining the architecture capabilities allows understanding of the system's purpose and the model's purpose.
UAF has a set of views for defining capabilities. Traceability and association relationships can be used among different views, including the operational architecture, which defines the system's abstract, logical, and solution-independent expression intended to be used in operations. As a result, the system views can define how these capabilities and operational architecture will be realized [37]. The strategic taxonomy (St-Tx) view specifies all the capabilities that are referenced throughout one or more architectures. In addition, it can be used as a source document to develop high-level use cases and user requirements.
The UAM ecosystem is composed of physical entities and human operators. When analyzing what types of abilities those components are required to provide a proper SA level, it is expected to consider systems capabilities from a technology perspective and human operation. Starting from SA Level 1, the perception stage requests monitoring the environment as a capability. There are different ways of achieving it, which is represented by the generalization relationship for Listen, See, and Feel [ Fig. 3(a)]. A generalization describes a relationship between a general kind and a more specific kind of thing. It is possible to monitor the environment either by listening, seeing, or feeling, or with any two or three senses simultaneously. Much of Level 1 SA comes from the individual directly perceiving the environment [13]. In the UAM context, the pilot uses all its sensory systems to capture information in highly dynamic behavior. Not only flight deck displays or sound alerts are present at this stage, but the pilot will eventually look out the window or feel acceleration motions on his body. Traffic controllers also need to use vision and hearing to monitor instruments and perceive the environment, although it represents a different set of information. Verbal and nonverbal communications with others form an additional information source that is drawn upon and contributes to Level 1 SA [13]. In this diagram, communication was specified by four types for differentiating the capability according to the resource's operational activity. This semantic of the model is strategic and valuable once the activities and services are being defined for the enterprise entities.
Level 2 SA requires a mental process to comprehend the scenario. Comprehension is based on a synthesis of level 1 elements and a comparison of that information to the mission objective. It involves integrating many pieces of data to form information and prioritizing that combined information's importance and meaning [13]. Process scenarios, process warnings, and process priorities are parts of this stage and are defined in the capability's taxonomy. The significance of the information perceived in the previous stage depends on the meaning of a specific operational goal. For instance, a pilot may comprehend a scenario differently when performing different tasks. During take-off, some goals and tasks are associated with the vehicle's airspeed, attitude indicator (artificial horizon), and propulsion. In contrast, propulsion system indication data comes to attention in the cruise phase if there is an off-nominal occurrence.
Level 3 SA is associated with the ability to project the future of the elements in the environment. The third and highest level of SA is achieved through knowledge of the status and dynamics of the elements and comprehension of the situation (both Level SA 1 and Level 2 SA) [20]. Anticipating the projected future situation provides the pilot (and ATC) with time to resolve conflicts and plan a course of action to meet their goals. Therefore, time is a critical piece in this stage. Predict Problems and Perform Corrective Actions are capabilities necessary to project the near-term future of UAM operation. For example, UAM traffic controllers will need to manage considerable airspace traffic, and avoiding collisions is one of their goals. They will need to put together information on various traffic patterns and flight plans to determine which UAM route will be accessible and where there is a potential for collisions.
Provide Information was added in the capability taxonomy as a counterpart of the perception level. In the UAM ecosystem, human users perceive the environment because there are physical or human entities providing information. Most problems with SA in the aviation domain occur at Level 1. In some cases (roughly two-fifths), this occurred because the needed information was not provided to the person who needed it or was not provided clearly due to system limitations or shortcomings [21]. The proposal to look at SA as an enterprise product must include the system's capability to provide the correct information in the best way and in a timely manner to achieve the intended safe performance.
Mental Model is a systematic understanding of how something works. Also known as schema or long-term memory structures, mental models were defined by Rouse and Morris [38] as mechanisms whereby humans are able to generate descriptions of system purpose and form, explanations of system functioning and observed system states, and predictions of future states. Mental models are based on both semantic knowledge and system knowledge and are complex structures people use to model the behavior of specific systems and operations. Moreover, this capability is a cognitive structure that allows humans to interact effectively with their environment by organizing knowledge into meaningful patterns. A mental model allows a pilot to take control of his attention and anticipate the consequences of those actions. Training, practicing different scenarios, and hours of practice can strengthen a mental model. Apart from the cognitive aspect that involves the mental model, the operational procedures play an important role in aviation operation. Operational checklists, authorization procedures, health checks, and turnaround procedures are also a way of organizing the knowledge into corrective actions. Mental model without knowing procedures is not effective. Similarly, knowing procedures with a poor mental model does not help predict a problem. In this sense, Know Procedures are defined as a capability and are crucial for safe operation. Considering that the model is defined for the utilization phase, it is expected to have already defined operational standards and procedures. Those topics are typically explored and defined by federal and local authorities, together with industry, OEMs, and stakeholders. The capability described in this taxonomy is intended to cover the dissemination and application of such procedures during operation.
Evidently, the capabilities of users and systems are deeply connected and constitute a complex dependency relationship. It is not possible to look into one capability without considering the others. UAF's strategic domain also includes connectivity, states, parameters, and traceability views to explore capabilities and capability management processes. Fig. 3(b) shows the constraints that are performance requirements constraining capabilities. The diagram defines a set of constraints related to HFs and a set of constraints related to the UAM ecosystem. Workload Level (composed of Boredom and Fatigue Handling), Emotion Handling, Trustability, Physical Discomfort Handling, Out of the Loop Syndrome, Attention Tunneling, and Complexity Creep are known hurdles for acquiring and maintaining SA from the user perspective [13]. All the constraints can reduce or cause loss of users' SA. This taxonomy is essential to define system states and behaviors since proper SA is a performance the ecosystem intends to achieve. The strategic constraints are all related to the recipient's context and what can affect the capability of processing and achieving SA. It allows us to focus on the pilot (or controller) when they receive information. The efficiency of the information provided must be considered from the recipients' capability of dealing with constraints.
When defining organizations and roles' responsibilities, knowing the constraints enables the enterprise to be prepared to prevent them. Correspondingly, UAM ecosystem constraints like High Traffic Handling, Network Connectivity Overload, Short Response Time, and Technology Uncertainty can affect the capability of physical components. High Traffic Handling increases the workload for both pilots and controllers. Network Connectivity Overload can affect the information flow accurately and at the right time. Short Response Time is related to the operational concept of the UAM flight profile, in which the pilot and controllers will have less time to react against an off-nominal situation. Last, Technology Uncertainty is a barrier to the UAM operation because new technologies in the vehicle (propulsion, energy, navigation, and traffic avoidance systems) and network (traffic management) can add failures and faults, increasing the workload of the operators.
There are undoubtedly other constraints for UAM operation like the weather, regulation, public acceptance, business model, security, and noise levels, to mention a few. However, as stated before, this model develops the architectural views and defines elements placing SA as a center piece.

D. UAM HIGH-LEVEL OPERATIONAL CONCEPT FROM A SITUATION AWARENESS PERSPECTIVE
UAM operation is the most discussed topic by the industry and lawmakers. Initiatives to discuss operational aspects involve many stakeholders and have raised different approaches. Operational considerations depend on vehicle type, airspace classification, business model, regulation, and specificity of locations, such as topology, local laws, public acceptance, demand, and infrastructure capacity [6], [7], [8], [9]. Traffic density projections and the infrastructure required to provide transportation and automation level make it necessary to define implementation in stages. Both FAA [4] and Em-braerX [5] published ConOps, which envisioned evolutionary states demonstrating how UAM operation can achieve a mature status. In this article, the UAM operational context includes medium-density operation, eVTOL vehicle type, PIC on-board, human-within-the-loop, and dedicated traffic management [urban air traffic management (UATM)]. Although autonomous flight is out of the scope of this architecture, human-on-the-loop, in which humans have supervisory control of the automation systems and can take full control when required or desired, is suggested in Section VI and can benefit from this article approach.
The UAF high-level operation concept diagram describes the resources and interactions required to meet an operational scenario from an integrated systems point of view. It is used to communicate overall quantitative and qualitative system characteristics to stakeholders. With SA in mind, the diagram in Fig. 4 depicts how the pilot, operators, and controllers are receiving and providing information during a UAM flight. UATM is the collection of systems and services that support the integrated operation of UAM vehicles in low-level airspace. Traffic management for UAM, UAS, and traditional aircraft will need to be integrated, and vehicle interactions will occur. In the UAM operational context, the PIC receives information from the UAM traffic controller, which in turn receives integrated information about external elements like weather information provider, UAS, and general aviation traffic (through ATC). UATM, represented as a symbol in the diagram, is the network system that integrates the external providers, and the UATM traffic controller is the human operator communicating with the PIC using data from the UATM network.
Vertiport is an area UAM vehicle (eVTOL) used to takeoff and land. A vertiport can have single or multiple UAM final and take-off areas (FATOs). Vertiports can be dedicated to passenger transit, maintenance services, and a place for charging the battery and parking vehicles. Navigation aids and visual cues with corresponding instruments are expected to be used in vertiport operation. For emergency situations, vertiport could be required to have contingency FATO and stands. Vertiport resources management is done by the vertiport operator, which also provides pertinent information to UATM. Moreover, ground traffic management is controlled by a vertiport operator, wherefore guidance and information are provided to PIC while the UAM vehicle is on the ground.
UAM operator is composed of pilots and vehicles. It is the organization that runs the operation and has direct contact with the passenger. During the flight, the pilot must be aware of vehicle (internal environment), terrain, airspace, and other vehicles (external environment).
This view represents a simplified idea of how the information is integrated into the UAM ecosystem and how it flows. As an ecosystem, or according to the SoSs definition [2], UAM is not an extensive monolithic system. There is operational and managerial independence of their components, and it has an evolutionary nature, emergent behavior, and a geographic extent that limits the interaction of their components to information exchange. The UAF high-level concept diagram is essential to understand which and how entities are integrated and sharing information. This step is crucial to defining organizations, operational processes, and activities. According to the operation described above, organization roles and responsibilities are defined in UAF personnel domain. Due to the size limitation of this article, personnel details are not depicted. Nonetheless, a sample of how personnel elements are valuable for the architecture definition process is discussed in Section V.

E. SITUATION AWARENESS BEHAVIOR DURING UAM FLIGHT FROM THE SENSORIAL SYSTEMS PERSPECTIVE
The UAF operational (Op) domain illustrates the logical architecture of the enterprise. There are 10 different views capable of describing operational behavior, requirement, structure, and exchanges required to support (exhibit) capabilities. UAF operational processes (Op-Pr) view concerns capturing activity-based behavior and flows. Having the operational performers defined by UAM vehicle, PIC, UATM traffic controller, UATM network, vertiport operation manager, and vertiport, it is possible to describe the activities typically conducted in the course of a UAM flight. SysML activity diagrams are used to explain a system behavior by telling a story and conveying a narrative. In this diagram, it is possible to know who (performers allocated on swimlanes) performs the behavior (action), what is needed as input, and what is the output of each action (token flows and pins). The intended usage of the operational processes (Op-Pr) view includes a description of activities and workflows, requirements capture, definition of roles and responsibilities, support task analysis to determine training needs, operational planning, and information flow analysis.
The traditional approach for defining operational flow in aviation is based on flight phases. A timeline is followed to describe the steps from flight plan approval, preflight check, take-off, cruise, approaching, landing, and postflight check. Analyzing the operational steps according to the flight phase and understanding the pilot, controllers, and other operators' tasks are fundamental to planning a safe flight. However, it does not represent the SA behavior with clarity. The proposed approach in this article intends to answer the following questions: If it was possible to see the SA behavior from the human operators' sensorial systems through a diagram, what does it looks like? Fig. 5 demonstrates how the UAM ecosystem uses the SA capabilities and represents the operator's sensory systems consuming capabilities while performing SA actions during UAM flight.
Aircraft's flight deck systems mostly combine visual and auditory displays and panels, making the pilot process multisensory information. In everyday life, a person can see, hear, smell, taste, feel different environments, and process information without much effort. Our brain can integrate and combine multiple senses' input even when there is incongruency among the information being received. In the cockpit, the sensory system of the pilot is the leading performer in acquiring SA. In the operational flow (Fig. 5), the pilot acknowledges the vehicle status using his primary capabilities: see, listen, communicate, and feel. Vehicle displays can show visual information about all its subsystems in different colors, layouts, sizes, and dynamics (blanking or fixed). Pilots need to acknowledge vehicle status to understand the vehicle's health state and to aviate and navigate. Data about systems status, faults, and failures (health data) will provide SA about the internal environment: the vehicle. The same applies to sound alerts in which vehicle warnings and cautions are emitted to inform the pilot of a situation requiring attention. Different tones and messages are played in the cockpit to alert the crew when certain conditions exist internally or externally (for example, terrain warnings). Communication represents the capability of hearing and speaking as a dual and combined activity for operators. The vehicle provides communication systems allowing the pilot to receive information from other vehicles and ground controllers about the internal and external environment. Still, from the vehicle as an operational performer, the flight motion can be felt by the pilot and inform about the vehicle's state, like acceleration force or vibration during abnormal conditions.
The actions allocated to the operational performer PIC include acknowledging the internal environment (vehicle) and external environment (airspace and ground) using its primary capabilities from its sensory systems. After receiving inputs from different sources, the pilot is able to perceive the environment and build the first SA capability, Perception (in pink). When the pilot is capable of processing what the information perceived means in terms of the mission goals, it can achieve level 2 SA capability: Comprehend (in orange). If he can project the scenario, predict problems, and take corrective actions, he can reach Projection (in purple), level 3 SA. The SA operational flow aims to fly the vehicle safely. Therefore, the action fly vehicle in the diagram represents the operational outcome for this behavior.
Traffic controllers and vertiport operators are also part of the UAM SA behavior when it comes to informing about the pilot's external environment. Controllers and operators collect and process visual and auditory data, providing information, guidance, and warnings to the pilot through communication capability. Likewise, controllers and operators also perceive the environment, comprehend the information in the mission goal's context, and project scenarios to provide the correct guidance for safe traffic management. In the diagram, the controller's input (primary capability) came only from the UATM, an operational performer integrated with other organizations sharing the airspace. However, the communication output after projecting scenarios is expected to happen with different vehicles simultaneously. The same is true for the vertiport operator who may need to control more than one vehicle while on the ground, guiding before take-off, after landing, during taxing, parking, and battery or maintenance support. The vertiport operator also communicates with UATM, who may inform about any emergency condition requiring vertiport usage and needs a vertiport status report.
SA is not linear, and the human cognitive process is very complex to be captured in only one behavior diagram. The inputs to the pilot's sensory system are part of a dynamic process, increasing the challenge of reproducing in the model. The dynamic aspect of an actual flight is an important temporal aspect of SA. Since the situation is always changing, the pilot's and controllers' SA must also constantly change or become outdated and thus inaccurate [20].
The lack of "initial" and "final" nodes in the diagram is a symptom of behavior with little linearity and order. Nonetheless, understanding how the human operators use their sensory systems in the UAM ecosystem is essential to knowing the extent of the workload and cognitive process to maintain a good level of SA. The limit of how many elements one person can pay attention to at one time affects how much information a person can process, forming a central bottleneck for SA [13]. Simultaneous information can be more easily processed (e.g., visual and audio information) or can place a person in cognitive overload. If information requests the same resources (central processing) from the operator, like visual, auditory, tactile, or smell, it is more difficult to attend to simultaneously [39].
Considering the workload and the amount of information received during a flight a major concern in this process flow, the sources of information shall share the same goal: to keep efficiency for the recipient. Mapping the source of information and how the human operators use their SA capabilities bring light to the analysis of how to acquire and maintain SA in the UAM ecosystem.

F. SERVICES TO ACHIEVE SITUATION AWARENESS DURING UAM FLIGHT
UAF operational processes (Op-Pr) view also describes the activities that are conducted in the course of achieving business goals that support a capability. In the UAM context, the PIC is an operational performer capable of performing UAM flight. As a high-level activity, it can then be decomposed by Monitor Vehicle, Aviate Vehicle, Navigate Vehicle,  UAF services (Sv) domain shows the specifications of services and service levels of these specifications required to exhibit a capability or to support an operational activity. Services in UAF are intended to allow the operational layer to be developed without impacting the resource layer, provided that the operational layer consumes the functionality defined for the services interfaces. Likewise, the resource layer can develop independently without impacting the operational layer, provided the service interfaces are untouched [18]. Fig. 6 shows the services taxonomy (Sv-Tx) diagram specifying the services consumed by the operational activities performed by the PIC. Each service specification exhibits the capability requested by the operational activity. Monitor Vehicle Service is a critical service that other services depend on. For the pilot to aviate, navigate, and communicate, he or she needs to monitor the vehicle constantly. The service methods are defined and represent the behavioral aspect of the performer (pilot) consuming the service. Thus, pilots see displays, listen to audio alerts, feel the environment (with their body through tactics, smelling or feeling acceleration and vibrations) and see components (like switches, buttons, and lights) in the vehicle. The access to the behavioral methods is the pilot's sensory system, defined by the Service Port propriety. In order to consume this service, the UAM vehicle, already defined as an operational performer, also has an operational activity called Provide Vehicle Data and consumes the service Vehicle Data Delivery Service. This service exhibits the capability Provide Information and is specified in accordance with the service required by the pilot.
According to the strategic view, the workload is specified in this service as a constraint able to affect the capability exhibited by the pilot as a recipient of the vehicle's information. For space limitation reasons, the other diagrams showing the services consumed by other operational performers are not illustrated in this article. However, the usage of the service view is strategic to cover the service requested and coherently provided by the enterprise. It also defines all operational elements in an implementation/ solution independent manner.
In the same sense, Vehicle Navigation Service, Aviate Vehicle Service, and Communicate were specified to accomplish the correspondent capability exhibition. The operational tasks like aviate, navigate, and communicate are complemented by the operator's needs to achieve and maintain SA and other important HFs. Constraints to the service are related to the vehicle or other physical entity, and most importantly, in this approach, they are related to the pilot's ability to process SA. Poor mental mode, workload level, distraction, emergency events, and unknown procedures are constraints that compromise the pilot's SA. In the vehicle data delivery service, for example, graphical and sound alerts have HFs as a constraint. Therefore, providing data needs to consider the human response to best delivers the information to the operator.
The service specification is a valuable tool in the EA when designing for SA is the primary goal. Services are not limited to internal system functions and can include HSI and graphical user interface functions [18]. The external service data providers and consumers can represent the human interacting with the service. Constraints to the services can be explored to identify mechanisms to mitigate SA loss in every service instance. Ensuring that the necessary information is obtained by the system and presented in a way that makes it easily processed by the system users, who can have many competing pieces of information contending for their attention [13].
Operational knowledge and training needs are essential components of SA. Pilots can only comprehend and project the flight scenario if the operational procedures are safe and properly known (as defined in requirement ID 1.3; Fig. 2). The Operational Education Service is consumed by the UAM flight and is necessary to all its owned operational activities. The service that provides the pilot education must consequently match the specification and should be planned by the UAM operator accordingly. With other UAF views in the service (Sv) domain, it is possible to define service connectivity, interaction scenarios, parameters, process, roadmaps, and traceability. In addition, services interface can be defined to invoke a service regardless of the technology. This is helpful because specifying the interface for the service provides a way of determining compatibility between service consumers and providers. In the architecture where SA is a goal, it is precious to verify if the human aspects are being provided as requested by human performers.

V. DISCUSSION: UAM ECOSYSTEM PERSONNEL REQUIRING SITUATION AWARENESS AS COMPETENCE
Competence in UAF is a specific set of abilities defined by knowledge, skills, and aptitude. Competence in the framework metamodel can be required or provided by an organizational resource. A function can also be associated with a set of competence to show what is needed to conduct the function. In addition, there is the Competence for Role, a tuple used to associate an organizational role with a specific set of required competencies. Having the element Competence and its relations provided by the model, this article proposes exploring SA as a competence in the UAM ecosystem.
The cognitive process serves as a function of the human operator's mental equipment. SA is the product of these processes, which also affects the process in a circular fashion [22]. Acquiring SA is a long and complex process that encounters obstacles from different sources and nature. Using EA views is possible to group elements of the physical and technological environment (vehicle, network, and devices), organizations with roles and responsibilities, operational flows, and human aspects imbued with constraints, services, relationships, capabilities, and competencies. By developing a good understanding of how people develop SA in the UAM operation and the challenges and limitations to the process, strategies for designing to enhance SA will be more apparent [13].
The architecture enablement process aims to develop, maintain, and improve the enabling capabilities, services, and resources needed to achieve the architecture goals. For instance, enabling services include, among other things, infrastructure, technologies, skilled personnel, and automation agents. Enabling resources include, among other things, architecture repository, library, and human and technical resources. As a result of the successful implementation of the architecture enablement process: 1) enabling capabilities, services, and resources are available when and where they are needed and are accessible by those who need them; 2) enabling services are suitable for and accessible to the architecture process activities; 3) enabling resources are suitable for and accessible to the architecture process activities; and 4) personnel have the requisite knowledge and skills for proper use of the enabling capabilities, services, and resources [36]. The personnel (Pr) domain describes the human-related elements of the architecture. It aims to clarify the role of HF when creating architectures in order to facilitate both human factors integration and SE.
Personnel taxonomy (Pr-TX) shows the taxonomy of types of organizational resources. It shows the possible relationships between organizational resources and composition relationships (one organizational resource being part of a parent organization). In addition, roles and responsibilities can be defined, as well as the interactions between those roles, where "roles" represent the functional aspects of organizational resources. Fig. 7 is a sample of the types of relationships that can be explored. Other taxonomies diagrams defined posts on the three prominent organizations identified from the high-level operational concept: UAM operator, UATM operator, and vertiport operator. Each of the posts can then have all responsibilities defined and associated. In the diagram below, a few posts are linked to the owner organization and some of the responsibilities allocated to them. It is shown only one post for each organization and a set of responsibilities to illustrate how the relationship with operator, activity, organization, and competence can be defined. It is clear that pilots require SA to perform a flight. However, his organization also requires SA competence since other posts are planning flights and controlling the vehicle operation schedule.
At the other end of the question, organization, posts, and process also provide the competence SA. Alternatively, entities that provide SA directly impact the UAM SA's competence. For example, UAM operator needs a post to manage the pilot with the responsibility of defining the pilot's work scale and availability. Also, pilot credentials and skills guidelines must be managed according to the training agenda defined and offered by another post, the training manager. Health condition guidelines and managing pilot health (physical and mental) are other departments' responsibilities and contribute immensely to the pilot's SA competence. The same reasoning applies to other posts in other organizations, like UATM and vertiport operators. There are modeling tools to understand and visualize the extent to which SA can be affected and how it is achieved. Relation maps and tables in the UAF (not shown here for space reasons) are especially useful in complex architecture. SA, as a competence in the UAM model, can be viewed as a product that affects the process of achieving it. Moreover, it is possible to show how a post that performs administrative work can affect the other end when a pilot performs a landing task, for example.

VI. CONCLUSION
In complex sociotechnical systems like UAM, SA is not limited to the individual mind as a pilot or traffic controller. However, it is a collective cognitive process distributed at different enterprise levels. Not only personal skills and technologycentered devices contribute to a proper level of SA. Workload, team communication, and interactions between agents, which can be human or nonhuman, may compromise the SA. Safe UAM transportation depends on achieving and maintaining an appropriate level of SA. This article addressed a comprehensive concept of SA in the context of the UAM ecosystem. A holistic approach to understanding what constitutes the process of achieving and maintaining SA during UAM operation was proposed using EA principles. To reunite and integrate different elements defining SA in the UAM ecosystem, this article utilized domains and model kinds of the UAF.
Starting by placing SA as an enterprise goal, the requirements were organized considering the UAM ConOps. SA was placed strategically at the highest level of the enterprise requirement. SA capabilities were identified together with the constraints that compromise them. Operational processes and performers were used to understand SA behavior from a pilot and controllers' perspectives as an example of how SA capabilities are valuable assets in the model. Moreover, services were presented to demonstrate how the pilot's operational activities consume to exhibit SA competencies. Finally, we discussed about how SA as competence is provided and required by different organizations and roles. The extent relationship between elements and competence within UAF model proved to be opportune to demonstrate that SA is not a simple frame during an operational task; many more levels in the enterprise affect SA. The SA, as a product that affects the process to achieve it, is more noticeable with the UAF modeling.
The first version of the model was scrutinized by experts and modified to better represent the SA in the UAM ecosystem. The success of the modeling effort was measured by achieving different views with coverage, coherence, and consistency, and receiving validation from experts on the research field. The UAF has fulfilled the purpose of modeling consistent architecture for the UAM SoS and supporting the analysis, specification, and design of UAM SA. Moreover, the model provided insightful outputs to understand SA behavior and structure. In the UAF personnel domain, organizations and roles are parts of the architecture and have responsibilities directly associated with the SA effort. Therefore, personnel views allowed for analyzing human aspects quantitatively and qualitatively when operational activities, responsibilities, and service specifications were defined through the SA lenses.
In addition, UAF enabled the definition of the global SA trace from an enterprise goal to users' capabilities in different operational scenarios. With the capabilities defined according to the SA process, it was possible to explore which and how the architecture elements use or contribute to the SA as a product. Capability gap analysis and sources for deriving cohesive sets of user requirements are other relevant insights the UAF model provides. The information and the processes can be organized consistently with the person's goal to require SA or provide SA. The next step in the model is to detail the structure and behavior of organizations and operational procedures. The UAF has a domain called Actual Resources used to represent real assets within a real operation. Moreover, the model can handle complex and integrated information in a very convenient way. Tables, diagrams, hierarchy views, matrices, and relation maps can be used to explore the correlation of different entities in the enterprise.
Whereas the operational tasks of the pilot and controllers have yet to be described in this article, it is suggested to use the framework to evaluate the workload and task analysis. Research on operational tasks during different flight phases and scenarios is encouraged. With detailing input, the operational process flow discussed in Section IV-E can be used to simulate the information flowing to the pilot using different techniques and configurations. Tactile displays, suggested as an alternative to reduce the chance of cognitive overload, can be added to the model to verify the pilot's workload. Taking advantage of parallel processing capabilities is one of the principles for designing for SA. Using UAF behavior viewpoints to explore different information flows and evaluate user processing capability is crucial to achieving a proper level of SA. Moreover, constraint capabilities were defined in the taxonomy and can be explored in future article while simulating SA states according to task analysis. The behavior of a user losing SA can be modeled once the set of operational tasks and states are described. Finally, the discussion on cockpit automation and autonomous systems in UAM can take great advantage of modeling SA. Presenting the UAM ecosystem in terms of SA can provide a robust frame of reference for new technologies, operational procedures, and training needs and increase people's trust in the operation.