Effective system safety and emergency management efforts require learning from failure, and from success. Lessons learned will be presented here, often illustrated through an accident or incident. Note that in discussing these events, the intent is not to oversimplify the conditions that led to the incidents or to place blame on individuals and organizations. Rarely is there only one identifiable cause leading to the accident. Accidents and incidents are usually the result of complex factors that include hardware, software, human interactions, procedures, and organizational influences. Readers are encouraged to review the full investigation reports referenced to understand the often complex conditions that led to each accident discussed here.
Aircraft Near Miss in Calgary
On March 2, 2010, an aircraft crossed the hold line on one taxiway as another aircraft passed overhead at the Calgary International Airport in Alberta, Canada. The Transportation Safety Board of Canada (TSB) determined in its investigation that multiple factors led to this runway incursion event. The airport controller lost track of the aircraft due to long delays between the time the aircraft arrived at the taxiway and the issuance of take-off clearance. The tower was at reduced staffing levels, and the tower coordinator position was vacant, so no one was present to check on the position of the aircraft. Calgary International Airport was equipped with Airport Surface Detection Equipment (ASDE), which included a real time display in the tower of aircraft and other vehicle traffic operating on airport maneuvering areas. The ASDE display did not show identification tags of the departing aircraft, which led the controller to lose the position of certain aircraft. The ASDE included a software feature known as the Runway Incursion Monitoring and Collision Avoidance System (RIMCAS) to monitor movements and identify conflicts. But the RIMCAS feature was not enabled, so the controller was not alerted to the potential for incursion. The RIMCAS had been disabled because the controllers experienced a large number of nuisance alarms associated with the system. Disabling the RIMCAS removed an opportunity for the controller to be alerted to the incursion, according to the TSB.
Lessons Learned: If too many alarms are received from a safety system, operators may become distracted and may not understand the potential for catastrophe. In some cases, those operators may disable key systems to reduce the number of nuisance alarms. Nuisance alarms must be considered in implementing hazard controls.
Transportation Safety Board of Canada, “Runway Incursion, NAV CANADA Calgary Tower, Calgary International Airport, Alberta, 02 March 2010,” Report Number A10W0040, October 21, 2010.
Ship Accident in New Zealand
On February 19, 2009, the crew of the passenger ship Oceanic Discoverer was conducting an emergency fire response drill when the chief engineer was trapped by a watertight door and died. The ship was in the New Zealand port of Napier at the time of the accident. The watertight doors were used to restrict flooding and reduce the risk of the ship sinking if one compartment was breached. The Transport Accident Investigation Commission of New Zealand investigated the accident and reported that the chief engineer likely tried to pass through the door when it was not fully opened, and the door automatically closed and trapped him. The watertight door had two modes of operation, local-control mode and remote-close mode. In local-control mode the door opened and closed manually, while in remote-control mode the door automatically closed when the user released the opening handle. The remote-control mode was only used for testing and actual emergencies. The report stated that, “The procedures for operating the watertight doors were the same for both modes of operation, even though the remote-close mode carried a much greater risk.” The accident report also noted that the door had been set to close in about 9 seconds, when the requirement set by the International Convention for the Safety of Life at Sea stated that the door should close no faster than 20 seconds. In addition, the audible alarm that warned that the door was closing was not working at the time of the accident. Also, the manufacturer of the watertight door had recommended weekly functional tests to check the closing time, but there was no evidence that these tests had been performed.
Lessons Learned: New hazards can be introduced in the verification process if the condition of the system is not properly understood. For example, the power could still be supplied to a control panel that is being serviced, creating a shock hazard to personnel performing maintenance. Testing can cause an unexpected change in the operational configuration or can stress a component leading to failures later. Hazards associated with testing, including those associated with emergency response equipment, should be analyzed. Organizations should perform test readiness reviews for complex systems. Test readiness reviews assure that systems are indeed ready for testing and that the system being verified is of the proper configuration and safe for operation.
Transport Accident Investigation Commission (New Zealand), “Passenger vessel Oceanic Discoverer Fatal injury, Port of Napier, 19 February 2009”, Marine Inquiry 09-202, November 2011.
Pipeline Failure in Maryland
On April 7, 2000, a pipeline failure occurred at the Chalk Point Generating Station in Maryland. The pipeline, owned by Potomac Electric Power Company, released approximately 140,400 gallons of fuel oil into surrounding wetlands, Swanson Creek, and the Patuxent River. The cost of the environmental response and cleanup exceeded $71 million. The National Transportation Safety Board (NTSB) determined that the probable cause of the accident was a fracture in a buckle in the pipe. The buckle went undiscovered because data from an in-line inspection tool were interpreted incorrectly. The NTSB stated that a contributor to the severity of the accident was inadequate operating procedures and practices for monitoring the magnitude of flow through the pipeline. When the leak occurred the 12-inch-diameter pipeline was being cleaned. The existing automated pipeline monitoring system could not adequately monitor pipeline conditions during this operation because the locations of the meters, pressure-sensing points, and temperature-sensing points were not in the direct liquid flow path. Therefore, the automated system did not provide alarms or other information to operations personnel. Field personnel manually recorded tank level measurements at the upstream and downstream points, but did not use this information to evaluate whether any fuel oil had been lost. The manual monitoring procedures and lack of alarms from the automated system led to a 7-hour delay in responding to the leak. The field personnel finally realized there was a problem when the fuel pump began to cavitate. Using hand calculations the crew then realized that they had not received over 3000 barrels of fuel oil and they shut the pipeline down. Following the accident the company installed a Supervisory Control and Data Acquisition (SCADA) system with software-based leak detection and radar tank gauges.
Lessons Learned: Strong hazard control design follows the design order of precedence, where the first approach is to try to design out the hazard or minimize the risks through design selection. Procedures alone may be insufficient to reduce the risk of an accident. Procedures may not properly identify the limits of safe operation for the operator, and procedures may not include all potentially hazardous scenarios. In addition, those procedures may be poorly written, and may make things worse by overwhelming the operator in a crisis situation. Also, without proper training the operator may not understand the purpose behind the procedure and therefore may make a poor decision in an emergency situation. A system that relies only on procedures to control hazards is likely not an inherently safe system.
U.S. National Transportation Safety Board, “Rupture of Piney Point Oil Pipeline and Release of Fuel Oil Near Chalk Point, Maryland, April 7, 2000,” Pipeline Accident Report NTSB/PAR-02/01, July 23, 2002.