Review ICAO Manual on Required Communication Performance (RCP)

  • Home 2010 Review ICAO Manual on Required....

Review ICAO Manual on Required Communication Performance (RCP)

49TH ANNUAL CONFERENCE, Punta Cana, Dominican Republic, 12-16 April 2010

WP No. 87

Review ICAO Manual on Required Communication Performance (RCP)

Presented by TOC

Summary

The ICAO Manual on Required Communication Performance (RCP) has been published under the ICAO doc number 9869 in its first edition in 2008. The purpose of the manual “is to explain the concept of RCP, identify RCP requirements applicable to the provision and use of air traffic services, and provide a basis for the application of RCP in a specified airspace.” TOC believes that the contents of the Manual are in agreement with IFATCA policy and the advanced communication concepts envisaged in the IFATCA “Statement on the Future of Global Air Traffic Management”.

Introduction

1.1 The fourth meeting of the ICAO Aeronautical Mobile Communications Panel (AMCP/4) (Montréal, April 1996) recognized the absence of objective criteria to evaluate communication performance requirements. The objective criteria needed were a set of values for parameters which would be based on the operational requirements for communication systems in the various phases of flight. The meeting agreed that there was an urgent need to assess the existing technical options of communication systems against such a set of parameter values. The term “Required Communication Performance (RCP) type” is used to denote a set of values for these parameters.

1.2 When reviewing the report of AMCP/4 in 1997, the Air Navigation Commission tasked the Automatic Dependent Surveillance Panel (renamed in 2000 as the Operational Data Link Panel — OPLINKP) to develop the operational concept of Required Communication Performance (RCP).

1.3 In 2001, the OPLINKP completed its document entitled Concept of Required Communication Performance, and the Air Navigation Commission (ANC) solicited comments thereon from ICAO Contracting States. The comments received indicated broad support for the RCP concept. In light of the comments received, in 2002 the ANC amended the OPLINKP work programme to develop a Manual on Required Communications Performance (RCP) and, as necessary, Standards and Recommended Practices (SARPS) and procedures relating to the use of RCP in the provision of air traffic services.

1.4 The aforementioned Manual has been published under the ICAO doc number 9869 in its first edition in 2008. The purpose of the manual “is to explain the concept of RCP, identify RCP requirements applicable to the provision and use of air traffic services, and provide a basis for the application of RCP in a specified airspace.”

Discussion

2.1 To meet the demands on airspace capacity and operational efficiency, the operational communication capability is playing an increasingly essential role in air traffic management using a mixture of data and voice communication. For example, data link can provide for the integration of air traffic management functional capabilities on the aircraft and at the ATS units, and for more direct controller-pilot communications enabling user-preferred and dynamic re-routing and intervention capabilities in reduced separation environments where alternative communications are more cumbersome. Examples can be found in the working paper Investigate Radiotelephony Frequency Management that is also part of the 2010 Punta Cana Technical Working Program The RCP concept provides a means to ensure the acceptable performance of communications within a complete ATM system.


2.2 Required Communication Performance (RCP)

2.2.1 The RCP concept characterizes the performance required of communication capabilities that support ATM functions without reference to any specific technology and is open to new technology. This approach is essential to the evolution of operational concepts that use emerging technologies. This is the same concept as in Required Navigation Performance where an aircraft needs to be able to navigate to a certain degree of accuracy etc. in order to be allowed to operate within a certain airspace. Under RCP, aircraft (and ground stations) have to be able to receive and transmit messages within a certain time frame.

2.2.2 The RCP concept assesses operational communication transactions in the context of an ATM function, taking into account human interactions, procedures and environmental characteristics.

2.2.2.1 The contribution of the human can be significant to RCP. Communication is the accurate transfer between sender and receiver of information which can be readily understood by both.

2.2.2.2 An operational communication transaction is the process a human uses to send an instruction, a clearance, flight information, and/or a request, and is completed when that human is confident that the transaction is complete.

2.2.3 The RCP concept is based upon “operationally significant” benchmarks which when attained assure confidence that the operational communications supporting the ATM functions will be conducted in an acceptably safe manner.

