Sju dow wp09 v4 0 by SESAR JU

WP 9 - Aircraft Description of Work (DoW)

Version 4.0

Released 17/12/2008

Table of content WP 9

Aircraft.............................................................................................. 5

Sub-Work Packages and Projects overview .....................................................................20

SWP 9.0

Global Co-ordination and Management....................................... 23

SWP 9.1

Airborne Initial 4D Trajectory Management................................. 29

SWP 9.2

Airborne Full 4D Trajectory Management & 4D contract capability........................................................................................ 36

SWP 9.3

Interoperability of Business Trajectory and Mission Trajectory 41

SWP 9.5

ASAS-ASPA ................................................................................... 45

SWP 9.6

ASAS ASEP.................................................................................... 49

SWP 9.9

RNP Transition to xLS (x = G, I, M)............................................... 54

SWP 9.10

Approach with Vertical Guidance APV ........................................ 57

SWP 9.11

Aircraft Systems for Wake Encounter Alleviation ...................... 60

SWP 9.12

GBAS Cat II/III ................................................................................ 64

SWP 9.13

Airport Surface Taxi Clearances .................................................. 68

SWP 9.14

Airport Surface Alerts (ownship and traffic) ............................... 75

SWP 9.16

New Communication Technology at Airport ............................... 82

SWP 9.19

SWIM Air-Ground Capability......................................................... 85

SWP 9.20

Military Datalink Accommodation ................................................ 91

SWP 9.21

ADS-B - 1090 Higher Performance Study .................................... 96

SWP 9.22

Mid & Full ADS-B Capability - Research.................................... 100

SWP 9.24

ADS-B In/Out for military aircraft ............................................... 105

SWP 9.27

Multi-constellation GNSS Airborne Navigation Systems ......... 108

SWP 9.28

Enhanced Vision (Head Down and Head Up) Solutions........... 113

SWP 9.29

Enhanced & Synthetic Vision ..................................................... 117

SWP 9.30

Weather Hazards / Wake Vortex Sensor .................................... 120

SWP 9.31

Aeronautical databases .............................................................. 123

SWP 9.33

ATS Datalink Operational Improvements .................................. 128

SWP 9.38

ASAS â&#x20AC;&#x201C; SSEP ............................................................................... 133

SWP 9.39

Continuous Climbing Cruise ...................................................... 134

SWP 9.40

Long-term CDA & Steeper Approach Airborne Architecture... 136

SJU DoW WP09 V4.0.doc

Page 2 of 143

SWP 9.44

Flexible Communication Avionics ............................................. 138

SWP 9.47

TCAS Evolution ........................................................................... 140

SWP 9.48

AIS/MET Services & Data Distribution....................................... 142

SJU DoW WP09 V4.0.doc

Page 3 of 143

Level 1 â&#x20AC;&#x201C; Work Package Description

SJU DoW WP09 V4.0.doc

Page 4 of 143

WP 9

Aircraft

WP 9

Title: Aircraft

Generic typology of expertise 1) Operations: • SESAR ConOp, • ATM Operational Concept (En Route, TMA, Network management, environment…), • ATM Operational Experience (En Route, TMA, Network management, environment…), • ATC users requirements (ground & air), • Airspace users, airport operators and airlines operators requirements, • Pilot/aircraft capabilities and constraints, • Military specific needs, • Validation methodologies,

runway runway

2) System: • System engineering, prototyping, • System development, • System Architecture, SOA, • ATM tools (Airport systems, CNS, Flight Operations Center, Network…), • Aircraft and avionic; • Datalink / data communication, • Ergonomics, Human-machine Interface (HMI) • Information management, • Verification methodologies, 3) Business, management and coordination: • Understanding of SESAR Programme objectives and work breakdown structure, ATM Master Plan and Target Concept & Architecture, • Safety, security and environment performance measurement, • Performance management and analysis, business case analysis, • Project management, • Quality management. 4) Pan-European ATM expertise: • Technical expertise, knowledge and capabilities related to the European network as a whole, • Development of pan-European Air Traffic management solutions, encompassing Civil/Military dimension. Concept & Objectives The future, performance-based European ATM system, as defined in the SESAR ATM Master Plan, foresees greater integration and optimum exploitation of the aircraft. In order to reach this objective a series of CLs (Capability Levels) have been scheduled. Each CL provides a stepped performance improvement, synchronised across all components (and stakeholders) of the ATM system.

SJU DoW WP09 V4.0.doc

Page 5 of 143

WP9 focuses on the aircraft system elements covering the development and validation of the airborne enablers necessary to support the (OIs) Operational Improvements associated with each of the capability levels CL 2, CL 3 and CL 4. The principal evolutions to the aircraft platform are summarised below, and in the extract of the SESAR Master Plan Aircraft Roadmap • 4D Trajectory management functions will be progressively introduced. Initial steps include the improvement of the Required Time of Arrival (RTA) function. Within aircraft capability level 3 the ability to take into account multiple time constraints and more complete and real time meteo data will be implemented, providing full gate to gate 4D trajectory management by aircraft capability 4; • Aircraft Separation Assurance develops progressively from the ATSAW functions to improve awareness, through spacing to optimise TMA operations, and finally separation delegated to the cockpit. • Approach functionalities are progressively enhanced to provide improved all weather operations, through the addition of new functions and technologies such as GBAS, Enhanced Visual Systems and wake vortex detection. • Surface movement operations are improved through the introduction of functions to initially provide guidance and then provide automatic taxi functionality. In order to support the above evolutions, enhancement and additions to the CNS Technologies are foreseen, including updates to ADS-B, a new air-ground datalink and improved navigation positioning technologies.

Aircraft Roadmap (extract from SESAR Master Plan) WP9 groups the activities necessary to deliver the above evolutions in an efficient and timely

SJU DoW WP09 V4.0.doc

Page 6 of 143

manner across all types of airborne platforms, and hence the objectives of WP9 can be summarised as: 1) To develop and validate at aircraft level all airborne functions (and associated demonstrators) identified in the SESAR ATM Master Plan aircraft Capabilities Levels 2, 3 & 4, and to support the "System of Systems" definition and validation. I.e. • Analyse the operational impact on the aircraft, and per aircraft types •

Develop and validate the aircraft functions (common functions, and specialised functions where applicable for some aircraft platforms);

•

Develop and validate an airborne Sub-System Demonstrator;

•

Contribute to the overall operational definition and validation,

2) To ensure operational & functional consistency across stakeholder airborne segments (Commercial Aircraft, Business Aviation, General Aviation, Military Aircraft, UAS, etc.). 3) To identify solutions for all airborne platform types (Mainline aircraft, Regional aircraft, Business Jets, Rotorcraft, Fighter/trainer, UAS, VLJ, etc.) 4) To assure, as far as possible, coexistence and interoperability between different airborne platforms 5) To ensure global interoperability and coordination with important external initiatives (e.g. JTI Clean Sky, NextGen). 6) To make proposals and provide inputs to update the SESAR Master Plan. The WP9 core work component comprises a number of Projects (at level 2 of the SESAR WBS). Derived from the SESAR Master Plan, these projects have been further consolidated with the initial list of aircraft projects developed in the SESAR definition phase Deliverable 6, and then structured within a rigorous and coherent set of WP activities and processes. Description of Work Context of WP9 with other SJU WPs The context of WP9 and its principal links with other SJU WPs is described below, and summarised in the figure below:

SJU DoW WP09 V4.0.doc

Page 7 of 143

WP B High Level Target Concept & Architecture

WP 16 Transversal areas

Overall high level operational view / Business View Enterprise Architecture (EA) Framework Guidelines and support for system engineering Planning and Coordination WP Performance Framework Validation Framework Overall Validation Strategy

- Validation plans and schedule - Consolidated platform / tool requirements

Operational WPs

WPs 4, 5, 6, 7

- Apportioned air-ground system requirements

WP 3 Validation Infrastructure

WP 9

- Development plans of validation platforms & tools - Planning of availability of systems & prototypes for integrated / pre-operational validation

- OSEDs, SPR

- Contributions to OSEDs, SPR, INTEROP - Airborne Prototype - Validation reports

Consolidated Validation Requirements WP Validation Strategy Consolidated Validation Plans Consolidated Validation Report Methodology Usability and request for improvement Performance framework related information Methodology Usability and request for improvement

System WPs

WP 15

- Airborne Prototypes for overall A/G CNS validation - Validation plans for airborne components

Context of WP9 with other SJU WPs •

WP9 reports to S-JU, in terms of overall management, technical and validation activities o WP9 applies management rules and principles in accordance with S-JU guidelines; o WP9 receives technical guidance in terms of overall R&D activities from, and reports on technical content to S-JU; o WP9 provides to WP3 consolidated validation infrastructure requirements; o WP9 receives its overall planning information from WPC (Master Plan Maintenance). As appropriate, WP9 provides proposals to modify/update the Master Plan.

•

With the support of S-JU, strong coordination exists between WP9 and the operational WPs 4 to 7. In the lifecycle these provide the operational requirements to WP9. Conversely, WP9 supports these WPs in their operational definition and system of systems validation activities.

•

Strong technical coordination is also required with WP15 CNS with joint activities to develop the system requirements and make technology selections. WP15 “leads” or orchestrates the system development for all overall air-ground systems and technologies. Airborne partners contribute to the overall air-ground system definition activities through their participation in WP15. Subsequent dedicated airborne activities are then performed within dedicated WP9 projects that are aligned and synchronised with their WP15 counterparts.

The interface with operational WPs and with WP15 is further depicted in the following diagram,

SJU DoW WP09 V4.0.doc

Page 8 of 143

representing the overall idealised â&#x20AC;&#x2DC;Vâ&#x20AC;&#x2122; lifecycle. Initially the operational WPs provide the operational requirements, such as SPRs, OSEDs etc. However, this does not imply that WP9 activities cannot start before Operational WPs deliver those inputs, as existing on-going activities and initial results could be used as baseline hypothesis. Coherency check between those baseline hypothesis and Operational WPs deliverables must be planned and performed, to limit any risks in further steps. If the element is an air-ground element, WP15 is responsible for developing the overall air-ground system functional requirements and apportioning the airborne elements. Subsequently WP9 develops the Airborne solutions. In the right (exit) path of the V, WP9 first validates its airborne components, and then WP15 validates the overall air-ground components, before passing to the operational WPs, for operational validation.

Operational WP activities

Service Description Interop, SPR

Overall Operational validation : - System of System s Integration and Validation

WP15

Global System Definition and Validation

Global System Technical Validation (if applicable)

(if applicable)

Onboard Operational Definition and Validation

Airborne Sub-System Demonstrator Validation at Aircraft Level

Functional Definition and Validation Airborne Sub-System Demonstrator Definition

WP 9 activities Relationship with Operational WPs and WP15 for the development of Air-ground systems. WP9 interface with the SWIM activities is shown in the diagram below. As with the previous working arrangements, WP15 acts as the primary interface for SWIM activities, developing the overall requirements with WP9 being apportioned responsibility for the detailed Aircraft development activities.

SJU DoW WP09 V4.0.doc

Page 9 of 143

WP 4 En Route

WP 5 TMA

WP 6 Airport

WP 7 Network

WP 8 Information Model

WP 14 SWIM Aircraft requirements

WP 15 CNS PROJECTS

Input for SWIM Validation

Non-Aircraft requirements

Requirement consolidation

WP 9 AIRCRAFT

End to End Technical validation

Airborne Prototype development

WP 15 CNS PROJECTS Non Avionics Prototype Development

Relationship of WP9 with SWIM activities concerning information related topics WBS Overview WP9 is decomposed into a number of level 2 work packages, each covering a specific Airborne function (project). A separate work package (WP9.0) covers the management activities.

WP 9 - Aircraft WP 9.0 Global Coordination and Management

WP 9.1 Airborne Function (Project)

WP9.2 Airborne Function (Project)

WP 9.X Airborne Function (Project)

• System definition • System validation High level WP9 WBS

SWP9.1 – SWP9.X Airborne functions (Projects)

SJU DoW WP09 V4.0.doc

Page 10 of 143

These WPs perform the core definition (including development) and validation activities and ensure timely delivery of the airborne platform functions as defined in the Master Plan. These are described in detail in section 3 of this WP9 DOW. In general1 each Project is further decomposed into a number of WA (work areas), and sub work areas, in order to clearly identify and apportion, activities that are a) common to all aircraft platforms, such as overall definition, and b) those activities that are specific to a particular airborne platform. For example the architecture, prototype development and subsequent airborne validation of large jet aircraft, requires different expertise and facilities than that of business jets or regional turbo prop aircraft. The decomposition is kept flexible, to enable the addition of other platform types as appropriate; E.g light GA, regional jets etc. The figure below shows a typical partitioning of a project, in order to apportion the platform independent and platform specific activities. WP9.02 contains monitoring activities to ensure consistency for similar platform types, across the various Projects. WP9.1 WP9.1Airborne AirborneFunction Function (Project) (Project)

WA1 WA1Definition Definition Platform independent Platform independent

WA2 WA2Validation Validation Platform Platformspecific specific

Function requirements High level architecture Mainline Mainlineaircraft aircraft

Business BusinessJets Jets

Turbo TurboProps Props

Other Otherplatforms platforms (as appropriate) (as appropriate)

For each platform type System architecture and definition HMI definition Prototype development Validation platform integration Test and trials

Typical partitioning of a Project into work areas in order to apportion activities for difference aircraft types. WP9 Projects are derived from the SESAR Master Plan, with each delivering an airborne enabler to support one, or a number of Operational Improvements (OIs). It is noted that most WP9 enablers, and consequently most WP9 projects, support a number of OIs. The next figure shows an example extract of the SESAR Master Plan, where for example a number of aircraft system (A/C) and technology (CTE) enablers support the ATSAW OI step for Capability Level 2.

This applies only to projects where different airborne platform type developments are foreseen. E.g. mainline aircraft, regional aircraft, Military etc.

SJU DoW WP09 V4.0.doc

Page 11 of 143

Example extract from SESAR Master Plan The list of WP9 projects has been further consolidated from the initial draft list of projects developed for the SESAR definition phase, deliverable D6. Approximately 26 projects have been identified, of which 20 have been identified as candidates with a start date in the 2009-2010 period. A summary of these projects, together with their OIs and capability level mapping is provided in the table below. A list of the projects candidates for a start in the period beyond 20092010 is provided in the next below. This second list is indicative and may be subject to revision, depending on first list projects results and potential Master Plan coverage issues identified in the course of the SESAR programme. Level 2 WP ID

Domain

9.1

Title Airborne Initial 4D Trajectory Management

4DTrajectory Management

SJU DoW WP09 V4.0.doc

OI Steps supported

Capability Level

AOM-0206 AOM0304 AOM-0501 AOM-0502 AOM0702 AOM-0704 AOM-0804 AUO0302 AUO-0303 AUO-0504 AUO0703 CM-0401 CM0601 CM-0602 CM0603 CM-0604 CM0701 CM-0702 IS0302 IS-0303 IS60402 TS-0103 TS0105

Enabler ID A/C-11 A/C-31 A/C-33 A/C-36 A/C-37 A/C-45

Page 12 of 143

9.2

Airborne Full 4D Trajectory Management & 4D contract capability

AOM-0206 AOM0304 AOM-0501 AOM-0503 AOM0702 AOM-0804 AUO-0302 AUO0303 AUO-0504 AUO-0703 CM-0501 CM-0401 CM-0601 CM-0602 CM-0603 CM-0604 CM-0702 IS-0303 IS-0305 IS-0406 IS-0501 IS-0707 IS-0709 TS-0103 TS-0105 TS-0106

A/C-12 A/C-14 A/C-31 A/C-33 A/C-34 A/C-37 A/C-38 A/C-46 A/C-47

9.3

Interoperability of Business Trajectory and Mission Trajectory

AOM-0304 AOM0202 AOM-0302

AAMS-11 AIMS-19

9.5

ASAS – ASPA

AUO-0504 TS0105 AUO-0302 AUO0504 AUO-0703 CM0601 CM-0603 CM0701 CM-0702 TS-0105

A/C-15 A/C-33

9.6

ASAS – ASEP

AUO-0302 AUO0504 AUO-0703 CM0601 CM-0603 CM0701 CM-0702 TS-0105

A/C-16 A/C-33

9.9

RNP transition to xLS (x=G, I, M)

9.10

Approach with Vertical Guidance APV

AUO-0602 AOM0702 AOM-0704 CM-0602

1,2

A/C-01 A/C-05 A/C-06

Aircraft Systems for Wake Encounter Alleviation

AUO-0504 CM-0704 CM-0804 IS-0406 IS-0710

A/C-08 A/C-30 A/C-50 A/C-54

9.12

GBAS Cat II/III

AO-0505

CTE-N4B

9.13

Airport Surface Taxi Clearances

AUO-0302

AGSWIM56

Airport Surface Alerts (ownship and traffic)

AUO-0605

A/C-43 AGSWIM47

New COM Technology at Airport

AUO-0302

CTE-C4B

SWIM Air-Ground Capability

IS-0710

CTE-C2B

ASAS

9.11

9.14

Terminal & Approach Operations

Airport Surface Operations

9.16 Technology Enablers 9.19

SJU DoW WP09 V4.0.doc

AUO-0303

Page 13 of 143

9.20

Military Data Link Accommodation

AOM-0304 IS-0709

IS-0706

CTE-C3

9.21

ADS-B - 1090 Higher Performance Study

TS-0105 0701

CM-

A/C-48 A/C-49 CTES2B/C

9.22

Mid & Full ADS-B Capability - Research

9.24

ADS-B In/Out for military

TS-0105 0701

A/C-48 AC-49 CTE S2B/C

9.27

Multi-constellation GNSS Airborne Navigation Systems

AUO-0604

CTE-N1A

9.28

Enhanced Vision(Head Down and Head Up) Solutions

AUO-0403

CTE-N9A

9.29

Enhanced & Synthetic Vision

AUO-0404

CTE-N9B

9.30

Weather Hazards / Wake Vortex Sensor

AO-0304

CTE-S8A

9.31

Aeronautical Databases

TBC

9.33

ATS Datalink Operational Improvements

TBC

AUO-0302 TS-0103

CM-

IS-0402 IS-0707

List of WP9 projects starting in the period 2009-2010

Title

Domain ASAS - SSEP

A/C-17 ; A/C-29 A/C-50

Continuous Climbing Cruise Terminal & Approach Long Term CDA & Steeper Approach Operations airborne architecture

A/C-09

9.38 9.39 9.40

Related SESAR Enablers ID

ASAS

Flexible Communication Avionics

9.44

AOM-0702 A/C-07 CTE-C1

Technology Enablers 9.47

TCAS Evolution

CTE-S11a CTE-S11b

9.48

(Transverse/Independ AIS/MET Services and Data Distribution ent) Data Link Services

A/C-46

Table 1 - List of WP9 projects starting beyond 2009-2010 Methodology

SJU DoW WP09 V4.0.doc

Page 14 of 143

A formal engineering process is applied to structure and organise the Level 2 (project) activities and deliverables, as shown in Figure 1. This process, mature and well developed within the air framer industry, mitigates the risks associated with the high complexity (and cost) of aircraft integration activities, by providing an incremental design approach, within a structure of rigorous monitoring and feedback. The project process can be described in a generic way as follows. A first loop analyses the operational impact of the service level in the cockpit, building models and running validation simulations. The following loop drafts the functional requirements, models the studied functions and runs simulations in an aircraft simulator, possibly coupled with an ATM simulator The next loop defines the airborne system demonstrator, then develops and validates it in an Aircraft Demonstrator coupled or not with other demonstrators (Aircraft or ATM). Note: The final loop (not within the direct scope of WP9) would consist in fitting the System Demonstrator in a Flight Test Aircraft, for validation at aircraft level and possibly at System of System level. The above activities provide key inputs to the Operational WPs that are responsible for the definition and refinement of Service Description (OSED), Safety Performance Requirements, Interoperability Standards and Total ATM System & CNS required performance.

Operational Definition (WP 4-8) Interoperability Standards Definition (including Service Description)

Safety Performance Requirements (including Service Description)

Total ATM System and CNS required performance Definition

Support to Rulemaking and Standardisation (ad-hoc AMC/EUROCAE, etc.)

Onboard Operational Definition and Validation Operational Analysis (impact on a/c)

Airborne Function Stand alone Simulation Airborne Function Simulation in ATM environment

Raw Modelling of Function (e.g. HMI)

Functional Definition and Validation Functional Requiremen t Definition

Modelling of Function

Simulation of Function in Aircraft Simulator (a/c â&#x20AC;&#x201C; 1)

Simulation of Function in Aircraft Simulator coupled with ATM simulator

Airborne Sub-System Demonstrator Definition and Validation Definition of Airborne SubSystem Demonstrator

Development of Airborne Sub-System Demonstrator

Validation of Airborne SubSystem Demonstrator in Aircraft Demonstrator in realistic ATM env. (a/c 0) Test of Airborne Sub-System Demonstrator in Flying Platform

A/C System Definition

A/C System Validation

WP9 Scope

Validation of SubSystem Demonstrator with coupled demonstrators/ (Air-Grnd and Air-Air validation) System of Systems Integration and Validation

Contribution to Overall Operational Validation

Figure 1 Generic Approach for WP9 Level 2 activities

SJU DoW WP09 V4.0.doc

Page 15 of 143

In above diagram we note that two principal activities are within the scope of WP9, namely Aircraft System Definition and Aircraft System Validation. Operational aspects of the overall process are performed in the other SJU Operational WPs (WPs 4-7). A generic description of these activities is described below. A more detailed description is provided in Annex A. Aircraft Sub-System Definition The objectives of this activity are to define initial airborne operational requirements (such as HMI specifications, retrofit specifications and requirements for the co-existence between civil and military avionics), functional requirements and possibly a sub-system demonstrator, before all these are validated (in other WPs). Three areas of activity are defined: Onboard Operational Definition The objective of this task is to analyse the ATM operations within the aircraft cockpit in order to derive airborne operational requirements (such as HMI, Human factor performance, airborne operational performanceâ&#x20AC;Ś). Inputs of this activity are initial draft versions of Interoperability standards, Safety Performance Requirements and Total ATM system & CNS required performance. Operational Analysis (impact on a/c): o Inputs: initial draft and refined versions of Operational Service description with Interoperability, Safety & Performance Requirements and Total ATM system & CNS required performance o Output: Technical note Functional Definition Functional Requirements Definition: o Inputs: Operational Technical note o Output: Functional Technical Note (experimental) Airborne Sub-System Demonstrator Definition Definition of Airborne Sub-System Demonstrator: o Inputs: Functional Technical note (experimental) o Output: Airborne Sub-system demonstrator description note The deliverable of the Aircraft Sub-System Definition activities are airborne sub-system demonstrator description note. This document will contain interface information required to ensure System of Systems consistency.

Aircraft Sub-System and Operational Validation The objective of this activity is to validate initial operational specifications (such as HMI hypothesis and description), functional technical note and finally a sub-system demonstrator, at the aircraft level (civil and military) and in simulated ATM environment. The full validation of the subsystem/function at "system of systems" level is addressed in Contribution to Overall Operational Validation. Three areas of activity are defined. Onboard Operational Validation

SJU DoW WP09 V4.0.doc

Page 16 of 143

The main inputs of this activity are the initial operational technical note (such as HMI hypothesis and description) defined in Aircraft Sub-System Definition. The following activities are carried out to contribute at the end to the refinement of the initial performance requirements. The tools that are used to carry out this activity are mainly desktop simulators that can permit to simulate a sub-system (architecture, operational logics, performance behaviour, etc.) with the simulation of its environment (navigation, aircraft displays, etc.). They can be fast time or real time and do not require a realistic physical aircraft mock up. Functional Validation at aircraft level This activity mainly consists of setting up and running real time simulations, using aircraft simulators that are based on real HMI and fully simulated software and environment. This activity can be broken down into the following tasks Functional Validation in "raw" ATM Environment Validation of function through Simulation of Function in (Aircraft) Simulator (a/c - 1) coupled with ATM simulator(s) Airborne Sub-System Demonstrator Validation The deliverables of the Aircraft Sub-System and Operational Validation are • Functional Validation Plan/s • Simulation Report/s • Validation Plan/s for Sub-System Demonstrator Validation • Validation Report/s for Sub-System Demonstrator Validation Note: Contribution to Overall Operational Validation This activity, essential, to the overall aircraft WP process, is performed in the operational WPs. A short overview of activities is included below for completeness. The principal areas of activity are • Operational Validation of Airborne Sub-System Demonstrator in ATM Environment • Contribution to System of Systems Validation With the deliverables being • Airborne Sub-System Demonstrator Validation Plan (Validation in ATM Environment) • Airborne Sub-System Demonstrator Validation Report (Validation in ATM Environment) • Flight Test Operational Plan • Operational Flight Test Report Summary of Deliverables for WP9 WP9 will produce the following deliverables Activity Aircraft Sub-System Definition • Deliverable: Elementary Technical notes Activity Aircraft Sub-System and Operational Validation • Deliverable: Functional Validation Plan/s

SJU DoW WP09 V4.0.doc

Page 17 of 143

• • •

Deliverable: Simulation Report/s Deliverable: Validation Plan/s for Sub-System Demonstrator Validation Deliverable: Validation Report/s for Sub-System Demonstrator Validation

Note: In addition active participation of WP9 partners will be needed in the Operational WPs4-7 in order to contribute to the following deliverables • Airborne Sub-System Demonstrator Validation Plan (Validation in ATM Environment) • Airborne Sub-System Demonstrator Validation Report (Validation in ATM Environment) • Flight Test Operational Plan • Operational Flight Test Report Dependencies & Work Flow High-level dependencies are provided in section 4 (cf. Description of Work section ‘Context of WP9 with other SJU WPs’). Risks Overall Risks Limited overall technical coherency and consistency with other WPs Inefficient working structures hinders development WP9 Risks Late or limited input of operational requirements

Likelihood High

Impact High. Inappropriate and/or unsynchronised deliverables High.

Mitigation Strong overall consistency provided by WP2. Close coordination between all level 1 WPs. S-JU to propose strong formal working structures and processes.

Likelihood High

Impact High. Development of solutions is hindered

Not all platforms segments adequately covered

High

Global interoperability not achieved

High

High: no buy in for some solutions by some platforms, credibility of SESAR Master Plan. High: no buy in from users.

WP9 Mitigation WP9 partners need to be implicated in the operational WPs to get early understanding of requirements. Identification within the WPSC of key partners to represent the various airborne platforms.

SJU DoW WP09 V4.0.doc

Medium

External coordination activity managed at the level of overall WP9 management to oversee global interoperability.

Page 18 of 143

SJU DoW WP09 V4.0.doc

Page 19 of 143

Sub-Work Packages and Projects overview Sub Work package n°

Sub Work Package title

Project n°

Project title

9.0

Global Co-ordination and Management

9.1

Airborne Initial 4D Trajectory Management

Project

9.2

Project

9.5

Airborne Full 4D Trajectory Management & 4D contract capability Interoperability of Business Trajectory and Mission Trajectory ASAS-ASPA

Project

9.6

ASAS ASEP

Project

9.9

RNP Transition to xLS (x = G, I, M)

Project

9.10

Approach with Vertical Guidance APV

Project

9.11

Aircraft Systems for Wake Encounter Alleviation

Project

9.12

GBAS Cat II/III

Project

9.13

Airport Surface Taxi Clearances

Project

9.14

Airport Surface Alerts (ownship and traffic)

Project

9.16

New Communication Technology at Airport

Project

9.19

SWIM Air-Ground Capability

Project

9.20

Military Data Link Accommodation

Project

9.21

ADS-B - 1090 Higher Performance Study

Project

9.22

Mid & Full ADS-B Capability - Research

Project

9.24

ADS-B In/Out for military aircraft

Project

9.27

Multi-constellation GNSS Airborne Navigation Systems

Project

9.28

Enhanced Vision (Head Down and Head Up) Solutions

Project

9.29

Enhanced & Synthetic Vision

Project

9.3

Type of activity (MGT/Project2)

Project MGT

MGT

Project

For operational activities, i.e. Projects, or SWP with R&D activities (“Project” SWPs have no Project attached) SWPs dedicated to management activities (Management SWPs have at least 2 Projects attached)

SJU DoW WP09 V4.0.doc

Page 20 of 143

9.30

Weather Hazards / Wake Vortex Sensor

Project

9.31

Aeronautical databases

Project

9.33

ATS Datalink Operational Improvements

Project

9.38

ASAS â&#x20AC;&#x201C; SSEP

Project

9.39

Continuous Climbing Cruise

Project

9.40

Project

9.44

Long-term CDA & Steeper Approach Airborne Architecture Flexible Communication Avionics

9.47

TCAS Evolution

Project

9.48

AIS/MET Services & Data Distribution

Project

SJU DoW WP09 V4.0.doc

Project

Page 21 of 143

Level 2 & 3 â&#x20AC;&#x201C; Work-Package Description

SJU DoW WP09 V4.0.doc

Page 22 of 143

SWP 9.0

Global Co-ordination and Management

SWP 9.0

Title: Global Co-ordination and Management

Necessary expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Significant experience in large Programme Management. • Multi cultural management experience. • Comprehensive understanding of SESAR Programme and of the ATM Network. Concept & Objectives The Sub-WP 9.0 “Global Co–ordination & Management”, carried out by the WP Leader, aims at carrying out the management activities at WP level. It monitors and controls the progress of the WP, Sub-WPs and Project activities for ensuring the achievement of the WP objectives and for delivering on time, with the required quality and making the best possible use of available resources by defining and applying relevant project management practices. It organises the review process leading to the acceptance in the view of delivering the Deliverable to the SJU. It coordinates the work of the different partners involved in the Work Package. It reports progress, risks and issues to the SJU and to the Programme Committee, and proposes mitigation actions as necessary. It ensures application of common SESAR methodologies and tools across the WP and provides assistance to that aim to the lower levels. It ensures the interface with WP B, WP C to propose update to the concept of operation or architecture and to the Master Plan and the work program. It also ensures interfaces with any other appropriate Work Packages to ensure consistency across WPs.

SJU DoW WP09 V4.0.doc

Page 23 of 143

Description of Work Management structure The management of the WP is organised according to the general principles described in the following figure: SJU Administrative Board

Programme Committee

…

WPY Leader

WPZ Leader

Sub-WP Manager Z.0

Project Manager Z1.1

…

Sub-WP Manager Z.n

Project Manager Z.1.n

…

Project Manager Z.n.1

Project Manager Z.n.n

Project Collaborator 1

…

Project Collaborator n

SubContractor 1

…

Project Level

Sub-Work Package Management

Sub-WP Level

…

Sub-WP Manager Z.1

Work Package Management

WP Level

WPX Leader

PLANNING, RISKS, BUDGET, GATE DEFINITION AND MAINTENANCE

Executive Director Industrial Support

Programme Level

Programme Management

Project Management

SubContractor n

Project Lifecycle Each project follows a lifecycle as described below: INITIATION PROCESS

Kick-off

Initiation

Impact Assessment

Go / No-go Go

SJU

Project Manager and Members

Work Package Leader

Initiation Report*

Impact assessment form

No-go

SJU

Execution

Project Manager and Members

Gate

Acceptance

Termination

SJU

* Revised Deliverables, Tasks, Planning, Risks, Budget and Contributions

SJU DoW WP09 V4.0.doc

Page 24 of 143

SJU engineering methodologies SJU engineering methodologies are the procedures, processes and tools that will be uniformly applied to ensure an overall consistency and coherence throughout the SESAR work programme (i.e. System of Systems (SoS) level). Each WP is to comply with the SJU engineering methodologies (SoS engineering methodologies defined by SJU) which include the SoS Technical Coherence and SoS Coherence. This compliance will support the SJU in its endeavors to achieve the overall performance benefits of the programme and to avoid divergence and fragmentation. The SJU will ensure consistency of the activities within and between the Operational Work Packages (WP), the SWIM WP, and the System WP, and consolidate their results throughout the development lifecycle. The SJU will define the Enterprise Architecture (EA) Framework, maintain ownership and provide access to the SoS data repository related to EA; this repository will be available to all WPs, as a unique reference. To ensure the SoS Technical Coherence of the works performed at the relevant Operational, SWIM and/or System WP levels (1, 2 or 3), SoS engineering methodologies for the entire programme will be provided and maintained by the SJU. This involves the continuous involvement of all WPs, especially through appropriate working groups, to ensure Top/Down (from Definition phase outputs), bottom/up (from Project at level 3) and transverse (covering inter and intra WPs, when relevant) coherence activities. To support this activity the SJU will implement SoS Coherence, with the contribution of WPs: - SoS definition: o develop the SoS specification and architecture requirements including, for example: the definition of interfaces and consolidation of the logical data model based on WP results; and, requirements consolidation, management, allocation and traceability. - SoS IV&V: o develop the SoS IV&V requirements including the test bed requirements; o coordinate the SoS IV&V activities. In implementing the methodologies, WPs are to ensure their representation at the required level of expertise in Working Groups as defined by the SJU. The Work Package Leader, within the Sub-WP 9.0, applies the SJU engineering methodologies and reports to SJU accordingly. Roles and responsibilities Work Package Leaders Each Work Package Leader shall: â&#x20AC;˘ Be accountable to the SJU for comprehensive oversight of its Work Package and for the senior management of the operational relationship between the Members involved at Work Package level, â&#x20AC;˘ Refine the SJU guidelines as appropriate for its Work Package in order to enable the implementation of the common SJU engineering methodologies and quality system at Project level, â&#x20AC;˘ Design the work plan for the duly and timely implementation of its Work Package, following the guidelines provided by the SJU, e.g.: o refine the methodology and processes (e.g. appropriate reporting, meetings,

SJU DoW WP09 V4.0.doc

Page 25 of 143

etc.), refine the schedule, milestone plan and detailed planning to achieve the delivery of its Work Package in accordance with the Programme schedule, Coordinate the activities, and monitor the work progress within its Work Package, in particular by providing the Impact Assessment within the framework of the Initiation process, Ensure the duly and timely communication of information, in particular: o within its Work Package, by setting regular meetings with all the Sub-Work Package Managers and/or Project Managers, o to the SJU, by periodically providing it with reports or answering requests from it, in particular on: progress (status of completion planning, Deliverables, Gates, resource consumption) including information on progress against the agreed description of the Work Package contained in the applicable Technical Schedule, Risks and Issues, in particular those requiring remedies, with the appropriate assessment form. Track Risks and Issues: o by identifying Risks and Issues that arise at Work Package level and assessing their impacts and criticality on the Work Package and/or the overall Programme, o by reviewing the impact assessment established by the Project Managers for Risks and Issues arising at Project level. Act as a referee at Work Package level, looking to the extent possible for a consensus, in particular in order to: o anticipate negative impacts of Issues and disputes internal to the Work Package, o ensure a timely resolution of disagreements in the first instance, within the Work Package, o when necessary, escalate the disagreements in accordance with MFA Schedule 3 (Escalation Process), Answer Audit requests and collaborate with Auditors, Ensure relationship with transversal Work Packages: o Relation with WP B: The Work Package Leader, within the Sub-WP 9.0, coordinates with WPB for any aspect in relation to Concept of Operations and Architecture and any evolutions proposed by the WP, o Relation with WP C: The Work Package Leader, within the Sub-WP 9.0, Submits to WP C (C.1) output/deliverables affecting the Master Plan contents (e.g. OIs, OI steps, Enablers description and/or timing, risk register etc.) in accordance with the process and procedures described in the Master Planning Handbook. Submits standardisation/regulatory needs to WP C (C.3). Co-ordinates CBA/Business Case development with WPC (C.6) prior to its start and communicates the results for consolidation into the overall Business Case. Ensures availability of the required expertise at the achievement of the E-OCVM V3 phase of a project for timely specification of Implementation Objectives with WP C (C.2), o Relation with WP 3: The Work Package Leader, within the Sub-WP 9.0, coordinates with WP 3 for any matters related to validation infrastructure. In particular, it will inform WP 3 for any validation platform needs. For E-OCVM phases V1 and V2, the WP could use its own tools, while for V3, it would preferably use tools developed under the co-ordination of WP 3, o Relation with WP 16: The Work Package Leader, within the Sub-WP 9.0, will o

•

• •

SJU DoW WP09 V4.0.doc

Page 26 of 143

coordinate with WP 16 for any matters related to safety, security, environment, contingency and human related aspects. In particular, it will foster the implementation of the guidelines, method and processes established by WP 16 throughout the WP activities. Sub-Work Package Managers Each Sub-Work Package Manager shall: • Ensure the overall consistency of the work plan of the Projects within its scope of supervision, • Contribute to the overall consistency of the Programme in accordance with the provided SJU engineering methodologies and established cross-WP technical coordination. • Follow up, collect and manage the information reported by the Project Managers and periodically report to the Work Package Leader, following guidelines provided by the latter, in particular on: o Progress (status of completion planning, Deliverables, Gates, resources consumption), o Risks and Issues, • Report to the SJU, upon any request, • Act as an intermediary at Sub-Work Package level in accordance with Schedule 3 (“Escalation process”), looking to the extent possible for a consensus, in particular in order to: o anticipate negative impacts of disagreements internal to the Sub-Work Package by solving them timely, o consider and resolve disagreements in the first instance, within the Sub-Work Package, o escalate disagreements in accordance with MFA Schedule 3 (Escalation Process) in case it cannot be or has not been remedied at Sub-Work Package level, • Answer Audit requests and collaborate with Auditors. Project Managers Each Project Manager shall: • Be accountable to the Work Package Leader for comprehensive oversight of the Project they have been entrusted with and for the senior management of the operational relationship between the Members involved at Project level, • Implement the SJU engineering methodologies within their Project, • Structure the Project to allow its duly and timely refinement and implementation by designing the work plan, following the guidelines provided by the Work Package Leader, including: o refining the methodology and processes (e.g. appropriate reporting, meetings, etc.), o coordinating the Initiation of its Project and submitting the Initiation Report to the SJU in accordance with MFA Article 9 “Initiation of a Project”, o developing a Project management plan conforming to the overall Programme plan, with a copy submitted to the SJU Executive Director • Lead and coordinate the activities within the Project, and monitor the work progress within the Project as defined during the Initiation phase, • Ensure the duly and timely communication of information, in particular: o within the Project, by setting regular meetings with all the Project Members, o to the upper levels, by periodically providing reports to the Sub-Work Package Manager, in particular on: progress (status of completion planning, Deliverables, Gates, resources consumption) including information on progress against the agreed

SJU DoW WP09 V4.0.doc

Page 27 of 143

•

• •

description of the Project contained in the applicable Technical Schedule, with particular emphasis on resources consumption; Risks and Issues, in particular those requiring remedies, with the appropriate assessment form. o to the SJU, by providing the periodic reports provided to the Sub-Work Package Manager, o to the SJU, by establishing and providing the Interim and Final Reports on Deliverables and Project, Track Risks and Issues, by identifying and assessing their impacts and criticality on the Project and/or on other Projects (within the same Work Package or within another Work Package), Secure a consensus and when necessary make decisions in order to: o anticipate negative impacts of Issues and disagreements internal to the Project by solving them timely, o consider and resolve issues and disagreements in the first instance, within the Project, o escalate the Issue or disagreements in accordance with MFA Schedule 3 (Escalation Process) in case it cannot be or has not been remedied at Project level, Answer Audit requests and collaborate with Auditors, Be involved in cross-WP working groups and reports.

Risks The procedures and rules guiding risks identification, management and mitigation will be gathered in the WP Risk Management Plan. The objective of risk management is to reduce the risks related to all WP Sub-WPs to an acceptable level, by transferring the risks, avoiding the risks, reducing the negative effect of the risks or accepting some consequences of a particular risk if no other possibilities. In all Sub-WPs the performance of the work is subject to some risks due to the complexity of the target project. The activities undertaken by Risk Management are: • Risk Identification; • Risk Assessment and Monitoring; • Mitigation measures (avoidance, reduction, retention, transfer); • Solution Implementation; • Review and evaluation.

SJU DoW WP09 V4.0.doc

Page 28 of 143

SWP 9.1

Airborne Initial 4D Trajectory Management

SWP 9.1

Title: Airborne Initial 4D Trajectory Management

SJU DoW WP09 V4.0.doc

Page 29 of 143

Description of Work PHASE 1 WA1 – Definition This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP5 & WP4 counterpart project: mainly operational assumptions and safety analysis results. The partners involved in this work package will actively participate in aircraft standardization groups so as to ensure high synchronization between the validation activities of the project and standardization activities. Particularly, coordination will be ensured with the RTCA SC-214/Eurocae WG-78. The technical definition activities will consist in : • Analyse functional A/C requirement definition containing HMI requirements • Analyse feasibility and potential technical solutions for A/C requirements • Analyse technical definition of high level A/C architecture and A/C system behaviour • Support Standardisation activities on 4D TRAD OSED, SPR, interoperation as well as Navigation standardisation Inputs: • Research finding on Initial 4D • Operational concept and scenarios for initial 4D and ATC Operational requirements applicable to A/C provided by WP 4 (4.5, 4.7) and WP5 (5.6 - Queue Management) • provided by WP 4 & 5 • Ground System (AMAN) requirements applicable to A/C provided by WP10 Short description of contribution: • • • • • • • • • • • • • • • • • •

Operational, functional and technical analysis (Leader) Operational, functional and technical analysis (for regional aircraft) Support to technical analysis for mainline and regional A/Cs common aspects Support standardization activities at aircraft level Operational and functional system definition for Business Aircraft Feasibility Feasibility on mainline aircraft Interface documents and standardisation Support to operational and functional system definition Support to technical analysis for mainline aircraft Support to feasibility assessment on mainline Support to Technical analysis for Regional aircraft Support to Feasibility assessment on Regional, and Monitor/Participate standardization of interfaces (e.g. FM & CMU) and/or between functions (e.g. applications and routers) Support standardization activities Support to the recommendations on the aircraft operational feasibility, especially for non-mainline aircraft. Analyse potential technical solutions for non-mainline aircraft in the scope of the objective “capable to be retrofitted to the whole commercial fleet with limited cost”. Analyse technical solutions which are feasible in a near-term operational context. Support the standardisation activities and in particular the Eurocae WG-78/SC-215 group. Validation of the proposed standards to ensure completeness and consistency

SJU DoW WP09 V4.0.doc

Page 30 of 143

WA2 – System Validation WA2.1 – Mainline aircraft 2.1.1 – Prototype Development This work area will consist in : • Development of fast time simulation tools to model behaviour of Initial 4D equipped A/C • Development of a FMS model with Initial 4D to be integrated in Mainline aircraft Research Simulator • Development of prototypes of FMS to support Initial 4D validation on Mainline aircraft integration simulator and flight test • Development of prototypes of ATSU to support Initial 4D validation on Mainline aircraft integration simulator and flight test Input: • Definition assumptions Short description of contribution: • • • • • • • •

Specification definition, verification and initial validation, Model development, System development A/C FMS simulation models A/C FMS prototype Support specification definition Development of FMS model with Initial 4D capability to be integrated in Mainline aircraft Research Simulator Internal pre-validation of FMS model on avionic simulators facility before delivery Development of FMS prototype to support Initial 4D validation on Mainline aircraft integration simulator and flight test Initial validation of FMS prototype before delivery

2.1.2 – Simulator Integration This work area will consist in : • Integration of prototype (developed in T2.1.1) in Mainline aircraft Research simulator • Coupling of Mainline aircraft Research simulator with an ATC System Demonstrator, and AMAN • Integration of FMS and ATSU prototypes in an Mainline aircraft integration simulator and Flight test A/C • Coupling of Mainline aircraft integration simulator with external ANSP facility for interoperation purpose Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP4 & WP5 operational scenarios

Short description of contribution: • • • • • •

Integration of prototype (developed in T2.1.1) in a research simulator Integration of FMS and ATSU prototypes in Integration simulator and Flight test A/C Participation to coupling activities Support to generic integration of FMS prototype in Integration simulator Participation in FMS model integration in Mainline aircraft Research simulator Participation in coupling of Mainline aircraft Research simulator with an ATC System

SJU DoW WP09 V4.0.doc

Page 31 of 143

• •

Demonstrator Support to generic integration of FMS prototype in Integration simulator Support to detailed integration of FMS prototype in Integration simulator and Flight test A/C

2.1.3 – Technical Validation We will derive from global validation plan of Initial 4D, the validation objectives on the A/C. Validation scenarios will be refined from Initial 4D operational concept and scenario document. Technical validation will be conducted within WP9. This validation will include mainline research simulator coupled with ATC system demonstrator + AMAN, mainline integration simulator coupled with an external ANSP facility for interop. purpose, and initial flight tests. Short description of contribution: • • • • • • • • • • •

Simulations using an aircraft Research Simulator Simulations using an aircraft Integration Simulator coupled with external ANSP facility Flight tests using Flight test aircraft Support to generic validation of FMS prototype in Integration simulator Support to validation scenario definition Support to simulations using an aircraft Research Simulator Support to simulations using an aircraft Integration Simulator Support to detailed validation of FMS prototype in Integration simulator Support to flight trials (using Flight test aircraft) in flight and post flight assessment Support to validation (scenario definition, results analysis) Support to validation in preparation for the pre-operational validation (scenario definition, results analysis)

WA2.2 – Regional Aircraft 2.2.1– Prototype/model Development • This activity will consist in: Development of fast time simulation tools to model behaviour of Initial 4D equipped A/C • Development of prototypes of FMS to support Initial 4D validation on Regional aircraft system integration bench • Development FMS model to support Initial 4D validation on Regional aircraft Research simulator • Development of prototypes of CMU to support Initial 4D validation on Regional aircraft system integration bench • Development of CMU model to support Initial 4D validation on Regional aircraft Research simulator Input: • Definition assumptions: operational , functional and high level architecture definition for regional / turbo prop aircraft from WA1 Short description of contribution:

•

FMS Prototype, data link function, Vertical flight path & Meteo model optimization for regional A/C Tools to monitor and/or simulate components and counter-parts of the Initial 4D chain

• • •

Fast time simulation activity A/C sub-system requirements definition Support to models development

•

SJU DoW WP09 V4.0.doc

Page 32 of 143

•

Support to prototypes development

2.2.2 – Simulator/bench Integration This work area will consist in integration of prototypes (developed in WA2.3.1) in Regional aircraft system Integration Bench and then in the Regional aircraft Research simulator. For these purposes the following activities will be performed: Adaptation of system integration bench to simulate corresponding Regional aircraft environment, including functional and system integration of datalink services. • Adaptation of Regional aircraft Research simulator to simulate corresponding Regional aircraft environment, including functional and system integration of datalink services. • Integration of prototypes (developed in T2.3.1) in Regional aircraft system integration bench for testing at equipment and avionic level. • Integration of models (developed in T2.3.1) in Regional aircraft Research simulator for testing at A/C level. • Coupling of Regional aircraft Research simulator with an ATC System Demonstrator, and AMAN Coupling of Regional aircraft integration simulator with external ANSP facility for interoperation purpose •

Input: • Definition assumptions • Prototypes readiness notes from WA2.3.1 • WP5 operational scenarios Short description of contribution: • •

• • • •

Integration of prototypes in Regional Integration Bench Integration and Testing at system level for datalink services (sub-systems, End-to-end validation, interoperability & performances testing for datalink services with ground counter-part Adaptation of bench environment Support to models integration in Regional aircraft Research simulator Adaptation of simulation environment Integration of models in Regional aircraft Research simulator

2.2.3 – Technical Validation This work area will consist in : • Validation plan and scenarios definition • Technical validation of Initial 4D on Regional aircraft system integration bench • Technical validation of Initial 4D on Regional aircraft Research simulator Input: • Regional aircraft simulator readiness from WA2.3.2 • WP4 & WP5 operational scenarios Short description of contribution: • • • •

Support to testing activity on Regional aircraft Research simulator Testing activity on Regional aircraft integration bench testing activity on Regional aircraft Research simulator Support to testing activity on Regional aircraft integration bench

SJU DoW WP09 V4.0.doc

Page 33 of 143

PHASE 2: • Complementary flight tests (transfer to Ops WP to be confirmed) • Interoperability and operational tests using Integration simulator coupled to ATC systems • Contribution (models, onboard operational constraints) to fast time simulations supporting local deployment Related OI Steps and System Enablers OI: • • • • • •

CM-0601 Precision Trajectory Clearances (PTC)-2D Based On Pre-defined 2D Routes CM-0602 Precision Trajectory Clearances (PTC)-3D Based On Pre-defined 3D Routes CM-0603 Precision Trajectory Clearances (PTC)-2D On User Preferred Trajectories IS-0302 Use of Aircraft Derived Data (ADD) to Enhance ATM Ground System Performance IS-0303 Use of Predicted Trajectory (PT) to Enhance ATM Ground System Performance TS-0103 Controlled Time of Arrival (CTA) through use of datalink

EN: •

A/C 11 Flight management and guidance to improve time constraints management (CTA) • (TBC) • A/C-33 Uplink and automatic loading in onboard navigation system of clearances • A/C-36 Downlink of aircraft derived data (e.g. ETA, weight, speed, wind) • A/C-37 Downlink of predicted trajectory in case of activation onboard of agreed or revise trajectory or in case proposal of onboard preferred trajectory avoiding an up linked area • A/C-45Uplink of aeronautical or MET data for use by relevant onboard system of service (D-OTIS) Deliverables PHASE 1 WA1 • Technical note: Main functional and high level aircraft architecture definition (Mainline Aircraft Flight Deck Integrator) • Technical note: Interface document between A/C and ground tools (Mainline Aircraft Flight Deck Integrator, Civil Avionics Manufacturer) WA2.1 • Technical Validation Plan of Initial 4D for WP9 (Mainline Aircraft Flight Deck Integrator) • Technical Validation scenarios (Mainline Aircraft Flight Deck Integrator) • Technical Validation Report (Mainline Aircraft Flight Deck Integrator) • WA2.2 Technical Validation Plan • Technical Validation scenarios • Technical Validation Report

SJU DoW WP09 V4.0.doc

Page 34 of 143

Risks The main technical risks are: • To ensure consistency between ATC and ground solutions requirements with A/C system behaviour • To have a timely and coordinated progress with the WP outside WP9 Mitigation means: • Define and follow a consistent Validation plan • Ensure close coordination with Operational and ground system WP

SJU DoW WP09 V4.0.doc

Page 35 of 143

SWP 9.2 Airborne Full 4D Trajectory Management & 4D contract capability SWP 9.2

Title: Full 4D Trajectory Management & 4D contract capability

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • A/C solutions are designed with the objective to satisfy Airline and pilot interests, and with a good level of maturity (Civil Avionics Manufacturer, Mainline Aircraft Flight Deck Integrator) • System development expertise in particular for FMS (FMS specialised Avionics Manufacturer) and ATSU (ATSU specialised Avionics Manufacturer) • Ground system expertise on ATC and data-link solutions (ATC specialised system Manufacturer) Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives 4D trajectory management is an A/C function that enables to build, guide, predict and communicate an A/C 3D + time trajectory. Full 4D is the second step towards SESAR target concept, and Initial 4D is the first step. Full 4D is aimed to provide significant benefits, on flight efficiency and Air traffic Management, based on a very precise trajectory management on 3D + time down to runway threshold. It will require that the vertical component of the flight trajectory of the aircraft is maintained in a precise volume of airspace. Such containment improves ATM on the vertical axis, taking benefits from aircraft’s system performances. Full 4D is more long term, as IOC for Full 4D is planned for 2017. It should take benefit of Initial 4D findings in order to reach quickly a good level of maturity. Full 4D is foreseen to be using multi-RTA to have a better control on future trajectory uncertainties. The project will also progress on the technical definition and the system design of the 4D-Contract Airborne Capability. CDA aspects or any optimised vertical trajectory in high density, combined with closed loop time guidance or open loop time management are included in the scope of this work package. Benefits: • Increase ATM capacity and flexibility • Reduce Airline costs linked to ATM delays, thanks to better predictability and flexibility of ATM • Increase of trajectory management flexibility for General & Business Aviation platforms • Reduce fuel used, noise and emission thanks to better ATM operation efficiency • Safety improvements through, reduction of Pilot workload, and enhanced conflict detection by ATC. The objective of the project is ensure that the airborne part of the technical definition and the system design of the Full 4D function and function supporting 4D contracts, is at the level of maturity relevant to launch a cost effective and robust A/C system development, and to define,

SJU DoW WP09 V4.0.doc

Page 36 of 143

design and to validate the architecture of Flight Management, Navigation and Flight Path Steering systems and related crew interface to ensure improved vertical navigation that meets the 4D concept and resulting operational requirements during Departure, Descent & Approach flight phases. Description of Work PHASE 1 WA1 – Definition This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate result of the WP4 & WP5 counterpart projects: mainly operational assumptions and safety analysis results. The partners involved in this work package will actively participate in standardization groups so as to ensure high synchronization between the validation activities of the project and standardization activities. The technical definition activities will consist in : • Analyse functional A/C requirement definition containing HMI requirements • Analyse feasibility and potential technical solutions for A/C requirements • Analyse technical definition of high level A/C architecture and A/C system behaviour • Support Standardization activities on OSED, SPR, interoperation as well as Navigation standardisation • Analyse use of vertical references and other flight control considerations - Trade-off and provide rationale for selection of a vertical reference with associated algorithms and crew interface (in particular regarding the monitoring of vertical containment). Inputs: • Synthesis of Initial 4D validation results • Research findings on Full 4D & 4D contracts • Operational concept and scenarios for Full 4D & 4D contracts and ATC Operational requirements applicable to A/C provided by WP 4 (4.5, 4.7), WP5 (5.6 - Queue Management) • Ground System and services requirements applicable to A/C provided by Operational WPs through SPR • Datalink System requirements applicable to A/C provided by WP15 (Data Link System requirements - 15.2.4) Short description of contribution: • Operational, functional and technical analysis (Leader) • Support to technical analysis for mainline and regional A/Cs common aspects. • Operational, functional and technical analysis (for Regional A/C at aircraft level) • Support to standardization activities • Operational feasibility for Business Aircraft • Business Aircraft high level architecture • Operational feasibility for mainline Standardisation activities • Support operational and functional system definition • Define operation concept on Mutilple CTOs/RTA • Suvey on existing tools and means on meteo data • Bandwith analysis for MTO update by data-link • Support technical analysis for mainline aircraft • Contribution to feasibility assessment on mainline • Contribution to the analysis of the operational requirements and to the functional system SJU DoW WP09 V4.0.doc

Page 37 of 143

• • • •

definition (common to all applications part) Definition and feasibility analysis for regional A/C Support standardization activities Support the data link and navigation standardisation activities. Support operational, functional and technical analysis.

WA2 – System Validation WA2.1 – Mainline Aircraft 2.1.1 - Mock-up Development This work area will consist in : • Development of fast time simulation tools to model behaviour of Full 4D equipped A/C • Development of a FMS model with Full 4D to be integrated in Mainline aircraft Research Simulator Input: • Definition assumptions Short description of contribution: • Specification definition, verification and initial validation, model development • Contribution to specification definition • Development of simulated FMS with Full 4D capability • Initial validation of FMS model on Avionics Manufacturer simulator facility 2.1.2 – Simulator Integration This work area will consist in : • Integration of models (developed in T2.1.1) in Mainline aircraft Research simulator • Coupling of Mainline aircraft Research simulator with ATC System Demonstrator, and AMAN Input: • Definition assumptions • Technical Validation Plan • WP4 & WP5 operational concept & scenario Short description of contribution: • Integration of prototype (developed in T2.1.1) in Research simulator • Participation to coupling activities • Support to integration of FMS model in Research simulator • Support to integration into ATC System Simulator with AMAN functionality (ensure consistency of interface & utility for ATC Simulators). 2.1.3 – Technical Validation We will derive from global validation plan of Full 4D, the validation objectives on the A/C. Validation scenarios will be refined from Full 4D operational concept and scenario document. Technical validation will be conducted within WP9 Short description of contribution: • Tests using an aircraft Research simulator • Support to model validation • Support to definition of validation scenarios and report

SJU DoW WP09 V4.0.doc

Page 38 of 143

PHASE 2 • Prototype(s) development (needs should be assessed for each category of aircraft) • Simulations using Aircraft Integration Simulator(s) • Additional Simulations using Aircraft Research Simulator • Flight tests (transfer to Ops WP to be confirmed) • Contribution (models, onboard operational constraints) to fast time simulations supporting local deployment Related OI Steps and System Enablers OI: • • • • • •

AOM-0701 Continuous Descent Approach (CDA) AOM-0702 Advanced Continuous Descent Approach (ACDA) AOM-0703 Continuous Climb Departure AOM-0704 Tailored Arrival AOM-0705 Advanced Continuous Climb Departure AUO-0302 Successive Authorisation of Reference Business / Mission Trajectory (RBT) Segments using Datalink • CM-0602 Precision Trajectory Clearances (PTC)-3D Based On Pre-defined 3D Routes • CM-0603 Precision Trajectory Clearances (PTC)-2D On User Preferred Trajectories • CM-0604 Precision Trajectory Clearances (PTC)-3D On User Preferred Trajectories (Dynamically applied 3D routes/profiles) • IS-0303 Use of Predicted Trajectory (PT) to Enhance ATM Ground System Performance • IS-0501 Use of Airborne Weather Data by Meteorological Service to Enhance Weather Forecast • TS-0106 Multiple Controlled times of Over-fly (CTOs) through use of data link

EN: • • • • • • • • •

A/C-12 Flight management and guidance to perform multiple time constraints management (CTOs) A/C-14 Monitoring of the conformance of the current PT versus RBT according to thresholds. A/C-31 Uplink and automatic loading in onboard navigation system of route, altitude and time constraints A/C-33 Uplink and automatic loading in onboard navigation system of clearances A/C-34 Uplink and automatic loading in onboard navigation system of 3D/4D Precision Trajectory Clearances A/C-37 Downlink of predicted trajectory in case of activation onboard of agreed or revise trajectory or in case proposal of onboard preferred trajectory avoiding an up linked area A/C-38 Automatic downlink of predicted trajectory on request or in case of delta versus RBT more than thresholds. A/C-46 Ground broadcast of aeronautical or MET data for use by relevant onboard system or service A/C-47 Downlink of meteo data from onboard sensor.

Deliverables

SJU DoW WP09 V4.0.doc

Page 39 of 143

PHASE 1 WA1 • • • •

WA2 • • •

Technical note: Main functional and high level aircraft architecture Technical note: Interface document between A/C and ground Technical note: Analyse operational requirement inputs and derive system level technical goals, which remain robust in defined operational environments. Allocate technical system goals to aircraft functions and specify functional and performance requirements as inputs to standardization activities Technical Validation Plan of Full 4D for WP9 Technical Validation scenarios Technical Validation Report

Risks The main technical risks are: • To ensure consistency between ATC and ground solutions requirements with A/C system behavior • To have a timely and coordinated progress with the WP outside WP9 Mitigation means: • Define and follow a consistent Validation plan • Ensure close coordination with Operational and ground system WP

SJU DoW WP09 V4.0.doc

Page 40 of 143

SWP 9.3 Interoperability of Business Trajectory and Mission Trajectory SWP 9.3

Title: Interoperability of Business Trajectory and Mission Trajectory

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following main domains: • Military avionic manufacturers (e.g. Flight/mission management system both for military transport and fighter/trainer aircraft, Mission planning system) • Military aircraft flight deck integrator (e.g. impacts on the current aircraft architectures and relevant cockpit systems) • Military operations on the civil airspace • Military users Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives In order to assure the coexistence and the interoperability between the civil transport and military aircraft in the new ATM environment that will be developed by SESAR, it is important to explore how the current military platforms may be conformed to the new operational concepts that will be adopted for managing the air traffic. It is essential to guarantee a compliance of the military aircraft that in normal operations flying the GAT aerospace requires the same performance level than civil aircraft. Assuring the interoperability between the civil and military aircraft will be an important added value allowing the achievement of the following benefits: •

• • • •

Capacity - Interoperability and coexistence of civil and military aircraft will allow to better exploit the airspace resource avoiding to restrict it for military use only (the most important benefit is for the civil airspace users). Safety - Interoperability between civil and military aircraft means the possibility to control and manage in a safely manner the OAT and GAT contemporary. Environment - The correct interoperability between military and civil aircraft will allow to better manage the GAT and as fallout will contribute in reducing the aircraft emission Cost - It is a fallout of the above benefits for the civil aircraft and in addition cost benefit specific for the military users (affordable retrofit). Standardise, as far as possible, the military/civil aircraft management in case of normal operations

Starting from the existing main military aircraft configuration (transport and fighter/trainer), and taking into account the needs of operational WPs requirements, wing ops centres systems and other ground systems support, objectives of the project are: • To assess the requirements capture relevant to full 4D capabilities • To verify the compatibility between military mission trajectory and business trajectory according to the current 4D onboard capabilities.

SJU DoW WP09 V4.0.doc

Page 41 of 143

•

To define and develop some dedicated new 4D required functions in order to guarantee an equivalent “full 4D capabilities” to the civil one with special attention to RTA function on the flight plan and up-down link of required aeronautical data taking into account the airborne legacy constraints.

The participation of the Military Users is expected. Description of Work PHASE 1 WA1 – Definition Starting from initial results from projects 9.1 and 9.2, this activity will consist in the definition of the operational and technical assumptions used for the project, using as an input intermediate results of the operational WPs: mainly operational assumptions and end-to-end safety analysis results. In this working area will be assessed the existing military aircraft capabilities understanding how they may comply with the new SES requirements taking into account the operational treads needs and the results achieved in project 9.1 and 9.2. in particular the assessment will be focused on the feasibility of reusing MMS systems / Mission Computer on board military aircraft to support FMS trajectory management functions. From these results will be selected few specific promised 4D trajectory function to be developed and validated that can really give and added value in terms of increment of compliant level that the military aircraft can achieve. The above 4D trajectory functions will be defined and specified in terms of high level functional requirements, human machine interface requirements and system requirements for the subsequent development. In particular, feasibility of reusing military aircraft Mission Computer/MMS systems to support FMS-alike trajectory management functions will be addressed.

The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. Inputs: • Initial results of Projects 9.1 and 9.2 • Operational concept and scenarios for Full 4D and ATC Operational requirements applicable to A/C provided by WP 4 (4.5), • Ground System and services requirements applicable to A/C provided by Operational WPs through SPR • Datalink System requirements applicable to A/C provided by WP15 (Future A/G Data Link System Definition - 15.2.4) • Future A/G Data Link System Definition - 15.2.4 Short description of contribution: • Operational, functional and technical analysis • Aircraft architecture, trade-off and initial safety analysis • HMI requirements definition

SJU DoW WP09 V4.0.doc

Page 42 of 143

• •

System requirements definition Ensure consistency between defence organisations

WA2 – System Validation WA2.1 key-4D functions Development For the military transport and fighter/trainer aircraft, this work area will consist in : • • •

Key-4D functions modelling for military transport and fighter/trainer aircraft to be integrated in the relevant flight simulators Virtual prototyping development and initial validation Key-4D functions development regarding military transport aircraft to be integrated in the relevant integration bench and in the subsequent phase on the aircraft

No fully development but only the most key-functions will be considered in this project. Input: • Technical note: operational feasibility for military transport and fighter/trainer aircraft. • Technical note: military transport and fighter/trainer aircraft architectures and key-4D functions requirements Short description of contribution: • Key-4D functions modelling and development • Key-4D functions validation meeting requirements WA2.2 – Simulator/bench Integration This work area will consist in: • Adaptation of military transport aircraft integration bench to host the developed key-4D trajectory management functions and relevant integrations • Adaptation of military transport and fighter/trainer aircraft flight simulators to host the key-4D trajectory management functions model and relevant integration • Coupling of flight simulator with ATC models/simulators Input: • • • •

Definition assumptions Technical Validation Plan Key-4D functions readiness operational scenario (WP 4 and WP 5 inputs)

Short description of contribution: • Integration of key-4D functions on test bench and integration test activities • Integration of key-4D functions models on flight simulators and test activities • Development and validation of operational scenarios WA2.3 – Technical Validation The technical validation will be made according to the operational validation objectives defined by the operational WPs and according to the identified validation infrastructure provided by WP 3. This work area will consist in : •

Validation plan and scenarios definition for OAT trajectory management functions

SJU DoW WP09 V4.0.doc

Page 43 of 143

•

Technical validation of OAT trajectory management on military transport aircraft system integration bench and on military transport and fighter/trainer aircraft flight simulators

It is assumed the possibility to perform operational validation integrating flight simulators with simulation of other components of SoS Validation Infrastructure in order to verify the interoperability requirements between civil and military platforms. Input: • Integration bench and flight simulators readiness from WA2.1 • WP4 & WP5 operational scenarios Short description of contribution: • Technical validation activities on military transport and fighter/trainer flight simulators and on the military transport integration bench • Assurance of compliance with OAT requirements PHASE 2 • upload of new key-4D functions on mission management system of military transport aircraft, • Ground test activities on military transport aircraft • Flight trials assessment and report Related OI Steps and System Enablers • • • • •

AOM-0304 OAT Trajectories AOM-0202 Enhanced Real-time Civil-Military Coordination of Airspace Utilisation AOM-0302 Harmonised OAT Flight Planning AAMS-11 Airspace management system enhanced with real-time functions and dialogues for dynamic airspace allocation AIMS-19 Aeronautical Information system is interfaced to receive and distribute aeronautical information electronically to military systems.

Deliverables PHASE 1 WA1 • • WA2 • • •

Technical note: operational feasibility for military transport and fighter/trainer aircraft. Technical note: military transport and fighter/trainer aircraft architectures and Key-4D function requirements Technical note - Technical Validation Plan Technical note - Technical Validation scenarios Technical note – Technical Validation Report

Risks • • •

Contemporary Datalink and ADS-B in&out coexistence Quality and level of integrity of ADS-B in&out information Required navigation performances and security.

SJU DoW WP09 V4.0.doc

Page 44 of 143

SWP 9.5

ASAS-ASPA

SWP 9.5

Title: ASAS-ASPA

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following main domains: • FMS avionics • Datalink avionics • Air Surveillance Prototyping • Display prototyping (Civil Avionics manufacturer) • Aircraft Architecture (Mainline, Regional and Business Aircraft Flight Deck Integrators). Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress with the technical definition and validation of ASPA S&M. ASPA S&M is expected to improve capacity and flight regularity in terminal areas by having the A/C fly their flight plan, maintaining a time spacing from a leader A/C. Having a regular flow of A/C should thus reduce fuel burns. ASPA S&M is a tool for controllers to help them handle with flows of A/C concentrated on a short period of time. It is robust to time variation since, if the leader A/C does not exactly comply with a time constraint, the following A/C automatically adapt their behaviour. A side effect should be the reduction of pilots’ and controllers’ workload in TMA (by suppressing the use of vectoring instructions). For ASPA S&M operations, even if voice communications can be used with ATC, CPDLC seems to be the best means to communicate with the trailer A/C : no risk of confusion between the leader A/C and the trailer A/C, reduction of the risk of misunderstanding (type of manoeuvre, trailer A/C, spacing value, merge waypoint –if any). Main technical aspects to explore are: • vertical profile compatible with time spacing constraint, including cohabitation with continuous descent approach concept; • maintaining time spacing whatever the lateral trajectory configuration (e.g.: turns, offsets,…) • alerts provided when the spacing is drifting then is missed • detection of the feasibility/unfeasibility of a spacing manoeuvre • function allocation over several supporting systems • study and validation of CPDLC messages to support ASPA S&M operations. Flight test trials will have to be conducted in order to validate the technical definition produced in a former step (Episode III). Very strong synergy is needed with the WP5 counterpart project aiming at operational definition and validation of ASPA S&M.

SJU DoW WP09 V4.0.doc

Page 45 of 143

Description of Work PHASE 1 WA1 – System Definition WA1.1 All Aircraft Types 1.1.1. Functional Definition This work will use as an input the results of the WP5 counterpart project: mainly operational assumptions and end-to-end safety analysis results. Input: • Operational requirements provided by WP5 (projects 5.6.6) • Technical results obtained from previous architecture studies and validation on simulators • For ATC datalink aspects, intermediate results of Cristal ITP activities and Project 4.7.4 early results will be used as inputs. Short description of contribution: • Functional requirements definition • Support to Functional requirements definition for aspects common to mainline and regional A/C • Operational, functional and technical analysis for regional A/C at aircraft level • Operational, functional and technical analysis for business A/C at aircraft level • Support to functional requirements definition • Analysis of ASAS/4D integration • Contribution to functional requirements definition (for both mainline and regional A/C) • Support standardization activities • Support to Functional requirements definition • contribution to CPDLC message standardisation (Interop). WA1.2 Mainline Aircraft 1.2.1 aircraft architecture This work area will consist in the specification of the systems involved in the ASPA S&M architecture defined in the definition phase for an installation in a flight test mainline A/C. • • •

a detailed aircraft system architecture (meeting WP5 operational requirements on safety, performance, etc.) an HMI requirement definition detailed definition of systems requirement (i.e. technical requirements at aircraft equipment level) for the implementation of ASPA S&M on board the flight test A/C.

Inputs: • Operational definition provided by WP5. • Technical results obtained from previous architecture studies and validation on simulators. Short description of contribution: • Definition of detailed aircraft architecture for mainline aircraft • support mainline architecture and system definition • support HMI requirement • Support mainline architecture and system definition • Contribution to HMI requirement definition

SJU DoW WP09 V4.0.doc

Page 46 of 143

•

Contribution to TCAS, FGS, EIS2, ATSU and FMS requirements and interfaces definition

WA2 System Validation WA2.1 Mainline Aircraft 2.1.1 – Prototype Development This work area will consist in improving the system prototypes developed in the previous phase (and used on integration simulator) in order to implement ASPA S&M function on board the flight test A/C: • Development of displays including ASPA S&M HMI novelties • Development of a traffic computer prototype (based on ATSAW) capable of ASPA S&M • Development of a navigation system prototype providing the necessary elements for ASPA S&M manoeuvre. • Development of a flight guidance system prototype able to manage specific ASPA S&M speed mode • Development of a datalink applications system (ATSU) able to manage CPDLC exchanges for S&M Input: • Definition issued from the architecture studies and test on integration simulator. Short description of contribution: • Support to equipment suppliers when functional need refinement is needed • Development of flight guidance system prototype • Follow-up of other prototypes developments (Displays) • Development of mainline traffic computer prototype • Development of ATSU prototype • Development of FMS prototype to support ASPA functions validation on Mainline aircraft Integration Simulator and flight test 2.1.2 – Integration and Installation on flight test A/C This work area will first consist in the integration of the prototypes in an aircraft integration simulator then in the installation on an aircraft of the systems prototyped for the ASPA S&M function to be tested in flight in the selected scenarios. Input: • • • •

Definition assumptions Flight Test Plan Prototypes readiness notes WP5 operational scenarios

Short description of contribution: • Integration in Integration Simulator and associated tests • Installation in Flight Test Aircraft • Support to simulator integration for TCAS FGS, EIS2, ATSU and FMS • Support to integration of all systems prototypes in Mainline aircraft integration simulator • Support to integration of all systems prototypes in flight test A/C 2.1.3 – Flight tests

SJU DoW WP09 V4.0.doc

Page 47 of 143

On the basis of the validation objectives defined in the Operational WP5, and on the basis of the identified flight test environments (provided by WP 3), this work area will focus on the validation of the airborne architecture and systems solutions and allow to evaluate the ASPA S&M in a real environment. Technical and operational validation objectives will be established. Validation scenarios will be established using the ANSP data and expertise. Flight test will be defined in terms of flight trials segregated airspace design (lateral and vertical limits definition) and flight test path structure definition (approach fix, procedure starting point). Technical validation will be conducted within WP9 using scenarios obtained from WP5. Processing analysis of recorded information relevant to the application (speed, heading, separation etc.) will be performed. Short description of contribution: • Scenario definition, flight tests, results analysis. • Support to mainline flight test (TCAS, EIS2, FGS, FMS, ATSU) • Support to validation scenario definition • Support to mainline flight test post flight data processing (for all systems) PHASE 2 • Pioneer Trials Related OI Steps and System Enablers OI: •

TS-0105: ASAS Sequencing and Merging as Contribution to Traffic Synchronization in TMA (ASPA-S&M)

EN: • A/C-15: Flight management and guidance to support ASAS spacing (ASPA) Deliverables PHASE 1 • • • •

Refined functional requirement definition of ASPA S&M High Level Architecture and system specification document. Flight test (validation) Plan Flight test Report

Risks •

Compatibility between following the vertical path and complying with the spacing instructions

• • • •

Difference between behaviour and performance of leader and trailer A/C Wake vortex Meteo Contingency procedures when manoeuvre interrupted.

SJU DoW WP09 V4.0.doc

Page 48 of 143

SWP 9.6

ASAS ASEP

SWP 9.6

Title: ASAS ASEP

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • FMS avionics • Datalink avionics • Air Surveillance Prototyping • Display prototyping • Aircraft Architecture Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress with the technical definition and validation of ASEP functions. ASEP is expected to help controllers in resolving conflicts between A/C by delegating them the responsibility to do the requested manoeuvre (e.g. vertical or lateral C&P) and maintaining separation during that manoeuvre. Main technical aspects to explore are: • Quality, integrity of the ADS-B data for separation purpose • Early analysis of cockpit and architecture needed to fulfil the safety requirements Very strong synergy is needed with WP4 / WP5 counterpart projects aiming at operational definition and validation of ASEP in the following environments: • TMA (WP5) • Continental En Route (WP4) • Oceanic En Route (WP4) WP9 will aim at beginning cockpit integration and early architecture definition. This will also provide early feedbacks to the Operational Definition conducted in WP4 and WP5. Description of Work PHASE 1 WA1 – System Definition WA1.1 All aircraft Types WA1.1.1 Functional definition This work area will consist in the definition of the operational and function assumptions used for

SJU DoW WP09 V4.0.doc

Page 49 of 143

the project. This work will use as an input intermediate results of the WP4/WP5 ASEP activities: mainly operational assumptions and end-to-end safety analysis results. The technical definition will consist in a high level functional requirement definition Inputs: • Operational definition (potentially interim versions to start with) provided by WP4 (4.7.6 ASEP, 4.7.4 ASEP-ITP) Short description of contribution: • Functional Definition • Contribution to Functional Definition for aspects common to mainline and regional • Operational, functional Definition for regional A/C • Operational, functional Definition for business A/C • Support to functional requirements definition for mainline aircraft • Functional analysis, task sharing and requirements definition WA2 – System Architecture and Validation 2.1 Mainline Aircraft WA2.1.1 High Level System Architecture This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP4/WP5 ASEP activities: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. The technical definition will consist in: • An early HMI requirement definition • High level description of new algorithms needed to support ASEP HMI concept and architecture • a high level architecture definition then systems requirement definition for the implementation of ASEP on board. Inputs: • Operational definition (potentially interim versions to start with) provided by WP4 and WP5. Short description of contribution: • High level system architecture definition • Support to mainline algorithm definition • Contribution to architecture definition • Early HMI requirement definition • Participation to standardization group (RTCA/Eurocae MOPS) • Support to positioning requirements and performance definition.

SJU DoW WP09 V4.0.doc

Page 50 of 143

2.1.2 – Mock-up Development This work area will consist in development of system prototypes in order to implement ASEP functions: • Development of a mock-up enabling evaluation by pilots of the cockpit impact of ASEP. • Algorithm development/prototype for the cockpit mock-up Input: • Definition assumptions Short description of contribution: • Mock-up development (HMI, TCAS, FG) • Mock-up component development 2.1.3 – HMI Validation On the basis of the validation objectives defined in the Operational WP4/WP5, this work area will focus on the validation of the airborne HMI and early system architecture. HMI validation objectives will be established. Validation traffic scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using traffic scenarios obtained from WP4/WP5. Short description of contribution: • Detailed scenarios definition, evaluations, results analysis • Support to HMI validation WA2.2 Business Jet 2.2.1 System Architecture This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP4/WP5 ASEP activities: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. The technical definition will consist in: • An early HMI requirement definition • High level description of new algorithms needed to support ASEP HMI concept and architecture • a high level architecture definition then systems requirement definition for the implementation of ASEP on board. Inputs: Operational definition (potentially interim versions to start with) provided by WP4 and WP5. Short description of contribution: • Define BA & GA HMI with special activities to insure BA & GA compatibility. 2.2.2 – Mock-up Development This work area will consist in development of system prototypes in order to implement ASEP functions: • Development of a mock-up enabling evaluation by pilots of the cockpit impact of ASEP. SJU DoW WP09 V4.0.doc

Page 51 of 143

•

Algorithm development/prototype for the cockpit mock-up

Input: • Definition assumptions Short description of contribution: • mock-up development for BA & GA on simulator 2.2.3 – HMI Validation On the basis of the validation objectives defined in the Operational WP4/WP5, this work area will focus on the validation of the airborne HMI and early system architecture. HMI validation objectives will be established. Validation traffic scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using traffic scenarios obtained from WP4/WP5. Short description of contribution: • Validation of test scenarios with simulator connected to ANSP ATM network for realistic evaluation PHASE 2 • Simulation • Flight Trials • Business Jets o Refinement of ASEP prototype for SSEP in Low density Operations o Simulations and Flight trials Related OI Steps and System Enablers OI: • • • EN: • •

CM-0701: Ad Hoc Delegation of Separation to Flight Deck - In Trail Procedure (ASEPITP) CM-0702: Ad Hoc Delegation of Separation to Flight Deck - Crossing and Passing (C&P) ASEP-Sequencing & Merging A/C-16: Flight management and guidance to support ASAS separation (ASEP) CTE-S8b: Airborne wake vortex detection (Higher performance)

Deliverables

SJU DoW WP09 V4.0.doc

Page 52 of 143

PHASE 1 WA1 •

Definition Assumptions document

WA2.1 • High level architecture document • Technical HMI Validation Plan • Technical HMI Validation Report WA2.2 • • •

High level architecture document Technical HMI Validation Plan Technical HMI Validation Report

Risks •

Severity of hazards identified leads to unfeasible aircraft architecture or CNS infrastructure needed.

SJU DoW WP09 V4.0.doc

Page 53 of 143

SWP 9.9

RNP Transition to xLS (x = G, I, M)

SWP 9.9

Title: RNP Transition to xLS (x = G, I, M)

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Airborne System Design (Avionics and Aircraft Manufacturer) • Aircraft Integration (Aircraft Manufacturer) Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective is to design the architecture of system to ensure continuous navigation during Initial, intermediate and final approach in order to support RNP to Precision approach transitions to xLS (x = ILS, MLS, GLS), taking into account the different RNP classes (RNP APCH, RNP AR APCH, …) and levels. The work has to be done first with CAT1 capability and auto-land. Description of Work PHASE 1 WA1 – Functional Definition This work area will consist in drafting functional requirements. Outputs will be used to support IFPP and RNP-SORG activities. Input: • Operational requirements from WP 5 Short description of contribution: • Support operational and functional system definition • Contributions to support to standardization and regulatory bodies WA2 – System Validation WA2.1 – Mainline aircraft 2.1.1– Airborne System Definition For mainline aircraft, principal focus is RNP-GLS function. This work area will consist in identifying the changes need in existing avionics system to operate such kind of operations. The systems impacted should be displays, FMGC and MMR. There might be an impact on other airborne systems. Input: • Operational requirements from WP 5.X (curved approaches) Short description of contribution:

SJU DoW WP09 V4.0.doc

Page 54 of 143

•

Support technical analysis to define technical requirements.

2.1.2 – Prototype Development For mainline aircraft, principal focus is RNP-GLS function. This work area will consist in developing: • An FMS model with RNP-GLS capability for mainline aircraft Research simulator • New functions in the following systems: Displays (EIS2), FMGC (FMS and FG) and MMR. Several specifications will be developed, from lab test ones to ready for flight. Input: • Technical Requirements defined in WA2 Short description of contribution: • Development of FMS model with RNP-GLS capability to be integrated in Mainline aircraft Research Simulator • Initial internal pre-validation of FMS model on avionic simulators facility before delivery • Development of FMS prototype to support RNP-GLS validation on Mainline aircraft integration simulator • Initial validation of FMS prototype before delivery • Support integration of FMS prototype in aircraft simulator 2.1.3 – Technical Validation and Verification For mainline aircraft, principal focus is RNP-GLS function. Once the requirements are defined in WA2, there will be design reviews with ops people and equipment suppliers to freeze the design. WP5 should also be involved. This WP will define the V&V strategy and the tests required to verify the novelties implemented in the systems. Following the equipment specifications development, simulator tests will be performed. Short description of contribution: • Participation to the V&V strategy • Support to V&V WA2.2 – Regional aircraft 2.2.1– Airborne System Definition This work area will consist in identifying the changes required in regional aircrafts avionics to ensure continuous navigation during Initial, intermediate and final approach and to operate RNP to Precision approach transitions (including GLS), taking into account the different RNP classes (RNP APCH, RNP AR APCH, …) and levels. Input: • Operational requirements from WP 5.X (curved approaches) Short description of contribution: • System architecture, simulation tools • Study and requirements of the FMS functions 2.2.2 – Prototype Development This work area will consist in prototyping the identified new functions in the FMS & avionics Input: • Technical Requirements defined in WA2 SJU DoW WP09 V4.0.doc

Page 55 of 143

Short description of contribution: • FMS with prototyped functions 2.2.3 – Technical Validation and Verification This WP will define the V&V strategy and the tests required to verify the novelties implemented in the systems. Following the equipment standards delivery, simulator tests will be performed. Short description of contribution: • Validation and verification strategy definition • Support to simulations using a Research Simulator • Support to simulations using Integration Simulator PHASE 2 WA3 – In-flight System Validation Validation scenarios definition and initial flight tests Related OI Steps and System Enablers OI: • EN: • •

AOM-0602 - Enhanced Terminal Route Design using P-RNAV Capability

CTE-N4a - GBAS Cat 1 CTE-N4c - GBAS Cat 2-3 universal, Galileo and GPS L5 based

Deliverables PHASE 1 WA1 •

FRD (experimental)

WA2.1 • Technical Requirements •

Technical Validation & Verification Report

WA2.2 • Technical Requirements • Technical note: Technical description of prototyped functions •

Technical Validation & Verification Report

SJU DoW WP09 V4.0.doc

Page 56 of 143

SWP 9.10 Approach with Vertical Guidance APV SWP 9.10

Title: Approach with Vertical Guidance APV

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Navigation systems architecture and design (FMS, GNSS, Airdata, INS/AHRS,) • Mainline Aircraft architecture and design • Regional Aircraft architecture and design • Knowledge of navigation regulations and certification rules • Definition of GNSS standards Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives This project is part of the WP9 activities on Terminal & approach operations. The objective is to support within the next years the use of deployment APV procedures in Europe. Indeed, with the progress made in the performance of the navigation means and more particularly on GNSS, a lot of users will benefit from APV procedures as soon as they are available and particularly regional aircraft. To this aim, the work plan has the following objectives: - Evaluation of the compliance of existing avionics (mainline aircraft) to APV-Baro VNAV requirements - Analysis of the required upgrades on existing avionics (mainline and regional aircraft) to fly LPV (APV-SBAS) - Definition prototyping, validation (simulator, flight tests) of future avionics with optimised architecture for APV - Support to the Development of the regulations and the standards that will be needed for certification and approval in Europe. It is proposed to base the activity on APV GPS /SBAS approach type applied to regional A/C combined with analysis of all APV approach types mainly from mainline A/C, which will contribute to a performance based concept. In the domain an optimisation of the avionics subsystem is more particularly necessary to speed up the development and use of APV GPS/SBAS procedures. Other APV’s: APV-baro and GPS APV not LPV will also be addressed as well as APV with future GNSS. Description of Work PHASE 1 WA1 APV Avionics definition WA1.1 requirements Define from APV types and definitions (inputs from WP5) a set of requirements to feed the next

SJU DoW WP09 V4.0.doc

Page 57 of 143

subtasks. WA1.2 technologies Address the impact of APV requirements on the different navigation sensors and management resources: FMS, GNSS (current GPS constellation and future GNSS constellations), AHRS/INS, DME-DME. A dedicated task is identified for the database issue that is one key topic for approaches. W A1.3 avionics architecture and trade off Is the place for the architecture definition and trade off (benefits analysis versus different architecture alternatives and current one). A key driver for these activities is future certifiability of the alternatives considered. Interaction where necessary will be clearly identified with other WP’s and managed. Inputs: Procedures definitions development plan and regulations foreseen from SESAR Operational WP (WP 5 on TMA) WA2 Support to APV standards and certification Promotion and support to the development of standards for equipment supporting APV (EUROCAE, RTCA and ARINC) based on the concepts, procedures and avionics requirements that will be defined through the other WP’s activities. The aim is to develop the right framework for equipment standards and resulting certification compliance material for Approaches with vertical guidance in Europe Inputs to WA2 Intermediate and final results from WA1 on APV avionics definition WA3 APV prototyping (Regional Aircraft). WP A31 design and development This activity is for the development of a representative APV/GPS-SBAS avionics based on the results from WPA1&2 results. This subsystem shall be developed with the aim of further installation and flight tests on a regional A/C as support to APV validation out of this WP. WP A32 In Lab validation APV prototype lab tests definition and run. PHASE 2 WA4 System Validation (Regional Aircraft) • APV models integration on Regional Airframer Research A/C simulator for trial execution • Flight trials (in Ops WP) WA5 Prototype Development and Validation (Mainline Aircraft) • APV-Baro VNAV : depending on trials results, architecture modifications and further trials Related OI Steps and System Enablers OI: • •

AO-0502 - Improved Operations in Low Visibility Conditions through Enhanced ATC Procedures AO-0505 - Improved Low Visibility Runway Operations Using GNSS / GBAS

SJU DoW WP09 V4.0.doc

Page 58 of 143

•

AOM-0602 - Enhanced Terminal Airspace with Curved/Segmented Approaches, Steep Approaches and RNAV Approaches Where Suitable

•

A/C-06 - Flight management and guidance to perform Localizer Precision with Vertical guidance (LPV) approach (e.g. SBAS) A/C-07 - Flight management and guidance to perform steep and curved approach (e.g. SBAS) CTE-N2 - SBAS

EN:

• •

Deliverables PHASE 1 WA1 • APV Avionics requirements and system architecture definition. WA2 •

Contributions (working papers) to the development and promotion of APV equipment standards and certification

•

System Lab validation tests results

WA3

SJU DoW WP09 V4.0.doc

Page 59 of 143

SWP 9.11 Aircraft Systems for Wake Encounter Alleviation SWP 9.11

Title: Aircraft Systems for Wake Encounter Alleviation

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • A/C surveillance systems • Flight warning systems • A/C flight control systems • A/C airborne data link • Flight deck displays & HMI • Wake vortex physics and detection Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives Concept Future on-board surveillance systems may include dedicated wake encounter and significant weather (e.g. clear air turbulence) avoidance function. This aims at considerably reducing the risk of severe upsets due to atmospheric disturbances and may lead to reduced wake turbulence separation requirements. It is an enabler for reduced separation operations during all phases of flight, specifically taking into account new operational concepts under study within SESAR. Such system may be operated in collaboration with dedicated ground-based wake advisory systems or be independent. It furthermore may rely on on-board, forward-looking sensors or be based solely on data link. The concept of airborne wake encounter alerting has been studied in the previous EC research projects FLAME, MFLAME, I-WAKE (sensor-based wake detection and alerting) and FLYSAFE (data link enabled wake prediction and alerting). Objectives The specific objectives of this work package are to: • Identify and define options for system interoperability with other current and future surveillance functions, sensors and flight control systems. • Identify and evaluate system H/W architecture options and potential costs. • Identify system and aircraft certification requirements. • Design and validate improved significant weather and wake vortex flight deck displays taking into account operational and flight crew information requirements as well as HMI aspects. Description of Work PHASE 1 WA1 Evaluate system interoperability

SJU DoW WP09 V4.0.doc

Page 60 of 143

• • • •

Integration with TCAS, T3CAS, ACAS, EGPWS etc. Integration with current and future on-board sensors Connection to ADS-B and interface specification Connection to F/CTL and interface specification

Inputs • Specifications of existing and planned surveillance, data link and F/CTL systems as well as ARINC definitions. • Initial specification and interface definition of airborne wake vortex sensor from WP9.30. • Airborne wake vortex alerting demonstrator software. Outputs • Technical Note describing system interoperability options and choices. • Extended demonstrator software. Short description of contribution: • Integration of predictive weather and wake vortex alerting function with traffic and terrain avoidance. Interface specification with F/CTL. •

Contribution to WA1: provide initial specification of sensor system from WP9.30, participation to operational requirements and constraints definition

•

System interoperability assessment.

WA2 Hardware architecture Identify and evaluate system hardware architecture options and costs • As part of an integrated surveillance system • As a stand-alone avionics module • In combination with specific surveillance modules Inputs • System interoperability choices from WA1. • Specification of existing system H/W architecture. Outputs • Technical Note describing system H/W architecture options, choices and estimated costs Short description of contribution: • Evaluation of options with regard to future aircraft programs. •

Contribution will include participation in system hardware definition and options selection

•

Evaluate HW architecture options/cost trade-offs.

WA3 Certification aspects Identify system and aircraft certification requirements. • Identification of certification options • Identification of certification requirements for options established in WA1 and WA2 Inputs

SJU DoW WP09 V4.0.doc

Page 61 of 143

• • •

System interoperability choices from WA1. System H/W architecture choices from WA2. Operational requirements and constraints from WP4/5/6.x.

Outputs • Technical Note defining system certification road-map. Short description of contribution: • Overall operational and aircraft certification requirements. •

Depending on the options chosen above, participation in the certification evaluation process for Mainline aircraft.

•

HF certification requirements for wake vortex display

WA4 Flight deck display Design and validate improved wake vortex flight deck display options including alerting and manoeuvre guidance taking into account HMI aspects. • Identify operational and flight crew information requirements. • Display integration with traffic information and alerts, weather hazards as well as with future operational concepts (e.g. ASAS) • 2D display options of weather hazards & wakes and conflict-free trajectory on flight deck display • 3D display options of weather hazards & wakes and conflict-free trajectory on flight deck display Inputs • Extended demonstrator software from WA1. • Operational requirements and constraints from WP4/5/6.x. Outputs • Technical Note describing display options and their HMI evaluation. Short description of contribution: • Requirements and predictive wake alert core system architecture. Provide & adapt core system prototype for simulator evaluation. Evaluation of display options in piloted simulator study. •

Contribution to define flight desk display

•

Wake vortex display HMI

PHASE 2 •

Development & evaluation of an integrated prototype system

Related OI Steps and System Enablers OI: •

AO-0304 - Dynamic Adjustment of Separations based on Real-Time Detection of Wake Vortex

EN:

SJU DoW WP09 V4.0.doc

Page 62 of 143

• • •

A/C-08 - Flight management and guidance to perform wake-vortex free approach A/C-30 - Onboard detection of wake-vortices for use as safety net CTE-S8a - Airborne wake vortex detection

Deliverables PHASE 1 WA1 •

Technical Note describing system interoperability options and choices.

WA2 •

Technical Note describing system H/W architecture options, choices and estimated costs.

WA3 •

Technical Note defining system certification road-map

WA4 •

Technical Note describing display options and their HMI evaluation

Risks Limited or missing input from previous projects due to IPR protection or confidentiality issues.

SJU DoW WP09 V4.0.doc

Page 63 of 143

SWP 9.12 GBAS Cat II/III SWP 9.12

Title: GBAS Cat II/III

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • System Design to assess GBAS Cat II/III L1 airborne components feasibility (Avionics and, Aircraft Manufacturer) Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives As a quick win and first step, Initial CAT II/III GBAS L1 which will aim at enabling CAT II/III operations based on GNSS for new aircraft in order to provide rapid benefits to users notably under low visibility as specified under WP6 and prepare the implementation of multiconstellation GBAS. GBAS based purely on an extrapolation of ILS requirements, without taking advantage of modern aircraft sensors and integration, will not be able to meet CAT II/III availability requirements based on one constellation and one frequency. The idea with Initial GBAS CAT II/III is to divert from the ILS look-alike concept by allocating risks to the ground and airborne system that differ from the current ILS risks and therefore requiring only GPS L1. ICAO NSP CSG has already started to draft SARPs for this new system, but validation remains to be done. The first objective of this work package is to focus on the airborne requirements of the SARPs and to design the architecture of the initial GBAS CAT II/IIII airborne system taking full account of the performance provided by the GBAS CAT II/III ground component as designed in WP15.3 in order to demonstrate that the CAT II/III operational performances can be met. The second objective is to ensure that the Initial GBAS CAT II/III system will not limit the development of GBAS CAT II/III multiple constellation/multiple frequencies (WP15.3.7). As a final step, the project will ensure that the technical definition and the system design of the full GBAS Cat II/III airborne function, is at the level of maturity relevant to launch a cost effective and robust A/C system development. Performance allocation will include navigation performance requirements with accuracy, integrity and continuity. Particular integrity and continuity schemes will be the main drivers for an innovative allocation to meet CAT III high level requirements. The aircraft will also be responsible to for a greater part in the provision of operational availability through sensor integration and advanced satellite selection schemes. Therefore aircraft certification requirements may change due to the change of the airborne allocation and the identified changes would have to be discussed in parallel to the design of the system.

SJU DoW WP09 V4.0.doc

Page 64 of 143

Description of Work PHASE 1 (covering only Initial GBAS) Airborne and ground architecture will need to be consolidated. Error models will be identified to feed future elements of the performance and certification compliance dossier. Failure modes will be identified at airborne level and consolidated with the ones on ground level from WP15. Definition of airborne monitors and validation of interaction with ground monitors from WP15 will be performed. Performance, safety, operational and certification requirements compliance assessment will be performed. WA1 – Airborne High Level System Architecture Design This work area will define the high level system Architecture for Mainline aircraft and Business Jets, and allocate qualitatively and quantitatively functional, performance and safety requirement to airborne part+ new airborne functionalities (e.g. onboard Iono algorithms) Inputs: • High level Requirements from ICAO proposed SARPs for GBAS CAT II/III L1 • System requirements from 15.3.1 navigation technologies specifications, 15.3.6GNSS CAT2-3 L1 Short description of contribution: • Participation to system architecture design •

Provide the link to the ATM application and ground developments

•

Contribution (GNSS receiver) to airborne system architecture, allocation of functions and performance

WA2 – System Validation WA 2.1 – Mainline Aircraft 2.1.1 – Prototype Development (first steps) This work area will consist in subsystem development and autoland simulation model development. It will also consist in the definition of continuity augmentation requirements if required, based on the ongoing continuity study. Input: • High Level System Requirement Document • GBAS continuity study (from WP15.3) • GBAS error noise model Short description of contribution: • Specification Definition • Prototype Development • SIMPA upgrade

SJU DoW WP09 V4.0.doc

Page 65 of 143

2.1.2 – Technical Validation This work area will use initial functional testbeds for simulation tests and will collect results from WA1 and 3 to validate architecture and subsystem design. This work area will also perform autoland simulations and failure mode simulations. First issues of local availability are to be studied, validation is only possible in the prototype stage. Short description of contribution: • Validation including Simulation test using prototype developed in WA2 •

Contribution to Simulation test

• •

Validation tool provision and support SARPs interoperability validation through comparison with other manufacturer ground and airborne results Availability Study Iocal environment guidelines – airborne aspects

• •

WA 2.2 – Business Aircraft 2.2.1 – Prototype Development (first steps) This work area will consist in subsystem development and autoland simulation model development. 2.2.2 – Technical Validation This work area will use initial functional testbeds for simulation tests and will collect results from WA1 and 3 to validate architecture and subsystem design. This work area will also perform autoland simulations and failure mode simulations. WA3– Ground Subsystem considerations for new Aircraft certification requirement Identification of any new aircraft certification requirement based on WP15 outcome notably for the accuracy, integrity, continuity and availability at specific locations. Input: • Functional Requirements Document and High Level System Requirements Document at GBAS system level • WP15 GBAS CAT II/III L1 standards, ground system performance, design, failures and mitigations Short description of contribution: • Participation in the identification of new aircraft certification requirements

PHASE 2 (covering Initial GBAS Cat2-3 and Full GBAS Cat2-3) • for Initial GBAS Cat2-3 • Further development and installation of airborne equipment for Mainline aircraft and Business aircraft • Flight Trials (Mainline aircraft and Business aircraft) SJU DoW WP09 V4.0.doc

Page 66 of 143

•

• Pioneer Trials for Full GBAS Cat2-3 • System Definition • System validation

Related OI Steps and System Enablers OI: •

AO-0505: Improved Low Visibility Runway Operations Using GNSS / GBAS

•

CTE-N4b: GBAS Cat 2-3 initial, GPS L1 based

EN:

Deliverables PHASE 1 (covering only Initial GBAS Cat2-3) WA1 •

Technical Note – Airborne Impact Analysis

WA2.1 • Technical Validation Plan • Technical Validation Report WA2.2 • Technical Validation Plan • Technical Validation Report WA3 • • • •

Technical Note - Certification Issues Technical Note – Availability and Local Environment aspects Technical Validation Plan Technical Validation Report

Risks • •

Transition to Multi GNSS GBAS CAT II/III too constraining Ground design from WP15 inadequate to meet performance requirements

SJU DoW WP09 V4.0.doc

Page 67 of 143

SWP 9.13 Airport Surface Taxi Clearances SWP 9.13

Title: Airport Surface Taxi Clearances

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Airport Navigation System Design to assess moving map implementation feasibility • Aircraft Integration e.g. mixed voice and datalink clearances impact on clearances conformance alerting • Datalink exchanges Prototyping Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress with the technical definition and validation of mixed voice and datalink taxi clearances on airport surface. It is anticipated that use of datalink taxi routing and clearances will provide an additional significant improvement to safety and predictability on current airport surface operations. The main technical issues are the level of quality of Airport databases, onboard HMIs, datalink exchanges means (technical enablers) and the criticality of all technical elements: architecture, moving map displays, airport database, ADS-B In/Out, etc. Some feasibility assessment will need to be conducted using industrial prototypes. Very strong synergy is needed with the WP6 counterpart project aiming at operational validation of mixed voice and datalink taxi clearances at airport.

SJU DoW WP09 V4.0.doc

Page 68 of 143

Description of Work PHASE 1 WA1 – System Definition WA1.1 All aircraft Types WA1.1.1 Functional Definition This work area will consist in the definition of the operational and functional assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The technical definition will consist in a high level functional requirement definition. Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 (6.7.3 – A-SMGCS Guidance Function) Short description of contribution: • Lead author for functional requirements definition •

Support Functional requirements definition (Regional Aircraft perspective)

•

Support Functional requirements definition (Business Aircraft perspective)

•

Support Functional requirements definition for both Regional and Mainline aircraft

WA2 System Architecture and Validation WA2.1 Mainline Aircraft WA2.1.1 System Architecture This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. WG78 on datalink exchanges and WG44 on databases) so as to expedite standardization activities using validation results. The technical definition will consist in: • Target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for mainline platform: • A high level HMI requirement definition • A system requirement definition (i.e. technical requirements at aircraft equipment level) of taxi clearances Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 Short description of contribution:

SJU DoW WP09 V4.0.doc

Page 69 of 143

•

Lead of HMI, system and architecture definition

•

Contribution to HMI requirements definition and system requirements definition for taxi clearances Monitor & Contribution to Airport datalink services standardization and regulatory bodies

•

WA2.1.2 – Prototype Development This work area will consist in : • Development of an airport navigation system prototype capable of taxi clearances • Development of a datalink exchange computer prototype capable of taxi clearances Input: • Definition assumptions Short description of contribution: • Prototyping of datalink exchange computer for taxi clearances (ATSU) and airport navigation system display. • Support to prototypes development. • •

Prototype of Functional database for taxi clearances Development of taxi clearances display function on Airport navigation system

WA2.1.3 – Simulator and Aircraft Integration This work area will consist in : Implementing adaptations required to host the prototypes and play the selected scenarios The integration of the prototypes in aircraft simulators and on an Aircraft. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

Short description of contribution: • Lead of simulator and aircraft integration. • Support integration on simulator and A/C for Airport Navigation System including Taxi clearances display function WA2.1.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). Technical validation objectives will be established. Validation taxi clearances scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using taxi clearances scenarios obtained from WP6. Short description of contribution: • Lead of technical validation on a representative Airport.

