PAGE Author

All posts by Urban Mäder

Situational Awareness in Aerobatics

To many pilots, aerobatics is the ultimate form of aviation: It requires extensive training; the mental and physical stress is enormous, but so is the satisfaction when a figure worked out, not just ok, but perfectly precise and by the book!

Collisions with other aircraft are usually prevented by making sure there are no other aircraft around before starting with the aerobatics program. While easy enough in a competition (think aerobatics box), it is more challenging for training. For instance, a visiting pilot may not be aware of the aerobatics activity. The aerobatics pilot also has a high workload due to the demanding piloting and the physical stress. Moreover, due to the quick flight direction changes, little time remains to scan the airspace properly. Hence, proper see-and-avoid is extraordinarily demanding.

How do professional aerobatics pilots deal with this situation?

Meet Ernesto Maurer of the Fliegermuseum Altenrhein (FMA). Ernesto has logged hundreds of hours on the Pilatus P-3 and PC-7 military trainers and routinely flies aerobatics programs at air shows or with passengers. He is also responsible for maintaining and updating the avionics in these airplanes. To improve situational awareness, FMA has equipped its aircraft with PowerFLARM Fusion.

Watch Ernesto talk about it:

Even if you are not into aerobatics, consider this: The next situation where time is short and workload high might be just around the corner. If you equip your aircraft with PowerFlarm, you have one thing less to worry about: Being surprised by another aircraft on a dangerous course! Peace of mind is attainable in this case.

Why a federated U-space architecture may be a bad idea

Distributed models for flight approval are much harder (than you think)

U-space is Europe’s name for their UAV Traffic Management Systems (UTM), extending the established Air Traffic Management (ATM) duties towards unmanned or unpiloted aircraft, ranging from small drones to large passenger vehicles for Urban Air Mobility (UAM) applications. In today’s ATM, humans make most decisions. UTM, however, is designed to be digitalized and automated from the ground up. While ATM instances manage thousands of flights daily, UTM aims at orders of magnitude more.

U-space is still work-in-progress. In Europe, the high-level regulation (EU 2021/664) has been in force since May 2021, but it still needs amendment by more detailed regulations. Once U-space is fully operational, it promises to provide services like flight approvals, traffic information (about manned and unmanned aircraft), remote identification of aircraft, airspace management, weather updates, and geo-awareness. It is expected to enable efficient, automated, and safe operation of large and diverse fleets of drones. Access to airspace is supposed to be fair, cheap, and thus not dominated by large companies. Finally, it shall at least match commercial civil aviation’s excellent level of safety. In short, U-space is intended to be the fundament that keeps anything from small delivery drones to large electric passenger drones running smoothly, much like ATM is today for manned aviation – but at a much larger scale, lower cost, and higher quality.

An international, collaborative effort is underway developing the technical standards for U-space, involving the FAA, EASA, and other organizations. Creating such a complex system is challenging. The system’s design goals are unknown as we don’t know yet how the drone ecosystem will look like in 20 or 50 years. Already today, it is massively different than what we expected half a decade ago.

Centralized? Distributed? Federated!

A central decision taken very early in the project was to use a federated architecture. Federation is an approach to designing complex systems that mixes distributed and centralized aspects. Federated systems allow a high level of autonomy of service providers while defining precise rules and protocols for interaction between them. End-users can select a service provider from a large pool of offerings based on quality, features, cost, etc.

This works as follows: Users interact with the system through a number of service providers. Service providers operate independently, storing the data that is relevant for their domain of operation. Data can be shared and synchronized between service providers, i.e., when a user initiates an interaction that affects the domain of other service providers.

To initiate such a synchronization, a service provider must first identify with which peer a synchronization is needed. For this, a central federation server is queried, which maintains a directory of service providers. The server returns the contact details of the service provider, matching the query. The direct synchronization can then start, using a standardized protocol for data exchange.

Federated systems can have a number of benefits, including resilience, robustness, scaling effects, and lower cost. In general, it is a good choice if there is a clear benefit in having a large number of service providers.

