acg workshop, 17 feb 2004 – oata and single european sky technical aspects of oata acg workshop,...

ACG Workshop, 17 Feb 2004 – OATA and Single European Sky

Technical Aspects of OATA

ACG Workshop, 17 February 2004

Bert Nijhof, Shanda Cordingley


Logical Architecture

Why Logical?


Organisation (OCD/CONOPS)

Goals:

What must be done work flows; activities; communication patterns.

How is it done assign (sub-) activities to systems or

humans; departments; assign activities to departments.

System (OATA)Goals:

What are the Application Activities relations and dependencies.

How is it done software programmes and modules; computers; networks; interoperability standards.

Recapitulation of Principles


Old Approach:

Main functions, function and sub-functions

radar data processing flight data processing flow management avionics

Current Approach:

Objects, co-operating objects Aircraft Airway Flight Plan Sector Radar and the services they provide

(e.g. FL change)

ATM Application Activities


The controller requests a FL change

The Flight Plan Object coordinates the change, since it knows

which aircraft is flying the route

It will pose the question “Can this aircraft fly on FL x” to the Route Object;

The Route Object will ask the Airspace Object and the Airway Object,

whether the actual aircraft equipage allows to fly on FL x.

The Flight Plan Object will change the FL or it will reject the

change

Note that for this FL change the following operational issue must

be solved:

what is the scope (current sector, current centre, remainder of the route)

when is co-ordination required

e.g. FL Change


The issues addressed are purely related to the Operational Use of the System

The process used is a formal Engineering Method; Identify which Objects from the Operational Domain(s) should be represented in

the system Define the boundary of the responsibility of each object What questions about themselves should those objects be able to answer

(services)

The result is a LOGICAL ARCHITECTURE!

Operational & Engineering Skills required


OATA is concerned primarily with the ATM Application!OATA is concerned primarily with the ATM Application!

Communication

COTS Middleware

User Interfaces

ATM Application Logic

ATM Application Technique

Architecture Layers


Translation of operational requirements in formal, unambiguous

engineering language(No need for skills in theology to explain the meaning of plain text requirements

during factory- and site-acceptance testing)

Close daily co-operation between the architects and

operational experts is essential

Alignment of the requirements for all involved parties (ANSP,

Airlines, Airports, Aircraft builders, ATC Systems Manufactures,

etc.)

Alignment of the target dates for development by the involved

parties through the Evolution plan

Organisation of a European wide buy-in

Benefits of the Approach


OATA Logical Architecture

A formal unambiguous specification of the operational behaviour of future ATM/CNS

systems accepted by the stakeholders


Progress

2 out of 6 Iterations have been completed.


Iteration 1

Airspace Management; Use Case: Submit a Regional Airspace Use Plan for Feedback

Airport Operations Use Case: Taxi-in of an aircraft

ATC and Flight Management Use Case: File a Flight Plan Use Case: Change Flight Intent to Resolve Conflict

Aeronautical Information Management Use Case: Obtain Pre-Flight Update Briefing

Surveillance Air and Ground Surveillance


Use cases: Submit ACC Capacity Plan for Feedback; Resolve Ad-Hoc Conflicts; Handle Aircraft Departure.

Airport Operations (WP 4.2.7)

Cross-Domain Modules

Flight Manager(4.2.1)

En-Route + TMA ATCExecutive Planning

(WP 4.2.2) (WP 4.2.3)Aeronautical Information

Manager (WP 4.2.4)

Configuration Manager(WP 4.2.8)

ATFCM (WP 4.2.9)

Aircraft Operator(WP 4.2.10)

Avionics(WP 4.2.11)

Aircraft Derived Data Manager

(WP 4.2.12)

SurveillanceGround - Air

(WP 4.2.5) (WP 4.2.6)

some further developmentssubstantial development

completion of bottom-up work

Iteration 2 - In Progress

In progress

Not started


The Process


Overall Architecture Development Process

Logical Architecturedevelopment

Operational scenarios 2011

ATM/CNSDomains

ExamplePhysical

Architecture

Analyticvalidation

Safetyanalysis

Legacy systemsanalysis

Cross-domainsynchronisation

Transition andEvolution plans

ConsolidatedLogical

architecture


Iterations

New Architecture

Technical Review

(TRG)

Legacy Systems

comparison

IssuesArchitecture development

New scenarios and use cases

Domain’s initiated changes

Legacy Systems analysis


top

-do

wn

bo

tto

m-u

p

ATM 2000+, OCD, OIs operational scenarios and use cases

legacy system analysis, R&D results

Futureconcepts

logical modules, information view

module interaction diagrams

high level system requirements

modules, services, information system reqs (services and NFRs)

non-feasibility new ideas

non-feasibility, new ideas

Phase 1 Architecture

Phase 1 Issues - old and new

Updates to domain architectures

issues, opportunities

Stakeholders (ANSPs, Industry, ...) with Agency support

non-feasibility new ideas

"current" functionality and grouping

Legacy systems - current and planned

AVENUE

Other Consolidated Architecture R&D

APIs

Stakeholder plans NB: Iterative Process

Process


System Wide Information Management

Using Cross Domain Components


Cross domain modules: Ensure that everybody has the same information

Communicate updates immediately, everywhere

Ensure data ownership rights, etc

Are not just data stores but provide services standardise the services that will access the shared data, rather than

standardising the data, avoiding the risk that data will be used in a different way

Consequently everybody interprets the data in the same way!

Identification of data and functionality common to different ATM domains

Built in Interoperability delivered by Cross-Domain Modules



A common set of services and data and on top of that:

