Functional Requirements for A-SMGCS Implementation Level 1

Transcription

1 EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION EUROCONTROL Functional Requirements for A-SMGCS Implementation Level 1 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 1 Publications Reference: ISBN Number: Document Identifier Edition Number: 2.1 Funct. Req. A-SMGCS L1 Edition Date: 30/06/2010 Abstract This document is the Eurocontrol specification of the functional requirements for A-SMGCS Level 1 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 Identification Level 1 Requirements 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 of 62

3

4 DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION NUMBER EDITION DATE REASON FOR CHANGE PAGES AFFECTED /09/2003 Released Issue /11/2006 Revisions following Eurocontrol and European Commission validation projects and review meeting with EUROCAE WG41 Sections 5 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 of 62

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 of 62 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...36 CHAPTER 6 Functional Breakdown Functional Architecture Provide Traffic Information Functional Architecture Acquisition of traffic information from non-cooperative surveillance sensors Acquisition of traffic information from cooperative surveillance sensors Acquisition of traffic information from approach RDPS Acquisition of other information about traffic Data Fusion Provide traffic context Functional Architecture Acquisition of traffic context from other ground systems Manual update of traffic context Update traffic context Interface with user Service monitoring...40 CHAPTER 7 Functional requirements Provide Traffic Information Acquisition of traffic information from non-cooperative surveillance sensors Acquisition of traffic information from cooperative surveillance sensors Acquisition of traffic information from approach RDPS Acquisition of other information about traffic Data Fusion Provide traffic context Acquisition of traffic context from other ground systems Manual update of traffic context Update traffic context Interface with user Service monitoring...47 ANNEX 1 Relationships between requirements...49 Edition: 2.1 Released Issue Page 5 of 62

7 REFERENCES...52 GLOSSARY...54 ABBREVIATIONS...59 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: Functional Architecture...37 Figure 10: Functional Architecture...38 Figure 11: Functional Architecture...39 Figure 12: Relationship between requirements 1/ Figure 13: Relationship between requirements 2/ Figure 14: Types of Mobiles...57 Table 1: List of Tables Categories of Operational Requirements...14 Page 6 of 62 Released Issue Edition: 2.1

8 EXECUTIVE SUMMARY This document describes the Eurocontrol specification of the functional requirements for the A-SMGCS Implementation Level 1. 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 of 62

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 focuses on the implementation of automated surveillance. It s associated operational concept and requirements are presented in Ref. 2 On the basis of the analysis of the users needs presented in Ref. 2, this document defines the functional specification for A-SMGCS Implementation Level 1. The EUROCONTROL A-SMGCS definition of Implementation Levels is included in Ref. 1 that had been derived from ICAO definitions as illustrated in Ref. 5, appendix B. 1.2 Structure of the document Introduction CHAPTER 1 describes the purpose of this document, its structure, the reference documents and an explanation of terms used throughout the document. Methodology CHAPTER 2 reminds the methodology applied to specify A-SMGCS and explain how the functional requirements are derived from the operational ones. 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 1. Functional breakdown CHAPTER 6 presents the functional breakdown for A-SMGCS level 1. Functional requirements CHAPTER 7 presents the functional requirements for each function of the functional breakdown. Page 8 of 62 Released Issue Edition: 2.1

10 Relationships between Requirements ANNEX 1 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. Definitions from, Ref. 5 are used as a first option. In general, other definitions are only used where there is no ICAO definition. If not, it is explained why another definition is preferred to the ICAO one. Alert Response Time (ART) Ref. 9 definition The time delay between an alert situation occurring at the input to the Alert Situation Detection Element and the corresponding alert report being generated at its output. Coverage Volume (CV) Ref. 9 definition That volume of space which encompasses all parts of the aerodrome surface where aircraft movements take place together with those parts of the surrounding airspace which affect surface operations. Display Resolution (DR) Ref. 9 definition The number of individually addressed picture elements (pixels) along each axis of the display screen. (For a raster-scan display, the resolution is normally expressed in terms of the number of raster lines and the number of pixels per line.) Information Display Latency (IDL) Ref. 9 definition The maximum time delay between a report, other than a target report, being received by the A-SMGCS HMI and the corresponding presentation on the HMI display of the information contained in the report. Position Registration Accuracy (PRA) Ref. 9 definition The difference between the co-ordinates contained in the dynamic input data to the HMI and the corresponding geographical position represented on the HMI display. Probability of Detection (PD) Ref. 9 definition The probability that an actual target is reported at the output of the Surveillance Element of an A-SMGCS. Edition: 2.1 Released Issue Page 9 of 62

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

