sju dow wp09 v4 0

WP 9 - Aircraft

Description of Work (DoW)

Version 4.0

Released 17/12/2008

SJU DoW WP09 V4.0.doc of 143

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 – SSEP............................................................................... 133

SWP 9.39 Continuous Climbing Cruise ...................................................... 134

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


SWP 9.44 Flexible Communication Avionics ............................................. 138

SWP 9.47 TCAS Evolution ........................................................................... 140

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


Level 1 – Work Package Description


WP 9 Aircraft

WP 9 Title: Aircraft

Generic typology of expertise

1) Operations:

• SESAR ConOp,

• ATM Operational Concept (En Route, TMA, Network management, runway environment…),

• ATM Operational Experience (En Route, TMA, Network management, runway environment…),

• ATC users requirements (ground & air),

• Airspace users, airport operators and airlines operators requirements,

• Pilot/aircraft capabilities and constraints,

• Military specific needs,

• Validation methodologies,

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.


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


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:


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,

WP BHigh Level Target

Concept & Architecture

WP 16Transversal areas

WP 9WPs 4, 5, 6, 7

WP 3Validation

Infrastructure

WP 15

Operational WPs

System WPs

- 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

- 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

- Validation plans and schedule- Consolidated platform / tool requirements

- Development plans of validation platforms & tools- Planning of availability of systems & prototypes

for integrated / pre-operational validation

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

- Apportioned air-ground system

requirements

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

- OSEDs, SPR

WP BHigh Level Target

Concept & Architecture

WP 16Transversal areas

WP 9WPs 4, 5, 6, 7

WP 3Validation

Infrastructure

WP 15

Operational WPs

System WPs

- 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

- 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

- Validation plans and schedule- Consolidated platform / tool requirements

- Development plans of validation platforms & tools- Planning of availability of systems & prototypes

for integrated / pre-operational validation

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

- Apportioned air-ground system

requirements

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

- OSEDs, SPR


representing the overall idealised ‘V’ 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

Onboard Operational

Definition and Validation

Functional

Definition and

Validation

Airborne Sub-System Demonstrator Definition

Overall Operational validation :

- System of Systems Integration and Validation

Service Description

Interop, SPR

Airborne Sub-System Demonstrator Validation at

Aircraft Level

WP 9 activities

WP15Global System Definition and

Validation

(if applicable)

Global System Technical Validation

(if applicable)

Operational WP activities

Onboard Operational

Definition and Validation

Functional

Definition and

Validation


Overall Operational validation :

- System of Systems Integration and Validation

Service Description

Interop, SPR

Airborne Sub-System Demonstrator Validation at

Aircraft Level

WP 9 activities

WP15Global System Definition and

Validation

(if applicable)

Global System Technical Validation

(if applicable)

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.


WP 4 En Route WP 5 TMA WP 6 Airport WP 7 Network

WP 8 Information Model

WP 14 SWIM

WP 15 CNS PROJECTSRequirement consolidation

WP 9 AIRCRAFTAirborne Prototype development

Input for SWIM Validation

WP 15 CNS PROJECTSNon Avionics Prototype Development

End to End Technical validation

Aircraft requirements Non-Aircraft requirements

WP 4 En Route WP 5 TMA WP 6 Airport WP 7 Network

WP 8 Information Model

WP 14 SWIM

WP 15 CNS PROJECTSRequirement consolidation

WP 9 AIRCRAFTAirborne Prototype development

Input for SWIM Validation

WP 15 CNS PROJECTSNon Avionics Prototype Development

End to End Technical validation

Aircraft requirements Non-Aircraft requirements

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.1 Airborne Function (Project)

WP9.2 Airborne Function (Project)

WP 9.X Airborne Function (Project)

WP 9.0 Global Co-

ordination and Management

• System definition

• System validation

High level WP9 WBS

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


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.



WA1 Definition

Platform independent

WA1 Definition


WA2 Validation

Platform specific

WA2 Validation

Platform specific

Mainline aircraftMainline aircraft Business JetsBusiness Jets Turbo PropsTurbo Props

Function requirements

High level architecture

For each platform type

System architecture and definition

HMI definition

Prototype development

Validation platform integration

Test and trials

Other platforms

(as appropriate)

Other platforms

(as appropriate)



WA1 Definition


WA1 Definition


