RWANDA

ADVISORY CIRCULAR
RCAA-AC-PANSOPS003
CIVIL AVIATION AUTHORITY

GUIDANCE ON IMPLEMENTATION OF PERFORMANCE BASED

NAVIGATION (PBN) IN RWANDA

1.0 PURPOSE

This Advisory Circular provides guidance on the procedures and steps to be followed by
Air Navigation Service Providers in the implementation of Performance Based
Navigation (PBN) in the Rwandan airspace.
2.0 INTRODUCTION

The PBN concept specifies that aircraft RNAV and RNP system performance
requirements be defined in terms of the accuracy, integrity, continuity and functionality,
which are needed for the proposed operations in the context of a particular airspace
concept. The PBN concept represents a shift from sensor-based to PBN. Performance
requirements are identified in navigation specifications, which also identify the choice of
navigation sensors and equipment that may

be used to meet the performance requirements. These navigation specifications are

defined at a sufficient level of detail to facilitate global harmonization by providing
specific implementation guidance for States and operators.

A navigation specification is a set of aircraft and aircrew requirements needed to

support a navigation application within a defined airspace concept. The navigation
specification defines the performance required by the RNAV or RNP system as well as
any functional requirements such as the ability to conduct curved path procedures or to
fly parallel offset routes

RNAV and RNP systems are fundamentally similar. The key difference between them is
the requirement for on-board performance monitoring and alerting. A navigation
specification that includes a requirement for on-board navigation performance
monitoring and alerting is referred to as an RNP specification. One not having such
requirements is referred to as an RNAV specification. An area navigation system
capable of achieving the performance requirement of an RNP specification is referred to
as an RNP system.

PBN offers a number of advantages over the sensor-specific method of developing

airspace and obstacle clearance criteria, i.e.:

RCAA-AC-PANSOPS003 January 2021 Page 2 of 29

a) reduces the need to maintain sensor-specific routes and procedures, and their
associated costs;

b) avoids the need for developing sensor-specific operations with each new evolution of
navigation systems, which would be cost-prohibitive;

c) allows for more efficient use of airspace (route placement, fuel efficiency and noise
abatement);

d) clarifies how RNAV and RNP systems are used; and

e) facilitates the operational approval process for operators by providing a limited set of
navigation specifications intended for global use.

3.0 REFERENCES

2.1 Part 22 of Civil Aviation Regulations

2.2 Part 6 of Civil Aviation regulations
2.3 Part 10 of civil Aviation regulations
2.4 ICAO ICAO PANS Doc 8168 Part II - Aircraft operations - Construction of Visual &
instrument flight procedures

2.5 ICAO Doc 9613 - Performance Based Navigation Manual

2.6 Rwanda Civil Aviation Technical Standards (RCATS)

4.0 IMPLEMENTATION PROCESSES

Implementing RNAV or RNP applications in the Rwandan airspace should be in

accordance with the following three processes:

 Process 1- Formulate an airspace concept

 Process 2- Identify ICAO navigation specification for implementation
 Process 3- Plan and implement.

RCAA-AC-PANSOPS003 January 2021 Page 3 of 29

4.1 PROCESS 1-FORMULATE AN AIRSPACE CONCEPT

An airspace concept is a general vision or master plan for a particular airspace. It is

driven by specific strategic objectives such as safety, capacity, efficiency, access
and environment as identified by airspace users, air traffic management(ATM), airports
as well as environmental and government policy.

Besides strategic objectives, airspace users (military/civil, air carriers, business/general

aviation) and ATM shall consider operational requirements as well. In addition, policy
directives concerning environmental mitigations, domestic and international user
requirements as well as airworthiness and operational approvals for operators shall be
considered.

An analysis should be carried out for all requirements (safety, efficiency, capacity) so as
to identify trade-offs necessary to strike a balance between competing requirements.
Consideration should be given to the primary and alternate means of meeting the
requirement, methods for communicating to airspace users the requirements and
availability(and outage) of services. A detailed plan for transition to the new airspace
concept needs to be developed.

4.1.1. Step 1- Formulate Airspace Concept

Airspace concept should be defined in sufficient detail so that supporting navigation

functions can be identified.

A team made up of air traffic controllers, airspace planners (from ANSP), pilots,
procedure design specialists, avionics specialists, flight standards and airworthiness
regulators and airspace users should carry out elaboration of the airspace concept.

Details on the following factors should be given:

 Airspace organization and management (i.e, ATS route placement, IDs/STARs,

ATC sectorization)
 Separation minima and route spacing;