12 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 Defines the frequency with which reports on target are delivered by the Surveillance element. Edition: 2.1 Released Issue Page 11 of 62

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 of 62 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 of 62

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 of 62 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 of 62

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 of 62 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. 2, 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 of 62

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 of 62 Released Issue Edition: 2.1

20 CHAPTER 3 ACTORS A-SMGCS actors take part in A-SMGCS operations as user or contributor. This section describes the respective role of the actors in A-SMGCS. 3.1 ATCO The role of ATCO is to manage aircraft and vehicles movements in the manoeuvring area with respect to safety requirements and planning constraints. With A-SMGCS, the surveillance service will provide to the controller a new source of data about the traffic situation in all visibility conditions. This new source of data will complement and could even replace the usual sources of traffic data (visual means and Mobiles R/T reports). As illustrated in the figure, the traffic situation picture, containing traffic context, position, and identity of the mobiles, is provided by A-SMGCS to the controller to help him perform its control task by actions on the traffic via R/T. The controller uses this surveillance information as following: The controller analyses the global view of the traffic situation; The controller focuses on particular airport areas (runway for instance) or mobiles (landing aircraft for instance) requiring his attention; The position of all the mobiles allows the controller to detect intruders, or participating mobile without authorisation; The identification of the mobile through its label allows the controller to communicate with the mobile by R/T; The mobiles positions with respect to airport layout help the controller to set up a traffic planning and provide guidance to the pilots/drivers; The controller monitors on the display that mobiles apply clearances he issued; Mobile position compared with airport layout allows the controller to check the mobile is on the right way and to provide guidance to the pilot/driver; Mobile position compared with airport areas status allows the controller to anticipate incursions in restricted areas and to alert the mobile; Mobile position compared with other mobiles position allows the controller to inform the mobile on its surrounding traffic and to anticipate collisions with other mobiles and to alert the mobile, and; Information on A-SMGCS status (failures?) which could affect safety allows the controller to apply the appropriate procedure. Edition: 2.1 Released Issue Page 19 of 62

21 Figure 6: ATCO role 3.2 Other operators If not automatic, one or more operators are needed to update the traffic context required by A-SMGCS, this includes: MET data, visibility (including transition between visibility conditions 1, 2, 3, and 4), etc. Airport Configuration: runway in use, open taxiways, etc. 3.3 Pilot 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 1, where the pilot is not a user of A-SMGCS, it will have the following impact on its work: Page 20 of 62 Released Issue Edition: 2.1

22 Reduction of R/T report: since the controller knows the position and identity of aircraft provided by A-SMGCS, it is possible that some aircraft position reports be not necessary anymore. This statement has to be confirmed by the definition of the procedures related to the use of A-SMGCS. Cooperative sensor checking: since aircraft are supposed to provide their identity through cooperative surveillance sensors, aircrew should check that this piece of equipment operates satisfactorily on board and should use it in the correct manner. 3.4 Vehicle Driver The role of the driver is to drive his vehicle following ATCO instructions and clearances provided by R/T, and with the help of visual aids and ATCO. The main tasks related to A-SMGCS are the following: Report its position to ATCO by R/T; Monitor surrounding traffic to prevent collision by visual means and traffic information provided by ATCO. With A-SMGCS the controller knows the position and identity of vehicles, so it is possible that some vehicle position reports are not necessary anymore. It has to be confirmed in the procedures related to the use of A-SMGCS. Moreover, if the vehicle is equipped for A-SMGCS, for instance with a transponder, the driver should check the equipment is activated and should use it in the correct manner. Edition: 2.1 Released Issue Page 21 of 62

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 of 62 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 of 62