2.2.4 The RCP concept is not based on technology; however, it is not intended to promote an unrestricted number of alternative communication technologies for one ATM function. Whilst RCP types will be prescribed on the basis of regional consultation within the ATM community, so too will be the aircraft equipage requirements for communications.

2.2.5 It is anticipated that most aircraft, operating in airspace for which RCP has been prescribed by States or on the basis of a regional air navigation agreement, will carry a mixture of voice and data communication equipment. The carriage of voice and data communication equipment may even be required in some regions or States to perform certain ATM functions. In order to receive approval to operate in such environments, the combined communications equipment should be required to provide at least the capabilities and features (or their equivalents) applicable to the appropriate RCP type.

2.2.6 The RCP concept seeks to manage the performance of communications supporting evolving ATM concepts and emerging technologies. This is achieved by:

  • determining an RCP type for the communication capabilities supporting an ATM function; then
  • prescribing the RCP type(s) related to the communications system(s) supporting the ATM functions within that airspace; and
  • complying with the prescribed RCP type(s) through analysis, operational assessments and performance monitoring of the communication systems.

2.3 RCP type

2.3.1 The basis for the development of the RCP concept was the need for objective operational criteria, in the form of an RCP type, to evaluate a variety of communication technologies. Once these criteria have been set and accepted, a specific implementation of an ATM function including its technical and human performance may have its viability assessed against acceptable operational criteria.

2.3.2 An RCP type is a label (e.g. RCP 240) that defines a performance standard for operational communication transactions. Each RCP type denotes values for communication transaction time, continuity, availability and integrity applicable to the most stringent operational communication transaction supporting an ATM function. In order to simplify the RCP type naming convention and to make the required communication transaction time readily apparent to airspace planners, aircraft manufacturers and operators, the RCP type is specified by the value in seconds for the communication transaction time associated with the ATM function.

2.3.3 Several factors may affect States’ decisions as to when an RCP type will be prescribed. These factors are based on the ATM functions that an air traffic services (ATS) provider chooses to implement within that airspace. In cases where a safety-related change, including the implementation of a reduced separation minimum or a new procedure, is predicated on communication performance, an RCP type should be prescribed. The approval of this change should include showing that the requirements and assumptions defined by the RCP type have been met.


2.4 Determining an RCP Type

2.4.1 To enable ATM functions within a performance-based airspace, it will be necessary to characterize the performance required for the applicable communication (C), navigation (N) and/or surveillance (S) elements. RCP will be used in conjunction with RNP and other performance-based measures. Chapter 3 of the Manual provides guidance for determining an RCP type for an ATM function.

2.4.2 For a particular ATM function, an increase or decrease in the required performance for any single element (i.e. C or N or S) may allow a trade-off in required performance of some or all of the other elements, provided the target level of safety is maintained.

2.4.3 It is important that the States globally harmonize RCP type for the same or similar ATM functions to reduce training requirements and errors resulting from confusion in operations across airspace boundaries.

2.4.4 For the time being, the following types are envisaged:

  • RCP 10 may be applied to controller intervention capability supporting separation assurance in a 5 NM radius environment.
  • In combination with the RCP 10 in a 5 NM radius environment, RCP 60 may be applied to routine communications on a data link system to offload the voice communication system.
  • RCP 120 may be used for controller intervention capability supporting separation assurance in a 15 NM radius separation environment.
  • RCP 240 is (at the time of publication) being investigated as a basis for controller intervention capability supporting separation assurance in a reduced separation environment, i.e. less than or equal to 50 NM longitudinal and less than or equal to 30 NM lateral separation minima.
  • RCP 400 may be used for controller intervention capability supporting separation assurance in current environments where separation minima are greater than 30 NM lateral or greater than 50 NM longitudinal, and alternative technologies are planned for providing normal means of communication, e.g. Iridium voice or HF data link in lieu of HF voice. RCP 400 might also be used to specify the performance required for the alternative means of communication that is not HF voice, when an independent alternative is required in combination with the normal means of communication, for which RCP 240 is specified.

2.4.5 RCP types were derived from intervention capabilities that exist today, aircraft performance characteristics, conflict detection and resolution capability, PANS-ATM (ICAO Doc 4444), RTCA/EUROCAE Standards, and other factors. The Manual provides no further information, and it also fails to cover TMA separation standards that go as low as 2 NMs at certain airports. IFATCA will have to decide whether we want to pursue those issues further and be involved in the creation and validation of RCP types.

2.4.6 The Manual states that it is important to note that the RCP type needs to be determined in the context of the relevant airspace characteristics, operational capabilities and overall CNS/ATM system performance. Trade-offs can be and are made to take advantage of existing fleet equipage and air navigation service provision. For example, when implementing the 50/50 NM separation minima, if the operator/aircraft is qualified for RNP 4 operations, the interval for ADS-C periodic position reports is 32 minutes. If an operator/aircraft were only qualified for RNP 10 operations, the separation minima can still be implemented, but the interval for ADS-C periodic position reports is 27 minutes, which increases the number of position reports and associated costs, but the operator would not have to incur costs to upgrade to RNP 4 operations. The service provision would need to allow for variations in these performance trade-offs. This, as stated before, might make things complicated for ATC staff and aircrew involved, it must be taken care of at system level.

2.4.7 An RCP type comprises values assigned to the following parameters:

  • Communication transaction time. The maximum time for the completion of the operational communication transaction after which the initiator should revert to an alternative procedure.
  • Continuity. The probability that an operational communication transaction can be completed within the communication transaction time.
  • Availability. The probability that an operational communication transaction can be initiated when needed.
  • Integrity. The probability of one or more undetected errors in a completed communication transaction.

The latter three values will be used to validate whether a certain RCP type performs as required. The Manual provides target figures that need to be met to demonstrate the system in question complies with a certain RCP type.

2.4.8 Given the airspace characteristics and other capabilities and performances, the RCP type is used to characterize the communication capability and performance that needs to exist for the controller to intervene and resolve a potential conflict. It is not intended to imply that all communication needs to meet the RCP type. However, in addition to the RCP type determined for the intervention capability, other RCP types may be appropriate for specific operations that may have different performance characteristics. This dependency may be related to, for example:

  • functional differences in the means of communication, such as between voice, which provides an interactive capability, and data, which provides an air-ground automation integration capability;
  • an increase in communications due to an increase in airspace capacity. For example, when increasing airspace capacity, the controller depends on a data link system to maintain an acceptable workload and suitable performance of the VHF voice communication to intervene in time-critical situations; and
  • a contingency procedure in the event the primary communication system fails. For example, when implementing the 30/30 separation minima, the contingency procedure requires an alternate means of communication that enables the controller to establish communications with an aircraft after the normal means fails.

In such cases, it may be necessary to establish specific operational criteria using a different RCP type for the alternate means of communication to ensure that it performs as expected and to convey its performance characteristics to the controller and flight crew for proper use. This RCP type is different from the RCP type established for the communications capability the controller uses to intervene and resolve a potential conflict. Again this poses problems when it is up to the controller to decide what kind of separation is still available to her or him when the main communications system fails, and needs to be dealt with at system level.


2.5 Prescribing an RCP Type

2.5.1 After an RCP type has been determined, it may be prescribed for an airspace based on the ATM functions that an airspace planner or authority chooses to implement within that airspace.

2.5.2 When an RCP type is prescribed based on the intended ATM function provided in a given airspace, the RCP type(s) will indicate the requirements for qualification and approval of the procedures, aircraft equipage and airspace infrastructure.

2.5.3 Ideally, airspace should have a single RCP type; but multiple RCP types may be prescribed within a given airspace. An example would be to prescribe one RCP type appropriate for the controller’s ability to intervene in a conflict situation given the separation minima and another RCP type to perform a specific procedure, such as an in-trail climb or dynamic re-route, within that airspace. The Manual does not mention how different RCP types within a single airspace will be managed. Controllers and pilots have to be aware at all times whether aircraft have the required RCP level to carry out certain operations. How this information will be presented to controllers and pilots remains unclear and is an issue that needs to be resolved.

