11 asmgcs functional spec impl level2

8/8/2019 11 Asmgcs Functional Spec Impl Level2

1/83

EUROPEAN ORGANISATION FOR THE SAFETY OFAIR NAVIGATION

EUROCONTROL

EUROPEAN AIR TRAFFIC MANAGEMENT PROGRAMME

Functional Specificationfor A-SMGCS

Implementation Level II

DAP / APT

Edition : 1.0Edition Date : 17/05/2004Status : Released IssueClass : General Public


2/83

DOCUMENT IDENTIFICATION SHEET

DOCUMENT DESCRIPTION

Document Title

Functional Specification for A-SMGCS Implementation Level II

EWP DELIVERABLE REFERENCE NUMBER:

PROGRAMME REFERENCE INDEX: EDITION: 1.0

EDITION DATE: 17/05/2004Abstract

Keywords

CONTACT PERSON: Paul Adamson TEL: UNIT: DAP / APT

DOCUMENT STATUS AND TYPE

STATUS CLASSIFICATION

Working Draft General Public

Draft EATMP

Proposed Issue Restricted

Released Issue

ELECTRONIC BACKUP

INTERNAL REFERENCE NAME:

HOST SYSTEM MEDIA SOFTWARE

Microsoft Windows Type: Hard disk

Media Identification:


3/83

Functional Specification for A-SMGCS ImplementationLevel II

DSA / AOP

Edition: 1.0 Page iii

DOCUMENT APPROVAL

The following table identifies all management authorities that have successively approvedthe present issue of this document.

AUTHORITY NAME AND SIGNATURE DATE

A-SMGCS

Project Manager Paul Adamson


4/83

DSA / AOP Functional Specification for A-SMGCSImplementation Level II

Page iv Edition: 1.0

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the presentdocument.

EDITION DATE REASON FOR CHANGE

SECTIONSPAGES

AFFECTED

0.a 16/05/2003 First draft

0.b 22/05/2003 Comments from 21/05/2003 videoconference all

0.c 04/08/2003 Comments from 05/06/2003 progress meeting all

0.d 10/05/2004 Comments from 06/04/2004 coordinationmeeting

Annex B

1.0 17/05/2004 Change of classification to General Public


5/83


DSA / AOP

Edition: 1.0 Page v

TABLE OF CONTENTS

1. INTRODUCTION...................................................................................................1

1.1 Scope of the document.............................................................................................................1

1.2 Structure of the document.........................................................................................................1

1.3 Reference Documents ..............................................................................................................2

1.4 Acronyms ..................................................................................................................................2

1.5 Explanation of terms .................................................................................................................3

1.6 Performance parameters ..........................................................................................................8

2. METHODOLOGY................................................................................................12

2.1 Need for a methodology..........................................................................................................12

2.2 Service level............................................................................................................................12

2.3 Functional level .......................................................................................................................14

2.4 Architectural level ....................................................................................................................14

2.5 Traceability along the process ................................................................................................15

2.6 Examples of allocation of an operational requirement to a function.......................................16

2.7 Scope of the functional specification.......................................................................................17

2.8 Validation Activity ....................................................................................................................18

3. ACTORS.............................................................................................................19

3.1 ATCO ......................................................................................................................................19

3.2 Other operators .......................................................................................................................20

3.3 Pilot .........................................................................................................................................20

3.4 Vehicle Driver ..........................................................................................................................21

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


6/83


Page vi Edition: 1.0

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

5. OPERATIONAL REQUIREMENTS ....................................................................26

5.1 General principles ...................................................................................................................26

5.2 Surveillance Service................................................................................................................32

5.3 Control Service........................................................................................................................38

5.4 Guidance Service....................................................................................................................43

6. FUNCTIONAL SPECIFICATION FOR A-SMGCS LEVEL II SERVICES TOCONTROLLERS.................................................................................................47

6.1 Functional Breakdown for A-SMGCS level II services to controllers......................................47

6.2 Functional Requirements for A-SMGCS level II services to controllers .................................51

7. FUNCTIONAL SPECIFICATION FOR A-SMGCS LEVEL II SERVICES TODRIVERS ............................................................................................................61

7.1

Functional Breakdown for A-SMGCS level II services to drivers............................................61

7.2 Functional Requirements for A-SMGCS level II services to drivers .......................................62

ANNEX A : INDEX ....................................................................................................67

ANNEX B : CONFLICTS / INFRINGEMENTS TO BE DETECTED BY THERUNWAY SAFETY NET.....................................................................................75

ANNEX C : RELATIONSHIPS BETWEEN REQUIREMENTS..................................77


7/83


DSA / AOP

Edition: 1.0 Page 1

1. INTRODUCTION

1.1 Scope of the document

TheEUROCONTROL A-SMGCS project aims at defining pragmatic implementationsteps for A-SMGCS. The first step named A-SMGCS Level I focuses on theimplementation of automated surveillance. Its associated operational concept andrequirements are presented in [D3]. On the basis of the analysis of the users needspresented in [D3], the functional specification for A-SMGCS Implementation Level Ihas been developed in [D5].

The second step named A-SMGCS Level II aims at complementing surveillanceservice with a control service which provides a runway safety net and prevents

