High Density Vertiport ConOps, like the NASA UML4 ConOps, leaves the Industry, and Local Governments Out to Dry

A link to the document — https://ntrs.nasa.gov/citations/20210016168

Let’s start here

“The industry is fragmented, and the vision is unclear on how vertiports will be integrated with VTOL aircraft, fleet operators, air charter brokers, and an Unmanned Aircraft System (UAS) Traffic Management (UTM)-inspired Provider of Services to Urban Air Mobility (PSU) Network.”

I applaud communicating the truth right off the bat. But it’s not just vertiports, the entire UAM/UTM space is unclear. Why????? Because everyone is looking to NASA and NASA is pulling up way short. And they have done it again here. Looking at this and the UML4 ConOps I thought the root cause was not understanding what a ConOps is. Now I think it’s a domain issue. The issue is there is not nearly enough due diligence in enough areas. It’s like NASA only involved folks who understand airports and Agile bottoms up design. Not air and ground C4ISR and how that looks with more use cases and aircraft types than airports deal with. When that domain limitation occurs, they punt to non-real time data based UTM, describe the other use cases and issues to consider but then punt on the specifics of how that looks at various complexity/UML levels and tell companies, cities and entities in the environment, good luck with handling this, especially deconfliction, beyond non-real time based UTM data and local entity sensors.

This is very evident in their lack of understanding of V2V. Which is really C-V2X

“Aircraft have vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication capabilities for tactical air and ground separation and spacing. (NASA UAM Vision ConOps UML-4)”.

Just like the UML4 ConOps this document thinks 999 simultaneous air ops are going to miraculously deconflict for each other because of non-surveillance UTM, sensors and V2X. In an environment where the vehicles are expected to be “autonomous”. How is V2X working at 25mhz with shared air and ground entities. And at just a 10hz update rate? (And I am not even mentioning folks think each entity will pass raw sensor data to others). All this separate PSUs are gonna coordinate with no gaps or need for a city wide common operating picture or warning and control system? With everyone, including drones, deconflicting for themselves because they have flight plans, push that data around nowhere near real-time, and have onboard sensors?

Use Cases

It’s great to list the primary use cases and vertiport flight ops quantities within UML4. But how does 999 simultaneous air ops look with mixed use cases from various vertiports? And those vertiports interacting with entities that come and go from areas that are not vertiports? While the document states the use cases can be used at any level it makes things very confusing by trying to associate the complexity of the use cases with the complexity of UML. While explaining the use case complexity makes sense the UML levels should assume all use cases participate at every level and show what the variations of that mix does and how to handle it. The approach here should be from the end-state backwards not Agile inaccurate bottoms up. Once the end-state is understood we should then show various incremental paths to that point based on use cases, environments, vehicle quantities etc.

VFR and IFR are human pilot terms and processes. That does not apply to autonomy

No more to say on that

Closing

Once again NASA is punting to local governments expecting them to do most of the work required here. As I said previously it seems clear the root cause here is focusing on comparisons to airports and involving Agile IT folks. (Deloitte was involved in both processes. Are they the root cause?) This is an air AND ground C4SIR issue far more like a battlefield that requires AWACS than an airport.

(Link-16 anyone? Maybe a CWACS-City Warning and Control System? If you don’t know what C4ISR, AWACS and Link-16 are you are helping me make my point.)

My name is Michael DeKort — I am a former system engineer, engineering, and program manager for Lockheed Martin. I worked in Aerospace/DoD/FAA simulation, as a Sr PM and then the Software Engineering Manager for all of NORAD, as a PM on the Aegis Weapon System, as a C4ISR systems engineer for the DHS Deepwater program and the lead C4ISR engineer for the Counter-terrorism team at the US State Department. I am now CEO/CTO at Dactle.

Industry Participation — Air and Ground

- Founder SAE On-Road Autonomous Driving Simulation Task Force

- Member SAE ORAD Verification and Validation Task Force

- Member UNECE WP.29 SG2 Virtual Testing

- Stakeholder USDOT VOICES (Virtual Open Innovation Collaborative Environment for Safety)

- Member SAE G-34 / EUROCAE WG-114 Artificial Intelligence in Aviation

- Member CIVATAglobal — Civic Air Transport Association

- Stakeholder for UL4600 — Creating AV Safety Guidelines

- Member of the IEEE Artificial Intelligence & Autonomous Systems Policy Committee

- Presented the IEEE Barus Ethics Award for Post 9/11 DoD/DHS Efforts