EUROPEAN ORGANISATION FOR THE SAFETY OF … premises of THALES Avionics in Toulouse, which shows a cockpit simulator with the enhanced capabilities,

The information contained in this document is the property of the EUROCONTROL Agency and no part should be reproduced in any form without the Agency’s permission.

The views expressed herein do not necessarily reflect the official views or policy of the Agency.

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL EXPERIMENTAL CENTRE

TOTAL INFORMATION SHARING FOR PILOT SITUATIONAL AWARENESS ENHANCED BY INTELLIGENT SYSTEMS (TALIS 1)

EEC Report No. 398

Project CNS-Z-TA

Issued: December 2004

Utilisateur

Rectangle

REPORT DOCUMENTATION PAGE

Reference: EEC Report No. 398

Security Classification: Unclassified

Originator: EEC - INO (Innovative Research Area)

Originator (Corporate Author) Name/Location: EUROCONTROL Experimental Centre Centre de Bois des Bordes B.P.15 F - 91222 Brétigny-sur-Orge Cedex FRANCE Telephone: +33 (0)1 69 88 75 00

Sponsor: European Commission Directorate – General Information SocietyITS Systems and Services for the Citizen

Sponsor (Contract Authority) Name/Location: EUROCONTROL EATMP 96, Rue de la Fusée B - 1130 Brussels BELGIUM Telephone: +32 2 729 90 11

TITLE: TOTAL INFORMATION SHARING FOR PILOT SITUATIONAL AWARENESS ENHANCED

BY INTELLIGENT SYSTEMS (TALIS 1)

Main-authors R. Ehrmanntraut

Date 12/2004

Pages x + 149

Figures 16

Tables 7

Annexes 3

References 15

Co-authors R. Grosmann, NLR

L. Nunes, SKYSOFT H. Silva, SKYSOFT

G. Francois, THALES Avionics A. Simonin, MODIS

Project CNS-Z-TA

Task No. Sponsor

Period 2001 to 2004

Distribution Statement:

(a) Controlled by: Head of INO (b) Special Limitations: None

Descriptors (keywords): TALIS – SWIM – Air Ground Integration - Software Architecture – System Engineering – Traffic Information System (TIS-C) – Weather Uplink Service – Demonstration Prototype A380

Abstract:

This is the final report of the Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, Phase 1 (TALIS 1) project, which was carried out from September 2001 until February 2004 by a consortium of 5 partners: LIDO, NLR, SKYSOFT, THALES Avionics and EUROCONTROL Experimental Centre (EEC). The project was coordinated by EEC. The total cost of the project was 4.4 Million €, co-financed by 50% by the European Commission, DG-IST, in the context of its 5th framework for research and development.

The objective of the project is to investigate the viability and benefits of adopting an approach based on standardised architectures to provide for pilot situational awareness resulting in a safer and more efficient air traffic management process involving interactions between the ground and the air to bring benefits to the travelling public.

by intelligent system (TALIS 1) EUROCONTROL

Project CNS-Z-TA - EEC Report No. 398 v

Total information sharing for pilot situational awareness enhanced

EXECUTIVE SUMMARY

The Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, Phase 1, (TALIS 1) project was carried out from September 2001 until February 2004 by a consortium consisting of 5 partners: LIDO, NLR, SKYSOFT, THALES Avionics and EUROCONTROL Experimental Centre (EEC). The project was co-ordinated by EEC. The total cost of the project was 4.4 Million €, co-financed by 50% by the European Commission, DG-IST, in the context of its 5th Framework for Research and Development.

TALIS makes an innovative approach to contribute to the improvements of efficiency and safety of the overall air traffic system and proposes state-of-the-art technological solutions to further strengthen the pilots' decision role, in supplying him/her with ambient intelligence through total information sharing. TALIS also addressed the role of standards and of avionics certification issues, to improve the service available to European citizens.

The objective of TALIS is to investigate the viability and benefits of adopting an approach based on standardised architectures to provide for pilot situational awareness resulting in a safer and more efficient air traffic management process involving interactions between the ground and the air, to bring benefits to the travelling public and to enhance the competitiveness of European industry. TALIS investigated an innovative software architecture that allows for quick, easy and cheap integration of aeronautical technologies using commercial-off-the-shelf components, in order to accelerate the long system developments especially for air-ground integration, and herewith become a cornerstone for future information sharing between all distributed partners and in particular the aircraft. The task of the software architecture is to ease integration for air-ground datalink technologies, to provide a component-based middleware infrastructure, to allow for dynamic discovery of components in the system (therefore its name Federation Architecture), and to use commercial-off-the-shelf components. Two innovative applications for the flight deck that improve pilot situational awareness are developed: uplink of meteorological information and of traffic information.

TALIS 1 is an innovating project, on several levels. It applies the Services-Concept for global, interoperable and dynamic availability of aeronautical services; it creates a Federated Architecture for dynamic and component based service-infrastructures; it integrates the principles of a flight deck browser for information; it conceives applications for increased pilot situational awareness with the Traffic Information Service in contract mode and the Weather Service; it innovates with a Total Information Sharing Protocol, ready for standardisation; it studies contextual information for an intelligent treatment of the information; it creates an OPEN systems to enable a community process; it is based on commercial-off-the-shelf (COTS) software for cheaper and more reliable systems; and last not least it uses Java portability for very dynamic, self-healing systems.

For demonstration and verification of these features, the TALIS 1 project developed a prototype at the premises of THALES Avionics in Toulouse, which shows a cockpit simulator with the enhanced capabilities, a Java-based TALIS infrastructure operating the Federated Architecture, and the two initial TALIS application servers.

This report finalises the TALIS 1 project. All major features have been implemented and can be demonstrated. A complete set of documents for user requirements, specification and design are available via the TALIS web site (http://talis.eurocontrol.fr). The project was executed in a difficult context, starting in September 2001 - nevertheless the Consortium is proud to present these results. Continuation is unclear at the moment of editing, but several members of the Consortium have plans to exploit the early results of the project.

http://talis.eurocontrol.fr/

EUROCONTROL by intelligent systems (TALIS 1)

vi Project CNS-Z-TA - EEC Report No. 398


Page intentionally left blank


Project CNS-Z-TA - EEC Report No. 398 vii


TABLE OF CONTENTS

LIST OF ANNEXES......................................................................................................... VIII

LIST OF FIGURES .......................................................................................................... VIII

LIST OF TABLES.............................................................................................................. IX

1. INTRODUCTION...........................................................................................................1 1.1. PROJECT OVERVIEW .................................................................................................. 1

1.1.1. Objectives..........................................................................................................1 1.1.2. Structure ............................................................................................................2

1.2. MAIN ACHIEVEMENTS ................................................................................................. 3 1.3. CONSORTIUM COMPOSITION AND ROLES OF PARTNERS.................................... 3

2. VISION ..........................................................................................................................5 2.1. INFORMATION SHARING - COLLABORATIVE DECISION MAKING – CO-

OPERATIVE ATS........................................................................................................... 5 2.2. TALIS SERVICES CONCEPT........................................................................................ 6 2.3. OPERATIONAL PROJECT GOALS AND OBJECTIVES............................................... 7 2.4. TECHNICAL PROJECT GOALS AND OBJECTIVES.................................................... 7

3. DESIGN.........................................................................................................................9 3.1. APPROACH ................................................................................................................... 9 3.2. PROJECT ORGANISATION ........................................................................................ 11 3.3. METHODS AND TECHNIQUES .................................................................................. 11 3.4. VERIFICATION ............................................................................................................ 12 3.5. VERIFICATION TEST RESULTS................................................................................. 15

4. REALISATION ............................................................................................................16 4.1. PROJECT BENEFITS .................................................................................................. 16 4.2. PROJECT DELIVERABLES......................................................................................... 17

4.2.1. Work Package 1 ..............................................................................................17 4.2.2. Work Package 2 ..............................................................................................18 4.2.3. Work Package 3 ..............................................................................................18 4.2.4. Work Package 4 ..............................................................................................18 4.2.5. Work Package 5 ..............................................................................................18

4.3. THE TALIS DEMONSTRATOR.................................................................................... 19 4.3.1. Hardware And Software Setup ........................................................................19 4.3.2. Demonstration Scenario, Run and Results .....................................................20

4.4. SCIENTIFIC/TECHNOLOGICAL QUALITY AND INNOVATION – PROJECT ACHIEVEMENTS ......................................................................................................... 21 4.4.1. Pilot Situational Awareness .............................................................................21 4.4.2. TALIS Services Concept .................................................................................22 4.4.3. Service Oriented Programming .......................................................................23 4.4.4. Federated Architecture ....................................................................................25 4.4.5. Flight-Deck Browser For Information...............................................................27 4.4.6. Traffic Information Service (TIS-C)..................................................................28 4.4.7. Weather Service ..............................................................................................29


viii Project CNS-Z-TA - EEC Report No. 398


4.4.8. Total Information Sharing Protocol (TISP).......................................................30 4.4.9. Intelligent Systems ..........................................................................................31 4.4.10. Certify-Ability ...................................................................................................32 4.4.11. Unified Process ...............................................................................................33

4.5. CONTRIBUTION TO COMMUNITY SOCIAL OBJECTIVES ....................................... 34 4.6. ECONOMIC DEVELOPMENT AND PROSPECTS...................................................... 35 4.7. PROJECT MANAGEMENT AND CO-ORDINATION ASPECTS ................................. 35

4.7.1. Consortium Performance.................................................................................35 4.7.2. Project Reviews by the EU Project Office .......................................................36 4.7.3. Development Performance (Metrics About Source Code, Use Of COTS, etc.)37 4.7.4. Challenges, Problems And Solutions ..............................................................38 4.7.5. Dissemination ..................................................................................................40 4.7.6. User Forum......................................................................................................41

5. OUTLOOK ..................................................................................................................44 5.1. BENEFITS AND EXPLOITATION ................................................................................ 44 5.2. CARRY ON .................................................................................................................. 47

6. CONCLUSIONS..........................................................................................................48

7. ACKNOWLEDGEMENTS ...........................................................................................49

FRENCH TRANSLATION (TRADUCTION EN LANGUE FRANÇAISE) ..........................51

LIST OF ANNEXES ANNEX A - ACRONYMS................................................................................................................. 56 ANNEX B - REFERENCES............................................................................................................. 59 ANNEX C - Scientific Papers And Publications............................................................................... 61 ANNEX C - 1 ................................................................................................................................... 63 ANNEX C - 2 ................................................................................................................................... 73 ANNEX C - 3 ................................................................................................................................... 85 ANNEX C - 4 ................................................................................................................................... 89 ANNEX C - 5 ................................................................................................................................. 103 ANNEX C - 6 ................................................................................................................................. 113 ANNEX C - 7 ................................................................................................................................. 123 ANNEX C - 8 ................................................................................................................................. 133 ANNEX C - 9 ................................................................................................................................. 141

LIST OF FIGURES Figure 1: Project management plan .............................................................................................. 2 Figure 2: Controller-Pilot Data Link Services................................................................................. 6 Figure 3: Rational tool, USDP and USDP tailored for TALIS....................................................... 10 Figure 4: Overview of the Verification Test Model, example from the Federated Architecture.... 12Figure 5: Lifecycle overview of the Validation Test Model........................................................... 13 Figure 6: Overview of the FA Component Test Model................................................................. 14 Figure 7: Meteo test windows for air (left) and ground (right) ...................................................... 15 Figure 8: DACOTA ...................................................................................................................... 19 Figure 9: Three snapshots of the Navigation Display with Traffic Information............................. 20


Project CNS-Z-TA - EEC Report No. 398 ix


Figure 10: TALIS Federated Architecture External System Overview........................................... 25 Figure 11: FA Technology Framework .......................................................................................... 26 Figure 12: Financial Figures (top-left to bottom-right): a) Cost types, b) cost per partner

per reporting period, c) effort in man*days per partner and reporting period, d) approximation of effort in man*years per partner and reporting period.................... 35

Figure 13: (a) Number of exchanged e-mails on the project blaster, (b) number of minutes from teleconferences, (c) number of work items in Gantt charts per work package..... 36

Figure 14: (a) Cumulative costs of the consortium, (b) Payments by the European Commission, not yet integrating payments to come after project end.......................... 40

Figure 15: TDS System ................................................................................................................. 44 Figure 16: Examples of air-side TDS part of METAR/TAF and Taxi application ........................... 45

LIST OF TABLES Table 1: Verification test results ................................................................................................. 15 Table 2: Work Package 1 ........................................................................................................... 17 Table 3: Work Package 2 ........................................................................................................... 18 Table 4: Work Package 3 ........................................................................................................... 18 Table 5: Work Package 4 ........................................................................................................... 18 Table 6: Work Package 5 ........................................................................................................... 18 Table 7: Recommended Tool Chain........................................................................................... 33


x Project CNS-Z-TA - EEC Report No. 398




Project CNS-Z-TA - EEC Report No. 398 1


1. INTRODUCTION

The mission of Air Traffic Management (ATM) is the safe, orderly and expeditious management of air traffic. The current ATM system operates close its capacity limit in high-density regions, and new concepts are needed to increase system capacity. New operational concepts like Controller-Pilot Data Link Communications (CPDLC) and the Airborne Separation Assurance System (ASAS) promise to increase capacity by a stronger integration of the air and the ground, and the co-operative handling of traffic management between the pilots and the controllers. However, if capacity can be increased, safety must be increased at least at the same pace to increase the performance of the overall system. For safety, it is therefore mandatory to increase the situational awareness of controllers and pilots in harmonisation. Especially the situational awareness of pilots is lacking behind and must be enhanced, because today pilots have very little situational awareness regarding ATM! TALIS is a technical concept that contributes to the increase of Pilot Situational Awareness, and herewith directly to safety, and indirectly to capacity.

The high costs of air-ground integration are a major problem. All technologies that integrate the air and the ground take a long time from research until implementation, due to the high safety concerns and costs for avionics integration, and the necessity for global deployment of infrastructures. E.g. typical implementation times for new technologies are measured in decades, as illustrated by certified GPS approaches in the navigation domain (versus massive GPS use in the general domain, cars and the maritime domain). The TALIS concept targets at shortening the time-to-market of new avionics packages, and herewith reduces the cost of implementation, by providing early benefits coming from an earlier deployment of the operational concepts. The TALIS concept will also attempt to lower the production cost of new packages, making intensive use of commercial-off-the-shelf software (COTS).

The underlying paradigm of the TALIS concept is closely related to the World-Wide-Web (WWW), with a special focus on mobile users. Information everywhere, for everybody, as a function of need, delivered in a framework of tools: services, protocols, and browsers. The principle of the WWW is further extrapolated for safety-related business cases.

This document is the Final Report of the TALIS Project, phase 1, which was carried out from September 2001 until February 2004. It summarises the objectives of the project, its expected benefits, the project achievement, and gives a view of the conduct of the project.

1.1. PROJECT OVERVIEW

The TALIS 1 project was carried out from September 2001 until February 2004 by a consortium consisting of 5 partners: LIDO, NLR, SKYSOFT, THALES Avionics and EEC. The total cost of the project was 4.4 Million €, co-financed by 50% by the European Commission, DG-IST, in the context of its 5th Framework for Research and Development. The project was co-ordinated by EEC.

1.1.1. Objectives

The objective of TALIS is to investigate an innovative software architecture that allows for quick, easy and cheap integration of aeronautical technologies using commercial-off-the-shelf components, in order to accelerate the long system developments especially for air-ground integration, and herewith become a cornerstone for future information sharing between all distributed partners and in particular the aircraft.


2 Project CNS-Z-TA - EEC Report No. 398


The task of the software architecture is to ease integration for air-ground datalink technologies, to provide a component-based middleware infrastructure, to allow for dynamic discovery of components in the system (therefore its name Federation Architecture), and to use commercial-off-the-shelf components. Two innovative applications for the flight deck that improve pilot situational awareness are developed: uplink of meteorological information and of traffic information.

1.1.2. Structure

Project management was conducted in 5 work packages.

• WP1 Project Management Provide for the planning, management, risk mitigation, control and completion of the project based upon the Unified Software Development Process. Leader of WP1 is EEC.

• WP2 High-Level System Requirements Define the architecture and application requirements to be used as the baseline for Specification, Design and Implementation activities to be conducted in WP3 and WP4. Leader of WP2 is NLR.

• WP3 Federated Architecture Specify, design and implement the Federated Architecture software. Leader of WP3 is EEC.

• WP4 Application and Services Specify, design and implement the Traffic Information and the Meteorological Services. Leader of WP4 is SKYSOFT.

• WP5 Avionics Certification Address the avionics certification issues related to the use and deployment of the innovative technologies specified and/or involved in the results of WP3 and WP4. Leader of WP5 is THALES Avionics.

WP1Project Management PlanDetailed Gantt ChartQuality Assurance PlanSoftware Acceptance Plan

WP2Federated Architecture RequirementsHigh-Level Application RequirementsDemonstration Plateform Requirements

WP3Federated Architecture DocumentsFederated Architecture SoftwareTALIS Standard Document

WP4Traffic Information Service DocumentsTraffic Information Service Software

Meteorological Service DocumentsMeteorological Service Software

WP5COTS Analysis and Certification ReportAirborne Architecture Requirements

… provides input material to …

Figure 1: Project management plan




1.2. MAIN ACHIEVEMENTS

TALIS 1 is an innovating project, on several levels. More details on innovation and achievements are discussed in section 4, and can be summarised as:

• TALIS conceives the Services-Concept for global, interoperable and dynamic availability of services;

• TALIS creates a Federated Architecture for dynamic and component based service-infrastructures;

• TALIS integrates the principles of a flight deck browser for information; • TALIS conceives applications for increased pilot situational awareness; • TALIS innovates with the Traffic Information Service in contract mode; • TALIS innovates with the Weather Service; • TALIS innovates with a Total Information Sharing Protocol, ready for standardisation; • TALIS studies contextual information for intelligent systems; • TALIS creates an OPEN systems to enable a community process; • TALIS is based on commercial-off-the-shelf (COTS) software fro cheaper and more

reliable systems; • TALIS uses Java portability for very dynamic, self-healing systems.

For demonstration and verification of these features, the TALIS 1 project developed a prototype at the premises of THALES Avionics in Toulouse, which shows a cockpit simulator with the enhanced capabilities, a Java-based TALIS infrastructure, and the two initial TALIS application servers.

1.3. CONSORTIUM COMPOSITION AND ROLES OF PARTNERS

The TALIS project was conducted by a consortium comprised of four European companies from four different European member states, and a European research centre. Consortium members are:

Lido GmbH Lufthansa Aeronautical Services

Lido represents an airline and brings expertise in the acquisition, storage and distribution of information related to airline operations and meteorological services.

National Aerospace Laboratory NLR

NLR represents a research agency and brings expertise in the definition of high-level requirements for the TALIS applications and architecture.




THALES Avionics (formerly called Sextant)

THALES represents an avionics equipment manufacturer and brings expertise in system integration to cockpit, ATN communication systems and certification of products to be used in aircraft.

Skysoft Portugal S.A.

Skysoft represents innovative SMEs with a high dynamic growth and brings expertise in the development of cockpit systems.

EUROCONTROL Experimental Centre EEC

EEC, acting as the project co-ordinator of the consortium, represents a European research centre and brings its expertise in the definition of the required architecture and application, and ATN communication systems.




2. VISION

The TALIS project introduces a high degree of innovation, with a vision for future systems on the operational and technical level.

2.1. INFORMATION SHARING - COLLABORATIVE DECISION MAKING – CO-OPERATIVE ATS

Information Sharing is a guiding principle in which the management of an information-rich environment will be key to the ATM concept. It is a support process which is essential to all ATM and which provides the foundation for subsequent decision making processes. It deals with the logistics of system-wide information management (SWIM) and sharing in a distributed environment of information suppliers and consumers which will allow the ATM community to conduct its business in a safe and efficient manner. Conceptually, Information Sharing covers a broad spectrum of issues, including:

• Continuously tracking the actors’ information needs and their willingness and ability to share information;

• Continuous management of the quality and interoperability qualities of the shared information in accordance with defined quality standards;

• Continuous management of an adequate supply of updates to the shared information; • Management of the dissemination process customised to each information consumer’s

needs; • Management of information security; • Ensuring optimum usage of storage and communication resources; • Management of information ownership, cost, pricing and liability.

Information Sharing results in the timely distribution of validated, current and relevant information to the appropriate destinations of all of the actors who have the authority to access it. This can range from information needed in the strategic planning phases, through that needed by controllers on the day of operation in real-time, to the final archiving of data so that it can, in turn, be used for future strategic planning. Information-management enables two of the key elements of ATM in the future - Information Sharing and Collaborative Decision-Making (CDM) [3].

Co-operative Air Traffic Services (COOPATS) [1] is expected to progressively enable a transition from current “conventional” ATM towards a new paradigm of ATM with increased involvement of the flight deck, enabled by new technologies and procedures, to provide the increase in productivity necessary to cope with the forecasted air traffic demand. It includes controller-pilot co-ordination based on Controller-Pilot Data Link Communications (CPDLC) and current ICAO procedures, as well as different degrees of delegations of tasks to the flight deck, up to autonomous aircraft operations generally known as Airborne Separation Assurance System (ASAS) [4].

The current definition of COOPATS contains a number of CPDLC and ASAS services for all flight phases. In addition to the many CPDLC-related services presented in Figure 2, there are a number of co-operative services for airborne separation assurance. They span from applications for situational awareness, to spacing-, separation- and self-separation applications. In the U.S. the concept of Distributed Air-Ground Traffic Management (DAG-TM) has an even increased number of applications that enable the free-flight concept [2].




FlightEvents

ATMPhase

Profile

Units andFacilitiesInvolved

Data linkServices

PlannedFlightData

DayPrior

Day ofOperation

RequestStart-Up Take-Off Cruise Level

ParameterfromDestination

Landing

StrategicPlanning

Pre-TacticalPlanning

TacticalPlanning

GroundMovement

Climb-Out En-Route Arrival Post-Arrival

IFPSCFMU

IFPSCFMUATM FMPsAMCs

IFPSCFMUFMPs

TWRAPPACCIFPSFMPs

APPACC(s)IFPSFMPs

ACC(s)IFPSFMPs

ACC(s)APP

TWR

- ACM- ACL- CAP- DCL- DSC- PPD- FLIPCY- DYNAV

- D-FIS

- COTRAC- SAP

Figure 2: Controller-Pilot Data Link Services

TALIS integrates the objectives of Information Sharing, or SWIM, and the operational applications from COOPATS and DAG-TM. It conceives an enabling structure that should shorten implementation times, and give a number of powerful services to its driving operational concepts: The TALIS Services Concept.

2.2. TALIS SERVICES CONCEPT

The TALIS Services Concept is the fundamental principle of TALIS: a component-based software architecture where service-providers can publish and offer their services on a dynamic basis, and service-consumers can discover these published services on the fly, and use them. This is known as dynamic service-discovery and dynamic service-binding. As service-providers may be complicated constructs they may consume yet other services, and chains of service-users/service-providers are created. When several services bind together to accomplish some common task, these are called federations of services. The federation is organic because its form may vary as a function of events that come from inside or outside the federation.

This gave the name to the software architecture that was developed in the TALIS project: The Federation Architecture (FA). The FA with its potential for dynamic service discovery, and service-binding, bears two other main properties: the system becomes self-forming and self-healing. That is of uttermost importance for Air Traffic Management, because safety considerations are of very highest importance.




Self-Forming And Self-Healing System

The self-forming character is the simple dynamic discovery and binding of components, where publishing and discovery may occur in any order. I.e. the service-consumer may ask for discovery of a service before the service-provider announced its service. It waits until it is informed by the FA that a service-provider published its service. It can then get the service: the system is self-forming. The service-consumer may decide to look for another service-provider upon some specified events, e.g. if a service provider fails to deliver a service for whatever reason, is down, or the service-consumer has changed location etc. Then the federation is re-created using different components to build the same application: the system is self-healing.

On the counter side, the very dynamic behaviour leads to security-related problems, which have to be dealt with. Therefore the FA proposes security services, and each component that wants to federate has to authenticate itself, and communications is encrypted between all components.

2.3. OPERATIONAL PROJECT GOALS AND OBJECTIVES

The operational goals of the TALIS project are on different levels: architecture, operations and certification.

1. To reinforce need for more responsiveness (new approach, new technologies) Investigate, within the framework of air-ground and ground-ground digital aeronautical communications, the viability and benefits of adopting an approach based on service oriented architecture and distributed systems.

2. To investigate a Co-operative ATS (COOPATS) [1] and DAG-TM [2] enabling technology By providing an architectural software environment allowing for advance services to be easily built upon more primitive services, investigate an enabling technology for the deployments of COOPATS and DAG-TM concepts.

3. To address certification issues Investigate the issues associated with certification of the proposed architecture by assessing the potential impacts of the involved technologies on the methods and development and deployment processes.

It should be noted that TALIS 1 project was set up as a first phase of a bigger project, and that the validation of the operational objectives is not part of the TALIS 1. Instead, TALIS 1 focussed on the creation and verification of the technical platform.

2.4. TECHNICAL PROJECT GOALS AND OBJECTIVES

The technical objective of the TALIS 1 project is to conceive and verify a demonstration platform, which shows the features of the system:

1. To demonstrate the Federation Architecture The demonstration platform integrates the following features: self-forming and self-healing component-based system, security services, and a Connector architecture for the Aeronautical Telecommunications Network (ATN). It is based on Commercial-Off-The-Shelf software.




2. To demonstrate 2 TALIS applications Two initial applications for the flight deck demonstrate the services concept:

• And extended traffic information service that visualises traffic related information of the own ship and adjacent aircraft like position, flight plan, trajectories, medium-term conflicts. This information is presented on the navigation display, and the pilots can interact with it.

• Meteorological information from the ground is shown on the Multi-Cockpit Display Unit.

It should be emphasized that TALIS 1 project was set up as the first phase of a bigger project, and that successive phases of the project should increment the functions:

• An extended integration of air-ground telecommunication technologies like GSM, GPRS, Wireless LAN, VDL4, and UAT.

• More applications for Collaborative-Decision Making and more functions for the Traffic Information Service.




3. DESIGN

The design process played an important role in the project. This section describes the design process that was adopted in the project. The objective was to innovate and to apply a user-centric, iterative, incremental and architecture-centric process. The choice was made to apply the Unified Software Development Process (USDP), which covers the entire life-cycle of a product. TALIS being a development project covers only the development parts of that life-cycle, which are the specifications, design, implementation and verification. The challenge of the design was to cover four levels of requirements: aeronautical applications, architecture, technology, and to apply a common design process all the way through.

Aeronautical Applications:Traffic-Information Service (section 4.4.6) and Weather Service (section 4.4.7) are typical aeronautic applications concerning safety requirements that apply for the ground side and airborne side. The challenge was to design these applications combining the high-level standard requirements for aeronautical applications with the TALIS Services (section 4.4.1) concept. The design had to cope with requirements for distribution, self-healing systems, information sharing, and networking.

Architecture:The Federated Architecture (FA) (section 4.4.4) is the middleware which manages all the TALIS system components services. These services are more than end-to-end capabilities. These services allow each system component to share information from multiple system resources in an abstract and seamless way. The FA separates the concerns for application implementers in providing high-level abstractions for complex services like component management and networking. This had to be reflected in the design.

Design Process:The design process was the Unified Software Development Process (USDP), which is tailored for object oriented programming using the Unified Modelling Language (UML). The USDP is a consistent, uniform, engineered and visual approach in the process of developing software based systems - and aims to bridge various stakeholders involved in the process: the end customer, the system integrator and the component developer.

Technology:The programming language of the project was defined being Java. The design process had to cope with the specific requirements of this language.

3.1. APPROACH

Following from the aspects above introduced, the first step was to agree with the specific specification and development guidelines which would provide a detailed reference process for all partners. The process adopted by the Consortium was subject of discussion and training at EEC Software Engineering Unit and is shown in Figure 3. It maps the theoretical phases of the USDP, which are user requirements capture, analysis, design, implementation and test, on more specific artefacts that would be developed by the TALIS team, and which are the requirements model, the architectural model with its sub-models conceptual, logical, and execution architecture, a component model, an implementation model, an integration model, and finally a verification model. The TALIS artefacts are explained in more detail:




Rose Rational Model Structure Use Case View Logical View Component View

USDP [theoretical] User Requirements

Capture Analysis Design Implementation Test

USDP applied to TALIS Architecture Model Implementation Model Integration

Model Requirements Model (WP2 activities) Conceptual

Architecture Logical

Architecture Execution

Architecture

Component Model Source

Code Unit Tests Container

Verification Model

- Analysis Packages - Analysis Classes - Use-cases realisation - Analysis - Architecture Description

Analysis Model - Design Classes- Use-cases realisation - Design - Design Subsystem, - Interface - Architecture Description

Design Model- Architectural implementation - implemented software components - tested software units

Implementation

Figure 3: Rational tool, USDP and USDP tailored for TALIS

Requirements Model:From the requirements capture results the requirements model, which is a detailed and schematic representation of the system, its context, functional requirements, and system quality requirements. The artefact includes use cases diagram and use cases realisation with sequence diagrams. For requirements analysis, the behaviour of a system may be expressed as services, tasks or functions the system is required to perform, independently as much as possible of any kind of system component architecture. It is crucial to provide the requirements to a level of abstraction that is relevant to the architecture, since the architecture must support the functional requirements of the system. This leads to the elaboration of software requirements, which include definitions for use-cases with their full description: names, actor, basic, alternative, exceptions flow of Events, pre- and post conditions etc.

Architectural Model:The architecture model is built on a three step basis: conceptual, logical and execution architecture.

• The conceptual architecture takes as input the requirements analysis from the requirements model, where software requirements are translated in detailed use cases, a first draft of class diagrams, a first draft of components diagrams, component interfaces and sequence diagrams. The uses cases include now important pieces of the system architecture called components.

• The logical architecture defines the final analysis definition of the class interfaces, the final analysis interface specification and final analysis component view.

• The execution architecture finalizes the analysis with a software prototype of all analysis components.

Component Model:Whilst the architecture is a description of functional and qualitative requirements, the component model imposes the structure of the system. Moreover, non-functional requirements are taken into account because programming issues become increasingly relevant. Finally, automatic code generation provided by the Rational Rose tool is used for design classes, design use cases realization, design interfaces, design sequence diagrams, and design component diagrams.




Implementation Model:The implementation model is the source code. It started on the automatically generated code by the Rational Rose tool. A normal Java IDE was used to produce and review the implemented code.

The following activities are distinguished:

• The UML package and class specifications were developed on basis of the design use-cases;

• The Java code was developed on basis of the UML package and class specifications; • The Java packages and objects were constructed from the Java code; • The software components were constructed from the Java packages and objects; • The TALIS prototype was constructed from the software components; • The TALIS “product” was composed from the prototype and documentation.

Unit Testing:

For unit testing a Java IDE was used enhanced with Junit feature to produce unitary testing of classes.

3.2. PROJECT ORGANISATION

Each design sub-process ran through internal review cycles, following the quality procedures of the project. The project also defined two major increments for the Federated Architecture and Traffic Information Service application, whereas the Weather application only ran through one increment due to management constraints.

The duration of the design process for first increment, built #1, took approximately one year, whereas the duration for built #2 took only 4 months. This illustrates that the Consortium learnt the iterative process, where the first cycle was still an old-style V, the second one was already an increment in the philosophy of the Unified Process, the Third cycle would have been a real application of the theory.

3.3. METHODS AND TECHNIQUES

All the TALIS development process was based on the USDP process, here after find some of methods and techniques used on the different stages:

Requirements: • UML in Rational Rose

Architectural Model: • UML in Rational Rose

• Rational Rose code generation for software prototype

Design Model: • UML in Rational Rose

• Rational Rose code generation

Implementation Model:

• Java standard edition

• Java enterprise edition

• Openwings

• Junit




3.4. VERIFICATION1

The TALIS Verification Test Model (VTM) specified the validation test approach, validation test cases, and component test cases of the TALIS system from a user's point of view. The tests are conducted to determine whether the TALIS prototype satisfied the TALIS requirements or not. These requirements were specified in the TALIS Federated Architecture Requirements [5] document.

Figure 4 depicts an overview of the test model. The following phases and activities are distinguished:

• In the requirements phase, the candidate requirements, supplementary requirements, requirements use-cases, and business use-cases are specified.

• In the design phase, the design use-cases are developed on basis of the requirements use-cases.

• In the implementation phase, the software components and the prototype are developed on basis of the design use-cases.

• In the test phase, the software components are tested against the design use-cases and the prototype is tested against the requirements and business use-cases. The former tests are called component tests; the latter tests are called validation tests.

FASupplementaryRequirements

FABusiness

Use-Cases

FASystem

FAValidation

Tests

FACandidate

Requirements

FARequirements

Use-Cases

FADesign

Use-Cases

FAComponents

FAComponent

Tests

Val

idat

ion

Ver

ifica

tion

RequirementsPhase

ImplementationPhase

DesignPhase

TestPhase

Figure 4: Overview of the Verification Test Model, example from the Federated Architecture

1 Verification is used as synonym for validation, which is used as described in software validation, and not related to MAEVA or other aeronautical validation efforts.




Figure 5 depicts a lifecycle overview of the VTM model. It provides more details about the implementation and test phases.

• The Java packages and objects were tested against the UML package and class specifications. These tests were called Unit Tests and are executed by the development team.

• The software components were tested against the design use-cases. These tests are called the Component Tests and are executed by the respective development team.

• The TALIS prototype was tested against the requirements and business use-cases. These tests are called the Verification Tests and are executed by the validation team.

• The TALIS “product” was tested and reviewed against the candidate and supplementary requirements. These tests and reviews are called Acceptance Tests and were executed by the TALIS consortium. The European Commission may witness or participate in the FA Acceptance Tests.

FACandidate Requirements

Supplementary Requirements

FARequirements Use-Cases

Business Use-Cases

FADesign Use-Cases

UMLPackages And Classes

FAProduct

FASystem

FAComponents

JavaPackages And Objects

Acceptance

FA Acceptance Tests

Validation

FA Validation Tests

Verification

FA Component Tests

FAJava Code

Verification

FA Unit Tests

Figure 5: Lifecycle overview of the Validation Test Model

Figure 6 depicts an overview of the component test model for the Federated Architecture. Each FA requirements or business use-case is detailed by one or more FA design use-cases. Each FA design use-case is implemented by one or more FA software components. The FA prototype was constructed from the FA components.




FA S

yste

m

FA ComponentTest Environment 1

FA ComponentTest Driver 1

FA Component 1

FA ComponentTest Environment 2

FA ComponentTest Driver 2

FA Component 2

FA ComponentTest Environment Z

FA ComponentTest Driver Z

FA Component Z

FA ComponentTest Stubs 1

FA ComponentTest Stubs 2

FA ComponentTest Stubs Z

FA ComponentTest Cases 1

FA ComponentTest Cases 2

FA ComponentTest Cases Z

FA DesignUse-Case 1

FA DesignUse-Case 2

FA DesignUse-Case Y

FA RequirementsAnd Business Use-Case 1

FA RequirementsAnd Business Use-Case 2

FA RequirementsAnd Business Use-Case X

Ver

ifica

tion

Figure 6: Overview of the FA Component Test Model




3.5. VERIFICATION TEST RESULTS

TALIS 1 is composed of three packages: Federated Architecture, Traffic Information Service and Weather Service. The Table 1 the test results for each of the packages for unit, component, verification and acceptance tests.

The Table 1 shows some metrics that resulting from validation testing.

Table 1: Verification test results

Metric Java shared software TALIS software

# classes 5620 102

# methods 61207 722

# interfaces 1000 32

Lines of code 1088174 14536

# FA component test cases -- 16

# FA validation test cases -- 29

# change request (project) -- 41

Verification of MET application is based on the description and reports given on the MET database. A scenario was developed for MET verification which enables a realistic supply of meteorological data to TALIS system, being the MET-G (ground side) the entry point of the TALIS system. The scenario is a flight from Nice to Munich. Figure 7 illustrates the test environment for the Weather service.

Figure 7: Meteo test windows for air (left) and ground (right)




4. REALISATION

4.1. PROJECT BENEFITS

The high degree of innovation that the TALIS project produces can be seen on the four different axes: technology, architecture, new operational applications, and project management. Each level of innovation brings specific benefits to the users:

Technology A major benefit of the technologies used in TALIS comes from code mobility enabled by Java e.g. and generic viewers e.g. web browsers, which will enable high reactivity of the system to new market opportunities. Today, the opportunities for improvements in air transport are very often limited by the static airborne avionics systems, its very long life cycle and high cost for retrofit. Code mobility and generic viewers will change this and enable a highly dynamical system, which can evolve as market opportunities evolve, without modifications of the airborne system, and without delay.

The use of state-of-the-art technology (Java, JINI, OPENWINGS) for the aeronautical sector is new. To use code mobility technology for a highly flexible and dynamic system is also new. Applying the paradigm of mass-market commercial-off-the-shelf for the avionics is new.

Architecture The generic TALIS architecture enables other applications with short time-to-market, to the benefit of the air transport sector. TALIS proposes an OPEN architecture that should contribute to smaller total cost of systems.

The architectural innovation is very high, and the applied principles of distributed and federated software components, and the needed architectures to support these, con-tribute to other high-end research efforts in general Information Technology research. The generic TALIS architecture will enable almost unlimited extensions for additional applications, and will allow to other third parties to add value.

New Operational Applications

The domain of Air Traffic Management will benefit from the development of the initial operational applications, Traffic Information Service and Weather Service. The Traffic Management Service (section 4.4.6, TIS-C) is a cheaper and possibly better alternative to TIS-B, the current enabling paradigm in ADS-B concepts. In addition to being cheaper, it increases the possibility for additional functions with open-ended extend-ability, which leads to shorter implementation times for concepts on the air-ground data link, and herewith contributes to earlier increases in safety and capacity.

The Weather uplink service is less innovative, but a cornerstone for safe and efficient flights. The full benefit of this application for the use in Air Traffic Management will be in combinations with other services, e.g. tactical weather-rerouting done by the flight crew in co-operative procedures.

Project Management

The innovative character of the project management will lead to benefits for the consortium members and for the project cost and time efficiency. As the iterative and incremental approach eases the feedback of early results into deliverables, the efficiency of the project regarding cost and delay is increased. Each partner will then benefit on the know-how achieved through this innovation. The European citizen profits in getting more results with less investment.




The Unified Software Development Process contributed to higher success of project deliveries due to the iterative and incremental approach. The deliverables are also closer to the analysts’ intentions, facilitating the trace-ability.

The iterative and incremental management process has proved to be especially useful for R and D projects, as early results could relatively easily influence the later work. That means that the management process was not only beneficial as a whole, but is especially relevant for this type of project.

4.2. PROJECT DELIVERABLES

The public TALIS consortium deliverables can be found on the project web site (http://talis.eurocontrol.fr). The consortium decided to include design in the form of UML models as public deliverables, which is unusual, to reflect the wish to promote OPEN system principles to help the aeronautical community (and the tax paying citizen) to prevent duplication of effort. Only the deliverables in the form of software are private deliverables to the consortium. Deliverables are grouped by work package:

4.2.1. Work Package 1 Table 2: Work Package 1

ID Deliverable Name Part Description

1 / 5 Management Plan - Consortium Level

2 / 5 Work Package 2 Specification Document



D1.1.1 Project Management Plan (PMP)


D1.1.2 Risk Management Plan (RMP) 1 / 1 Risk Management Plan

D1.1.3 Detailed Gantt Charts 1 / 1 Detailed Gantt Charts

D1.1.4 Management Reports (quarterly) 1 / 9 September 2001 - February 2002

2 / 9 March 2002 - May 2002

3 / 9 March 2002 - August 2002

4 / 9 September 2002 - November 2002

5 / 9 September 2002 - February 2003

6 / 9 March 2003 - May 2003

7 / 9 March 2003 - August 2003

8 / 9 September 2003 - November 2003

9 / 9 September 2003 - February 2004

D1.1.5 Project Presentation 1 / 1 Project Presentation

D1.1.5 Final Report 1 / 1 Final Report (Not Yet Available)

D1.2.3 Publication over Web-site 1 / 1 Publication over web-site

D1.2.4 Dissemination and Use Plan (DUP) 1 / 1 Dissemination and Use Plan






4.2.2. Work Package 2

Table 3: Work Package 2


D2.1 Application Requirements 1 / 1 High-Level Application Requirements

D2.2 Federated Architecture Requirements 1 / 1 Federated Architecture Requirements

D2.3 Verification Platform Requirements 1 / 1 Verification Platform Requirements





1 / 4 FA Reference Document (Analysis)

2 / 4 FA Interface Control Document

3 / 4 FA Architecture & Design ModelD3.1 Federated Architecture Document

4 / 4 FA Verification Test Model

D3.2 Federated Architecture Software 1 / 1 FA Software

D3.3 TALIS Standard Document 1 / 1 TALIS Standard Document




1 / 4 MET Architecture Document (Analysis)

2 / 4 MET Interface Control Document (ICD)

3 / 4 MET Architecture & Design ModelD4.1 Critical Weather Information Update (MET)

Document

4 / 4 MET Verification Test Model

D4.2 Critical Weather Information Update (MET) Software 1 / 1 MET Software

1 / 4 TIS Architecture Document (Analysis)

2 / 4 TIS Interface Control Document (ICD)

3 / 4 TIS Architecture & Design ModelD4.3 Traffic Information Service (TIS) Document

4 / 4 TIS Verification Test Model

D4.4 Traffic Information Service (TIS) Software 1 / 1 TIS Software




D5.1 COTS Analysis and Certification Report 1 / 1 COTS Analysis and Certification Report

D5.2 Airborne Architecture Recommendations 1 / 1 Airborne Architecture Recommendations




4.3. THE TALIS DEMONSTRATOR

The TALIS Verification Platform is a test, verification, and demonstration environment for the TALIS Federated Architecture and the two TALIS 1 applications. It simulates the behaviour of the TALIS context (real world) as required to test and demonstrate the architecture and applications.

The development process for the demonstrator has been identical to the process for architecture and applications, but restricted to a requirements and deployment model, because the demonstrator implements no additional software.

4.3.1. Hardware And Software Setup

The TALIS Verification Platform is not constructed from scratch and is based on existing products that are enhanced and improved for TALIS purposes. The demonstration platform incorporates the following facilities, interfaces, and data:

• Cockpit display facilities is part of the rapid prototyping platform DACOTA at TAHLES Avionics. The used displays are the Navigation Display, and the Multi-Cockpit Display Unit (MCDU) as depicted in Figure 8.

• Synchronised recorded radar data comes from a log from a fast time ATC simulator (RAMS), which are converted into the XML format that is used for the TALIS interfaces.

• Synchronised recorded weather data comes from a log from the LIDO database.

• Aeronautical Telecommunications Network (ATN) data-link facilities are external components provided by THALES Avionics, together with the Java ATN data-link Application Programming Interface (API).

• The TALIS Federated Architecture and applications.

Hardware is set up to use four PCs with one dedicated PC for the ATN air and ground side respectively, and one PC for the rest-of-the-system air and ground sides respectively. A user manual has been produced for the reproduction of the setup [18].

Navigation Display

MCDU - RMP

Navigation Display

MCDU - RMP

Figure 8: DACOTA




Figure 9: Three snapshots of the Navigation Display with Traffic Information

Some interesting statistics of the demonstrator:

Raw Data Verification Platform

Number of requirements 17

Number of use-cases 36

Number of software requirements Not relevant

Number of analysis classes: - classes: - actors: - interfaces:

Not relevant 10 4

Number of design classes Not relevant

Number implementation classes Not relevant

Total number of lines of code Not relevant

Number of test cases Not relevant

4.3.2. Demonstration Scenario, Run and Results

The demonstrator is placed at THALES Avionics in Toulouse, and integrates into the DACOTA rapid prototyping cockpit.




4.4. SCIENTIFIC/TECHNOLOGICAL QUALITY AND INNOVATION – PROJECT ACHIEVEMENTS

The TALIS project was striving for high innovation and scientific and technological excellence. There are a number of innovations that make the value of the project and where the most important ones are enumerated in this section. Each innovation is described, the degree of innovation is explained, the result that the project produced is given, and finally recommendations for future work are given.

4.4.1. Pilot Situational Awareness

Description:

The operational objective and goal of the TALIS project is to increase Pilot Situational Awareness with the help of intelligent applications. Pilot Situational Awareness is a cornerstone and mandatory if functions, tasks and responsibilities are delegated from the ground traffic management system to the flight deck. The functions that are needed to support the flight deck in the procedures of the new co-operative and collaborative concepts is of different nature:

• A basic functionality is the increased pilot situational awareness needed to evaluate the need for action in co-operative processes, and monitor the implementation of manoeuvres. Here the flight deck is the drain for all kind of information from environment and ATC tactical data, e.g. the surrounding aircraft identification, position and velocity, clearances for the own ship and potentially also for other surrounding aircraft, airspace status information like dynamic route information, congestion or special use airspace, meteorological information for all flight phases, airport approach slotting, dynamically contributed SID and STAR, runway identification, runway visual range, taxi routing information, maps, gate management and much more.

• Decision support and decision making is functionality that traditionally involves the human, typically for controller-pilot exchanges and pilot-airline operator exchanges. In the future these decision processes will increasingly rely on digital information exchanges and protocols like CPDLC, and evolve towards at least triangular processes that include the pilot, controllers, airline operators, airport- and military control. Other types of decision support tools for conflict prediction, prevention and resolution will be supported by tools provided those reach approximately the capacity of humans.

• Future concepts foresee new logistics functions beyond flow management, an evolution in the cockpit in the sense that the pilot will be involved in air traffic flow processes, from pre-flight planning at the last minute, to in-flight tactical flow management. For the airline operations side the pilots’ role will evolve to higher anticipation in airline fleet management, and passenger flow support.




Innovation:

The current definitions of the driving operational concepts COOPATS and DAG-TM have a limited vision of situational awareness, the enablers being limited on current technologies for ADS-B, TIS-B and FIS-B. TALIS, however, with its Services Concept and its multitude of technical enablers and integration technologies for the air-ground link, goes far beyond these possibilities. The TALIS services do not only enrich the current set of services, but their inherent extend-ability creates an entire new scope of pilot situational awareness. That means that much more services can be made available to the flight, with more and often better information than what is currently proposed, and with more intelligent treatment of this information, because the context of the target aircraft is better understood with more available information. One example is the treatment of situational information when a medium-term conflict occurs, as described in section 4.4.5.

Results:

The TALIS 1 project selected a limited number of initial services to demonstrate the overall concept: Traffic Information Service and Weather Service. The Traffic Information Service includes a number of traffic-related information that is available on the ground and sent to the flight deck upon request: Aircraft positions in volumes around the aircraft, aircraft trajectories, aircraft flight plans, conflicting aircraft, and the position of adjacent aircraft at the moment of conflict. Different filters can be applied on this information, e.g. the “ADS gap-filler” filter only sends position information of aircraft that are not equipped with ADS-B. The flight deck can also interactively browse for information, see section 4.4.5.

Future Work:

Some basic operational assumptions need to be validated. This work was not carried out in TALIS phase 1, which only concentrates on system conception and prototype implementation.

• Do the additional TALIS services contribute to an increased situational awareness? • Which services are beneficial? • Investigate further combinations of Traffic and Weather Services, e.g. for tactical re-

routing. • Are new services useful, e.g. for surface movement guidance, for tactical flow like up-

linked arrival lists, metering-point arrival lists etc.?

4.4.2. TALIS Services Concept

Description:

The Services Concept was introduced in section 2.2 as a basic principle of TALIS.

Innovation:

The TALIS Services Concept is highly innovative, and a possible pre-cursor of what the common mass-market will produce for mobile, context-centric users of the Internet. Its vision is beyond current paradigms of mobility and interconnection, in that it proposes a framework of dynamically connecting services as a function of the users’ behaviour.




Results:

The demonstration of the TALIS FA (section 4.4.4) and the application services (section 4.4.3) proved that the dynamic service-discovery and service-binding is feasible with the underlying commercial-off-the-shelf software package called OPENWINGS (http://www.openwings.org). The biggest size of a federation for a single function (application) was 6 services . This result is important because it shows that the proposed federation architecture could be a potential cornerstone for future system standardisation, once the operational benefits have been proved.

Future Work:

Further validation of the technical concept should include:

• Extensions of the architecture to include web-services, possibly based on Enterprise Java Beans (EJB) technology or equivalent.

• The use of an XML-based discovery, possibly using a real mass-market search engine like Google.

• System developers adopted the paradigm of service-oriented programming, at all levels of conception. It may be useful to have conventions for service hierarchies to separate modules from components from applications from systems etc.

4.4.3. Service Oriented Programming

Description:

Service-Oriented Programming (SOP) is the translation of the TALIS Services Concept into a technical concept. SOP is the basic paradigm for business-to-business applications. Service-oriented computing contains components that publish and use services in a peer to peer manner. In SOP a client is not tied to a particular server and service providers are all treated equivalently.

The following architectural elements define Service-Oriented Programming:

• Contracts – An interface that contractually defines the syntax and semantics of a single behaviour.

• Components – Third party, reusable, deployable computing elements that are independent of platforms, protocols, and deployment environments.

• Connectors – A connector encapsulates the details of transport for a specified contract. It is an individually deployed element that contains a user proxy and a provider proxy.

• Container – A service that can run components while managing their availability and code security.

• Contexts – A context for deploying plug and play components, that prescribes the details of installation, security, discovery, and lookup.

Several architectural aspects are important to service-oriented computing, e.g. they must be conjunctive, and i.e. it must be possible to combine services in ways not conceived by their originators, which implies that services have published interfaces that can be discovered.




Services must be deployable, i.e. it must be possible to deploy or reuse the component in any environment. This requires environment independence which includes transport independence, platform independence, and context independence. Services must be mobile, i.e. it must be possible to move code around the network. This is used to move proxies, user interfaces, and even mobile agents. Services must be available, i.e. it must be possible to obtain high availability through network redundancy. Service must be secure, i.e. it must be possible to protect the services from misuse.

TALIS applies Service-Oriented Programming. Its components can both, provide and use services. A provider component supplies a service to the Federated Architecture, which is the entity responsible to receive and automatically discover services for a component. A user component discovers and uses a service from other provider components. Services can be split into two major categories, synchronous and asynchronous. Synchronous services are request protocols with return values, i.e. the user component waits and blocks for an answer by the provider component. This category is known as provide/use paradigm in the Federated Architecture. On the asynchronous service, methods do not return values, i.e. the user component does not wait or block on the answer by the service provider. This category is known as publish/subscribe paradigm in the Federated Architecture.

Innovation:

To use Service-Oriented Programming for aeronautical appliances is very innovative, making a huge step from current practices towards state-of-the-art technologies. This has value for increased software reusability, improvement on system integration and distributed operations.

The service-oriented paradigm also leads to self-forming and self-healing systems, because of the loose coupling of system components and the network redundancy.

Results:

Several papers for international conferences have been produced on the Software Connector [13], [14].

TALIS achieved the installation of Meteorological and Traffic Information components which provide, discover and use internal and external services. TALIS FA also implemented Connectors, examples are the JMS, RMI and ATN connector. TALIS FA also implemented containers, which are the execution environments for components and services, and which manage security, authentication and availability. A TALIS computer is an example of a Container. Although not used on TALIS final demonstrator, it was successfully tested the context of containers, special on the implementation and testing project phases. Code migration and even running applications migration, with some technological restrictions, were successfully achieved on the project.

Future Work:

Special attention should be given to the competitiveness between identical services, and further demonstrations should be envisaged for this. A custom scenario for Air Traffic Management should show the interest of self-forming and self-healing systems.




4.4.4. Federated Architecture

Description:

The TALIS Federated Architecture (FA) is a framework in which applications can be deployed as distributed system components in an aeronautical network. The architecture comprises component-based middleware that will enable interoperability between applications, and common capabilities that can be reused by TALIS applications e.g., system management, remote management, component communications, data encryption, data authentication, and security.

Aeronautical Network

Protected interface, accessible only within the TALIS Federated ArchitecturePublic interface, accessible only via mediation of TALIS Federated Architecture

TALISApplications

TALISArchitecture

Components

Airborne Systems

TALISControl and

Display Units

TALISApplications

TALISArchitecture

Components

Ground-Based Systems

TALISControl and

Display Units

Figure 10: TALIS Federated Architecture External System Overview

Figure 10 depicts an external system overview of the Federated Architecture in perspective to the TALIS applications, the TALIS Control and Display Units (CDU), and aeronautical networks.




RMI

JMS

MDB

JCA

ATN Comp. Controller

Air/GndComm.

Network

J2EE

JiniManagement Services

Security Services

Components Services

Service Handler

Message Handler

J2SE

Java Openwings TALISFA

Time Mgr.

Flight Phase

Figure 11: FA Technology Framework

The Federated Architecture is highly based on a commercial-off-the-shelf middleware package called OPENWINGS2, which itself is based on Java libraries, JINI components and other XML related middleware. The TALIS architecture adds to this with even higher abstractions and additional middleware services. It includes Connector technology for a complete abstraction of the air-ground and other telecommunications technologies like the ATN3. Figure 11 depicts the technology-framework that is used for the FA.

Innovation:

The goal of the TALIS FA is to provide an environment in which new aeronautical applications and new technologies can easily be executed and tested. The key benefits of the TALIS FA are rapid responds to user needs (i.e., early deployment) and stimulation of technological innovations. This can be done without re-equipping aircraft or updating ground-based systems.

TALIS FA innovates with high degrees of separation of concern for system developers, in providing high-abstracted middleware interfaces and domain-independent capabilities to the aeronautical domain.

Results:

The Federated Architecture is highly based on a commercial-off-the-shelf middleware package called OPENWINGS4, which itself is based on Java libraries, JINI components and other XML related middleware. The TALIS architecture adds to this even higher abstractions and additional middleware services. It includes Connector technology for a total abstraction of the air-ground and other telecommunications technologies like the ATN5.

2 http://www.openwings.org 3 ATN – Aeronautical Telecommunications Network 4 http://www.openwings.org 5 ATN – Aeronautical Telecommunications Network




One main feature of the Federation Architecture is the support for dynamic discovery and linking between components. This is the major enabler of the TALIS Services Concept described in section 4.4.1, because applications can build up from a number of underlying services that are discovered and used on-the-fly depending on their geographic availability or other criteria.

The TALIS 1 prototype demonstrated successfully this approach.

Future Work:

The TALIS architecture could be further extended:

• To integrate additional data link and telecommunication technologies for point-to-point and broadcast applications. Of special interest could be the integration of GSM for world-wide airline applications at airports, and of wireless LAN for local high-bandwidth applications at gates of airports.

• To augment system capability with integrated HTML-based solutions like Enterprise JavaBeans (EJB).

• To increment discovery functions with mass-market search engines like Google, and add XML discovery to JINI discovery.

4.4.5. Flight-Deck Browser For Information

Description:

Ideally, all information is always available at all times. Realistically, information is distributed as a function of user-need. Some automatic functions, e.g. getting information as a function of the context of the user can be implemented (section 4.4.8) to avoid unnecessary work load. However, the users may also directly request for information and interact with the system.

In the case of air-ground integration, care has to be taken of what information is automatically available and what information is only sent to the flight deck upon pilot request, because the available bandwidth of the air-ground data link is limited.

The possibility of requesting information by interacting with the graphical user interface is similar to browsing for information and services on the World-Wide-Web, enhanced with a graphical function.

Innovation:

The TALIS system foresees a mode of pilot interaction for information sharing that is comparable to browsing on the World-Wide-Web. If more information is needed on a specific visual object, e.g. an adjacent aircraft, then the object can be selected and more information be requested. Upon this request, the system subscribes to a remote-service to deliver this information. The requested information is visualised to the pilot.




Results:

The TALIS prototype allows for information browsing in the TIS application. Selecting adjacent aircraft may request additional information, like flight plan and trajectories.

The prototype has two screens for visualising information, depending on the information: the Navigation Display and the Multi-Cockpit Display Unit. The information is presented either graphically or textually on the respective user interfaces.

Future Work:

• The concept of pilot-browsing needs operational validation. Special attention should be given to the evaluation of work load when information is requested manually or given automatically.

• It could be investigated how graphical web-browsing could be implemented in the cockpit, where also the graphics would dynamically build on dynamically available services. I.e. instead of opening another page of hyper-text for a new service, the visual information is a graphical object that integrates into the current picture.

4.4.6. Traffic Information Service (TIS-C)

Description:

Traffic Information Service in contract modus is a new concept that has been developed by the TALIS project ([8], [9], [11]). It is a service that allows for the subscription of the flight deck to traffic services that are provided from ground servers. The traffic services defined in TALIS are aircraft positions, aircraft flight plans, aircraft trajectories, conflicting aircraft with the conflict geometry, and predicted positions of adjacent aircraft at the time of conflict.

Innovation:

The major innovation is that TIS-C presents a credible alternative to TIS-B. TIS-C proposes a concept which groups traffic-related information beyond everything that is known up to date from the ADS-B and TIS-B concepts. It gives more traffic information with a higher quality because the information can be treated by powerful servers on the ground before being sent to the aircraft. This allows for the contextual intelligence in treating information for aircraft. The medium-term conflict is a good example: the aircraft does not only get the conflict geometry, but also the trajectories of involved aircraft and can herewith check its own state, and in addition it receives trajectories of contextual aircraft together with their predicted position at the time of conflict. This should allow the flight deck to fully understand the conflict situation and a find a better conflict resolution if this is requested, or simply get a better understanding of the air traffic controllers’ action.

Results:

Several papers have been produced for the TIS-C service that describe the benefit of the TIS-C service in comparison to TIS-B [8], describe the operational concept [9]. In addition, the TIS-C concept has been validated with a simulation tool [11]. These papers have been presented on international conferences and have partly been rewarded as best conference track papers [9], see also section 4.4.8 [10].




Several project deliverables have been produced for the specification, design, implementation and test of TIS-C Service (section 4.2.4).

The TALIS Standards And Recommendations Document was produced with a standardised description of TIS-C.

The TALIS demonstrator implements the TIS-C concept as currently defined, and the functions have been verified through a high number of test cases.

The state of the technical work of TIS-C should allow it to be proposed for standardisation, the underlying protocol and data types being defined and tested.

Future Work:

The TIS-C concept needs operational validation, which was not in the scope of TALIS 1.

The TIS application can further be extended to deliver more information for pilot situational awareness applications, conflict detection and resolution, and collaborative decision making.

4.4.7. Weather Service

Description:

The purpose of the Weather Application is to support decision making processes for the flight deck and for ground personnel who are involved in the actual flight operation after the planning and flight briefing phases have been completed. For this purpose, the most likely decision making factor, after the planning and flight briefing phases, is the weather condition along the flight plan. The Weather Application will improve and increase the productivity and flexibility of the different actors in view of an economical decision making process. The airline passengers will observe and experience enhanced aviation safety, improved flight punctuality, and increased number of flights and connections.

The TALIS Weather application shall be aware of the present position of the flight and its current flight path. In case safety related and operational relevant weather phenomena or critical NOTAM information is received and detected, an automated in-flight support process shall be invoked, which automatically sends the information to the related aircraft. The application displays the given whether information, such as relevant NOTAMs, in a textual form on a cockpit display and contributes herewith to the pilot situational awareness.

The TALIS Weather application sends scheduled weather updates to the aircraft: Meteorological Aerodrome Report (METAR) and Terminal Aerodrome Forecast (TAF).

It sends non-scheduled weather updates to the aircraft: Significant Meteo (SIGMET), Tropical Storms, Volcanic Ash Advisories, Convective SIGMETs, Clear Air Turbulence Warnings and Wind Shear warnings. It also sends Notice(s) To Airmen (NOTAM) updates to aircraft. The data comes from the LIDO weather database.

Innovation:

Weather information onboard the aircraft exist today for some airlines using existing data link technologies. However, these will be limited and difficult to extend. The TALIS system, in contrary, is conceived for extension. It will herewith be easily possible to use the information from the Weather application in combination with other services or applications, e.g. for tactical weather re-routing applications, which do not exist today. The TALIS Weather Applications is therefore an enabler for future innovations.




Results:

The TALIS demonstrator implements the weather application presenting textual information on the MCDU. The functions have been verified through a high number of test cases. However, the life data connection to the LIDO database was not implemented, and the meteorological information is only shown in textual format on the Multi Cockpit Display Unit, and not as initially planned in graphical format on the Navigation Display.

Several project deliverables have been produced for the specification, design, implementation and test of MET Service (section 4.2.4).

Future Work:

For future work on the METEO application it is foreseen the introduction of life data. TALIS made only use of a static database to populate the application. It would be useful to test a scenario of several weather service providers and several aircraft using them, to test the service competition as explained in section 4.4.3.

It would also be useful to revise the presentation of the information, i.e. to add symbols on the Navigation Display and make them “browse-able” for textual information.

4.4.8. Total Information Sharing Protocol (TISP)

Description:

The Total Information Sharing Protocol (TISP) is a new concept that has been developed by the TALIS project [10]. TISP as a protocol is a cornerstone for TIS-C (section 4.4.6) and many potential future applications. It defines the way how services are discovered and subscribed to. Similar to ADS-C it is based on a contract between the air and the ground, and adds possibilities for a dynamic negotiation of contracts.

TISP is a generic software protocol for client-server software architectures. It customises the client-server protocol for mobile consumers and for safety-critical applications. It is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service consumer. Therefore special attention has been put on the discovery of service providers, the negotiation of contracts between service providers and service consumer, and a pre-negotiated seamless hand-over between service providers. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. All these features will be presented in the following paragraphs.

TISP is composed of a set of protocol patterns that are the dynamic service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over.

Innovation:

TISP could be used beyond the small world of Air Traffic Management. No other information platform has yet combined dynamic service lookup, contract negotiation, contract delivery and service hand-over for mobile users in a single logic protocol, whereas the entire world of mobile business services would profit from such a protocol.




Results:

The TALIS demonstration platform has successfully implemented the TISP protocol, with the exception of two functions: service hand-over and service-update.

Several papers for international conferences have been produced on TISP and the overlying TIS-C applications. These papers have partly been rewarded as best conference track papers ([10], see also section 4.4.6).

The TALIS Standards And Recommendations Document was produced with a standardised description of TISP.

Future Work:

• Technical verification has been conducted in TALIS 1. The next steps towards operational validation must be done now.

• The document for candidate requirements has defined functions that are beyond the implementation of the TALIS 1 project that could be implemented, amongst them elementary functions like the TISP hand-over, and TISP update.

4.4.9. Intelligent Systems

Description:

The objective of intelligence in the context of the TALIS concept is to take away pilot workload, so that the decision of which service to be used is taken by the system, and to filter out information to prevent from information-overload. This function acts on two levels. The first level is about the subscription to specific services depending on the current situation of the user. The second level is a filtering of this information, again as a function of the context of the user.

In the TALIS project, together with the Technical University of Berlin, theoretical considerations have been undertaken to get a better understanding of this function [7]. The underlying idea is that the “context” of the user is the object that helps in the generation of events that will trigger the different subscription and filter functions. The objective of this study is to take a software-engineering approach and to get a better understanding of what “context” means with the tools of modelling.

Some specifications for context-based behaviour have been defined on the protocol level for the application:

1. Flight-phase information, which is used as a trigger for different subscription schemes, and leads to customised information presentation. An example is the change of the “volume of interest” for the TIS application as a function of the flight phase. When the flight phase is changed, the contract with the ground-based service provider is renewed with a different value for the size of the volume of interest.

2. Subscription to classes of events. Events can be ordered in a hierarchy, and subscription to any event, or its specialisation, or its abstraction, leads to the sending of the relevant information or the relevant service. This function has only been implemented as an open protocol specification, but not as a visible function of the demonstration platform.




Example: TIS service subscribes to events of type “ATC”; then the system makes a new service available that generates ATC-types of events, e.g. CPDLC messages for adjacent aircraft; the subscribed flight deck is informed of the availability of the service, and can (automatically) subscribe and get this information (that had not been foreseen in the initial system). It can provide a generic means for the presentation of this formerly unknown information, e.g. by tagging presentation meta-information.

Innovation:

To integrate a level of artificial intelligence to profile the user is still a field of research, even though it has first appliances for marketing and for military users. The TALIS approach did not try to integrate Artificial Intelligence; instead it tried to understand the problem with the use of software modelling. It was felt that the understanding of the users’ context would be key to a better understanding. Modelling of context became a research topic in itself, with results for improvement of modelling technique.

Results:

The work resulted in a successful diploma thesis “Identification and Modelling of Contexts for Different Information Scenarios in Air Traffic Management” [7]. However, the results of this study show that the topic of intelligent and dynamic treatment of information on the meta-level is still a field of research. Its implications with the art of Artificial Intelligence are hardly understood, not even in its beginnings. The short timeframe of the TALIS project did not allow for any further research.

The TALIS prototype demonstrates functions of context-based information fetching depending on the flight phase of the aircraft. The TIS-C service is modified as a function of flight phase.

Future Work:

Future extension of the project should push further in the realisation of the principles of contextual intelligence, further in the idea of generic service frameworks and federations of services as a function of user-context, and should start to validate the utility of such functions in the air transportation domain. It should be evaluated whether the dynamic extension of service federations can realistically be triggered with the help of abstract event typing when user contexts change.

4.4.10. Certify-Ability

Description:

The TALIS system was introduced as a solution to allow the use of more dynamic and cost effective software to be used in airborne systems. In order to achieve these goals the TALIS system uses commercial off-the-shelf software and Java as implementation platform, ensuring the availability of support tools. The TALIS system is used both as part of an airborne system and a ground based system, which makes DO-178B/ED-12B and DO-278/ED-109 applicable.

A specific challenge is the use of Java for safety critical application, and much work is ongoing in the world to allow Java to be used for safe critical applications.

Innovation:

Innovation is on three levels: the use of commercial-off-the-shelf software packages, the use of a new chain for development tools, and the use of Java programming language for aeronautical and safety critical applications.




Results:

To show the availability of COTS development tools a market survey was conducted, which concludes that it should be possible to create an efficient software development environment using state of the art technologies, while still being able to achieve the highest levels of safety. The relatively low rankings of all tools analysed in the market survey indicate that more work needs to be performed by tool vendors in order to provide better support a DO-178B/ED-12B development process. Tool qualification especially is an issue that must be resolved in order to employ the tools effectively. The market survey depicted in Table 7 indicates the following tool chain:

Table 7: Recommended Tool Chain

Kind of tool Tool Static analysis tool Aubjex or Jtest

Structural coverage analysis tool Jcover

Unit testing tool Jtest Integration tool WebSphere micro environment

Traceability tool DOORS

High level guidelines and points of focus were produced to allow the Unified Software Development Process (USDP) to be used, while still being able to comply with the certification guidelines. Possible implementation of all objectives of DO-178B/ED-12B has been presented. It was shown that a combination of USDP and DO-178B/ED-12B is possible.

Another threat of TALIS is the use of Java. Two attempts have been analysed: Sun’s real-time specification for Java and the real-time core extensions of the J-Consortium. While they solve a number of timing and memory allocation issues other issues remain. A list of these other issues that are specific to the Java programming language and the Java Virtual Machine (JVM) are identified and recommendations are given to allow a subset of Java and the JVM to be used. This information indicates Java can be used for safety critical software projects, if a JVM is developed, that provides certification data and implements one of the two real-time extensions.

4.4.11. Unified Process

Description:

The description of the Unified Process has been introduced in section 3. The objective of the unified process is to ensure a controlled development process whereas users, engineers work on a common level of understanding and preparing a good starting point as object oriented design and development is concerned.

Innovation:

The deployment of a formal and conceptual modus operandi across various partners with different main areas of research and development is still a challenge. The Unified Process was new to all partners. The process had to be developed during execution of the project, and the deliverables, or artefacts, be defined.




Results:

The Unified Process was experienced and experimented by each of the partners, all used to the rigid V-cycle. Therefore all partners went through a learning curve. This is somehow reflected in the very long cycle of built #1, and the short cycle for #2.

Each member of the Consortium had the ability to work under the same development standards: the equipment manufacturer THALES Avionics, the research institutes NLR and EEC, the airliner systems supplier Lido and the software developer Skysoft, under the co-ordination of EEC.

Future Work:

The Unified Process is assimilated by the Consortium today, yet, lessons can be learnt from the last 2.5 years and the process reviewed based on this experience.

4.5. CONTRIBUTION TO COMMUNITY SOCIAL OBJECTIVES

Description:

The primary impact of the TALIS project is its contribution to a user friendly information society, reaching each airspace user. It will be an important step in the creation of a global European airspace information system. Airlines and other airspace users will be able to offer complete information services in an integrated system, using the same web-technologies as the ones defined in the project. The augmentation of safety and air-space capacity achieved with Total Information Sharing will be of benefit for the European society. Last but not least, the European citizen as a passenger will benefit because the Total Information Sharing System will enable him in the medium term to access to supporting real-time travel information using internet and web technologies.

Results:

The community added values and contributions to the social objectives must be seen in the medium to long term, the project concentrating on innovative research and not on implementation. Nevertheless, some findings of the project could find relatively early applications, especially where no avionics certification is needed, e.g. for airport collaborative processes. This could be the result of extensions to the TALIS 1 project.

In the medium-term the TALIS concept should keep its promises: increased information sharing leads to a more performing air transport system, which results in less delays and less pollution, and contributes to the growth of the air transportation sector with its employments.

It should be emphasised that information sharing and -management has become strategic for increased ATM performances, as stated in the EUROCONTROL strategy [3]. TALIS is an early contributor and pre-cursor to that.




4.6. ECONOMIC DEVELOPMENT AND PROSPECTS

Results:

The economic prospects for the participating partners are that all partners have acquired know-how of the high-end, component-based technologies such as JavaBeans, JINI, OPENWINGS, XML and CORBA. As a result, they are able to take a lead role in future activities. In addition, the results can be commercially exploited by THALES Avionics and Skysoft. THALES Avionics and Skysoft will be able to either propose commercial products or at least have the way paved for commercial exploitation. NLR will benefit in having acquired new technologies, which will then be exploited in other proto-types and demonstrators to augment the value of the company in their ATM activities. EEC will have benefits in the technological know-how, contribution to future concepts, and in the medium-term the operational exploitation of the results. It must be noted that during the execution of the project, LIDO has reduced its activity due to difficulties after September 11th. Herewith LIDO’s initially planned exploitation was not possible anymore. This had hardly impact on TALIS 1, but TALIS2, which intended to implement some of the services, is compromised regarding the exploitation of results in some aspects, since Skysoft had to overtake important parts of the Lido related work. - Through very strong personal support through Lido namely by supervision and mentoring towards Skysoft Lido bridged the gap thereof and allowed the project to be successfully finalized. The scientific and technological prospects have already been discussed in section 4.4.3.

4.7. PROJECT MANAGEMENT AND CO-ORDINATION ASPECTS

4.7.1. Consortium Performance

Budget:

Total of 4,231,838.87 €, planned in contract was 4.38 Million €, i.e. 3% under-spending.

0%

10%

20%

30%

40%

50%

60%

Personnel Subcontract-ing

Travel andsubsistence

Other specificcosts

Overheads Adjustement 0.00

50000.00

100000.00

150000.00

200000.00

250000.00

300000.00

350000.00

Sept-2001

Mar-2002

Sept-2002

Mar-2003

Sept-2003

Feb-2004

EEC (Coordinator)LIDONLRSkysoftThales Avionics

Total Project Effort

0

5000

10000

15000

20000

25000

30000

35000

1 2 3 4 5

Reporting Period

Effo

rt (m

en-h

ours

)

TAVSKYNLRLIDOEEC (+)

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

1 2 3 4 5

EEC (+)LIDONLRSKYTAV

Figure 12: Financial Figures (top-left to bottom-right): a) Cost types, b) cost per partner per reporting period,

c) effort in man*days per partner and reporting period, d) approximation of effort in man*years per partner and reporting period




Figure 12 illustrate the statistics about the costs of the project. The main costs, besides overhead, are personnel and subcontracting, which means that the project almost only spent on effort. The total personnel cost corresponds to 109993 man*hours, which are roughly 66 man*years over the period of 2.5 years, but where large parts of effort from EEC and LIDO are not counted because put under sub-contracting.

Delay:

Total project delay is 6 months on a total duration of 30 months (20%), requested after the first year.

Other metrics:

The project has only used teleconferences as management tools, and minutes for about 100 teleconferences have been produced. The monitoring of the project was done using action lists in the minutes.

There were no Project Management Board meetings. Travel was only used for red flags on the management level, e.g. the contract amendment after the first project review, and for integration and dissemination.

Each work package has produced an own management plan, the WP Specifications, containing detailed Gantt charts. In total 441 work items have been identified and traced.

The project has produced a full set of Project Management Plan, Quality Management Plan and Risk Management Plan. 9 project reports and 5 costs statements have been produced for the EU Project Office.

0

200

400

600

800

1000

1200

1400

WP1 WP2 WP3 WP4 WP5 0

10

20

30

40

50

60

WP1 WP2 WP3 WP4 WP50

20

40

60

80

100

120

140

WP1 WP2 WP3 WP4 WP5

Figure 13: (a) Number of exchanged e-mails on the project blaster, (b) number of minutes from teleconferences, (c) number of work items in Gantt charts per work package

4.7.2. Project Reviews by the EU Project Office

There have been two intermediate project reviews (19 Nov 2002, 14 Oct 2003) and one final review (27 Feb 2004).

The first one led to an amendment of the contract, basically to shift effort from LIDO to SKYSOFT in order to assure the development of the Meteo application since LIDO reduced its effort on the project due to commercial difficulties. The second review was announced on short notice so that the project co-ordinator was unable to attend being on the user forum, and the manager’s assistant in hospital, which led to an unsatisfactory review.




The final review was successful, with the submission of a satisfactory version of this final report (v1.0), and a successful demonstration of TALIS deliverables and the TALIS demonstrator. The conclusion of the EU Project Officer and the three reviewers was that the project came to a successful end, produced satisfactory deliverables and managed to get through very difficult situations.

4.7.3. Development Performance (Metrics About Source Code, Use Of COTS, etc.)

Performance data has been recorded for each of the TALIS applications, which are representative of the size and complexity of the developed software.

Raw Data FA TIS MET

Number of requirements 36 27 68

Number of use-cases 29 20 26

Number of software requirements

19 20 24

Number of analysis classes: - classes: - actors: - interfaces:

9 0 9

28 2

10

43 7

28

Number of design classes 45 68 71

Number implementation classes 106 65 75

Total number of lines of code 32223 18894 17586

Number of test cases 149 208 121

It is remarkable that the Federated Architecture is almost double the size of an application. Some interesting metrics can be derived from the raw data.

Metrics FA TIS MET

Number of software requirements / number of requirements

0.53 0.9 0.35

Number of analysis classes / number of software requirements

0.47 1.4 1.8

Number of design classes / number of software requirements

2.4 3.4 2.96

Number of lines of code / number of software requirements

1696 945 733

Number of lines of code / implementation class 304 291 234

Number of test cases / number of software requirements 7.8 10.4 5.0




Based on the metrics, the conclusions of the Consortium are the following:

1. The size of elements increases, sometimes exponentially, with the stage in the life-cycle, starting at requirements down to number of lines of code;

2. The most noteworthy differences between the three applications is the ratio between number of lines of code per software requirement;

3. The metric which varies less is the number of software requirements / number of requirements;

4. Based on the number of test cases, and not code coverage, the application which seems to be most tested is TIS.

The TALIS demonstrator totals 184 design classes, 246 implementation classes, 68703 lines of no-COTS code, and 478 test cases. The amount of COTS code extends 1000000 lines.

4.7.4. Challenges, Problems And Solutions

There were a number of major challenges that the TALIS consortium had to overcome. The project was launched in September 2001, just a week after the tragic events of September 11th. This had major impact on the consortium, especially Lido felt the economical consequences almost immediately and had to reduce its practical contribution to the project. This had direct impact on the production of the project deliverables. Fortunately Skysoft volunteered to conduct the missing work. They were strongly supported in these areas of the work by Lido to conduct good results anyway. Due to this change, the contract with the European Commission had to be amended generating enormous and unplanned management overhead. Later, but not less true, NLR started a major reorganisation, which did not directly impact the project, but was yet perceptible for the others. Minor reorganisations also took place in THALES Avionics and EEC.

A “normal” challenge for an international consortium are cultural and language differences. This unavoidably leads to unnecessary conflicts due to misunderstandings. Project management decided to reduce meetings to a strict minimum, handling almost everything by teleconferences and e-mail. However, these media require a lot of rigour and discipline for the involved; the Consortium successfully mastered this challenge.

The consortium encountered problems with the development of its design documents, due to the distribution of the participating partners. This was mainly due to the very long learning curve for the operational and technical aspects of the project. Despite of common training, the synchronisation of the development team probably only took place after 1.5 years (of 2.5), which is very long, and lead to strong conflicts in the consortium.

Another foreseeable challenge was the technical integration of software components that were developed at different places. The Consortium suffered from this, and it could be observed that the integration of built #1 was much longer than planned. The lessons to be learnt are manifold:

• The stricter application of the incremental process with smaller increments but done more often. However, quick increments require a stable architecture, which could not be the case for TALIS where the FA is a major deliverable itself. It is still not clear for the project manager how to harmonise the need for quick increments and an evolving architecture – to this regard the Unified Process fails, as far as we applied it.

• The project was not set up correctly regarding integration, due to the split of TALIS into phases 1 and 2, where phase 2 should have been the major integration and validation phase. Therefore the planned effort for integration was shortened too much. Possibly the project was too ambitious for phase 1.




To apply the Unified Software Development Process was a major challenge for all partners, with the aeronautical habits of big and long V-cycles. With the background in DO, ESA and military standards, one can observe that sometimes the UML process lacks behind these, due to its informal character, where SDL is perceived as being better performing. UML and SDL should find a nice complementation for future projects. The UML process splits the functional architecture into several parts, which is not always beneficial, especially when trying to explain to higher management. Good old functional block diagrams have more power here. In the beginning of the architectural work, UML was lacking architecture descriptions, and the Consortium had to select an Architecture Description Language (ADL), which was a time consuming process. The use of ADL has proved to be beneficial.

Two initial requirements have been downscaled, as reflected in the amendment of the contract with the EU:

1. The demonstrator was not put on a portable platform, due to performance limitations for DACOTA. However, development work has been executed on portable PCs, which proves that the Federated Architecture and the applications are able to run on a single portable platform.

2. Real radar data was not possible to be used by the Consortium, because the EUROCONTROL instance responsible for distribution of real-time surveillance data would not accept the request possibly due to Sep. 11th, unless specific terms would have been contractually fixed. The Consortium did not invest into that lengthy process.

For the second increment some requirements for functions on the protocol level have been dropped in favour of more visual application functions for better demonstration and herewith easier dissemination, i.e. the hand-over function of the TISP protocol has not been implemented and postponed to the future, and instead the MTCD function in TIS has been implemented. This could be done within the contractual terms, but led to some tensions in the Consortium.

The choice of the OPENWINGS middleware as a commercial-off-the-shelf platform forming the basis of the Federated Architecture should be reconsidered. The WP3 Architecture made a choice of platforms based on reading paper, not experimenting. The OPENWINGS platform had been compared to the J2EE platform, and been selected due to its additional announced features, i.e. discovery and Connectors not being treated by J2EE at that time, JINI component management container etc. However, the reality encountered at integration is that this platform is unstable and slow. Changing the Federated Architecture for another underlying environment would have been too expensive, due to the late detection of difficulties. For the future it is highly recommended to replace OPENWINGS with another technology, even if there is still no other equivalent on the functional level existing.

The treatment of the cost statements by the EU took a long time, due to blocking payments arguing that only after successful contract amendment the situations would be unblocked, and then EU internal end-of-the-year procedures. This makes that until the end of the project the EU only paid 52% of their part, whereas the partners had almost 100% costs. This is problematic for the entire consortium, and led to severe difficulties for Skysoft being a SME. The situation endangered the success of the whole project, because at the final integration of build 2 money was missing for travel! Figure 14 illustrates the situation.




0.000.100.200.300.400.500.600.700.800.901.00

Sept-2001 Mar-2002 Sept-2002 Mar-2003 Sept-2003 Feb-2004

% cumulative costs (Total = 4.23 M EURO)

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

Sep-01

Dec-01

Mar-02

Jun-0

2

Sep-02

Dec-02

Mar-03

Jun-0

3

Sep-03

Dec-03

Mar-04

PreCS1CS2+3

Figure 14: (a) Cumulative costs of the consortium, (b) Payments by the European Commission, not yet integrating payments to come after project end

Another anomaly is the request from the project office to reduce travel cost, and at the same time request more frequent direct interactions between in the consortium to promote a common project culture and share know-how, e.g. by organising project board meetings.

4.7.5. Dissemination

Dissemination to the outside world was mainly done by NLR and EEC. Several publications and presentations in order to disseminate the TALIS project and to receive feedback from its potential (global) users have been produced. A number of well-established conferences have been selected and many scientific publications have been presented, and in some cases been rewarded as best papers. The dissemination events were carefully selected to have a global coverage [16].

To assess whether the air transport community is open to network-driven services, presentations were given to several organisations for each type of actor followed by interviews (i.e., air traffic management operators, airports, regulators, and airlines). To prevent a national bias, actors from six European countries have been consulted by NLR. All actors recognise the problem and acknowledge the optimisation opportunity:

• Air traffic management operators have no problem with providing their information. They express a reactive attitude: their customers, i.e. the airlines, have to ask for it first. As a new system for an air traffic control centre typically takes at least decade to realise, their time-to-market is in multiple years.

• Airports have a challenge to keep the data obtained from the various actors consistent and base them on uniformly defined moments in the aircraft turn around processes. Services based on these data are not yet within their time horizon.

• Regulators (in a role to approve those operational applications that could infringe the safety) express interest in the new technology but will only take actions once a product is being submitted for certification. In the European Union the regulatory scene is changing due to evolution from National regulators and JAA to the European Aviation Safety agency (EASA) at European Union level, temporarily reducing their available effort for new technologies.




• Airlines, due to the harsh economic realities, need a business case per application. Their time-to-market is years, except when a competitor gets there first. Following their US examples, low cost carriers are becoming very successful in Europe as well. Using the Internet to sell the majority of their tickets, they are used to network-driven services. They want to restrict the required capabilities to data exchange to ease certification. Their time-to-market is a few months at most with a similar short return-on-investment. Potential next steps are flexible depending on continuously monitored consumer changes and experience gained.

The advantages of a service-driven network centric concept are recognised by all actors. Facing the harsh economic realities, and not used to innovation beyond a single user community, no one is willing to take the first step. Consequently for the first service the time-to-market should be a couple of months, with a very affordable investment. This implies that it can not be a certifiable service. Fortunately, many ideas for such non-certifiable services are available.

Important and intensive dissemination internal to EUROCONTROL has been carried out, and most related projects and programmes have been informed and invited to contribute or participate: the Communication, Navigation, Surveillance, Data Processing and Aeronautical Information domains, and especially the Air-Ground Cooperation (AGC), Overall Target Architecture (OATA), Aeronautical Information Management (AIM) and Consistent Flight Data Management (FDM) projects. In addition some links have been made with Maastricht UAC for the elaboration of a regional flight data server, with a proposal to use TALIS technology for the distribution and management of flight data. Unfortunately, due to budgetary restrictions, this project did not proceed.

Further input was given to the initiation of a new ICAO working group (end 2003) in co-operation with the FAA.

First steps are being undertaken to propose the TALIS Standard Document [17] to EUROCAE to investigate whether international standardisation can be undertaken at the current state of the document.

4.7.6. User Forum

The TALIS project intended to organise a user forum towards the end of the project. However, the project being focussed on very technical issues, it was felt that the final user community, i.e. airlines and ATM organisations, would be difficult to get to participate in such an event, because their main interest is the operational improvement, not the technical enabler. Therefore it was decided to use a big international conference to replace the user forum, and to address the scientific community. The 22nd Digital Avionics System Conference, Indiana, USA, was chosen and three scientific papers presented in two different threads:

1. Tuesday, Oct 14: Track 6 Open Systems Architecture, track chair Louis J. Bottino, FAA Tech Center, session 6A Hardware and Software Architectures, session chair Theodore Bayruns, Boeing Helicopter Div: System-Of-Systems Integration Of Air-Ground Telecommunications With The Software Connector [14].

2. Wednesday, October 15: Track CNS, track chair Denise Ponchak, NASA Glenn, session 4B, CNS Networks and Protocols, session chair Chris Wargo, CNS Inc: Towards a Concept Definition of the Total Information Sharing Protocol [9] Paper awarded as best-session paper.




3. Wednesday, October 15: Track CNS, track chair Denise Ponchak, NASA Glenn , session 4C, Airborne and Surface Surveillance, session chair: Len Carlson, TSC: Enabling Air-Ground Integration: Concept Definition For Traffic Information Service In Contract Mode (TIS-C) [10]. Paper awarded as best-session paper.

Each presentation was followed by question-answer sessions. The main questions can be summarised as follows:

• Architecture: Astonishment about the attempt to push high-end technologies into the domain of ATM and especially the field of air-ground integration, which requires certification.

True, gives rationale to the work package on certify-ability. The use of state-of-the-art technologies is useful when provided by commercial-off-the-shelf products.

• Architecture: Question whether Java can be used for safety critical applications, knowing that it is no strict real-time environment, and herewith impossible to certify for aeronautical avionics applications.

True, gives rationale to the work package on certify-ability. The scope of real-time Java is outside of TALIS, but many international groups and project are working on it, as can be seen on the same conference, where an entire track is dedicated to the subject.

• Architecture: Difficulty to understand the Connector principles and the potential benefits to ATM.

Subject of the presentation. The conclusions are that connector technology can be very useful to integrate all the legacy of ATM into one system of systems. However, not all features of the technology should be considered for the air-ground integration, i.e. is the dynamic generation of source code and its compilation in run-time not really required, the technologies not changing very often.

• Applications: Question about the need for bandwidth for the TIS-C application.

Basic consideration for the usefulness of TIS-C is the bandwidth it uses. TIS-C should be used in complement to a mandate to ADS-B enabled by Mode-S technology, for lowest implementation cost. In this case TIS-C does not uplink the entire air situation picture, but only complements with added-value information.

The correctness of this statement could be verified with studies after the user forum.

• Applications: Discussion of the differences between the Context Management (CM) application from the Aeronautical Telecommunications Network (ATN) on one side and the discovery-function in TISP on the other side.

The CM application in ATN is a dynamic and distributed naming server. Because the updates of the names (addresses) are made over the air-ground data link and relayed by the aircraft, it is quite vulnerable. TALIS has used another, much more robust mechanism, which is the dynamic discovery. It is not only much more robust, but it will lead to self-forming and self-healing systems, a true advance in safety.




Conclusions of the User Forum:

There has been a very high interest in the TALIS presentation, and very positive feedback. Two of the three papers have been awarded best-session papers. Especially the TIS-C presentations have been very well received. There was public from the DAG-TM projects at NASA that was enthusiastic about the new possibilities that the enabler could offer to the operational concept.

The project management believes that it was a good decision to use the DASC conference as a forum.




5. OUTLOOK

5.1. BENEFITS AND EXPLOITATION

LIDO:

LIDO expects operational benefits through the uplink of meteorological information to the cockpit through the AOC link. The TALIS Weather Service using an emulation of the LIDO weather server is one step into that direction. However, this result needs further integration with the real MET system in Frankfurt to have some operational significance. Therefore the envisaged use and exploitation of the TALIS system with economical impacts cannot be achieved for LIDO by the end of the project.

NLR:

NLR is developing a TALIS Demonstrator System (TDS) as identified in chapter 11 of the TALIS contract, EU contract no. IST-2000-28744. The TDS system is used for exploitation and application, research and development purposes of the TALIS technology within the scope of the TALIS project. To meet these objectives, the TDS shall be portable and even (partially) airborne-capable, as one of its distinguishing characteristics.

Figure 15: TDS System

The TDS system consists of subsystems with distinguishing characteristics (Figure 15): an airborne capable air-side subsystem, a mobile land-side subsystem, and two transportable ground-side subsystems. The TDS subsystems are interconnected with a wireless communications network (for all subsystems) and a wired communications network (for ground-side subsystems only). Furthermore, the TDS subsystems is compatible with the TALIS Verification Platform subsystems in order to be able to execute the TALIS Federated Architecture (FA) middleware and the TALIS air-side and ground-side applications. Specific hardware [TALIS-WP5-WHP-5504] for the TDS system is purchased.

Figure 16 shows examples of the realisation of a TDS air-side METAR/TAF application. To improve pilot acceptability, the display layout closely resembles other cockpit displays. The left column of buttons lists available airports based on current aircraft position. The text box at the bottom provides TAF/METAR information for the selected airport in the compact format pilots is familiar with (e.g., EHAM for Amsterdam, LFPO for Paris). Other applications are being developed for taxi procedures, de-icing procedures, etc.




Figure 16: Examples of air-side TDS part of METAR/TAF and Taxi application

Using the TDS system from NLR a lot of periodic feed back is received from the aviation industry in order to improve the service-driven network technology.

SKYSOFT:

• Skysoft could augment its know-how for development with the Java programming language and a high-end technology middleware platform provided by the Federated Architecture. Of special interest is the high-level integration of the ATN technology with the Java distributed environment. The TALIS system components have been designed in the view of system fundaments, which are closely concerned with communication- and protocol aspects and with applications level aspects. At this point, basic functionalities illustrate how these components perform within a distributed system and bear the potential to be further developed in the view of a developing a rather comprehensive and robust system. That will help Skysoft to be present on demands for system development for airliners or AOC services providers, which require robustness and high functionality under very tough time-to-market constraints.

• The ATN interface is of focal importance since ATN is an important standard communication networking. The TALIS system, by definition, is inter-operable with any communication system and such capability is of most convenience when developing a system which is to be deployed in the future ATM context. Skysoft is proud having contributed to this, especially because THALES Avionics, being one of the major cockpit manufacturers and partner in the TALIS 1 consortium will have acquired the same technology.

• Skysoft could augment its know-how on software development processes beyond its existing experience in object-oriented development with a profound experience with the Unified Software Development Process. This required complete relearning and a different approach in comparison with the traditional V-cycle development, by starting with a basic prototype and iteratively furthering its capabilities. As a software company it will help to produce future products in a scalable and maintainable way, and herewith have better prediction of software production cost. In addition, this new experience provides for a valid approach for system development and will permit Skysoft to improve its competitive position, it will help Skysoft to be better performing in the future, and to be present on the market with state-of-the-art processes and know-how.




• Sharing experience with reputable reference European actors of aeronautical industrial and research domain.

THALES Avionics:

Several subjects of TALIS 1 can be exploited by THALES Avionics.

The work on the certification of Java is important for future product development, which hopes to apply this technology for the cockpit equipment. The Certification work package has produced some very useful results to continue in that direction. There is strong interest to continue investigation, especially on the feasibility of a Java real-time Virtual Machine, which is one of the most important but yet uncompleted components for avionics certification.

Next, some of the architecture technologies will be integrated into a micro-kernel – a further step towards product development. That will require the reduction of the very rich TALIS 1 environment to some basic key functions. Of special interest is the integration of JMS (Java Messaging Service) into the micro-kernel, JMS being part of the Federation Architecture. This technology provides for distributed event handling and allows for integration into the future distributed avionics architecture.

Of possible commercial significance is the encapsulation of the ATN with the Java connector provided by the Federation Architecture. This will allow easily adding new applications in a complete abstraction of the underlying telecommunications technology, and herewith contributing to a transparency of air-ground mobile and airborne fixed networks. This will expand system capabilities, reduce production cost and increase time-to-market performance.

Furthermore, the TALIS 1 project has permitted some major evolutions to the DACOTA rapid-prototyping platform:

• The presentation of surrounding traffic has been an external component of DACOTA and has now been integrated into it;

• The cockpit-screens have evolved, screens provide new functions and additional symbols have been added;

• DACOTA has been extended with ground-based functions. The extension to ground-functions will allow the test of the platform in itself, and will make it available for the integration of further components for concepts implementing air-ground integration.

Last not least, TALIS 1 has contributed to the European position of THALES Avionics, and herewith manifested the interest of THALES to participate in the European research landscape in a co-operative manner, also for very innovative projects.

EEC:

The most important benefit for the EEC has been the development of the Traffic Information Service in Contract (TIS-C, see section 4.4.6) application, and the specification of the underlying generic protocol for information sharing on the air-ground TISP (section 4.4.8). The combination of this generic protocol for mobile client-server applications and one (of many) specific applications for improved pilot situational awareness should become a foundation stone for all future concepts of air-ground integration. The EEC would be interested in a continuation of the development of this service! Of special interest would be work on enhanced pilot situational awareness for airborne conflict management and the definition of future airborne applications to support applications for tactical flow management, as well as CPDLC situational awareness applications.




The EEC has made a further step in industrial co-operation for the research of aeronautical technologies, here with a focus on air-ground integration. It has strengthened the links to some key players, and could contribute to a common understanding of the potential future distributed system and its architecture.

The EEC has gained experience in the coordination of an international consortium and the relations with the European Commission office, and could improve the rigour of project management. Project management has gained experience using the Unified Process or software development, i.e. an iterative, incremental and architecture-centric process.

The EEC has further deepened its knowledge of open distributed systems, acquired knowledge on a specific middleware platform called Openwings, has experimented the use of software connectors, experimented higher modular component platforms, authentication and encryption on the air-ground link. Especially the use of discovery services has been recognised having high potential for safety critical applications in ATM.

5.2. CARRY ON

TALIS 1 was planned as the first phase of a bigger project that was initially proposed in two phases. The second phase TALIS 2 has been proposed twice so far:

The first time the technical evaluation by the European Commission was successful, however, it was considered too early in the TALIS1 project to start phase 2, and therefore recommended to resubmit at a later stage, and possibly in the next 6th Framework. Then, a modified consortium submitted TALIS 2 again for the 6th Framework, and had not been accepted by the evaluators.

This final report of the phase 1 of TALIS includes an impressive list of ideas for continuing work, which covers on one hand some important continuation mainly for validating the innovative concepts, and on the other hand injects an entire bunch of new items and research suggestions that would be useful for investigations. The concept of intelligent and mobile transport systems has just been started to be explored, it bears a very high potential for research, with useful applications for the travelling public and the air transport system, increased intellectual property for the research community, and last not least an overall benefit to our European society.




6. CONCLUSIONS

It is the conviction of the TALIS 1 consortium that information-sharing as a cornerstone of system-wide information management is needed more than ever, and that technical work, which would allow integration into the system-of-systems will be increasingly required. The overall performance of the Air Traffic Management system would be improved in all its dimensions: safety, capacity, cost and environment. The TALIS 1 project has given some initial contributions to this with the elaboration of the Federation Architecture and two applications for pilot situational awareness.

The Federation Architecture and the two flight deck applications have been conceived, documented, developed and integrated into a prototype cockpit. The demonstration has been run. That required a high degree of innovation, on the software-technology and operational levels.

Many subjects would merit continuation and have therefore been enumerated in this report: operational validation of the architecture and the applications, additional applications, additional architecture features, additional off-the-shelf components, life-data, life-trials etc. However, others have been found unsatisfactory: lacks in UML, reliability of the chosen off-the-shelf middleware for the software architecture etc.

These are the results of the TALIS 1 project. All partners have already gained value through the additional know-how that has been acquired. There is some potential for early exploitation disregarding the high innovative character of the project. Continuation with TALIS 2 or another successor project is uncertain at the moment of editing these last lines.




7. ACKNOWLEDGEMENTS

The Consortium would like to thank the EU project co-ordinator F Ferreira, and the reviewers M. Garcia, R.-J. Molemaker and B. Cloos.

The EEC would like to thank Y. Lambert, V. Aguado, J.M. Garot, P. Andribet and V. Duong for their management support. Financial and juridical support was provided by P. Cauwenbergh, M.C. Pinto, M.M. Pesty and B. von Erlach. Secretary support was provided by A. Pernel, C. Begault and M. Jürgens. Technical preparation was conducted by E. Parmigiani (ext) and M. Bernier (ext). The student on the project was J. Bauer (ext). The technical team during project execution consisted of J. Ikhlef, R. Maddock, M. Bernier, A. Hally, and A. Castrogiovanni (all ext). Project management assistance was given by A. Simonin (ext), project initiation and co-ordination by R. Ehrmanntraut.






Projet CNS-Z-TA – Rapport CEE n° 398 51


TRADUCTION EN LANGUE FRANÇAISE

1. SYNTHESE

Le projet TALIS 1 (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems - Phase 1) a été mené de septembre 2001 à février 2004 par un consortium regroupant 5 partenaires : LIDO, NLR, SKYSOFT, THALES Avionics et le Centre Expérimental d'EUROCONTROL (CEE). La coordination en a été assurée par le CEE. Le coût total de ce projet a été de 4,4 millions d'euros, cofinancés à hauteur de 50% par la Commission Européenne (DG-IST), dans le contexte de son 5e programme-cadre pour la recherche-développement.

TALIS contribue de manière innovante à l'amélioration de l'efficacité et de la sécurité de l'ensemble du système de la circulation aérienne et propose des solutions technologiques modernes pour renforcer les moyens dont dispose le pilote pour prendre ses décisions, en lui fournissant des renseignements sur la situation environnante grâce au partage intégral des informations. TALIS traite également de l'importance du rôle que jouent les normes et la certification de l'avionique dans l'amélioration du service mis à la disposition des citoyens européens.

L'objectif de TALIS est d'étudier la viabilité d'une approche fondée sur des architectures normalisées, et les avantages à en attendre, dans le but de fournir aux pilotes une image de la situation qui permette d'améliorer la sécurité et l'efficacité du processus de gestion du trafic aérien, lequel implique des interactions entre le sol et l'air, de procurer des avantages aux voyageurs et de renforcer la compétitivité de l'industrie européenne. TALIS a porté sur l'étude d'une architecture logicielle innovante, qui permet l'intégration rapide, facile et bon marché de technologies aéronautiques, en faisant appel à des composants standard du commerce, afin d'accélérer les développements de système, généralement longs, notamment pour ce qui est de l'intégration air-sol, et de jeter ainsi les fondements des partages futurs d'information entre tous les partenaires, et en particulier les aéronefs. L'architecture logicielle a pour rôle d'intégrer les technologies de liaison de données air-sol, d'offrir une infrastructure de logiciels intermédiaires par composant, de permettre la découverte dynamique de composants dans le système (d'où le nom d'architecture fédérée) et d'utiliser des composants standard du commerce. Deux applications novatrices pour le poste de pilotage, qui améliorent la connaissance que le pilote a de la situation, sont développées : la liaison montante des informations météorologiques et celle des informations de trafic.

TALIS 1 est un projet innovant, à plusieurs titres. Il applique le "concept de services" pour une disponibilité dynamique, à l'échelle mondiale, de services aéronautiques interopérables ; il crée une architecture fédérée d'infrastructures de services dynamiques et par composant ; il intègre les principes d'un navigateur poste de pilotage pour la recherche d'information ; il conçoit des applications qui améliorent la connaissance que les pilotes ont de la situation environnante grâce au service d'information sur le trafic en mode contractuel et au Service de météorologie ; il innove avec un protocole de partage intégral de l'information, prêt à être normalisé ; il étudie l'information contextuelle pour un traitement intelligent de l'information ; il crée un système OUVERT pour permettre un processus communautaire ; il fait appel à des logiciels standard du commerce (COTS) pour réduire le coût des systèmes et en augmenter la fiabilité ; enfin, et ce n'est pas le moindre aspect, il utilise la portabilité du langage Java en faveur de systèmes très dynamiques et autoréparateurs.


52 Projet CNS-Z-TA - Rapport CEE n° 398


Pour démontrer et vérifier ces caractéristiques, le projet TALIS 1 a mis au point un prototype dans les locaux de THALES Avionics à Toulouse, qui consiste en un simulateur de cockpit doté de moyens renforcés, une infrastructure TALIS faisant appel au langage Java, qui exploite l'architecture fédérée et les serveurs de deux applications TALIS initiales.

Le présent rapport clôture le projet TALIS 1. Toutes les fonctions principales ont été mises en œuvre et peuvent faire l'objet d'une démonstration. Un jeu complet de documents décrivant les besoins des utilisateurs, les spécifications et la conception peuvent être consultés sur le site web de TALIS (http://talis.eurocontrol.fr). Le projet a été exécuté dans un contexte difficile, puisqu'il a démarré en septembre 2001, mais le Consortium est fier de présenter ces résultats. À la date de rédaction du présent rapport, la suite n'est pas claire, mais plusieurs membres du Consortium ont des projets d'exploitation de ces premiers résultats.

2. INTRODUCTION

La gestion du trafic aérien (ATM) a pour mission de gérer la circulation aérienne dans de bonnes conditions de sécurité, d'ordre et de rapidité. Le système ATM actuel fonctionne aux limites de sa capacité dans les régions à forte densité de trafic, et des concepts nouveaux sont nécessaires pour accroître cette capacité. De nouveaux concepts opérationnels tels que les communications contrôleur-pilote par liaison de données (CPDLC) et le système embarqué d'assurance de séparation (ASAS) laissent prévoir un accroissement de la capacité grâce à une intégration air-sol plus poussée, et à une prise en charge du trafic concertée entre les pilotes et les contrôleurs. Toutefois, s'il est possible d'accroître la capacité, il est nécessaire de renforcer la sécurité, au moins au même rythme, pour améliorer la performance globale du système. Sur le plan de la sécurité, il est donc impératif d'accroître de manière harmonisée la connaissance que pilotes et contrôleurs ont de la situation. Cette connaissance de la situation est en particulier en retard dans le cas des pilotes, qui sont très peu au courant de la situation ATM ! TALIS est un concept technique qui contribue à améliorer la connaissance qu'ont les pilotes de la situation environnante, et apporte donc une contribution directe à la sécurité et une contribution indirecte à la capacité.

Le niveau élevé des coûts de l'intégration air-sol est un problème important. Toutes les technologies qui intègrent l'air et le sol demandent de longs délais entre la recherche et la mise en oeuvre, pour des raisons qui tiennent à la sécurité, aux coûts de l'intégration de l'avionique et à la nécessité d'un déploiement des infrastructures à l'échelle mondiale. Les délais de mise en oeuvre de nouvelles technologies se chiffrent habituellement en décennies, comme l'illustrent le cas des GPS certifiés dans le domaine de la navigation (par opposition à l'exploitation de masse du GPS dans le domaine général, l'automobile ou le domaine maritime). Le concept TALIS vise à réduire le délai de mise sur le marché des nouveaux ensembles d'avionique, et à diminuer ainsi les coûts de mise en oeuvre, en permettant de tirer plus tôt profit d'un déploiement plus précoce des concepts opérationnels. Le concept TALIS tentera également de réduire le coût de production des nouveaux ensembles, grâce à un recours intensif à des logiciels standard du marché (COTS).

Le paradigme qui sous-tend le concept TALIS est étroitement lié à l’Internet, et spécialement axé sur les utilisateurs mobiles. L'information partout, pour tous, selon les besoins, livrée au moyen d'outils : services, protocoles et navigateurs. Le principe de l’Internet fait l'objet d'études poussées en ce qui concerne les dossiers de sécurité.

Le présent document est le rapport final de la phase 1du projet TALIS, qui s'est déroulée de septembre 2001 à février 2004. Il récapitule les objectifs du projet, les avantages qui en sont escomptés, sa réalisation, et donne un aperçu de la façon dont le projet a été mené.



Projet CNS-Z-TA – Rapport CEE n° 398 53


2.1. APERÇU DU PROJET

Le projet TALIS 1 a été exécuté de septembre 2001 à février 2004 par un consortium regroupant 5 partenaires : LIDO, NLR, SKYSOFT, THALES Avionics et le CEE. Le coût total du projet s'est élevé à 4,4 millions d'euros, cofinancés à hauteur de 50% par la Commission Européenne (DG-IST), dans le contexte de son 5e Programme-cadre pour la recherche-développement. Le projet a été coordonné par le CEE.

2.1.1. Objectifs

L'objectif de TALIS est d'étudier architecture logicielle innovante, qui permet l'intégration rapide, facile et bon marché des technologies aéronautiques, en faisant appel à des composants standard du commerce, afin d'accélérer les développements de système, généralement longs, notamment dans le cas de l'intégration air-sol, et jeter ainsi les fondements des partages futurs d'information entre tous les partenaires distribués, et en particulier les aéronefs. L'architecture logicielle a pour rôle de faciliter l'intégration des technologies de liaison de données air-sol, d'offrir une infrastructure de logiciels intermédiaires par composant, de permettre la découverte dynamique de composants dans le système (d'où le nom d'architecture fédérée) et d'utiliser des composants standard du commerce. Deux applications novatrices pour le poste de pilotage, qui améliorent la connaissance que le pilote a de la situation, sont développées : la liaison montante des informations météorologiques et celle des informations de trafic.

2.2. PRINCIPALES REALISATIONS

TALIS 1 est un projet innovant, à plusieurs titres. On trouvera davantage de détails sur les innovations et les réalisations à la section 5 (version anglaise) ; en voici une synthèse :

• TALIS s'appuie sur le "concept de services", pour une disponibilité dynamique de services interopérables, à l'échelle mondiale ;

• TALIS crée une architecture fédérée d'infrastructures de services dynamiques et par composant ;

• TALIS intègre les principes d'un navigateur de poste de pilotage pour la recherche d'information;

• TALIS conçoit des applications qui améliorent la connaissance qu'ont les pilotes de la situation environnante ;

• TALIS innove avec le service d'information sur le trafic en mode contractuel ;

• TALIS innove avec le service météorologique ;

• TALIS innove avec le protocole de partage intégral de l'information, prêt pour la normalisation ;

• TALIS étudie l'information contextuelle pour des systèmes intelligents ;

• TALIS crée un système OUVERT pour permettre un processus collectif ;

• TALIS fait appel à des logiciels standard du commerce (COTS) pour réduire le coût des systèmes et en accroître la fiabilité ;

• TALIS exploite la portabilité du langage Java en faveur de systèmes très dynamiques et autoréparateurs.


54 Projet CNS-Z-TA - Rapport CEE n° 398


Pour démontrer et vérifier ces caractéristiques, le projet TALIS 1 a mis au point un prototype dans les locaux de THALES Avionics à Toulouse, qui comporte un simulateur de poste de pilotage doté de moyens évolués, une infrastructure TALIS faisant appel au langage Java et les serveurs des deux applications TALIS initiales.

3. CONCLUSIONS

Le consortium TALIS 1 est convaincu que le partage de l'information est, en tant que pierre angulaire d'une gestion systémique de l'information, plus que jamais nécessaire, et que des travaux techniques seront de plus en plus nécessaires pour permettre l'intégration dans le système des systèmes. La performance globale du système de gestion du trafic aérien s'en trouvera améliorée dans toutes ses dimensions : sécurité, capacité, coût et environnement. Le projet TALIS 1 a apporté de premières contributions en ce sens, avec la mise au point d'une architecture fédérée et de deux applications axées sur la sensibilisation des pilotes à la situation environnante.

L'architecture fédérée et les deux applications pour poste de pilotage ont été conçues, documentées, développées et intégrées en un prototype de cockpit. Elles ont fait l'objet de démonstrations. Ces travaux ont nécessité un degré élevé d'innovation, tant au niveau de la technologie logicielle que sur le plan opérationnel.

De nombreuses questions appellent des travaux complémentaires et sont donc énumérées dans le présent rapport : validation opérationnelle de l'architecture et des applications, applications supplémentaires, caractéristiques architecturales supplémentaires, composants du commerce supplémentaires, données réelles, expérimentations en conditions réelles, etc. D'autres aspects ont, en revanche, été jugés insatisfaisants : insuffisance d'UML, fiabilité des logiciels intermédiaires du commerce retenus pour l'architecture logicielle, etc.

Tels sont les résultats du projet TALIS 1. Les partenaires en ont tous déjà tiré profit, sous la forme d'un savoir-faire supplémentaire. Il existe un certain potentiel d'exploitation à bref délai, indépendamment du caractère éminemment innovant du projet. La poursuite des travaux, dans le cadre d'un projet ultérieur, TALIS 2 ou autre, est incertaine au moment où sont rédigées ces lignes.




ANNEXES








ANNEX A - ACRONYMS

Abbreviation De-Code ASAS Airborne Separation Assurance Systems

ADS-C Automatic Dependence Surveillance – (mode) Contract

AOC Aircraft Operations Control

ATC Air Traffic Control

CNS Communication Navigation and Surveillance

CPDLC Controller-Pilot Data Link Communications

EC European Community

EEC Eurocontrol Experimental Center

Eurocontrol European Organisation for the Safety of Air Navigation

FAR Federated Architecture Requirements

FTP File Transfer Protocol

FMS Flight Management System

GmbH Gesellschaft mit beschränkter Haftung (limited company)

HAR High-Level Application Requirements

QAP Quality Assurance Plan

ICAO International Civil Aviation Organization

LIDO Lido GmbH Lufthansa Aeronautical Services

NLR National Aerospace Laboratory NLR

NOTAM NOtice To Air-Men

OMG Open Management Group

PMP Project Management Plan

RMP Risk Management Plan

SA Société Anonyme (limited company)

SAP Software Acceptance Test Plan

SQAR Software Quality Assurance Responsible

SKY Skysoft Portugal

STD Software Test Description

STR Software Test Result

STS Software Test Standard

TALIS Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems

TAV Thales Avionics SA

TBC To Be Confirmed

TBD To Be Done

TBS To Be Specified

THALES Thales Avionics SA

TIS Traffic Information Service

TRR Test Readiness Review

UML Unified Modeling Language (OMG)

USDP Unified Software Development Process




Abbreviation De-Code VPR Verification Platform Requirements

WP Work Package

WBS Work Breakdown Structure

WPS Work Package Specification document




ANNEX B - REFERENCES

[1] EUROCONTROL, 18/06/02, Towards Co-operative ATS - The COOPATS Concept, Version 1.0, EUROCONTROL - EATMP – AGC PROGRAMME.

[2] NASA, Concept Definition for Distributed Air-Ground Traffic Management (DAG-TM), Version 1.0, Sep. 1999, NASA – AATT Project.

[3] EUROCONTROL, 2002, Operational Concept Document.

[4] FAA/EUROCONTROL Co-operative R&D, 19 June 2001, Principles of Operation for the Use of Airborne Separation Assurance Systems ASAS.

[5] Ehrmanntraut, Rudi, 2001, TALIS Services Concept, in proceeding of the FAA/EUROCONTROL Action Plan 5 workshop, Toulouse, France.

[6] Ehrmanntraut, Rudi, A. Hally, J. Bauer, 2002, EUROCONTROL, Intelligent Information And Interactive Systems For Pilot Situational Awareness Enabled By A Federation Architecture, in proceedings of the 21st Digital Avionics System Conference, Irvine, California.

[7] Bauer, Josep, 2002, Diploma Thesis, TUB and EUROCONTROL, Identification and Modeling of Contexts for Different Information Scenarios in Air Traffic Management, http://talis.eurocontrol.fr.

[8] Ehrmanntraut, Rudi, 2003, Alternative Enablers For Airborne Separation Assurance Systems, in the EEC Newsletter of July 2003.

[9] Ehrmanntraut, Rudi, et. al., Apr. 2003, Enabling Air-Ground Integration: Concept Definition For Traffic Information Service In Contract Mode (TIS-C), EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC, 2003.

[10] Ehrmanntraut, Rudi, 2003, Towards a Concept Definition of the Total Information Sharing Protocol, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[11] Ehrmanntraut, Rudi, 2004, Validation Of The Traffic Information Service In Contract Mode (TIS-C) Concept Over VDL Mode 2 With The Acts Simulator, EUROCONTROL Experimental Centre.

[12] Kesseler, Ernst, et.al., Integrating Navigation and Communication Systems for Innovative Services, NLR and EEC, Jun. 2002, in Proceedings of 9th St Petersburg Conference for Integrated Systems.

[13] Ehrmanntraut, Rudi, 2003, System-Of-Systems Integration Of Air-Ground Telecommunications With The Software Connector, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[14] Ehrmanntraut, Rudi, 2003, Towards a System of Systems: Transparent Integration of Air-Ground Telecommunications Using the Connector Technology, EUROCONTROL Experimental Centre, in Proceedings of 10th Saint Petersburg International Conference on Integrated Navigation Systems May 26 - 28, 2003.

http://www.eurocontrol.talis.int/




[15] TALIS Federated Architecture Requirements.

[16] TALIS Consortium, 2003, TALIS Dissemination And Use Plan V1.0, TALIS-WP1-DUP-0018, http://talis.eurocontrol.fr.

[17] TALIS Consortium, 2004, TALIS Standard Document, http://talis.eurocontrol.fr.

[18] TALIS Consortium, 2003, TALIS Application Test Plan Document, TALIS-WP4-WHP-4102, http://talis.eurocontrol.fr.

[19] TALIS Consortium, 2003, TALIS Demonstrator System Purchase Specification, TALIS-WP5-WHP-5504, http://talis.eurocontrol.fr.








ANNEX C - SCIENTIFIC PAPERS AND PUBLICATIONS

The following papers have been produced in the TALIS 1 project and are appended to the final Report:

C-1 Concept of Dynamic Services for Total Information Sharing in Air Traffic Management.

C-2 Intelligent Information and Interactive Systems for Pilot Situational Awareness enabled by a Federation Architecture.

C-3 Alternative Enablers for Airborne Separation Assurance Systems.

C-4 Enabling Air-Ground Integration: Concept Definition for Traffic Information Service in Contract Mode (TIS-C).

C-5 Enabling Air-Ground Integration: Definition of a Total Information Sharing Protocol.

C-6 Bandwidth Simulations of the Traffic Information Service in Contract Mode (TIS-C) over VDL Mode 2 with the Acts Simulator.

C-7 Integrating Navigation And Communication Systems for Innovative Services.

C-8 Transforming Air Transport to a Concurrent Enterprise Technical, Safety and Security Perspectives.

C-9 Total Information Sharing for Pilot Situational Awareness enhanced by Intelligent Systems.





Page 63

FAA-Eurocontrol Workshop, Toulouse, 3-5th June 2002

Concept of Dynamic Services for Total InformationSharing in Air Traffic Management

R. Ehrmanntraut, EUROCONTROL Experimental Centre

AbstractA Service Concept, we will show this in this paper, is a generic approach to enable sharing ofinformation in large systems, and to prepare information intelligently. The Services Concept is aconcept to convert high-level user requirements into a total information infrastructure. TheServices Concept is independent of the application domain or technology. I.e. total informationsharing and the Services Concept can be and will be applied for other businesses and not onlyin the air transport sector. Our scope however is the air transport domain. In the air transportdomain we will limit ourselves to the air-ground integration in its widest sense, and not to air-ground datalink only.

1. IntroductionTotal Information Sharing for air transportservices is an enabler and an integrator forexisting and future concepts of air-groundintegration. In this section we will list current,near term and long term air-ground conceptsand discuss how total information sharingcontributes to or fits into these concepts.

Historically the air-ground integration hastaken a bottom-up approach starting withtechnology and ending with operationalrequirements, probably due to the technicalcomplexity of the air-ground datalink.Therefore many concepts have not beenelaborated in a top-down approach technicalfeasibility being the primary occupation.Operational requirements state the need fora very performing system, that did not andstill does not exist: A perfect datalink systemwould comply with high reliability, robustness,high data transfer rates, short transfer delaysat very low cost. In the next years newtechnical systems will be introduced that profitfrom other mass-markets, especially mobiletelecommunications systems and highbandwidth broadcast systems. These newsystems with higher performances willprobably allow operational concepts to beconceived in a top-down approach. Thefollowing list of air-ground technologies andconcepts is rather unordered and tries to givea rough overview:

The ACARS or FANS-1 datalink has been thefirst available technology for Flight InformationServices (FIS) and Airline Operational Control(AOC) services, but also for ATC relatedservices like Automatic DependentSurveillance (ADS-C) and Controller PilotDatalink Communications (CPDLC). Theimplementation of ACARS is regional, andFANS-1 is also implemented on some specificroutes or big regions (e.g. Pacific). Thereliability has been low or very low, eventhough the performance is increasing. Onecannot speak of a formulated concept forACARS or FANS-1, but many elements of air-ground integration are already present.

The INMARSAT satellite telecommunicationssystems is an almost global satelliteconstellation, which allows datalink. It is mainlyused for airline operations, and is defined asa sub-network for the AeronauticalTelecommunications Network (ATN).

With the venue of the AeronauticalTelecommunications Network one can speakfor the first time of a formulated concept forair-ground integration, defined by ICAO. Itconsists of an operational concept of ADS-C,CPDLC and FIS; and a technical conceptbased on the OSI model (Open SystemsInterconnection, by ISO). The technical OSIconcept is at the moment of editing of thisdocument largely overtaken, however, it hasmany merits which are still of value: first the

Utilisateur

Zone de texte

ANNEX C - 1

Page 64

The Impact of ATM/CNS Evolution on Avionics & Ground Systems Architectures

concept of OPEN systems, which is more thanever a necessity for big systems; second theidea of a system architecture, even if the OSIlayers architecture is a very simple model fromtoday’s viewpoint. The operational conceptsof the ATN will have a longer lifetime than thetechnical concept, as it introduces air-grounddatalink for core Air Traffic Control functions:ADS-C will be implemented in some regionsas a supplementary surveillance means overmainly oceanic or other non-radar regions,using the ATN Internet with satellitetelecommunications; CPDLC will find largepan-European, American and Asianimplementations, using the ATN Internet withVDL-2. The future of FIS over the ATN Internetis relatively unclear. The ATN Internet is aprecursor of total information sharing with theconcept of ubiquitous services.

In the follow-up of ATN and the ATN Internet,there are bottom-up projects working on theintegration of the ATN and IP (InternetProtocol); and on future wide-bandtelecommunications systems.

Mode-S enhanced surveillance has come upwith several datalink trials, but none of themhas found wider acceptance. The ‘EnhancedSurveillance’ is an operational concept whichhas been formalised specifically for Mode-Stechnology2. The central idea of EnhancedSurveillance by down-linking aircraftparameters to optimise Air Traffic Controllers’(ATCO) work is still valid, independently ofMode-S technology. The availability of headinginformation in terminal airspace e.g. is a veryuseful information, and the ATCO does nothave to use other means, today the radio-telephony, to ask for the heading. Theconcepts of enhanced surveillance cantherefore be found again in the ADS-Bconcepts (see beneath). The initial ideas touplink Flight Information Services (FIS) andTraffic Information Services (TIS) have alsoalready been studied by Mode-S, butunfortunately without separation of operationalconcept on one side and technology on theother side.

Automatic Dependent Surveillance –Broadcast (ADS-B) is a future concept, whichis not well expressed by its name. The ADS-B

concept also has a bottom-up history: To usetraffic information in the cockpit for differentservices, amongst others airborne separation.Today ADS-B is much more than its name, itis an operational concept for many airborneservices based on traffic information and intentinformation, and it fuses with ground basedATC services, radar uplink services, SurfaceMovement Guidance and Control Systems(SMG-CS) etc. Many trials and trialsinfrastructures are currently created underlarge number of projects. ADS-B is also aprecursor of total information sharing, and thetendency to include more information, whichis not only related to traffic, into the concept,confirms the need of information sharing.

Airborne Separation Assurance System(ASAS) is an operational concept that hasbeen driven by the former ACAS concepts. Itis a top-down concept that has lead to differentterms in the past, e.g. autonomous aircraftand free flight. These terms are used lesstoday, in favour of the better word ‘Co-operative Air Traffic Services’. ASAS includesthe concepts of Conflict Detection, Predictionand Resolution (CD&R), which conceiveservices for the pilot to make self-separation.The Flight Management System as adistributed processing unit is of greatimportance for CD&R, because computingmust be done in the aircraft. Trials have beenconducted to exchange trajectories betweenthe air and the ground with medium technicalsuccess, and nowadays the focus is laid moreon broadcasting of Trajectory Change Points(TCP) than on trajectory negotiation. The linesbetween ADS-B and ASAS concepts areunclear3. ADS-B includes application andtechnology work, e.g. different RTCA MOPSfor VDL4, Mode-S Extended Squitter and UAT.ASAS focuses more on the services ofairborne separation assurance e.g. trafficmerging, station keeping, implementation ofmanoeuvre and other traffic patterns.

COOPATS (Co-operative ATS) is aEUROCONTROL concept for air-groundintegration for air traffic services in the largestsense, but still only limited to air-ground. Thisconcept is based on a long history on CPDLCservices and airborne situational awareness

2 Mode-S Concept of Operation (CONOPS). 3 … for the author.

Page 65


works. It defines a high numberof services on the air and onthe ground, which enables acontinuum between traditionaland fully delegated ATS. It isthe most recent work on thisside of the Atlantic, andincludes all kinds of servicesfor the pilot and aircraftoperation, including ATS, AOCand airport operations,weather etc. It gives a strongrequirement for totalinformation sharing or systemwide information management(SWIM).

DAG-TM (Distributed Air-Ground Traffic Management)is a NASA concept for total air-ground integration, and statesa vision where the pilot and theaircraft is in the centre of allflight operations, and whereairline fleet management is strongly integratedwith ATS flow management. It is anoperational concept integrating different viewsof a flight and its context, i.e. from gate-to-gate, through all ATC responsibilities, and withall possible airspace constraints like trafficdensity, weather etc. It spans the triangle ofCollaborative Decision Making (CDM) from thepilots’ viewpoint. DAG-TM include conceptelements that are ground-only, and opens awider scope than COOPATS. DAG-TM hasvery strong requirements for total informationsharing.

This finishes the relatively exhaustive list ofoperational and technical concepts on the air-ground datalink. We excluded ACAS being anair-air datalink. The next section will show howthe Total Information Sharing ServicesConcept fits with these concepts.

2. TALIS Services ConceptThe Total Information Sharing ServicesConcept is an enabling concept for alloperational concepts mentioned above,especially COOPATS and DAG-TM. TheTALIS concept is a federation concept for thedifferent services from the different

operational and technological concepts, anddifferent technologies.

Total Information Sharing being defined as anenabling concept does not contain anoperational concept in itself but is driven bythem. The scope of TALIS is the widestpossible, and therefore the operationalconcepts that drive best are COOPATS andDAG-TM, they themselves including CDM,CPDLC, ASAS etc. The TALIS conceptenables all concept elements of theoperational concepts, from gate to gate,through all operational domains like surface-, terminal- and en-route airspace, and at allairspace status like weather, traffic flow,congestion etc. The TALIS concept being afederation concept includes other enablingconcepts and their technology part.

The Total Information Sharing concept islayered as shown in Figure 1.

2.1 Services LayerThe services layer includes all services thatare required by the operational concept andtheir operational concept elements. It isassumed that all information to be shared isshared via services, and all operationalconcepts that need information sharing

DA

G-T

M

AD

S-B

ASA

S

CPD

LC

Enha

nced

Surv

eilla

nce

CD

&R

CO

OPA

TS

CD

M

OperationalConcepts

Services

Architecture

Infrastructure

IP ATN

Inte

rnet

AC

AR

SVD

L 2/

4W

ideb

and

Gat

elin

kSa

telli

teU

AT

MO

DE-

S ES

Federation Architecture

Wx AirTrafficManagement FlowManagementTerrainMaps AirportMaps AirlineLogistics

Context DependantServices

ServicesFederations

UserRequirements shall shall shall shall shall shall shall

Figure 1: The scope of the Total Information Sharing ServicesConcept is to enable the operational concepts, which areexpressed in user requirements, by proposing a layeredarchitecture based on services, services federations and

context dependent services. The Total Information Sharingconcept integrates other technologies for air-ground datalink

and federates them into a single infrastructure.

Page 66


express their needs via requirements forservices. Services can be categorised into airtraffic management services includingseparation assurance services and flowmanagement services, airline logisticsservices also including flow managementservices, information services includinggeographical services like maps and otherAIPs, weather services and much more.

The services layer(s) has a strongrequirement for ubiquitous access, taking intoconsideration that the pilot or aircraft as userof services is mobile on a global basis. Thisrequirement for services access everywhereand at every time produces the userrequirement to discover services dynamicallyand to use the services over a distributedinfrastructure.

2.1.1 Context-Dependent Services

The services layer has a strong requirementfor context-dependent access to services, tosupport all involved parties in their tasks togather relevant information via services for thespecific context the aircraft is in. The conceptof context-dependent services supposes thatservices prepare information in an intelligentway depending on the context (of the aircraft).

� That context may be the specific flightphase the aircraft is in, e.g. when at thegate the pilot gets some rampmanagement services from the airline andthe airport and Air Traffic Control; whentaxiing the pilot gets airport maps andtraffic information services, runwayincursion warning systems, taxi routingservices; when airborne the pilot getsseparation assurance services; whenapproaching the pilot gets airport maps,runway visual range services, other FIS,runway clearances services etc.

� That context may also be the operationaldomains of surface-, terminal and en-routeairspace the aircraft is in, e.g. if aircraft isdelayed on the ground due to airlineconstraints then ATC gets informationservices about departure and vice-versaetc.

� That context may also be the airspacestatus the aircraft is in, e.g. the pilot isinformed if the airspace is congested,when there are important weatherphenomena, when separation assuranceis partially delegated etc.

There should be a certain level of ‘intelligence’to support the pilot at work withoutoverwhelming him/her with uselessinformation, e.g. the pilot is only interested innew weather services if the weather haschanged compared to the initial informationand has either passenger comfort or safetyor economy related impact on the flight; thepilot is alerted about other traffic if it hasinfluence on the own flight, either interferingon separation assurance or traffic flow; thepilot wants to know the impact on the airlineflow management when a big weatherphenomena has to be avoided and aircraftalready airborne; the pilot wants to know theimpact on the airline flow management whenre-routed by Air Traffic Management andaircraft already airborne. These examples ofcontext-dependent services illustrate theintelligent preparation of information to theflight deck.

2.1.1 Services Federations

The services layer in the Total InformationSharing Services Concept has a strongrequirement for services to federate, i.e. tobe able to find another dynamically, to connectdynamically with another, to operate together,and to leave another when a task iscompleted. This is to fulfil the requirement ofhighest possible quality of service, assumingthat not all services are available everywhereor a specific family of services is only availablelocally.4

This is best illustrated with an example. ForASAS purposes the aircraft runs a trafficsituation picture service and an airbornemedium term conflict detection service. Thisservice is configured in a way that it tries to

4 Note: This is not in contradiction with the requirementof ubiquitous services, because services may bedisrupted or only local and yet world-wide, e.g. specificservices are only available on airports, or in specificairspace, or for specific flight context etc.

Page 67


get the highest quality ofservice amongst the availableservices. It will search for theminimal required, mostaccurate and most economictraffic information. We developa scenario where the aircraftflies through airspace withdifferent procedures for co-operative ATS and withdifferent ground infrastructuresregarding traffic services. E.g.if the aircraft is in an airspacewith traditional ATC andwithout ground based TIS-Bservice, then the ASAS servicewill only be based on the mosteconomical ADS-B/VDL4broadcast service where allinformation is received fromother broadcasting aircraft,knowing that not all aircraft areequipped with this functionalityand may therefore not be seen.When coming into a co-operative ATS airspace still with radar butwithout ground based TIS-B, the ASAS servicewill in addition to the ADS-B/VDL4 servicesubscribe to a TIS service based on ATN/VDL2 with only uplinking directly surroundingaircraft and those that the ground detectsbeing in conflict with the own ship. In thiscontext either the task of spacing or theresponsibility of separation is delegated to thepilot. That requires the pilot to be able to seetraffic for one or two concerned aircraft, forexample he/she has to maintain spacing withone leading aircraft. Then only the theseconcerned aircraft are uplinked with ATN/VDL2, whether ADS-B equipped or not. In thenext step of our example scenario a groundbased TIS-B service becomes available;therefore the ASAS service un-subscribesfrom the ATN/VDL2 TIS service and uses TIS-B, which is more economical (for the airline).When in terminal airspace the aircraftoperates in co-operative ATS e.g. stationkeeping on approach. For safety reasons itsubscribes again to TIS over ATN/VDL2 to get

an additional uplink of the leading aircraftposition and flight vector, and it downlinks itsfull own flight vector. Finally, if the aircraft getsinto the region of the destination airport, itsubscribes via IP/Gatelink to a taxi routingservice, and to a TIS service to get all vehicleinformation which comes close to its taxi route.

That complex example illustrates both, thedynamic federation of services and thecontext-dependent behaviour of services.Service federations are a new paradigm tobuild up complex applications over adistributed and network-centric infrastructure.The two main properties of servicesfederations are to be self-forming and self-healing.

• Service federations are self-forming andbased on the principle of servicediscovery. Each service will lookup for theother services it needs and lease theservices it found. The discovered servicejoins the federation and becomes afederate. The federate may also decide toleave a federation, then it alerts the other

ADS-B

TIS/ATN

TIS-BNo TIS/ATN

Figure 2: Example of context-dependent services: The aircraftis flying through airspace 1.) without radar where only ADS-B is

available, 2.) with radar and ATN but no TIS-B, and 3.) withradar, ATN and TIS-B. Depending on the context of co-

operative air traffic services and their criticality, one or severallinks must be used. The context-dependency is managed

automatically.

Page 68


services that have been using it. Thedescribed capability to organise at thelowest level is the most powerful propertyof service federations, as no staticconfiguration is needed. It allows endlessscaling of federated systems withoutadministration explosion.

• Service federations have the importantcapability to be self-healing, especially ifthe service architecture and infrastructurehave been designed to it. A redundantclustering of services over a network or anavailability zone enables redundant lookupand makes services available when theirpeers crash; this case of cold standby candeliver high availability.

2.2 Architecture LayerThe architecture defines the fundamentalorganisation of the system embodied in itscomponents, their relationships to each otherand to the environment and the principlesguiding its design and evolution. Therequirements on the architecture are to bedistributed and network-centric, self-formingand self-healing, be component based and tocomply with Service Oriented Programming,be independent of technology, and last notleast to be OPEN.

The services in the Total Information Sharingconcept are by definition distributed andtherefore the architecture has the requirementto be a distributed architecture: The servicesof the operational concepts will be providedby airlines, airports, Air Traffic Serviceproviders, data services providers, aircraft,pilots etc. all over the world. These serviceswill be interconnected via a variety of networksor connections, air-air, air-ground and ground-ground.

The requirements to be self-forming and self-healing lead to a service-federationarchitecture, brief federation architecture asexplained above. The requirement to be self-forming comes from the fact of big,heterogeneous distributed systems with

responsibility boundaries, that cannot bemanaged from a single central point and thatcannot be managed in a static way. Especiallythe aircraft being a mobile distributed part ofthe system and the different services itaccesses cannot be managed centrally (atreasonable cost). Parts of the system mustbe able to discover themselves when needed,and to manage themselves and their relationsin a service federation. System configurationin a self-forming system is thereforedecentralised and dynamic, in opposition totoday’s central and static system configurationand -management. This type of architectureis relatively new (very new). It has its paradigmin the Internet and Internet services like theWAP, where services are availableeverywhere and also as a function of usercontext, at the moment mainly thegeographical context. In the close future moreand more businesses will be inter-connectedto deliver more and more complex services.There are several architecture proposals forfederation architectures on the table5, but allhave shortfalls.6 The most promising off-the-shelf architectures are OPENWINGS, with thestrong default to be language-dependent(Java) and not directly built onto the Web; andCORBA, with the shortfall to be connector-dependent, static and also not directly buildingonto the Web.

The importance of component-based service-oriented design is paramount for the TotalInformation Sharing concept, being based onservices only. To be compliant with service-oriented programming and component-baseddesign is very much one and the samerequirement, but yet it marks the path fromthe pure object-oriented component towardsthe service component, which may still beobject-oriented. Service orientedprogramming is very powerful if the userrequirements are already expressed inservices. There is also the strong belief thatcomponent software re-use is facilitated bythe definition of services rather than objects.That can be illustrated in an example: Acompany decides to outsource an internal

5 OMG: CORBA; W3C: XML plus tools; IBM: Tspacesand Aiglets; Microsoft: .NET (dot-net); HP: Cooltown;SUN: JINI; Motorola: OPENWINGS

6 Note: Nevertheless the TALIS project will rather selectone of the existing architectures rather than re-inventing.

Page 69


service, e.g. payroll service in the humanresources department. The service is givento an external company. Therefore thecompany has to define where the interfacesare between itself and the service provider,and makes a contract with the serviceprovider. Then it gets the delivery of theservice as defined. Other companies will dothe same thing, and will use the same serviceprovider, thus the service provider is re-used,and may become cheaper. Another advantageof user requirements expressed throughservice definitions and service orientedprogramming is the transparency of theservice once the interface and the contractare defined. A service as required by anoperational need may be delivered by anentire sub-system including people,procedures and infrastructure. It will be withoutimpact to the service user if the serviceprovider decides to automate, as long as theinterface and the contract are not impacted.Yet another advantage of service orientationis that today’s software engineering facilitatesservice-thinking by using ‘use-case’ as definedin the Unified Modeling Language. Thisapproach captures user requirements andconverts it into use cases. If the use case isstructured correctly, then a direct link can bedone between user requirement, userinterface and service7.

The architecture must be independent oftechnology, i.e. independent of platforms,connections, middleware, databases andprogramming languages. Most of these pointsare in people minds, as we all suffer fromarchitectures that have exactly the oppositefeatures. One relatively new point is theindependence of connections. In the past (andat the moment) many IT communities stillbelieve that a single approach tointerconnecting systems is feasible, havingstarted with the telephone, the OSI Internet,the IP Internet, Asynchronous Transfer Mode,GSM, UMTS. Each of these communitiesstate at a moment in time that their approachwill be THE global approach. History has learntus that this is false, there is no and will not bea single connection system! There will be new

small networks in cars, domestic equipment,and still a lot of legacy networking. A newapproach is to federate on an abstraction layerrather than to force communality, and theapproach is the ‘connector’. The connector isa total abstraction of telecommunications,including asynchronous, synchronous andstreaming protocols on one side, and on theother side point-to-point and broadcastprotocols. Another important feature of theindependence of technology and theabstraction from data providers andconnections is that it gives a good requirementfor a container model. In this container modelall component services like data,management, security and connection areprovided to the user services via the container.

Last not least the architecture for the TALISServices Concept must be OPEN. There aremany good arguments for being OPEN, wewill just give some: The air transport industrybeing very big cannot be put on a closedsystem, which is often synonym for single-provider; we need to facilitate competitionwithout paying the cost of separated systems.The air transport industry must find an easyway to standardise services through an OPENarchitecture. The architecture itself must easilyevolve through an open process based onpartnership etc.

Weather

TALIS Domain

Java

ComponentTIS

Flat File

ObjectDatabase

RelationalDatabase Management

Services

SecurityServices

Data Services

Component Services

Platform Services

Connector Services

StreamingProtocols

SynchronousProtocols

Asynchr.Protocols

Network

ApplicationSW

Application Support SW

Middleware

SystemSW and HW

Figure 3: The federation architecture showsthat user services access via a high

abstraction to different underlying serviceslike data services, connector services,

management services and securityservices. These will be delivered by a

container.

7 RSI approach: Requirement, Service, Interface, a wayof modeling user requirements with use cases.

Page 70


2.3 Infrastructure LayerThe infrastructure layer is out of the scope of theconcept of Total Information Sharing; however, theTALIS concept has the objective to federate theexisting technologies and infrastructures.

The integration of the different connectors playa very important role, as the target is air-ground integration. All legacy, current andfuture connectors should be integrated andfederated in the federation architecture asexplained above: ACARS, ATN/VDL2, ATN/SATCOM, IP versions 4 and 6, mobilewideband, ADS-B technologies like VDL4,UAT and MODE-S Extended Squitter, futurebroadcast technologies like wideband satellitebroadcast etc.

The integration of legacy services is also veryimportant, like radar data processing, flightdata processing, flight planning processing,airline flight operations on the ground. In theavionics the integration of flight managementsystems and other flight deck systems e.g.cockpit user interfaces like displays andkeyboards is very important and thearchitecture must be able to comply with thislegacy. That all gives a very strong case forCORBA integration layers in the architecture.

3. ConclusionsThe TALIS Services Concept has beendeveloped in this document. It fixes the scopeof total information sharing beyond air-groundintegration, but is illustrated with air-groundintegration. Therefore the historical, existing andfuture operational and technical concepts of air-ground integration have been analysed and ithas been shown that total information sharingis an enabler for the widest concepts, namelythe Co-operative ATS concept fromEUROCONTROL and the Distributed Air-Ground Traffic Management from NASA.

The logical path from operational concepts, userrequirements, services definitions, context-dependent services, services federations,federation architecture and federatedinfrastructure is given. The importance and thebenefits of a service oriented approach isunderlined. The notion of context-dependent

services and services federations has beenintroduced and their advantages discussed. Ina next step we defined the requirements for thefederation architecture, with the very newnotions of self-forming and self-healingcapabilities by the use of service-discovery.Finally we discussed the integration andfederation of different infrastructures andlegacies, concentrating on the air-groundintegration.

This Services Concept definition and the venueof total information sharing is a milestone in air-ground integration. We expect it to become aleading principle for all further work in thedomain. We recommend everybody toparticipate in the needed efforts, for the finalbenefit of the travelling citizen.

References[1] TALIS White Paper, R. Ehrmanntraut,

Version 0.2, March 2001, EUROCONTROLExperimental Centre

[2] Towards Co-operative ATS - TheCOOPATS Concept, Version 0.5, Nov.2000, EUROCONTROL - EATMP – AGCPROGRAMME

[3] Concept Definition for Distributed Air-Ground Traffic Management (DAG-TM),Version 1.0, Sep. 1999, NASA – AATTProject

[4] Minimum Operational PerformanceStandards for Cockpit Display of TrafficInformation CDTI, http://www.rtca.org/

[5] DO-242, Minimum Aviation SystemPerformance Standards for AutomaticDependent Surveillance Broadcast (ADS-B), http://www.rtca.org/

[6] ASAS Concept

Page 71


[7] Concept of Operations for AirborneConflict Management: Detection, Predictionand Resolution; RTCA SC-186, WG1, May2000, draft version 3.0

[8 ] ICAO ATN Users Manual[9] Introduction to Service Oriented

Programming, Guy Bieber, Jeff Carpenter,Motorola, OPENWINGS. Openwings http://www.openwings.org

Abbreviations and AcronymsACARS Aircraft Communications,

Addressing, and Reporting SystemACAS Airborne Collision Avoidance

System (sometimes referred to asTCAS, one of its implementationversions)

ADS-B Automatic Dependent Surveillance -Broadcast

ADS-C Automatic Dependent Surveillance -Contract

AIP Aeronautical Information PublicationAOC Airline Operational CommunicationsASAS Airborne Separation Assurance

SystemATC Air Traffic ControlATCO Air Traffic ControllerATM Air Traffic ManagementATN Aeronautical Telecommunications

NetworkATS Air Traffic ServicesCD&R Conflict Detection, Prevention and

ResolutionCOOPATS Co-operative Air Traffic ServicesCNS Communications, Navigation and

SurveillanceCPDLC Controller-Pilot Datalink

CommunicationsDAG-TM Distributed Air Ground Traffic

ManagementFANS (-1) Future Air Navigation System by

ICAO, FANS-1 a preliminaryindustrial implementation

FIS Flight Information Services

ICAO International Civil AviationOrganisation

IP Internet Protocol, synonym for THEInternet

ISO International Standard OrganisationIT Information TechnologiesMode-S Secondary Surveillance Radar Mode

SOSI Open Systems InterconnectedTALIS TALIS Project – Total Information

Sharing for Pilot SituationalAwareness Enhanced by IntelligentSystems

TALIS-SC TALIS Services ConceptTIS (-B) Traffic Information Services (-

Broadcast)UMTS Universal Mobile

Telecommunications SystemVDL 2/4 VHF Datalink Modes 2 and 4

KeywordsSystem Wide Information Management

Federation Architecture

Service Oriented Programming

Reference/tasks/talis/eec/doc/2-user-requirements/talis-services-concept

Revision: 1.0 Date: 19 June 2001 / 25 March2002





by intelligent systems (TALIS 1) EUROCONTROL

Project CNS-Z-TA - Report EEC No. 398 73


ANNEX C - 2 INTELLIGENT INFORMATION AND INTERACTIVE SYSTEMS FOR PILOT

SITUATIONAL AWARENESS ENABLED BY A FEDERATION ARCHITECTURE Rudi Ehrmanntraut, Joseph Bauer, Aubin M.A.C. Hally

EUROCONTROL Experimental Centre EEC, CNS, 91222 Brétigny sur Orge, France

Keywords: System Wide Information Management, Air-Ground Integration, Total Information Sharing

Introduction The domain of digital air-ground integration is relatively young for civil aviation, and the move from procedures between pilots, controllers, airport and airline operators using voice towards digital integration of aircraft with ground systems will take its time. The digital datalink that is used or is currently under conception will make the aircraft an integral part of an information system. However, CNS (Communication, Navigation, Surveillance) technologies for datalink have followed a bottom-up development approach, without taking into account a system architecture view. The lack of this global view resulted in customized applications per technology. A federation architecture is needed in applying a top-down approach on system architectural level to integrate the different applications and technologies. The applications that are federated in this architecture must span the widest possible scope of co-operative and collaborative air-ground integration, and include Controller-Pilot Datalink, Airborne Separation Assurance, Collaborative Decision Making, Conflict Detection, Prevention & Resolution, Automatic Dependent Surveillance, Enhanced Surveillance, Surface Movement Guidance, Flight Information Services for ATC, and many other airline applications like pre-flight and in-flight management. The technologies that are federated must be complete and cover ACARS, SATCOM, VDL Modes, Future satellite and terrestrial telecoms, Internet technologies, telephone technologies, broadcast technologies like UAT, MODE S Extended Squitter, VDL4, and future satellite broadcast. The mechanisms for the federation is by abstraction for components, data, connection, management,

security and platforms. We will show in this paper that such an approach is feasible, and develop the building blocks of this federation architecture. Intelligent information for pilot situational awareness is the principle of showing only minimal needed and necessary, relevant information to the flight crew to enable correct human decision making in co-operative and collaborative processes. This information to be ‘intelligent’ requires a process of data gathering and preparation. The data gathering is based on the principles of ubiquitous services – with reference to the Internet principles of everywhere, every time, everybody – and we will develop a concept of information services for the aeronautical sector. The data selection mechanism is based on the notion of ‘context awareness’, and we will show how the context of the aircraft can be analyzed, abstracted, and converted into architectural elements that enable the treatment of information in an intelligent way. Furthermore we will elaborate the concept of dynamic federation of information services, to combine and associate information. Interactive systems for pilot situational awareness are the ability for the pilot to get more than the automatically presented information if needed. We will elaborate a system in analogy to the World Wide Web browser that enables the pilot to browse for more information on a graphical presentation system. The information sources will again be information services, whether in the own ship, the ground or other aircraft. We will develop the architectural mechanisms needed for this type of flight crew interaction. This paper has been created by the TALIS project (Total Information Sharing for Pilot Situational Awareness Enhanced by


74 Project CNS-Z-TA - Report EEC No. 398


Intelligent Systems, http://talis.eurocontrol.fr) which is funded by the European Commission, DG IST, and the project partners LIDO, NLR, Skysoft, THALES Avionics and EEC. The next section treats the federation architecture, followed by sections on intelligent information and interactive systems, to conclude with a summary.

Federation Architecture Federation Architecture Principles The tendency to create Business-to-Business (B2B) applications coupled with the needs for a short Time-To-Market (TTM) has introduced the requirement for machine-driven search and integration of distributed services, which is known as dynamic service discovery. Integration of data and application has for many decades been the focus of the industry. This has led to the development of many distributed, component-based, object-oriented system technologies. Nowadays distributed systems are described as a collection of components and the interaction among those components. Components however, are subject to failure whether partial or total. These partial failures that plagued distributed computing for many years now, have led the industry to shift the focus to service-based architecture. The need for a distributed architecture that can accommodate elements joining and leaving the network in an ad-hoc manner, the need for integration and interoperability with legacy systems based on the service concept, led in its turn to federated systems. A Federation is an interoperation relationship that exists between independent software components or subsystems. Each software component or subsystem can act as a client to each other. The components or subsystems that form the federation are called federates. A federated architecture provides infrastructure services that allow federates to communicate and inter-operate without the need of being concerned about system boundaries.

A federation is event-based and service oriented. A federation can be implemented as ‘Publish-subscribe’ (event-based) system, where components are loosely coupled and communicate through multicast. Components in a federation can be added or removed without the direct knowledge or cooperation of other components.

Integration Principles In the past fifty years as technology evolved new forms of application architecture have emerged that present a need for meta-information services. This technological evolution has first led to networked systems, which simply connected computers and allowed remote access to and from any of the connected computers. The interoperation in a networked system was restricted to the exchange of files. These non-integrated platforms necessitated the development of what is now known as distributed systems. “Distributed-systems are a collection of independent computers that appear to the user of the system as a single computer”. In a federation emphasis is made on interoperability. Interoperability is a very important property that enables information and functionality to be shared among systems operating in the federation. The interaction model of modules in a traditional distributed system has a level of coupling that is related to the type of dependency that exists between these modules. Processing dependency is when processing in a module is dependant on some work to be carried out by other modules (remote or local) in order to complete. Informational dependency is when a component needs to send or receive information to and from other local or remote components. Integration is the second important principle of the Federation Architecture. The given requirement is to integrate all current, next-generation or future datalink technologies with a single, simple underlying paradigm: the connector. The divers technologies are e.g. ACARS, ATN, VDL modes 2/3/4, X.25, SATCOMs, IPv4, IPv6, mobile telephone modes like GSM, GPRS, UMTS and other 3G, but also broadcast technologies like





VDL4, UAT, MODE S Extended Squitter, and future satellite wide-band broadcast. The architecture proposes to abstract these some basic categories of connectors: synchronous and asynchronous, point-to-point and broadcast.

Service Principles Analogous to the World-Wide-Web (WWW), functionality is to the system via services. Services could be anything ranging from for example www.meteo.com, www.atm.com, www.atm.org, www.airport.com, www.flightplan.org, www.air-traffic.com, www.airspace.com, www.airline.com, www.your-travel-agent.com, to www.air-police.gov. These services although very useful by themselves, could serve a more powerful purpose if connected together through a federation. Within a federation, these services will be collaborating, reliable and able to tolerate and survive network failures. Commonly provide services by a federation include: Starting and stopping of a federation, services location and discovery, services registry, federates management and data management services.

What is a service? A service is a contractually defined behavior that can be implemented and provided by any component for use by any component, based solely on the contract [6]. This definition is based on the new paradigm called Service Oriented Programming (SOP), where the focus is on modeling problems in terms of the services that a component can provide or use. For a client component a service denotes a functionality that can be performed by its system environment. SOP identifies the following architectural elements and aspects of services: Contracts – An interface that contractually

defines the syntax and semantics of a single behavior [6]. Contracts establish declared interfaces to the federation required for the cooperating components. Contract specification typically include data and its format, communication semantics, security and other protocols

such as failure and recovery and data exchange.

Components - An individually deployable, binary implementation that provides contractually specified services. Components are subject to third party composition and deployment.

Mobility – The ability to move code around by means of a proxy. A proxy is a local object that replaces the remote object on the local machine. The proxy deals with any network-related functions, transmitting any parameters to the remote services and receiving any return values from that service.

Availability – SOP has the goal to handle partial failures (local or remote), that reduces the availability of distributed systems. High availability in SOP, is provided through redundant network resources.

The high availability of services for its use in air traffic, with its severe safety requirements will drive requirements for dynamic services management. This means that services could be added and removed dynamically, i.e. at run-time. One of the key features enabled with dynamic service discovery is self-forming and self-healing systems. Self-forming because the system will not be statically pre-configured, but instead be built on system components that dynamically join and leave the distributed runtime environment, and user services that discover underlying services at runtime. Self-healing because the distributed runtime environment can be conceived in a way that all services are redundant; if one service fails or stops or leaves the federation, then it can be replaced at runtime with another, redundant service. That feature is of highest importance for the safety-critical air transport system. As will be explained beneath, the dynamic service discovery will be used to introduce the notion of context-dependent services, i.e. agglomerations of services that federate to give a common service, dependent on the current context of the user.




Federation Architecture Building Blocks A federation is a component-based architecture that is composed of modular and reusable components. It is a collection of collaborating software services. Components in a federation architecture are hardware and software components. Federation has the following properties: The Federation is network centric. The Federation is service oriented, i.e.

federated systems are founded on the concept of service.

The Federation must help achieve modularity and reuse of components that make up that architecture.

The Federation must provide information and resources only when they are needed.

The Federation must only provide visibility to needed information.

The Federation must contain failures and information defects and must not propagate these through the entire system.

The Federation must provide interoperability among its components. Interoperability is a fundamental feature of a federation.

In addition to the above-mentioned properties, we briefly discuss some properties found in certain implemented federated systems including TALIS. A federation implies a loosely coupled system distributed across a network. The key concept in a federation is that federates or participants, can join or leave the federation in an ad-hoc manner. Components are the basic units of software that can be composed together to form applications. Components usually have their instances created and managed within a framework. This framework is called a container. Apart from managing components life cycle, a container also provides the basic services that components use to operate and to communicate with other components. Within TALIS we have a meteo component, a Traffic Information System (TIS) component, a Flight Management System (FMS)

component and others. These components make use of the TALIS Federated Architecture (FA) services. The FA is a software environment that allows components to be dynamically instantiated, to provide their services and to use services provided by other components. Just how this propagation of services is achieved, is explained later. The FA is designed to optimise the use of components that are distributed across a wide-area network and to operate different distributed computing and e-commerce technologies such as Jini, Openwings and J2EE. To accomplish this, we defined components that abstract some of the core services that are needed for discovery, startup, shutdown, maintenance, recovery, load balancing and monitoring of TALIS components. Some of these component services are discussed below and a conceptual architectural overview of TALIS is provided. Connector services. Connectors represent the communication glue that captures the nature of an interaction beween components. Connector services provide TALIS with the following facilities: Transport protocol abstraction facilities. Connectors provide facilities to connect

component that execute on the same or different networked machines.

The Architecture Description Language (ADL), which is the modeling language for service-oriented systems, defines two primary interface types for components: interfaces that components provide to other components and interfaces that use functionality from others. These interfaces are called ports and roles. Each role of the connector defines a participant of the interaction represented by the connector. There are two roles: the sender role and the receiver role. These roles translate into sender and receiver proxies in the connector services. Event services. The event paradigm is often used to federate new or existing systems and components to interoperate. Event services allow components to communicate with each other via implicit




invocation. In this architectural pattern, components publish the details of their services and clients can register their interests, so that they can be notified when a particular event of their interest occurs. An event is an asynchronous message containing details of an activity, which has occurred within a component or has been detected by the component. Events can be distributed on the network (LAN, Inter/Intranet). Examples of events in TALIS are weather updates, aircraft positions updates, severe weather notifications and others. The TALIS Federated Architecture has abstracted this event-based mechanism to allow for reusability and de-coupling from any particular event-based framework. Registry services. The registry services are used by components to advertise their existence in the federation and to search for other advertised component services.

RMI

JMS

MDB

JCA


Air/GndComm.

Network

J2EE


Security Services

Components Services

Service Handler

Message Handler

J2SE


Time Mgr.

Flight Phase

Figure 1. TALIS architectural overview

As depicted in the figure above, TALIS FA is composed of three layers: The FA layer, the Openwings layer and the Java layer. The Java layer provides a set of services to its deployed components. These services are hidden from the application components through a simplified application programming model.

These services include: Load balancing – By replicating its

container services across the network, a share of processing load can be achieved and therefore a better overall performance of a deployed system.

Asynchronous Messaging - J2EE provides this through Java Messaging Service (JMS).

Management Services – J2EE provides component monitoring facilities through its Managed Beans technology. Managed Beans or MBeans are plug-ins that can be added to a component at run-time to monitor its operations.

Message Driven Beans (MDB) – To take full advantage of the asynchronous messaging mechanism provided. MDBs participate in the messaging services provided by JMS.

The Openwings layer is a service-oriented architectural framework, based on Service Oriented Programming (SOP). It is intended for building self-healing, self-repairing and network-centric systems. Openwings builds on Java and Jini by providing components that can be installed over the network. Some of the services provided by Openwings are of particular interest to TALIS, like its Component and Connector Services. Openwings component services provide abstraction of the service discovery and lookup. The following are some goals, among others, as defined by the Openwings community to be provided by the Openwings component services: Service APIs that abstracts the

communication between components. The ability to provide, locate and use

services independent of any location/lookup mechanism.

Allow services to be provided, located and used by components over the network.

Support location of services based on a unique service identifier or a set of attributes describing the service.




The TALIS FA layer introduces a layer of abstraction that: 1. Componetises the services – By providing

components that are self-contained and well specified for easy integration.

2. Greatly reduces dependency to legacy systems.

3. Introduces reusability through the use of patterns.

4. Promotes extensibility. The Message Handler component implements the ‘Publish/Subscribe’ pattern, where events are published and subscribed to. An event could be a message or a service. The event handler hides the identity of its agents. Agents are message producers and consumers. The event handler promotes: Loose coupling of components -

Components do not depend on information about other component’s interface.

Extensibility – Components can be added easily and participate in the messaging process.

Maintainability is greatly improved partly through extensibility and partly through low coupling.

The service handler is another core component within the TALIS FA. In short it provides facilities for: Service Registry – Provides components

with the facility to register and unregister their services.

Service Lookup and Discovery - Provides components with the facilities to discover offered services within the system.

Service Propagation – Facilities to propagate registered services through the entire network.

Dynamic discovery of services is becoming increasingly important. Services are being selected automatically taking into account its location, its context and other semantics information. Currently businesses are moving towards a model where services can be provided ‘anytime and anywhere’. Air-Ground Communication component.

This component abstracts the communication details between air and ground components by implementing a façade to the real air-ground communication API.

Intelligent Information Intelligent Information Requirements The execution of a flight requires a number of different tasks from the pilots - from navigating the aircraft, responding to air traffic control, exchanging information with the airline to some peripheral tasks like passenger entertainment. New concepts of air traffic management add new tasks to the pilot, in that the flight deck will be increasingly involved in decision processes, and a true co-operation takes place between the pilot and controller. This concept is called ‘Co-operative Air Traffic Services’ [2]. In addition, higher automation of airline and airport processes include the pilot in the information chain, and increase pilot involvement. This concept is called ‘Collaborative Decision Making’ in Air Traffic Management. That evolution of the pilots’ work results in an increased need for information treatment in the cockpit. The difficulties of the increased information treatment in the cockpit and the pilot being part in the information chain come from their environment. Cockpit space is a limited resource that is already overloaded with technical devices, and the pilot must be enabled to conduct the current work, flying the aircraft, at the same or increased level of safety. New functionality needed for the enhanced concepts as explained above must be introduced in a non-evasive way, i.e. the pilot should not perceive them as additional workload and they should not interfere with the pilots’ basic tasks. The pilot must be helped in continuing making coherent decisions and not be distracted by the additional functionality. The functionality that is needed for the new co-operative and collaborative concepts is of different nature: A basic functionality is the increased pilot

situational awareness needed to evaluate the need for action in co-operative processes, and monitor the




implementation of maneuvers. Here the flight deck is the drain for all kind of information from environment and ATC tactical data, e.g. the surrounding aircraft identification, position and velocity, clearances for the own ship and potentially also for other surrounding aircraft, airspace status information like dynamic route information, congestion or special use airspace, meteorological information for all flight phases, airport approach slotting, dynamically contributed SID and STAR, runway identification, runway visual range, taxi routing information, maps, gate management and much more.

Decision support and decision making is functionality that traditionally involves the human, typically for controller-pilot exchanges and pilot-airline operator exchanges. In the future these decision processes will increasingly rely on digital information exchanges and protocols like CPDLC, and evolve towards at least triangular processes that include the pilot, controllers, airline operators, airport- and military control. Other types of decision support tools for conflict prediction, prevention and resolution will be supported by tools, provided those reach approximately the capacity of humans.

The concepts foresee new logistics functionality beyond flow management, an evolution in the cockpit in the sense that the pilot will be involved in air traffic flow processes, from pre-flight planning at the last minute, to in-flight tactical flow management. For the airline operations side the pilots’ role will evolve to higher anticipation in airline fleet management, and passenger flow support.

From this impressive list of newly introduced functionality into the cockpit it seems obvious that the pilot must get the best possible support: 1) not to be overloaded with information that is not relevant and that does not contribute to the situational awareness, 2) to have coherent information to support decision and logistics processes and the right tools for the decision protocols. To this end the information must be consequently treated so that it is convenient for the human user.

That is meant with the keyword ‘intelligent information’. However, any type of intelligence is difficult to implement in information systems as has learnt us the domain of Artificial Intelligence. The characteristics of this ‘intelligence’ can be given to reduce its scope and put it on feasible basis. First, the information is tailored to the driving concepts to reduce the possible information. Second, system behavior is in many cases predictable, which helps in the filtering of information. Third, the status of the user or the context can be considered to apply further filtering or preparation of information. The context of the aircraft can be analyzed, abstracted, and converted into architectural elements that enable the treatment of information in an intelligent way. The following paragraphs detail the notion of context and context dependent information.

Context Dependent Information A "Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves "[4]. In an air traffic scenario the aircraft is an entity. Contexts of an aircraft are for example "status", "activity" and "identity". The context “status” contains criteria such as: fuel consumption, remaining fuel, navigational and kinematics data. The context "activity" contains criteria, like the intended flight path (trajectory). Additional entities are the pilot and weather phenomena (e.g. turbulence, storm). They have related contexts (e.g. location, status) with their related criteria. Usually this information (turbulence with its location and status) is not provided in the format of entity and context, but it can be seen as it. This is similar to the relation between information and meta-information. The context can be used by an information system to provide specific information to the user. Based on the contexts, the information system can select information that is relevant to the users current situation.




"A system is context-aware if it uses context to provide relevant information to the user, where relevancy depends on the users task" [4]. This implies that all defined context information is available to the information system. Information scenarios arise by correlating the contexts of different entities, e.g. comparing intended flight trajectories from different aircraft may result in detecting possible conflicts. All useful context combinations should be identified and described in the information scenarios. Information logistic scenarios can be developed based on the context information. "Turbulence" is an example for such an information scenario. The activation can be computed by correlating the context "intended flight path" of the entity aircraft and the context "location" of the entity turbulence. That means, the information scenario "turbulence" is activated, if the turbulence is located on (or in the near of) the flight path. The time of the occurrence of the turbulence has to be taken into account too. The activation of the information scenarios is not a mandatory part of the information system. This can also be done by external components. In fact these kind of systems exist (a medium term conflict can be detected by the medium term conflict detection system – MTCD). After the activation of the information scenario it has to be clarified: "Which information should be available for whom, where, when and how?" The information analysis of the scenarios defines: actors, involved components, work flow, information need, information flow and presentation of information. 1. The actors and involved components

define who needs information and who will provide it.

2. The work flow defines the necessary actions. This leads to the related information need.

3. The information need defines what kind of information are relevant and desired in the specific situation.

4. The information flow defines the distribution of information.

5. The information presentation defines how the information will be presented to the user.

For the definition of these information scenarios a generic description has to be found. This makes it possible to add future scenarios to the information system. Furthermore, existing scenarios can be extended without chnging the implementation. The information scenario “turbulence” can be defined as follows: The actor is the pilot. If the information scenario is activated, the pilot wants to receive information about the turbulence (e.g. strength, location, duration). Based on this information he can follow his predefined flight path or bypass the turbulence. The second solution defines an information need: surround traffic. The pilot needs information about the surround traffic to find an alternative flight path. This information is currently available via different systems, e.g. TIS-C, ADS-B, TIS-B. The information gives the pilot the possibility to find a solution, which he can communicate with the sector controller. The pilot has to implement this solution in co-operation with the sector controller. More information scenarios can be identified and analyzed that are based on the context. These scenarios are based on the main principle of the information logistic – only relevant information are provided to the user.

Interactive Systems Changing Role of Pilot The cockpit is subject to constant changes through the past and the future, with increasing automation of functions that have been or are conducted by humans. Therefore the trend to reduce the number of pilots is still ongoing, and there are serious plans for one-man cockpits and Unmanned Aerial Vehicles (UAV). However, both the one-man cockpit and the UAV are concepts that require still a lot of technical and operational conception and validations, and it is difficult to anticipate the time for the implementation of these concepts in civil aviation. The future concepts that influence the cockpit must take these evolutions into account, as is the case here.




The role of the pilot is changing. His workload is shifting from tactical to strategic navigation, and towards increased implications in flight management tasks for the airline. The operational concepts of co-operative ATS and Collaborative Decision Making, as mentioned above, demonstrate this well. For pilot-controller co-operation e.g. it is obvious that the pilot’s work will evolve in parallel to the changes of the controller’s work; if the controller’s workload is shifted from tactical to strategic, then the pilot workload will as well. This means that planning tasks and involvement in strategic decisions will increase, and execution of tactical clearances decrease. Another example is the participation in flow management e.g. for departure and arrival, and also en-route (keyword tactical flow). The pilot needs the right tools that help to fulfil the new roles in new decision processes, and the new tools need the correct information. Today’s systems in the cockpit are not adequate for that, because of their poor human-machine interfaces for information handling, and very poor link with the ground and hence lack of information. Interaction with the system is sometimes cumbersome, e.g. the keyboard of the Multi Cockpit Display Unit. The next generations of cockpits overcome many of the defaults and put the human in the center of an information system, with more displays, multi-function displays and pointer input devices. The military cockpit shows a further way ahead with the use of enhanced vision (or augmented reality), i.e. an overlay of the natural vision and data about objects, using head-up displays. This type of technology is already available for CATIII landing systems. In the future the same visualization devices can be used to inform the pilot about much more events also coming from outside the aircraft, e.g. runway meteorological information as wind and visual range, runway clearances, taxi routing, gate allocations etc., provided there is a link to ground-based services that can deliver that information.

Interactive Cockpit The interactive cockpit as conceived by the TALIS project (see next paragraph) illustrates how human machine interaction is seen in the next-generation cockpit, and how information services are used for increased pilot situational awareness. Information is shown on graphical user-interfaces, and pilots may select objects and browse for further information on objects, very much as on a WWW page. The Multi Cockpit Display Unit treats only textual information, the other displays like the Navigation Display with an additional vertical window, and also the Primary Flight Display can treat visual and textual information. The information is presented in objects that may have visual instances on several displays at a time. Depending on the design of an application, the behavior of objects may depend on which screen the user interaction takes place. The Traffic Information Service e.g. gives information about other aircraft in the vicinity of the own ship. That information could come from an ADS-B source or a ground-based data server. The pilot may select other aircraft and browse for more information about them, like for example the other aircraft flight plan or the other aircraft trajectory, or its arrival airport, -runway and –slot. This information will be provided by other services from possibly a multitude of information servers at airlines, airports and ATC. The following figure is an example of how the pilot can obtain information on objects for traffic information.




Additional information

On the intruder aircraft

List of allowed action

Traffic

Clickedintruder(Magenta)

Figure 2. illustrates that a service is executed by clicking on an object in the Navigation Display. That service gives additional information related to the object in the vertical window, plus associated actions in the window of the MCDU. The information and further actions that are shown are a property of the service. The location of the service is transparent to the users, and herewith the functionality of the service might depend (if specified) from the actual service that is used. E.g. a TIS service provided by an airport may provide different functions from a TIS service for en-route. The services will then propose different user interfaces. The meteo service developed by TALIS follows the same rules, the pilot is informed about meteorological information via the meteo service, and can browse for additional information through the selection of graphical objects.

The Services Concept The TALIS Services Concept [1] is a system engineering approach for the implementation of the multitude of services defined in [2] and that can be derived from [3]. As mentioned before, the Internet and the WWW with its evolution towards Business-to-Business applications are the paradigm for the Services Concept, i.e. that all functionality of the system is delivered by services, and that services are ubiquitous. Services themselves make use of other services to build up more complex functions.

ASASService

TISService

METEOService

RADARService

Flight PlanService

ADS-BService

CPDLCService

CD&RService

Flight Mgt.Service

METEOService

CDMService

in a/c ATCground

CFMUground

airlineground

airlineground

Figure 3. could be a snapshot for a scenario where the pilot is requested to fly station keeping on a target aircraft to avoid thunderstorms. The pilot has access to the application services like CPDLC, ASAS, METEO and CDM. These application services build upon underlying services, which may be transparent to the user. The location of the source information is transparent to the hirarchy of services, via the abstraction of the architecture.




The “agglomerations” of services are not static but build up dynamically instead, through dynamic service discovery and dynamic service binding, to produce the federations of services. Services join and leave to these federations as the aircraft moves, e.g. a flight from New York to Paris will use the New York airport CDM, SMGCS, meteo and traffic services; then Atlantic meteo, and later the Paris, meteo, traffic, SMGCS and CDM services. The almost impossibility to configure such a system statically leads to the requirements of dynamic service binding. It allows also for much more dynamic local implementation of services, without need for upgrading aircraft. That leads ultimately to very fast implementation times.

The TALIS Project

TALIS (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems) is a project carried out by a consortium in the context of the 5th Research Framework of the European Commission, DG Information Society. The partners are EUROCONTROL, LIDO, NLR, SKYSOFT and THALES Avionics. The objectives are to produce a verification prototype including a cockpit (A380), weather and flight data sources, that demonstrate the Federation Architecture. A special work package focuses on the possibility for avionics certification, considering that the Federation Architecture builds on commercial-off-the-shelf components. The duration of the first phase of TALIS is two years.

Conclusions This paper has investigated on automatic and interactive features of the future cockpit as needed for future operational improvements. In this cockpit the services may be presented to the pilot with graphical objects, and related information and actions about that object are provided to the pilot with the other graphical or textual user interfaces. The pilot uses pointer devices and the keyboard to browse for more information or execute an function from a service. The services that are used in

the cockpit applications are transparent to the user and may be distributed on the ground, and bind together to form federations of services. Therefore the entire system is conceived as services. An approach has been made to analyze the possibility of filtering ‘useful’ information with the notion of ‘context’, ‘context-awareness’ and ‘information scenario’, in the hope that these abstractions will permit to react intelligently to unknown extensions of the system, the system being built on dynamic services federations. An initial approach has been worked out that consists of the information analysis of the scenarios as defined by actors, involved components, work flow, information need, information flow and presentation of information. The requirements of the TALIS Federated Architecture have been specified and its components described. It has been pointed out that a major innovation in comparison to existing component-based and distributed systems are the requirement for dynamic service discovery, and a complete abstraction of telecommunications technology for the air-ground link with the use of ‘connector’. As a positive side-effect, the notion of dynamic service discovery leads to self-forming and self-healing systems. The Federated Architecture has then be broken down into three layers of distinct functionality, and the building blocks have been shown. That summarizes in brief the first findings of the TALIS project. Further scientific work is needed to clarify ‘contextual awareness’ for intelligent information. The Federated Architecture and the cockpit will be further developed and result in a demonstration platform, with the potential of becoming a reference platform for air-ground integration. The documents from the TALIS project will be a first step towards system standardization. The evolution of the cockpit and the pilots’ roles is just about to start in a co-operative and collaborative environment. The full integration of the aircraft into an overall information system will give entirely new possibilities to the improvement of the future air transport system. At the end the traveling citizen will profit from better and safer air transport services.




Acronyms

3G 3rd Genereation Mobile Telephone A/c Aircraft ACARS Aircraft Communications, Addressing,

and Reporting System ADL Architecture Description Language ADS-B Automatic Dependent Surveillance ATN Aeronautical Telecommunications

Network ATS Air Traffic Services B2B Business To Business CD&R Conflict Detection, Prevention and

Resolution CDM Collaborative Decision Making COOPATS Co-operative ATS CORBA Common Object Request Broker

Architecture CPDLC Controller-Pilot Data Link

Communications EEC EUROCONTROL Experimental Centre FA Federated Architecture FA TALIS Federated Architecture GPRS General Packet Radio Service GSM Global System for Mobile

Communication IPv4 Internet Protocol Versions 4 and 6 J2EE Java 2 Enterprise Edition JCA Java 2 Connector Architecture JMS Java Message Service MCDU Multi Cockpit Display Unit MDB Message Driven Beans MODE S Secondary Surveillance Radar MODE S SATCOMs Satellite Communications SID Standard Instrument Departure SOP Service Oriented Programming STAR Standard Instrument Arrival TALIS Total Information Sharing for Pilot

Situational Awareness Enhanced with Intelligent Systems

TIS Traffic Information Service TTM Time To Market UAT Universal Access Transceiver UAV Unmanned Aerial Vehicles UML Unified Modeling Language UMTS Universal Mobile Telecommunications

Service VDL VHF Datalink WWW World-Wide-Web

References

1 TALIS “Concept of Dynamic Services for Total Information Sharing in Air Traffic Management”, Rudi Ehrmanntraut, EUROCONTROL Experimental Centre, CNS, 19 June 2001

2 “Operational Requirements for Air/Ground Cooperative Air Traffic Services, EUROCONTROL, AGC-ORD-01, Edition 1.0, 02 Apr 2001” and “Towards Co-operative ATS - The COOPATS Concept”, Version 0.5, Nov. 2000, EUROCONTROL - EATMP – AGC PROGRAMME

3 Concept Definition for Distributed Air-Ground Traffic Management (DAG-TM), Version 1.0, Sep. 1999, NASA – AATT Project

4 Anind K. Dey “Providing Architectural Support for Building Context Aware Applications” Georgia Institute of Technology; 2000

5 David Garland, Robert Monroe and David Wilde. ACME: An Architecture Description Language. 1997

6 Guy Bieber, Jeff Carpenter. Introduction to Service Oriented Programming.

7 Wade Wassenberg. Protocol Independent Programming Using Openwings Connector Services.

8 General Dynamics, Decision Systems, 2002. Service Basecx Architecture as Enabler for Next Generation Battlefield Systems.

9 Randall Bramley and Co, Indiana University. A Component Based Services Architecture for Building Distributed Applications.

10 Anna Liu, Len Bass and Mark Klein. Technical Note, CMU/SEI-2001-TN-025. Analyzing Enterprise Java Beans Using Quality Attribute Design Primitives

11 Aubin M.A.C. Hally. Eurocontrol White paper, TALIS-WP3-WHP-3104, June 2002. TALIS FA Coneptual Architecture.




ANNEX C - 3

ALTERNATIVE ENABLERS FOR AIRBORNE SEPARATION ASSURANCE SYSTEM

An opinion from Rudi Ehrmanntraut, May. 2003

Headline This is an appeal to the ADS-B community to change its way of thinking, to realise that Mode-S ES and VDL 2 are realities, and to build an optimised system around these available components. It is strongly recommended to mandate Mode-S Extended Squitter, and to promote the idea to augment it with a VDL 2 based Traffic Information System in Contract (TIS-C) mode.

Introduction The community that works towards the implementation of the Airborne Separation Assurance System (ASAS) enabled by Automatic Dependent Surveillance in its broadcast mode (ADS-B) is progressing well, with many initiatives in Europe and U.S.A. However, a recent decision from the main airframe manufacturers in favour of Mode-S Elementary Surveillance based on concerns about spectrum interference with Digital Datalink Mode 4, as well as the easy and cheap feasibility of Extended Squitter, put into question current thinking about the technical enablers of the system. It is useful to consider alternatives that take a system engineering and architecture centric view of the system. An approach is developed where basic and short-ranged position information broadcast by Mode-S Extended Squitter is augmented with information using the Digital Datalink Mode 2 as a point-to-point medium, to enable ASAS applications in the flight deck. This would be based on a mandate for the Extended Squitter, which would have as a consequence that the currently developed Traffic Information System in broadcast mode (TIS-B) would not be needed anymore and could be replaced by a Traffic Information System in contract mode (TIS-C).

The Technical Link Assessment Needs Review The Technical Link Assessment Report [RTCA, 2001] is a good comparison between three broadcast technologies: Mode-S Extended Squitter (ES), Digital Datalink Mode 4 (VDL 4), and Universal Access Transceiver (UAT). To make a long story short, one could summarise that the technically best candidate UAT is not feasible in Europe because of unavailable frequency spectrum, Mode-S is limited to basic position information and may run out of capacity with increasing traffic forecasts, and VDL 4 has the best capacity/feasibility ratio.

However, there are several arguments that lead to a reconsideration of these findings: 1. The implementation of TCAS version 7 and of Mode-S Elementary Surveillance required

updates of the aircraft transponder. That means that an update of the Mode-S Transponders to support the Extended Squitter is feasible, easy, quick, cheap and has no political risk, even when executed with a mandate.

2. VDL Mode 4 when used for ADS-B has problems of co-spacing antennas on the airframe, that are not yet resolved. The observed problems are channel interferences with voice and other VDL modes.

3. Airbus and Boeing support a policy in favour of the Extended Squitter [Airbus, 2003; Boeing 2003].

Given this, the question is not any more about a broadcast link decision, which would now be in favour of the Extended Squitter, but rather how to accommodate the system so that the relatively bad technical performances of Extended Squitter are counter-balanced.




The System Concept Needs Review If one considers the easy feasibility of Extended Squitter, and the fact that industry is clearly supporting that trend, then a mandate for it seems logical and without any political risks. The effect of such a decision would have repercussions on the current system architecture. In current thinking Automatic Dependent Surveillance in Broadcast (ADS-B) mode is not implemented by a mandate. That means that not all aircraft will be equipped with it neither during transition, nor in end-state, and hence the air situation picture on the flight deck would be incomplete, with disastrous consequences on ASAS applications. Therefore the Traffic Information Service in broadcast mode (TIS-B) was invented, first and foremost to fill that gap, but then in addition to augment air-to-air information with other ground-based information like flight information services.

TIS-B is a relatively complex system, and complex means expensive: It requires additional frequency bands for the information broadcast (which by the way are not available), it conceives a complex ground infrastructure with physical and logical information volumes, ground stations etc., and it requires additional radios in the aircraft for the reception on multiple channels. It is expensive to maintain because being a customised system in comparison to one from a service provider, and it is expensive to evolve towards new requirements because the broadcast types of networks are hardly scalable. Also, these subjects are still in the research domain.

If Extended Squitter were mandated, then there would be no need for the ADS-B gap-filler, because all aircraft would at least broadcast their position information, and aircraft equipped with ASAS equipment like the Cockpit Display for Traffic Information (CDTI) could show a complete air situation picture. The problems of Extended Squitter are (1) that it is limited to position information and does not contain trajectory-change-points or other complex flight vector information or aircraft derived data, and (2) that its range is limited to about 120-70 NM depending on the number of aircraft, which is roughly 15-10 minutes flying time. Therefore there is a need for an augmentation system that complements the basic information that it provides.

The next section will develop such an augmentation system, which will potentially give many other added values in comparison to TIS-B.

The Alternative: TIS-C The idea is straightforward: VDL 2 is another datalink that started operations and will be used for Air Traffic Management with the introduction of CPDLC from 2007-2010 (http://www.eurocontrol.int/link2000). That link is available, further investments are ongoing, and it can be used to serve the "augmentation system". VDL 2 is a point-to-point medium, so if information is given to aircraft, it will be uplinked using a point-to-point protocol. In the EEC we have baptised this Traffic Information System in Contract mode, or TIS-C. This works simply in that an aircraft subscribes to ground data sources to get information, and vice-versa [Ehrmanntraut, 2003].

Figure 1 illustrates that with TIS-C several contracts can be made that give different types

of traffic information to the flight deck.

http://www.eurocontrol.int/link2000




The information for ASAS is typically traffic information:

1. We have analysed that most of the ASAS applications like station-keeping etc. only require one single aircraft information. This information could be requested via TIS-C, and in addition other relevant information can be sent to the flight deck, e.g. flight plan, trajectory, etc. One can think of all kind of information, because TIS-C works in a dialog, and even "confidential" information can be sent.

2. Situational Awareness applications need all positions around the own ship, at least as long as there is no conflict, and one can consider the range of Extended Squitter as being sufficient. However, other information like CDPLC clearances from all adjacent aircraft can be sent to the flight deck to compensate for the loss of the party line. That is best done with TIS-C. This simple example shows that the possibilities for TIS-C reach far beyond those of TIS-B.

3. Medium-Term Conflict (MTCD) data can be treated with more intelligence because, at least as long as the aircraft is flying over the core area, more information is available on the ground and can be first treated on the ground in an intelligent way, and then sent to the flight deck. One could consider the ground system to send information about predicted conflicts and surrounding position predictions in a MTCD volume to the flight.

Figure 2 illustrates that in case of MTCD much more information

can be given to the aircraft than with TIS-B.

More Advantages of Various Enablers There are some other arguments that are worthwhile mentioning in brief [Ehrmanntraut, 2002]:

1. Higher categories of ASAS applications like self-separation may require an independent duplication of the link for safety reasons, which can be fulfilled with ES and TIS-C/VDL2. Also it can be foreseen that these high-category ASAS applications need more information than can be provided by ADS-B/TIS-B, as mentioned with the example of MTCD.

2. TIS-C can be used for other reasons than ATM, e.g. airline operational applications. Given that the implementation of ASAS is quite expensive, it could be helpful to share investments between ATM and airlines.

3. TIS-C can be secured with specific protocols, which is very important for national defense. It is impossible to secure broadcast data.

Conclusion This is an appeal to the ADS-B community to change its way of thinking, to realise that Mode-S ES and VDL 2 are realities, and to build an optimised system around these available components. It is strongly recommended to mandate Mode-S Extended Squitter, and to promote the idea to augment it with a VDL 2 based Traffic Information System in Contract (TIS-C) mode.




What is next: All considerations lead to the conclusion that the development of a total information sharing system between the air and the ground is needed, not limited to traffic and basic flight information. One step into this direction is made by the TALIS (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems) project. The interested reader can get more information on the WWW site http://talis.eurocontrol.fr.

References

1 RTCA Free Flight Select Committee, Safe Flight 21 Steering Committee, Eurocontrol ADS Programme, ADS-B Technical Link Assessment Team (TLAT), Technical Link Assessment Report, March 2001, http://www.eurocontrol.int/ads/ADS_Programme_content.htm

2 Airbus, 5th March 2003, Airbus position on VDL mode 4 in the NUP 2 programme.

3 Boeing, 2003, Boeing Position Paper on VHF Digital Link Mode 4 (VDLM4), Data Link Users Forum, Brussels, Belgium, June18-19, 2003

4 R. Ehrmanntraut, Enabling Air-Ground Integration: Towards a Concept Definition of TIS-C, EEC, May 2003, planned for the proceedings of the 22nd DASC 2003, http://talis.eurocontrol.fr.

5 R. Ehrmanntraut, About Alternative Enablers for ASAS, EEC, CNS, Dec. 2002, http://talis.eurocontrol.fr.

The Author R. Ehrmanntraut works since 1996 at the EUROCONTROL Experimental Centre in Brétigny sur Orge, France. Since January 2003 he works on small studies about the strategy of the EEC. He is co-ordinator of the TALIS consortium. From 1999 until 2003 he was CNS Business Area Manager. From 1996 until 1999 he has conducted several projects on air-ground integration. Before 1996 he has worked as development engineer in information technologies in an industrial company. He holds a diploma of telecommunications engineer at RWTH Aachen, Germany from 1991.


http://www.eurocontrol.int/ads/ADS_Programme_content.htm






ANNEX C - 4

22ND DIGITAL AVIONICS SYSTEMS CONFERENCE, INDIANAPOLIS, INDIANA, 12-16 OCTOBER 2003

ENABLING AIR-GROUND INTEGRATION:

CONCEPT DEFINITION FOR TRAFFIC INFORMATION SERVICE IN CONTRACT MODE (TIS-C)

Rudi Ehrmanntraut, EUROCONTROL Experimental Centre (EEC), Brétigny sur Orge, France

Achille Castrogiovanni, Steria, Paris, France

E-mail: [email protected]

Abstract The goal of this paper is to introduce the new Traffic Information Service in Contract (TIS-C) concept, and to give a high-level definition as well as to discuss its performance parameters. It was shown in the study “Alternative Enablers for Airborne Separation Assistance Systems (ASAS)” [1]6 that TIS-C when compared with its broadcast counterpart TIS-B is a better candidate to support ASAS applications. That viewpoint was systematically developed, and a high number of arguments were developed to give evidence. Based on these findings it would be useful to give a better definition of the new TIS-C concept. The objective of TIS-C is to provide the flight deck with many kinds of traffic related information, using point-to-point telecommu-nications. The traffic information may be manifold and concern the own ship as well as its surroundings. The entire scope of the concept will be described by indicating the variety of possible information that can be presented in the flight deck, from the simple positions of other aircraft, to flight vectors, flight plans, trajectories, to airspace information and airport information. Then some of the basic data used in TIS-C: position, flight plan, trajectory, and medium-term conflict will be described. The highest-level use cases of TIS-C will be defined. A first draft of the protocols that will be used

6 All references to conceptual documents from EURCONTROL, FAA, RTCA, NASA and EEC etc. are given in this study and are not repeated here.

between the TIS consumer and provider will be given: a Total Information Sharing Protocol. The architecture of TIS-C will be described and its sub-enablers discussed. Finally there is a conclusion with a number of steps to take if the TIS-C concept is to be brought towards implementation and an extrapolation of future applications is given that could be provided with TIS-C.

Introduction The integration of air and ground for Air Traffic Management is progressing, pushed by operational concepts of Co-operative Air Traffic Services and Collaborative Decision-Making. This trend raises a high number of new requirements concerning data availability in the flight deck. This paper gives a definition of the Traffic Information Services – Contract (TIS-C) concept that enables the flight deck to receive all manner of traffic-related information to increase pilot situational awareness.

Information Sharing

Decision Making

Get TIS

Position

Get Wx

CPDLC

ASAS

Trajectory

CDM

Flight Plan

MTCD

SMGCS

Environment

FlightDeck

Figure 1 Categorisation of TIS.

mailto:[email protected]




On the flight deck there will be two sorts of applications, information-sharing- and decision-making applications. TIS-C falls into the first category by providing the flight deck with information about its own and other aircraft: position, flight plan, trajectory, medium-term conflict, surface movement guidance and control, and environment data (Figure 1). A potential application is shown in Figure 2, where the flight deck is alerted by a ground-based MTCD (Medium Term Conflict Detection) tool about a medium-term conflict, via TIS-C.

TIS-C will make other traffic data available in an intelligent way, e.g. the trajectories or flight plans of aircraft that will be in the conflict area. The application could then predict the situation of the conflict at the time of conflict, as shown in a section below. Figure 3 shows a medium-term conflict from the perspective of the flight deck. Even if the conflicting aircraft is not in the zoom area, i.e. the current volume of interest, its data is still available. The following section defines the concept of TIS-C

ADS VolumeMTCD Volume

Figure 2 MTCD Example

Discussion

TIS-C Concept Definition Vision. Traffic Information Services are an enabler of CPDLC, ASAS and ADS-B operational applications and provide the pilot with information about other flights and their environment. The pilot uses this information for his/her situational awareness e.g. in a CPDLC environment where less information transits via radiotelephony. The pilot requires information when involved in airborne separation procedures, e.g. when tasks are delegated to the flight deck to separate it from leading or crossing traffic.

Context TIS-C relates to CPDLC, ADS-B and TIS-B. In the study “About Alternative Enablers for ASAS” [1] it was shown that TIS-C has

benefits in comparison to TIS-B, provided that there are mandated minimal solutions for ADS-B available, as is the case with Mode-S Extended Squitter. However, the “market” of TIS-C is bigger in comparison to TIS-B and ADS-B concepts because it can handle much more information, not being dependent on customised broadcast technologies.

Scope TIS-C is targeted at airspace with CPDLC operations and ASAS operations. TIS-C covers gate-to-gate operations. TIS-C is targeted at commercial flight operations (in Europe) unless enabling technology becomes more affordable for other airspace users like General Aviation. The time horizon for implementation of TIS-C is linked to the introduction of CPDLC and ASAS;.probably on a voluntary basis for




CPDLC operations and eventually a mandatory basis for some ASAS application categories. As development of TIS-C started only recently, it may not be available at the first introduction stages of CPDLC and ASAS, which are planned for about 2007-2010. TIS-C gives information about traffic to the pilot including surrounding traffic positions, flight plans, trajectories, Medium Term Conflict Alert, Conflicting Aircraft Forecast, Surface Movement Guidance and Control (SMGCS) functions, environment information like airspace status etc. Weather and other applications like CDM (Collaborative Decision Making), CPDLC and ASAS clearances are not directly part of TIS-C.

Goal The goal of TIS-C is to increase pilot situational awareness concerning traffic-related information. Enhanced pilot situational awareness enables the flight deck to participate safely in CPDLC and ASAS operations.

Figure 3 MTCD in the Flight Deck

Outline of Concept TIS-C is a concept where the flight deck is provided with many kinds of traffic related information by the ground using point-to-point data links.

TIS-C is a layered concept; i.e. it is composed of a technology-independent and a

technology-related component. TIS7 (no B, no C) is technology independent and states the ATM requirements for traffic information for situational awareness. TIS-C is linked to a CNS (Communications, Navigation and Surveillance) technology and indicates that the traffic information is provided via a contract, and requires that this is enabled with a point-to-point telecommunications link. One layer affects the other in that the functions that can be provided on the operational layer are directly dependent on the underlying CNS capabilities, due to performance limitations of the air-ground data link. TIS-C is a client-server application where the flight deck is the client that retrieves information from ground-based data servers. The client and the server must respect a common protocol. TIS-C establishes a contract between the client and the server, to which both must comply. The client may end that contract, but not the service provider. The contract also includes safe and seamless hand-over between service providers, e.g. in case the aircraft reaches the geographical limits of one service provider and is handed over to an adjacent one. The information that is handled by TIS-C is related to traffic in the widest sense, and includes early definitions of aircraft position, flight plan, trajectory, medium-term conflict, environment data and airport surface movement and guidance data. The flight deck subscribes to receive traffic information in traffic volumes, which are like cylinders around the position of interest ,normally own ship.

Benefits In this brief paper only a high-level statement can be given on the performance dimensions of TIS-C. TIS-C has safety benefits in that it provides situational awareness for traffic on the flight deck. The safety benefit is directly proportional to the fleet equipage rate and does not depend on population effects. TIS-C does not increase capacity by itself, but is an enabler for capacity increase with CPDLC

7 We do not mention the TIS from Mode-S, which is close to TIS-C with very limited functions.




and ASAS. TIS-C may increase security through shared situational awareness and vigilance, but may also do the contrary if it provides information to intruders of the system. TIS-C has no impact on environment, unless it is combined with e.g. the Weather8 service. Economically TIS-C will need a high investment, hopefully shared with other applications, and will possibly have a late return-on-investment.

Cost TIS-C is an enabler concept that brings cost with it, which can be split into the investment cost and the operating cost. The components on which TIS-C is built need to be in place, i.e. datalink, CDTI in the flight deck, interconnected data servers and service providers on the ground. The operating cost is mainly the air-ground datalink cost, provision of data on the ground, and the maintenance of the entire equipment. The study [1] has argued that this cost is still less than TIS-B, because of possible cost share with other applications, its scalability and the use of the available frequency spectrum.

Sub-Enablers TIS-C being an enabler for CPDLC and ASAS is itself dependent on three major sub-enablers or system components. Avionics: The flight deck needs to be

equipped with graphical user interfaces like a CDTI and vertical display etc., and should link an input device e.g. the keyboard on the MCDU, to the screens. Higher integration with the FMS (Flight Management System) might be very useful to avoid wrong input by the pilots and enable faster response times.

Data link: The aircraft must be equipped with at least VDL-2 (VHF Digital Link Mode 2), or in the future more powerful datalinks.

Consistent flight data: The TIS-C service providers must provide consistent flight data. This gives strong requirements for system-wide information management.

8 The second application that is developed in the TALIS 1 project.

Transition TIS-C has no specific transition problems. ANSPs (Air Navigation Service Providers) could provide the traffic services once aircraft are equipped. When Europe evolves towards higher integrated flight data management the service could be provided from a central entity.

TIS-C Scenario The TIS-C concept can be illustrated with a scenario from gate to gate. Gate: The flight deck receives position

information about neighbouring aircraft, possibly mixed with CDM and aircraft pushback orders.

Surface: The flight deck receives position and vector information about surrounding aircraft and vehicles, possibly enriched with SMGCS guidance signals for taxi routing.

Take-off and Climb: The flight deck receives position and velocity data for aircraft in a high cylinder within a small range, at a high update rate.

En-route: The flight deck receives position information in a large and flat volume with low update rate.

En-route CPDLC: Upon the event of a CPDLC clearance in proximity of the own ship, the flight deck receives traffic information of this aircraft, with the CPDLC clearance.

En-route ASAS: The air traffic controller wishes to apply a co-operative procedure like station-keeping on another aircraft. The controller pushes traffic information with a contract for the lead-aircraft only, with its flight plan and trajectory, at a high update rate for position information.

En-route Conflict: Upon a medium-term conflict, the flight deck receives, if possible trajectory data, otherwise flight plan data of all aircraft that will be in the predicted conflict area, with position data of other aircraft at time of closest point of approach.9 In addition it receives

9 These are measures to optimise air-ground bandwidth, in an ideal environment all position, flight plans and trajectories will always be sent to the flight deck.




positions of other aircraft in a small volume around its position at a high update rate.

En-route Weather Avoidance: If weather has to be avoided, then the same applies as for MTCD to make the flight deck aware of the other traffic that has to be re-routed as well.

En-route: The flight deck receives environment information for sector information, Flexible Use of Airspace etc.

Approach and Landing: The flight deck receives traffic information in a high cylinder with smaller range, possibly combined with airport CDM information and CPDLC services for runway use and visual range etc.

TIS-C Architecture The architecture of TIS-C is based on a client-server model with publish-subscribe event handling i.e. the client, who is the flight deck, subscribes to ground service providers.

UserInterface

ApplicationLayers

BusinessData

FatClient

Nav. DisplayVertical Display

Keyboard

MTCD

WeatherRadar Flight Plan Trajectory

Weather Avoidance

CPDLC CDM ASAS

TIS Context

ThinClient

Dis

trib

utio

n

Pers

iste

nce

Avionics

Ground

Environment-airspace-maps Airport

Figure 4 Layered Architecture

TIS-C does not impose the architecture for client “intelligence” i.e. whether it serves as fat or thin client multi-tier architecture, nor for data persistency i.e. whether data is stored on the flight deck or not. Some functions are duplicated on the air and the ground e.g. it will make sense to include an ADS data tracker in the aircraft in addition to the one on the ground. The same applies for the MTCD algorithm that is allocated in the aircraft to work autonomously with ADS-B data, and on the ground.

Theoretically speaking, TIS-C is not a component in itself but falls into the category of software Connectors [2] that distribute data and events between components. This means that distribution is not an application in itself, it only enables distributed applications. Figure 4 illustrates the layered architecture of TALIS applications. It should be noted that TIS-C is mainly about data distribution and less an application in itself, yet it is put into the schema to show flight context dependencies.

ADS-BReceiver

Intent

4D Position + Intent

TrajectoryConverter

4D Trajectories

ADS-B MTCDAlgorithm

Conflicts

TIS-CAir

Own Ship 4D Trajectory

MTCD Check

Flight Manage.System

MTCD Fusion

Verified Conflicts

Conflicts + Tracks + 4D Trajectories

SurveillanceData Processing

FlightData Processing

TrajectoryPrediction

MTCDAlgorithm

TIS-CGround

Conflicts

4D Trajectories

Radar Tracks Flight Plans

MTCD +ADS Volumes

Figure 5 MTCD Functional Architecture

Figure 5 shows some building blocks of the functional architecture, where integration with ADS-B technologies is illustrated for the MTCD case.




TIS-C Use Cases

Get TrafficInformation

PositionGround FP

Ground Traj

Trajectory ADS-B Intent

Flight Plan

MTCD

SMGCS

Environment

FlightDeck

Radar

ADS-B

Ownship

Ownship MTCD

Ground MTCD

Signals + Routes

Ground Database

Set TIS-CContract

Browse TrafficInformation

Standard

Custom

Automatic

Figure 6 High-level Use-Cases

Use-case Get Traffic Information (Figure 6) is the central use case of TIS-C and gives traffic information to the flight deck and other applications on the flight deck, e.g. the avionics MTCD. For optimisation and accuracy it will always use the own ship data, ADS-B data when available, and ground based data. Use-Case Browse Traffic Info allows the pilot to browse through the traffic information. The requirement is not to overload the pilot with information, but make it available either automatically for predefined situations, or to let the pilot browse for more information by selecting objects on the user interfaces and requesting more information about them. E.g. at any time the pilot may select a surrounding aircraft and request flight plan, trajectory, destination airport, runway etc. Figure 7 shows that the pilot can “browse” on the conflict to get the predicted situation of the conflict area. Information about other flights can also be shown with other user interfaces, like the vertical display and the MCDU screen.

AFR8910290 330

Figure 7 MTCD Browser

Use-case Set TIS-C Contract lets the pilots define the details of a TIS-C contract. As explained below there are several types of contracts – predefined standard contracts and customised contracts. In addition the avionics might make automatic modifications of the contract, depending on its context, to optimise contracts for flight phases. This use case is for the settings of the standard and automatic contracts, as well as to input parameters for the customised contract.

TIS-C Application Data Requirements When possible the data dictionary is derived from the AVENUE project [6] data definitions, which should be refined for the optimisation of the air-ground link. Air situation picture

1 Sequence of Track Air situation picture The position data is a subset of Asterix 62 [7] used for TIS-B. For further optimisation only track-elements 1,2,3,5 could be used. Track

1 FlightID Flight ID

2 Integer Track ID

3 LatLong4DPosition Position

4 AirSpeed

Heading

Vertical Rate

Air Vector




Track

5 GroundSpeed

TrackAngle

Ground Vector

6 Integer Data Source Identifier

7 Sequence of LatLong4DPosition

Projected Profile

Flight Plan


2 NbOfAircraft

ICAOAircraftType

AircraftTurbulence

Model

Company

EngineModel

AircraftType

FlightType

ICAOFlightType

RawAcTypeZ

AvionicData

AircraftInfo

3 AirportName

Estimated Off-Block Day and Time (EOBD, EOBT)

ETD (estimated)

ATD (actual)

DepartureInfo

4 AirportName

ETA

ATA

AlternativeAirport

ArrivalInfo

5 FlightInfoRegionTime FlightInfoRegionTime

6 FlightLevel RequestedFL

7 Speed CruiseSpeed


Route

PredictedTrajectory



PredictedTrajectory

Medium-Term Conflict List

1 Sequence of MediumTermConflict

MTCD List

MediumTermConflict

1 CoflictID MTCD ID

2 CPATime (mandatory), StartTime/EndTime (optional)

ConflictTime

3 WakeTurbulenceCategory

CoflictGeometry

OtherFlight

4 CoflictGeometry OwnShip

5 Sequence of PositionCPATime

PredictedTrajectory

AircraftInConflictArea

CoflictGeometry


2 LatLong3Dposition StartOfConflict

4 LatLong3Dposition Closest Point Of Approach (CPA)

4 LatLong3Dposition EndOfConflict ATM Environment and Airport types are not yet defined.

Ad. MTCD In case of a MTCD it was decided to uplink the own ship conflict-geometry as well, even though the flight deck could compute it from the geometry data of the conflicting aircraft. This is to enable an additional check for the validity of the conflict. The own ship should confirm the conflict with its own trajectory information and compare the result with the given information. If there are 'significant' differences, then the aircraft should update the ground server with its own computed trajectory, and the conflict should disappear. Figure 8 is an illustration that the aircraft uses the uplinked geometric conflict information concerning itself to verify the conflict, and in case of discrepancy updates the ground server with its own predicted trajectory computation.




TIS-C GroundServer

Aircraft

Get MTCD

Send own 4D trajectory

Compare ownship conflict geometrybeteen onboard algorithm anduplinked info

Figure 8 Conflict Check

TIS-C Contracts The TALIS system is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service users. Therefore special attention has been put on the negotiation of contracts between service providers and service users. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC (Air Traffic Control) imposing standard contracts for all aircraft and service providers. TIS-C contracts are defined between the flight deck and ground service providers for the delivery of traffic services. One aircraft can make one or more contracts with one or more service providers. Several contracts with the same service provider are useful to have a concatenation of data that leads to superposition for the flight deck. E.g. the flight deck makes one contract for position data in a large volume with a low update rate, another contract for position data in a small volume at a high update rate, and yet another contract specifying MTCD parameters. The aircraft can also make contracts with several service providers, e.g. to get en-route traffic information from a national traffic service provider, environmental data from a central European one, and airport information from a local airport service provider. The contract defines all terms of service provision. It contains a number of paragraphs that are agreed upon. The paragraphs are specific to the service and shall be

standardised for all mandatory paragraphs (parameters) or conform to a convention. The paragraphs of a contract are defined as follows: § TIS Parties defines the roles and the

power of the parties involved in TIS contract negotiation, and may be an entitled service user like the aircraft, AOC, ATC and airport; an entitled service provider; and an entitled third party like ATC and AOC.

§ TISP Policy defines the policy that is applied for the TIS protocol as defined in a section below. It specifies which party is entitled to initiate a negotiation; which party is entitled to end a contract; which party is entitled to update a contract; which party is entitled to initiate the hand-over of the service; whether a standard or custom contract is allowed; and how many contracts may be concatenated. We suggest for TIS that all parties may initiate the negotiation; that all service users and their third parties may end a contract; that all parties may update and initiate a hand-over; that standard contracts are used; and that not more than 4 contracts can be concatenated.

§ TIS Requested Information defines the type of information i.e. aircraft identification, 3D position, time, figure of merit, ground vector, air vector, projected profile, short term intent, intermediate intent and extended projected profile, flight plan whole or leg, or 4D trajectory whole or leg, and MTCD conflict data. In addition it defines data filters like the dimensions of the volume of interest with a parameter for range, relative flight level distance above and beneath; data filter to send only aircraft position for non-ADS-B aircraft; data filter to send only position for one aircraft; and data filter for aircraft in medium-term conflict.

§ TIS Delivery Strategy defines when traffic information is provided, i.e. whether periodically, on demand, on event or on emergency. For TIS we consider the following parameter settings: Periodicity of 3, 5, 10, 15, 30 seconds, above interval of 15 seconds typically 1, 5, 10, 15 minutes; On demand upon a user




interaction; On event is more complex because four types of events are identified, where each event type can have parameters. The four event types are Severity, Information, Flow Management and ATC event.

§ TIS Quality of Service defines the cost of service, the cost-sharing model for the telecommunications cost, and the granted figure of merit.

TIS Standard and Company Contract Traffic Information in the flight deck enables ATC application for co-operative air traffic services. The main users are therefore ATC and the pilot. ATC being a safety critical application, the TIS contracts must comply with minimum performance requirements. Therefore it should be envisaged that TIS contracts are predefined by ATC and all involved parties must comply with the terms. Such a predefined contract is called a standard contract. The same may apply to AOCs and service providers when they negotiate a contract with specific conditions, which are fixed in the company contract. When a user is searching for a service, it should use the service providers with which standard or company contracts exist. TIS for ATC should be based on standard contracts. This summarises the current definition of the contract. The following section defines the protocol that is used between user and service provider.

TIS-C Protocol Requirements The Total Information Sharing Protocol (TISP) is explained in the paper [3], and here is given just a brief summary of its features. TISP is a generic protocol for service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over. TISP can be used by all information sharing applications that need to retrieve data from service providers, and that need to get contractual service delivery; therefore it is not limited to TIS-C.

Lookup Service Server

TIS-C GroundServer A

TIS-C Ground Server B

Aircraft

Lookup Traffic Information Service

Subscribe at Traffic Information Service A

Get Traffic Information Service

Handover to B


Negotiate Service

Figure 9 TISP Protocol

TISP is discussed with respect to its atomic patterns. Figure 9 shows the simplified Total-Information-Sharing-Protocol (TISP), a generic protocol for information sharing of mobile users, with service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over.

Service Provider Discovery Users find services through dynamic service discovery10.

Contract Negotiation A contract is negotiated between the client and the service provider. A contract can also be negotiated between a third party on behalf of a client and a service provider, e.g. in the case that ATC wishes a specific aircraft to receive traffic information. A special case of contract negotiation is when the client or third party sends an existing contract identification, which refers to a previous or standard contract.

Service Subscription The service user is subscribed to the service upon successful negotiation of a contract.

Service Delivery Services are delivered to the users upon successful subscription to the service.

10 In opposition to the ATN where users get service provider addresses through a distributed forward naming service (that we don’t like) called Context Management.




Service Update The user or the service provider can make an update to the contract, to modify the current service delivery without going through an entire contract negotiation.

Service Hand-over The hand-over to another service provider gives the possibility of seamless services to the user. The conditions of the hand-over are defined in the contract. The service provider must comply with these conditions. The service provider forwards the contract with one aircraft to another, probably an adjacent service provider. The next service provider must confirm the hand-over. The service hand-over must be synchronised so that no hole in service provision occurs.

Service End Both sides can initiate the end of service. The conditions for the end of service are stated in the contract i.e. only the client or client party may end the contract for the TIS application, other applications may not have this contractual restriction. The reason for the end of service should be given when it is not at a hand-over, e.g., service not needed anymore, service boundary reached etc.

Other Attractive Features There are some other attractive use-cases of TIS-C that will be highlighted here.

Third Party The negotiation and the subscription to a contract by a third party have been defined above. This very useful feature allows ATC or AOCs to push services for aircraft, without the pilot being the initiator. This is especially useful and economical for the probably cumbersome contract negotiation. This could, for example, result in the negotiation of a standard contract with a service provider for an entire flight region or parts of Europe (Figure 10, left). Very useful is the subscription to services on behalf of the user, e.g. when ATC wishes information to be pushed into the flight deck (Figure 10, right), or the ATCO wishes to apply station-keeping

on one aircraft and pushes traffic information of the leading aircraft to the trailing aircraft.

Push TrafficInformationATC Flight

Deck

Pre-negotiateContract

ATC

AOC

Airport Figure 10 Pre-Negotiation and Information Push

Automatic Contract Modifications The human users or machines may modify contracts. The modification of the contract by a machine may be very useful to optimise traffic information for the current context of the aircraft. This may vary from very basic modification like the adaptation of the volumes of interest for different flight phases and to adapt to own speed etc. up to more complex situational contexts like modifications of contracts when under specific procedures. For example the behaviour for MTCD as described above is a situation where flight information of other aircraft that will be in the conflict is also sent to the flight deck. Other scenarios can be conceived for the combination of specific event types with requests for specific information types. This subject is under investigation and the study [4] gives some first findings.

Reacting on Event Types Four event types have been introduced: Severity-type, ATC-type, Flow-Management-type and Information-type events. Severity type examples are: MTCA, military special-use airspace (SUA) occupied, or significant weather change. An ATC type is when surrounding aircraft receive CPDLC clearances, or surrounding aircraft are transferred to another R/T frequency etc. Examples of flow management types are;. changes to airport departure and arrival lists, surrounding aircraft change from or to ASAS-mode, or weather changes that impact flow management, or availability of flexible airspace. Examples of information types are the updated trajectory from other aircraft, updated flight plans from other aircraft, updated civilian special-use airspace, or less significant weather changes.




It is important to give some guidelines for use because the combination of types can become quite complex and lead to disorganised behaviour. Figure 11 shows the use-case for the delivery strategy of the service provider, with the refined event types.

ServiceProvider

Deliver Service

Periodic

Event

On Demand

Emergency

ATC Type

Flow Mgt Type

Information Type

Severity Type

Figure 11 Event Types

All aircraft should subscribe to severity-type events, at all times. Severity events should lead to a maximum of related information, e.g. SUA airspace events should lead to getting environment data plus trajectories of surrounding aircraft; severe weather changes should lead to weather updates and trajectories of involved aircraft as already explained for the MTCD event. All aircraft should subscribe to ATC-type events, but only in a limited volume. Aircraft may subscribe to flow-type events when under procedures for enhanced tactical flow like sequencing for airports or en-route station keeping. Aircraft should subscribe to traffic information in a large volume at low update rates to enhance situational awareness.

TIS-C Sub-Enablers Avionics are needed for the treatment of different information by the flight deck, and where appropriate show it to the pilots. Therefore the cockpit should be fitted with a Navigation Display like a CDTI, and enhancements should be done for this. A vertical display is very useful for the visualisation of data of vertical interest as during climb and descent flight phases. The displays must be integrated with input devices like a keyboard, usually on the MCDU today, or other pointing input devices. Last but not least a high integration with

CPDLC and FMS will help to update the ownship information.

Air-Ground Mobile Networks The TIS-C concept is based on the availability and sufficient performance of mobile air-ground networks. This can already be achieved by the use of VDL 2; however, it can be foreseen that the performance of VDL 2 will not be sufficient if many aircraft use TIS-C. Research is necessary to develop networks with higher performances. Another mitigation strategy to work around the low performance of today’s air-ground networks is to evaluate the risk of using commercial telecommunications as proposed for the cabin. That may work for some categories of non-critical data.

Consistent And Intelligent Data Management There is a major safety risk if the data that is distributed is not accurate, consistent, available, interoperable, integrated, secure and safe. This needs some improvements in the European ATM system, which requires integration of Central Flow Management Unit, Air Traffic Service Providers, Airports, military control, airlines with their aircraft, or other independent aircraft. System-wide Information Management is required. Figure 12 illustrates that the information-sharing network is based on several data sources. These must be accurate, consistent, available, interoperable, integrated, secure and safe.

RadarGroundStation

Mode-S ES & TIS-C equipped aircraft

ADS-B GroundStation

SurveillanceData

ADS-BRouter

WeatherData

WeatherServer

CPDLC&CDMServers

ConsistentFlight Plans

TIS-CServer

ATC&AirportData

VDL2 or other point to point

SMS or GPRS

ConsistentTrajectories

Medium TermConflicts

EnvironmentData

Figure 12 System-Wide Information Management




TIS-C Future Evolution

Towards Implementation There will be a number of decision points before TIS-C can be implemented. Being an enabler for CPDLC and ASAS it also depends on the implementation of these. The ASAS community, which is closely linked with ADS-B and TIS-B, must be convinced that TIS-C has advantages in comparison with TIS-B and the defenders of UAT and VDL 4. Technically the TIS-C concept has to define its telecommunications performance, prove that it is feasible over VDL 2, and show the performance limits. Technically, TIS-C has to be validated, with a special focus on safety. Institutionally, TIS-C has to be standardised. Economically, TIS-C has clear benefits in comparison to TIS-B, yet both TIS –B or –C must show adequate returns on investment.

ASASService

TISService

METEOService

RADARService

Flight PlanService

ADS-BService

CPDLCService

CD&RService

Flight Mgt.Service

METEOService

CDMService

in a/c ATCground

CFMUground

airlineground

airlineground

Figure 13 New Applications Prototype

New Applications One of the features of TIS-C in comparison to its competitors is that it is scalable and allows for new applications with minimum effort using the same initial infrastructure. If the trend towards co-operation in ATS continues, then it can be imagined that a high number of new and additional applications will develop next to and in TIS, because all information that is provided to the controller today will be needed on the flight deck tomorrow. Also other information like gate-management, passenger management etc. will be given to the flight deck in the right context. The TALIS project foresees a higher integration between the information-sharing part that is provided by TIS-C and the decision-making applications like CPDLC; ASAS and CDM. The arrival of more flow-related applications is foreseen, e.g. the severe-weather-avoidance-routing application shown in Figure 12 that combines TIS, Weather, and tactical flow management, eventually enabled by station-keeping. Figure 13 illustrates the prototype cockpit from THALES Avionics as used in the TALIS project. In the future one could combine weather- and traffic information services with tactical-flow-management- and separation services.

The TALIS Project The TALIS (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, http://talis.eurocontrol.fr) project develops specifications and prototypes for a distributed information-sharing system providing TIS-C and Weather services. The approach of the project is to focus on the overall integration of existing system components into a system of systems with the help of a Federation Architecture. This Federation Architecture will handle collaborative, co-ordinated, distributed, and consistent information-sharing and decision-making.





Figure 14 TALIS Project

Requirement, specification and architecture documents for TIS-C will be available on the WWW soon. A demonstration is planned for early 2004. Figure illustrates the vision of the TALIS project: A collaborative, distributed, interoperable, consistent, available and integrated information sharing system [5].

Conclusions This paper defined the concept of TIS-C, with a discussion of vision, context, scope, goal, outline of concept, cost, benefits, sub-enablers and transition. Further paragraphs have covered detail for most of these, with a special focus on the outline of the concept itself. The solution that is presented is a contract-based protocol between the flight deck as a primary client and ground-based service providers. The paper arguments that it is important to base the relationship of service consumer and user on a contractual basis, primarily for safety reasons in a commercial environment. Furthermore the information that is distributed by TIS-C is defined: position, flight plan, trajectory, MTCD, but leave SMGCS and environmental data undefined at the moment. TIS-C needs to be based on a globally acknowledged protocol that will enable operations and interoperations world-wide. The TALIS consortium is convinced that TIS-C is the way forward for the support of CPDLC, ASAS and CDM, and any future concept like tactical flow management and integration with ground automation. The combination of these concepts in some

powerful future applications for the flight deck has been demonstrated. The R&D part of the TIS-C concept is well advanced. Ongoing studies confirm its feasibility over VDL211. Decisions in favour of the concept are now needed for further elaboration and validation. TIS-C has cost-benefit advantages in comparison to TIS-B. The authors believe that nothing should really stop TIS-C.

Acknowledgements This paper has been created for the TALIS project funded by the European Commission, DG IST, and the project partners LIDO, NLR, Skysoft, THALES Avionics and EEC. We thank the European Commission officers, as well as stakeholders in EUROCONTROL for their support.

The Authors R. Ehrmanntraut has been working since 1996 at the EUROCONTROL Experimental Centre in Brétigny sur Orge, France. Since January 2003 he has worked on the strategy of the EEC. He is co-ordinator of the TALIS consortium. From 1999 until 2003 he was CNS Business Area Manager. From 1996 until 1999 he conducted several projects on air-ground integration. Before 1996 he worked as development engineer in information technologies in an industrial company. He holds a diploma of telecommunications engineer from RWTH Aachen, Germany from (1991). A. Castrogiovanni has a degree in computer-science engineering from the University of Napoli "Federico II" from 2002. He works for the TALIS project at the EUROCONTROL Experimental Centre on the design of TIS-C. His fields of interest are UML and XML.

11 Soon to come: Assessment of TIS-C over VDL2




References [1] Ehrmanntraut Rudi, Dec. 2002,

Alternative Enablers for ASAS, EUROCONTROL Experimental Centre.

[2] Ehrmanntraut Rudi, 2003, System-Of-SystemS Integration of Air-Ground Telecommunications with the Software Connector, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[3] Ehrmanntraut Rudi, et al., 2003, Towards a Concept Definition of the Total Information Sharing Protocol, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[4] Bauer Joseph, 2003, Identification and Modeling of Contexts For Different Information Scenarios in Air Traffic, TU Berlin and EEC, Diplomarbeit.

[5] Kesseler Ernst, et al., 2002, Integrating Navigation and Communication Systems for Innovative Services, NLR and EEC, in Proceedings of 9th St Petersburg Conference for Integrated Systems.

[6] AVENUE data dictionary, http://www.eurocontrol.fr/projects/avenue/.

[7] EUROCONTROL, 2000, Standard Document for Surveillance Data Exchange Part 9, Transmission of System Track Data, SUR.ET1.ST05.2000-STD-09-01.

Acronyms ADS-B Automatic Dependent Surveillance -

Broadcast AOC Airline Operations and Control ASAS Airborne Separation Assurance System ATC Air Traffic Services ATM Air Traffic Management ATN Aeronautical Telecommunications

Network ATS Air Traffic Services ATSU Air Traffic Service Unit, sometimes used

as synonym for Air Navigation Service Provider (ANSP)

CDM Collaborative Decision Making CDTI Cockpit Display for Traffic Information CNS Communications, Navigation and

Surveillance COOPATS Co-operative ATS CPDLC Controller-Pilot Data Link

Communications DG IST Direction Generale – Information Society

and Technology EEC EUROCONTROL Experimental Centre GPRS General Packet Radio Service GSM Global System for Mobile

Communication MCDU Multi Cockpit Display Unit MODE-S Secondary Surveillance Radar MODE-S Mode-S ES Secondary Surveillance Radar Mode-S

Extended Squitter MTCD Medium Term Conflict Detection R/T Radiotelephony RWTH Rheinisch-Westfälisch Technische

Hochschule Aachen SMGCS Surface Movement Guidance & Control SUA Special Use Airspace TALIS Total Information Sharing for Pilot


TIS Traffic Information Service TIS-B TIS Broadcast TIS-C TIS Contract TISP Total Information Sharing Protocol UAT Universal Access Transceiver VDL Very High Frequency Digital Link Wx Weather

http://www.eurocontrol.fr/projects/avenue/





ANNEX C - 5 22nd Digital Avionics Systems Conference, Indianapolis, Indiana, 12-16 October 2003

ENABLING AIR-GROUND INTEGRATION: DEFINITION OF A TOTAL INFORMATION SHARING PROTOCOL


E-mail: [email protected]

Abstract It would be useful to define a generic protocol for information sharing on the air-ground link, so that the flight deck could access information services in a standardised, compatible and inter-operable way around the world. Such a protocol, here called Total Information Sharing Protocol (TISP), is defined in this paper. The usefulness of TISP derives from the concept definition of Traffic Information Services in Contract (TIS-C) mode [1], which itself is justified [2] with the introduction of TIS-C in the operational concepts Airborne Separation Assurance System (ASAS) and Controller-Pilot Datalink Communications (CPDLC), and their need for Pilot Situational Awareness. The paper will give an introduction to the concept of TIS-C and discuss the need for TISP, which is its underlying generic protocol. A definition of Total Information Sharing Protocol (TISP) will be given. The Total Information Sharing Protocol is a generic software protocol in client-server12 software architectures. TISP customises the client-server protocol for mobile consumers and for safety-critical applications. It is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service consumer. Therefore special attention has been put on the discovery of service providers, the negotiation of contracts between service providers and service consumer, and a pre-negotiated seamless hand-over between service providers. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline 12 TISP can also be used for services-services architectures.

negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. All these features will be presented in the following paragraphs. TISP is composed of a set of protocol patterns that are the dynamic service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over.

Introduction It would be useful to define a generic protocol for information sharing between system components and their offered services, so that interaction of services can be standardised and operate on a global basis. This would be a prerequisite for the mobile user like the aircraft. The generic protocol would form an important part of the architecture or framework of large distributed systems. Air Traffic Management is such a large, distributed and heterogeneous system, when we consider all Air Traffic Service Providers, airline operation centres, airports, military operations and the aircraft. The future ATM system will link all these with an information-sharing network. A generic protocol for component interaction for information sharing would then allow for the combination of services in so called service-federations. In addition the generic protocol will handle mobility of service users in a seamless and transparent way. There is no equivalent protocol on the mass-market of Information Technology, but the TALIS (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems) project foresees that such a protocol will be needed soon. E.g. mobile devices like telephones, palmtops or laptops will increasingly have access to any





kind of services that are available on the Internet and that have to be paid for. The outcome of a generic protocol like TISP could result in standardised middleware components and platform programming constraints. The generic protocol is defined as the Total Information Sharing Protocol (TISP). In the following sections we will define TISP.

Discussion The discussion will contain both, the definition of the Total Information Sharing Protocol (TISP) and its rationale.

Overview Of TISP TISP is a generic software protocol for client-server13 software architectures (Figure 1). TISP customises the client-server protocol for mobile consumers and for safety-critical applications. It is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service consumer. Therefore special attention has been put on the discovery of service providers, the negotiation of contracts between service providers and service consumer, and a pre-negotiated seamless hand-over between service providers. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. All these features will be presented in the following paragraphs. TISP is composed of a set of protocol patterns that are the dynamic service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over.

13 TISP can also be used for services-services architectures.

Search Engine Server

Ground Appl.Server A

Ground Appl. Server B

Aircraft

Discover Services

Subscribe at Service A

Get Service from A

Handover to B

Get Service from B

Negotiate Service

Figure 1: Total Information Sharing Protocol

The following paragraphs define the elements of the TISP protocol one by one. We will call them protocol patterns or behavioural patterns, or in short patterns.

TISP Pattern: Dynamic Service Discovery Dynamic Service Discovery allows the building up of a system during runtime, e.g. services can be discovered during a flight and then used in the aircraft. The service is used, and when it is no more provided – or needed – or available- it is released and another service is looked for. This is somehow close to the Context Management application of Aeronautical Telecommunications Network (ATN), but has substantial differences! ATN has the same requirement for dynamic use of services for mobile users, but it builds upon a fragile chain where only special service providers may forward other available services to the users, and the user may not make an active search for services. That is very limiting, and possibly even dangerous. In contrast, Dynamic Service Discovery could lead to highly flexible and dynamic system behaviour that would intrinsically lead to self-healing systems [3], and herewith increase system availability, and system safety.




ServiceProvider

User

Publish Service

Discover Service

Naming Service

Trader Service

Proxy Offer Figure 2: Service Publishing and Discovery

Definitions Dynamic Service Discovery (Figure 2) is a protocol pattern that allows a user to discover dynamically the name of a service (or component or object etc.) in a distributed environment through the matching of selection constraints against advertised capabilities. A Search Engine (or trader, or lookup) is a service that facilitates the offering and discovery of services of particular types. A Proxy Forward (proxy offer) is a service from the Search Engine to store a proxy from the service provider and forward it directly to a service consumer upon match of the Service Discovery.14

1. In the first step the service consumer must formulate a search with attribute-value pairs, e.g. Service: Traffic Information Service –

Contract Service Version: X.XX Geo-Availability: Central Europe OR

Germany Service Functions: Position AND

Flight Plan AND Trajectory AND Medium Term Conflict Alert

2. In the second step the service consumer must address this request to a known Search Engine. Different technologies handle this issue differently, e.g. JINI [4], a Java technology, discovers also the Search Engine via a special broadcast protocol. Others assume that the service consumer knows the Search Engine, in

14 Definitions are highly influenced by [13, 14].

analogy with the World Wide Web (WWW)15.

3. In the third step the Search Engine executes the comparison of the request with available service providers and their published services.

4. In the forth step the Search Engine informs the service consumer about matches or mismatches in the request with a list of services.

As mentioned before, today there are three families of technologies that can provide Dynamic Service Discovery service, but which offer different features: CORBA, JINI and XML [5], [6], [7]. None have high market impact at the moment because of the young age of the technologies. The richest capability is provided by JINI, which is however limited to the Java world. CORBA is as usual a very good technical candidate especially for large distributed systems with its integration constraints. XML, because of its similarities with the current WWW will probably be the most commonly used, regardless of its drawbacks like the rather complex SOAP protocol.

Search Engine JINI Lookup

ServiceProvider

User

request service

forward service proxy

publish service

Figure 3: JINI Lookup

JINI (Figure 3) has an interesting feature that allows a user to register with a request and to be alerted whenever a service provider publishes a service that matches the requested criteria. This feature allows very dynamic and highly asynchronous system behaviour, and helps system designers avoid static set-up and system locks at start-up. This should lead to cheaper systems. To register with a Search Engine is a very useful 15 WWW users know Google, Alta Vista and others.




feature that has an impact on the human users, and has operational impact on Air Traffic Management. However, the other additional feature of JINI to use a broadcast protocol for the discovery of Search Engines is not useful in the context of air-ground integration, because these do not allow for this specific protocol. Proxy-offer and proxy-forward have some problems in the aeronautical context, in that forwarding a proxy is equivalent to sending and loading executable code into the clients’ runtime environment. The size and capabilities of a proxy are flexible and depend on the service provider, and a proxy may be very thin and dumb and just providing an interface to the service, - or fat and intelligent and performing local computation in the client’s environment. That means that the aircraft, being the principle client, must allow for mobile code execution, which is a difficult safety issue. One of the difficulties is that the user environment which hosts the proxy must be able to execute it, i.e. its runtime environment must suit the proxy, i.e. runtime environment and proxy must be compatible. That is achievable if it is based on one single technology like Java. However it is not probable that all aircraft provide a single technology environment. CORBA and XML technologies are better for heterogeneous environments, and both allow in principle a kind of code mobility, however, this is not used very often. The TALIS project studies these issues in a dedicated work package [8]. The service discovery enables the user to find a service provider with a set of search-constraints. As a result the user gets an address, or a proxy, and potentially a number of attributes of the service. Once the user knows the addresses of the service providers, it can contact them and go to the next stage of the protocol, the service negotiation. This next step is only necessary for services that require negotiation; for other services the users may directly subscribe with the name of the service or application.

TISP Pattern: Service Negotiation The TALIS system is conceived to operate in an environment of service providers and service users, competition between service

providers, and free choice of services for the service users. Therefore special attention has been put on the negotiation of contracts between service providers and service users. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. Service negotiation is based on contracts. Each service for each application defines its own contract specifics, i.e. the TIS-C application specifies which kind of contract is to be used to get TIS-C services [1], the Weather application specifies contract properties for Weather services and so forth.

Contract

Custom Standard Company

Figure 4: Contract Classification

There are three classes of contracts (Figure 4): custom, standard and company. Custom contracts are negotiated on-the-fly, whereas standard and company contracts are negotiated long before service use. Standard contracts are valid for an entire set of users, e.g. all aircraft that want to use TIS-C in Europe. Company contracts are valid for a number of users, possibly for all aircraft from one airline e.g. to access to one specific service provider at special rates. Custom contracts are special contracts for special requests by the users. One user can make one or more contracts with one or more service providers. Several contracts with the same service provider are useful to have a concatenation of data.




ServiceProvider

User Negotiate Service

Third Party

ATC AOC Figure 5: Service Negotiation Actors

User

Contract

Providern

1

n

n

Application1n

1

n

Figure 6: Cardinalities

The relations between users, applications, contract and providers are defined as follows (Figure 5, Figure 6): Each user can negotiate several contracts with one provider. Each user can have several contracts with many providers. Each provider can serve many users with many applications. One application allows for more than one contract per user, e.g. TIS-C up to 4. The contracts for one application can be with different service providers. Contract negotiation can become quite complex, because it tries to imitate a contract negotiation between persons, which culminates in a legally binding agreement. The topic has arisen in the context of Business-to-Business on the WWW [9], [10], [11], [12], but there are no standards available yet. The World-Wide-Web Consortium (W3C) has started (slowly) to act on standardisation of contract management. TALIS will propose a protocol for contract negotiation in the absence of a standard in information technology. However, if an aeronautical standardisation body like RTCA, EUROCAE or ICAO in the future would like to standardise TISP, then it should investigate whether there are available standards for contract negotiation in the field at that moment in time.

The following sequence diagrams indicate the primary use-cases for contract negotiation (Figure 7, Figure 8). The outcome of a successful negotiation is a service ID that is provided to the user, and with which the user can consequently subscribe to a service.

ServiceProvider

User

propose contract (custom contract)

accept contract (custom service ID)

Figure 7: Custom Contract Negotiation.

Client ContractManager Service

ProviderUser

propose contract (standard contract ID)

accept contract (standard service ID)

get contract ID (application)

Figure 8: Nominal Standard Contract Negotiation

A further simple scenario is when the proposed contract is rejected (Figure 9). In that case the service provider that rejects the contract should give a reason, like service unavailable etc. In case that there are problems with an ATC related standard service, the service provider should alert the third party of ATC.

ServiceProvider

User

propose contract (any contract)

reject contract (reason)

Third Party

inform third party (rejection reason)

Figure 9: Rejected Contract

These simple cases barely reflect a real-life negotiation. There is also the possibility to go into a real negotiation with a ‘ping-pong’




effect between the user or its third party and the service provider.

ServiceProvider

Third Party

propose contract (standard contract)

counter propose contract (modified contract)

counter propose contract (modified contract)

reject contract (modified contract)

Figure 10: Failed Company Contract

Figure 10 shows a failed contract negotiation for a company contract between a third party and a service provider with an exchange of counterproposals. This is allowed to last as long as the negotiation parties wish, and in any detail of the contract. Nevertheless, each negotiation party should take care that the negotiation makes sense, and can stop it by rejecting. If a custom negotiation is done over the air-ground datalink, then the number of counter proposals should be limited to 1 to avoid waste of bandwidth. For in-depth negotiations each party should have a contract manager that sets up the negotiation strategy and fixes limits for negotiated values. This concluded the service negotiation patterns. The user should now have a service ID to subscribe for a service.

TISP Pattern: Service Subscription Users can subscribe to services with the service subscription pattern. There are services that require the negotiation of a contract, and others that do not. In the first case the user subscribes by issuing the service ID that s/he retrieved from the negotiation, in the latter case the user issues the name of the service. Figure 11 shows the two cases of subscription, one with a contract ID and the other one with a name.

ServiceProvider

User

subscribe to service (service ID)

subscribe to service (name, attributes)

Figure 11: Service Subscriptions

A service may be subscribed to on behalf of the user, either in case that this was contractually fixed, or simply if the service allows for it. In this case the third party must give an identity of the user that will benefit from the service. One could consider higher-level applications where the third party subscribes on behalf of sets of users, e.g. an airline wishing that all of their flying fleet gets specific services, or an ATCO wishing that all aircraft in the sector get specific services. This application, however, is not (yet) defined. Figure 12 shows service subscription by a third party; the last case where the third party may indicate sets of users or other grouping criteria has not been specified yet.

ServiceProvider

subscribe to service (service ID,target user ID)

subscribe to service (name, attributes,target user ID)

Third Party

subscribe to service (service ID,sets of user Ids, grouping criteria)

Figure 12: Third Party Subscription

TISP Pattern: Service Delivery The service delivery pattern is straightforward. Services are always delivered to the user, never to the third party.




ServiceProvider

Deliver Service

Periodic

Event

On Demand

Emergency

ATC Type

Flow Mgt Type

Information Type

Severity Type

Figure 13: Delivery Strategies

Figure 13 shows the use-case for service delivery with different delivery strategies that can be defined in the contract, here the TIS-C possibilities. In the case of problems in the service delivery, the user is informed. The same applies in the case that the underlying system encounters problems like transmission problems on the air-ground datalink.

TISPSystem Service

ProviderUser

service abort (origin, reason)


service not compliant (service ID, error)

Third Party

Figure 14: Service Abort

Figure 14 shows that the user can complain when the service delivery does not conform to the contract or other expectations; the service provider can then update, end or must abort16. The abortion may also originate from the underlying TISP system, e.g. connectivity, logical errors etc. In all cases the third party is informed.

16 Note that TIS-C [1] does not allow the service provider to end a service, yet the service provider may abort it, but should have good reasons to do so.

TISP Pattern: Seamless Service Hand-Over The seamless hand-over of services is very important for safety related mobile services if there are many adjacencies between services, or a lot of competition. To simplify service hand-over we suggest that none should be the case. The behaviour depends on whether the service is contractual or consensual. If the service is of contractual nature, then the clauses for service-hand-over are fixed in the contract that is negotiated between the user and the first service provider. That means that the first service provider negotiates with its peers for the hand-over conditions.17 The negotiation depth is also contractual, i.e. whether only the new or adjacent provider is concerned or whether there are chains. The specifications of pre-negotiated hand-over will not be covered here, because of its current irrelevance.

Figure 15: Provider Geometry

Figure 15 is a simplistic illustration that the complexity of pre-negotiated service hand-over depends on the granularity of the service providers. Simplest would be if there were only one provider for ATM services in Europe with one backup. However, the service hand-over itself is important, because it must be sure that the service in the aircraft is not interrupted between the transaction of services.

17 It is anticipated that transaction protocols will perform well here.




ServiceProvider B

User

hand-over (contract ID, service ID,target user ID)

deliver service (service ID)

confirm reception

ServiceProvider A

confirm reception

end service

Figure 16: Service Hand-over

Figure 16 indicates the sequence of a service-hand-over. It is ground-initiated, ground forwarded, user-confirmed, ground ended. This will give high reliability and performance because the air-ground link is only used for confirmation.

TISP Pattern: Service End The end of service depends whether the service is consensual or contractual. If the service is consensual, then any party may request the end of service. If the end of service is contractual, then only those parties that are empowered may end the service. E.g. TIS-C defines that only the service user and the third party may end service, but not the service provider. If the service provider has to end the service, it must use abort and give a good reason for it. The user or third party may give a reason to the requested end of service. If the service is handed over, then the confirmation of the reception that is forwarded between service providers replaces the service end request. If the request for end of service is omitted and the service provider thinks that the service is not really used anymore (Figure 17), it may send a request to end the service to the user or the initiating third party, and should wait about 2 minutes for a reply. If there is no reply, then the service provider may abort with reason. This may happen e.g. if the aircraft is stopped without driving down all services properly.

ServiceProvider

User

request end of service (service ID)


time-out

request end of service (service ID)

subscribe to service (service ID)

Figure 17: Service Abort

The TALIS Project The TALIS (Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, http://talis.eurocontrol.fr) project develops specifications and prototypes for a distributed information-sharing system providing TIS-C and Weather services. The approach of the project is to focus on the overall integration of existing system components into a system of systems with the help of a Federation Architecture. This Federation Architecture will handle collaborative, co-ordinated, distributed, and consistent information-sharing and decision-making. Figure 18 illustrates the vision of the TALIS project: A collaborative, distributed, interoperable, consistent, available and integrated information sharing system [13].

Figure 18: TALIS Vision





Detailed specifications of TISP will be available on the WWW soon. A demonstration is planned for early 2004.

Conclusions The Total Information Sharing Protocol (TISP) is a generic software protocol for client-server software architectures. TISP customises the client-server protocol for mobile consumers and for safety-critical applications. It is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service consumer. Therefore special attention has been given to the discovery of service providers, the negotiation of contracts between service providers and service consumer, and a pre-negotiated seamless hand-over between service providers. In addition the notion of third parties has been specified so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. TISP is composed of a set of protocol patterns that are the dynamic service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over. The TISP protocol could underlie many client-server applications between the air and the ground, and the first candidates are the TIS-C and Meteo applications that are developed in the TALIS project; others will follow. A standardised TISP protocol is a cornerstone for an interoperable global system. We recommend that these findings be forwarded to the international standardisation bodies for Air Traffic Management.

Acknowledgements This paper has been created for the TALIS project funded by the European Commission, DG IST, and the project partners LIDO, NLR, Skysoft, THALES Avionics and EEC.

We thank the European Commission officers, as well as stakeholders in EUROCONTROL for their support.

The Authors R. Ehrmanntraut has been working since 1996 at the EUROCONTROL Experimental Centre in Brétigny sur Orge, France. Since January 2003 he has worked on the strategy of the EEC. He is coordinator of the TALIS consortium. From 1999 until 2003 he was CNS Business Area Manager. From 1996 until 1999 he conducted several projects on air-ground integration. Before 1996 he worked as development engineer in information technologies in an industrial company. He holds a diploma of telecommunications engineer from RWTH Aachen, Germany (1991).

References [1] Ehrmanntraut Rudi, et. al., Apr. 2003,

A Concept Definition Of TIS-C, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC, 2003.

[2] Ehrmanntraut Rudi, Dec. 2002, Alternative Enablers For ASAS, EUROCONTROL Experimental Centre, TALIS Project.

[3] OPENWINGS Availability Specifications, http://www.openwings.org/download/specs/Openwings_Availability.pdf

[4] JINI, http://www.jini.org/

[5] OMG Trader Service V1.0, May 2000, http://www.omg.org/

[6] OMG Naming Service, Revised Edition, Feb. 2001, http://www.omg.org/

[7] W3C Discovery, http://www.w3.org/

[8] TALIS, WP5, COTS Analysis and Certification Report, http://talis.eurocontrol.fr/delivs.html

[9] Caplan Jennifer, October 17, 2001, Contract Automation: Digitizing the Party of the First Part Companies turn

http://www.openwings.org/download/specs/Openwings_Availability.pdf

http://www.openwings.org/download/specs/Openwings_Availability.pdf

http://www.jini.org/

http://www.omg.org/

http://www.omg.org/

http://www.w3.org/




to Web-based applications to better manage corporate contracts, CFO.com

[10] Hurwitz Report, Publicity: Negotiated Trade: The Next Frontier for B2B e-Commerce - TradeAccess Inc., http://www.hurwitz.com

[11] Aberdeen Group, Mar. 2000, Publicity: Negotiated Trade: The Next Frontier for B2B e-Commerce - TradeAccess Inc., http://www.aberdden.com.

[12] Ozro Negotiate, Publicity: Ozro Technology & Solutions, http://www.ozro.com.

[13] Kesseler Ernst, et.al., Integrating Navigation and Communication Systems for Innovative Services, NLR and EEC, Jun. 2002, in Proceedings of 9th St Petersburg Conference for Integrated Systems.

Acronyms ADS-B Automatic Dependent Surveillance -

Broadcast ATN Aeronautical Telecommunications

Network ATS Air Traffic Services ATSU Air Traffic Service Unit, sometimes used

as synonym for Air Navigation Service Provider (ANSP)

CDM Collaborative Decision Making CPDLC Controller-Pilot Data Link

Communications EEC EUROCONTROL Experimental Centre FA TALIS Federated Architecture Mode-S ES Secondary Surveillance Radar Mode-S

Extended Squitter SATCOMs Satellite Communications TALIS Total Information Sharing for Pilot


TIS Traffic Information Service TIS-B TIS Broadcast TIS-C TIS Contract WWW World-Wide-Web W3C WWW Consortium

http://www.hurwitz.com/

http://www.aberdden.com/

http://www.ozro.com/




ANNEX C - 6

BANDWIDTH SIMULATIONS OF THE TRAFFIC INFORMATION SERVICE IN CONTRACT MODE (TIS-C) OVER VDL MODE 2 WITH THE ACTS

SIMULATOR Rudi Ehrmanntraut, EUROCONTROL Experimental Centre (EEC),

Brétigny sur Orge, France, Jan. 2004

E-mail: [email protected] The concept of Traffic Information Services in Contract Mode (TIS-C) is new, in that it proposes client-server protocols between the air and the ground similar to those known from the World-Wide Web by extending these with contractual behaviour for mobile safety applications. The advantages of TIS-C in comparison to Traffic Information Services in Broadcast Mode (TIS-B), especially when combined with a mandate for Automatic Dependent Surveillance – Broadcast (ADS-B) based on cheap and available MODE-S technology have been discussed in previous work. In addition it has been argued that TIS-C even when operated over the available Digital Link Mode 2 (VDL 2) can fulfil basic requirements of applications for Airborne Separation Assurance System (ASAS), and do much more. The technical concepts and protocols of TIS-C have been elaborated and are available now. This paper presents the results of the validation of the TIS-C concept over VDL2. The validation tool that is used is the Aeronautical Communications Technologies Simulator (ACTS), which has been developed in EUROCONTROL and is one of the most performing VDL2 simulators at the moment. Different TIS-C applications for ASAS are analysed in their use of bandwidth, and several scenarios run with changing traffic loads, equipage rates, and VDL2 parameters. The technical and operational assumptions for parameters of the simulations are discussed. The work proves that the TIS-C concept over VDL 2 is possible for many applications, but also shows its limitations. The validation results emanating from the simulations are presented for the first time in this paper.

Introduction The mission of Air Traffic Management (ATM) is the safe, orderly and expeditious management of air traffic. Over the last few years there has been a constant increase in the amount of air traffic and this is predicted to continue for the next decade [1]. The current ATM system seems to reach its performance limits, and therefore new operational concepts are needed [2]. Some significant research is being undertaken for the integration of the air and the ground systems under the umbrella concept of Cooperative Air Traffic Services [3], [4] which includes applications for Controller-Pilot Data Link Communications (CPDLC), ADS-B and ASAS. CPDLC has started to be implemented, in U.S.A. with the Free Flight Build 1 programme by the Federal Aviation Administration and in Europe with the LINK 2000+ programme18 by EUROCONTROL. The creation of a master plan [5][6] for the implementation of the first package of ground-surveillance and airborne surveillance applications will further promote ADS-B and ASAS applications. Research continues on both sides of the Atlantic19 with a special focus on ASAS applications. The concept of cooperative air traffic services foresees a higher share of tasks between the

18 http://www.eurocontrol.int/link2000/overview.htm19 Europe: MA-AFAS (www.ma-afas.com), AFAS (www.airbus.com) , INTENT (www.nlr.nl/public/hosted-sites/intent/download.htm), NUP2 (www.nup.nu), MFF/MEDUP (www.medff.it, www.adsmedup.it), TALIS (http://talis.eurocontrol.fr), COSPACE (www.eurocontrol.fr/projects/freer). U.S.A: DAG-TM (www.asc.nasa.gov/aatt/dag.html), Safe Flight 21 (www2.faa.gov/safeflight21), Capstone (www.alaska.faa.gov/capstone)


http://www.eurocontrol.int/link2000/overview.htm

http://www.medff.it/




air traffic controller and the flight deck. ASAS applications treat new types of air traffic management procedures where controllers delegate work to the flight deck. Four categories of applications have been defined by the different degrees of the delegation of tasks: situational awareness, spacing, separation and self-separation [7]. Situational awareness applications will help the flight deck to get a better picture of the context, mainly with the help of an airborne air situation picture based on ADS-B. For the second category of applications, spacing, the controller delegates some tasks where the flight deck may catch up with leading aircraft or merge into streams [8]. The fourth category, self-separation, handles the fully autonomous aircraft, and the third category, separation, is something in-between, where the flight deck is responsible for the resolution of conflicts, but is still instructed on the procedure to follow.

TIS-C TIS-C has been developed as an enabler to support cooperative air traffic services. It proposes client-server protocols between the air and the ground similar to those known from the World-Wide Web by extending these with contractual behaviour for mobile safety applications. The advantages of TIS-C in comparison to TIS-B, especially when combined with a mandate for ADS-B based on cheap and available MODE-S technology have been discussed in previous work [9]. The technical concepts and protocols of TIS-C have been elaborated and are available now [10]. With TIS-C the flight deck requests information from ground service providers and then receives services from the providers upon successful contract handling. The initial services are traffic-related and mainly focussed on pilot situational awareness, i.e. information about adjacent aircraft, their flights and eventually conflicts are uplinked. TIS-C Application Data The data content vary depending on the operational application that TIS-C supports, as described in the operational scenarios below. Therefore the size of the data that is sent from the ground to the air must be

defined. This paper does a simple octet (or byte) count. Further optimization could be achieved by the use of compression e.g. the Packed Encoding Rules (PER) applied in the ATN20. However, object IDs are not counted, e.g. Java counts 4 bytes for one object ID. The data types have been defined in previous TIS-C concept definitions [11], [12], which collected it from the AVENUE21 data directory [13], the ASTERIX radar data definitions [14], the ICAO ADS-C SARPs22 [15], and the technical evaluation of data links for TIS-B [16]. Table 1 gives some sizes of formats for different uses. The simple 3D position corresponds to a blip, the 4D position is a time-stamped blip, the smallest track will allow correlation with ADS-B data in the flight deck and adds air speed and heading, the next is a real track correlated with a flight plan containing ground speed and track angle, next is a track containing two 3D positions as simple trajectory-change points, and last is a full track with a projected profile of 20 4D positions. The flight deck may request a flight plan of adjacent aircraft. This contains the flight ID, aircraft information (model, company, ICAO flight type), departure (airport name, ATD) and arrival information (airport name, ETA), requested FL, cruise speed. The route is not added, because TIS-C allows for a request of the projected profile. The total size of a flight plan is 56 octets. The flight deck may also receive medium-term conflict information. In the simple mode only the conflict geometry is sent to the aircraft consisting of: MTCD ID, time of closest point of approach (CPA), flight ID, own start of conflict 3D position, own CPA, own end of conflict 3D position, other flight wake-turbulence category, other start of conflict 3D position, other closest point of approach, and other end of conflict 3D position. The total is 150 octets for one conflict, there may be several conflicts per aircraft.

20 Aeronautical Telecommunications Network 21 AVENUE project 22 Standards And Recommended Practices




Type Position3D Position4D Track1 Track2 Track3 Full Flight ID - - - 8 8 8

Mode S/A/C ID - - 2 2 2 2 Track ID 4 4 4 4 4 4

Lat-Long 3D Position 22 - - - - - Lat-Long 4D Position - 30 30 30 30 30

Air Speed - - 4 4 4 4 Heading - - 2 2 2 2

Vertical Rate - - - 3 3 3 Ground Speed - - - 4 4 4

Track Angle - - - 2 2 2 Data Source Identifier - - - 4 4 4 Projected 3D Profile - - - - 2*22 - Projected 4D Profile - - - - - 20*30

Total 26 34 42 63 165 663

Table 1: Sizes of tracks in octet without compression In the extended MTCD-mode additional trajectory information is sent for n aircraft in proximity at the conflict. The trajectories can be optimised as 3D trajectories with one position per minute look-ahead plus one 4D position at the time of closest point of approach, i.e. 20*22 + 1*30 = 470 (octet) per trajectory.

ACTS Simulator The Aeronautical Communication Technologies Simulator23 (ACTS) in its version 1.5 Beta has been used for the validation, which is running faster than real-time on a simple 750 MHz PC. Figure 1 shows the main page of the simulator. ACTS is a generic telecommunications simulator with a very powerful model for VDL 2. It allows the variable setting of many generic and specific system parameters: The propagation model, which is specific to each frequency band; physical layer parameters like power, feeder loss, antenna gain, noise figure etc.; medium-access-control layer parameters and data-link layer parameters. ACTS can simulate many ground-stations and the effects that occur on the telecommunications channel under these circumstances.

23

http://www.eurocontrol.fr/Newsletter/2003/March/ACTS/ACTSNews.htm#_Toc29716201

Validation. ACTS is continuously refined and improved, and has gone through a rigorous validation campaign. The validation is on different levels: • The application of certification-oriented

tests, typically those of system MOPS24 to individual ground-station models in order to confirm its correct behaviour,

• Theoretical mathematical models are used for validating the main trends in the results,

• Cross-check with independent simulation when available,

• Field trials with defined simplest scenarios,

• Initial operation feedback.

24 Minimal Operational Performances Standards




Figure 1: ACTS V1.5 AVLC Window

The powerful features and its validation status make ACTS one of the most performing VDL 2 simulators at the moment.

Simulation Parameters The settings of the simulator can largely influence the results of the simulation. The following parameters and capabilities were set during the simulations and impact the output: • Only one ground-station, i.e. no handover

and hidden stations effects decrease channel capacity.

• No TMA is simulated, i.e. only flight levels 200 – 400 are used. The effect of an airport is not simulated.

• Random air traffic distribution, i.e. in a scenario with 100 aircraft these are evenly distributed over the range and the flight levels.

• 10 m antenna height, 190 NM range. • No other applications like CPDLC

services were simulated. • The propagation model used 2 way

vertical polarisation, over both dry and wet land.

• Parameters on the physical layer were set to 136.975 MHz channel frequency, 600000 K noise temperature, 12 KHz reception filter depth, 44 dBm ground station and 42 dBm aircraft emission

power, 3 dBm ground antenna gain and 1 dBm aircraft antenna gain.

• The P-factor in the CSMA25 layer was set to 13/256.

• ATN was not taken into consideration. It is assumed that ATN protocols and ATN data compression result in a zero-overhead balance. However, as some of the scenarios lose packages, the ATN in connection-oriented mode would try to recover, and this cost has not been included.

Operational Scenarios And Simulation Results Situational Awareness Applications TIS-B broadcasts traffic information to all aircraft in a specific “logical volume”. It is interesting to which extend TIS-C is able to emulate TIS-B. TIS-C will not broadcast, but can be used to uplink selective, adjacent flights. Five scenarios have been simulated: Five Aircraft Positions at Five Seconds. (Figure 2, legend: 5ac 5sec) Each uplink target receives the simple 3D position (26 octets) of five adjacent aircraft at an interval of 5 seconds. Ten Aircraft Positions at Five Seconds. (Figure 2, legend: 10ac 5sec) Each uplink target receives the simple 3D position (26 octets) of ten adjacent aircraft at an interval of 5 seconds. Three Aircraft 4D-Positions at Three Seconds. (Figure 2, legend: 3ac p4D 3sec) Each uplink target receives the 4D position (34 octets) of three adjacent aircraft at an interval of 3 seconds. Three Aircraft Track 1 at Three Seconds. (Figure 2, legend: 3ac track1 3sec) Each uplink target receives the Track 1 (42 octets) of three adjacent aircraft at an interval of 3 seconds. Three Aircraft Track 2 at Three Seconds. (Figure 2, legend: 3ac track2 3sec) Each uplink target receives the Track 1 (63 octets) of three adjacent aircraft at an interval of 3 seconds.

25 The Medium Control Access sub-layer in VDL 2




The long update rates of 5 seconds intent to simulate an en-route environment for ASAS procedures and intensive situational awareness.

The short update rates of 3 seconds intent to simulate a TMA requirement with varying information about flight vectors.

Real channel load (%)

0102030405060708090

1 2 5 10 20 50 100

Uplink Targets

%

Net throughput (%)

01020304050607080

1 2 5 10 20 50 100

Uplink Targets

%

Success rate (%)

0

20

40

60

80

100

120

1 2 5 10 20 50 100

Uplink Targets

%

5ac 5sec10ac 5sec3ac p4D 3sec3ac track1 3sec3ac track2 3sec

Max turnaround delay (ms)

0

50000

100000

150000

200000

1 2 5 10 20 50 10

Uplink Targets

ms

Figure 2: Real Channel Load, Net Throughput, Success Rate and Maximal Turnaround Delay for TIS-B Emulation

Spacing Applications Spacing applications hook one aircraft behind another in the case of station-keeping; and merge one aircraft, eventually into an existing sequence in the case of traffic-merging. Station-Keeping at 15 seconds. (Figure 3, legend: SK 15sec) Each uplink target receives a full track (63 octets) of one adjacent aircraft at an interval of 15 seconds. Station-Keeping at 5 seconds. (Figure 3, legend: SK 5sec) Each uplink target receives a full track (63 octets) of one adjacent aircraft at an interval of 5 seconds. Station-Keeping at 3 seconds. (Figure 3, legend: SK 3sec) Each uplink target receives

a full track (63 octets) of one adjacent aircraft at an interval of 3 seconds. Traffic-Merging at 15 seconds. (Figure 3, legend: TM 15sec) Each uplink target receives a full track (63 octets) of one adjacent aircraft at an interval of 15 seconds and an additional full track (63 octets) for a second adjacent aircraft at half the update rate, i.e. 30 seconds. Traffic-Merging at 5 seconds. (Figure 3, legend: TM 5sec) Each uplink target receives a full track (63 octets) of one adjacent aircraft at an interval of 5 seconds and an additional full track (63 octets) for a second adjacent aircraft at half the update rate, i.e. 10 seconds.




Traffic-Merging at 3 seconds. (Figure 3, legend: TM 3sec) Each uplink target receives a full track (63 octets) of one adjacent aircraft at an interval of 3 seconds and an additional full track (63 octets) for a second adjacent aircraft at half the update rate, i.e. 6 seconds. The long update rates would support situational awareness, the short update rates co-operative manoeuvres, the very short also for reduced horizontal separation e.g. TMA or approach.

Station-keeping would in general send the leading aircraft track. Traffic-Merging would in general add the trailing aircraft track at half the update rate.


0102030405060708090

1 2 5 10 20 50 100

Uplink Targets

%

Net throughput (%)

01020304050607080

1 2 5 10 20 50 100

Uplink Targets

%

Success rate (%)

0

20

40

60

80

100

120

1 2 5 10 20 50 100

Uplink Targets

%

TM 15secTM 5secTM 3secSK 15secSK 5secSK 3sec

Max. turnaround delay (ms)

0

5000

10000

15000

20000

25000

30000

1 2 5 10 20 50 10

Uplink Targets

ms

Figure 3: Real Channel Load, Net Throughput, Success Rate and Maximal Turnaround Delay for

Station-Keeping and Traffic Merging

Separation Applications Simple MTCD. (Figure 4, legend: MTCD) Medium-term conflict information would support ASAS applications form the separation- and self-separation- categories. It helps the controller and both flight decks to have a common view on the conflict situation. TIS-C has been defined as to uplink the complete conflict geometry, together with the predicted trajectories for aircraft in proximity

to the conflict. The frequency that conflicts occur has been set to one per ground station per minute [17]. Each uplink target receives a MTCD (150 octet), the number of uplink targets correspond to the number of uplinks per minute in the range of the ground station. Extended MTCD. (Figure 4, legend: MTCD and 3 FPs) It could be useful for the flight deck to receive the MTCD as defined above, and in addition receive predicted trajectories of the three most adjacent aircraft at the time




packages per minute, each

e

plink per minute per target due to limitations.

1.

of the closest point of approach. Each uplink target receives a MTCD plus three trajectories (150 + 3*470 = 1560), the number of uplink targets correspond to the number of uplinks per minute. The information is split into two 780 octet. Trajectory Negotiation. (Figure 4, legend: TN) For this applications which is close to the COTRAC26 service [4] it is assumed that an aircraft downlinks its flight plan containing a 4D projected profile once per centre entry, and gets one correction per sector, i.e. one trajectory uplink. No real negotiation is assumed, all uplinked trajectories become clearances and are acknowledged. For convenience the trajectory is chosen to be a Full Track (663 octet), the uplink-rate is one per minute per VDL 2 ground station and thdownlink-rate is 0.1 per minute per aircraft. Air-to-Air CD&R27. (Figure 4, legend: A2A CD&R) Upon a MTCD two aircraft receive the MTCD and three flight plans of adjacent aircraft and exchange each its trajectory twice where the TIS-C ground server acts as a relay, i.e.4 trajectory uplinks and 4 trajectory downlinks. Conflicts occur once per minute in the range of the ground-station. The information is 2*780 + 4x470 = 3440 octet, approximated with 870 downlink and three times 870 u

Discussion All applications can be supported for 20 aircraft in the range of the ground station with near to 100% success rate and very good delays. 50 aircraft can be supported for five aircraft positions at five second, for three aircraft 4D-positions at three seconds, for three aircraft Track 1 at three seconds, for all spacing applications, and also for MTCD, MTCD with three flight plans, and trajectory negotiation. 100 aircraft can be supported by no situational-awareness application, but by station-keeping at 15 seconds, MTCD and trajectory negotiation.

26 Flight Plan Consistency 27 Conflict Detection and Resolution

2. With the exception of situational awareness, the results are more than sufficient for operational use, i.e. it is most unlikely that 100 aircraft would make one conflict with an exchange of trajectories per minute in the volume – here the simulation shows simply the limits of the system without operational significance.

3. The maximum turnaround delay increases with increasing number of uplink targets. That means that information is received with a delay, which is dangerous for time-critical information. Therefore the aircraft architecture should include a tracker, which would use even obsolete information for a better prediction of the current positions of the adjacent aircraft.

Conclusions The results of the simulations show that TIS-C over VDL 2 seems to be feasible. All applications could be used with operational satisfaction. A limitation would be the full situational-awareness applications. The correct mode of operation should therefore be to deliver situational awareness only upon event to a limited number of aircraft in that volume. Situational awareness of adjacent aircraft would be better given by the uplink of predicted trajectories rather than the frequent “broadcast” of air situation pictures. Another feasible use for situational-awareness with TIS-C would be to operate in gap-filler mode, i.e. when only a few aircraft receive adjacent position information.





0

20

40

60

80

100

1 2 5 10 20 50 100

Uplink Targets

%

Net throughput (%)

01020304050607080

1 2 5 10 20 50 100

Uplink Targets

%

Success rate (%)

0

20

40

60

80

100

120

1 2 5 10 20 50 10

Uplink Targets

%

MTCDMTCD and 3 FPsTNA2A CD&R

Max turnaround delay (ms)

0

20000

40000

60000

80000

100000

1 2 5 10 20 50 100

Uplink Targets

ms

Figure 4: Real Channel Load, Net Throughput, Success Rate and Maximal Turnaround Delay for event-type applications

Next steps should be to evaluate a mix of applications, something which is not feasible with this version of the simulator, which would put higher loads on the channel. Furthermore, the foreseen frequency utilisation could be extended to several bands as planned for the real VDL deployment scheme, which would increase available channel capacity. Furthermore, the VDL 2 simulation should be refined to emulate a hypothetical ground infrastructure of VDL 2 stations, which should decrease channel capacity.

This evaluation is a major step for the TIS-C concept. So far the results are very encouraging! The major assumptions that TIS-C can replace TIS-B and do much more even when operated over VDL 2 seem to be correct. Some of the simulated scenarios, especially for conflict detection and –resolution would not be possible with TIS-B. The ASAS community should be glad to find

that they could build their applications only by using Mode-S Extended Squitter and VDL 2, i.e. available and ready-to-deploy technology, which would make the overall concept much cheaper and help for an early operational use of ASAS.

Acknowledgements The author thanks Patrick Delhaise from the EUROCONTROL CNS domain for making the ACTS simulator available for this paper. Many thanks to Yannick Montulet who is the software developer of ACTS. Special thanks to Bertrand Desperier who is the telecommunications expert that specified ACTS.




The Author R. Ehrmanntraut has been working since 1996 at the EUROCONTROL Experimental Centre in Brétigny sur Orge, France. Since autumn 2003 he started a PhD thesis in Air Traffic Management. He has been co-ordinator of the TALIS consortium, an EC project that finished in spring 2004. From 1999 until 2003 he has been CNS Business Area Manager. From 1996 until 1999 he has conducted several projects on air-ground integration. Before 1996 he has been engineer in information technologies in an industrial company. He holds a diploma of telecommunications engineer from RWTH Aachen, Germany in 1991.

References [1] EUROCONTROL, Performance

Review Report 2002, PRU, 2003. [2] ICAO, Air Traffic Management

Operational Concept Panel (ATMCP), 18 to 28 March 2002, first meeting, Montreal, Operational Concept Document.

[3] EUROCONTROL, 2002, Towards Co-operative ATS - The COOPATS Concept, Version 1.0, EUROCONTROL - EATMP – AGC PROGRAMME.

[4] EUROCONTROL, 2001, Operational Requirements for Air/Ground Co-operative Air Traffic Services, AGC-ORD-01.

[5] EUROCONTROL, 2003, CARE/ASAS Action, Activity 5, Proposal for working arrangements to develop Package I of AS/GS applications, Version 2.1, July 10, 2003.

[6] P. v.d. Kraan, J. Steinleitner R. Darby, 2002, The Way Towards Implementation Of ADS-B In Europe ADS Programme EUROCONTROL, in proceedings of the IAATC 2002.

[7] FAA/EUROCONTROL Co-operative R&D, 19 June 2001, Principles of Operation for the Use of Airborne Separation Assurance Systems ASAS, Edition 7.1.

[8] I. Grimaud, E. Hoffman, L. Rognin, K. Zeghal, November 2003, Towards the use of spacing instructions for sequencing arrival flows ICAO Operational datalink Panel (OPLINKP), Annapolis, Maryland, USA.

[9] Ehrmanntraut, R., Dec. 2002, Alternative Enablers for ASAS, EUROCONTROL Experimental Centre

[10] TALIS Consortium, TALIS Final Report, 2004.

[11] Ehrmanntraut, R., 2003, Towards a Concept Definition of the Total Information Sharing Protocol, EEC.

[12] Ehrmanntraut, R., 2003, Towards a Concept Definition of TIS-C, in Proceedings of the 22nd DASC, http://talis.eurocontrol.fr.

[13] AVENUE data dictionary, http://www.eurocontrol.fr/projects/avenue/.

[14] EUROCONTROL, 2000, Standard Document for Surveillance Data Exchange Part 9, Transmission of System Track Data, SUR.ET1.ST05.2000-STD-09-01.

[15] ICAO, Automatic Dependent Surveillance Panel (ADSP), Draft ICAO Manual Of Air Traffic Services (ATS), Data Link Applications, Draft Version 0.3, 29 March 1996.

[16] ADS-B Technical Link Assessment Team (TLAT), March 2001, Technical Link Assessment Report, RTCA Free Flight Select Committee, Safe Flight 21 Steering Committee, Eurocontrol ADS Programme, http://www.eurocontrol.int/ads/ADS_Programme_content.htm.

[17] Ehrmanntraut, R., R. Christien, 2004, Measures of Conflicts in Europe with a Simulation Model, EUROCONTROL Experimental Centre, in Proceedings of the 23rd Digital Avionics Conference DASC, Oct. 24-28 2004, Salt Lake City, USA.








Integrating navigation and communication systems for innovative services

by

Ernst Kesseler1, Ronald Grosmann2, Rudy Ehrmanntraut3

National Aerospace Laboratory, NLR, P.O. Box 90502, 1006 BM Amsterdam, The Netherlandse-mail: [email protected], [email protected]

Eurocontrol Experiment Centre, EEC, P.O. Box15, F-91222 Bretigny sur Orge Bretigny, Francee-mail: [email protected]

AbstractMax 1000 characters, please note the smaller font.In air transport safety is rightly is a prime concern, which led to safe proprietary solutions but a conservative approach toinnovation. Forecasted traffic growth, economic pressure and passenger preferences require more responsiveness. Both newair traffic management concepts, Eurocontrol’s COOPATS and FAA’s DAG-TM are based on extensive information sharingbetween all parties concerned. TALIS has chosen to use COTS based Internet technology to provide the enabling datasharing. This open solution also allows for easy integration with non-traditional actors like airports, passenger services etc.The 2 ½ year realisation time for the TALIS prototype versus the decades typical for the industry and the relatively minorinvestment, of which already half is spend on applications, testify to the success of the approach.

IntroductionAir transport is a safety conscious industry. The downside of the success in its safety records is its conservativeapproach to innovation. Economic pressure will force it to be become more competitive and hence moreresponsive to other user needs. This paper describes an approach to use the Internet based service paradigm inwhich services are provided to customers. These services are based on, or use, other services. In this waycommunication services and navigation services can be integrated to provide innovative services to satisfy userneeds in a timely fashion.

The first section will provide the background or a high level view of the current practise in air transport. Thenext section argues why innovation is needed. Subsequently the two major user driven new Air TrafficManagement (ATM) concepts will be described, Eurocontrols’ s COOPATS and FAA’ s DAG-TM. Subsequentlythe Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems (TALIS)services approach is explained, illustrated by an en-route example and an airport one. The TALIS solution iselaborated including its underlying Internet technology. Finally a section discusses some safety issues before theconclusion summarises this paper.

1. BackgroundAir transport technology is heavily influenced by safety concerns. Its safety record justifies this approach.Compared with the general market, the volume, both for aircraft avionics and for ground systems is relativeminor. This combination results in a slow evolution of the technology deployed and a very limited use of COTS(Commercial of the Shelf) products. Nevertheless the evolution tends to be technology driven in stead of userdriven due to the complex aeronautical issues involved. Typical implementation times for new technologies aremeasured in decades, as illustrated by certified GPS approaches in the navigation domain (versus massive GPSuse in the general domain, cars and the maritime domain), and the still incumbent ATN (AeronauticalTelecommunication Network) versus massive use of mobile communication in the general domain. TheCOOPATS (Co-operative ATS (Air Traffic Services)) document [2] provides a vivid example of these longimplementation times by contemplating the use of data link technologies, which it mentions started in the early1970’ s.

2. Need for changeAir transport is expected to grow in the long term, despite the temporal downturns like the one after theSeptember 11, 2001 attacks, see [1]. It is a widely held view [2], [3], that this expected traffic volume can onlybe accommodated by a paradigm shift away form the current concepts and ways of working. Rising delaysreinforce the business need for more responsiveness of the air transport system to user needs instead of thecurrent practise of innovation based on technological opportunities. Cost concerns imply that an effort should bemade to harness the power of COTS to allow the resources to concentrate on air transport specific problems..

. 1 Drs, Head Embedded Systems Department NLR, 2 Senior research scientist NLR, 3 Head CNS studies EEC

Utilisateur

Zone de texte

ANNEX C - 7

Utilisateur

Zone de texte

Page 123

Utilisateur

Texte inséré

ANNEX C - SCIENTIFIC PAPERS AND PUBLICATIONS

Apart form these high level incentives for change, other factors reinforce this need for more responsiveness.Based on the finding that weather related accidents have the highest fatality rate, [4] studied the use of datalinked weather update for general aviation pilots Conclusions include that on-board intelligence is needed totransform weather information to a usable service supporting the pilot. Also the important but not wellunderstood issue of the Human Machine Interface (HMI) makes updates of the initial service and its supportingsoftware likely, reinforcing the need for responsive user-driven services.

3. User driven conceptsCurrently a number of air-ground integration operational concepts are being conceived. These range from shortterm improvements like ADS-C and CPDLC (Controller/Pilot Data Link Communications), through AirborneSeparation Assurance System (ASAS) to the long term vision of Co-operative ATS (COOPATS) of Eurocontrolfor the European Civil Aviation Conference (ECAC) area or Distributed Air-Ground Traffic Management(DAG-TM) of NASA for the USA. These concepts are based on integrating the air-side and the ground-sidecomprising amongst others integration of the navigation capabilities with the communication systems. Thesecommunication systems are an enabling technology, just now being deployed in the air transport domain. Theneed for flexibility and more responsiveness of the air transport information technology systems will beillustrated by the following cursory description of COOPATS and DAG-TM.

3.1 COOPATS conceptThe COOPATS concept is defined in [2] as “a concept of Air Traffic Management (ATM) that enhances theproductivity and safety of Air Traffic Services by optimising the involvement of controllers, aircrew and airlineoperators through integrated Data Communications and improved forms of surveillance and automation”. Thehigh level objective of Co-operative ATS is to support controllers, pilots and all potential ATM users, in allphases of flight, up to enabling autonomous flight operations in Free Flight Airspace by progressivelyimplementing fully seamless communications, data exchange, situational awareness and automation capabilities.The Co-operative ATS concept is based on the human centred automation paradigm, as a consequence of theresponsibilities defined by ICAO in [5]. It identifies the following concept goals:� Fully seamless communication between controllers and pilots,� Fully seamless data exchange capabilities between all involved ground systems and aircraft,� Optimal provision of flight information data in real time, for use by aircrew and any other involved parties,

such as meteorological centres.The key principle is improved situational awareness, enabled by data link technologies. ATM will becomeincreasingly dependent upon the efficiency and quality of supporting processes and services such as System-wide Information Management (SWIM), Aeronautical Information Services (AIS) and aviation meteorologicalservices (MET). For planning purposes, Co-operative ATS is divided into two concept levels, level 1 forevolution up till 2008 / 2010 and level 2 between 2007 and 2015. Figure 1 provides an overview of the data linkservices per flight phase. The bottom three services, in Italics, relate to level 2 services. Note that the Co-operative ATS concepts naturally uses the word services and the notion that advanced services build upon moreprimitive services.

FlightEvents

ATMPhase


Data linkServices

PlannedFlightData

DayPrior

Day ofOperation

RequestStart-Up Take-Off Cruise Level

Parameterfrom

DestinationLanding

StrategicPlanning


TacticalPlanning

GroundMovement Climb-Out En-Route Arrival Post-Arrival

IFPSCFMU

IFPSCFMU

ATM FMPsAMCs

IFPSCFMUFMPs

TWRAPPACCIFPSFMPs

APPACC(s)IFPSFMPs

ACC(s)IFPSFMPs

ACC(s)APP TWR

ACM� � � � �

ACL� � � � �

CAP� � �

DCL�

DSC� � �

PPD� � � �

FLIPCY� � � �

DYNAV� � �

D-FIS� � � � �

COTRAC� � � �

SAP� � �

ATSAW� � � � �

COSEP� � � �

AUTOPS�

Profile

Figure 1 Envisaged Co-operative ATS services

Utilisateur

Zone de texte

Page 124

Co-operative ATS assumes the ATM system to evolve in a gradual and interactive way towards its final form.Consequently Co-operative ATS implies a mechanism for continuous change of the software and applicationswhich implement these services.

3.2 DAG-TM conceptThe DAG-TM concept is defined in [6] as “a concept in which flight deck crews, air traffic service providers andaeronautical operational control personnel use distributed decision making to enable user preferences andincrease system capacity, while meeting air traffic management constraints. DAG-TM will be accomplished witha human centred operational paradigm enabled by procedural and technological innovations. These innovationsinclude automation aids, information sharing, communication, navigation and surveillance (CNS) air trafficmanagement technologies”. The fundamental objective of DAG-TM is to minimise static restrictions i.e. theusers can plan and operate according to theirs preferences (as the rule) with ATM deviations only wheninevitable (by exception). The DAG-TM concept will be implemented using a spiral development approach, asknown from the information technology [7]. The DAG-TM concept, as described in [3], is denoted as the gate-to-gate concept. Taking the user needs and individual return-of-investment decisions into account, it assumes amixed fleet equipage for additional DAG-TM capabilities. The centrepiece of the DAG-TM concepts isdistributed decision making between the three parties involved� The flight deck, operated by the flight crew,� The aeronautical operational control centre, operated by the flight planners and flight dispatchers,� The air traffic service provider, including air traffic controllers and traffic flow managers.This is depicted in figure 2.

Flight crewPilot

Distribution of� Information� Responsibility of

Ã Flow rate conformanceÃ Trajectory informationÃ Separation assurance

Aeronautical Operational Control (AOC)Air Traffic Server Provider (ATSP)

Flight planners / dispatchersAir Traffic controller, Traffic low managers

Figure 2 DAG-TM concept triad

The flight deck plus the aeronautical operational control centre together constitute the DAG-TM users. TheDAG-TM concept is based on extensive information sharing and subsequent distributed decision-makingresponsibility by all three parties. To exchange information the 4–D trajectory is considered fundamental. Table1 provides the fundamental gate-to-gate concept plus the 14 derived DAG-TM concepts elements and theirprovided services.

DAG-TM concept element provided services1. Gate-to-gate Information access / exchange for enhanced decision

support2. Pre-flight planning NAS constraint considerations for schedule / flight

optimisation3. Surface departure Intelligent routing for efficient pushback times and taxi4. Terminal departure Free manoeuvring for user-preferred departures5. Terminal departure Trajectory negotiation user-preferred departures6. En route (departure, cruise, arrival) Free manoeuvring for

� user-preferred Separation assurance� user-preferred local traffic flow management

conformance

Utilisateur

Zone de texte

Page 125

7. En route (departure, cruise, arrival) Trajectory negotiation� user-preferred Separation assurance� user-preferred local traffic flow management

conformance8. En route (departure, cruise, arrival) Collaboration for mitigating local traffic flow

management restrictions due to weather, Special UseAirspace and complexity

9. En route / Terminal arrival Collaboration for user-preferred arrival metering10. Terminal arrival Free manoeuvring for weather avoidance11. Terminal arrival Trajectory negotiation for weather avoidance12. Terminal arrival Self spacing for merging and in-trail separation13. Terminal arrival Trajectory exchange for merging and in-trail

separation14. Terminal arrival Airborne conflict detection and resolution for closely

spaced approaches15. Surface arrival Intelligent routing for efficient active-runway crossing

and taxi

Table 1 DAG-TM concept elements and provided services

The DAG-TM concept is based on decision support tools. The determination of information exchange is one ofthe foremost research issues to determine its feasibility. The information sharing and the improved situationalawareness aim to increase both safety and capacity. For the arrival phase, the Estimated Time of Arrival (ETA)will be replaced by a Desired Time of Arrival (DTA). This will allow the uses to either accept some delays usingtheir preferred route or avoid congested airspace and arrive earlier (e.g. using another runway with increasedtaxiing time). This mimics car drivers, which might take the shortest but congested route or take a longer notcongested route.

The DA-TM concept states information sharing and distributed decision making as fundamental enabler. Asresearch continues current ideas evolve and new ideas are expected to arise necessitating new procedures andalgorithms. An software characteristic is for products to evolve over time, so the DAG-TM concept with itsheavy reliance on software implicitly needs a mechanism to cost-effectively and swiftly disseminate newsoftware or software updates to the existing fleet i.e. it needs a flexible communication infrastructure.

4. TALIS approachThe aforementioned need for change results in user driven concepts enabled by a way to share information.Based on this the Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems(TALIS) project is being executed. Its objective is to provide an architecture that supports a layered servicesconcept. To achieve this the architecture builds upon (or uses in Internet parlance) navigation andcommunication services to provide more advanced services like ADS-B (Automatic Dependant Surveillance)and Traffic Information Services (TIS). By using general hardware and software components i.e. COTStechnology and Internet based solutions, the time-to-market of the services can be reduced drastically. Uplinkingnew data, or even new software, facilitates a swift deployment of new or updated services, also for aircraft withlegacy avionics. This is a big advantage when new requirements arise, as is currently the case for security. Figure3 depicts this layered services concept. Viewing the Flight Management System (FMS) in an analogue way, theFMS provides the capability (service) to navigate from any designated point to any point, based on groundbeacons plus the aircraft’ s Inertial Navigation System (INS) plus local processing capabilities or intelligence, thesupporting or lower level services.

TALIS aims to be an enabler for the Co-operative ATS and DAG-TM concepts as well as for many otherservices, including non-ATM services like aeronautical operational control and passenger services. The next twoservices describe two sample services, both from the ATM domain, the first being realised in the TALIS projectand the second being considered for implementation. Both services are focused on pilot users.

Utilisateur

Zone de texte

Page 126

Figure 3 TALIS layered services concept

4.1 En-route example servicesSome en-route services with their TALIS support are illustrated using the Airborne Separation AssuranceSystem (ASAS) concept. Depending on the navigation and communication services available, a different level ofASAS service can be supplied. When no radar is available, ASAS will be Automatic Dependent SurveillanceBroadcast (ADS-B) based and provides protection for equipped aircraft only. Where radar and ATN areavailable, the aircraft in the immediate surrounding of the own ship can be uplinked providing protection to allaircraft. In the approach phase, when radar, ATN and Traffic Information Service-Broadcast(TIS-B) are available, these services will allow station keeping. Figure 3 illustrates the context dependantservices. TALIS is currently working on the Traffic Information Service part.

No Radar

RadarATNno TIS-B

RadarATN TIS-B

ADS-B

TIS/ATN

TIS-BNo TIS/ATN

Figure 4 TALIS en-route context dependant services

4.2 Airport example servicesOn an airport the pilot has different information needs, depending on the flight phase. Figure 5 provides somesample services. The co-ordinated pushback service will allow the pilot to improve the reliability of on-timepushback taking information of all relevant parties into account. The pilot needs amalgamated information fromfuelling services, baggage-handling services, catering services, security services, gate personnel, AOC forinformation on connecting passengers etc. This co-ordinated pushback service optimises usage of the taxi-waylinking the various gates and prevents two aircraft from blocking each other or ending up in the wrong take-off

Utilisateur

Zone de texte

Page 127

order. Subsequently taxi-services [8] guide the aircraft to the correct runway, optimised for the other airfieldtraffic. Finally runway incursion services improve the safety of the take-off. During landing the taxi services canguide the aircraft and the ground handling vehicles to the (re)allocated gates. These services illustrate the powerof integrating navigation and communication capabilities based on updateable software.

TALIS airport services for� Runway� Taxiing� Gate management

Fig 5 Example TALIS airport services

5. TALIS solutionSummarising, some important requirements for the TALIS solution will be to� Support a variety of applications, the mix of which will evolve over time, for a diverse set of users� Support a mix of hardware and software platforms, both on-board the aircraft and for the various ground

systems involved� Be responsive to evolving user requirements� Be able to accommodate the safety and security concerns of some of the envisaged applications.To accomplish this, TALIS has chosen to harness the power of COTS tools by choosing Javatm technology.Javatm technology is COTS technology. As Javatm is being used in many Internet applications a lot of work isbeing done on Javatm technology, amounting to investments which are much larger then possible for dedicatedair transport solutions. The general usage of Javatm also implies that TALIS can be used for other applicationsthen air traffic management alone, like aeronautical operational control, passenger information and even forsecurity services. This will improve the return-on-investments, or increase the passenger service and hencecompetitiveness of the airline. For a solution which interfaces with so many independent parties as TALIS, it isimportant that the solution is vendor independent i.e. open. Open solutions provide a level playing field for allcompetitors, prevent monopolies, foster innovation by competition and tend to generate standard solutions thatare easier to integrate in a business organisation. Javatm complies with this requirement.

Note that independently of this work, in the automotive transport industry a similar approach of Internet basedservice provision is being aimed at [9]. Interestingly both security services and a number of charged passengerservices are being envisaged, like tourist information, news, weather /news / stock and location basedinformation. A car is even referred to as a Javatm browser on wheels. In another independent work stream formilitary pilots [10] investigates the concept of on-board intelligence combined with a network connection andsupporting ground services. It seems the time is set for this type of network centric solutions.

Utilisateur

Zone de texte

Page 128

Figure 6, TALIS concept

Figure 6 depicts the general philosophy of the TALIS solution. A standard infrastructure will be provided, whichwill connect all relevant actors, or people performing functions. On top of this infrastructure applications (orservices) will be provided, which support the person(s) involved. By using the TALIS infrastructure theseapplications will easier to develop than in the current business practise. An advantage of the shared infrastructureis that applications can interact, allowing for more advanced services to be offered building upon existingservices. The TALIS architecture consists of TALIS applications complemented by TALIS services. Theapplication provides the services to the user e.g. a weather update to the pilot. The corresponding TALIS servicewill be a meteorological service, probably ground based, which can provide the requested weather. As iscommon in Internet, many applications will also provide services to other applications. This is depicted in theTALIS application and TALIS services boxes in figure 7.The mapping of the TALIS architecture to the COTSbased implementation is shown in figure 7.

TALIS applications TALIS services TALIS applications TALIS services

TALIS service conceptTALIS service layer

JiniJavatm Virtual Machine (JVM)

(Real-Time) Operating SystemJavatm support

.g. standard web browser, embedded Linux,proprietary operating system

Aeronautical TelecommunicationNetwork

Aeronautical TelecommunicationNetwork

Figure 7 TALIS architecture and implementation

The TALIS service concept layer hides all network and operating system implementation specific details fromthe TALIS application developer. By using Javatm TALIS will be able to dynamically detect new services, andservers. Javatm has been designed to run unmodified on any computer platform where a Javatm Virtual Machine(JVM) is available. The Javatm compiler translates the TALIS application in Javatm to intermediate Javatm byte

Implementation

Utilisateur

Zone de texte

Page 129

codes. The Javatm Virtual Machine then executes these Javatm byte codes. Depending on the type of applciation,the amount of functions required from the JVM may vary and consequently several JVM are available, from thefull J2EE (Javatm 2 platform Enterprise Edition) to the smallest J2ME (Javatm 2 Platform Micro Edition). Toillustrate the power of COTS, the standard Javatm 2 platform software in March 2002 was already downloadedover 1 million times. Also due to the recent security concerns, work is being done to include some securityfeatures into Javatm. This is possible for COTS products that are in common use, for air transport specificproducts the price of such additions would be prohibitive and the realisation time would be far longer.

Jini network technology is an open architecture that enables developers to create network-centric services. Jinitechnology is designed to build adaptive networks that are scalable and can evolve. These are the characteristicsneeded by TALIS. As can be seen from figure7, TALIS will need to add a specific interface for communicationover the Aeronautical Telecommunication Network. Due to the substantial deployment of Java, it is expectedthat it will be easy to add wireless portable and wearable devices when they will become available in the future,as all of this will be COTS products. This scenario will allow the air transport actors to concentrate on providingadded value by exploiting new technologies, as they become available.

The use of the chosen COTS technologies pays off for TALIS. Project management and a study of airbornecertification issues account for one third of the TALIS effort. Of the remaining effort, half is spend on the twodemonstration applications, a meteo update service and Traffic Information Services. The other half is spend ontechnical issues related to the federated architecture, the common infrastructure.

7. Certification issuesAir transport could benefit from a number of services, which can be provided by the TALIS infrastructure. Someof these services are not critical, like passenger information services, but many of these services incur a safetyconcern in case the TALIS infrastructure would fail. Consequently there is a requirement to certify TALISservices and the supporting TALIS infrastructure. Due to historic reasons, for the airborne part of TALIS DO-178B is available, but for the ground part no standard yet mandated. In the US work is being done on a groundequivalent of DO-178B [11], DO-278 / ED-109 [12]. For the ECAC area Eurocontrol is busy with a Europeanstandard. This European standard is based on combining elements of DO-178B, IEC 61508 [13] and addressesboth safety concerns as well as quality issues. For the latter the Capability Maturity Model (CMM) [14] is used.All of these standards classify applications depending on the hazardous consequences software failure can incur.The TALIS approach will be to study the safety and certification issues starting with applications with low safetyclassification levels. When the need arises, the certification activities could be extended to higher levels, iffeasible. This in accordance with the finding that considerable effort can be saved by applying the costly safetycritical development process only to those parts which really need them and partition the application accordingto its safety critical functions [15]. Like many other languages, certification concerns will lead to the definitionof a safe subset of the language complemented by programming standards limiting the use of some otherunavoidable constructs. Work on Javatm and DO-178B is being discussed in the Open Group [16]

It is expected that some TALIS application will require some form of real time behaviour. Those applicationswill need a real time operating system kernel to support those services. Again the COTS paradigm can beexploited. A Real Time Javatm (RTJ) working group exists [17], which is defining a hard real-time version ofJava. Due to the communication delays incurred by the ATN, it is expected that for TALIS currently soft real-time will suffice. The real time Javatm working group also addresses related DO-178B certification issues.

8. ConclusionsBy applying general Commercial of the Shelf (COTS) concepts, taken from amongst others the Internettechnologies, and exploiting some enabling navigation and communication technologies the TALIS projectfocuses on a way to support a user driven approach to air transport. TALIS provides an architecture, based ongeneral Internet / COTS concepts but enhanced to take the air transport specific requirements into account, themost important of which are safety and communication related. This will significantly accelerate the introductionand deployment of new services, improve the return-on-investment and reduce aircraft maintenance costs andreduce aircraft out-of-service time. This will foster innovation in combined navigation and communicationservices thus contributing to a more responsive air transport system.

9. Acronyms and abbreviations

ACC Area Control CentreACL ATC Clearance and Information (Service)ACM ATC Communications Management (Service)

Utilisateur

Zone de texte

Page 130

ADS-B Automatic Dependant Surveillance – BroadcastAIS Aeronautical Information ServicesAMC Airspace Management CellAOC Aeronautical Operational ControlAPP Approach Control (Service) (Unit)ATSAW Air Traffic Situation(al) AwarenessATSP Air Traffic Server ProviderASAS Airborne Separation Assurance SystemATM Air Traffic ManagementATN Aeronautical Telecommunication NetworkATS Air Traffic ServicesAUTOPS Autonomous Flight OperationsCFMU Central Flow Management UnitCMM Capability Maturity ModelCNS communication, navigation and surveillanceCOOPATS Co-operative ATS (Air Traffic Services)COSEP Co-operative Separation AssuranceCOTRAC Common Trajectory Co-ordination (Service)COTS Commercial of the ShelfCPDLC Controller/Pilot Data Link CommunicationsDAG-TM Distributed Air-Ground Traffic ManagementDCL Departure Clearance (Service)DSC Downstream Clearances (Service)DFIS Data Link Flight Information (Services)DTA Desired Time of ArrivalDYNAV Dynamic Route Availability (Service)ECAC European Civil Aviation ConferenceFLIPCY Flight Plan Consistency (Service)FMP Flight Management PositionFMS Flight Management SystemHMI Human Machine InterfaceIFPS Initial Flight Plan Processing SystemINS Inertial Navigation SystemJ2EE Javatm 2 platform Enterprise EditionJ2ME Javatm 2 Platform Micro EditionJVM Javatm Virtual MachinePPD Pilot Preferences Downlink (Service)RTJ Real Time Javatm

SAP System Access Parameters (Service)SWIM System-wide Information ManagementTALIS Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent SystemsTIS Traffic Information ServicesTWR Tower Control Service (Unit)

References1. Eurocontrol, Performance Review Commission, http://www.eurocontrol.int/prc/reports/prr4/reference.html2. Eurocontrol, Towards Co-operative ATS, The COOPATS Concept // Eurocontrol

DIS/ATD/AGC/MOD/DEL 01, Version 0.5, 01/11/20003. S.M. Green, K.D. Bilimoria, M.G. Ballin, Distributed air/ground traffic management for en route flight

operations // Air Traffic Control Quarterly, vol 9, number 4, 2001, P. 259-2854. D. E. Yuchnovicz, et al, Use of data-linked weather information display and effects on pilot navigation

decision making in a piloted simulation study // NASA / CR-2001-211047, august 20015. International Civil Aviation Organization, Human Factors Digest No. 10: Human Factors, Management and

Organization.// ICAO circular, n.249, 19946. K.D. Bilimoria, Distributed air/ground traffic management // Air Traffic Control Quarterly, vol 9, number 4,

2001, P.255-2587. B. Boehm, A spiral model for software development and enhancement // IEEE, Computer, Volume21,

number 5, P. 61-72, 19888. P. van Leeuwen, Scheduling aircraft using constraint satisfaction // 11th International workshop for

functional and logic programming, June 2002, Grado, Italy http://www.dimi.uniud.it/~wflp2002/

Utilisateur

Zone de texte

Page 131

9. S. Ashley, Driving the info highway // Scientific American, October 2001, P. 44-5010. H.H. Hesselink, et al., On-board decision support through the integration of advanced information

processing and human factors techniques // NLR-TP-2001-611, NATO SCI lecture series on TacticalDecision Aids and Situational awareness, Amsterdam November 2001, Sofia November 2001, MadridNovember 2001, Patuxent River (MD) November 2001 and NVvL November 2001

11. DO-178B / ED12B, Software Considerations in Airborne Systems and Equipment Certification // RTCA /EUROCAE (December 1992)

12. DO-278 / ED-109 Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management(CNS/ATM) Systems Software Integrity Assurance // RTCA / EUROCAE 2002

13. IEC 61508 Functional safety: safety related systems, 7 parts // , (June 1995)14. M. C. Paulk, C. V. Weber, S. M. Garcia, M. B. Chrissis, M. W. Bush, "Key Practices of the Capability

Maturity Model, Version 1.1" // Software Engineering Institute, CMU/SEI-93-TR-25, DTIC NumberADA263432, February 1993 or http://www.sei.cmu.edu/cmm/obtain.cmm.html

15. E. Kesseler, Applying theory to practice: Airworthy software measured and analysed // 16th IFIP WorldComputer Congress (WCC2000), Beijing, China August 21-25, 2000

16. John Joseph Chilenski, Software development under DO-178B // The open Group, Anaheim, January 28,2002

17. E. D. Jensen, Requirements For Real-time Extensions For the Java™ Platform // The open Group, Anaheim,January 28, 2002

Utilisateur

Zone de texte

Page 132

Transforming air transport to a concurrententerprise

Technical, safety and security perspectives

Ernst Kesseler

NLR, A. Fokkerweg 2, 1059 CM Amsterdam, The Netherlands, [email protected]

Abstract

The various parts of the air transport system have evolved independently, with the continuation of the good safetyrecord as overriding concern. Economic realities create an incentive to move from the proprietary stand-alonesolutions to an integrated concurrent enterprise solution.

The TALIS case study demonstrates the technical feasibility of the concurrent enterprise for air transport within therequired safety levels. The UML based software development process might not be responsive enough for therequired time-to-market for every service. Validated metrics, for use early in the software development, are welcome.A goal-based approach could provide the needed harmonisation of the various safety standards.

Keywords

Service-based architecture, federated systems, concurrent enterprise, Java, safety

1 Introduction

Historically air transport has taken a safety-first approach. To counteract the inherent dangers offlying, the industry is technology focussed with the continuation of its good safety record as theoverriding requirement for all its activities. This has led to an industry where innovation tends tobe technology driven. Independent assessment of the safety leads to certification of theequipment, operators, services, etc. used. The result has been specialised, safe, proprietarysolutions for the various activities involved. However these solutions experience a very low rateof innovation and are expensive, compared with the general market. Lack of competition helps tomaintain the status quo.

Currently economic pressure, passenger preferences, heightened security concerns and expectedlong-term traffic growth necessitate a paradigm shift from a technology driven approach to acustomer or service-oriented approach. This paper describes an industrial case study to determinewhether an Internet enabled service-based architecture could facilitate the transformation to acustomer-oriented organisation. As the various services and systems are independently ownedand operated, the integration aims for a federated network of co-operating entities. The lessonslearned up to now are provided.

As safety remains a prime concern, safety issues will be discussed briefly to assess their impacton the architecture. After the tragic September 11, 2001 events, security has become moreimportant. Some preliminary software related results are presented.

2 Existing Theories and Work

Currently the design of a new aircraft, like the Airbus A380, the Boeing Sonic Cruiser (recentlytransformed to the 7E7) or the Lockheed Martin Joint Strike Fighter, is a major effort whichtakes well over a decade from initial idea to a flying and certified product. As aircraft will remainin operation for decades and retrofitting equipment is very cumbersome and costly, legacy

Utilisateur

Zone de texte

ANNEX C - 8

Utilisateur

Zone de texte

Page 133

systems will be inevitable. Even on the ground, Air Traffic Management (ATM) systems take asimilar time to produce and get operational. In Europe every country has its own, custom madesystem and some countries even operate several centres, each with their own dissimilar system.Consequently an integrated air transport solution has to be platform independent as well as takelegacy (sub)systems into account.

This situation bears similarities with the US military, which have to integrate many independentsystems into a working combination. The US military have initiated the [Joint vision 2020] totransform their existing capabilities into a network centred enterprise. Combining the platformindependence of Java with the networking capabilities of Open wings should, a/o, enable theJoint Vision 2020.

The software certification standard for aircraft, [DO-178B, 1992] is considered by many as oneof the toughest in the software industry. Various parties are currently contemplating thedefinition of a real-time DO-178B certifiable Java subset plus accompanying virtual machine.The European Space Agency expects it to materialise in the foreseeable future [Claes, 2002],which would satisfy the safety concerns from a technical point of view.

The various aircraft systems are highly integrated to optimise the aircraft flight within theapplicable safety limits. However as aircraft are not connected to air traffic management systems,other then via an old-fashioned voice link between pilot and air traffic controller, thisoptimisation can not take other traffic or other ground system information into account.

The justification of air traffic management is to prevent collisions between aircraft. Aircraftoperate in conditions (e.g. flying through clouds) where the pilots can not do this themselves.Traditionally air traffic management is a national responsibility, where use of civil airspace andairports is optimised to achieve maximum traffic flow while respecting military requirements.The resulting country specific airspace design combined with full national airspace autonomy,led to systems that are optimised per country.

APPACC

APPACC(s) ACC(s) ACC(s)

APP

IFPS IFPS IFPS

FlightEvents

ATMPhase


Data linkServices

StrategicPlanning


TacticalPlanning

GroundMovement

Climb-Out En-Route Arrival Post-Arrival

CFMU CFMU

ATM FMPs

AMCs

CFMU

FMPsTWR

IFPS IFPS IFPSFMPs FMPs FMPs

TWR

ACMACLCAPDCLDSCPPDFLIPCYDYNAVD-FISCOTRACSAPATSAWCOSEPAUTOPS

Profile

PlannedFlightData

DayPrior

Day ofOperation

RequestStart-Up

Take-Off Cruise LevelParameter

fromDestination

Landing

QQ QQ QQ QQ QQ

QQ QQ QQ QQ QQ

QQ QQ QQ

QQ

QQ QQ QQ

QQ QQ QQ QQ

QQ QQ QQ QQ

QQ QQ QQ

QQ QQ QQ QQ QQ

QQ QQ QQ QQ

QQ QQ QQ

QQ QQ QQ QQ QQ

QQ QQ QQ QQ

QQ

EUROCONTROL

AMSTERDAM - LISBON12345-7 1015 1215 KL1693123456- 2035 2235 KL1697 10:15 12:15

Figure 1 EUROCONTROL collaborative decision making concept and tentative services

Air transport improvement at European level can only be obtained by integrating the existingsubsystems in a federated European system. Both EUROCONTROL (the European organisationfor air navigation) and the USA Federal Aviation Authority are developing CollaborativeDecision Making (CDM) concepts in which all relevant stakeholders like pilots, air traffic

Utilisateur

Zone de texte

Page 134

controllers, airports and airlines will share information to arrive at user preferred flights. Theseconcepts define the high-level user requirements. Figure 1 depicts EUROCONTROL’scollaborative decision making concept. This concept’s high-level objective is to support airtraffic controllers, pilots, and all potential ATM users, in all phases of flight by progressivelyimplementing fully seamless communications, data exchange, situational awareness andautomation capabilities. Many supporting services are being defined, which are expected toevolve significantly until their planned initial deployment in the 2008-2015 timeframe. Thatthese services are referred to as data link services illustrates the industry’s technology drivenapproach. After nearly two decades of work on the single current data link service, it is in onlylimited pre-operational use, illustrating the need for a dramatically improved time-to-market.

Several Civil Aviation Authorities currently provide much non-critical and consequently non -certifiable information on the Internet like Notice to Airman (NOTAM), weather reports (TAF,METAR) etc. [Finnish AIS]. Currently this information is not available anymore once the pilotenters the aircraft, which illustrates some limitations of current proprietary solutions as well asadvantages of transforming to concurrent enterprise solutions. Similarly EUROCONTROL istransforming a lot of airport information to Extensible Mark-up Language (XML), to provideidentical and timely information to all actors involved.

Airlines operate in a competitive environment, which might force them into agile softwaredevelopment [Abrahamsson, 2002] for non-safety related services, the extreme opposite from thetraditional waterfall model and time-to-market currently used. The current state-of-the-artsuggests that the proposed European air transport architecture should be federated, to protectcommercial interests, allow the simultaneous support of services with mixed safety and securityclassifications, be platform independent, deploy Commercial off-the-Shelf (COTS) to benefitform existing solutions, improve time-to-market and improve affordability and be open to allowfor new requirements and solutions.

3 Research approach

To assess the technical feasibility of combining existing (sub)systems into a network-centredservice-based architecture the innovative Total Information Sharing for Pilot SituationalAwareness Enhanced by Intelligent Systems (TALIS) project has been initiated.

Figure 2 Conceptual view of the TALIS architecture

Utilisateur

Zone de texte

Page 135

The TALIS architecture provides an infrastructure to enable the required collaborative decisionmaking concepts. Within the project the architecture will be developed and a prototypeimplemented with two demonstration services. Figure 2 depicts the TALIS architecture.

To describe how the air transport concurrent enterprise concept would work, the sample TALISservice depicted in figure 3 is described. The sample service focuses on a pilot user. On anairport the pilot’s information needs differ depending on the flight phase. A co-ordinatedpushback service will allow the pilot to improve the reliability of on-time pushback. For this thepilot needs amalgamated information from fuelling services, baggage-handling services, cateringservices, security services, gate personnel, Airline Operations Centre (AOC) for information onconnecting passengers etc. A co-ordinated pushback service optimises usage of the taxiwaylinking the various gates and prevents aircraft from blocking each other. Subsequently SurfaceMovement Guidance and Control System (SMGCS) based taxi-services guide the aircraft to thecorrect runway, optimised for other airfield traffic and taking possibly adverse weather or airfieldmaintenance restrictions into account. Finally runway incursion alerting services, usingsurveillance services, improve the safety during take-off. For arriving aircraft taxi-services guidethe aircraft and the ground handling vehicles to the (re) allocated gates. Such TALIS poweredservices illustrate the power of integrating existing services i.e. deploy the concurrent enterprise.

AOCservice

Fuelservice

Baggagehandling

Securityservice

Gatemanagement

Airport services for• Runway incursion alert• Taxi guidance• Gate management• Co-ordinated push back

Surveillanceservice

SMCGSservice

Airfieldmanagement

Meteoservice

Runwayincursion

Figure 3 Sample TALIS airport service

Java’s platform independence supports uplinking new data, or even new software to the aircraft.This facilitates a swift deployment of updated or even new services, also for aircraft with legacyavionics. This big advantage is already commonplace for concurrent enterprises in otherdomains. Consequently TALIS will be Java based.

Summarising the major TALIS requirements include:

• Build upon the many disparate legacy systems in use and take into account the variousindependent (sub)system owners (federated architecture)

• Be flexible by configuring the architecture to the needs of the local user, e.g., pilot, airtraffic controller, airline, gate manager, fuel service, luggage handling, meteorologicaloffices, etc. This is referred to as variability in software product lines (variability)

• Allow interconnection with the various, non-harmonised existing systems of the widevariety of actors (cross platform connectivity)

Utilisateur

Zone de texte

Page 136

• Provide plug-and-play at system level to allow users and their services to enter and leavethe network at their own discretion without interrupting the other provided services (self-forming self-healing network)

• Provide simultaneous support of both services with a safety impact as well as non-certifiable services (multiple-level safety support)

• Support simultaneously many communication technologies, which will evolve withcommercial speeds. The architecture should survive the specific supporting technology,e.g., Aeronautical Telecommunication Network (ATN), UMTS, satellite communication,wireless LAN, bluetooth, etc. (technology independence)

• Foster innovation by providing an open system to support new, as yet unknown, servicesto improve the responsiveness of the air transport system (open system)

• Be affordable by deploying COTS solutions wherever possible. Open systems alsofacilitate competition which further improves the affordability (affordable)

• Improve time-to-market by deploying COTS and concentrate on air-transport specificparts (time-to-market)

• Provide simultaneous support of both services with a security impact as well as serviceswithout security concerns. (multiple-level security support)

4 TALIS architecture

Based on the challenge described above, the TALIS architecture provides the middleware tointegrate the existing elements. By combining the strengths of the individually provided servicesthe time-to-market for new services can be reduced significantly and competitiveness increasedresulting in better service at lower costs. TALIS has chosen to exploit COTS as much aspossible, e.g. the Internet Protocol (IP) to provide cross-platform connectivity, Java to providecross-platform applications and OpenWings to add the plug-and-play (self forming, self healing)capability at system level. Java also provides code mobility, enabling the swift update of servicesneeded by the concurrent enterprise approach to air traffic service provision. What remains forTALIS is to define the architecture, the application specific service interfaces and the supportingservices around the components. These components can be new components or legacy systemswith a wrapper. TALIS also needs to address the air transport specific safety and securityrequirements. Table 1 summarises the TALIS requirements are their compliance.

Requirement Compliance

Federated architecture OpenWings

Variability Java

Cross platform connectivity Java + OpenWings

Self-forming self-healing network OpenWings

Multiple-level safety support TALIS

Technology independence TALIS (specific protocols) + OpenWings

Open system TALIS + Java

Affordable COTS

Time-to-market TALIS + COTS

Multiple-level security support TALIS + COTS

Table 1 Summary of TALIS requirements compliance

Utilisateur

Zone de texte

Page 137

5 Process observations

This section provides the lessons learned while applying the concurrent enterprise to airtransport. In air transport traditionally structured methods are used combined with a waterfall lifecycle. Combined with company specific software processes these lead to safe and certifiableproducts but at comparative high cost, long time-to-market and limited variability. To improveon this, TALIS has chosen the Unified Modelling Language (UML) design method and theUnified Software Development Process (USDP) development process, a major innovation forthis industry. Theoretical knowledge of UML and USDP was available at some partners, all werelacking practical experience.

Many of the TALIS requirements need to be accommodated in its architecture. Consequently thequality of the architecture becomes of paramount importance. The Rational Rose UML tool suiteprovides much less model checks then the tools, with proprietary extensions, we were used to.Consequently the planned formal reviews became more important. The reviews were held inaccordance with European Space Agency (ESA) [ECSS-E-40, 1999] practises. An improvementwould be to use a documented assessment method like Scenario-Based Analysis of SoftwareArchitecture (SAAM) [Kazman, 2003] during such review. The disadvantages of any review arethe high cost and non-repeatable results. Consequently feedback on architecture decisions is onlyprovided at a few moments, when a lot of work has already been done. Automatically generatedmetrics, which provide immediate feedback, have proven their worth with the structuredmethods. Some trials were performed, but the tools used presumed UML model conventions.These conventions turned out to be incompatible with the project conventions, which are basedon available company practises and document generation tools. The correct way for metricswould be to use the Goal Question Metric approach [Basili, 1994], but only one validated metricfor statecharts was found. Experience with automatic architecture metrics [Chaudron, 2003]tends to suggest that after manual interpretation they may point to design weaknesses. Mostbenefit is acquired when watching the trend in these metrics during the design period. Moreautomated and validated metrics that provide direct feedback during the architecture design arewelcomed.

The implementation of the TALIS prototype architecture is on track. A demonstration isexpected beginning of 2004. Exploiting COTS already proved its worth, since the start of theproject Jini has been superseded by OpenWings which provides much better technologyindependence. Also work on a DO-178B certifiable Java subset has started in the Open Group[Foss, march 2003]. Once completed this will allow the TALIS architecture to support anyapplication, irrespective of its safety criticality.

Preliminary results for a 2 KLoC (thousand Lines of Code) component to display an aircraftinstrument (the safety critical primary flight display) of the 80 KLoC cockpit display subsystemindicate that Java halves the implementation time with respect to the current Ada and C basedpractise. Re-use of a/o graphic components is the major contributor to this improvement. In caseof certification, improvement is also expected for module tests and test effort.

Using the USDP process at project start three iterations of a traffic information service wereforeseen with two iterations for the meteorological application and only one iteration for thearchitecture. It is important to note that for certifiable software much effort is needed forverification and validation, both of which have been excluded from the TALIS applications. Theeconomic downturn resulted in a major effort shift between partners for the latter application,causing a reduction to one iteration and a minor project extension. For the former application theUML and USDP learning curve caused a reduction to two iterations. UML and USDPconsiderably reduce to time-to-market with respect to current practise. Nevertheless for serviceswithout safety implications and stringent time-to-market requirements another more responsivesoftware paradigm e.g. from agile software development needs to be considered.

Utilisateur

Zone de texte

Page 138

6 Safety and security issues

Relying exclusively on certified products, services, procedures and people ensures air transportsafety. For aircraft certification is performed once before entry into service. For every subsequentmodification an additional certification is needed. For ground systems and maintenance a licenseis provided for a fixed period of time. After expiry another assessment is performed beforeextending the license period. Additionally all operators like pilots, air traffic controllers andmaintenance personnel need a personal license. These licenses also cover a fixed time periodwith checks upon renewal. For all parts of the air transport system incident and accident reportsare produced and analysed to continuously improve all elements concerned. These procedureshave been so successful that accident rates, in the developed world, continue to drop and for allaccidents the human in stead of technology is now the major contributing factor by far.

As TALIS integrates aircraft, ground systems and some services, many different safety standardsapply for its components. Due to its different background each standard evolved differently andnow imposes, with due justification, specific not harmonised requirements. As various serviceswill be of different safety criticality, the architecture supports this. The TALIS architecture itselfcomplies with the requirements of the most critical service it intends to support.

As software can not be tested or be proven to comply with the required failure rates of once perbillion operating hours for the most hazardous class, all standards impose requirements on thesoftware development processes. The various standards impose different life cycle models withdifferent software artefacts so harmonisation or mutual recognition is needed in order not toimpede market conformant time-to-market and service update rates. Also current standards arelagging behind modern technology, e.g. object orientation and COTS are still notaccommodated. This delay incurs lot of additional effort on suppliers wishing to use such newtechnologies. In a goal-based approach like [SW01, 1998] the software is classified, the requiredevidence defined and a reasoning needs to be provided that the evidence satisfies the safetyrequirements. This approach is more appropriate for a federated system then the manyincompatible standards currently prescribed.

Systematic application of security in air transport systems is innovative. The use of special small-volume technology used to work as a kind of deterrent. This deterrent is already not effectiveanymore. TALIS reliance on COTS both necessitates security measures as well as facilitates thedeployment of existing solutions. In line with the TALIS philosophy security is best addressedby adhering to an open, internationally recognised standard. The [Common Criteria 1999]originating from the military domain, provide objective evidence about the product securitylevel. Qualified and officially recognised assessors perform the objective and repeatableevaluation, much like for safety certification. The common criteria impose software processrequirements as well as a standard list of security functions from which to chose. Further study isneeded to check whether the common criteria address all security concerns and assess thecompatibility of yet another set of software process requirements.

7 Conclusions

The TALIS prototyping work demonstrates that it is technically feasible to transform the airtransport system from the current set of stand-alone proprietary systems to a service-basedarchitecture enabling a concurrent enterprise. The federated architecture allows incorporatingcurrent legacy systems. The extensive use of COTS improves affordability, time-to-market,competition and reduces obsolescence by continuously incorporating new supportingtechnology. The result would be a more responsive air transport system

UML and USDP improve the time-to-market. The lack of validated automatically generatedmetrics makes intermediate assessment of the architecture cumbersome. For services without

Utilisateur

Zone de texte

Page 139

safety or security impact but stringent time-to-market requirements, other software paradigms,like agile software development, might be more appropriate.

The proposed TALIS architecture and its supporting COTS technology can simultaneouslyprovide services of various safety levels. Even the most safety critical services could beaccommodated after completion of market-driven progress on Java. A goal-based approach isrecommended to harmonise the various, currently incompatible, (sub)system certificationstandards.

For security concerns, which arose after the project start, a promising standard and certificationscheme has been identified. Its impact has to be studied further.

Acknowledgement

This work has been partly funded by the European Commission, DG Information Society Technologies as projectIST-2000/28744. The EUROCONTROL Experimental Centre leads the consortium of Lido, NLR, Thales Avionicsand Skysoft.

References

Pekka Abrahamsson: Agile software development methods: A mini-tutorial. WWW page.http://agile.vtt.fi/seminar2002.html, accessed March 2003.

V.R. Basili; C Caldiera; H. D. Rombach: Goal Question metric paradogm. Encyclopedia of software engineering,Volume 1, John Wiley & Sons, 1994, p.528-532.

Michel Chaudron; Johan Muskens: A comparative study of software architecture metrics in embedded andinformation system. WWW page. http://metric.cse.unsw.edu.au/Metrics2003, accessed March 2003

Peter Claes: The Galileo SW Development Context - Risks, Context, Ground Segment engineering, Space Segmentengineering, PA/QA, Safety, and SW Standards. WWW page.http://www.estec.esa.nl/conferences/02c30/index.html,

Common criteria for security evaluation, Version 2.1. WWW page. http://www.commoncriteria.org/cc/cc.html,August 1999, accessed March 2002. Also know as ISO/IEC 15408

DO-178B / ED12BL: Software Considerations in Airborne Systems and Equipment Certification. RTCA &EUROCAE, December 1992.

European Co-operation for Space Standardisation (ECSS). WWW page. http://www.ecss.nl/, accessed March 2003.

Finnish Aeronautical Information Service (AIS),

• Pre-flight Information Bulletins (PIB). WWW page. http://www.ilmailulaitos.fi/bulletins/Bulletinvalikko.htm

• Notice to Airman (NOTAM) summary. WWW page.http://www.fcaa.fi/bulletins/summary/notam_summary.pdf, accessed March 2003.

Jim Alves Foss; et al: Partitioning kernel protection profile, version 1.2. WWW page.http://www.opengroup.org, accessed March 2003 (members only).

Joint vision 2020. WWW page. http://www.dtic.mil/jv2020/jvpub2.htm, accessed March 2003.

Rick Kazman; G. Abowd; L. Bass; Clements: Scenario-based analysis of software architecture . WWW page.http://www.sei.cmu.edu/architecture/scenario_paper/ieee-sw3.htm , accessed March 2003.

SW01: CAP 670 ATS Safety Requirements, UK CAA. WWW page. http://www.caa.co.uk/docs/33/CAP670.pdf ,April 1998, accessed March 2003.

Acronyms

AOC Airline Operations CentreATM Air Traffic ManagementATN Aeronautical Telecommunication NetworkCDM Collaborative Decision MakingCOTS Commercial off-the-ShelfIP Internet ProtocolKLoC Thousand Lines of codeNOTAM Notice to AirmanSMGCS Surface Movement Guidance and Control

System

SAAM Scenario-Based Analysis of Software Architecture

TALIS Total Information Sharing for PilotSituational Awareness Enhanced byIntelligent Systems

UML Unified Modelling LanguageUSDP Unified Software Development ProcessXML Extensible Mark-up Language

Utilisateur

Zone de texte

Page 140




ANNEX C - 9

TOTAL INFORMATION SHARING FOR PILOT SITUATIONAL AWARENESS ENHANCED BY INTELLIGENT SYSTEMS


E-mail: [email protected] System-Wide Information Management

Air-Ground Integration

Abstract28

The Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, Phase 1 (TALIS 1) project was carried out from September 2001 until February 2004. The objective of the project was to investigate the viability and benefits of adopting an approach based on standardised architectures to provide for pilot situational awareness resulting in a safer and more efficient air traffic management process involving interactions between the ground and the air to bring benefits to the travelling public. This paper provides a summary of its final report with a high-level technical overview of project results.

Introduction The mission of Air Traffic Management (ATM) is the safe, orderly and expeditious management of air traffic. The current ATM system operates close to its capacity limit in high-density regions, and new concepts are needed to increase system capacity. Operational concepts like Controller-Pilot Data Link Communications (CPDLC) and the Airborne Separation Assurance System (ASAS) promise to increase capacity by a stronger integration of the air and the ground, and the co-operative handling of traffic management between the pilots and the controllers [1], [2], [3]. However, if capacity can be increased, safety must be increased at least at the same pace to increase the performance of the overall system. For safety, it is therefore mandatory to increase

28 Proceedings of the 23rd Digital Avionics Conference DASC, Oct. 24-28 2004, Salt Lake City, USA

the situational awareness of controllers and pilots in harmonisation. Especially the cockpit side is lacking behind and must be enhanced, pilots having very little situational awareness regarding ATM! Total Information Sharing is a technical concept that contributes to the increase of pilot situational awareness, and herewith directly to safety, and indirectly to capacity.

Information-sharing between the air and the ground suffers from the high complexity of air-ground integration, and its high costs are a major problem. All technologies that integrate the air and the ground take a long time from research until implementation, due to the high safety concerns and costs for avionics integration, and the necessity for global deployment of infrastructures. E.g. typical implementation times for new technologies are measured in decades, as illustrated by certified GPS29 approaches in the navigation domain - versus massive GPS use in the general domain, cars and the maritime domain. The TALIS project targets at shortening the time-to-market of new avionics packages, and herewith reduces the cost of implementation, by providing early benefits coming from an earlier deployment of the operational concepts. TALIS also attempts to lower the production cost of new packages, making intensive use of commercial-off-the-shelf software (COTS).

The information-sharing paradigm in TALIS is closely related to the World-Wide-Web (WWW), with a special focus on mobile users. Information everywhere, for everybody, as a function of need, delivered in a framework of tools: services, protocols, and browsers. The principle of the WWW is further extrapolated for safety-related business cases.

29 Global Positioning System





This paper gives a high-level overview of the findings of the TALIS project.

TALIS Project The Total Information Sharing for Pilot Situational Awareness Enhanced by Intelligent Systems, Phase 1, (TALIS 1) project was carried out from September 2001 until February 2004 by a consortium consisting of 5 partners: LIDO, NLR, SKYSOFT, THALES Avionics and EUROCONTROL Experimental Centre (EEC). The project was coordinated by EEC. The total cost of the project was 4.4 Million €, co-financed by 50% by the European Commission, DG-IST, in the context of its 5th Framework for Research and Development.

The objective of the project was to investigate the viability and benefits of adopting an approach based on standardised architectures to provide for pilot situational awareness resulting in a safer and more efficient air traffic management process involving interactions between the ground and the air to bring benefits to the travelling public.

Figure 1: TALIS Concept Illustration

Figure 2: TALIS Concept Illustration

Figure 1 and Figure 2 illustrate the vision of the TALIS project: A collaborative, distributed, mobile, interoperable, consistent, available and integrated information sharing system.

TALIS Results The TALIS project was striving for high innovation and scientific and technological excellence. There are a number of innovations that make the value of the project and where the most important ones are enumerated in this section. Most of the project results are publicly available at http://talis.eurocontrol.fr.

Pilot Situational Awareness

The operational objective and goal of the TALIS project is to increase pilot situational awareness with the help of intelligent applications. Increased pilot situational awareness is mandatory if functions, tasks and responsibilities are delegated from the ground traffic management system to the flight deck.

A basic functionality is the increased pilot situational awareness needed to evaluate the need for action in co-operative processes, and monitor the implementation of manoeuvres. The flight deck becomes the drain for all kind of information from environment and ATC tactical data, e.g. the surrounding aircraft identification, position and velocity, clearances for the own ship and potentially also for other surrounding aircraft, airspace status information like dynamic route information, congestion or special use airspace, meteorological information for all




flight phases, airport approach slotting, dynamically contributed SID and STAR, runway identification, runway visual range, taxi routing information, maps, gate management and much more.

Decision support and decision making is functionality that traditionally involves the human, typically for controller-pilot exchanges and pilot-airline operator exchanges. In the future these decision processes will increasingly rely on digital information exchanges and protocols like CPDLC, and evolve towards at least triangular processes that include the pilot, controllers, airline operators, airport- and military control. Other types of decision support tools for conflict prediction, prevention and resolution will be supported by tools provided they can approximately reach the capacity of humans.

Future concepts foresee new logistics functions beyond flow management, an evolution in the cockpit in the sense that the pilot will be involved in air traffic flow processes, from pre-flight planning at the last minute, to in-flight tactical flow management. For the airline operations side the pilots’ role will evolve to higher anticipation in airline fleet management, and passenger flow support.

The TALIS project has made a modest start with the elaboration of two applications, the Traffic Information Service in contract mode and the Weather application.

TALIS Services Concept

The TALIS Services Concept [4] is the fundamental principle of TALIS: a component-based software architecture where service-providers can publish and offer their services on a dynamic basis, and service-consumers can discover these published services on the fly, and use them. This is known as dynamic service-discovery and dynamic service-binding. As service-providers may be complicated constructs they may consume yet other services, and chains of service-users/service-providers are created. When several services bind together to accomplish some common task they are called federations of services. The federation is organic because its form may vary as a function of events that come from inside or outside the federation. This gave the name to

the software architecture that was developed in the TALIS project: The Federation Architecture (FA).

Figure 3 illustrates an example for a flight deck application where the navigation display integrates both traffic services and weather services. In the future they could be “federated” and combined e.g. for tactical-flow-management- and separation services.

ASASService

TISService

METEOService

RADARService

Flight PlanService

ADS-BService

CPDLCService

CD&RService

Flight Mgt.Service

METEOService

CDMService

in a/c ATCground

CFMUground

airlineground

airlineground

Figure 3: Services Concept30

Service Oriented Programming

Service-Oriented Programming (SOP) is the translation of the TALIS Services Concept into a technical concept. SOP is the basic paradigm for business-to-business applications. Service-oriented computing contains components that publish and use services in a peer to peer manner. In SOP a client is not tied to a particular server and service providers are all treated equivalently.

The following architectural elements define Service-Oriented Programming:

30 CDM – Collaborative Decision Making, CD&R – Conflict Detection and Resolution, ADS-B – Automatic Dependent Surveillance Broadcast, CFMU – Central Flow Management Unit




• Contracts – An interface that contractually defines the syntax and semantics of a single behaviour.

• Components – Third party, reusable, deployable computing elements independent of platforms, protocols, and deployment environments.

• Connectors – Encapsulates details of transport for a specified contract, an individually deployed element that contains a user proxy and a provider proxy.

• Container – Service that can run components, managing availability and code security.

• Contexts – For deploying plug-and-play components, for installation, security, discovery, and lookup.

Federated Architecture

The TALIS Federated Architecture (FA) is a technology-framework in which applications can be deployed as distributed system components in an aeronautical network. The architecture comprises component-based middleware that will enable interoperability between applications, and common capabilities that can be reused by TALIS applications e.g. system management, remote management, component communications, data encryption, data authentication, and security [5].

The Federated Architecture is highly based on a commercial-off-the-shelf middleware package called OPENWINGS31, which itself is based on Java libraries, JINI components and other XML related middleware. The TALIS architecture adds to this with even higher abstractions and additional middleware services. It includes Connector technology for a complete abstraction of the air-ground and other telecommunications technologies like the ATN32. Figure 4 depicts the technology-framework that is used for the FA.

31 http://www.openwings.org 32 ATN – Aeronautical Telecommunications Network

RMI

JMS

MDB

JCA


Air/GndComm.

Network

J2EE


Security Services

Components Services

Service Handler

Message Handler

J2SE


Time Mgr.

Flight Phase

Figure 4: FA Technology Framework

One main feature of the Federation Architecture is the support for dynamic discovery and linking between components. This is the major enabler for the TALIS Services Concept described above, because applications can build up from a number of underlying services that are discovered and used on-the-fly depending on their geographic availability - or other criteria. The FA with its potential for dynamic service discovery, and service-binding, bears two other main properties: the system becomes self-forming and self-healing. That is of uttermost importance for Air Traffic Management, because safety considerations are of highest importance.

Several papers for international conferences have been produced on the Software Connector ([6], [7]). The installation of Meteorological and Traffic Information components which provide, discover and use internal and external services was achieved. The FA implements Connectors, examples are the JMS, RMI and ATN connector. The FA also implemented containers, which are the execution environments for components and services, and which manage security, authentication and availability. Code migration and even running applications migration, with some technological restrictions, were successfully achieved on the project.




Flight-Deck Browser TALIS foresees a mode of pilot interaction for information sharing that is comparable to browsing on the World-Wide-Web. If more information is needed on a specific visual object, e.g. an adjacent aircraft, then the object can be selected and more information be requested. Upon this request, the system subscribes to a remote-service to deliver this information. The requested information is visualised to the pilot. The TALIS prototype allows for information browsing in the TIS application (Figure 5). Selecting adjacent aircraft may request additional information, like flight plan and trajectories. The prototype has two screens for visualising information depending on the information: the Navigation Display and the Multi-Cockpit Display Unit. The information is presented either graphically or textually on the respective user interfaces.

Figure 5: Example Navigation Displays with TIS-C Information

Traffic Information Service - Contract Traffic Information Service in contract modus (TSI-C) is a new concept that has been developed by the TALIS project. It is a service that allows for the subscription of the flight deck to traffic services that are provided from ground servers. The traffic services defined in TALIS are aircraft positions, aircraft flight plans, aircraft trajectories, conflicting aircraft with the conflict geometry, and predicted positions of adjacent aircraft at the time of conflict. Figure 6 illustrates the functional architecture diagram for the MTCD33 service. 33 MTCD – Medium Term Conflict Detection

ADS-BReceiver

Intent

4D Position + Intent

TrajectoryConverter

4D Trajectories

ADS-B MTCDAlgorithm

Conflicts

TIS-CAir

Own Ship 4D Trajectory

MTCD Check

Flight Manage.System

MTCD Fusion

Verified Conflicts

Conflicts + Tracks + 4D Trajectories

SurveillanceData Processing

FlightData Processing

TrajectoryPrediction

MTCDAlgorithm

TIS-CGround

Conflicts

4D Trajectories

Radar Tracks Flight Plans

MTCD +ADS Volumes

Figure 6: MTCD Functional Architecture

Several papers have been produced for the TIS-C concept and its validation ([8], [9], [10]). Several project deliverables have been produced for the specification, design, implementation and test of TIS-C Service. The TIS-C Standards And Recommendations Document was produced, the demonstrator implements the TIS-C concept as currently defined (Figure 5), and the functions have been verified through a high number of test cases.

Weather Service

The purpose of the Weather Application is to support decision making processes for the flight deck and for ground personnel who are involved in the actual flight operation after the planning and flight briefing phases have been completed. For this purpose, the most likely decision making factor, after the planning and flight briefing phases, is the weather condition along the flight plan. The Weather Application will improve and increase the productivity and flexibility of the different actors in view of an economical decision making process.

The TALIS Weather application sends scheduled weather updates to the aircraft: Meteorological Aerodrome Report (METAR) and Terminal Aerodrome Forecast (TAF). It sends non-scheduled weather updates to the




aircraft: Significant Meteo (SIGMET), Tropical Storms, Volcanic Ash Advisories, Convective SIGMETs, Clear Air Turbulence Warnings and Wind Shear warnings. It also sends Notice(s) To Airmen (NOTAM) updates to aircraft. The data comes from the LIDO weather database, however, the TALIS demonstrators uses logs of this database and no real-time data connection yet. The meteo information is shown in textual form on the MCDU, the graphical version could not be implemented yet.

It will be possible to use the information from the Weather application in combination with other services or applications, e.g. for tactical weather re-routing applications, which do not exist today. The TALIS Weather Applications is therefore an enabler for future innovations.

Total Information Sharing Protocol (TISP)

The Total Information Sharing Protocol (TISP) is a new concept [11] that underlies TIS-C and many potential future applications. It defines the way how services are discovered and subscribed to. Similar to ADS-C it is based on a contract between the air and the ground, and adds possibilities for a dynamic negotiation of contracts.

TISP is a generic software protocol for client-server software architectures. It customises the client-server protocol for mobile consumers and for safety-critical applications. It is conceived to operate in an environment of service providers and service users, competition between service providers, and free choice of services for the service consumer. Therefore special attention has been put on the discovery of service providers, the negotiation of contracts between service providers and service consumer, and a pre-negotiated seamless hand-over between service providers. In addition the notion of third parties has been introduced so that contracts can be negotiated on behalf of a party, e.g. an airline negotiating a company contract for all of its aircraft, or ATC imposing standard contracts for all aircraft and service providers. All these features will be presented in the following paragraphs.

Figure 7 depicts the set of protocol patterns that TISP is composed of: dynamic service discovery, service negotiation, service subscription, service delivery, and seamless service hand-over.

Lookup Service Server

TIS-C GroundServer A

TIS-C Ground Server B

Aircraft

Lookup Traffic Information Service

Subscribe at Traffic Information Service A


Handover to B


Negotiate Service

Figure 7: Simplified TISP

Intelligent Systems

There has been some effort to analyse how the software system could select and filter information in an intelligent way. The approach has been through structured object-oriented software analysis [12]. This approach has not shown significant results. There are, however, some intelligent filter functions through the definition of abstract event-types in the TISP protocol that will lead to enhanced contextual behaviour of applications.

Certify-Ability

The TALIS system was introduced as a solution to allow the use of more dynamic and cost effective software to be used in airborne systems. In order to achieve these goals it uses commercial off-the-shelf software and Java as implementation platform, ensuring the availability of support tools. The TALIS system is used both as part of an airborne system and a ground based system, which makes DO-178B/ED-12B and DO-278/ED-109 applicable [13], [14].

A specific challenge is the use of Java for safety critical application, and much work is ongoing in the world to allow Java to be used for safe critical applications.




To show the availability of COTS development tools a market survey was conducted, which concludes that it should be possible to create an efficient software development environment using state of the art technologies, while still being able to achieve the highest levels of safety. The relatively low rankings of all tools analysed in the market survey indicate that more work needs to be performed by tool vendors in order to provide better support a DO-178B/ED-12B development process. Tool qualification especially is an issue that must be resolved in order to employ the tools effectively.

Unified Process

The design process played an important role in the project. The objective was to innovate and to apply a user-centric, iterative, incremental and architecture-centric process and the choice was made to apply the Unified Software Development Process (USDP).

The deployment of a formal and conceptual modus operandi across various partners with different main areas of research and development is still a challenge. The process had to be developed during execution of the project, and the deliverables, or artefacts, be defined.

The Unified Process was experienced and experimented by each of the partners, all used to the rigid V-cycle. Therefore all partners went through a learning curve. This was reflected in the very long cycle for the first iteration, and the short cycle for the second one. It was felt that a third iteration would be in the spirit of the process, whereas the first two ones were learning. Once mastered, the Unified Process can be considered beneficial and leading to lower development costs.

TALIS Deliverables The public deliverables can be found on the project web site (http://talis.eurocontrol.fr).

The consortium decided to include design in the form of UML models as public deliverables, which is unusual, to reflect the wish to promote OPEN system principles to help the aeronautical community (and the tax

paying citizen) to prevent duplication of effort. Only the deliverables in the form of software are private deliverables to the consortium.

The TALIS Demonstrator The TALIS Verification Platform is a test, verification, and demonstration environment for the Federated Architecture and the two applications. It is built into the rapid-prototyping platform DACOTA (Figure 8) from THALES Avionics.

Navigation Display

MCDU - RMP

Navigation Display

MCDU - RMP

Figure 8: DACOTA

The TALIS demonstrator adds 184 design classes, 246 implementation classes, about 69000 lines of no-COTS code, and 478 test cases to that platform. The amount of COTS code extends 1000000 lines.

Conclusion It is the conviction of the TALIS consortium that information-sharing as a cornerstone of system-wide information management will improve the overall performance of the Air Traffic Management system in all its dimensions: safety, capacity, cost and environment. Technical work to allow integration into the system-of-systems will be increasingly required. The TALIS 1 project has given some initial contributions to this with the elaboration of the Federation Architecture and two applications for pilot situational awareness.

The Federation Architecture and the two flight deck applications have been conceived, documented, developed and integrated into a prototype cockpit. The demonstration has been run. That required a high degree on innovation, on the software-technology and operational levels.

Many subjects would merit continuation: operational validation of the architecture and





the applications, additional applications, additional architecture features, additional off-the-shelf components, life-data, life-trials etc. However, others have been found unsatisfactory: lacks in UML, reliability of the chosen off-the-shelf middleware for the software architecture etc.

These are the high-level results of the TALIS 1 project. All partners have already gained value through the additional know-how that has been acquired. There is some potential for early exploitation disregarding the high innovative character of the project. Continuation of the project is unclear at the moment of editing this paper.

The Author R. Ehrmanntraut has been working since 1996 at the EUROCONTROL Experimental Centre in Brétigny sur Orge, France. Since autumn 2003 he started a PhD thesis in Air Traffic Management. He has been co-ordinator of the TALIS consortium, an EC project that finished in spring 2004. From 1999 until 2003 he has been CNS Business Area Manager. From 1996 until 1999 he has conducted several projects on air-ground integration. Before 1996 he has been engineer in information technologies in an industrial company. He holds a diploma of telecommunications engineer from RWTH Aachen, Germany in 1991.

Acknowledgements Many thanks to the co-authors of the TALIS 1 Final Report: Ronald Grosmann, NLR, Luis Nunes, SKYSOFT, Helder Silva, SKYSOFT, Gilles Francois, THALES Avionics, Alexandre Simonin, MODIS. Special thanks to the entire TALIS technical team.

References [1] EUROCONTROL, 2002, Towards Co-

operative ATS - The COOPATS Concept, Version 1.0, EUROCONTROL - EATMP – AGC PROGRAMME.

[2] NASA, Concept Definition for Distributed Air-Ground Traffic Management (DAG-TM), Version 1.0, 1999, NASA – AATT Project.

[3] FAA/EUROCONTROL Co-operative R&D, 2001, Principles of Operation for the Use of Airborne Separation Assurance Systems ASAS.

[4] Ehrmanntraut, Rudi, 2001, TALIS Services Concept, in proceeding of the FAA/EUROCONTROL Action Plan 5 workshop, Toulouse, France.

[5] Ehrmanntraut, Rudi, A. Hally, J. Bauer, 2002, EUROCONTROL, Intelligent Information And Interactive Systems For Pilot Situational Awareness Enabled By A Federation Architecture, in proceedings of the 21st Digital Avionics System Conference, Irvine, California.

[6] Ehrmanntraut, Rudi, 2003, System-Of-Systems Integration Of Air-Ground Telecommunications With The Software Connector, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[7] Ehrmanntraut, Rudi, 2003, Towards a System of Systems: Transparent Integration of Air-Ground Telecommunications Using the Connector Technology, EUROCONTROL Experimental Centre, in Proceedings of 10th Saint Petersburg International Conference on Integrated Navigation Systems May 26 - 28, 2003.

[8] Ehrmanntraut, Rudi, 2003, Alternative Enablers For Airborne Separation Assurance Systems, in the EEC Newsletter of July 2003




[9] Ehrmanntraut, Rudi, et. al., 2003, Enabling Air-Ground Integration: Concept Definition For Traffic Information Service In Contract Mode (TIS-C), EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC, 2003.

[10] Ehrmanntraut, Rudi, 2004, Validation Of The Traffic Information Service In Contract Mode (TIS-C) Concept Over VDL Mode 2 With The Acts Simulator, EUROCONTROL Experimental Centre.

[11] Ehrmanntraut, Rudi, 2003, Towards a Concept Definition of the Total Information Sharing Protocol, EUROCONTROL Experimental Centre, in Proceedings of the 22nd DASC.

[12] Bauer, Josep, 2002, Diploma Thesis, TUB and EUROCONTROL, Identification and Modeling of Contexts for Different Information Scenarios in Air Traffic Management, http://talis.eurocontrol.fr.

[13] Kesseler, Ernst, et.al., 2002, Integrating Navigation and Communication Systems for Innovative Services, NLR and EEC, in Proceedings of 9th St Petersburg Conference for Integrated Systems.

[14] Kesseler, Ernst, 2003, Transforming Air Transport To A Concurrent Enterprise Technical, Safety And Security Perspectives, NLR, in proceedings of the Aviation in the XXI-st Century conference, Kiev, Ukraine.


http://www.congress.org.ua/

http://www.congress.org.ua/