Learning from Accident Investigations: CAST Accident Analysis (Safety Critical Systems Club)

Learning from Accident Investigations: CAST Accident Analysis (Safety Critical Systems Club)



there we go excellent hello everybody so when my name is Simon Whitely I'm a system safety engineering consultant I work as a system safety engineer across all parts of the engineering product project lifecycle across a variety of industries primarily civil and defense aerospace so large multi engine aircraft fast jets and helicopters some air traffic control weapon systems defense maritime defense nuclear armored automotive healthcare and government IT rail and pharmaceuticals and then developing into unmanned air systems autonomous vehicles and cyber security so there's a lot of there but mainly aerospace and defense but being a contractor for so long gave me the opportunity to basically pick and choose the type of projects that I was interested in and that I wanted to work on and that's given me quite a unique view across the design and engineering lifecycle across a different of industries so there are a lot of common issues with healthcare and engineering and it's just good to be able to get that perspective now I offer consulting training and coaching primarily at the moment in the use of the stamp based safety assessment methods across the whole lifecycle but predominantly accidents an incident investigation which is what I'm going to talk about today I'm also keen volunteer and I've recently celebrated 10 years volunteering at the Royal International Air Tattoo so what Andy was saying nearly runs you know put a bit of a shiver down my spine but today you've got some basic objectives of this presentation number one is to exercise your mind as the saying goes minds are like parachutes they only work if they're open I'd like to spawn some new ideas in your minds I'd like to provide an overview of this topic and it also you know need to highlight that we haven't got that much time there's a lot to get through so we're not going to be solving the case study today so I'd like to after this presentation I'd like you to be able to recognize what is meant by stamp and what is meant by a cast analysis I'd also like you to appreciate the core process of a cast accident analysis and also appreciate how to apply the cast accident analysis approach as part of an accident an hour that you do yourself so there's some quite lofty goals and as I said there is a lot to get through so we're going to be going through this at quite a rate so to give you a bit of context then so hands up who's familiar with the diffusion of innovation curve does that mean that he says a few people they're not so many ok I'll go through that so essentially the diffusion of innovation is a theory of how why and how fast new ideas and technology spread and the reason I'm highlighting this is because I need to put stamp and the cast accident analysis into context so we are at the very early days of this approach being developed in academia starting to be used in industry you know it's early days and the usage of these approaches is predominantly imp right in private behind closed doors and that's for two main reasons the first is when you talk in matters of safety if you start to see if you start to use a new approach and find issues you don't really want to air your dirty washing so you're not going to publish papers and talk about it in public but also the use of this approach provides a significant competitive advantage and so those organizations particularly in automotive and defense that are using this they're sort of keeping storm about it and also the adoption maturity varies across different industries in different countries now stamp originates from the United States so naturally US companies us academics u.s. industry are really leading with this and essentially what I'm trying to do is get stamp from academia put it into the mainstream and help people to start to take advantage of it because the longer it's spends in this early innovators stage you know the more accidents they're going to be more expense you know I want to give people an advantage there now over the last few years I've been doing various webinars various training presentations and I've had interest in usage from people across the globe from over 22 different countries 17 different industries or domains and the domains that I've highlighted in green there just to highlight there the industries that are really embracing this and really pushing forward experimenting with it and learning with it and particularly accidents an incident investigation which we're going to focus on today so why do we need stamp and what is meant by stamp I've not actually said what that is yet is it can I have a show of hands for anybody who knows what stamp is not many okay you do come on get you hand up okay so II why do we need stamp well this is just a news clipping from a guardian newspaper with regards to a 737 aircraft that was taken off from Belfast and the aircraft essentially struggled to climb and if the terrain around the airfield had been more severe this would have resulted in a catastrophic outcome now you'll notice that this sort of tagline is entry of wrong temperature into the computer so surely you know entering some temperature data in the computer shouldn't result in an accident or should it you know so that sort of sparks the interest there in terms of the system designs software complexity you know there's no real human error associated with this you might say then this is another accident it might be familiar with this one this is rated as being where is it on the article it's a widely believed to be the first fatal collision involving an autonomous vehicle now essentially in this accident this vehicle was being driven autonomously and it had a safety driver the safety driver was you know watching Netflix or something on their phone while the vehicle was doing what it was doing and the vehicle itself there was no strict technical failures the vehicle knew that there was a pedestrian they classified what they were but the vehicle didn't take action they actually did not stop the car and because the safety driver for want of a better description was not looking out the window TechEd the threat in time and avoid the accident this is another accident this is the Boeing the first Boeing 737 max accident you know there's mention of air speed problems mentions of repairs that have been done mentions of new features on the aircraft that have not been made made aware of the aircrew and then also later on there's questions about the engineering and regulatory complications differences of opinion between the federal and company safety experts you know so there are issues all over the place this wasn't just a simple technical accident due to bird strike or whatever it is this is a very complex accident so there are challenges with regards to the you know with this situation and that is that there is an increased speed of technical innovation and the need to be first especially in the case of the 737 I mentioned a moment ago systems are becoming increasingly complex not just technical systems but also social systems contracting systems there was a mention earlier on about contracting for services in and then expecting the responsibility to go to those organizations whereas you still hold the responsibility so there are complexity increases in organizations there are increases complexity and challenges with inter dependency and interactions connectivity and then especially the human role changes from a doer to a supervisor so the example there of the self-driving car you know the driver was not the driver they were the supervisor of the automation so this is all about complexity so how do we deal with complexity well there is a traditional approach for dealing with complexity and that is that the divide and conquer approach and some of you might be familiar with analytic reduction you break the problem down into smaller parts solve those smaller parts put it back together and everything should be fine and that involves quite a few subtle but significant assumptions which are not always obvious especially to those that are not involved in design engineering so we might split the physical and functional aspects into distinct parts we might split the diff a behavior into distinct events over time so you might be familiar with chains of events and then we analyze those parts separately in combined results and as I mentioned there is some significant assumptions with that and one of those is that each part behaves independently both individually and when combined as a whole with other parts and then the parts themselves their interactions and events they're not dependent on feedback loops or nonlinear interactions and that's been mentioned a couple of times today so there is a new approach and this is the opportunity that I'm presenting and this approach is based on Systems Theory or synthesis so this is where you think about things as a whole as a larger system not breaking it down into parts but linking looking a larger bigger picture so everything is presumed to be part of a system however you so define that it includes components and interactions emergent properties and feedback loops so in terms of an example of an emergent property you might be familiar with the concept of wetness in the water in your glasses so that's a system property if you were to zoom into that you know with a microscope and look at the molecules of h2o h2o at that level of abstraction the concept of wetness doesn't exist so if you operate in the world at the microscopic level you may never be aware of the emergent property of water that needs to be managed and this approach basically allows you to zoom out and think differently in spot opportunities so stamp a very brief overview so where does it originate well it originates from Professor Nancy Leveson and her team at the MIT in the US she wrote about in her second book engineering a safer world and Nancy's quite kindly made that book available for free as a PDF download so if you don't already have a copy there's now no excuse you can get a free PDF version of it now stamp itself is an acronym and it refers to two core things it refers to what's called an accident causality model which is systems theoretic accident model and that's based on systems thinking systems theory and control theory concepts there's a lot of theory there but just bear with me and then some processes built on built on that accident causality model and these are a set of analysis and design processes now you might be asking well what is an accident causality model but I'm pretty sure a show of hands who's familiar with Swiss cheese dominoes chains and all of that good stuff so that is an accident causality model and that essentially defines how you you know think about how accidents could occur and that model implicit as it might be underpins efforts to think about discuss manage an engineer for safety but also it underpins the way you approach an investigation and what you look for and it's often not explicit or documented so everyone has one embedded in their mind and model and this presentation is obviously intended to update your mental model now you'll notice I've used fact I'll say just now I've used square brackets throughout this presentation to highlight that I'm talking about specific concepts so we're using the same English words but I need to differentiate between the English words that you'll see in other safety analyses and papers from this because there are slightly different concepts that I need to highlight now the traditional view of accident causality the realm of Swiss cheese dominoes and bowties is that accidents are caused by or due to a chain of directly related events or due to breach barriers hands up if that sounds like sounds familiar okay a few nods for you great excellent okay and it essentially defines safety as a management of failures problem so in principle if you prevent you prevent accidents by identifying and preventing failures or managing their consequences now contrary sort of built beyond that further beyond that using the Systems Theory systems thinking approach and control theory the stamp view introduces control loops and structures so instead of thinking about Swiss cheese Domino's and both Domino's and bowties we start to think about control loops and structures so essentially accidents are defined as involving complex dynamic processes and it defines safety as a dynamic control problem and to prevent accidents you essentially enforce constraints on system behavior and interactions among system components using the control structure now there's a lot of words there a lot of them are quite technical and I've put some square brackets in there and this is just a highlight that the language used here that the vocabulary is born of the control theory and sorry control engineering and systems engineering and so it's necessary to use that language to be precise about the things the concepts that we're talking about and I'll talk a little bit more about that in a moment so the traditional view for complex systems it doesn't really deal with indirect or nonlinear interactions and complexity amongst system components and parts yes bear with me there's a lot of words there it's a you know it's very specific engineering it doesn't particularly deal with human behavior and human factors software and complex hardware system design errors requirements errors or no failure accidents system behaved as design which the the autonomous vehicle accident is an example of and then also systemic factors that affect all components barriers layers of protection so in this stamp caused the accident causality model is based upon systems theory and control theory and it introduces concepts of systems components and interactions structure hierarchy control and feedback loops emergent properties and constraints and it's the same basis as the systems engineering discipline that's used to design complex systems aircraft weapons and all of that good stuff and it covers the traditional view inadequacies really well especially know failure system behaved as designed accidents and also where new technology and designs with no historical pedigree exist so things like autonomous vehicles and perhaps artificial intelligence now how do we actually prevent accidents then so we enforce constraints on system behavior and interactions and we do that with a control structure now a control structure is made up of these this basic concept of a control loop does this look familiar to everybody or should I go into that in any sort of detail ok so essentially you have some form of concert control process which is under the control of a controller and it controls and forces constraints on this process through some form of control actions it receives feedback about that process which updates a process model and the control algorithm essentially defines how that controller behaves provides control actions based on the feedback that it receives now in terms of accident investigation or safety analysis we're particularly interested in instances of what are called unsafe control actions or in accident investigation what you might call contributory control actions so as part of the analysis we look for these control loops and then we look for instances of these unsafe control actions now there are four general types of control actions one is that a control action required for safety is not provided so they don't do something an unsafe control action is provided so they do something that results in a negative outcome a potential safe control action is provided too early or too late at the wrong time so timing in sequence and then the fourth is essentially to do with duration too long or too short mmm and we can look at reasons why that unsafe control action contributory control action can occur and that could be due to issues with feedback such as feedback delays or loss of feedback no feedback in terms of a process or mental model that is out of sequence or not updated there was a mention there about the explosive potential of fuels earlier on the mental model of those operators was clearly deficient because they didn't recognize the potential threat from explosions and then in terms of control algorithms so that will be about their behavior so they may have recognized the threat from the you know the fuel but they didn't have the behaviors to actually do something about it they didn't know what to do perhaps once you've identified your unsafe control actions you essentially walk around work around this control loop to understand what all the contributors causal scenarios are that led to those unsafe control actions those contributory control actions and then essentially those control loops are formed in some form of hierarchical control structure so this is a model of your social technical system this could be a physical process this could be an autonomous controller this could be a human frontline operator and this could be their management and this is just a basic control structure model now you in terms of your control structure models one of the things that really makes the stamp based approaches stand out so powerful is as part of the analysis you create your control structure model because they are model-based analysis approaches and thinking in terms of control structures it helps to organize your thinking and understanding about the accident you're investigating but it also provides a natural path to follow a structure to work to and if you're working as part of an investigation team when you our team come together to create this model it helps form a common mental model amongst the team members so that they're all talking about the same thing and not their interpretation of it if that makes sense and for me this is one of the real key things that make the stamp based assessment so powerful now this is an example of a control structure model which is from the Tenerife disaster and it's very very straight forward but it contains a lot of valuable information so along the bottom here we've got the physical process which was the trajectory interactions between two aircraft trajectories so this aircraft and this aircraft were on the same runway at the same time it was a very foggy day so they couldn't visually see each other the visual feedback loop was broken and they were completely reliant on the radio equipment talking with the air-traffic controller and then of course if you're familiar with this accident the mental model of the career over here was that they had clearance to take off and that the runway was clear so this aircraft was not in conflict and they believed that they'd received clearance to take off so they took off and then these aircraft collided and lots of people died and this is an ad this is a more developed version of this control structure model so all I've done is taken this part of the model and blown it up and included the aircrew the aircraft so on this aircraft there was a captain first officer and a flight engineer this was the late 70s and they worked together to control the aircraft to ensure that it operated safely and now you'll notice that this is technology but these are humans but they're treated the same in the control structure model so this approach includes humans hardware software all together in one approach and this is an example from the Hawaii ballistic missile alert that went out last year this is just a whiteboard drawing was it last year maybe it was a year before he was a quiet it was a while ago now but essentially this individual who issued the alert they their mental model was this is a real alert I've got to do this because on the morning of the incident they'd switch switched over between the two shifts and the outgoing shift decided they'd play a player drill on the in come in shift and so somebody rang up on the official Batphone in the middle of the room and said you know this is an exercise and then proceeded to read the real attack message that said this is not a drill so this individual is suddenly all right hang on and that's the end of the story so and this is another control structure model this is for an unmanned air system mister for a Watchkeeper system there was an app there's been a couple of accidents for very similar reasons I was able to model the air vehicle itself and the ground station with the mission commander and pilot including their procedures and then also the manufacturers in there and this was able to highlight issues with the laser our laser altimeter and pseudo weight on Wheels algorithm so when you do control structure modeling it's essentially like building a jigsaw puzzle so when you go and do your investigation you're looking for the jigsaw pieces you're looking for those control loops and you're trying to arrange them in a hierarchy control structure hierarchy to try and understand what the system was at the time the accident occurred but you might be familiar with this chap he's a world famous statistician called Georgie p-box and he said all models are wrong but some are useful and I'm sure you must have heard that loads of times as well so what are the stamp basted processes so there are currently four stamp based processes there is the STP a hazard analysis approach which is used during system design you could use it during accident recommendations if you wanted to but I won't touch on that today cast accident analysis which we'll talk about today Stecker which is systems theoretic early concept analysis and then STP a sec which is systems theoretic process analysis security this one is focused on cybersecurity now fundamentally all four of these processes are based upon the same principles and they are very similar in reality but in terms of caste accent analysis that's what we're going to talk about today so a very brief overview on this then so as part of an accident investigation process a very generic accident investigation process you will do some observation you will document some information some evidence and then you'll form a plan as to how you want to execute your investigation what type of resources you need what type of team members you need and all of that good stuff now as part of that you will generate some facts you will do some analysis you'll document some findings you'll form some conclusions and you'll make some recommendations now it's really clear I want to make it really clear that caste accident analysis fits in this sort of phase so Donna showed a really great picture and she highlighted the analysis the root cause analysis part this is the same so Cass could fit in that slot now you could use when you get more practice with caste you could actually use it to steer the plan of your investigation because you may have some initial reports that indicate certain parts of the control structure were contributing to the accident so you could use that information to steer your plan and as I mentioned earlier you could use SCP a hazard analysis to help you design more effective recommendations but we're going to focus on caste now if you imagine hypothetically all possible causes of accidents they will be due to some form of unsafe or contributory control action from the control loop and they will be due to a number of causal scenarios now if an accident occurs it won't be due to all of these unsafe contributor control actions it will be due to some specific ones and your investigation purpose is to go and find what they are what the causal scenarios were and that's what caste focuses on those specific contributory control actions and causal scenarios now because of the systematic nature of caste accident analysis you may also find other causes of the same accident that didn't occur on this occasion or you might find other causes of other accidents which you now have the opportunity to potentially fix mm-hmm okay so the case study itself mid-air collision uber link in a quick show of hands who are familiar with this particular accident so a number of people okay well essentially what I did is I took the single source of information the official investigation report I reviewed that report and then I applied the caste accident analysis process to it to see what other learning we could get from the report and so on the day this occurred over a Burlington Lake Constance in Germany in 2002 was 21:35 local time so it was dark clear skies 10 kilometers visibility and it involved two aircraft which was a Boeing 757 and a tupolev tu-154m now essentially the two aircraft collided in flight which resulted in total loss of the aircraft 71 people were killed including a lot of children and then there was damage to fields and foresters forests the various impact sites now in this particular accident the story goes even worse because the actual air traffic controller involved in this accident was subject to a revenge killing of one of the Russian fathers of some children and he was subject to a prison sentence so this is just an overview of the trajectories of the two aircraft so this is the 757 this is the top left – you form five four and this is the collision angle essentially they flew into each other so just quickly the timeline then so at twenty one thirty three and three seconds two minutes 29 minutes before the collision there was a start of a conversation on the top level craft about a teak a Syndication so the crew on that aircraft were aware that there was an intruder in aircraft and they were talking about it and thinking about what they might do a few seconds later or a minute or so later the tea cast system alerted both crews on both flight decks that there was traffic so from a mental model perspective both aircrew knew that there was some traffic that was potentially a threat and then at 43 seconds before the collision the radar control of the air traffic controller instructed the crew of the top alev to essentially descend so they did what the controller said and started to descend they initiated a descent and then as they started to initiate the descent two seconds later the tea caste system issued what's called a resolution advisory which is essentially you need to pull up or descend very rapidly so the aircraft is 757 they received a descent command whereas the tupolev crew received a climb command which was in contravention to what they had already been told by the air traffic controller so these guys on this side they did what they're supposed to do the guys on this side well they did what they thought they were supposed to do because they will work into their training which in the Russian Republic at the time was due what the air traffic controller says whereas the the priority of T Cass was not highlighted so they continued descending no matter what T Cass was saying and they continued to continued descending this crew continued descending so they both basically descended each other into each other and collided so that's that's that's the sort of background to the case study so in terms of caste accident analysis ultimate goal so when you do caste what you're trying to do is you're trying to identify what was the control structure that existed to enforce what are called high level safety constraints and I'll talk about that in a second and then establish how and why each level of that control structure essentially allowed or contributed to inadequate control at that level and you'll notice I've not used the word failure anywhere in there because as I said at the very beginning this is not just about failures this is about dangerous successes you might want to call it and they may recommend date recommendations so what changes to the control structure is necessary so that those high-level safety constraints can be enforced and that's if they can because there may be instances when you do an investigation where the system has presented cannot enforce those constraints so in terms of the accident analysis process cast this is basically on one page so you document the losses you identify the Associated hazards the high level safety constraints associated with those hazards you do some modeling so the timeline you saw a minute ago and then you control structure model and then you do the analysis and there's three parts to that you analyze the physical process then the control structure components and then the excuse me structure of that control structure ok so definition of a hazard what is a hazard so I've got my square brackets out and it's now in purple so it's really important to highlight this so hands up who is used or heard of the hazard word hazard before probably uses it on a daily basis probably has lots of arguments and fights with people about it right ok great all I'm saying here is when we're talking about the stamp based approach when we're talking about hazards we're talking about this definition which is specific and it is more constrained more narrow than the typical definition of a hazard everybody uses elsewhere so when we talk about hazard usually it is anything that has the potential to cause an accident well that's a very broad very broad concept so how do we sort of narrow that and bring it within the realm of our our control the designers control so we talk about a system state or set of conditions that together with a particular set of worst-case environmental conditions will lead to an accident so when people talk about a mountain range in terms of air traffic people might say the mountain range is a hazard whereas under this definition the mountain range is a mountain range it's not a hazard it only becomes a hazard in combination with some air traffic and only then if they are in a conflict in trajectory does that make sense yeah excellent so I just need to highlight when somebody says I'm gonna compare stamp hazard analysis or stamp based approach with other safety analysis methods just keep it in the back of your mind that the definition is different okay excellent right so in the context of this accident there were two high level hazards one is the loss of safe separation margin between aircraft in controlled airspace the second is to do with conflict in trajectories that lead to a loss of safe separation margin and so a high-level safety constraint this is basically a requirement that the whole control structure must enforce to avoid this hazard which is that the hierarchical control structure shall prevent the loss of safe separation margin between aircraft and then for the second one the control structure shall prevent conflict in trajectories so there's sort of two prime missions that that whole control structure both pilots aircraft aircraft designers air traffic controllers aircraft air traffic control service providers all of them together they have a contribution to these high-level requirements so then we get into hierarchical control structure modeling so we start with talking about the physical physical process which in this case is the trajectory of two aircraft those trajectories are under the control of an aircraft which is under the control of Kru on both sides and then they've got some tea Cass traffic collision alerting systems that interact with each other and alert the crews then we've got the air traffic control themselves and they communicate with the aircraft through radio control system they have a sector radar picture and they have some flight strips now you can expand that if you want to go to a lot of detail you know this is quite a high level abstraction so this is sufficient to do some analysis and get some great results but if you want to look at more systematic issues you can start to look much higher so this is the air traffic control system equipment itself this is the air traffic controller in their sector management suite with their supervisor you've got the technical management of the air traffic control system the technical stuff then you've got operations management organization management right up to the regulators and even to the ICAO if you want to go that far now obviously you'll notice there's no arrows or no links between these and that's because there's not enough information in the original investigation report that looks at these so that shows that perhaps the original investigators didn't go that far or that they just didn't document it in the investigation report now you'll notice this bit here and I'll talk about this a little bit more in a moment sorry I'll just highlight that so there's an air traffic controller and then there's notionally a second air traffic controller and that's important so let's do the causal analysis then so as I mentioned there are three parts physical analysis controller component and then structure analysis so the first part is to talk about the physical equipment so what was the physical equipment involved in this accident well there were basically two aircraft with flying controls traffic collision avoidance system collision beacons flashing lights etc and there was no failures with any of that all worked perfectly no technical faults whatsoever in terms of safety requirements well there were some warning requirements on the TAS and that performed as it should do so there's no failures there no physical failures but the worst some unsafe interactions and that was the trajectory of the flight path now there were no significant physical equipment or process contextual factors involved in this there were two perfectly serviceable airplanes with crews operating appropriately mm-hmm excuse me so there's no answered question there how could two perfectly serviceable aircraft crash into each other so we need to investigate that further and look at the control structure so we do that in two parts we do component analysis structure analysis as part of the component analysis we essentially want to establish these things and any extra questions that we need to look at so what are the safety related roles and responsibilities of that component so the pilots or the air traffic controller or the Technical Systems what are the control and feedback ability actuators and sensors or any failures so when I was talking about the control loop you know control actions are implemented by actuators and feedback is provided by sensors in terms of contribution control actions well we mentioned that the Russian crew descended when the air traffic controller told them to and we know that the to descend and at the same time resulted in the collision then we've got mental model and process model flaws then we've got contextual factors and then context within which decisions were made so the aircrew they decided to descend because the air traffic controller told them to do it the t caste system then told them to do something opposite but they didn't talk to the air traffic controller and say hey you know the computers telling us to do something else what do I do but in that situation there may not be enough time to actually do anything and then look at the structure analysis so structure of the control structure architecture and interactions communication and coordination dynamics and changes or evolution safety management systems safety information system and safety culture so there's a lot of things you can look at if you do this approach you can look and find a lot of different things and you can also consider work as imagined and work has done so that's quickly we've already spoken a bit about the Bosch Korean crew so their mental model was that they know that there's a conflict in traffic perhaps but they know that the air traffic controller has told them to descend so they're descending they're doing what they should do that's correct but that but in the context of their actions looking at the overall system because the DHL crew are doing the same thing that is what results in the accident so I'm going to quickly move forward there so this is a picture of the actual control suite so there are two stations two workstations one for the sector with the 757 and the top left on it and then one with another aircraft that arrives later on it's a disturbance now essentially on the day there was only one air traffic control and not two so this would be what the control structure should look like this air traffic controller looks after this airspace using this equipment and this air traffic controller looks after this airspace with this equipment but what was actually happening on the day was that this air traffic controller was essentially looking after all of it and so that might be perfectly fine on a quiet evening when there's not much traffic but if there's any disturbances or other problems then this could quickly put you in a dangerous or accident situation does that make sense everybody got that excellent so then we can talk about management well what was the mental model of the air traffic controller well in terms of this particular accident on the night this accident occurred the technical team they were actually doing some technical changes to the technical equipment and as part of that technical change they actually removed some of the telecommunications equipment so that it wasn't working at the time and so this air traffic controller here a completely different Center they were sat looking at their radar screen and they got a conflict alert that said there's two aircraft coming together but because they're outside that person's sector they were not able to do anything about it so they tried to call this air traffic controller by the phone but the phone was not available so they could not prevent the accident and at the time this accident occurred these aircraft were coming together this air traffic controller saw that there was an issue but didn't realize how significant of an issue it was and then was so happened disturbed by this other aircraft on a completely different radio frequency so you can imagine somebody sat trying to work both of these workstations moving around trying to listen to things and take action and that's just incredibly difficult for one person okay so summary we've gone through that very very quickly that's just to give you a flavor so from the official investigation report there were two immediate causes one was that there was an imminent separation infringement that was not noticed by the air traffic controller in time so that was their mental model was not updated in time the tu-154 crew followed the ATC instruction to descend and continued to do so after t Cass advised them to climb there are three systemic causes highlighted in the report one is to do with the integration of T casts into the global aviation system so in the Western world it was better integrated the pilots were trained do what T Cass says no matter what the air traffic controller says do what D Cass says whereas in Russia it was the other way around they were taught to do what the air traffic controller said a navigation service provider they did not ensure that all open ATC workstations were continuously staffed and then the air navigation service provided tolerated for years single ATCO operations so this was going on for years so final thoughts near-misses so on near misses so an accident or near miss or incident reveals that the control structure was inadequate and that's a fact some shape or form it was inadequate didn't end for safety constraints so when people talk about root causes I'm being facetious here but technically there's only one root cause and that is that the control structure was inadequate in some shape or form so there's a massive learning opportunity from near misses and incidents and they're cheap and people are more willing to speak to you when you do your investigation and give information freely you

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *