Functional Requirements for A-SMGCS Implementation Level 2

Transcription

1 EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION EUROCONTROL Functional Requirements for A-SMGCS Implementation Level 2 Edition Number : 2.1 Edition Date : 30/06/2010 Status : Released Issue Intended for : General Public COOPERATIVE NETWORK DESIGN

2 DOCUMENT CHARACTERISTICS TITLE Functional Requirements for A-SMGCS Implementation Level 2 Publications Reference: ISBN Number: Document Identifier Edition Number: 2.1 Funct. Req. A-SMGCS L2 Edition Date: 30/06/2010 Abstract This document is the Eurocontrol specification of the functional requirements for A-SMGCS Level 2 implementation. In 2006 the EUROCONTROL A-SMGCS project published the latest version of this document that has been agreed by WG41 of EUROCAE. Further developments as well as the integration of the specifications into a European Norm and updated references consequently required an update of this document. Keywords A-SMGCS Implementation Specifications A-SMGCS Identification Level 2 Requirements Identification Authors Contact(s) Person Tel Unit Matthis BIRENHEIDE Project Manager A-SMGCS CND/CoE/AT/AP STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via Working Draft General Public Intranet Draft CND Stakeholders Extranet Proposed Issue Restricted Audience Internet ( Released Issue Electronic copies of this document can be downloaded from: html Edition: 2.1 Released Issue Page 1

3

4 DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION NUMBER EDITION DATE /09/ /11/2006 Released Issue REASON FOR CHANGE Revisions following Eurocontrol and European Commission validation projects and review meeting with EUROCAE WG41 PAGES AFFECTED Sections 5, 6 and /12/2006 Finalisation Template /06/2010 Update of references and template. Editorial changes. Executive summary. All Publications EUROCONTROL Headquarters 96 Rue de la Fusée B-1130 BRUSSELS Tel: +32 (0) Fax: +32 (0) publications@eurocontrol.int Edition: 2.1 Released Issue Page 3

5 Contents DOCUMENT CHARACTERISTICS...1 DOCUMENT APPROVAL...2 DOCUMENT CHANGE RECORD...3 EXECUTIVE SUMMARY...7 CHAPTER 1 Introduction Scope of the document Structure of the document Performance parameters...9 CHAPTER 2 Methodology Need for a methodology Service level Functional level Architectural level Traceability along the process Examples of allocation of an operational requirement to a function Example Example Scope of the functional specification Validation Activity...18 CHAPTER 3 Actors ATCO Other operators Pilot Vehicle Driver...21 CHAPTER 4 Data Model Airport traffic situation Airport Traffic Situation Chart Traffic context Traffic information Mobile Position Mobile Identity Other Information about Traffic Types of traffic information Surface Mobile Information Airborne Aircraft Information Service Alert C/I Alert...24 Page 4 Released Issue Edition: 2.1

6 CHAPTER 5 Operational Requirements General principles Assumptions Recommendation Requirement Surveillance Service Requirement Scenario A: Arriving Aircraft Scenario B: System Failure Control Service Requirements Scenario Guidance Service to Vehicle Drivers (Optional) Requirements...41 CHAPTER 6 Functional specification for A-SMGCS Level 2 services to ATCOs Functional Breakdown for A-SMGCS Level 2 Services to ATCOs Functional Architecture (Level 2) Provide Traffic Information Provide traffic context Conflicts / Infringements Detection Interface with user Service monitoring Functional Requirements for A-SMGCS Level 2 services to ATCOs Provide Traffic Information Provide traffic context Conflicts / Infringements Detection Interface with user Service monitoring...55 CHAPTER 7 Functional Specification for A-SMGCS Level 2 service to Vehicle Drivers Functional Breakdown for A-SMGCS Level 2 services to Vehicle Drivers Functional Architecture Provide Vehicle Information Provide traffic context Interface with driver Guidance Service Monitoring Functional Requirements for A-SMGCS Level 2 services to Vehicle Drivers Provide Vehicle Information Provide traffic context Interface with driver Guidance Service Monitoring...61 Edition: 2.1 Released Issue Page 5

7 ANNEX 1 Conflicts / infringements to be detected by the runway safety net...63 ANNEX 2 Relationships between requirements...66 A2.1 A-SMGCS Level 1 Surveillance Service...67 A2.2 A-SMGCS Level 2 Control Service...69 A2.3 A-SMGCS Level 2 Guidance Service to Vehicle Drivers (optional)...70 REFERENCES...71 GLOSSARY...73 ABBREVIATIONS...78 List of Figures Figure 1: Service level...13 Figure 2: Functional level...14 Figure 3: Architectural level...15 Figure 4: Operational and Functional requirements...16 Figure 5: A-SMGCS Project Life-Cycle...18 Figure 6: ATCO Role...20 Figure 7: Airport Traffic Situation Chart...22 Figure 8: Types of traffic information...24 Figure 9: Example - Information...40 Figure 10: Example - Alarm...41 Figure 11: Ground Segment Functional Architecture (Level 2)...44 Figure 12: Functional Architecture...45 Figure 13: Functional Architecture...46 Figure 14: Functional Architecture for Vehicles...57 Figure 15: Types of Mobiles...76 List of Tables Table 1: Categories of Operational Requirements...14 Table 2: Conflicts / infringements to be detected at each individual runway...64 Table 3: Additional conflicts / infringements to be detected when two runways are intersecting...65 Table 4: A-SMGCS Level 1 Surveillance Service...67 Table 5: A-SMGCS Level 1 Surveillance Service...68 Table 6: A-SMGCS Level 2 Control Service...69 Table 7: A-SMGCS Level 2 Guidance Service to Vehicle Drivers (optional)...70 Page 6 Released Issue Edition: 2.1

8 EXECUTIVE SUMMARY This document describes the Eurocontrol specification of the functional requirements for the A-SMGCS Implementation Level 2. Based on the results of validation projects, an update of the initial requirements had been prepared and agreed with EUROCAE WG41 for A-SMGCS and was published in The EUROCONTROL and EUROCAE specifications have been incorporated in the creation of a European Norm (EN) for A-SMGCS Level 1 and Level 2 by the European Telecommunications Standardisation Institute (ETSI) based on Mandate 390 of the European Commission to a significant extend. This European Norm is planned to be converted into a European Community Specification (CS) by end of Both forms are intended as means of compliance to the European Regulation on Interoperability (EC) No 552/2004 being amended by Regulation (EC) No 1070/2009. Edition: 2.1 Released Issue Page 7

9 CHAPTER 1 Introduction 1.1 Scope of the document The EUROCONTROL A-SMGCS project aims at defining pragmatic implementation steps for A-SMGCS. The first step named A-SMGCS Level 1 focused on the implementation of automated surveillance. Its associated operational concept and requirements are presented in Ref. 2. On the basis of the analysis of the users needs presented in Ref. 2, the functional requirements for A-SMGCS Implementation Level 1 have been developed in Ref. 21. The second step named A-SMGCS Level 2 aimed at complementing surveillance service with a control service which provides a runway safety net and prevents incursions into restricted areas. A guidance service may also be provided to the vehicles driver as an option. The A-SMGCS Level 2 operational concept and requirements are presented in Ref. 3. On the basis of the analysis of the users needs presented in Ref. 2, the functional requirements for A-SMGCS Implementation Level 2 had been developed and are presented in the present document. The EUROCONTROL definition of A-SMGCS Implementation Levels is based on ICAO Ref. 4 definitions and presented in Ref Structure of the document Introduction CHAPTER 1 describes the purpose of this document, its structure, the reference documents, and an explanation of terms used throughout the document Methodology CHAPTER 2 reminds the methodology applied to specify A-SMGCS and explain how the functional requirements are derived from the operational one. Actors CHAPTER 3 presents the actors involved in the surveillance service. Data Model CHAPTER 4 presents the data types used in the functional specification. Operational requirements CHAPTER 5 lists the operational requirements of A-SMGCS Level 2. Functional Specification for A-SMGCS Level 2 services to Controllers CHAPTER 6 presents the Functional Specification for A-SMGCS Level 2 services to Controllers: surveillance and control services. Page 8 Released Issue Edition: 2.1

10 Functional Specification for A-SMGCS Level 2 services to Drivers CHAPTER 7 presents the Functional Specification for A-SMGCS Level 2 services to Drivers: guidance service. Annex 1: Summary of Conflicts / infringements to be detected ANNEX 1 summaries the conflicts / infringements to be detected by the runway safety net and associated alerts. Annex 2: Relationships between Requirements ANNEX 2 exposes the traceability between operational and functional requirements 1.3 Performance parameters This section provides the explanation of terms required for a correct understanding of the present document. Most of the following explanations are drawn from the A-SMGCS manual Ref. 5, the ICAO Annex 14 Ref. 6, or the EUROCAE MASPS for A-SMGCS Ref. 9 in that case it is indicated in the definition. Ref. 5 definitions are used as a first option. In general, other definitions are only used where there is no ICAO definition. If not, it is explained why another definition is preferred to the ICAO one. Alert Response Time (ART) Ref. 9 definition The time delay between an alert situation occurring at the input to the Alert Situation Detection Element and the corresponding alert report being generated at its output. Coverage Volume (CV) Ref. 9 definition That volume of space which encompasses all parts of the aerodrome surface where aircraft movements take place together with those parts of the surrounding airspace which affect surface operations. Display Resolution (DR) Ref. 9 definition The number of individually addressed picture elements (pixels) along each axis of the display screen. (For a raster-scan display, the resolution is normally expressed in terms of the number of raster lines and the number of pixels per line.) Information Display Latency (IDL) Ref. 9 definition The maximum time delay between a report, other than a target report, being received by the A-SMGCS HMI and the corresponding presentation on the HMI display of the information contained in the report. Position Registration Accuracy (PRA) Ref. 9 definition The difference between the co-ordinates contained in the dynamic input data to the HMI and the corresponding geographical position represented on the HMI display. Edition: 2.1 Released Issue Page 9

11 Probability of Detection (PD) Ref. 9 definition The probability that an actual target is reported at the output of the Surveillance Element of an A-SMGCS. Probability of Detection of an Alert Situation (PDAS) Ref. 9 definition The probability that the Monitoring/Alerting Element correctly reports an alert situation. Probability of False Alert (PFA) Ref. 9 definition The probability that the Control service reports anything other than actual alert situations. Probability of False Detection (PFD) Ref. 9 definition The probability that the Surveillance Element of an A-SMGCS reports anything other than actual targets. Probability of False Identification (PFID) Ref. 9 definition The probability that the identity reported at the output of the Surveillance Element of an A-SMGCS is not the correct identity of the actual target. Probability of Identification (PID) Ref. 9 definition The probability that the correct identity of a co-operative target is reported at the output of the Surveillance Element. Reported Position Accuracy (RPA) Ref. 9 definition The difference, at a specified confidence level, between the reported position of the target and the actual position of the target at the time of the report. Reported Velocity Accuracy (RVA) Ref. 9 definition The difference, at a specified confidence level, between the reported target velocity and the actual target velocity at the time of the report. Response Time to Operator Input (RTOI) Ref. 9 definition The maximum time delay between the operator making an input on a data entry device of an A-SMGCS HMI and the corresponding action being completed or acknowledged on the HMI display. Surveillance Capacity Ref. 9 definition The number of target reports in a given period which the Surveillance Element is able to process and output without degradation below the minimum performance requirements. System accuracy Page 10 Released Issue Edition: 2.1

12 Ref. 5 definition The term accuracy generally describes the degree of conformance between a platform's true position and/or velocity and its estimated position and/or velocity. System availability Ref. 5 definition Availability is the ability of an A-SMGCS to perform a required function at the initiation of the intended operation within an A-SMGCS area. System Capacity Ref. 5 and Ref. 9 definition The maximum number of simultaneous movements of aircraft and vehicles that the system can safely support within an acceptable delay commensurate with the runway and taxiway capacity at a particular airport. System continuity Ref. 5 definition Continuity is the ability of an A-SMGCS to perform its required function without non-scheduled interruption during the intended operation in an A-SMGCS area. System integrity Ref. 5 definition Integrity relates to the trust which can be placed in the correctness of the information provided by an A-SMGCS. Integrity includes the ability of an A- SMGCS to provide timely and valid alerts to the user(s) when an A-SMGCS must not be used for the intended operation. System reliability Ref. 5 definition Reliability is defined as the ability of an A-SMGCS to perform a required function under given conditions for a given time interval. Target Display Latency (TDL) Ref. 9 definition The maximum time delay between a target report being received by the A- SMGCS HMI and the corresponding presentation on the HMI display of the target position contained in the report. Target Report Update Rate (TRUR) Ref. 9 definition The frequency with which target reports are output from the Surveillance Element. Edition: 2.1 Released Issue Page 11

13 CHAPTER 2 Methodology 2.1 Need for a methodology The operational users (ATCOs for instance) on one hand and the system designers (engineers) on the other hand have different points of view and often do not talk the same language. It is important to recognise that users have an external view of the system. For them key questions are: what do I get from the system?, and in which conditions? A user elaborates concepts, often based on the experience, to express what is expected from the system. Therefore, he is only concerned with the external view of the system (how to interface, which environment, what are the limits,). For a user, the system itself is a black box. On the contrary the engineers are concerned about the internal building blocks of the system and they need to elaborate a logical representation of the system taking into account the users demands (i.e. operational requirements). The internal organisation of the system can be described by means of functions (also called building blocks or components). Functions are still abstract entities but they can be expressed in technical terms and they are part of a hierarchical breakdown of the system. This hierarchical breakdown implies that, depending on the complexity, functions may be refined into sub-functions and that interfaces between functions and subfunctions are clearly specified. There is a need for a generic methodology capable to support the capture of user needs and to translate them into an engineer view. From a methodological point of view, it is proposed to define 3 levels of requirements for an A-SMGCS system: Operational or Service level; Functional level, and; Architectural level. 2.2 Service level At the service level, the A-SMGCS system is seen as a black box providing services to users. This black box interacts with the users but also with its environment and other external systems. At this level, the requirement analysis allows to define the operational requirements from a user point of view and to identify the environmental constraints and the interfaces with external systems. Page 12 Released Issue Edition: 2.1

14 Services to users A-SMGCS System Airport Traffic Context Airport Traffic Figure 1: Service level The operational requirements are broken down into the following categories: Operational Requirements Categories Services requirements Operational range Responsibilities Interfaces Performances Monitoring Environmental constraints Definitions They define the services to be provided to the users These requirements define the operational range covered by the systems, they fix the operational limits of the system Requirements related to assignment of responsibilities when using A-SMGCS Requirements related to interfaces between A-SMGCS and users or other systems These requirements define the performances to be fulfilled by A-SMGCS at an operational level Requirements related to monitoring of A-SMGCS equipment, Quality of Service, Performances, etc. Requirements related to interference between A- SMGCS and its environment Abbreviations Op_ Serv Range Resp If Perf Mon Env Edition: 2.1 Released Issue Page 13

15 Operational Requirements Categories Design Definitions They are not pure operational requirements but more general principles on system design Abbreviations Ds Op_ System evolution They are not strictly-speaking operational requirements but more general principles on future evolutions of the system Evo Table 1: Categories of Operational Requirements In the operational specification, these requirements are numbered according to the following frame: Op_Abbreviation-Number, e.g. Op_Serv Functional level At the functional level, the analysis of operational requirements allows to define the internal building blocks of the A-SMGCS system, which is seen as an interaction of different functions. The operational requirements are mapped onto the functional framework, to get a first engineering view of the system architecture to be developed. In particular interfaces with users are refined and if possible expressed in more technical terms. Services to users A-SMGCS Functions Function B Function A Function C Airport Traffic Context Airport Traffic Figure 2: Functional level Consistency and completeness of the functional representation of the system is assessed with respect to operational requirements. At this stage the functional framework is an efficient tool for communication between ATM Operational experts and engineering experts. Page 14 Released Issue Edition: 2.1

16 The building of the functional framework provides a reference for A-SMGCS instances, it allows the definition of test cases, and validation exercises. In addition, it facilitates the comparison between validation results obtained at different evaluation platforms. 2.4 Architectural level At the architectural level, the requirement analysis defines the physical components of the A-SMGCS system which executes the different functions defined previously. The functions are mapped onto the physical architecture. At this level, the specification goes deeper in the details of the system design: the functional requirements are derived into more detailed requirements. Services to users A-SMGCS Architecture Airport Traffic Context Airport Traffic Figure 3: Architectural level 2.5 Traceability along the process As shown in the following figure, the different levels of requirements have relationships as if they are part of a same family. It is possible to consider that operational requirements are the core specification. They are the starting point (the parents) from which derived functional requirements which can be considered as children requirements. Finally, the functional requirements are used to derive detailed design requirements which can be seen as grand children of the operational requirements. Edition: 2.1 Released Issue Page 15

17 Parents = Operational requirements Children = Functional requirements Grand Children = Detailed Design Figure 4: Operational and Functional requirements There is a strong relationship between the operational requirement and the functional one: the operational requirement is the parent and the functional one is the child. It is important to trace this dependence between the operational and functional requirements for several reasons. Firstly, during the project life cycle, the requirements will evolve. For instance, if an operational requirement is modified, it will impact its child requirements. So, it will be necessary to also update the child requirements in order to keep a consistent specification. Secondly, the traceability between the requirements will be used during the validation of the A-SMGCS. For instance, when testing a specific function, all the functional requirements applying to this function are checked. If the function is not consistent with one of these functional requirements, it will be concluded that the parent(s) operational requirement(s) are not fulfilled by the A-SMGCS. 2.6 Examples of allocation of an operational requirement to a function Example 1 The objective of this section is to explain to the reader by using 2 examples how the operational requirements are derived into a functional specification. Here is an operational requirement we want to analyse from a functional point of view: Op_Monitoring-02-Equipment Status Page 16 Released Issue Edition: 2.1

18 2.6.2 Example 2 The operational status of all A-SMGCS equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation. When reading this requirement, the first conclusion is that the system must contain a function which monitors all A-SMGCS equipment. This function is named Service Monitoring because it will monitor not only the equipment but also the performance and any parameter representing the quality of service. Here is another example which shows an operational requirement which is derived in several functional requirements during the allocation process: Op_Interface-1-User interface A-SMGCS Level 1 shall enable controllers to interface efficiently. When reading this requirement, the first conclusion is that it will apply to the function named Interface with user. This operational requirement is not accurate because it uses a very general term: efficiently. So when allocating this requirement to the function, it is interesting to precise if possible the meaning of the operational requirement. interface efficiently may be translated in terms of Response Time to Operator Input, number of input actions, User workload, As a consequence, the operational requirement is derived in several functional requirements as following: Fn_Perf-18-Response Time to Operator Input The Response Time to Operator Input shall not exceed 250 ms. Fn_Perf-20-Input actions The HMI shall minimise the number of input actions required. Fn_Perf-21-User workload The HMI shall ensure a level of user workload which is consistent with efficient and effective activity. All the above functional requirements are the children of the operational requirement analysed in this example. 2.7 Scope of the functional specification This document does not aim to identify all the previously mentioned requirements, but only focuses on the first two requirements levels: operational and functional requirements. The operational requirements are already presented in Ref. 3, and they are recalled and listed in the present document for readability purpose. Most of the requirements are drawn from Ref. 5 or Ref. 9. In that case, their reference is attached to the requirements. These requirements have been validated in the frame of the validation activities. Edition: 2.1 Released Issue Page 17

19 2.8 Validation Activity The functional specification gives an engineer view of A-SMGCS. This logical modelling of the system will be used by manufacturers to produce a detailed design of the system. Once the system is developed, it will be tested through validation activities. This is illustrated in the following figure: EUROCONTROL & STAKEHOLDERS Operational Concept Operational Procedures Operational Specification Functional Specification Validation Activities : simulations, operational trials, Detailed Design Technical Tests MANUFACTURER Development Figure 5: A-SMGCS Project Life-Cycle The role of EUROCONTROL was to manage the validation by developing a Validation Master Plan and monitoring the validation exercises. The final aim of the validation activity was to validate the A-SMGCS operational concept, procedures, operational and functional requirements. Therefore the validation led to a refinement of the requirements being listed in the present document. The performance figures given in the requirements are also drawn from ICAO or EUROCAE documents. Those performance figures have usually not been tested and validated by operational experiences. When a figure has been validated through a project (3 validation projects involving 5 European airports took place), it is explicitly indicated in the associated requirements. Page 18 Released Issue Edition: 2.1

20 CHAPTER 3 Actors 3.1 ATCO As for Level 1, the role of the controller does not really change by the implementation of A-SMGCS Level 2, but the controller tasks evolve in the sense that the A-SMGCS control service provides the controller with a dedicated source of alert information in all visibility conditions, and the controller must apply the procedures related to each type of alert. This new source of data complements the conflict / infringement detection performed by the controller in analysing the traffic visually or using surveillance data. The traffic situation picture and the conflict / infringements detection are provided by A-SMGCS to the controller to help him performing its Control task by actions on the traffic via R/T. The controller uses the alerts to: Resolve conflict / infringements and give essential traffic information; Anticipate incursions into runways and restricted areas, and alert the mobiles; Anticipate risk of collision between mobiles on the runways, and alert the mobiles. When alerted by a conflict / infringement detection, the surveillance information also provided to the controller allows him to have a good awareness and understanding of the alert situation by identifying on his screen the area of alert situation and the mobiles implicated in the alert situation. Therefore, the controller is able to quickly take the appropriate action to resolve the conflict / infringement. Even if provided with the A-SMGCS control service, the controller shall not rely on it to detect conflict / infringement, but shall continue the analysis of the traffic situation to detect conflict / infringement himself as in SMGCS or A- SMGCS Level 1. Edition: 2.1 Released Issue Page 19

21 Figure 6: ATCO Role 3.2 Other operators A pre-requisite for an efficient detection of conflict / infringement is the correct configuration of the automated tool, i.e. through the provision of the following information: Airport Configuration: runways in use, runways status, restricted areas, Applied procedures and working methods: LVP, multiple line-ups. If not automatic, the configuration of the tool providing the automatic A- SMGCS control service may be allocated to one or more operators of the ATC team. 3.3 Pilot The role of the pilot remains the same as for Level 1. The role of the pilot is to navigate his aircraft following ATCO instructions and clearances provided through R/T, and with the help of visual aids and ATCO. The main tasks related to A-SMGCS are the following: Report its position to ATCO by R/T; Monitor surrounding traffic to prevent collision by visual means and traffic information provided by ATCO. At Level 2 the pilot is not a user of A-SMGCS, it will have the following impact on its work: Reduction of R/T report: since the controller knows the position and identity of aircraft provided by A-SMGCS, it is possible that some Page 20 Released Issue Edition: 2.1

22 aircraft position reports be not necessary anymore. This statement has to be confirmed by the definition of the procedures related to the use of A-SMGCS. Cooperative sensor checking: since aircraft are supposed to provide their identity through cooperative surveillance sensors, aircrew should check that this piece of equipment operates satisfactorily on board and should use it in the correct manner. 3.4 Vehicle Driver The role of the driver is to drive his vehicle following ATCO instructions and clearances provided by R/T, and with the help of visual aids and ATCO. The main tasks related to A-SMGCS are the following: Report its position to ATCO by R/T; Monitor surrounding traffic to prevent collision by visual means and traffic information provided by ATCO. With A-SMGCS the controller knows the position and identity of vehicles, so it is possible that some vehicle position reports are not necessary anymore. It has to be confirmed in the procedures related to the use of A-SMGCS. Moreover, if the vehicle is equipped for A-SMGCS, for instance with a transponder, the driver should check the equipment is activated and should use it in the correct manner. In A-SMGCS Level 2, the vehicle driver may optionally be provided with a guidance service. The role of the vehicle driver will not really change when equipped with the guidance service. Its tasks will evolve in the sense that the guidance service will provide to the driver a new source of data about its position related to the airport layout and fixed obstacles in all visibility conditions. This new source of data will complement the usual visual observation outside the vehicle. The guidance service does not require any inputs neither from the driver, nor from the controller. The driver will use this new information (position of its vehicle, airport map, reference points on the map, visualised on a display) for the navigation of its vehicle. For instance, when he is lost, there is no indication about its position outside, or he cannot see them because of reduced visibility conditions, he will be able to use the information provided by the guidance service to know exactly where he is on the airport platform. Edition: 2.1 Released Issue Page 21

23 CHAPTER 4 Data Model This section presents the types of data used in the functional specification. In the functional charts, they are used to indicate the type of data exchanged between two functions. 4.1 Airport traffic situation The airport traffic situation, presented in the following chart, is a data type, which includes Traffic Context (airport layout, etc), and Traffic Information. 4.2 Airport Traffic Situation Chart Figure 7: Airport Traffic Situation Chart 4.3 Traffic context The traffic context contains all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in its surveillance task. The traffic context at least includes: Page 22 Released Issue Edition: 2.1

24 Airport layout : geographical representation of various airport areas (TWY, RWY, etc); Reference points: holding positions, stop bars (and other airfield lighting), RWY thresholds, and; Fixed obstacles. The traffic context may optionally include (local issue): Status of runways and taxiways (open / closed); The reason a runway or taxiway is closed; Status of ATS system, e.g. landing systems aids, ATIS, etc, and; Other data as e.g. meteorological conditions, etc. 4.4 Traffic information Traffic information is a general term to indicate the following information about the Mobiles: Position; Identity; Other information (aircraft gate, etc). 4.5 Mobile Position Mobile Position indicates position for each aircraft and vehicle. Position of all mobiles is necessary for the Controller in order to monitor the traffic and in particular to detect the intruders. 4.6 Mobile Identity Mobile Identity indicates identity for each aircraft (call sign for instance) or vehicle. Identity allows the controller to identify each mobile. The identity of mobiles is necessary for the controller to communicate with the pilots or vehicle drivers in particular to issue clearances. The surveillance service will display the identity of all mobiles in a label attached to the corresponding target. Identity can only be provided by cooperative surveillance sensors. 4.7 Other Information about Traffic Other Information about traffic represents in various information such as destination parking and gate that could be provided to the controller if needed. Other parameters (velocity, etc) may be required for other A-SMGCS modules such as Conflicts/Infringements Detection. Edition: 2.1 Released Issue Page 23

25 4.8 Types of traffic information Functional Requirements for A-SMGCS Implementation Level 2 Figure 8: Types of traffic information A-SMGCS covers both ground and airborne traffic. Ground traffic concerns aircraft and vehicles on airport surface. Airborne traffic concerns aircraft above the manoeuvring area, e.g. landing and departing aircraft. 4.9 Surface Mobile Information Surface Mobile Information indicates traffic information for mobiles on the ground Airborne Aircraft Information Airborne Aircraft Information represents information about airborne traffic. This information is provided by approach Radar Surveillance Data Processing System (RDPS) and/or airport surveillance system. Airborne Aircraft Information is used to take into account in particular landing and departing aircraft and to ensure coordination between Ground control and Approach control Service Alert Service alert is used when system must not be used for intended operation (or when the system performances are restricted for significant failures). Such a situation could appear for different reasons (significant failures, equipment status, and low performance) C/I Alert C/I alerts are provided to the user when Conflicts/Infringements are detected. Page 24 Released Issue Edition: 2.1

26 CHAPTER 5 Operational Requirements In this section the operational requirements already defined for A-SMGCS Level 1, Ref. 2 and for A-SMGCS Level 2, Ref. 3 are listed. The requirements related to System Design, Evolution, Operational Range, Responsibilities, Interfaces, and Environmental Constraints are listed as "General Principles" while requirements specific to A-SMGCS services are listed in specific sections. 5.1 General principles Assumptions Cooperative All participating mobiles shall be cooperative. Sensors and Data Fusion It is expected that more than one type of sensor and a data fusion unit may be needed to meet the following requirements. Source: Ref Recommendation Op_Ds-1-Modularity to fit aerodrome needs An A-SMGCS shall be composed of different modules required for particular user needs or technological choices. Note 1 - Each aerodrome has its own operational needs and technological constraints. So each aerodrome will only implement the A-SMGCS modules fitting its needs and its technological choices in order to minimize the cost of its A-SMGCS. Consequently, ASMGCS consists of many elements which, when integrated, are designed to meet the specific operational requirements of an aerodrome. Note 2 - The combination of modules used for any A-SMGCS Level shall ensure that the requirements of this Level are met. It implies that minimum modules are required, i.e. cooperative surveillance. Source: Ref. 5, and Ref. 9, Op_Ds-2-HMI design The A-SMGCS design concept must be built upon the integration of the fundamental and principal system elements and facilitate the upgrading of those elements whilst maintaining, where possible, the same HMI and Edition: 2.1 Released Issue Page 25

27 5.1.3 Requirement Functional Requirements for A-SMGCS Implementation Level 2 references. This is important when considering harmonisation, familiarisation, and training requirements, and will allow the evolution of the system design through to a full A-SMGCS with the minimum negative impact on the users' ability to interface with the system. Source: Ref. 9, Op_Ds-3-Interoperability Standards like Standards and Recommended Practices (SARPs) shall be written and used to permit interoperability between the A-SMGCS elements developed by different manufacturers. the manufacturer, service provider and user. It should also encourage timely implementation by avoiding a proliferation of different specifications. Source: Ref. 9, Op_Env-1-Aerodrome An A-SMGCS should be capable of being installed at any aerodrome. Source: Ref. 5, Op_Evo-3-HMI impact A-SMGCS evolution shall have a minimum negative impact on the users' ability to interface with the system. This is important when considering harmonisation, familiarisation, and training requirements. Source: Ref. 9, Op_Evo-4-Modularity for A-SMGCS Levels The design principle of an A-SMGCS shall permit modular enhancements such as implementation of further A-SMGCS Levels. Note - A-SMGCS will evolve from a SMGCS by progressive enhancements to match the desired level of operations. The competent authority will determine, in consultation with the users, whether existing SMGCS needs to be upgraded to A-SMGCS. A-SMGCS for each aerodrome will comprise a different mix of modular components dependent upon operational factors. Source: Ref. 5, and Ref. 9, Op_Evo-5-Cost of evolution The design principle of an A-SMGCS shall permit system enhancements at minimal cost. Source: Ref. 9, Data recording Data should be stored to reconstruct the video rendering of each HMI unit. Op_Ds-4-Standardised Data Format The data interchange between systems should be performed in a standardised format in order to ensure an adequate exchange of information. Note - ASTERIX will most likely be the standard to be used for surveillance data in Europe. Source: Ref. 5, Op_Ds-5-Self-checking system A self-checking system with failure alerts shall be in the system design. Page 26 Released Issue Edition: 2.1

28 Source: Ref. 5, Op_Ds-6-System status Equipment which shows control data shall both be fail-safe and fail-soft. Note - The term "fail-safe" in this context means that sufficient redundancy is provided to carry data to the display equipment to permit some components of the equipment to fail without any resultant loss of data displayed. The term "fail-soft" means that the system is so designed that, even if equipment fails to the extent that loss of some data occurs, sufficient data remain on the display to enable the controller to continue operation without assistance of the computer. Source: Ref. 5, Op_Ds-7-Failure effect In case of a failure of an element of an A-SMGCS, the failure effect shall be such that the element status is always in the "safe" condition. Note - For instance, the element shall not provide wrong data which could impact on safety. Source: Ref. 5, Op_Ds-8-Self-restartable An A-SMGCS shall be self-restartable. Source: Ref. 5, Op_Ds-9-Restart The restart of an A-SMGCS shall include the restoration of pertinent information on actual traffic and system performance. Source: Ref. 5, Op_Env-2-Flight operations The ground elements of the system shall be sited so as not to affect flight operations. Source: Ref. 18 Op_Env-3-Equipment Any A-SMGCS equipment sited close to the movement areas should be: a) Lightweight; b) Frangible where appropriate; and c) Capable of withstanding the effects of jet blast. Note - It is understood that any A-SMGCS equipment installed in the movement area will comply with the general obstacle limitations requirements in Ref. 6, Note 2. Source: Ref. 18 Op_Env-4-Adverse effects The system shall have adequate immunity to adverse effects such as: a) Radio interference, including that produced by standard navigation, telecommunications and radar facilities (including airborne equipment); b) Signal reflections and shadowing caused by aircraft in flight, vehicles or aircraft on the ground, buildings, snow banks or Edition: 2.1 Released Issue Page 27

29 other raised obstacles (fixed or temporary) in or near the aerodrome environment; and c) Meteorological conditions or any state of the aerodrome resulting from adverse weather in which operations would otherwise be possible. Source: Ref. 5, Op_Env-5-Radio Spectrum Those elements of A-SMGCS which require the use of radio spectrum should operate in properly allocated frequency bands in accordance with appropriate national and international radio regulations. Source: Ref. 19 Op_Env-6-Interference to Other Systems A-SMGCS equipment shall not cause interference to standard radio navigation, surveillance, and communication systems. Source: Ref. 19 Op_Evo-1-Operational Change An A-SMGCS shall be capable of accommodating any operational change of the aerodrome after being installed, for instance a physical change in layout (runways, taxiways and aprons), or a change in the aerodrome procedures, rules, etc. Source: Ref. 5, and Ref. 9, Op_If-1-User interface A-SMGCS shall enable users to interface efficiently. Source: Ref. 5, Op_If-2-Operator interface A-SMGCS shall enable operators updating traffic context or configuration of the system to interface efficiently. Op_If-3-Interface with mobiles A-SMGCS shall be capable of interfacing with all cooperative mobiles in order to collect the required traffic data. In addition it should interface with existing and future embedded systems. Source: Ref. 5, and Ref. 17 Op_If-4-Interface with ground systems In order to fully benefit from an A-SMGCS by all parties concerned, the system should be capable of interfacing with the following ground systems: Air traffic management (ATM), including Integrated Initial Flight Plan Processing System (IFPS), departure management, etc. Approach surveillance system to take into account airborne aircraft; Stand management systems; Existing and future ATS systems; MET systems; Visual aids; Page 28 Released Issue Edition: 2.1

30 Any other system as part of the Collaborative Decision Making Process (CDM). Source: Ref. 5, Op_If-5-Interference with ATC The operation of A-SMGCS interfaces should not interfere with other ATC responsibilities, such as the observation of aerodrome activity and the requirements to provide alerting service. Source: Ref. 5, Op_Range-1-Visibility conditions A-SMGCS shall be capable of operating in all visibility conditions. Source: Ref. 5, (l) Op_Range-2-Capacity A-SMGCS shall be able to handle all traffic movements on their area of interest at any instant time. Note -Since capacity is a site-specific parameter, the determination of the maximum number of aircraft on the manoeuvring area should be based on the assumed peak traffic at the aerodrome. Aerodromes continually strive to increase capacity and therefore the number of movements, and hence aircraft and vehicles will probably increase over time. The A-SMGCS capacity figure should be sufficient to cater for expansion of this nature and reviewed on a regular basis to ensure that it is sufficient. Source: Ref. 5, Op_Range-3-Mobile types 1 An A-SMGCS shall support operations involving all aircraft types and all vehicles types within the coverage area. Source: Ref. 5, and Ref. 17 Op_Range-4-Mobile types 2 An A-SMGCS shall be capable of adaptation to cater for future aircraft types and vehicles types within the coverage area. Source: Ref. 5, Op_Range-5-Speeds and Orientation The system shall be capable of supporting operations of mobiles within the following parameters: Minimum and maximum speeds for aircraft on final approach, and runways; Minimum and maximum speeds for aircraft on taxiways; Minimum and maximum speeds for vehicles, and; Any heading. Source: Ref. 5, Op_Range-6-Velocity The A-SMGCS should cover the following speeds: 0 to 93 km/h (50 kt) for aircraft on straight taxiways; 0 to 36 km/h (20 kt) for aircraft on taxiway curves; Edition: 2.1 Released Issue Page 29

