Mediterranean
Free Flight - "Air Weeks" Real-time Simulation
Andy Barff
and Luca Bellesia
1. Background
In the
Mediterranean Free Flight (MFF[1])
project we were facing a serious risk and we had to devise a risk reduction
strategy. As you may know, MFF is an ambitious project involving advanced
Airborne Separation Assurance (ASAS) applications and a technically complex
simulation facility in Rome known as the Ground ATM Testbed. This facility is
based around the ESCAPE simulator and a full fidelity cockpit known as the
Autonomous Aircraft Simulator (ACS). In addition to these elements which are
co-located in the ENAV Experimental Centre there are links to additional
facilities including the Rome ACC at Ciampino and two additional cockpits; the
Multi-cockpit Simulator (MCS) in Brétigny and the Research Flight Simulator
(RFS) at the NLR facilities in Amsterdam. It was summer 2002 and we were
planning the second MFF large-scale simulation due to be conducted in February
2003 (MFF RTS2). We were expected to include all three cockpits in the
simulation exercises to enable us to study the effects on flight crew of the
MFF ASAS applications. This is an obvious requirement where new tasks are being
allocated to flight crew, having a major impact on both aircrew and the
controller team on the ground. The ESCAPE simulator facility in Rome has 13
control positions and 10 pseudo pilot stations, so with the addition of
potentially 3 cockpits, the result is quite a large, complex, simulation
configuration. What concerned us was the number of people that would be
involved plus their location in 3 different countries. We estimated that entire
team would include over 30 participants (controllers and pilots) plus around 20
simulation staff - all of whom would be wasting their valuable time should we
hit technical problems. In addition it is notoriously difficult to
"script" situations in large simulations where controllers acting in
the most appropriate way for the situation may dramatically modify expected
traffic flows and aircraft interactions. That’s why it was very difficult to
create the situations we needed to study the cockpit in simulations where the
main focus lies with the ground system evaluation. One may wish to evaluate
specific manoeuvres in specific situations – such as an ASAS Station Keeping
between two aircraft - but since the controller is handling the traffic in his
own way you never know whether this situation will ever happen. You may end up
with cockpit simulators never being involved in an ASAS manoeuvre because the
situation isn’t appropriate for such a manoeuvre. Suffice to say that it seems
generally better to separate the airborne and the ground-based research
objectives into different simulations.
2. The "Air Week" Solution
Therefore
MFF Working Area 4.5 - Human Factors under the leadership of Dirk Schaefer
proposed to separate "Ground" aspects from "Air" aspects by
devising a complimentary simulation to follow on 1 week after the main
simulation. This simulation ran for 2 weeks and became known as the "MFF
Air Weeks" simulation. Due to the weight of work on the main simulation
team under Andy Barff much of the preparation of the "Air Weeks" was
delegated to WA4.5. The NLR agreed to carry out the simulation design and
provide the Rome team with detail scenarios that could be re-created in
specific traffic samples. As the airspace environment for the main ground
simulation was still under development it was decided to take one of the
sectors from the 1st MFF Real-time simulation (conducted in April-May
2002) and adapt aspects to meet the requirements for the "Air Weeks".
We wanted to reduce the focus of the airborne simulations to address fewer
questions but to address them adequately. In addition, the capabilities of the
cockpits were somewhat limited. Both the MCS and ACS were in the process of
being upgraded in the context of MFF and by the time of the simulation would
only be capable of ASAS Spacing and Merging operations. The RFS however was at
a more advanced state of development and was already capable of ASAS Crossing
and Passing manoeuvres as well. The simulation therefore concentrated on
simulating MFF Application A3 - ASAS Spacing which had recently been redefined
to bring it into line with the FAA-Eurocontrol Principle of Operations for ASAS
(known as PO-ASAS) which envisages both Sequencing & Merging and Crossing
& Passing within the ASAS Spacing[2]
application.
3. Scenarios
The chosen
airspace was the Rome sector "ES" which encompassed the airspace over
eastern Sicily and the toe of Italy. The normal traffic flows involved
converging en-route flows and arrival flows into the airport of Catania. The
MFF RTS2 scenario also included the Free Route Concept[3]
and the airspace of the Air Weeks simulation was therefore designated Free
Route Airspace above FL245. This led to interesting ASAS scenarios in which
traffic converged on Free Route exit points on the eastern side of the sector
and also converged on specific points designated as high level arrival fixes
for Catania where the vertical transition from Free Route Airspace to a fixed
arrival route was made at FL245 followed by descent into the Catania TMA.
The NLR
devised a range of scenarios for the simulation taking into account the
environment and capabilities of the cockpits. Additional traffic was also
included in the scenarios, to be flown by the normal ESCAPE piloting system -
MASS. The scenarios were delivered to the data preparation team in Rome as a
series of events which should occur in sequence to simulate a series of ASAS
situations. The idea was to create a suitable traffic sample and then provide
the controller with a script which if followed would ensure that the situation
would unfold as planned and all the necessary events would occur. The
controller role was therefore a "pseudo" controller role and his task
was that of creating a specific traffic situation – the one we wanted to look
at from the pilot’s point of view. It was an interesting task undertaken by
Pietro Rotundo of ENAV to translate NLR's list of events into a scripted traffic
sample in which aircraft would be in exactly the right place at the right time
to be involved in their next ASAS event. Stefan Oze of the EEC also assisted in
this task and he took on the role of managing the simulation organisation in
Brétigny during the actual running of the experiment.
4. Technical Aspects
Before
anything could be simulated however, many technical problems had to be
overcome.
4.1 Connecting Simulators.
Three
different aircraft simulators based in geographically distant locations needed to
be coupled with the ground simulator ESCAPE based in the ECEC (ENAV CNS/ATM
Experimental Centre) in Rome. The connection should allow transportation of not
only bi-directional flight related data but also voice communications between
pilots and ground controllers.
4.2
The ESCAPE
Simulator
An ESCAPE
platform with 12 controller working positions is installed in the ECEC, acting
as test bed for the MFF real time simulation. The ESCAPE simulator consists of
4 separate components:
·
the
Ground subsystem which performs the Flight Plan Data Processing,
·
the
MASS (Multi Aircraft Simplified Simulator) subsystem which simulates the
traffic,
·
the
AudioLAN system, a radio-telephone Voice Communication System based on low-cost
effective computer and Internet Telephony technologies. Using voice transport
over IP protocol, each AudioLAN position provides clear, high-quality audio
conversations with two radiotelephone full duplex channels and a complete set
of functionalities.
·
The
CWP (controller working positions) which display traffic information sto the
controller and allow interaction with the system.
The whole
architecture is built on the Common Platform that uses a CORBA (Common Object
Request Broker Architecture) middleware to provide inter-client communication.
4.3
The Aircraft
simulators
Three
different aircraft simulators needed to be connected with the Ground simulator:
·
the
Autonomous cockpit simulator (ACS) based in the ECAC (ENAV CNS/ATM Experimental
Centre) in Rome, a static twin pilot position cockpit simulator with external
view capability based on an Airbus A320
Figure 1: The inside of the ACS cockpit in
Rome
·
the
Multi-aircraft Cockpit simulator (MCS)
based in the EEC (EUROCONTROL Experimental Centre) in Bretigny near Paris, a
static twin pilot position cockpit simulator based on an Airbus A320, that can
be flown stand alone or coupled to a traffic simulator where it can fly with
other aircraft in a common virtual world.
Figure 2: The MCS cockpit during the
experiment
§
the
Research Flight Simulator (RFS ) based in NLR Amsterdam, a generic flight
simulator representing a modern large airliner, used in the Boeing 747
configuration (with Boeing 747-400 enhanced displays and a simulated Boeing
747-400 Flight Management System). The RFS is equipped with a four degrees-of-freedom
motion system and an external view system. (see photo,
Figure 3: The RFS external view (photo
courtesy of NLR)
4.4
Connection
Issues
The cockpit
simulators of MFF are not integrated with the ESCAPE platform through a CORBA
connection. Therefore, the MFF technical team needed to identify an
alternative, different means to transport digital data (traffic data) and audio
data (voice communications) between remote locations. After conducting a survey
of different technologies, the team decided to adopt solutions that represented
the minimal implementation risk, in consideration of the already challenging
task. Therefore, the option of using a DIS protocol for digital data and
telephonic connection for voice communication was retained, which was already
tested in a previous EUROCONTROL experiment.
Two ISDN
connections were established between the ECEC and the EEC (512 kbit/sec) and
NLR (256 kbit/sec) respectively, using CISCO 3620 routers. Through this digital connections, two types of
data were transmitted:
·
Traffic
data, including cockpit positions transmitted from the cockpit simulators to
ground and traffic information sent from ground to the cockpit simulators;
·
AudioLAN
controlling data (push-to-talk button and change of frequency information).
Due to the
requested bandwidth for the whole simulator (64kbyte/sec for each of the 24
connected AudioLAN positions), voice communication was not transported over
AudioLAN on a digital line but instead, a remote headset was connected via an
analogue line (telephone line).
A specific
configuration was adopted for the connection of the ACS with the ESCAPE
platform, since they were located in the same building. While the digital
connection was still using the DIS protocol locally, the voice communication could
be made full use of the AudioLAN features thanks to the larger bandwidth of the
local LAN.
4.5
Communication Protocol
The chosen
communication protocol was based on the IEEE standard 1278 (DIS 2.0.4)
Distributed Interactive Simulation (DIS). This relatively old protocol was
invented by the US Department of Defence (DoD) in order to support large-scale
simulations of warfare by interconnecting several remote simulators. Dedicated
links were assessed as not being cost-efficient if developed on an individual
basis. Therefore, DIS aimed at providing connection software for linking
various simulators, without conditions on the place or on the platform they
were running concurrently. The MFF technical team decided for the DIS protocol
because of its relative simplicity and robustness, which had already been
assessed by EUROCONTROL for the connection of the Eurocontrol MCS
(Multi-aircraft Cockpit Simulator) with the ESCAPE simulator. When the MCS was
industrialised during the period 1999 to 2000, the company Faros included in
the delivery a DIS interface written in "C". This interface not only
allowed the MCS to send out its own state but to receive the states of other
aircraft. These states (e.g. identification, position, velocity) could be used
as if they had originated from the new air to air surveillance technology:
Automatic Dependent Surveillance – Broadcast (ADS-B) and be presented to the
pilots on a Cockpit Display of Traffic Information (CDTI). The DIS interface
also allowed status information about the cockpit radio to be communicated so
that the pilot/air traffic controller audio communications could be simulated
using the AudioLAN system.
In the DIS
protocol, the world is modeled as a set of “entities” (in this case aircraft)
that interact with each other by means of “events” that they cause. These
events may be perceived by other entities and may have effects on them, which
in turn may cause other events that affect other entities.
At the
heart of DIS, there is a set of protocols that convey messages about entities
and events, via a network, among various simulation nodes that are responsible
for maintaining the status of the entities in the virtual world. The
characteristics of the network are not important, as long as it can convey
these messages to the interested simulation nodes with reasonably low latency
(100 to 300 milliseconds) and low latency variance. Within these constraints,
the systems that generate entities that appear to be adjacent in the virtual
world could be separated by thousands of miles in the real world.
The DIS
definition includes:
·
A data
model, associated with a common representation of them
·
The
assembling of these data into messages, called Protocol Data Units (PDU)
·
The
circumstances under which these PDUs are transmitted
·
The processing
that must be done on receipt of PDUs
·
Key
algorithms (e.g. dead reckoning) that must be implemented
4.6
System
Overview
Figure shows the DIS connection of one
of the cockpit simulators (MCS) to other simulators (the same model has been
applied to the other cockpit simulators). The MCS and DIS interface code is
based on "C" running on a Windows NT/PC platform. The DIS interface
code translates data and event messages travelling in both directions between
the MCS and an external TCP/IP twisted pair ethernet 10 Mb/s (10BaseT) link.
Outgoing messages from the MCS are transmitted in unicast mode and the same
mode is used for incoming messages. The external TCP/IP ethernet link is
connected to a P-server running on a Sun/Unix platform which receives DIS
unicast messages and distributes them via several unicast links so that other
connected simulators including AudioLAN and ESCAPE can communicate.
The
AudioLAN system has a DIS interface marked as RadioIF in figure 4. This
DIS/AudioLAN gateway takes radio information issued from the MCS (frequency
changes, push-to-talk state) and sends it to AudioLAN host via a specific
communication protocol.
Figure 4: DIS local
connection
Figure 5
shows the configuration used to link the MFF ESCAPE platform to the remote cockpit simulators. In order
to keep this diagram simple, P-servers are represented as DIS sub-networks. In
this configuration, AudioLAN does not transport voice on a digital line but instead,
a remote headset is connected via an analogue line.