WA2 Validation

Platform specific

WA2 Validation

Platform specific

Mainline aircraftMainline aircraft Business JetsBusiness Jets Turbo PropsTurbo Props

Function requirements

High level architecture

For each platform type

System architecture and definition

HMI definition

Prototype development

Validation platform integration

Test and trials

Other platforms

(as appropriate)

Other platforms

(as appropriate)

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.

1 This applies only to projects where different airborne platform type developments are foreseen. E.g. mainline

aircraft, regional aircraft, Military etc.


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 2009-2010 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 Title OI Steps supported Capability Level

Enabler ID

9.1

4D-Trajectory

Management

Airborne Initial 4D Trajectory Management

AOM-0206 AOM-0304 AOM-0501 AOM-0502 AOM-0702 AOM-0704 AOM-0804 AUO-0302 AUO-0303 AUO-0504 AUO-0703 CM-0401 CM-0601 CM-0602 CM-0603 CM-0604 CM-0701 CM-0702 IS-0302 IS-0303 IS60402 TS-0103 TS0105

2 A/C-11 A/C-31 A/C-33 A/C-36 A/C-37 A/C-45


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

AOM-0206 AOM-0304 AOM-0501 AOM-0503 AOM-0702 AOM-0804 AUO-0302 AUO-0303 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

3 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 AOM-0202 AOM-0302

2 AAMS-11 AIMS-19

9.5 ASAS – ASPA AUO-0504 TS0105 AUO-0302 AUO-0504 AUO-0703 CM-0601 CM-0603 CM-0701 CM-0702 TS-0105

2 A/C-15 A/C-33

9.6

ASAS

ASAS – ASEP AUO-0302 AUO-0504 AUO-0703 CM-0601 CM-0603 CM-0701 CM-0702 TS-0105

3 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 AOM-0702 AOM-0704 CM-0602

1,2 A/C-01 A/C-05 A/C-06

9.11 Aircraft Systems for Wake Encounter Alleviation

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

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

9.12

Terminal & Approach

Operations

GBAS Cat II/III AO-0505 2 CTE-N4B

9.13 Airport Surface Taxi Clearances

AUO-0302 3 AGSWIM-56

9.14

Airport Surface Operations

Airport Surface Alerts (ownship and traffic)

AUO-0605 2 A/C-43 AGSWIM-47

9.16 New COM Technology at Airport

AUO-0302

AUO-0303

2 CTE-C4B

9.19

Technology Enablers

SWIM Air-Ground Capability

IS-0710 3 CTE-C2B


9.20 Military Data Link Accommodation

AOM-0304 IS-0706 IS-0709

2 CTE-C3

9.21 ADS-B - 1090 Higher Performance Study

TS-0105 CM-0701

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

9.22 Mid & Full ADS-B Capability - Research

9.24 ADS-B In/Out for military TS-0105 CM-0701

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

9.27 Multi-constellation GNSS Airborne Navigation Systems

AUO-0604 3 CTE-N1A

9.28 Enhanced Vision(Head Down and Head Up) Solutions

AUO-0403 2 CTE-N9A

9.29 Enhanced & Synthetic Vision

AUO-0404 4 CTE-N9B

9.30 Weather Hazards / Wake Vortex Sensor

AO-0304 2 CTE-S8A

9.31 Aeronautical Databases 2 TBC

9.33 ATS Datalink Operational Improvements

AUO-0302 IS-0402 TS-0103 IS-0707

3 TBC

List of WP9 projects starting in the period 2009-2010

Domain Title Related SESAR

Enablers ID

9.38 ASAS ASAS - SSEP A/C-17 ; A/C-29

A/C-50

9.39 Continuous Climbing Cruise A/C-09

9.40 Terminal & Approach

Operations Long Term CDA & Steeper Approach airborne architecture

AOM-0702

A/C-07

9.44 Flexible Communication Avionics CTE-C1

9.47

Technology Enablers

TCAS Evolution CTE-S11a CTE-S11b

9.48 (Transverse/Independent) Data Link

Services

AIS/MET Services and Data Distribution A/C-46

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

Methodology


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.

A/C System ValidationA/C System Definition

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

Functional

Requirement Definition

Functional Definition and Validation

Simulation of Function

in Aircraft Simulator coupled with ATM

simulator

