Urban Air Mobility has a Terminology and Systems Engineering Problem
The two main terms being used by the industry are:
· Urban Air Mobility (UAM)
· Unmanned Aircraft System (UAS) Traffic Management (UTM)
UTM is defined by the FAA as:
The FAA, NASA, other federal partner agencies, and industry are collaborating to explore concepts of operation, data exchange requirements, and a supporting framework to enable multiple beyond visual line-of-sight drone operations at low altitudes (under 400 feet above ground level (AGL)) in airspace where FAA air traffic services are not provided.
Unmanned Aircraft System Traffic Management (UTM) is a “traffic management” ecosystem for uncontrolled operations that is separate from, but complementary to, the FAA’s Air Traffic Management (ATM) system. UTM development will ultimately identify services, roles and responsibilities, information architecture, data exchange protocols, software functions, infrastructure, and performance requirements for enabling the management of low-altitude uncontrolled drone operations.
The definition says It ONLY comprises unmanned and uncontrolled drones that are no beyond the visual line of sight (BVLOS) NOT unmanned air taxis for example. But the UTM definition says “aircraft”. Where do drones beyond the line of sight find a home? Where are manned or unmanned aircraft like air taxis covered?
The FAA and NASA believe they have that covered with Air Traffic Management (ATM) which is different than Air Traffic Control (ATC).
According to Wiki:
Air traffic management (ATM) is an aviation term encompassing all systems that assist aircraft to depart from an aerodrome, transit airspace, and land at a destination aerodrome, including Air Traffic Control (ATC), Air Traffic Services (ATS), Airspace Management (ASM), and Air Traffic Flow and Capacity Management (ATFCM).[1]
The increasing emphasis of modern ATM is on interoperable and harmonized systems that allow an aircraft to operate with the minimum of performance change from one airspace to another. ATC systems have traditionally been developed by individual States that concentrated on their own requirements, creating different levels of service and capability around the world.
So, it seems UTM is a subset of ATM that is limited to 400 feet AND only for drones not beyond the visual line of site (BVLOS). If a manned or unmanned aircraft or air taxis is flying NOT in relationship to an airport, which is covered by ATC, whether it is 400 feet or not, that is ATM. What if I have a drone airport or use the “aerodrome” the air taxis use for drone deliveries? (The BVLOS drones appear homeless.)
Wow!
This is far more than a terminology issue. Overly complex, confusing and incomplete terminology causes overly complex, confusing, and incomplete design and execution. This is what we want in a complex environment where tens of thousands of simultaneous operations are planned to take place in the air? Where the public likely will not tolerate a single significant mishap?
This is what happens when you apply a bottoms up Silicon Valley “engineering” approach to complex efforts. And that work is being done by folks who lack domain and/or systems engineering experience.
Why isn’t this simple? Why not one term with subcategories for the air space or domain and another, with subcategories, for the management of it? (And fix the ridiculous treatment of “surveillance” as a “supplemental” non-core process). Why isn’t the entire non-airport domain, for everything in the air that flies in it, 400 feet and below, called Urban Air Mobility? And that is managed under Air Traffic Management? Under that UTM is modified to include all unmanned aircraft and another category added for manned aircraft? Under each of those you could have subcategories as well? Or some other idea, as long as UAM and ATM remain as I stated. In either case, please stop the bottoms up stumbling on things nonsense and fix this unnecessary and avoidable non-intuitive, incomplete, confusing, and dangerous mess while it’s still in its infancy. Fix it through the use of a systems of systems design and common-sense approach. Staffed by folks who know how to do that and who understand the overall and various parts of the domain.
Beyond this things actually get worse. More below
Urban Air Mobility — Four Paths to Disaster
· https://imispgh.medium.com/urban-air-mobility-four-paths-to-disaster-9dd3966f85e2
Why Silicon Valley Agile engineering approaches won’t work for urban air mobility
My name is Michael DeKort — I am a former system engineer, engineering and program manager for Lockheed Martin. I worked in simulation, as the software engineering manager for NORAD, as a PM on the Aegis Weapon System and lead C4ISR systems engineer for the DHS Deepwater program. I am now CEO/CTO at Dactle.
Key Autonomous Vehicle Industry Participation
- Founder SAE On-Road Autonomous Driving Simulation Task Force
- Member SAE ORAD Verification and Validation Task Force
- Member SAE G-34 / EUROCAE WG-114 Artificial Intelligence in Aviation
- 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 Whistleblowing Efforts