RCAA-AC-PANSOPS003 January 2021 Page 4 of 29

  Instrument approach procedure options;
 How ATC is to operate the airspace
 Expected operations by flight crew and
 Airworthiness and operational approval.
4.1.1.1. Insets 1 to 4 below provide expanded information for the teams’ consideration:

RCAA-AC-PANSOPS003 January 2021 Page 5 of 29

RCAA-AC-PANSOPS003 January 2021 Page 6 of 29
4.1.2 Step 2: Assessment of Existing Fleet Capability and Available Navaid
Infrastructure.

Understanding the capabilities of aircraft that will be using the airspace is essential in
determining the type of implementation that is feasible to the users. Additionally,
understanding what is available in terms of navaids infrastructure is essential in
determining how and if a navigation, specification can be supported.

The following should be considered:

4.1.2.1 Assessing Aircraft Fleet

Aircraft fleets are not homogeneous in terms of RNAV system capability. Different
generations of aircraft may be active in airspace. Therefore, the airspace has to
accommodate all aircraft operating both on old and new technology.

This mixed- equipage traffic environment will be inevitable during the transition period. It
is therefore necessary to know the characteristics and level of equipage of the fleet
operating in the airspace. Questions that may be considered include:

RCAA-AC-PANSOPS003 January 2021 Page 7 of 29

  Are sufficient aircraft equipped with GNSS capability?
 Can failures of GNSS be mitigated by other means of navigation (e.g. DME- based
RNAV, conventional navigation or ATS surveillance system)?
 Do all IFR approved aircraft carry VOR and DME equipment and is that
equipment integrated into an RNAV system?
 When there are, insufficient navaids to provide adequate signal coverage, can the
gaps in coverage be accommodated by reliance on aircraft inertial systems?
If a mixed RNAV performance environment (or a mixed RNAV and conventional
environment) has been decided upon, ATC requirements must also be addressed for
those operations. Handling traffic of mixed navigation equipage can, depending on
the level of mixed equipment and operations, adversely affect capacity in the airspace
and place an unsuitable workload on controllers.

4.1.2.2. Assessing Navaid Infrastructure

4.1.2.2.1 Satellite navigation based on Global Navigation Satellite Systems (GNSS) has
made RNAV a reality for many operators. It has also made it possible for ANSPs to
consider a full transition to RNAV-based en route and terminal operations. However, since
such a transition may take a number of years, ANSP should identify a need to maintain
some ground-based navaids, either to provide alternate input to RNAV systems, to
support a reversionary conventional navigation environment or to provide conventional
navigation environment for non- RNAV equipped users.

4.1.2.2.2 Factors determining the scope of a ground navaids replacement programme

include:

RCAA-AC-PANSOPS003 January 2021 Page 8 of 29

 i. The rate at which aircraft operators equip their fleets with GNSS capable avionics.
ii. The extent of the requirement to retain some ground navaids for users not equipped
with GNSS, or as back-up to GNSS ( e.g. partial mitigation to the potential hazard
posed by interference with GNSS signals)
iii. The existence and age of existing navaid infrastructure.

4.1.2.2.3 Implementing an RNAV application should not in itself become the cause for
installing new navaid infrastructure. However, the introduction of RNAV application could
result in some existing navaids being moved (e.g. DMEs relocated when they no longer
have to be co-located with VOR).

4.1.3 Step 3-Assessment of the Existing ATS Surveillance System and

Communication Infrastructure and the ATM system.

PBN is only the navigation component of CNS/ATM. It cannot be safely and successfully
implemented without due consideration of the communication and ATS surveillance
infrastructure available to support the operation. e.g., an RNAV 1 route will require
different ATS route spacing in a radar or non-radar environment. Similarly, availability of
communication between aircraft and air traffic services may influence the level of air traffic
intervention capability needed for safe operations.

4.1.3.1. ATS Surveillance Infrastructure

Current ATS surveillance infrastructure is composed of primary and/or secondary

surveillance radar to support en route, terminal and approach operations. Newer systems
such as ADS-B can be expected to play an increasing role, particularly in procedurally
controlled environments. However, the dependence of ADS on the navigation solution

RCAA-AC-PANSOPS003 January 2021 Page 9 of 29