A good example of a federated system is email, invented in the early 70ies: The data (that is, emails, including headers and attachments) is highly distributed among millions of email servers like Gmail, Yahoo, or smaller corporate or private servers. Emails are synced between servers only when needed, that is when a user sends an email to an address, not on the same server, e.g., from alice@gmail.com to bob@yahoo.com. To find the right server, the sender performs a lookup in the Domain Name System (DNS). DNS is a hierarchic system to globally organize internet names such as ibm.com. Domains can contain an entry for an email server; hence the sender can query DNS for the correct server to contact. Once the recipient is known, the sender contacts it directly and sends the email using a protocol called Simple Mail Transfer Protocol (SMTP), defined precisely in an open standard.

Email was the original killer app for the internet, long before we started browsing the World Wide Web or posted cats on Facebook. Email has worked exceptionally well for decades, scaling from a handful to millions of servers, thanks to a few clever, simple, well-defined protocols – and the federated structure that made it possible to scale. But it has also failed to innovate: Large attachments, end-to-end encryption, message integrity, and authentication, receive notifications, guaranteed delivery, etc., are still not available to the average user, even though there were major attempts and a clear need to add them. Today, we’re using centralized, proprietary services like Signal, WhatsApp, or Telegram for some of these features.

Federated U-space

Why does U-space use a federated design? The traditional, national ATM providers (also called ANSP) with their state monopolies were perceived as dead ends: They have not innovated or invested enough in the past, nor did they appear to be capable of doing so. Decision-making was (and is) still very much human-in-the-loop (on the ground and in the cockpit) and thus hard to automate and scale. Clearly, this was not the model for U-space.

The idea was thus to start with the opposite of a monopoly: A competitive environment. Competition would lead to innovation, a high level of safety, low prices for users, and it would scale very quickly. If we’d succeed in creating a vibrant ecosystem, then U-space could instead even become the sandbox or role model for the future ATM or replace it altogether.

In this envisioned ecosystem, many U-space Service Providers (USP or USSP) are to collaborate, sometimes in the same area, offering different features, services, and specializations tailored to their customer base. The many USPs would communicate over the internet. To synchronize, they would use the Discovery and Synchronization Service (DSS), which provides the means to find all other USP operating in the same area, comparable to DNS in the above email example. DSS does not store UAV flight data itself. Crucially, each USP autonomously decides which data to share with or ask from other USPs.

Not all parts of a UTM need to be federated. For instance, weather information, geo-awareness, or fleet management functions can be offered independently by each USP. Synchronization is mainly needed for flight approvals and collision avoidance. These are fundamentally similar problems on a different time scale: While flight approvals look ahead minutes to hours ahead, collision avoidance has a horizon of seconds to minutes. The concept is quite simple: No two vehicles may occupy the same airspace at the same time. Safety buffers are applied in both space and time to deal with uncertainties. If a conflict is predicted, then the plan of at least one of the vehicles must be changed. Flight approvals compare flight plans; collision avoidance compares actual trajectories.

This is a crucial aspect for the safety of U-space: The certainty with which two vehicles can be prevented from occupying the same airspace at any given time.

Federated U-space attempts to solve this collaboratively: A USP checks for conflicting flight plans by contacting nearby USPs. If a conflict is detected, the flight plan is modified until it is free of conflict. For low traffic densities, this can be sufficient, but the more USPs and the more vehicles, the harder it gets to maintain a consistent view of the airspace.

Distributed systems are hard

