free flight - flight management system brite/euram project · free flight - flight management...

Free Flight - Flight Management SystemBrite/EuRam project

3FMSSIMULATION FACILITIES DEFINITION

DOCUMENT

(3FMS - SFDD)

P/N: WP 1.3

Rev: 4

Date: March 19, 1999

SXT AS SI ETG NLR Skysoft DERA

Author’s name - ChristopheFerrachat

StephaneParis

- - Ruud. G.den Boer

Collin S.Beers

- -

Approvals

3FMS SIMULATION FACILITIES DEFINITION DOCUMENT

3FMS PROJECT 2 SFDD.doc



TABLE OF CONTENTS

ABBREVIATIONS/DEFINITIONS .......................................................................................................................................5

1. INTRODUCTION...........................................................................................................................................................7

2. SCOPE OF THE TRIALS; HOW THE SIMULATION FACILITY WILL BE USED...........................................8

3. ARCHITECTURE OF THE 3FMS DEMONSTRATOR ...........................................................................................9

4. THE AIRCRAFT SIMULATOR (EPOPEE - AEROSPATIALE)...........................................................................10

4.1 GENERAL DESCRIPTION...............................................................................................................................................104.2 FUNCTIONAL DESCRIPTION..........................................................................................................................................114.3 COMPONENTS NEEDED FOR SIMULATION.....................................................................................................................13

5. THE ATC SIMULATOR (NARSIM - NLR)..............................................................................................................14

5.1 GENERAL ............................................................................................................................... .....................................145.2 NARSIM SERVERS .....................................................................................................................................................15

5.2.1 General .............................................................................................................................................................155.2.2 NARSIM Simulation control .............................................................................................................................165.2.3 Traffic Generation ............................................................................................................................................195.2.4 Environment .....................................................................................................................................................245.2.5 Ground system ..................................................................................................................................................285.2.6 Communication.................................................................................................................................................33

5.3 LOCAL DATABASES.....................................................................................................................................................365.3.1 Airspace............................................................................................................................................................365.3.2 Airport data ......................................................................................................................................................365.3.3 IFPs ..................................................................................................................................................................365.3.4 Meteo ................................................................................................................................................................365.3.5 A/C performance data (BADA).........................................................................................................................36

5.4 LOCAL RECORDING.....................................................................................................................................................36

6. INTERCONNECTION BETWEEN THE A/C SIMULATOR AND THE NARSIM SIMULATOR....................37

6.1 RADIO TELEPHONY (R/T) CONNECTION .............................................................................................................................376.2 DATA CONNECTION ................................................................................................................................................37

6.2.1 Physical connection ...............................................................................................................................................386.2.2 Transmission Control Protocol .............................................................................................................................396.2.3 Data Protocol. .........................................................................................................................................................396.2.4 Exchanged data......................................................................................................................................................406.2.5 Data dynamics (Communication mechanisms) .................................................................................................40

7. MISCELLANEOUS TOPICS......................................................................................................................................41

7.1 DATA BASES................................................................................................................................................................417.2 SIMULATION CONTROL ...............................................................................................................................................417.3 RECORDING OF THE DATA EXCHANGED BETWEEN NARSIM AND THE 3FMS .............................................................41

8. REFERENCES..............................................................................................................................................................43

APPENDICES.........................................................................................................................................................................44

APPENDIX A GENERAL NARSIM INFORMATION...............................................................................................................44A.1 Simulation Room ...........................................................................................................................................................44A.2 Hardware specifications ...............................................................................................................................................44A.3 Software Specifications .................................................................................................................................................46A.4 NARSIM architecture ....................................................................................................................................................46

APPENDIX B ADS-B .........................................................................................................................................................48APPENDIX C TIS-B ...........................................................................................................................................................49APPENDIX D CPDLC ........................................................................................................................................................50APPENDIX E FIS ...............................................................................................................................................................54



Abbreviations/Definitions

A/C AircraftACOD Area COnflict DetectionADS Automatic Dependent Surveillance ADS – A ADS – Adressed ADS – B ADS – Broadcast ADS – C ADS – ContractAM Arrival ManagerAOC Airline Operational ControlA/P AirportAS AerospatialeASAS Airborne Separation Assurance SystemATC Air Traffic ControlATCo Air Traffic Controllers

CNAV Conventional NavigationCPDLC Comtroller Pilot Data Link CommunicationCRDA Converging Runway Display AidCWP Controller Working Position

DCDU Datalink Control Display Unit (main HMI for ATC-Pilot dialog)DIS Distributed Interactive SimulationD/L Datalink

EFIS Electronic Flight Information SystemEPOPEE Etude Prospective d'Organisation d'un Poste d'EquipagEE/WD Engine/Warning Display

FCU Flight Control UnitFDP Flight Data ProcessingFFAS Free Flight AirspaceFIS Flight Information ServiceFM Flight ManagementFMS Flight Management SystemFPM Flight Position Monitor

GHMI Ground HMIGTS Ground Traffic Server

HMI Human Machine Interface

IFP Initial Flight PlanI/O Input/Output

LAN Local Area Network



MAS Managed AirspaceMCDU Multi purpose Control Display Unit

NARSIM NLR ATC Research SIMulatorND Navigation DisplayNCS NARSIM Client ServerNLR Nationaal Lucht- en Ruimtevaartlaboratorium (National Aerospace Laboratory)NWS Nose Wheel System

PDU Protocol Data UnitPFD Primary Flight DisplayPLAID Programme LAnguage Independent Data

RNAV Area NavigationR/T RadiotelephonyRTA Required Time of Arrival

SAP Service Acces PointSD System DisplaySPL System (flight-) PLan; (in other systems often named FDP)STCA Short Term Conflict Alert

TDD Trials Definition Document (WP 5.1)Time experiment time simulation time + off-set

simulation time synthetic time indicating how long the simulation is running ; = 0 for the start of the simulation ; runs twice as fast as world time when simulation speed is two.world time time derived from GPS information

TIS Traffic Information ServiceTN Trajectory NegotiationTP Trajectory Predictor

VNAV Vertical NavigationVRV Vertical View

WP WorkpackageWS Work Station



1. Introduction

This document describes the architecture and functionality of the simulation environment which will be usedduring the trials at the end of the 3FMS project.

Important input for this document is the “Functional Definition Document (FDD, see reference 4)” as producedin workpackage 1.2, which describes the functionality that will be included in the 3FMS prototype. It is assumedthat a large part of this functionality will be adressed in the final trials at the end of the project. These trials, whichwill be defined in the Trials Definition Document (TDD, see reference 6; workpackage 5.1), will fall within thegeneral context as sketched in the Free Flight scenario Definition Document (FFDD, see reference 3), producedin workpackage 1.1.

The TDD and the FDD determine which functionality (and data) is needed in the simulation facility. The SFDDspecifies both the functionalities which shall be present in the simulation facility as well as the data flows (andrelated formats) between the components of the facility.Chapter 2 describes on a high level how the facility will be used.Chapter 3 presents the high level view of the 3FMS simulation facility, called the 3FMS demonstrator. Threemajor elements can be distinguished :• 3FMS prototype (described in the Functional Definition Document, FDD),• A/C simulator EPOPEE (described in chapter4),• ATC simulator NARSIM (described in chapter 5).

For reasons of clarity, a large part of the outline of this document (SFDD) is chosen to be as close aspossible to the outline of the FDD.



2. Scope of the Trials; how the simulation facility will be used

The trials are defined in the Trials Definition Document (TDD, see reference 6). However, on this place a verybrief outline of the trials and the implications on the 3FMS Facility is presented.

It is envisaged that during trails, the EPOPEE is simulating gate to gate operation between Amsterdam airport(EHAM) and the Paris Charles de Gaulle airport (LFPG). The ATC environment, weather and the trafficsurrounding the EPOPEE will be simulated by NARSIM. The TDD defines the Airspace stucture and the ATCmethods which will be applied in the different parts of the airspace. These methods will have implications on thesimulation facility, for instance with respect to which tools are needed by the various Air Traffic Controllers(ATCo’s). All separate parts of the ATM control between Amsterdam and Paris will be simulated, however, it isforeseen that during simulation, only the sector where the EPOPEE actually is flying in and the next sector it willenter, are ATC positions with human control.

