Jon is the CEO and co-founder of
Kittyhawk, the leading provider of unmanned software and airspace systems.
More posts by this contributor
When Josh, my co-founder, and I founded Kittyhawk, we saw the need for a new way to aviate with the demands and opportunities that unmanned systems would create. We set out to build the future of programmatic aviation, yet to enable this aviation renaissance we also knew that pragmatic innovation was key.
We didn’t rush into building cool but ineffective technologies. We ignored the lure of flashy solutions looking for problems. We started from day one working, learning and engaging directly with our customers, who are now some of the largest users of aviation. Unless our customers — operators of some of the largest manned and unmanned fleets in the U.S. — can leverage a piece of technology today, its usefulness is muted. Unless our platform can make the entire National Airspace System (NAS) safer for all stakeholders, the effectiveness is diluted.
Our DNA is built on skating where the puck is going, innovating at the edge so that we can move fast and deliver actual capabilities that are impactful from day one with the potential to accrue more value and evolve over time. There’s no better example of this than Remote ID.
More than two years ago, we released our real-time telemetry and tracking of aircraft. Not simple representations of a flight icon on a screen, but live data of aircraft that businesses, governments and public safety workers utilize every day. How we view the future of Remote ID is based on our experience of powering live-flight data and the feedback and learning that we’ve received over the last two years of enabling Remote ID across our user base. We’ve incorporated all of this data and practical experience — along with all of your feedback from our NPRM survey results — to inform our approach to Remote ID.
Below, we’ve attached the full public comments that we’ll submit to the FAA’s notice of proposed rulemaking (NPRM) on Remote ID, but first, let’s begin with a few of our core beliefs that are central to how we operate as a company and the voice that we strive to give all of our users who fly with Kittyhawk:
- We believe that technology and software innovations should enable flight.
- Any rules, technologies or regulations that curtail or disenfranchise flight are not well-thought out and fail to appreciate what technology can solve.
- We believe that technology should be adopted based on its merits and its core utility.
- Regulating technologies based on the potential for misuse is unprecedented in our nation and has no place in the adoption of unmanned systems.
- We believe the future of aviation requires new ways of thinking to accomplish scale requirements and the need for mass adoption.
- Rules or processes that start and end within a traditional mindset are flawed and will fail to result in meaningful impact.
- We believe the future is now.
- Safety and speed are not mutually exclusive and there are ways to create a safer NAS today that all aviation users can adopt immediately.
On November 21, 2019, the FAA was rolling out a new batch of LAANC-enabled airports, including Washington Dulles International Airport (KIAD), which represents a huge swath of airspace in the security-sensitive area of Washington, DC. To give you a sense of how excited our users were for this, we began receiving support requests shortly after the strike of midnight as people were anxious to comply and fly in this airspace. Their initial authorization requests, however, were receiving errors, as it wouldn’t be until later that day that the FAA would officially flip the switch for these new airports and we could begin accepting LAANC requests for KIAD.
Moral of the story: If you give operators an easy way to comply, they’ll move faster than regulators to do everything they can to get in the air compliantly.
High-level comments on the NPRM
The current draft of the NPRM is overly complicated, presenting solutions for problems that don’t exist and introducing complexity that won’t solve the problems that do. We can create a baseline for Remote ID today that opens airspace and impacts safety. We can create a system that demands compliance without creating privacy black holes. There is a better way and we can do it in 2020.
No. 1: Leave OEM certification out of the picture completely
There is absolutely no reason that OEMs should be involved in the NPRM on Remote ID. The role of an aircraft is to reliably fly based on the controls it receives, not the other way around.
We do not require DVRs to prevent you from recording the Super Bowl on the off chance that you might redistribute it. We do not require cars to prevent you from driving if you don’t have validated licenses and registrations. Just because a piece of technology has the potential for misuse, it’s unprecedented and un-American to restrict capabilities at the hardware level based simply on what-ifs.
Any hardware requirement for Remote ID introduces unnecessary security concerns and also adds unnecessary time to the path to adoption. The thought of giving this much power to hardware manufacturers to control access to the NAS should scare everyone, and I’m surprised the FAA failed to consider this. OEM control of airspace access via Remote ID greatly expands the target landscape for hackers and data breaches.
By removing OEM requirements and proposals around things like new serial number systems, all current unmanned systems and models alike will not be relegated to the scrap heap. All current recreational and commercial operations will not need to buy new drones or worry about costly retrofits with untold timelines for potential compliance.
Recommendation: Put all the responsibility on the Remote Pilot In Command (RPIC). Delete all OEM manufacturer requirements from the rule.
No. 2: A logical, tiered approach is the only way
A tiered approach to Remote ID makes a lot of sense, but the proposed tiers in the NPRM are misguided and disjointed.
Remote ID tiers should account for different types of flight by different types of operations in different types of airspace. The more timely and rich the Remote ID data, the more freedom to the sky should be enabled, but there should be more tiers with a lower bar to simply get in the air.
To this end, there should be a tier that includes a volume-based Remote ID (like we have in the ASTM and like we’ve already developed and showcased in the open-source InterUSS Remote ID platform). Think LAANC reservation, but for Remote ID, where a user can announce a time/place of flight. This would require no new hardware and no new technology. Every operation from model aircraft to routine Part 107 commercial flights could adopt and comply with this, effective immediately at zero cost.
Additionally, there should be more privileges for sharing real-time data and having a connected operation that can communicate and deviate if required. If Remote ID is going to unlock BVLOS, then the highest tier of Remote ID operations should do just that.
Recommendation: A tiered system that creates a low-friction, zero-cost ability to comply with Remote ID, extending to a more demanding requirement that results in BVLOS without a waiver.
|
Tier 1 |
Tier 2 |
Tier 3 |
| Ceiling (Uncontrolled Airspace) |
Up to 200ft |
Up to 400ft |
Up to 400ft |
| Ceiling (Controlled Airspace) |
Up to 100ft* |
Up to 400ft* |
Up to 400ft* |
| Range |
VLOS |
VLOS |
BVLOS |
| Remote ID Requirements |
Volume-based reservation of a time/place.
Can be done remotely, up to 90 days in advance.
|
Volume-based reservation of a time/place.
Plus live sharing of telemetry via broadcast or network.
|
Volume-based reservation of a time/place.
Plus live sharing of telemetry via broadcast or network.
Plus network connection for aircraft or control stations to send and receive real-time messages.
|
| Process |
Submitted and processed like LAANC to a USS. |
Submitted and processed like LAANC to a USS.
Broadcast or network to meet data requirements (see below).
|
Submitted and processed like LAANC to a USS.
Broadcast or network to meet data requirements (see below).
|
*Or lower if flying in controlled airspace and LAANC ceiling is lower than the corresponding tier.
No. 3: Tier-based Remote ID data
Remote ID data for public consumption should be separate from law enforcement use cases that may come in the future. Conflating public use cases with law enforcement use cases adds unnecessary complexity and sacrifices privacy.
The objective with Remote ID data is that it’s actionable for other aircraft and flights in the area — and for the public — to understand what is buzzing over them. Yet, the public needs only a few data points to share with law enforcement who can then put the pieces together. The “license plate” is all law enforcement really needs to take action.
Anything else is a bonus and should be optional based on the tier of the flight you want to execute.
In our experience with customers who want to early adopt into Remote ID and from what we’ve seen in our Remote ID survey, people will gladly share more information with law enforcement. People will also gladly share more information if it results in more access to the air. Just as it is the RPIC’s responsibility to comply with Remote ID, it should also be up to the RPIC to control her data.
Recommendation: Fewer data requirements with more optional fields at lower-tier operations, with more demanding data sharing and real-time communications at the highest tier to enable advanced operations.
|
Tier 1 |
Tier 2 |
Tier 3 |
| Aircraft Identity |
serial number or anonymous session ID** |
serial number or anonymous session ID** |
serial number or anonymous session ID** |
| Aircraft Location |
N/A |
real-time LAT/LONG |
real-time LAT/LONG |
| Operator Identity |
optional |
FAA registration number or anonymous operator ID** |
FAA registration number or anonymous operator ID** |
| Operator Location |
N/A |
N/A |
real-time LAT/LONG |
| Operator Contact Information |
optional |
optional |
required |
| Flight Plan |
optional |
optional |
Submitted with takeoff, landing, route and emergency landing points.
Updated in real time.
|
**Generated and stored by a USS.
The FAA remarked in the NPRM at the successful private-public partnership that is LAANC. Let’s build on that infrastructure. We don’t need a new class of USS but simply to extend where and how we announce flights in the NAS. We already see that behavior today where users want to create polygons and announce flights in uncontrolled airspace.
At Kittyhawk, we’re going to continue building this concept of Remote ID into our platform for all of our users and we welcome other USSs and partners who want to join us and bring an actionable form of Remote ID to the NAS.
If you share our vision, please let us know and also let the FAA know with comments on the NPRM. There is a simpler and more effective path to Remote ID and we can do it in 2020.