Distributed systems have some surprising pitfalls that are not immediately apparent. Notably, the intuition we have from centralized systems is often misleading. In the following, we point out some of the problems that arise from distributed U-space along with the topics of technology, safety, and business:

  • Starting with technology, a sudden increase of network latency or complete failure may lead to a USP being detached from the internet. When this happens, flight information and approvals can no longer be exchanged between this USP. How do the other USPs deal with this? Can they simply ignore it, or do they need to wait until the connection comes back up? If the former: What impact does it have on safety, and how to mitigate? If the latter: What is the effect of this on the availability of U-space, given that this adds many single points of failure?
  • The next challenge is maintaining transactional integrity: This describes a property of any database to execute a change without conflicting with other changes that may execute at the same time, thereby corrupting the database. For U-space, this would mean that a user can file a flight plan without ending up with another conflicting flight plan being filed somewhere else at the same time. This is a fundamental aspect of U-space: If integrity is lost, so is safety, as conflicting flight plans may get approved. Integrity is almost trivial for centralized databases but vastly more difficult for distributed systems.
  • Suppose the above problems are infrequent enough that we can try to work around them (this may indeed be feasible initially when traffic volume is low). Then, since inconsistencies are inherently accepted, there needs to be a mechanism to recover a consistent state reliably. This is the problem of finding consensus: Let’s assume there are two flight plans approved by a different USP. One USP clearly needs to delete or change its flight plan and inform the operator, but which one? Consensus protocols are widely discussed today in the context of cryptocurrencies. Unsurprisingly, they are hard to design, implement, and operate. Some are also really expensive and have other negative consequences, such as high transactional latency.
  • The more USP there are, the more we will also have a problem of trust: Is everybody playing by the rules? Who is to judge this? Non-compliant behavior may be intentional: There are, after all, commercial benefits to bending the rules. More often, though, it will be bugs and human errors that lead to non-compliance. This will happen, so we should at least have mechanisms to detect it and deal with it after the fact.
  • Solving the technical problems is complex, making it harder and more expensive or commercially infeasible for companies to become a USP in the first place. Do we risk the opposite of what was intended: U-space is dominated by a very small number of financially very potent players?
  • The commercial aspects of U-space are still quite murky overall: Airspace is assumed to be free to reserve, and users only pay the USP a small service fee. But should airspace in high demand not be more expensive to use? Getting airspace pricing right is extremely important since it helps to create the right incentives and behaviors. While we cannot yet calculate the cost of operating U-space nor know the commercial potential, there should at least be a coarse pricing model: What should be charged, how is the price determined, who pays whom, and how transparent is this? How can such price finding work in the distributed setup? Can airspace be resold or auctioned off, as is common practice in ATM?
  • Finally, the hard problem of fairness: Access to U-space is supposed to be granted under fair conditions. Small users shall not be bullied by big corporates. But what does this mean? There is no objective standard for fairness, no arbitration authority, no clearly designed system of incentives. Who will reprimand or sue users in case of abuse? Apart from the (lack of a) price for airspace, are there any other incentives that deter users from behaving unfairly? How would a user even detect his own unfair behavior? Fairness is far trickier in a decentralized environment.

Email, by the way, has developed interesting solutions to all these problems: Network degradation is not an issue almost by definition since there is no urgency: If the network is down, the server simply tries again later, making it robust. Transactional integrity and consensus finding are not needed as a whole, only between two mail servers, where it is easy to achieve. The problem of trust is the hardest, currently mitigated by a complicated system of individual black and white lists, sophisticated systems for detecting malicious behavior, and historical data. As an example: If a mail server continuously sends large amounts of spam to Gmail, then it will be blacklisted eventually. New mail servers, on the other hand, need to first gain Gmail’s trust by behaving properly. This can take years.

Conclusion

Designing the next-generation traffic management system from scratch is a genuinely hard task. The decision to use a federated, decentralized architecture was made with good intentions: To enable competition and allow the USPs to operate independently and with responsibility. But it introduces a level of complexity that may lead to the opposite result: The technology becomes so complicated that only a handful of (very potent) providers are able to participate, with potential conflicts of interest (cross-subsidization, governmental influence).

Also, the complexity may not be needed: A vibrant ecosystem is easily thinkable if only the aspect of safe flight approval is centralized:  Uniquely reserving a slab of airspace for a defined time span. Everything else can be decentralized or delegated to individual USPs. Quite possibly, we would see a more diverse ecosystem.

To be clear: None of the challenges described here are unsolvable. But distributed systems are much harder to get right, especially when we have high expectations in terms of safety, reliability, robustness, formal certification, and cyber risk security. Realistically, we should probably expect several improvement cycles with this new technology anyway. The risk we face is that these cycles are too slow now or may not happen at all. We may end up with a dysfunctional, or, less pessimistically, too complex and expensive solution, in which only very few large players can afford to compete, or national systems dominate, similar to ATC.

Crucially, it may be hard to recover from such a mess. Consider Email again: The current deficiencies are not from a lack of proposals on how to solve them but a reluctance of service providers to invest and adopt the new standards: There is simply not enough benefit initially. Introducing fundamental changes may similarly fail for U-Space when there is not enough incentive for the individual supplier to do so. It only works if the majority adopts the change, which is increasingly hard to achieve in a federated setup.

There is so much we still don’t know yet about the future drone ecosystem. Manned aviation needed decades of continuous improvement to develop the highly efficient and extremely safe mechanism that we enjoy today. A similar approach for the development of U-space would mean a simpler, less ambitious, less distributed design with fewer functions, aimed at being practical and commercially feasible today.