incursions into restricted areas. A guidance service may also be provided to thevehicles driver as an option. Its associated operational concept and requirementsare presented in [D4]. On the basis of the analysis of the users needs presented in[D4], the functional specification for A-SMGCS Implementation Level II has beendeveloped in the present document.

EUROCONTROL A-SMGCS Project Strategy and definition of ImplementationLevels are included in [D1] and [D2].

Note: The present document contains a draft version of the requirements in order tosupport validation activity. The document will be updated according to the validationresults.

1.2 Structure of the document

Introduction

Describes, in Chapter 1, the purpose of this document, its structure, the referencedocuments and an explanation of terms used throughout the document

Methodology

Chapter 2 reminds the methodology applied to specify A-SMGCS and explain howthe 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 II.

Functional Specification for A-SMGCS level II services to Controllers

Chapter 6 presents the Functional Specification for A-SMGCS level II services toControllers : surveillance and control services.

Functional Specification for A-SMGCS level II services to Drivers


8/83


Page 2 Edition: 1.0

Chapter 7 presents the Functional Specification for A-SMGCS level II services toDrivers : guidance service.

Annex A :

Annex A is the document index.

Annex B :

Annex B summaries the conflicts / infringements to be detected by the runwaysafety net and associated alerts.

Annex C :

Annex C presents the relationships between operational and functionalrequirements.

1.3 Reference Documents

[D1] A-SMGCS Project Strategy

[D2] Definition of A-SMGCS Implementation Levels

[D3] A-SMGCS Level I Operational Concept and Requirements

[D4] A-SMGCS Level II Operational Concept and Requirements

[D5] Functional Specification for A-SMGCS Implementation Level I

[ICAO-SMGCS] ICAO Manual of Surface Movement Control and Guidance Systems(SMGCS) doc 9476-AN/927 First Edition 1986

[ICAO-A-SMGCS] ICAO European Manual on Advanced Surface Movement Control and

Guidance Systems (A-SMGCS) AOPG, Final Draft, Nov 2001

[ICAO-Annex14] ICAO Annex 14, Volume I, Chapter 8

[ICAO-4444] ICAO Doc 4444-RAC/501 RULES OF THE AIR AND AIR TRAFFICSERVICES

[ICAO-7030] ICAO Doc 7030- European Supplementary Procedures

[EUROCAE-MASPS] EUROCAE WG-41, MASPS for A-SMGCS, Edition ED-87A, January2001

[EUROCAE-MOPS] EUROCAE WG-41, MOPS for SMR sensor systems for use in A-SMGCS

[AOPG-Procedures] ICAO AOPG2, Proposed Implementation of A-SMGCS Procedures andamendments to ICAO Documentation, 2002

[AOP-Req] EUROCONTROL Airport Operations Group, Advanced SurfaceMovement Guidance and Control Systems Concept Justification andUser Requirements, AOT/10 WP3, June 2002

[NUP II] European Commission Swedish CAA (LVF), NUP II Enhanced AirportSurface Movement Safety OSED, 2002

1.4 Acronyms

ADP Aroport de Paris


9/83


DSA / AOP

Edition: 1.0 Page 3

ADS Automatic Dependent Surveillance

ADS-B Automatic Dependent Surveillance Broadcast

ANSPs Air Navigation Service Provider

AMAN Arrival Manager

AOP Airport Operations Unit

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

AVOL Aerodrome Visibility Operational LevelCDM Collaborative Decision Making

CFMU Central Flow Management Unit

CNS Communication Navigation Surveillance

DMAN Departure Manager

EC European Commission

ECAC European Civil Aviation Conference

EUROCAE European Organisation for Civil Aviation Equipment

FAA Federal Aviation Administration

HMI Human Machine Interface

ICAO International Civil Aviation Organisation

LVP Low Visibility Procedures

R/T Radio Telephony

RWY Runway

SMGCS Surface Movement Guidance and Control Systems

SMR Surface Movement Radar

TMA Terminal Manoeuvring Area

1.5 Explanation of terms

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

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

[ICAO-A-SMGCS] definition

Systems providing routing, guidance, surveillance and control to aircraft andaffected vehicles in order to maintain movement rates under all local weather


10/83


Page 4 Edition: 1.0

conditions within the Aerodrome Visibility Operational Level (AVOL) whilstmaintaining the required level of safety.

Aerodrome

[ICAO-Annex14] and [ICAO-A-SMGCS] definition

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

Aerodrome movement

[ICAO-A-SMGCS] definition addresses only aircraft movement, we extended the definition to allmobiles.

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

Aerodrome Visibility Operational Level (AVOL)


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

Airport authority


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

Alert


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

[EUROCAE-MASPS] definition

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

Apron


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

A-SMGCS capacity


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

Conflict


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

Control


11/83


DSA / AOP

Edition: 1.0 Page 5


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

Cooperative mobile

Cooperative target [EUROCAE-MASPS] definition in which target is replaced by mobile (seemobile definition)

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

Note : as several cooperative surveillance technologies exist, a mobile iscooperative on an aerodrome only if the mobile and the aerodrome are equippedwith cooperative surveillance technologies which are interoperable.

Cooperative surveillance

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

The cooperative surveillance may be :

Either dependant on the cooperative mobile, when the mobile automaticallygenerates the information and transmits it to the surveillance sensor, forinstance via ADS-B;

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