SJU DoW WP09 V4.0.doc

Page 70 of 143

•

Participation to technical validation

WA2.2 Business Jets WA2.2.1 System Architecture This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. WG78 on datalink exchanges and WG44 on databases) so as to expedite standardization activities using validation results. The technical definition will consist in: • Target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for business platform • An HMI requirement definition • A system requirement definition (i.e. technical requirements at aircraft equipment level) of traffic alerts Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 Short description of contribution: • HMI requirements for BA • support system definition WA2.2.2 – Prototype Development This work area will consist of: • Development of an airport navigation system prototype capable of taxi clearances • Development of a datalink exchange computer prototype capable of taxi clearances Input: • Definition assumptions Short description of contribution: • prototype for taxi clearance • BA datalink prototype for taxi clearance WA2.2.3 – Simulator and Aircraft Integration This work area will consist in: Implementing adaptations required to host the prototypes and play the selected scenarios The integration of the prototypes in avionic and simulators and on an Aircraft. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

SJU DoW WP09 V4.0.doc

Page 71 of 143

Short description of contribution: • Integration of prototypes in simulator WA2.2.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). Technical validation objectives will be established. Validation taxi clearances scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using taxi clearances scenarios obtained from WP6. Short description of contribution: • Validation of scenarios on simulator standalone or coupled with ATM network simulator