New Features for PowerFLARM Fusion

We have recently released an update for PowerFLARM Fusion. The release consists of PowerFLARM firmware version 7.04 and FLARM Hub version 1.21. Both need to be updated to use the new features. This is a large release, so let’s dig in.

Simulator

Testing FLARM installations has traditionally been a bit of a chore — some displays at least indicate a healthy data connection to the main unit, but will they also correctly display Mode-S alarms? What about the audio integration, is the audio panel configured correctly? Will my EFB show traffic, and how do alarms sound?

With Simulator, it has just become a lot easier to answer these questions. Simulator can run various scenarios to test different aspects of a FLARM system. Data flows through the entire system: The LCD display on the serial port, the EFB using Wi-Fi, the Traffic Monitor page on Hub, and the audio signal. Simulator tests all the connected system components for proper connection and configuration, like the baud rate and the protocol version.

Available scenarios range from simple (single FLARM-aircraft) for testing basic traffic displays to more complex with multiple concurrent aircraft using FLARM, ADS-B, and Mode-S. Alarms for obstacles and alert zones can be simulated as well.

Simulator always uses a simulated position in the middle of the Pacific Ocean (to be precise: 48°52’S 123°23’W). This makes it obvious that a simulation is running when using Fusion as the position source, e.g. on a moving map. Once started, each scenario runs independently for 30 seconds. All outputs of Fusion can be observed while it is running, including the Traffic Monitor in Hub:

Task Declaration

Task definitions for glider competitions can now be declared directly in Hub, either by editing the waypoints manually or by uploading a declaration file. The editor allows to review, edit, delete, and commit a task to the flight recorder.

Hub also accepts task declarations in text files like they were used in previous products.

Independent of the method, the task is activated by restarting the device. It will appear in IGC flight logs started after the restart.

Other Features

Support for the Garmin TIS protocol has been added on both data ports. This was a popular request from pilots using the mobile Garmin units such as the GPSMAP 695. No license is needed; the protocol can simply be activated in the configuration. You also need to set the correct baud rate (9600 bps) for Garmin TIS to work.

For glider pilots, support for the popular Naviter Oudie instrument was added. This uses Bluetooth to stream traffic and navigation data from Fusion. For gliding competitions, Random ID was improved to improve anti-leeching.

Download

For a complete list of features and bugfixes, please read the full release notes (Hub, PowerFLARM). To download the firmware, head to the Firmware Updates page.

A word on maintenance

On November 7th, a mid-air collision occurred over Mount Diablo, California, between an ASW-20 and an ASW-27 glider. Both gliders had a PowerFLARM installed, but one was not functioning due to an expired firmware. Luckily, both pilots survived by bailing out.

But why does the firmware expire in the first place?

This is our current approach to managing change in the highly distributed system that is FLARM. Unlike with other IT systems you may know, we cannot gradually update the population of FLARM devices since they all need to talk the same language (the radio protocol) to work. Firmware expiration allows us to change and improve the radio protocol safely, without rendering part of the devices dysfunctional.

Ok, so when does the firmware expire?

This is stated in the Release Notes. The published, most current firmware always has an expiration date of at least 14 months in the future. Hence, simply updating once a year as part of the annual maintenance will be just fine.

We know that maintenance is a tedious chore, especially since we only do it once per year. Remembering and doing the necessary steps each year requires a deliberate mental effort.

To facilitate the process, we have recently released the Instruction for Continued Airworthiness (ICA) document. The ICA is a beefy document that contains a lot of useful information, but the core of it is really small: The annual maintenance checklist, found in Appendix B. It contains the following points:

  1. Verify proper installation and secure mounting of installed parts.
  2. Verify that all antennas are correctly installed/placed and are not damaged.
  3. Verify that antenna cables, wiring, and connectors are  undamaged, unbent, have no corrosion or signs of water, and are correctly installed.
  4. Check if the range has deteriorated by performing a Range Analysis.
  5. Reset the Continuous Analyzer of Radio Performance (CARP)
  6. Update the FLARM firmware
  7. Update the display firmware, if applicable
  8. Check the release notes for changes. Do you need to update the configuration?
  9. Update the obstacle database if installed
  10. Check for errors during the startup sequence.

That’s it, really! Going through these 10 points once a year should be sufficient to keep your FLARM in working condition.

Read all about the accident mentioned above, including a thorough analysis by Ramy Yanetz, in the November PASCO newsletter.