Data Fusion


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

False Alert


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 therule set but are inappropriate to the desired outcome).

Guidance


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

Identification



12/83


Page 6 Edition: 1.0

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

Identity

Aircraft identification [ICAO-4444] definition extended to all mobiles.

A group of letters, figures or a combination thereof which is either identical to, or thecoded 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 servicescommunications.

Incursion


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

IntruderAny mobile which is detected in a specific airport area into which it is not allowed toenter.

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 anotherobstacle, the termMobile will be preferred to Target. The term Target will only be used whenconsidering an image of a mobile or other obstacle displayed on a surveillancescreen.

Modularity


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

Movement area

[ICAO-Annex14] , [ICAO-4444] and [ICAO-A-SMGCS] definitionThat 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 [EUROCAE-MASPS] definition in which target is replaced by mobile (seemobile definition)

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

Non-Cooperative surveillance


13/83


DSA / AOP

Edition: 1.0 Page 7

The surveillance of mobiles is non-cooperative when a sensor, named non-cooperative surveillance sensor, detects the mobiles, without any action on theirbehalf. This technique allows to determine the position of any mobile in the

surveillance area and in particular to detect intruders. Examples of non-cooperativesurveillance sensors are the Primary Surveillance Radars.

Normal Visibility

Visibility conditions sufficient for personnel of control units to exercise control overall traffic on the basis of visual surveillance (correspond to visibility condition 1defined by ICAO [ICAO-A-SMGCS]).

Nuisance Alert


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

Obstacle

[ICAO-Annex14] and [ICAO-A-SMGCS] 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 thatextend 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 onairport movement areas. As illustrated in the Figure 1-1, a participating mobile iseither cooperative or non-cooperative.

ALL MOBILES

INTRUDERS

Cooperative

mobiles

Non cooperative

mobiles

PARTICIPATING MOBILES

Figure 1-1 : 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 alertsituation is detected when a mobile is on a runway and one or more mobiles enterthe runway protection area.

Reduced Visibility


14/83


Page 8 Edition: 1.0

Visibility conditions insufficient for personnel of control units to exercise control overall traffic on the basis of visual surveillance (correspond to visibility conditions 2, 3,and 4 defined by ICAO [ICAO-A-SMGCS]).

Restricted Area

Aerodrome area where the presence of an aircraft or a vehicle is permanently ortemporarily forbidden.

Route


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

Routing


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

Runway Incursion

EUROCONTROL Runway Incursion Task Force definition

The unintended presence of an aircraft, vehicle or person on the runway or runwaystrip.

Stand


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

aircraft.

Surveillance


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

Target

[ICAO-A-SMGCS] definition (this definition has been preferred to the [EUROCAE-MASPS] definition)An aircraft, vehicle or other obstacle, which image is displayed on a surveillancedisplay.

Note : when referring to an aircraft or a vehicle, and not anotherobstacle, the termMobile will be preferred to Target. The term Target will only be used whenconsidering an image of a mobile or other obstacle displayed on a surveillancescreen.

1.6 Performance parameters

This section provides the explanation of terms required for a correct understandingof the present document. Most of the following explanations are drawn from the A-SMGCS manual [ICAO-A-SMGCS], the ICAO Annex 14 [ICAO-Annex14] or theEUROCAE MASPS for A-SMGCS [EUROCAE-MASPS], in that case it is indicated


15/83


DSA / AOP

Edition: 1.0 Page 9

in the definition. [ICAO-A-SMGCS] definitions are used as a first option. In general,other definitions are only used where there is no ICAO definition. If not, it isexplained why another definition is preferred to the ICAO one.

Alert Response Time (ART)


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

Coverage Volume (CV)


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

Display Resolution (DR)[EUROCAE-MASPS] definition

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

Information Display Latency (IDL)


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

Position Registration Accuracy (PRA)


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)


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

Probability of Detection of an Alert Situation (PDAS)[EUROCAE-MASPS] definition

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

Probability of False Alert (PFA)


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

Probability of False Detection (PFD)


16/83


Page 10 Edition: 1.0


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

Probability of False Identification (PFID)


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

Probability of Identification (PID)


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

Reported Position Accuracy (RPA)


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

Reported Velocity Accuracy (RVA)


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

Response Time to Operator Input (RTOI)


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

Surveillance Capacity


The number of target reports in a given period which the Surveillance Element isable to process and output without degradation below the minimum performancerequirements.

System accuracy

[ICAO-A-SMGCS] definitionThe term accuracy generally describes the degree of conformance between aplatform's true position and/or velocity and its estimated position and/or velocity.

System availability


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

System Capacity

[ICAO-A-SMGCS] and [EUROCAE-MASPS] definition


17/83


DSA / AOP

Edition: 1.0 Page 11

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

System continuity


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


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

System reliability


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

Target Display Latency (TDL)


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

Target Report Update Rate (TRUR)


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


18/83



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 do not talk often thesame language.