The TDD will also define air traffic surrounding the EPOPEE (traffic density, what kind of different flightsdepartures/arrivals/en-route, including the equipment level (e.g. ASAS equipped or not) of the A/C simulatingthose flights.



3. Architecture of the 3FMS demonstrator

This chapter presents on a high level the architecture of the 3FMS demonstrator. Figure 1 presents themain components and the way they communicate with each other. The 3FMS demonstrator comprises thefollowing main items:• 3FMS prototype,• A/C simulator EPOPEE,• ATC simulator NARSIM.The computers of the 3FMS (prototype) and the computers of the EPOPEE will communicate via anethernet connection. The computers of NARSIM will communicate via a separate ethernet. The 3FMSprototype and the EPOPEE are located in Toulouse (France), whereas NARSIM is located in Amsterdam(the Netherlands).

ATCSimulator

ISDN lines

Air-TrafficSimulator

Communication

ISDN

modem

3FMS

FM

NARSIM EPOPEE

DIS DIS

A/CSimulator

Ethernet IEEE 802.3u

Ethernet IEEE 802.3u

Scram-net

AS

ISDN modem

Scram-net

Figure 1 Basic architecture of the 3FMS simulator

Communication between the two sites will be done via an ISDN connection between a dedicated ASworkstation with Scramnet tool and one of the NARSIM computers. Messages will be “packed” and“unpacked” by DIS software installed at both sites. All the data that will be exchanged between both sitesis described in detail in this document.



4. The aircraft simulator (EPOPEE - Aerospatiale)

4.1 General descriptionThe A/C simulator is based on the Aerospatiale’s EPOPEE research simulator. It provides a high fidelitysimulation of an A340-300 with CFM56-5C4 engines.The EPOPEE simulator serves the purpose of studying new commands, ergonomics, as well as newtechnological applications. It consists of the following elements:

- a ground fixed A/C cockpit, called the EPOPEE cabin,- a set of calculators and graphic stations supporting the various simulation applications,- an electronic interface between the cabin commands and the simulation applications running on

central calculators,- a Local Area Network dedicated to communication between all elements,- a set of monitoring tools aiming at supporting simulation parameters surveillance, monitoring,

visualization, recording, etc.

Figure 2 The EPOPEE research simulator

The EPOPEE cabin itself is equipped with seats, pedals, side-sticks, throttle, gear and slats/flaps levers,ground spoilers, speed brakes, parking brakes, Nose Wheel System (NWS) and a complete set of controland display interfaces, including :

- Four EFIS displays : two Primary Flight Displays (PFD) and two Navigation Displays (ND),- Two ECAM displays : one Engine/Warning Display (E/WD) and one System Display (SD),- Two Datalink Control and Display Units (DCDU),- Two Multiple Control and Display Units (MCDU),- One Flight Control Unit (FCU),- EFIS Control Panels,- Audio Control Panels, headphones and microphones,- Radio Management Panels,- Overhead Control Panels.

GraphicStations

SimulationCalculators

EPOPEECabin

ElectronicInterface

MonitoringTools



Figure 3 The EPOPEE cockpit lay-out

EPOPEE also comprises a simulation software that deal with:- Aerodynamics models,- Engine models,- EFIS,- Flight Controls,- Flight Guidance and Envelope protection,- Systems (hydraulic, engines, etc.).

The simulation software is divided into several tasks running simultaneously on the simulationcalculators.These tasks are monitored in real-time.The EPOPEE simulation environment is based on POSIX operating system, and the EFIS simulation isbased on VAPS for the graphic part.Communication between all the workstations is achieved through either Ethernet or Scramnet reflectivememory links.

4.2 Functional descriptionThe different functions of the A/C simulator are as follows :- Simulation calculation means,- Graphic calculation means,- Local Area Network (LAN),- VISUEL function,- Audio elements,- Interface,- Additive tools: Video, audio, parameters recording.

FCU + EFISControl Panel

Throttle

E/WDDCDU

MCDURMP

SD

OverheadControlPanel

PFDND

Side-stickPedals

NWS



4.2.1 Simulation calculation meansThey support real-time simulation software, LAN communication, communication with graphic stations,and users’ access to internal parameters. They also acquire flight parameters changes from the cabincommands and reinject them into the directives they send to the cabin, through the interface .

4.2.2 Graphic simulation meansThey support graphic images generation and transmission to the EPOPEE cabin for display to users.

4.2.3 LANThis LAN comprises two separate sub-networks. One is dedicated to real-time communication with thecabin (simulation directives, dialog with the cabin systems, etc.), and the other supports the managementof all the calculators and the monitoring elements of EPOPEE (tools, etc.).

4.2.4 VISUEL functionVISUEL is the visual system of the EPOPEE A/C simulator, displaying the visual environment of thesimulated aircraft. Consequently, the VISUEL function is supported by a specific calculator whichprovides this environment.

4.2.5 Audio elementsThese elements comprise all normal A/C audio equipments: headphones, microphones, etc.They allow to perform fully operational tests.

4.2.6 Electronic interfaceThe interface support the communication between the EPOPEE cabin systems and the simulationcalculators. They format the analogic, discretes and ARINC signals coming from the cabin so that thesimulation calculators can correctly treat them. Those signals come from the cockpit commands, panelcontrols, visual alarms, displays, etc. The interface also deals with the Ethernet and RS232 links.

4.2.7 Additive toolsApart from the described real-time tasks, there is a need for monitoring the simulation configuration. Forthat purpose, tools have been designed so as to visualize, record and monitor internal simulationparameters. These tools consist of applications running on separate computers, used before, during andafter simulator sessions.



4.3 Components needed for simulationIn accordance with the scenario defined in the "Free Flight Definition" document, the followingcomponents will be required in order to conduct the 3FMS evaluation:

A/C SimulatorComponents

Status Requirements

FCU ExistingND Captain’s side / EFISsim.

Adaptation (New symbology,Size 6x8)

CDTIWeatherTerrain & Airspace

PFD Captain’s side ExistingDCDU Captain’s side Existing ATC messages display and

handlingMCDU Captain’s side New A340 MCDU with ATC

keyCursor Control Device ? New component HMI controls (modes : Traffic,

Weather, Geographic)



5. The ATC simulator (NARSIM - NLR)

5.1 General

In the 3FMS project, NLR’s ATC Research Simulator (NARSIM) will be used. NARSIM is a verymodular and flexibile simulator providing extensive functionality. It has been developed to perform real-time ATM simulation with men (both the Air Traffic Controller and the Pilot) in the loop. Figure 4presents the general set-up of the system in the NLR environment. Instead of the RFS the EPOPEE flightsimulator will be used for 3FMS.

Figure 4 NARSIM features links with both research aircraft and research flight simulators

The pilot in the loop can be of three types :• A pilot of a Flight Simulator (in case of the NLR environment the Research Flight Simulator (RFS),

in case of 3FMS the EPOPEE Flight Simulator),• A pilot of a real aircraft (in case of the NLR environment the Cessna Citation II or Metro II NLR

research aircraft),• A pseudo-pilot/blipdriver (called simulated pilots in figure 4) behind a X-terminal.Of course, a number of all three types of pilots can participate in the same simulation. Note that incommon practice, the largest number of aircraft is piloted by the pseudo pilots.



The aircraft, controlled by the pseudo pilots are also able to exchange data link messages with the« ground side » of the simulation and pseudo pilots have a voice connection with the Air TrafficControllers via regular Radiotelephony (R/T). Beside the three types of piloted aircraft, also aircraftwhich fly according to pre-specified rules, may join the simulation.

NARSIM can also be connected with other ATC simulators (e.g. using the DIS server) and towersimulators. In this way it becomes possible to perform real time « man in the loop » ATM simulationsfrom gate to gate. Appendix AGeneral NARSIM information), presents a brief overview of thesimulation room of NARSIM and the hardware available.

NARSIM Status Requirements for 3FMSHardware(Computer, consoles, etc.)

Existing Small adaptations/extensions expected.For instance with respect to ISDN infrastructure.

5.2 NARSIM servers

5.2.1 General

Below, the for the 3FMS project most relevant servers of NARSIM are listed ; the following sectionspresent more detailed information on them.A. Simulation control (see section 5.2.2)

A.1 Executive Server A.2 Supervisor HMI server

B. Traffic Generation (see section 5.2.3) B.1 Air Traffic server B.2 Air - Pseudo Pilot HMI B.3 Ground Traffic Server B.4 Ground – Pseudo Pilot HMI

C. Environment ( see section 5.2.4) C.1 Initial Flight Plan servers C.2 Taxi environment server C.3 Airspace server C.4 Geographic environment server C.5 Meteo server

D. Ground system (see section 5.2.5) D.1 Radar Tracker server D.2 HMI for Ground Traffic Controller D.3 HMI for Air Traffic Controller D.4 Tools for the Air Traffic Controller D.5 System Flight Plan server/Flight Data Processing

E. Communication (see section 5.2.6) E.1 Datalink server E.2 R/T server E.3 DIS server



