FLIGHT OBJECT

1
FLIGHT OBJECT
Flight Object Workshop Brussels June 4th 5th,
2008 Meeting
2
AGENDA

• CONTEXT AND APPROACH
• Jean-Guy RAVEL (THALES)
• MAIN PRINCIPLES
• Julian ALONSO (INDRA)
• TECHNOLOGY SELECTION
• Gianluca AGRESTA (SELEX)
• INTERFACE CONTROL DOCUMENTS
• MIDDLEWARE ICD - Gianluca AGRESTA (SELEX)
• ENVIRONMENT (AIM) ICD - Julian ALONSO (INDRA)
• FLIGHT OBJECT ICD Emile-Henri BALLAND (THALES)

3
EUROCAE WG59 TERM OF REFERENCE

•  Inter-operability Standardisation Of FLIGHT
  DATA Processing 
• Develop standards for FDP inter-operability up to
  the level of detail required for the
  implementation (comprising application and
  communication layers as required) with due regard
  to safety, security, performance, and
  implementation cost. These standards shall take
  due accountability of existing requirements for
  future FDP projects.
• Develop validation procedures for the standards
  in order to ensure that operational requirements
  can be met
• Develop compliance checks for the implementation
  of such a standard

4
EUROCAE WG59 WORK PLAN STEPS

• Several steps have been identified
• Flight Object Data Services modelling
• Architectural implications cooperation patterns
• Safety Assessment
• Technology assessment
• ICD definition
• Standard Proposal for the FO domain
• Necessary links with other SWIM domains (AIM,
  METEO ) to be addressed.

5
EUROCAE WG59 IOP STUDIES

• Stakeholders concerns are as follows
• Air Traffic Services Units
• Flow Management (ATFM)
• Airports,
• Airlines,
• Military Units,
• Aircraft
• ATC to ATC Ground-Ground IOP has been selected as
  the initial goal of the work as
• It is considered as an general enabler for all
  ATM stakeholders,
• There is a window of opportunity with the
  on-going eFDP implementation programmes
• ATC to ATFM Ground-Ground IOP corresponds to the
  next step that is currently on-going

6
SWIM -  TOP-DOWN  APPROACH 
Data Reference Model
T E C H N O L O G Y
S E R V I C E S
functional
Non-functional
Application independent "Middleware"
Network Backbone
7
SWIM -  TOP-DOWN  APPROACH 
Applications
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
8
SWIM -  TOP-DOWN  APPROACH 
Applications
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
Harmonisation also possible with other SWIM
domains (e.g. AIM)
9
EUROCAE WG59 IOP STUDIES

• Up-to-date Engineering processes have been
  applied
• FOIPS adopted the Unified Modelling Language
  (UML) to capture the nature of data services
  required for IOP .
• ICOG1 architectural principles have been
  identified with
• use case analysis based on ATC operational
  scenario,
• system requirements definition of architectural
  features,
• Safety analysis where hazards necessary
  mitigation means have been specified as part of
  the system requirements.
• ICOG2 ICDs have been produced with
• FOIPS refinement update based on ATC
  operational scenario,
• Identification of non-functional requirements
  (evolutivity, multi-versionning, )
• Technology selection through Benchmarking
• PIM / PSM approach to produce the ICD

10
EUROCAE WG59 DOCUMENTS

• EUROCAE document(s) for ATC to ATC Flight Object
  interoperability will be produced before end of
  2008 for
• Supporting on-going projects
• Provide technical material necessary for Single
  European Sky mandate (M390)
• Establish the SESAR baseline for FO SWIM domain

11
AGENDA

• CONTEXT AND APPROACH
• MAIN PRINCIPLES
• TECHNOLOGY SELECTION
• INTERFACE CONTROL DOCUMENTS
• MIDDLEWARE ICD
• ENVIRONMENT (AIM) ICD
• FLIGHT OBJECT ICD

12
ATC TO ATC MAIN PRINCIPLES

• One common environment
• Consistency of environmental data (AIM) is prime
• Availability of environmental data update is
  necessary
• Collection of information
• Each ATSU concerned by the flight contributes to
  common view
• Build a unique Flight Object
• For each flight, at any one time, one system is
  responsible for the establishment of the related
  Flight Object.
• Distribution of information (FO, ENV, )
• Distribution scheme defined for Flight Object
  environmental data

13
ATC TO ATC MAIN PRINCIPLES

• Flight Object handover management
• Dynamic allocation of Flight Object
  responsibility consistent with ATC handover.
• Coordination
• Fully support ATC coordination.
• Trajectory management
• Flight Script The flight intent expressed in
  the vertical horizontal planes together with
  the applicable constraints both strategic and
  tactical in all dimensions of the flight
  (route, level, speed, rate of climb/descent,
  time)
• 4D trajectory simulated execution of the script
  using also weather forecast and aircraft
  performance model
• Trajectory management provide a shared and
  consistent view of
• The flight script (consolidated with different
  contributions)
• The corresponding 4D trajectory with the same
  accuracy over the IOP area (related to the
  predicted distance/level).

14
COOPERATION PATTERNS - TERMINOLOGY
15
COOPERATION PATTERNS - IOP ROLES
USER CONTRIBUTOR
C(D1) U5(D1)
MANAGER
M(D1)
P1(D1)
USER
U3(D2)
PUBLISHER
U1(D1)
M(D2) U4 (D1)
P2(D2)
USER CONTRIBUTOR
USER
PUBLISHERMANAGER for D2
U2(D2) C(D2)
16
COOPERATION PATTERNS FLIGHT OBJECT

• For the Flight Object, in an ATC to ATC scenario,
  IOP roles are instantiated as
