functional requirements a-smgcs level 2 - eurocontrol · this document is the eurocontrol...

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

COOPERATIVE NETWORK DESIGN

Functional Requirements for A-SMGCS

Implementation Level 2

Edition Number : 2.1

Edition Date : 30/06/2010

Status : Released Issue

Intended for : General Public

Functional Requirements for A-SMGCS Implementation Level 2

Edition: 2.1 Released Issue Page 1

DOCUMENT CHARACTERISTICS

TITLE


Publications Reference:

ISBN Number:

Document Identifier Edition Number: 2.1

Funct. Req. A-SMGCS L2 Edition Date: 30/06/2010

Abstract

This document is the Eurocontrol specification of the functional requirements for A-SMGCS Level 2 implementation.

In 2006 the EUROCONTROL A-SMGCS project published the latest version of this document that has been agreed by WG41 of EUROCAE. Further developments as well as the integration of the specifications into a European Norm and updated references consequently required an update of this document.

Keywords

A-SMGCS Implementation Specifications A-SMGCS

Identification Level 2 Requirements Identification

Authors

Contact(s) Person Tel Unit

Matthis BIRENHEIDE

Project Manager A-SMGCS +32 2 729 3449 CND/CoE/AT/AP

STATUS, AUDIENCE AND ACCESSIBILITY

Status Intended for Accessible via

Working Draft General Public Intranet

Draft CND Stakeholders Extranet

Proposed Issue Restricted Audience Internet (www.eurocontrol.int)

Released Issue Electronic copies of this document can be downloaded from: http://www.eurocontrol.int/airports/public/standard_page/surface_library.html

http://www.eurocontrol.int/airports/public/standard_page/surface_library.html�

http://www.eurocontrol.int/airports/public/standard_page/surface_library.html�

mbirenhe

Typewritten Text

10/07/15-67



DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present document.

EDITION NUMBER

EDITION DATE

REASON FOR CHANGE PAGES

AFFECTED

1.0 30/09/2003 Released Issue

1.1 22/11/2006 Revisions following Eurocontrol and European Commission validation projects and review meeting with EUROCAE WG41

Sections 5, 6 and 7

2.0 13/12/2006 Finalisation Template

2.1 30/06/2010

Update of references and template.

Editorial changes.

Executive summary.

All

Publications

EUROCONTROL Headquarters

96 Rue de la Fusée

B-1130 BRUSSELS

Tel: +32 (0)2 729 1152

Fax: +32 (0)2 729 5149

E-mail: [email protected]

mailto:[email protected]�


Page 4 Released Issue Edition: 2.1

Contents

DOCUMENT CHARACTERISTICS.............................................................................1

DOCUMENT APPROVAL...........................................................................................2

DOCUMENT CHANGE RECORD...............................................................................3

EXECUTIVE SUMMARY.............................................................................................7

CHAPTER 1 – Introduction .......................................................................................8 1.1 Scope of the document..............................................................................................8 1.2 Structure of the document .........................................................................................8 1.3 Performance parameters ...........................................................................................9

CHAPTER 2 – Methodology ....................................................................................12 2.1 Need for a methodology ..........................................................................................12 2.2 Service level ............................................................................................................12 2.3 Functional level........................................................................................................14 2.4 Architectural level ....................................................................................................15 2.5 Traceability along the process.................................................................................15 2.6 Examples of allocation of an operational requirement to a function........................16

2.6.1 Example 1 ...................................................................................................16

2.6.2 Example 2 ...................................................................................................17

2.7 Scope of the functional specification .......................................................................17 2.8 Validation Activity.....................................................................................................18

CHAPTER 3 – Actors...............................................................................................19 3.1 ATCO.......................................................................................................................19 3.2 Other operators........................................................................................................20 3.3 Pilot ..........................................................................................................................20 3.4 Vehicle Driver ..........................................................................................................21

CHAPTER 4 – Data Model .......................................................................................22 4.1 Airport traffic situation..............................................................................................22 4.2 Airport Traffic Situation Chart ..................................................................................22 4.3 Traffic context ..........................................................................................................22 4.4 Traffic information ....................................................................................................23 4.5 Mobile Position ........................................................................................................23 4.6 Mobile Identity..........................................................................................................23 4.7 Other Information about Traffic................................................................................23 4.8 Types of traffic information ......................................................................................24 4.9 Surface Mobile Information......................................................................................24 4.10 Airborne Aircraft Information....................................................................................24 4.11 Service Alert ............................................................................................................24 4.12 C/I Alert ....................................................................................................................24



CHAPTER 5 – Operational Requirements..............................................................25 5.1 General principles....................................................................................................25

5.1.1 Assumptions ...............................................................................................25

5.1.2 Recommendation........................................................................................25

5.1.3 Requirement ...............................................................................................26

5.2 Surveillance Service ................................................................................................31 5.2.1 Requirement ...............................................................................................31

5.2.2 Scenario A: Arriving Aircraft........................................................................36

5.2.3 Scenario B: System Failure ........................................................................36

5.3 Control Service ........................................................................................................36 5.3.1 Requirements..............................................................................................36

5.3.2 Scenario......................................................................................................40

5.4 Guidance Service to Vehicle Drivers (Optional) ......................................................41 5.4.1 Requirements..............................................................................................41

CHAPTER 6 – Functional specification for A-SMGCS Level 2 services to ATCOs .....................................................................................................44 6.1 Functional Breakdown for A-SMGCS Level 2 Services to ATCOs..........................44

6.1.1 Functional Architecture (Level 2) ................................................................44

6.1.2 Provide Traffic Information..........................................................................45

6.1.3 Provide traffic context .................................................................................46

6.1.4 Conflicts / Infringements Detection .............................................................47

6.1.5 Interface with user.......................................................................................47

6.1.6 Service monitoring ......................................................................................47

6.2 Functional Requirements for A-SMGCS Level 2 services to ATCOs......................47 6.2.1 Provide Traffic Information..........................................................................47


6.2.3 Conflicts / Infringements Detection .............................................................51

6.2.4 Interface with user.......................................................................................52

6.2.5 Service monitoring ......................................................................................55

CHAPTER 7 – Functional Specification for A-SMGCS Level 2 service to Vehicle Drivers........................................................................................57 7.1 Functional Breakdown for A-SMGCS Level 2 services to Vehicle Drivers..............57

7.1.1 Functional Architecture ...............................................................................57

7.1.2 Provide Vehicle Information........................................................................58


7.1.4 Interface with driver.....................................................................................58

7.1.5 Guidance Service Monitoring......................................................................58

7.2 Functional Requirements for A-SMGCS Level 2 services to Vehicle Drivers .........58 7.2.1 Provide Vehicle Information........................................................................58


7.2.3 Interface with driver.....................................................................................59

7.2.4 Guidance Service Monitoring......................................................................61



ANNEX 1 – Conflicts / infringements to be detected by the runway safety net ............................................................................................................63

ANNEX 2 – Relationships between requirements................................................66 A2.1 A-SMGCS Level 1 – Surveillance Service...............................................................67 A2.2 A-SMGCS Level 2 – Control Service.......................................................................69 A2.3 A-SMGCS Level 2 – Guidance Service to Vehicle Drivers (optional) .....................70

REFERENCES..........................................................................................................71

GLOSSARY ..............................................................................................................73

ABBREVIATIONS.....................................................................................................78

List of Figures

Figure 1: Service level .....................................................................................................13 Figure 2: Functional level................................................................................................14 Figure 3: Architectural level............................................................................................15 Figure 4: Operational and Functional requirements ....................................................16 Figure 5: A-SMGCS Project Life-Cycle ..........................................................................18 Figure 6: ATCO Role........................................................................................................20 Figure 7: Airport Traffic Situation Chart ........................................................................22 Figure 8: Types of traffic information ............................................................................24 Figure 9: Example - Information .....................................................................................40 Figure 10: Example - Alarm...............................................................................................41 Figure 11: Ground Segment Functional Architecture (Level 2).....................................44 Figure 12: Functional Architecture ..................................................................................45 Figure 13: Functional Architecture ..................................................................................46 Figure 14: Functional Architecture for Vehicles .............................................................57 Figure 15: Types of Mobiles..............................................................................................76

List of Tables

Table 1: Categories of Operational Requirements.....................................................14 Table 2: Conflicts / infringements to be detected at each individual runway .........64 Table 3: Additional conflicts / infringements to be detected when two

runways are intersecting ...............................................................................65 Table 4: A-SMGCS Level 1 – Surveillance Service.....................................................67 Table 5: A-SMGCS Level 1 – Surveillance Service.....................................................68 Table 6: A-SMGCS Level 2 – Control Service .............................................................69 Table 7: A-SMGCS Level 2 – Guidance Service to Vehicle Drivers (optional).........70



EXECUTIVE SUMMARY

This document describes the Eurocontrol specification of the functional requirements for the A-SMGCS Implementation Level 2.

Based on the results of validation projects, an update of the initial requirements had been prepared and agreed with EUROCAE WG41 for A-SMGCS and was published in 2006.

The EUROCONTROL and EUROCAE specifications have been incorporated in the creation of a European Norm (EN) for A-SMGCS Level 1 and Level 2 by the European Telecommunications Standardisation Institute (ETSI) based on Mandate 390 of the European Commission to a significant extend. This European Norm is planned to be converted into a European Community Specification (CS) by end of 2010. Both forms are intended as means of compliance to the European Regulation on Interoperability (EC) No 552/2004 being amended by Regulation (EC) No 1070/2009.



CHAPTER 1 –Introduction

1.1 Scope of the document

The EUROCONTROL A-SMGCS project aims at defining pragmatic implementation steps for A-SMGCS. The first step named A-SMGCS Level 1 focused on the implementation of automated surveillance. Its associated operational concept and requirements are presented in Ref. 2. On the basis of the analysis of the users needs presented in Ref. 2, the functional requirements for A-SMGCS Implementation Level 1 have been developed in Ref. 21.

The second step named A-SMGCS Level 2 aimed at complementing surveillance service with a control service which provides a runway safety net and prevents incursions into restricted areas. A guidance service may also be provided to the vehicles driver as an option.

The A-SMGCS Level 2 operational concept and requirements are presented in Ref. 3. On the basis of the analysis of the users needs presented in Ref. 2, the functional requirements for A-SMGCS Implementation Level 2 had been developed and are presented in the present document.

The EUROCONTROL definition of A-SMGCS Implementation Levels is based on ICAO Ref. 4 definitions and presented in Ref. 1.

1.2 Structure of the document

Introduction

CHAPTER 1 – describes the purpose of this document, its structure, the reference documents, and an explanation of terms used throughout the document

Methodology

CHAPTER 2 – reminds the methodology applied to specify A-SMGCS and explain how the functional requirements are derived from the operational one.

Actors

CHAPTER 3 – presents the actors involved in the surveillance service.

Data Model

CHAPTER 4 – presents the data types used in the functional specification.

Operational requirements

CHAPTER 5 – lists the operational requirements of A-SMGCS Level 2.

Functional Specification for A-SMGCS Level 2 services to Controllers

CHAPTER 6 – presents the Functional Specification for A-SMGCS Level 2 services to Controllers: surveillance and control services.



Functional Specification for A-SMGCS Level 2 services to Drivers

CHAPTER 7 – presents the Functional Specification for A-SMGCS Level 2 services to Drivers: guidance service.

Annex 1: Summary of Conflicts / infringements to be detected

ANNEX 1 – summaries the conflicts / infringements to be detected by the runway safety net and associated alerts.

Annex 2: Relationships between Requirements

ANNEX 2 – exposes the traceability between operational and functional requirements

1.3 Performance parameters

This section provides the explanation of terms required for a correct understanding of the present document. Most of the following explanations are drawn from the A-SMGCS manual Ref. 5, the ICAO Annex 14 Ref. 6, or the EUROCAE MASPS for A-SMGCS Ref. 9 in that case it is indicated in the definition. Ref. 5 definitions are used as a first option. In general, other definitions are only used where there is no ICAO definition. If not, it is explained why another definition is preferred to the ICAO one.

Alert Response Time (ART)

Ref. 9 definition

The time delay between an alert situation occurring at the input to the Alert Situation Detection Element and the corresponding alert report being generated at its output.

Coverage Volume (CV)

Ref. 9 definition

That volume of space which encompasses all parts of the aerodrome surface where aircraft movements take place together with those parts of the surrounding airspace which affect surface operations.

Display Resolution (DR)

Ref. 9 definition

The number of individually addressed picture elements (pixels) along each axis of the display screen. (For a raster-scan display, the resolution is normally expressed in terms of the number of raster lines and the number of pixels per line.)

Information Display Latency (IDL)

Ref. 9 definition

The maximum time delay between a report, other than a target report, being received by the A-SMGCS HMI and the corresponding presentation on the HMI display of the information contained in the report.

Position Registration Accuracy (PRA)

Ref. 9 definition

The difference between the co-ordinates contained in the dynamic input data to the

HMI and the corresponding geographical position represented on the HMI display.



Probability of Detection (PD)

Ref. 9 definition

The probability that an actual target is reported at the output of the Surveillance Element of an A-SMGCS.

Probability of Detection of an Alert Situation (PDAS)

Ref. 9 definition

The probability that the Monitoring/Alerting Element correctly reports an alert situation.

Probability of False Alert (PFA)

Ref. 9 definition

The probability that the Control service reports anything other than actual alert situations.

Probability of False Detection (PFD)

Ref. 9 definition

The probability that the Surveillance Element of an A-SMGCS reports anything other than actual targets.

Probability of False Identification (PFID)

Ref. 9 definition

The probability that the identity reported at the output of the Surveillance Element of an A-SMGCS is not the correct identity of the actual target.

Probability of Identification (PID)

Ref. 9 definition

The probability that the correct identity of a co-operative target is reported at the output of the Surveillance Element.

Reported Position Accuracy (RPA)

Ref. 9 definition

The difference, at a specified confidence level, between the reported position of the target and the actual position of the target at the time of the report.

Reported Velocity Accuracy (RVA)

Ref. 9 definition

The difference, at a specified confidence level, between the reported target velocity and the actual target velocity at the time of the report.

Response Time to Operator Input (RTOI)

Ref. 9 definition

The maximum time delay between the operator making an input on a data entry device of an A-SMGCS HMI and the corresponding action being completed or acknowledged on the HMI display.

Surveillance Capacity

Ref. 9 definition

The number of target reports in a given period which the Surveillance Element is able to process and output without degradation below the minimum performance requirements.

System accuracy



Ref. 5 definition

The term accuracy generally describes the degree of conformance between a platform's true position and/or velocity and its estimated position and/or velocity.

System availability

Ref. 5 definition

Availability is the ability of an A-SMGCS to perform a required function at the initiation of the intended operation within an A-SMGCS area.

System Capacity

Ref. 5 and Ref. 9 definition

The maximum number of simultaneous movements of aircraft and vehicles that the system can safely support within an acceptable delay commensurate with the runway and taxiway capacity at a particular airport.

System continuity

Ref. 5 definition

Continuity is the ability of an A-SMGCS to perform its required function without non-scheduled interruption during the intended operation in an A-SMGCS area.

System integrity

Ref. 5 definition

Integrity relates to the trust which can be placed in the correctness of the information provided by an A-SMGCS. Integrity includes the ability of an A-SMGCS to provide timely and valid alerts to the user(s) when an A-SMGCS must not be used for the intended operation.

System reliability

Ref. 5 definition

Reliability is defined as the ability of an A-SMGCS to perform a required function under given conditions for a given time interval.

Target Display Latency (TDL)

Ref. 9 definition

The maximum time delay between a target report being received by the A-SMGCS HMI and the corresponding presentation on the HMI display of the target position contained in the report.

Target Report Update Rate (TRUR)

Ref. 9 definition

The frequency with which target reports are output from the Surveillance Element.



CHAPTER 2 –Methodology

2.1 Need for a methodology

The operational users (ATCOs for instance) on one hand and the system designers (engineers) on the other hand have different points of view and often do not talk the same “language”.

It is important to recognise that users have an “external view of the system”. For them key questions are: “what do I get from the system?”, and “in which conditions?” A user elaborates concepts, often based on the experience, to express what is expected from the system. Therefore, he is only concerned with the external view of the system (how to interface, which environment, what are the limits,). For a user, the system itself is a black box.

On the contrary the engineers are concerned about the “internal building blocks” of the system and they need to elaborate a logical representation of the system taking into account the users demands (i.e. operational requirements). The internal organisation of the system can be described by means of “functions” (also called building blocks or components). Functions are still abstract entities but they can be expressed in technical terms and they are part of a hierarchical breakdown of the system. This hierarchical breakdown implies that, depending on the complexity, functions may be refined into sub-functions and that interfaces between functions and sub-functions are clearly specified.

There is a need for a generic methodology capable to support the capture of user needs and to translate them into an engineer view. From a methodological point of view, it is proposed to define 3 levels of requirements for an A-SMGCS system:

Operational or Service level;

Functional level, and;

Architectural level.

2.2 Service level

At the service level, the A-SMGCS system is seen as a black box providing services to users. This black box interacts with the users but also with its environment and other external systems. At this level, the requirement analysis allows to define the operational requirements from a user point of view and to identify the environmental constraints and the interfaces with external systems.



Figure 1: Service level

The operational requirements are broken down into the following categories:

Operational

Requirements

Categories

Definitions Abbreviations

Op_

Services

requirements

They define the services to be provided to the users Serv

Operational range These requirements define the operational range

covered by the systems, they fix the operational limits

of the system

Range

Responsibilities Requirements related to assignment of responsibilities

when using A-SMGCS

Resp

Interfaces Requirements related to interfaces between A-SMGCS

and users or other systems

If

Performances These requirements define the performances to be

fulfilled by A-SMGCS at an operational level

Perf

Monitoring Requirements related to monitoring of A-SMGCS

equipment, Quality of Service, Performances, etc.

Mon

Environmental

constraints

Requirements related to interference between A-

SMGCS and its environment

Env

Airport Traffic Context

Airport Traffic

Services to users

A-SMGCS System



Operational

Requirements

Categories

Definitions Abbreviations

Op_

Design They are not “pure” operational requirements but more

general principles on system design

Ds

System evolution They are not “strictly-speaking” operational

requirements but more general principles on future

evolutions of the system

Evo

Table 1: Categories of Operational Requirements

In the operational specification, these requirements are numbered according to the following frame: Op_Abbreviation-Number, e.g. Op_Serv-1

2.3 Functional level

At the functional level, the analysis of operational requirements allows to define the internal building blocks of the A-SMGCS system, which is seen as an interaction of different functions. The operational requirements are mapped onto the functional framework, to get a first engineering view of the system architecture to be developed. In particular interfaces with users are refined and if possible expressed in more technical terms.

Figure 2: Functional level

Consistency and completeness of the functional representation of the system is assessed with respect to operational requirements. At this stage the functional framework is an efficient tool for communication between ATM Operational experts and engineering experts.

Services to users

A-SMGCS Functions Function A

Function B

Function C


Airport Traffic



The building of the functional framework provides a reference for A-SMGCS instances, it allows the definition of test cases, and validation exercises. In addition, it facilitates the comparison between validation results obtained at different evaluation platforms.

2.4 Architectural level

At the architectural level, the requirement analysis defines the physical components of the A-SMGCS system which executes the different functions defined previously. The functions are mapped onto the physical architecture. At this level, the specification goes deeper in the details of the system design: the functional requirements are derived into more detailed requirements.

Figure 3: Architectural level

2.5 Traceability along the process

As shown in the following figure, the different levels of requirements have relationships as if they are part of a same family. It is possible to consider that operational requirements are the core specification. They are the starting point (the parents) from which derived functional requirements which can be considered as “children requirements”. Finally, the functional requirements are used to derive detailed design requirements which can be seen as ‘grand children’ of the operational requirements.

Services to users

A-SMGCS Architecture


Airport Traffic



Parents =

Operational requirements

Children =

Functional requirements

Grand Children =

Detailed Design

Figure 4: Operational and Functional requirements

There is a strong relationship between the operational requirement and the functional one: the operational requirement is the parent and the functional one is the child. It is important to trace this dependence between the operational and functional requirements for several reasons.

Firstly, during the project life cycle, the requirements will evolve. For instance, if an operational requirement is modified, it will impact its child requirements. So, it will be necessary to also update the child requirements in order to keep a consistent specification.

Secondly, the traceability between the requirements will be used during the validation of the A-SMGCS. For instance, when testing a specific function, all the functional requirements applying to this function are checked. If the function is not consistent with one of these functional requirements, it will be concluded that the parent(s) operational requirement(s) are not fulfilled by the A-SMGCS.

2.6 Examples of allocation of an operational requirement to a function

The objective of this section is to explain to the reader by using 2 examples how the operational requirements are derived into a functional specification.

2.6.1 Example 1

Here is an operational requirement we want to analyse from a functional point of view:

Op_Monitoring-02-Equipment Status



The operational status of all A-SMGCS equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation.

When reading this requirement, the first conclusion is that the system must contain a function which monitors all A-SMGCS equipment. This function is named “Service Monitoring” because it will monitor not only the equipment but also the performance and any parameter representing the quality of service.

2.6.2 Example 2

Here is another example which shows an operational requirement which is derived in several functional requirements during the allocation process:

Op_Interface-1-User interface

A-SMGCS Level 1 shall enable controllers to interface efficiently.

When reading this requirement, the first conclusion is that it will apply to the function named “Interface with user”. This operational requirement is not accurate because it uses a very general term: “efficiently”. So when allocating this requirement to the function, it is interesting to precise if possible the meaning of the operational requirement. “interface efficiently” may be translated in terms of “Response Time to Operator Input”, “number of input actions”, “User workload”, … As a consequence, the operational requirement is derived in several functional requirements as following:

Fn_Perf-18-Response Time to Operator Input

The Response Time to Operator Input shall not exceed 250 ms.

Fn_Perf-20-Input actions

The HMI shall minimise the number of input actions required.

Fn_Perf-21-User workload

The HMI shall ensure a level of user workload which is consistent with efficient and effective activity.

All the above functional requirements are the children of the operational requirement analysed in this example.

2.7 Scope of the functional specification

This document does not aim to identify all the previously mentioned requirements, but only focuses on the first two requirements levels: operational and functional requirements. The operational requirements are already presented in Ref. 3, and they are recalled and listed in the present document for readability purpose.

Most of the requirements are drawn from Ref. 5 or Ref. 9. In that case, their reference is attached to the requirements. These requirements have been validated in the frame of the validation activities.



2.8 Validation Activity

The functional specification gives an engineer view of A-SMGCS. This logical modelling of the system will be used by manufacturers to produce a detailed design of the system. Once the system is developed, it will be tested through validation activities. This is illustrated in the following figure:

Figure 5: A-SMGCS Project Life-Cycle

The role of EUROCONTROL was to manage the validation by developing a Validation Master Plan and monitoring the validation exercises. The final aim of the validation activity was to validate the A-SMGCS operational concept, procedures, operational and functional requirements. Therefore the validation led to a refinement of the requirements being listed in the present document.

The performance figures given in the requirements are also drawn from ICAO or EUROCAE documents. Those performance figures have usually not been tested and validated by operational experiences. When a figure has been validated through a project (3 validation projects involving 5 European airports took place), it is explicitly indicated in the associated requirements.

EU

RO

CO

NT

RO

L &

S

TA

KE

HO

LD

ER

SM

AN

UF

AC

TU

RE

R

Operational Concept

Operational Specification

Functional Specification

Operational Procedures

Valid

atio

n Ac

tiviti

es :

sim

ulat

ions

, ope

ratio

nal t

rials

,…

Detailed Design

Development

Technical Tests



CHAPTER 3 –Actors

3.1 ATCO

As for Level 1, the role of the controller does not really change by the implementation of A-SMGCS Level 2, but the controller tasks evolve in the sense that the A-SMGCS control service provides the controller with a dedicated source of alert information in all visibility conditions, and the controller must apply the procedures related to each type of alert.

This new source of data complements the conflict / infringement detection performed by the controller in analysing the traffic visually or using surveillance data.

The traffic situation picture and the conflict / infringements detection are provided by A-SMGCS to the controller to help him performing its Control task by actions on the traffic via R/T. The controller uses the alerts to:

Resolve conflict / infringements and give essential traffic information;

Anticipate incursions into runways and restricted areas, and alert the mobiles;

Anticipate risk of collision between mobiles on the runways, and alert the mobiles.

When alerted by a conflict / infringement detection, the surveillance information also provided to the controller allows him to have a good awareness and understanding of the alert situation by identifying on his screen the area of alert situation and the mobiles implicated in the alert situation. Therefore, the controller is able to quickly take the appropriate action to resolve the conflict / infringement.

Even if provided with the A-SMGCS control service, the controller shall not rely on it to detect conflict / infringement, but shall continue the analysis of the traffic situation to detect conflict / infringement himself as in SMGCS or A-SMGCS Level 1.



Figure 6: ATCO Role

3.2 Other operators

A pre-requisite for an efficient detection of conflict / infringement is the correct configuration of the automated tool, i.e. through the provision of the following information:

Airport Configuration: runways in use, runways status, restricted areas,

Applied procedures and working methods: LVP, multiple line-ups.

If not automatic, the configuration of the tool providing the automatic A-SMGCS control service may be allocated to one or more operators of the ATC team.

3.3 Pilot

The role of the pilot remains the same as for Level 1. The role of the pilot is to navigate his aircraft following ATCO instructions and clearances provided through R/T, and with the help of visual aids and ATCO. The main tasks related to A-SMGCS are the following:

Report its position to ATCO by R/T;

Monitor surrounding traffic to prevent collision by visual means and traffic information provided by ATCO.