WA2.3 Regional Aircraft WA2.3.1 System Architecture This work area will consist in the definition of the operational and technical assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. WG78 on datalink exchanges and WG44 on databases) so as to expedite standardization activities using validation results. The technical definition will consist in: • Target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for regional aircraft • An HMI requirement definition • A system requirement definition (i.e. technical requirements at aircraft equipment level) of taxi clearances Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 • Inputs from WA2.1 Short description of contribution: • Aircraft architecture and requirements • HMI requirements definition and system requirements definition for taxi clearances WA2.3.2 – Prototype Development This work area will consist in : • Development of an airport navigation system prototype capable of taxi clearances • Development of a datalink exchange computer prototype/model capable of taxi clearances Input: • Definition assumptions • Civil Avionics Manufacturer moving map and CMU prototypes and evaluations SJU DoW WP09 V4.0.doc

Page 72 of 143

Short description of contribution: • Contribution to prototype development , initial validation and readiness for integration feasibility • Prototype of Functional database for taxi clearances Development of taxi clearances management and display function on Airport navigation system WA2.3.3 – Simulator/bench integration This work area will consist in : • Adaptation of system integration bench to simulate corresponding Regional aircraft environment, including functional and system integration of datalink services. • Adaptation of Regional aircraft Research simulator to simulate corresponding Regional aircraft environment, including functional and system integration of datalink services. • Integration of prototypes in Regional aircraft system integration bench for testing at equipment and avionic level • Integration of models in Regional aircraft Research simulator for testing at A/C level. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