31 Functional Requirements for A-SMGCS Implementation Level 2 0 to 150 km/h (80 kt) for aircraft on runway exits; 0 to 460 km/h (250 kt) for aircraft on final approach, missed approach and runways; 0 to 150 km/h (80 kt) for vehicles on the movement area, and; 0 to 20 km/h (10 kt) for aircraft and vehicles on stands and stand taxi lanes. Source: Ref. 5, Op_Resp-1-Users Although the responsibilities and functions may vary, they shall be clearly defined for all users of A-SMGCS. Source: Ref. 5, 2.3 Op_Resp-2-Assignment An A-SMGCS shall be designed so that the responsibilities and functions may be assigned to the following: a) The automated system; b) Controllers; c) Pilots; d) Vehicle drivers; e) Airport authorities, and; f) System operators. Note 1 - The allocation of functions and/or responsibilities might differ depending on visibility condition, level of automation and level of implementation of an A-SMGCS. A different division of functions among the control personnel (e.g. between authorities responsible for aerodrome movement control and apron management services) may also be necessary as a result of possible changes in procedures caused by automation. Note 2 - ATC will be responsible for the management and overall operation of the system. When certain functions will be delegated to automated elements of the system, responsibilities for the integrity and reliability of those functions lie with the service providers, certification authorities, manufacturers and software suppliers. Note 3 - When A-SMGCS is in operation, pilots remain responsible for the safety and control of aircraft. Note 4 - At Level 1 and 2 ATC controllers and pilots are the only critical decision makers. Their decisions are based on surveillance data which have a specify integrity. Source: Ref. 5, 2.3 Op_Resp-3-A-SMGCS category The responsible authority shall be in charge of notifying the application of Mode-S transponder operating procedures in the Aeronautical Information Publication (AIP). Source: Ref. 17 Page 30 Released Issue Edition: 2.1

32 5.2 Surveillance Service Requirement Op_Mon-1-Equipment Status The operational status of all A-SMGCS equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation. Source: Ref. 5, and Op_Mon-2-Performance Monitoring of the performance of an A-SMGCS should be provided such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service. Source: Ref. 5, Op_Mon-3-Data The A-SMGCS shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation. Note - As an example when a mobile is still on his area of interest, the system shall continuously detect the mobile; otherwise the user shall be timely alerted. Source: Ref. 5, Op_Mon-4-Back-up The system shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur. Source: Ref. 5, Op_Mon-5-System Failures Operationally significant failures in the system shall be clearly indicated to the control authority and any affected user. Source: Ref. 5, and Op_Mon-6-Failure Alerts All critical elements of the system should be provided with audio and visual indication of failure given in a timely manner. Source: Ref. 5, Op_Perf-1-Probability of Detection The probability that an actual aircraft, vehicle, or object is detected and reported at the output of the surveillance element of the A-SMGCS shall be: 99.9% minimum on the manoeuvring area 98% minimum on the apron for moving aircraft only Exceptions for well-identified areas on airport surface are acceptable (defined locally). Note - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors. Source: Ref. 5, (a); Ref. 9, 3.2.3, 3.2.4, and Ref. 16 Edition: 2.1 Released Issue Page 31

33 Op_Perf-2-Probability of False Detection The probability that anything other than an actual aircraft, vehicle, or object is detected and reported by the surveillance element of the A-SMGCS shall not exceed 0.1%. Note 1 - The surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors. Note 2 - Some ATS Providers request a Probability of False Detection less than 1%. Source: Ref. 5, (a) and Ref. 9, and Op_Perf-3-Probability of Identification The probability that the correct identity of cooperative aircraft and vehicles, broadcasting their identification correctly, is reported at the output of the surveillance element shall be: 99.9% minimum on manoeuvring area 98% minimum on apron. Note 1 - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors. Note 2 - Some ATS providers request a Probability of Identification of at least 99% while the Probability of Identification required for Mode S radars is 99.9%. Note 3 - The requirement only intends to specify the performance of the ground system. E.g. pilot deviations for operating Mode-S transponder are not taken into account. Source: Ref. 5, (a); Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17 Op_Perf-4-Probability of False Identification The probability that the identity reported at the output of the surveillance element is not the correct identity of the actual aircraft, vehicle, or object shall not exceed 0.1%. Note 1 - The output of the surveillance element means at the output of the process which builds a comprehensive surveillance package after fusion of data provided by the different surveillance sensors. Note 2 - The value of 0.1% for Probability of False Identification is already requested by some ATS providers and accepted by manufacturers. Note 3 - The requirement only intends to specify the performance of the ground system. E.g. pilot deviations for operating Mode-S transponder are not taken into account. Source: Ref. 5, (a); Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17 Op_Perf-5-Position Accuracy For the surveillance service, the allowable error in reported position shall be consistent with the requirements set by the control task of the controller: 7.5 m on manoeuvring area at a confidence level of 95% Page 32 Released Issue Edition: 2.1

34 12 m on apron at a confidence level of 95%. Note - For Reported Position Accuracy (RPA), ICAO specification recommends a value of 7.5m (Ref. 5, and 4.2.3). For Ref. 10, a value of 7.5m (95% level of confidence) is recommended. For Ref. 9, , a value of 12m would be reasonable for the surveillance service. Source: Ref. 5, and 4.2.3; Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17 Op_Perf-6-Position Resolution The mobile position resolution shall be at least 1 m. Source: Ref. 9, Op_Perf-7-Altitude Accuracy Where airborne traffic participates in the A-SMGCS, the level of an aircraft when airborne shall be determined within ±10m. Note - Justification has not been provided for the need of aircraft altitude for A-SMGCS and for the value of its accuracy. However, it has been decided to keep this requirement as such in the document because it is provided by ICAO. If no more information about this requirement is provided so far, the validation activity will determine the status of this requirement. Source: Ref. 5, Op_Perf-8-Update rate Where appropriate, the update rate of an A-SMGCS shall be consistent with the requirements set by the control task of the controller: 1 per second. Note - Ref. 9, 3.2.3, 3.2.4, and Ref. 5, require the update rate should be at least 1 per second. For example, in one second, an aircraft rolling at 10 kts covers a distance of 5 meters. A vehicle at 35 km/h will move of 10 metres. In that case, the position displayed to the controller can differ of 10 metres from the actual position before being updated with the new reported value. If we take the maximum speed of 93 km/h (50 kt) for aircraft on straight taxiways (Ref. 5, ), the displayed position can differ by 25 metres. Source: Ref. 5, and Ref. 9, and Op_Perf-10-Availability The availability of an A-SMGCS shall be sufficient to support the safe, orderly, and expeditious flow of traffic on the movement area of an aerodrome. Source: Ref. 5, ; Ref. 9, Op_Perf-11-Reliability A failure of equipment shall not cause: An unacceptable reduction in safety (fail soft), and; The loss of basic functions. Note - this requirement is achieved using backup and/or redundancy systems. Source: Ref. 5, ; Ref. 9, and Ref. 17 Op_Perf-12-Continuity of Service 1 An A-SMGCS shall provide a continuous service. Source: Ref. 5, ; Ref. 9, and Ref. 10, and Edition: 2.1 Released Issue Page 33

