2018 started with the drone market in Singapore bustling with activities, with now more than 200 Unmanned Operator Permit (UOP) holders, there’s never a better a time to talk about airspace management for drones.
Although drones are primarily still used in recreation, inspection, mapping, surveillance and a variety of aerial photography and videography use cases, the days where drones will be used in Singapore for Beyond Visual Line Of Sight (BVLOS) flights, such as large compound security surveillance, e-commerce last mile delivery, and even emergency medical supplies delivery might be coming really soon.
At least, as soon as we sort out how we’re going to share the skies at low altitudes. Today’s UOP framework requires explicit exemptions for all flights beyond the national drone ceiling of ~60 meters (200 ft), utilisation of any form of catch and release mechanisms, or carrying a variety of payload weights.
The Unmanned Traffic Management (UTM) system Singapore needs has to be a dynamic one the addresses the need for drones as well as manned aviation, such as air taxis. Here are some examples:
- For a compound security drone to use vision tracking to chase trespassers out of their regular, approved patrol paths, they will need real time information of their limits imposed by their command center, the national area limits, and emergency stay-out zones (called geofences), on top of really good sense and avoid capabilities.
- For a fleet of e-commerce drones to ply hyperlocal routes between distribution centers and various HDB flats, fully connected command control fleet management systems will need to perform highly coordinated and efficient traffic management around distribution points, not to mention scheduling it around our fast changing weather and avoid generating too much noise in the neighbourhood.
- Some drones will need higher priority over other drones, such as during a live saving emergency. This includes blood, organ, or emergency medical supplies delivery, either between hospitals or any accident or mass casualty sites.
To better illustrate the various designs for such a UTM, we will use an actual scenario to surface the various challenges, potential methods of approaching the issue, and our current position on the issue.
Here’s a hypothetical example: Emergency Blood Delivery.
Imagine an “SG Blood Delivery Service” that can deliver emergency blood from our Blood Bank in SGH, to anywhere in Singapore under 10 minutes.
Suppose there was a mass casualty event at a hypothetical location at Yishun. A call to 995 will activate the emergency medical teams from Yishun Fire Station and Khoo Teck Puat hospital.
Knowing that supplies such as blood will be short from these satellite stations, the 995 operator also activates the “SG Blood Delivery Service”. It can deliver emergency blood and other supplies from Singapore General Hospital (at Outram) to anywhere in Singapore in 10 minutes flat.
Let us now consider each of the challenges this delivery service will face.
Part 1: AIRSPACE
Given the current framework for airspace management, the destination is within 2 airport’s aerodromes: Sembawang Airbase (military), and Seletar airport (commercial). Flying within 5km from an airport’s boundary requires authorisation.
The airspace around that area also happens to be a controlled airspace, falling under the purview of Sembawang airport’s Air Traffic Control Officer (ATCO). For simplicity, let’s just say it requires additional authorisation from additional stakeholders.
The role of the ATCO situated in the airport’s control tower is to de-conflict the use of airspaces, in this case, the low altitude flights from high altitude manned aircrafts. Currently, it takes 5 business days to and fro between the drone operator, the regulator (CAAS), these various stakeholders and the ATCO for flight approval.
To save lives, our new goal is to make this authorisation happen in 5 seconds instead.
Here’s Garuda Robotics’ proposal, simplified to help the public appreciate it better:
- Establish a mutually exclusive and completely exhaustive (MECE) ownership of all airspace in Singapore, like a 3D jigsaw puzzle.
- For each piece of the sky, establish a set of rules that will automatically be granted approvals, that varies by drone operator or classes of drone operators.
- Programmatically route and approve flight authorisation requests if it meets the predetermined rules, and escalate to the human ATCO for intervention when it doesn’t.
- Allow the human ATCO to revoke the programmatically granted authorisation at any point under exceptional circumstances.
This seems like a good solution, but might not be fully compatible with how airspace is managed today. Let’s start with how airspace is classified.
Let’s start with, say, International Civil Aviation Organization (ICAO)’s definition of airspace classes. Notice that these classifications are static and does not change. ICAO member states adopt these definitions so that manned aircraft pilots, ATCOs, and basically everyone in the aviation industry can speak the same language. This facilitates cross boundary integration, mobility of expertise, and safe flights everywhere.
On the other hand, the unmanned air traffic does not yet have such standards. One contributing factor is that unmanned air traffic is disproportionately local, so various parties have tried to demarcate the sky their own way. Most international references try to specify something in the uncontrolled airspace (Class G), of which Singapore has close to none. Let’s take a look at some proposals.
Amazon wants local traffic below 60m (200ft), and their higher speed e-commerce drones to deliver your shopping hauls between 60m – 120m (200ft – 400ft).
Many earlier proposals were similar to this: simple and practical, with drones overflying a practically flat terrain.
Unfortunately, Singapore and other megapolis are too crowded for this simple classification.
In Singapore, Airbus Helicopters recently completed a trial for a parcel delivery through established “Skyways” around the National University of Singapore.
This limits the white-listing of airspace to the size of a pipe, which has the potential to streamline the interaction with various authorities who owns the airspaces where the cylinder punches through.
Researchers in the Air Traffic Management Research Institute (ATRMI) went all the way to combine these ideas into a coherent picture, where high speed delivery drones will fly between 150m (500ft) and 180m (600ft), a labyrinth of unilateral digital lanes, which are connected by nodes that sport a “traffic light system”. To ensure all drones adhere to their traffic management, they even went to the extent of plotting out telco signal strengths (AirMatrix), and propose the shape these “roads” in the sky based on them.
Single European Sky ATM Research (SESAR) Joint Undertaking recently released a U-space Blueprint. We notice that it tends point towards only centralising the authorisation and de-conflicting aspects of airspace management, leaving the responsibility of avoiding obstacles, flight path planning, and so on to the drone operators themselves.
This is intuitive and similar to how land authorities regulate the use of vehicles on the road. How the pilot flies his aircraft, what technology is employed, and so on, should not be limited by what the central de-conflicting party can or cannot interact with.
Additionally, the U-space blueprint also does not prescribe how airspace will be organised. Rather, it motivates a negotiation framework where airspaces are dynamically assigned. In other words, depending on how the various stakeholders interact with each other, they can temporarily or permanently take over airspace authority, while ensuring that every compatible UAV acknowledges the change in real time. This can reduce the economic penalty for reserving and not fully utilising our scarce airspace.
To conclude this section, we propose two immediate services to be provisioned:
- For ground obstacles, such as tall cranes erected for construction, we need to augment manned aviation’s NOTAM (Note to Airman) service into a rich, real time, high resolution, 3D version of Singapore, that smaller drones can use to navigate the landscape.
- For dynamic geofences (temporary flight restrictions), we need a coordinating government function whose role is to own that MECE skies for drones we spoke about earlier, and allow all government stakeholders to claim it temporarily or permanently. These changes in authority should be programmatic and immediate reflected to all drone operators and the public.
Part 2: CONTROL
Source: Precision Hawk
Connecting drones via mobile networks
Suppose flight authorisation can happen in seconds, the next important challenge is to stay in control of the drone throughout its entire flight from Outram to Yishun.
Unmanned aviation faces this additional challenge where the pilot is remote from the vehicle. A simple ground and air antenna pair does not scale nationwide. RF spectrum is fairly congested in a city like Singapore, and re-using aviation spectrum will result in the need of much rework of manned aviation standards.
Drones does have one advantage over traditional manned aviation: it flies really low. In most countries we have ceilings around 120m (400ft) or 240m (800ft) but in Singapore we’re talking about 60m (200ft) here. Singapore also has a lot of tall buildings for connectivity infrastructure can sit on.
So it should be no surprise that Garuda Robotics’s proposal echos the telco industry:
- Reuse existing 3G/4G networks to connect drones to the Internet for the purpose of Command and Control (C2) for BVLOS flights, or simple telemetry updates to their respective DOCs
- Enforce nationwide coverage up to the national drone ceiling, providing a fault tolerant, low latency network product to all drone operators
- Allow telco operators to monetise the additional investment of tilting their antennas for sky coverage by selling premium products (for example, high bandwidth for video streaming)
Similarly, it should be no surprise that many 5G trials around the world has drone connectivity in mind. Without waiting for the general availability of 5G in Singapore, we mapped out selected parts of Singapore, including the designated drone test site at One North, and found certain parts of Singapore has very good 4G connection at 60m. This is especially the case for open areas, such as the Old Holland Road field where many commercial and recreational drone activities take place.
Unfortunately, dense built-up areas in Singapore presents a challenge as antennas were optimised for ground coverage, resulting in either RF silence once we exceed 30m, or suffers from uplink RF interference from nearby antennas transmitting in the same frequency.
Because connectivity is never static and guaranteed, all drones will need to be equipped with auto-pilot that could self navigate, especially during the short period of time it loses connection. Similar to current VLOS systems today, all BVLOS drones must have a deterministic behaviour when it comes to exceptional conditions, known as fail-safe, e.g. if the drone cannot communicate with its operations center for more than, say, 20 seconds, it will automatically return home or land at the nearest safe landing spot.
Other known optimisations built on top of a mobile core that are currently studied in Singapore include
(i) HetNet (Heterogeneous Network), ie. combine WiFi and 3G/4G into one network for seamless handoff from ground to sky;
(ii) DSRC (Dedicated Short Range Communications) for V2X, ie. using nearby drones as relays similar to Autonomous Vehicles and ERP2; and
(iii) a variety of IoT focused comms for only the telemetry portion
A fully connected airspace is a game changer, and can happen sooner in a small city state like Singapore or other cities in the world.
Part 3: COMMAND
The next issue to tackle is command. Who can command the drone, and how to keep the drone in control by a “good guy” commander? For liability reasons, there must ultimately be a commander of the drone, even though the drone is being flown mostly on auto-pilot.
Before we offer our recommendation, let’s look at 4 scenarios:
(1) Fully distributed command scenario
This is the de-facto case today, where the pilot of retail drones commands the drone with no coordination with anyone. If he turns off his phone’s connection or prevent the manufacturer’s app from using the network to connect to the manufacturer’s servers, then even the manufacturer has no information about the occurrence of the flight.
To track or stop rogue pilots in this scenario, airspace regulators will have to use a variety of tracking radar or employ signal jamming techniques. They can certainly enact laws to require permits to fly, or put in place remote identification requirements to all manufacturers, similar to car plates.
(2) Partially connected scenario
In this scenario, the drone’s basic telemetry will be made available to an airspace manager (e.g. an ATCO), either directly from the (3G/4G capable) drone, or via their GCS (ground control station – VLOS flights), or DOC (drone operations centers – BVLOS flights).
A variation to this scenario is where all drones will sport a transponder that emits an identifier (think: drone plate number), to static or mobile receivers on the ground.
One could imagine this as an attempt to replicate the behaviour of ADS-B, a protocol for manned aviation to broadcast their location, leveraging telco infrastructure instead of installing ADS-B receivers everywhere.
The ATCO, having the benefit of a global view of all air traffic, will now be able to respond to bad behaviour either programmatically (e.g. display a warning on his or her app), or by calling the pilot.
(3) Fully connected scenario
In this scenario, all drones will be required to have an Internet connection to fly at all. The command for the drone can happen anywhere, either locally via a separate, direct connection from the ground, or via the national drone network. All drone pilots will be known, registered, and contactable.
As improbable as this scenario sounds, it’s actually the de-facto case for the mobile industry: All phones comes with IMEI identifiers, while MSISDN / IMSI ties the subscriber to the phone. By placing a 3GPP communication module on the drone, the same registration process would already apply.
This scenario presents very interesting use cases that we will explore throughout the remainder of this presentation.
To stretch your imagination, I’ll share one futuristic use case, where
– A drone could be piloted by a distributed team of pilots, potentially from different drone operators, with an established hierarchy.
– Remote Landing: A pilot in command could delegate partial control to a nearby ground observer with line of sight to the drone to help land the drone safely.
– Training: A pilot’s command could be relinquished to his or her superior, say, the Chief Pilot of the drone operator company.
– Lawful Intercept: In extenuating circumstances, where even the Chief Pilot of the drone operator company had gone rogue, the national drone ATCO could override to take over command, for example, forcing the drone to land before it flies into the airport.
(4) Central command scenario
For completeness, imagine a scenario where all drones are simply commanded by a single drone command center. This will most likely apply only to a busy drone port, where all landing and take off would need to be scheduled and coordinated.
It’s very likely that all 4 scenarios will pan out in parallel, depending on how congested the airspace is, and what the drone is overflying.
Garuda Robotics recommends that different laws should apply for each of these scenarios, so that we can provide drone operators lots of freedom at low density airspace, but little freedom at high density airspace. Not just density of manned and unmanned aircrafts, but density of buildings, people, and various ground assets.
- Recreation flights outside aerodromes and away from people can continue to enjoy the freedom and anonymity of scenario 1 laws.
- Flying of drones around HDB flats for inspection purposes might require minimally scenario 2 laws, and to inform the public of the purpose of the flight.
- All BVLOS flights that crosses airspace boundaries for delivery, or working in congested airspace, such as inspecting airport buildings or runways, must adhere to scenario 3 laws and above.
Back to the story
Putting together rapid authorisation, dynamic airspace management, telco connectivity, and multi-pilot command, we can now proceed to deliver our emergency blood from the blood bank to the site.
Let’s continue our hypothetical story.
The blood was retrieved from the freezer and started to thaw as the blood bank officer loads it onto the drone. A path was planned and assigned to a high speed altitude plain or cylinder, cleared with all authorities for flights, and it takes off. Elapsed time: 1 minute.
At 25m/s or 90km/h, the estimated time to destination was 4 minutes, adding 1 more minute to land, the total time required for this delivery was 6 minutes. Two planned flights for building inspection along the way were told to hold for at least 10 minutes, before commencing their work.
Barely 1 minute into the flight, a new geo-fence was broadcasted to all drones about a potential threat that was discovered at Bishan MRT. An unattended package with radio devices had been found, and the police had put in place a temporary no fly zone 2km around the MRT.
Because the drones stayed connected all the time, it was possible for our blood delivery drone to dynamically reroute its path around the new geo-fence, all the while keeping all interested parties informed of the potential delay. Additional time required: 30 seconds.
As the drone homed into the destination, the command center pilot handed over the command of the drone to an officer on the ground to command the landing.
In this scenario, the landing spot was not a preplanned, fully open to the sky spot, like that of delivery drones moving from lockers to lockers. There were slight obstructions by our large canopy rain trees in Singapore.
The trained medic sergeant used a simple interface to nudge the drone in its descend to avoid those branches. Once the drone had visual of the precision landing symbol, it commenced its regular vision based homing system, landed on the mobile landing pad, and released the payload to the medical officers.
With its successful delivery, the drone could now return to the blood bank by flight, or simply join the medic’s ride back to the hospital on the ambulance.
Part 4: CYBER SECURITY
With the complete story in mind, now let us consider what else could go wrong for this hypothetical flight.
Could a drone be hijacked to perform a mission it was not programmed to do? Could the command center receive telemetry that was fake? Could an unauthorized pilot take over a drone claiming to be the authorized pilot?
All qualified DOC systems require a very high degree of trust to be established with the remote aircraft. Because the bad guys are not sitting in the drone, their lives are not at stake when they do bad things.
Cyber security is a huge topic that I cannot do justice with this limited amount of time. And cyber security is just a small portion of a larger “safety-first” risk management portfolio to measure all other kinds of risks, specifically liability, privacy and physical damage due to anything from avionics failure simply bad navigation decisions.
Nevertheless, I will highlight 3 of them here:
(1) We will need some way to be sure that the pilot on the ground or at the command center is who he is, either by scanning his ID, or his thumbprint, or recognize his face, and so on.
(2) We will need to be able to authenticate drones when they make claims about their drone ID, their position, and the reported time of the system.
(3) We will need to make sure the channel remains secret between the drone and all potential operators for the flight, which in our story includes the main pilot in the command center, the ground observer who can land the drone visually, and an authority, perhaps the police, who can cancel the flight and send it home.
The key recommendation here is to go with the best practises and best protocols in Internet Security, instead of trying to create a UAV only secure protocol. This leverages the best minds in securing connectivity, allows drone operators to respond faster to a new threat by patching their systems, and simplifies the need for various stakeholders to agree on newly designed protocols.
If the drone cannot be attacked from inside, how about from outside? On a tactical basis, how can two drones from two independent systems know of each other and avoid crashing into one another? How can drones avoid birds and other flying objects that cannot be preempted by the UTM or the ATCO?
The holy grail for Detect, Sense, and Avoid is no doubt a non-collaborative, multi-sensory setup, comprising a fusion of on board sensors for the drone to “see” or “hear” things around it. The most common tech today are stereo visual cameras in the direction of travel of the drone, add to that a collection of lidar (light detection and ranging) and sonar (sound navigation and ranging) sensors. They are unfortunately not mature and not mandated currently, while reliability varies greatly between manufacturers.
Today’s traffic management services can provide a stop gap by localising and exchanging telemetry data from disparate systems in real time. Designed with a reasonable buffer for reaction and coordination, the localised de-conflicting of flight paths can happen between auto-pilots, removing the human whose intervention would be slow and non-deterministic.
Part 5: ECOSYSTEM
Besides technology, a comprehensive traffic management service should come with a huge education component for the public and the professionals.
At the moment, Singapore residents has little tools and means of evaluating their circumstances, when they are faced with a flying robot.
Is that drone a legit drone? Is it an ambulance saving lives? Is it my naughty nephew zooming through window to read my confidential information on my table? Is that NEA’s mosquito-killing drone outside my HDB flat or my mother-in-law’s remote control CCTV?
Professionals and companies who can operate a nationwide drone delivery or surveillance service is also going to be a challenge to train and retain.
The high stakes for BVLOS flights must be matched with high levels of competency by operations.
Rigorous training and familiarisation is a must with drone operations center software and various new air traffic services, in addition to meticulous fleet management of the operational drone fleet.
Implementing a UTMS is an urgent need for any city who wants to be the leader in drone adoption, to save lives, decongest traffic, avoid working at heights, and invent the future from a bird’s eye view.
Solving all the mentioned challenges takes time and requires an evolutionary approach for various technology to mature and various stakeholders to align their operations to this common goal.
I will leave you with these 3 principles for rolling out such a service.
One, as mentioned earlier, lots of freedom for low density, but little freedom for high density.
Two, open up airspace for high end drones as well as low end, simple maker-movement type drones, embrace commodity hardware, internet protocols and open interfaces, and espouse closed proprietary systems often pushed by dominant players.
Three, make UTMS the UTM Services instead of UTM System, by decoupling critical innovations into modular but compatible services, to encourage an ecosystem of players to bring to bear their strengths asynchronously, so that we can take multiple baby steps towards a multi-vendor, multi-technology, even multi-risk model, but programmatic, single-protocol, long term service evolution kind of UTM Service.
With that, I hope I’ve given everyone a gentle introduction to our garden in the sky.
Thank you, and Happy flying!