At Level 2 the pilot is not a user of A-SMGCS, it will have the following impact on its work:

Reduction of R/T report: since the controller knows the position and identity of aircraft provided by A-SMGCS, it is possible that some



aircraft position reports be not necessary anymore. This statement has to be confirmed by the definition of the procedures related to the use of A-SMGCS.

Cooperative sensor checking: since aircraft are supposed to provide their identity through cooperative surveillance sensors, aircrew should check that this piece of equipment operates satisfactorily on board and should use it in the correct manner.

3.4 Vehicle Driver

The role of the driver is to drive his vehicle following ATCO instructions and clearances provided by R/T, and with the help of visual aids and ATCO. The main tasks related to A-SMGCS are the following:

Report its position to ATCO by R/T;

Monitor surrounding traffic to prevent collision by visual means and traffic information provided by ATCO.

With A-SMGCS the controller knows the position and identity of vehicles, so it is possible that some vehicle position reports are not necessary anymore. It has to be confirmed in the procedures related to the use of A-SMGCS.

Moreover, if the vehicle is equipped for A-SMGCS, for instance with a transponder, the driver should check the equipment is activated and should use it in the correct manner.

In A-SMGCS Level 2, the vehicle driver may optionally be provided with a guidance service. The role of the vehicle driver will not really change when equipped with the guidance service. Its tasks will evolve in the sense that the guidance service will provide to the driver a new source of data about its position related to the airport layout and fixed obstacles in all visibility conditions. This new source of data will complement the usual visual observation outside the vehicle. The guidance service does not require any inputs neither from the driver, nor from the controller.

The driver will use this new information (position of its vehicle, airport map, reference points on the map, visualised on a display) for the navigation of its vehicle. For instance, when he is lost, there is no indication about its position outside, or he cannot see them because of reduced visibility conditions, he will be able to use the information provided by the guidance service to know exactly where he is on the airport platform.



CHAPTER 4 –Data Model

This section presents the types of data used in the functional specification. In the functional charts, they are used to indicate the type of data exchanged between two functions.

4.1 Airport traffic situation

The airport traffic situation, presented in the following chart, is a data type, which includes Traffic Context (airport layout, etc), and Traffic Information.

4.2 Airport Traffic Situation Chart

Figure 7: Airport Traffic Situation Chart

4.3 Traffic context

The traffic context contains all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in its surveillance task.

The traffic context at least includes:



Airport layout : geographical representation of various airport areas (TWY, RWY, etc);

Reference points: holding positions, stop bars (and other airfield lighting), RWY thresholds, and;

Fixed obstacles.

The traffic context may optionally include (local issue):

Status of runways and taxiways (open / closed);

The reason a runway or taxiway is closed;

Status of ATS system, e.g. landing systems aids, ATIS, etc, and;

Other data as e.g. meteorological conditions, etc.

4.4 Traffic information

Traffic information is a general term to indicate the following information about the Mobiles:

Position;

Identity;

Other information (aircraft gate, etc).

4.5 Mobile Position

Mobile Position indicates position for each aircraft and vehicle. Position of all mobiles is necessary for the Controller in order to monitor the traffic and in particular to detect the intruders.

4.6 Mobile Identity

Mobile Identity indicates identity for each aircraft (call sign for instance) or vehicle. Identity allows the controller to identify each mobile. The identity of mobiles is necessary for the controller to communicate with the pilots or vehicle drivers in particular to issue clearances. The surveillance service will display the identity of all mobiles in a label attached to the corresponding target. Identity can only be provided by cooperative surveillance sensors.

4.7 Other Information about Traffic

Other Information about traffic represents in various information such as destination parking and gate that could be provided to the controller if needed. Other parameters (velocity, etc) may be required for other A-SMGCS modules such as Conflicts/Infringements Detection.



4.8 Types of traffic information

Figure 8: Types of traffic information

A-SMGCS covers both ground and airborne traffic. Ground traffic concerns aircraft and vehicles on airport surface. Airborne traffic concerns aircraft above the manoeuvring area, e.g. landing and departing aircraft.

4.9 Surface Mobile Information

Surface Mobile Information indicates traffic information for mobiles on the ground.

4.10 Airborne Aircraft Information

Airborne Aircraft Information represents information about airborne traffic. This information is provided by approach Radar Surveillance Data Processing System (RDPS) and/or airport surveillance system. Airborne Aircraft Information is used to take into account in particular landing and departing aircraft and to ensure coordination between Ground control and Approach control.

4.11 Service Alert

Service alert is used when system must not be used for intended operation (or when the system performances are restricted for significant failures). Such a situation could appear for different reasons (significant failures, equipment status, and low performance).

4.12 C/I Alert

C/I alerts are provided to the user when Conflicts/Infringements are detected.



CHAPTER 5 –Operational Requirements

In this section the operational requirements already defined for A-SMGCS Level 1, Ref. 2 and for A-SMGCS Level 2, Ref. 3 are listed. The requirements related to System Design, Evolution, Operational Range, Responsibilities, Interfaces, and Environmental Constraints are listed as "General Principles" while requirements specific to A-SMGCS services are listed in specific sections.

5.1 General principles

5.1.1 Assumptions

Cooperative

All participating mobiles shall be cooperative.

Sensors and Data Fusion

It is expected that more than one type of sensor and a data fusion unit may be needed to meet the following requirements.

Source: Ref. 5 3.4.1.3

5.1.2 Recommendation

Op_Ds-1-Modularity to fit aerodrome needs

An A-SMGCS shall be composed of different modules required for particular user needs or technological choices.

Note 1 - Each aerodrome has its own operational needs and technological constraints. So each aerodrome will only implement the A-SMGCS modules fitting its needs and its technological choices in order to minimize the cost of its A-SMGCS. Consequently, ASMGCS consists of many elements which, when integrated, are designed to meet the specific operational requirements of an aerodrome.

Note 2 - The combination of modules used for any A-SMGCS Level shall ensure that the requirements of this Level are met. It implies that minimum modules are required, i.e. cooperative surveillance.

Source: Ref. 5, 3.4.1 and Ref. 9, 1.8.2

Op_Ds-2-HMI design

The A-SMGCS design concept must be built upon the integration of the fundamental and principal system elements and facilitate the upgrading of those elements whilst maintaining, where possible, the same HMI and



references. This is important when considering harmonisation, familiarisation, and training requirements, and will allow the evolution of the system design through to a full A-SMGCS with the minimum negative impact on the users' ability to interface with the system.

Source: Ref. 9, 2.5.2

Op_Ds-3-Interoperability

Standards like Standards and Recommended Practices (SARPs) shall be written and used to permit interoperability between the A-SMGCS elements developed by different manufacturers. the manufacturer, service provider and user. It should also encourage timely implementation by avoiding a proliferation of different specifications.


Op_Env-1-Aerodrome

An A-SMGCS should be capable of being installed at any aerodrome.

Source: Ref. 5, 3.5.12.1

Op_Evo-3-HMI impact

A-SMGCS evolution shall have a minimum negative impact on the users' ability to interface with the system. This is important when considering harmonisation, familiarisation, and training requirements.


Op_Evo-4-Modularity for A-SMGCS Levels

The design principle of an A-SMGCS shall permit modular enhancements such as implementation of further A-SMGCS Levels.

Note - A-SMGCS will evolve from a SMGCS by progressive enhancements to match the desired level of operations. The competent authority will determine, in consultation with the users, whether existing SMGCS needs to be upgraded to A-SMGCS. A-SMGCS for each aerodrome will comprise a different mix of modular components dependent upon operational factors.

Source: Ref. 5, 3.4.1 and Ref. 9, 1.8.2

Op_Evo-5-Cost of evolution

The design principle of an A-SMGCS shall permit system enhancements at minimal cost.


Data recording

Data should be stored to reconstruct the video rendering of each HMI unit.

5.1.3 Requirement

Op_Ds-4-Standardised Data Format

The data interchange between systems should be performed in a standardised format in order to ensure an adequate exchange of information.

Note - ASTERIX will most likely be the standard to be used for surveillance data in Europe.

Source: Ref. 5, 3.6.21.2

Op_Ds-5-Self-checking system

A self-checking system with failure alerts shall be in the system design.



Source: Ref. 5, 2.7.5.1

Op_Ds-6-System status

Equipment which shows control data shall both be fail-safe and fail-soft.

Note - The term "fail-safe" in this context means that sufficient redundancy is provided to carry data to the display equipment to permit some components of the equipment to fail without any resultant loss of data displayed. The term "fail-soft" means that the system is so designed that, even if equipment fails to the extent that loss of some data occurs, sufficient data remain on the display to enable the controller to continue operation without assistance of the computer.

Source: Ref. 5, 2.6.9.1

Op_Ds-7-Failure effect

In case of a failure of an element of an A-SMGCS, the failure effect shall be such that the element status is always in the "safe" condition.

Note - For instance, the element shall not provide wrong data which could impact on safety.

Source: Ref. 5, 2.6.9.2

Op_Ds-8-Self-restartable

An A-SMGCS shall be self-restartable.

Source: Ref. 5, 2.6.9.4

Op_Ds-9-Restart

The restart of an A-SMGCS shall include the restoration of pertinent information on actual traffic and system performance.

Source: Ref. 5, 2.6.9.4

Op_Env-2-Flight operations

The ground elements of the system shall be sited so as not to affect flight operations.

Source: Ref. 18

Op_Env-3-Equipment

Any A-SMGCS equipment sited close to the movement areas should be:

a) Lightweight;

b) Frangible where appropriate; and

c) Capable of withstanding the effects of jet blast.

Note - It is understood that any A-SMGCS equipment installed in the movement area will comply with the general obstacle limitations requirements in Ref. 6, Note 2.

Source: Ref. 18

Op_Env-4-Adverse effects

The system shall have adequate immunity to adverse effects such as:

a) Radio interference, including that produced by standard navigation, telecommunications and radar facilities (including airborne equipment);

b) Signal reflections and shadowing caused by aircraft in flight, vehicles or aircraft on the ground, buildings, snow banks or



other raised obstacles (fixed or temporary) in or near the aerodrome environment; and

c) Meteorological conditions or any state of the aerodrome resulting from adverse weather in which operations would otherwise be possible.


Op_Env-5-Radio Spectrum

Those elements of A-SMGCS which require the use of radio spectrum should operate in properly allocated frequency bands in accordance with appropriate national and international radio regulations.

Source: Ref. 19

Op_Env-6-Interference to Other Systems

A-SMGCS equipment shall not cause interference to standard radio navigation, surveillance, and communication systems.

Source: Ref. 19

Op_Evo-1-Operational Change

An A-SMGCS shall be capable of accommodating any operational change of the aerodrome after being installed, for instance a physical change in layout (runways, taxiways and aprons), or a change in the aerodrome procedures, rules, etc.

Source: Ref. 5, 3.5.12.2 and Ref. 9, 1.8.3

Op_If-1-User interface

A-SMGCS shall enable users to interface efficiently.

Source: Ref. 5, 2.6.16.3

Op_If-2-Operator interface

A-SMGCS shall enable operators updating traffic context or configuration of the system to interface efficiently.

Op_If-3-Interface with mobiles

A-SMGCS shall be capable of interfacing with all cooperative mobiles in order to collect the required traffic data. In addition it should interface with existing and future embedded systems.

Source: Ref. 5, 2.6.2 and Ref. 17

Op_If-4-Interface with ground systems

In order to fully benefit from an A-SMGCS by all parties concerned, the system should be capable of interfacing with the following ground systems:

Air traffic management (ATM), including Integrated Initial Flight Plan Processing System (IFPS), departure management, etc.

Approach surveillance system to take into account airborne aircraft;

Stand management systems;

Existing and future ATS systems;

MET systems;

Visual aids;



Any other system as part of the Collaborative Decision Making Process (CDM).

Source: Ref. 5, 2.6.16.1

Op_If-5-Interference with ATC

The operation of A-SMGCS interfaces should not interfere with other ATC responsibilities, such as the observation of aerodrome activity and the requirements to provide alerting service.

Source: Ref. 5, 3.5.18.6

Op_Range-1-Visibility conditions

A-SMGCS shall be capable of operating in all visibility conditions.

Source: Ref. 5, 2.5.4.1 (l)

Op_Range-2-Capacity

A-SMGCS shall be able to handle all traffic movements on their area of interest at any instant time.

Note -Since capacity is a site-specific parameter, the determination of the maximum number of aircraft on the manoeuvring area should be based on the assumed peak traffic at the aerodrome. Aerodromes continually strive to increase capacity and therefore the number of movements, and hence aircraft and vehicles will probably increase over time.

The A-SMGCS capacity figure should be sufficient to cater for expansion of this nature and reviewed on a regular basis to ensure that it is sufficient.

Source: Ref. 5, 4.1.1.6

Op_Range-3-Mobile types 1

An A-SMGCS shall support operations involving all aircraft types and all vehicles types within the coverage area.