35 Op_Perf-14-Recovery time For a cold restart, the recovery time of an A-SMGCS shall be acceptable and the maximum value shall be specified locally. (Recommendation) Note During the validation activity the requirement of ICAO guidance for recovery within a few seconds could not be met. Technology might evolve over time and requirements should be reviewed regularly. Source: Ref. 5, and Ref. 17 Op_Serv-1-Service A-SMGCS shall provide the surveillance service to the users. Op_Serv-2-User The users of the surveillance service shall be all control authorities concerned in the manoeuvring area of the aerodrome. Op_Serv-3-Airport Traffic Situation The surveillance service shall continuously provide the following airport traffic situation: Traffic Information, and Traffic context. Op_Serv-4-Traffic information 1 The surveillance service shall continuously provide the following traffic information: Position of all vehicles on the area of interest for vehicles, including intruders; Identity of all cooperative vehicles on the area of interest for vehicles; Position of all relevant aircraft on the area of interest for aircraft, including intruders; Identity of all relevant aircraft on the area of interest for aircraft, and; History of the mobiles position (e. g. the 3 last positions displayed). Op_Serv-5-Traffic information 2 The traffic information may optionally include other information about traffic, such as: Vehicle type; Aircraft type and registration number; Aircraft s identification (ICAO 3 letter code and flight number); Mode A code and Mode S code ; Departure / destination Airport; Estimated Time of Arrival / Departure; Allocated Stand, and current stand status (occupied/free); Wake Vortex Category; CFMU Slot time (if applicable); Assigned runway and SID/STAR/Approach Procedure; Estimated and actual off-block times, and; Page 34 Released Issue Edition: 2.1

36 Any other information deemed useful for the local operations. The provision of such information shall be made compliant with an integrity level that is to be determined locally. Op_Serv-6-Area of interest for vehicles The area of interest for vehicles shall be the manoeuvring area. Op_Serv-7-Area of interest for aircraft The area of interest for aircraft shall be the movement area, plus a volume around the runways for aircraft on approach to each landing runway direction, at such a distance that inbound aircraft can be integrated into an A-SMGCS operation and that aerodrome movements, including aircraft departures, relevant missed approaches or aircraft crossing the relevant active runways, can be managed. Source: Ref. 5, , , and Op_Serv-8-Traffic context1 Traffic context provided by the surveillance service shall contain all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in his surveillance task. Op_Serv-9-Traffic context2 The traffic context shall at least include: Airport layout: geographical representation of various airport areas (TWY, RWY, etc); Reference points: holding positions, stop bars (and other airfield lighting), RWY thresholds; Fixed obstacles. Source: Ref. 5, Op_Serv-10-Traffic context3 The traffic context may optionally include (local issue): Status of runways and taxiways (open / closed); An indication of the duration of the runway/taxiway closure (temporary, long term); Status of ATS systems: landing systems aids, ATIS; Other data: meteorological conditions Source: Ref. 5, Op_Serv-11-Position Each mobile shall be seen in the correct position with respect to the aerodrome layout and other traffic. Note - It means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement. Op_Serv-12-Label The surveillance service shall provide to the user the ability to manually put the right callsign in the label associated to a vehicle equipped with mobile cooperative equipment used for different vehicles. Op_Serv-13-Transition Edition: 2.1 Released Issue Page 35

37 A seamless transition should be provided between the surveillance for an A- SMGCS and the surveillance of traffic in the vicinity of an aerodrome. Source: Ref. 5, Scenario A: Arriving Aircraft This section and the following one describe two operational scenarios for A- SMGCS in order to provide to the reader a better understanding of A-SMGCS surveillance service. An aircraft approaching an airport will be detected by the approach Radar Data Processing System (RDPS). When arriving over the runway threshold, this aircraft must be displayed to the ground controllers. A-SMGCS will provide a seamless transition between air and ground surveillance systems. Actually, the aircraft will be firstly detected by A-SMGCS through the data sent by the approach surveillance system. As soon as the aircraft is under coverage of the cooperative surveillance sensor, surveillance data from cooperative and non-cooperative surveillance sensors will be combined by the data fusion process to provide to the controller the exact position and identity of the aircraft. During the taxiing phase on the manoeuvring area, the controller will always have the exact position and identity of the aircraft. During the taxiing on the apron, the A- SMGCS surveillance service will continue to provide the aircraft position and identity till the stand. Note - In the future, approach Surveillance Data could be not only provided by Radar but also by other technologies such as ADS Scenario B: System Failure Considering the previous scenario, we can imagine that all the cooperative surveillance sensors have a significant failure. In this case A-SMGCS is not able to collect the identity of the aircraft, but it could continue to display the identity previously provided by the approach RDPS. In this situation, the controller will be alerted by the service monitoring process that A-SMGCS may not be able to provide identity of mobiles and the controller should revert to adequate back-up procedures. In particular, the identity of cooperative vehicles entering the manoeuvring area won't be provided to the controller. 5.3 Control Service Requirements All A-SMGCS performance and system monitoring operational requirements for surveillance service apply to A-SMGCS control service. The performance requirements presented in the following section are specific to the control service. Op_Perf-15-Position Accuracy The allowable error in reported position used for conflict/infringement (within runway protection area) shall be consistent with the requirements set by the Control service: 7.5m at 95% level of confidence on the manoeuvring area, and; 12m at 95% level of confidence on the apron. Page 36 Released Issue Edition: 2.1

38 Note - The required position accuracy may be specifically defined at each airport by the ATS authority on the basis of local safety analysis. Source: Ref , , and 4.2.3; Ref and 3.2.4; Ref. 17 Op_Perf-16-Reported Velocity Accuracy The velocity shall be determined to the following accuracy: Speed: <5m/s Direction of movement consistent with alerting algorithms Note - For reported velocity accuracy, ICAO specification recommends the following values: Speed: +/- 1 Kt (0.5m/s) Direction of movement: +/-1. According to the performance of existing tracking systems studied in other projects these values do not seem to be achievable. Therefore, we recommend the values required by Ref. 9, 3.2.4: <5 m/s for speed and for direction of movement consistent with alerting algorithms. Source: Ref and ; Ref Op_Perf-17-Target Report Velocity Resolution The target report velocity resolution shall be: Speed: 0,25m/s Source: Ref Op_Perf-18-Alert latency The alert resulting of conflict / infringement detection shall be provided to the user well in advance within a specified time frame, to enable the appropriate remedial action with respect to: a) Conflict / infringement prediction; b) Conflict / infringement detection; and c) Conflict / infringement resolution. Source: Ref Op_Perf-19-Alert Continuity The Conflict/Infringement Alert should be displayed continuously while the conflict is detected. Source: Ref Op_Perf-20-False and Nuisance alert number The number of 3 false alerts (stage ALARM) should not be exceeded on a weekly basis. Source: Ref. 14 Op_Perf-21-Impact of false alert on safety The false alerts shall not impact on the airport safety. Op_Serv-14-Service A-SMGCS Level 2 shall provide the control service to the users. Op_Serv-15-User Edition: 2.1 Released Issue Page 37

39 The users of the A-SMGCS control service shall be all control authorities concerned in the manoeuvring area of the aerodrome. Op_Serv-16-Conflicts/infringements on runway The control service shall detect the conflicts/infringements on runway: 1) Aircraft arriving to, or departing aircraft on, a closed runway; 2) Arriving or departing aircraft with traffic on the runway (including aircraft beyond the runway holding positions); 3) Arriving or departing aircraft with moving traffic to or on a converging or intersecting runway; 4) Arriving or departing aircraft with opposite direction arrival to the runway; 5) Arriving or departing aircraft with traffic crossing the runway; 6) Arriving or departing aircraft with taxiing traffic approaching the runway (predicted to cross the runway-holding position); 7) Arriving aircraft exiting runway at high speed with converging taxiway traffic; 8) Arriving aircraft with traffic in the sensitive area (when protected); 9) Aircraft exiting the runway at unintended or non-approved locations; 10) Unauthorised traffic approaching the runway, and; 11) Unidentified traffic approaching the runway; Source: Ref (a) Op_Serv-17-Restricted area incursions The control service shall detect the restricted area incursions caused by an aircraft (not vehicles) into an area such as closed TWY, ILS, or MLS critical area, to be defined locally for each aerodrome. Source: Ref and Op_Serv-18-Runway protection area The runway protection area shall be composed of two boundaries: A ground boundary to detect the mobiles on the surface, an air boundary to detect airborne aircraft. Op_Serv-19-Ground boundary The length of the ground boundary must at least include the runway strip. The width could be defined, and different, according to the meteorological conditions, e.g. Non-LVP, LVP. As an example based on today ILS holding positions: In Non-LVP: ground boundary defined by Cat I holding position In LVP: ground boundary defined by Cat II / III holding position This ground boundary will be used for both INFORMATION and ALARM stages. Note - In order to avoid unnecessary INFORMATION or ALARM to the controllers, current systems wait until the mobile has crossed the boundary. Subject to further development, if the runway protection is ensured by an algorithm which could predict that a mobile is able or not to stop before Page 38 Released Issue Edition: 2.1

40 entering the protection area, i.e. the ground boundary, an INFORMATION / ALARM could be generated before the mobile crosses the boundary. Such algorithms, based on the speed and position of a mobile, may already exist but they have to be evaluated. Op_Serv-20-Air boundary The air boundary shall be defined as a flight time to threshold and would take into account the two stages of alert, INFORMATION and ALARM, as well as the meteorological conditions: Non-LVP: INFORMATION around T1 = 30'', ALARM around T2 = 15'' LVP: INFORMATION around T1 = 45'', ALARM around T2 = 30'' Note - Theses times should be configurable, depending upon optimisation at the aerodrome. Source: Ref and Op_Serv-21-Traffic Context Update For the Conflict/Infringement detection, additional updated and correct traffic context information shall be provided to the system as required for the detection. Examples: Airport Configuration: runways in use, runways status, restricted areas; Applied procedures: e.g. LVP; ATC working methods: e.g. multiple line-ups. Source: Ref. 13 and Ref. 17 Op_Serv-22-Alert The control service shall alert the users in case of conflict/infringement detection. Source: Ref Op_Serv-27-Stages of alert The control service shall provide 2 stages of alert: Stage 1 alert is used to inform the controller that a situation which is potentially dangerous may occur, and he/she needs to be made aware of. According to the situation, the controller receiving a stage 1 alert may take a specific action to resolve the alert if needed. This is called INFORMATION step. The stage 2 alert is used to inform the controller that a critical situation is developing which needs immediate action. This is called ALARM step. Note - Controllers have different preferences, some of them want to be alerted only when the situation is critical (only stage 2 alerts), and others wish more anticipation (2 stages of alert). This is confirmed by the evaluations performed in the BETA project. As a consequence, some ATS providers may choose to have ALARM only, and not use INFORMATION. The choice of having several stages of alerts presented to the controller, according to the conflict / infringement, should be left to the ATS providers and is a local decision. Op_Serv-28-Alert priority Priorities should be established so as to ensure system logic performs efficiently. Conflict alerting priorities should be as follows: a) Runway incursions. Edition: 2.1 Released Issue Page 39