has to be considered when undertaking the overall evaluation of the operation (See
assessment of ADSP to Support Air Traffic Services and Guidelines for implementation
(ICAO circular 311)

4.1.3.1.1 Without robust ATS surveillance systems, RNAV route spacing is large.
Implementation of RNP in such an environment can compensate to some extent for the
lack of ATS surveillance coverage.

4.1.3.2 Communication Infrastructure

3.1.3.2.1 Currently, voice communication service is provided through VHF and HF radio.
VHF service is particularly widely available and is expected to be maintained (with or
without augmentation by data link communications).

4.1.3.3 ATM Systems

3.1.3.3.1 The evolution of the ATM system to meet the needs of PBN implementation
should be considered. Reduction of separation minima affects the alert limits of conflict
detection tools, or if different separation minima are used for different route types or
aircraft capabilities, this should be considered in the ATM system evolution.

If required time of arrival is included in an airspace concept, the automation system would
need to be designed accordingly. This same consideration applies with use of equipment
classifications (e.g., flight plan suffixes); controller merging and spacing tools and any

RCAA-AC-PANSOPS003 January 2021 Page 10 of 29

other air traffic control automation features that enable the of maximization the benefits
of RNAV and RNP.

4.1.4 Step 4-Identify Necessary Navigation Performance and Functional

Requirements.

4.1.4.1 The decision on the choice of an ICAO RNAV or RNP navigation specification is
not only determined by aircraft performance requirements (e.g. accuracy, integrity,
continuity, availability), but may also be determined by the need for specific functional
requirements (e.g., leg transitions/path terminators, parallel offset capabilities, holding
pattern, navigation data bases)

4.1.4.2 The proposed navigation functional requirements also need to consider:

a) The complexity of the RNAV procedures envisaged; the number of way points needed
to define the procedure; the spacing between waypoints and the need to define how a
turn is executed; and

b) Whether the procedures envisaged aim simply to connect with enroute operations and
can be restricted to operations above minimum vectoring altitude/ minimum sector
altitude, or are the procedures expected to provide approach guidance.

RCAA-AC-PANSOPS003 January 2021 Page 11 of 29

4.1.5 –Step 5 Go to Process 2

Figure 1-B-2-1 Summary of Process 1

RCAA-AC-PANSOPS003 January 2021 Page 12 of 29

 4.2 PROCESS 2- IDENTIFY ICAO NAVIGATION SPECIFICATION FOR
IMPLEMENTATION

The goal of process 2 is to identify ICAO navigation specification(s) that will support
the airspace concept and navigation functional requirements as defined in process 1.
The navigation functional requirements, fleet capability and CNS/ATM capabilities
already identified in process 1 will provide the specific context against which ability to
meet the requirement of a particular ICAO navigation specification can be evaluated.

4.2.1 Step 1-Review ICAO Navigation specification in Volume 2 of PBN Manual

(doc 9613)

a) Step 1 is aimed at finding a potential match between the requirements identified in

process 1 and those contained in one or more of the ICAO navigation specifications in
volume II.

b) In reviewing one or more possible ICAO navigation specifications, there will be a

need to consider the output of process 1 with respect to:

i) the ability of the existing aircraft fleet and available navaid infrastructure to meet the
requirements of a particular ICAO specification (step 1A in figure 1-B-3-1) and

RCAA-AC-PANSOPS003 January 2021 Page 13 of 29

 ii) the capabilities of the communication and ATS surveillance infrastructure, and ATM
system to support implementation of this particular ICAO navigation specification (step
1B in figure 1-B-3-1)

4.2.1.1 Examples of some questions to be considered when comparing the output

from process 1 with the ICAO navigation specifications are shown in inset 5.

4.2.2 Step 2-Identify appropriate ICAO Navigation Specification to apply in the

specific CNS/ATM environment.

4.2.2.1 If it is determined that a particular ICAO navigation specification in Vol. II

can be supported by the fleet equipage,navaid infrastructure, communication
and ATS surveillance and ATM capabilities available, proceed to process 3-
planning and Development.

4.2.2.2 If an ICAO navigation specification cannot be supported, continue with

process 2, step 3.

4.2.3. Step 3-Identify trade-offs with airspace concept and functional

requirements (if necessary).

RCAA-AC-PANSOPS003 January 2021 Page 14 of 29

 4.2.3.1. This step is followed when an exact match between a particular ICAO
navigation specification and the fleet equipage, navaid infrastructure,
communications and ATS surveillance and ATM capabilities available cannot be
made.

4.2.3.2 The aim is to change either the airspace concept or navigation function
requirements, in order to select an ICAO navigation specification. e.g.,
operational requirements reflected in the airspace concept could be reduced, or
alternative means identified to achieve a similar (if not identical) operational
result.