Source: Ref. 5, 2.6.2 and Ref. 17

Op_Range-4-Mobile types 2

An A-SMGCS shall be capable of adaptation to cater for future aircraft types and vehicles types within the coverage area.


Op_Range-5-Speeds and Orientation

The system shall be capable of supporting operations of mobiles within the following parameters:

Minimum and maximum speeds for aircraft on final approach, and runways;

Minimum and maximum speeds for aircraft on taxiways;

Minimum and maximum speeds for vehicles, and;

Any heading.


Op_Range-6-Velocity

The A-SMGCS should cover the following speeds:

0 to 93 km/h (50 kt) for aircraft on straight taxiways;

0 to 36 km/h (20 kt) for aircraft on taxiway curves;



0 to 150 km/h (80 kt) for aircraft on runway exits;

0 to 460 km/h (250 kt) for aircraft on final approach, missed approach and runways;

0 to 150 km/h (80 kt) for vehicles on the movement area, and;

0 to 20 km/h (10 kt) for aircraft and vehicles on stands and stand taxi lanes.

Source: Ref. 5, 4.1.1.8

Op_Resp-1-Users

Although the responsibilities and functions may vary, they shall be clearly defined for all users of A-SMGCS.

Source: Ref. 5, 2.3

Op_Resp-2-Assignment

An A-SMGCS shall be designed so that the responsibilities and functions may be assigned to the following:

a) The automated system;

b) Controllers;

c) Pilots;

d) Vehicle drivers;

e) Airport authorities, and;

f) System operators.

Note 1 - The allocation of functions and/or responsibilities might differ depending on visibility condition, level of automation and level of implementation of an A-SMGCS. A different division of functions among the control personnel (e.g. between authorities responsible for aerodrome movement control and apron management services) may also be necessary as a result of possible changes in procedures caused by automation.

Note 2 - ATC will be responsible for the management and overall operation of the system. When certain functions will be delegated to automated elements of the system, responsibilities for the integrity and reliability of those functions lie with the service providers, certification authorities, manufacturers and software suppliers.

Note 3 - When A-SMGCS is in operation, pilots remain responsible for the safety and control of aircraft.

Note 4 - At Level 1 and 2 ATC controllers and pilots are the only critical decision makers. Their decisions are based on surveillance data which have a specify integrity.

Source: Ref. 5, 2.3

Op_Resp-3-A-SMGCS category

The responsible authority shall be in charge of notifying the application of Mode-S transponder operating procedures in the Aeronautical Information Publication (AIP). Source: Ref. 17



5.2 Surveillance Service

5.2.1 Requirement

Op_Mon-1-Equipment Status

The operational status of all A-SMGCS equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation.

Source: Ref. 5, 2.5.1.2 and 2.7.3.2

Op_Mon-2-Performance

Monitoring of the performance of an A-SMGCS should be provided such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service.

Source: Ref. 5, 2.7.4.3

Op_Mon-3-Data

The A-SMGCS shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation.

Note - As an example when a mobile is still on his area of interest, the system shall continuously detect the mobile; otherwise the user shall be timely alerted.

Source: Ref. 5, 2.7.3.2

Op_Mon-4-Back-up

The system shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur.

Source: Ref. 5, 2.7.5.3

Op_Mon-5-System Failures

Operationally significant failures in the system shall be clearly indicated to the control authority and any affected user.

Source: Ref. 5, 2.7.5.3 and 2.7.4.4

Op_Mon-6-Failure Alerts

All critical elements of the system should be provided with audio and visual indication of failure given in a timely manner.

Source: Ref. 5, 2.6.9.3

Op_Perf-1-Probability of Detection

The probability that an actual aircraft, vehicle, or object is detected and reported at the output of the surveillance element of the A-SMGCS shall be:

99.9% minimum on the manoeuvring area

98% minimum on the apron for moving aircraft only

Exceptions for well-identified areas on airport surface are acceptable (defined locally).

Note - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors.

Source: Ref. 5, 3.4.1.4 (a); Ref. 9, 3.2.3, 3.2.4, and Ref. 16



Op_Perf-2-Probability of False Detection

The probability that anything other than an actual aircraft, vehicle, or object is detected and reported by the surveillance element of the A-SMGCS shall not exceed 0.1%.

Note 1 - The surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors.

Note 2 - Some ATS Providers request a Probability of False Detection less than 1%.

Source: Ref. 5, 3.4.1.4 (a) and Ref. 9, 3.2.3 and 3.2.4.

Op_Perf-3-Probability of Identification

The probability that the correct identity of cooperative aircraft and vehicles, broadcasting their identification correctly, is reported at the output of the surveillance element shall be:

99.9% minimum on manoeuvring area

98% minimum on apron.

Note 1 - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors.

Note 2 - Some ATS providers request a Probability of Identification of at least 99% while the Probability of Identification required for Mode S radars is 99.9%.

Note 3 - The requirement only intends to specify the performance of the ground system.

E.g. pilot deviations for operating Mode-S transponder are not taken into account.

Source: Ref. 5, 3.4.1.4 (a); Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17

Op_Perf-4-Probability of False Identification

The probability that the identity reported at the output of the surveillance element is not the correct identity of the actual aircraft, vehicle, or object shall not exceed 0.1%.

Note 1 - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors.

Note 2 - The value of 0.1% for Probability of False Identification is already requested by some ATS providers and accepted by manufacturers.

Note 3 - The requirement only intends to specify the performance of the ground system.


Source: Ref. 5, 3.4.1.4 (a); Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17

Op_Perf-5-Position Accuracy

For the surveillance service, the allowable error in reported position shall be consistent with the requirements set by the control task of the controller:

7.5 m on manoeuvring area at a confidence level of 95%



12 m on apron at a confidence level of 95%.

Note -

For Reported Position Accuracy (RPA), ICAO specification recommends a value of 7.5m (Ref. 5, 2.7.1.2 and 4.2.3).

For Ref. 10, a value of 7.5m (95% level of confidence) is recommended.

For Ref. 9, 3.2.3.1, a value of 12m would be reasonable for the surveillance service.

Source: Ref. 5, 2.7.1.2 and 4.2.3; Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17

Op_Perf-6-Position Resolution

The mobile position resolution shall be at least 1 m.

Source: Ref. 9, 3.2.4.

Op_Perf-7-Altitude Accuracy

Where airborne traffic participates in the A-SMGCS, the level of an aircraft when airborne shall be determined within ±10m.

Note - Justification has not been provided for the need of aircraft altitude for A-SMGCS and for the value of its accuracy. However, it has been decided to keep this requirement as such in the document because it is provided by ICAO. If no more information about this requirement is provided so far, the validation activity will determine the status of this requirement.


Op_Perf-8-Update rate

Where appropriate, the update rate of an A-SMGCS shall be consistent with the requirements set by the control task of the controller: 1 per second.

Note - Ref. 9, 3.2.3, 3.2.4, and Ref. 5, 4.2.4 require the update rate should be at least 1 per second. For example, in one second, an aircraft rolling at 10 kts covers a distance of 5 meters. A vehicle at 35 km/h will move of 10 metres. In that case, the position displayed to the controller can differ of 10 metres from the actual position before being updated with the new reported value. If we take the maximum speed of 93 km/h (50 kt) for aircraft on straight taxiways (Ref. 5, 4.1.1.8), the displayed position can differ by 25 metres.

Source: Ref. 5, 4.2.4 and Ref. 9, 3.2.3 and 3.2.4.

Op_Perf-10-Availability

The availability of an A-SMGCS shall be sufficient to support the safe, orderly, and expeditious flow of traffic on the movement area of an aerodrome.

Source: Ref. 5, 2.7.4.1; Ref. 9, 3.1.1.2

Op_Perf-11-Reliability

A failure of equipment shall not cause:

An unacceptable reduction in safety (fail soft), and;

The loss of basic functions.

Note - this requirement is achieved using backup and/or redundancy systems.

Source: Ref. 5, 2.7.5.2; Ref. 9, 3.1.1 and Ref. 17

Op_Perf-12-Continuity of Service 1

An A-SMGCS shall provide a continuous service.

Source: Ref. 5, 2.7.4.2; Ref. 9, 3.1.1.2 and Ref. 10, 2.20.1 and 2.20.2.



Op_Perf-14-Recovery time

For a cold restart, the recovery time of an A-SMGCS shall be acceptable and the maximum value shall be specified locally. (Recommendation)

Note – During the validation activity the requirement of ICAO guidance for recovery within a few seconds could not be met. Technology might evolve over time and requirements should be reviewed regularly.

Source: Ref. 5, 2.6.9.4 and Ref. 17

Op_Serv-1-Service

A-SMGCS shall provide the surveillance service to the users.

Op_Serv-2-User

The users of the surveillance service shall be all control authorities concerned in the manoeuvring area of the aerodrome.

Op_Serv-3-Airport Traffic Situation

The surveillance service shall continuously provide the following airport traffic situation:

Traffic Information, and

Traffic context.

Op_Serv-4-Traffic information 1

The surveillance service shall continuously provide the following traffic information:

Position of all vehicles on the area of interest for vehicles, including intruders;

Identity of all cooperative vehicles on the area of interest for vehicles;

Position of all relevant aircraft on the area of interest for aircraft, including intruders;

Identity of all relevant aircraft on the area of interest for aircraft, and;

History of the mobiles position (e. g. the 3 last positions displayed).

Op_Serv-5-Traffic information 2

The traffic information may optionally include other information about traffic, such as:

Vehicle type;

Aircraft type and registration number;

Aircraft’s identification (ICAO 3 letter code and flight number);

Mode A code and Mode S code ;

Departure / destination Airport;

Estimated Time of Arrival / Departure;

Allocated Stand, and current stand status (occupied/free);

Wake Vortex Category;

CFMU Slot time (if applicable);

Assigned runway and SID/STAR/Approach Procedure;

Estimated and actual off-block times, and;



Any other information deemed useful for the local operations.

The provision of such information shall be made compliant with an integrity level that is to be determined locally.

Op_Serv-6-Area of interest for vehicles

The area of interest for vehicles shall be the manoeuvring area.

Op_Serv-7-Area of interest for aircraft

The area of interest for aircraft shall be the movement area, plus a volume around the runways for aircraft on approach to each landing runway direction, at such a distance that inbound aircraft can be integrated into an A-SMGCS operation and that aerodrome movements, including aircraft departures, relevant missed approaches or aircraft crossing the relevant active runways, can be managed.

Source: Ref. 5, 2.5.1.2, 2.5.1.4, 2.5.1.5 and 2.7.3.2

Op_Serv-8-Traffic context1

Traffic context provided by the surveillance service shall contain all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in his surveillance task.


The traffic context shall at least include:

Airport layout: geographical representation of various airport areas (TWY, RWY, etc);

Reference points: holding positions, stop bars (and other airfield lighting), RWY thresholds;

Fixed obstacles.

Source: Ref. 5, 3.3.3.7


The traffic context may optionally include (local issue):

Status of runways and taxiways (open / closed);

An indication of the duration of the runway/taxiway closure (temporary, long term);

Status of ATS systems: landing systems aids, ATIS;

Other data: meteorological conditions

Source: Ref. 5, 3.3.3.7

Op_Serv-11-Position

Each mobile shall be seen in the correct position with respect to the aerodrome layout and other traffic.

Note - It means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement.

Op_Serv-12-Label

The surveillance service shall provide to the user the ability to manually put the right callsign in the label associated to a vehicle equipped with mobile cooperative equipment used for different vehicles.

Op_Serv-13-Transition



A seamless transition should be provided between the surveillance for an A-SMGCS and the surveillance of traffic in the vicinity of an aerodrome.

Source: Ref. 5, 3.4.1.2

5.2.2 Scenario A: Arriving Aircraft

This section and the following one describe two operational scenarios for A-SMGCS in order to provide to the reader a better understanding of A-SMGCS surveillance service.

An aircraft approaching an airport will be detected by the approach Radar Data Processing System (RDPS). When arriving over the runway threshold, this aircraft must be displayed to the ground controllers. A-SMGCS will provide a seamless transition between air and ground surveillance systems. Actually, the aircraft will be firstly detected by A-SMGCS through the data sent by the approach surveillance system.

As soon as the aircraft is under coverage of the cooperative surveillance sensor, surveillance data from cooperative and non-cooperative surveillance sensors will be combined by the data fusion process to provide to the controller the exact position and identity of the aircraft. During the taxiing phase on the manoeuvring area, the controller will always have the exact position and identity of the aircraft. During the taxiing on the apron, the A-SMGCS surveillance service will continue to provide the aircraft position and identity till the stand.

Note - In the future, approach Surveillance Data could be not only provided by Radar but also by other technologies such as ADS.

5.2.3 Scenario B: System Failure

Considering the previous scenario, we can imagine that all the cooperative surveillance sensors have a significant failure. In this case A-SMGCS is not able to collect the identity of the aircraft, but it could continue to display the identity previously provided by the approach RDPS.

