KR20240029396A - Method for managing traffic flow for urban air mobility and apparatus and system therefor - Google Patents

Abstract

The present invention relates to a traffic flow management method for urban air mobility and an apparatus and system therefor. The method performed by a server for managing the traffic flow of UAM (Urban Air Mobility) according to an aspect of the present disclosure includes the UAM And collecting information from an external server, analyzing air traffic flow based on the collected information, and generating information on a user interface screen for providing real-time air traffic flow information based on the analysis results. and transmitting information about the generated user interface screen to at least one of the UAM and the external server.

Description

Traffic flow management method for urban air mobility and apparatus and system therefor {Method for managing traffic flow for urban air mobility and apparatus and system therefor}

The present invention relates to a technology for managing the traffic flow of urban air mobility, and more specifically, to a technology for smoothly managing the traffic flow of urban air mobility and safely arriving at the destination according to the flight plan. will be.

The concept of Urban Air Mobility (UAM) was first defined by the National Aeronautics and Space Administration (NASA) as “safe and efficient air traffic operations in metropolitan areas for manned and unmanned aircraft systems.” Recently, as governments, businesses, and research institutes have shown increasing interest in UAM, this new concept is spreading rapidly.

Recently, the Ministry of Land, Infrastructure and Transport established a Korean urban air transportation (K-UAM) roadmap and technology roadmap to create a UAM ecosystem, and discussions are actively underway to expand the number of participating organizations in UAM Team Korea.

In addition, the K-UAM Grand Challenge operation plan (draft), a public-private joint demonstration project to sufficiently verify safety and prepare operational concepts and technical standards suitable for domestic conditions before the UAM commercialization stage, was approved.

UAM Team Korea plans to discuss more specific matters necessary for commercialization of UAM, such as enacting UAM special laws, establishing UAM-only skyways, and presenting infrastructure guidelines.

The UAM traffic management system is largely comprised of airlines/operators/aircraft manufacturers who establish flight plans and directly manufacture, operate, and manage aircraft, perform review and approval procedures for flight plans, share flight safety information, and manage overall traffic flow. It can be divided into a UAM traffic management service provider that controls and a vertiport operator that operates basic infrastructure such as vertiports (takeoff/landing grounds).

According to a market report by Global Information, Inc., the urban air mobility (UAM) market size will expand at a compound annual growth rate (CAGR) of 13.5%, from $2.6 billion in 2020 to $9.1 billion in 2030. It is predicted to grow. Factors such as improved efficiency, safety for people, and increased investment demand are expected to promote market growth.

UAM is expected to revolutionize existing transportation modes including highways, rail, air and waterways. A 2018 Morgan Stanley blue paper estimates that the global UAM addressable market will reach $1.5 trillion by 2040.

The UAM concept can be further extended to applications in rural areas where existing ground transportation infrastructure is inadequate. In particular, in addition to the transportation sector, UAM vehicles are expected to be applied in specific scenarios such as tourism, industry, emergency medical services, and fire control.

In the future, smart UAM vehicles may be equipped with autonomous driving capabilities and remote control functions to eliminate the need for a pilot on board. This not only eliminates the need for pilots and related costs in the vehicle, but also prevents the risk of safety accidents due to human error, and makes it easier and safer to control and control the vehicle on the ground.

UAM vehicles are flying vehicles that transport passengers or cargo on a point-to-point route within an urban area. Unlike aircraft that use conventional runways due to the constraints of buildings, factories, road traffic and urban crowds, the ideal vehicle model must be autonomous, small, efficient, agile and maneuverable with the ability to take off and land vertically.

In addition, electric UAM vehicles are environmentally friendly by using eco-friendly energy such as solar energy, electric energy, and hydrogen fuel rather than existing fossil fuels in consideration of atmospheric environmental issues, etc., and have the advantage of producing no exhaust gases at all.

UAM vehicles have the advantage of being faster and more efficient than traditional ground transportation in that they allow individuals and cargo to move between cities on direct air routes.

The centralized UAM platform provides a convenient network, eliminating the need for individuals to own their own UAM vehicles. This not only improves asset utilization but also reduces resource waste.

Additionally, a centralized UAM platform can eliminate the parking problem that dominates much of today's urban life and has the advantage of realizing a true sharing economy compared to traditional cars.

UAM can provide short-distance (3 km - 100 km) air services and is designed for urban residents, effectively solving the "last 50 km" problem that current airlines cannot provide.

For early commercialization and activation of UAM services, a UAM traffic flow management method that can manage UAM traffic flow more safely and efficiently is required.

The purpose of the present invention is to provide a traffic flow management method for urban air mobility and an apparatus and system therefor.

Another object of the present invention is to provide a UAM traffic management system capable of safely and efficiently managing and controlling the traffic flow of urban air mobility.

Another object of the present invention is to provide a traffic flow management method for urban air mobility capable of efficiently managing flight delays by providing intuitive flight guidance information to the relevant operators and pilots by monitoring the flight delay status in real time compared to the flight plan, and the same. To provide devices and systems for

Another object of the present invention is to provide a traffic flow management method for urban air mobility that can minimize traffic congestion and resulting cost losses at Bertie Port due to flight delays and early arrival, and an apparatus and system therefor.

Another purpose of the present invention is to calculate the optimal operation speed and operation route for the aircraft by monitoring the real-time operation status of the aircraft in the corridor based on the sensing data collected from the aircraft, and to calculate the optimal operation speed and route for the aircraft. It provides a UAM traffic management system that can be configured as an intuitive user interface screen and provided to the relevant operator and/or pilot.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

A method performed by a server that manages traffic flow of UAM (Urban Air Mobility) according to an aspect of the present disclosure includes collecting information from the UAM and an external server and analyzing air traffic flow based on the collected information. generating information on a user interface screen for providing real-time air traffic flow information based on the analysis results, and transmitting information on the generated user interface screen to at least one of the UAM and the external server. It may include steps.

In an embodiment, the information collected from the UAM includes sensor data collected by sensors mounted on the UAM, driving data collected from ECUs (Electric Control Units) mounted on the UAM, and GPS receivers mounted on the UAM. It may include at least one of positioning data.

In an embodiment, the external server is a UAM flight server that provides at least one of flight plan information and real-time operation-related information, and an infrastructure operation server that provides at least one of type information for each port, available information, and real-time capacity information. It may include at least one of a flight support information providing server that provides at least one of corridor design information, information on obstacles and terrain for each corridor, emergency landing site information, base station information, and weather information.

In an embodiment, the information on the user interface screen includes information on a four-dimensional view screen containing at least one of latitude information, longitude information, altitude information, and flight time information of the aircraft in flight for each corridor connecting two vertiports. It can be included.

In an embodiment, the information about the four-dimensional view screen includes information about a horizontal view screen configured to arrange the corridors connecting the two verti ports on a horizontal plane, and information about the four-dimensional view screen configured to arrange the corridors connecting the two verti ports on a vertical plane. May contain information about the configured vertical view screen.

In an embodiment, the method further includes identifying the two vertiport types and determining one of the horizontal view screen and the vertical view screen as the main view screen based on the identified vertiport type, , Based on the fact that the identified verti port type is a Single-FATO (Final Approach and Take-Off area) in which two aircraft cannot take off and land simultaneously, the horizontal view screen is determined as the main view screen, and the identified verti port type is determined to be the main view screen. Based on the fact that the port type is Multi-FATO, which allows simultaneous takeoff and landing of two aircraft, the vertical view screen may be determined as the main view screen.

In an embodiment, the method further includes determining one of the horizontal view screen and the vertical view screen as an auxiliary view screen based on the identified verti port type, wherein the identified verti port type is the Single- Based on FATO, the vertical view screen is determined as the auxiliary view screen, and based on the identified vertiport type being Multi-FATO, the horizontal view screen is determined as the auxiliary view screen, and the auxiliary view screen is In PIP (Picture In Picture) mode, it can be controlled to be displayed in a pop-up form on one side of the main view screen.