Simulation of Function in

Aircraft Simulator (a/c –

1)

Modelling

of Function

Operational Analysis

(impact on a/c)

Airborne Function Stand alone Simulation

Onboard Operational Definition and Validation

Airborne Function Simulation in ATM

environment

Raw Modelling of Function (e.g. HMI)

Contribution to Overall Operational

Validation

Test of Airborne Sub-System Demonstrator in Flying Platform

System of Systems Integration and

Validation

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

Validation of Sub-

System Demonstrator with coupled

demonstrators/(Air-Grnd and Air-Air

validation)

Airborne Sub-System Demonstrator Definition and Validation

Definition of Airborne Sub-

System Demonstrator

Validation of Airborne Sub-System Demonstrator in

Aircraft Demonstrator in realistic ATM env. (a/c 0)

Development of Airborne Sub-System

Demonstrator

WP9 Scope

A/C System ValidationA/C System DefinitionA/C System Definition




Safety Performance







Safety Performance




Functional





simulator



1)

Modelling

of Function

Functional





simulator



1)

Modelling

of Function

Functional





simulator



1)

Modelling

of Function

Functional





simulator



1)

Modelling

of Function


(impact on a/c)




environment



(impact on a/c)




environment



(impact on a/c)




environment


Contribution to Overall Operational

Validation




Validation


Validation

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

Validation of Sub-



validation)

Validation of Sub-



validation)

Airborne Sub-System Demonstrator Definition and Validation

Definition of Airborne Sub-

System Demonstrator

Validation of Airborne Sub-System Demonstrator in

Aircraft Demonstrator in realistic ATM env. (a/c 0)

Development of Airborne Sub-System

Demonstrator

WP9 Scope

Figure 1 Generic Approach for WP9 Level 2 activities


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…). 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)


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 sub-system/function at "system of systems" level is addressed in Contribution to Overall Operational Validation. Three areas of activity are defined. Onboard Operational Validation


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


• 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 Likelihood Impact Mitigation Limited overall technical coherency and consistency with other WPs

High High. Inappropriate and/or unsynchronised deliverables

Strong overall consistency provided by WP2. Close coordination between all level 1 WPs.

Inefficient working structures hinders development

Medium High. S-JU to propose strong formal working structures and processes.

WP9 Risks Likelihood Impact WP9 Mitigation Late or limited input of operational requirements

High High. Development of solutions is hindered

WP9 partners need to be implicated in the operational WPs to get early understanding of requirements.

Not all platforms segments adequately covered

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

Identification within the WPSC of key partners to represent the various airborne platforms.

Global interoperability not achieved

High High: no buy in from users.

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


Sub-Work Packages and Projects overview

Sub Work package n°

Sub Work Package title

Project n° Project title

Type of activity (MGT/Project2)

9.0 Global Co-ordination and Management MGT

9.1 Airborne Initial 4D Trajectory Management Project

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

Project

9.3 Interoperability of Business Trajectory and Mission Trajectory

Project

9.5 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

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

MGT SWPs dedicated to management activities (Management SWPs have at least 2 Projects attached)


9.30 Weather Hazards / Wake Vortex Sensor Project

9.31 Aeronautical databases Project

9.33 ATS Datalink Operational Improvements Project

9.38 ASAS – SSEP Project

9.39 Continuous Climbing Cruise Project

9.40 Long-term CDA & Steeper Approach Airborne Architecture

Project

9.44 Flexible Communication Avionics Project

9.47 TCAS Evolution Project

9.48 AIS/MET Services & Data Distribution Project


Level 2 & 3 – Work-Package Description


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.


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.


Description of Work

Management structure

The management of the WP is organised according to the general principles described in the following figure:

Programme

Level

Sub-WP

Level

Project

Level

Industrial Support

WP

Level

WPX Leader WPY Leader WPZ Leader

Sub-WP Manager Z.1

Sub-WP Manager Z.n

…

…

Project Manager

Z1.1

Project Manager

Z.1.n

Project Manager

Z.n.n… …

Project Collaborator 1

…

Executive Director

Programme Management

Work Package

Management

Project

Management

PLANNING, RISKS, BUDGET, GATE

DEFINITION AND MAINTENANCE

Project Manager

Z.n.1

Project Collaborator n

Sub-Work Package Management

Sub-WP Manager Z.0

