What is AVENUE Compliant ESCAPE?

 

Dave Young interviews the ACE Project Manager, Anthony Inard.

 

 

Anthony, I’ve known you now for several years but due to your discretion know very little about you. Would you like to introduce yourself?

 

Why not! I’m French, grew up by the sea in the Indian ocean and studied around to get my French and a bit of American University education. I’m now approaching an age of relative maturity (36) and have a 5-year-old son teasing me about my grey hairs that start to appear... I’ve been working in the Real Time Simulator Development domain for 8 years now. My very first task at the Experimental Centre was to introduce the notion of distributed system design to the EEC’s Real Time Simulator, which as I am sure we will address later, was a very interesting challenge at that time.

 

We are now entering into the ACE era, which if I recall correctly is the 7th generation Real Time simulator of the EEC. To set up the scene and preferably in simple terms, can you introduce us to ACE?

 

I think EUROCONTROL have always been champions of TLA’s (three letter acronyms) and ACE is another fine example. ACE in fact stands for ‘AVENUE-compliant ESCAPE’ and as you correctly calculated, is the 7th generation of facilities at the EEC. This new generation of ATM real-time simulator has been developed within the EATMP framework by the ERIS programme from September 2001 to September 2002. As its acronym indicates, the ACE platform is built upon a previously released and much abused version of the ESCAPE platform, the main evolution being the adoption of the AVENUE architecture. This standard architecture consists not only on specific logical module decomposition but also imposes the use of dedicated API (Application Programme Interface expressed in an OMG-based standard language called CORBA IDL).

 

Clearly, acronyms are rapidly replacing common language, so maybe you could explain some of the more important ones, for example ERIS, ESCAPE, AVENUE and OMG…….

 

ERIS – for me, without any doubt, you’re facing here the trickiest acronym at the EEC!!... Just remember ERIS as the host programme for the production of the EEC ATC simulation facility.

 

ESCAPE – EUROCONTROL Simulation Capability And Platform for Experimentation, the EEC’s first open system that served as a foundation to subsequent activities.

 

AVENUE – An ATM Validation Environment for Use towards EATMS

 

OMG – Object Management Group, the standardisation body for open systems in a multitude of domains, including transport, formed by a very large number of major companies.

 

 

OK, I give up with the acronyms! What exactly is this AVENUE architecture? Where does it come from? It does sound particularly complex to the uninitiated……..

 

To summarize, AVENUE is a standardised architecture for ATM validation platforms. ‘Standard’ in this context means that it is a commonly agreed view among several key actors (ATM Supply Industry, ATSP and R&D establishments) within the ATM domain.

 

The best analogy would be that of a box of Lego bricks…. They are of different colours, forms and sizes, but due to the common interface, can be assembled into many different toys…. AVENUE, simplistically viewed, provides a number of standard bricks (logical modules) and the interfaces that allow them to be assembled together to provide different levels of ATM functionality….. approaching “plug-and-play”, a term that many fear!

 

To give a brief history, the AVENUE project was launched in 1997 by the European Commission (EC) in the context of the 5th Framework Programme, following work performed in the 4th Framework under the name of PATIO. A consortia comprising key European partners drawn from Research, Air Traffic Service Provision, the ATM supply industries and the EEC worked together to achieve the identified goals until April 2001 when the project was completed. The main objective of the AVENUE project was to deliver a logical architecture (supported by a set of defined APIs) for a platform capable of validating new concepts and functionalities for ATM in both simulation and real-world demonstration. In addition to the architecture definition, the EEC and the ATM supply industries supplied one or several components that were successfully assembled into a demonstration platform, thereby building confidence that the resulting architecture was not only paper exercise, but also could actually support ATM simulations and evaluations.

 

But why are we moving onto AVENUE architecture? What is the rationale behind that strategy when we have ESCAPE?

 

First, I would say that I’ve always seen AVENUE as the next natural step in the simulator evolution. When we look back at the more recent simulator development history, we moved from a monolithic, big-blob SIM5+ platform into an open architectured, CORBA-based ESCAPE platform in 1997 to combat the limitations inherent to architectures of that nature.

 

Although an excellent tool for the HMI and behavioural flexibility necessary in supporting the multitude of different requirements from the customers of organisational simulations, we had little to no functional flexibility within SIM5+, into which the introduction of new functionality required major work, disturbing large proportions of the global platform software, proving costly, particularly time consuming and inefficient. Its modularity was quite poor but equally, we relied on proprietary communication protocols, parts that were almost always affected by the changes.

 

