Roundtable "Potential of OSS for ATM" - Jointly organized by CALIBRE and EUROCONTROL
Previous 7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France Next

Home

Intro

Programme

Synopsis

Abstracts

Participants

Debriefing

Glossary

Organisation

Short bios

Thanks

Follow-up

Experience Report
on www.OpenATC.org and AudioLan

by Gilles Gawinowski, EUROCONTROL

Overview

I started working with AudioLan around ten years ago, in 1995. AudioLan is a Voice Over IP (VOIP) system for Air and Ground Communication. At the time, voice over IP was a relatively unknown, pioneering technology, and our work was to see how this technology could be applied to our domain. Two OSS kernels were available: one from Berkeley and the other from INRIA. We used these two kernels to develop our radio and telephone system.

The software had to be customized for EUROCONTROL's needs and requirements, both in terms of features, and in terms of environment. For example, a supervision tool and a recording tool were needed. The architecture was reviewed in order to facilitate software maintenance and industrialization, with outsourcing objectives.

Other discussions address code quality in OSS, but our experience has been shades of grey, not black or white. Our reason for using these open source kernels is that it gave us free access to the efforts of academic research in the VOIP domain. The quality, architecture, and languages chosen were perhaps less appropriate for our mission and the industrialization requirements we had.

For us, it was a success. The system was deployed in 10 European sites, with about 500 positions. It was then proposed as freeware to industry and research centres, in order to disseminate our research. 10 licenses agreements were signed with industrial partners, which stipulated that we were giving this software for free, but that they should contribute back any modifications they make. The goal was to have a win-win mechanism.

The next step was industrialization. In this step, industrial enterprises re-engineered the industrial design, to deliver features according to user requirements. What we delivered as a white box became converted into a black box. Why did this happen? In part, because there is some ambiguity about our mission as a public research centre. When we develop interesting technology that will be used by our clients, we need to take into account issues like support, installation, maintenance, and continued development of the software. The role and mission of a public research centre is to make innovation and promote this innovation. It is not to become an industrial actor, we don't want to support, install, or maintain the innovation afterwards.

Thus industry is the key factor to promote and use the research results. However, in the process, the open source research project is irremediably lost. In our experience, each customer has completely re-engineered our software and turned it into a black box. The OSS philosophy is lost, and the product again becomes proprietary. The cost for clients remains the same, compared to former products, since the added value industry provides is quality process, documentation, support, and responsiveness. The advantage to the client is the access to the innovative technology resulting from the research effort -- in our case, clients can switch from traditional telephony to communications based on Internet protocols using VOIP.

We can now fast-forward to around 6 years ago, in 1999, when we tried to create a community of researchers on the OpenATC project. Two research centres collaborated to develop a research community in ATM through a forum. The objective was to stimulate Air Traffic Control research and development by providing an easy way to share resources. We wanted to create a community, with not only software researchers, but operational people as well. Above all, we wanted to stimulate the exchange of ideas about the future of Air Traffic Management systems.

We created a web site for free software. Initially, everybody was quite enthusiastic about making interesting software available on the site, but we rapidly observed that when the strategic value of the software was high, the software wasn't posted on the site as freeware. Specifically, some participants raised a distinction about "added-value software", and tried to use that to cut a commercial deal with industry. While open source is a nice philosophy, when we have more concrete constraints in terms of political and strategic issues, and especially when money is involved, the philosophy changes.

F. Gasperoni: Gilles, could you define "freeware"? For me, freeware is neither OSS nor free software. So I would like to hear your definition.

G. Gawinowski: I am not a specialist. What we observe is that there are a lot of definitions, and different perceptions and understanding about what it means. I will come back about the possible ambiguity between the objective of a research centre about software and the open source community.

F. Gasperoni: So the binary code was available as freeware without a licence.

G. Gawinowski: There was no licence and no constraints.

F. Gasperoni: If there is no licence, you cannot use it. But anyway...

G. Gawinowski: The objective was to create a community, not open source for open source.