In this situation, the controller will be alerted by the service monitoring process that A-SMGCS may not be able to provide identity of mobiles and the controller should revert to adequate back-up procedures. In particular, the identity of cooperative vehicles entering the manoeuvring area won't be provided to the controller.

5.3 Control Service

All A-SMGCS performance and system monitoring operational requirements for surveillance service apply to A-SMGCS control service. The performance requirements presented in the following section are specific to the control service.

5.3.1 Requirements


The allowable error in reported position used for conflict/infringement (within runway protection area) shall be consistent with the requirements set by the Control service:

7.5m at 95% level of confidence on the manoeuvring area, and;

12m at 95% level of confidence on the apron.



Note - The required position accuracy may be specifically defined at each airport by the ATS authority on the basis of local safety analysis.

Source: Ref. 5 2.7.1, 3.4.1.12, and 4.2.3; Ref. 9 3.2.3.2 and 3.2.4; Ref. 17

Op_Perf-16-Reported Velocity Accuracy

The velocity shall be determined to the following accuracy:

Speed: <5m/s

Direction of movement consistent with alerting algorithms

Note - For reported velocity accuracy, ICAO specification recommends the following values:

Speed: +/- 1 Kt (0.5m/s)

Direction of movement: +/-1°.

According to the performance of existing tracking systems studied in other projects these values do not seem to be achievable.

Therefore, we recommend the values required by Ref. 9, 3.2.4: <5 m/s for speed and for direction of movement consistent with alerting algorithms.

Source: Ref. 5 4.1.1.8 and 4.1.1.10; Ref. 9 3.2.4

Op_Perf-17-Target Report Velocity Resolution

The target report velocity resolution shall be:

Speed: ≤0,25m/s

Source: Ref. 9 3.2.4

Op_Perf-18-Alert latency

The alert resulting of conflict / infringement detection shall be provided to the user well in advance within a specified time frame, to enable the appropriate remedial action with respect to:

a) Conflict / infringement prediction;

b) Conflict / infringement detection; and

c) Conflict / infringement resolution.


Op_Perf-19-Alert Continuity

The Conflict/Infringement Alert should be displayed continuously while the conflict is detected.

Source: Ref. 5 3.4.5.14

Op_Perf-20-False and Nuisance alert number

The number of 3 false alerts (stage ALARM) should not be exceeded on a weekly basis.

Source: Ref. 14

Op_Perf-21-Impact of false alert on safety

The false alerts shall not impact on the airport safety.

Op_Serv-14-Service

A-SMGCS Level 2 shall provide the control service to the users.

Op_Serv-15-User



The users of the A-SMGCS control service shall be all control authorities concerned in the manoeuvring area of the aerodrome.

Op_Serv-16-Conflicts/infringements on runway

The control service shall detect the conflicts/infringements on runway:

1) Aircraft arriving to, or departing aircraft on, a closed runway;

2) Arriving or departing aircraft with traffic on the runway (including aircraft beyond the runway holding positions);

3) Arriving or departing aircraft with moving traffic to or on a converging or intersecting runway;

4) Arriving or departing aircraft with opposite direction arrival to the runway;

5) Arriving or departing aircraft with traffic crossing the runway;

6) Arriving or departing aircraft with taxiing traffic approaching the runway (predicted to cross the runway-holding position);

7) Arriving aircraft exiting runway at high speed with converging taxiway traffic;

8) Arriving aircraft with traffic in the sensitive area (when protected);

9) Aircraft exiting the runway at unintended or non-approved locations;

10) Unauthorised traffic approaching the runway, and;

11) Unidentified traffic approaching the runway;

Source: Ref. 5 3.4.5.7 (a)

Op_Serv-17-Restricted area incursions

The control service shall detect the restricted area incursions caused by an aircraft (not vehicles) into an area such as closed TWY, ILS, or MLS critical area, to be defined locally for each aerodrome.

Source: Ref. 5 3.4.5.2 and 3.4.5.11

Op_Serv-18-Runway protection area

The runway protection area shall be composed of two boundaries: A ground boundary to detect the mobiles on the surface, an air boundary to detect airborne aircraft.

Op_Serv-19-Ground boundary

The length of the ground boundary must at least include the runway strip. The width could be defined, and different, according to the meteorological conditions, e.g. Non-LVP, LVP.

As an example based on today ILS holding positions:

In Non-LVP: ground boundary defined by Cat I holding position

In LVP: ground boundary defined by Cat II / III holding position

This ground boundary will be used for both INFORMATION and ALARM stages.

Note - In order to avoid unnecessary INFORMATION or ALARM to the controllers, current systems wait until the mobile has crossed the boundary.

Subject to further development, if the runway protection is ensured by an algorithm which could predict that a mobile is able or not to stop before



entering the protection area, i.e. the ground boundary, an INFORMATION / ALARM could be generated before the mobile crosses the boundary.

Such algorithms, based on the speed and position of a mobile, may already exist but they have to be evaluated.

Op_Serv-20-Air boundary

The air boundary shall be defined as a flight time to threshold and would take into account the two stages of alert, INFORMATION and ALARM, as well as the meteorological conditions:

Non-LVP: INFORMATION around T1 = 30'', ALARM around T2 = 15''

LVP: INFORMATION around T1 = 45'', ALARM around T2 = 30''

Note - Theses times should be configurable, depending upon optimisation at the aerodrome.

Source: Ref. 5 3.4.5.12 and 3.4.5.13

Op_Serv-21-Traffic Context Update

For the Conflict/Infringement detection, additional updated and correct traffic context information shall be provided to the system as required for the detection.

Examples:

Airport Configuration: runways in use, runways status, restricted areas;

Applied procedures: e.g. LVP;

ATC working methods: e.g. multiple line-ups.

Source: Ref. 13 and Ref. 17

Op_Serv-22-Alert

The control service shall alert the users in case of conflict/infringement detection.


Op_Serv-27-Stages of alert

The control service shall provide 2 stages of alert:

Stage 1 alert is used to inform the controller that a situation which is potentially dangerous may occur, and he/she needs to be made aware of. According to the situation, the controller receiving a stage 1 alert may take a specific action to resolve the alert if needed. This is called INFORMATION step.

The stage 2 alert is used to inform the controller that a critical situation is developing which needs immediate action. This is called ALARM step.

Note - Controllers have different preferences, some of them want to be alerted only when the situation is critical (only stage 2 alerts), and others wish more anticipation (2 stages of alert). This is confirmed by the evaluations performed in the BETA project. As a consequence, some ATS providers may choose to have ALARM only, and not use INFORMATION. The choice of having several stages of alerts presented to the controller, according to the conflict / infringement, should be left to the ATS providers and is a local decision.

Op_Serv-28-Alert priority

Priorities should be established so as to ensure system logic performs efficiently. Conflict alerting priorities should be as follows:

a) Runway incursions.



b) Restricted area incursions.

Source: Ref. 5 3.4.5.10

Op_Serv-29-Adaptation to local procedures

In order to efficiently assist ATCO, the automated A-SMGCS control service should be configurable to adapt to local ATC procedures and working methods.

Source: Ref. 17

Op_Serv-30-Traffic Information Update

For the Conflict/Infringement detection, additional updated and correct traffic information shall be provided to the system such as mobiles velocity.

5.3.2 Scenario

This section describes an operational scenario for A-SMGCS in order to provide to the reader a better understanding of A-SMGCS control service.

Meteorological conditions are supposed to be LVP;

Considering an aircraft approaching the runway 14. This aircraft is assumed to be already under coverage of the A-SMGCS surveillance sensors. The data collected by cooperative and non cooperative surveillance sensors are combined by the data fusion process to provide surveillance information to the controller and to the conflict/infringement detection process;

Considering a cooperative vehicle which is going to enter the runway 14.

Since it entered on the manoeuvring area, he has been continuously tracked by the A-SMGCS surveillance service too, and surveillance data are provided to the controller and to the conflict/Infringement process through the data fusion process.

In this scenario the vehicle enter the runway without requesting clearance to the ATCO, believing he is on a taxiway.

When the aircraft arrives at T1 = 45s from the runway threshold, the vehicle is still on the runway. The Conflict/Infringement detection process detects the conflict and then generates an “INFORMATION”.

Figure 9: Example - Information

The controller considers the INFORMATION and analyses the surveillance data provided by the surveillance service. If the vehicle is not exiting the runway, he contacts the driver to inform him that there is an aircraft on final and that he must immediately exit the runway. If he has no response and no reaction, the controller can already order the pilot to go around.

INFORMATION



When the aircraft arrives at T2=30s from runway threshold, if the situation is not resolved, the conflict/infringement process generates an ALARM and the controller will immediately order the aircraft pilot to go around.

Figure 10: Example - Alarm

5.4 Guidance Service to Vehicle Drivers (Optional)

5.4.1 Requirements

Op_Mon-7-Equipment Status

The operational status of all guidance service equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation.


Op_Mon-8-Performance

Monitoring of the performance of the guidance service should be provided such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service.


Op_Mon-9-Data

The A-SMGCS shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation.


Op_Mon-10-Back-up



Op_Mon-11-System Failures

Operationally significant failures in the system shall be clearly indicated to any affected user.

Source: Ref. 5 2.7.5.3 and 2.7.4.4

Op_Mon-12-Failure Alerts

ALARM






For the guidance service, the allowable error in reported position shall be consistent with the requirements set by the task of the user: 12m at a confidence level of 95 %.

Note -

For the Guidance service the position accuracy doesn't need to be better than for surveillance service.

If the same equipment is used to provide the position both to the control and the guidance service, the position accuracy must be consistent with the Position Accuracy requirement set for the control service.

Source: Ref. 5 2.7.1.2; Ref. 9 3.2.4, and Ref. 17

Op_Perf-23-Position Resolution

The mobile position resolution shall be ≤1m.


Op_Perf-24-Update rate

Where appropriate, the update rate of the reported mobile position shall be consistent with the requirements set by the task of the driver: approximately 1 per second.

Note - EUROCAE and ICAO-A-SMGCS require an update rate of at least 1 per second. For example, in one second, a vehicle at 35 km/h will move of 10 metres. In that case, the position displayed to the user can differ of 10 metres from the actual position before being updated with the new reported value. If we take the maximum speed of 150 km/h (80 kt) for vehicles on the movement area, the displayed position can differ by 40 metres.

Source: Ref. 5 4.2.4, and Ref. 9 3.2.4

Op_Perf-25-Integrity

A-SMGCS shall preclude failures that result in erroneous data provided to the users.

Source: Ref. 5 2.7.3.1, and Ref. 9 3.1.1.1

Op_Perf-26-Reliability

A failure of equipment shall not cause:

A reduction in safety (fail soft), and;

The loss of basic functions.

Source: Ref. 5 2.7.5.2, and Ref. 9 3.1.1


An A-SMGCS shall provide a continuous service.

Note – The provisions of Ref. 5 are extended to vehicle drivers.

Source: Ref. 5 2.7.4.2, Ref. 9 3.1.1.2


Any unscheduled break in continuity shall be sufficiently short or rare as not to affect the safety of mobiles.



Note – The provisions of Ref. 5 are extended to vehicle drivers.

Source: Ref. 5 2.7.4.2, Ref. 9 3.1.1.2

Op_Perf-29-Recovery time

When restarting, the recovery times of the guidance service shall be compatible with user operations (a value of 1 minute would be reasonable as a maximum).

Source: Ref. 5 2.6.9.4 and 2.7.4.4

Op_Serv-23-Service

A-SMGCS Level 2 may optionally provide the guidance service to the users.

Op_Serv-24-User

The users of the guidance service shall be the vehicles drivers.

Op_Serv-25-Display Items

The guidance service of an A-SMGCS Level 2 shall display the following items to the user:

Vehicle position;


Optionally:

Reference points: holding points, stop bars (and other airfield lighting), RWY thresholds;

Fixed obstacles;

Other vehicle information (heading, etc), if required by the user.

Op_Serv-26-Position

The vehicle shall be seen in the correct position with respect to the aerodrome layout.

Note - This means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement.



CHAPTER 6 –Functional specification for A-SMGCS Level

2 services to ATCOs

6.1 Functional Breakdown for A-SMGCS Level 2 Services to ATCOs

The functions, that A-SMGCS shall perform, have been defined on the basis and through close examination of operational requirements. The operational requirements have been allocated to each function which implies that each function is specified by a list of functional requirements which have been derived from the operational requirements and which could thus be considered as the children of operational requirements.

These functions are independent from each other and linked by data flows. The description of the different functions and the links between each function represent the functional architecture of A-SMGCS which is presented in the following sections.

6.1.1 Functional Architecture (Level 2)

Figure 11: Ground Segment Functional Architecture (Level 2)



6.1.2 Provide Traffic Information

This function is in charge of providing the traffic information (position and identity of the mobiles). The traffic information can be collected from different systems:

Cooperative / non-cooperative surveillance sensors, approach surveillance systems;