Note: Safety can be improved by establishing uniform aircraft and navigation

requirements across varying regions. Navigation specifications are also significant
sources of cost control to operators.

Navigation specifications have associated aircraft requirements, navaid

infrastructure expectations and route spacing requirements.

4.2.3.3 Airspace concept and required navigation functions identified in process

1, should be revisited to determine what trade-offs can be made so as to
implement a particular existing ICAO navigation specification.

The following are the reasons which could explain the lack of match:

a) The original analysis of the navigation functional requirements (from process

1) did not correctly identify all functions required for the airspace concept.
Perhaps a functional capability was omitted or because it was unnecessarily
identified. Initial analysis could have omitted some or all the leg types required
for RNAV in terminal airspace, or failed to require fixed-radius transitions where
closely spaced parallel tracks are to be implemented in enroute applications.

RCAA-AC-PANSOPS003 January 2021 Page 15 of 29

 b) The navigation function requirements identified in process 1 were defined
around existing fleet capability operating in the airspace, with the expectation
that this capacity would be appropriate for the airspace concept. If use of this
fleet capability remains the target, then it would be necessary to change the
airspace concept.

4.2.3.4 In most instances, it will be possible to make sufficient trade-offs in the

original airspace concept or required navigation functions from process 1, such
that an existing ICAO navigation specification can be selected. Once trade-offs
have been made that will allow selection of an ICAO navigation specification,
proceed to process 3: Planning and Implementation.

4.2.3.5 If in the rare case that it is determined that it is impossible to make trade-
offs in airspace concept and/or navigation function requirements, a new navigation
specification would have to be developed. (Chapter 5)

RCAA-AC-PANSOPS003 January 2021 Page 16 of 29

RCAA-AC-PANSOPS003 January 2021 Page 17 of 29
 4.3 PROCESS 3: PLANNING AND IMPLEMENTATION

Process 3 is concerned with planning and implementation of PBN. It follows upon

completion of processes 1 and 2. Detailed discussion of some important
considerations that should be kept in mind when framing the implementation
plan are given in inset 6 below.

RCAA-AC-PANSOPS003 January 2021 Page 18 of 29

 Navigation functional requirements, fleet capability and CNS/ATM capabilities will
have been identified in process 1. The ICAO navigation specification(s) will have
been selected in process 2. Possible additional national or regional requirements
for implementation should be identified and incorporated.

STEPS IN PROCESS 3

4.3.1 Step 1-Formulate Safety Plan

4.3.1.1The first step in process 3 is to formulate a safety plan for PBN

implementation (See guidance, SMM manual)

4.3.1.2 Depending on the nature of implementation, this could be a national or

regional plan. Normally, the ANSP safety team, to the satisfaction of the
regulatory authority, would develop such a plan. The safety plan details how
the safety assessment is to be accomplished for the proposed RNAV or RNP
implementation.

4.3.2-Step 2-Validate Airspace Concept for Safety

4.3.2.1 This step involves completing a safety assessment. From the

assessment, additional safety requirements may be identified which need to be
incorporated into the airspace concept prior to implementation.

RCAA-AC-PANSOPS003 January 2021 Page 19 of 29

 4.3.2.2 Four validation means are traditionally used to validate airspace concept:

a) airspace modeling

b) fast-time simulation (FTS)

c) real-time simulation (RTS)

d) live ATC trials.

4.3.2.3 For simple airspace changes, it may be necessary to use all of the above
validation means for any one implementation. For complex airspace changes,
FTS and RTS can provide essential feedback on safety (and efficiency) issues and
their use is encouraged. Application of new navigation specifications can range
from simple through major changes to the airspace concept.

The four types are discussed below:

4.3.2.4 Airspace Modelling.

Airspace modeling is beneficial because it provides some understanding of how

the proposed implementation will work, yet it does not require the participation
of controllers or pilots. Airspace models are computer-based, so it is possible to
make changes quickly and effectively to ATS routes, holding patterns, airspace
structures or sectorization to identify the most beneficial scenarios (i.e. those
that are worth carrying forward to more sophisticated validations).

Using computer-based airspace model can make it easier to identify non-viable

operating scenarios so that unnecessary expense and effort is not wasted on
more advanced validation phases.

RCAA-AC-PANSOPS003 January 2021 Page 20 of 29

 The main role of an airspace model is to eliminate non-viable airspace scenarios
and to support the qualitative assessment of further concept development.

4.3.2.5 Fast-Time Simulation (FTS)