OpenATC failed. Why did it fail? the main negative factor is the fact that the ATM research community is too small: probably less than 1000 researchers in this specific area.

Besides that, at EUROCONTROL, research is no longer the core business. There has been a drastic reduction of research centres over the last ten years and software development is now often outsourced. There are only two research centres with sufficient research mass left in Europe. Some former research centres have become more IT service providers, some have become private companies. This EUROCONTROL research centre has few software engineers compared to ten years ago; now more of the personnel are managerial or operational.

Another problem has been the "not invented here" syndrome. Opening up code opened up a lot of duplicated efforts, reinventing the wheel. Many participants preferred to promote their own software rather than improve somebody else's software.

As for ATM research in general, six or seven years ago, there a were a series of European Commission project initiatives to get the various parties involved together to work on interoperability and plug and play. This was just a dream, though, because now, after the intervening years, we can see we failed totally.

Their idea was to standardize the middleware, the API, and the applications. They wanted to force the industry to standardize at least these two components. Now we can see that the industry has not been following the game. They have been involved in these projects to observe, maybe learn something, and receive grant money. But there is not a single industrial example of standardized or common ATM middleware. None of the industrial players use the standard API either. In terms of applications that we wanted to promote on OpenATC, there were a lot of duplicated efforts, but no real idea of a community working together to try to push one application shared by all.

Therefore, in terms of middleware, API, and applications, there were maybe some limited successes, but when we observe the situation today, we need to recognize that we failed.

The question remains: Is there a future for OSS in the ATM area? There are issues:

What are the interest and quality of an OSS product in terms of architecture, functions, and interface, as well as support and maintenance? There has been a drastic reduction in ATM research centres, there is no critical mass. Most IT here has been outsourced. In any case software is no longer a core business of EUROCONTROL.

Our perception is that often, OSS is just opportunistic. It's just a freeware to capture clients and then to become proprietary under the pretext of additional features, like Skype. Some OSS wants to capture clients just seduced by the "free" religion. My opinion is that rather than accepting OSS as religious faith, we should ask what should be the added value to try to push open source in our specific environment. Some companies make software free for commercial opportunity.

Our market is small, with just a few key players in the industry. At the risk of being provocative, in my opinion there is no sign of evidence for an OSS future in the ATM area.

Beyond religious dogma, what are the objectives of an OSS approach? At a minimum we have our performance requirements, which are to make future ATM systems in terms of traffic capacity, efficiency, security, and environmental considerations. To meet our research objectives, we try to create something useful, and make public, transparent, understandable, and available.

These objectives may look like OSS but maybe they have nothing to do with OSS.

In my opinion as a computer science guy, who has been involved in technological project and OSS initiatives, the ATM research problem is not a technological issue but an operational one. Our main problems today are not technical, but operational. That is why I do not see how OSS can answer properly our problems.

Discussion

from 19'42" to 35:42" (16'00")

F. Gasperoni: Could you define "operational" in this context?

G. Gawinowski: Let's look at the difference between avionics and ground systems. There are few different avionics designs, just two big manufacturers' standards. In avionics, the design is driven by the manufacturer, because the aircraft is a technical object.

In our area, the situation is quite different. We have to deal with over 50 different ground systems in Europe, because the requirements are driven by the users. The ground system is essentially based on the human operator, with his human ability to manage the situation. Thus, while ATM systems initially appear as very technical systems, they actually are human systems.

This human path is essential. When we use the word "operational" we mean the modus operandi. How does this teamwork operate, how do these individual human operators work together? It's more a question of working methods rather than technological issues.

S. Swierstra: ATM hasn't changed much from the seventies. The controller still sits behind a screen that gives them the positions of the aircraft approximately 5 seconds ago. In the '70s, the screen could only display green labels. Now, modern colour screens can display the labels in green as well.