Other systems.

From the analysis of the operational requirements, it can be concluded that:

A non-cooperative surveillance sensor is needed to detect any mobile on the surface, in particular intruders;

A cooperative surveillance sensor is needed to provide the identity of the participating mobiles on the surface;

An approach surveillance system will provide the information on departing / arriving aircraft in airside;

Other systems will provide any other traffic information required.

All the traffic information provided by these different sources need to be computed in order to obtain a consistent traffic information picture. This is performed by the "Data Fusion" function.

All the above functions are described in the following sections.

6.1.2.1 Functional Architecture

Figure 12: Functional Architecture

6.1.2.2 Acquisition of traffic information from non-cooperative surveillance sensors

At least one non-cooperative surveillance sensor is needed to detect any mobile on the surface, in particular intruders. This sensor (e.g. SMR) is able to provide the position of any mobile on the airport surface.

6.1.2.3 Acquisition of traffic information from cooperative surveillance sensors

At least one cooperative surveillance sensor (e.g. ADS-B / Mode S) is needed to provide the identity of the participating mobiles on the surface. The participating mobiles are those known by the aerodrome authority, and likely to move on the manoeuvring area. All the participating mobiles are required to



be cooperative, allowing the cooperative surveillance sensor to collect information about the mobiles, at least their identity.

6.1.2.4 Acquisition of traffic information from approach RDPS

The approach RDPS (Radar Data Processing System) will provide the information (at least position and identity) on airborne aircraft to be covered by A-SMGCS. In the future, this surveillance data could be collected from different sensors such as Automatic Dependant Surveillance.

6.1.2.5 Acquisition of other information about traffic

Other systems will provide any other traffic information (e.g. aircraft type, gate, etc), which may be required by local authority.

6.1.2.6 Data Fusion

The surveillance information provided by the different surveillance sensors is combined by a data fusion process to provide a comprehensive surveillance package.

6.1.3 Provide traffic context

This function is in charge of providing the traffic context (airport configuration, runways status, etc). The data on traffic context may be obtained automatically from other systems (MET systems, etc), or updated by a human operator. It means this function is composed of sub-functions as described in the following sections.

6.1.3.1 Functional Architecture

Figure 13: Functional Architecture

6.1.3.2 Acquisition of traffic context from other ground systems

This function is in charge of automatically providing the traffic context obtained from other systems (MET systems, etc).

6.1.3.3 Manual update of traffic context

This function is in charge of providing the traffic context (airport configuration, runways status, etc) updated by a human operator.

6.1.3.4 Update traffic context

The Traffic Context provided by the different sources (automatic or manual) is combined to provide a comprehensive traffic context package.



6.1.4 Conflicts / Infringements Detection

This function shall consider traffic information and traffic context information as input data, and generates C/I alert when a predefined Conflict/Infringement situation is detected according to predefined scenario provided in annex.

6.1.5 Interface with user

This function is the interface with the users. It is in charge of providing to the users all the surveillance data required and alerts generated by the service monitoring process.

6.1.6 Service monitoring

This function monitors the quality of service of A-SMGCS (equipment status, performances, operational failures, etc), and generate an alert when A-SMGCS must not be used for the intended operation.

6.2 Functional Requirements for A-SMGCS Level 2 services to ATCOs

This section lists for each function the functional requirements.

It could be noted that the operational requirements related to Design, Operational Range and Evolution which apply to each function are not allocated, and considered as "general principles" requirements.

In the same way, operational requirements, dealing with constraints from A-SMGCS environment, are not allocated to A-SMGCS functions because they do not refer to the functional specification but more to the technical characteristics of the A-SMGCS equipment.

6.2.1 Provide Traffic Information

6.2.1.1 Acquisition of traffic information from non-cooperative surveillance sensors

Fn_If-1-Data format

The data interchange with non-cooperative surveillance sensors shall be performed in a standardised format in order to ensure an adequate exchange of information.

Note - ASTERIX will be the European standard to be used for surveillance data.

Source: Ref. 5, 2.6.16.2

Fn-1-Mobile Position

The non-cooperative surveillance sensors shall determine the position of any mobile in its area of interest.

6.2.1.2 Acquisition of traffic information from cooperative surveillance sensors

Fn_If-2-Data format

The data interchange with cooperative surveillance sensors shall be performed in a standardised format in order to ensure an adequate exchange of information.




Source: Ref. 5, 2.6.16.2

Fn-2-Mobile Position

The cooperative surveillance sensors shall determine the position of any cooperative mobile in its area of interest.

Fn-3-Mobile Identity

The cooperative surveillance sensors shall determine the identity of any cooperative mobile in its area of interest.

Fn-73-Mobile Velocity

The cooperative surveillance sensors shall determine the velocity of any cooperative mobile in its area of interest.

6.2.1.3 Acquisition of traffic information from approach RDPS

Fn_If-3-Data format

The data interchange with approach RDPS shall be performed in a standardised format in order to ensure an adequate exchange of information.


Source: Ref. 5, 2.6.16.2

Fn-4-Aircraft Position

The approach RDPS shall determine the position of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft).

The approach RDPS shall determine the position of any airborne aircraft to be covered by A-SMGCS). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/Infringements.

Fn-5-Aircraft Identity

The approach RDPS shall determine the identity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft).

The approach RDPS shall determine the identity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/Infringements.

Fn-6-Provide a seamless transition



Fn-66-Aircraft Velocity

If possible, the approach RDPS shall determine the velocity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/Infringements.

6.2.1.4 Acquisition of other information about traffic

Fn_If-4-Data format



The data interchange with ground systems shall be performed in a standardised format in order to ensure an adequate exchange of information.

Note - ASTERIX will be the standard to be used for surveillance data.

Source: Ref. 5, 2.6.16.2

Fn-7-Other Information about Traffic

This function should optionally provide any other information about traffic from other ground systems and as required by the users.

6.2.1.5 Data Fusion

Fn_Perf-1-Reported Position Accuracy

At Level 1, the error in reported position shall be:

7.5 m on the manoeuvring area at a confidence level of 95%

12 m on the apron at a confidence level of 95%

Source: Ref. 9 3.2.4, Ref. 16 and Ref. 17

At Level 2, the error in reported position shall be:

7.5m at 95%

12m at 99%

When provided to Conflict/Infringement process i.e. on the runway protection area.

Source: Ref. 9 3.2.4 and Ref. 16

Fn_Perf-2-Reported Position Resolution



Fn_Perf-3-Aircraft level accuracy

The allowable error in the level of an aircraft when airborne shall be ±10m.


Fn_Perf-4-Update rate

The update rate of surveillance information shall be at least 1 per second.

Source: Ref. 5 4.2.4 and Ref. 9 3.2.4

Fn_Perf-5-Probability of Detection

The probability that an actual aircraft, vehicle, or object is detected and reported at the output of the Data Fusion shall be:

99.9% at minimum on the manoeuvring area

98% at minimum on the movement area

Source: Ref. 5 3.4.1.4 (a), Ref. 9 3.2.4, Ref. 16 and Ref. 17

Fn_Perf-6-Probability of False Detection

The probability that anything other than an actual aircraft, vehicle, or object is detected and reported at the output of the data fusion shall not exceed 0.1%.

Source: Ref. 5 3.4.1.4 (a) and Ref. 9 3.2.4

Fn_Perf-7-Probability of Identification



The probability that the correct identity of an aircraft, vehicle, or object is reported at the output of the surveillance element shall be:

99.9% at minimum on the manoeuvring area

98% at minimum on the apron

Note - The requirement only intends to specify the performance of the ground system.



Fn_Perf-8-Probability of False Identification

The probability that the identity reported at the output of the surveillance element is not the correct identity of the actual aircraft, vehicle, or object shall not exceed 0.1%.

Note - The requirement only intends to specify the performance of the ground system.



Fn_Perf-46-Reported Velocity Accuracy

The velocity shall be determined to the following accuracy:

Speed: <5m/s

Direction of movement consistent with alerting algorithms

Note - For reported velocity accuracy, ICAO specification recommends the following values:

Speed: +/- 1 Kt (0.5m/s)

Direction of movement: +/-1°.

According to the performance of existing tracking systems studied in other projects these values do not seem to be achievable.

Therefore, we recommend the values required by Ref. 9, 3.2.4: <5 m/s for speed and for direction of movement consistent with alerting algorithms.

Source: Ref. 5 4.1.1.8 and 4.1.1.10; Ref. 9 3.2.4

Fn_Perf-47-Target Report Velocity Resolution

The target report velocity resolution shall be:

Speed: ≤0,25m/s


Fn-9-Traffic Information

This function shall provide the complete Traffic Information.


6.2.2.1 Acquisition of traffic context from other ground systems

Fn_If-5-Data format

The data interchange with ground systems shall be performed in a standardised format in order to ensure an adequate exchange of information.



Note - ASTERIX will be the standard to be used for surveillance data.

Source: Ref. 5, 2.6.16.2

Fn-10-Traffic Context

This function shall provide information about traffic context (runways status, meteo, etc) from ground systems (MET systems, other ATS systems).

6.2.2.2 Manual update of traffic context


The Response Time to Operator Input:

Shall be 250 ms on average

Shall never exceed 500 ms

Source: Ref. 9 3.4.1.5, Ref. 17


This function shall update information about traffic context (airport layout, etc), which cannot be automatically updated.

6.2.2.3 Update traffic context


This function shall provide traffic context containing all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in its surveillance task.

Fn-13-Operational change

This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, rules...

Source: Ref. 5 3.5.12.2 and Ref. 9 1.8.3

Fn-72-Level 2 Traffic context

For the Conflict/Infringement detection, additional updated and correct traffic context information shall be provided to the system such as:

Airport Configuration: runways in use, runways status, restricted areas, etc.;

Applied procedures and working methods: LVP, multiple line-ups.

6.2.3 Conflicts / Infringements Detection

Fn_Perf-25-Probability of detection of an alert situation

The probability of detection of an alert situation should be greater than 99.9%.

Source: Ref. 5 4.5.1 and Ref. 9 3.3.2.1

Fn_Perf-26-Probability of false alert

The number of 3 false alerts (stage ALARM) should not be exceeded on a weekly basis.

Source: Ref. 14

Fn_Perf-27-Alert Response Time



Delays due to the control service should be kept small compared to other delays in the system, particularly with regard to human action, aircraft braking times, etc...

In the absence of a specific operational requirement, the proposed minimum performance figure for the ART should be 0.5s.


Fn-36-Alert report

The output of alert report which may be used by the HMI should at least include:

Type of alert;

Alert stage;

Time of alert;

Identity of target(s) in alert situation.


Fn-37-Alert hierarchy

Priorities should be established so as to ensure system logic performs efficiently. Conflict alerting priorities should be as follows:

Runway incursions.

Restricted area incursions.

Fn-38-Adaptation to local procedures

In order to efficiently assist ATCO, the automated A-SMGCS control service shall be configurable to adapt to local ATC procedures and working methods.

Fn-58-Conflicts/infringements on runway

This function shall detect the conflicts/infringements on runway provided in annex.

Fn-60-Restricted area incursions

This function shall detect the restricted area incursions caused by an aircraft (not vehicles) into an area such as closed TWY, ILS, or MLS critical area, to be defined locally for each aerodrome.

6.2.4 Interface with user

Fn_Perf-10-Situation assessment

The HMI shall permit rapid situation assessment.


Fn_Perf-11-Map Accuracy

The airport map accuracy shall provide for reference points the following values:

Thresholds - 1 m

Runway limits - 1 m

Holding positions - 0.5 m

Stop bars - 0.5 m

Runway exits - 0.5 m



Taxiway intersections - 0.5 m

Intersection limits - 0.5 m

Switchable centre line light block limits - 2.5 m

Parking positions - 0.5 m

Source: Ref. 5, Chapter 3, table 3-1

Fn_Perf-12-Display Resolution

The Display Resolution shall be consistent with the Display Position Accuracy.


Fn_Perf-13-Position Registration Accuracy

The Position Registration Accuracy should not appreciably degrade the accuracy of the information it receives. (In fact, it is to be expected that the only degradation of accuracy attributable to the HMI will be that caused by quantisation errors).

It should be noted that conversion between various co-ordinate systems may introduce significant inaccuracies and should be avoided where possible.


Fn_Perf-14-Target Display Latency

The Target Display Latency:



Source: Ref. 9 3.4.1.3 and Ref. 17

Fn_Perf-15-Information Display Latency

For safety critical information, the Information Display Latency:



For information that is not safety critical, these values can be relaxed.







Fn_Perf-17-User workload

The HMI should ensure a level of user workload which is consistent with efficient and effective activity.

Note - the user workload has to be analysed in details with users.

Source: Ref. 5 2.6.14.1, Ref. 9 2.5.2.1

Fn_Perf-18-Entry means

The HMI should employ user friendly and familiar data entry means.



Note - Data entry means have to be designed as required by users at each local implementation.