41 5.3.2 Scenario b) Restricted area incursions. Functional Requirements for A-SMGCS Implementation Level 2 Source: Ref Op_Serv-29-Adaptation to local procedures In order to efficiently assist ATCO, the automated A-SMGCS control service should be configurable to adapt to local ATC procedures and working methods. Source: Ref. 17 Op_Serv-30-Traffic Information Update For the Conflict/Infringement detection, additional updated and correct traffic information shall be provided to the system such as mobiles velocity. This section describes an operational scenario for A-SMGCS in order to provide to the reader a better understanding of A-SMGCS control service. Meteorological conditions are supposed to be LVP; Considering an aircraft approaching the runway 14. This aircraft is assumed to be already under coverage of the A-SMGCS surveillance sensors. The data collected by cooperative and non cooperative surveillance sensors are combined by the data fusion process to provide surveillance information to the controller and to the conflict/infringement detection process; Considering a cooperative vehicle which is going to enter the runway 14. Since it entered on the manoeuvring area, he has been continuously tracked by the A-SMGCS surveillance service too, and surveillance data are provided to the controller and to the conflict/infringement process through the data fusion process. In this scenario the vehicle enter the runway without requesting clearance to the ATCO, believing he is on a taxiway. When the aircraft arrives at T1 = 45s from the runway threshold, the vehicle is still on the runway. The Conflict/Infringement detection process detects the conflict and then generates an INFORMATION. INFORMATION Figure 9: Example - Information The controller considers the INFORMATION and analyses the surveillance data provided by the surveillance service. If the vehicle is not exiting the runway, he contacts the driver to inform him that there is an aircraft on final and that he must immediately exit the runway. If he has no response and no reaction, the controller can already order the pilot to go around. Page 40 Released Issue Edition: 2.1

42 When the aircraft arrives at T2=30s from runway threshold, if the situation is not resolved, the conflict/infringement process generates an ALARM and the controller will immediately order the aircraft pilot to go around. ALARM Figure 10: Example - Alarm 5.4 Guidance Service to Vehicle Drivers (Optional) Requirements Op_Mon-7-Equipment Status The operational status of all guidance service equipment shall be monitored by the system, and alerts shall be provided when the system must not be used for the intended operation. Source: Ref Op_Mon-8-Performance Monitoring of the performance of the guidance service should be provided such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service. Source: Ref Op_Mon-9-Data The A-SMGCS shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation. Source: Ref Op_Mon-10-Back-up The system shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur. Source: Ref Op_Mon-11-System Failures Operationally significant failures in the system shall be clearly indicated to any affected user. Source: Ref and Op_Mon-12-Failure Alerts Edition: 2.1 Released Issue Page 41

43 All critical elements of the system should be provided with audio and visual indication of failure given in a timely manner. Source: Ref Op_Perf-22-Position Accuracy For the guidance service, the allowable error in reported position shall be consistent with the requirements set by the task of the user: 12m at a confidence level of 95 %. Note - For the Guidance service the position accuracy doesn't need to be better than for surveillance service. If the same equipment is used to provide the position both to the control and the guidance service, the position accuracy must be consistent with the Position Accuracy requirement set for the control service. Source: Ref ; Ref , and Ref. 17 Op_Perf-23-Position Resolution The mobile position resolution shall be 1m. Source: Ref Op_Perf-24-Update rate Where appropriate, the update rate of the reported mobile position shall be consistent with the requirements set by the task of the driver: approximately 1 per second. Note - EUROCAE and ICAO-A-SMGCS require an update rate of at least 1 per second. For example, in one second, a vehicle at 35 km/h will move of 10 metres. In that case, the position displayed to the user can differ of 10 metres from the actual position before being updated with the new reported value. If we take the maximum speed of 150 km/h (80 kt) for vehicles on the movement area, the displayed position can differ by 40 metres. Source: Ref , and Ref Op_Perf-25-Integrity A-SMGCS shall preclude failures that result in erroneous data provided to the users. Source: Ref , and Ref Op_Perf-26-Reliability A failure of equipment shall not cause: A reduction in safety (fail soft), and; The loss of basic functions. Source: Ref , and Ref Op_Perf-27-Continuity of Service 1 An A-SMGCS shall provide a continuous service. Note The provisions of Ref. 5 are extended to vehicle drivers. Source: Ref , Ref Op_Perf-28-Continuity of Service 2 Any unscheduled break in continuity shall be sufficiently short or rare as not to affect the safety of mobiles. Page 42 Released Issue Edition: 2.1

44 Note The provisions of Ref. 5 are extended to vehicle drivers. Source: Ref , Ref Op_Perf-29-Recovery time When restarting, the recovery times of the guidance service shall be compatible with user operations (a value of 1 minute would be reasonable as a maximum). Source: Ref and Op_Serv-23-Service A-SMGCS Level 2 may optionally provide the guidance service to the users. Op_Serv-24-User The users of the guidance service shall be the vehicles drivers. Op_Serv-25-Display Items The guidance service of an A-SMGCS Level 2 shall display the following items to the user: Vehicle position; Airport layout: geographical representation of various airport areas (TWY, RWY, etc); Optionally: Reference points: holding points, stop bars (and other airfield lighting), RWY thresholds; Fixed obstacles; Other vehicle information (heading, etc), if required by the user. Op_Serv-26-Position The vehicle shall be seen in the correct position with respect to the aerodrome layout. Note - This means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement. Edition: 2.1 Released Issue Page 43

45 CHAPTER 6 Functional specification for A-SMGCS Level 2 services to ATCOs 6.1 Functional Breakdown for A-SMGCS Level 2 Services to ATCOs The functions, that A-SMGCS shall perform, have been defined on the basis and through close examination of operational requirements. The operational requirements have been allocated to each function which implies that each function is specified by a list of functional requirements which have been derived from the operational requirements and which could thus be considered as the children of operational requirements. These functions are independent from each other and linked by data flows. The description of the different functions and the links between each function represent the functional architecture of A-SMGCS which is presented in the following sections Functional Architecture (Level 2) Figure 11: Ground Segment Functional Architecture (Level 2) Page 44 Released Issue Edition: 2.1

46 6.1.2 Provide Traffic Information This function is in charge of providing the traffic information (position and identity of the mobiles). The traffic information can be collected from different systems: Cooperative / non-cooperative surveillance sensors, approach surveillance systems; Other systems. From the analysis of the operational requirements, it can be concluded that: A non-cooperative surveillance sensor is needed to detect any mobile on the surface, in particular intruders; A cooperative surveillance sensor is needed to provide the identity of the participating mobiles on the surface; An approach surveillance system will provide the information on departing / arriving aircraft in airside; Other systems will provide any other traffic information required. All the traffic information provided by these different sources need to be computed in order to obtain a consistent traffic information picture. This is performed by the "Data Fusion" function. All the above functions are described in the following sections Functional Architecture Figure 12: Functional Architecture Acquisition of traffic information from non-cooperative surveillance sensors At least one non-cooperative surveillance sensor is needed to detect any mobile on the surface, in particular intruders. This sensor (e.g. SMR) is able to provide the position of any mobile on the airport surface Acquisition of traffic information from cooperative surveillance sensors At least one cooperative surveillance sensor (e.g. ADS-B / Mode S) is needed to provide the identity of the participating mobiles on the surface. The participating mobiles are those known by the aerodrome authority, and likely to move on the manoeuvring area. All the participating mobiles are required to Edition: 2.1 Released Issue Page 45

47 be cooperative, allowing the cooperative surveillance sensor to collect information about the mobiles, at least their identity Acquisition of traffic information from approach RDPS The approach RDPS (Radar Data Processing System) will provide the information (at least position and identity) on airborne aircraft to be covered by A-SMGCS. In the future, this surveillance data could be collected from different sensors such as Automatic Dependant Surveillance Acquisition of other information about traffic Data Fusion Other systems will provide any other traffic information (e.g. aircraft type, gate, etc), which may be required by local authority. The surveillance information provided by the different surveillance sensors is combined by a data fusion process to provide a comprehensive surveillance package Provide traffic context This function is in charge of providing the traffic context (airport configuration, runways status, etc). The data on traffic context may be obtained automatically from other systems (MET systems, etc), or updated by a human operator. It means this function is composed of sub-functions as described in the following sections Functional Architecture Figure 13: Functional Architecture Acquisition of traffic context from other ground systems This function is in charge of automatically providing the traffic context obtained from other systems (MET systems, etc) Manual update of traffic context This function is in charge of providing the traffic context (airport configuration, runways status, etc) updated by a human operator Update traffic context The Traffic Context provided by the different sources (automatic or manual) is combined to provide a comprehensive traffic context package. Page 46 Released Issue Edition: 2.1

48 6.1.4 Conflicts / Infringements Detection This function shall consider traffic information and traffic context information as input data, and generates C/I alert when a predefined Conflict/Infringement situation is detected according to predefined scenario provided in annex Interface with user This function is the interface with the users. It is in charge of providing to the users all the surveillance data required and alerts generated by the service monitoring process Service monitoring This function monitors the quality of service of A-SMGCS (equipment status, performances, operational failures, etc), and generate an alert when A- SMGCS must not be used for the intended operation. 6.2 Functional Requirements for A-SMGCS Level 2 services to ATCOs This section lists for each function the functional requirements. It could be noted that the operational requirements related to Design, Operational Range and Evolution which apply to each function are not allocated, and considered as "general principles" requirements. In the same way, operational requirements, dealing with constraints from A- SMGCS environment, are not allocated to A-SMGCS functions because they do not refer to the functional specification but more to the technical characteristics of the A-SMGCS equipment Provide Traffic Information Acquisition of traffic information from non-cooperative surveillance sensors Fn_If-1-Data format The data interchange with non-cooperative surveillance sensors shall be performed in a standardised format in order to ensure an adequate exchange of information. Note - ASTERIX will be the European standard to be used for surveillance data. Source: Ref. 5, Fn-1-Mobile Position The non-cooperative surveillance sensors shall determine the position of any mobile in its area of interest Acquisition of traffic information from cooperative surveillance sensors Fn_If-2-Data format The data interchange with cooperative surveillance sensors shall be performed in a standardised format in order to ensure an adequate exchange of information. Edition: 2.1 Released Issue Page 47