Programme Committee

Sub-Contractor 1

… Sub-Contractor n

SJU Administrative Board

Project Lifecycle

Each project follows a lifecycle as described below:

Initiation

Execution Acceptance

Go /

No-goKick-off

Initiation

Report*

Termination

Project Manager

and Members

SJU

Project Manager and

Members

SJU

Go No-go

INITIATION PROCESS

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

Gate

SJU

Impact

Assessment

Impact

assess-

ment

form

Work Package

Leader


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:

• 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,

• 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,

• 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,


etc.), o 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


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


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.


SWP 9.1 Airborne Initial 4D Trajectory Management

SWP 9.1 Title: Airborne Initial 4D Trajectory Management

Necessary 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%


4D trajectory management is an A/C function that enables to build, guide, predict and communicate an A/C 3D + time trajectory. Initial 4D is the first step towards full 4D planned in SESAR target concept. It is aimed to provide significant early benefits, while being capable to be retrofitted to the whole commercial fleet with limited cost. CDA aspects, or any vertically optimised flight trajectory, in mid/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

• 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 Initial 4D function, is at the level of maturity relevant to launch a cost effective and robust A/C system development.


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


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


• 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:


• Technical Validation Plan

• Prototypes readiness

• WP4 & WP5 operational scenarios


• 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


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


• 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


• 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:


• Prototypes readiness notes from WA2.3.1

• WP5 operational scenarios


• 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


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-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


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


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

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

Necessary 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)




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,


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)


• 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


definition (common to all applications part)

• Definition and feasibility analysis for regional A/C


• 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:



• 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:



• 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


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


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-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-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


PHASE 1

WA1

• 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

WA2

• Technical Validation Plan of Full 4D for WP9

• Technical Validation scenarios


Risks


• 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


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:



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.


• 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


• 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


• 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:



• 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


• 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


• 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

• 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

WA2

• 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.


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).




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.


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.


• 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 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.


• 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


• 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:


• 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


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


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.


SWP 9.6 ASAS ASEP

SWP 9.6 Title: ASAS ASEP

Necessary Expertise


• FMS avionics


• Air Surveillance Prototyping

• Display prototyping

• Aircraft Architecture Indicative work breakdown per co-financed contributors:



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


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)


• 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.


• 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.


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.


• 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.


• Algorithm development/prototype for the cockpit mock-up

Input:


• 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


OI:

• CM-0701: Ad Hoc Delegation of Separation to Flight Deck - In Trail Procedure (ASEP-ITP)

• CM-0702: Ad Hoc Delegation of Separation to Flight Deck - Crossing and Passing (C&P)

• ASEP-Sequencing & Merging EN:

• A/C-16: Flight management and guidance to support ASAS separation (ASEP)

• CTE-S8b: Airborne wake vortex detection (Higher performance)

Deliverables


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.


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


• Airborne System Design (Avionics and Aircraft Manufacturer)

• Aircraft Integration (Aircraft Manufacturer) Indicative work breakdown per co-financed contributors:



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:


• 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



• 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


OI:

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

EN:

• 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


SWP 9.10 Approach with Vertical Guidance APV

SWP 9.10 Title: Approach with Vertical Guidance APV

Necessary 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:



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


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


OI:

• AO-0502 - Improved Operations in Low Visibility Conditions through Enhanced ATC Procedures

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


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

EN:

• 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

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

WA3

• System Lab validation tests results


SWP 9.11 Aircraft Systems for Wake Encounter Alleviation

SWP 9.11 Title: Aircraft Systems for Wake Encounter Alleviation

Necessary 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:



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


• 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.


• 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


• 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


• 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.


• 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.


• 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


OI:

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

EN:


• 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.


SWP 9.12 GBAS Cat II/III

SWP 9.12 Title: GBAS Cat II/III

Necessary Expertise


• System Design to assess GBAS Cat II/III L1 airborne components feasibility (Avionics and, Aircraft Manufacturer)




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 multi-constellation 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.


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


• 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


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.


• 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


• 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)


• Pioneer Trials • for Full GBAS Cat2-3

• System Definition

• System validation


OI:

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

EN:

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

Deliverables

PHASE 1 (covering only Initial GBAS Cat2-3)

WA1

• Technical Note – Airborne Impact Analysis

WA2.1