In an embodiment, the information on the user interface screen is about an air traffic flow monitoring screen that includes at least one of information about the current flight speed of the aircraft in flight for each corridor connecting two verti ports and information about the recommended flight speed. May contain information.

In an embodiment, the information on the user interface screen includes information on an air traffic flow monitoring screen that includes information on the late arrival time or early arrival time of the aircraft in flight for each corridor connecting two vertiports. can do.

In an embodiment, the information on the user interface screen is information about the collision protection section for the corridors connecting two verti ports of the Single-FATO (Final Approach and Take-Off area) type, where two aircraft cannot take off and land simultaneously. It may contain information about the air traffic flow monitoring screen that includes.

In an embodiment, the information on the user interface screen includes information about at least one aircraft in flight for each corridor connecting two verti ports, and when one of the at least one aircraft is selected, the selected aircraft is in flight. Information may be transmitted to at least one of the UAM and the external server at the expected arrival time for each preset section within the current corridor.

In an embodiment, the method may further include generating navigation information for configuring a navigation screen mounted on the aircraft based on information collected from the UAM and transmitting the generated navigation information to the corresponding UAM.

In an embodiment, the navigation information may include at least one of information about coordinate values indicating the degree of departure from the course of the aircraft with the center of the corridor in flight as the origin and forward steering control information to prevent departure from the forward course.

storing at least one computer program including instructions that, when executed by at least one processor according to another aspect of the present disclosure, cause the at least one processor to perform operations for managing traffic flow of Urban Air Mobility (UAM); In the non-volatile computer-readable storage medium, the operations include collecting information from the UAM and an external server, analyzing air traffic flow based on the collected information, and analyzing real-time air traffic flow based on the analysis results. It may include generating information on a user interface screen for providing flow information and transmitting the generated information on the user interface screen to at least one of the UAM and the external server.

A server that manages traffic flow of UAM (Urban Air Mobility) according to another aspect of the present disclosure includes a collection unit that collects information from the UAM and an external server, and an analysis unit that analyzes air traffic flow based on the collected information. and a generating unit that generates information on a user interface screen for providing real-time air traffic flow information based on the analysis results, and transmits information on the generated user interface screen to at least one of the UAM and the external server. It may include a transmission unit.

In an embodiment, the information collected from the UAM includes sensor data collected by sensors mounted on the UAM, driving data collected from ECUs (Electric Control Units) mounted on the UAM, and GPS receivers mounted on the UAM. It may include at least one of positioning data.

In an embodiment, the external server is a UAM flight server that provides at least one of flight plan information and real-time operation-related information, and an infrastructure operation server that provides at least one of type information for each port, available information, and real-time capacity information. It may include at least one of a flight support information providing server that provides at least one of corridor design information, information on obstacles and terrain for each corridor, emergency landing site information, base station information, and weather information.

In an embodiment, the information on the user interface screen includes information on a four-dimensional view screen containing at least one of latitude information, longitude information, altitude information, and flight time information of the aircraft in flight for each corridor connecting two vertiports. It can be included.

In an embodiment, the information about the four-dimensional view screen includes information about a horizontal view screen configured to arrange the corridors connecting the two verti ports on a horizontal plane, and information about the four-dimensional view screen configured to arrange the corridors connecting the two verti ports on a vertical plane. May contain information about the configured vertical view screen.

In an embodiment, the analysis unit identifies the two verti port types and determines one of the horizontal view screen and the vertical view screen as the main view screen based on the identified verti port type, wherein the identified verti port Based on the fact that the type is Single-FATO (Final Approach and Take-Off area), where two aircraft cannot take off and land simultaneously, the horizontal view screen is determined as the main view screen, and the identified vertiport type is used for two aircraft. Based on the fact that it is a multi-FATO capable of simultaneous takeoff and landing, the vertical view screen may be determined as the main view screen.

In an embodiment, the analysis unit determines one of the horizontal view screen and the vertical view screen as an auxiliary view screen based on the identified vertiport type, and based on the identified vertiport type being the Single-FATO The vertical view screen is determined to be the auxiliary view screen, the horizontal view screen is determined to be the auxiliary view screen based on the identified vertiport type being Multi-FATO, and the generator is configured to operate in Picture In Picture (PIP) mode. It can be controlled to display the auxiliary view screen in a pop-up form on one side of the main view screen.

In an embodiment, the information on the user interface screen includes information on the air traffic flow monitoring screen including information on the current flight speed of the aircraft in flight for each corridor connecting two verti ports and information on the recommended flight speed. can do.

In an embodiment, the information on the user interface screen includes information on an air traffic flow monitoring screen that includes information on the late arrival time or early arrival time of the aircraft in flight for each corridor connecting two vertiports. can do.

In an embodiment, the information on the user interface screen is information about the collision protection section for the corridors connecting two verti ports of the Single-FATO (Final Approach and Take-Off area) type, where two aircraft cannot take off and land simultaneously. It may contain information about the air traffic flow monitoring screen that includes.

In an embodiment, the information on the user interface screen includes information about at least one aircraft in flight for each corridor connecting two verti ports, and when one of the at least one aircraft is selected, the selected aircraft is in flight. Information can be controlled to be transmitted to at least one of the UAM and the external server at the expected arrival time for each preset section within the current corridor.

In an embodiment, the generating unit may generate navigation information for configuring a navigation screen mounted on the aircraft based on information collected from the UAM, and the transmitting unit may transmit the generated navigation information to the corresponding UAM.

In an embodiment, the navigation information may include at least one of information about coordinate values indicating the degree of departure from the course of the aircraft with the center of the corridor in flight as the origin and forward steering control information to prevent departure from the forward course.

A method performed by urban air mobility linked to a server through a communication network according to another embodiment of the present disclosure includes the steps of transmitting data collected from sensors and electronic control units provided during flight to the server through the communication network; Receiving information on a user interface screen displaying a real-time air traffic flow from the server and outputting a screen generated based on the received information on the user interface screen to a display provided, the user interface The information about the screen may include information about a four-dimensional view screen that displays at least one of latitude information, longitude information, altitude information, and flight time information of an aircraft in flight for each corridor connecting two vertiports.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

Embodiments of the present disclosure have the advantage of providing a traffic flow management method for urban air mobility and devices and systems therefor.

Additionally, embodiments of the present disclosure have the advantage of providing a UAM traffic management system that can safely and efficiently manage and control the traffic flow of urban air mobility.

In addition, embodiments of the present disclosure provide urban air mobility that can prevent flight delays in advance and efficiently manage early arrival by monitoring the status of flight delays compared to the flight plan in real time and providing intuitive flight guidance information to the relevant operator and pilot. There is an advantage in providing a traffic flow management method and devices and systems for the same.

In addition, embodiments of the present disclosure have the advantage of providing a traffic flow management method for urban air mobility, and devices and systems therefor, capable of minimizing traffic congestion and resulting cost losses at Vertiport due to flight delays and early arrivals. There is.

In addition, embodiments of the present disclosure monitor the real-time operation status of the aircraft in the corridor based on sensing data collected from the aircraft, calculate the optimal operation speed and operation route for the aircraft, and calculate the optimal operation speed and operation route for the aircraft. It has the advantage of providing a UAM traffic management system that can configure routes on an intuitive user interface screen and provide them to the relevant operator and/or pilot.

In addition, various effects that can be directly or indirectly identified through this document may be provided.