49 Note - ASTERIX will be the European standard to be used for surveillance data. Source: Ref. 5, Fn-2-Mobile Position The cooperative surveillance sensors shall determine the position of any cooperative mobile in its area of interest. Fn-3-Mobile Identity The cooperative surveillance sensors shall determine the identity of any cooperative mobile in its area of interest. Fn-73-Mobile Velocity The cooperative surveillance sensors shall determine the velocity of any cooperative mobile in its area of interest Acquisition of traffic information from approach RDPS Fn_If-3-Data format The data interchange with approach RDPS shall be performed in a standardised format in order to ensure an adequate exchange of information. Note - ASTERIX will be the European standard to be used for surveillance data. Source: Ref. 5, Fn-4-Aircraft Position The approach RDPS shall determine the position of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). The approach RDPS shall determine the position of any airborne aircraft to be covered by A-SMGCS). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/infringements. Fn-5-Aircraft Identity The approach RDPS shall determine the identity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). The approach RDPS shall determine the identity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/infringements. Fn-6-Provide a seamless transition A seamless transition should be provided between the surveillance for an A- SMGCS and the surveillance of traffic in the vicinity of an aerodrome. Source: Ref Fn-66-Aircraft Velocity If possible, the approach RDPS shall determine the velocity of any airborne aircraft to be covered by A-SMGCS (e.g. departing or arriving aircraft). In particular, airborne aircraft shall be considered within the air boundary used to detect conflicts/infringements Acquisition of other information about traffic Fn_If-4-Data format Page 48 Released Issue Edition: 2.1

50 Data Fusion The data interchange with ground systems shall be performed in a standardised format in order to ensure an adequate exchange of information. Note - ASTERIX will be the standard to be used for surveillance data. Source: Ref. 5, Fn-7-Other Information about Traffic This function should optionally provide any other information about traffic from other ground systems and as required by the users. Fn_Perf-1-Reported Position Accuracy At Level 1, the error in reported position shall be: 7.5 m on the manoeuvring area at a confidence level of 95% 12 m on the apron at a confidence level of 95% Source: Ref , Ref. 16 and Ref. 17 At Level 2, the error in reported position shall be: 7.5m at 95% 12m at 99% When provided to Conflict/Infringement process i.e. on the runway protection area. Source: Ref and Ref. 16 Fn_Perf-2-Reported Position Resolution The mobile position resolution shall be at least 1 m. Source: Ref Fn_Perf-3-Aircraft level accuracy The allowable error in the level of an aircraft when airborne shall be ±10m. Source: Ref Fn_Perf-4-Update rate The update rate of surveillance information shall be at least 1 per second. Source: Ref and Ref Fn_Perf-5-Probability of Detection The probability that an actual aircraft, vehicle, or object is detected and reported at the output of the Data Fusion shall be: 99.9% at minimum on the manoeuvring area 98% at minimum on the movement area Source: Ref (a), Ref , Ref. 16 and Ref. 17 Fn_Perf-6-Probability of False Detection The probability that anything other than an actual aircraft, vehicle, or object is detected and reported at the output of the data fusion shall not exceed 0.1%. Source: Ref (a) and Ref Fn_Perf-7-Probability of Identification Edition: 2.1 Released Issue Page 49

51 The probability that the correct identity of an aircraft, vehicle, or object is reported at the output of the surveillance element shall be: 99.9% at minimum on the manoeuvring area 98% at minimum on the apron Note - The requirement only intends to specify the performance of the ground system. E.g. pilot deviations for operating Mode-S transponder are not taken into account. Source: Ref (a), Ref , Ref. 16 and Ref. 17 Fn_Perf-8-Probability of False Identification The probability that the identity reported at the output of the surveillance element is not the correct identity of the actual aircraft, vehicle, or object shall not exceed 0.1%. Note - The requirement only intends to specify the performance of the ground system. E.g. pilot deviations for operating Mode-S transponder are not taken into account. Source: Ref (a), Ref , Ref. 16 and Ref. 17 Fn_Perf-46-Reported Velocity Accuracy The velocity shall be determined to the following accuracy: Speed: <5m/s Direction of movement consistent with alerting algorithms Note - For reported velocity accuracy, ICAO specification recommends the following values: Speed: +/- 1 Kt (0.5m/s) Direction of movement: +/-1. According to the performance of existing tracking systems studied in other projects these values do not seem to be achievable. Therefore, we recommend the values required by Ref. 9, 3.2.4: <5 m/s for speed and for direction of movement consistent with alerting algorithms. Source: Ref and ; Ref Fn_Perf-47-Target Report Velocity Resolution The target report velocity resolution shall be: Speed: 0,25m/s Source: Ref Fn-9-Traffic Information This function shall provide the complete Traffic Information Provide traffic context Acquisition of traffic context from other ground systems Fn_If-5-Data format The data interchange with ground systems shall be performed in a standardised format in order to ensure an adequate exchange of information. Page 50 Released Issue Edition: 2.1

52 Note - ASTERIX will be the standard to be used for surveillance data. Source: Ref. 5, Fn-10-Traffic Context This function shall provide information about traffic context (runways status, meteo, etc) from ground systems (MET systems, other ATS systems) Manual update of traffic context Fn_Perf-9-Response Time to Operator Input The Response Time to Operator Input: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref , Ref. 17 Fn-11-Traffic Context This function shall update information about traffic context (airport layout, etc), which cannot be automatically updated Update traffic context Fn-12-Traffic Context This function shall provide traffic context containing all data, except traffic information (mobiles position and identity), which is necessary for the ATCO in its surveillance task. Fn-13-Operational change This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, rules... Source: Ref and Ref Fn-72-Level 2 Traffic context For the Conflict/Infringement detection, additional updated and correct traffic context information shall be provided to the system such as: Airport Configuration: runways in use, runways status, restricted areas, etc.; Applied procedures and working methods: LVP, multiple line-ups Conflicts / Infringements Detection Fn_Perf-25-Probability of detection of an alert situation The probability of detection of an alert situation should be greater than 99.9%. Source: Ref and Ref Fn_Perf-26-Probability of false alert The number of 3 false alerts (stage ALARM) should not be exceeded on a weekly basis. Source: Ref. 14 Fn_Perf-27-Alert Response Time Edition: 2.1 Released Issue Page 51

53 Delays due to the control service should be kept small compared to other delays in the system, particularly with regard to human action, aircraft braking times, etc... In the absence of a specific operational requirement, the proposed minimum performance figure for the ART should be 0.5s. Source: Ref Fn-36-Alert report The output of alert report which may be used by the HMI should at least include: Type of alert; Alert stage; Time of alert; Identity of target(s) in alert situation. Source: Ref Fn-37-Alert hierarchy Priorities should be established so as to ensure system logic performs efficiently. Conflict alerting priorities should be as follows: Runway incursions. Restricted area incursions. Fn-38-Adaptation to local procedures In order to efficiently assist ATCO, the automated A-SMGCS control service shall be configurable to adapt to local ATC procedures and working methods. Fn-58-Conflicts/infringements on runway This function shall detect the conflicts/infringements on runway provided in annex. Fn-60-Restricted area incursions This function shall detect the restricted area incursions caused by an aircraft (not vehicles) into an area such as closed TWY, ILS, or MLS critical area, to be defined locally for each aerodrome Interface with user Fn_Perf-10-Situation assessment The HMI shall permit rapid situation assessment. Source: Ref Fn_Perf-11-Map Accuracy The airport map accuracy shall provide for reference points the following values: Thresholds - 1 m Runway limits - 1 m Holding positions m Stop bars m Runway exits m Page 52 Released Issue Edition: 2.1

54 Taxiway intersections m Intersection limits m Switchable centre line light block limits m Parking positions m Source: Ref. 5, Chapter 3, table 3-1 Fn_Perf-12-Display Resolution The Display Resolution shall be consistent with the Display Position Accuracy. Source: Ref Fn_Perf-13-Position Registration Accuracy The Position Registration Accuracy should not appreciably degrade the accuracy of the information it receives. (In fact, it is to be expected that the only degradation of accuracy attributable to the HMI will be that caused by quantisation errors). It should be noted that conversion between various co-ordinate systems may introduce significant inaccuracies and should be avoided where possible. Source: Ref Fn_Perf-14-Target Display Latency The Target Display Latency: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref and Ref. 17 Fn_Perf-15-Information Display Latency For safety critical information, the Information Display Latency: Shall be 250 ms on average Shall never exceed 500 ms For information that is not safety critical, these values can be relaxed. Source: Ref and Ref. 17 Fn_Perf-16-Response Time to Operator Input The Response Time to Operator Input: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref and Ref. 17 Fn_Perf-17-User workload The HMI should ensure a level of user workload which is consistent with efficient and effective activity. Note - the user workload has to be analysed in details with users. Source: Ref , Ref Fn_Perf-18-Entry means The HMI should employ user friendly and familiar data entry means. Edition: 2.1 Released Issue Page 53

55 Note - Data entry means have to be designed as required by users at each local implementation. Source: Ref (c) and Ref Fn_Perf-19-Input actions The HMI should minimise the number of input actions required. Source: Ref and Ref Fn_Perf-20-Ambient light The HMI display shall be capable of being viewed in all ambient light levels appropriate to the user environment. Source: Ref , and Ref Fn_Perf-61-Alert Continuity This function should continuously display Conflict/Infringement Alert while the conflict is detected. Source: Ref Fn-14-Display Airport traffic situation This function shall be capable of displaying the complete airport traffic situation. Fn-15-Display Mobile Position Each mobile shall be seen in the correct position with respect to the aerodrome layout and other traffic. Note - It means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement. Fn-16-Display Alerts This function shall display alerts generated by the service monitoring process. Source: Ref This function shall display alerts generated by the service monitoring process and by the Conflict/Infringement detection process. Source: Ref Fn-17-Display configuration The HMI shall allow the user to configure the display (e.g. range scale selection, pan/zoom, brightness, map overlays). Source: Ref Fn-18-Manual Label Attribution The surveillance service shall provide to the user the ability to manually put the right callsign in the label associated to a vehicle equipped with mobile cooperative equipment used for different vehicles. Fn-19-Essential tasks An A-SMGCS should not inhibit control staff from carrying out their other essential tasks. Source: Ref Fn-20-User Decisions Page 54 Released Issue Edition: 2.1

56 The HMI shall support the user to make the decisions on those actions for which he/she is responsible. Source: Ref (b), and Ref Fn-21-Balance The HMI shall maintain a balance between human and machine functions. Source: Ref (a), and Ref Fn-22-Manual operation The HMI shall permit full manual operation in the event of a failure of an automatic function or whenever manual operation is required. Source: Ref Fn-23-Harmonisation The HMI should be harmonised where possible with existing ATM HMI. Note - ATM HMI may be specific to each local implementation. Source: Ref Fn-24-Operational change This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, rules, etc. Source: Ref , Ref Fn-25-Operational Conditions The A-SMGCS HMI design shall take into account the working environment of the user under various operational conditions. In this respect the HMI shall be adaptable to the various circumstances of the user. As an example, good visibility operations with high traffic throughput will require a different A- SMGCS set-up than that required for low visibility operations with reduced throughput. Source: Ref Fn-26-Integrate vicinity airborne traffic A seamless transition should be provided between the surveillance for an A- SMGCS and the surveillance of traffic in the vicinity of an aerodrome. Source: Ref Service monitoring Fn-8-Failure Alerts All critical elements of the system should be provided with audio and visual indication of failure given in a timely manner. Source: Ref Fn-27-Equipment status This function shall monitor the operational status of all A-SMGCS equipment, and shall generate alerts when the system must not be used for the intended operation. Fn-28-Performance Edition: 2.1 Released Issue Page 55