It is important to recognise that users have an external view of the system. Forthem key questions are : what do I get from the system ? , in which conditions ?... Auser elaborates concepts, often based on the experience, to express what isexpected from the system . Therefore, he is only concerned with the external view ofthe 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 ofthe system and they need to elaborate a logical representation of the system takinginto account the users demands (i.e. operational requirements). The internalorganisation of the system can be described by means of functions (also calledbuilding blocks or components). Functions are still abstract entities but they can beexpressed in technical terms and they are part of a hierarchical breakdown of thesystem. This hierarchical breakdown implies that, depending on the complexity,functions may be refined into sub-functions and that interfaces between functionsand 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 ofview, it is proposed to define 3 levels of requirements for an A-SMGCS system :

Operational or Service level

Functional level

Architectural level

2.2 Service level

At the service level, the A-SMGCS system is seen as a black box providing servicesto 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 theoperational requirements from a user point of view and to identify the environmentalconstraints and the interfaces with external systems.


19/83


DSA / AOP


Airport Traffic Context

Airport Traffic

Services to users

A-SMGCS

System

Figure 2-1 : Service level

The operational requirements are broken down into the following categories :

OperationalRequirements

Categories

Definitions AbbreviationsOp_

Servicesrequirements

They define the services to be provided to the users Serv

Operational range These requirements define the operational rangecovered by the systems, they fix the operational limitsof the system

Range

Responsibilities Requirements related to assignment of responsibilitieswhen using A-SMGCS

Resp

Interfaces Requirements related to interfaces between A-SMGCSand users or other systems

If

Performances These requirements define the performances to befulfilled by A-SMGCS at an operational level

Perf

Monitoring Requirements related to monitoring of A-SMGCSequipment, Quality of Service, Performances,

Mon

Environmentalconstraints

Requirements related to interference between A-SMGCS and its environment

Env

Design They are not pure operational requirements but moregeneral principles on system design

Ds

System evolution They are not pure operational requirements but moregeneral principles on future evolutions of the system

Evo

Table 2-1: Categories of Operational Requirements

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


20/83



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 ofdifferent functions. The operational requirements are mapped onto the functionalframework, to get a first engineering view of the system architecture to bedeveloped. In particular interfaces with users are refined and if possible expressedin more technical terms.

Services to users

A-SMGCS

FunctionsFunction A

Function B

Function C


Airport Traffic

Figure 2-2 : Functional level

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

The building of the functional framework provides a reference for A-SMGCSinstances, it allows the definition of test cases and validation exercises. In addition, itfacilitates the comparison between validation results obtained at different evaluationplatforms.

2.4 Architectural level

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


21/83


DSA / AOP


Services to users

A-SMGCS

Architecture


Airport Traffic

Figure 2-3 : Architectural level

2.5 Traceability along the process

As shown in the following figure, the different levels of requirements haverelationships as if they are part of a same family. It is possible to consider thatoperational requirements are the core specification. They are the starting point (theparents) from which are derived functional requirements which can be considered aschildren requirements. Finally, the functional requirements are used to derivedetailed design requirements which can be seen as grand children of theoperational requirements.


22/83



Parents =

Operational requirements

Children =

Functional requirements

Grand Children =

Detailed Design

Figure 2-4 : Operational and Functional requirements

There is a strong relationship between the operational requirement and thefunctional one : the operational requirement is the parent and the functional one isthe 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 anoperational requirement is modified, it will impact its child requirements. So, it will benecessary to also update the child requirements in order to keep a consistentspecification.