The drawings attached to this specification are intended to provide an understanding of the present invention, show various embodiments of the present invention, and together with the description of the specification, explain the principles of the present invention.
Figure 1 is a diagram for explaining the overall network structure for providing UAM services according to an embodiment.
Figure 2 is a diagram for explaining a method of providing information by a UAM traffic management server according to an embodiment.
Figure 3 is a diagram for explaining a method of providing information by a UAM traffic management server according to another embodiment.
Figure 4 is a diagram for explaining a strategic/tactical collision prevention method in the UAM traffic management server according to an embodiment of the present disclosure.
Figure 5 is an example of an aircraft flight screen within a corridor and a navigation screen for aircraft mounting according to an embodiment of the present disclosure.
Figure 6 is a flowchart illustrating a method of providing air traffic flow information in the UAM traffic management server according to an embodiment of the present disclosure.
Figure 7 is a flowchart illustrating a method of providing air traffic flow information in a UAM traffic management server according to another embodiment of the present disclosure.
Figure 8 is a block diagram for explaining the configuration of UAM according to an embodiment of the present disclosure.
Figure 9 is a block diagram for explaining the configuration of a UAM traffic management server according to an embodiment of the present disclosure.

Hereinafter, some embodiments of the present invention will be described in detail through illustrative drawings. When adding reference numerals to components in each drawing, it should be noted that identical components are given the same reference numerals as much as possible even if they are shown in different drawings. Additionally, when describing embodiments of the present invention, if detailed descriptions of related known configurations or functions are judged to impede understanding of the embodiments of the present invention, the detailed descriptions will be omitted.

In describing the components of the embodiments of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, sequence, or order of the component is not limited by the term. Additionally, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by a person of ordinary skill in the technical field to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and should not be interpreted in an ideal or excessively formal sense unless explicitly defined in the present application. No.

In various examples of this disclosure, “/” and “,” should be interpreted as indicating “and/or.” For example, “A/B” can mean “A and/or B.” Furthermore, “A, B” may mean “A and/or B.” Furthermore, “A/B/C” may mean “at least one of A, B and/or C.” Furthermore, “A, B, C” may mean “at least one of A, B and/or C.”

In various examples of this disclosure, “or” should be interpreted as indicating “and/or.” For example, “A or B” may include “only A,” “only B,” and/or “both A and B.” In other words, “or” should be interpreted as indicating “additionally or alternatively.”

Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 1 to 9.

Figure 1 is a diagram for explaining the overall network structure for providing UAM services according to an embodiment.

Referring to FIG. 1, the UAM service network 100 largely includes a UAM air base 10, a UAM navigation server 20, a UAM traffic management server 30, an infrastructure operation server 40, a navigation information provision server 50, and It may be configured to include a communication network 60.

The UAM fleet 10 may be configured to include at least one UAM aircraft managed by each UAM operating company. UAM aircraft can exchange information with other UAM aircraft through V2V (Vehicle to Vehicle) communication.

At least one of the UAM air base 10, UAM flight server 20, UAM traffic management server 30, infrastructure operation server 40, and flight information provision server 50 exchanges various information with each other through the communication network 60. and can transmit and receive control signals.

As an example, the communication network 60 may be configured to include a wireless communication network and a wired communication network.

As an example, a wireless communication network may include a mobile communication network and/or a satellite network.

A wireless communication network may be a multiple access system that supports communication with multiple users by sharing available system resources (eg, bandwidth, transmission power, etc.). Examples of multiple access systems include code division multiple access (CDMA) systems, frequency division multiple access (FDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single carrier frequency (SC-FDMA) systems. division multiple access) system, MC-FDMA (multi carrier frequency division multiple access) system, etc.

CDMA can be implemented with wireless technologies such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented with wireless technology standards such as global system for mobile communications (GSM)/general packet radio service (GPRS)/enhanced data rates for GSM evolution (EDGE). OFDMA can be implemented with wireless technology standards such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), etc. IEEE 802.16m is an evolution of IEEE 802.16e and provides backward compatibility with systems based on IEEE 802.16e. UTRA is part of the universal mobile telecommunications system (UMTS). 3GPP (3rd generation partnership project) LTE (long term evolution) is a part of E-UMTS (evolved UMTS) that uses E-UTRA (evolved-UMTS terrestrial radio access), employing OFDMA in the downlink and SC in the uplink. -Adopt FDMA. LTE-A (advanced) is the evolution of 3GPP LTE. 5G NR is a successor technology to LTE-A and is a new clean-slate mobile communication system with characteristics such as high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, including low-frequency bands below 1 GHz, mid-frequency bands between 1 GHz and 10 GHz, and high-frequency (millimeter wave) bands above 24 GHz.

Urban air mobility is equipped with a Global Positioning System (GPS) receiver and can receive and decode GPS satellite signals. Urban air mobility can obtain current GPS coordinate information from GPS satellite signals and provide it to other nearby urban air mobility and/or external servers through an equipped communication terminal.

V2X refers to a communication technology that exchanges information with other UAMs, pedestrians including passengers and pilots, objects built as infrastructure (e.g., verti ports), and network devices (e.g., base stations, etc.). V2X refers to vehicle-to-vehicle (V2V) for communication between UAMs, vehicle-to-infrastructure (V2I) for communication between UAMs and infrastructure, and vehicle-to-network (V2N) for communication between UAMs and communication networks. and V2P (vehicle-to-pedestrian) for communication between UAM and passengers and/or pilots. V2X communication may be provided through the PC5 interface and/or the Uu interface.

Sidelink (SL) refers to establishing a direct wireless link between communication terminals mounted on urban air mobility, enabling access to the city without going through a base station (BS) or infrastructure - for example, a Road Side Unit (RSU). It refers to a communication method that allows information to be exchanged directly between air mobility. SL can be considered as a method that can not only alleviate the burden on the base station due to rapidly increasing data traffic, but also minimize transmission delay when communicating between urban air mobility.

The UAM navigation server 20 manages the UAM fleet 10 and can provide services related to security and passenger safety.

The UAM navigation server 20 can establish a flight plan for each UAM aircraft according to the user's reservation, and provide the established flight plan and real-time operation-related information to the UAM traffic management server 30.

The UAM traffic management server 30 may perform approval and adjustment procedures for the flight plan submitted by the UAM navigation server 20.

The UAM flight server 20 prepares a flight plan including aircraft information, captain information, information on departure and arrival times, information on departure and arrival ports, passenger information, and logistics information before the flight, and prepares the UAM traffic management server. It can be sent to (30).

If the submitted flight plan is acceptable, the UAM traffic management server 30 may reserve takeoff and landing times at the origin and destination vertiports, and reserve a corridor connecting the origin vertiport and the destination vertiport.

The UAM traffic management server 30 can sequentially approve and manage flight plans according to the order of submission or flight time, and rejects requests for duplicate reservations for already-booked flight plans, thereby strategically starting from the flight plan establishment stage. Conflict management can be performed.

In addition, the UAM traffic management server 30 generates real-time air traffic flow and emergency events through collaboration with the UAM aircraft, external servers, and/or other control centers during flight - for example, obstacle detection, unauthorized aircraft detection, and weather. Deterioration, lack of remaining aircraft battery power, etc. can be monitored in real time. The UAM traffic management server 30 may perform tactical collision management to prevent accidents such as collisions between aircraft based on real-time air traffic flow monitoring results and/or event detection results.

If the flight plan submitted by the UAM navigation server 20 is acceptable as is, the UAM traffic management server 30 may transmit a flight plan acceptance message indicating that the flight plan has been successfully accepted to the UAM navigation server 20.

If the flight plan submitted by the UAM navigation server 20 is not acceptable, the UAM traffic management server 30 may transmit a flight plan rejection message including a reason for rejection to the UAM navigation server 20.

If the flight plan submitted by the UAM navigation server 20 requires adjustment, the UAM traffic management server 30 may transmit a flight plan adjustment request message containing adjustment details to the UAM navigation server 20. If the flight plan submitted by the UAM navigation server 20 requires adjustment, the UAM traffic management server 30 according to the embodiment creates a recommended flight plan based on various information already collected, and creates the recommended flight plan. This included flight plan adjustment request message may be transmitted to the UAM flight server 20.

The UAM traffic management server 30 may collect flight safety information corresponding to the flight plan and provide the collected flight safety information to the UAM flight server 20. For example, operational safety information includes obstacle and terrain information, weather information, noise limit information, various accident and event information, information on congestion including port availability information and real-time capacity, real-time corridor operation status information, restricted airspace information, etc. It may include, but is not limited to this.