Note that this list is not exhaustive. For the 3FMS project some new servers need to be made while otherservers will be extended. To mention an example which is not yet included in the NARSIM ATCsimulator: simulation of taxiing A/C. The extensions to be made will be established more detailed whenthe Functional Definition Document for the 3FMS will be finalised. In the next sections, the servers willbe described on a userlevel. At the end of each section, it is indicated what extensions and/ormodifications need to be done for the 3FMS project.

Note that, beside the software, also data bases are needed, e.g. for A/C performance data, Airspace data,Initial Flight Plans and Meteo Data.

5.2.2 NARSIM Simulation control

This section describes the control of the NARSIM part only; for the control of the simulation of NARSIMand EPOPEE together, see section 7.4

5.2.2.1 Executive Server

Figure 5 Data-flow diagram of the Executive server

DescriptionThe Executive server’s task is to manage the simulation. It provides server (e.g. name, network-address)and service information (e.g. providers) to the other servers. The Executive server also controls time andits update rate (speed) during a simulation.

The Executive server is the first server to start. After start-up and initialisation the other servers may bestarted. According to the requirements, the Executive server maintains a central administration of servers,services, simulation architecture and settings. In order to access this information, a server has to connectto the Executive server. The servers will have to know the exact location (Service Access Point SAP) ofthe Executive server to make their connection.

Executive Server (EXEC)

Executive

NCS

GeneralTime



The SAP of the Executive server is dynamic, i.e. arbitrary for a simulation. Therefore each server shouldoffer a general mechanism, for instance a command-line option, to specify the SAP of the Executiveserver. This SAP should be passed to each server part of the simulation. Also an environmental variablecan be defined to specify the SAP of the Executive server.

After start-up a server is not automatically involved in the simulation: it has no knowledge about serversand services available. The Exec services are defined to maintain and provide a central administration ofthe servers and services available. In order to establish this administration, servers have to register theirserver and service information. Clients can use the information provided by the Exec services in findingthe appropriate servers and services.

During the simulation-run a server may for some reason (termination, missing required services) decideto withdraw some of its services. The Executive server will provide the withdraw information to the(interested) other servers, which should take appropriate action, by not calling these services any longer.If a server called a service just before it was informed about the withdrawal, the Executive server still hasto deal (maybe low-level) with requests for the services withdrawn.

While performing their tasks, possibly already during initialisation, some servers may need services fromother servers. A server will not be aware of who’s providing what in a simulation-run, until the Executiveserver informs it. The Executive server will keep a server informed of servers joining this simulation,after receiving an explicit request. The server is informed of both new and terminating servers, the latteralso if a server crashes.

The simulations controlled by the Executive server are stateless; i.e. a common state for all servers doesnot exist. As a result servers may start at an arbitrary simulation moment. The presence of a sequence inthe execution of an arbitrary server, as sketched in the sections above, introduces some server-local states.These states are directly coupled to the service calls made by the server. The server states are not used inthe Executive server, but can be used to keep the experiment leader informed.

Specification-The executive server provides the execution control of the simulator,-The executive server provides information of the servers and services involved,-The executive server provides facilities to maintain, adapt and supply simulation time and

speed,-The minimum simulation speed of the NARSIM C/S system is 0, corresponding with freezing the

simulation,-The maximum simulation speed of the NARSIM C/S system is 10 times real time.

NARSIM Status Requirements for 3FMSExec Server Existing None



5.2.2.2 Supervisor HMI server

Figure 6 Data-flow diagram of the Supervisor HMI server

DescriptionThe supervisor HMI server enables an experiment leader, other human supervisors and softwaredevelopers to monitor and control the progress of a simulation.It supplies at least commands to start and stop the simulator as also facilities to control the simulationtime and speed (time rate). It also supplies facilities for on-line monitoring to keep the supervisorinformed.

Specification- The Supervisor of the NARSIM simulator controls the execution of the NARSIM C/S system. For that

purpose, simulation commands are defined.- The Supervisor of the simulator is able to:

-Monitor simulation time-Change simulation time rate (accelerate, decelerate simulation)

- The Supervisor server provides facilities to display messages, debug and analysis data provided byinvolved servers, thereby enabling off-line simulation analysis.

NARSIM Status Requirements for 3FMSSupervisor Existing 1. None

Supervisor Server (SUP)

General TimeExec

HMI



5.2.3 Traffic Generation

5.2.3.1 General

As compared to air-traffic, for ground-traffic the equations of motion are very simple, and, instead of aflying in a three-dimensional airspace, the A/C is taxiing on a (almost) two dimensional airport. Becauseof the different nature of the problem, separate servers will be used for the simulation of the ground-traffic and the air-traffic ; also the HMI for the pseudo pilot will be a different one for piloting the A/C onthe ground as for piloting the A/C in the air.

5.2.3.2 Air Traffic server

5.2.3.2.1 General description

Figure 7 Data-flow diagram of the Air Traffic server

DescriptionThe Air-traffic server is responsible for simulating flights. These flights are made available to clients bymeans of the traffic services. The simulated flights are created from the Initial Flightplans (IFP’s)received as a result of the requested IFP subscriptions. Once a flight is created it will be updated with aconfigurable rate. Behaviour of simulated flights is influenced by meteo data, datalink messages and thecommands entered by the blipdrivers.

Several Blipdriver I/O servers can be coupled to the Air-traffic server to control the simulated flights.Using the interfaces described in the blipdriver services (used by the Air-traffic server) and the trafficservices (used by the blipdrivers) performs this coupling. The Air-traffic server will subscribe toblipdriver commands and blipdriver parameters at each server providing these services. The Air-trafficserver also handles datalink messages from the pseudo-pilots and the air-traffic controllers.

Air Traffic Server (ATS)

Traffic General

Exec Airspace Blipio IFP TimeDatalink



The Air Traffic server can simulate any aircraft provided by the BADA database. BADA 2.6 providesoperations and procedures data for a total of 166 aircraft types. For 69 of these aircraft types, data isprovided directly in files. These aircraft types are referred to as being directly supported. For the other97 aircraft types, the data is specified to be the same as one of the directly supported 69 aircraft types.This second set of aircraft types are referred to as being supported through equivalence.

Some Aircraft Types Supported by BADAA/CCode

ModelType

Aircraft Name Equiv.A/C

Max.Altitude

WakeCat.

E110 equiv Embrear Bandeirante D228 29600 L

E120 direct Embraer EMB-120 Brasilia 32000 L

EA30 direct Airbus A300 39000 H


EA32 direct Airbus A320 39000 M



Specification- The Air Traffic server can simulate any aircraft provided by the BADA database.- The Air Traffic server simulates auto pilot capability, consisting of pitch, roll and speed modes- The Air Traffic server simulates auto throttle capability- The Air Traffic server simulates aircraft behaviour in the following flight phases:

Waiting/Taxiing, Initial Climb, Constant CAS/Mach Climb, CAS/Mach cruise, Constant CAS/Mach Descent, Initial/Intermediate/Final Approach and Holding.

- The Air Traffic server simulates area navigation (RNAV), “conventional” navigation (CNAV) andvertical navigation (VNAV)

- The Air Traffic server simulates navigation along great circles- The Air Traffic server simulates standard radial and track interceptions- The Air Traffic server simulates standard ILS interceptions as described in ICAO document

ref.[ICAO-8168]- The Air Traffic server simulates a holding procedure as described in ICAO document ref.[ICAO-

8168]- The Air-traffic server has the following functions:- Real-time simulation of air-traffic as input for the Radar/Track server.- Handling of Datalink messages, either transferring them from ATCo Display servers to Blipdriver I/O

servers and vice versa, or processing them internally, or both.- Handling of DAP (Downlink of Aircraft Parameters) Datalink messages to and from other servers, via

the Datalink server.- The Air-traffic server uses Initial Flightplans, sent from an Initial Flightplan server or read from a data

file, to create flights.- The Air-traffic server uses information from the Meteo, Airspace and Blipdriver I/O Servers to

simulate flights.- One or more Blipdriver I/O servers form the user interface to the Air-traffic server.



5.2.3.2.2 Conflict Detection and Resolution (ASAS)

Figure 8 Data-flow diagram of the ASAS server

Two options may be considered :1. The ASAS module of the 3FMS demonstrator will be integrated in the ATS.

2. An ASAS module will be newly developed and integrated in the ATS.

5.2.3.2.3 Other 3FMS extensions

Beside the extension of the air taffic server with conflict detection and resolution for the simulation ofASAS, also the following extensions for the 3FMS project are foreseen :- Functionality related to station keeping - Functionality related to « free flight » related procedures