Source: Ref. 5 2.6.15.2. (c) and Ref. 9 2.5.2.1


The HMI should minimise the number of input actions required.

Source: Ref. 5 2.6.15.3 and Ref. 9 2.5.2.1

Fn_Perf-20-Ambient light

The HMI display shall be capable of being viewed in all ambient light levels appropriate to the user environment.

Source: Ref. 5 2.6.15.4, and Ref. 9 2.5.2

Fn_Perf-61-Alert Continuity

This function should continuously display Conflict/Infringement Alert while the conflict is detected.

Source: Ref. 5 3.4.5.14

Fn-14-Display Airport traffic situation

This function shall be capable of displaying the complete airport traffic situation.

Fn-15-Display Mobile Position

Each mobile shall be seen in the correct position with respect to the aerodrome layout and other traffic.


Fn-16-Display Alerts

This function shall display alerts generated by the service monitoring process.


This function shall display alerts generated by the service monitoring process and by the Conflict/Infringement detection process.


Fn-17-Display configuration

The HMI shall allow the user to configure the display (e.g. range scale selection, pan/zoom, brightness, map overlays).


Fn-18-Manual Label Attribution

The surveillance service shall provide to the user the ability to manually put the right callsign in the label associated to a vehicle equipped with mobile cooperative equipment used for different vehicles.

Fn-19-Essential tasks

An A-SMGCS should not inhibit control staff from carrying out their other essential tasks.

Source: Ref. 5 3.5.18.6

Fn-20-User Decisions



The HMI shall support the user to make the decisions on those actions for which he/she is responsible.

Source: Ref. 5 2.6.15.2. (b), and Ref. 9 2.5.2.1

Fn-21-Balance

The HMI shall maintain a balance between human and machine functions.

Source: Ref. 5 2.6.15.2. (a), and Ref. 9 2.5.2.1

Fn-22-Manual operation

The HMI shall permit full manual operation in the event of a failure of an automatic function or whenever manual operation is required.


Fn-23-Harmonisation

The HMI should be harmonised where possible with existing ATM HMI.

Note - ATM HMI may be specific to each local implementation.



This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, rules, etc.

Source: Ref. 5 3.5.12.2, Ref. 9 1.8.3

Fn-25-Operational Conditions

The A-SMGCS HMI design shall take into account the working environment of the user under various operational conditions. In this respect the HMI shall be adaptable to the various circumstances of the user. As an example, good visibility operations with high traffic throughput will require a different A-SMGCS set-up than that required for low visibility operations with reduced throughput.


Fn-26-Integrate vicinity airborne traffic



6.2.5 Service monitoring

Fn-8-Failure Alerts



Fn-27-Equipment status

This function shall monitor the operational status of all A-SMGCS equipment, and shall generate alerts when the system must not be used for the intended operation.

Fn-28-Performance



This function shall monitor the performance of A-SMGCS such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service.

Fn-29-Validation of data

This function shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation.

Fn-30-Operationally significant failures

This function shall clearly indicate operationally significant failures in the system to the control authority and any affected user.

Fn-31-Back-up




CHAPTER 7 –Functional Specification for A-SMGCS Level

2 service to Vehicle Drivers

7.1 Functional Breakdown for A-SMGCS Level 2 services to Vehicle Drivers

The functions, that A-SMGCS shall perform, have been defined on the basis and through close examination of operational requirements. The operational requirements have been allocated to each function which implies that each function is specified by a list of functional requirements which have been derived from the operational requirements and which could thus be considered as the children of operational requirements.

These functions are independent from each other and linked by data flows. The description of the different functions and the links between each function represent the functional architecture of A-SMGCS which is presented in the following sections.

7.1.1 Functional Architecture

Figure 14: Functional Architecture for Vehicles

The following data flow chart presents the functional architecture of the A-SMGCS Level 2. For each connection between two functions, the information exchanged is defined.



7.1.2 Provide Vehicle Information

This function is in charge of providing the vehicle position and any other vehicle information (heading, etc), if required. The vehicle position can be collected from GNSS receiver for instance.


This function is in charge of providing the traffic context information required for the guidance service (Airport map updates). The traffic context data may be periodically updated by a human operator.

7.1.4 Interface with driver

This function is the interface with the driver. It is in charge of providing to the drivers all the guidance data required and alerts generated by the guidance service monitoring process.

7.1.5 Guidance Service Monitoring

This function monitors the quality of service of A-SMGCS guidance service for driver (equipment status, performances, operational failures, etc), and generates an alert when A-SMGCS must not be used for the guidance operation.

7.2 Functional Requirements for A-SMGCS Level 2 services to Vehicle Drivers

This section lists for each function the functional requirements. It could be noted that the operational requirements related to Design, Operational Range and Evolution which apply to each function are not allocated, and considered as "general principles" requirements.

In the same way, operational requirements, dealing with constraints from A-SMGCS environment, are not allocated to A-SMGCS functions because they do not refer to the functional specification but more to the technical characteristics of the A-SMGCS equipment.

7.2.1 Provide Vehicle Information

Fn_Perf-28-Position Accuracy

The error in reported position shall be 12 m (95% level of confidence).

Source: Ref. 17

Fn_Perf-29-Reported Position Resolution


Fn_Perf-30-Update rate

The update rate of vehicle information shall be at least 1 per second.

Fn-59-Vehicle Information

The function shall provide own-vehicle position. Optionally state vector information (e.g. heading) may also be provided.










This function shall update information about traffic context: - Airport layout, - Reference points (optionally).

7.2.3 Interface with driver

Fn_Perf-32-Situation assessment

The HMI shall permit rapid position assessment.


Fn_Perf-33-Map Accuracy

The minimum airport map accuracy shall provide for reference points the following values:

Thresholds - 1 m

Runway limits - 1 m

Holding positions - 0.5 m

Stop bars - 0.5 m

Runway exits - 0.5 m

Taxiway intersections - 0.5 m

Intersection limits - 0.5 m

Switchable centre line light block limits - 2.5 m

Parking positions - 0.5 m

Source: Ref. 5, Chapter 3, table 3-1

Fn_Perf-34-Display Resolution

The Display Resolution shall be consistent with the Display Position Accuracy.


Fn_Perf-35-Position Registration Accuracy

The Position Registration Accuracy should not appreciably degrade the accuracy of the information it receives. (In fact, it is to be expected that the only degradation of accuracy attributable to the HMI will be that caused by quantisation errors).

It should be noted that conversion between various co-ordinate systems may introduce significant inaccuracies and should be avoided where possible.


Fn_Perf-36-Target Display Latency

The Target Display Latency:






Fn_Perf-37-Information Display Latency

For safety critical information, the Information Display Latency:



For information that is not safety critical, these values can be relaxed.







Fn_Perf-39-Driver workload

The HMI should ensure a level of driver workload which is consistent with efficient and effective activity.

Note - the driver workload has to be analysed in details with drivers.

Source: Ref. 5 2.6.14.1, Ref. 9 2.5.2.1

Fn_Perf-40-Entry means

The HMI should employ user friendly and familiar data entry means.

Note - Data entry means have to be designed as required by users at each local implementation.


The HMI should minimise the number of input actions required.

Fn_Perf-42-Ambient light

The HMI display shall be capable of being viewed in all ambient light levels appropriate to the user environment.

Source: Ref. 5 2.6.15.4 and Ref. 9 2.5.2

Fn-40-Display Items

This function shall display the following items to the user: -Vehicle position;


Optionally:

Reference points: holding points, stop bars (and other airfield lighting);

RWY thresholds, etc;

Fixed obstacles.

Fn-41-Position

The vehicle shall be seen in the correct position with respect to the aerodrome layout.


Fn-42-Display Alerts



This function shall display alerts generated by the guidance service monitoring process.

Fn-43-Display configuration

The HMI shall allow the user to configure the display capabilities (e.g. range scale selection, pan/zoom, brightness, map overlays).


Fn-44-Essential tasks

An A-SMGCS should not inhibit drivers from carrying out their other essential tasks.

Source: Ref. 5 3.5.18.6

Fn-45-User Decisions

The HMI shall support the user to make the decisions on those actions for which he/she is responsible.

Source: Ref. 5 2.6.15.2. (b), and Ref. 9 2.5.2.1

Fn-46-Balance

The HMI shall maintain a balance between human and machine functions.

Source: Ref. 5 2.6.15.2. (a), and Ref. 9 2.5.2.1


This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, or rules.

7.2.4 Guidance Service Monitoring

Fn_Perf-49-Integrity

A-SMGCS shall preclude failures that result in erroneous data provided to the users.

Fn-48-Equipment status

This function shall monitor the operational status of all guidance service equipment, and shall generate alerts when the system must not be used for the intended operation.

Fn-49-Performance

This function shall monitor the performance of the guidance service such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service.

Fn-50-Validation of data

This function shall perform a continuous validation of data provided to the user and timely alert the driver when the system must not be used for the intended operation.

Fn-51-Operationally significant failures

This function shall clearly indicate operationally significant failures in the system to the driver and any affected user.

Fn-52-Back-up

This function shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur.



Fn-57-Failure Alerts




ANNEX 1 –Conflicts / infringements to be detected by the runway safety net



Reference Aircraft Conflicting Mobile INFORMATION ALARM

Unidentified mobile on the runway protection area Yes No

Identified vehicle on an open runway Yes No

Aircraft proceeding to a closed runway aircraft on runway protection area

surface

Departing aircraft lining-up or taking-off

or arriving aircraft (< T1 from threshold)

No Reference

Aircraft

Aircraft departing on the runway in the wrong direction When lining-up when taking-off

a mobile (aircraft or vehicle) is on the runway protection

area surface

arriving aircraft < T1 from

threshold

the arriving aircraft < T2 from threshold, until the

arriving aircraft has passed the mobile (mobile

behind the arriving aircraft)

a slower preceding departing aircraft which has not

crossed the end of the runway-in-use or has not started a

turn1


threshold arriving aircraft < T2 from threshold

Arriving Aircraft

a preceding arriving aircraft which has not cleared the

protection area2


threshold arriving aircraft < T2 from threshold

Departing Aircraft a mobile (aircraft or vehicle) is on the runway protection

area surface and not behind the departing aircraft3

departing aircraft is not yet taking-

off (speed < 50 knots) departing aircraft is taking-off (speed > 50 knots)

Note : The air boundary is defined as a flight time to threshold : Non-LVO : T1 = 30’’, T2 = 15’ / LVO : T1 = 45’’, T2 = 30’

Table 2: Conflicts / infringements to be detected at each individual runway

1 See specific rules when reduced spacing procedures are in force

2 See specific rules when reduced spacing procedures are in force

3 See specific rules when multiple line-up is applied



Reference Aircraft Conflicting Mobile INFORMATION ALARM

an aircraft is lined-up on the other runway Yes No

an aircraft is taking off on the other runway Yes No

an aircraft is landing on the other runway Yes No Lining up aircraft

arriving aircraft on short final (<IRT2) on the other runway Yes No

Arriving aircraft on long final (<IRT1) on the other runway Yes No

arriving aircraft on short final (<IRT2) on the other runway No Yes

an aircraft is landing on the other runway + converging Yes No Arriving aircraft on long final (<IRT1)

an aircraft is taking off on the other runway + converging Yes No

arriving aircraft on short final (<IRT2) on the other runway No Yes

an aircraft is landing on the other runway + converging No Yes Arriving aircraft on short final (<IRT2)

an aircraft is taking off on the other runway + converging No Yes

Table 3: Additional conflicts / infringements to be detected when two runways are intersecting

Note: It could be required to use Time To Threshold T1 and T2 different from those defined previously. We will call them Intersecting Runways Time To Threshold IRT1 and IRT2. They could be defined as following:

Long final: Aircraft on final between IR T1 and IR T2;

Short final: Aircraft on final between IR T2 and Threshold over-flight.



ANNEX 2 –Relationships between requirements

The following matrix presents the relationships between requirements. The columns represent the operational requirements and the lines represent the functional requirements. A coloured box indicates an operational requirement is the parent of the functional one.



A2.1 A-SMGCS Level 1 – Surveillance Service

Table 4: A-SMGCS Level 1 – Surveillance Service



Table 5: A-SMGCS Level 1 – Surveillance Service



A2.2 A-SMGCS Level 2 – Control Service

The table depicts the specific functional requirements required for the Control Service (conflict/infringement detection), this includes several enhancements to Level 1 requirements (e.g. accuracy Fn_Perf-1)

Table 6: A-SMGCS Level 2 – Control Service



A2.3 A-SMGCS Level 2 – Guidance Service to Vehicle Drivers (optional)

Table 7: A-SMGCS Level 2 – Guidance Service to Vehicle Drivers (optional)



REFERENCES

Ref. 1 EUROCONTROL definition of A-SMGCS Implementation Levels, Edition 1.2,

30/06/2010

Ref. 2 EUROCONTROL A-SMGCS Level 1 Operational Concept and Requirements,

Edition 2.1, 30/06/2010