2.5.4 Different RCP types may be prescribed for different airspace depending on the ATM functions. As an example, an RCP type in terminal area airspace may be different from the RCP type for en-route or oceanic airspace.

2.5.5 Chapter 4 of the Manual provides guidance for prescribing an RCP type for a particular airspace. Once the ATM functions and the associated RCP type(s) have been established, these should be published in the appropriate local documentation (e.g. AIP, regional guidance material). Care should also be taken to ensure that any potential users of the airspace are provided with an unambiguous definition of the procedures, aircraft equipage and training requirements necessary to operate in that airspace as well as the performance monitoring criteria. When an RCP type(s) is prescribed in a given airspace, the RCP type(s) will provide the basis for qualification and approval of the procedures, aircraft equipage and airspace infrastructure. The basis for each type of approval is provided in the form of an RCP type allocation. RCP type allocations are documented in ICAO manuals or industry-developed minimum aviation system performance standards which specify allocations for various communication system elements.


2.6 Compliance with an RCP type

2.6.1 Chapter 5 of the Manual deals with the obligation of the States and the aircraft operator to establish Evidence of Compliance with an RCP type. This compliance is performed as part of different approval types. The different approval types are the ATS provider approval, aircraft operator approval, and aircraft type design approval. These separate and distinct types of approvals collectively define the conceptual “ATM system approval.” In cases for which there is no regulatory basis for approval of a part of the ATM system, “approval” denotes the activities that take place to show compliance with the requirements allocated to that part of the ATM system.

2.6.2 To comply with an RCP type, all communication systems that support the ATM function are considered. Actual communication performance (ACP) is the dynamic assessment of the operational performance of the communication path, with human performance and technical performance included in the assessment. Human performance considers such factors as training, procedures and human-machine interaction (HMI). Technical performance comprises the installed elements of communication performance operating together and is used to demonstrate that the technical part of the operational communication system meets the intended function. ACP is assessed in the same terms and parameters as the RCP type.

2.6.3 Initially, for aircraft type design approval and ATS provider approval, the expected ACP is determined based on validating any assumptions and demonstrating with representative elements of the complete system that the aircraft’s or ATS unit’s actual performance complies with its RCP type allocation. For the operational approvals, the ACP is determined based on measurements of actual performance characteristics of a specific implementation of the ATM function, initially, and in continued operations. The results of these activities are provided as evidence of compliance, which is used to qualify for the different types of approvals.

2.6.4 States should provide information and guidance related to responsibilities of ATS providers, aircraft operators, and manufacturers and modifiers of aircraft, for monitoring, alerting and reporting requirements related to communication performance. The following types of monitoring and alerting should be considered:

a) Real time monitoring. For all RCP operations, communication systems should be designed to monitor for compliance to the RCP type. Should performance fall below the parameter values for the RCP type, the flight crew and the controller should be notified of the non-compliance within acceptable time limits.

b) Alerts. For all RCP operations, in the event of system failure or the performance degrading to below that specified by the RCP type, alerts should be provided to the controller and flight crew to, as necessary, enable reversion to alternative means of communication or commence contingency procedures.

c) Statistical monitoring. For continued operations, organizations should statistically monitor to detect performance degradations due to capacity loading and other nondeterministic effects. Procedures should be established to conduct cause-and-effect analysis, notify appropriate parties and coordinate timely and effective corrective action.

The Manual then specifies the statistical monitoring objects to be met. Most important is the Monitoring, measurement and analysis of the normal time in which operational transactions are completed during demonstrations, operational trials, and in continued operations. Monitoring and measurement are necessary when actual times cannot be accurately predicted with an acceptable level of confidence, and the potential variability is significant to the required performance. The normal time target is typically defined as the time at which 95 per cent of all transactions that are initiated are, in fact, completed. The normal time is related to the operational communication transaction time and continuity (probability of completing the transaction) only to the extent that the probability distribution function can be accurately predicted. The normal time target is predetermined based on the operational communication transaction time requirement, the continuity requirement, and an analysis to determine the statistical distribution of the operational communication transaction time. Accuracy in predicting the distribution of transaction times and building an acceptable level of confidence can be attained through demonstrations, operational trials, and management of system configuration during continued operations.