J. Feller: The failure of www.OpenATC was a failure of community, not technology. It looks like OpenATC turned into a place for "show-and-tell", just a place where people could show off their code. Since you said you were provocative, I will be provocative in return: I would argue that the basis of the failure lies in the final slide. Instead of building something useful and making it public and transparent, you need to build something open, public, and transparent, and use the community to build the useful something. If you have essentially closed teams going off, building things, and then saying, "look what we've done!" then open source will never work. Show your mistakes, that is how you are going to learn.

G. Gawinowski: There is not a critical mass of ATM researchers to create an open source community. There are perhaps 1000 ATM researchers throughout Europe. Of them, even fewer are software engineers.

J. Seifarth: Why was it not possible to mandate that the APIs be published and more standardized APIs be used, when the contract for industrialization is written?

G. Gawinowski: Our previous attempts resulted in a monopoly situation. Either we try to regulate the market, or we let the market organize itself. The latter is the current approach, and we can note that in Europe, there are only about three key industrial players. These competing players have no interest in standardizing the API. They try to get clients to customize the software for their proprietary systems.

M. Bourgois: Around seven years ago, there was a lot of pressure from the Commission and from EUROCONTROL to establish common middleware, so that individual components would be more modularized. Service providers would be able to recombine these modules from different vendors, thanks to the common middleware and APIs. EUROCONTROL invested quite a bit in that, and Bretigny was a leading player in that effort. We have an ongoing project for building a common architecture, whom we have not invited today. We may be underestimating the value of that effort, but there was no obvious way to link it with open source.

J-P. Florent: The situation has changed in the intervening years. Since future systems are developed at European level instead of national level, we can hope that things will change.

P. Kappertz: I think there is an important issue missing. We are discussing from a user point of view why OSS is relevant or useful. But the missing point is why should the industry support OSS? What is the interest for the industry to support the OSS concept? You are only discussing the situation where the research results are given to the industry, but the industry is also developing something and it has to be paid for.

M. Bourgois: Let's leave that question pending now, because we have other interventions today from an industry viewpoint.

R. Schreiner: Were the problems with the common architecture technical or political?

G. Gawinowski: I think it is not a technical problem.

R. Schreiner: If you had community problems with this middleware, the problems with the open source community will be worse. In our experience, many in the community surrounding an open source project are just greedy. Many open source tools are used in industry by organizations who not only don't contribute to the project, but who aren't even willing to contribute their experience with the software as a success story.

M. Bourgois: For middleware, it's clear that the idea hasn't taken off. For architecture, the verdict is still out.

Why was the AudioLAN development work re-engineered by each participant? Why went wrong in that scheme?

G. Gawinowski: To a large extent, simply to meet their individual needs, and partly just because they could tinker with it, again reinventing the wheel.

The level of commercial and competitive constraints varies with the level of the software involved. For instance, in graphics libraries or operating systems, ATM can benefit from open source. As we approach the core business of ATM, the working methods and the tools, like conflict detection and resolution algorithms, are the core business of industrial entities.

M. Bourgois: Maybe we have to back on this issue when we discuss about business model, because it does not make sense for business to reinvent just for the pleasure.

P. Johnson: We need to look separately at two areas: research area and base technology of ATM.

P. Crebassa: The level of issues derived from the competitive situation depends on the level of the software we address. If we get closer to the core business ATM, for example conflict resolution algorithms are the core business of industrials and this may be the limit of the ATM communities and the open source principles.

G. Gawinowski: Software work like development of the graphics libraries, which I think is interesting, useful, and was consistent with some strategies 10 years ago, is no longer relevant to EUROCONTROL's current core business focused short-term strategy. Given such a trend, it is may be less relevant to think about open source today.

P. Crebassa: It seems French ATM R&D strategy is maybe a bit different from the other in Europe. So far, we consider that in essential topics like HMI or graphics, we still need some innovative capabilities.

Salient points

 
Gilles Gawinowski
 

"The ATM research problem
is not a technological issue
but an operational one."

Abstract Slides MP3 OGG
abstract slides MP3 OGG