Secondly, the traceability between the requirements will be used during thevalidation of the A-SMGCS. For instance, when testing a specific function, all thefunctional requirements applying to this function are checked. If the function is notconsistent with one of these functional requirements, it will be concluded that theparent(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 theoperational 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 ofview :

Op_Monitoring-02-Equipment Status


23/83


DSA / AOP


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

When reading this requirement, the first conclusion is that the system must contain afunction which monitors all A-SMGCS equipment. This function is named ServiceMonitoring because it will monitor not only the equipment but also the performanceand any parameter representing the quality of service.

2.6.2 Example 2

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

Op_Interface-1-User interface

A-SMGCS level I shall enable controllers to interface efficiently.

When reading this requirement, the first conclusion is that it will apply to the functionnamed Interface with user. This operational requirement is not accurate because ituses a very general term : efficiently. So when allocating this requirement to thefunction, it is interesting to precise if possible the meaning of the operationalrequirement. interface efficiently may be translated in terms of Response Time toOperator Input, number of input actions, User workload, As a consequence,the operational requirement is derived in several functional requirements asfollowing :

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 andeffective activity.

All the above functional requirements are the children of the operational requirementanalysed in this example 2.

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 functionalrequirements. The operational requirements are already presented in [D4], and theyare recalled and listed in the present document for readability purpose.

Most of the requirements are drawn from [ICAO-A-SMGCS] or [EUROCAE-MASPS]. In that case, their reference is attached to the requirements. Theserequirements will be validated in the frame of the validation activity. Moreover, whenthe results from the BETA project will be published, they could benefit to therequirements listed in this document, in particular requirements dealing with A-SMGCS performances.


24/83



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 designof the system. Once, the system developed, it will be tested through validationactivities. This is illustrated in the following figure :

EUROCONTROL&

STAKEHOLDERS

MANUFACTURER

Operational Concept

Operational Specification

Functional Specification

Operational Procedures

Valid

atio

nActiviti

es:

sim

ulatio

ns,ope

ratio

nalt

rials

,

Detailed Design

Development

Technical Tests

Figure 2-5 : A-SMGCS Project Life-Cycle

The role of EUROCONTROL is to manage the validation by developing a ValidationMaster Plan and monitoring the validation exercises. The final aim of the validationactivity is to validate the A-SMGCS operational concept, procedures, operationaland functional requirements. Therefore the validation could lead to a refinement ofthe requirements listed in the present document.

The performance figures given in the requirements are also drawn from ICAO orEUROCAE documents. Those performance figures have usually not been testedand validated by operational experiences. When a figure has been validated through

a project (BETA for instance), it is explicitly indicated in the associatedrequirements.


25/83


DSA / AOP


3. ACTORS

A-SMGCS actors take part in A-SMGCS operations as user or contributor. Thissection describes the respective role of the actors in A-SMGCS.

3.1 ATCO

As for Level I, the role of the controller does not really change by the implementationof A-SMGCS level II, but the controller tasks evolve in the sense that the A-SMGCScontrol service provides the controller with a dedicated source of alert information inall visibility conditions, and the controller must apply the procedures related to eachtype 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 byA-SMGCS to the controller to help him performing its Control task by actions on thetraffic 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 alsoprovided 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 themobiles implicated in the alert situation. Therefore, the controller is able to quicklytake the appropriate action to resolve the conflict / infringement.

Even if provided with the A-SMGCS control service, the controller shall not rely on itto detect conflict / infringement, but shall continue the analysis of the traffic situationto detect conflict / infringement himself as in SMGCS or A-SMGCS level I.


26/83



Air Traffic Controller

Traffic Situation

Picture +

Conflicts /

Infringements

Detection

Traffic Context

Position, Identity,

Speed, of

Mobiles


Airport Traffic

Actions on

Traffic

Surveillance

Information

Alerts

ATCO Role

3.2 Other operators

A pre-requisite for an efficient detection of conflict / infringement is the correctconfiguration of the automated tool, i.e. through the provision of the followinginformation :

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

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

If not automatic, the configuration of the tool providing the automatic A-SMGCScontrol 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 I. The role of the pilot is tonavigate his aircraft following ATCO instructions and clearances provided throughR/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 trafficinformation provided by ATCO.

At level II, the pilot is not a user of A-SMGCS, it will have the following impact on itswork :


27/83


DSA / AOP


- Reduction of R/T report : since the controller knows the position and identity ofaircraft provided by A-SMGCS, it is possible that some aircraft position reports benot 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 identitythrough cooperative surveillance sensors, aircrew should check that this piece ofequipment 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 andclearances provided by R/T, and with the help of visual aids and ATCO. The maintasks 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 trafficinformation provided by ATCO.

With A-SMGCS the controller knows the position and identity of vehicles, so it ispossible that some vehicle position reports are not necessary anymore. It has to beconfirmed 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 correctmanner.

In A-SMGCS level II, the vehicle driver may optionally be provided with a guidanceservice. 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 willprovide to the driver a new source of data about its position related to the airportlayout and fixed obstacles in all visibility conditions. This new source of data willcomplement the usual visual observation outside the vehicle. The guidance servicedoes 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 indications about its position outside or hecannot see them because of reduced visibility conditions, he will be able to use theinformation provided by the guidance service to know exactly where he is on theairport platform.


28/83



4. DATA MODEL

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

4.1 Airport traffic situation

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

4.2 Airport Traffic Situation Chart

Figure 6 Airport Traffic Situation Chart

4.3 Traffic context

The traffic context contains all data, except traffic information (mobiles position andidentity), 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, ) ;


29/83


DSA / AOP


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

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 systems : landing systems aids, ATIS;

Other data : meteorological conditions,

4.4 Traffic information

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

Position

Identity

Other information (aircraft gate,...)

4.5 Mobile Position

Mobile Position indicates position for each aircraft and vehicle. Position of allmobiles is necessary for the Controller in order to monitor the traffic and in particularto 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 isnecessary for the controller to communicate with the pilots or vehicle drivers inparticular to issue clearances. The surveillance service will display the identity of allmobiles 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 various informations such as destinationparking, gate, which could be provided to the controller if needed. Other parameters


30/83



(velocity,...) may be required for other A-SMGCS modules such asConflicts/Infringements Detection.

4.8 Types of traffic information

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

Figure 7 Types of traffic information

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 totake into account in particular landing and departing aircraft and to ensure co-ordination between Ground control and Approach control.

4.11 Service Alert

Service alert is used when system must not be used for intended operation (or whenthe system performances are restricted for significant failures). Such a situation


31/83


DSA / AOP


could appear for different reasons (significant failures, equipment status, lowperformance).

4.12 C/I Alert

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


32/83



5. OPERATIONAL REQUIREMENTS

In this section, are listed the operational requirements already defined in [D3] for A-SMGCS level I and [D4] for A-SMGCS level II. The requirements related to SystemDesign, Evolution, Operational Range, Responsibilities, Interfaces andEnvironmental Constraints are listed as "General Principles" while requirementsspecific 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 beneeded to meet the following requirements.

Sources : [ICAO A-SMGCS] 5.5.2.1.3

5.1.2 Requirements

Op_Ds-1-Modularity to fit aerodrome needs

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