2.6.5 Compliance to the integrity value of the RCP type is typically shown by analysis, design and system architecture for the technical parts of the system. For the human, compliance to the integrity value of the RCP type is typically shown by evaluations of HMI, system design and capabilities, training/qualification, and operational judgment. This latter statement is important as it refers to the fact that the RCP type consists of both a technical part (the time it take for the message to reach the addressee) and a human factors part (how long does it take a human to compose a message, and how long for the addressee to decode it?). In the case of voice communication, this will be a straightforward process, but with CPDLC, HMI design and other factors need to be considered. Consider as an everyday example the sending of a text message by mobile phone: A message will take seconds to travel the network, but the phone you type it out on might have fiddly keys, and the one you read it on might have a flimsy display, increasing the total time of message delivery far beyond the technical transmission. Again, TOC believe this to be a very sensible way of measuring RCP.


2.7 Appendices of the RCP Manual

2.7.1 Appendix A provides a Glossary of Terms.

2.7.2 Appendix B provides a comprehensive “checklist for RCP application”.

2.7.3 Appendix C provides a very detailed example of determining an RCP type. In this example, it is desired to allow in the TMA an increase in air traffic of 20 per cent over current air traffic demand. However, to maintain separation minima at an acceptably safe level, the current air traffic demand is at the maximum when considering controller workload and congestion on the VHF voice communications. The air traffic demand could be increased by implementing an air-ground data link system which can be used to perform some of the less time-critical ATC communications, thereby maintaining an acceptable intervention capability using the VHF voice communications. Additionally, with proper integration into the controller’s workstation, the data link system will enable the controller to maintain an acceptable level of workload with the increase in air traffic.

All three appendices serve their purpose well. Appendix C also shows that ICAO is aware of the possible benefits of integrating voice and datalink communication as postulated by TOC in the working paper Investigate Radiotelephony Frequency Management that is also part of the 2010 Punta Cana Technical Working Program.


2.8 IFATCA Policy

At the 2009 IFATCA Annual Conference in Dubrovnik, IFATCA has adopted Policy on Mixed Mode Operations:

“Mixed mode operations are defined as ATM Operations that require different procedures due to variances in airspace users characteristics and/or ATM design within the same area of controller responsibility. Efforts should be undertaken to reduce existing Mixed Mode Operations by creating intrinsically safe solutions.

Introductions of new Mixed Mode Operations should be avoided by creating intrinsically safe solutions.

When safety of a Mixed Mode Operation cannot be completely managed at an intrinsic level, assessment must take place that the change in the ATM system does not increase controller workload to an unacceptable level.”

 

In the opinion of TOC, these Policy statements cover the introduction of different RCP types within the same airspace; therefore, no new policy is required.

Conclusions

3.1 The ICAO Required Communication Performance Concept follows the same principles as the Required Navigation Performance Concept already widely accepted within aviation.

3.2 The RCP Manual ICAO Doc 9869 in general provides adequate guidance material for States that want to introduce RCP within their airspace. It remains unclear how exactly the RCP types stated in the manual were determined.

3.3 The inclusion of the human when defining RCP types is supported by TOC.

3.4 The Manual states the possibility of operating more than one RCP type within a given airspace, yet fails to mention how in such a case the different RCP types should be managed. This is a human factors issue that is not addressed in the Manual.

3.5 IFATCA has newly adopted policy on Mixed Mode Operations which covers those cases of Mixed Mode Operations postulated in the RCP Manual.

Recommendations

It is recommended that:

4.1 This paper is accepted as Information Material.

Last Update: September 29, 2020  

April 16, 2020   1116   Jean-Francois Lepage    2010    

Comments are closed.


  • Search Knowledgebase