Short description of contribution: • Support to bench trials • Adaptation of simulation environment • Bench trials • Support to adaptation of simulation environment WA2.3.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). Technical validation objectives will be established. Validation taxi clearances scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using taxi clearances scenarios obtained from WP6. Input: • Operational scenario from WP6 Short description of contribution: • Support to testing activity on Regional aircraft Research simulator • Testing activity on Regional aircraft integration bench • Testing activity on Regional aircraft Research simulator • Support to testing activity on Regional aircraft integration bench PHASE 2 • Pioneer trials

SJU DoW WP09 V4.0.doc

Page 73 of 143

Related OI Steps and System Enablers OI: •

AUO-0302: Successive Authorisation of Reference Business / Mission Trajectory (RBT) Segments using Datalink

•

AGSWIM-56: Basic air-ground datalink communications service supporting different kinds of applications

EN:

Deliverables PHASE 1 WA1 •

A high level functional requirement definition

WA2.1 • High Level Architecture Definition Assumptions document.

• •

Technical Validation Plan Technical Validation Report

WA2.2 • High Level Architecture Definition Assumptions document. • Technical Validation Plan • Technical Validation Report WA2.3 • High Level Architecture Definition Assumptions document. • Technical Validation Plan • Technical Validation Report Risks • • • •

Integration of taxi clearances in the cockpit Quality and level of integrity of datalink exchanges information. Quality and level of integrity of airport databases and moving map. Compatibility of Aircraft and Ground enablers (databases etc).

SJU DoW WP09 V4.0.doc

Page 74 of 143

SWP 9.14 Airport Surface Alerts (ownship and traffic) SWP 9.14

Title: Airport Surface Alerts (ownship and traffic)

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Airport Navigation System Design to assess moving map implementation feasibility (Avionics Manufacturer, Aircraft Manufacturer) • Aircraft Integration e.g. cohabitation of ownship and traffic alerts with other alerts in the cockpit (Aircraft Manufacturer). • Datalink exchanges Prototyping (ATSU Specialized Manufacturer) • Air Surveillance Prototyping (TCAS Specialized Avionics Manufacturer) • Human Factors Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress with the technical definition and validation of ownship alerts (conformance to clearance, runway and taxiway compatibility) and traffic alerts on airport surface. Also the HMI needs to be defined and validated. Ownship alerts: It is anticipated that use of datalink taxi clearances, together with displaying other traffic via ADS-B and TIS-B, will provide an additional significant improvement in safety and predictability on current airport surface operations. The step forward will then be the display of specific conformance and compatibility alerts to the flight crew. Some work has already been conducted by research projects (CASCADE, EMMA and EMMA2, NUP2+). The main technical issues are the level of quality of Airport databases, onboard HMIs, datalink exchanges means (technical enabler) and the criticality of all technical elements: architecture, moving map displays, airport database, etc. Traffic alerts : It is anticipated that use of traffic situation awareness (ATSA-SURF) will provide an additional safety net to current airport surface operations. The step forward will then be the display of specific alerts to the flight crew. The main technical issues are the level of quality of ADS-B data (technical enabler) and the criticality of all technical elements: architecture, moving map displays, airport database, etc. Some feasibility assessment will need to be conducted using industrial prototypes. Very strong synergy is needed with the WP6 counterpart project “safety net” aiming at operational validation of alerts at airport.

SJU DoW WP09 V4.0.doc

Page 75 of 143

Description of Work WA1 System definition WA1.1 All aircraft Types WA1.1.1 Functional Definition This work area will consist in the definition of the operational and functional assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. The technical definition will consist in a high level functional requirement definition. Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 (6.7.1 – Airport Safety Support Tools for pilots and controllers) Short description of contribution: • Lead author for the detailed functional requirements definition • Support functional requirements definition (regional aircraft perspective) • Support functional requirements definition (business aircraft perspective) • Support functional requirements definition for traffic computer functional logics • Support functional requirements definition for alerts display WA2 System Architecture and Validation WA2.1 Mainline Aircraft WA2.1.1 System Architecture This work area will consist in the definition of the operational and functional assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups so as to expedite standardization activities using validation results. The technical definition will consist in: • target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for mainline platform • a high level HMI requirement definition • a system requirement definition (i.e. technical requirements at aircraft equipment level) of alerts Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 Short description of contribution:

SJU DoW WP09 V4.0.doc

Page 76 of 143

• • • •

Leader of the mainline architecture definition Contribution to HMI requirements definition and system requirements definition Development of display function on Airport System Navigation Traffic alerts : support mainline architecture.

WA2.1.2 – Prototype Development This work area will consist in : • Development of an airport navigation system prototype capable of alert display • Development of a traffic computer prototype (based on ATSAW) capable of traffic alerting • Concept development for both the awareness display and alerts. • If necessary a dedicated prototype for datalink exchanges capable of taxi clearances (prototypes dedicated to the taxi clearances project may be sufficient) Input: • Definition assumptions Short description of contribution: • Support to equipment suppliers when functional need refinement is needed • Support with Traffic Computer prototype WA2.1.3 – Simulator Integration This work area will consist in integrating the prototypes in the Mainline Aircraft Research simulator. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

Short description of contribution: • Leader for simulator integration • Support integration on Mainline Aircraft Research simulator and A/C for Airport Navigation System including alerts function • Support to simulator integration of the traffic computer prototype WA2.1.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). On the basis of the validation objectives defined in the Operational WP6, and on the basis of the identified simulation environments (provided by WP 3), this work area will focus on the validation of the airborne architecture and systems solutions Technical validation objectives will be established. Validation scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using scenarios obtained from WP6.

SJU DoW WP09 V4.0.doc

Page 77 of 143

Short description of contribution: • Leader for technical validation •

Support to technical validation

WA2.2 Business Jets WA2.2.1 System Architecture This work area will consist in the definition of the operational and functional assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups so as to expedite standardization activities using validation results. The technical definition will consist in: • target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for business aircraft platform • an HMI requirement definition • a system requirement definition (i.e. technical requirements at aircraft equipment level) of traffic alerts Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 Short description of contribution: • Define BA Architecture • HMI requirements for BA • Support system definition (EGPWS/RAAS)

.Potential

quick

win

using

existing

equipments

WA2.2.2 – Prototype Development This work area will consist in : • Development of an airport navigation system prototype capable of alert display • Development of a traffic computer prototype (based on ATSAW) capable of traffic alerting • Concept development for both the awareness display and alerts. • If necessary a dedicated prototype for datalink exchanges capable of taxi clearances (prototypes dedicated to the taxi clearances project may be sufficient) Input: • Definition assumptions Short description of contribution: • prototype for Traffic and Ownship alerts

WA2.2.3 – Simulator Integration

SJU DoW WP09 V4.0.doc

Page 78 of 143

This work area will consist in : • Implementing adaptations required to host the prototypes and play the selected scenarios • The integration of the prototypes in avionic simulators. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

Short description of contribution: • Integration of prototypes in simulator WA2.2.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). On the basis of the validation objectives defined in the Operational WP6, and on the basis of the identified simulation environments (provided by WP 3), this work area will focus on the validation of the airborne architecture and systems solutions. Technical and HMI validation objectives will be established. An HMI Evaluation/Validation Plan will be developed. Validation scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using scenarios obtained from WP6 Short description of contribution: • Validation of scenarios on simulator standalone or coupled with ATM network simulator

WA2.3 Regional Aircraft (ownship alerts only) WA2.3.1 System Architecture This work area will consist in the definition of the operational and functional assumptions used for the project. This work will use as an input intermediate results of the WP6 counterpart project: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups so as to expedite standardization activities using validation results. The technical definition will consist in: • target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for regional aircraft • an HMI requirement definition and analysis • a system requirement definition (i.e. technical requirements at aircraft equipment level) of alerts Inputs: • Operational definition (potentially interim versions to start with) provided by WP6 Short description of contribution:

SJU DoW WP09 V4.0.doc

Page 79 of 143

• •

Aircraft architecture and system requirements HMI requirements definition and system requirements definition for ownship alerts

WA2.3.2 – Prototype Development This work area will consist in : • Development of an airport navigation system prototype capable of alert display • Development of a traffic computer prototype (based on ATSAW) capable of traffic alerting • Concept development for both the awareness display and alerts. • If necessary a dedicated prototype for datalink exchanges capable of taxi clearances (prototypes dedicated to the taxi clearances project may be sufficient) Input: • Definition assumptions Short description of contribution: • Contribution to prototype development , initial validation and readiness for integration feasibility •

Development of ownship alerts function (generation and display) on Airport navigation system

WA2.3.3 – Simulator Integration This work area will consist in : • Implementing adaptations required to host the prototype and play the selected scenarios • The integration of the prototype in a regional aircraft simulator. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP6 operational scenario

Short description of contribution: • Integration on regional aircraft simulator • Support integration on regional aircraft manufacturer simulator and A/C for Airport Navigation System including ownship alerts function WA2.3.4 – Technical Validation This work area will begin within WP6 with the identification of operational validation objectives in close coordination with the ANSP partner so as to be consistent and potentially complementary with the Ground counterpart project (WP12). On the basis of the validation objectives defined in the Operational WP6, and on the basis of the identified simulation environments (provided by WP 3), this work area will focus on the validation of the airborne architecture and systems solutions. Technical and HMI validation objectives will be established. An HMI Evaluation/Validation Plan will be developed. Validation scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using scenarios obtained from WP6.

SJU DoW WP09 V4.0.doc

Page 80 of 143

Short description of contribution: • Technical validation and reports • Technical validation with regional aircraft manufacturer and reports PHASE 2 • Flight Trials • Pioneer Trials Related OI Steps and System Enablers OI: • EN: • •

AUO-0605: Automated Alerting of Runway Incursion to Pilots (and Controller) A/C-43: Automatic uplink of the alert to avoid runway incursion AGSWIM-47: Air-ground data communications service for surface information and guidance (D-SIG)

Deliverables PHASE 1 WA1 •

Functional requirements document

WA2.1 • High Level System Definition Assumptions document • • Technical Validation Plan • Technical Validation Report WA2.2 • High Level System Definition Assumptions document • Technical Validation Plan • Technical Validation Report WA2.3 • High Level System Definition Assumptions document • Technical Validation Plan • Technical Validation Report Risks • • • • • •

Integration of alerts in the cockpit Quality and level of integrity of datalink exchanges. Quality and level of integrity of ADS-B-Out and ADS-B-In information. Quality and level of integrity of airport databases and moving map. Compatibility of Aircraft and Ground enablers (databases etc). Quality and level of integrity of ownship position and velocity vector information.

SJU DoW WP09 V4.0.doc

Page 81 of 143

SWP 9.16 New Communication Technology at Airport SWP 9.16

Title: New Communication Technology at Airport

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • ATM Connectivity solutions • WiMax technology (Telecom supplier via Datalink civil avionics manufacturer) • System design and antennae installation (Mainline Aircraft Flight Deck Integrator) Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives Coordination with Project 15.2.7 (Airport Surface Datalink). Define, validate and demonstrate a technical profile and architecture for a new generation of airport surface system to enable advanced surface CNS systems and improved information distribution and provide lower cost, safer and more efficient airport surface operations: the new surface communication system will be based on Wimax 802.16e standard for ATS/AOC communications, compliant with SESAR/FCI recommendations, in strong collaboration with Project 15.2.7 for end-to-end requirement definition, system design, WIMAX profile definition…. Technical objectives • Study of impact of integration onboard aircraft • Advanced Antenna Studies • RF & Capacity Planning Tools • Preliminary certification framework • Preliminary inputs to regulatory bodies • Preliminary inputs for standardization • Prototypes of airborne products Description of Work WA1 Deployment & Integration Analysis Objectives are: • To investigate and clarify all the issues related with the technical deployment of the new Wimax System on the Aircraft. • To investigate advanced themes related to the A/C platform Antenna integration Short description of contribution • System requirements, analysis of the technology and impacts on antennae technology,. Study of Packaging, interfaces, HW and SW qualification objectives • Participation to system analysis and profile definition

SJU DoW WP09 V4.0.doc

Page 82 of 143

WA 2 Airborne Prototype development Objectives are: • To Design & Develop a demonstrative Aero-wimax subsystem composed by Subscriber, Base Station, Management System • Integration and qualification of the demonstrator acting as a player and a “broker” to apply proper integration methodology. This will ensure that the individual components will work together in a way that will support the intended services enabling seamless operation of specified end user functional applications. • To ensure coherency of architecture and design in a path to eventual validation and demonstration of the global solution. Short description of contribution • Monitoring of development and refinement of needs and architecture constraints • Participation to system development, integration and standardisation and prototype realization WA3 Integration & Testing Objective is to validate the definition of AeroWiMax in real environment, up to integration in a real flight test aircraft. The data gathered in this task will be used to complement the technical study performed in WP6.1, 6.2 and 6.3 but also WP 15 and will be input for any further re-analysis or feedback and for other initiatives (SANDRA) Focus will be put on: • Physical layer and real environment performances • CEM and antenna installation • Security • Quality of Service / services provided • Mobility • Performance Short description of contribution • Test objectives definition, • Test tools requirements, • Test bed architecture definition (aircraft sketch – installation layout for antenna/cabin equipment - Architecture requirement Dossier), Development of test tools (Log analysis tools provided – automatic analysis tool to be developed and rest of the work will mainly consist in setting up of COTS tools/applications) , • Test bed integration (Installation on aircraft, Integration of ground tools, Installation on van), • Tests (3 van tests sessions, 10 non specific ground tests) (including 1-2 tests analysis) , • final technical analysis. It is assumed here that basic test tools will be provided by the supplier (wimax monitoring tools…) WA4 – Advanced Studies Integration with positioning (ADS-B,GPS, GALILEO) for A-SMGCS Studies and recommendations for high speed adaptation (802.16m?)

SJU DoW WP09 V4.0.doc

Page 83 of 143

Solutions for ad-hoc L2 networking Short description of contribution • Advanced studies for A-SMGCS, high-speed adaptation & ad-hoc networking Related OI Steps and System Enablers OI: • • •

AUO-0302: Successive Authorisation of Reference Business/ - Mission Trajectory (RBT) Segments using Datalink AUO-0303: Revision of Reference Business/Mission Trajectory (RBT) using Datalink AO-0104: Airport Safety Nets including Taxiway and Apron

EN: • CTE-C4a: Airport Datalinks (WIFI, EDGE, GPRS, ...) • CTE-C4b: New Airport Datalinks·Link to Operational Improvement· Deliverables • • •

WIMAX airborne system requirements Report on Airborne Modelling and Performance simulation Report on advanced studies outcome and proposed next steps

SJU DoW WP09 V4.0.doc

Page 84 of 143

SWP 9.19 SWIM Air-Ground Capability SWP 9.19

Title: SWIM Air-Ground Capability

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following knowledge areas are essential: • Avionics concepts of operation, capabilities, architectures, information content and usage • Existing and upcoming communications technologies for aviation • Communication technology trends and evolution forecasts in the military, commercial and consumer industries • Information security concepts of operation and process framework, specifically as it applies to aeronautical/aircraft information security· • Aeronautical information security standards (e.g., ICAO, AEEC, ATA, etc.) as well as commercial information security standards (e.g., IETF, ITU, PKIX, etc.) • Regulatory and certification environment, standardization framework and processes for avionics systems • Worldwide spectrum regulations, availability, usage and approval process, with special emphasis on EU countries As, SWIM Air-Ground capability is a communications technology enabler for SWIM (WP-14) and Information Management (WP-8), through knowledge the following are highly desirable: • •

SWIM operational aspects EATM/SWIM technology aspects

Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The SWIM Air-Ground capability facilitates the exchange of information seamlessly and securely in/out of the aircraft system by enabling the aircraft to be a peer node on the Netcentric EATM SWIM network. The objective of SWIM Air-Ground Capability is to provide communication services between the aircraft and ground peer entities to support SWIM operational aspects. It defines, develops, demonstrates and validates the internetworking, routing, relaying, transport, and communication management functions required to meet safety, performance and Quality of Service (QoS) requirements imposed by SWIM (WP-14) and Information Management (WP-8). This project works in close collaboration with WP15 to define, develop, demonstrate and validate the networking and security concepts. It is envisioned that all end-state data communication needs for SESAR will be satisfied by SWIM. This includes high bandwidth, time critical and near real-time data communication. In order to achieve that goal, it will be necessary for SWIM Air-Ground Capability to manage the underlying datalink A/G resources to assure QoS requirements. SWIM air-ground capability is an important enabler for IFR equipped general aviation. The increased use of regional airport with mixed mainline/business/regional/general aviation traffic

SJU DoW WP09 V4.0.doc

Page 85 of 143

requires access of business and general aviation to SWIM, both publishing relevant data to SWIM as well as subscribing to specific information. This work package does not define the underlying datalink services. It utilizes existing and future Air/Ground datalink services being addressed by WP9.16, WP9.17 and WP15.2.4. As a user of the services offered by the above referenced work packages, SWIM Air-Ground capability will impose requirements on them. Air-ground datalink security is an essential technology enabler for SWIM Air-Ground services. Protecting air-ground datalink communications is critical since safety-of-flight may be jeopardised if an unauthorised entity accesses/exploits sensitive information or compromises the integrity of ATM data/services. While end-to-end security concepts and overall policy will be performed in WP14, and architecture and requirements definition will be performed under WP15, the primary objectives of this project are: • Ascertain air-ground datalink information security needs,· • Analyse the information security risks, • Specify the minimum set of information security countermeasures necessary to reduce risk to a level acceptable for safety-of-flight, • Develop an initial strategy for proof-of-concept demonstration and validation Information Management and SWIM services definitions are outside the scope of this SWIM Air-Ground Capability work package. Description of Work PHASE 1 WA1 – Liaison SWIM Air-Ground Capability is based on Service Oriented Architecture and supports other aircraft subsystems and functions. As such, a primary function of this capability is to liaise with WP-9.0, WP-2, WP-8, WP-15 and WP-14 to support System of Systems requirements definitions, concept of operations and validation. Projects undertaken by the Liaison sub-WP are: • Support the development of Information Management (in WP-8) OSEDs by defining the Concept of Operation for SWIM Air-Ground Capability. • Support SPR definitions for Information Management (in WP-8) • Support SWIM Interoperability Specification development (in WP-14) • Support Data link security, end-to-end Air-Ground Datalink architecture and requirements definitions (in WP15) • Support the formulation of validation and standardization strategies, e.g. MASPS and MOPS (in WP-2) • Coordinate closely with overarching ATM Security project (WP16.2) Activities under WP9.19 will be concentrated in this work area during the first phase of the project to support the operational concepts, end-to-end systems architecture for different platforms (mainline, regional), performance and technical requirements definitions. Short description of contribution • Coordination among work areas as project leader; interaction with relevant WP2, WP8, WP14, WP15 and WP16 activities. • Analysis of SPR and Interop hypothesis on Airborne Architecture • Contribution to compilation of current status of Information Management (types of SJU DoW WP09 V4.0.doc

Page 86 of 143

• •

applications, needs, technologies, phases of application) to define a global technical roadmap. Characterize the flows and the types of operations to be satisfied. Support the information management, interoperability and validation strategies

WA2 – Concept Definition The Air-Ground Capability performs three major functions: • Aggregation of data from various aircraft sub-systems for consumption by other groundbased SWIM entities. • Distribution and transfer of information between aircraft systems and Ground-based systems. The transfer function manages the underlying datalink services and physical resources to ensure that the QoS, information assurance, security and authentication requirements are satisfied. • Encoding, decoding and presentation of information to comply with SWIM standard formats to enable independent evolution of avionics and ATM systems. The concept definition work area for each of the major functions will encompass the following activities: • Perform feasibility and trade-off analyses of various air-ground communications technologies. • Identify candidate technologies to provide SWIM capabilities for each implementation packages. • Investigate solutions for SWIM Air-Ground capability for Military Aircraft • Develop the air-ground communications architecture and technical specifications to meet SWIM SPR. Technical specifications will include functional and system level technical requirements. • Cost benefit analysis for regional aircraft. • Define regional aircraft architecture • Establish an approach to standardize the air-ground communication functions and support activities leading to regulatory approval. This will require active participation in standardization groups (e.g. RTCA/Eurocae/ICAO/AEEC) to expedite standardization activities. • Define the air-ground datalink security context, derived from an overall, high-level security context· • Perform an information security risk assessment within the scope of the air-ground datalink security context and derived from an overall, high-level security risk assessment Inputs: • OSEDs and SPRs • ICAO Doc 9896 - ATN/IPS specification of MobileIPv6 and its mobility architecture • SESAR ATM Security Framework (WP16.2.1.1) and Information Security Risk Assessment (WP16.2.3) • ARINC Report 811, ARINC Specifications 822 and 823 Short description of contribution • Lead trade-off analyses; architecture & requirements definition, and technical specification development. Participate in relevant standardization committees. • System architecture definition and standardisation approach. • Assessment of the impact on current airborne architectures and accommodation of “legacy” systems.

SJU DoW WP09 V4.0.doc

Page 87 of 143

•

• • • •

Contribute to definitions and specifications in term of system performances and environment (logical & physical infrastructure, interfaces) to meet the targeted requirements per SESAR IP. Contribution to definition of a functional architecture capable of supporting these services (with particular attention to Network Management Architecture). Trade-off analysis and identification of the most appropriate technologies to be used to comply with SWIM Definition of AG communications architecture and technical specifications Definition of low cost architecture for GA access to SWIM

WA3 – Airborne Prototype Development This work area will develop a prototype of the SWIM air-ground capability to demonstrate seamless routing and relaying of SWIM Information among airborne and ground peer entities using underlying datalink services. The prototype will include applicable QoS, information assurance, security and authentication requirements to support system objectives. As WP9.19 is dependent on other work packages that are being defined concurrently, complete prototyping of SWIM Air-Ground capability can not be realized within the time period (2009 to 2011) covered by this Project. It is anticipated that prototype activities will continue around 2013 . To maximize the benefits from the prototyping activities, a spiral development methodology will be employed. The following activities are included within the scope of this work area: • Create a prototype development plan to harmonize contributions across all partners • Establish an uniform development environment to facilitate integration of SW/HW components to be developed concurrently at partner organizations • Emulate interfaces to selected avionics platforms: specifics to be developed under WA3.1 and WA3.2 • Emulate legacy A/G datalink services and SWIM A/G interface to AGDLGMS • Prototype collection, encoding, aggregation, distribution and transfer of information types (TBD based on ConOPS and objectives) NOTE: Prototype and demonstration of airborne security capabilities are included in this work area. Full end-to-end SWIM networking and security prototypes will be harmonized with the deliverables of WP15. Input: • System architecture, requirements and interoperability specifications Short description of contribution • Lead SWIM A/G prototype development. Develop capabilities listed above in lab/simulator environment using workstations. • Contribution to the requirements and specifications of relevant functionalities for the mid-term airborne package & mapping onto functional and physical components. • Contribute to design and development of airborne part prototypes of selected components. • Contribute to assess the technologies and ensure that most important elements of the architecture are integrated for a proof of concept. • Contribution to prototype development through the sub work areas WA3.1 and WA3.2. • Implementation of a middleware demonstrating seamless routing and relaying of information

SJU DoW WP09 V4.0.doc

Page 88 of 143

WA3.1 Mainline This work area will provide the mainline prototype and simulation. WA3.2 Regional Aircraft This work area will provide regional aircraft specific prototypes and simulations. •

•

Prototype development based on the specific platform of the SWIM air-ground capability to demonstrate seamless routing and relaying of SWIM Information among airborne and ground peer entities using underlying datalink services. The prototype will include applicable QoS, information assurance, security and authentication requirements to support system objectives.

WA4 – Technical Validation This work area will expand on the validation strategies developed in conjunction with WP2 to develop specific validation plans, and data for the SWIM Air-Ground capability. It will establish technical validation objectives and perform technical concept validation. Input: • • • •

System architecture definition System functional specification and system requirements System interoperability specification System validation strategies

Short description of contribution • Lead the validation activities. Develop a detailed validation plan and perform validation based on prototypes developed under WA3 • Airborne validation activities including modelling/simulation of candidate datalink security controls to ascertain whether required quality of supported services is achievable (availability, continuity, integrity, latency) • Contribute to defining demonstrator architecture & test procedures for the mid-term airborne package. • Provisioning/modification of test components. • Modification/development of test applications. • Perform validation tests (lab tests on near-to-real life networks) and with ground counter-part • Participation to technical validation objectives definition and technical validation assessment • Support to technical validation PHASE 2 • Continue formulation of international standards at various aviation industry forums (e.g. EUROCAE, RTCA, ICAO, AEEC) • Port capability to blue label avionics for HW in the loop demonstration and testing in the lab. • Perform proof-of-concept demonstrations in support of validation initiatives. • Support pre-operational trials