57 This function shall monitor the performance of A-SMGCS such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service. Fn-29-Validation of data This function shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation. Fn-30-Operationally significant failures This function shall clearly indicate operationally significant failures in the system to the control authority and any affected user. Fn-31-Back-up The system shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur. Page 56 Released Issue Edition: 2.1

58 CHAPTER 7 Functional Specification for A-SMGCS Level 2 service to Vehicle Drivers 7.1 Functional Breakdown for A-SMGCS Level 2 services to Vehicle Drivers The functions, that A-SMGCS shall perform, have been defined on the basis and through close examination of operational requirements. The operational requirements have been allocated to each function which implies that each function is specified by a list of functional requirements which have been derived from the operational requirements and which could thus be considered as the children of operational requirements. These functions are independent from each other and linked by data flows. The description of the different functions and the links between each function represent the functional architecture of A-SMGCS which is presented in the following sections Functional Architecture Figure 14: Functional Architecture for Vehicles The following data flow chart presents the functional architecture of the A- SMGCS Level 2. For each connection between two functions, the information exchanged is defined. Edition: 2.1 Released Issue Page 57

59 7.1.2 Provide Vehicle Information Functional Requirements for A-SMGCS Implementation Level 2 This function is in charge of providing the vehicle position and any other vehicle information (heading, etc), if required. The vehicle position can be collected from GNSS receiver for instance Provide traffic context This function is in charge of providing the traffic context information required for the guidance service (Airport map updates). The traffic context data may be periodically updated by a human operator Interface with driver This function is the interface with the driver. It is in charge of providing to the drivers all the guidance data required and alerts generated by the guidance service monitoring process Guidance Service Monitoring This function monitors the quality of service of A-SMGCS guidance service for driver (equipment status, performances, operational failures, etc), and generates an alert when A-SMGCS must not be used for the guidance operation. 7.2 Functional Requirements for A-SMGCS Level 2 services to Vehicle Drivers This section lists for each function the functional requirements. It could be noted that the operational requirements related to Design, Operational Range and Evolution which apply to each function are not allocated, and considered as "general principles" requirements. In the same way, operational requirements, dealing with constraints from A- SMGCS environment, are not allocated to A-SMGCS functions because they do not refer to the functional specification but more to the technical characteristics of the A-SMGCS equipment Provide Vehicle Information Fn_Perf-28-Position Accuracy The error in reported position shall be 12 m (95% level of confidence). Source: Ref. 17 Fn_Perf-29-Reported Position Resolution The mobile position resolution shall be at least 1 m. Fn_Perf-30-Update rate The update rate of vehicle information shall be at least 1 per second. Fn-59-Vehicle Information The function shall provide own-vehicle position. Optionally state vector information (e.g. heading) may also be provided Provide traffic context Fn_Perf-31-Response Time to Operator Input Page 58 Released Issue Edition: 2.1

60 The Response Time to Operator Input: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref and Ref. 17 Fn-39-Traffic Context This function shall update information about traffic context: - Airport layout, - Reference points (optionally) Interface with driver Fn_Perf-32-Situation assessment The HMI shall permit rapid position assessment. Source: Ref Fn_Perf-33-Map Accuracy The minimum airport map accuracy shall provide for reference points the following values: Thresholds - 1 m Runway limits - 1 m Holding positions m Stop bars m Runway exits m Taxiway intersections m Intersection limits m Switchable centre line light block limits m Parking positions m Source: Ref. 5, Chapter 3, table 3-1 Fn_Perf-34-Display Resolution The Display Resolution shall be consistent with the Display Position Accuracy. Source: Ref Fn_Perf-35-Position Registration Accuracy The Position Registration Accuracy should not appreciably degrade the accuracy of the information it receives. (In fact, it is to be expected that the only degradation of accuracy attributable to the HMI will be that caused by quantisation errors). It should be noted that conversion between various co-ordinate systems may introduce significant inaccuracies and should be avoided where possible. Source: Ref Fn_Perf-36-Target Display Latency The Target Display Latency: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref and Ref. 9 Edition: 2.1 Released Issue Page 59

61 Fn_Perf-37-Information Display Latency For safety critical information, the Information Display Latency: Shall be 250 ms on average Shall never exceed 500 ms For information that is not safety critical, these values can be relaxed. Source: Ref and Ref. 9 Fn_Perf-38-Response Time to Operator Input The Response Time to Operator Input: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref and Ref. 17 Fn_Perf-39-Driver workload The HMI should ensure a level of driver workload which is consistent with efficient and effective activity. Note - the driver workload has to be analysed in details with drivers. Source: Ref , Ref Fn_Perf-40-Entry means The HMI should employ user friendly and familiar data entry means. Note - Data entry means have to be designed as required by users at each local implementation. Fn_Perf-41-Input actions The HMI should minimise the number of input actions required. Fn_Perf-42-Ambient light The HMI display shall be capable of being viewed in all ambient light levels appropriate to the user environment. Source: Ref and Ref Fn-40-Display Items This function shall display the following items to the user: -Vehicle position; Airport layout: geographical representation of various airport areas (TWY, RWY, etc); Optionally: Reference points: holding points, stop bars (and other airfield lighting); RWY thresholds, etc; Fixed obstacles. Fn-41-Position The vehicle shall be seen in the correct position with respect to the aerodrome layout. Note - It means for instance, if a mobile is on the runway, it must be seen on the runway and not outside the runway. The position accuracy is given in another requirement. Fn-42-Display Alerts Page 60 Released Issue Edition: 2.1

62 This function shall display alerts generated by the guidance service monitoring process. Fn-43-Display configuration The HMI shall allow the user to configure the display capabilities (e.g. range scale selection, pan/zoom, brightness, map overlays). Source: Ref Fn-44-Essential tasks An A-SMGCS should not inhibit drivers from carrying out their other essential tasks. Source: Ref Fn-45-User Decisions The HMI shall support the user to make the decisions on those actions for which he/she is responsible. Source: Ref (b), and Ref Fn-46-Balance The HMI shall maintain a balance between human and machine functions. Source: Ref (a), and Ref Fn-47-Operational change This function shall be capable of accommodating any operational change of the aerodrome, for instance a physical change in layout (runways, taxiways, and aprons), or a change in the aerodrome procedures, or rules Guidance Service Monitoring Fn_Perf-49-Integrity A-SMGCS shall preclude failures that result in erroneous data provided to the users. Fn-48-Equipment status This function shall monitor the operational status of all guidance service equipment, and shall generate alerts when the system must not be used for the intended operation. Fn-49-Performance This function shall monitor the performance of the guidance service such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service. Fn-50-Validation of data This function shall perform a continuous validation of data provided to the user and timely alert the driver when the system must not be used for the intended operation. Fn-51-Operationally significant failures This function shall clearly indicate operationally significant failures in the system to the driver and any affected user. Fn-52-Back-up This function shall allow for a reversion to adequate back-up procedures if failures in excess of the operationally significant period occur. Edition: 2.1 Released Issue Page 61

63 Fn-57-Failure Alerts Functional Requirements for A-SMGCS Implementation Level 2 All critical elements of the system should be provided with audio and visual indication of failure given in a timely manner. Page 62 Released Issue Edition: 2.1

64 ANNEX 1 Conflicts / infringements to be detected by the runway safety net Edition: 2.1 Released Issue Page 63

65 Reference Aircraft Conflicting Mobile INFORMATION ALARM Unidentified mobile on the runway protection area Yes No No Reference Aircraft Identified vehicle on an open runway Aircraft proceeding to a closed runway Yes aircraft on runway protection area surface No Departing aircraft lining-up or taking-off or arriving aircraft (< T1 from threshold) Aircraft departing on the runway in the wrong direction When lining-up when taking-off a mobile (aircraft or vehicle) is on the runway protection area surface arriving aircraft < T1 from threshold the arriving aircraft < T2 from threshold, until the arriving aircraft has passed the mobile (mobile behind the arriving aircraft) Arriving Aircraft a slower preceding departing aircraft which has not crossed the end of the runway-in-use or has not started a turn 1 arriving aircraft < T1 from threshold arriving aircraft < T2 from threshold a preceding arriving aircraft which has not cleared the protection area 2 arriving aircraft < T1 from threshold arriving aircraft < T2 from threshold Departing Aircraft a mobile (aircraft or vehicle) is on the runway protection area surface and not behind the departing aircraft 3 departing aircraft is not yet takingoff (speed < 50 knots) departing aircraft is taking-off (speed > 50 knots) Note : The air boundary is defined as a flight time to threshold : Non-LVO : T1 = 30, T2 = 15 / LVO : T1 = 45, T2 = 30 Table 2: Conflicts / infringements to be detected at each individual runway 1 See specific rules when reduced spacing procedures are in force 2 See specific rules when reduced spacing procedures are in force 3 See specific rules when multiple line-up is applied Page 64 Released Issue Edition: 2.1

66 Reference Aircraft Conflicting Mobile INFORMATION ALARM an aircraft is lined-up on the other runway Yes No Lining up aircraft an aircraft is taking off on the other runway Yes No an aircraft is landing on the other runway Yes No arriving aircraft on short final (<IRT2) on the other runway Yes No Arriving aircraft on long final (<IRT1) on the other runway Yes No Arriving aircraft on long final (<IRT1) arriving aircraft on short final (<IRT2) on the other runway No Yes an aircraft is landing on the other runway + converging Yes No an aircraft is taking off on the other runway + converging Yes No arriving aircraft on short final (<IRT2) on the other runway No Yes Arriving aircraft on short final (<IRT2) an aircraft is landing on the other runway + converging No Yes an aircraft is taking off on the other runway + converging No Yes Table 3: Additional conflicts / infringements to be detected when two runways are intersecting Note: It could be required to use Time To Threshold T1 and T2 different from those defined previously. We will call them Intersecting Runways Time To Threshold IRT1 and IRT2. They could be defined as following: Long final: Aircraft on final between IR T1 and IR T2; Short final: Aircraft on final between IR T2 and Threshold over-flight. Edition: 2.1 Released Issue Page 65

67 ANNEX 2 Relationships between requirements The following matrix presents the relationships between requirements. The columns represent the operational requirements and the lines represent the functional requirements. A coloured box indicates an operational requirement is the parent of the functional one. Page 66 Released Issue Edition: 2.1

68 A2.1 A-SMGCS Level 1 Surveillance Service Table 4: A-SMGCS Level 1 Surveillance Service Edition: 2.1 Released Issue Page 67

69 Table 5: A-SMGCS Level 1 Surveillance Service Page 68 Released Issue Edition: 2.1