• simulated A/C in FFAS will sent a message to enter MAS• message will be shown at GHMI.

- Addition of functionality to process the new D/L commands. It is indicated in the Appendicescontaining the D/L commands which are the new ones to be implemented.

- Functionality for the transfer of A/C between the ATS and the GTS

NARSIM Status Requirements for 3FMSAir-traffic Server Existing Major additions expected:

1. Addition of simulated airborne conflict detectionfor ASAS

2. Addition of simulated airborne conflictresolution for ASAS

3. Miscellaneous other extensions, see section5.2.3.2.3

ASAS Server (ASAS)

ASAS

Exec Air-traffic Time

General

Datalink



5.2.3.3 Air - Pseudo Pilot HMI server (APH)

Figure 9 Data-flow diagram of the Air - Pseudo Pilot server

DescriptionThe Blipdriver server forms the user-interface between the Air-Traffic server and the pseudo-pilots. Itshows the status of the aircraft that the pseudo-pilot has under control and it enables the pseudo-pilot toenter commands that control the behaviour of those aircraft.

All aircraft are active on a certain communication frequency. Aircraft are assigned to those Pseudo-pilotsthat also have activated that frequency.

When there is more than one Pseudo-pilot on that frequency, a choice is made based on the pseudo-pilots’individual load. For this, the Blipdriver I/O server provides the ‘SubscribeBlipParameters’ service.

This service provides clients with the frequencies that the pseudo-pilot has activated and an indication ofhis/her current load. The Air Traffic server subscribes to this service to be able to decide which pseudo-pilot should control an aircraft. It can then assign flights by calling the correct blipdrivers ‘AcceptFlight’service. The pseudo-pilot can also use commands to explicitly ask for control of an aircraft.

The Blipdriver I/O server is also an endpoint for datalink messages. These can be sent from the ATCo tothe aircraft or vice versa. Pseudo-pilots are able both to respond to datalink messages (included in theflight data) and to initiate them. This is realised by adding datalink commands to the set of pseudo-pilotcommands.

Blipdriver Server (Blip)

Blipio General

Exec Time Traffic

IFP



Specification- The Blipdriver I/O server forms the interface between the Air Traffic server and the pseudo-pilots. As

such it will display aircraft status information, and enable pseudo-pilots to control those aircraft byentering commands.

- The assignment of aircraft to Blipdriver I/O servers is based on the frequency that the aircraft and thepseudo-pilot have activated, coupled with the individual workload of the pseudo-pilots.

- It is possible for the pseudo-pilot to respond to datalink messages sent by the air traffic controller, andhave them automatically executed by the Air Traffic server. It is also possible for the pseudo-pilot toinitiate datalink messages to the air traffic controller.

NARSIM Status Requirements for 3FMSAir - Pseudo Pilot HMIserver (APH)

Existing Adaptations expected :1. Extension of D/L commands

5.2.3.4 Ground Traffic Server

The Ground Traffic Server (GTS) will have the same data-flow structure as the Air Traffic Server(5.2.3.2).

Note that for D/L messages,the CPDLC list (see Appendix C) contains some messages related to taxiing.

NARSIM Status Requirements for 3FMSGround Traffic Server Non-existing

5.2.3.5 Ground – Pseudo Pilot HMI

NARSIM Status Requirements for 3FMSGround- Pseudo PilotHMI server (GPH)

Non-existing



5.2.4 Environment

5.2.4.1 General

All servers providing the environment make use of a data base. The airspace data, taxi environment dataand the actual weather data shall be installed locally both at the EPOPEE and the NARSIM site. All otherdata bases supporting the « environment » servers will be installed on the NARSIM site. The data will bestored using the PLAID format. See also section 7.1. For information on PLAID see reference 7.

5.2.4.2 Initial Flight Plan servers (IFP)

Figure 10 Data-flow diagram of the IFP server

DescriptionThe task of the Initial Flightplan server is to distribute Initial Flightplans to (in particular) the SPL server(ground system) and the Air Traffic server. The initial flightplans will be read from a PLAID data file.Inreality, the situation can arise where there are differences between the flightplan in the air-traffic controlsystem (the ground system) and the flightplan that the aircraft is executing, sometimes even to the pointthat the ground system has no flightplan at all. To emulate this kind of situation, it must be possible tointroduce differences between the Initial Flightplan that the System Flightplan server (the ground system)receives, and the one that the Air-Traffic server (the aircraft) receives. This way it is possible to createadditional workload for the air-traffic controllers, and furthermore it is possible to test the behaviour ofsystem components when they are given incorrect or incomplete data. This mechanism can also be usedto specify different times for the delivery of Initial Flightplans to different clients.

The IFP data file also specifies the initial experiment time. By default, the IFP server will use this to setthe initial experiment time.

Initial Flightplan Server (IFP)

IFP

Exec

General

Airspace Time

IFPs



Specification- The Initial Flightplan server distributes Initial Flightplans to all servers that have subscribed to them.- Initial Flightplans are read from a PLAID-formatted data file.- Initial Flightplans contain a subset of the data in a System Flightplan. This data shall be sufficient to

create both System Flightplans and Air Traffic server flights.- It is possible to specify at which time an Initial Flightplan will be delivered, and to which server(s).- It is possible to introduce deviations, i.e. when distributing an Initial Flightplan to several servers,

differences in one or more items in the Initial Flightplan can be introduced.- The Initial Flightplan server delivers static flight plans, where the System Flightplan server delivers

dynamic flight plans.

NARSIM Status Requirements for 3FMSInitial Flight Plan Server Existing None

5.2.4.3 Taxi environment server

NARSIM Status Requirements for 3FMSTaxi environment server Non-existing

5.2.4.4 Airspace server (AIR)

Figure 11 Data-flow diagram of the Airspace server

DescriptionThe Airspace server maintains a database of airspace objects. These include waypoints, airfields, runwaysetc. One thing that is typical for information about the airspace is that it is static during a simulation. Inother words, each time information is obtained about a specific entity it is exactly identical.

Air Space Server (AIR)

Airspace General

Exec

AirspaceSpecification



Specification-The Airspace server maintains information about entities in the airspace structure

(e.g. runways, waypoints) and provides it on request to other servers.- It is possible for users of NARSIM in off-line mode to modify existing airspace information and extend

it with elements of distinguished entities.

NARSIM Status Requirements for 3FMSAirspace server Existing None

5.2.4.5 Geographic environment server

NARSIM Status Requirements for 3FMSGeographic EnvironmentServer

Non -Existing The EPOPEE shall maintain it’s own geographicenvironment database.The A/C simulated by the ATS of NARSIM shallnot use the geographic environment database.

5.2.4.6 Meteo server (MET)

Figure 12 Data-flow diagram of the Meteo server

Meteo Server (MET)

Meteo

Exec Airspace Time

General

MeteoConditions



Description

The 4D Meteo server provides actual, nowcast and forecast weather data, METAR’s, TAF’s andSIGMET’s to the air and ground system of an ATM simulator, and optionally to external air systems,research flight simulators and research aircraft, when they join an ATM simulation.The most important meteo states are described next:

Actual weather: Simulated 4D-continuous real-world weather as to be perceived by simulated aircraft, based on so-calledanalysed weather data from numerical weather models of meteorological offices.

Forecast:Expected long term weather conditions, based on the processing of objective weather observations(measurements) from various resources by numerical weather models of meteorological offices. At anytime, at most 6 consecutive forecasts each with a typical duration of 1 hour, are available.

Nowcast:Short term forecast of improved quality, based on the additional processing of recent objective weatherobservations (measurements) from aircraft by numerical weather models of meteorological offices. Atany time, at most 1 nowcast with a typical duration of 20 minutes, is available.

The Meteo server provides 4D meteo data, based on grid-meteo. Meteo data includes wind speed anddirection and air pressure, temperature and density.

Specification-The Meteo server maintains meteorological information:

-Wind speed-Wind direction-Pressure (also at sea level)-Temperature-Accuracy

- The Meteo server is able to provide meteorological information about a specified 3D position.- It is possible for other servers to update or add to the meteorological information that is maintained by

the Meteo server.- It is possible to provide meteorological information on a specified 4D trajectory (also referred to as

route meteo).- It is possible to provide “average” meteorological information. This will be calculated by averaging the

meteorological information belonging to a specified set of positions.



NARSIM Status Requirements for 3FMS / remarksMeteo server Existing, to be

extendedNo actual weather shall be exchanged betweenEPOPEE and NARSIM (see section 7.1)

No METAR and TAF information will be used in3FMS