The UAM traffic management server 30 can control the takeoff and landing of the UAM aircraft and the overall aircraft operation status for each corridor.

The infrastructure operation server 40 provides at least one of information about the type of port for each port, real-time port availability information, and information about real-time capacity changes for each port to the UAM navigation server 20 and/or the UAM traffic management server 30. It can provide information on the status of verti port operation, including.

The UAM operation server 20 and/or the UAM traffic management server 30 may monitor real-time gas capacity changes as well as the real-time availability status of the corresponding port based on information received from the infrastructure operation server 40.

The UAM traffic management server 30 can monitor real-time flight information for each aircraft within the corridor and calculate the expected arrival time and/or expected departure time for each aircraft. The UAM traffic management server 30 may provide information about the calculated expected arrival time and/or expected departure time to the infrastructure operation server 40.

The UAM traffic management server 30 can monitor in real time whether an emergency condition occurs for the port and/or corridor and/or individual aircraft. For example, an emergency state may be a port exceeding capacity event, an unsecured corridor safety distance event, a corridor (or route) deviation event, a delayed arrival event, a delayed departure event, a collision expected event, a communication loss event, a bad weather event, and a restricted airspace flight. This may include, but is not limited to, an event, an aircraft failure event, or an emergency charging event indicating that emergency charging is required due to insufficient battery power.

When the UAM traffic management server 30 detects the occurrence of an emergency state, it provides information to the UAM navigation server 20 and/or the infrastructure operation server 40 and/or the respective individual through a predefined control communication network according to the detected emergency state event type. A predetermined warning alarm message can be sent to the aircraft. Here, the warning alarm message may include information on how to take action against the emergency state.

The infrastructure operation server 40 can manage Verti Port ground operations and monitor the Verti Port area to manage the security and safety of Verti Port.

The infrastructure operation server 40 can monitor the real-time congestion and availability status of the port. Additionally, the infrastructure operation server 40 may receive information about the flight plan and air mass operation plan from the UAM operation server 20, and receive real-time flight status information for each corridor from the UAM traffic management server 30.

The infrastructure operation server 40 can adaptively control takeoff and landing of the aircraft at the corresponding vertiport based on the current vertiport operation status, flight plan for each vertiport, and real-time flight status information.

The flight support information provision server 50 provides at least one of corridor design information, information about obstacles and terrain for each corridor, information about emergency landing sites, information about base stations, and weather information to the UAM traffic management server 30 and/or UAM. It can be provided to the navigation server 20.

The UAM traffic management server 30 according to the embodiment can collect sensor data collected from various sensors installed on the aircraft in real time through a wireless network. The UAM traffic management server 30 can estimate and determine the flight status of the aircraft through learning based on sensor data collected from the aircraft. As an example, the sensor data may include at least one of image data captured by a camera, positioning data, speed data, acceleration data, flight trajectory data, remaining battery level data, and flight altitude data, but is not limited thereto.

In an embodiment, a camera mounted on urban air mobility may include at least one of a thermal imaging camera, a night vision camera equipped with an infrared sensor, and a Surround View Monitor (SVM) camera.

Images captured by cameras mounted on urban air mobility can be input to a deep learning-based semantic segmentation network, and the deep learning-based semantic segmentation network learns to detect obstacles ahead, Other nearby aircraft, virtual corridors, weather conditions, etc. can be identified. As an example, the UAM traffic management server 30 may receive image data captured by the aircraft, and learn from the received image data to extract various characteristic information for estimating the current flight state of the aircraft.

Additionally, the UAM traffic management server 30 can estimate the arrival delay time or early arrival time to the destination through learning based on sensor data received from the aircraft.

In addition, the UAM traffic management server 30 can estimate the flight status of the aircraft within the corridor through learning based on sensor data received from the aircraft, and determine whether and the extent of the aircraft deviating from the route based on the estimation results. .

Additionally, the UAM traffic management server 30 can estimate the expected flight trajectory of the aircraft within the corridor through learning based on sensor data received from the aircraft.

The UAM traffic management server 30 may calculate the error of the expected flight trajectory from the center of the corridor.

The UAM traffic management server 30 may transmit information about the trajectory error calculated based on the expected flight trajectory within the corridor to the corresponding aircraft.

The aircraft can construct a navigation screen displaying the calculated trajectory error and display it on the provided screen. At this time, the navigation screen may include predetermined navigation guidance information that guides the aircraft to follow the central axis of the corridor without deviating from the designated route (i.e., corridor).

In the case of a verti port that shares a landing zone and a takeoff zone, the UAM traffic management server 30 can control aircraft to land and take off from the corresponding verti port so that they are not dispatched within a specific time window.

In other words, the UAM traffic management server 30 detects collisions between aircraft in a single FATO (Final Approach and Take-Off) area environment, which means a situation in which two aircraft cannot take off and land at the same time at the corresponding vertiport. To prevent this, takeoff and landing can be scheduled to occur sequentially at certain time intervals. For example, the UAM traffic management server 30 can adaptively control the operation of two aircraft attempting takeoff and landing at a vertiport in a single FATO environment so that they attempt takeoff and landing at least 5 minutes apart.

The UAM traffic management server 30 can adaptively control the operating speed of the two aircraft so that the distance between the two aircraft flying on the same corridor is maintained at a certain distance or more - that is, a predetermined safe distance can be secured. .

The UAM traffic management server 30 determines a recommended flight speed by considering the current location and current flight speed of each aircraft, and provides information about the determined recommended flight speed to the aircraft, so that the aircraft arrives late or arrives early at the destination. You can prevent it from happening.

The UAM traffic management server 30 may adaptively adjust the flight plan by considering at least one of port availability and current weather conditions. The UAM traffic management server 30 may provide information about the adjusted flight plan to the UAM navigation server 20.

The UAM traffic management server 30 can diagnose aircraft failure based on sensor data received from the aircraft, and provides a predetermined warning alarm to other aircraft flying around the aircraft in which the aircraft defect is detected based on the failure diagnosis results. Alternatively, a predetermined warning alarm may be sent to the UAM operation server 20 to temporarily restrict flights to the relevant flight area and/or corridor and/or port.

The UAM navigation server 20 according to the embodiment may identify flight areas and/or corridors and/or ports where flights are not possible based on the warning alarm received from the UAM traffic management server 30, and then the scheduled flight. You can select a detour route for the schedule and dispatch it.

The UAM traffic management server 30 can detect an aircraft in an emergency situation based on sensor data collected from at least one aircraft, and can control the aircraft for which an emergency situation has been detected to land safely at a nearby emergency landing site. It may be possible. For example, when an emergency situation occurs, control of the aircraft may be transferred from the pilot of the aircraft (i.e., modified driving mode) to the UAM traffic management server 30 and converted to remote control mode.

The remote operator of the remote control center connected to the UAM traffic management server 30 can remotely control the aircraft and guide the aircraft to the nearest available emergency landing site while monitoring real-time images captured by the aircraft.

For example, an emergency situation may include not only a failure situation due to an aircraft defect, but also a situation with insufficient remaining battery power and a situation in bad weather.

The UAM traffic management server 30 may provide information on various view screens or view screens about the corridors connecting two vertiports related to the flight of the aircraft according to the user's menu selection (e.g., the pilot). You can.

As an example, the view screen may include a vertical view screen and a horizontal view screen, and may include a main view screen and a secondary view screen depending on the type of the corresponding verti port(s) and/or the design of the corridors disposed between the two verti ports. This can be determined adaptively.

For example, if the two vertiports related to the flight of the aircraft are Single FOTA types, the horizontal view screen may be determined as the main view screen, and the vertical view screen may be determined as the auxiliary view screen. On the other hand, if the two verti ports related to the flight of the aircraft are of the Multi FOTA type that allows for takeoff and landing of two aircraft at the same time, the vertical view screen may be determined as the main view screen, and the horizontal view screen may be determined as the auxiliary view screen.