SJU DoW WP09 V4.0.doc

Page 89 of 143

Related OI Steps and System Enablers OI: • • •

IS-0706 SWIM – European Air-Ground Communication Infrastructure IS-0707 SWIM Air-Ground limited services IS-0709 SWIM Air-Ground extended services

EN: •

SWIM-20 New EUROCAE Standard for SWIM - Air-Ground IOP/SWIM (Aircraft and AGDLGMS) Services, Protocol and QoS • SWIM-16 Overall SWIM technical reference architecture • AOC-ATM-04 Data model to allow transfer of trajectory from AOC-ATM system into ATC world with SWIM • AOC-ATM-05 Data model to allow transfer of update trajectory from ATC world to AOCATM system with SWIM Deliverables PHASE 1 • • • • • • •

Input to Concept of Operations (OSED) and SPR documents; white papers Input to Interoperability Specification document; white papers High Level System architecture definition document Air-Ground Datalink Security Context Definition and Risk Assessment System functional specification and technical requirements documents. Technical Validation Plan Technical Validation Report

Risks • • •

Global interoperability and harmonization with aeronautical industry standards Development Information Management OSED, SPR and overall SWIM architecture definition concurrently with SWIM Air-Ground capability definition SWIM performance requirements consistent with technical capabilities of underlying datalink services

SJU DoW WP09 V4.0.doc

Page 90 of 143

SWP 9.20 Military Datalink Accommodation SWP 9.20

Title: Military Datalink Accommodation

Necessary Expertise In the following main domains: For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following knowledge areas are essential: • Datalink communications • Military aircraft flight deck integrator (e.g. impacts on the current aircraft architectures and relevant cockpit systems) • Military avionic manufacturers • Military operations on the civil airspace • Military users • Military operations on the civil airspace Indicative work breakdown per co-financed contributors: Airborne Industries: 100% Concept & Objectives Four categories of military aircrafts are defined: military transport aircraft, fighter/trainer aircraft, light aircraft (light civil and military aircraft, helicopters, paramilitary aircraft) and different types of UAS: all categories may fly GAT or OAT. These 4 different categories of State aircraft will be equipped with new CNS capabilities as defined for comparable categories of civil aircraft (commercial, business aviation, light aircraft) in order to ensure the required levels of civil-military ATM- interoperability. Military Datalink Accommodation will analyze use of available military datalinks to support CPDLC, ADSB/ASAS and other services by performing a feasibility study to investigate a solution for interoperability (ground interface to be considered). This would enable military aircraft participation in the SWIM environment. As part of the Capability level 4 R&D, there is the need to determine solutions for military aircraft compliance with 4D Trajectory performance based navigation requirements including, where possible, the reuse of military enablers: interoperability with military datalinks and use of FMS alike Military Mission Systems to support trajectory management are areas to be investigated. Many of the technologies necessary to support the ConOps and its associated architecture - up to and including ATM Capability 3 - are already - or planned to be - implemented to fulfil the needs of ATM to service all aircraft from legacy carriers and military to ultra-light aircraft. Starting from the existing main military aircraft configuration (transport and fighter/trainer), and taking into account the needs of wing ops centres systems and other ground systems support, objectives of the project are: • •

To analyse the new requirements (e.g. 4D, ASAS, etc.) the military datalink should be able to support To verify if and how the current military datalink (e.g. Link 16) are able to support the new aircraft functions

SJU DoW WP09 V4.0.doc

Page 91 of 143

â&#x20AC;˘ â&#x20AC;˘

Investigation of feasibility for using available Link 16 to support ATM functions through a ground interface to prove in-flight the Link 16 validity in supporting the military users in the new functions

The participation of the Military Users is expected.

SJU DoW WP09 V4.0.doc

Page 92 of 143

Description of Work 1.1.1.1 WA1 – Definition This activity will consist in the definition of the operational and technical assumptions used for the project, using as an input intermediate results of the operational WPs: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. The technical definition will consist in: • • • •

a high level functional requirement definition target aircraft architecture (meeting operational WPs requirements, on safety, performance, etc.) and initial safety analysis feasibility assessment on the use of Link 16 in terms of messages, protocol and security issues all type of transport aircraft requirements definition for datalink installation

Inputs: • Operational definition provided by operational WPs • Technical note - definition assumptions Short description of contribution • Aircraft architecture, evaluation impacts and system requirements • Contribution to feasibility assessment of Link16 (messages, protocol and security) • Feasibility assessment on the use of Link 16 in terms of messages, protocol and security issues • Datalink installation solution for military transport aircraft WA2 – Datalink Integration This work area will consist in: • • •

Implementing adaptations required to host the Link 16 on military transport aircraft Integration and installation of Link 16 on military transport aircraft for validation purpose Perform initial integration verification tests on ground (at bench and aircraft level)

Input: • Definition assumptions • Technical Validation Plan • operational scenario (operational WPs inputs) Short description of contribution • Link 16 model integration on military transport aircraft and initial verification • Adaptation of military transport aircraft to accommodate the Link 16 • Monitor definition assumptions

SJU DoW WP09 V4.0.doc

Page 93 of 143

WA3 – Technical Validation The technical validation will be made according to the operational validation objectives defined by the operational WPs and according to the identified validation infrastructure provided by WP 3. This work area will consist in: • •

Validation plan and scenarios definition Technical validation on military transport aircraft performing flight test before the subsequent operational validation (in charge of Ops work packages)

It is assumed the possibility to perform technical validation integrating the aircraft with ground systems (e.g. gateway). Input: • Link 16 integration readiness from WA2 • WP4 & WP5 operational scenarios • WP 15 Short description of contribution • Technical validation by means of flight trials assessments, results analysis and reports • Contribution to technical validation • Participation in trials and tests WA4 – Operational validation (to be transferred in ops WPs) Verify that in the SoS concept the Link 16 is a possible solution in guaranteeing the interoperability between the military and civil traffic. Related OI steps and system enablers OI: •

IS-0706: SWIM - European Air-Ground Communication Infrastructure [2016]

•

IS-0709: SWIM - Air-Ground extended services [2020]

•

AOM-0304: OAT Trajectories [2015]

•

CTE-C3 - Military datalink accommodation

EN:

Phasing 2011/2012: •

Prototype integration on ground rig and testing

•

Prototype installation on military transport aircraft and ground testing

•

Flight trials assessment and report

Deliverables

SJU DoW WP09 V4.0.doc

Page 94 of 143

• • • •

Definition Assumptions document for military transport and fighter/trainer Technical note - Technical Validation Plan Technical note - Technical Validation scenarios Technical note – Technical Validation Report

Risks • •

Security and datalink capability Antenna coupling

SJU DoW WP09 V4.0.doc

Page 95 of 143

SWP 9.21 ADS-B - 1090 Higher Performance Study SWP 9.21

Title: ADS-B - 1090 Higher Performance Study

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following knowledge areas are essential: • CNS Avionics, 1090 MHz Capacity Simulation Capability, Air-Air / Air-Ground Data-link technologies, Future ASAS Application Knowledge, Future Traffic Growth Estimates) Indicative work breakdown per co-financed contributors: Airborne Industries: 100% Concept & Objectives It is expected that future ATM applications will require additional ADS-B data such as flight path intent data. There is concern about 1090 MHz capacity in core Europe in the future. (See CASCADE PROGRAMME 1090 MHZ CAPACITY STUDY). The objective of this study is to identify and evaluate potential solutions or mitigations to the 1090 MHz capacity issue in order to meet the required effective update rate, surveillance range, and data capacity (i.e. ability to transmit more bits) required by ASAS applications. 1090 ES ADS-B In/Out will be deployed to support the introduction of these ASAS applications. ADS-B Out 1090 level of capability (accuracy, latency, integrity, etc.) linked to RAD, spacing and an upgrade to the standards will be required to support separation applications (e.g. ITP) Mode S transponder will be updated to support the implementation of 1090 ADS-B Out for air broadcast of aircraft position/vector: Performance of Navigation enablers to be addressed. The scope of work address 1090 Capacity Study for ADS-B Service with special attention on 1090 technology capacity on physical and datalink layer and avionics hardware implementation to address Minimum Operational Performance Standards. Description of Work Assessment of ADS-B 1090 capacity in support of ASAS applications surveillance range, minimum update rate, and data capacity requirements. Identify potential mitigating solutions. Attend RFG meetings to participate and represent the SESAR concept in these meetings. WA1 – Definition WA1 should identify requirements for additional performance and identify possible options to improve ADS-B 1090 capability. This work area will consist of the following: • Current Technical performance assessment • Real measurement of performance in current high density area/ simulation of future performance of current technique • Technical validation requirements • Definition of the validation strategy/program • Identify needs for higher performance, list the required additional performance with justification

SJU DoW WP09 V4.0.doc

Page 96 of 143

• • • • • • •

Identify constraining requirements on allowable mitigation – (are different or enhanced modulation techniques allowed) Identify coarse sizing requirements for amount of additional data and rates. Identify coarse surveillance range requirements and required update for future applications Attend RFG meetings to participate and represent the SESAR concept in these meetings Identify options to improve ADS-B 1090 performance Airborne improvements including higher update rate, dynamic power management, additional modulation scheme, others Ground improvements including measures to optimize/reduce pollution generated by other systems in high density area

Inputs: • Interim Interoperability Standards Definition (including Service Description) provided by WP4, WP6, WP8 and WP15 • Cross SESAR projects data exchange requirements. • WP9 Definition of Functional Requirements. • Interim results from Project 9.22 – Mid&Full ADS-B Capability • Interim results from WP15 Projects related Spectrum management • RFG performance requirements for different applications • Interim results from 9.5 ASAS ASPA, 9.6 ASAS ASEP. Short description of contribution • Mitigation technologies studies – Aircraft focused. • Functional specifications • Contribution to performance aspects of the definition • Perform current technical performance assessment, define ground based mitigation improving 1090 capability, attend RFG meeting to collect needs and represent SESAR • Contribution to feasibility study and architecture requirements WA2 – Functional analysis & modelling This work area will consist in : • Create model or update model which can be used to evaluation of the effectiveness of different mitigation techniques. • Evaluation of the impact to avionics for the different aircraft based mitigation techniques. Input: • • • • • •

Technology Study from WA1 Functional Specification from WA1 Interim results from Project 9.22 – Mid&Full ADS-B Capability Interim results from WP15 Projects related to Spectrum management Cooperation on model development to secure compatibility between Ground and Airborne models. Cooperation on model development to secure compatibility between Ground and Airborne models.

Short description of contribution • Define the impact to aircraft avionics (cost, architecture, etc) to implement the mitigation techniques.

SJU DoW WP09 V4.0.doc

Page 97 of 143

• • • •

Contribute to avionics impact Update 1090 MHz/Mode S Model. Define impact to ATSP to implement mitigation technique Participation in the evaluation of avionic impacts

WA3 – Simulator Integration & Validation • Use of the model developed in WA2 to simulate effectiveness of different 1090 MHz mitigation techniques Input: • • • • •

1090 MHz Utilization Model Traffic Density Projections Interim results from Project 9.22 – Mid&Full ADS-B Capability Coordination activities with Project 9.22 – Mid&Full ADS-B Capability Validation requirements from ASAS S&M, ATSA-ITP,.ASEP C&P and ASAS-SSEP Projects under WP4 & WP15.

Short description of contribution • Coordination of Simulator Integration & Validation • Coordinate report and scoring of different mitigation techniques. • Perform the simulation of the mitigation techniques WA4 – Evaluation Input: • Depending on the different mitigation techniques identified work on prototype evaluation • Coordination activities with Project 9.22 – Mid&Full ADS-B Capability Short description of contribution • Lab Prototype/Demo development • Contribute to performance and aircraft feasibility evaluation • Involvement in impact measurement campaign (ADS-B receiver performance, participation in analysis of impact on other systems ) • Participation of acceptability analysis at aircraft level Related OI steps and system enablers OI: •

IP2: IS-0707, IS-0302, IS-0303, IS-0501, AOM-0502, AOM-0501, AUO-0204, AUO0303, CM-0103, CM-0104, CM-0204, CM-0401, CM-0404, CM-0403, TS-0103, TS0106, CM-0601, CM-0602, CM-0701, TS-0105, AO-0204, AO-0206, AO-0205, AUO0604, AUO-0605, AO-0304,

•

CTE-S2a ADS-B In/Out 1090 (260) to Capability in support ATSAW, ITP (Step 2)·

•

CTE-S2b: ADS-B 1090 in/out (260A) to support full spacing e.g S&M (step3)·

•

CTE-S2c (ADS-B 1090 in/out (260A+) to support initial separation (step 4)

EN:

Phasing Transition activities onto following Mid&Full ADS-B Projects

SJU DoW WP09 V4.0.doc

Page 98 of 143

Deliverables

•

Functional specifications – Documentation and rationale of sizing requirements for intent and other future data. Also performance specification for the different mitigation techniques which were identified in the Technology Studies.

•

Technical Report describing effectiveness of different mitigation means

•

Technical Evaluation Report

Risks • •

IP issues with proposed 1090 MHz issues Complexity of Modeling requirements

SJU DoW WP09 V4.0.doc

Page 99 of 143

SWP 9.22 Mid & Full ADS-B Capability - Research SWP 9.22

Title: Mid & Full ADS-B Capability - Research

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • CNS Avionics, TP management, Tools for CD&R, Air-Air, Air-Ground Data-link technologies; Airborne & Ground Traffic Awareness systems and displays Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to provide research which results in high level functional, operational, system and performance requirements (integrity, accuracy, availability, continuity) of next generation of ADS-B Out datalink service to support future ATM services and applications (e.g. ATSAW, ASAS/aircraft self-separation, air-ground CD&R automation tools, Increase of data accuracy for traffic awareness systems) enabling 2020 SESAR concept and cover also transitional phases. There will be the corresponding implementation and introduction of functionality like update of traffic computer and display of surrounding traffic on a moving map, in order to support the implementation of 1090 ADS-B In to receive other aircraft position/vector/intent. It is anticipated that use of aircraft transmitted ADS-B Out data merged with information provided by a combination of Multi-lateration (MLAT) and/or Surface Movement Radar (SMR) will provide significant increase of position/vector accuracy for ground traffic monitoring systems and in combination with ADS-B In technology also enables longer range traffic awareness for Airborne listeners. Addition of adequate ADS-B In capability will also support future conflict detection and avoidance. Thus, an important additional value of Mid&Full ADS-B Out functionality is provision of aircraft intent for enhanced strategic/tactical de-conflicting and separation management tools which will be developed under related WP9 Projects (e.g. ASAS ASPA, ASAS ASEP, etc.) and WP15 Projects (e.g. ADS-B to support ATSAW, ASPA, ASEP, MLAT, etc.) driven by requirements from operational work packages WP4 and WP5. Initial research also includes contribution to Concept Definition in terms of Initial Technical Feasibility Study and Cost & Benefit Assessment. The scope of work address ADS-B Application with special attention on requirements of avionics software, data content and standardization activities connected with airborne ADS-B technology to address Minimum Aviation System Performance Standards. The solution should be applicable to General Aviation (which generally necessitates low cost/low power avionics) and Military Aircraft (which have specific avionics architecture and stringent legacy constraints). There will be two work lines. Mid-term ADS-B will address requirements on IP2 phase and Full ADS-B will address requirements on IP3. Despite different deployment target dates, the content of work is similar and complementary: • Gathering requirements on technology for desired ATM Service (e.g. ASAS S&M) in particular IP phase

SJU DoW WP09 V4.0.doc

Page 100 of 143

• •

Development of models for Airborne ADS-B Validation in context of appropriate Service Development of prototypes.

It is envisioned that R&D work described in WA1 and WA2 will be completed in first two years for both Mid-term and Full ADS-B Application. WA3 and WA4 is highly dependant on WP9/WP15 Simulation platform development and maturity of developed concept of SESAR ATM Services (e.g. ASAS ASAP, ASAS ASEP, ASAS SSEP) so Mid-term ADS-B application Validation and Evaluation and Full ADS-B Application can vary in Project time-scale Description of Work PHASE 1 WA1 – Definition of Mid-term and Full ADS-B Capabilities This work area will consist in exploration of envisioned future ATM applications which will rely on the usage of broadcasted aircraft state and intent data with enhanced accuracy. Under expressions aircraft state and intent data can be considered not only parameters currently included in ADS-B standards (e.g. DO-242A) but there can be also included further aircraft state parameters available (or planned for implementation) in avionics/buses (e.g. weight, accuracy of predicted trajectory, control modes, experienced turbulence). Gathered project requirements will serve as a baseline for the functional and technical requirements on future ADS-B technology or enhancement of current ADS-B applications and technologies. Special attention must be given on feasibility assessment of deployment terms for each functional or technical requirement. This includes suitable data link (in collaboration with WP15) that support both the ADS-B state and the intent information. This work should also consider the impact of the additional aircraft projects. This work will also use intermediate results of the mainly WP4, WP5, WP8 and WP15 definition phases and will be closely coupled with 9.5 ASAS ASPA, 9.6 ASAS ASEP Projects and Projects 15.2.4. The content of work will consist in: • Exploration of envisioned future ATM applications which expect enhanced surveillance. • Definition of high level functional requirements on ADS-B technology focused on application layer. • Identification of functional requirements also on lower layers (physical, data link, network and transport) and hardware equipment.European selection for 1090 MHz Extended Squitter as a preferred data link layer for ADS-B clearly indicates the reference solution for functional and technical requirements. • Definition of initial high level performance requirements. • Definition of possible added future requirements when aircraft intent data is included. Inputs: • Interim Interoperability Standards Definition (including Service Description) provided by WP4, WP6, WP8 and WP15 • Cross SESAR projects data exchange requirements. • WP9 Definition of Functional Requirements. Short description of contribution • Feasibility studies • Technology studies • System requirements • Contribution to capabilities and requirements • Definition of high level functional requirement & preliminary architecture specifications

SJU DoW WP09 V4.0.doc

Page 101 of 143

•

Participation on feasibility studies and architecture specification

WA2 – Functional analysis & modeling This work area will consist in : • Development of functional diagrams, definition of key inputs/systems to ADS-B. • Assessment of functions in relationship with 1090 MHz Extended Squitter technology and potential development of new communication methods/links which better fit to the technology concept. • Development of function models of essential ADS-B services. • Development of simulation frame suitable for ADS-B function models integration. • (Mid-term) Cooperation on model development to secure compatibility between Ground and Airborne models (15.4.5 – Ground System Enhancement for ADS-B). • (Full ADS-B) Cooperation on model development to secure compatibility between Ground and Airborne models (15.2.4). Input: • Validation concept from WP3 and WP9. • Validation platform definition for WP9. • Interim results from WP15 Projects related to ADS-B. Short description of contribution • Functional analysis & diagrams • Technical feasibility & readiness assessment. • Preliminary technical validation requirements • Definition of the validation strategy/program • Functional modelling and simulation • Contribution to technical validation requirements WA3 – Simulator Integration & Validation This work area will consist in: • (Mid-term) ADS-B module integration activities into WP9 Validation platform in particular focus on support ATSAW, ASAS S&M and ATSA-ITP applications. • (Full-ADS-B) ADS-B module integration activities into WP9 Validation platform in particular focus on support ASEP C&P and ASAS-SSEP applications. • Gathering of requirements for integration into Validation platforms outside of WP9. • Validation of ADS-B module in simulated environment. It will consider Mainline, General Aviation and Military users. Input: • • • • • •

Technical Validation Plan WP9 operational scenario Definition of Airborne Sub-System Demonstrator (Mid-term) Validation requirements from ASAS S&M and ATSA-ITP Projects. (Full-ADS-B) Validation requirements from ASEP C&P and ASAS-SSEP Projects. Interim results from WP15 Projects related to ADS-B

Short description of contribution • Coordination of Simulator Integration & Validation

SJU DoW WP09 V4.0.doc

Page 102 of 143

• •

Support to validation in simulated environment Participation in module integration into simulator and relevant validation

WA4 – Evaluation This work area will consist in: • Evaluation of ADS-B Initial Performance requirements. • Evaluation of functional requirements. • Cost & Benefit Assessment Input: • Experimental design for Evaluation phase. • Evaluation strategy. Short description of contribution • Coordination of evaluation results • Contribution to evaluation • Contribution to functional & performance evaluation • Participation in functional requirements evaluation and cost-benefit analysis PHASE 2 •

(Optionally) Analysis of further ADS-B Application requirements (e.g. Air-Air Coordination purposes) on second ADS-B datalink

•

Flight Tests

Related OI Steps and System Enablers OI: •

•

IP3: IS-0709, IS-0710, AOM-0503, SDM-0202, CM-0501, CM-0604, CM-0702, AUO0504, CM-0704, CM-0804, CM-0805

•

CTE-S2a ADS-B In/Out 1090 (260) to Capability in support ATSAW, ITP (Step 2)·

•

CTE-S2b: ADS-B 1090 in/out (260A) to support full spacing e.g S&M (step3)·

•

CTE-S2c (ADS-B 1090 in/out (260A+) to support initial separation (step 4)

EN:

Deliverables

SJU DoW WP09 V4.0.doc

Page 103 of 143

PHASE 1 • System requirements for Mid-term and Full ADS-B capability • Initial high level performance requirements for Mid-term and Full ADS-B capability • Preliminary architecture specifications for Mid-term and Full ADS-B capability • Preliminary safety assessment for Mid-term and Full ADS-B capability • Functional analysis for Mid-term and Full ADS-B capability. • Technical Validation Plan • • Technical Validation Report • Cost & Benefit Assessment Risks •

A lack of clear definition of data exchange requirements for 2020+ envisioned ATM solutions.

SJU DoW WP09 V4.0.doc

Page 104 of 143

SWP 9.24 ADS-B In/Out for military aircraft SWP 9.24

Title: ADS-B In/Out for military aircraft

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise in the following knowledge areas are essential: • Military avionic manufacturers (e.g. Military datalink, Surveillance systems such IFF & ADS-B In&Out) • Military aircraft flight deck integrator (e.g. impacts on the current aircraft architectures and relevant cockpit systems) • Military operations on the civil airspace • Military users Indicative work breakdown per co-financed contributors: Airborne Industries: 100% Concept & Objectives To implement the new SESAR functions in a military aircraft implies a number of technology enabler that will allow to the aircraft to be a passive and active node of the network sharing all the required information needed to perform the developed operational concepts. In order to comply with these new needs, it is essential to explore if the existing military aircraft can be equipped with new technology able to assure these new performances and maintaining at the meantime the capability to interoperate with the civil aircraft in a collaborative approach. Since the wide differences between the current military aircrafts (transport, fighter, trainer, etc.) in terms of architectures, and considering also the stringent legacy constraints, different tradeoff need to be considered in order to find the appropriate solution that can accommodate different specific needs not necessarily common. Starting from the existing main military aircraft configuration (transport and fighter/trainer), and taking into account the needs of operational WPs requirements, wing ops centres systems and other ground systems support, objectives of the project are: • • • • • •

To analyse the new requirements that ADS-B In&Out (1090 ES) should be able to support To define HMI requirements for ADS-B In&Out To define the use of ADS-B In&Out operational/non operational military environment. To define military transport aircraft new avionics architecture required for ADS-B In&Out. To integrate the ADS-B In&Out into a military transport aircraft. To validate for military transport aircraft the new functions by means of flight trial assessments

The participation of the Military Users is expected.

SJU DoW WP09 V4.0.doc

Page 105 of 143

Description of Work WA1 – Definition This activity will consist in the definition of the operational and technical assumptions used for the project, using as an input intermediate results of the operational WPs: mainly operational assumptions and end-to-end safety analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae MOPS) so as to expedite standardization activities using validation results. The technical definition will consist in: • • • •

a high level functional and HMI requirement definition, target aircraft architecture (meeting operational requirements, on safety, performance, etc.) and initial safety analysis preliminary feasibility study for ADS-B In&Out military aircraft installation ADS-B In/out Installation solution identification & HMI adaptation

Inputs: • Operational concept and scenarios for initial 4D provided by WP 4 & 5 • ATC Operational requirements applicable to military aircraft provided by WP 4 & 5 • Ground System requirements applicable to military aircraft provided by WP10 & 15 Short description of contribution • • • •

Architecture, impact analysis and system requirements ADS-B In&Out installation solution definition ADS-B In&Out HMI adaptation selection of appropriate military airframes and military for the validation of proposed solution

WA2 – ADS-B In/out Integration and adaptation This work area will consist in: • • • •

Adaptation of military transport aircraft to host existing ADS-B in&out Adaptation of HMI to manage the ADS-B In/out info The integration and installation of existing ADS-B in&out on military transport aircraft Perform initial integration verification tests on ground (in the bench and in the aircraft)

Input: • Definition assumptions • Technical Validation Plan • operational scenario (operational WPs inputs) Short description of contribution • •

ADS-B In&Out model integration on military transport aircraft Contribution to ADS-B In/out integration into military transport aircraft

WA3 – Technical Validation

SJU DoW WP09 V4.0.doc

Page 106 of 143

The technical validation will be made according to the operational validation objectives defined by the operational WPs and according to the identified validation infrastructure provided by WP 3. For existing ADS-B In&Out, this work area will consist in: • •

Validation plan and scenarios definition Technical validation on military transport aircraft performing flight test before the subsequent operational validation (in charge of Ops work packages)

It is assumed the possibility to perform technical validation integrating the aircraft with ground systems. Input: • ADS-B In/out readiness from WA2 • WP4 & WP5 operational scenarios • WP 15 Short description of contribution • •

Technical validation on military transport aircraft by means of flight trials assessments, results analysis and report Contribution to operational validation

WA4 – Operational validation (to be transferred in ops WPs) Verify that in the SoS concept existing ADS-B can really assist the military users in guaranteeing the interoperability between the military and civil traffic. Related OI steps and system enablers OI: •

IS-0203, TS-0102, TS-0201, AUO-0401, AUO-0402, AO-0201, AOM-0206, AOM-0804

•

MIL-0203, MIL-0601, A/C-49

EN:

Deliverables • • •

Technical note - definition of assumptions document for military transport and fighter/trainer. Technical note - Technical Validation Plan Technical note – Technical Validation Report

SJU DoW WP09 V4.0.doc

Page 107 of 143

SWP 9.27 Multi-constellation GNSS Airborne Navigation Systems SWP 9.27

Title: Multi-constellation GNSS Airborne Navigation Systems

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Definition, design, development of GNSS receivers • Definition design development of low cost based MEMS inertial navigation systems • Architecture and design of A/C Navigation systems • Knowledge in navigation systems regulations and certification rules • GNSS integrity techniques (ABAS RAIM, ABAS INS) • Definition of GNSS standards • GNSS Antenna definition, design, development Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The overall objective of the WP 9 projects dedicated to Multi-constellation GNSS navigation systems is to support and speed up the transition to future GNSS based navigation systems (Galileo, modernized GPS, combination with Low cost-Low grade inertial systems ) The typical time schedule foreseen for this transition is • Short term 2015: first operational benefits from Galileo (OS/SOL) combined with GPS L1/SBAS • Long term 2015 -2020: Galileo SOL +GPS L1, L5 / SBAS full operational benefit + Low cost MEMS Based INS The WP 9 project 27 technical objectives are: • To develop and provide the foreseen definitions and operational use of future GNSS multi constellation equipment (all platforms) so that to support the key decisions on the transition plan. • To support the promotion and recognition of these definitions more particularly within the standardisation and certification bodies • To progress on the key technologies (Multi constellation GNSS receivers, GNSS Low cost low grade inertial) needed and start prototyping activities as well validation activities supporting the foreseen definition. • To develop and test a multi-constellation multi-frequency GNSS receiver to facilitate to the use of future GNSS constellations in business and general aviation (BGA). These platforms have a different architecture affecting the GNSS receiver solution. Furthermore, for general aviation the cost is a critical aspect. To mitigate this, different class of GNSS receiver (different concept of operation) may need to be standardized for BGA. For the military the integration of precise signals services has to be studied These activities described above have to be performed in liaison with WP15 related projects.

SJU DoW WP09 V4.0.doc

Page 108 of 143

The WP 9.27 project activities are organized in three phases: Phase 1: Multi GNSS receiver definition phase and prototyping, initial technical and technological activities on GNSS low cost low grade inertial including early IRS /GPS prototyping â&#x20AC;˘ Phase 2 : extend the GNSS receiver capability preparing it for use with additional signals (e.g. Galileo); and continue on GNSS low cost techniques and technologies (e.g. MEMS sensors) Phase 3 : Final activities on Multi GNSS receiver including flight trials validation, main activity on GNSS low cost low grade inertial with prototyping and flight tests evaluation Description of Work

SJU DoW WP09 V4.0.doc

Page 109 of 143

PHASE 1 WA1 - Definition WA1.1 - Concept of operations and combinations techniques One of the first issues to investigate shall be the definition of the combination rules for aviation operations of the multiple GNSS signals and constellations that will be available in liaison with Project 15.3.4 "GNSS baseline study" and with Project 15.3.5 "Enhanced SBAS – GNSS" Definition Study. The targeted result is an associated concept of operations. WA1.2 - ABAS/INS GNSS In parallel optimisation of navigation avionics taking into account future GNSS and the progress in low cost inertial technologies shall be assessed WA1.3 - MCR definition Then receiver architecture, definition and preliminary design complying with the requirements shall be assessed for all platforms. The main objective of this work area is to define: • RF hardware performance specifications for multiple frequency and multiple modulation processing for Galileo and GPS and associated SBAS constellations (EGNOS, WAAS, MSAS etc) •

Implications of WP9.0 and WP3 for prototype receiver concept

In coordination with EUROCAE WG-62 GPS/Galileo ad-hoc group determine potential benefits of available open service signals (L1, L5, E1, E5a, E5b), SBAS services, and Regional Corrections and select candidate combinations for GA.

WA1.4 - Definition and preliminary design of a multi-constellations GNSS antenna WA1.5 - Support to standards In parallel of all the previous activities the WA1 should include a support to the development of the GNSS new regulations, certification rules and standards

WA2 - Key techniques & technologies Based on the requirements and definitions from WA1 and on Project 15.3.4 "GNSS baseline study" and Project 15.3.5 "Enhanced SBAS – GNSS" Definition Study, this wok package will investigate the key techniques and technologies driving the future development and the transition strategy to low cost GNSS and GNSS-INS based navigation.. The major topics to be addressed shall be: WA2.1 - Integrity for multi constellations receivers WA2.1.1 Mainline WA2.1.2 Business/General Aviation •

GA integrity requirements for non-precision and precision approaches

•

GA availability, accuracy and timing requirements for ADS-B position reporting

SJU DoW WP09 V4.0.doc

Page 110 of 143

•

GA HMI / failure modes for PVT reporting in all modes

WA2.2 - Integrity for multi constellations GNSS/INS systems WA2.2.1 Mainline WA2.2.2 Business/General Aviation WA2.3 - Robustness to radio frequency interference WA2.4 - Low cost technologies for future receivers and antenna WA2.5 - Low cost INS (MEMS) for future GNSS/INS hybrid systems WA3 - Prototyping WA3.1 - MCR mock-up The objective is to consolidate receiver definition, the technical feasibility and the expected performance through mock up and lab testing It is assumed that the partners contributing have already internal predevelopment / mock up activities on future GNSS receivers so that prototyping in the frame of this project can be optimised. WA3.1.1 Mainline The mock up shall be able to process GPS and GALILEO (OS signals) signals for performance evaluation with GNSS simulator) in simulated typical civil aviation mission (dynamic and radio frequency I environment). It should also be compatible with further extension to SOL service in the next phase of the project. WA3.1.2 Business/General Aviation • Algorithm refinement aimed at GA • Software and VHDL design for lab mockup: design of the system prototype to test and validate traditional and innovative methodological approaches • Lab system prototype testing and stressing through processing of huge amount of heterogeneous data in order to assess real-time performances and reliability capabilities WA3.2 - GPS ABS/INS mock-up The objective is to develop and test in lab a GPS ABAS /INS mock-up for further in flight evaluation of enhanced integrity techniques in a next step of the project . The operational target is to provide APV with INS/GPS PHASE 2 • To extend the GNSS receiver mock up capability, validate new functions in laboratory and prepare first flight trials planned in phase 3 as soon as Galileo signals will be available. • To follow on activities on low cost GPS/low grade INS equipment and ABAS GNSS/INS techniques to consolidate feasibility, foreseen benefits and to prepare 9.27 phase 3 where GNSS low cost low grade prototyping is planned • Evaluation of candidate (new types of) sensors for intertial replacements to be used in the design of low-cost integrated GNSS/INS solutions required for BGA platform.

