Loss of separation
Nav Canada Vancouver Area Control Centre
DUXAR Intersection,
British Columbia, 110 nm NW
The Transportation Safety Board of Canada (TSB) investigated this occurrence for the purpose of advancing transportation safety. It is not the function of the Board to assign fault or determine civil or criminal liability. This report is not created for use in the context of legal, disciplinary or other proceedings. See Ownership and use of content.
Summary
An Air Canada Boeing 737 (ACA3584) had departed Vancouver, British Columbia, on a scheduled flight to Whitehorse, Yukon. The aircraft was cruising at flight level (FL) 310 under the control of the Vancouver Area Control Centre (ACC). An Omni Air Express DC-10 (OAE960), under the control of the Edmonton ACC, was flying southeast from Anchorage, Alaska, to Cherry Point, North Carolina, and had been cleared to climb from FL290 to FL330. About 10 minutes after the B737 crossed the Vancouver/Edmonton airspace boundary at the DUXAR intersection, a loss of separation occurred in nonradar airspace when the DC-10 came into conflict with the B737 at FL310. Both aircraft received traffic alert and collision-avoidance system warnings; the DC-10 descended to FL290, and the B737 climbed to FL335 before returning to FL310, once clear of the conflict.
Factual information
The B737 (ACA3584) was proceeding to Whitehorse via the Houston VOR (very high frequency omnidirectional radio range) and the DUXAR intersection at a cleared altitude of FL310. It crossed the Northern Control Area Route 10 (NCA 10) about 110 nautical miles (nm) northwest of the DUXAR intersection. This intersection is at the airspace boundary between the Vancouver and Edmonton ACCs. (See Figure 1.) Between the Houston VOR and DUXAR, the aircraft was under the control of the Sandspit sector of Vancouver ACC.
Most of the traffic in this sector is high-level, heading to or from oceanic airspace entry points. The sector had been staffed by a radar controller and a data controller until approximately 15 minutes before the incident, at which time staffing was reduced to a single controller. The workload was assessed as moderate, with some complexity. A number of aircraft were entering the western portion of the sector, for which no flight plan existed in the radar data-processing system (RDPS). The lack of a flight plan prevented the radar targets from being tagged with the flight number. The controllers were required, in some instances, to manually enter information until action could be taken to update the RDPS. The attention of the Sandspit radar controller was therefore directed toward the western portion of the airspace. The B737 was flying through the northeastern portion of the sector, which contained no other traffic at the time.
An estimate for the B737 at DUXAR intersection of 1427 Pacific daylight timeFootnote 1 had been passed from the previous sector (Haida) controller to the Sandspit data controller and was shortly thereafter revised to 1422. The Sandspit radar controller accepted a radar handoff of the B737 near the boundary with the Haida sector and, at 1406, established contact with the aircraft. No further communication occurred between the B737 and the Sandspit controller. Contrary to Vancouver ACC procedures, the Sandspit controller did not instruct the B737 to contact Edmonton ACC at the boundary fix (DUXAR).
A number of lists are available to controllers to display alphanumeric flight information on the radar indicator module (RIM). The arrival list displays information on flights that are currently under the controller's jurisdiction but are not being displayed as targets on the RIM. Aircraft on the arrival list are tracked by the radar system. The coast list displays information on aircraft that have a controller jurisdiction symbol (CJS) and whose targets have been lost by the radar. The lists ensure that flight information is still available to the controller, even though there is no radar target displayed. The lists are designed as defences to prevent controllers from forgetting about flights not currently displayed. The Nav Canada Air Traffic Control Manual of Operations (ATC MANOPS) requires that the coast list be displayed; other lists, such as the arrival list, are displayed at the controller's discretion.
The DUXAR intersection is a compulsory reporting point on Canadian en route high-altitude charts. Aircraft passing over that point are required to report their position to an air traffic service facility. Aircraft under radar control, however, need only file a position report over a compulsory reporting point when specifically requested to do so. The Sandspit radar controller did not request the B737 to make a position report, and the pilot did not do so.
At 1419, the radar target for the B737 disappeared from the northern edge of the Sandspit radar controller's RIM, just as the B737 was crossing into airspace controlled by the Edmonton ACC at DUXAR intersection. The aircraft target and data block disappeared, and the flight number and the CJS, highlighted by asterisks, were transferred to the arrival list displayed near the bottom of the controller's RIM. The Sandspit radar controller did not notice that the B737 radar target was no longer displayed. The B737 proceeded out of radar coverage at 1422, about 22 nm northwest of DUXAR intersection. The aircraft flight number was then transferred from the arrival list to the coast list. The Sandspit radar controller did not observe the transfer of information from one list to the other, nor did the computer system provide any type of alert to the controller.
The DC-10 (OAE960) was flying from Anchorage to Cherry Point via NCA 10 at FL290. At 1429, the pilot requested a clearance from Edmonton ACC to climb to FL330. The Edmonton ACC controller issued the clearance for the climb, and the aircraft commenced climb shortly thereafter. About two minutes after commencing the climb, the pilot of the DC-10 advised the Edmonton ACC controller that he had received a traffic alert and collision-avoidance system (TCAS) warning of another aircraft 2000 feet above and that he was descending back down to FL290.
At 1437, the pilot of the B737 contacted the Edmonton ACC and advised that they were 177 nm from Whitehorse, level at FL310, and that 10 nm earlier (approximately as they crossed NCA 10) they had received a TCAS resolution advisory (RA) to climb because of an intruder aircraft approaching from below. The pilot had climbed the aircraft 2500 feet at a rate of 3000 feet per minute to avoid the intruder and, when clear of the conflict, descended back to FL310. Before the call from the B737, Edmonton ACC controllers were not aware that this aircraft had entered their airspace because Vancouver ACC had not passed an estimate to Edmonton ACC. The Sandspit controllers had not coordinated the B737 flight with Edmonton ACC. The inter-unit agreement between Edmonton and Vancouver ACCs specifies that an estimate is to be passed from one unit to the other 15 minutes before the aircraft penetrates the other unit's airspace.
The DC-10 and the B737 were flying in airspace outside radar coverage when they received TCAS alerts. The proximity of the aircraft could not be determined; however, TCAS RAs are normally provided when aircraft are approximately 20 seconds' flying time apart. The separation required for aircraft on reciprocal tracks in a nonradar environment is 2000 feet vertically from 10 minutes before until 10 minutes after their estimated passing time.
Estimates for aircraft entering the Anchorage Air Route Traffic Control Center (ARTCC) airspace are passed to that agency by air traffic operations specialists (ATOSs). Estimates for aircraft entering the airspace of adjacent Canadian ACCs are passed directly by the controller. The Sandspit data controller had received the DUXAR estimate for the B737 and subsequently included that information in a batch of nine other estimates that he passed to the ATOS. The Sandspit data controller should have passed the estimate for the B737 directly to the Edmonton ACC controller instead of to the ATOS.
A few minutes after receiving the grouped estimates, the ATOS called the Sandspit data controller back to confirm the flight number for the B737 because he had initially written it down incorrectly. The Sandspit data controller confirmed that the flight number was ACA3584 and updated the earlier estimate with a new time of 1422. The ATOS then asked the controller to confirm that the estimate was for Houston; the controller mistakenly confirmed that it was. Local procedures require controllers to include the flight number, fix, time, and altitude when passing estimates to the ATOS. A review of air traffic control (ATC) communications revealed that when the controller passed this batch of estimates, the fix was specified for only three of the nine.
When the controller passed the estimate for the B737 to the ATOS, the ATOS believed that this information had to be relayed to Anchorage ARTCC because he has no role in relaying estimates to Edmonton ACC. In most situations, ATOSs do not challenge controllers about information given them to relay to another ATC agency. It was not unusual for the ATOS to receive a Houston estimate to pass on to Anchorage ARTCC; he therefore accepted the Houston estimate for the B737 for that point.
The ATOS who received the original and the revised estimates for the B737 was then relieved by another ATOS, as part of the normal shift rotation. The second ATOS received a reject message for the B737, indicating that a flight plan was not on file in the Anchorage ARTCC system. The unwritten procedure in response to this type of problem was for the ATOS to review the route, make a minor change, usually deleting one of the fixes just before destination, then resend the information. However, the Anchorage computer continued to reject the flight plan. After receiving three more rejects, the ATOS contacted his Anchorage counterpart directly. The Anchorage ATOS advised that the information for the B737 had been passed to a floor supervisor, although both ATOSs were unsure why the estimate was being passed to Anchorage in the first place. This action was deemed satisfactory to both ATOSs, and no further action was taken with the B737. It was not determined what actions the Anchorage supervisor took regarding the estimate for the aircraft.
Nav Canada had not issued explicit procedures for ATOSs to follow when they encounter multiple rejections of estimate information. ATOSs are not required to advise controllers when estimates have been successfully passed. Nav Canada had recently implemented a revised software program for sending flight plan and estimate information, but it significantly increased the number of reject messages received from Anchorage ARTCC. As a result, the ATOSs' workload had increased substantially. Due to the number of problems encountered with this new system, the new program was disabled shortly after this occurrence and is pending further development before a re-introduction.
The Sandspit data controller entered the DUXAR estimate for the B737 into box 7 of the flight progress strip (FPS) when he first received the estimate from the Haida sector. (See Figure 2. Note: Times recorded on all ATC documents are in Coordinated Universal Time.) He did not indicate that the estimate was for DUXAR. The Vancouver ACC strip-writing procedures that supplement ATC MANOPS Part 9, Flight Progress Strip Marking, indicate that box 14 may be used for entering estimates for fixes that are not posted on the flight data board. In this incident, the FPS for the B737 was placed under the Houston fix posting on the flight data board, even though the received estimate was for DUXAR. Since there is no separate DUXAR fix designator on the data board, box 14 of the FPS may be used to show the fix (DUXAR) and the estimated time. Alternatively, the DUXAR estimate may be written above the fix name in the route in box 6. Controller practices for recording the estimate on the FPS varied. When the Sandspit data controller received the estimate for DUXAR, the information was passed to the ATOS, and the FPS was then marked to record that the estimate had been passed to the next concerned sector. The slash marks in box 7 indicate that an estimate and a revision have both been passed, in accordance with the standard procedure for this flight route.
The Sandspit radar controller allowed the data controller to proceed on a break at about 1415 and assumed responsibility for the radar and the data functions. The handover briefing between these controllers did not include a detailed review of the status of each aircraft flying in the sector because the controllers had worked the same traffic together during this shift. Some time later, in the process of rearranging the flight progress board, the Sandspit radar controller noticed that the strip for the B737 did not indicate that the aircraft had been transferred to Edmonton ACC. At 1431, the Sandspit radar controller asked an Edmonton ACC controller to confirm if they were in communication with the ACA3584. The Edmonton ACC controller advised that they were not and that they had not received an estimate for this flight.
The Edmonton ACC northern airspace display system (NADS) had the required flight information on the B737 in its database, and an FPS had been printed for the appropriate sectors. However, to cause an aircraft target to be displayed on the NADS situational display (NSiT), the Edmonton controller first has to enter an estimate for a fix into the NADS. For the B737, the fix would have been the DUXAR intersection. The Edmonton controller did not receive the estimate from the Sandspit controller; therefore, the fix estimate was not entered, and the target was not displayed on the controller's NSiT.
Analysis
ATC procedures and standard practices concerning flight information handling and tracking are designed to act as multilevel defences so that a failure in one area does not lead directly to an accident. Among these are standard strip handling and marking practices, standardized coordination and information practices, and technology in the automated systems to alert controllers to unusual situations. In this incident, the defences broke down, resulting in a risk of collision between two large transport-category aircraft.
The Sandspit data controller did not follow either of the local FPS marking conventions of placing the DUXAR estimate above that fix in the routing in box 6 or writing DUXAR and the estimate in box 14. The controller wrote the B737 DUXAR estimate in a location normally reserved for a Houston estimate. The FPS for the B737 was now indistinguishable from the other flights that had to be passed to ATOS. Even with the subsequent prompting from the ATOS to confirm the flight number for the B737, the controller did not detect the problem and actually confirmed that the estimate given to the ATOS had been for Houston rather than for DUXAR.
Nav Canada's local procedures specify the information to be included when passing estimates to ATOSs. In this occurrence, the controller did not pass the fix name to which the B737's estimate applied. Furthermore, the fix name was passed only three times in the group of nine estimates passed at the same time as that of the B737. In essence, this procedural omission delegated to the ATOS the responsibility of determining where the aircraft crosses into the next agency's airspace and of determining to which agency the estimate should be passed. Nav Canada has not provided ATOS personnel with specific instructions to follow when they encounter system errors, such as rejected flight plan messages. Feedback was not provided to the Sandspit data controller, nor was there a requirement to do so, when a problem with the estimate for the B737 was encountered.
The Sandspit radar controller did not notice the target for the B737 disappear from the RIM because, at the time, the controller was focused on traffic in the western part of the sector. The automatic transfer of the flight information for the B737 to the arrival list, the subsequent loss of the radar target, and the transfer of the flight information from the arrival list to the coast list were missed by the Sandspit radar controller. The defences that were to be provided by the lists were not effective in alerting the controller that the target for the B737 was no longer being displayed. There were no compelling system-generated warnings to draw the controller's attention to the fact that a radar target was no longer being displayed. With the B737 no longer visible on the RIM, and the controller's attention directed elsewhere in the sector, it was less likely that the controller would recall the requirement to hand off the B737 to Edmonton ACC. In a radar environment, FPSs alone are less often reviewed and, therefore, do not provide as effective a defence against forgetting about a particular aircraft. Controllers have the option of requesting position reports from aircraft under radar control; however, this technique is not widely used when radar control services are being provided.
The handover from the Sandspit data controller to the Sandspit radar controller at a time of sector consolidation did not include a detailed review of the status of each flight in the sector. The underlying assumption by both controllers was that they were each aware of all the aircraft in the sector, and they did not match FPS information with each displayed radar target.
The area around DUXAR intersection is a critical location for the display of and communication with aircraft. Therefore, procedures for passing estimates and monitoring the progress of the flights in this vicinity is critical to ensure that the required separation is maintained. Because the B737 was not activated on the Edmonton NSiT display, and the Vancouver controller did not notice the aircraft fly beyond the area displayed on his RIM and subsequently out of radar coverage, defences were no longer in place to prevent the loss of separation. The advisories provided by the onboard TCAS equipment were the last defences against a potential midair collision.
Findings
Findings as to causes and contributing factors
- The Sandspit data controller did not pass the estimate for the B737 to Edmonton ACC. As a result, the aircraft was not activated on the Edmonton controller's NSiT. The Edmonton controller was therefore not aware of the conflicting traffic when he issued a climb clearance to the DC-10.
- The Sandspit radar controller did not transfer the B737 to the Edmonton ACC frequency before losing communications with the aircraft. As a result, the aircraft flew into Edmonton-controlled airspace without the Edmonton controller's knowledge.
- The fix name was not included when passing the B737 estimate to the ATOSs, and it was often not included on other occasions. As a result, the ATOS was not in a position to note that the estimate should have been passed to Edmonton rather than to Anchorage.
Findings as to risk
- The directions for ATOSs to follow if a flight plan reject message is received do not provide specific guidance as to required actions. This has led to the development of ad hoc and nonstandard procedures among the ATOSs.
- There is no compelling warning to controllers when an aircraft target under the controller's responsibility disappears from the display. The resultant transfer of flight information to one of the lists on the display was, in this occurrence, not sufficient to alert the controller. Not all lists are required to be displayed.
- The handover between the Sandspit data and radar controllers did not include a detailed review of each flight within the sector. This reduced the likelihood of detecting errors made in coordination and strip marking.
Safety action
Safety action taken
Effective 15 May 2002, Nav Canada implemented well-defined procedures for the ATOSs to follow in the exchange of flight data, both between and within ACCs. The new procedures also provide ATOSs with specific direction on how to proceed when a reject message is received.
On 08 April 2002, the TSB issued Aviation Safety Advisory A020002-1. The advisory suggested that Nav Canada may wish to develop effective measures to ensure that controllers become immediately aware that a radar target has been lost from the display because of the range setting selected for the display, limitation of radar coverage, or any other reason. Nav Canada responded to this advisory on 30 May 2002:
- Vancouver ACC has received new enhanced RDPS situational displays with improved radar target loss processing, including colour highlighting and flashing alerts.
- Nav Canada has initiated a Level 3 operations safety investigation to investigate the safety issues surrounding loss of radar targets.
- Nav Canada will continue to develop supporting technologies to reduce the workload of operational staff and enhance safety.
This report concludes the Transportation Safety Board's investigation into this occurrence. Consequently, the Board authorized the release of this report on .
Appendices
Appendix A - Glossary
- ACC
- area control centre
- ARTCC
- air route traffic control center
- ATC
- air traffic control
- ATC MANOPS
- Air Traffic Control Manual of Operations
- ATOS
- air traffic operations specialist
- CJS
- controller jurisdiction symbol
- FL
- flight level
- FPS
- flight progress trip
- NADS
- northern airspace display system
- NCA
- northern control area
- nm
- nautical mile
- NSiT NADS
- situational display
- RA
- resolution advisory
- RDPS
- radar data-processing system
- RIM
- radar indicator module
- TCAS
- traffic alert and collision-avoidance system
- VOR
- very high frequency omnidirectional radio range