• The ATSU in control of the referenced flight is
• the Manager consolidation possible
  arbitration of constraints expressed by
  downstream ATSUs.
• the Publisher unique writer of the Flight
  Object for the referenced flight. Provides
  updates of the Flight Object to downstream ATSUs
  and relevant users (e.g. ATFM)
• The ATSUs traversed by the referenced flight are
  
• Contributors they provide constraints
  pertaining to their area of responsibility and
  anticipated for the referenced flight
• Users they are posted with the shared view of
  the Flight Object.
• Any interested IOP partner can be a User (e.g.
  AFTM for airborne flights).

17
COMMUNICATION PRINCIPLES (1)
Simplistic IOP Area A, B, C and D
B
A
D
C

• Example
• 4 AORs A, B, C, D
• One ATSU per AOR
• One IOP area (in green)

18
COMMUNICATION PRINCIPLES (2)
Awareness AOI of A
Awareness AOI of D
Awareness AOI of B
B
A
D
B
C
A
D
C
Awareness AOI of C
19
COMMUNICATION PRINCIPLES (3)

• 4 systems, one per ATSU
• Each ATSU
• Subscribes to flights
• Publishes flights
• Contributes to flights

B
A
D
C
A
B
C
D
Contribute to flights
Contribute to flights
C
C
Published flights
Subscribed flights
S
P
S
P
Published flights
Subscribed flights
20
COMMUNICATION PRINCIPLES (4)
Manager Publisher controlling
ATSU Contributors traversed ATSUs Users
interested participants (at least Awareness AOI
crossed)
F2
B
A
D
F1
C

• IOP area entry expected in B
• B Manager Publisher of F2

F1 crosses B awareness AOI gt B subscriber of F1
A
B
C
D
Contribute to flights
Contribute to flights
Contribute to flights
Contribute to flights
F1
F1
F2
Pub
Use
Pub
Use
Use
Pub
Use
Pub
F2
F2
F1
F1
F1
F1
21
COMMUNICATION PRINCIPLES (5)
F2
B
A
D
F1
C
 Post correlation  of F1 in Awareness AOI of A

• F1 under control of C
• C Manager Publisher of F1

A
B
C
D
Contribute to flights
F2
Contribute to flights
Contribute to flights
Contribute to flights
F1
Pub
Use
Pub
Use
Use
Pub
Use
Pub
F2
F2
F1
F1
F1
F1
22
COMMUNICATION PRINCIPLES (6)
F2
B
A
D
F1
C
 Post correlation  of F2 in Awareness AOI of B
D only subscriber to F1
A
B
C
D
Contribute to flights
Contribute to flights
Contribute to flights
Contribute to flights
F1
Pub
Sub
Pub
Sub
Sub
Pub
Sub
Pub
F2
F2
F1
F1
23
COOPERATION PATTERNS ENVIRONMENT

• For the Environmental Data, IOP roles are
  instantiated as
• Each ATSU is Publisher of dynamic environmental
  data pertaining to its area of responsibility
• No Manager might be necessary if no consolidation
  nor arbitration is required.
• Each ATSU is a User of Environmental Data.
• AFTM is a User of Environmental Data.

24
ATC Operational Scenarios

• Validation of the identified mechanisms (and
  their features) through operational scenarios
• Three examples of operational scenarios in the
  following slides
• Route approval
• AMAN
• MTCD

25
ATC Operational Validation Route Approval

1. Proposal made by Proposing ATSU
2. Validation of new route according to strategic
and traffic load constraints
3. Possible agreement with control operator in
Validating ATSU

• IOP mechanisms
• All ATSU share same Flight Object
• Manager/Publisher or Contributor proposes a
  change for the Flight Object or sets a constraint
• Coordination
• Flight Object consistency ensured by
  Manager/Publisher
• Updated Flight Object is distributed

26
ATC Operational Validation Arrival Manager

1. AMAN ATSU provides time constraints
2. Controlling ATSU takes tactical decision to
meet constraint

• IOP mechanisms
• All ATSU share same Flight Object
• Flight Owner or Data Owner proposes a change for
  the Flight Object or sets a constraint
• Negotiation
• Final Decision up to Flight Owner
• Updated Flight Object is distributed

• IOP mechanisms
• All ATSU share same Flight Object
• Manager/Publisher or Contributor proposes a
  change for the Flight Object or sets a constraint
• Coordination
• Flight Object consistency ensured by
  Manager/Publisher
• Updated Flight Object is distributed

27
ATC Operational Validation MTCD

1. Conflict detected by Giving ATSU in its
awareness Area of Interest
2. Conflict free coordination is agreed

• IOP mechanisms
• All ATSU share same Flight Object
• Flight Owner or Data Owner proposes a change for
  the Flight Object or sets a constraint
• Negotiation
• Final Decision up to Flight Owner
• Updated Flight Object is distributed

• IOP mechanisms
• All ATSU share same Flight Object
• Manager/Publisher or Contributor proposes a
  change for the Flight Object or sets a constraint
• Coordination
• Flight Object consistency ensured by
  Manager/Publisher
• Updated Flight Object is distributed

28
AGENDA

• CONTEXT AND APPROACH
• MAIN PRINCIPLES
• TECHNOLOGY SELECTION
• INTERFACE CONTROL DOCUMENTS
• MIDDLEWARE ICD
• ENVIRONMENT (AIM) ICD
• FLIGHT OBJECT ICD

29
AGENDA

• CONTEXT AND APPROACH
• MAIN PRINCIPLES
• TECHNOLOGY SELECTION
• INTERFACE CONTROL DOCUMENTS
• MIDDLEWARE ICD
• ENVIRONMENT (AIM) ICD
• FLIGHT OBJECT ICD