DEFAMM - Final Report · 0 Final Report – Volume II: Summary of DEFAMM Deliverables This second volume of the Final Report contains the full set of short descriptions of all public

___________________________________________________________________________

Final Report

Volume II (public edition)

Demonstration Facilities for Airport Movement Management

DEFAMM

Alcatel Air Navigation Systems

Project Manager: Franz-Georg Monzel

Alcatel Air Navigation Systems Lorenzstrasse 10, D-70435 Stuttgart, Germany

Phone: +49 711 821 34657, FAX: +49 711 821 43613 e-mail: [email protected]

Copyright Notice This document and the information contained herein is the property of Aéroports de Paris, Alcatel Air Navigation Systems GmbH, Alcatel ISR, Alenia, Daimler-Benz Aerospace, Dassault Electronique, Deutsche Flugsicherung GmbH, Deutsche Forschungsanstalt für Luft- und Raumfahrt, Defence Research Agency, Flughafen Köln/Bonn, Instituto Nacional de Técnica Aeroespacial, National Avionics, Nationaal Lucht- en Ruimtevaartlaboratorium, Oerlikon-Contraves, Société Française d'Etudes et de Réalisations d'Equipements Aéronautiques and the EC, DG VII. Any reproduction or other use of this material shall acknowledge the DEFAMM project, the companies involved and the EC as the information sources.

Disclaimer

The members of the DEFAMM team (see cover page) and the EC shall not be liable for any damage resulting from the application of the contents or part of the contents of this report or the documents referenced in this report. Any third party shall be entirely responsible for the use to which it puts the information contained in these papers.

Public AANS _____________________________________________________________________

DEFAMM Final Report

Volume II (public edition)

Summary of DEFAMM Deliverables

Table of Contents:

0 FINAL REPORT – VOLUME II: SUMMARY OF DEFAMM DELIVERABLES 4

1 WP 1000 : DEFINITION OF DEMO SYSTEMS 5

2 WP 2000: DEMO FACILITIES MONITORING (PHASE I) 20

3 WP 3000 : DEMO FACILITIES PLANNING & GUIDANCE (PHASE II) 51

4 WP 4000 : REALISATION 69

5 WP 5000: DEMONSTRATION TESTS 74

6 WP 6000: EVALUATION 81

7 WP 7000: MANAGEMENT 86

_____________________________________________________________________ 22.10.02;DEFAMM_firap5.doc Task 7100 Page 3 of 89

Public AANS _____________________________________________________________________

0 Final Report – Volume II: Summary of DEFAMM Deliverables

This second volume of the Final Report contains the full set of short descriptions of all public DEFAMM deliverables. The short descriptions are organised according to the DEFAMM Work Packages. This Volume II is issued in two versions, a public and a restricted edition. The table below shows the organisation of the DEFAMM work packages and the activities performed. The identifiers of the work packages are hyperlinks. A mouse click on such a link will directly lead to the document list of the corresponding work package. From there either the short description can be shown on the display or the complete document can be downloaded form the DEFAMM CD-ROM.

Table of Contents

Name Title and Activities Performed PageWP 1000: DEFINITION OF DEMO SYSTEMS: Elaborate functional and architectural

structure of the demonstrator system including definition of subsystems and interfaces.

5

WP 2000: DEMO FACILITIES MONITORING (PHASE I): Provide pretested subsystems required for Surveillance and Control System Demonstrator including sensors, processing units, communication systems and HMI, and perform predemonstrations on several test sites.

20

WP 3000: DEMO FACILITIES PLANNING & GUIDANCE (PHASE II): Provide pretested subsystems required for Planning, Guidance and Control System Demonstrator including, processing units, guidance means and extension of communication systems and HMI, and perform predemonstrations on several test sites.

51

WP 4000: REALISATION: Plan, install, and verify A-SMGCS demonstrator performance in two overlapping phases with emphasis on Surveillance in Phase I and planning and guidance in Phase II, including provision of test site specific facilities.

69

WP 5000: DEMONSTRATION TESTS: Plan and perform tests with Phase I (Surveillance and Control) and Phase II (Planning, Guidance and Control) demonstrator system including development of test equipment.

74

WP 6000: EVALUATION: Evaluate the demonstrator system, assess improvement of A-SMGCS support on safety and efficiency, validate A-SMGCS system functions and procedures, and define a prototype system.

81

WP 7000: MANAGEMENT: Manage and control the project regarding deliverables, cost and schedule and coordinate with other tasks.

86


Public AANS _____________________________________________________________________

1 WP 1000: DEFINITION OF DEMO SYSTEMS

Title Related Task

Acronym / Filename

Go to Shortdescr. Load File Type of

Deliverable

2. User Requirements Document, General A-SMGCS Issue T1100 D_URDG41 D_URDG41 D_URDG41 Public

3. DEFAMM User Requirements Document T1100 D_URDD41 D_URDD41 D_URDD41 Public 5. System Requirements Document, General

A-SMGCS Issue T1100 D_SRDG41 D_SRDG41 D_SRDG41 Public

6. DEFAMM System Requirements Document T1100 D_SRDD41 D_SRDD41 D_SRDD41 Public

8. Demo System Functional Requirements Document T1200 D_DRD_19 D_DRD_19 D_DRD_19 Public

9. Demo System Functional Requirements Document ANNEX T1200 D_DRD_A3 D_DRD_A3 Public

12. Public Part of DEFAMM SMGCS Relevant Technology Documentation T1300 D_RTD_P D_RTD_P D_RTD_P Public

14. Public Part of Demo System Design Specification Document T1400 D_DDS_P D_DDS_P D_DDS_P Public

15. Demo System Interface Control Document T1500 D_ICD_21 D_ICD_21 D_ICD_21 Public

16. Demo System Interface Control Document, ANNEX A: System Model Use Cases and Event Diagrams

T1500 D_ICDA30 D_ICDA30 D_ICDA30 Public

17. Demo System Interface Control Document, ANNEX B: System Model Event Summary Diagrams and Message Tables

T1500 D_ICDB30 D_ICDB30 D_ICDB30 Public

18. Demo System Interface Control Document, ANNEX C: Structured SMGCS Information Content (SSIC)

T1500 D_ICDC71 D_ICDC71 D_ICDC71 Public

19. Demo System Interface Control Document, ANNEX D: ASTERIX-S T1500 D_ICDD28 D_ICDD28 D_ICDD28 Public

20. Demo System Interface Control Document, ANNEX E: DLR DEFAMM Messaging

T1500 D_ICDE20 D_ICDE20 D_ICDE20 Public

21. Demo System Interface Control Document, ANNEX L: Message Tables for IDL definition