WA2.2



WA3

• Technical Note - Certification Issues

• Technical Note – Availability and Local Environment aspects



Risks

• Transition to Multi GNSS GBAS CAT II/III too constraining

• Ground design from WP15 inadequate to meet performance requirements


SWP 9.13 Airport Surface Taxi Clearances

SWP 9.13 Title: Airport Surface Taxi Clearances

Necessary 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:



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.


Description of Work

PHASE 1



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)


• 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.


• 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



• 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:



• 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:




• 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.


• Participation to technical validation

WA2.2 Business Jets


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.


• 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 a datalink exchange computer prototype capable of taxi clearances Input:



• 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:




• WP6 operational scenario



• 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.


• 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:


• 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



• Development of a datalink exchange computer prototype/model capable of taxi clearances

Input:


• Civil Avionics Manufacturer moving map and CMU prototypes and evaluations



• 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


• 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:





• 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



OI:

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

EN:

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

Deliverables

PHASE 1

WA1

• A high level functional requirement definition

WA2.1

• High Level Architecture Definition Assumptions document.



WA2.2



• Technical Validation Report WA2.3




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).


SWP 9.14 Airport Surface Alerts (ownship and traffic)

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

Necessary 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:



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.


Description of Work

WA1 System definition


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)


• 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



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.


• 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:


• 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.



• 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:


• 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:





• 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.



• Leader for technical validation

• Support to technical validation

WA2.2 Business Jets


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.


• target aircraft architectures (meeting WP6 operational requirements, on safety, performance, etc.) for business aircraft platform


• a system requirement definition (i.e. technical requirements at aircraft equipment level) of traffic alerts

Inputs:



• Define BA Architecture

• HMI requirements for BA

• Support system definition .Potential quick win using existing equipments (EGPWS/RAAS)







Input:



• prototype for Traffic and Ownship alerts

WA2.2.3 – Simulator Integration



• Implementing adaptations required to host the prototypes and play the selected scenarios

• The integration of the prototypes in avionic simulators.

Input:






• 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


• Validation of scenarios on simulator standalone or coupled with ATM network simulator

WA2.3 Regional Aircraft (ownship alerts only)


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:




• Aircraft architecture and system requirements

• HMI requirements definition and system requirements definition for ownship alerts WA2.3.2 – Prototype Development






Input:



• Contribution to prototype development , initial validation and readiness for integration feasibility

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



• Implementing adaptations required to host the prototype and play the selected scenarios

• The integration of the prototype in a regional aircraft simulator.

Input:





• 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.



• Technical validation and reports

• Technical validation with regional aircraft manufacturer and reports

PHASE 2

• Flight Trials

• Pioneer Trials


OI:

• AUO-0605: Automated Alerting of Runway Incursion to Pilots (and Controller) EN:

• 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

•









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.


SWP 9.16 New Communication Technology at Airport

SWP 9.16 Title: New Communication Technology at Airport

Necessary 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:



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


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?)


Solutions for ad-hoc L2 networking Short description of contribution

• Advanced studies for A-SMGCS, high-speed adaptation & ad-hoc networking


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


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:



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 Net-centric 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


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.


• 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


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 ground-based 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.


• 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


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


• 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



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 AOC-ATM 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.



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


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 avionic manufacturers


• Military users • Military operations on the civil airspace

Indicative work breakdown per co-financed contributors: Airborne Industries: 100%


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


• 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



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:



• 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


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:


• 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


• 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]

EN:

• CTE-C3 - Military datalink accommodation

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


• Definition Assumptions document for military transport and fighter/trainer


• Technical note - Technical Validation scenarios


Risks

• Security and datalink capability

• Antenna coupling


SWP 9.21 ADS-B - 1090 Higher Performance Study

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

Necessary Expertise


• CNS Avionics, 1090 MHz Capacity Simulation Capability, Air-Air / Air-Ground Data-link technologies, Future ASAS Application Knowledge, Future Traffic Growth Estimates)


Airborne Industries: 100%


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


• 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.


• 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 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.


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


• 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


• 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.


• 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


OI:

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

EN:

• 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)

Phasing

Transition activities onto following Mid&Full ADS-B Projects


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


SWP 9.22 Mid & Full ADS-B Capability - Research

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

Necessary Expertise