Note 1 : Each aerodrome has its own operational needs and technologicalconstraints. So each aerodrome will only implement the A-SMGCS modules fittingits needs and its technological choices in order to minimize the cost of its A-SMGCS. Consequently, A-SMGCS consists of many elements which, whenintegrated, 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 thatthe requirements of this Level are met. It implies that minimum modules arerequired, i.e. cooperative surveillance.

Sources : [ICAO A-SMGCS] 3.4.1, [EUROCAE MASPS] 1.8.2

Op_Ds-2-HMI design

The A-SMGCS design concept must be built upon the integration of the fundamentaland principal system elements and facilitate the upgrading of those elements whilstmaintaining, where possible, the same HMI and references. This is important whenconsidering harmonisation, familiarisation and training requirements, and will allow


33/83


DSA / AOP


the evolution of the system design through to a full A-SMGCS with the minimumnegative impact on the users ability to interface with the system.

Source : [EUROCAE MASPS] 2.5.2

Op_Ds-3-Interoperability

Standards like Standards and Recommended Practices (SARPS) shall be writtenand used to permit interoperability between the A-SMGCS elements developed bydifferent manufacturers.

Note : Such interoperability will help to maximise commercial and economic benefitsfor the manufacturer, service provider and user. It should also encourage timelyimplementation by avoiding a proliferation of different specifications.


Op_Ds-4-Standardized Data Format

The data interchange between systems should be performed in a standardizedformat in order to ensure an adequate exchange of information. ASTERIX will be thestandard to be used for surveillance data.

Source : [ICAO A-SMGCS] 3.6.21.2

Op_Ds-5-Self-checking system

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


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 isprovided to carry data to the display equipment to permit some components of theequipment to fail without any resultant loss of data displayed.

The term "fail-soft" means that the system is so designed that, even if equipmentfails to the extent that loss of some data occurs, sufficient data remain on the displayto enable the controller to continue operation without assistance of the computer.


Op_Ds-7-Failure effect

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

Note : For instance, the element shall not provide wrong data which could impact onsafety.


Op_Ds-8-Self-restartable

An A-SMGCS shall be self-restartable.



34/83



Op_Ds-9-Restart

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


Op_Env-1-Aerodrome

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


Op_Env-2-Flight operations

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


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 movementarea will comply to obstacle limitations requirements in Annex 14, Volume I.


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 onthe ground, buildings, snow banks or other raised obstacles (fixed or temporary) inor near the aerodrome environment; and

c) meteorological conditions or any state of the aerodrome resulting from adverseweather in which operations would otherwise be possible.

Sources : [ICAO A-SMGCS] 3.5.1.1, 3.6.6.1

Op_Env-5-Radio Spectrum

Those elements of A-SMGCS which require the use of radio spectrum shouldoperate in properly allocated frequency bands in accordance with appropriatenational and international radio regulations.


Op_Env-6-Interference to Other Systems

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


35/83


DSA / AOP



Op_Evo-1-Operational Change

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

Sources : [ICAO A-SMGCS] 3.6.15.2, [EUROCAE MASPS] 1.8.3

Op_Evo-2-Technological Change

An A-SMGCS shall be capable of accommodating any technological change afterbeing installed.

Note : as several technologies are candidates to A-SMGCS implementation andthese technologies evolve, technological changes are very likely. These changescan be driven by performance enhancements or cost decrease reasons, but also byother ATM services which share systems with A-SMGCS.


Op_Evo-3-HMI impact

A-SMGCS evolution shall have a minimum negative impact on the users ability tointerface 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 asimplementation of further A-SMGCS levels.

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

Sources : [ICAO A-SMGCS] 3.4.1, [EUROCAE MASPS] 1.8.2

Op_Evo-5-Cost of evolutions

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


Op_If-1-User interface

A-SMGCS shall enable users to interface efficiently.


Op_If-2-Operator interface

A-SMGCS shall enable operators updating traffic context or configurating thesystem to interface efficiently.


36/83



Op_If-3-Interface with mobiles

A-SMGCS shall be capable of interfacing with all cooperative mobiles in order tocollect the required traffic data. In particular, it shall interface with existing and future

embedded systems.Source : [ICAO A-SMGCS] 3.6.21.1

Op_If-4-Interface with ground systems

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

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

- Approach surveillance system to take into account airborne aircraft;

- Stand mangement systems;

- Existing and future ATS systems;

- MET systems;

- Visual aids;

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


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 requirementsto provide alerting service.

Sources : [ICAO A-SMGCS] 3.6.20.1

Op_Range-1-Visibility conditions

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

Source : [ICAO A-SMGCS] 3.2.4 and 3.2.5

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 maximumnumber of aircraft on the manoeuvring area should be based on the assumed peaktraffic at the aerodrome. Aerodromes continually strive to increase capacity andtherefore the number of movements, and hence aircraft and vehicles will probablyincrease over time. The A-SMGCS capacity figure should be sufficient to cater forexpansion of this nature and reviewed on a regular basis to ensure that it issufficient.


Op_Range-3-Mobile types 1


37/83


DSA / AOP


An A-SMGCS shall support operations involving all aircraft types and all vehiclestypes.


Op_Range-4-Mobile types 2

An A-SMGCS shall be capable of adaptating to cater for future aircraft types andvehicles types.


Op_Range-5-Speeds and Orientation

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