SJU DoW WP09 V4.0.doc

Page 111 of 143

•

To launch activities preparing longer term Galileo and GPS/Galileo applications (new functions and support)

PHASE 3 To flight test the Multi GNSS receiver with real GALILEO /GPS signals for applicable platforms To support the transition to GNSS Low cost low grade inertial systems through: Design and validation through simulations and critical mock up of the future system architecture based on multi constellation GNSS, Low cost MEMS, GNSS/INS sensor fusion algorithms) GNSS/MEMS INS prototype development and testing (laboratory and flight tests). To follow on activities on GALILEO and GPS/GALILEO receivers future extensions Related OI Steps and System Enablers EN: •

A/C-01 - Enhanced positioning on the airport surface and in flight (SBAS)

•

A/C-02 - Enhanced positioning on the airport surface and in flight (Galileo, GPS L5)

•

CTE-N1a,CTE-N1b,CTE-N2,CTE-N3a,CTE-N3b,CTE-N3c Multi constellation GNSS ABAS - / INS - / RAIM

Deliverables PHASE 1 • Report on future GNSS receivers providing major requirements for future receivers, concept of operational use, GNSS based avionics systems and GNSS receiver architecture, preliminary standards • Report on key techniques and technologies with performance assessment (simulations results) of multi constellation receivers and recommendations for prototyping • Report on ABAS/GPS enhanced techniques for APV (receiver performance assessment through preliminary mock-up and lab tests) Risks •

Lack of maturity in Galileo signals definition during the project.

SJU DoW WP09 V4.0.doc

Page 112 of 143

SWP 9.28 Enhanced Vision (Head Down and Head Up) Solutions SWP 9.28

Title: Enhanced Vision (Head Down and Head Up) Solutions

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise”. Specific expertise: •

Sensors (esp. infrared and millimetre wave), Sensor integration, Human Factors, Systems Engineering, Display Hardware, Graphics Processing, Flight Deck Design

Indicative work breakdown per co-financed contributors: •

Airborne Industries: 100%

Concept & Objectives The objective of this work is to develop head-up and head-down Enhanced and Synthetic Vision System (ESVS) concepts to enable more efficient approach, landing and taxi operations in conditions of low visibility. This is applicable to all platforms and even if mainlines platforms have auto land capabilities to facilitate approaches in low visibility conditions; they have no capabilities to facilitate taxi and take in order to maintain airport capacity. The initial goal is to develop new Synthetic Vision (Head Down Display) and Enhanced vision (Head Up Displays) concepts that will be used to estimate the expected benefits on airport capacity in order to provide elements for a decision gate before undertaking any prototyping development The graphic concepts that will be used integrate visualizations based on correlation of enhanced vision sensor and database information. This EPIC platform will be used as the basis for the BGA validation but other prototyping tools might be required for other platforms. Whilst the operational flight safety benefits are an important aspect of ESVS systems, it is mainly the operational efficiency aspects that will be scrutinized in this program, e.g., landing, taxi and take-off in low RVR conditions. The EVS sensor selection activity work should be common to both the HDD and HUD solutions. The candidates for enhancement of HDD and HUD data will cover: infrared, millimeter wave radar-based and/or LIDAR enhanced vision sensor information. The perimeter of the study includes the sensors, data bases, data link, display hardware, symbology overlay, and human factors concepts that will demonstrate the system value for more efficient approach, landing and taxi operations in conditions of low visibility. Since it is not yet clear if such a solution will bring a real benefit, a business case evaluation will provide element for a decision gate before undertaking any prototyping development. Description of Work Work will start by defining high level concepts (solutions) to validate the operational and technical assumptions used for the project, using as an inputs intermediate results from WP5 and WP6 project. This will also allow confirming the high value proposition of ESVS to increase the airport capacity in bad weather condition. The next step will be the evaluation of sensors, AIS data, display hardware, graphics processors, data base technology, and graphical user interface concepts, available for

SJU DoW WP09 V4.0.doc

Page 113 of 143

improved ESVS display, both head up and head down related to operations in low visibility conditions. The objective would be to define the best suitability of technologies for low visibility and bad weather conditions. Issues related to the allocation of information across displays will be addressed by developing and evaluating different information allocation and information flow concepts that blend forward and top-down views of synthetic vision information. This work will also evaluate existing database (ED98, ED99) to check the availability of data to generate appropriate information for ESVS concept and how they could be enhanced by use of AIS or other data link sources. Partners involved in this project will actively participate in industry standardization working groups. PHASE 1

WA1 – Requirements Analysis This work area will consist of requirements definition and technical assumptions used for the project: • Concept definition and analysis of achievable traffic increase (value function) by enhancing HDD and HUD solutions and combining non precision solutions (e.g. SBAS) • Operational requirements analysis • Functional requirements analysis • System requirements analysis • participation in industry working group (EUROCAE-WG-79 / RTCA SC-213) Inputs: • Operational definition (potentially draft versions initially) provided by WP4,5, 6 • Requirements from industry working groups Short description of contribution • Support for analysis of achievable traffic increase by ESVS augmentation • Requirements analysis • Functional requirements and system requirements definition Participation to standardization working group • Business case establishment to provide elements of decision for undertaking activities beyond WA1. WA2 – Technologies evaluations Database evaluations This work area will consist on evaluations of existing database (ED98, ED99) to define the best suitability of database content with operational and functional needs. Enhancement of data base using AIS or data link will be considered as well. Participation to working group EUROCAE-WG-44 / RTCA SC-193 Sensors evaluations This work area will consist on evaluations of different sensor technologies (infrared, millimetre wave or LIDAR) in different conditions of use (visibility and weather). The characterization of the different sensors will conduct to define the best suitability of sensors technologies to low

SJU DoW WP09 V4.0.doc

Page 114 of 143

visibility and bad weather conditions. This selection should be common to HDD and HUD solutions. Short description of contribution • ESVS technology evaluations • Evaluation of database content according to functional requirements • Evaluations of AIS capability for data base enhancement • Evaluation of different sensors technologies to define minimum characteristics and performances for each technology according to visibility and weather conditions. WA3 – Initial Enhanced Visions Head Down and Head Up Systems Design Definition This work area will consist of the initial enhanced system design definition including both HMI definition and a system definition. Input: • Report from WA1 - Operational, functional and systems requirements documentation and WA2 – Report on sensors evaluations & report on databases evaluations Short description of contribution • Initial system design definition including HMI for both HDD (ESVS) and HUD (EVS) solutions • System design definition including HMI requirements definition (HDD & HUD) PHASE 2 WA4 – Initial ESVS (HDD & HUD) Prototype Development This work will develop and evaluate an infrared, millimeter wave radar-based and/or LIDAR EVS head-up and/or head-down display. The development will include the sensor and sensor integration (and sensor fusion as appropriate), AIS/data link integration with data base, display hardware, graphics processing, and flight symbology. The evaluation will include pilot performance and efficiency measures related to a variety of scenarios for low visibility operations. This will provide real time/hardware in the loop validation of airport capacity improvement. Validation plan, scenario and reports will be provided. Related OI steps and system enablers OI: • EN: • • •

AUO-0403 - Enhanced Vision for the Pilot in Low Visibility Conditions

A/C 22 - Enhanced vision of terrain on head up display in low visibility conditions A/C 23 – Synthetic vision on head down and up in low visibility conditions CTE-N9a - HUD/EVS

Deliverables

SJU DoW WP09 V4.0.doc

Page 115 of 143

PHASE 1 • •

High level operational, functional and systems requirements documentation. Initial ESVS System Design Definition

•

Initial EVS System Design Definition

•

Requirements definition for data base and data link (AIS) used for enhancement.

•

Requirements definition for sensors and sensor-related characteristics of airport objects (lights, paint reflectivity, etc.) to be detected.

PHASE 2 •

Technical validation plans for ESVS

• •

Technical validation scenario Technical validation report

SJU DoW WP09 V4.0.doc

Page 116 of 143

SWP 9.29 Enhanced & Synthetic Vision SWP 9.29

Title: Enhanced & Synthetic Vision

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise”. Specific expertise: Human Factors and Cognitive/Perceptual Psychology, Display algorithms and computational processing, Operations Research, Systems Engineering, Graphics Processing, Data bases, Display Hardware, Flight Deck Design, Sensors (e.g., Infrared, millimetre wave and LIDAR), Sensor integration Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of this work is to develop head-up and head-down Enhanced and Synthetic Vision System (ESVS) concepts that enable more efficient approach and landing operations in conditions of low visibility. The goal is to develop new ESVS graphic concepts that integrate graphic visualizations based on correlation of enhanced vision sensor and database information. This EPIC platform will be used as the basis for the program. Whilst the operational flight safety benefits are an important aspect of ESVS systems, it is only the operational efficiency aspects that will be scrutinized in this program, e.g., landing with lower minima in low visibility conditions. The EVS sensor selection work should be coordinated with WP 9.28 EVS. Technology link with remote tower development investigated un WP12.4.10 “Remotely Operated Tower Computer Augmented Dynamic Vision” should be used for business case development. Since it is not yet clear if such a solution will bring a real benefit, a business case evaluation will provide element for a decision gate before undertaking any prototyping development Description of Work Development and evaluation of display hardware, graphics processors, data base technology, and graphical user interface concepts, for improved ESVS display, both head up and head down related to operations in low visibility conditions. Issues related to the allocation of this information across displays will be addressed by developing and evaluating different information allocation and information flow concepts that blend forward and top-down views of synthetic vision information. Another work area will consist of the definition of the operational and technical assumptions used for the project, using as an inputs intermediate results WP5 and WP6 project. This work will also evaluate existing database (ED98, ED99) to check the availability of data to generate appropriate information for ESVS concept and evaluate sensors technologies

SJU DoW WP09 V4.0.doc

Page 117 of 143

(infrared, millimetre wave, LIDAR) in all weather conditions to define the best suitability of technologies to visibility and weather conditions. Partners involved in this project will actively participate in industry standardization working groups. PHASE 1 WA1 – Requirements Analysis and business case establishment This work area will consist of requirements definition and technical assumptions used for the project: • Operational requirements analysis • Functional requirements analysis • System requirements analysis • Analysis of achievable traffic increase by combining non precision solutions (e.g. SBAS) with ESVS augmentation • participation in industry working group (EUROCAE-WG-79 / RTCA SC-213) Inputs: • Operational definition (potentially draft versions initially) provided by WP4,5, 6 • Requirements from industry working groups Short description of contribution • Requirements analysis • Functional requirements and system requirements definition Participation to standardization working group • Support for analysis of achievable traffic increase by ESVS augmentation • Business case establishment to provide elements of decision for undertaking activities beyond WA1 This point of the project will consist in a decision gate. WA2 – Technologies evaluations Database evaluations This work area will consist on evaluations of existing database (ED98, ED99) to define the best suitability of database content with operational and functional needs. Participation to working group EUROCAE-WG-44 / RTCA SC-193 Sensors evaluations This work area will consist on evaluations of different sensor technologies (infrared, millimetre wave or LIDAR) in different conditions of use (visibility and weather). The characterization of the different sensors will conduct to define the best suitability of sensors technologies to visibility and weather conditions. The EVS sensor selection work should be coordinated with WP 9.28 EVS. Short description of contribution • ESVS technology evaluations • Evaluation of database content according to functional requirements

SJU DoW WP09 V4.0.doc

Page 118 of 143

•

Evaluation of different sensors technologies to define minimum characteristics and performances for each technology according to visibility and weather conditions.

WA3 – Initial ESVS System Design Definition This work area will consist of the initial ESVS system design definition including both HMI definition and a system definition. Input: • Report from WA1 - Operational, functional and systems requirements documentation and WA2 – Report on sensors evaluations & report on databases evaluations Short description of contribution • Initial system design definition including HMI • System design definition including HMI requirements definition PHASE 2 WA4 – Initial ESVS Prototype Development (NOTE: Consider moving all or part of this WA into 2009-2011 timeframe) This work area will consist of developing the ESVS system prototype. Some iteration of the prototype is expected as it matures and feedback is provided from the initial reviews of appropriate stakeholders. Assume that development and demonstration of concepts is on a fixed-based simulator (e.g. Honeywell TRACS) and limited flight tests with a live sensor on a EPIC platform with PC test equipment in support. WA5 – ESVS System and Operational Validation The work will focus on a pilot-in-the-loop operational validation of the ESVS system. The potential capacity increase will be analyzed.

Related OI steps and system enablers OI: • EN: •

AUO-0403 - Enhanced Vision for the Pilot in Low Visibility Conditions

A/C-23 - Synthetic vision on head up display in low visibility conditions

Deliverables PHASE 1 •

Operational, functional and systems requirements documentation

•

Initial ESVS System Design Definition

SJU DoW WP09 V4.0.doc

Page 119 of 143

SWP 9.30 Weather Hazards / Wake Vortex Sensor SWP 9.30

Title: Weather Hazards / Wake Vortex Sensor

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Knowledge and background on physical vortex phenomenon (vortex aerodynamic) • Airborne LIDAR technology, both I-R and U-V, continuous and pulsed • Aircraft reaction to vortex encounter, and possible mitigation actions • Aircraft flight controls • Airborne electro-optic equipment. Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives Concept Future on-board surveillance systems may include dedicated wake encounter avoidance functions. This aims at considerably reducing the risk of severe upsets due to wake vortices and may lead to reduced wake turbulence separation requirements. It is an enabler for reduced separation operations during all phases of flight, specifically taking into account new operational concepts under study within SESAR. To mitigate the effects of inadvertent wake vortex encounters a forward-looking LiDAR sensor is envisaged that allows tailored wake upset alleviation by directed flight control activity. Relevant experience with LiDAR systems has been gathered in ALEV, ALEV3, DALHEC, DALAS, NESLIE and DALEV. An airborne LiDAR sensor (UV) was flight tested in the AWIATOR project. Use of LiDAR information for wake vortex detection and characterisation has been studied in the previous EC research projects FLAME, M-FLAME, I-WAKE and FLYSAFE. Objectives The objective of the project is to define the technologies and the architecture of a system capable of both detecting the presence of wake vortices on the trajectory of the aircraft, and measuring sufficient information to enable the flight control system of the aircraft to react safely when it enters a wake vortex. The specific objectives of this work package are to: •

Define and characterise the relevant wake vortex disturbance to be taken into account.

•

Create a real-time simulation model of a LIDAR sensor with data processing.

•

Study different F/CTL wake alleviation strategies in dedicated simulations.

•

Derive sensor requirements and define applicable sensor technologies.

•

Initiate design of selected sensor technology.

SJU DoW WP09 V4.0.doc

Page 120 of 143

Description of Work PHASE 1 WA1 Wake Vortex models Define the wake vortex characteristics which can impact modern aircraft safety, assuming flight control performance (velocity distribution, and their evolution with time) WA2 Parametric sensor model for flight simulation Create a simulation model of forward looking LiDAR systems including wake characterisation with and without input from wake vortex prediction models WA3 Alleviation of wake effects by flight control Study different flight control wake alleviation strategies as well as different sensor capabilities and strategies in simulated wake encounters. WA4 Sensors requirements & technology selection Define from previous steps the sensors requirements: velocity components to be measured, measurement volume, spatial and time resolution, notice time, accuracy, integrity and reliability, installation constraint, integration with aircraft system. Identify and select the most promising concept for further evaluation. WA5 Sensor preliminary design Define the architecture and the pieces of equipment of the projected sensor and of the demonstrator which will be assembled and tested in step 2, and provide a performance assessment PHASE 2 •

First prototyping, lab tests and in flight tests

•

Evaluation of medium range wake detection and avoidance

•

Addition of prediction/reaction (TBC)

Related OI Steps and System Enablers

SJU DoW WP09 V4.0.doc

Page 121 of 143

OI:

•

AO-0303 - Fixed Reduced Separations based on Wake Vortex Prediction AO-0304 - Dynamic Adjustment of Separations based on Real-Time Detection of Wake Vortex AUO-0504 -Self-Adjustment of Spacing Depending on Wake Vortices

• • • •

A/C-08 - Flight management and guidance to perform wake-vortex free approach A/C-30 - Onboard detection of wake-vortices for use as safety net CTE-S8a - Airborne wake vortex detection CTE-S8b - Airborne wake vortex detection (Higher performance)

• •

EN:

Deliverables PHASE 1 •

Technical report on wake vortex alleviation by flight control

•

Technical report on Wake vortex sensor design and specification .

SJU DoW WP09 V4.0.doc

Page 122 of 143

SWP 9.31 Aeronautical databases SWP 9.31

Title: Aeronautical databases

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Procedure design (PANS OPS, IFPP) • Operational deployment of aeronautical database : ANSP/procedure designers/AIS • Database providers. • Avionics Flight Management System • Airport navigation manufacturers Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives At the operational level (through operational work package activity) : • Develop necessary draft material for ICAO PANS OPS to ensure that designed procedures are compatible with aircraft behavior, capabilities, performance and onboard definitions; coordinate with IFPP in order to ensure data consistency between ground and airborne sides. • At the ATC level this will improve trajectory predictability ensuring consistency between ground (ATC) and air (FMS) trajectories. • At an investment level, reduce cost o of Flight Management and Airport Navigation systems development. o of airlines data acquisition The operational activity and work should attain non-equivocal interpretation of aircraft behavior and definition of the trajectory. The finality being database coding (structure and content), and on a longer term to generate benefit of standardisation for avionics systems (e.g. through AIXM deployment). For the navigation database: data coding (legs, etc…) that may be integrated in the ARINC 424 & 829 standards. Air – Ground coding harmonization to make the predictions easier For the Terrain & Obstacle database: Promote an embedded format based on ARINC 816 example taking credit of existing standards for user requirements for Terrain & Obstacle DB (EUROCAE ED98A / RTCA DO276A) For all databases: • Prepare future systems to take EUROCAE/RTCA AIS-MET Datalink operational context into account. • Develop necessary draft material for ICAO PANS OPS to ensure that procedures are designed that are compatible with the RNAV capability • Harmonize Airport & Navigation Database for future gate2gate applications. • Ensure adequacy of targeted formats with concept of DB centralize server that will host

SJU DoW WP09 V4.0.doc

Page 123 of 143