The Meteo server shall provide :1. SIGMET information to EPOPEE.

EPOPEE needs to take a « Subscription » toSIGMET. Every time new SIGMET informationbecomes available, this will be send to EPOPEE(see Appendix E FIS).

Nowcast/forecast for a given LAT/LON/FLL/timecombination(this can be used by 3FMS prototype for trajectoryreplanning)

5.2.5 Ground system

5.2.5.1 Radar Tracker server

Figure 13 Data-flow diagram of the Radar/Track server

DescriptionThe Radar/track server 'converts' positions from simulated aircraft obtained from e.g. an air-traffic serverinto observed tracks. When several servers provide air-traffic services, all observed aircraft will becombined into a single stream of tracks. This server can currently simulate two types of radars.

Radar/Track Server (RAD)

Exec

Radar

Time Traffic

General



Simulating the NULL-radar, the Radar/Track server immediately converts any incoming aircraft positionsto a track, which is then propagated to clients having subscribed to radar tracks. When simulating rotaryradar, a delay is computed based on the position of the aircraft, the position of the radar beam and theirrespective movements. This model represents the real-life observation of an aircraft by a radar, throughdetection by the radar beam.

The Radar/Track server maintains a database of aircraft tracks. Its function is to regulate access to thisdatabase and to distribute any changes to all interested servers. The Radar/Track server simulates one ormore radars by implementing the Radar/Track services. Tracks delivered to clients are generated fromobservations received by means of the Air-Traffic services. Each simulated radar will derive tracks fromthese observations depending on its type and parameters. A NULL-radar will pass observations directly toits clients without any modifications. Rotary radars are simulated by adding noise to the trafficobservations and may even miss some updates. The Radar/Track server can be configured to simulateseveral radars with different features. Clients may obtain information about the simulated radars byinvoking the appropriate Radar/Track services.

The Radar/Track server subscribes to new flights and flight updates. Each time a flight update delivery isreceived, the corresponding radar observation time is calculated and a timer is (re)started. When the timerexpires a new track is produced based on the latest flight delivered. Optionally some noise can be addedto the track or the track can be totally removed. Tracks not removed are delivered to the subscribedclients.

Specification-The input of the Radar/Track server is the aircraft status vector from an Air Traffic server.-The output of the Radar/Track server is tracks.-It is possible to incorporate a multi-radar tracker.-It is possible to incorporate probabilistic radar models.-The Radar/Track server is able to simulate the following modes:

-Rotating radar-NULL-radar

-The rotating radar simulates radar turning about an axis and being able to detect aircraft within a certainrange. The axis of rotating radar is identified by its position.

-It is possible to simulate a rotating radar with errors by specifying the angle, distance, missed plots,garbled SSR, etc.

-The NULL-radar simulates no delays and will immediately produce the track when an aircraft update isreceived.

-The Radar/Track server is able to simulate the different radar modes simultaneously.-The Radar/Track server is able to simulate different radars with similar mode simultaneously.-The radar configuration items of the Radar/Tracker serv are different depending on the mode of the

radar.-The rotating radar has the following radar configuration items:

-Latitude and longitude: the position of the radar-Range: the range of the radar

- Revolution time: the time needed to rotate 360 degrees

NARSIM Status Requirements for 3FMS / remarksRadar Tracker Server Existing None



5.2.5.2 GHMI for Traffic Controller

5.2.5.2.4 General

Different types of controllers will work during the simulations:• En Route Traffic Controllers• Approach Traffic Controllers• Feeder Traffic Controllers• Ground Traffic Controllers

5.2.5.2.5 GHMI for Ground Traffic Controller

The maps of airport A and B must be displayed to control and monitor the taxi procedures for the GroundTraffic Controllers.

5.2.5.2.6 GHMI for Air Traffic Controller

The different sectors from Amsterdam to Paris must be available for the Air Traffic Controller.Standard HMI combined with Free Flight HMI (CDTI) to monitor the aircraftwhile flying in FFAS.

5.2.5.2.7 GHMI Functionality related to new procedures

For the 3 FMS trials new procedures have to be established : to mention some examples :1. How will an A/C flying in an uncontrolled airspace, enter the controlled airspace ? Will the « ground

issue, on request of the A/C a slottime for a point (Initial Approach Fix) on the edge of theuncontrollled airspace. Will this clearance also put constraints on how to pass this IAF ? For instanceat (or below) a certain altitude at (or below) a certain speed, flying in a certain direction (headingconmstraint). Or, in the case when « station keeping is applied, « pass IAF 2 minutes after apredecessor » (at same height, speed and direction).



5.2.5.3 Tools for the Air Traffic Controller

Currently the NARSIM tools are :• Area Conflict Detection (ACOD),• Short Term Conflict Alert (STCA),• Flight Position Monitor (FPM),• Converging Runway Display Aid (CRDA),• Trajectory Predictor (TP),• Vertical View (VRV),• Arrival Manager (AM).

The first four tools have been designed and evaluated in co-operation with the Dutch ATC (Dutch:Luchtverkeersbeveiliging or LVNL) and will be incorporated in the new AAA system. The TrajectoryPredictor (TP) has been designed to support e.g. ACOD and other NARSIM purposes.

PurposeThese tools assist the air traffic controller in controlling traffic safely and efficiently. The increasingdemand of air traffic and the increasing number of traffic peaks and peak duration are a burden on the airtraffic controller’s workload. To reduce the workload of air-traffic controllers, sophisticated computerassistance has been introduced to assist the controller in his job.

Functional descriptionThe offered functionality for ATM tools differs hugely between different tools. Some tools assist thecontroller in his planning task, some monitor traffic for possible deviations from a cleared route, andothers predict future conflicts so that the controller can take appropriate action. More sophisticated toolsmay even suggest the controller how to avoid or solve conflicts.

Technical descriptionGenerally the tools need track and flight plan data. Roughly speaking these contain the current state andplans of the aircraft respectively. When an ATM tool detects a deviation, a future conflict, has asuggestion or whatever, it can generate data for other ATM tools, for the ATCo's display or perhaps evenfor a pilot. It is usually the controller's responsibility to handle the messages appropriately.



5.2.5.4 System Flight Plan server/ Flight Data Processing

Figure 14 Data-flow diagram of the SPL server

