The Network

Management Systems
The NM context
The NM Service layer architecture
 The Network Technical Systems (NTS)
• The Flight Plan Management Systems
support the collection, validation and
distribution of the flight plan data required to
assess the demand on the global ATC system;
• The Flow & Capacity Management Systems
relate the demand to the available capacity
and in case of capacity shortfall propose
ATFCM measures;
• The Environment Data Management
Systems maintain and distribute the
(geographical) structure of the ATC system as
well as other shared information;
• The Service Layer Systems and Client
Applications allow external, as well as
internal, NM stakeholders to access and
Flight Plan Management Systems
 The Initial Flight Plan Processing System
(IFPS): designed to rationalise the reception,
initial processing and distribution of flight plan
data related to civil aviation flights within the
area covered by the participating States.

 The Repetitive Flight Plan Processing

System (RPL): receives processes and stores
Repetitive Flight Plans submitted by the Aircraft
Operators.
 IFPS redundancy
• The IFPS processing is distributed on two
geographically separated units: one (IFPU-1)
in Haren, Brussels, and the other (IFPU-2) in
Brétigny-sur-Orge near Paris.
• The basic principle is that no Flight Plan
Message (FPM) can ever be lost, even in case
of major failure. It is acceptable, on the other
hand, that some messages get duplicated
during the switchover procedure.
• At any time, all FPMs are received by both
IFPUs. One IFPU is marked as “Responsible”
for the FPM. The other IFPU is marked as
 FILING TO IFPS

AO SUBMIT
 ATFCM NMOC

(ACK) (MAN) (REJ)

IFPS
ARO ATS MESSAGES

IFPS ZONE

 “Direct” filing preferred

when ADEP inside the IFPZ 
Filing in accordance with AIP of State
where ADEP located outside the IFPZ
 Flight Plan

• (FPL-SWR1607-IS
-SF34/M-SR/S
-LIMC1635
-N0276F190 ABESI/N0277F180 N851 ELMUR L613
HOC W102 BALIR Z59 LUMEL
-LFSB0109 LSZH
-REG/FGPKM SEL/NONE DOF/030618 EET/LSAS0012
LFEE0055 RVR/550 RMK/RTE 11 RMK/SEQ10001)
 Flight plan assistance tools (IFPUV): for
improving the quality of the flight plans submitted
to IFPS. The IFPUV is a separate system, totally
independent of the operational IFPS, providing
two main services:
o Flight Plan Validation: solely for the purpose of
submitting test Flight Plans.
o Route Generation: accepts a partial flight plan
as input and generates up to 10 alternative
routes, sorting them by cost.
 The Flight Assessment and Alert System
(FAAS): designed to host various alerting
functions as required by member states
(ECAC) and the European Commission (EC).
o Safety Assessment and Alert System
(SAFA): alerts the competent authorities to
ensure that Aircraft Operators (AOs) or
specific Aircraft that have been banned by
the European Commission do not operate in
the European airspace.
o ACC3/CARGO: alerts the competent
authorities to ensure that Cargo Aircraft
Operators’ flights entering the European
airspace satisfy security regulations, for
departure airports in third countries.
 The CallSign Similarity Tool (CSST): to
detect and de-conflict callsign similarities in an
automated manner; used by Aircraft Operators
(AOs) and the CallSign Similarity Management
Cell (CSMC) to help de-conflict flight
schedules.
Flow and Capacity Management Systems
 The ENHANCED TACTICAL FLOW
MANAGEMENT SYSTEM (ETFMS)
• task of NMOC
– avoid overloading of airport and ATC
– optimise the usage of the airspaces
• How ???
Regulation:
– Delay (NMOC resp.)
– Rerouting (Airline resp.)
– Level capping (ATC)
– increase capacity of the environment
• military airspace
 ETFMS DATA INPUT

AO
FLIGHT PLANS
ATC/AO NMOC/AD
AIRCRAFT ENVIRONMENT
POSITION DATA

ETFMS
ATC/Airports NMOC/FMP
FLIGHT DATA ATFCM
UPDATE MEASURES
 ETFMS functionality
The ETFMS core functionality is provided by three main
processes:

•The Profiler process handles the flights known to the

ETFMS system. It computes their 4D-profiles and
maintains their states.

•The Counter process computes lists and counts of flights

per traffic volume. The number of Counter processes is
configurable.

•The Regulation process maintains the regulations and

allocates slots for the flights in the currently active
regulations.
 ETFMS Traffic Models

• ETFMS maintains three views (called models) of the current traffic

situation:
– The Filed Tactical Flight Model (FTFM) that corresponds to
the demand computed from the filed flight plans – i.e. the
flights as they are provided by IFPS (and the AO).
– The Regulated Tactical Flight Model (RTFM) corresponding
to the FTFM with all regulations taken into account – the flights
affected by a regulation.
– The Current Tactical Flight Model (CTFM) that is the RTFM
updated with real-time operational data (the correlated position
reports) – the airborne flights.
Horizontal profile re-calculation

Time
updates
C D
B 21Nm

+ Predicted
route E
A
Correlated Time and
Position path updates
Report (CPR)
 Vertical profile re-calculation

Flight Plan Predicted

ATC intention

Reported profile
 ETFMS DATA DISTRIBUTION (DDS)

TRAFFIC
SLOT
SUMMARIES
MESSAGES

ETFMS

FLIGHT
COUNTS LISTS

EFD
MESSAGES
 The Centralised SSR Code Assignment and