these DBs. Particularly, protocol, requests and performances aspects shall be carefully assessed. Description of Work WA0 - Collect requirements This work area will consist in the gathering of the requirements that will be used for the definition WA. The project 9.31 will be focused on static data inter alia airport, navigation, meteorological. For each type of data, requirements will be collected such as the updates, integrity, the required degree of consistency, confidence, liability among the ground and airborne users, the safety requirements and the security requirements. All these requirements will be considered by taking in account the whole chain from each actual data producers to each actual or potential end-users. These requirements will be translated into definitions, exchange formats or other standardizations for use in the following WAs." WA1 – Definition This work area will consist in the definition of the operational and overall technical assumptions used for the project. This work will use inputs from the operational WP counterpart project on air and ground trajectory and terrain definitions. This work area will consist in : For Flight Management and trajectory related data : • At ensuring operational commonality and consistency of ground-ATC / airborne-FMSdata and behaviour. This should avoid any ATC/FMS misinterpretation, limit the complexity, and therefore increase safety. • At the aircraft level, Definition of the embedded format(s) in the frame of ARINC subcommittee ARINC 424 / ARINC 829, and link should also be made with ARINC 702A trajectory format. For Airport Navigation-related data : • Specify ARINC 816 modifications to take into account functional changes of Airport Navigation Function and impacts of digital NOTAM / Datalink. • At the aircraft level, ensure that ARINC 816 evolutions guarantee the consistency between navigation and airport databases. For global Database management process (from ground to FMS, Airport Navigation and other potential on-board System requiring data) : • Definition of Database production chains, including for instance data sourcing, Database packing and verification, certification. • Participation in EUROCAE/RTCA AIS-MET Datalink working group to ensure a technically and industrially feasible implementation. • Ensuring the developments are coordinated with IFPP Inputs: • Definition assumptions • Procedures design rules compatible with aircraft behaviour Short description of contribution • Work with other operational WP counterparts to capture the need and study feasibility • Contribution to definition

SJU DoW WP09 V4.0.doc

Page 124 of 143

• • • •

•

Participate to ARINC 816, ARINC 829, AIS Datalink Working groups Define Database production chains with relevant partners Contribution to definition and standards. Preparation of papers for IFPP to ensure the implications of proposed developments on PANS OPS are reviewed and to identify issues which need to be reflected back into WA 1. Participation in the definition of standards for navigation databases and data exchange

WA2 – System Validation WA2.1 – Mainline aircraft 2.1.1– Prototype & Tools Development This work area will consist in : • Development of the data production chains from the procedure design office to the operational databases dedicated to the new procedures coding and the new formats. • Development / upgrade both the ATC module and the impacted on-board Systems/Functions (Flight Management, Airport Navigation, …) of the simulated environment to take the new procedure, new formats and AIS / Datalink services into account. • Validating the whole Database production process, AIS Datalink services and use by the on-board Systems. • Ensure compatibility of both air and ground systems with the candidates AIS/DL services. • Ensure compatibility of PANS OPS with the RNAV performance capability services Input: • Definition assumptions Short description of contribution • Development of the database production chains • Development / upgrade of the modules • Contribution to DB chain requirements • Development of draft amendments to PANS-OPS and (if necessary) Annex 15. Through ICAO IFPP and RNPSORSG seek to ensure global harmonisation of RNAV Procedure definitions with the data standards. • Development of support tools to ensure that procedure design software is compatible with the new data production chain 2.1.2 – Simulator Integration • This work area will consist in: • Implementing adaptations required (e.g. ATC module, Flight Management, Airport Navigation ...) to host the new data format • The integration of the prototypes in relevant simulators. Input: • • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP4/5, WP6 operational scenario

Short description of contribution

SJU DoW WP09 V4.0.doc

Page 125 of 143

• • • • •

Implementation of the adaptations in simulated environment Integration of the prototypes in simulators Contribution to scenarios definition Integration in simulators. Contribution to scenarios definition

2.1.3 – Technical Validation Deployment & validation of the standards in the simulated environment: • Implementation and validation of the complete database production chain(s) from procedure designer to simulated ATC and embedded databases: the new procedure design is integrated in a complete Air-ground simulated environment: ATC and FM. • Validation in operational environment of the AIXM: xNOTAM as first application of AIS/DL • A829/NDBX implementation taking in account both AIS DL and new procedure coding/design Short description of contribution • validation of the complete database production chain, the new formats and AIS Datalink services through simulators • Contribute to Validation in an operational environment • Validation of the complete database production chain. As an end-user. Validation in operational environment. • Participation in the implementation process Related OI Steps and System Enablers OI: • • •

IS-0202 - Improved Supply Chain for Aeronautical Data through Common Quality Measures IS-0203 - Harmonised Aeronautical Information through Common Data Model IS-0204 - Facilitated Aeronautical Data Exchanges through Digitalised Information

EN: • • • • • • • •

AIMS-06 - Aeronautical Information system providing airspace information static and dynamic AIMS-13 - Controlled & Harmonised Aeronautical Information Network Activity (CHAIN) AIMS-14 - Aeronautical Information system adapted to provide aeronautical information to users through services (D-AIM) AIMS-15 - Aeronautical Information sub-system enhanced to be able to handle Dynamic Mobile Areas AIMS-16 - Electronic Terrain and Obstacle Data (TOD) AIMS-17 - Aeronautical Information enhanced with digital NOTAMs AIMS-18 - Aircraft Information system CTE-N8 - FMS performance standards

In addition to the direct links identified above, databases are also linked to several operations and enablers related to airborne navigation/trajectory, airport navigation and terrain – including synthetic terrain. Deliverables

SJU DoW WP09 V4.0.doc

Page 126 of 143

WA1 • • WA2 •

Standards definition. AIS/DL implementation opportunities

Technical Validation Report(s)

Risks The main technical risks are: • Details of the definition of the AIS Datalink services not precise enough in term of definition. • Definition in due time of a standard for terrain & Obstacle DB Mitigation means: • Active standardisation of the AIS Datalink. • Preparation with involved partners of technical aspects. Lobbying with involved organizations.

SJU DoW WP09 V4.0.doc

Page 127 of 143

SWP 9.33 ATS Datalink Operational Improvements SWP 9.33

Title: ATS Datalink Operational Improvements (not related to datalink evolutions enabling specific ATM improvement, e.g. ASAS, 4D, etc.)

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Aircraft Integration e.g. use of CPDLC in Flight Phases different from Enroute (Aircraft Manufacturer) and FANS (AFN, CPDLC) applications • Ground Enroute/App Datalink System Design to assess impact on ground system (overall definition) • Ground Airport Datalink System Design to assess impact on ground system (overall definition) • Airport Operations to validate operational, safety and performance assumptions (use of CPDLC for DCL) • Approach Operations to validate operational, safety and performance assumptions (use of CPDLC in approach) • Enroute Operations to validate operational assumptions (operational procedure for silent transfer) • En-route Operational assessment to validate operational assumptions (acceptability of automatic transfer from oceanic to domestic airspaces) • Design, development and integration of datalink technologies (specifically ATN and ACARS) • Avionics systems capabilities Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress with the technical definition and validation of core CPDLC services required by the more extensive use of D/L expected in the mid/long terms. (e.g. Airport Operations, 4D, AIS-MET, ASAS-ITP, ASPA, …). The Project will also address all new D/L services which will be necessary to support future or enha nced applications. The project will also progress the technical definition and validation of the automatic transition from oceanic to domestic airspaces to enable long haul aircraft communications in domestic environment. There are four main features to be defined: • Use of CPDLC communications for Departure Clearance (complementing current A623 based operations) • Use of CPDLC communications in approach • Use of CPDLC communications for silent transfer between sectors (in place of existing vocal Contact procedure) • Use of new D/L services required to support future or enhanced applications It is anticipated that use of Datalink (based on ATN technology) for ATS communications will be

SJU DoW WP09 V4.0.doc

Page 128 of 143

widely deployed in European domestic airspaces and ultimately be managed inside the SWIM context. The steps forward will then enable extension of the use of CPDLC communications for non-tactical operations to alleviate some existing procedures and introduction of new services and allow automatic and seamless transition of Datalink equipped aircraft from oceanic to continental ATS Datalink communications environments (and vice versa). The main issues are the definition of operational, safety and performance requirements to support these extensions, and the definition of agreed procedures at air/ground interoperability level (mainly to deal with AFN and CMA synchronized use to achieve automatic transfers) Some feasibility assessment will need to be conducted using prototypes. Very strong synergy is needed with the WP4, WP5 and WP6 counterpart project aiming at operational validation of enroute, approach and airport operations as well as with undergoing project addressing similar objectives (4DLink).

Description of Work PHASE 1 WA1 – System Definition This work area will consist in the definition of the operational and function assumptions used for the project. This work will use as an input intermediate results of the WP4, WP5 WP6, and WP10 counterpart project: mainly operational assumptions and end-to-end safety & performance analysis results and intermediate results of Cristal ITP activities and Project 4.7.4 early results. The technical definition will consist in a high level functional requirement definition Inputs: • Consolidated assumptions (potentially interim versions to start with) provided by WP4, WP5 and WP6 • OSEDs, SPR and Interop coming from WP4, WP5 and WP6, as appropriate Short description of contribution • Participation to the functional definition with airborne perspective. • Contribution to high level functional requirement definition • Contribution to the operational and functional requirement definition • Monitor and contribute to standardisation bodies at datalink services level and at equipment standards level on interfaces between equipment (e.g. FM & CMU) and/or between functions (e.g. applications and routeurs) WA2 System Architecture Validation WA2.1 Mainline Aircraft WA2.1.1 – System Architecture

SJU DoW WP09 V4.0.doc

Page 129 of 143

This work area will consist in the definition of the architecture assumptions used for the project. This work will use as an input intermediate results of the WP4, WP5, WP6 and WP10 counterpart project: mainly operational assumptions and end-to-end safety & performance analysis results. The partners involved in this work package will actively participate in standardization groups (e.g. RTCA/Eurocae) so as to expedite standardization activities using validation results. The technical definition will consist in: • target aircraft architecture (meeting WP4 operational requirements, on safety, performance, etc.) to support A/G Datalink service including ASA-ITP, ASAS-ASPA • an HMI requirement definition • a system requirement definition (i.e. technical requirements at aircraft equipment level) Inputs: • Consolidated assumptions (potentially interim versions to start with) provided by WP4, WP5, WP6 and WP10 • OSEDs, SPR and Interop coming from provided by WP4, WP5 and WP6, as appropriate Short description of contribution • Avionics system requirement definition and management of prototype development. • Contribution to system requirement definition (one system requirement for all aircraft types) WA2.1.2 – Prototype Development This work area will consist in the development of an ATIMS System prototype capable of : • CPDLC communications for Departure Clearance • CPDLC communications in approach • CPDLC communications for silent transfer between sectors (with the adequate automation level in avionics) • CMA communications consistent with a ground CM server architecture • New D/L services required to support future or enhanced applications including ASASITP, ASAS-ASPA inside the avionics hosting the Air Traffic Services • Automatic transition between oceanic and domestic airspaces (for ASAS, the related TCAS necessary evolutions will results from project 9.47) Input: • Definition assumptions Short description of contribution • Prototype development. • Contribution to system prototype development (some extra work of adaptation for each aircraft type) WA2.1.3 – Simulator Integration This work area will consist in: Implementing adaptations required to host the prototypes and play the selected scenarios The integration of the prototypes in aircraft simulator. Input:

SJU DoW WP09 V4.0.doc

Page 130 of 143

• • • •

Definition assumptions Technical Validation Plan Prototypes readiness WP4, WP5 and WP6 operational scenarios

Short description of contribution • Provision of a representative test platform, e.g. aircraft simulator (real equipment). • Contribution to integration of prototypes in an aircraft simulator WA2.1.4 – Technical Validation This work area will begin within WP4, WP5 and WP6 with the identification of operational validation objectives in close coordination with the ANSP partners so as to be consistent and potentially complementary with the Ground counterpart project (WP10 and WP12). On the basis of the validation objectives (defined in the Operational WP4, WP5 and WP6), and on the basis of the identified simulation environments (provided by WP3), this work area will focus on the validation of the airborne architecture and systems solutions. Technical validation objectives will be established. Validation traffic scenarios will be established using the ANSP data and expertise. Technical validation will be conducted within WP9 using operational scenarios obtained from WP4, WP5 and WP6. Short description of contribution • Definition of V&V objectives • Test procedure • Test performing • Test result • Contribution to technical validation (basically this effort for each aircraft type) WA2.2 – Regional Aircraft This work area consists in the definition of the architecture and technical assumptions for regional aircraft. The technical definition consists in: • Target aircraft architecture definition (meeting WP4 operational requirements, on safety, performance, etc, and functional and operational requirements) • HMI requirement definition • System requirement definition (i.e. technical requirements and interfaces at aircraft equipment level) 2.2.1– Prototype Development Development of the avionics prototype meeting the high-level requirements Short description of contribution • Prototype Development 2.2.2 – Test benches & Integration Tests facilities to test the avionics package consist in. • Integration bench aiming at validating the correct integration & the correct functional behaviour of the datalink services and HMI transitions • System bench aiming at validating the correct integration of the global avionics package (with real and simulated equipments) Short description of contribution • Design & development of test facilities for the avionics prototype.

SJU DoW WP09 V4.0.doc

Page 131 of 143

•

Development of tools to monitor and/or simulate other equipments and counter-parts

2.2.3 – Technical Validation Perform a set of test activities from equipment up to full integration of the avionics package. Short description of contribution • Coordination with ground systems to define a representative set of operational scenarios • Produce plans for V&V activities at system level for datalink services (including transition oceanic to continental and vice-versa) • Conduct sub-systems integration & validation • End-to-end interoperability & performances testing for datalink services with ground counter-part • Analyse impacts for cockpit integration and human interactions (enhanced HMI for crew operations) PHASE 2 • Flight trials Related OI Steps and System Enablers OI: • • • • EN: • •

AUO-0302: Successive Authorisation of Reference Business / Mission Trajectory (RBT) Segments using Datalink IS-0402: Extended Operational Terminal Information Service Provision Using Datalink TS-0103: Controlled Time of Arrival (CTA) through use of datalink IS-0707: SWIM - Air-Ground limited services

A/C-33 Uplink and automatic loading in onboard navigation system of clearances CTE-C2b - Enhanced VDL2 Air-Ground datalink (Common network protocol ATN+ or IP+)

• Deliverables PHASE 1 WA1 • Aircraft Functional Definition Assumptions Document. WA2.1 • Technical Note on Avionics System Definition. • Technical Validation Plan • Technical Validation Report WA2.2 • Technical Note on Avionics System Definition. • Technical Validation Plan • Technical Validation Report

SJU DoW WP09 V4.0.doc

Page 132 of 143

SWP 9.38 ASAS – SSEP SWP 9.38

Title: ASAS-SSEP

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Datalink avionics • Aircraft Architecture Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to assess the technical feasibility of the ASAS- Self-Separation airborne capability. Description of Work WA1 – Technical Feasibility Assessment Assessment of the impact on a/c architecture of airborne safety and performance requirements defined in SPR, and Interop delivered by P4.7.5 (Self separation in mixed mode environment)

SJU DoW WP09 V4.0.doc

Page 133 of 143

SWP 9.39 Continuous Climbing Cruise SWP 9.39

Title: Continuous Climbing Cruise

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Trajectory prediction • Computation • Display systems Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives Typical cruising flight of jet transport aircraft involves a sequence of level segments increasing in altitude as fuel is burned. The steps in altitude are typically of 1000, 2000, or 4000 feet depending upon the constraints of the airspace in which the aircraft is flying. A step climb is typically made when the flight efficiency between two candidate altitudes is approximately equal, and the air traffic controller can allow the aircraft to climb. At the point of such a step climb, the optimal cruise altitude is approximately at the mid-point between the two altitudes. There is a potential for increased fuel savings by allowing aircraft to continuously track their optimal cruise altitude, slowly climbing at a rate of 10-50 feet per minute, as computed by the onboard flight management system. Challenges to performing continuous cruise climb include lack of support from current generation avionics, lack of air traffic control procedures for efficiently allowing this type of operation, and lack of data link support for uplink of clearances and downlink of aircraft intent. To perform a continuous cruise climb with present day capabilities requires the air traffic controller to give an aircraft a block altitude clearance, which uses up a significant chunk of airspace, and the pilot must manually transfer the FMS computed optimal altitude into the autopilot control panel at a frequency desired by the pilot (every 5 minutes, for example). This task describes the research required to make this capability feasible for normal operations. In the future, this type of operation may occur in self-separation airspace, with airborne ASAS capability. Description of Work WA1 – Avionics Requirements This work area will consist in the determination and description of required modifications of the existing airborne systems: • Computation of optimal vertical flight path and speed (FMS) • Trajectory prediction (FMS) • Guidance / Autopilot • Surveillance – ASAS impact

SJU DoW WP09 V4.0.doc

Page 134 of 143

•

Display modifications (e.g., IPFD)

WA2 – Safety Analysis This work area will consist in contributing to the safety assessment of the cruise climb operations. This analysis will be performed in close collaboration with the WP5. WA3 – Human Factor Analysis This work area will consist in the analysis of human factors aspects of new cruise climb operations and proposed avionics and cockpit systems modifications. WA4 – System Validation Simulations and trials with business jet platforms Related OI Steps and System Enablers OI: • EN: •

AUO-0304 Initiating Optimal Trajectories through Cruise-Climb Techniques· 08 Optimising Climb/Descent

PRO-AC-09 Cockpit procedure to perform continuous climbing cruise· management and guidance to perform climbing cruise

SJU DoW WP09 V4.0.doc

L02-

A/C-09 Flight

Page 135 of 143

SWP 9.40 Long-term Architecture SWP 9.40

CDA

Steeper

Approach

Airborne

Title: Long-term CDA & Steeper Approach Airborne Architecture

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • FMS avionics • Datalink avionics • Aircraft Architecture • Display system Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The objective of the project is to progress on the technical definition and the system design of the Long-term CDA & Steeper Approach Airborne Capability. This project aims to define and validate a new airborne navigation system design that will enable to compute and fly more optimized arrival & approach profiles in terms of emissions & noise. These profiles will results from the best trade-offs in terms of aircraft altitude, speed and configuration. As defined in the ICAO Circular, CDA (Constant Descent Arrival/Approach) comprehends the Arrival (from the en-route structure until the IAF) and the Initial Approach (from the IAF until the FAF/P). The initial part is of interest for fuel burn and emissions, the last part of the CDA is relevant for noise abatement purposes. The way the aircraft will manage the transition from the initial part to the last one should be deeply studied. Besides, the aircraft configuration - flaps and slats position – is an important noise factor that should be duly considered in the definition of the vertical profiles of lower parts of CDAs and Steeper Approaches: indeed, potential noise reduction expected from a steeper approach path could be totally wrecked by the noise generated by the aircraft configuration and speed that would be required to fly this path. A less steep approach path (possibly with a non-constant slope) could finally prove to be more beneficial in terms of noise.

SJU DoW WP09 V4.0.doc

Page 136 of 143

Description of Work WA1 – System Definition This work area will consist in the definition of the operational and function assumptions used for the project. WA2 – System Validation 2.1.1 – Mock-up/Prototype Development 2.1.2 – Simulator Integration 2.1.3 – Technical Validation

SJU DoW WP09 V4.0.doc

Page 137 of 143

SWP 9.44 Flexible Communication Avionics SWP 9.44

Title: Flexible Communication Avionics

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Datalink avionics • Software defined radio (including Military development) • Aircraft Architecture Indicative work breakdown per co-financed contributors: • Airborne Industries: 100% Concept & Objectives The communication exchanges between aircraft and the ground and between several aircraft will drastically evolve to enable the SESAR Capability levels. These exchanges will require more advanced functionalities, different category of QoS including stringent QoS and higher throughput. The characteristics of these exchanges will be area dependant (e.g. the volume of exchange in an airport will be significantly different than in En-route). To deal with such disparities and to fulfil the communication requirements (e.g. availability), different components are necessary. Different previous studies concluded on a communication sub-system including a new ground-station based element (potentially capable of supporting Air/Ground and Air/Air services), a satellite communication element, and a wireless airport element. The potential consequence of this multi element organisation is the potential need for aircraft to be equipped with different avionics and the need to be capable, during the transition phases, to operate legacy exchanges. The objective of this project is to consider the most suited “radio” avionics which would minimise the number of different developments and the number of avionics equipment required on-board while supporting the identified elements necessary to enable the concept. Description of Work PHASE 1 WA1 - System Definition The objective of this working area is to investigate the feasibility of flexible on-board radio (such as, but not limited to, Software Defined Radio) which could support several or the totality of the communication future and legacy elements and addressing different platform (e.g. Mainline, Regional, Military, …aircraft). This study will investigate: • The technical feasibility to introduce different protocols types

SJU DoW WP09 V4.0.doc

Page 138 of 143

• •

• • •

The constraints and solutions for using such flexible radio on-board aircraft (e.g. certification issues) The order of cost of this type of solution Vs the classical way of supporting on-board communication protocols (including development aspects and possession and implementation aspects) The identification of the most appropriate type of solutions The work to be carried out during the second phase as well as the envisaged cost. Any important issues

During this investigation, results from aeronautical and non-aeronautical activities on similar concern (e.g. military developments) will be carefully taken into account and almost-cots components will be considered. A close cooperation will be required with 15.2.4 which is considering the full communication sub-network aspect. The end of this phase will constitute a Decision Gate where the findings of 9.44, 15.2.4, 15.2.6, and 15.2.7 will be presented as a whole to the S-JU to decide on the approach to follow during the PHASE 2. PHASE 2 The second phase will undertake the work which will be agreed at the Phase 1 Decision Gate. It could include • solution refinement, • simulation development, • prototype development, • flight trials. The cost of this second phase shall not be evaluated for the time being.

Related OI Steps and System Enablers EN: • • •

CTE-C1 CTE-C12 CTE-C4b

Deliverables PHASE 1 Gate Decision report including: • Technical feasibility and identification of the most appropriate solution • Constraint and solving solution • Cost (order of magnitude at least) • Phase 2 work programme and associated cost

SJU DoW WP09 V4.0.doc

Page 139 of 143

SWP 9.47 TCAS Evolution SWP 9.47

Title: TCAS Evolution

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Traffic collision avoidance • Airspace structure • Separation management • ADS-B Indicative work breakdown per co-financed contributors: • Service providers: 15% •

Airborne Industries: 85%

Concept & Objectives The first objective of the project is to analyse TCAS alert data to assess whether the nuisance alert rate is too high contributing to non compliance to the TCAS resolution advisories and develop the necessary methods of reducing the nuisance alert rate by 1. the prudent use of additional surveillance information such as ADS-B make use of the concepts for full ADS-B. 2. use the knowledge of the airspace design Without sacrificing the independent backup “safety net” provided by TCAS. The second objective is to study changes to TCAS algorithms in order to accommodate changes in airspace design. As spacing of aircraft are potentially changed (enabled by ASAS / ASPA functionality) TCAS may produce false / nuisance alerts. The third objective is to improve the multi-threat logic within the TCAS. It is known that this logic is not mature. The multi-aircraft logic may become more important as airspace is changed. The fourth objective is to assess the impact of the implementation of the proposed changes to different avionics architectures, e.g. mainline, regional, business and general aviation. In all cases much of this work can be evaluated and performed using simulation tools and not prototyping until the concepts are quite mature.

Description of Work WA1 Nuisance alert rate reduction: WA1.1 Analysis of TCAS alert data

SJU DoW WP09 V4.0.doc

Page 140 of 143

WA1.2 Development of nuisance alert rate reduction techniques WA2 TCAS algorithm changes WA3 Improve multi-threat logic within the TCAS In all cases much of this work can be evaluated and performed using simulation tools and not prototyping until the concepts are quite mature.

SJU DoW WP09 V4.0.doc

Page 141 of 143

SWP 9.48 AIS/MET Services & Data Distribution SWP 9.48

Title AIS/MET Services & Data Distribution

Necessary Expertise For general expertise please refer to overall WP description, section “Generic typology of expertise” Specific expertise: • Airborne System Design (Avionics and Aircraft Manufacturer) • Aircraft Integration (Aircraft Manufacturer) • Future datalink concepts and services • Avionics systems within which aeronautical and/or meteorological data is used Indicative work breakdown per co-financed contributors: • Service providers: 15% • Airborne Industries: 85% Concept & Objectives The objective is to design the architecture of system in order to provide: • AIS and MET information to the crew or the avionics systems during flight • Additional information of increased situational awareness to the crew or avionics systems • Additional alerts to the crew Description of Work WA0 - Collect requirements This work area will consist in the gathering of the requirements that will be used for the definition WA. The project 9.48 will be focused on dynamic data inter alia airport, navigation, meteorological. For each type of data, requirements will be collected such as the refresh rates, integrity, the required degree of consistency, confidence, liability among the ground and airborne users, the safety requirements and the security requirements. All these requirements will be considered by taking in account the whole chain from each actual data producers to each actual or potential end-users. These requirements will be translated into definitions, exchange formats, means or other standardizations for use in the following WAs." WA1 – Functional Definition • Derive, from operational projects and global ground to A/C system definitions : o Tools to provide A/C with Aeronautical updates & SYNC services o Tools to provide A/C with meteorological information for planning, near-term and immediate services o Additional datalink services to support operations as defined in operational projects WP 4, WP 5, WP 6, and SWIM services as defined in WP 14. o Corresponding Airborne systems architecture: define a standard interface to the distributed components of the aeronautical and meteorological services and to various means, taking into account results and definitions from project 15.2.4 Future Data Link System Definition WA2 – System Validation

SJU DoW WP09 V4.0.doc

Page 142 of 143

2.1– Airborne System Definition • A/C system definition for all further data exchange based services covering interaction of these services with all related airborne systems. 2.2 – Prototype Development • Airborne system development to receive & use AIS & MET uplinked data • Tools development to connect data ground sources to airborne systems o Database packing (aeronautical Sync service) o Real time update (aeronautical update service) o Meteorological data handler • Airborne system design and development to send/receive & use at cockpit level further datalink services. 2.3 – Technical Validation and Verification • Verification & Validation in a simulated environment

SJU DoW WP09 V4.0.doc

Page 143 of 143