- 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 50 kts for aircraft on straight taxiways;

- 0 to 20 kts for aircraft on taxiway curves;

- 0 to 80 kts for aircraft on runway exits;

- 0 to 250 kts for aircraft on final appoach, missed approach and runways;

- 0 to 80 kts for vehicles on the movement area; and

- 0 to 10 kts for aircraft and vehicles on stands and stand taxilanes.


Op_Resp-1-Users

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

Source : [ICAO A-SMGCS] 3.3.1

Op_Resp-2-Assignment

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

a) the automated system;

b) controllers;

c) pilots;

d) vehicle drivers;


38/83



g) airport authorities;

h) system operators.

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

Note 2. - ATC will be responsible for the management and overall operation of thesystem. When certain functions will be delegated to automated elements of thesystem, responsibilities for the integrity and reliability of those functions lie with theservice 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 I and II ATC controlers and pilots are the only critical decisionmakers. Their decisions are based on surveillance data which have a specifyintegrity.

Source : [ICAO A-SMGCS] 3.3.2

Op_Resp-3-A-SMGCS category

Airport authority shall be responsible for notifying the A-SMGCS category operatingin its aerodrome and the procedures that may be applied.

5.2 Surveillance Service

5.2.1 Requirements

Op_Mon-01-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 intendedoperation.


Op_Mon-02-Performance

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


Op_Mon-03-Data

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


39/83


DSA / AOP


Note: As an exemple when a mobile is still on his area of interest, the system shallcontinuously detect the mobile, otherwise the user shall be timely alerted.


Op_Mon-04-Back-up

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


Op_Mon-05-System Failures

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

Source : [ICAO A-SMGCS] 3.7.6.5, 3.7.5.4

Op_Mon-06-Failure Alerts

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


Op_Perf-01-Probability of Detection

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

Note 1 : The output of the surveillance element means at the output of the processwhich builds a comprehensive surveillance package after fusion of data provided by

the different surveillance sensors.

Note 2 : Some ATS providers request a Probability of Detection of at least 95%,while the Probability of Detection is 99% for an Primary Surveillance Radar, and95% for a Surface Movement Radar. The value of 99.9% could be achieved bycombining several surveillance sensors, e.g. cooperative surveillance sensors.

Sources : [ICAO A-SMGCS] 5.5.2.2.1, [EUROCAE MASPS] 3.2.3

Op_Perf-02-Probability of False Detection

The probability that anything other than an actual aircraft, vehicle or object isdetected and reported by the surveillance element of the A-SMGCS shall not

exceed 10E-3 per reported target.Note 1 : The surveillance element means at the output of the process which builds acomprehensive surveillance package after fusion of data provided by the differentsurveillance sensors.

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


Op_Perf-03-Probability of Identification

The probability that the correct identity of an aircraft, vehicle or object is reported atthe output of the surveillance element shall be 99.9% at minimum.


40/83



Note 1 : The output of the surveillance element means at the output of the processwhich builds a comprehensive surveillance package after fusion of data provided bythe 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%.


Op_Perf-04-Probability of False Identification

The probability that the identity reported at the output of the surveillance element isnot the correct identity of the actual aircraft, vehicle or object shall not exceed 10E-3per reported target.

Note 1 : The output of the surveillance element means at the output of the processwhich builds a comprehensive surveillance package after fusion of data provided bythe different surveillance sensors.

Note 2 : The value of 10E-3 for Probability of False Identification is alreadyrequested by some ATS providers and accepted by manufacturers.


Op_Perf-05-Position Accuracy

For the surveillance service, the allowable error in reported position shall beconsistent with the requirements set by the control task of the controller : 12 m.

Note:

For Reported Position Accuracy (RPA), ICAO specification recommends a value of

7.5m ([ICAO-A-SMGCS] 4.3.3.1).For [EUROCAE MOPS], a value of 7.5m (95% level of confidence) is recommended.

For [EUROCAE MASPS] 3.2.2.1, a value of 12m would be reasonable for thesurveillance service. The argument leads to the need only to place an aircraft withinthe width of a taxiway, or at least to be able to determine unambiguously which oftwo parallel taxiways an aircraft is using. If we therefore consider a typical taxiwaywidth of 24 m it would be reasonable to require an RPA for taxiing aircraft of 12metres.

At level II, when the control service is also provided to the controller, [EUROCAEMASPS] 3.2.3 and [ICAO-A-SMGCS] 4.3.3.1 agree to consider a value of 7.5metres for RPA. This value is required by the control service and not thesurveillance service. This figure seems to be a little more demanding than theperformance of existing tracking and labelling systems, using SMR as a source(confirmed by BETA project).

To take into account the level distinction made by EUROCAE, we propose a valueof 12 metres for RPA when the position is used by the surveillance service.

Sources : [ICAO A-SMGCS] 3.7.1.2, 4.3.3.1, [EUROCAE MASPS] 3.2.3

Op_Perf-06-Position Resolution

The mobile position resolution shall be at least 1 m.

Sources : [EUROCAE MASPS] 3.2.3


41/83


DSA / AOP


Op_Perf-07-Altitude Accuracy

Where airborne traffic participates in the A-SMGCS, the level of an aircraft whenairborne 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 thisrequirement as such in the document because it is provided by ICAO. If no moreinformation about this requirement is provided so far, the validation activity willdetermine the status of this requirement.