First PowerFLARM Fusion delivered

Today, Patrik Eichenberger and his Flight School based in Buttwil, Switzerland, took delivery of the very first PowerFLARM Fusion with the special serial number 1. It will replace an existing PowerFLARM Core in one of their Cessna 152 trainer airplanes, where it will deliver collision warnings and traffic information on both a dedicated FLARM display and an iPad running the Air Navigation Pro app.

“PowerFLARM Fusion is a clever upgrade of our collision avoidance instrumentation, allowing us to connect the iPad directly. This makes our installation simpler and less error-prone. Honestly, configuration and maintenance of the old PowerFLARM Core was always a challenge since the device is not easily accessible”, said Patrik Eichenberger — while casually updating his first Fusion to the latest firmware on his phone.

Introducing PowerFLARM Fusion — Back to Simple!

Over the years, many features and details have been added to PowerFLARM, making it harder to understand what is going on: Is the configuration correct? What firmware version is installed, and does it need updating? Was the log file written to the flash drive? What does a solid amber light mean again? Oh my.

PowerFLARM Fusion brings simplicity back to FLARM.

An integrated Wi-Fi module hosts the FLARM Hub web application, making configuration and troubleshooting painless. FLARM Hub is a user interface for mortal humans: It runs on any computer or mobile device, offering a clean, modern, and intuitive user interface. Traffic data can be streamed to navigation apps and EFBs over Wi-Fi or Bluetooth. The range analyzer is built-in — no need to juggle IGC files anymore.

Of course, Fusion integrates the latest PowerFLARM technology, operating worldwide with optimal performance in every region. It comes fully loaded with all the features, no need to deal with options or license files. Upgrading an existing PowerFLARM Core installation is straightforward, as the dimensions are identical.

Also, it is orange.

Please read up on all the details about PowerFLARM Fusion on our product page.

 

 

 

Foca’s Detect-and-Avoid Dilemma

NZZ today published an article citing a recently released report by the Swiss Accident Investigation Board (Sust) on a near-miss between an A319 and a drone. The vertical distance was 10 m – scary stuff! While this was (likely) an intentional action by an irresponsible individual, we will certainly see more of this soon due to the increasing use of drones for useful purposes.

So how do we prevent such disasters from happening?

A Foca spokesperson was further interviewed in the article. TCAS and transponders are quickly ruled out as being too bulky, too power-hungry, and too expensive. Also, TCAS is a safety-critical system that safes lots of lives, today. Can we really risk to introduce many more transmitters to the same frequency band, thereby potentially reducing the effectiveness of TCAS?

The upcoming traffic management system for drones (called U-Space in Europe) will solve the problem eventually, but there is still a very long way to go: The federated, distributed approach that is currently adopted uses the internet as communication backbone. Robust network access is thus required for all participants of U-Space, which is no small feat for an airliner moving through the air at 150 knots. Federation also means that the overall complexity will be much higher compared to a centralized system to achieve the necessary standards for reliability, availability, and safety.

So what else? FLARM is mentioned as a promising technology, but lacking an open standard. But such a standard exists and can be downloaded here. Unlike other standards for Remote ID, our proposal does not use the 2.4 GHz frequency band that is so densely used and limited in achievable range. Based on our standard, Detect & Avoid and Remote Identification applications can be built that provide the performance needed to protect the crews and passengers in airliners. No need to wait for the future.

Kollionsgefahr: Passagierflugzeuge sollen vor Drohnen gewarnt werden
Summarischer Bericht
FLARM UAV eID Standard

Swiss Army procures Lockheed Martin’s Indago 3 drone with FLARM for SAA

The Swiss Army just announced the procurement of Lockheed Martin’s Indago 3 reconnaissance drones. These vehicles carry a miniaturized FLARM as part of their sense-and-avoid suite. Nearby manned traffic will be displayed to the drone operator so conflicts can be easily avoided. Likewise, the drones will be visible to manned traffic as well.

This is another strong argument for technical diversity in electronic conspicuity: No single technology is capable of covering all the use cases. The integration of a FLARM system is simple and inexpensive. There is no need for an expensive and unreliable infrastructure for rebroadcasting signals – it just works.

Press release: Swiss Army Chooses Lockheed Martin’s Indago 3 UAS for Tactical Reconnaissance and Surveillance

Media coverage: AGEFI 2020/09/11