Post on 09-Apr-2018
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
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:
8/8/2019 11 Asmgcs Functional Spec Impl Level2
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
5/83
Functional Specification for A-SMGCS ImplementationLevel II
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
6/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
7/83
Functional Specification for A-SMGCS ImplementationLevel II
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/8/2019 11 Asmgcs Functional Spec Impl Level2
8/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
9/83
Functional Specification for A-SMGCS ImplementationLevel II
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
10/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
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)
[ICAO-A-SMGCS] definition
The minimum visibility at or above which the declared movement rate can besustained.
Airport authority
[ICAO-A-SMGCS] definition
The person(s) responsible for the operational management of the airport.
Alert
[ICAO-A-SMGCS] 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
[EUROCAE-MASPS] definition
Any situation relating to aerodrome operations which has been defined as requiringparticular attention or action.
Apron
[ICAO-Annex14] and [ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
A situation when there is a possibility of a collision between aircraft and/or vehicles.
Control
8/8/2019 11 Asmgcs Functional Spec Impl Level2
11/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 5
[ICAO-A-SMGCS] definition
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
[EUROCAE-MASPS] definition
A generic term used to describe the process of combining surveillance informationfrom two or more sensor systems or sources.
False Alert
[EUROCAE-MASPS] 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 therule set but are inappropriate to the desired outcome).
Guidance
[ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
8/8/2019 11 Asmgcs Functional Spec Impl Level2
12/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
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
[ICAO-A-SMGCS] definition
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
[ICAO-Annex14] and [ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
13/83
Functional Specification for A-SMGCS ImplementationLevel II
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
[EUROCAE-MASPS] definition
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
14/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
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
[ICAO-A-SMGCS] definition
A track from a defined start point to a defined endpoint on the movement area.
Routing
[ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
A stand is a designated area on an apron intended to be used for the parking of an
aircraft.
Surveillance
[ICAO-A-SMGCS] definition
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
15/83
Functional Specification for A-SMGCS ImplementationLevel II
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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] 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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
The probability that the Control service reports anything other than actual alertsituations.
Probability of False Detection (PFD)
8/8/2019 11 Asmgcs Functional Spec Impl Level2
16/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 10 Edition: 1.0
[EUROCAE-MASPS] definition
The probability that the Surveillance Element of an A-SMGCS reports anything otherthan actual targets.
Probability of False Identification (PFID)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
The probability that the correct identity of a co-operative target is reported at theoutput of the Surveillance Element.
Reported Position Accuracy (RPA)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
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
[EUROCAE-MASPS] definition
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
[ICAO-A-SMGCS] definition
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
17/83
Functional Specification for A-SMGCS ImplementationLevel II
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
[ICAO-A-SMGCS] 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
[ICAO-A-SMGCS] definition
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
[ICAO-A-SMGCS] definition
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)
[EUROCAE-MASPS] definition
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)
[EUROCAE-MASPS] definition
The frequency with which target reports are output from the Surveillance Element.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
18/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 12 Edition: 1.0
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
19/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 13
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
20/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 14 Edition: 1.0
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 Context
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
21/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 15
Services to users
A-SMGCS
Architecture
Airport Traffic Context
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
22/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 16 Edition: 1.0
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
23/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 17
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
24/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 18 Edition: 1.0
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
25/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 19
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
26/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 20 Edition: 1.0
Air Traffic Controller
Traffic Situation
Picture +
Conflicts /
Infringements
Detection
Traffic Context
Position, Identity,
Speed, of
Mobiles
Airport Traffic Context
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 :
8/8/2019 11 Asmgcs Functional Spec Impl Level2
27/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 21
- 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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
28/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 22 Edition: 1.0
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, ) ;
8/8/2019 11 Asmgcs Functional Spec Impl Level2
29/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 23
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
30/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 24 Edition: 1.0
(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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
31/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 25
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
32/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 26 Edition: 1.0
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
33/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 27
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.
Source : [EUROCAE MASPS] 1.8.4
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.
Source : [ICAO A-SMGCS] 3.7.6.2
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.
Source : [ICAO A-SMGCS] 3.6.12.1
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.
Source : [ICAO A-SMGCS] 3.6.12.2
Op_Ds-8-Self-restartable
An A-SMGCS shall be self-restartable.
Source : [ICAO A-SMGCS] 3.6.14.1
8/8/2019 11 Asmgcs Functional Spec Impl Level2
34/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 28 Edition: 1.0
Op_Ds-9-Restart
The restart of an A-SMGCS shall include the restoration of pertinent information onactual traffic and system performance.
Source : [ICAO A-SMGCS] 3.6.14.2
Op_Env-1-Aerodrome
An A-SMGCS should be capable of being installed at any aerodrome.
Source : [ICAO A-SMGCS] 3.6.15.1
Op_Env-2-Flight operations
The ground elements of the system shall be sited so as not to affect flightoperations.
Source : [ICAO A-SMGCS] 3.6.15.3
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.
Source : [ICAO A-SMGCS] 3.6.15.4
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.
Source : [ICAO A-SMGCS] 3.6.5.1
Op_Env-6-Interference to Other Systems
A-SMGCS equipment shall not cause interference to standard radio navigation,surveillance and communication systems.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
35/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 29
Source : [ICAO A-SMGCS] 3.6.7.1
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.
Source : [EUROCAE MASPS] 1.8.3
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.
Source : [EUROCAE MASPS] 2.5.2
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.
Source : [EUROCAE MASPS] 1.8.3
Op_If-1-User interface
A-SMGCS shall enable users to interface efficiently.
Source : [ICAO A-SMGCS] 3.6.21.3
Op_If-2-Operator interface
A-SMGCS shall enable operators updating traffic context or configurating thesystem to interface efficiently.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
36/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 30 Edition: 1.0
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).
Source : [ICAO A-SMGCS] 3.6.21.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 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.
Source : [ICAO A-SMGCS] 4.2.3.1
Op_Range-3-Mobile types 1
8/8/2019 11 Asmgcs Functional Spec Impl Level2
37/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 31
An A-SMGCS shall support operations involving all aircraft types and all vehiclestypes.
Source : [ICAO A-SMGCS] 3.6.2.1
Op_Range-4-Mobile types 2
An A-SMGCS shall be capable of adaptating to cater for future aircraft types andvehicles types.
Source : [ICAO A-SMGCS] 3.6.2.2
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.
Source : [ICAO A-SMGCS] 3.6.4.1
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.
Source : [ICAO A-SMGCS] 4.2.4.2
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;
8/8/2019 11 Asmgcs Functional Spec Impl Level2
38/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 32 Edition: 1.0
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.
Source : [ICAO A-SMGCS] 3.5.1.2
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.
Source : [ICAO A-SMGCS] 3.7.5.3
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
39/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 33
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.
Source : [ICAO A-SMGCS] 3.7.3.2
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.
Source : [ICAO A-SMGCS] 3.7.6.4
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.
Source : [ICAO A-SMGCS] 3.6.13.1
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%.
Sources : [ICAO A-SMGCS] 5.5.2.2.1, [EUROCAE MASPS] 3.2.3
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
40/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 34 Edition: 1.0
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%.
Sources : [ICAO A-SMGCS] 5.5.2.2.1, [EUROCAE MASPS] 3.2.3
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.
Sources : [ICAO A-SMGCS] 5.5.2.2.1, [EUROCAE MASPS] 3.2.3
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
41/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 35
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.
Sources : [ICAO A-SMGCS] 4.3.3.2
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.
Sources : [ICAO A-SMGCS] 3.7.2.1, [EUROCAE MASPS] 3.2.3
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.
Sources : [ICAO A-SMGCS] 3.7.4.1, [EUROCAE MASPS] 3.1.1.2
Op_Perf-11-Reliability
A failure of equipment shall not cause:
- a reduction in safety (fail soft); and
- the loss of basic functions.
Sources : [ICAO A-SMGCS] 3.7.6.3, [EUROCAE MASPS] 3.1.1
Op_Perf-12-Continuity of Service 1
An A-SMGCS shall provide a continuous service.
Sources : [ICAO A-SMGCS] 3.7.5.1, [EUROCAE MASPS] 3.1.1.2
8/8/2019 11 Asmgcs Functional Spec Impl Level2
42/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 36 Edition: 1.0
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.
Sources : [ICAO A-SMGCS] 3.7.5.2, [EUROCAE MASPS] 3.1.1.2
Op_Perf-14-Recovery time
When restarting, the recovery times of A-SMGCS shall be of a few seconds.
Source : [ICAO A-SMGCS] 3.6.14.1
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
43/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 37
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.
Op_Serv-09-Traffic context2
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.
Sources : [ICAO A-SMGCS] 3.4.3.3
Op_Serv-10-Traffic context3
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,
Sources : [ICAO A-SMGCS] 3.4.3.3
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
44/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 38 Edition: 1.0
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.
Source : [ICAO A-SMGCS] 3.5.1.6
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.
8/8/2019 11 Asmgcs Functional Spec Impl Level2
45/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 39
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:
8/8/2019 11 Asmgcs Functional Spec Impl Level2
46/83
DSA / AOP Functional Specification for A-SMGCSImplementation Level II
Page 40 Edition: 1.0
Source : [ICAO A-SMGCS] 3.5.4.4
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
8/8/2019 11 Asmgcs Functional Spec Impl Level2
47/83
Functional Specification for A-SMGCS ImplementationLevel II
DSA / AOP
Edition: 1.0 Page 41
- In LVP : ground boundary defined by Cat II / III holding position
This ground boundary will be used for both INFORMATION and ALARM stages