As another example, if the two vertiports related to the flight of the aircraft are Single FOTA types, the vertical view screen may be determined as the main view screen, and the horizontal view screen may be determined as the auxiliary view screen. On the other hand, if the two vertiports related to the flight of the aircraft are Multi FOTA types that allow for takeoff and landing of two aircraft at the same time, after takeoff and landing are separated, the horizontal view screen is determined as the main view screen, and the vertical view screen is determined as the auxiliary view screen. You can.

In an embodiment, the auxiliary view screen may be displayed in a pop-up form on one side of the main view screen - that is, the navigation screen - in Picture in Picture (PIP) mode.

Figure 2 is a diagram for explaining a method of providing information by a UAM traffic management server according to an embodiment.

In detail, Figure 2 is an example of a view screen displaying real-time flight status information for each corridor designed between two verti ports.

Referring to FIG. 2, at least one corridor connecting the first verti port 210 and the second verti port 220 may be designed. In the embodiment of Figure 2, it is assumed that the flight time for each corridor is designed to be 30 minutes, and the types of the first verti port 210 and the second verti port 220 are both assumed to be Single FOTA type.

As shown in FIG. 2, the main view screen may display the location within the corridor of the aircraft currently in flight and the flight direction of the aircraft.

A predetermined ID (Identity) for each corridor may be predefined and assigned, and the corridor ID within the corresponding UAM service network may be uniquely assigned.

Referring to FIG. 2, the first corridor 201 is a flight path moving from the second vertiport 220 to the first vertiport 210, and is assigned a unique ID of 78563411, and the second corridor 202 is It is a flight path moving from the first verti port 210 to the first verti port 220, and shows that a unique ID of 12345678 is assigned. UAM 2 and UAM 3 are in flight in the first corridor (201), and UAM 1 is in flight in the second corridor (202).

As shown in Figure 2, objects displayed on the main view screen can be mapped on a map and configured as a four-dimensional image with latitude/longitude/altitude/time information displayed.

When one of the aircraft displayed on the main view screen is selected, information about the expected arrival time for each predefined location within the corridor in which the selected aircraft is flying can be intuitively displayed on one side of the corridor.

When UAM 1 flying in the second corridor 202 is selected by the user, the expected arrival time for each location in the second corridor 202 may be displayed.

The main view screen can be configured based on a map, and the locations of the base station 250 and emergency landing site 240 can be mapped and displayed on the map.

An auxiliary view screen 230 may be configured and displayed in a pop-up form on one side of the main view screen.

As shown in FIG. 2, when the main view screen is a horizontal view screen, the auxiliary view screen 230 may be configured as a vertical view screen. On the other hand, when the main view screen is a vertical view screen, the auxiliary view screen 230 may be configured as a horizontal view screen.

In an embodiment, the main view screen may be changed according to the user's selection of a certain menu, but this is only one embodiment, and the type of the main view screen may be automatically determined depending on the type of the target verti port.

Information about the flight status may be displayed on one side of the aircraft on the main view screen. For example, the flight state is a take-off state indicating a state in preparation for takeoff, a climb state in which the altitude is increased after takeoff, a cruise state in which the flight is maintained at a certain altitude, and an altitude. It can be divided into a descent state in which the aircraft is descending, an approach state in which it is approaching the verti port, and a landing state in which the landing has been completed.

On one side of the main view screen, the current location information of the aircraft - for example, information such as latitude/longitude/altitude - may be further displayed. Of course, the base station 250 may further display location information about the emergency landing site 240 and the vertiports 210 and 220 - for example, information such as latitude/longitude/altitude. Additionally, the main view screen may further display information about the length/width and altitude of each corridor. Additionally, the main view screen may further display information about the separation distance between corridors.

Additionally, the main view screen may display information about the number of aircraft in flight for each corridor and information about the average separation distance for each aircraft.

Additionally, the main view screen may display additional information that can identify the aircraft you are operating.

Additionally, the main view screen may further display information that can identify the aircraft in which an emergency situation has been detected.

Additionally, the main view screen may further display information about the number of aircraft waiting to fly for each vertiport and the number of available takeoff and landing ports.

Additionally, the main view screen may further display information about the current flight speed and recommended flight speed for each aircraft in flight.

Depending on the user's menu selection, the main view screen may be switched to the air traffic flow monitoring screen of FIG. 4, which will be described later, or the flight navigation screen, of FIG. 5, which will be described later.

Figure 3 is a diagram for explaining a method of providing information by a UAM traffic management server according to another embodiment.

In detail, Figure 3 is an example of a vertical view screen provided by the UAM traffic management server 30.

Referring to FIG. 3, at least one corridor connecting the first verti port 310 and the second verti port 320 may be designed. In the embodiment of Figure 3, it is assumed that the flight time for each corridor is designed to be 30 minutes, and the types of the first verti port 310 and the third verti port 320 are both assumed to be Single FOTA type.

As shown in FIG. 3, the main view screen may display the location within the corridor of the aircraft currently in flight and the flight direction of the aircraft.

A predetermined ID (Identity) for each corridor may be predefined and assigned, and the corridor ID within the corresponding UAM service network may be uniquely assigned.

Referring to FIG. 3, the first corridor 370 is a flight path for an aircraft moving from the second verti port 320 to the first verti port 310, and is assigned a unique ID of 78563411, and the second corridor ( 380) is the flight path of the aircraft moving from the first vertiport 310 to the first vertiport 320, and shows that a unique ID of 12345678 is assigned. The first corridor 370 shows UAM 2, UAM 3, and UAM 4 in flight, and the second corridor 380 shows UAM 1 in flight.

As shown in FIG. 3, objects displayed on the main view screen can be mapped on a map and configured as a 4-dimensional image showing not only the latitude/longitude/altitude of the aircraft but also the arrival time information of the selected aircraft at the corresponding point.

When one of the aircraft displayed on the main view screen is selected, information about the expected arrival time for each predefined location within the corridor in which the selected aircraft is flying can be intuitively displayed on one side of the corridor.

Referring to FIG. 3, when UAM 1 flying in the second corridor 380 is selected by the user, the expected arrival time for each predetermined location within the second corridor 380 flight path may be displayed as shown in drawing number 360. . Additionally, information about the remaining flight time to the destination for the aircraft selected by the user may be displayed.

The main view screen can be configured based on a map, and the latitude/longitude/altitude of aircraft flying in the corridor, base station 250, emergency landing site 240, and verti ports 310 and 320 are mapped on the map. can be displayed.

An auxiliary view screen 330 may be configured and displayed in a pop-up form on one side of the main view screen.

As shown in FIG. 3, when the main view screen is a vertical view screen, the auxiliary view screen 330 may be configured as a horizontal view screen. On the other hand, when the main view screen is a horizontal view screen, the auxiliary view screen may be configured as a vertical view screen, as shown in FIG. 2 above.

If the auxiliary view screen 330 is a horizontal view screen, information for identifying the direction of movement of each aircraft may be displayed. For example, as shown in drawing number 330, the movement direction of each aircraft can be identified by displaying different colors depending on the movement direction of the aircraft.

In an embodiment, the main view screen may be changed according to the user's selection of a certain menu, but this is only one embodiment, and the type of the main view screen may be automatically determined depending on the type of the target vertiport.

Information about the flight status may be displayed on one side of the aircraft displayed on the main view screen. For example, the flight state is a take-off state indicating a state in preparation for takeoff, a climb state in which the altitude is increased after takeoff, a cruise state in which the flight is maintained at a certain altitude, and an altitude. It can be divided into a descent state in which the aircraft is descending, an approach state in which it is approaching the verti port, and a landing state in which the landing has been completed.

On one side of the aircraft displayed on the main view screen, additional information may be displayed on the aircraft's current flight speed and recommended flight speed. Additionally, the main view screen may further display information about the length/width/height of each corridor. Additionally, the main view screen may further display information about the separation distance between corridors.

Additionally, the main view screen may further display information about the number of aircraft in flight for each corridor and information about the average separation distance for each aircraft.

Additionally, the main view screen may further display information that can identify the aircraft the user is operating, as shown in drawing number 390.

Additionally, the main view screen may further display information that can identify the aircraft in which an emergency situation has been detected, as shown in drawing number 395.

Additionally, the main view screen may further display information about the number of aircraft waiting to fly for each vertiport and the number of available takeoff and landing ports.

Depending on the user's menu selection, the main view screen may be converted to the air traffic flow monitoring screen of FIG. 4, which will be described later, or the in-aircraft flight navigation screen, of FIG. 5, which will be described later.

Figure 4 is a diagram for explaining a strategic/tactical collision prevention method in the UAM traffic management server according to an embodiment of the present disclosure.

In a Single FATO environment, two aircraft cannot be dispatched for takeoff and landing at the same time to prevent collisions between aircraft. In order to solve the problem of collision between aircraft that may occur due to the above-mentioned limitations in the Single FATO environment, the UAM traffic management server 30 monitors air traffic flow for each corridor in real time and provides various information to prevent strategic/tactical collisions. It may be generated and the generated information may be provided to at least one of the corresponding aircraft, the UAM operation server 20, and the infrastructure operation server 40.

The UAM traffic management server 30 according to the embodiment may provide information on the air traffic flow monitoring screen or air traffic flow monitoring screen according to the user's request.

Figure 4 shows that the flight time for each corridor between Vertiport 1 (VP-1) and Vertiport 2 (VP-2), which provides a Single FATO environment, is designed to be 30 minutes by the UAM traffic management server 30. This is an example of the generated air traffic flow monitoring screen 400.

Referring to FIG. 4, the air traffic flow monitoring screen 400 displays information on the current flight speed of each aircraft flying in each corridor, as shown in drawing number 410, in order to intuitively show the air traffic flow for each corridor. and information about recommended flight speeds may be displayed.

In addition, as shown in drawing number 440, the air traffic flow monitoring screen 400 may display the estimated arrival time compared to the flight plan as + (late arrival)/- (early arrival), and the user can determine whether the aircraft is flying. You can intuitively check to what extent your arrival will be delayed or early compared to your plan.

As described above, information on the recommended flight speed for each aircraft and the status of delays compared to the flight plan can be provided to the pilot and/or UAM operator in real time through the air traffic flow monitoring screen 400, so the pilot and/or UAM operator can You can quickly determine how much the aircraft's flight speed needs to be adjusted compared to the flight plan. As a result, the air traffic flow monitoring screen 400 can be used as an auxiliary means to accurately and safely fly to the destination according to the flight plan.

In addition, the air traffic flow monitoring screen 400 displays a predetermined collision screen as shown in drawing numbers 420 and 430 so that the movement lines of the aircraft do not overlap in the takeoff and landing sections in order to strategically/tactically prevent collisions between aircraft. A protection section may be displayed. Referring to drawing numbers 420 and 430, a collision protection section may be set in the takeoff and landing section of Bertie Port 1 and the takeoff and landing section of Bertie Port 2.

In Figure 4, the collision protection section may be set to 5 minutes after takeoff and 5 minutes before landing of the aircraft on the corresponding vertiport, but this is only an example and may be set differently depending on the design of a person skilled in the art. Within the collision protection zone, it must be managed to prevent two aircraft from taking off and landing at the same time.

When the UAM traffic management server 30 according to the embodiment is expected to simultaneously take off and land within the collision protection section through air traffic flow monitoring, the corresponding aircraft and/or the UAM navigation server 20 and/or the infrastructure operation server ( By sending a predetermined warning alarm to 40), only one aircraft within the collision protection section can be controlled to attempt takeoff or landing.

In the above embodiment, it is explained that the collision protection section is set at the takeoff and landing time of the aircraft for each vertiport, but this is only one embodiment, and the collision protection section according to another embodiment is other than the takeoff and landing time. It can also be set in the flight section. In an embodiment, the length of the collision protection section set at the time of takeoff and landing - hereinafter, the length of the first collision protection relief section - and the length of the collision protection section set at other flight sections other than the time of takeoff and landing - hereinafter, the second collision protection section. The guard interval length can be set differently. For example, the length of the first collision protection section may be set to be longer than the length of the second collision protection section.

Figure 5 is an example of an aircraft flight screen within a corridor and a navigation screen for aircraft mounting according to an embodiment of the present disclosure.

Drawing number 510 is an example of an aircraft flight screen within a corridor consisting of a three-dimensional screen showing the real-time flight status of the aircraft within the corridor. The center movement line 511 of the corridor is displayed on the aircraft flight screen 510 within the corridor, so that it is possible to intuitively check whether the aircraft is flying along the center of the corridor.

Drawing number 520 is an example of a navigation screen for aircraft mounting.

As shown in drawing number 521, the aircraft-mounted navigation screen 520 displays information on the ID of the corridor in which the aircraft is currently flying and indicates how far the aircraft is flying away from the center of the corridor so that the aircraft does not deviate from the route of the corridor. Information about the coordinate values (x, y) may be displayed. Here, the center of the corridor has a coordinate value of (0,0), and if the x value is a positive number, it means that the aircraft is flying at a distance of x to the right from the center of the corridor. If the x value is negative, the aircraft is flying in the corridor. This means that it is flying at an absolute value of x-, that is, |x|- to the left from the center. If the y value is a positive number, it means that the aircraft is flying upward by an amount y spaced from the center of the corridor. If the y value is a negative number, the aircraft is spaced downward by an absolute value y - that is, |y|- - from the center of the corridor. It means that it is in flight.

Additionally, forward steering control information 522 to prevent the aircraft from deviating from its course may be displayed on the aircraft-mounted navigation screen 520. As an example, the forward steering control information 522 may include information about how many meters ahead, in which direction, and by how many degrees the pilot should perform steering control. If a situation arises where the aircraft must take a 60-degree curve while flying at a speed of 300 km/h, the possibility of deviating from the route may increase. To prevent this, the UAM traffic management server 30 according to the present disclosure provides forward steering control information 522 to the operator and/or pilot (pilot), thereby preventing the aircraft from deviating from the route.

Additionally, the aircraft-mounted navigation screen 520 may further display warning alarm information (not shown). As an example, the warning alarm information includes information indicating that another aircraft is flying a few meters ahead, information indicating that a collision protection zone has been entered, information indicating that the distance between aircraft has entered a preset threshold distance for collision protection, It may include at least one of information indicating that an aircraft defect has occurred, information indicating that the degree of route deviation has exceeded a predetermined threshold level, and information indicating that the route change standard deviation value for unit time has exceeded a predetermined threshold value. there is. Here, the route change standard deviation value can be used as an indicator for evaluating the pilot's careless driving. That is, when unsafe flight of the aircraft is detected due to the pilot's careless driving or changes in air currents, a corresponding warning alarm may be displayed on one side of the aircraft navigation screen 520.

Figure 6 is a flowchart illustrating a method of providing air traffic flow information in the UAM traffic management server according to an embodiment of the present disclosure.

Referring to FIG. 6, the UAM traffic management server 30 can collect various information from the UAM aircraft and external servers (S610). Here, information collected from the UAM aircraft may include data collected by various sensors provided on the UAM aircraft.

As an example, UAM sensor data may include at least one of GPS information, information about flight speed and altitude, camera captured image data, and information about remaining battery capacity, but is not limited thereto.

The external server may include at least one of the above-described UAM navigation server 20, the infrastructure operation server 40, and the navigation support information provision server 50, but this is only one embodiment and is not used for UAM traffic flow analysis. Servers that provide other necessary information may be added.

As an example, information collected from external servers includes information on UAM flight plans, information on air mass operation plans, information on corridor design, information on vertiport availability and real-time capacity changes, weather information, obstacles and terrain information for each corridor. , It may include at least one of information about the location of base stations around the corridor, emergency landing site information, information about operation restrictions, restricted airspace information, and information about communication channels for emergency control.

The UAM traffic management server 30 can analyze the UAM traffic flow based on the collected information (S620). As an example, the UAM traffic management server 30 can generate various data to safely and smoothly manage the traffic flow by analyzing the UAM traffic flow.

The UAM traffic management server 30 may generate a user interface screen or information about a user interface screen for controlling smooth air traffic flow based on the UAM traffic flow analysis results (S630). As an example, information about the user interface screen may include information about various view screens described in FIGS. 2 and 3 and information about the air traffic flow monitoring screen described in FIG. 4 .

The UAM traffic management server 30 may transmit the generated user interface screen or information about the user interface screen to the corresponding UAM aircraft and/or an external server (S640).

Figure 7 is a flowchart illustrating a method of providing air traffic flow information in a UAM traffic management server according to another embodiment of the present disclosure.

In detail, FIG. 7 is a flowchart illustrating a method of providing information for configuring a navigation screen mounted on a UAM aircraft from the UAM traffic management server to the corresponding UAM aircraft.

Referring to FIG. 7, the UAM traffic management server 30 can collect information from the UAM aircraft currently in flight and an external server (S710). Here, the information collected from the UAM aircraft and external server is replaced with the description of the above-mentioned drawings.

The UAM traffic management server 30 can analyze the collected information and analyze the real-time flight status for each UAM aircraft (S720). Here, the information analyzed may include, but is not limited to, whether or not the current route is deviated and the direction, whether or not a warning alarm event occurs and the warning alarm type, and the possibility of deviating from the forward route.

The UAM traffic management server 30 can generate information for configuring the navigation screen within the aircraft based on the results of real-time flight status analysis for each UAM aircraft (S730). Here, the generated information may include at least one of information about coordinate values indicating a state of departure from the route, forward steering control information to prevent departure from the route ahead, and warning alarm event information.

The UAM traffic management server 30 may transmit the generated information to the corresponding UAM aircraft (S740). The UAM aircraft can configure the navigation screen of FIG. 5 described above based on information received from the UAM traffic management server 30 and output it on the provided display screen.

Figure 8 is a block diagram for explaining the configuration of UAM according to an embodiment of the present disclosure.

Referring to FIG. 8, the UAM 800 includes a controller 8010, a sensor 820, a GPS receiver 830, a communication terminal 840, a navigation system 845, an output device 850, and an electronic control device. It may be configured to include at least one of Electric Control Units (860), a memory (870), a charging device (880), and a battery (890).

The controller 810 can control the overall operation and input/output of the UAM 800.

The controller 810 may obtain real-time sensing data from the sensor 820 and transmit the obtained sensing data to the UAM traffic management server 30.

Additionally, the controller 810 may obtain real-time driving data from the ECUs 860 and transmit the obtained driving data to the UAM traffic management server 30.

The sensor 820 may include, but is not limited to, a camera 821, an ultrasonic detection sensor 822, a lidar (823), a radar (824), etc., and is not limited to SPAS (Smart Parking Assistance System). ) It may further include at least one of a sensor, an infrared sensor, and an inertial measurement sensor. The camera 821 according to the embodiment may include a front camera for capturing distant images and an SVM camera for capturing images around the aircraft. Here, the SVM camera may include at least one of a front camera, left/right side cameras, rear camera, and downward camera.

The controller 810 can collect various sensing information and status information from the lower module through the UAM internal communication network, and when specific control is required based on the sensing information and status information, it can transmit a control command to the corresponding lower module. Here, the lower module may include, but is not limited to, a sensor 820, a communication terminal 840, an output device 850, ECUs 860, and a charging device 880.

Here, the UAM internal communication network may include, but is not limited to, CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, and MOST (Media Oriented Systems Transport) communication network.

The controller 810, through the communication terminal 840, uses a user terminal (not shown), other UAM, UAM navigation server 20, UAM traffic management server 30, infrastructure operation server 40, and navigation support information provision server ( 50) can communicate with at least one of the following.

The communication terminal 840 includes a first communication module for connection to a 4G/5G commercial mobile communication network, a second communication module for short-range wireless communication, a third communication module for connection to an aviation voice communication network, and a third communication module for RF communication. At least one of three communication modules and a fourth communication module for emergency control communication may be installed. As an example, the communication terminal 840 uses at least one of the first to fourth communication modules to connect a user device, a UAM traffic management server 30, a communication terminal of another urban air mobility, an emergency landing site, a UAM navigation server 20, Communication may be performed with at least one of the infrastructure operation server 40 and the navigation support information provision server 50.

The navigation system 845 may create a navigation screen based on information received from the UAM traffic management server 30.

The output device 850 may include a display, speaker, vibration module, etc.

The output device 850 may output a screen generated by the navigation system 845. Additionally, the output device 850 may configure a screen based on information about the user interface screen for air traffic flow monitoring received from the UAM traffic management server 30 and output the configured screen through a provided display.

The output device 850 may output the warning alarm message received from the UAM traffic management server 30 through at least one of a display, speaker, and vibration module.

ECUs 860 may include, but are not limited to, a steering system, drive system, braking system, vertical takeoff and landing system, navigation control system, battery management system, etc. Here, the drive system may include a travel drive system that drives a motor for land travel and a flight drive system that drives a motor for aerial flight.

The charging device 880 may charge the battery 890 by receiving wireless or wired power from a supply device (not shown) provided in a verti port or an emergency landing pad. Additionally, when an emergency situation occurs during flight - for example, when a low battery level situation occurs - the charging device 880 may receive or transmit wireless power in conjunction with a charging device mounted on another urban air mobility.

The memory 870 may maintain various software/firmware and various parameter setting information necessary for the operation of the UAM 800. Additionally, the memory 870 may be equipped with various learning software engines for machine learning.

Figure 9 is a block diagram for explaining the configuration of a UAM traffic management server according to an embodiment of the present disclosure.

Referring to FIG. 9, the UAM traffic management server 30 may be configured to include a receiving unit 910, an analysis unit 920, a generating unit 930, and a transmitting unit 940.

The receiving unit 910 can collect information from the UAM aircraft and external servers. Here, the collected information is replaced with the description of FIGS. 1 to 8 described above.

The analysis unit 920 can analyze air traffic flow and flight status for each aircraft based on the collected information. Here, the specific content analyzed by the analysis unit 920 is replaced with the description of FIGS. 1 to 8 described above.

The generation unit 920 may generate a user interface screen showing real-time air traffic flow or information about a user interface screen based on the air traffic flow analysis result of the analysis unit 920. Here, the specific form of the user interface screen is replaced with the description of FIGS. 2 to 4 described above.

Additionally, the generation unit 920 may generate information for configuring a navigation screen mounted on the aircraft based on the analysis unit 920's analysis of the flight status for each aircraft. Here, the information for configuring the navigation screen is replaced with the description of FIG. 5 described above.

The transmitting unit 920 may transmit information about the user interface screen and navigation screen configuration information generated by the generating unit 920 to the corresponding UAM and/or UAM navigation server 20.

The steps of the method or algorithm described in connection with the embodiments disclosed herein may be implemented directly as hardware, software modules, or a combination of the two executed by a processor. Software modules may reside in a storage medium (i.e., memory and/or storage) such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM.

An exemplary storage medium is coupled to a processor, the processor capable of reading information from and writing information to the storage medium. Alternatively, the storage medium may be integral with the processor. The processor and storage medium may reside within an application specific integrated circuit (ASIC). The ASIC may reside within the user terminal. Alternatively, the processor and storage medium may reside as separate components within the user terminal.

The above description is merely an illustrative explanation of the technical idea of the present invention, and various modifications and variations will be possible to those skilled in the art without departing from the essential characteristics of the present invention.

Accordingly, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention, but are for illustrative purposes, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be interpreted in accordance with the claims below, and all technical ideas within the equivalent scope should be construed as being included in the scope of rights of the present invention.

Claims (22)