Ref. 3 EUROCONTROL A-SMGCS Level 2 Operational Concept and Requirements,

Edition 2.1, 30/06/2010

Ref. 4 ICAO Manual of Surface Movement Control and Guidance Systems (SMGCS)

Doc 9476-AN/927 First Edition 1986

Ref. 5 ICAO Manual on Advanced Surface Movement Control and Guidance Systems

(A-SMGCS), Doc 9830, First Edition 2004

Ref. 6 ICAO Annex 14 – Aerodrome Design and Operations, Volume I, Fifth Edition, July

2009

Ref. 7 ICAO Doc 4444 – Procedures for Air Navigation Services (PANS) Air Traffic

Management (ATM), Fifteenth Edition 2007

Ref. 8 ICAO Doc 7030 - European Supplementary Procedures, Fifth Edition 2008

Ref. 9 EUROCAE Minimum Aviation System Performance Specifications (MASPS) for A-

SMGCS (Level 1 and 2), Edition ED-87B, January 2008, including ED-87B

amendment No 1 of January 2009

Ref. 10 EUROCAE Minimum Operational System Performance Specifications (MOPS) for

Surface Movement Radar sensor systems for use in A-SMGCS, Edition ED-116,

January 2004

Ref. 11 ICAO – Approval of a Proposal for Amendment of Regional Supplementary

Procedures – Doc 7030/5 (Serial No.: EUR/NAT-S 08/08 – EUR 6-5) of

12/06/2009; and

Open Proposal for Amendment to the Regional Supplementary Procedures – Doc

7030/5 (SUPPs) (Serial No: EUR/NAT-S 08/09 – EUR 6-5) related to low visibility

procedures.

Ref. 12 EUROCONTROL Airport Operations Team, A-SMGCS Concept Justification and

User Requirements, AOT/10 WP3, June 2002

Ref. 13 European Commission – Swedish CAA (LVF), NUP II NUPII Technical



Verification, and Validation of ADS-B for A-SMGCS version 1.0, 16/12/2002.

Ref. 14 EUROCONTROL Preliminary Safety Case for A-SMGCS Levels 1 and 2, Edition

2.1, 30/06/2010

Ref. 15 EUROCONTROL Human Factor Case for A-SMGCS Levels 1 and 2, Edition 1.2,

30/06/2010

Ref. 16 EVA Project Final Validation Report for A-SMGCS Levels 1 and 2, version 1.0,

27/11/2006

Ref. 17 Final Validation Report for A-SMGCS Levels 1 and 2 at Paris CDG, Volume 1,

version 1.1, 28/06/2006, and Final Validation Report for A-SMGCS Levels 1 and 2

at Paris CDG, Volume 2, version 1.0, 23/05/2006

Ref. 18 ICAO Doc 9157 – Aerodrome Design Manual, Part 6 – Frangibility, First Edition

2006

Ref. 19 European Directive on Radio equipment and Telecommunications Terminal

Equipment 1999/5/EC of 9 March 1999

Ref. 20 ICAO Doc 9870 Manual on the Prevention of Runway Incursions, First Edition,

2007

Ref. 21 EUROCONTROL Functional Requirements for A-SMGCS Implementation Level 1,

Edition 2.1, 30/06/2010



GLOSSARY

This section provides the explanation of terms required for a correct understanding of the present document. Most of the following explanations are drawn from the A-SMGCS manual Ref. 5, the ICAO Annex 14 Ref. 6, or the EUROCAE MASPS for A-SMGCS Ref. 9, in that case it is indicated in the definition. A-SMGCS, Ref. 5 definitions are used as a first option. In general, other definitions are only used where there is no ICAO definition. If not, it is explained why another definition is preferred to the ICAO one.

Advanced Surface Movement Guidance and Control Systems (A-SMGCS)

Ref. 5 definition

Systems providing routing, guidance, surveillance and control to aircraft and affected vehicles in order to maintain movement rates under all local weather conditions within the Aerodrome Visibility Operational Level (AVOL) whilst maintaining the required level of safety.

Aerodrome


A defined area on land or water (including any buildings, installations, and equipment) intended to be used either wholly or in part for arrival, departure and surface movement of aircraft.

Aerodrome movement

Ref. 5 definition addresses only aircraft movement, we extended the definition to all mobiles.

The movement of a mobile (aircraft or vehicle) on the movement area.

Aerodrome Visibility Operational Level (AVOL)

Ref. 5 definition

The minimum visibility at or above which the declared movement rate can be sustained.

Airport authority

Ref. 5 definition

The person(s) responsible for the operational management of the airport.

Alert

Ref. 5 definition

An indication of an existing or pending situation during aerodrome operations, or an indication of abnormal A-SMGCS operation, that requires attention/action.

Alert Situation

Ref. 9 definition

Any situation relating to aerodrome operations which has been defined as requiring particular attention or action.

Apron


A defined area on a land aerodrome, intended to accommodate aircraft for purposes of loading or unloading passengers, mail or cargo, fuelling, parking or maintenance.

A-SMGCS capacity



Ref. 5 definition

The maximum number of simultaneous movements of aircraft and vehicles that the system can safely support within an acceptable delay commensurate with the runway and taxiway capacity at a particular aerodrome.

Conflict

Ref. 5 definition

A situation when there is a possibility of a collision between aircraft and/or vehicles.

Control

Ref. 5 definition

Application of measures to prevent collisions, runway incursions and to ensure safe, expeditious and efficient movement.

Cooperative mobile

“Cooperative target” Ref. 9 definition in which “target” is replaced by “mobile” (see mobile definition)

Mobile which is equipped with systems capable of automatically and continuously providing information including its Identity to the A-SMGCS.

Note - as several cooperative surveillance technologies exist, a mobile is cooperative on an aerodrome only if the mobile and the aerodrome are equipped with cooperative surveillance technologies which are interoperable.

Cooperative surveillance

The surveillance of mobiles is cooperative when a sensor, named cooperative surveillance sensor, collects information about the mobiles from an active element of the transponder type which equips the mobiles. This technique allows collecting more mobile parameters than the non-cooperative surveillance, for instance the mobiles identity.

The cooperative surveillance may be:

Either dependant on the cooperative mobile, when the mobile automatically generates the information and transmits it to the surveillance sensor, for instance via ADS-B;

Or Non-dependant on the cooperative mobile, when the mobile is interrogated by the surveillance sensor, for instance Mode S Multilateration.

Data Fusion

Ref. 9 definition

A generic term used to describe the process of combining surveillance information from two or more sensor systems or sources.

False Alert

Ref. 9 definition

Alert which does not correspond to an actual alert situation.

Note - It is important to understand that it refers only to false alerts and does not address nuisance alerts (i.e. alerts which are correctly generated according to the rule set but are inappropriate to the desired outcome).

Guidance

Ref. 5 definition

Facilities, information, and advice necessary to provide continuous, unambiguous, and reliable information to pilots of aircraft and drivers of vehicles to keep their aircraft or vehicles on the surfaces and assigned routes intended for their use.



Identification

Ref. 5 definition

The correlation of a known aerodrome movement callsign with the displayed target of that mobile on the display of the surveillance system.

Identity

“Aircraft identification” Ref. 7 definition extended to all mobiles.

A group of letters, figures or a combination thereof which is either identical to, or the coded equivalent of, the mobile call sign to be used in air-ground communications, and which is used to identify the mobile in ground-ground air traffic services communications.

Incursion

Ref. 5 definition

The unauthorized entry by an aircraft, vehicle, or obstacle into the defined protected areas surrounding an active runway, taxiway or apron.

Intruder

Any mobile which is detected in a specific airport area into which it is not allowed to enter.

Manoeuvring area


That part of an aerodrome to be used for the take-off, landing and taxiing of aircraft, excluding aprons.

Mobile

A mobile is either an aircraft or a vehicle.

Note - when referring to an aircraft or a vehicle, and not another obstacle, the term “Mobile” will be preferred to “Target”. The term “Target” will only be used when considering an image of a mobile or other obstacle displayed on a surveillance screen.

Modularity

Ref. 5 definition

Capability of a system to be enhanced by the addition of one or more modules to improve its technical or functional performance.

Movement area

Ref. 5, Ref. 6 and Ref. 7 definition

That part of an aerodrome to be used for the take-off, landing and taxiing of aircraft, consisting of the manoeuvring area and apron(s).

Non-Cooperative mobile

“Non-cooperative target” Ref. 9 definition in which “target” is replaced by “mobile” (see mobile definition)

Mobile which is not equipped with systems capable of automatically and continuously providing information including its Identity to the A-SMGCS.

Non-Cooperative surveillance

The surveillance of mobiles is non-cooperative when a sensor, named non-cooperative surveillance sensor, detects the mobiles, without any action on their behalf. This technique allows determining the position of any mobile in the surveillance area and in particular to detect intruders. Examples of non-cooperative surveillance sensors are the Primary Surveillance Radars.

Normal Visibility



Visibility conditions sufficient for personnel of control units to exercise control over all traffic on the basis of visual surveillance (correspond to visibility condition 1 defined by ICAO Ref. 5).

Nuisance Alert

Ref. 9 definition

Alert which is correctly generated according to the rule set but are inappropriate to the desired outcome.

Obstacle

Ref. 5 and Ref. 6 definition extended to all mobiles.

All fixed (whether temporary or permanent) and mobile obstacles, or parts thereof, that are located on an area intended for the surface movement of mobiles or that extend above a defined surface intended to protect aircraft in flight.

Participating mobile

Mobile whose identity is known by the aerodrome authority and likely to move on airport movement areas. As illustrated below, a participating mobile is either cooperative or non-cooperative.

Figure 15: Types of Mobiles

Protection area

A protection area is a virtual volume around a runway, a restricted area or a mobile. This protection area is used to detect an alert situation. For instance, an alert situation is detected when a mobile is on a runway and one or more mobiles enter the runway protection area.

Reduced Visibility

Visibility conditions insufficient for personnel of control units to exercise control over all traffic on the basis of visual surveillance (correspond to visibility conditions 2, 3, and 4 defined by ICAO Ref. 5).

Restricted Area

Aerodrome areas where the presence of an aircraft or a vehicle is permanently or temporarily forbidden.

Route

Ref. 5 definition

A track from a defined start point to a defined endpoint on the movement area.

Routing

Ref. 5 definition

ALL MOBILES

INTRUDERS

Cooperative mobiles

Non cooperative mobiles

PARTICIPATING MOBILES



The planning and assignment of a route to individual aircraft and vehicles to provide safe, expeditious, and efficient movement from its current position to its intended position.

Runway Incursion

Ref. 20 definition

Any occurrence at an aerodrome involving the incorrect presence of an aircraft, vehicle, or person on the protected area of a surface designated for the landing and take off of aircraft

Stand

Ref. 5 definition

A stand is a designated area on an apron intended to be used for the parking of an aircraft.

Surveillance

Ref. 5 definition

A function of the system which provides identification and accurate positional information on aircraft, vehicles, and obstacles within the required area.

Target

Ref. 5 definition (this definition has been preferred to the Ref. 9 definition)

An aircraft, vehicle, or other obstacle, which image is displayed on a surveillance display.

Note - when referring to an aircraft or a vehicle, and not another obstacle, the term “Mobile” will be preferred to “Target”. The term “Target” will only be used when considering an image of a mobile or other obstacle displayed on a surveillance screen.



ABBREVIATIONS

ADS Automatic Dependent Surveillance

ADS-B Automatic Dependent Surveillance Broadcast

ANSP Air Navigation Service Provider

AMAN Arrival Manager

AOP Airport Operations Programme

AOPG ICAO Aerodrome Operations Group

AOT Airport Operation Team

A-SMGCS Advanced Surface Movement Guidance and Control Systems

ATC Air Traffic Control

ATCO ATC Controller

ATM Air Traffic Management

ATS Air Traffic Services

ATSU Air Traffic Service Unit

AVOL Aerodrome Visibility Operational Level

CDM Collaborative Decision Making

CFMU Central Flow Management Unit

CNS Communication Navigation Surveillance

DMAN Departure Manager

EC European Commission

ECAC European Civil Aviation Conference

ESARR Eurocontrol Safety Regulatory Requirements

EUROCAE European Organisation for Civil Aviation Equipment

FAA Federal Aviation Administration

GBAS Ground based Augmentation System

GNSS Global Navigation Satellite System

GPS Global Positioning System

HMI Human Machine Interface

ICAO International Civil Aviation Organisation

LVO Low Visibility Operations

LVP Low Visibility Procedures

MASPS Minimum Aviation System Performance Specification

MLS Microwave Landing System

MOPS Minimum Operational Performance Specification

R/T Radio Telephony



RVR Runway Visual Range

SMGCS Surface Movement Guidance and Control Systems

SMR Surface Movement Radar

SRC Safety Regulation Commission

TMA Terminal Manoeuvring Area

functional requirements a-smgcs level 2 - eurocontrol · this document is the eurocontrol...

Documents