25 4.8 Types of traffic information Functional Requirements for A-SMGCS Implementation Level 1 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 of 62 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. 5, 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 of 62

27 5.1.3 Requirement Functional Requirements for A-SMGCS Implementation Level 1 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 of 62 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 of 62

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 of 62 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 of 62

31 Functional Requirements for A-SMGCS Implementation Level 1 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 of 62 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 of 62

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 of 62 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 of 62

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 of 62 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 of 62

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. Page 36 of 62 Released Issue Edition: 2.1

38 CHAPTER 6 Functional Breakdown 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 with their associated requirements and the links between each function represent the functional architecture of A- SMGCS which is presented in the following sections. 6.1 Functional Architecture Figure 9: Functional Architecture The following data flow chart presents the functional architecture of the A- SMGCS level 1. For each connection between two functions, the information exchanged is defined. Edition: 2.1 Released Issue Page 37 of 62

39 6.2 Provide Traffic Information Functional Requirements for A-SMGCS Implementation Level 1 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, and; 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 10: 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 Page 38 of 62 Released Issue Edition: 2.1

40 to move on the manoeuvring area. All the participating mobiles are required to be cooperative, allowing the cooperative surveillance sensor to collect information about the mobiles, at least their identity 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. 6.3 Provide traffic context This function is in charge of providing the traffic context (airport configuration, runways status, etc). The traffic context data may be automatically obtained from other systems (MET systems, etc) or being updated by a human operator. It means this function is composed of sub-functions as described in the following sections Functional Architecture Figure 11: 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. Edition: 2.1 Released Issue Page 39 of 62

41 6.3.4 Update traffic context The Traffic Context provided by the different sources (automatic or manual) is combined to provide a comprehensive traffic context package. 6.4 Interface with user This function is the interface with the users. It is in charge of providing to the users all surveillance data required and alerts generated by the service monitoring process. 6.5 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. Page 40 of 62 Released Issue Edition: 2.1

42 CHAPTER 7 Functional requirements This section lists for each function the functional requirements. It could be noted that the operational requirements related to Design, Operational Range and Evolution which apply to each function are not allocated, and considered as "general principles" requirements. In the same way, operational requirements, dealing with constraints from A- SMGCS environment, are not allocated to A-SMGCS functions because they do not refer to the functional specification but more to the technical characteristics of the A-SMGCS equipment. 7.1 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. Note - ASTERIX will be the European standard to be used for surveillance data. Source: Ref. 5, Edition: 2.1 Released Issue Page 41 of 62

43 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 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). 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). 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. 5, Acquisition of other information about traffic Data Fusion Fn_If-4-Data format The data interchange with ground systems shall be performed in a standardised format in order to ensure an adequate exchange of information. Note - ASTERIX will be the standard to be used for surveillance data. Source: Ref. 5, 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 The error in reported position shall be: 7.5 m on the manoeuvring area at a confidence level of 95% 12 m on the apron at a confidence level of 95% Source: Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17 Fn_Perf-2-Reported Position Resolution The mobile position resolution shall be at least 1 m. Page 42 of 62 Released Issue Edition: 2.1