T1500 D_ICDL32 D_ICDL32 D_ICDL32 Public

Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ User Requirements Document, General A-SMGCS Issue (D_URDG41) Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: User Requirements, General Issue Related Task('s): 1100 Emission Date of Delivery: 27. September 1996 Revision Number: 4.1 Ref./File No. D_URDG41.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The General A-SMGCS User Requirements were found by the following processes: 1. Prior to the initiation of DEFAMM a number of studies, technology demonstrations and sets

of requirements were produced by various organisations in several countries. 2. Review of this previous work to identify a set of User Requirements based on the results of

all these earlier activities. 3. Analysis to produce user requirements which are grouped together according to their

functions. 4. Operational Requirement developed by AOPG (ICAO) was adopted by all the significant

operational and regulatory bodies. This document was chosen as a basis for the General A–SMGCS User Requirements and supplemented with the previous results.

In order to organise the User Requirements a definition of requirement attributes and acronyms of DEFAMM subsystems were necessary. All User Requirements found by the process described above are listed in tables in which their attributes and their association to the specific DEFAMM subsystem are given.


Public AANS _____________________________________________________________________ DEFAMM User Requirements Document (D_URDD41) Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: User Requirements, DEFAMM Issue Related Task('s): 1100 Emission Date of Delivery: 27. September 1996 Revision Number: 4.1 Ref./File No. D_URDD41.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: For the definition of the DEFAMM User Requirements, the more general document (User Requirements Document, General A-SMGCS Issue) was reviewed. by the partners in order to select those requirements which were specific to the scope of DEFAMM. For the organisation of the DEFAMM User Requirements the same attributes and acronyms as used in the general article were used. All requirements are listed in tables in which their attributes and their association to the specific DEFAMM subsystem are given.


Public AANS _____________________________________________________________________ System Requirements Document, General A-SMGCS Issue (D_SRDG41) Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: System Requirements, General Issue Related Task('s): 1100 Emission Date of Delivery: 27. September 1996 Revision Number: 4.1 Ref./File No. D_SRDG41.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The purpose of the System Requirements document is to identify performance and design criteria for the sub systems and equipment that enable the user requirements to be met. It therefore provides an essential link between what the user needs and the actual system to be demonstrated within DEFAMM. This document presented for DEFAMM is the set of A–SMGCS system requirements reviewed and judged by the DEFAMM partners to be relevant for A–SMGC systems. Not all of these requirements are realised in the DEFAMM demonstrator system. Like the User Requirements, the System Requirements are listed in tables in which their attributes and their association to the specific DEFAMM subsystem are given.


Public AANS _____________________________________________________________________ DEFAMM System Requirements Document (D_SRDD41) Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: System Requirements, DEFAMM Issue Related Task('s): 1100 Emission Date of Delivery: 27. September 1996 Revision Number: 4.1 Ref./File No. D_SRDD41.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: For the definition of the DEFAMM System Requirements, the more general document <<System Requirements Document, General A-SMGCS Issue>> was reviewed. by the partners in order to select those requirements which were specific to the scope of DEFAMM. For the organisation of the DEFAMM User Requirements the same attributes and acronyms as used in the general document were used. All requirements are listed in tables in which their attributes and their association to the specific DEFAMM subsystem are given.


Public AANS _____________________________________________________________________ Demo System Functional Requirements Document (DRD) (D_DRD_19) Author(s): W. Kailbach, W. Nusser, WP1000 Team Company: AANS Subject: Task 1200 Deliverable Document Related Task('s): 1200 Emission Date of Delivery: 27. September 1996 Revision Number: 1.7 Ref./File No. D_DRD_19.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: Based on the System Requirements, the relevant functional structures of the DEFAMM SMGCS are elaborated and described in this document. The main functional structures were identified as:

• Surveillance: This function is based on distributed sensor subsystems providing location and/or identification information about the relevant objects. The Sensor Data Fusion then combines the information provided by the different sensors (cooperative and non-cooperative).

• Routing: Processes like selection and assignment of routes to aircraft, runway occupancy, push back planning, plan deviation monitoring and other related functions are summarised in the routing function.

• Control: The Control function is subdivided into the "Situation Assessment ", which extracts the tactical traffic situation from the real traffic situation and the "conflict handling", which finally detects runway incursions and imminent conflict situations.

• Guidance: This function is responsible for the correct guidance of an aircraft using the appropriate means for routing.

• Human Machine Interface (HMI): It displays the current traffic situation to the controller and shows possible conflicts, alarms and plan deviations. The HMI also takes care about the controller interactions with other DEFAMM functions.

• Communication: This function defines the subsystems necessary for communication between the SMGCS and the pilots/vehicle drivers.

• Management: Here, data storage and data recording as well as the technical system control unit, used for technical management are located.

Furthermore, the test sites for the (pre)demonstration of the A-SMGCS functions are investigated. In order to gain the maximum benefit from the A–SMGCS, the already existing facilities of the airports are analysed. The DEFAMM test locations are

• Cologne/Bonn (Germany) • Orly (France) • Braunschweig (Germany) • Malpensa (Italy)


Public AANS _____________________________________________________________________ Public Part of DEFAMM SMGCS Relevant Technology Documentation (D_RTD_P) Author(s): D.GODEL Company: Dassault Electronique Subject: Public Part of SMGCS Relevant Technology

Documentation Related Task('s): 1300 Emission Date of Delivery: 13. December 1996 Revision Number: 1.6 Ref./File No. D_RTD_P.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is a review of technologies that could be used within an A-SMGCS Not all possible technologies are included. However, representative examples of each functional category (see document D_ICD_21) are described. This document should be used as an introduction to the technology being deployed in DEFAMM. The way in which the equipment is embedded into the demonstrator system can be found in the design documents. The ‘state–of–the–art’ technology of the following systems are briefly discussed: • Near Range Network radar (NRN) and SYLETRACK as example for surveillance sensors. • Methods and concepts of the Sensor Data Fusion as provided by Dassault Electronique. • The role of the Situation Assessment and Conflict Handling within DEFAMM. • The TARMAC System responsible for routing and runway occupancy planning. • Guidance processing and the controlling of ground guidance means like taxiway centre

lights. • Pilot/Driver Assistant System in order to transfer information to the aircraft. • As example for the communication between sensors, the Mode S subnetwork and the

UHF/VHF data link is described. • Requirements for the Human Machine Interface are discussed.


Public AANS _____________________________________________________________________ Demonstrator System Design Specification Document (DDS) (D_DDS_P) Author(s): W.Kailbach, W.Nusser, WP1000 Team Company: Alcatel Air Navigation Systems Subject: System Architectures Related Task('s): 1400 Emission Date of Delivery: 13. December 1996 Revision Number: 2.0 Ref./File No. D_DDS_P.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In this document the system design specification of the DEFAMM demonstrators at Cologne/Bonn, Orly, Braunschweig and Malpensa are described. It shows the assignment of the subfunctions defined in WP1200 to physical subsystems and processing units and their interconnection topology. Moreover, the basic subsystem parameter definitions are laid down in this document.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICD21) Author(s): W. Kailbach, K. Klein, Ch. Meier, A. Schnorr, Company: AANS, DLR Subject: Interfaces Related Task('s): 1500 Emission Date of Delivery: 11. December 1996 Revision Number: 2.0 Ref./File No. D_ICD_21.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Task 1500 documents, of which this is the main document, give the interface definitions of application level interconnections between subsystems as well as of protocols for physical interconnections of subsystems/processing units and external systems.

Since the Cologne/Bonn demonstrator is a very complex system covering all A-SMGCS functions and consisting of several subsystems from different partners, it had to be defined completely from the system and the subsystem interfacing view. According to the complexity of this task, a generic A-SMGCS approach as well as a new way to solve the interface definition problem with tool-based system modelling is introduced:

• Development of a tool-based system modelled by so-called Use Cases. • Evaluation of Event Trace Diagrams describing the operational procedures. • Collection of logical messages in the system with the help of event summary diagrams and

message tables. A comprehensive description of the interfacing subjects can be found in the following annexes: D_ICDA30.DOC System model use cases and event diagrams, D_ICDB30.DOC System model event summary diagrams and message tables, D_ICDC71.DOC SMGCS Structures Interface Content format definition, D_ICDD28.DOC DEFAMM ASTERIX-S definition, D_ICDE20.DOC DLR Messaging. D_ICDL32.DOC Message tables for IDL definition For transport, session, presentation, and partly application it was agreed to use in general CORBA (ORBIX implementation) combined with TCP for interprocess and intersubsystem communication. Exceptions from this regulations concern sensor subsystems which will use an ASTERIX-S protocol combined with UDP for messaging. The current version of the documents gives all partners a clear understanding of the systems/subsystems functionality and messaging and builds the basis for the adaptation developments of WP 2000.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDA30) ANNEX A: System Model Use Cases and Event Diagrams Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: Use Cases and Event Trace Diagrams Related Task('s): 1500 Emission Date of Delivery: 06. Juni 1997 Revision Number: 3.0 Ref./File No. D_ICDA30.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In this document the subsystem interfaces will be defined. For this purpose, so called ‘Use Cases’ and ‘Event Trace Diagrams’ described by Ivar Jacobsen in his book "Object Oriented Software Engineering" are applied. In this approach a use case is described as a specific way of using the system by using some part of the functionality. Each use case constitutes of a complete course of events initiated by an actor. It specifies the interaction that takes place between an actor and the system. A use case is thus a special sequence of related transactions performed by an actor and the system in a dialogue. The collected use cases specify all the existing ways of using the system. The actors model anything that needs exchange of information with the system. Actors can model human users, but they can also model other systems communicating with the system. For each concrete use case (at least) one event trace diagram or interaction diagram was drawn. An event trace diagram describes how the use case is realized by the interaction of communicating objects. The objects are the DEFAMM Koeln/Bonn demonstrator subsystems. The interaction takes place as the subsystems send events or stimuli between one another. As we draw the event trace diagrams we will define all the events, including the parameters. In an event trace diagram a subsystem or actor is described by a bar. These bars are drawn as vertical lines in the diagram. The time axis in the event trace diagram is going downwards. A use case thus starts at the beginning of the event trace diagram. The events are stimuli that are sent from one subsystem to another. Therefore each event initiates an operation in the receiving subsystem. If all use cases and the events which are exchanged between the subsystems and between actors and the system are described, the complete functionality of the system will be found.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDB30) ANNEX B: System Model Event Summary Diagrams and Message Tables Author(s): Dr. W. Nusser, WP 1000 Team Company: Alcatel Air Navigation Systems Subject: Event Summary Diagrams/Event Tables Related Task('s): 1500 Emission Date of Delivery: 04. June 1997 Revision Number: 3.0 Ref./File No. D_ICDB30.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document can be regarded as a continuation of the Demonstrator System Interface Control Document Annex A. Here, the event summary diagrams of the DEFAMM Cologne/Bonn Demonstrator subsystems as well as the Message Tables are generated automatically on the basis of the Event Trace Diagrams presented in the predecessor document mentioned above. They do not contain any additional information and are only an alternative representation of the event flows with the focus on individual subsystem in each case.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDC71) ANNEX C: Structured SMGCS Information Content (SSIC) Author(s): K. Klein, Ch. Meier Company: DLR Subject: Structured SMGCS Information Content (SSIC) Related Task('s): 1500 Emission Date of Delivery: 09. July 1997 Revision Number: 3.1 Ref./File No. D_ICDC71.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Structured SMGCS Information Content (SSIC) describes the message formats which are exchanged between A-SMGCS subsystems. The separation of the information content from A-SMGCS functionality and connectivity is a main objective. In this way, changes in the distribution of A-SMGCS functionality do not affect the SSIC. SSIC is located in the seventh ISO/OSI layer, it should be used to convert internal data representations from different protocol stacks into each other. Every subsystem shall use SSIC as an intermediate layer between the application itself and communication with the rest of the A-SMGCS. Therefore SSIC can be considered as a recommended high level software interface for all subsystems within A-SMGCS. The definition of such a high level software interface is a prerequisite for all subsystems or work-packages that have to deal with a large number of different subsystems (e.g. SDF, System-Integration or especially Testing). The definition of SSIC reduces drastically the number of necessary conversions between different representations of the same information. SSIC consists of the following four items: • Version: The version consists of a main version - indicating incompatibility with previous

versions - and a release number - indicating that SSIC has been compatibly extended • Data Set Table: The information content is structured hierarchically in data sets. Each data

set consists of a list so called data set members. Data set members can either be fundamental data types or data sets themselves. Data sets are classified logically into groups.

• Code Table: Codes are used for data set members that do only represent a selection from a fixed number of discrete values (e.g. aircraft weight classes). The code table associates these codes with readable text information.

• Invalid Value Table: Some data sets contain optional data set members. For these optional data set members invalid values are reserved in order to distinguish between data set member present and data set member absent.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDD28) APPENDIX D: ASTERIX-S Author(s): D. Godel Company: Dassault Electronique Subject: ASTERIX-S definition Related Task('s): 1500 Emission Date of Delivery: 9. July 1997 Revision Number: 2.8 Ref./File No. D_ICDD28.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document contains the Asterix-S definition which is basically an EUROCONTROL ASTERIX protocol adapted to A-SMGCS applications. With the help of this protocol, data exchange be between • available sensors and the SDF & ID subsystem, • the SDF & ID subsystem and the Situation Assessment subsystem, • the Situation Assessment subsystem and the HMI subsystem, take place. At first, a general presentation of the ASTERIX format is done. Then an adaptation of the SSIC format to the ASTERIX-S format is described with a mapping of the traffic object data set of the SSIC table, the traffic object data set including all data transmitted between the previously enumerated subsystems. The ASTERIX-S messages are structured as follows: • Data Category: Determines the type of the data to be exchanged • Data Block: Defines the data format • Record: A record contains the information of the requested data category • Data Item: This is the smallest unit of information possible. • User Application Profile: The UAP is the mechanism in which the correspondence between

data items and data fields is standardisised for each application making use of the ASTERIX message structure.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDE20) ANNEX E: DLR DEFAMM Messaging Author(s): K. Klein, Ch. Meier Company: DLR Subject: DLR DEFAMM Messaging Related Task('s): 1500 Emission Date of Delivery: 3. December 1996 Revision Number: 2.0 Ref./File No. D_ICDE20.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is one of the Task 1500 annex documents. It contents the DLR DEFAMM Messaging definition, the protocol definition for layers 5-7 of the ISO/OSI model implemented in the Braunschweig demonstrator. The DEFAMM-MSG format is part of the inter process communication (IPC) concept (see document D_RTD_13) which includes Static Connection Management (SCA) as well as the Dynamic Connection Management (DCM). The fundamental concept is based on the asynchronous exchange of messages between subsystems. The messages are of a well defined, uniform structure, with a fixed length header and variable length body. The advantages are:

• The definition of the interfaces between subsystems is reduced to the definition of messages.

• All types of information exchange is covered uniformly: data, commands, subsystem status messages.

• A machine independent data representation is part of the protocol stack. A hardware change is possible without additional effort on the interface.

• DMSG can work together with other communication mechanisms. • DMSG is a non-blocking transfer. • Although the transmission of fully user defined data is permitted in the syntax the data can

be build up from a list of simple information units.


Public AANS _____________________________________________________________________ Demonstrator System Interface Control Document (ICD) (D_ICDL32) ANNEX L: Message Tables for IDL definition Author(s): W. Kailbach Company: Alcatel Air Navigation Systems Subject: Message Tables for IDL definition Related Task('s): 1500 Emission Date of Delivery: 08. Mai 1998 Revision Number: 3.2 Ref./File No. D_ICDL32.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The message tables presented in this document are based on those of D_ICDB30, but with emphasis on which mechanism shall be used for implementation and who is responsible for the interface definition in case of CORBA. Corresponding columns were added to the tables and the references to Use Cases as well as redundant listings of messages were omitted.


Public AANS _____________________________________________________________________

2 WP 2000: DEMO FACILITIES MONITORING (PHASE I)

Title Related

Task Acronym / Filename


Deliverable 1. Mode S System Overview Document T2100 D_MSO_02 D_MSO_02 D_MSO_02 Public 2. DGPS System Overview Document T2100 D_ESO_02 D_ESO_02 D_ESO_02 Public 3. SYLETRACK System Overview Document T2100 D_SSO_11 D_SSO_11 D_SSO_11 Public

4. ASDE / ASDE Extractor System Overview Document T2200 D_RSO_03 D_RSO_03 D_RSO_03 Public

5. E-Scan ASDE System Overview Document T2200 D_ASO_10 D_ASO_10 D_ASO_10 Public

6. 95 GHz Mini Radar System Overview Document T2200 D_MRO_10 D_MRO_10 D_MRO_10 Public

7. Near Range Radar Network (NRN) System Overview Document T2200 D_NSO_11 D_NSO_11 D_NSO_11 Public

8. Sensor Data Processor Architecture Document T2300 D_SDF_23 D_SDF_23 D_SDF_23 Public

9. Situation Assessment & Conflict Handling System Overview Document T2300 D_SDA_02 D_SDA_02 D_SDA_02 Public

10. Phase I & II HMI Architecture Document T2400 D_HSA1&2 D_HSA1&2 D_HSA1&2 Public 11. Phase I Datalink Architecture Document T2500 D_DLA1_3 D_DLA1_3 D_DLA1_3 Public

12. Phase I & II Network Architecture Document T2500 D_NWA_20 D_NWA_20 D_NWA_20 Public

13. Mode S Pretest Report T2100 D_MPR_10 D_MPR_10 D_MPR_10 Public 14. DGPS Pretest Report T2100 D_EPR_10 D_EPR_10 D_EPR_10 Public

15. DGPS Pretest Report, ANNEX A - DGPS Reference Station T2100 D_EPRA10 D_EPRA10 D_EPRA10 Public

16. DGPS Pretest Report, ANNEX B - DGPS Central Station T2100 D_EPRB10 D_EPRB10 D_EPRB10 Public

18. SYLETRACK Pretest Report T2100 D_SPR_10 D_SPR_10 D_SPR_10 Public 19. SYLETRACK Pretest Report – ANNEX A T2100 D_SPRA10 D_SPRA10 Public 20. SMR/Radar Data Interface Pretest Report T2200 D_RPR_10 D_RPR_10 D_RPR_10 Public 21. E-Scan ASDE Pretest Report T2200 D_APR_10 D_APR_10 D_APR_10 Public

23. Near Range Radar Network (NRN) Pretest Report T2200 D_NPR_20 D_NPR_20 D_NPR_20 Public

24. Sensor Data Processor Pretest Report T2300 D_SDP_10 D_SDP_10 D_SDP_10 Public

25. Sensor Data Processor Pretest Report - Braunschweig T2300 D_SDPB20 D_SDPB20 D_SDPB20 Public

26. Phase I & II HMI Pretest Report T2400 D_HPR1_1 D_HPR1_1 D_HPR1_1 Public 27. Phase I Datalink Pretest Report T2500 D_DPR110 D_DPR110 D_DPR110 Public 28. Phase I & II Network Pretest Report T2500 D_NWR_02 D_NWR_02 D_NWR_02 Public 29. FKB Predemo I Test Plan T2600 D_PFP111 D_PFP111 D_PFP111 Public 30. Braunschweig Predemo I Test Plan T2600 D_PBP110 D_PBP110 D_PBP110 Public 31. Bergamo Predemo I Test Plan T2600 D_PMP105 D_PMP105 D_PMP105 Public

32. Phase I Predemonstration and Field Acceptance Test Report T2600 D_PFR110 D_PFR110 D_PFR110 Public

33. Bergamo Predemo I Test Report T2600 D_PMR102 D_PMR102 D_PMR102 Public 34. Braunschweig Predemo I Test Report T2600 D_PBR110 D_PBR110 D_PBR110 Public Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________


Public AANS _____________________________________________________________________ Mode S System Overview (D_MSO_02) Author(s): W. Kailbach, Dr W. Nusser Company: AANS Subject: Task 2100 Overview Document Related Task('s): 2100 Emission Date of Delivery: 16. December 1996 Revision Number: 02 Ref./File No. D_MSO_02.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The DEFAMM Mode S Subsystem is a surveillance element which delivers position information of cooperative targets that are equipped with a Mode S transponder, i.e. aircraft and dedicated ground vehicles (e.g. emergency services). This document gives a detailed description of the Mode S functionality. In contrast to conventional Mode S positioning based on ρ/θ-measurements, a differential multilateration technique is applied. The Mode S system contains several Mode S ground stations having a receiver and signal processing equipment, and a central processing station which combines the received signals to calculate multilateration results. At least three of these ground stations are suitably distributed over the airport surface yielding a two-dimensional position. Furthermore, an identification of targets is performed via the Mode S subnetwork. This is an ICAO-defined network of the Aeronautical Telecommunication Network (ATN) which facilitates the communication between ground subnetworks and avionics subnetworks onboard an aircraft. This document also contains a list of requirements and interface definitions for the airports Cologne/Bonn and Braunschweig.


Public AANS _____________________________________________________________________ DGPS System Overview (D_ESO_02) Author(s): W. Kailbach, Dr W. Nusser Company: AANS Subject: Task 2100 Deliverable Documents Related Task('s): 2100 Emission Date of Delivery: 13. December 1996 Revision Number: 02 Ref./File No. D_ESO_02.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In DEFAMM the Differential Global Positioning System (DGPS) contributes to surveillance as a cooperative sensor system by providing DGPS based target reports from the test vehicles as well as from appropriately equipped aircraft of the regular traffic on the airport surface. It consists of: • one GPS receiver per vehicle and a mobile UHF subnetwork radio • a DGPS reference station to calculate a pseudorange correction for each of the visible

satellites. This information is necessary to achieve the required position accuracy for the GPS receivers on the airport area.

• a DGPS central processing station which determines the position of the target using the pseudorange correction.

The DGPS uses the UHF subnetwork to transmit the position reports and to broadcast the DGPS corrections to the vehicles. For communication with regular aircraft the DEFAMM Mode S subnetwork is used. Additionally, a list of requirements and interface definitions for the DGPS subsystem is given.


Public AANS _____________________________________________________________________ SYLETRACK System Overview (D_SSO_11) Author(s): Luc FAUCHEUR - Claude TSIAMPALIDIS Company: SOFREAVIA - ADP Subject: Syletrack Related Task('s): 2100 Emission Date of Delivery: 27. January 1997 Revision Number: 1.1 Ref./File No. D_SSO_11.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: SYLETRACK is a radio positioning system for vehicles which is used as demonstrator operating at Roissy Charles De Gaulle, Le Bourget and Orly airports. The main functions of SYLETRACK are: • To alert the vehicles drivers in operation on the airport platform when they enter runway

areas. This function prevent inadvertent critical areas incursions. • To provide a central system with the position, speed vector, identifier and activity of any

equipped vehicle at the refresh rate of one second. • After the fusion with other sensors, it allows :

- to present to the controller the labelled positions of ground mobiles. - to alert the controllers when a conflict situation is detected with an aircraft.

• For some vehicles operating in all weather conditions, an additional functionality allows the drivers to get a ground guidance aid, through a on-board visualisation tool.

The SYLETRACK system components consist of : • several beacons on the ground, • a central monitoring station (central receiver & frame synchronisation transmitter), • lightweight transceiver units on-board of the vehicles. Each beacon broadcasts information concerning synchronisation and localisation code. The equipped vehicles receive these information from any beacon and calculate their position by triangulation. The position information is then transmitted by the vehicles to the central receiver (located on the airport).


Public AANS _____________________________________________________________________ ASDE / ASDE Extractor System Overview (D_RSO_03) Author(s): W. Kailbach, Dr W. Nusser Company: AANS Subject: Task 2200 Overview Document Related Task('s): 2200 Emission Date of Delivery: 16 December 1996 Revision Number: 0.3 Ref./File No. D_RSO_03.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The ASDE is the operational radar of the Cologne/Bonn Airport and specifically developed for surveillance of ground airport traffic at all weather and visibility conditions. It is a stand alone system consisting of antenna, transmitter, receiver and its own display unit which is used to display an airport map and the scan converted radar plots. The antenna is installed on the roof of the ATC tower at a height of about 60 m and therefore guarantees the coverage of the DEFAMM testing area. The main characteristics of the ASDE radar are:

Frequency : 9,41 GHz +/- 450 MHz Gain : 38 dB minimum Boresight angle : 0 degr. +/- 2.5 degr. Horizontal Beamwidth : 0.4 degr. +/- 10 % Azimuth Sidelobe level : 27db Peak Elevation Pattern : Inverse Cosec 2 to -10 degr. Range coverage : from 200 meter from radar, to 5000 meter Azimuth coverage : 360 degrees SMR refresh rate : once every 1 sec. Peak power : 15kW nom Average Power : 2.4 W

The RETS is devoted to process the data coming from the ASDE sensor. Its main functions are • to provide a data set for each detected target, with fundamental information about the target. • to correlate with previous datasets in order to get one vector per traffic object (tracking). • to receive airport map data and masked area data from the DEFAMM data base. • to interface with other DEFAMM subsystems, mainly to provide the radar tracks for the

Sensor Data Fusion. Furthermore, this document provides the user requirements and interface definitions for the ASDE/RETS combination.


Public AANS _____________________________________________________________________ E-Scan ASDE System Overview Document (D_ASO_10) Author(s): D. Godel Company: Dassault Electronique Subject: E-Scan ASDE System Overview Document Related Task: 2200 Emission Date of Delivery: 18. December 1996 Revision Number: 1.0 Ref./File No. D_ASO_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The E-Scan ASDE radar is a non-cooperative sensor developed specifically for ground airport traffic at all weather conditions. It consists of • an active phased array antenna with electronic scan. • several solid-state Transmitter/Receiver modules • a fully adaptive digital signal and data processing • digital interface and ASTERIX standard output for the Sensor Data Fusion


Public AANS _____________________________________________________________________ 95 GHz Mini Radar System Overview (D_MRO_10) Author(s): M. Ferri Company: Oerlikon-Contraves S.p.A. Subject: Task 2200 Overview Document Related Task('s): 2200 Emission Date of Delivery: 18. December 1996 Revision Number: 1.0 Ref./File No. D_MRO_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The 95GHz Mini Radar is a non-cooperative sensor developed specifically for ground airport traffic at all weather conditions. Within DEFAMM, this radar was used as a demonstrator system at Bergamo airport. The difference to other sensor systems is the complete new architecture of this radar: Instead of a single sensor which is installed at a central location, an array of small 95GHz radar are distributed over the whole airport area, each of them connected to central processor via FDDI. The advantages of this architecture are a high resolution, a simple installation and an improvement of conflict detection. The main characteristics of the 95GHz Mini Radar radar are the following:

Frequency : 95 GHz Transmitter: 1.2 kW peak power, EIO tube. Antenna: inverse cosec², 0.18° azimuth beamwidth circular polarisation, side lobes level less than 30 dB, dimensions: 1.1 m (W) x 1 m (H) Receiver : logarithmic, non coherent, 60 dB dynamic at input of log receiver; Pulse length: 20 ns; IF Frequency: 1.9 GHz; Frequency agility: None; PRF: 3 ¸ 10 kHz. Scan rate: 60 RPM Range performance: greater than 1500 m in rainy weather condition (16 mm/h); Unambiguous range: > 15 km


Public AANS _____________________________________________________________________ Near Range Radar Network (NRN) System - Overview (D_NSO_11) Author(s): K.Klein, Bethke Company: DLR Subject: NRN Related Task('s): T2200 Emission Date of Delivery: 17. December 1996 Revision Number: 1.0 Ref./File No. D_NSO_11.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Near Range Radar Network (NRN) is a non-cooperative sensor constructed for all weather conditions which is based on a modular structured surveillance. Several distributed modules form a radar network for the surveillance of the ground traffic on the complete airport surface or alternatively, only on defined sections of the airport. A prototype module is integrated within the multisensor arrangement of the DEFAMM phase I at Braunschweig airport. Each module observes a selected area of the airport surface. A module is composed of several radar stations each illuminating a common region of surveillance. This allows an optimal adaptation of the module geometry to minimise disturbances, i.e., less shadowing and multipath effects by buildings within the airport environment. One radar module is concepted for the surveillance of an area of max. 1100x1100 m2. The position of each radar station can be adapted to the given airport topography. Wireless communication between the radar stations allows a placement which is independent of the airport infrastructure. The operation of each module is managed by the main station, which is in direct contact to the central control computer of the radar network via the local FDDI. A simultaneous operation of 10 modules is possible. Beside surveillance and position information, the NRN is able to provide the Sensor Data Fusion with reliable data concerning velocity, classification and heading.


Public AANS _____________________________________________________________________ Sensor Data Processor Architecture Document (D_SDF_23) Author(s): D. GODEL Company: Dassault Electronique Subject: Sensor Data Processor Architecture Related Task('s): WP 2300 Emission Date of Delivery: 10 December 1996 Revision Number: 2.0 Ref./File No. D_SDF_23.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: Because of the complexity of an airport no single sensor is able to meet all requirements for a surveillance system for A-SMGCS. Furthermore, a Controller cannot work efficiently with different systems, providing the surveillance information on different displays. Therefore, a data fusion from all available sensors is necessary in order to give an unambiguous and useable representation at the traffic situation. The goal of a Sensor Data Fusion (SDF) is to improve the knowledge of the actual traffic situation though the combination of different sensors. Within DEFAMM the individual surveillance elements which provide the Sensor Data Fusion with information are: the ASDE extractor, the E-Scan ASDE, SSR Mode-S and DGPS. Additional information comes from the airport databases, the manual tagging from the HMI and the flight planning system. The SDF processing collects all the track information (each track is linked to a target or mobile detected in the airport space ) in order to consolidate the track characteristics like position, speed, heading, size, and to identify the associated target with its call-sign, its SSR code, its registration number, its mode S address or maybe with its arrival time or departure time. Improvements of characteristics and identification is based on the existing correlation between all these data. The SDF output consisting of a consistent traffic situation with unique track IDs will be broadcasted mainly to the Situation Assessment and HMI.


Public AANS _____________________________________________________________________ Situation Assessment & Conflict Handling (D_SDA_02) Author(s): W. Kailbach, Dr W. Nusser Company: AANS Subject: Task 2300 Overview Document Related Task('s): 2300 Emission Date of Delivery: 13. December 1996 Revision Number: 02 Ref./File No. D_SDA_02.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: Within the DEFAMM demonstrator, the objectives of the subsystem "Situation Assessment and Conflict Handling" are • to detect deviations of aircraft and controlled vehicles from the assigned taxiplans • to detect traffic conflicts and to provide conflict solutions in order to prevent collisions and incursions into protected areas. The Situation Assessment and Conflict Handling subsystem receives the system tracks from the "Sensor Data Fusion and Identification" subsystem, containing the surveillance data of the objects (position, velocity, identification, etc.), and the taxi plans from the "Flow Planning" subsystem, containing the planning waypoints. The sum of system tracks and the taxiplans represent the complete actual and planned traffic situation at the airport and therefore they are the basis for the conflict detection and plan deviation detection. The further processing is split in the following steps: • The Situation Assessment characterises all detected objects in such a way, that it is possible

for the conflict detection to reduce the number of objects which are potentially involved in conflicts.

• The Conflict Handling comprises conflict detection and conflict resolution processes as well as processes necessary for the management of data produced by the conflict detection process.

• The Conflict Detection process in DEFAMM is mainly realised as a bubble concept. For each traffic object a warning bubble and an alert bubble is calculated. When two bubbles of different traffic objects overlap, a warning or an alert will be generated.

• The Conflict Management checks whether new conflicts or unsolved old conflicts have been occurred and sends a request to the HMI.

• The Conflict Resolution will immediately activate protection devices and propose a guidance for the controller.

• The plan deviation detection process will check the surveillance data as well as the taxiplans of each planned mobile in order to detect an imminent temporal or spatial plan deviation. If an imminent temporal plan deviation is detected guidance instructions will be created and transmitted to the deviating mobile in order to get it back to the plan. If this is not possible an actual temporal plan deviation is given.


Public AANS _____________________________________________________________________ Phase I & II HMI architecture document (D_HSA1&2)

T. Payan, S. Buck, R. de Laat Company: NLR & AISR Subject: HMI architecture

Author(s):

Related Task('s): 2400 & 3400 Emission Date of Delivery: 17. December 1996 Revision Number: 1.0 Ref./File No. HSA1&2.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start WP1 WP2 WP3 WP4 WP5 WP6 WP7 Table of Contents Summary: The Human Machine Interface (HMI) provides the controller with all information and data he needs for surveillance, guidance, planning and conflict detection of the airport ground traffic. For this purpose two screens are provided: The complete traffic situation is displayed on the main screen. It will contain all moving targets with blips and labels, obstacles, the airport map with all runways, taxiways, aprons and gates so far as relevant for DEFAMM as well as planning and guidance information. Here, all primary information necessary to control the ground traffic is summarised. Furthermore, all information supporting this task indirectly, i.e. flight strip, system status, etc., will be displayed on an additional screen. A detailed list of all the data to be displayed is given in this document. The interaction between the controller and the HMI is achieved by using the traffic situation display for interaction purposes. In most cases the interaction is managed by clicking on those points of the screen, where at that certain moment the focus of attention as well as the focus of the controller’s eye is supposed to be. In the following a brief overview on the controller’s possibilities is given.

• Labelling: The controller can add labels for unidentified aircraft. Furthermore, he/she can change runways, gates, taxiroutes and departure routes assigned for the aircraft.

• Conflicts: In case of a conflict, the labels of the involved objects turn red and the controller must acknowledge the alert.

• Zooming: Each sector of the airport area can be enlarged for a detailed view. • Planning: The HMI displays the planned route of the aircraft on mouseclick. The

controller will then accept the planned route, or he can negotiate and input an own route by various possibilities.

• Guidance: Guidance information on the window will consist of centreline-lights as well as stopbars. The controller is able to view guidance information given by the system and to interact with the lighting segments.


Public AANS _____________________________________________________________________ Phase I Data Link Architecture Document (D_DLA1_3) Author(s): Bertrand Faust Company: NA Subject: Phase I Data Link Architecture Related Task('s): WP 2500 Emission Date of Delivery: 09. December 1996 Revision Number: 3 Ref./File No. D_DLA1_3.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document describes the specifications of the UHF Data Link, UDL 2000, which will be implemented for the SMGCS experiments planned within the framework of the DEFAMM project. Furthermore, all necessary requirements are reviewed The UDL 2000 is designed for two way data communications in the frequency range of 420 Mhz to 470 Mhz . In DEFAMM it shall allow communications between mobile vehicles and the fixed components of an SMGC System. Through a subnetwork, mobiles report their GPS positions to a base sub-system whose main functions are to interface with the SMGC System, to manage the data link operation, and to broadcast messages to the mobiles. The UDL subnetwork consists of a number of mobile radios (MR), of one or more base radios (BR) and one base controller (BC). Each Base Radio (BR) receives the reports of a fraction of the vehicles present on the airport (vehicles in line of sight), and is in charge for those vehicles of transmitting addressed messages forwarded by the SMGCS. All the base radios are interfaced to a controller unit (BC) which centralises the data to be sent on the SMGCS LAN, and distributes the data received from the SMGCS components. A detailed description of the interfaces and the system requirements can be found in the document.


Public AANS _____________________________________________________________________ Phase I and II Network Architecture Document (D_NWA_20) Author(s): W. Kailbach Company: AANS Subject: Task 2500/3500 Deliverable Document Related Task('s): 2500/3500 Emission Date of Delivery: 26. March 1998 Revision Number: 2.0 Ref./File No. D_NWA_20.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is subdivided into the following sections: 1. System and Interface Definition Approach: DEFAMM is decomposed into several

subsystems. Their interface definitions are modelled by so called ‘use cases’. These describe the system operation from the view of users (controller, pilot/driver, technical supervisor) and therefore consider operational aspects. Modelling all relevant use cases (about 50 in DEFAMM) leads to a complete collection of logical messages in the system (event summary diagrams and message tables). The technical implementation of the logical messages is defined in so called Structured SMGCS Interface Content (SSIC). For the OSI reference layers 4 to partly 7 (transport, session, presentation, and partly application) it was agreed to use in general CORBA (ORBIX implementation) combined with TCP for interprocess and intersubsystem communication. For sensor data transmission an ASTERIX-S protocol combined with UDP is used. For the layers 1-3 (physical, datalink and network) standard FDDI and IP protocols will be used according to the FDDI LAN implementation at Cologne/Bonn and Braunschweig Airport.

2. Cologne/Bonn System Architecture: In the main locations, which are the Old Tower Technical Room, the New Tower Technical Room and the Apron Control Room, DEFAMM proprietary FDDI LAN concentrators respectively a switch will be installed, which will be interconnected with a FDDI fibre dual ring. Within the main locations the DEFAMM units will be interconnected in a star configuration with the FDDI concentrators as a central nodes. Other DEFAMM units need to be placed outside of technical rooms, i.e. Mode S ground stations, radio stations, antennae and the E-scan ASDE. Those units are either connected directly to the processing stations if they are located close to the technical rooms, through existing telephone lines or fibre cables for longer distances.

3. Demonstrator Units: This sections gives a detailed description where subsystems are located at Cologne/Bonn Airport and how they are connected to the Local Area Network (LAN).


Public AANS _____________________________________________________________________ Mode S Pretest Report (D_MPR_10) Author(s): Dr. Holger Neufeldt Company: AANS Subject: Mode S Pretest Report Related Task('s): 2100 Emission Date of Delivery: 27. May 1999 Revision Number: 1.0 Ref./File No. d_mpr_10.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The scope of the Mode S Pretest Report is to document the individual pretest activities for the Mode S Subsystem of DEFAMM. The Mode S Pretest Report for DEFAMM starts with a short overview on the Mode S Subsystem (the objectives of the Mode S in DEFAMM and the position of the Mode S subsystem in the DEFAMM context) and then documents the details of the tests. The main objectives of the Mode S subsystem in DEFAMM are: • To detect and identify aircraft and Mode S equipped vehicles by their Mode S signals • To assign a Registration Mark to the mobiles if this can be derived from the Mode S address • To determine the position of the detected mobiles by multilateration • To distribute the identity and position via the ASTERIX interface The Mode S System consists of four receive-only ground stations (MAGS-GSR), one receive-transmit ground station (MAGS-GST) and a central station (MAGS-CS). The following figures show the installed system. The Pretests comprised

• geometrical configuration tests, i.e. line of sight, multilateration geometry, multipath effects

• Factory acceptance tests of ground stations and central station as separate units • Integration tests of ground stations and central station together • Installation tests as final check if the equipment deployed at he selected sites works in the

intended way • Site acceptance tests to verify the Mode S subsystem performance as a whole

The Mode S subsystem passed all tests and was therefore released for technical and operational testing within the DEFAMM system.


Public AANS _____________________________________________________________________ DGPS Pretest Report (D_EPR_10) Author(s): O. Glaser Company: Alcatel Air Navigation Systems Subject: DGPS pretest report Related Task('s): 2100 Emission Date of Delivery: 02. December 1997 Revision Number: 1.0 Ref./File No. D_EPR_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The scope of the DGPS Pretest Report is to document the individual pretest activities for the DGPS Subsystem of DEFAMM. The DGPS Pretest Report for DEFAMM consists of this overview document which recalls the main tasks of the DGPS sensor and two detailed annexes. • the Pretest Report for the DGPS Reference Station (Annex A, D_ERPA10): This test was

performed from 24 November 1997 until 28 November 1997 at the location of ALCATEL Air Navigation Systems in Stuttgart Lorenzstraße, BAU 55. First, a detailed explanation of the initialisation and setting up of the ALCATEL RS 2000 DGPS DR Differential GPS Reference Station with Monitor Receiver is given. Then, the test scenario is described, followed by data recording and evaluation.

• the Pretest Report for the DGPS Central Processing Station (Annex B, D_ERPB10). Again, the tests have been conducted by the Air Navigation Systems. Special emphasis was put on the accuracy of the coordinate transformation module and the processing software.


Public AANS _____________________________________________________________________ Syletrack Pretest Report (SPR) (D_SPR_10) Author(s): Tsiampalidis, Faucheur, Descourvières Company: Sofréavia - AdP Subject: Syletrack - Evaluation report Related Task('s): 2100 Date: 30. April 1998 Revision Number: 1.0 Ref./File No. D_SPR_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document presents the output of the evaluation of the Syletrack system installed in Orly. The test evaluation has been performed to obtain the necessary information about the performance and the deficiency of the system. In order to assess the system performances, the following parameters were analysed: • Radio coverage and position accuracy • Response time • Reliability and Availability • Integrity • Capacity • Electro magnetic compatibility In conclusion, the Syletrack System is almost compliant with the initial requirements (e.g. required accuracy in 95% of the time rather than in 99%). The response time of the system worse than a radar but is acceptable for the present use.


Public AANS _____________________________________________________________________ ASDE Extractor Pretest Report (D_RPR_10) Author(s): M. D’Andrea Company: AANS Subject: Pretest Reports Related Task('s): 2200 Emission Date of Delivery: 23. March 1999 Revision Number: 1.0 Ref./File No. D_RPR_10.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document reports the factory pretests activities for the ASDE Extractor which is used in the DEFAMM system at Cologne/Bonn Airport. When connected to a Surface Movement Radar, the ASDE Extractor provides surveillance data like tracks and plots of fixed and moving targets. These data can be further processed by other subsystems. The factory test equipment consists of a Test Bench, a scan converter, a control and monitoring workstation and a message recorder. The test were performed according to the System Requirements defined for this subsystem. For each test, a short test description, the test procedure and the test result is given. The following features were tested: • Track Data Output Format: • Track Data Reference Coordinate • Track Continuity • Track Load • Track Speed Accuracy • Build in test equipment In conclusion, the ASDE Extractor fullfills nearly all system requirements. The verification of typical accuracy measurements that requires an real airport field (resolution, position accuracy) were delayed until the first side acceptance tests.


Public AANS _____________________________________________________________________ E-SCAN ASDE Pretest Report (D_APR_10) Author(s): Philippe Serre, Christian Prévot Company: DE Subject: E-SCAN ASDE Pretest Report Related Task('s): 2200 Emission Date of Delivery: 24. March 1999 Revision Number: 1.0 Ref./File No. D_APR_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The purpose of this document is to summarise the pretest results for the RAPSODIE Electronic Scan (E-Scan) ASDE radar installed as part of the Cologne/Bonn DEFAMM demonstrator. Installed in December 1997, the E-Scan radar was submitted to performance tests from January to March 1998. Several software updates, essentially enhancing tracking performance, have been implemented until October, date of the beginning of DEFAMM operational tests. Special emphasis is put on two factors: • Test of the E-Scan radar interfaces. Particular the connections to the radar data transmission

channel, ASTERIX and CORBA interfaces and the LAN modem for remote access was checked.

• Test of the E-Scan radar performance parameter. Here, the technical aspects of the radar like frequency stability, range accuracy false alarm rate and probability of detection was tested.


Public AANS _____________________________________________________________________ Near-Range Radar Network (NRN) Pretest Report (D_NPR_20) Author(s): Karl-Heinz Bethke Company: DLR Subject: NRN Related Task('s): T2200 Emission Date of Delivery: 07. May 1999 Revision Number: 0.2 Ref./File No. D_NPR_20.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Near-range Radar Network (NRN) is a non-co-operative sensor based on primary radar technique. Within the framework of DEFAMM a prototype module was installed at Braunschweig Airport. It comprises four local distributed low power radars each equipped with non-rotating sector antennas permanently observing a common part of the airport surface. The major system components and the functionality of this prototype module are described in the DEFAMM document D_NSO_04. The NRN had to be integrated within the sensor data fusion (SDF) of the experimental A-SMGCS of the DLR. This document focuses on to the pre-test phase of the NRN which comprises the verification of characteristic features. It is reported on the installation and the test of NRN specific functions. Within this context, adaptation work was necessary in order to optimise NRN functionality. The existing antenna set, for instance, was extended and the diagrams of the new antennas had to be measured and the required characteristics to be verified. One major aspect was the connection of the NRN to the SDF. The process of detection of a traffic event, the transmission to the SDF and the registration had to proceed in quasi real-time. The principle of data transmission using SSIC data structures had already been tested via internet between Oberpfaffenhofen and Braunschweig. All pre-tests could be finished in time before the main DEFAMM test campaign started at Braunschweig Airport.


Public AANS _____________________________________________________________________ Sensor Data Fusion Pretest Report (D_SDP_10) Author(s): Didier GODEL Company: DE Subject: SENSOR DATA FUSION Pretest Report Related Task('s): 2300 Emission Date of Delivery: 22. March 1999 Revision Number: 1.0 Ref./File No. D_SDP_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document provides the pretest results for the Sensor Data Fusion installed as part of the Cologne/Bonn DEFAMM demonstrator. The ASTERIX interface checking has been performed during a Factory Acceptance Tests via a connection to the E-Scan sensor unit. The CORBA interfaces have been validated during integration on site with the other subsystems of the DEFAMM demonstrator. Furthermore, the Sensor Data Fusion has been tested using a scenario recorded at Orly airport where three different E-Scan sensor locations were simulated. In Cologne/Bonn airport, on site adjustments were needed to fulfil specific features of the airport and to take into account the specifications of all the sensors involved in the DEFAMM demonstrator. Specific emphasis was put on fusion accuracy, identification capabilities and maintainability.


Public AANS _____________________________________________________________________ Sensor Data Processor Pretest Report (Braunschweig) (D_SDPB20) Author(s): Ch. Meier Company: DLR Subject: Factory Acceptance Test Related Task('s): 2300 Emission Date of Delivery: 03. March 1999 Revision Number: 1.0 Ref./File No. D_SDPB20.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document describes the factory acceptance test of the Sensor Data Fusion (SDF) developed by DLR for the Braunschweig Predemo I Phase. Since no overview document is provided for this system, its architecture will briefly mentioned in the following. The SDF is a pure software product, running on a IBM compatible PC with the operating system Windows NT Server. The SDF is connected with the rest of the A-SMGCS (sensors, data base etc.) by a FDDI network. Interfacing between the SDF processes and the sensors takes place by asynchronous, non-blocking exchange of binary messages via the TCP/IP protocol. The SDF consists of the following processes: 1. SDF Kernel: Tracking of the traffic objects using the multisensor data as well as massive a

priori knowledge. Filtering of kinematic data as well as features of the traffic objects over time. Estimating the relationships of the traffic objects to the airport topology.

2. SDF Identification: Uses the estimated feature vector and possible traffic object identities stored in a data base to identify the traffic objects.

3. SDF Control Display: Shows the estimated traffic situation with additional data fusion information to allow the monitoring of the data fusion processes by an engineer.

A Factory Acceptance test was performed in order to check quality of the fusion algorithm, latency times and stability.


Public AANS _____________________________________________________________________ Phase I & II HMI Pretest Report (D_HPR1_1) Author(s): T. Payan, R. D. Hoetmar Company: NLR, AISR Subject: Phase I & II HMI Pretest report Related Task('s): 2400 & 3400 Emission Date of Delivery: 29. January 1999 Revision Number: 1.0 Ref./File No. D_HPR1_1.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document aims to describe the methodology used in order to test in factory the Human Machine Interface (HMI) subsystem before its installation at Köln/Bonn Airport. The objective of these tests was to ease the integration with other DEFAMM subsystems at the airport and so to reduce the time necessary for it in order to focus on functional and operational aspects. The DEFAMM HMI has been tested at the NLR and ISR. The results demonstrate that the functioning is conform the specifications that were written down in the HSA document. The deviations from it are minor. Due to the extensive communication testing, no problems are expected with the stability of the HMI server. The methodology used during the pre-test period, consisting of several testing phases and developing skeletons for other DEFAMM subsystems, allowed the detection and correction of communication errors. Because of these pre-tests, the integration period can be small and will consist of: � replacing these skeletons with the real subsystems in order to test with real data, � tuning communication aspects, � focusing on functional aspects, � slightly adapting user interface. After the integration period and the functional tests, the system will then be ready for the operational tests.


Public AANS _____________________________________________________________________ Phase I Datalink Pretest Report (D_DPR110) Author(s): B. Hurley (O. Glaser) Company: NA (AANS) Subject: Phase I Datalink Pretest Report Related Task('s): 2500 Emission Date of Delivery: 25. May 1999 Revision Number: 1.0 Ref./File No. D_DPR110.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The scope of the Phase I Datalink Pretest Report is to document the individual pretest activities for the Phase I Datalink Subsystem of DEFAMM. The Phase I Datalink Pretest Report for DEFAMM starts with a short overview on the Phase I Datalink Subsystem (the objectives of the Phase I Datalink in DEFAMM and the position of the Phase I Datalink subsystem in the DEFAMM context) and is then documenting the details of the tests. The main objectives of the Phase I Datalink subsystem in DEFAMM are: • to distribute the DGPS correction information coming via the DGPS central station from the

DGPS reference station once per second via radio transmission to all mobiles. • to transmit the position reports from all equipped mobiles and forward them once per second

to the DGPS central station. Different types of tests have been performed at National Avionics premises in Dublin to check the correct function of the Phase I VHF Subnetwork. Positions from moving and non-moving objects have been measured. The position reports were displayed by a supporting program on the maintenance screen and were recorded for evaluation. The DGPS correction information was correctly distributed every second in the RTCA format. The position accuracy of the reported positions was sufficient and the interaction with the other system interfaces like DGPS central processing Station and Technical System Control worked correctly.


Public AANS _____________________________________________________________________ Phase I and II Network Pretest Report (D_NWR_02) Author(s): W. Kailbach Company: Alcatel Air Navigation Systems GmbH Subject: Task 2500/3500 Deliverable Document Related Task('s): 2500/3500 Emission Date of Delivery: 8. Mai 1998 Revision Number: 0.2 Ref./File No. D_NWR_02.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In this document, the pretests for the DEFAMM Local Area Network (LAN) are described. The tests decompose into factory acceptance tests which took place at Alcatel Air Navigation in Stuttgart and site acceptance tests at Cologne/Bonn Airport. Both tests are structured in the following way: 1. Short description of the test configuration 2. FDDI Fibre Ring Test 3. FDDI TP-Ports Test 4. Ethernet Ports Test 5. ‘Ping’ Test 6. File Transfer Test and Interface Test The tests proof the full functionality of the DEFAMM LAN at Cologne/Bonn.


Public AANS _____________________________________________________________________ FKB Predemo I Test Plan (D_PFP111) Author(s): K. Klein, P. Zenz, Test Team Company: DLR, AANS Subject: Functional Testing Related Task('s): 2600 Emission Date of Delivery: 15. December 1997 Revision Number: 1.1 Ref./File No. D_PFP111.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The aim of the tests described in this document is to show the basic functionality of the surveillance part of the DEFAMM system as far as installed at Cologne/Bonn Airport. The paper is derived from the main testing document ‘General Test Description’ (D_DTD_10) with some detailed test procedure descriptions. The results of these predemo tests will be laid down in the Document ‘Phase I Predemonstration and Field Acceptance Test Report’ (D_PFR1xx.doc). To execute the predemonstation tests at Cologne/Bonn Airport, all the Phase I Subsystems which are not tested at other sites are integrated. The Phase I Subsystems consists of

• Cooperative Sensor Subsystems − D-GPS subsystem (NA/AANS)

• Non-Cooperative Sensor Subsystems − Radar Data Interface (AANS) − E-SCAN ASDE (DE)

• Sensor Data Processing − Sensor Data Fusion (DE) − Situation Assessment (AANS)

• Phase I Communication Subsystem − Radio Data Link System (NA) − Real Time Data Network (AANS)

• Phase I HMI (AISR/NLR) The predemonstation Tests Phase I consist of general tests:

• Interface tests in order to check the data format and data contents between subsystems • Interoperability tests in order to check the correct data sequence and timing

Furthermore a part of the Functional Tests will be performed in a reduced extent:


Public AANS _____________________________________________________________________ Braunschweig Predemo I Test Plan (D_PBP110) Author(s): Ch. Meier, Kh. Hurrass, B. Stieler, P. Zenz, K.

Klein Company: DLR Subject: Demonstration Test Activity Related Task('s): 2600 Emission Date of Delivery: 17. December 1997 Revision Number: 1.0 Ref./File No. D_PBP110.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: All tests to be carried out at Braunschweig Airport to fulfil the tasks defined in WP2600 are described. These include field acceptance tests for subsystems having gone through an adaptation development within this project. The results of the Predemo I phase contribute to the recommendation of a prototype system (153/UR 692) and will be documented in ‘Braunschweig Predemo I Test Report’ (D_PBR110.doc). The subsystems for acceptance testing and predemonstration are:

1. Mode S supplied by AANS, 2. DGPS including VHF data link (DLR’s GP&C system) in replacement for the one

supplied by AANS and NA at FKB, 3. NRN supplied by DLR, 4. Sensor data fusion supplied by DLR, 5. Situation Assessment & Conflict Handling (SA) supplied by AANS.

Each sensor mentioned under item 1 to 3 will go through a separate factory acceptance test before it is integrated together with the Sensor Data Fusion (SDF) subsystem. The Predemonstration Tests Phase I consist of general tests: • Interface tests to check the data format and data contents between subsystems • Interoperability tests to check the correct data sequence and timing • Test Procedure BFU.1: Surveillance of movement area and Identification of authorised cars • Test Procedure BFU.2 Surveillance coverage in aerodrome and vicinity areas • Test Procedure BFU.3: Monitoring of Separation between mobiles • Test Procedure BFU.4: Detection of intrusion into prohibited areas (Runway incursion)


Public AANS _____________________________________________________________________ Bergamo Predemo I Test Plan (D_PMP105) Author(s): Mauro Ferri Company: OCI/Alenia Subject: Demonstration Test Activity Related Task('s): 2600 Emission Date of Delivery: 7 May 1998 Revision Number: 5 Ref./File No.: D_PMP105.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The testing approach criteria to evaluate the 95 GHz miniradar demo-sensor is to organise demonstration tests by taking into account a reference system to obtain referenced data in relation to which the original data can be analysed. For the set-up activities, fine weather conditions are required in order to rightly calibrate the mini-radar sensor system. During the tests, several weather conditions will be taken into account (fog, heavy rain, etc.) in order to validate the system performances in the widest scenarios. The functional test program consists of: • Probability of false alarm • Minimum/maximum distance coverage test • Detection Probability • Resolution test • Play-back procedure Appropriate forms will be filled during the execution of each test in order to keep track log all main data concerning the test procedure implemented.


Public AANS _____________________________________________________________________ Phase I Predemonstration and Field Acceptance Test Report (D_PFR110) Author(s): K. Klein, P. Zenz, K-H. Hurrass, O. Glaser Company: DLR, AANS Subject: Field Acceptance Test Related Task('s): 2600 Emission Date of Delivery: 27.05.1999 Revision Number: 1.0 Ref./File No. D_PFR110.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The report describes the functional tests performed at FKB during the Predemonstration I Field Acceptance Tests. The aim of these tests was to show the basic functionality of the surveillance part of the DEFAMM system as far as installed at Koeln/Bonn airport. The tests were carried out as described in the guidelines given in the ‘FKB Predemo I Test Plan’ (D_PFP110.DOC).

The following subsystems were tested: • Co-operative Sensor Subsystems • Non Co-operative Sensor Subsystems • Sensor Data Processing • Phase I Communication Subsystem • Phase I HMI (AISR/NLR)

At a first step the interfaces and software functions were tested. The next part of trials concerned the following functional tests:

FU.1: Surveillance of movement area and identification of authorised vehicles FU.2: Surveillance coverage in aerodrome and vicinity areas FU.6: Control of aircraft runway and taxiway incursion FU.7: Control of vehicle intrusion into prohibited areas FU.9: Control of separation between two vehicles

All main requirements are fulfilled. Only some minor parts of the system should be improved. The following remarks concern some functional tests:

Surveillance and Identification (FU 1): The requirements are mainly met. Improvements are necessary with respect to the determination of size classes and the detection and tracking of non co-operative objects.

Surveillance Coverage (Fu 2): The coverage was sufficient and included the vicinity of the Koeln/Bonn airport. The coverage of the Mode S sensor should be expanded in future systems. But due to the data fusion coverage problems were removed.

Control of Separation (FU 9): This test was in principle successful. Additional investigations are necessary with respect to this function. In order to reduce the overall reaction time which has to be taken into account by the system, pilots and drivers should be automatically informed about potential conflicts.


Public AANS _____________________________________________________________________ Bergamo Pretest I Test Report (D_PMR102) Author(s): Mauro Ferri Company: OCI Subject: BERGAMO PREDEMO I TEST REPORT

DEFAMM Testing Related Task('s): 2600 Emission Date of Delivery: 19. March 1999 Revision Number: 2.0 Ref./File No. D_PMR102.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is dedicated to the results of the tests performed in DEFAMM project with a small 95 GHz airport surface surveillance radar. These tests took place in the period between 15th June and 7th August 1998 in Bergamo “Orio Al Serio” airport. Their goal was to demonstrate all capabilities deriving from using the millimetre wave band in airport surveillance radar applications with particular reference to easy installation, instrument dimensions, high detection probability small objects and very high discrimination performance. The description of the procedures used to execute the tests in Bergamo airport is reported in Bergamo Predemo I Test Plan document (D_PMP105.DOC). The following amount of tests is provided: • More than 250 hours of continuous surveillance • More than 5 Gbyte of radar data recorded (about 20 hours of registration) • Many radar airport images • More than 12 type of aircraft characterised (fixed and rotary wings) • More than 10 type of typical airport vehicles characterised • Several kind of airport targets characterised, including man and baggage The tests were performed with respect to coverage, false alarm test, minimum and maximum distance coverage, detection probability and resolution. The following conclusions can be drawn: • Coverage was limited due to the low height of the antenna. The optimal height should be

25m. • Detection performance is very good: The sensor is even able to distinguish small objects like

men or baggage. • Robustness against bad weather conditions.


Public AANS _____________________________________________________________________ Braunschweig Predemo I Test Report (D_PBR110) Author(s): P. Zenz, K. Klein, C. Meier Company: DLR Subject: DEFAMM Testing Related Task('s): 2600 Emission Date of Delivery: 14. August 1998 Revision Number: 1.0 Ref./File No. D_PBR110.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Pre-Demonstration phase I of DEFAMM is focussed on the surveillance and monitoring part of the A-SMGCS design. The test site Braunschweig is used to check the complete chain from different sensors to the test recording. The detailed description of the various test scenarios can be found in the document D_PBP110. The following list gives a brief summary of the test report: • The Interfaces to other subsystems (Mode S, NRN, GP&C Base Station, SDF, Situation

Assessment and the AVES system) were tested successfully. • Interoperability Test: The format of the data messages (ASTERIX, CORBA) were ok.

However, the time delay of the Sensor Data Fusion shows time delays up to 13s corresponding to old GP&C transponder installations.

• The Field Tests show, that the SDF is processing the sensor data reliably and in real-time and

that Outliners and False Alarms are recognised in most cases. Furthermore, Data of NRN and GP&C are successfully associated and fused. Objects are immediately identified if identifiable.


Public AANS _____________________________________________________________________

3 WP 3000 : DEMO FACILITIES PLANNING & GUIDANCE (PHASE II)

Title Related



Deliverable 1. Orly Demonstrator Overview Document T3100 D_PSO_10 D_PSO_10 D_PSO_10 Public 2. Planning System Overview Document T3100 D_PSD_10 D_PSD_10 D_PSD_10 Public

3. Guidance Processor Architecture Document T3200 D_GPA D_GPA D_GPA Public

4. Ground Based Guidance Means System Overview Document T3300 D_GSO_01 D_GSO_01 D_GSO_01 Public

5. Phase I & II HMI Architecture Document - Appendix T3400 DAHSA1 DAHSA1 Public

6. Phase II Datalink Architecture Document T3500 D_DLA210 D_DLA210 D_DLA210 Public

7. Phase I & II Network Architecture Document T3500 D_NWA_20 D_NWA_20 D_NWA_20 Public

8. Pilot/Driver Assistant System Overview Document T3600 D_DSO_10 D_DSO_10 D_DSO_10 Public

9. Orly Predemo II Test Report T3700 D_POR210 D_POR210 D_POR210 Public 10. Orly Planning Functional Pretest Report T3100 D_PPRO10 D_PPRO10 D_PPRO10 Public 11. Guidance Processor Pretest Report T3200 D_GPR_20 D_GPR_20 D_GPR_20 Public

12. Ground Based Guidance Means Pretest Report T3300 D_GSP_10 D_GSP_10 D_GSP_10 Public

Phase I & II HMI Pretest Report T3400 D_HPR1_1 D_HPR1_1 D_HPR1_1 Public 13. Phase II Datalink Pretest Report T3500 D_DPR210 D_DPR210 D_DPR2 Public 14. Pilot/Driver Assistant Pretest Report T3600 D_DSP_10 D_DSP_10 D_DSP_10 Public 15. FKB Predemo II Test Plan T3700 D_PFP210 D_PFP210 D_PFP210 Public 16. Orly Predemo II Test Plan T3700 D_POP210 D_POP210 D_POP210 Public 17. Braunschweig Predemo II Test Plan T3700 D_PBP210 D_PBP210 D_PBP210 Public

18. Phase II Predemonstration and Field Acceptance Test Report T3700 D_PFR210 D_PFR210 D_PFR210 Public

Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ ORLY Demonstrator Overview Document (D_PSO_10) Author(s): L. Faucheur / T. Payan Company: A ISR / SOF / ADP Subject: Orly demonstrator Related Task('s): 3100 Emission Date of Delivery: 03. July 1997 Revision Number: 1.0 Ref./File No. D_PSO_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary:

The purpose of the Orly project is to demonstrate the benefit that could be produced by implementing a limited short term planning function to handle the traffic on the airport platform in a more efficient way. In the following a brief overview on the demonstrators subsystems and architecture will be given.

System’s architecture: The Orly demonstrator will be connected to the existing Airport system thanks to an Ethernet network and then will be able to receive general airport data (planned arrival aircraft sequence, traffic situation for mobiles, ...). New infrastructure will be added on the airport, for instance, new specialised lines dedicated to the communication between the demonstrator and the ground signs located on the platform. The hardware configuration consists of a SUN Ultra 1 workstation and four ground signs.

• Display and interaction: The display covers the runway 07, three exits and the location of the ground signs.

This document gives an overview of the Orly demonstrator functions identified in the D_DRD_19 document defined in WP 1200. It is also dedicated to explain the limited planning function that will be developed for this demonstrator.

Subsystem functions:

• Topology management function: The aim of the topology management function is first to provide a segmentation of the airport and second to identify continuously the exact location of the mobile.

• Planning function: The planning function is in charge of predicting the runway exit and the route to the gate.

• Expert Database: Only one database is installed, which stores general and specific data for each function.

• Situation Assessment: The situation assessment function is in charge of receiving the positions of aircraft and vehicles and transmitting them to HMI, planning function and ground signs management function in order to be treated.


Public AANS _____________________________________________________________________ Planning System Overview Document, CGN and BS Version (D_PSD_10) Author(s): Institut für Flugführung Company: DLR Subject: Flow Planning for Cologne/Bonn and

Braunschweig Related Task('s): 3100 Emission Date of Delivery: 26. June 1997 Revision Number: 1.0 Ref./File No. D_PSD_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In this document, the functionality and realisation of the DEFAMM subsystem ‘Flow Planning’ is described. Starting with the DEFAMM user and system requirements a basic definition for the Ground Movement Planning is given. According to this definition, the Planning System can be termed as a event driven, recurrent planning with sliding horizon. However, an event can also be initiated by the Flow-Planning system itself. The heart of the Ground Movement Planning is a complex domain model that is adequate to • the topography of the airport (respectively the DEFAMM area),

• the Taxi Planning Unit (TPU) which actually calculates the time windows and routes for the aircraft. This process is quite time consuming, therefore a SUN SPARC ULTRA 2 and a SUN SPARCstation 5 is used to cope with this task.

• the operational rules for taxi operations under consideration of the runway configuration, • the aircraft performance parameter, • the human (common) assessment of plan quality The Flow Planning Subsystem is realised with two main elements: • the Data Base Management System (DBMS) which holds all static information describing

the airport topology, and operational rules as well as dynamic information like current system state, traffic situation etc. This Data Base works as SQL server on a Pentium PC.


Public AANS _____________________________________________________________________ Guidance Processor Architecture Document (GPA) (D_GPA) Author(s): Victor J. Fernandez Company: INTA Subject: Guidance Processor Architecture Related Task('s): 3200 Emission Date of Delivery: 25. June 1997 Revision Number: 0.1 Ref./File No. D_GPA.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7

The development of the Guidance Processor Software for the DEFAMM demonstrator at Cologne/Bonn Airport is described. This document contains the Guidance Software Top Level design which is subdivided into three main blocks related to

Inbound Traffic - Manual Guidance Inbound Traffic - Automated Guidance

Outbound Traffic - Automated Guidance

Summary:

• Operational Guidance Sequences with the guidance flows for the four main operations.

Outbound Traffic - Manual Guidance

• Architecture Diagrams with the process decomposition including: Inputs and outputs Structures Functionality’s of the bottom down processes.

• Data identifiers with the identifiers of the Cologne/Bonn topology, Clearances and Guidance Commands


Public AANS _____________________________________________________________________ Ground Based Guidance Means System Overview (D_GSO_01) Author(s): R.Mohrdieck Company: Daimler-Benz Aerospace Subject: Ground Based Guidance Means Related Task('s): 3300 Emission Date of Delivery: 27. November 1997 Revision Number: 1.1 Ref./File No. D_GSO_01.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document gives an overview over the structure of the existing Control- and Monitoring System of the Airfield Ground Lighting System at Cologne/Bonn Airport, where parts of the taxiway lighting system will be used in DEFAMM as Ground Based Guidance Means. The principle technical approach of merging both, the operational system and the DEFAMM extensions, is described.

To use the taxiway centreline lights of the taxiways for DEFAMM as ground based guidance means it is necessary to split the lighting into small segments. Since Cologne/Bonn Airport has no individual switchable lights available, the existing system was analysed for the smallest units, which can be switched. As this cannot be done from the high level control, the internal control software has to be modified for additional interfaces to provide low level switching and allow outbound control of the system by DEFAMM guidance processor.


Public AANS _____________________________________________________________________ Phase II Data Link Architecture Document (D_DLA210) Author(s): Bertrand Faust/Stephen Kernan/Brian HurleyCompany: NA Subject: Phase II Data Link Architecture Related Task('s): WP 3500 Emission Date of Delivery: 03. July 1997 Revision Number: 1 Ref./File No. D_DLA210.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In the framework of the DEFAMM SMGCS experiments, the data link shall allow communications between mobile vehicles and the fixed components of an SMGC System connected to an FDDI LAN. Through a subnetwork, mobile vehicles report their GPS positions to a fixed subsystem whose main functions are to interface with the SMGC System, to manage the data link operation, and to broadcast messages to the mobiles. This fixed subsystem consists of one or more STDMA base stations and one base controller, whose minimum role is to interface the base station to a FDDI LAN. However, the number of base stations depends on the topology of the airport. The subnetwork supplies the SMGC System with one position report of each of the vehicles once per second. The position report is tagged with the time of measurement. The subnetwork allows the broadcasting of the DGPS correction message and the transmission of addressed messages from the fixed subsystem to a given vehicle. Each mobile transponder contains a GPS receiver and is interfaced with a Pilot/Driver Assistant by means of a single-board computer System Requirements like Radio Characteristics, Data Link capacity and network operations are discussed. Furthermore, external requirements and logical messages are defined. Finally, the requirements for the system components are presented.


Public AANS _____________________________________________________________________ Phase I and II Network Architecture Document (D_NWA_20) Author(s): W. Kailbach Company: AANS Subject: Task 2500/3500 Deliverable Document Related Task('s): 2500/3500 Emission Date of Delivery: 03. July 1997 Revision Number: 1.0 Ref./File No. D_NWA_20.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is an overview document of the Cologne/Bonn DEFAMM LAN. It is an updated assembly of the WP 2500 system definition document. Only a few modifications were necessary: 1. The DGPS reference stations and the related central station are now interconnected with a

RS-232 serial interface. 2. The Flow Planning Processing now consists of a dual computer instead of two workstations

and a personal computer. It is connected to the FDDI concentrator with two UTP-RJ-45 cables.

3. Instead of a VHF, a UHF subnetwork is used as radio link. One of the two UHF Base Radios (UHF BR) is still located in the Old Tower Technical Room, the other one in a different location on the airport. The external BR is connected to the BC via a telephone line.

4. It was not possible to install the DGPS antenna on the top of the Apron Control Tower. 5. The access to the DFS ZKSD is now possible via an Ethernet connection between a

DEFAMM FDDI LAN Concentrator/Switch and the VAN Hub in the Tower Building Technical Room.


Public AANS _____________________________________________________________________ Pilot/Driver Assistant System Overview Document (D_DSO_10) Author(s): R. Espin Company: DRA Subject: Pilot/Driver Assistant System Overview

Document Related Task('s): 3600 Emission Date of Delivery: 07. July 1997 Revision Number: 1.0 Ref./File No. D_DSO_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: As part of the DEFAMM collaborative project DRA Bedford has been contracted to provide the Pilot/Driver taxiing assistant systems. These systems are intended to provide guidance to pilots and drivers as they manoeuvre on active airfields. Three types of assistant systems are intended to be developed by DRA Bedford: • A Driver system is installed and operates in a suitably equipped trials/airport vehicle. This

system will be provided with differentially corrected GPS position via a VHF STDMA system.

• A Hybrid pilot/driver system which is identical to the driver system, except that the position is provided by the same type of GNSS receiver used in the pilot system.

• A Pilot system which is intended for use onboard aircraft operated by the DRA. This system will use a GNSS aircraft receiver provided with differential corrections over a MODE S datalink.

This document provides a description and specification of each of the assistant systems. The current approach to system design is also described.


Public AANS _____________________________________________________________________ Orly Pre-Demo II Test Report (D_POR210) Author(s): Luc Faucheur – Luc Deneuchatel Company: Sofreavia – Alcatel ISR - AdP Subject: Pre Demonstration II Tests Activity Related Task('s): 3700 Emission Date of Delivery: 18. September 1998 Revision Number: 1.0 Ref./File No. D_POR210.RTF Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document presents the results of the DEFAMM predemo testing in Orly as far as the use of the whole DEFAMM Orly integrated demonstrator in an operational environment (real traffic) is concerned. The purpose of the Orly test is to demonstrate the benefit that could be produced by implementing a limited short term planning function to handle the traffic on the airport platform in a more efficient way. The system is connected for demonstration purpose to some signs along the main taxiways to facilitate the expedition of the traffic when arriving at a very complex crossing of taxiways. In a nutshell, the following conclusions and recommendations can be assumed: • The use of a planning function implemented with a significant level of autonomy with regard

to the controller task shall be subjected to a in depth validation in order to offer a very good level of confidence from a controller point of view. The implementation of this kind of planning tool which should automate and ease the controller work, would require in depth changes in the control procedures in order to share the responsibilities between the controllers.

• The performance of a planning function is directly related to the coherence of the routing rules used in the airports. The implementation of such a function is all the more difficult that the standard rules are not carefully respected.

• A routing system dealing with arrivals shall be able to manage the occurrence of busy gates, For the demonstrator installed in Orly (limited to a specific complex crossing), the achieved figures are the following : • Planning of runway exit 88% of success • Planning of taxiway from crossing 74% of success • Re-planning ratio 20% • Controller validation ratio 87% • not followed routes ratio 14%


Public AANS _____________________________________________________________________ Orly Planning Functional Pre-test Report (D_PPRO10) Author(s): Thierry PAYAN - Luc FAUCHEUR Company: Alcatel ISR - Sofreavia - AdP Subject: Functional Testing : Orly Planning system Related Task('s): 3100 Emission Date of Delivery: 18. September 1998 Revision Number: 1.0 Ref./File No. D_PPRO10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: As part of the WP3100, the present document aims to describe the results of the functional tests of the Orly planning system and its interfaces. A requisite for the understanding of the present document is the “ Orly Demonstrator Overview Document ” (D_PSO_10) as it describes the detailed system architecture.

The test procedures which concern the Orly planning subsystem and its interface are the following :

TEST PROCEDURE OF 1 Communication interfaces with planning system TEST PROCEDURE OF 2 Traffic model simulation TEST PROCEDURE OF 3 Plan deviation TEST PROCEDURE OF 9 Contents and Display of graphical information TEST PROCEDURE OF 10 Ground signs management

The detailed test results can be found in the document. Instead a brief conclusion about the experience at the test side will be given. Of course, during such kind of project, with connection to external systems, a lot of technical problems occurred. But, the risk has been minimised thanks to the choice of the developing and testing methods which avoided a lot of problems during integration phase at the airport. Even if this method needs more developing effort for recording and playing back tools, the benefit comes later because :

• less moving to the airport are necessary,

• factory tests can be performed when and as often we want,

• factory tests can be performed with realistic data.

Therefore, this method can be recommended for this kind of projects where a lot of data comes from external systems, operational constraints exist and also where the test site is located far from the developing companies.


Public AANS _____________________________________________________________________ Guidance Processor SW Pretest Report (GPR) (D_GPR_20) Author(s): Felix Sanchez, Victor J. Fernandez Company: INTA Subject: Guidance Processor Pretest Report Related Task('s): 3200 Emission Date of Delivery: 24. March 1999 Revision Number: 0.1 Ref./File No. D_GPR_20.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The purpose of this document is to present the summary of the pretest results for the DEFAMM Guidance Processor. Special emphasis is put on the interface and functional tests. The following test scenarios are recorded for later evaluation: Functional Tests: FT1 Change of operational mode from mode D to mode C FT2 Change of operational mode from mode C to mode D FT3 Start taxiing procedure for an outbound aircraft FT4 Guidance for an outbound aircraft FT5 Guidance for an inbound aircraft FT6 Change from mode C to mode D meanwhile a mobile is being guided. FT7 Modification of an assigned route before guidance has begin FT8 Modification of an assigned route once guidance has begin FT9 Guidance of two mobiles following the same route FT10 Guidance of two mobiles with an stop of the first one FT11 Guidance of three mobiles with an stop of the first one FT12 Guidance of a mobile thought its route with a second mobile situated on the route FT13 Guidance of two mobiles following intersecting routes FT14 Guidance of a mobile over an intersection with a controller order over a stopbars

of the intersection. Interface Tests: GST.1 : Initialisation

GST.2 : Taxiplan Management GST.3 : Transmit Clearances GST.4 : CWP Commands GST.5 : SMAC Commands


Public AANS _____________________________________________________________________ Ground Based Guidance Means Pretest Report (D_GSP_10) Author(s): R. Mohrdieck, J. Brettschneider Company: DASA (Honeywell) Subject: Ground Based Guidance Means Pretest

Report Related Task('s): 3300 Emission Date of Delivery: 24. March 1999 Revision Number: 1.0 Ref./File No. D_GSP_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document describes the pretests performed for the subsystem Ground Based Guidance Means which provides the software interface to the existing airfield lighting system of Cologne/Bonn Airport to the DEFAMM Guidance processor. The specific tasks of the Ground Based Guidance Means can be read from document D_GSO_01. • Interface Tests: The CORBA interface of the Ground Based Guidance Means to other

DEFAMM subsystem was tested successfully. A special interface was developed for the commissioning phase of the subsystem, which allowed the manipulation of light and system status. This interface was used during the pretest phase to simulate lighting system information as an test aid for the methods.

• Performance Parameter: Ground Based Guidance Means is to be considered as ‘not critical’

in respect to timing and data throughput parameters. Main factor was the AFL system reaction time to change the light status. Typical response times are 0.5 seconds, so all other delays resulting from data transmission over the DEFAMM network and command processing in the subsystem can be neglected. Reliability and availability have been nearly 100% after repair of an spurious error on the workstation’s mainboard.

As a conclusion, the pretests have demonstrated, that an existing airfield lighting system can be effectively integrated in a modern ASMGCS system with several different subsystem by using standards like CORBA. Doing this way, the lights can be made available to the ASMGCS as a guidance mean with a high availability.


Public AANS _____________________________________________________________________ Phase II Datalink Pretest Report (D_DPR210) Author(s): B. Hurley (O. Glaser) Company: NA (ANS) Subject: Phase II Datalink Pretest Report Related Task('s): 3500 Emission Date of Delivery: 22. May 1999 Revision Number: 1.0 Ref./File No. D_DPR210.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The scope of the Phase II Datalink Pretest Report is to document the individual pretest activities for the Phase II Datalink Subsystem of DEFAMM. The Phase II Datalink Pretest Report for DEFAMM starts with a short overview on the Phase II Datalink Subsystem (the objectives of the Phase II Datalink in DEFAMM and the position of the Phase II Datalink subsystem in the DEFAMM context) and is then documenting the details of the tests. The main objectives of the Phase II Datalink subsystem in DEFAMM are, to perform in addition to the Phase I Datalink tasks the following: • receive from the Pilot Driver Assistance System requests and acknowledgements and to

forward these messages to the Guidance Processing Subsystem • receive clearances, instructions and taxi-plans from the Guidance Processing Subsystem and

forward them to the Pilot Driver Assistance System Tow types of tests have been performed at Naitonal Avionics premises in Dublin. In the first test the Pilot Driver Assistance System was connected via a modem with the VHF sub-network in the second test the PDAS was brought to Dublin to connect it directly to the system. The test showed that requests and acknowledgements can be received by the VHF Datalink Subsystem from the Pilot Driver Assistance System. These messages are then forwarded correctly to the Guidance Processing Subsystem. Clearances, instructions and taxi-plans received by the VHF datalink Subsystem from the Guidance Processing Subsystem are forwarded to the Pilot Driver Assistance System. The received taxi-plans are visualised on the PDAS screen as routes with way-points and related and timeslot information.


Public AANS _____________________________________________________________________ Pilot/Driver Assistance System Pretest Report (D_DSP_10) Author(s): M. Downs Company: DRA Subject: Pilot/Driver Assistance System Pretest Report Related Task('s): 3600 Emission Date of Delivery: 24. March 1999 Revision Number: 1.0 Ref./File No. D_DSP_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Pilot Driver Assistant is a generic term used to describe two functionally similar systems. One of these is intended for use in a test vehicle for use by drivers on the airfield, the other cockpit based for use by pilots in order to assist in taxiing the aircraft. The formats of the displays used are similar and the differences are primarily in the hardware used for symbol generation. A detailed overview is given in the D_DSO_10 document. Test were performed in order to check the interface to other subsystems and to find the performance parameter of the Assistance unit. As conclusion it can be said, that the system performed very well in surveillance mode with the display being robust and providing accurate details of own vehicle and other vehicle positions. In extended control and guidance modes limitations in the DEFAMM system were identified preventing the full functionality to be assessed. Recording of ‘real world’ data allowed multiple replays of data to check consistency and accuracy of operation.


Public AANS _____________________________________________________________________ FKB Predemo II Test Plan (D_PFP220) Author(s): B. Stieler, K. Klein, P. Zenz, Test Team Company: DLR, AANS Subject: Functional Testing Related Task('s): 3700 Emission Date of Delivery: 12. August 1998 Revision Number: 1.0 Ref./File No. D_PFP220.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document describes the testing of the following DEFAMM subsystems after they have been integrated at Cologne/Bonn Airport:

• the Cooperative Sensor Mode S (AANS) • the Flow Planning (DLR) including

− the Data Base Management System (DLR), − the Flight Plan Interface plus Gate Management Interface and − the CORBA Interface

• the Guidance Subsystems consisting of − Guidance processor (INTA) − Guidance Means Central Station (DASA) − Pilot Driver Assistance System (DERA)

• the Extended Communication Subsystem consisting of − Radio Data Link System (NA) − Real Time Data Network (AANS)

• the Extended HMI (AISR/NLR) • the test equipment

• the technical system control • the test data recording/storage and • the AVES.

The predemonstration tests are structured as follows:

• Interface Tests: Here, the correct data format and data contents between the various subsystems are checked.

• Interoperability Tests: Check of the correct data timing and data handling • Test Procedure FU3: Taxi Plan generation and presentation • Test Procedure FU4: Guidance with ground based means • Test Procedure FU5: Guidance with “on board guidance means” • Test Procedure FU8: Control of plan deviation

The Test Procedures FU3 – FU8 and their results are described in the document D_PFR2xx.doc. _____________________________________________________________________ 22.10.02;DEFAMM_firap5.doc Task 7100 Page 65 of 89

Public AANS _____________________________________________________________________ Orly Predemo II Test Plan (D_POP210) Author(s): Luc FAUCHEUR - Joël MOYAUX Company: Sofreavia Subject: Demonstration Tests Activity Related Task('s): 3700 Emission Date of Delivery: 11. December 1997 Revision Number: 1.0 Ref./File No. D_POP210.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document presents the detailed test plan which will be applied for the DEFAMM predemo testing at Orly Airport. A general overview of the DEFAMM testing activity is presented in the "General Test Document" (D_DTD_10) where the specific approach for Orly Airport is described. Here, only test concerning the framework of the WP 3700 are described. The functional tests of the system are described in the following documents: • WP 2100 : Syletrack pretest report (D_SPR_10. doc), • WP 3100 : Orly Planning system pretest report (D_PPRO10. ), Therefore, the test procedures described in this document concern the use of the whole DEFAMM Orly integrated demonstrator in operational environment. These tests will involve a specific controller dedicated to the DEFAMM HMI in parallel to the operational controller, so these tests cannot be called operational test in the DEFAMM sense. The applied test procedures covers: • Predictions validity • Quantitative traffic expedition efficiency • Qualitative traffic expedition efficiency and operational interest (user feed-back)


Public AANS _____________________________________________________________________ Braunschweig Predemo II Test Plan (D_PBP210) Author(s): B. Stieler, K. Klein Company: DLR Subject: Functional Testing Related Task('s): 3700 Emission Date of Delivery: 25. May 1999 Revision Number: 1.0 Ref./File No. D_PBP210.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The aim of the tests described in this document is to show the basic functionality of the DEFAMM’s flow planning system as far as installed at Braunschweig Airport. The results of these predemo II tests will be laid down in the document ‘Phase II Predemonstration and Field Acceptance Test Report’ (D_PFR). During the Functional Tests in the Predemo II Phase at Braunschweig Airport, the Flow Planning developed by DLR is in the focus of interest. It is the core of the DEFAMM System Architecture and includes • the Planning (PL), • the Data Base Management System (DBMS), • the DFS plus FKB Interfaces and • the CORBA Interface For each of the tests the aim of the test and the test conditions are described. The description of the test conditions comprises the test set-up and the necessary equipment, the test scenario, the involved persons and the test sequence and expected time duration of the test. These descriptions are followed by the form-sheets of the test reports concerning this functional test. This form-sheet contains a checklist for requirements to be evaluated on-line and optionally also off-line.


Public AANS _____________________________________________________________________ Phase II Predemonstration and Field Acceptance Test Document (D_PFR210) Author(s): H-P. Zenz, K-H. Hurrass, K. Klein, O. Glaser Company: DLR, AANS Subject: DEFAMM Testing Related Task('s): 3700 Emission Date of Delivery: 27. May 1999 Revision Number: 1.0 Ref./File No. D_PFR210.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The report describes the field acceptance tests of DEFAMM (functional tests) which were focussed on the complete system function of the A-SMGCS design. The test site Koeln/Bonn was used to check the complete chain from different sensors to the controller HMI and the guidance means. The tests were carried out as described in the guidelines given in the ‘FKB Predemo II Test Plan’ (D_APD10.DOC).

All DEFAMM subsystems for the following tasks were involved in the following tests.

FU. 1: Surveillance of movement area and identification of authorised mobiles FU. 3: Taxi Plans Generation and Presentation FU. 4: Guidance with Ground Based Guidance Means FU. 5: Guidance with On-Board Guidance Means FU. 8: Control of Plan Deviations.

It was possible to demonstrate that all planned functions in principle were working. Problems arose mainly due to bad reliability of some components of the system. But these shortcomings can be solved. The following remarks concern some tests:

Surveillance and Identification (Fu 1): The off-line evaluation showed that this test was successful. In particular the position accuracy is well below the required value of 10 m.

Taxi Plan Generation and Presentation (Fu 3): It was possible to demonstrate the required functions. But the planning system needs better integration with ATC- and Airport systems. The user interaction for the planning function needs further investigation (role of the controller and the system).

Ground Based Guidance (Fu 4): For the ground based guidance centre line lights were used which were switched according the generated taxi plans. More investigations are necessary in order to find optimal solutions.

On-Board Guidance Means (Fu 5): It was shown that such guidance means can improve the operations on an airport. The procedures for giving clearances and acknowledgements should be improved. The interface for pilots and drivers should also be revised.


Public AANS _____________________________________________________________________

4 WP 4000 : REALISATION

Title Related



Deliverable 1. Implementation Plan Document T4100 D_IPD_10 D_IPD_10 D_IPD_10 Public

2. Test Site Specific Equipment Description Document T4200 D_TSD_10 D_TSD_10 D_TSD_10 Public

3. Functional Test Plan Document T4400 D_APD_10 D_APD_10 D_APD_10 Public

4. Köln/Bonn Field Test Acceptance Document T4400 D_FAD_10 D_FAD_10 D_FAD_10 Public

5. The Airport Topology T4400 D_TOP_03 D_TOP_03 D_TOP_03 Public Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ Implementation Plan Document Koeln/Bonn (D_IPD_10) Author(s): W. Kailbach O. Glaser Company: ANS Subject: Implementation Plan Related Task('s): 4100 Emission Date of Delivery: 25. May 1999 Revision Number: 1.0 Ref./File No. D_IPD_10.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The scope of the Implementation Plan Document Koeln/Bonn is to give a plan for the physical implementation of the DEFAMM equipment in Koeln/Bonn. The Implementation of the A-SMGCS functions in Koeln/Bonn is performed in two phases. Phase I concentrates on the equipment needed for the Surveillance function and the Human machine interface (HMI) for situation presentation. Phase II complements the Phase I functions by Planning and Guidance as well as by additional Control and HMI functions. The equipment needed for the two phases is described and the plan for the installation in two phases is presented. The installation covers indoor ant outdoor installations. The equipment to be installed at different location on the basis of site survey is described and the responsibility of the individual partner for of the installation details is fixed. It is described how the installation will be organised in a time sequential order according to the project plan


Public AANS _____________________________________________________________________ Test Site Specific Equipment Description Document (D_TSD_10) Author(s): K. Klein, W. Kailbach Company: DLR, AANS Subject: DEFAMM Testing Related Task('s): 4200 Emission Date of Delivery: 13. July 1998 Revision Number: 1.0 Ref./File No. D_TSD_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is dedicated to the specific test installation used in the DEFAMM project at two sites (Braunschweig and Cologne/Bonn). It is part of the test documents set covering the concept, the procedures and later on the results as well as a separate document (D_TED_10) covering the test equipment in general. These deliverables give an overview on the tools to help the understanding of testing in DEFAMM.

Specific installation at Cologne/Bonn airport concerning Communication Systems are • LAN Fibres • Modem Links to DFS equipment

In addition temporarily a Bintec Ethernet/ISDN-S0-Router is installed in the Old Tower Technical Room. This router is connected to the DEFAMM-FDDI-LAN via the FDDI/Ethernet switch. It allows remote dial-up links to the DEFAMM subsystems for remote diagnosis/maintenance and also file transfers. Test-PCs are also connected to the DEFAMM FDDI-LAN via the FDDI/Ethernet switch temporarily. These are used for network tests and also for logging/recording of test data on PC media (Magneto-Optic Discs). Furthermore, the sensor- and VHF subnetwork subsystems require site specific installations.

The DEFAMM installation at Braunschweig airport is based on the previous DLR infrastructure. This facility has been outlined to enable A-SMGCS surveillance and control equipment integration and test. The installation consist of six sensor shelters which are equipped with power supply and various sensor systems plus their associated control electronics. An optical fibre data network on the basis of Fibre Distributed Data Interface (FDDI) connects each of the shelters on the airport and each control and demonstration room. The whole network can be divided into: • the peripheral network (Braunschweig Airfield), • the medium network (Inhouse), • the central network (Inhouse for Display and Planning).

While the peripheral and medium network has to be designed as high speed data networks (e.g. FDDI or ATM) the requirements for the central network layer are less stringent and can be realised as an Ethernet


Public AANS _____________________________________________________________________ Functional Test Plan (D_APD_10) Author(s): K. Klein, P. Zenz, O. Glaser, A. Grimaldi,

Test Team Company: DLR, AANS Subject: DEFAMM Testing Related Task('s): 4400 Emission Date of Delivery: 07. April 1998 Revision Number: 1.0 Ref./File No. D_APD_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The aim of the functional tests listed below is to show that DEFAMM performs the functions as defined in the system requirements. For this purpose there have been defined nine functional test procedures in the „General Test Document“ D_DTD_10.DOC. Hereby, the first tests concerning the surveillance function are the basic ones. The availability of reliable surveillance data serves the generation of taxi plans and the related guidance of aircraft. Finally, based on guidance information and on knowledge of movement rules, the deviation from released plans can be detected by control functions. FU. 1: Surveillance of movement area and Identification of authorised mobiles FU. 2: Surveillance Coverage in aerodrome and vicinity areas FU. 3: Taxi Plans Generation and Presentation FU. 4: Guidance with Ground Based Guidance Means FU. 5: Guidance with On-Board Guidance Means FU. 6: Control of aircraft Runway and Restricted Area Incursions FU. 7: Control of vehicle Intrusions into Sensitive Areas FU. 8: Control of Plan Deviations FU. 9: Control of Separation between two mobiles For each of the tests the aim of the test and the test conditions are described. The description of the test conditions comprises the test set-up and the necessary equipment, the test scenario, the involved persons and the test sequence and expected time duration of the test. During the tests, data and events are recorded for off-line evaluation (see WP 6000). The test description ends with a list of system requirements which shall be proven by means of this test. The system requirements are taken from the document D_DTDA10.DOC. The DEFAMM functional tests were performed with two especially equipped test vehicles, the AVES vehicle of DLR and the DRA test vehicle. In addition, several vehicles of the Cologne/Bonn Airport, equipped with DGPS for DEFAMM can be used for the functional tests


Public AANS _____________________________________________________________________ The Airport Topology (D_TOP_03) Author(s): D. Böhme, Ch. Meier, K. Klein Company: DLR Subject: Common ASMGCS Topology Principles and

DEFAMM Implementation Related Task('s): 1500, 2300, 3100 Emission Date of Delivery: 18. May 1999 Revision Number: 0.3 Ref./File No. D_TOP_03.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: A topological model is needed to define the set of all routes of an vehicle or aircraft on the Airport which are both • in accordance with all operational rules and • in accordance with the technical parameters of aircraft, e.g. the minimum radius of a turn.

The often applied method to model a topology by using a graph is also applied in DEFAMM: Usually a topology is modelled by a graph Tn = (N, L), whereby N = {n1, n2, ...nR} is the set of nodes and L={l1, l2, ...,lS), li = (n., n.) is the set of links. The graph may be directed and/or evaluated additionally. Furthermore it might be that links have to be interpreted differently. For example, links connecting one node ni with an other node nj describe a planned movement from one certain location to another certain location, whereas every link l.=(ni, ni) describes the possibility of a planned hold of the object. The problem of irregular routes can be solved by introducing a more complex graph T*=(N,L,M), where M is the set of meta links that codes for every link the possible (allowed) successors. Since the topological model should be used to define routes and plans which are due to the operational rules, nodes as well as all real links that connect different nodes must refer to the topographical elements like runways, taxiways, junctions (crossing) and gates. Every of these elements covers a certain area (or a point). However, in general topological nodes are not identical with these areas. For DEFAMM it was agreed • to define exactly one topological node for each junction or crossing of taxiways or runways; • to define exactly one topological node for each switchable lightning element; • to define exactly one topological node for a stop bar; • to define additional topological nodes for parking positions (gates) and for a refinement of the

planning model, • to conjoin to each topological node a certain topographical point with well defined Cartesian

co-ordinates. These well defined topographical points will be used to address topological nodes belonging to a predefined route or a calculated plan. The topological data as well as the topographical data will be stored in a Data Base Management System (DBMS) for consistent and easy access by all subsystems within the DEFAMM system.


Public AANS _____________________________________________________________________

5 WP 5000: DEMONSTRATION TESTS

Title Related



Deliverable 1. General Test Document T5100 D_DTD_10 D_DTD_10 D_DTD_10 Public

2. General Test Document, ANNEX A - System Requirement Description T5100 D_DTDA10 D_DTDA10 Public

3. General Test Document, ANNEX B - User Requirements Description T5100 D_DTDB10 D_DTDB10 Public

4. Operational Test Description Document T5200 D_DPD_11 D_DPD_11 D_DPD_11 Public

5. The Complex Operational Test Procedure T5200 D_COP_11 D_COP_11 D_COP_11 Public

6. Test Equipment Description Document T5300 D_TED_10 D_TED_10 D_TED_10 Public 7. Demonstration Test Report T5400 D_DTR_10 D_DTR_10 D_DTR_10 Public 8. Test Handbook T5400 D_TEST02 D_TEST02 D_TEST02 Public 9. Test Handbuch T5400 F_TEST02 F_TEST02 Public Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ General Test Document (D_DTD_10) Author(s): O. Glaser, A. Grimaldi, K. Klein, B. Stieler

(Editors), Test Team Company: AANS, DLR Subject: Demonstration Test Activity Related Task('s): 2600, 3700, 4400, 5100, 5200 Emission Date of Delivery: 18. May 1999 Revision Number: 1.0 Ref./File No. D_DTD_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The basis for DEFAMM testing is the System and User Requirements worked out in the WP 1000. Starting from the Requirements the test procedures will be defined. Recordings will be made and evaluated on-line or off-line to obtain quantitative or qualitative information to prove that the requirements are met. DEFAMM testing is done in several steps. Therefore the test procedures description, the results and the tools to be used are splitted into several documents. The structure of the test procedures are explained in chapter 2 of the present document. The relevant test parameters like Probability of Detection, Position Accuracy, update rate, etc. are described in chapter 3. Chapter 4 of the present document gives an overview on the test conditions and the test procedures for the main testing activities at Koeln/Bonn. The detailed descriptions will be laid down in the adequate test plans. Finally in Chapter 5 descriptions of the predemonstration tests at the different European airports can be found.


Public AANS _____________________________________________________________________ Operational Test Description (D_DPD_11) Author(s): S. Buck, O. Glaser, A. Grimaldi, J. Heinz, K.

Klein (Editors), Test Team Company: AANS, DFS, DLR, NLR Subject: DEFAMM Demonstration Tests Related Task('s): 5200 Emission Date of Delivery: 06. April 1998 Revision Number: 1.1 Ref./File No. D_DPD_11.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: Aim of the operational tests is to find out the advantages in safety and efficiency of the DEFAMM system with respect to systems actually utilised for ground movement surveillance. For this purpose, operational tests will be performed constantly comparing controllers/pilots reactions using DEFAMM and NO-DEFAMM systems. This document is describing the DEFAMM demonstration tests which are focused on the operational aspects which will be demonstrated at Cologne/Bonn airport. Similar to the functional tests, the operational tests are also subdivided into nine sections: OP. 1: Surveillance of movement area and Labelling of authorised mobiles OP. 2: Taxi Plans Generation and Presentation OP. 3: Guidance with Ground Based Guidance Means OP. 4: Guidance with On-Board Guidance Means OP. 5: Guidance with Ground – and On-Board Guidance Means OP. 6: Guidance for route changes OP. 7: Detection of runway incursions OP. 8: Control of vehicle intrusion into prohibited areas OP. 9: Conflict Detection and Resolution OP. 10: Control of separation between two mobiles OP.11: Routing under dense traffic conditions OP.12: Routing and destination changes on controller working position

For each test, the test procedure with test conditions and the test evaluation are presented. The first ones describe the aim of the test, the expected test time duration, the necessary instrumentation, the test set-up and the test sequence. The second one presents information which must be added each time the test is performed. Date and time, weather conditions, traffic conditions, participants names, indication of areas interested by the test, additional test set up if applicable. For each test procedure, when necessary, an airport map is presented with the indication of the movement of the mobiles on it.


Public AANS _____________________________________________________________________ The Complex Operational Test Procedure (D_COP_11) Author(s): S. Buck, J. Heinz, K. Klein (Editor) Company: NLR, DFS, DLR Subject: Operational Tests Related Task('s): 5000 Emission Date of Delivery: 07. April 1998 Revision Number: 1.1 Ref./File No. D_COP_11.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This DEFAMM document represents an extract from the Operational Test Procedures Description (D_DPD_11.DOC) and contains the complex operational test. In real operations a lot of different situations may occur. A demonstrator like DEFAMM can only highlight a certain number of traffic constellations. To point out the purpose of an A-SMGCS a complex traffic situation will be helpful. So, the final demonstration tests combines several unexpected events to be handled by the controller, the pilot and the system. The complex operational procedure is a combination of the 12 single operational procedures. They have been combined in order to show the benefit of DEFAMM in one single operational run. Due to the length of this run (about 90 minutes), it might be possible, that other events (technical, operational, meteorological etc.) might interrupt the execution of the whole procedure. For this reason the point of time to execute the complex operational procedure has to be chosen very carefully.


Public AANS _____________________________________________________________________ Test Equipment Description Document (D_TED_10) Author(s): K. Klein (Editor), Test Team Company: AANS, DLR, DRA, SOF Subject: DEFAMM Testing Related Task('s): 2600, 3700, 4400, 5000 Emission Date of Delivery: 13. July 1998 Revision Number: 1.0 Ref./File No. D_TED_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: This document is dedicated to the test equipment used in the DEFAMM project at different sites. It gives an overview on the tools installed at the airports and provides a better understanding of the testing in DEFAMM. In the following, the test equipment according to the different provider are listed. A detailed description can be found in this document. AANS Test equipment: • Technical System Control • Data Recording Storage DLR Test equipment: • AVES Testing Tools • AVES Ground System/Mobile System DERA Test equipment: • Test vehicle • Test Aircraft Orly Test equipment: • Real Traffic Environment • SYLETRACK vehicles • Interview


Public AANS _____________________________________________________________________ Demonstration Test Report (D_DTR_10) Author(s): P. Zenz, K. Klein, K. H. Hurrass, O. Glaser Company: DLR, AANS Subject: DEFAMM Demonstration Tests Related Task('s): 5400 Emission Date of Delivery: 15. May 1999 Revision Number: 1.0 Ref./File No. D_DTR_10.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The system design is described in the documents of work package 1000 whereas the test equipment can be found in D_TED_10.doc and D_TSD_10.doc. The tests are carried out according the planned test procedures D_DPD_10.doc. All DEFAMM Subystems were involved in the following operational tests at Koeln/Bonn. OP.1:Surveillance of movement area and Labelling of authorised mobiles OP.2: Taxi plans generation and presentation OP.3: Guidance with ground based means (switchable lights) OP.4: Guidance with on board guidance means OP.5: Guidance with ground and on-board guidance means OP.6: Guidance for route changes OP.7: Detection of runway incursion OP.8: Control of vehicle intrusion into prohibited areas OP.9: Conflict detection and resolution OP.10: Control of separation between two mobiles OP.11: Routing under dense traffic conditions OP.12: Routing and destination changes on controller working position From the first evaluations of the operational tests it could be demonstrated that in principle all defined requirements can be fulfilled with the implemented system. During several runs for specific operational tests not all requirement could be tested with success. Therefore repetitions of the trials were necessary.


Public AANS _____________________________________________________________________ Test Handbook (D_TEST02) Author(s): O. Glaser, J. Heinz, K. Klein, K. Schinzel, P.

Zenz Company: AANS, DFS, DLR, FKB Subject: Functional and Operational Testing at FKB Related Task('s): 5400 Emission Date of Delivery: 02. December 1997 Revision Number: 0.2 Ref./File No. D_TEST02.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The intention of this document is to assist every person involved in the DEFAMM testing at the Cologne/Bonn Airport to be able to do the necessary work under safe and optimised conditions. The fundamental items for the DEFAMM tests are: 1. All DEFAMM work and tests at the airport have to be performed in such a way that neither

persons nor material is damaged, injured or safety of air traffic is impaired. The adequate laws and the airport, aircraft safety regulations have strictly to be met. Everybody of the test crew must take care to avoid any dangerous situations.

2. The DEFAMM tests will take place during normal traffic operations at the airport. Therefore all tests have to be performed in such a way that the impact to the commercial traffic will be minimised.

3. In case of appearance of an emergency situation, indicated by the tower controller or observed by the Staff, the manoeuvring area (runways and taxiways) has to be vacated immediately, disregarding all clearances or instructions received before

4. Every person working with the DEFAMM tests at the airport must be checked by the standard security procedure of the airport.

Furthermore, the personnel to perform the various test scenarios are listed and their behaviour during the tests are defined. A global time schedule for the FKB tests is provided.


Public AANS _____________________________________________________________________

6 WP 6000: EVALUATION

Title Task Acronym /

Filename Go to Shortdescr. Load File Type of

Deliverable 1. Evaluation Report T6100 D_EVR_10 D_EVR_10 D_EVR_10 Public 2. Improvement Assessment Report T6200 D_IAR_04 D_IAR_04 D_IAR_04 Public 3. Recommendations Document T6300 D_FRD_04 D_FRD_04 D_FDR_04 Public 4. A-SMGCS Prototype Overview Document T6400 D_POD_10 D_POD_10 D_POD_10 Public Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ Evaluation Report - Evaluation of Demo System (D_EVR_10) Author(s): O. Glaser(editor), Dr. R. Schroll (AANS),

K.Klein (DLR), S. Buck (NLR), L. Faucheur (SOF), M. Ferri (OCI)

Company: AANS Subject: Evaluation Report Related Task('s): 6100 Emission Date of Delivery: 20. May 1999 Revision Number: 1.0 Ref./File No. D_EVR_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The Evaluation Report provides a concise description of the evaluation of the demonstration tests performed at the four DEFAMM demonstration sites Cologne/Bonn, Orly, Braunschweig and Bergamo. Firstly, the reader will find a brief description of the methodology that forms the basis of the DEFAMM functional and operational testing and evaluation. The evaluation then starts with the assessment of the demonstration tests at Cologne/Bonn Airport. In the first subparagraph the functional tests are documented, particularly which of the system requirements have been checked during each of the tests. This is combined with a set of qualitative evaluation recommendations for technical enhancements related to each of the tests, in order to present the DEFAMM experience. The next subparagraph then describes in detail the numerical evaluation of the surveillance performance as a result of extensive numerical evaluation of recorded data. The last subparagraph gives an overview on the evaluation of the operational tests, the checked user requirements and the acceptance or the procedures by controllers, pilots and drivers are mentioned. This chapter is followed by a synopsis of the Orly evaluation report. There the possible movement expedition in complex crossing situations by means of a short term planning tool combined with switchable signs was demonstrated. The evaluations of the Braunschweig demonstration tests comes next. Here, a new combination of sensors, the Near Range Radar Network (NRN) and the DGPS together with a Sensor Data Fusion (SDF) was used. Then, the performance results of the 95 GHz Mini Radar are presented. Finally, an elaborate review with conclusions and recommendations for the different test sides are given.


Public AANS _____________________________________________________________________ Improvement assessment report of safety/efficiency (D_IAR_04) Author(s): S. Buck, R. Verkaik Company: National Aerospace Laboratory (NLR) Subject: Evaluation Related Task('s): 6200 Emission Date of Delivery: 23 March 1999 Revision Number: 0.1 Ref./File No. D_IAR.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: In DEFAMM a couple of ASMGCM functions (e.g. planning, routing, conflict warning) were tested and procedures were applied in an operational setting. The current document assesses the impact of those procedures on safety and efficiency. The first part of the document evaluates questionnaires given to controllers and pilots concerning their overall impression of the DEFAMM system and describes open interviews with pilots. The second part of the current document contains an analysis of each single operational test — plus the Complex Operational Procedure — with respect to safety and efficiency. In a nutshell, the most striking results: • Identification and warning features were highly appreciated by the controllers. Going

through their comments it becomes evident that the reason lies in the fact that positive identification and warning features can be implemented without disturbing their current working habits.

• Voice communication is experienced as quite vital, instantaneous, and valid, even if data on certain aircraft accidents might prove the opposite.

• Planning features were not accepted. Time and effort is needed to agree with the system on a common plan. Today only a fraction of that time is needed by the controller to provide the aircraft with a new plan.

• The guidance features were highly appreciated by the pilots. Whether ground based or onboard guidance, these features seem to support the pilots enormously. Future developments cannot ignore the value of such elements.


Public AANS _____________________________________________________________________ Recommendations on optimised A-SMGCS functions and procedures (D_FRD_04) Author(s): S. Buck, R. Verkaik Company: National Aerospace Laboratory (NLR) Subject: Evaluation Related Task('s): 6300 Emission Date of Delivery: 29 March 1999 Revision Number: 0.4 Ref./File No. D_FRD_04.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP7 WP1 WP2 WP3 WP4 WP5 WP6 Summary: This document provides recommendations which are based on the conclusions from the DEFAMM demonstration at Cologne/Bonn. It focuses on the functions and procedures of A-SMGCS, and discusses the position of the controllers with respect to the functions and procedures investigated in DEFAMM. The aim of the document is to provide decision makers of future A-SMGCS systems with information on potential improvements concerning functions and procedures.

The document is subdivided in three parts: 1. The perspective from which recommendations are given 2. Recommendations on functions and procedures 3. Recommendations related to operational tests.

The essential conclusion can be summarised as follows: The controller has organised his work and has defined and/or identified the tasks he has to do and how he has to execute them. This is called the mental working model. There exists three types of functions, which more or less fit into the controllers’ mental working model. The first type deals with functions which form a backup for functions the controller is already executing (e.g. warning functions). They will easily adapted to the mental model and therefore accepted. The second type form new elements in the model, but are very helpful to use. They will be accepted very easily as well. The third type of functions require completely new working habits and are hardly accepted by the controller. From this background it becomes obvious that the success of a tool is dependent on the ease with which the function can be implemented into the mental working model of the controller. One solution would be to invent only functions which can be easily implemented. But each mental model has its limits and the point will easily be reached where no further improvement will be possible with the current mental model. An alternative solution would be to slowly change and expand the controller's mental model. A third solution would be to change the surrounding effects, e.g. the regulations under which the controller works. In the end probably a combination of all three possibilities will have to be applied.

It is further recommended to execute research in both operational and simulated environments. Simulated environments make a valid training and assessment of new functions and procedures possible; physiological measurements of workload can also be quite easily executed.


Public AANS _____________________________________________________________________ A-SMGCS Prototype Overview Document (D_POD_10) Author(s): W. Kailbach, O. Glaser Company: AANS Subject: Prototype Overview Document Related Task('s): 6400 Emission Date of Delivery: 31. May 1999 Revision Number: 01.0 Ref./File No. D_POD_10.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP7 WP6 Summary: The intention of this WP 6400 document is to give proposals for an A-SMGCS prototype considering the experiences made in the DEFAMM project with respect to technical and operational issues. The prototype definition comprises basically the same scope of functions as the DEFAMM demonstrator but takes also into account features beyond the DEFAMM functionality as noted in the Recommendations Document (D_FRD_04.DOC, Task 6300). The main functions of the prototype system shall be the same as in DEFAMM. They consist of the four basic functions Surveillance, Control, Routing/Planning and Guidance and the support functions, the Human Machine Interface Function and the Management and Communication functions. The main features beyond the scope of DEFAMM concern the new subsystem Operational System Control as part of the Management Function, which is responsible to administer all proceedings in a configuration of multiple control units. Furthermore the subsystem Conflict Handling shall be enhanced by conflict resolution advice and related interactions, which was not part of DEFAMM. Guidelines for the prototype subsystems related to these main functions are described in the document, based on the experience in DEFAMM. Furthermore the relations of the prototype to external systems are described. These are the external Airport Surveillance Radar ASR as external sensor, the Flight Plan Information Systems with Departure and Arrival Co-ordination systems of the ATC provider and the Gate Management and related systems of the Airport Authority.


Public AANS _____________________________________________________________________

7 WP 7000: MANAGEMENT

Title Task Acronym /

Filename Go to Shortdescr. Load File Type of

Deliverable D_FIR_P5 D_COR_10

1. Final Report T7100 D_FIR_P5 Public D_FIR_P5 2. Coordination Report T7200 D_COR_10 Public D_COR_10 Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7


Public AANS _____________________________________________________________________ Final Report–Volume 1 (D_FIR_P5) Author(s): F. Monzel Company: AANS Subject: WP 7000 Final Report Related Task('s): 7100 Emission Date of Delivery: 22. September 1997 Version Number: 0.1 Ref./File No. D_FIR_P5.DOC Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The DEFAMM final report consists of two volumes. This first volume describes the essentials of the project; the second volume contains summaries of all public DEFAMM papers. Volume I is dedicated to all parties interested on A-SMGCS definition, development, implementation and usage and provides related background information in the introduction. The engineering methodology successfully applied in DEFAMM is outlined to motivate future programs to follow consequent development and reliable evaluation procedures. A central part of this volume is the description of the functional architecture developed in DEFAMM. It can serve as connecting link between user, decision-maker and developer to discuss a common understanding of A-SMGCS requirements and technical solutions. Subsequent to this chapter the relevant items of the Physical Architecture at the different DEFAMM sites are presented. This demonstrates how A-SMGCS functions can be realised by adaptation of existing technology. The description of the DEFAMM tests and their results gives interesting insight for developer and user and can be seen as a guideline on the way from demonstration systems to prototypes and operational systems. The lessons learned shall stimulate decisions on the next steps in development and research as well as review of requirements.


Public AANS _____________________________________________________________________ Co-ordination Report (D_cor_10) Author(s): Bernhard Stieler, Peter Calin Company: DLR, ANS Subject: Co-ordination Report Related Task('s): 7200 Emission Date of Delivery: 12. May 1999 Revision Number: 1.0 Ref./File No. D_cor_10.doc Deliverable Type: (PU/LI/RP/INT)* PU Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7 Summary: The co-ordination report gives an overview on the internal and external co-ordination activities in DEFAMM and background information derived from different projects supported by EC. The following Co-ordination activities, initiated by EC, were joined for project coordination: • Interproject Workshop on Airports in Brussels on 5th December 1996,

(ARAMIS, DEFAMM, TAPE, DA VINCI, DAFUSA, MANTEA, ATHOS, AIRPORT-G) • Interproject Workshop on Airports in Massy on 19th November 1997,

(ARAMIS, AMAN/DMAN, DA VINCI, MICA, SMAN, MANTEA, DEFAMM) Interproject Workshop between DEFAMM and NEAP in Koeln/Bonn on 27th May 1998, •

• Interproject Workshop OPTAS in Rome on 20th January 1999-05-12. (ARAMIS, DA VINCI., OPTAS B, SAMS, ATOPS, MANTEA, ATHOS, AIRPORT-G)

During the DEFAMM project meetings were necessary to co-ordinate the workshare between the DEFAMM team members. These meetings are classified into: Review meetings, management meetings, technical meetings and other meetings. Review meetings with EC took place to asses the progress of the DEFAMM Project. In these review meetings the Progress Report were discussed and if necessary actions were initiated. In summary 5 review meeting were held. The work on the DEFAMM project has been performed by a team of 15 partners. The Project Manager had the overall responsibility of the organisation, planning and control of the project. He called, organised and chaired 10 management meetings. During the DEFAMM Project Technical Meetings were held to co-ordinate the work within the Work Package (WP). The WP leader was responsible for the work done by the participants within his WP. In summary 27 technical meetings and several site meeting were held. Due to the high interest into the DEFAMM Project approximately 8 external meetings with standardisation bodies (e.g. AWOP, IATA, ...) were joined by DEFAMM members. _____________________________________________________________________ 22.10.02;DEFAMM_firap5.doc Task 7100 Page 88 of 89

Public AANS _____________________________________________________________________


End of Final Report – Volume II Go to: Start Table of Contents WP1 WP2 WP3 WP4 WP5 WP6 WP7