Following the computer- based airspace modeling phase,it can be useful to run a
fast time simulation. A more sophisticated assessment that airspace modeling, an
FTS returns more precise and realistic results while still not requiring the active
participation of controllers or pilots; however, in terms of data collection and
input, preparation can be demanding and time consuming.

4.3.2.6 Real-Time Simulation (RTS)

The most realistic way to validate an airspace concept is to subject the viable
scenarios to real-time simulation (RTS). These simulators realistically replicate
ATM operations and require the active participation of proficient controllers and
simulated ‘pseudo’ pilots. In some cases, sophisticated RTS can be linked to
multiple-cockpit simulators so that realistic flight performance is used during
simulation. One of the difficulties that can be encountered with real time simulation
is that the navigation performance of the aircraft is too perfect. Aircraft in RTS may
operate with a navigation precision that is unrealistic, given weather realities,
individual aircraft performance etc. In such cases, error rates from live operations
are analyzed and can be scripted into RTS.

RCAA-AC-PANSOPS003 January 2021 Page 21 of 29

4.3.2.7 Live ATC Trials

Live ATC trials are generally used to verify operating practices or procedures when
subtleties of the operations are such that FTS and RTS do not satisfy the validation
requirements.
It should be noted that step 3-Procedure Design must be completed before live
ATC trials can be conducted.

4.3.3 Step 3-Procedure Design

4.3.3.1 A total system approach to implementation of the airspace concept

means that the procedure design process is an integral element. Therefore, the
procedure designer is a key member of the airspace concept development team.

4.3.3.2 Procedure designers need to ensure that the procedures can be coded in ARINC
424 format. Currently this is one of the major challenges facing procedure designers.
Many are not familiar with either the path and terminators used to code RNAV systems
or the functional capabilities of different RNAV systems (See attachment A of volume 2
of the PBN Manual, ICAO Doc). Many of the difficulties can be overcome however, if close
cooperation exists between procedure designers and the data houses that provide coded
data to navigation data base providers.

4.3.3.3 Once these procedures have been validated and flights inspected (see step 4 and
6), they are published in the AIP along with any changes to routes, holding areas or
airspace structures.
4.3.3.4 The complexity involved in data processing of RNAV system database means that
in most instances, a lead period of two AIRAC cycles is required (see volume 1,
attachment B, section 3 for more details).

4.3.4 Step 4- Procedure Ground Validation

4.3.4.1 The development of an RNAV or RNP instrument flight procedure or ATS route
follows a series of steps from the origination of data through survey to the final
publication of the procedure and subsequent coding of it for use in an airborne

RCAA-AC-PANSOPS003 January 2021 Page 22 of 29

navigation database (see Attachment B of volume 2 of PBN Manual). At each step of the
procedure design process, there should be quality control procedures in place to ensure
that the necessary levels of accuracy and integrity are achieved and maintained. These
quality control procedures are detailed in PANS-OPS (Doc 8168), Volume II.

4.3.4.2 After designing the procedure, and before an RNAV or RNP route or procedure
is published, PANS-OPS (Doc 8168) require that each procedure undergo a validation
process. The objective of validation is to:

a) provide assurance that adequate obstacle clearance has been provided;

b) verify that the navigation data to be published, as well as that used in the design
of the procedure, are correct;
c) verify that all required infrastructure, such as runway markings, lighting, and
communications and navigation sources, are in place and operative;
d) conduct an assessment of flyability to determine that the procedure can be
safely flown; and
e) evaluate the charting, required infrastructure, visibility and other operational
factors.

4.3.4.3 Many of these factors can be evaluated, entirely or in part, during ground
validation. Initial flyability checks should be conducted with software tools allowing the
flyability of the procedure to be confirmed for a range of aircraft and in a full range of
conditions (wind/temperature, etc.) for which the procedure is designed.

The verification of the flyability of an RNAV or RNP procedure can also include
independent assessments by procedure designers and other experts using specialized
software or full-flight simulators. Flyability tests using flight inspection aircraft can be
considered, but it must be borne in mind that this only proves that the particular aircraft
used for the test can execute the procedure correctly. This is probably acceptable for the

RCAA-AC-PANSOPS003 January 2021 Page 23 of 29

majority of less complex procedures. The size and speed of flight test aircraft can
seldom fully represent the performance of a fully loaded B747 or A340 and therefore
simulation is considered the most appropriate way to carry out the flyability test.

Flight simulator tests should be conducted for those more complex procedures, such as
RNP AR APCH, when there is any indication that flyability may be an issue.

