7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France
Hypotheses about OSS in ATM
by Marc Bourgois and Jean-Luc Hardy, EUROCONTROL
Overview
The past year has been a year of discovery for the Open Source Implications For EUROCONTROL (OSIFE) project. We've been discovering contacts like CALIBRE, the principles of open source, and what has been done in EUROCONTROL and ATM before. We've come up with four hypotheses, which we will develop in more depth below. Observing the open source paradigm shift, the objective of the study is to determine how, if, and when OSS will impact the business of ATM.
The scope of OSIFE study is limited to ATM applications. We specifically exclude administrative and office software, as well as ATM systems infrastructure. Our focus is the applications layer for open source ATM software, i.e. Secondary Software Sector (SSS).
We started by reviewing the popular, technical, and scientific literature on open source. We defined the major hypotheses, and have been gathering facts and arguments on these hypotheses. Today's roundtable is the fruit of this preliminary work: we've gathered a series of open source and ATM specialists and actors in the area to analyze case studies. The prioritization of these efforts will be the result of today's meeting.
2005 has been a year of networking. A lack of awareness was discovered within EUROCONTROL. We observed that there were many people who had done something similar, not only within EUROCONTROL, but in industry as well. It's interesting to note that most attendees of this roundtable are from industry partners, not from research partners.
We've distilled a series of four hypotheses from our preliminary work, which should be validated or disproved by further work. We will now take a closer look at each.
The first hypothesis is perhaps the most important, given the role of EUROCONTROL: Open source can be a facilitator for better harmonization and improve interoperability. Traditionally, EUROCONTROL has tried to achieve interoperability between different ATM systems in the various member countries. These ATM systems are country-specific, with their own national suppliers and customized software. The task of EUROCONTROL has been to integrate the different systems.
Standardization attempts have met with limited success. Some successful standards include data formats for radar and coordinations between ATC centres, but they have been few: since EUROCONTROL has been established, a maximum of 6 standards have been created. Several have been very successful, but they have not solved the interoperability problem.
In the '90s, the European Harmonization Program tried another approach: EUROCONTROL developed the software, and gave it to all the partners. The idea was that this would improve harmonization, because everyone would be running the same software. Examples include ARTAS, a radar tracking system. EUROCONTROL stopped that approach, since we were pushing other suppliers out of the market and creating monopoly positions to the dismay of the European Commission.
The third approach involved multiple developers competing. Several smaller projects used this technique, with several development contracts concluded with different companies. Consolidation within the sector resulted in mergers between the former competitors, so we were back to square two, with a monopoly situation again.
A better approach to harmonization could be that we finance or facilitate open source ATM kernels that implement core functions. These standard kernels could be adopted throughout Europe, and maybe even other regions if they are successful. This would, of course, have an impact on business models, as we will discuss later. An example for this interoperability hypothesis will be discussed in a talk on a white box trajectory predictor, later today. EUROCONTROL is introducing another round of harmonization with the SESAR program. Perhaps OSS could be an alternative to market domination or hard core standardization, which is limited to interface definition, and which has not brought the full scope of benefits we had hoped for.
The second hypothesis concerns quality: the quality of complex ATM software could be maintained, if not improved, through OSS development methods. Quality covers two fundamental issues in our domain: safety and security. We must be sure that safety and security are at least maintained at current levels.
Over the year, we had hoped to learn about quality issues from research, but not a lot of research actually has been done, and from what is available, the issue is not black and white. It would be worthwhile to investigate OSS quality influences, identify the variables involved, and determine their impact on ATM. For example, how does quality vary with the number of developers? The ATM community is small, but highly professional. How will a small, tightly focused community influence the quality spectrum?
There is a rather controversial argument that the safety criticality of ATM software is low, in contrast to the safety criticality of avionics. ATM controls the separation of aircraft. In the normal state of the system, the aircraft are separated. If the ATM system goes down for several minutes, the aircraft will still be separated when the system comes back up. The safety criticality situation for avionics is quite different -- real-time responses are required. Thus safety considerations are different in airborne and ground-based systems.
S. Swierstra: As air traffic increases, there will be more integration with air traffic systems, and ground-based systems safety will become more important. More demands will be placed on the intelligence of ground systems, which will have safety impacts different from those we have today. Another safety argument is that the integration of airborne and ground-based systems is such that to add new equipment, one would have to certify ground-based systems like we certify avionics. However, certification of ground-based systems to meet end-to-end certification requirements would be massively expensive. >Sip>
Our hypotheses concerning safety and security are defensive: we want to make sure that by introducing OSS in ATM, we are not opening ourselves to new risks. We are essentially hoping that having more eyes on the source code can only improve it.
From a security perspective, we assume, and verify regularly with audits, that the ATM system is completely isolated from other networks. The ATM systems are integrated with each other, but are not integrated with wide-access public systems.
Our understanding of the business model is weak, and we hope that today's speakers will improve our understanding. The ATM application providing industry is quite small. The market is fragile, with big companies as major players, but which don't seem to make much revenue from such systems. The software is highly customized. Unlike aircraft cockpits, ATM controller positions are not standardized, with variations from country to country, and even between different software clients. This entails extra costs, but whether these costs are generating profits for the manufacturers is unclear.
We must address the issue of what business model makes sense if the ATM kernels are open source, and financed by all the parties, i.e. by EUROCONTROL. The revenue would come from what? The services and fringe products around it? It would be worthwhile to examine what the ATM industry would look like if the kernels are open source.
A major problem that has confronted EUROCONTROL is appropriation by suppliers. We pay for the development, over many years, and unavoidably create a monopoly, or pay for the development twice. We end up paying for the development, then paying for the product. We loose control of the software. It's not just lock-in, it's complete appropriation of the software.
EUROCONTROL is a public service. Everything we do should be in the interest of the public, in the interest of our member states. This goes beyond operationally usable software, to experimental and research software. At ATM research centres, software is developed for experimental purposes, and once the experiment is finished, this software languishes unused. There is outside interest in having access to this software. This would only have benefits for us. If we were to make it available, we would at least archive it and be aware that it exists. If we had a systematic way of opening up this software, it would not only benefit us, but our research and commercial partners as well. There is a counter-argument from our project managers: this internal research software does not necessarily have quality standards commensurate with EUROCONTROL's image.
An interesting parallel can be made with another release of intellectual property rights, in a domain far removed from ATM and open software. The BBC is releasing footage from their archives, and is on the verge of releasing even more material, including video and drama for which they have the IPR. Their argument is that since the public paid for this work, it should be available as a public service for the public to use creatively. They feel that there is an interest in the media community to create new productions, documentaries or films, based on existing material. For that to be possible, the existing material must be openly usable from an IPR point of view. The BBC has used their mandate as a public service to justify the release of the IPR.
This same public service argument could also be valid for EUROCONTROL, at least in the research community. Since the research was paid for by public money, there is no reason why these tools should not be placed at the disposition of other researchers.
P. Johnson: EUROCONTROL should apply E. S. Raymond's law of "release often, release early". There's no problem in releasing with a 0.x release number, stating explicitly that it's an experimental prototype. The essential point is to release something! >Paul>
Salient points
- We have identified four hypotheses:
- ATM harmonization will be facilitated
- ATM quality will be improved
- ATM industry will change but continue
- ATM public service obligation will be met better
- OSS could be the best approach to satisfy an important role of EUROCONTROL, which is to achieve interoperability and harmonization in ATM.
- There is not a lot of research available on the subject. How will a small, tightly focused community influence the quality spectrum?
- Our understanding of the business model is weak. What business model makes sense if the ATM kernels are open source?
- Since the research was paid for by public money, and EUROCONTROL has a public service mandate, there is no reason why these research tools should not be placed at the disposition of other researchers.
"A better approach
to harmonization could be
that we finance or facilitate
open source ATM kernels
that implement core functions."
 |
 |
 |
| slides | MP3 | OGG |