44 Source: Ref. 9, and Fn_Perf-3-Aircraft level accuracy The allowable error in the level of an aircraft when airborne shall be ±10m. Source: Ref. 5, Fn_Perf-4-Update rate The update rate shall be at least 1 per second. Source: Ref. 5, and Ref. 9, and Fn_Perf-5-Probability of Detection The probability that an actual aircraft, vehicle, or object is detected and reported at the output of the Data Fusion shall be: 99.9% at minimum on the manoeuvring area 98% at minimum on the movement area Source: Ref. 5, (a), Ref. 9, 3.2.3, and 3.2.4; Ref. 16, and Ref. 17 Fn_Perf-6-Probability of False Detection The probability that anything other than an actual aircraft, vehicle, or object is detected and reported at the output of the data fusion shall not exceed 0.1%. Source: Ref. 5, (a), Ref. 9, 3.2.3, and Fn_Perf-7-Probability of Identification The probability that the correct identity of an aircraft, vehicle, or object is reported at the output of the surveillance element shall be: 99.9% at minimum on the manoeuvring area 98% at minimum on the apron Note - The requirement only intends to specify the performance of the ground system. 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 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. 5, (a), Ref. 9, 3.2.3, 3.2.4; Ref. 16, and Ref. 17 Fn-9-Traffic Information This function shall provide the complete Traffic Information. Edition: 2.1 Released Issue Page 43 of 62

45 7.2 Provide traffic context Functional Requirements for A-SMGCS Implementation Level 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. Source: Ref. 5, Fn-10-Traffic Context This function shall provide information about traffic context (runways status, MET, 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. 9, and 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, etc. Source: Ref. 5, and Ref. 9, Interface with user Fn_Perf-10-Situation assessment The HMI shall permit rapid situation assessment. Source: Ref. 9, 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 Page 44 of 62 Released Issue Edition: 2.1

46 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-12-Display Resolution The Display Resolution shall be consistent with the Display Position Accuracy. Source: Ref. 9, 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. 9, Fn_Perf-14-Target Display Latency The Target Display Latency: Shall be 250 ms on average Shall never exceed 500 ms Source: Ref. 9, 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. 9, 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. 9, 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. 5, and Ref. 9, Edition: 2.1 Released Issue Page 45 of 62

47 Fn_Perf-18-Entry means The HMI should employ user friendly and familiar data entry means. Note - Data entry means have to be designed as required by users at each local implementation. Source: Ref. 5, (c) and Ref. 9, Fn_Perf-19-Input actions The HMI should minimise the number of input actions required. Source: Ref. 5, and Ref. 9, Fn_Perf-20-Ambient light The HMI display shall be capable of being viewed in all ambient light levels appropriate to the user environment. Source: Ref. 5, and Ref. 9, 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. 9, Fn-17-Display configuration The HMI shall allow the user to configure the display (e.g. range scale selection, pan/zoom, brightness, and map overlays). Source: Ref. 9, 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 a mobile cooperative equipment used for different vehicles. Fn-19-Essential tasks An A-SMGCS should not inhibit control staff from carrying out their other essential tasks. Source: Ref. 5, Fn-20-User Decisions The HMI shall support the user to make the decisions on those actions for which he/she is responsible. Source: Ref. 5, (b) and Ref. 9, Page 46 of 62 Released Issue Edition: 2.1

48 Fn-21-Balance The HMI shall maintain a balance between human and machine functions. 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. 9, 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. 5, and Ref. 9, 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. 9, 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. 5, 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. 5, Fn-27-Equipment status This function shall monitor the operational status of all A-SMGCS equipment, and shall generate alerts when the system must not be used for the intended operation. Fn-28-Performance This function shall monitor the performance of A-SMGCS such that operationally significant failures are detected and appropriate remedial action is initiated to restore the service or provide a reduced level of service. Fn-29-Validation of data This function shall perform a continuous validation of data provided to the user and timely alert the user when the system must not be used for the intended operation. Fn-30-Operationally significant failures Edition: 2.1 Released Issue Page 47 of 62

49 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 48 of 62 Released Issue Edition: 2.1

50 ANNEX 1 Relationships between requirements The following matrix (Figure 12 and Figure 13) presents the relationship between different requirements. The columns represent the operational requirements; the lines represent the functional requirements. A coloured box indicates an operational requirement is the parent of the functional one Edition: 2.1 Released Issue Page 49 of 62

51 Figure 12: Relationship between requirements 1/2 Page 50 of 62 Released Issue Edition: 2.1

52 Figure 13: Relationship between requirements 2/2 Edition: 2.1 Released Issue Page 51 of 62