Software tools that use digital terrain data (typically digital terrain elevation data (DTED)
level 1 being required) are available to confirm appropriate theoretical navaid coverage.

4.3.5-Step 5- Implementation Decision

4.3.5.1 It is usually during the various validation processes described above that it
becomes evident whether the proposed design can be implemented. The decision
whether or not to go ahead with implementation needs to be made at a pre-determined
point in the life cycle of a project.

Note. — If the available tools and/or quality of data used in Step 4 warrant, it may be
desirable to undertake Step 6 before a final implementation decision is taken.

4.3.5.2 The decision of whether to go ahead with implementation will be based on

certain deciding factors. These include:

a) whether the ATS route/procedure design meets air traffic and flight operations
needs;
b) whether safety and navigation performance requirements have been satisfied;
c) pilot and controller training requirements; and
d) whether changes to flight plan processing, automation, or AIP publications are
needed to support the implementation.
4.3.5.3 If all implementation criteria are satisfied, the project team needs to plan for
execution of the implementation, not only as regards their “own” airspace and ANSP,

RCAA-AC-PANSOPS003 January 2021 Page 24 of 29

but in cooperation with any affected parties which may include ANSPs in an
adjacent State.

4.3.6 Step 6 — Flight inspection and flight validation

4.3.6.1 Flight inspection of navaids involves use of test aircraft which are specially
equipped to gauge the actual coverage of the navaid infrastructure required to support
the procedures, arrival and departure routes designed by the procedure design
specialist.

Flight validation continues the procedure validation process noted in Step 4. It is used to
confirm the validity of the terrain and obstruction data used to construct the procedure,
and that the track definition takes the aircraft to the intended aiming point, as well as the
other validation factors listed in Step 4.

4.3.6.2 Output from the above procedures may require the procedure design specialist
to refine and improve the draft procedures. The Manual on Testing of Radio Navigation
Aids (Doc 8071) provides general guidance on the extent of testing and inspection
normally carried out to ensure that radio navigation systems meet the SARPs in
Annex 10 —Aeronautical Telecommunications, Volume I. PANS-OPS (Doc 8168),
Volume II, Part 1, Section 2, Chapter 4, Quality Assurance provides more detailed
guidance on instrument flight procedure validation.

4.3.7 Step 7 — ATC system integration considerations

4.3.7.1 The new airspace concept may require changes to the ATC system interfaces
and displays to ensure controllers have the necessary information on aircraft
capabilities. Considerations arising from mixed equipage scenarios are discussed in
Inset 7. Such changes could include, for example:
a) modifying the air traffic automation’s flight data processor (FDP);

b) making changes, if necessary, to the radar data processor (RDP);

c) requiring changes to the ATC situation display; and

d) requiring changes to ATC support tools.

RCAA-AC-PANSOPS003 January 2021 Page 25 of 29

4.3.7.2 There may be a requirement for changes to ANSP methods for issuing
NOTAMS.

RCAA-AC-PANSOPS003 January 2021 Page 26 of 29

4.3.8 Step 8 — Awareness and training material

The introduction of PBN can involve considerable investment in terms of training,

education and awareness material for both flight crew and controllers. In many States,
training packages and computer-based training have been effectively used for some
aspects of education and training. ICAO provides additional training material and
seminars. Each navigation specification in Volume II, Parts B and C addresses the
education and training appropriate for flight crew and controllers.

4.3.9 Step 9 — Establishing operational implementation date

An effective date will be set out in accordance with the requirements set out in Volume I,
Attachment B, Data Processes. Experience has identified that an additional time period
(e.g. one to two weeks) should be allocated prior to the operational implementation
date. This additional period is to ensure ground and airborne system data are properly
loaded and validated in databases.

4.3.10 Step 10 — Post-implementation review

4.3.10.1 After the implementation of PBN, the system needs to be monitored to ensure
that safety of the system is maintained and to determine whether strategic objectives
have been achieved. If after implementation, unforeseen events do occur, the project
team should put mitigation measures in place as soon as possible. In exceptional

circumstances, this could require the withdrawal of RNAV or RNP operations while
specific problems are addressed.

4.3.10.2 A system safety assessment should be conducted after implementation and

evidence collected to verify that the safety of the system is assured — see the Safety
Management Manual (SMM) (Doc 9859).

RCAA-AC-PANSOPS003 January 2021 Page 27 of 29

RCAA-AC-PANSOPS003 January 2021 Page 28 of 29
RCAA-AC-PANSOPS003 January 2021 Page 29 of 29