• CNS Avionics, TP management, Tools for CD&R, Air-Air, Air-Ground Data-link technologies; Airborne & Ground Traffic Awareness systems and displays




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


• 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


• Participation on feasibility studies and architecture specification WA2 – Functional analysis & modeling


• 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:



• 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


• 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.


• 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


OI:

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

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

EN:

• 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)

Deliverables


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.


•


• Cost & Benefit Assessment

Risks

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


SWP 9.24 ADS-B In/Out for military aircraft

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

Necessary Expertise


• Military avionic manufacturers (e.g. Military datalink, Surveillance systems such IFF & ADS-B In&Out)



• Military users


Airborne Industries: 100%


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 trade-off 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



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


• 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


• 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:



• 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


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:


• 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


• 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.


OI:

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

EN:

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

Deliverables

• Technical note - definition of assumptions document for military transport and fighter/trainer.




SWP 9.27 Multi-constellation GNSS Airborne Navigation Systems

SWP 9.27 Title: Multi-constellation GNSS Airborne Navigation Systems

Necessary 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:



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.


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

• 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


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


• 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.


• 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


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.


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




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


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


• 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


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


• 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.


OI:

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

• 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


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


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




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


(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


• 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


• 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


• 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.


OI:

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

• 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


SWP 9.30 Weather Hazards / Wake Vortex Sensor

SWP 9.30 Title: Weather Hazards / Wake Vortex Sensor

Necessary 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:



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.


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)



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 EN:

• 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)

Deliverables

PHASE 1

• Technical report on wake vortex alleviation by flight control

• Technical report on Wake vortex sensor design and specification .


SWP 9.31 Aeronautical databases

SWP 9.31 Title: Aeronautical databases

Necessary 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:



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 on-board 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


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-FMS-data 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:


• 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


• 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:



• 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:




• WP4/5, WP6 operational scenario Short description of contribution


• 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


• 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


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


WA1

• Standards definition.

• AIS/DL implementation opportunities

WA2

• Technical Validation Report(s)

Risks


• 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.


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


• 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:



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


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


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.1 – System Architecture


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.


• target aircraft architecture (meeting WP4 operational requirements, on safety, performance, etc.) to support A/G Datalink service including ASA-ITP, ASAS-ASPA


• 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


• Avionics system requirement definition and management of prototype development.

• Contribution to system requirement definition (one system requirement for all aircraft types)


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 ASAS-ITP, 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)



Implementing adaptations required to host the prototypes and play the selected scenarios The integration of the prototypes in aircraft simulator.

Input:





• 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)


• Design & development of test facilities for the avionics prototype.


• 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


OI:

• 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 EN:


• 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 Note on Avionics System Definition.




SWP 9.38 ASAS – SSEP

SWP 9.38 Title: ASAS-SSEP

Necessary Expertise






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)


SWP 9.39 Continuous Climbing Cruise

SWP 9.39 Title: Continuous Climbing Cruise

Necessary Expertise


• Trajectory prediction

• Computation

• Display systems Indicative work breakdown per co-financed contributors:



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


• 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


OI:

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

EN:

• PRO-AC-09 Cockpit procedure to perform continuous climbing cruise· A/C-09 Flight management and guidance to perform climbing cruise


SWP 9.40 Long-term CDA & Steeper Approach Airborne Architecture

SWP 9.40 Title: Long-term CDA & Steeper Approach Airborne Architecture

Necessary Expertise


• FMS avionics


• Aircraft Architecture

• Display system Indicative work breakdown per co-financed contributors:



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.


Description of Work


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


SWP 9.44 Flexible Communication Avionics

SWP 9.44 Title: Flexible Communication Avionics

Necessary Expertise



• Software defined radio (including Military development)




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


• 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.


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


SWP 9.47 TCAS Evolution

SWP 9.47 Title: TCAS Evolution

Necessary Expertise


• Traffic collision avoidance

• Airspace structure

• Separation management

• ADS-B Indicative work breakdown per co-financed contributors:

• Service providers: 15%



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


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.


SWP 9.48 AIS/MET Services & Data Distribution

SWP 9.48 Title AIS/MET Services & Data Distribution

Necessary 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%



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


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

Documents

d trajectory management

sju dow wp09

aircraft systems

military aircraft

mission trajectory

airborne initial

adsb capability research

d contract capability