Domain specialisations (extensions) possible domain-specific data domain-specific services

Each physical system will need its own instance of these cross domain modules


CommonFlight

Manager

ATC

Specialisation

Common FM

TrajectoryFlight

ATC FM

SSR CodeTact Constraint

ATFM FM

Regulation

Specialisation E.g. Flight Manager (FM)


CommonFlight

Manager

AFTM

Specialisation

CommonFlight

Manager

ATCCommonFlight

Manager

ATC

Specialisation

CommonFlight

Manager

ATC

Specialisation

CommonFlight

Manager

Airline

CommonFlight

Manager

Airline

CommonFlight

Manager

Aircraft Operator

Specialisation

Instantiations e.g. Flight Manager


Overview of Logical Architecture


Multi-lateration

Aircraft Autonomous sensorsNavigation Aids Pilot

ADS - B

ACC & APPATCOs

Airport Operator

Overall Architecture: Overview

TWRATCOs

Middleware & Communications Layer

Air Surveillance

Ground Surveillance

Aircraft Navigation

Aircraft Surveillance

Flight Manager

Configuration Manager

ADD

Manager

Aeronautical Information

ManagerAircraft

En-route/APP ATC

Airport Airside

Operations


ServiceATFCM

Aircraft Operations

PSR, SSR Mode-S Radar

ADS Airport SUR

AIS AO Pilot

CNSATM


FMPAirspace Manager

Aerodrome ATC

METAOC


Short Term Conflict Mgt

Medium Term Conflict Mgt

SurveillanceFlight Management

ADD Manager


Management

Aircraft Navigation Aircraft Operations

Aerodrome

ATC

Configuration Manager

Arrival Management

Conformance Monitoring

Correlation

Air Traffic Controllers

Aircraft

Clearances, trajectories

FPL creation, cancellation, modification

Aircraft State

Aircraft State

Track information

Arrivals/Departures co-ordination

Track information

Flight information

Flight information

Flight info, update, co-ordination,

transfer

Conflicts, advisories

Alerts

AirspaceA

irspa

ce

conf

igur

atio

n da

ta

Sequence, advisories

Flight information

Alerts

Correlation information

a/c performances

ATC Architecture: Overview


Flight Plan Management

Constraint Management

Coordination Management

Flight Data Management

SSR Code Management

Trajectory Management

Flight Manager Decomposition


+strategic_constraints

FlightManagement

+ update_flight_intent()+ select_estimated_on_stand_time()+ check_coordination_conditions()+ atc_constraint_input()+ change_flight_information()+ propose_alternate_flight_intent()+ delete_proposal()+ change_proposal_status()+ generate_what_if_context()+ select_flight()+ find_flight_for_ssrcode()+ find_flight_for_callsign()+ find_next_linked_flight()+ select_flight_situation()+ get_flights_of_context()+ get_current_sector()+ update_current_sector()+ get_all_flights()+ compute_control_sectors_list()+ compute_informed_sectors_list()+ amend_control_sectors_list()+ amend_informed_sectors_list()+ replace_trajectory()+ request_push_back()+ push_back_clearance()+ retrieve_predeparture_information()+ transfer_communication()

SystemTrack

- latitude- longitude- altitude- time- 24_bit_address : 24bitsAddress

(from Track Manager)

Aircraft

+ is_equipped()+ retrieve_speed()+ calculate_max_flight_level()+ calculate_efficient_level()+ can_fly_trajectory()

(from Aircraft Module Structure)

Correlation

+ correlation_mode : CorrelationMode

+ create()+ destroy()

(from DRAFT)

1

0..1

+correlated_track 1

+correlation 0..1

TacticalConstraint

+ status : Boolean

(from ConstraintManagement)

StrategicConstraint(from ConstraintManagement)

FlightPlan

+ date_of_flight : Date+ departure_time : TimeOfDay

+ create()+ destroy()+ check_route()

(from Fl ightPlan)

0..*

1

0..* +aircraft

1

Trajectory

+ get_time_at_point()+ get_trajectory_point_at_time()+ list_top_of_descents()+ list_top_of_climbs()+ project_on_trajectory()+ is_manoeuvring_at_time()+ get_next_significant_point()+ compute_traversed_sector_sequence()+ get_estimated_landing_time()+ get_estimated_take_off_time()

(from TrajectoryManagement)

Route

- name

+ create()+ copy()+ destroy()+ change()+ find_departure_airport()+ find_destination_airport()+ is_SID_in_route()+ is_STAR_in_route()+ expand_portions()+ insert_SID()+ find_takeoff_runway()+ find_landing_runway()

(from Fl ightPlan)

0..1

1

0..1

+route

1

Flight

+ callsign : Callsign+ departure_airport : ICAOAerodromeID+ destination_airport : ICAOAerodromeID+ flight_state : FlightState+ priority : FlightPriority

+ create_alternative()+ set_SSR_code()+ create()+ destroy()+ update_with()+ find_takeoff_slot()+ expand_route()+ update()

10..1

+correlated_flight

1

+correlation

0..1

10..*

1

+tactical_constraints

0..*

0..*

0..*

0..*

0..*

0..1+flight_plan 0..1

0..1

1

+planned_trajectory0..1

+flight1

0..1

1

+tactical_trajectory0..1

1

0..1

+expanded_route

0..1

Details of Flight Data Management


Questions?

acg workshop, 17 feb 2004 – oata and single european sky technical aspects of oata acg workshop,...

Documents

single european sky

single european sky

single european sky

fl change slide

logical architecture

route f

process slide

approach slide