Category: Mil-Std-882E

  • Risk Assessment Standards: How to Choose and Use Them

    Risk Assessment Standards: How to Choose and Use Them

    Risk Assessment Standards: How to Choose and Use Them. The standard is the thing that we’re going to use to achieve things – the tool. And that’s important because tools designed to do certain things usually perform well. But they don’t always perform well on other things. So we will ask, ‘Are we doing the right thing?’ And ‘Are we doing it right?’

    This post is part of a series:

    Video Highlights

    Understanding Your Standard: Highlights

    Transcript

    What and Why?

    So, what will we do and why are we doing it? First, the use of safety standards is very common for many reasons. It helps us to have confidence that what we’re doing is good enough. We’ve met a standard of performance in the absolute sense. It helps us to say, ‘We’ve achieved standardization or commonality in what we’re doing’.

    We can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or different organizations. Standardization gives us some of the other benefits as well. If we’re all doing the same thing rather than we’re all doing different things, it makes it easier to train staff. This is one example of how a standard helps.

    However, we need to understand this tool that we’re going to use. What it does, what it’s designed to do, and what it is not designed to do. That’s important for any standard or any tool. In safety, it’s particularly important because safety is, in many respects, an intangible. This is because we’re always looking to prevent a future problem from occurring. In the present, it’s a little bit abstract. It’s a bit intangible. So, we need to make sure that conceptually what we’re doing makes sense and it’s coherent. That it works together. If we look at those five bullet points there, we need to understand the concept of each standard. We need to understand the basis of each one.

    They’re not all based on the same concept. Thus, some of them are contradictory or incompatible. We need to understand the design of the standard. What the standard does, what the aim of the standard is, and why it came into existence. And who brought it into existence. To do what for whom – who’s the ultimate customer here?

    For risk analysis standards, we need to understand what kind of risks they address. Because the way you treat a financial risk might be very different from a safety risk. In the world of finance, you might have a portfolio of products, like loans. These products might have some risks associated with them. One or two loans might go bad, and you might lose money on those. But as long as the whole portfolio is making money, that might be acceptable to you. You might say, ‘I’m not worried about that 10% of my loans have gone south and all gone wrong. I’m still making plenty of profit out of the other 90%.’ It doesn’t work that way with safety. You can’t say ‘It’s OK that I’ve killed a few people over here because all this a lot over here are still alive!’. It doesn’t work like that!

    Also, what kind of evidence does the standard produce? Because in safety, we are very often working in a legal framework that requires us to do certain things. It requires us to achieve a certain level of safety and prove that we have done so. So, we need certain kinds of evidence. In different jurisdictions and different industries, some evidence is acceptable. Some are not. You need to know which is for your area. And then finally, let’s think about the pros and cons of the standard. What does it do well? And what does it do not so well?

    System Safety Pedigree

    We’re going to look at a standard called Military Standard 882E. This standard was first developed several decades ago. It was created by the US government and military to help them bring into service complex, cutting-edge military equipment. Equipment that was always on the cutting edge. That pushes the limits of what you can achieve in performance.

    That’s a lot of complexity. Lots of critical weapon systems, and so forth. So they needed something that could cope with all that complexity. It’s a system safety engineering standard. It’s used by engineers, but also by many other specialists. As I said, it’s got a background in military systems. These days, you find these principles used pretty much everywhere. So, all the approaches to System Safety that 882 introduced are in other standards. They are also in other countries.

    It addresses risks to people, equipment, and the environment, as we heard earlier. And because it’s an American standard, it’s about system safety. It’s very much about identifying requirements. What do we need to happen to get safety? To do that, it produces lots of requirements. It performs analyses of all those requirements and generates further requirements. And it produces requirements for test evidence. We then need to fulfill these requirements. It’s got several important advantages and disadvantages. We’re going to discuss these in the next few slides…

    This is Module 3 of SSRAP

    ‘Understanding Your Risk Assessment Standard’ is Module 3 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.

    The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos here and order using the coupon “Pre-order-Half-Price-SSRAP”. But don’t leave it too long because there are only 100 half-price courses available!

    Meet the Author

    Learn safety engineering with me, an industry professional with 25 years of experience. I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.

  • System Safety Analysis: Methods, Tasks and Techniques

    System Safety Analysis: Methods, Tasks and Techniques

    In this ‘super post’, we will learn System Safety Analysis: Methods, Tasks and Techniques. I will show you thirteen lessons that explain each of the ten analysis tasks, the analysis process, and how to combine those tasks into a program!

    Follow the links to sample and buy lessons on individual tasks.

    Introduction

    Military Standard 882, or Mil-Std-882 for short, is one of the most widely used system-safety standards. As the name implies, this standard is used on US military systems, but it has found its way, sometimes in disguise, into many other programs around the world. It’s been around for a long time and is now in its fifth incarnation: 882E.

    Unfortunately, 882 has also been widely misunderstood and misapplied. This is probably not the fault of the standard and is just another facet of its popularity. The truth is that any standard can be applied blindly – no standard is a substitute for competent decision-making.

    In this series of posts, we will: provide awareness of this standard; explain how to use it; and discuss how to manage, tailor, and implement it. Links to each training session and to each section of the standard are provided in the following sections.


    Mil-Std-882E Training Sessions

    System Safety Process, full post here

    Photo by Bonneval Sebastien on Unsplash

    In this full-length (50 minutes) video, you will learn to:

    • Know the system safety process according to Mil-Std-882E;
    • List and order the eight elements;
    • Understand how they are applied;
    • Skilfully apply system safety using realistic processes; and
    • Feel more confident dealing with multiple standards.

    In the System Safety Process Course, we look at the general requirements of Mil-Std-882E. We cover the Applicability of the 882E tasks; the General requirements; the Process with eight elements; and the application of process theory to the real world.


    Design Your System Safety Analysis Program

    Photo by Christina Morillo from Pexels

    Learn how to Design a System Safety Program for any system in any application:

    Learning Objectives. At the end of this course, you will be able to:

    • Define what a risk analysis program is;
    • List the hazard analysis tasks that make up a program;
    • Select tasks to meet your needs; and
    • Design a tailored risk analysis program for any application.

    Analysis: 200-series Tasks

    Preliminary Hazard Identification, Task 201

    Identify Hazards.

    In this video, we find out how to create a Preliminary Hazard List, the first step in safety assessment. We look at three classic complementary techniques to identify hazards and their pros and cons. This includes all the content from Task 201, and also practical insights from my 25 years of experience with Mil-Std-882.

    You can buy the full video, plus lots of bonus material:


    Preliminary Hazard Analysis, Task 202

    See More Clearly.

    In this 45-minute session, The Safety Artisan looks at Preliminary Hazard Analysis, or PHA, which is Task 202 in Mil-Std-882E. We explore Task 202’s aim, description, scope, and contracting requirements. We also provide value-adding commentary and explain the issues with PHA – how to do it well and avoid the pitfalls.


    System Requirements Hazard Analysis, Task 203

    Law, Regulations, Codes of Practice, Guidance, Standards & Recognised Good Practice.

    In this 45-minute session, The Safety Artisan looks at Safety Requirements Hazard Analysis, or SRHA, which is Task 203 in the Mil-Std-882E standard. We explore Task 203’s aim, description, scope, and contracting requirements. SRHA is an important and complex task, which needs to be done on several levels to be successful. This video explains the issues and discusses how to perform SRHA well.


    Sub-system Hazard Analysis, Task 204

    Breaking it down to the constituent parts.

    In this video lesson, The Safety Artisan looks at Sub-System Hazard Analysis, or SSHA, which is Task 204 in Mil-Std-882E. We explore Task 204’s aim, description, scope, and contracting requirements. We also provide value-adding commentary and explain the issues with SSHA – how to do it well and avoid the pitfalls.


    System Hazard Analysis, Task 205

    Putting the pieces of the puzzle together.

    In this 45-minute session, The Safety Artisan looks at System Hazard Analysis, or SHA, which is Task 205 in Mil-Std-882E. We explore Task 205’s aim, description, scope, and contracting requirements. We also provide value-adding commentary, which explains SHA – how to use it to complement Sub-System Hazard Analysis (SSHA, Task 204) to get the maximum benefits for your System Safety Program.


    Operating and Support Hazard Analysis, Task 206

    Operate it, maintain it, supply it, dispose of it.

    In this full-length session, The Safety Artisan looks at Operating & Support Hazard Analysis, or O&SHA, which is Task 206 in Mil-Std-882E. We explore Task 205’s aim, description, scope, and contracting requirements. We also provide value-adding commentary, which explains O&SHA: how to use it with other tasks; how to apply it effectively on different products; and some of the pitfalls to avoid. We refer to other lessons for specific tools and techniques, such as Human Factors analysis methods.


    Health Hazard Analysis, Task 207

    Hazards to human health are many and various.

    In this full-length (55-minute) session, The Safety Artisan looks at Health Hazard Analysis, or HHA, which is Task 207 in Mil-Std-882E. We explore the aim, description, and contracting requirements of this complex Task, which covers: physical, chemical & biological hazards; Hazardous Materials (HAZMAT); ergonomics, aka Human Factors; the Operational Environment; and non/ionizing radiation. We outline how to implement Task 207 in compliance with Australian WHS. 


    Functional Hazard Analysis, Task 208

    Components where systemic failure dominates random failure.

    In this full-length (40-minute) session, The Safety Artisan looks at Functional Hazard Analysis, or FHA, which is Task 208 in Mil-Std-882E. FHA analyses software, complex electronic hardware, and human interactions. We explore the aim, description, and contracting requirements of this Task, and provide extensive commentary on it. 


    System-Of-Systems Hazard Analysis, Task 209

    Existing systems are often combined to create a new capability.

    In this full-length (38-minute) session, The Safety Artisan looks at Systems-of-Systems Hazard Analysis, or SoSHA, which is Task 209 in Mil-Std-882E. SoSHA analyses collections of systems, which are often put together to create a new capability, which is enabled by human brokering between the different systems. We explore the aim, description, and contracting requirements of this Task, and an extended example to illustrate SoSHA. (We refer to other lessons for special techniques for Human Factors analysis.)


    Environmental Hazard Analysis, Task 210

    Environmental requirements in the USA, UK, and Australia.

    This is the full, one-hour session on Environmental Hazard Analysis (EHA), which is Task 210 in Mil-Std-882E. We explore the aim, task description, and contracting requirements of this Task, but this is only half the video. We then look at environmental requirements in the USA, UK, and Australia, before examining how to apply EHA in detail under the Australian/international regime. This uses my practical experience of applying EHA. 

  • Sub-System Hazard Analysis with Mil-Std-882E

    Sub-System Hazard Analysis with Mil-Std-882E

    In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I’m using my long experience with this Standard to teach a pragmatic approach to getting the work done.

    Task 204 is one of three tasks that integrate tightly in a Systems Engineering framework. (The others are System Hazard Analysis, Task 205, and System of Systems Hazard Analysis, Task 209.)

    SSHA is designed to be used where a formal Sub-System Specification (SSS) has been created. However, an SSS is not essential to perform this Task. The need for SSHA is usually driven by the complexity of the system and/or that sub-system development is contracted out.

    Together, we will explore Task 204’s aim, description, scope, and contracting requirements. There’s value-adding commentary, and I explain the issues with SSHA – how to do it well and avoid the pitfalls.

    This is the seven-minute demo, the full video is 40-minutes’ long.

    Topics: Sub-System Hazard Analysis

    • Preamble: Sub-system & System HA.
    • Task 204 Purpose:
      • Verify subsystem compliance;
      • Identify (new) hazards; and
      • Recommend necessary actions.
    • Task Description (six slides);
    • Reporting;
    • Contracting; and
    • Commentary.

    Transcript: Sub-System Hazard Analysis

    Introduction

    Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial instruction on all things system safety. I’m Simon – I’m your host for today, as always and it’s the fourth of April 22. With everything that’s going on in the world, I hope that this video finds you safe and well.

    Sub-System Hazard Analysis

    Let’s move straight on to what we’re going to be doing. We’re going to be talking today about subsystem hazard analysis and this is task 204 under the military standard 882E. Previously we’ve done 201, which was preliminary hazard identification, 202, which is preliminary hazard analysis, and 203, which is safety requirements hazard analysis. And with task 204 and task 205, which is system has analysis, we’re now moving into getting stuck into particular systems that we’re thinking about, whether they be physical systems or intangible. We’re thinking about the system under consideration and I’m really getting into that analysis.

    Topics for this Session

    So, the topics that we’re going to cover today, I’ve got a little preamble to set things in perspective. We then get into the three purposes of task 204. First, to verify compliance. Secondly, to identify new hazards. And thirdly, to recommend necessary actions. That would be recommended control measures for hazards and risks. We’ve got six slides of task description, a couple of slides on reporting, one on contracting, and then a few slides on some commentary where I put in my tuppence worth and I’ll hopefully add some value to the basic bones of the standard.

    It’s worth saying that you’ll notice that subsystem is highlighted in yellow and the reason for that is that the subsystem and system hazard analysis tasks are very, very similar. They’re identical except for certain passages and I’ve highlighted those in yellow. Normally I use a yellow highlighter to emphasize something I want to talk about. This time around, I’m using underlining for that and the yellow is showing you what these are different for subsystem analysis as opposed to system [hazard analysis]. And when you’ve watched both sessions on 204 and 205, I think you’ll see the significance of what I’ve done.

    Preamble – Sub-system & System HA

    Before we get started, we need to explain the system model that the 882 is assuming. If we look at the left-hand side of the hexagons, we’ve got our system in the center, which we’re considering. Maybe that interfaces with other systems. They work within the operating environment; hence we have the icon of the world, and the system and maybe other systems are there for a purpose. They’re performing some task; they’re doing some function and that’s indicated by the tools. We’re using the system to do something, whatever it might be.

    Then as we move to the right-hand side, the system is itself broken down into subsystems. We’ve got a couple here. We’ve got sub-systems A and B and then A further broken down into A1 and A2, for example. There’s some sort of hierarchy of subsystems that are coming together and being integrated to form the overall system. That is the overall picture that I’d like to bear in mind while we’re talking about this. The assumption in the 882, is we’re going to be looking at this subsystem hierarchy bottom upwards, largely. We’ll come on to that.

    Sub-System Hazard Analysis (T204)

    The purpose of the task, as I’ve said before, it’s threefold. We must verify subsystem compliance with requirements. Requirements to deal with risk and hazards. We must identify previously unidentified hazards that may emerge as we’re working at a lower level now. And we must recommend actions as necessary. Those are further requirements to eliminate all hazards or mitigate associated risks. We’ll keep those three things in mind and that will keep coming up.

    [Video continues…]

    End: Sub-System Hazard Analysis

    My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains: aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

    You can find a free PDF of the System Safety Engineering Standard, Mil-Std-882E, here.

  • System Hazard Analysis with Mil-Std-882E

    System Hazard Analysis with Mil-Std-882E

    In this 45-minute session, I look at System Hazard Analysis with Mil-Std-882E. SHA is Task 205 in the Standard. I explore Task 205’s aim, description, scope, and contracting requirements.

    I also provide commentary, based on working with this Standard since 1996, which explains SHA. How to use it to complement Sub-System Hazard Analysis (SSHA, Task 204). How to get the maximum benefits from your System Safety Program.

    Using Task 205 effectively is not just a matter of applying it in number order with the other Tasks. We need to use it within the Systems Engineering framework. That means using it top-down, to set requirements, and bottom-up to verify that they are met.

    This is the seven-minute-long demo. The full video is 47 minutes long.

    System Hazard Analysis: Topics

    • Task 205 Purpose [differences vs. 204];
      • Verify subsystem compliance;
      • ID hazards (subsystem interfaces and faults);
      • ID hazards (integrated system design); and
      • Recommend necessary actions.
    • Task Description (five slides);
    • Reporting;
    • Contracting; and
    • Commentary.

    Transcript: System Hazard Analysis with Mil-Std-882E

    Introduction

    Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial safety training resources and videos. I’m Simon, your host, and I’m recording this on the 13th of April 2020. And given the circumstances when I record this, I hope this finds you all well.

    System Hazard Analysis Task 205

    Let’s get on to our topic for today, which is System Hazard Analysis. Now, system hazard analysis is, as you may know, Task 205 in the Mil-Std-882E system safety standard.

    Topics for this Session

    What we’re going to cover in this session is purpose, task description, reporting, contracting, and some commentary – although I’ll be making commentary all the way through. Going back to the top, the yellow highlighting with this (and with Task 204), I’m using the yellow highlighting to indicate differences between 205 and 204 because they are superficially quite similar. And then I’m using underlining to emphasize those things that I want to bring to your attention and emphasize.

    Within Task 205, Purpose. We’ve got four purpose slides for this one. Verify subsistent compliance and recommend necessary actions – fourth one there. And then in the middle of the sandwich, we’ve got the identification of hazards, both between the subsystem interfaces and faults from the subsystem propagating upwards to the overall system and identifying hazards in the integrated system design. So, quite a different emphasis to 204, which was thinking about subsystems in isolation. We’ve got five slides of task description, a couple on reporting, one on contracting – nothing new there – and several commentaries.

    System Requirements Hazard Analysis (T205)

    Let’s get straight on with it. The purpose, as we’ve already said, there is a three-fold purpose here; Verify system compliance, hazard identification, and recommended actions, and then, as we can see in the yellow, the identifying previously unidentified hazards is split into two. Looking at subsystem interfaces and faults and the integration of the overall system design. And you can see the yellow bit, that’s different from 204 where we are taking this much higher-level view, taking an inter-subsystem view and then an integrated view.

    Task Description (T205) #1

    On to the task description. The contract has got to do it and document, as usual, looking at hazards and mitigations, or controls, in the integrated system design, including software and human interface. We must come onto that later.

    All the usual stuff about we’ve got to include COTS, GOTS, GFE, and NDI. So, even if stuff is not being developed, if we’re putting together a jigsaw system from existing pieces, we’ve still got to look at the overall thing. And as with 204, we go down to the underlined text at the bottom of the slide, areas to consider. Think about performance, and degradation of performance, functional failures, timing and design errors, defects, inadvertent functioning – that classic functional failure analysis that we’ve seen before.

    Again, while conducting this analysis, we’ve got to include human beings as an integral component of the system, receiving inputs, and initiating outputs.  Human factors were included in this standard from long ago…

    The End

    You can see all the Mil-Std-882E Analysis Tasks here.

    Get a free PDF of the System Safety Engineering Standard, Mil-Std-882E, here.

    Learn safety engineering with me, an industry professional with 25 years of experience, I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.

  • Sub-System Hazard Analysis with Mil-Std-882E

    Sub-System Hazard Analysis with Mil-Std-882E

    In this video lesson, I look at Sub-System Hazard Analysis with Mil-Std-882E (SSHA, which is Task 204). I teach the mechanics of the task, but not just that. I’m using my long experience with this Standard to teach a pragmatic approach to getting the work done.

    Task 204 is one of three tasks that integrate tightly in a Systems Engineering framework. (The others are System Hazard Analysis, Task 205, and System of Systems Hazard Analysis, Task 209.)

    SSHA is designed to be used where a formal Sub-System Specification (SSS) has been created. However, an SSS is not essential to perform this Task. The need for SSHA is usually driven by the complexity of the system and/or that sub-system development is contracted out.

    Together, we will explore Task 204’s aim, description, scope, and contracting requirements. There’s value-adding commentary, and I explain the issues with SSHA – how to do it well and avoid the pitfalls.

    This is the seven-minute demo, the full video is 40-minutes’ long.

    Topics: Sub-System Hazard Analysis

    • Preamble: Sub-system & System HA.
    • Task 204 Purpose:
      • Verify subsystem compliance;
      • Identify (new) hazards; and
      • Recommend necessary actions.
    • Task Description (six slides);
    • Reporting;
    • Contracting; and
    • Commentary.

    Transcript: Sub-System Hazard Analysis

    Introduction

    Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial instruction on all things system safety. I’m Simon – I’m your host for today, as always and it’s the fourth of April 22. With everything that’s going on in the world, I hope that this video finds you safe and well.

    Sub-System Hazard Analysis

    Let’s move straight on to what we’re going to be doing. We’re going to be talking today about subsystem hazard analysis and this is task 204 under the military standard 882E. Previously we’ve done 201, which was preliminary hazard identification, 202, which is preliminary hazard analysis, and 203, which is safety requirements hazard analysis. And with task 204 and task 205, which is system has analysis, we’re now moving into getting stuck into particular systems that we’re thinking about, whether they be physical systems or intangible. We’re thinking about the system under consideration and I’m really getting into that analysis.

    Topics for this Session

    So, the topics that we’re going to cover today, I’ve got a little preamble to set things in perspective. We then get into the three purposes of task 204. First, to verify compliance. Secondly, to identify new hazards. And thirdly, to recommend necessary actions. That would be recommended control measures for hazards and risks. We’ve got six slides of task description, a couple of slides on reporting, one on contracting, and then a few slides on some commentary where I put in my tuppence worth and I’ll hopefully add some value to the basic bones of the standard.

    It’s worth saying that you’ll notice that subsystem is highlighted in yellow and the reason for that is that the subsystem and system hazard analysis tasks are very, very similar. They’re identical except for certain passages and I’ve highlighted those in yellow. Normally I use a yellow highlighter to emphasize something I want to talk about. This time around, I’m using underlining for that and the yellow is showing you what these are different for subsystem analysis as opposed to system [hazard analysis]. And when you’ve watched both sessions on 204 and 205, I think you’ll see the significance of what I’ve done.

    Preamble – Sub-system & System HA

    Before we get started, we need to explain the system model that the 882 is assuming. If we look at the left-hand side of the hexagons, we’ve got our system in the center, which we’re considering. Maybe that interfaces with other systems. They work within the operating environment; hence we have the icon of the world, and the system and maybe other systems are there for a purpose. They’re performing some task; they’re doing some function and that’s indicated by the tools. We’re using the system to do something, whatever it might be.

    Then as we move to the right-hand side, the system is itself broken down into subsystems. We’ve got a couple here. We’ve got sub-systems A and B and then A further broken down into A1 and A2, for example. There’s some sort of hierarchy of subsystems that are coming together and being integrated to form the overall system. That is the overall picture that I’d like to bear in mind while we’re talking about this. The assumption in the 882, is we’re going to be looking at this subsystem hierarchy bottom upwards, largely. We’ll come on to that.

    Sub-System Hazard Analysis (T204)

    The purpose of the task, as I’ve said before, it’s threefold. We must verify subsystem compliance with requirements. Requirements to deal with risk and hazards. We must identify previously unidentified hazards that may emerge as we’re working at a lower level now. And we must recommend actions as necessary. Those are further requirements to eliminate all hazards or mitigate associated risks. We’ll keep those three things in mind and that will keep coming up.

    [Video continues…]

    End: Sub-System Hazard Analysis

    My name’s Simon Di Nucci. I’m a practicing system safety engineer, and I have been, for the last 25 years; I’ve worked in all kinds of domains, aircraft, ships, submarines, sensors, and command and control systems, and some work on rail air traffic management systems, and lots of software safety. So, I’ve done a lot of different things!

    You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.

  • System Hazard Analysis with Mil-Std-882E

    System Hazard Analysis with Mil-Std-882E

    In this 45-minute session, I look at System Hazard Analysis with Mil-Std-882E. SHA is Task 205 in the Standard. I explore Task 205’s aim, description, scope, and contracting requirements.

    I also provide commentary, based on working with this Standard since 1996, which explains SHA. How to use it to complement Sub-System Hazard Analysis (SSHA, Task 204). How to get the maximum benefits from your System Safety Program.

    Using Task 205 effectively is not just a matter of applying it in number order with the other Tasks. We need to use it within the Systems Engineering framework. That means using it top-down, to set requirements, and bottom-up to verify that they are met.

    This is the seven-minute-long demo. The full video is 47 minutes long.

    System Hazard Analysis: Topics

    • Task 205 Purpose [differences vs. 204];
      • Verify subsystem compliance;
      • ID hazards (subsystem interfaces and faults);
      • ID hazards (integrated system design); and
      • Recommend necessary actions.
    • Task Description (five slides);
    • Reporting;
    • Contracting; and
    • Commentary.

    Transcript: System Hazard Analysis with Mil-Std-882E

    Introduction

    Hello, everyone, and welcome to the Safety Artisan, where you will find professional, pragmatic, and impartial safety training resources and videos. I’m Simon, your host, and I’m recording this on the 13th of April 2020. And given the circumstances when I record this, I hope this finds you all well.

    System Hazard Analysis Task 205

    Let’s get on to our topic for today, which is System Hazard Analysis. Now, system hazard analysis is, as you may know, Task 205 in the Mil-Std-882E system safety standard.

    Topics for this Session

    What we’re going to cover in this session is purpose, task description, reporting, contracting, and some commentary – although I’ll be making commentary all the way through. Going back to the top, the yellow highlighting with this (and with Task 204), I’m using the yellow highlighting to indicate differences between 205 and 204 because they are superficially quite similar. And then I’m using underlining to emphasize those things that I want to bring to your attention and emphasize.

    Within Task 205, Purpose. We’ve got four purpose slides for this one. Verify subsistent compliance and recommend necessary actions – fourth one there. And then in the middle of the sandwich, we’ve got the identification of hazards, both between the subsystem interfaces and faults from the subsystem propagating upwards to the overall system and identifying hazards in the integrated system design. So, quite a different emphasis to 204, which was thinking about subsystems in isolation. We’ve got five slides of task description, a couple on reporting, one on contracting – nothing new there – and several commentaries.

    System Requirements Hazard Analysis (T205)

    Let’s get straight on with it. The purpose, as we’ve already said, there is a three-fold purpose here; Verify system compliance, hazard identification, and recommended actions, and then, as we can see in the yellow, the identifying previously unidentified hazards is split into two. Looking at subsystem interfaces and faults and the integration of the overall system design. And you can see the yellow bit, that’s different from 204 where we are taking this much higher-level view, taking an inter-subsystem view and then an integrated view.

    Task Description (T205) #1

    On to the task description. The contract has got to do it and document, as usual, looking at hazards and mitigations, or controls, in the integrated system design, including software and human interface. We must come onto that later.

    All the usual stuff about we’ve got to include COTS, GOTS, GFE, and NDI. So, even if stuff is not being developed, if we’re putting together a jigsaw system from existing pieces, we’ve still got to look at the overall thing. And as with 204, we go down to the underlined text at the bottom of the slide, areas to consider. Think about performance, and degradation of performance, functional failures, timing and design errors, defects, inadvertent functioning – that classic functional failure analysis that we’ve seen before.

    Again, while conducting this analysis, we’ve got to include human beings as an integral component of the system, receiving inputs, and initiating outputs.  Human factors were included in this standard from long ago…

    The End

    You can see all the Mil-Std-882E Analysis Tasks here.

    Get a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.

    Learn safety engineering with me, an industry professional with 25 years of experience, I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.

  • Designing Your Risk Assessment Program

    Designing Your Risk Assessment Program

    Designing Your Risk Assessment Program. Which Ingredients should we use? In this post, I draw upon my 25+ years in system safety to give you some BOLD advice! I’m going to dare to suggest which analysis tasks are essential to every System Safety Program. I also suggest which tasks are optional depending on the system that you are analyzing.

    Which Ingredients should we use?

    • Everything – high novelty, challenging requirements, bespoke development and massive scrutiny);
    • The Bare Essentials;
    • New Designs and Integrations;
    • The Human Element;
    • Electronics, Software and Data;
    • Combining existing Systems; and
    • Environmental Protection.

    Video Highlights

    Designing Your Safety Program – Highlights (SSRAP M4)

    Topics

    Designing Your Risk Assessment Program: Transcript

    We’re onto Module Four – Designing Your Program.

    This module aims to show you how to design a systematic, effective strategy for Risk Analysis. An effective program for Risk Analysis that isn’t wasteful. This module is a little bit longer than the others but bear with me! This is the real meat of what I promised you. So, let’s get started.

    Multiple Points of View

    As I said in a previous slide, we will deal with multiple points of view. We will use multiple points of view to look at the system from many different angles.

    Ten different angles, in this case, one for each task. Each of those tasks brings a different perspective. So, each task has a different purpose. What they have in common is they are all there to bring out a different aspect of the system. They are different kinds of analysis, but they all have the same aim. To identify hazards and analyze hazards.

    From that, we can then identify what we need to do to control those hazards. And that, in turn, gives us safety requirements. Sometimes they’re called ‘derived safety requirements’. They need to be met for the system to be safe. That’s the whole point of what we’re doing, as mentioned before.

    Which Ingredients?

    But if you’ve got everything then you only need all those 10 tasks if everything is in the red. Perhaps you’ve got a very novel system. You’ve got challenging performance requirements. You’ve got lots of bespoke development. And you’ve got a very critical system that’s going to get a lot of scrutiny. So, you need all 10 only if you’ve got a development from hell. Where you’ve got a very challenging development and you need all the tools you can get.

    Now, that’s fine. That’s what the standard’s designed for. But very rarely are we going to work on a program where we’re pulling out all the stops. More often, we’re going to be working on something where there are some challenging areas and some less so. And we don’t need the entire program. We don’t need all 10 tasks to achieve success. And it’s OK to tailor your safety analysis to deliver value for money. In fact, this approach is better.

    So, we’ve got some options here. I’m going to take you through the bare essentials. Those are what you need to do for every safety program. The work that we would do to address new designs and new integrations. Work that we would do to address the human element. This includes both parts of human factors. That’s the human contribution to safety and the impact that the system might have on human health. So, there’s a bit of back and forth in there in the two tasks there.

    Then if our system has got programmable electronic software, we might need to look at that. Or if it has data that is being developed or modified, we need to look at that too. We need to assess the safety implications of the modifications/development. We might consider combining existing systems into a system of systems. And then finally, we might have to do environmental protection. So, the bare essentials plus those five optional elements are the ones that we will look at.

    The Essentials #1

    Let’s start with the essentials. I’m going to say it’s axiomatic – that every program needs these three tasks. It needs Preliminary Hazard Identification. It needs Preliminary Hazard Analysis. And it needs System Requirements Hazard Analysis. The last one is about identifying safety requirements for the system.

    Now, that’s a very bold statement, is it for me to say you must have these elements in every safety program? Let me justify that, first of all, before I explain it a little bit in the next slide.

    The first thing to note is that you can do these tasks early on. They are quick and cheap tasks if you do them early enough. If you do them early enough, it’s low granularity. So, it can be a quick and simple analysis. And because of that, it’s cheap. But don’t let that fool you! Getting in early and thinking about Risk early gives us valuable insight. Insight that we can then take action on. So we get actionable results early enough in the program to do something about it if we do it.

    The second point to note with these three is that every other task depends on their outputs. Indeed, if you’re going to successfully tailor a safety program, you need the output from these tasks. They will help you focus on what’s important and what’s less important.

    Thirdly, from experience, almost every program suffers from not doing these three tasks. Whether that be well enough, early enough, or both. I’ve never been on a program where we said, ‘We did too much Preliminary Hazard Identification Analysis!’. Nor ‘We did too much identification of safety requirements!’. That has never, ever happened in more than 20 years of experience working on safety programs.

    It’s always been the opposite. We wish we’d done more. We wish we’d gone in earlier with these tasks. Then we would have known something that would have helped us to make sensible decisions. Ultimately, it would have saved a lot of time and money too! Think of these essentials as an investment, because that’s what they are…

    This is Module 4 of SSRAP

    This is Module 4 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.

    The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos here and order using the coupon “Pre-order-Half-Price-SSRAP”. But don’t leave it too long because there are only 100 half-price courses available!

    Meet the Author

    Learn safety engineering with me, an industry professional with 25 years of experience, I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.

  • Understanding Your Risk Assessment Standard

    Understanding Your Risk Assessment Standard

    When Understanding Your Risk Assessment Standard, we need to know a few things. The standard is the thing that we’re going to use to achieve things – the tool. And that’s important because tools designed to do certain things usually perform well. But they don’t always perform well on other things. So we will ask, ‘Are we doing the right thing?’ And ‘Are we doing it right?’

    This post is part of a series:

    Video Highlights

    Understanding Your Standard: Highlights

    Transcript

    What and Why?

    So, what will we do and why are we doing it? First, the use of safety standards is very common for many reasons. It helps us to have confidence that what we’re doing is good enough. We’ve met a standard of performance in the absolute sense. It helps us to say, ‘We’ve achieved standardization or commonality in what we’re doing’.

    We can also use it to help us achieve a compromise. That can be a compromise across different stakeholders or different organizations. Standardization gives us some of the other benefits as well. If we’re all doing the same thing rather than we’re all doing different things, it makes it easier to train staff. This is one example of how a standard helps.

    However, we need to understand this tool that we’re going to use. What it does, what it’s designed to do, and what it is not designed to do. That’s important for any standard or any tool. In safety, it’s particularly important because safety is, in many respects, an intangible. This is because we’re always looking to prevent a future problem from occurring. In the present, it’s a little bit abstract. It’s a bit intangible. So, we need to make sure that conceptually what we’re doing makes sense and it’s coherent. That it works together. If we look at those five bullet points there, we need to understand the concept of each standard. We need to understand the basis of each one.

    They’re not all based on the same concept. Thus, some of them are contradictory or incompatible. We need to understand the design of the standard. What the standard does, what the aim of the standard is, and why it came into existence. And who brought it into existence. To do what for whom – who’s the ultimate customer here?

    For risk analysis standards, we need to understand what kind of risks they address. Because the way you treat a financial risk might be very different from a safety risk. In the world of finance, you might have a portfolio of products, like loans. These products might have some risks associated with them. One or two loans might go bad, and you might lose money on those. But as long as the whole portfolio is making money, that might be acceptable to you. You might say, ‘I’m not worried about that 10% of my loans have gone south and all gone wrong. I’m still making plenty of profit out of the other 90%.’ It doesn’t work that way with safety. You can’t say ‘It’s OK that I’ve killed a few people over here because all this a lot over here are still alive!’. It doesn’t work like that!

    Also, what kind of evidence does the standard produce? Because in safety, we are very often working in a legal framework that requires us to do certain things. It requires us to achieve a certain level of safety and prove that we have done so. So, we need certain kinds of evidence. In different jurisdictions and different industries, some evidence is acceptable. Some are not. You need to know which is for your area. And then finally, let’s think about the pros and cons of the standard. What does it do well? And what does it do not so well?

    System Safety Pedigree

    We’re going to look at a standard called Military Standard 882E. This standard was first developed several decades ago. It was created by the US government and military to help them bring into service complex, cutting-edge military equipment. Equipment that was always on the cutting edge. That pushes the limits of what you can achieve in performance.

    That’s a lot of complexity. Lots of critical weapon systems, and so forth. So they needed something that could cope with all that complexity. It’s a system safety engineering standard. It’s used by engineers, but also by many other specialists. As I said, it’s got a background in military systems. These days, you find these principles used pretty much everywhere. So, all the approaches to System Safety that 882 introduced are in other standards. They are also in other countries.

    It addresses risks to people, equipment, and the environment, as we heard earlier. And because it’s an American standard, it’s about system safety. It’s very much about identifying requirements. What do we need to happen to get safety? To do that, it produces lots of requirements. It performs analyses of all those requirements and generates further requirements. And it produces requirements for test evidence. We then need to fulfill these requirements. It’s got several important advantages and disadvantages. We’re going to discuss these in the next few slides…

    This is Module 3 of SSRAP

    ‘Understanding Your Risk Assessment Standard’ is Module 3 of the System Safety Risk Assessment Program (SSRAP) Course. Risk Analysis Programs – Design a System Safety Program for any system in any application.

    The full course comprises 15 lessons and 1.5 hours of video content, plus resources. It’s on pre-sale at HALF PRICE until September 1st, 2024. Check out all the free preview videos here and order using the coupon “Pre-order-Half-Price-SSRAP”. But don’t leave it too long because there are only 100 half-price courses available!

    Meet the Author

    Learn safety engineering with me, an industry professional with 25 years of experience. I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.

  • Environmental Hazard Analysis

    Environmental Hazard Analysis

    This is the full-length (one hour) session on Environmental Hazard Analysis (EHA), which is Task 210 in Mil-Std-882E. I explore the aim, task description, and contracting requirements of this Task, but this is only half the video. In the commentary, I then look at environmental requirements in the USA, UK, and Australia, before examining how to apply EHA in detail under the Australian/international regime. This uses my practical experience of applying EHA. 

    You Will Learn to:

    • Conduct EHA according to the standard;
    • Record EHA results correctly;
    • Contract for EHA successfully;
    • Be aware of the regulatory scene in the US, UK, and Australia;
    • Appreciate the complexities of conducting EHA in Australia; and
    • Recognize when your EHA program requires specialist support.
    This is the seven-minute demo of the full-length (one hour) session on Environmental Hazard Analysis.

    Topics: Environmental Hazard Analysis

    • Environmental Hazard Analysis (EHA) Purpose;
    • Task Description (7+ slides);
    • Documentation, HAZMAT & Contracting (2 slides each);
    • Commentary (8 slides); and
    • Conclusion.

    Transcript: Environmental Hazard Analysis

    Introduction

    Hi, everyone, and welcome to the Safety Artisan. Today, we’re going to be talking about Environmental Hazard Analysis – A big topic! And I’m covering this as part of the series on the System Safety Engineering Standard – Mil. Standard 882E. But it doesn’t really matter what standard we are using the topic is still relevant.

    Environmental Hazard Analysis is a big topic because we’ll cover everything, not just hazards. At the end of this session, you should be able to enjoy three benefits. First of all, you should know how to approach Environmental hazard analysis from:

    • The point of view of the requirements,
    • The Hazard Analysis itself (the process), and
    • Some national and international variations in the English-speaking world.

    So, you should know how to do the basics and also to recognize when maybe you need to bring in a specialist.

    But maybe most important of all, number three is you should have the confidence to be able to get started. So I’m hoping that this session is really going to help you get started, know what you can do, and then maybe recognize when you need to bring in some specialist help or go and seek some further information.

    As you’ll see, it’s a big, complex subject. I can get you started today, but that’s all I can do in one session. And in fact, I think that’s all anyone can do in one session. Anyway, let’s get on with it and see what we’ve got.

    Environmental Hazard Analysis, Mil-Std-882E Task 210

    Environmental Hazard Analysis, which is Task 210 under Mil. Standard 882E. So let’s look at what we’re going to talk about today.

    Topics for this Session

    And you’ll see why it’s going to be quite a lengthy session. I think it will last an hour because we’re going to go through the Purpose and Task Description of Environmental Hazard Analysis as set out in the Mil. Standard. And it says seven-plus slides because there are seven mainstream slides plus some illustrations in there as well. Then we’ve got a couple of slides each on Documentation, Hazardous Materials or HAZMAT, and Contracting. Then eight slides of Commentary and this is the major value add because I’ll be talking about applying Environmental Hazard Analysis in a US, UK, and Australian jurisdiction under the different laws, which I have some experience of.

    I worked closely with environmental specialists on the Eurofighter Typhoon project, and I’ve also worked closely with the same specialists on US programs which had been bought by different countries. And then finally, I’ve been closely involved in a major environmental – or safety and environmental – project here in Australia. So I’ve been exposed and learned the hard way about how things work or don’t work here in Australia. So I’ve got some relevant experience to share with you, as well as some learned material to share with you. And then a little Conclusion, because I say this will take us an hour so there’s quite a lot of material to cover. So, let’s get right on with it.

    EHA

    So the purpose of Environmental Hazards Analysis, or EHA, as it says, is to support design development decisions. Now all of the 882 tasks are meant to do this, but actually, the wording in Task 210 is the clearest of all of them. Really makes it explicit what we’re trying to do, which is excellent.

    So we’re going to identify hazards throughout the life cycle – cradle to grave, whatever system it is. We’re going to document and record those hazards and their leading particulars within the Hazard Tracking System or Hazard Log, as we more often call it. We’re going to manage the hazards using the same system safety process in Section Four as we use for safety. This is the process that you will have heard in the other lessons that I’ve given. And very often under 882, Safety and Environmental Hazards are considered together. There are pros and cons with that approach, but nevertheless, a lot of the work is common. We’ll see why later on.

    In this American standard, it says we are to provide specific data to support the National Environmental Policy Act and executive order requirements. So the NEPA is an American piece of legislation and therefore I use this color blue to indicate anything that’s an American-specific requirement. So if you’re not operating in America, you’ll need to find the equivalent to manage to and to comply with. Moving on…

    …see the full transcript here (TBD).

    Links: Environmental Hazard Analysis

    The links mentioned in the video are here:

    You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E, here.

    Meet the Author

    Learn safety engineering with me, an industry professional with 25 years of experience, I have:

    •Worked on aircraft, ships, submarines, ATMS, trains, and software;

    •Tiny programs to some of the biggest (Eurofighter, Future Submarine);

    •In the UK and Australia, on US and European programs;

    •Taught safety to hundreds of people in the classroom, and thousands online;

    •Presented on safety topics at several international conferences.