OneSky’s description of its Urban Air Traffic Management (UATM) solution in Korea as part of the K-UAM Grand Challenge began by building the airspace information layers to integrating surveillance and utilizing feeds. OneSky then introduced flight authorization and the rules engine built into the OneSky UATM. In this latest update, OneSky focuses on strategic deconfliction and conformance monitoring, as well as how everything works in a federated architecture where the UATM system can manage operations from multiple operators and PSUs.
According to OneSky:
Conformance monitoring moves into the mission’s operations phase. For example, suppose we have a few regional flights going between regional airports in a given geographical area. In that case, we may get information from our surveillance systems that they are coming too close to our operation. That will get detected by the OneSky separation management service. It detects violations of the well-clear and near-mid-air collision boundary in real-time. In addition, it forward propagates the surveillance and own-ship tracks to predict upcoming violations of the WC and NMAC boundaries. The operator is notified of existing or upcoming violations in the UATM alerts panel, as well as through the Server-Sent Event stream.
The operator can choose to change their flight based on the notification. What happens if the operator changes their flight? Well, if you go outside the 4-dimensional volumes assigned to your flight, you become “non-conforming.” Alerts are sent, and a non-conformance volume generated by the UATM.
The non-conformance volume is a dynamic geometry that tracks the non-conforming operation based on the last received position, heading, and speed. This volume is an appended version of your operational intent that was previously deconflicted and shared with other airspace users. Using ASTM standards for USS/PSU operational intent sharing, we discover and share this updated operational intent volume with all affected operators.
If you can get back into your assigned volume in a standard amount of time (ASTM standard or system-level setting), you return to the conforming state. However, if the operation remains non-conforming, it will eventually transition to the “contingent” state. Contingent operations trigger similar workflows to non-conforming operations, i.e., contingent volumes are generated based on the predicted trajectory of the operation and then shared with affected airspace users. However, contingent operations can not return to the conforming state and must be ended as soon as safely possible.
PSU Information exchange services
Now all of this comes down to information exchange. PSU and USS systems need to be able to exchange information, such as flight intents and tracking information, in real time. This is enabled by the UATM information exchange service. OneSky has implemented the ASTM standards for USS-to-USS information exchange, which utilizes the InterUSS Discovery and Synchronization Service (DSS) for discovery of service providers and ASTM standard APIs for peer-to-peer information exchange. We have also implemented the ASTM PSU to PSU peer-to-peer protocols, which have yet to be ratified but have been trialed in projects like NASA NC X4 and FAA UAM Demonstrator. The primary difference between the USS and PSU protocols is how flight intents are described, i.e., 4D Volumes vs 4D Trajectories.
ASTM standards are just one way to exchange information across the ecosystem. We are also pursuing information exchange using SWIM-compliant services and models, such as FIXM Core schemas and FF-ICE message templates. In collaboration with KARI and the KUAM SWIM Working Group, OneSky will adapt the traditional FIXM schemas to include UAM-specific properties such as vertiports, eVTOL properties, equipage, etc. At the end of the day, it doesn’t really matter the protocol. There have to be standards in place to make sure that data is exchanged in a common way.
For more information visit:
www.onesky.xyz