Management System (CCAMS): a tool to optimise the
allocation of SSR codes, based on profile information
(from flight plans), delay and suspension information, and
airborne information. CCAMS functionality is provided by
the ETFMS system.
 Alleviates
limitation
s of the
ORCAM
system
 Fills the
gap until
new SUR
technolog
ies (e.g:
mode S)
are
 The PREDICT system:
 has the same functionality as ETFMS but it is used for
pre-tactical operations
 uses archived information to assess the traffic
situation over the coming days
 compares forecasted traffic and capacity to predict the
load situation for the following days (up to 6 days in
advance).
 Scenarios can be implemented in this system in order
to assess the impact of ATFCM measures before
being applied in ETFMS.

 The Simulation Tool (SIMEX):

 used in strategic, pre-tactical and tactical ATFCM
operations.
 It enables Network Operations staff to simulate
Environment Data Management Systems
 The Environment Data Management systems

maintain and distribute the airspace information

used by the Network Technical Systems.
Main responsibilities :
Airspace Data Management: maintenance of all
the airspace structure data required to run
ATFCM operations, including the validation
processes to allow operational use of the data,
and distribution of the airspace data to all NM
systems that require it.
Support of the Airspace Management (ASM)
process: consolidation, coordination and
 The ENV system is used for data maintenance
and distribution.
 Implemented via several inter-communicating
ENV system instances:
o An ENV Master instance where data
modifications take place.
o An ENV Slave instance, which is an off-site
replica synchronised with the ENV Master
and ready to take over the Master role when
the contingency plan is activated.
o One or more ENV Client instances, used by
the client applications in read-only mode.
o An additional read-only ENV standalone
 The ENV Validation Tool is used to anticipate
and solve potential problems in the course of
the AIRAC Data preparation process.
 The new version of the environment data is
submitted twice to standalone versions of the
NM systems that will use it, in order to validate
and assess the quality of the data for
operational use.
 This tool is also used to prepare, validate and
evaluate the impact of large airspace
modifications during the strategic phase.
Historical Information Management Systems
The Historical Information Management systems
• correlate all the sources of information
concerning the flights handled by the Network
Technical Systems. Raw data is archived for a
maximum of 2 years.
• daily aggregate flight data (kept for 5 years) and
compute statistics (kept for 15 or 5 years) on:
 General traffic flow
 Airspace
 Departure and arrival
 Regulation
 Rerouting proposals
 ASM Monitoring
NM Service Layer Systems and Client Application
Access to the Network Technical Systems is in
general provided via two layers:
 NM Service Layer: Provides the infrastructure
allowing client applications to access the
provided services, providing an isolation layer
above the NM Business Applications.
 Client Layer: Client applications that provide
users with an interface to NM services.
Access for external clients (e.g. ANSPs, AOs)
goes through these layers. However, some users
internal to the Network Manager still have
dedicated interfaces that access the NM Business
Applications directly.
 NM Service Layer
 NOP Portal: a web application providing an HMI to
access the NM services;
 provides a consolidated view of the different aspects
of the Network Operations Plan (NOP);
 gives access to a set of services to support the NOP
preparation and dissemination activities.

 B2B Web Services: system-to-system interfaces to

access both NM data and services, using an external
exchange model.
 allow NM users to exploit and use the information in
their own systems, according to their business needs.
 support the interoperability required in the ATM
systems in a way that is compatible with SWIM
 NM Client Layer
provides external access to the Network Technical Systems through:
 Web Browser: providing access to
o NOP Portal web application.
o Network Manager static pages, a classical web server where
general NM information is made accessible via Internet. The NM
static pages are mainly served by the EUROCONTROL
Headquarters infrastructure.
o NMIR, a web-based interface to the Business Intelligence System
for post-ops analysis and reporting.
o Remedy and Claim Management System (CCMS), supporting
process workflows.

 CHMI (Collaboration Human Machine Interface): a standalone Java-

based client application that can communicate with the NM systems
over the Internet or through the NM Extranet (PENS).

Actors may also use B2B External Applications, which make use of the
The NOP Portal
 The CHMI (1)
The CHMI (Collaboration Human Machine
Interface)

services and interfaces:

– Traffic monitoring.
– Traffic load status for the Flow
Management Positions (FMP).
– Show ATFCM measures: regulation list and
description; list of reroutings.
– Show traffic/flow counts.
– Show flight lists & details for individual
flights.
– Request slot swapping (limited to chaotic
 CHMI (2)
– Show tower departure lists.
– Show suspended flight lists.
– ATFCM message exchange.
– Issue slot-related messages (CASA).
– Show departure and regulation delays.
– "WHAT IF RE-ROUTE" facility.
– Create, read, update, delete environment data
(ENV).
– Show and update ATFCM environment data
(ETFMS/Predict).
– Management of AUP/UUP.
– The same CHMI framework is used to provide five
different types of interfaces, each exposing
different sets of functionality:
 CHMI (3)
Route Assistance through:
– Flight plan validation (access the IFPUV),
– Route generation

Geographical display (map) of information including:

– Geographical display of environment data (e.g.
country borders, airspaces, aerodromes, points);
– Geographical display of the regulations and the
average delays;
– Geographical display of the flight paths;
– Graphical display of the vertical profile.
CHMI FMP monitor
CHMI Traffic Counts Graph
CHMI Flight lists
flight on the CHMI Vertical Map
CHMI Traffic Volume Map Colour

The default colours

are:
a) Red Overload
b) Yellow Low
threshold
c) Orange High
threshold
d) Green Normal