Op_Perf-08-Update rate

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

Note : [EUROCAE MASPS] 3.2.3 and [ICAO-A-SMGCS] 4.3.5 require the updaterate should be at least 1s. For example, in one second, an aircraft rolling at 10 ktscovers a distance of 5 meters. A vehicle at 35 km/h, will move of 10 metres. In thatcase, the position displayed to the controller can differ of 10 metres from the actualposition before being updated with the new reported value. If we take the maximumspeed of 50kts for aircraft on straight taxiways ([ICAO-A-SMGCS] 4.2.4.2), thedisplayed position can differ of 25 metres.


Op_Perf-09-Integrity

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

Sources : [ICAO A-SMGCS] 3.7.3.1, [EUROCAE MASPS] 3.1.1.1

Op_Perf-10-Availability

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

Note : Some ATS providers require an availability of 95.5% per year, and anunavailability less than 1 hour per day.


Op_Perf-11-Reliability

A failure of equipment shall not cause:

- a reduction in safety (fail soft); and

- the loss of basic functions.


Op_Perf-12-Continuity of Service 1

An A-SMGCS shall provide a continuous service.



42/83



Op_Perf-13-Continuity of Service 2

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


Op_Perf-14-Recovery time

When restarting, the recovery times of A-SMGCS shall be of a few seconds.


Op_Serv-01-Service

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

Op_Serv-02-User

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

Op_Serv-03-Airport Traffic Situation

The surveillance service shall continuously provide the following airport trafficsituation :

- Traffic Information ;

- Traffic context.

Op_Serv-04-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 ;

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

Op_Serv-05-Traffic information 2The traffic information may optionally include other information about traffic, such as:

- vehicle type ;

- aircraft type ;

- aircraft gate;

- ...

Note : this is a local issue to be decided by the ATS provider.


43/83


DSA / AOP


Op_Serv-06-Area of interest for vehicles

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

Op_Serv-07-Area of interest for aircraft

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

Source : [ICAO A-SMGCS] 3.5.1.1, 3.5.1.4, 3.5.1.5

Op_Serv-08-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 inits surveillance task.


The traffic context shall at least include :

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

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

- 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 systems : landing systems aids, ATIS;

- Other data : meteorological conditions,


Op_Serv-11-Position

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

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

Op_Serv-12-Label


44/83



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

Op_Serv-13-Transition

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


5.2.2 Scenario A : Arriving Aircraft

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

An aircraft approaching an airport will be detected by the approach Radar DataProcessing System (RDPS). When arriving over the runway threshold, this aircraftmust be displayed to the ground controllers. A-SMGCS will provide a seamlesstransition between air and ground surveillance systems. Actually, the aircraft will befirstly detected by A-SMGCS through the data sent by the approach surveillancesystem.

As soon as the aircraft is under coverage of the cooperative surveillance sensor,surveillance data from cooperative and non-cooperative surveillance sensors will becombined by the data fusion process to provide to the controller the exact positionand identity of the aircraft. During the taxiing phase on the manoeuvring area, thecontroller will always have the exact position and identity of the aircraft. During thetaxiing 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 Radarbut also by other technologies such as ADS.

5.2.3 Scenario B : System Failure

Considering the previous scenario, we can imagine that all the cooperativesurveillance sensors have a significant failure. In this case A-SMGCS is not able tocollect the identity of the aircraft, but it could continue to display the identitypreviously 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 shouldrevert to adequate back-up procedures. In particular, the identity of cooperativevehicles entering the manoeuvring area won't be provided to the controller.

5.3 Control Service

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


45/83


DSA / AOP


5.3.1 Requirements

Op_Perf-15-Position Accuracy

The allowable error in reported position shall be consistent with the requirements setby the Control service: 7.5 when the position is used by the conflict / infringementdetection process.

Note 1 : The position accuracy could not be the same in all areas, depending on theconflict / infringement detection requirements.

Note 2 : The required position accuracy may be specifically defined at each airportby the ATS authority on the basis of local safety analysis.

Source : [ICAO A-SMGCS] 3.7.1.2, 4.3.3.1, [EUROCAE MASPS] 3.2.3.

Op_Perf-16-Reported Velocity Accuracy

The velocity shall be determined to the following accuracy:

- speed:


46/83




Op_Perf-19-Alert Continuity

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

Source : [ICAO A-SMGCS] 5.5.6.3.4

Op_Perf-20-False and Nuisance alert number

The number of false alerts and nuisance alerts shall be as low as possible to notdisturb the user and avoid him to loose confidence in the system.

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 II 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 concernedin the manoeuvring area of the aerodrome.

Op_Serv-16-Conflicts/infringements on runway

The control service shall detect the conflicts/infringements on runway provided inannex.

Source : [ICAO A-SMGCS] 3.5.4.1, [ICAO A-SMGCS] 3.5.4.3

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 bedefined locally for each aerodrome.

Source : [ICAO A-SMGCS] 3.5.4.1, [ICAO A-SMGCS] 3.5.4.3

Op_Serv-18-Runway protection area

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

Op_Serv-19-Ground boundary

The length of the ground boundary must at least include the runway strip. The widthcould 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


47/83


DSA / AOP


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

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