At that time there were visionaries at the EEC who recognised the necessity to evolve the system to facilitate the notional introduction of “plug-and-play” functions into a common architectural framework. This coincided the EATCHIP III period, where Operational Requirements Documents were being developed for a number of “advanced” functions. To ensure that these new concepts be developed and integrated into the centre’s simulation facilities, it was essential to create an adequately open and distributed system favouring the notion of “plug-and-play”.

 

Hence the birth of ESCAPE. We were finally able to enrich the platform more efficiently than before, with less disturbance to the overall system, and through the introduction of the CORBA standard communication protocol, were able to focus software development on the ATM domain, simplifying both system and integration aspects. This was leading edge at the time, especially in ATM and although we had come up with a nicely distributed system with modular ATM functionality, our ATM data model and general platform architecture (service interfaces) were still largely based upon the legacy system. CORBA had obviously brought standardisation to our architecture but certainly not to the ATM domain side. ESCAPE was still a proprietary, CORBAised version of SIM5+….

 

And this is what AVENUE is about, pushing standardisation farther, or probably more modestly, initiating standardisation?

 

Absolutely. Although the AVENUE data model and platform architecture is built upon CORBA, it differs from ESCAPE in its recognition (as commonly agreed pre-standard) from a large number of key players in the European ATM community. We can now claim that our platform relies on standards in both domains, technically (with a CORBA middleware) and functionally (with the AVENUE data model and service interfaces). In fact, it is now sited as a reference or foundation for formalised standardisation with the European Standardisation bodies….

 

And where are the benefits of that?

 

I would split the benefits into 2 categories. Firstly, by providing and maintaining this commonly agreed architectural foundation, it strengthens EUROCONTROL’s supporting role to the European Commission’s objectives in the areas of interoperability and standardisation. This standardisation will allow the controlled evolution of the foundation in close partnership with the ATM supply industry, providing a common view of the ATM system architecture, which will ease development and integration of future ATM products and components. The adoption by the supply industry of this foundation will greatly accelerate the transfer of products of research into operations and contribute largely to a more flexible and progressive evolution of the ATM system.

 

Secondly, the benefits for the ERIS programme itself. This commonly agreed framework favours industrial partnerships, allowing ERIS to move away from pure software development and to re-focus its activities upon the ATM research domain, whilst providing the necessary support to international standardisation.

 

But is there a benefit to the platform users, to the industry at large?

 

At first sight, you may think that architecture standardisation does not bring any advantage to the platform users… Effectively this should be transparent to the end user.

 

For many years, the EEC suffered from an image of a “dream factory” by the supply industry. This had both positive and negative connotations attached… On the negative side, many users found very promising ideas at the EEC and assumed that these were readily available, off-the-shelf from within the supply industry. As these were prototypes built upon in-house solutions they were often frustrated.

 

This situation will now change. With greater industrial participation, the users will have better access to industry-based ATM products which provide experimenters with both a credible and operationally proven foundation upon which they can integrate new prototype functions in support to the concept evolutions, something that was hard to envisage at the time of SIM5+….. Equally beneficial is that the supply industry will have access to the new functionality and therefore be in a position to prepare for their product evolutions accordingly.

 

To bring one example to the forefront, ACE2004A (the version of ACE to be delivered at the end of 2003) will include an advanced trajectory predictor (TP) from INDRA that will enable, for example, advanced AMAN experimentations with controller time input orders.

 

Still thinking as a platform user, what are the implications of using the ACE platform?

 

Compared to current ESCAPE platform, we have developed ACE to maximise the re-use of existing hardware when migrating from ESCAPE. Indeed, all pilot (PWP) and controller (CWP) working positions, that is to say, a large proportion of the hardware composing an ACE installation, will be kept as ACE will run these on either HP-UX 11, SUN-Solaris 8 or PC-Linux. However, using ACE will have an impact on the GROUND system hardware since its applications (FDPS, RDPS, ATC tools, datalink and Supervision) can be run exclusively under SUN-Solaris 8.

 

Anthony, it certainly looks as if you and your team have been very busy over the last few years and I understand that ACE will be delivered to the Gate-to-Gate European Commission project of the 5th Framework Programme shortly. So what is next?

 

Vacation maybe, sometimes in 2005!....

 

 

For more information, click on this link to see a brochure about ACE (warning 4 MB).

 

Or contact Anthony Inard.

 

ERIS Business Area