DescriptionThe System Plan server collects, maintains and distributes system plan information. It serves as thecentral repository of all System Flightplans active in the simulation. Clients can be notified of newlycreated System Flightplans and can then decide whether they wish to be notified of changes to them. Toreduce the number of deliveries, clients can specify exactly which changes they want to be notified of.The System Flightplan server also performs some actions to maintain the consistency of SystemFlightplans, e.g. checking whether the correct radar tracks are linked to the Flightplan and performingflight progress monitoring. Furthermore the SPL server attempts to link SPL’s to Radar/Trackinformation based on the SSR mode A code. External sources (e.g. ATCo's) can also initiate or evenoverrule a current link between an SPL and a track. There is no pre-set limit to the number of SystemFlightplans that the System Flightplan server can handle. Clients can create multiple System Flightplansfor a flight, as long as they use a unique callsign. This can be done by (for example) adding a character tothe callsign.

Specification-There is no pre-set limit to the number of System Flightplans.-System plan information covers among others:

-Callsign (unique)-Squawk code (assigned SSR mode A)-Assigned flightlevel (EFL), heading and speed-Requested flightlevel (RFL) and airspeed (RAS)-Departure and Destination airfield and runway-Aircraft type, wake turbulence category and equipment on board-Next way-point-Link(s) to tracks

-The SPL server receives initial flightplans from all servers that provide them.-The SPL server receives, processes and distributes SPL updates.-The SPL server provides and administrates links from System Flightplans to Tracks.-The System Flightplan server delivers dynamic flight plans, where the Initial Flightplan server delivers static flight plans.

System Flightplan Server (SPL)

GeneralSPL

Exec IFP Radar Time



NARSIM Status Requirements for 3FMS / remarksSystem Flight Plan server/Flight Data Processing

Existing Only minor changes expected.

5.2.5.5 Airline Operational ControlWithin the 3FMS project, no AOC will be simulated.

5.2.6 Communication

5.2.6.1 Datalink server

Figure 15 Data-flow diagram of the datalink server

Air/Air

• Between A/C both in the Air Traffic Simulator• Between the A/C simulator (EPOPEE) and an A/C in the Air Traffic Simulator

Air/Ground (vice versa)

NARSIM Status Requirements for 3FMS / remarksData Link Server Existing Major extensions expected.

Datalink Server (Datalink)

SPLRadarExec Time

Datalink General



5.2.6.2 R/T server

Figure 16 Data-flow diagram of the Radio-telephony server

DescriptionThe R/T communication between Air Traffic controllers and pseudo-pilots is simulated by a computercontrolled system. The system consists of 16 channels. A maximum of 16 stereo or 32 mono headsets or acombination of stereo/mono can be used.

If necessary the system can be expanded. For each channel a voice connection can be established betweenseveral controller working positions (CWP) and several pseudo-pilot working positions (PPP). The AirTraffic control positions are equipped with a headset (mono or stereo), loudspeaker and microphone. Thepseudo-pilot working positions are equipped with stereo headsets.

The R/T server will handle all voice communications between ATCo HMI servers and pseudo-pilot HMIservers. Configuration is done using an HMI. Significant events can be recorded.

SpecificationThe ATCo HMI servers and pseudo-pilot HMI servers will use the R/T server.• Direct telephone lines are available between all CWP’s.• Conference calls between CWP’s are possible.• Each CWP is fitted with a telephone selection panel.• Direct telephone line selection is available.• An audible and adjustable indicator is fitted for incoming calls.• The following parameters are recorded each time an attempt was made to establish a telephone call:-Event identification (i.e. telephone call)-Identification of call indicator-Identification of addressee-Start time of addressee’s incoming call alert• For recording of event data, synchronisation with the real-time ATC simulation is possible.

Radio-telephony Server (R/T)

Exec Time

General

HMI



NARSIM Status Requirements for 3FMS / remarksR/T Server Existing No changes expected

5.2.6.3 DIS server

Figure 17 Data-flow diagram of the DIS server

Data communication will be performed conform the DIS protocol.

DescriptionThe purpose of the DIS (Ref. IEEE 1278.1 1993) server is to interact with other (local or remote)simulation applications and exchange data in such a way that all simulators can participate in one global(real-time) exercise. The DIS infrastructure provides interface standards, communications architecturesand management structures necessary for linking all kinds of simulators into one distributed simulationexercise. Data exchange between simulators has been defined by DIS using Protocol Data Units (PDU’s).Although DIS initially has not been designed for linking ATC simulators, it is a well defined standardthat can be adapted for inter-site ATC simulation. Extra capabilities can be added in the form of freedefinable Data PDU’s (e.g. Flightplan updates).

EPOPEE will be able to send :1. Start2. Stop3. Freeze4. Create A/C5. A/C update (including dead – reckoning principle to be applied)6. Datalink messages

NARSIM will be able to send1. Stop2. Freeze3. Create A/C4. A/C update (including dead – reckoning principle to be applied)5. The Air-traffic filtered with respect o the setting of the ARS parameter6. Datalink messages

Distributed Interactive Simulation Server (DIS)

DIS

Exec

General

Time Traffic



Note that, apart form the simulation control, data, the DIS server mainly functions as an additional AirTraffic Server : it handles the « traffic service » of the EPOPEE data and the D/L messages.

NARSIM Status Requirements for 3FMS / remarksDIS Server Non - existing Shall be developed for 3FMS

5.3 Local DatabasesThis section describes which data bases are needed.

5.3.1 AirspaceThe data of the airspace the aircraft is crossing when flying from A to B must be available.

5.3.2 Airport dataThe data of the airports A and B must be available to integrate the taxi procedures for the air trafficcontrollers as well as for the pseudo pilots.

5.3.3 IFPsA data file of Initial Flight Plans (IFPs) must be available to generate simulated air traffic around theEPOPEE reseach simulator.

5.3.4 Meteo The file for the following meteo - data shall be based on a file from the UK MET-Office :• Actual Weather• Now – cast• Fore – castFor NARSIM, a local PLAID file will be deduced from these data.SIGMET data is not in the UK MET-Office file ; it will be added by hand. See also section 7.1.

5.3.5 A/C performance data (BADA)BADA models will be used for the A/C performance data.

5.4 Local RecordingTime stamps



6. Interconnection between the A/C simulator and the NARSIM simulator

6.1 Radio Telephony (R/T) connectionR/T connection will be done by a regular phone connection. The frequency selected by the EPOPEE willbe part of the data transferred from the EPOPEE to NARSIM. The selected frequency determines withwhich air traffic controller has radio contact. Of course, the pilot in the EPOPEE can hear all thecommands and clearances this air traffic controller issues to other A/C in the simulation.

6.2 Data connection

Figure 18 Data connection between NARSIM and EPOPEE

GRAPHIC STATION

GRAPHIC STATION

GRAPHIC STATION

GRAPHIC STATION

NARSIM3FMS

PROTOTYPE

Scramnet ISDN line

Arinc

Arinc, discretes, analogicinputs from cabin commands

Cabin videoscreens :DCDU, EFIS

SIMULATIONCALCULATOR

ELECTRONICINTERFACE

AS WORKSTATION

Ethernet802.3

Ethernet802.3

EPOPEE CABIN

VISUEL

MCDU

MCDU



6.2.1 Physical connection

As shown in the figure above, the physical connection between NARSIM and EPOPEE for data exchangewill be separated into three parts :• Between NARSIM and an AS workstation,• Between the AS workstation and the 3FMS prototype,• Between the 3FMS prototype and the EPOPEE simulator.

The physical connection between NARSIM and the AS workstation will be one (or may be more,depending on the amount of data to be exchanged) ISDN-2 line(s).The main advantages of ISDN are :• small propagation delay• good security aspects (in contrast with e.g. an internet connection) due to point to point connection.Let’s first remind ourselves some ISDN line characteristics : an ISDN line comprise two channels, with adata flow of 8Ko/s for each channel. If the two channels are multiplexed, the data flow can go up to16Ko/s, i.e 128Kbit/s.

Among the different envisaged solutions for connecting the NARSIM simulator in Amsterdam to theEPOPEE simulator located in Toulouse, apart from the ISDN link, the link that will be used is based onthe Scramnet technology. To determine this choice, three solutions have been analyzed :

1. Information exchange supported by an ISDN line passing through the Aerospatiale firewall. In thiscase, there is no possibility to multiplex any channels, what will limit the data flow to 64 Kbit/s. Thisvalue seems obviously too restrictive in the 3FMS project context. Besides, for security concerns, itmust be agreed between all the parties that none of the elements of the 3FMS demonstrator will beconnected to a public network, e.g. the Internet.

2. Information exchange supported by a specialized line through the Aerospatiale firewall, with an ATMprotocol (Asynchronous Transfer Mode). This solution allows a minimum data flow of 2 Mbit/s,which may go up to 45 Mbit/s. Though, the condition that there shall be no connection to any publicnetwork remains applicable. Moreover, such a line shows to be much more restrictive, in terms offinancial matters, than mere ISDN lines.

3. Information exchange through one or more ISDN lines, bypassing the Aerospatiale firewall but goingthrough a Scramnet dedicated workstation. The Scramnet technology uses a reflective memoryprinciple.

The agreed solution is the third one. The Scramnet dedicated workstation will be provided byAerospatiale; it will most likely be a SUN SS20 station. A Scramnet card is at present already installed onthis station. For validation purposes, it may also be lent to SXT during the NARSIM-3FMS prototypeconnection validation process. This solution indeed improves the data flow capacity : if three ISDN linesare used, the data flow can go up to 48Ko/s, i.e. 384Kbit/s. This should be sufficient in terms ofexchanged data amount and time responses.



Finally, the connection between the 3FMS prototype and the EPOPEE simulator will be based on anEthernet line. Data sent by the 3FMS prototype will go through the EPOPEE electronic interface,including the data sent for display on the cockpit screens (EFIS, DCDUs). The protocol used in particularfor the 3FMS-DCDU interface will be based on the ISO5 protocol, as used in ARINC429 High Speedconnections. The only connection which will not use an Ethernet physical link is the connection betweenthe 3FMS prototype and the MCDUs in EPOPEE. In this case, it was decided to use a normal ARINC429 High Speed connection. That implies that there will be an ARINC card within the 3FMS prototype.

6.2.2 Transmission Control ProtocolFor the transmission control protocol, TCP/IP will be used, with a point-to-point connection (nobroadcast).

6.2.3 Data Protocol.The data send and received by the application programs, must be structured according to a protocolknown on both sides of the connection. The Distributed Interactive Simulation (DIS) will be used in the3FMS project.DIS is especially developed as to provide (IEEE-) standard for the linking of various typesof simulations on different locations. A full set of formatted messages is defined in this protocol. Thesemessages are called Protocol Data Units (PDU’s). Different PDU’s are available for (amongst others)* simulation control (start, stop, acknowledge, etc.)* create/remove entities (the only entities in our case are aircrafts)* entity updates (updates of position, speed, etc. of a single entity).Beside a large set of very precisely defined PDU’s, also a “free” PDU is available for transmission of datanot foreseen in the DIS standard.It is important to note that in the 3FMS project context, the ATC+Traffic simulator (NARSIM) will beconnected to EPOPEE solely through the Scramnet workstation. There is to be no direct connection ofNARSIM to EPOPEE. Hence, the presence of a DIS data protocol within EPOPEE itself proves not to beuseful. However, the 3FMS prototype has to be provided with such a data protocol, and communicationbetween the 3FMS prototype and NARSIM will be supported by one or more ISDN lines.One of the interesting features of DIS is “deadreckoning”:By deadreckoning, an extrapolation algorithm is agreed between sender and receiver, and only a newupdate is send when the difference between the real value and the extrapolated value exceed a predefinedthreshold. By applying deadreckoning, the update rate can be decreased.For more detailed information on DIS, IEEE standard 1278.1 1995 (including description on a bit - levelof all the different PDU’s).

By using the DIS standard, the 3FMS project also may benefit from the Eurocontrol Air/Groundinterface which is largely based on DIS. However, in contrast with the standard DIS interface, the statevectors of all A/C’s in the simulation are sent in the same message (PDU). This may hamper real timesimulation and makes different update rate for different A/C’s in the simulation impossible.



6.2.4 Exchanged data

First of all, the proper exchange of data cannot be performed without a correct synchronization of bothsides (EPOPEE and NARSIM). In order to comply with this, the first data to be exchanged is the UTCtime. It may come either from the A/C sim clock or from GPS.Apart from that, three different types of data shall be exchanged :Simulation control data, simulated traffic/flight, datalink messages. For each type of data it is indicatedbelow which services are involved on the NARSIM side.

Simulation control dataThe EPOPEE simulator is provided with switch buttons that allow the simulation to be stopped, or to befrozen. There also exists a "standby" mode. For a correct dialog between both sites (Amsterdam andToulouse), the following parameters will be exchanged :1. Start simulation (only possible from Toulouse site)2. Stop simulation3. Freeze simulation4. Frequency selected by EPOPEE for R/T connection5. Parameter (ARS) selected by EPOPEE which determines the size of the region in which ADS-B is

applied; the initial value at the beginning of the simulation will be sent, as well as changes of thisparameter during the exercises.

Simulated traffic• NARSIM to EPOPEE

Not the data of all traffic in the simulation will be sent from NARSIM to EPOPEE; only ADS-Bmessages which are within « reach » of the EPOPEE, will be sent This is done to limit the loading ofthe data connection.Also for reduction of the data to be transferred, « dead reckoning » will be applied. Due to theextrapolation of the A/C positions on the EPOPEE site, it is needed to apply the same filtering asapplied on the NARSIM site (to check if the A/C are within the reach of the selected ADS-B rangealso on the EPOPEE site.

• EPOPEE to NARSIMAll relevant data relative to the simulated A/C has to be sent with an agreed « deadreckoning/extrapolation » principle

Since there will be a separate display dedicated to Taxi Management, there will also be a specific graphicworkstation on the A/C simulator for Taxi display purposes.

6.2.5 Data dynamics (Communication mechanisms)Things like:• Synchronous calls• Asynchronous calls• SubscriptionsWhat kind of communication mechanisms for which data?



7. Miscellaneous topics

7.1 Data basesNARSIM will uplink information from its airspace database and weather database

The airspace data base shall be based on the AIP with adaptations as small as possible to introduce FreeFlight Airspace.

7.2 Simulation ControlData exchange between the 3FMS prototype and NARSIM will be done via the ISDN lines and using theDIS protocol. Data exchange between NARSIM and the EPOPEE will be realised via the 3FMSprototype.The start command (via a DIS - PDU) will be of the form : « simulation will start at time xxx » ; thestart command will be possible at the Toulouse site only. Before a « start » command at Toulouse isissued, the NARSIM simulator shall be started via it’s supervisor and exec server.The stop and freeze command will be possible both on the Toulouse site as well as on the Amsterdamsite.

It is assumed that both the NARSIM simulator and the 3FMS communication computer will synchronisewith GPS time dayly.

It is assumed that the speed during all the simulations will be 1 (one).

There will be a possibility to monitor the 3FMS evaluation between Amsterdam and Toulouse throughvideo conference means. The Aerospatiale laboratory is indeed provided with a portable video conferencetool. Finally, there are also means to record the performance of the 3FMS evaluation sessions, thanks toaudio and video recording tools.

The actual configuration and experiment set-up will be described in the Trials Definition Document(TDD, WP 5.1, see reference 6).

7.3 Recording of the data exchanged between NARSIM and the 3FMSDescribed in the Trials Definition Document (TDD, WP 5.1, see reference 6).



X/2 NMX/2 NM

X NM

X/3 NM

Phase Ground Approach Cruise

Standard range X 5 NM 20 NM 90 NM

Extended (standardx2) range X 10 NM 40 NM 180 NM

Figure 19 Acquisition distance model



8. References

1. Michiels, R.W.F.J. A survey of the NARSIM C/S Middleware, NLR TP 96220 L,1996

2. Apeldoorn, M.C. NARSIM Software User Manual, NLR TR 97023 L, 1997

3. 3FMS Free Flight scenario Definition Document (FFDD, WP 1.1.)

4. 3FMS Functional Definition Document (FDD, WP 1.2.)

5. 3FMS Global Design Document (GDD, WP 2.1.)

6. 3FMS Trials Definition Document (TDD, WP 5.1.)

7. Michiels, R.W.F.J. PLAID, a Programming Language Independent Data Tool,NLR TR-95157, NLR, 1995

8. Beers, C.S. The NLR Air Traffic Control Research Simulator, GeneralSpecifications, NLR, 1999



Appendices

Appendix A General NARSIM information

A.1 Simulation RoomAlmost all NARSIM activities are concentrated in and around the NARSIM room.With over 120 sq. meters it is large enough to suit medium-sized ATC simulations. Simulations with 6ATCo’s, 11 HP workstations, 15 X-terminals for pseudo pilots (blipdrivers) and one technical experimentleader (and several observers) can be accommodated with ease.

Figure 20 Overview of NARSIM room

As NARSIM is regularly used for the evaluation of new operational procedures, it is important torealistically simulate the ATC environment. This means having proper (adjustable) illumination, airconditioning, no distracting reflections, adjustable working positions for the air traffic controllers and R/Theadsets.

A.2 Hardware specificationsThe two NARSIM hostcomputers are HP 9000 series computers, respectively model K580 (with 4processors) and model K380, both running HP-UX. With each approximately 800 MIPS, 512 MBmemory and 13 GB local disk space it can easily run simulations with moderately heavy algorithmicATM tools. For blipdrivers and for software development purposes 15 X-terminals (1280x1024) areconnected to the NARSIM hostcomputers. The display computers are HP 9000 series model 700computers.



The display controllers for the ATCo positions are two Metheus Omega 3720 controllers, one MetheusOmega 5700 controller and 5 Barco X controllers, all are connected to 2048x2048 Sony monitors and arecompatible with the X Window System.

Figure 21 NARSIM ATCo consoles

Together with touch-input devices and track balls these form the ATCo consoles. All NARSIMcomputers are inter-connected via a 100 Mbit/s base T LAN Ethernet. The two NARSIM host computerslink all NARSIM computers to the outside world via the Internet connected NLR wide network.

The NARSIM Radio/Telephony (R/T) system is a communication simulation system.

The main function is to dynamically route the audio signals as used in traffic control situations betweenthe various persons in the experiment, using headsets with microphones: - Air traffic controllers (local or remote by telephone lines), - Blipdrivers (Pseudo pilots) simulating the pilots, - Experiment leader, who is able to communicate with all or selected groups.

To record the experiment, to connect special audio sources and to interface to special equipment (i.e. theflight simulator) line level signals can be input or output.

An external host computer controls the routing of the audio signals. There are a maximum of 64 inputsand 64 outputs. A stereo headset counts as two inputs and outputs. There can be up to 16 independentchannels. Each input has an associated ’talk switch’ input that may automatically control the processing ofthe input/output signal.



The volume of the headsets is controlled at the operator position on the headset connection box.The NARSIM R/T can connect to the telephone lines using DTMF (Dual Tone Multi Frequency) dialling,detect incoming telephone calls, and detect busy tones.

A.3 Software SpecificationsNARSIM is built on a UNIX/X-window platform. The NARSIM software has been written in thefollowing computer languages: Fortran 77, C and ADA. The NARSIM function NCSGEN generates aC/S interface between the different NARSIM servers. This interface will be written in the Fortran, C orADA format. With NCSGEN it is also possible to integrate extern modules as a server within theNARSIM C/S architecture.

A.4 NARSIM architecture

As a research simulator the architecture of NARSIM is very important for flexibility in incorporation offuture concepts. The architecture of NARSIM should contain only limited assumptions on present ATCconcepts. Furthermore the architecture should provide a base supporting the maintenance of thisfrequently changing research simulator.

Figure 22 The basic architecture of NARSIM

The basic architecture of NARSIM is a distributed system. This architecture is shown in figure 22. In adistributed system the simulator is subdivided in several manageable components, called "servers". Theseservers contain the real ATC simulator functionality. Servers communicate with each other by means ofmiddleware, called GEAR. GEAR is highly flexible and efficient NLR middleware, which is alsoscalable. Use of middleware is typical for distributed systems. Its purpose is to abstract from low-levelcommunication characteristics. The GEAR middleware is built on top of the UNIX operating system,which in its turn runs on a hardware platform. Apart from GEAR, servers may interface with Tcl/Tkand/or XWindows to provide graphical user interfaces. NARSIM also contains pre- and post-processingtools, which are not part of the real-time environment. For this reason they are built directly on top ofUNIX and Tcl/Tk or XWindows.



The architecture described above is quite technical, but has really turned NARSIM into a flexiblesimulator. Only the top layer, containing the servers and tools, contain ATC knowledge. The bottom threelayers are independent of ATC. Since the top layer is the most interesting layer for an ATC simulator, itsarchitecture is also described below.

Figure 23 Overview of the ATC layer architecture

Figure 23, provides an overview of the architecture of the top (ATC) layer of NARSIM. The top-layerconsists of many components, tools and servers, which change regularly. Goal of the architecture is todescribe the constant conceptual part instead of the continually changing components. The architecturemakes only limited assumptions on ATC, by abstracting as much as possible from present changing ATCconcepts. This architecture can be subdivided into three parts, the preprocessing tools, the real-timesimulator and the post-processing tools. The real-time simulator can again be subdivided into thefollowing parts, which may consist of several components:• Air system: This part simulates aircraft, which can be controlled by a pseudo pilot. A real ATC

system will not contain this component.• Ground system/ATM tools: This part is almost identical to a real ATC system, it contains flightplan

administration and ATM tools.• Environment: Environment contains meteorological information and airspace definitions. Some parts

may be available in real ATC systems also.• Air/ground integration: Radar simulation and datalink simulation are examples of this part. Radars

have to be simulated because real radars can not detect simulated aircraft.• Simulation control: Control components to start/stop or change speed of a simulation are stored here.

This part also contains general monitoring features.The architecture described above has shown to be constant for past, present and far future simulations.However the contents of the described parts may change depending on the ATC concept.



Appendix B ADS-B

Call sign

Address Mode S address

A/C type

State vector

• 3D position

• 3D velocity vector

• Rate of turn

Status and intent information

• Emergency/priority status (normal, General emergency, Minimum fuel, Nocommunication..)

• Current trajectory changepoint (TCP)

Note 1

• Trajectory change point + n Note 2

Class code indicate the capability of an aircraft to support specificoperation as Station Keeping or free flight

Other information For example, information required for resolution coordination

Note 1: The TCP is the point in three dimensional space where the current operational trajectory is planed to

change and the estimated remaining flight time to that point. The TCP is defined as four elementsconsisting of the following:• Latitude• Longitude• Altitude• Time to go

Note 2:The number of required TCP should be high enough to allow the Conflict Detection to predict the trajectory

for the entire look-ahead time period.

ADS-B messages will only cover a certain altitude band which is relevant for the simulation.



Appendix C TIS-B

The Traffic Information Service (TIS-B) is based on surveillance ground-based systems that broadcasttraffic information for a given area. This service will allow non ADS-B equipped aircraft to be seen byothers traffic. It will operate during the transition phase.

The TIS-B application will be in charge of receiving TIS-B reports from the Traffic simulator andforwarding them to Traffic Situation function. TIS-B data is shown below.

Call sign

Address Mode S address

State vector

• 3D position

• 3D velocity vector

TIS-B messages will only cover a certain altitude band which is relevant for the simulation.



Appendix D CPDLC

Vertical Clearances (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

20 CLIMB TO AND MAINTAIN[Altitude]

Y Y

23 DESCEND TO ANDMAINTAIN [Altitude]

Y Y

Crossing Constraints (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

46 CROSS [Position] AT[Altitude]

Y Y

49 CROSS [Position] AT ANDMAINTAIN [Altitude]

N Y

51 CROSS [Position] AT [Time] Y Y61 CROSS [Position] AT AND

MAINTAIN [Altitude] AT[Speed]

N Y

62 CROSS [Position] AT ANDMAINTAIN [Altitude] AT[Time]

N Y

63 CROSS [Position] AT ANDMAINTAIN [Altitude] AT[Time] AT [Speed]

N Y

Lateral Offsets (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

64 OFFSET [Distanceoffset][Direction] OF ROUTE

Y Y

72 RESUME OWNNAVIGATION

N Y



Route Modifications (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

74 PROCEED DIRECT TO[Position]

Y Y

79 CLEARED TO [Position] VIA[Routeclearance]

Y Y

80 CLEARED [Routeclearance] N Y81 CLEARED [Procedure] Y Y94 TURN [Direction] HEADING

[Degrees]Y Y

Speed Changes (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

106 MAINTAIN [Speed] N Y111 INCREASE SPEED TO

[Speed]N Y

113 REDUCE SPEED TO [Speed] N Y116 RESUME NORMAL SPEED N Y

Contact/Monitor/Surveillance Requests (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

117 CONTACT [ICAOunitname][Frequency]

Y Y



3FMS ASAS Messages (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

EXPECT FREE FLIGHTMODE AT [Position]

N Y

EXPECT FREE FLIGHTMODE AT [Time]

N Y

CLEARED FOR FREEFLIGHT MODE

N Y

EXPECT TO TERMINATEFREE FLIGHT MODE AT[Position]

N Y

EXPECT TO TERMINATEFREE FLIGHT MODE AT[Time]

N Y

TERMINATE FREE FLIGHTMODE

N Y

MAINTAIN SEPARATION[Distance] BEHIND[Aircraftident]

N Y

REDUCE SEPARATION TO[Distance] BEHIND[Aircraftident]

N Y

INCREASE SEPARATIONTO [Distance] BEHIND[Aircraftident]

N Y

TERMINATE STATIONKEEPING AND MAINTAIN[Speed]

N Y

TERMINATE STATIONKEEPING AND REDUCESPEED TO [Speed]

N Y

TERMINATE STATIONKEEPING AND INCREASESPEED TO [Speed]

N Y

TERMINATE STATIONKEEPING

N Y



3FMS Taxi Messages (Uplink)AvailableinNARSIM

Requiredby 3FMS

Remarks

TAXI TO [Position] N YTAXI TO [Position] VIA[Taxiroute]

N Y

CROSS [Runway] N YHOLD SHORT OF [Position] N YGIVE WAY TO [Aircraftident] N YFOLLOW [Aircraftident] N YCLEARED TO LINE UP[Runway]

N Y

CLEARED FOR TAKEOFF Y Y

Responses (Downlink)AvailableinNARSIM

Requiredby 3FMS

Remarks

0 WILCO Y Y1 UNABLE Y Y2 STANDBY Y Y3 ROGER Y Y



Appendix E FIS

The FIS application is designed to enable FIS services to be provided to a pilot via the exchange ofmessages between aircraft avionics and FIS ground systems.

The FIS application will be in charge of receiving FIS messages from the ATC simulator and forwardingthem to Weather Situation function.

Significant weather phenomena (Uplink)Available inNARSIM

Requiredby 3FMS

Remarks

SIGMET data• validity period• weather phenomena1

• observed or forecast• area (poly-line)• lower FL or altiude• upper FL or altitude• direction of movement• speed of movement• change in intensity

N Y not yet available in NARSIM asair-ground message, currentlyavailable in a simplified dataformat

1 Significant en-route weather phenomena:-a) thunderstorm (obscured, embedded, frequent, squall line, obscured with heavy hail, embedded with heavy hail, frequent with heavy hail, squall line

with heavy hail)b) turbulence (moderate, severe)c) icing (moderate, severe, severe due to freezing rain)

For 3FMS only three weather phenomena messages, being : icing, turbulence and thunderstorms, willbe supportedFor 3FMS the FIS message « Airspace structure (Uplink) » will not be used

free flight - flight management system brite/euram project · free flight - flight management...

Documents