In a method of a server managing traffic flow of UAM (Urban Air Mobility),
Collecting information from the UAM and external servers;
Analyzing air traffic flow based on the collected information;
generating information on a user interface screen for providing real-time air traffic flow information based on the analysis results; and
Transmitting information about the generated user interface screen to at least one of the UAM and the external server
Method, including. According to paragraph 1,
The information collected from the UAM is:
Sensor data collected by sensors mounted on the UAM;
Driving data collected from ECUs (Electric Control Units) mounted on the UAM; and
Positioning data collected from the UAM-equipped GPS receiver
Method, comprising at least one of: According to paragraph 1,
The external server is,
A UAM flight server that provides at least one of flight plan information and real-time flight-related information;
An infrastructure operation server that provides at least one of type information for each port, available information, and information on real-time capacity; and
A flight support information server that provides at least one of corridor design information, information on obstacles and terrain for each corridor, emergency landing site information, base station information, and weather information.
Method, comprising at least one of: According to paragraph 1,
The information on the user interface screen includes information on a four-dimensional view screen on which at least one of latitude information, longitude information, altitude information, and flight time information of the aircraft in flight for each corridor connecting two vertiports is displayed. . According to paragraph 4,
The information about the view screen includes information about a horizontal view screen configured to place the corridors connecting the two verti ports on a horizontal plane and a vertical view screen configured to arrange the corridors connecting the two verti ports on a vertical plane. Containing information about, methods. According to clause 5,
identifying the two vertiport types; and
Determining one of the horizontal view screen and the vertical view screen as the main view screen based on the identified vertiport type.
Further including, the horizontal view screen is determined as the main view screen based on the fact that the identified vertiport type is a Single-FATO (Final Approach and Take-Off area) in which two aircraft cannot take off and land simultaneously, Characterized in that the vertical view screen is determined as the main view screen based on the identified vertiport type being a multi-FATO capable of simultaneous takeoff and landing of two aircraft. According to clause 6,
Further comprising determining one of the horizontal view screen and the vertical view screen as an auxiliary view screen based on the identified verti port type,
Based on the identified vertiport type being the Single-FATO, the vertical view screen is determined as the auxiliary view screen, and based on the identified vertiport type being Multi-FATO, the horizontal view screen is determined as the auxiliary view. decided on the screen,
The method, characterized in that the auxiliary view screen is displayed in a pop-up form on one side of the main view screen in PIP (Picture In Picture) mode. According to paragraph 1,
The information on the user interface screen is information about the current flight speed of the aircraft in flight for each corridor connecting two verti ports, which are Single-FATO (Final Approach and Take-Off area) type where two aircraft cannot take off and land simultaneously. , A method comprising information on an air traffic flow monitoring screen that includes at least one of information about a recommended flight speed, information about a late arrival time of an aircraft, information about an early arrival time, and information about a collision protection zone. According to paragraph 1,
The information on the user interface screen includes information about at least one aircraft in flight for each corridor connecting two verti ports, and when one of the included at least one aircraft is selected, the selected aircraft is in flight. A method, characterized in that information is transmitted to at least one of the UAM and the external server at an expected arrival time for each preset section within the corridor. According to paragraph 1,
Generating navigation information for configuring a navigation screen mounted on the aircraft based on the information collected from the UAM; and
Transmitting the generated navigation information to the corresponding UAM
It further includes,
The navigation information includes information on coordinate values indicating the degree of route deviation of the aircraft, with the center of the corridor in flight as the origin; and
Forward steering control information to prevent deviation from the forward course
Method, comprising at least one of: Non-volatile computer-readable storage storing at least one computer program including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for managing traffic flow in Urban Air Mobility (UAM). In the media,
The above operations are:
Collecting information from the UAM and external servers;
Analyzing air traffic flow based on the collected information;
generating information on a user interface screen for providing real-time air traffic flow information based on the analysis results; and
Transmitting information about the generated user interface screen to at least one of the UAM and the external server
Storage media, including. In the server that manages the traffic flow of UAM (Urban Air Mobility),
a collection unit that collects information from the UAM and external servers;
an analysis unit that analyzes air traffic flow based on the collected information;
a generating unit that generates information on a user interface screen for providing real-time air traffic flow information based on the analysis results; and
A transmission unit that transmits information about the generated user interface screen to at least one of the UAM and the external server.
Server, including. According to clause 12,
The information collected from the UAM is:
Sensor data collected by sensors mounted on the UAM;
Driving data collected from ECUs (Electric Control Units) mounted on the UAM; and
Positioning data collected from the UAM-equipped GPS receiver
Containing at least one of the servers. According to clause 12,
The external server is,
A UAM flight server that provides at least one of flight plan information and real-time flight-related information;
An infrastructure operation server that provides at least one of type information for each port, available information, and information on real-time capacity; and
A flight support information server that provides at least one of corridor design information, information on obstacles and terrain for each corridor, emergency landing site information, base station information, and weather information.
Containing at least one of the servers. According to clause 12,
The information on the user interface screen includes information on a four-dimensional view screen displaying latitude information, longitude information, altitude information, and flight time information of the aircraft in flight for each corridor connecting two vertiports. According to clause 15,
The information about the four-dimensional view screen includes information about a horizontal view screen configured to place the corridors connecting the two verti ports on a horizontal plane and a vertical view configured to arrange the corridors connecting the two verti ports on a vertical plane. A server that contains information on the screen. According to clause 16,
The analysis unit identifies the two verti port types and determines one of the horizontal view screen and the vertical view screen as the main view screen based on the identified verti port types, where the identified verti port types are two. Based on the fact that it is a Single-FATO (Final Approach and Take-Off area) where two aircraft cannot take off and land simultaneously, the horizontal view screen is determined as the main view screen, and the identified verti port type allows two aircraft to take off and land simultaneously. The server, characterized in that the vertical view screen is determined as the main view screen based on possible Multi-FATO. According to clause 17,
The analysis unit determines one of the horizontal view screen and the vertical view screen as an auxiliary view screen based on the identified verti port type,
Based on the identified vertiport type being the Single-FATO, the vertical view screen is determined as the auxiliary view screen, and based on the identified vertiport type being Multi-FATO, the horizontal view screen is determined as the auxiliary view. decided on the screen,
The server, characterized in that the generating unit generates the four-dimensional view screen so that the auxiliary view screen is displayed in a pop-up form on one side of the main view screen in Picture In Picture (PIP) mode. According to clause 12,
The information on the user interface screen is information about the current flight speed of the aircraft in flight for each corridor connecting two verti ports, which are Single-FATO (Final Approach and Take-Off area) type where two aircraft cannot take off and land simultaneously. , a server containing information about an air traffic flow monitoring screen that includes at least one of information about recommended flight speeds, information about late arrival times, information about early arrival times, and information about collision protection zones. According to clause 12,
The information on the user interface screen includes information about at least one aircraft in flight for each corridor connecting two vertiports, and when one of the at least one aircraft is selected, the selected aircraft is in the corridor in flight. A server, characterized in that information is transmitted to at least one of the UAM and the external server at an expected arrival time for each preset section. According to clause 12,
The generating unit generates navigation information for configuring a navigation screen mounted on the aircraft based on information collected from the UAM,
The transmission unit transmits the generated navigation information to the corresponding UAM,
The navigation information is characterized in that it includes at least one of information about coordinate values indicating the degree of departure from the course of the aircraft with the center of the corridor in flight as the origin and forward steering control information to prevent departure from the forward course, the server . In a method in urban air mobility linked to a server through a communication network,
transmitting data collected from sensors and electronic control units provided during flight to the server through the communication network;
Receiving information on a user interface screen displaying real-time air traffic flow from the server; and
Constructing a screen based on information about the received user interface screen and outputting it to a provided display.
It includes, and the information on the user interface screen is information about a four-dimensional view screen that includes at least one of latitude information, longitude information, altitude information, and flight time information of the aircraft in flight for each corridor connecting two verti ports. Method, including.