Using simulations in accident investigations
Board Member, Transportation Safety Board
Kongsberg Users’ Conference
St. John’s, Newfoundland and Labrador
18 September 2012
Check against delivery
Download the slide presentation (Powerpoint format, 94 Mb)
Speaking notes for the presentation
Slide 1: Title page
Slide 2: Outline
Slide 3: About the TSB
The Transportation Safety Board was formed in 1990 with the passing of the Canadian Transportation Accident Investigation and Safety Board Act. We conduct independent, expert investigations of selected marine, pipeline, rail and air occurrences.
A transportation occurrence can be an incident or accident. Incidents generally involve events such as engine failures or risks of collisions, whereas accidents are more serious, involving serious injury, loss of life or significant equipment damage. The reportable types of occurrences are defined for each transportation mode in the Transportation Safety Board Regulations.
We have approximately 230 employees across the country. The Board currently consists of 5 Board Members, including the Chair.
Slide 4: TSB Mandate
The TSB's mandate is to advance transportation safety in the air, marine, rail and pipeline modes of transportation. We are not a court, and we do not assign fault or determine civil or criminal liability. We aren't a regulator, and we don't have powers of enforcement. Neither do we investigate military or criminal occurrences.
Slide 5: TSB Offices
The TSB has its head offices in Gatineau, Quebec. We also have eight regional offices across the country—from Vancouver to Halifax—as well as an engineering laboratory just outside the Ottawa airport. It's at “the lab” that the majority of our simulation work is carried out, which I will describe shortly.
Slide 6: TSB Methodology
The TSB receives notice of thousands of occurrences each year, incidents and accidents. After an initial assessment, the decision to investigate is based on the potential to advance transportation safety—on what we feel we can learn, whether it's new, and what the risk is to the Canadian transportation system. In 2011&2012, we began 60 new investigations over the four modes: marine, pipeline, rail, and aviation.
During an investigation, TSB investigators identify safety issues by assessing the technical, operational and human factors related to an occurrence. They then determine the unsafe acts and conditions, as well as any other underlying factors that might have an influence on safety. From there, they assess the risks and analyze the defences in place, as well as any other existing risk-control options.
One of our goals is to get safety critical information to all stakeholders as soon as possible. That includes industry change agents, regulators, and the Canadian public. We use multiple types of communications to do this (in addition to news releases and face to face meetings or phone calls).
Safety Advisories and Safety Information Letters are one method to notify the industry and regulators. The Board can also issue safety concerns. The Board reserves its formal recommendations to handle the more difficult, systemic issues.
Slide 7: Advantages of Simulation Software
Since 1997, the TSB has used navigational software to help investigators ensure credibility in determining causes and contributing factors. The TSB has worked closely with some manufacturers and has custom fit this software in order to address specific needs. TSB-Marine, joined by other investigative agencies, has encouraged manufacturers of Voyage Data Recorders, through the IEC Working Groups and during IMO NAV Committees (IMO Circ.246), to agree to allow their proprietary format to be read by the upcoming TSB investigative playback software and other tools to analyze recorded data to further the assessment of causes leading to marine accidents.
Our contribution to the development of such software came from our interest in providing the manufacturer with specifications that would serve our unique purposes in order to play back navigation and communication data in real-time to further our assessments of occurrence. The opportunity of using such technology to our advantage, in order to enhance safety in transportation, was envisioned by the marine staff and the development of this tool quickly came to fruition.
Slide 8: Types of Simulations
At the TSB, we use different types of simulations. We have in-house capability to do animations, simulations and modelling. For a full-motion simulation, we would turn to a third party.
Let me give you a Marine example of modelling.
Mathematical modeling of ships—or of aircraft and train dynamics—can greatly assist an investigation.
Supported by our naval architects, we can produce an exact replica of vessels involved in marine accidents. The work also involves a great deal of testing to ensure that models are accurate as per the actual ship's performance characteristics.
Slide 10: Models (continued)
The “Virtual Shipyard” (which is a feature of Transas) software is the result of many years of research carried out by a leading group of naval architects and hydrodynamicists.
When a math model is completed, it is validated using a FMBS to conduct sea trials with the participation of knowledgeable Masters, officers, pilots, Naval Architects.
Our library of ship models is fairly large and comprise of vessels of different tonnage, dimension and hull forms, including container ships, tankers, gas carriers, fishing vessels, passenger ships, ferries and last but not least LNG/LPG vessels that will be trading in Canada in the coming years.
Slide 11: Building 3-D Environments
The user selects an area from a vector chart portfolio and sets the coastline configuration to ensure accuracy of the spatial area being built.
The result of this is …
Slide 12: 3-D Environments (continued)
Here is a polygonal terrain model that was built automatically from chart data.
When we put it all together, we can show some very detailed work.
Slide 13: Example #1: Queen of the North
On the night of March 22, 2006, the passenger and vehicle ferry Queen of the North struck the northeast side of Gil Island, BC. The vessel sustained extensive damage to its hull, lost its propulsion, and drifted for about 1 hour and 17 minutes before it sank in 430 m of water. On board were 59 passengers and 42 crew members, not all of whom abandoned the vessel before it sank. Two passengers were unaccounted for after the abandonment and have since been declared dead.
The presentation you're about to see includes actual audio from that night.
The TSB's investigation was able to recover the hard drive from a computer on the bridge, and we were able to recreate the vessel's track. This was invaluable in helping us determine what happened, on a minute-by-minute basis, comparing witness statements against the ship's own data.
Slide 14: When is it Useful? Always
At the TSB, the use of simulations closely follows our investigation process, playing a role at each stage. In the early days, when we're still out in the field, collecting evidence and gathering facts, we want to know what happened. Later, in the analysis phase, we begin testing hypotheses in order to rule out competing ones. We also use it to help validate ideas within a team and with external stakeholders. Once the report is written, we need to communicate the content to the Canadian public. A picture may be worth 1000 words, but a video simulation is worth a thousand pictures.
Let's look at these aspects individually.
Slide 15: Reconstruction (What happened?)
As we collect information, we determine what happened. Reconstruction allows us to develop an accurate representation of the accident scenario—for example, using a Flight Data Recording or an electronic chart system data to recreate the course of a vehicle.
This can be supplemented with additional information from various sources such as: voice and video recordings, site survey, witness statements, photography, and video for photogrammetry, etc.
Non-volatile memory is another area of technology that is becoming more common in systems, and thus more useful to us.
We've seen the Queen of the North. Now let's look at an aviation example.
Slide 16: Example #2: Cougar Flight 91
On the 12th of March, 2009, 18 people boarded a Sikorsky S-92 helicopter bound for the oil rigs of the North Atlantic. At 9:45 local, twenty-eight minutes after takeoff, the crew of Flight 91 suddenly became aware they had trouble when a red warning message appeared in the cockpit, indicating low oil pressure in the main gearbox. What the crew didn't know was that two of the three main gearbox filter bowl mounting studs had broken.
When they broke, the oil in the main gearbox escaped rapidly. Without enough oil, the gears began to overheat and this led eventually to the failure of the gear driving the tail rotor. Shortly after it failed, Flight 91 crashed into the Atlantic – just 11 minutes after the first indication of trouble.
Here we have the aircraft en route at 9000 ft. Then the crew got a MGB warning indicating they had a loss of oil and the animation shows a close up of this. The first warning was followed approximately 25 seconds later by a secondary indication of trouble, when the oil pressure dropped below 5 psi.
The crew turned around and began to descend.
As they descended, the crew transmitted a Mayday and began working through the emergency procedure.
We are now going to jump ahead to the helicopter established in level flight at 800ft with the crew heading back towards St. John's.
Suddenly, something dramatic happened that triggered the crew to decide to ditch and the Flight Data Recorder to shut down. We were able to collect additional data from other onboard systems which allowed us to further our understanding of the event.
The crew advised ATC that they were ditching and gave the ditching command to the passengers.
The aircraft was under control at first; however, the tail rotor failed when the gears controlling it began to break down.
You can see the tail rotor pinion and the stripped gears on the left.
The crew had no option but to shut the engines down and begin an emergency power off landing.
Data collection stopped at 90 ft with a 2300ft/min rate of descent. From this height, the helicopter fell to a severe impact with the surface.
The impact disabled the Emergency Flotation System, and the helicopter sank quickly.
Slide 17: Hypothesis Testing
Once we've established what happened, we need to understand why. It is here that simulations can help us test hypotheses, related to specific areas of interest. We have, for example, used a full-motion aviation simulator to look at the workload implications of a new technology, such as HUDs, or Heads-Up Displays.
Simulation also helps address questions such as what crew members saw in terms of instrumentation such as controls and displays. Or what they saw in terms of visual clues, both internal (displays such as radar, ECS, etc) and external.
Simulation can also be an extremely valuable tool in testing “what if” questions, specifically with respect to any impediments to the field of view. A good example is the Brockville rail occurrence, which is coming up shortly. Simulation there allowed our investigators to examine the occurrence from various perspectives. This helped us visualize the impact of design changes on visibility.
Slide 18: Example # 3 Crossing Accident (Brockville, ON, 2005)
On February 17, 2005, a young girl lost her life and a second person received serious injuries while crossing double railway tracks near their school. The TSB determined that the two pedestrians stepped into the path of the eastward train while likely preoccupied with the passing of the westward train and their conversation. This type of accident is termed a “second-train collision.” The TSB report shows that the proportion of this type of accident is increasing. The outcome of one of these accidents almost invariably results in a fatality. Without a pedestrian safety-specific intervention at multi-track crossings, the outcomes are not likely to change. Second train accidents are continuing, and children are especially at risk when faced with that deficiency.
Slide 19: Example #4 Brockville (continued)
Here is the same accident, but with one of the buildings removed, to demonstrate both a different point of view and a “what-if” scenario: What if the building wasn't there? What would people have seen?
Would the two pedestrians have seen the second train? Our investigation concluded that, yes, they likely would have.
You see that this presents a very compelling argument regarding design of crossings and location of right of way buildings.
Slide 20: Achieving a Common Understanding
A simulation can also help validate contributory factors with internal and external stakeholders. This is particularly true when an investigation hinges on technical elements that may be better understood visually.
The next slide will help demonstrate this.
Slide 21: Example # 5 Sea Urchin (2006)
In May 2006, while at anchor in the Bay of Sept Iles, Quebec, a lifeboat drill was carried out on board the bulk carrier Sea Urchin. During the recovery of the starboard lifeboat with five persons on board, the after release gear mechanism opened. The forward mechanism was unable to take the resulting load and it also opened. The lifeboat fell, stern first from a height of 11 m, into the sea. As a result, one of the five crew members was fatally injured.
What you are looking at here is an animation of the lifeboat's release-gear mechanism.
Aspects of this presentation were shown to the manufacturer, the P&I Club Representative, and the classification society. A copy was also sent to the regulator (TC), along with a safety letter
Slide 22: Example # 6 Concordia (2010)
Achieving a common understanding isn't only important for manufacturers or change agents. It's also vital when we deal with the Canadian public, many of whom may have little technical background. It's in our mandate that we have to report publically, and animations can be very helpful in helping the public visualize the accident scenario.
What follows are two examples where the animation made it explicit what happened, and what the issues were. With respect to the first example I'll show you, we were able to incorporate animation, video, and photographs from the occurrence. This was built by our experts at the TSB engineering branch (lab), using several different types of software.
On the afternoon of February 17, 2010, the sail-training yacht Concordia was knocked down and capsized after encountering a squall off the coast of Brazil. All 64 crew, faculty, and students abandoned the vessel into liferafts. They were rescued 2 days later by 2 merchant vessels and taken to Rio de Janeiro, Brazil.
You'll see that the simulation we developed for this investigation was useful at all stages of the investigation: It helped us determine what happened, as well as why—validating hypotheses—and also to communicate the results to stakeholders.
Slide 23: Example # 7 Mallorytown (2008)
Here is the second example.
On 15 July 2008, a passenger train derailed on the busy railway corridor between Toronto, Ontario, and Montréal, Quebec, after striking a loaded tractor-trailer immobilized at a crossing in Mallorytown, Ontario. The low ground clearance trailer and the equipment it was carrying were destroyed. The truck driver escaped unharmed. The operating locomotive engineer and four train passengers had minor injuries
Note that the animation includes both photographs and height measurements to clearly communicate the issue.
Slide 24: Summary
We're using simulations more and more. They enhance witness statements and allow us to test or validate these statements. They also let us test/validate scenarios (what we think we know), and help us better communicate ideas to stakeholders and the Canadian public.
Slide 25: END
- Date modified: