Categories
Mil-Std-882E Safety Analysis System Safety

Sub-System Hazard Analysis

In this video lesson, I look at Sub-System Hazard Analysis, or SSHA, which is Task 204 in Mil-Std-882E. 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. Or in fact, that would be recommended control measures for hazards and risks.

We’ve got six slides on the 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 different for subsystem analysis as opposed to system. And when you’ve watched both sessions on 204 and 205, I think you’ll see the significance of why 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 on the left-hand side of the hexagons, we’ve got our system in the centre, which we’re considering. Maybe that interfaces with other systems. They work within 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-system 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.

System Requirements Hazard Analysis (T204)

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 which may emerge as we’re working at a lower level now. And we must recommend actions necessary. That’s further requirements to eliminate all hazards or mitigate associated risks. We’ll keep those three things in mind and that will keep coming up.

Task Description (T204) #1

The first of six slides on the task description. Basically, we are being told to perform and document the SSHA, sub-system hazard analysis. And it’s got to include everything, whether it be new developments, COTS, GOTS, GFE, NDI, software and humans, as we’ll see later. Everything must be included. And we’re being guided to consider the performance of the subsystem: ‘What it is doing when it is doing it properly’. We’ve got to consider performance degradation, functional failures, timing errors, design errors or defects, and inadvertent functioning – we’ll come back to that later. And while we’re doing analysis, we must consider the human as a component within the subsystem dealing with inputs and making outputs. If, of course, there is an associated human. We’ve got to include everything, and we’ve got to think about what could go wrong with the system.

Task Description (T204) #2

The minimum that the analysis has got to cover is as follows. We’ve got to verify subsystem compliance with requirements and that is to say, requirements to eliminate hazards or reduce risks. The first thing to note about that is you can’t verify compliance with requirements if there are no requirements. if you haven’t set any requirements on the subsystem provider or whoever is doing the analysis, then there’s nothing to comply with and you’ve got no leverage if the subsystem turns out to be dangerous. I often see it as it gets missed.

People don’t do their top-down systems engineering properly; They don’t think through the requirements that they need; and, especially, they don’t do the preliminary hazard identification and analysis that they need to do. They don’t do Task 203, the SRHA, to think about what requirements they need to place further down the food chain, down the supply chain. And if you haven’t done that work, then you can’t be surprised if you get something back that’s not very good, or you can’t verify that it’s safe. Unfortunately, I see that happen often, even on exceptionally large projects. If you don’t ask, you don’t get, basically.

We’ve got two sub-paragraphs here that are unique to this task. First, we’ve got to validate flow down of design requirements. “Are these design requirements valid?”, “Are they the right requirements?” From the top-level spec down to more detailed design specifications for the subsystem. Again, if you haven’t specified anything, then you’ve got no leverage. Which is not to say that you have to dive into massive detail and tell the designer how to do their job, but you’ve got to set out what you want from them in terms of the product and what kind of process evidence you want associated with that product.

And then the second sub-paragraph, you’ve got to ensure design criteria in the subsystem specs have been satisfied. We need to verify that they’re satisfied, and that V and V of subsystem mitigation measures or risk controls have been included in test plans and procedures. As always, the Mil. standard 882 is the American standard, and they tend to go big on testing. Where it says test plans and procedures that might be anything – you might have been doing V and V by analysis, by demonstration, by testing, by other means. It’s not necessarily just testing, but that’s often the assumption.

End

So, that’s the end of the presentation and it just remains for me to say, thanks very much for watching and supporting the Safety Artisan. And I’ll be doing Task 205 system hazard analysis next in the series, look forward to seeing you again soon. Bye-bye, everyone.

End: Sub-System Hazard Analysis

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

Categories
Blog

The 2022 Digest

This is The 2022 Digest – all the posts from The Safety Artisan last year. There have been 31 posts in all covering subjects such as:

  • Risk and Safety basics;
  • Tools and Techniques;
  • A short series on Safety Management (to be continued);
  • Design Safety;
  • SFARP and Australian WHS;
  • Hazard Logs (also to be continued);
  • Launching my Thinkific page;
  • Cyber security;
  • A series on Software Safety and Standards; and
  • Updates of posts on System Safety Analyses.

Here we go…

The 2022 Digest: Quarter Four

In this 45-minute session, I’m looking at System Requirements Hazard Analysis, or SRHA, which is Task 203 in the Mil-Std-882E standard. I will 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 … Read more

In this 45-minute session, The Safety Artisan looks at how to do 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. Topics: … Read more

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. (We refer to other lessons for special techniques … Read more

Are you looking for Safety Engineering Jobs in Australia?  Thinking of moving into the profession and wondering if it’s worth it?  Already a safety engineer and thinking of moving to Australia (Poms, take note)?  Then this article is for you! Introduction The most popular online job site in Australia is seek.com.au. If we go on … Read more

SW Safety Principles Conclusions and References is the sixth and final blog post on Principles of Software Safety Assurance. In them, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of these guidelines … Read more

This post, Software Safety Assurance and Standards, is the fifth in a series of six blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can … Read more

Software Safety Assurance is the fourth in a new series of six blog posts on Principles of Software Safety Assurance. In them, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of these … Read more

Software Safety Principle 4 is the third in a new series of six blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of … Read more

The 2022 Digest: Quarter Three

Software Safety Principles 2 and 3 is the second in a new series of blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think … Read more

This is the first in a new series of blog posts on Principles of Software Safety Assurance. In it, we look at the 4+1 principles that underlie all software safety standards. We outline common software safety assurance principles that are evident in software safety standards and best practices. You can think of these guidelines as … Read more

Proportionality is about committing resources to the Safety Program that are adequate – in both quality and quantity – for the required tasks. Proportionality is a concept that should be applied to determine the allocation of resource and effort to a safety and environmental argument based on its risk.  It is a difficult concept … Read more

This post, Blog: Australian vs. UK Safety Law compares the two approaches, based on my long experience of working on both sides. Are you a safety professional thinking of emigrating from the UK to Australia?  Well, I’ve done it, and here’s my BREXIT special guide!  In this 45-minute video, The Safety Artisan looks at the … Read more

In this course, ‘CISSP 2021: What’s New?’, we look at the significant changes that have been made to the CISSP Official Exam Outline (the course syllabus). Learn what’s new in the CISSP Curriculum, from May 1st, 2021 (next update in 2024) There are still Eight Domains – D1, D3 & D7 are … Read more

In this 45-minute video, I discuss System Safety Principles, as set out by the US Federal Aviation Authority in their System Safety Handbook. Although this was published in 2000, the principles still hold good (mostly) and are worth discussing. I comment on those topics where the modern practice has moved on, and those jurisdictions where … Read more

In this 33-minute session, Safety Concepts Part 2, The Safety Artisan equips you with more Safety Concepts. We look at the basic concepts of safety, risk, and hazard in order to understand how to assess and manage them. Exploring these fundamental topics provides the foundations for all other safety topics, but it doesn’t have to … Read more

In Hazard Logs – a Brief Summary, we will give you an overview of this important safety management tool. This post serves as an introduction to longer posts and videos (e.g. Hazard Logs & Hazard Tracking Systems), which will provide you with much more content. Hazard Logs – a Brief Summary Description of Hazard Log … Read more

In this Australian WHS Course, we show you how to practically and pragmatically implement the essential elements of Australian Work Health and Safety Legislation. In particular, we look at the so-called ‘upstream’ WHS duties. These are the elements you need to safely introduce systems and services into the Australian market. Lessons in This Course A Guide … Read more

The 2022 Digest: Quarter Two

In this lesson, I will teach you how to demonstrate SFARP. To use the proper terminology, from the Australian WHS Act, how to eliminate or minimize risks so far as is reasonably practicable. (The Act never uses the acronym SFARP or SFAIRP, but everyone else does.) This will build upon the post So Far As … Read more

Career change: in my lecture to the System Engineering Industry Program at the University of Adelaide, I reflect on my career changes. What can you learn from my experiences? (Hint: a lot, I hope!) I want to talk about career changes because all of you – everyone listening – have already started to make them. … Read more

In this post on Safety Management Policy, we’re going to look at the policy requirements of a typical project management safety standard. This is the Acquisition Safety & Environmental System (ASEMS). The Ministry of Defence is the biggest acquirer of manufactured goods in the UK, and it uses ASEMS to guide hundreds of acquisition projects. … Read more

Good work design can help us achieve safe outcomes by designing safety into work processes and the design of products. Adding safety as an afterthought is almost always less effective and costs more over the lifecycle of the process or product. Introduction The Australian Work Health and Safety Strategy 2012-2022 is underpinned by the principle … Read more

Safety Planning: if you fail to plan, you are planning to fail. In my experience, good safety plans don’t always result in successful safety programs; however, bad safety plans never lead to success. Safety Planning: Introduction Definitions A Safety Management Plan is defined as: “A document that defines the strategy for addressing safety and documents the Safety Management … Read more

Our Second Safety Management Procedure is the Project Safety Committee. Okay, so committees are not the sexiest subject, but we need to get stakeholders together to make things happen! Project Safety Committee: Introduction Definitions A Safety Committee is defined as: A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities. Def … Read more

In ‘Project Safety Initiation’ we look at what you need to do to get your safety project or program started. Introduction Definitions A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to … Read more

The 2022 Digest: Quarter One

‘So Far As Is Reasonably Practicable’ is a phrase that gets used a lot, but what does it mean? How do you demonstrate it? Well, in Australia we do it like this … and you can learn from this wherever you operate! Attribution This post uses text from ‘How to Determine what is Reasonably Practicable … Read more

In Safety Assessment Techniques Overview we will look at how different analysis techniques can be woven together. How does one analysis feed into another? What do we need to get sufficient coverage to be confident that we’ve done enough? Learning Objectives: Safety Assessment Techniques Overview You will be able to: List and ‘sequence’ the five … Read more

TL;DR This article on Failure Mode Effects Analysis explains this powerful and commonly-used family of techniques. It covers: A description of the technique, including its purpose; When it might be used; Advantages, disadvantages and limitations; Sources of additional information; A simple example of an FMEA/FMECA; and Additional comments. I’ve added some ‘top tips’ of my … Read more

I’m pleased to tell you that The Safety Artisan is on Thinkific! Thinkific is a powerful and beautifully-presented online Learning Management System.  This will complement the existing Safety Artisan website.   My first course will be ‘System Safety Assessment‘ with ten hours of instructional videos. The new course is here. (Please note that this is the same … Read more

What is System Safety Engineering? System Safety Engineering does five things: Deals with the whole system, including software, data, people, and environment; Uses a systematic (rigorous) process; Concentrates on requirements (to cope with complexity); Considers safety early in the system life cycle; and Handles complexity cost-effectively and efficiently. System Safety Engineering: Transcript What is system … Read more

In this article, I look at The Risk Matrix, a widely used technique in many industries. Risk Matrices have many applications! In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence. Introduction A risk matrix is a graphical representation of the … Read more

You heard me right. Risk: Averse, Adverse, or Appetite? Which would you choose? Do we even have a choice? Read on … We often hear that we live in a risk-averse society.  By that, I mean that we don’t want to take risks, or that we’re too timid.  I don’t think that’s the whole story. … Read more

Thanks for Your Support in 2022!

Creating The 2022 Digest has reminded me just how much content I have produced this year. If you would like to get content emailed to you every two weeks, plus big discounts on courses then subscribe here!

Categories
Blog Mil-Std-882E Safety Analysis

How to do Preliminary Hazard Analysis with Mil-Std-882E

In this 45-minute session, The Safety Artisan looks at how to do Preliminary Hazard Analysis with Mil-Std-882E. Preliminary Hazard Analysis, or PHA, is Task 202 in the standard.

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.

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

Topics: How to do Preliminary Hazard Analysis

  • Task 202 Purpose;
  • Task Description;
  • Recording & Scope;
  • Risk Assessment (Tables I, II & III);
  • Risk Mitigation (order of preference);
  • Contracting; and
  • Commentary.

Transcript: How to do Preliminary Hazard Analysis

Hello and welcome to the Safety Artisan, where you’ll find professional, pragmatic, and impartial safety training resources. So, we’ll get straight on to our session, which is on the 8th of February 2020.

Preliminary Hazard Analysis

Now we’re going to talk today about Preliminary Hazard Analysis (PHA). This is Task 202 in Military Standard 882E, which is a system safety engineering standard. It’s very widely used mostly on military equipment, but it does turn up elsewhere.  This standard is of wide interest to people and Task 202 is the second of the analysis tasks. It’s one of the first things that you will do on a systems safety program and therefore one of the most informative. This session forms part of a series of lessons that I’m doing on Mil-Std-882E.

Topics for This Session

What are we going to cover in this session? Quite a lot! The purpose of the task, a task description, recording, and scope. How we do risk assessments against Tables 1, 2, and 3. Basically, it is severity, likelihood, and the overall risk matrix.  We will talk about all three, about risk mitigation and using the order of preference for risk mitigation, a little bit of contracting, and then a short commentary from myself. In fact, I’m providing commentary all the way through. So, let’s crack on.

Task 202 Purpose

The purpose of Task 202, as it says, is to perform and document a preliminary hazard analysis, or PHA for short, to identify hazards, assess the initial risks and identify potential mitigation measures. We’re going to talk about all of that.

Task Description

First, the task description is quite long here. And as you can see, I’ve highlighted some stuff that I particularly want to talk about.

It says “the contractor” [does this or that], but it doesn’t really matter who is doing the analysis, and actually, the customer needs to do something to inform themselves, otherwise they won’t really understand what they’re doing.  Whoever does it needs to perform and document a PHA. It’s about determining initial risk assessments. There’s going to be more work, more detailed work done later. But for now, we’re doing an initial risk assessment of identified hazards. And those hazards will be associated with the design or the functions that we’re proposing to introduce. That’s very important. We don’t need a design to do this. We can get in early when we have user requirements, functional requirements, and that kind of thing.

Doing this work will help us make better requirements for the system. So, we need to evaluate those hazards for severity and probability. It says based on the best available data. And of course, early in a program, that’s another big issue. We’ll talk about that more later. It says to include mishap data as well, if accessible: American term mishap, means an accident, but we’re avoiding any kind of suggestion about whether it is accidental or deliberate.  It might be stupidity, deliberate, or whatever. It’s a mishap. It’s an undesirable event.

We look for accessible data from similar systems, legacy systems, and other lessons learned. I’ve talked about that a little bit in Task 201 lesson about that, and there’s more on that today under commentary. We need to look at provisions, alternatives, meaning design provisions and design alternatives to reduce risks and add mitigation measures to eliminate hazards. If we can all reduce associated risk, we need to include all of that. What’s the task description? That’s a good overview of the task and what we need to talk about.

Reading & Scope

First, recording and scope, as always, with these tasks, we’ve got to document the results of the PHA in a hazard tracking system. Now, a word on terminology; we might call a hazard tracking system; we might call it a hazard log; we might call it a risk register. It doesn’t really matter what it’s called. The key point is it’s a tracking system. It’s a live document, as people say, it’s a spreadsheet or a database, something like that. It’s something relatively easy to update and change. And we can track changes through the safety program once we do more analysis because things will change. We should expect to get some results and refine them and change them as time goes on. Very important point.

That’s it for the Demo…

End: How to do Preliminary Hazard Analysis

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

Categories
Mil-Std-882E System Safety

Learn How to Perform System Safety Analysis

In this ‘super post,’ you’re going to Learn How to Perform System Safety Analysis. I’m going to point you to thirteen lessons that explain each of the ten analysis tasks, the analysis process, and how to combine the tasks into a program!

Follow the links to sample and buy lessons on individual tasks. You can get discount deals on a bundle of three tasks, or all twelve (+bonus)!

Discount Offer

Click here for 60% off on all twelve (+bonus) videos:

  • Safety Assessment Techniques Overview;
  • System Safety Process;
  • Design your System Safety Program; and
  • All ten System Safety Analysis 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, 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 System Safety Process, we look a 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.

This lesson is also available as part of the twelve+one-lesson bundle (see the top/bottom of this post).

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.

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.

Triple Bundle Offer

Click here for a half-price deal on the three essential tasks: Preliminary Hazard Identification, Preliminary Hazard Analysis, and Safety Requirements Hazard Analysis.

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) in order 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. 

Discount Offer

Click here for a bumper deal on all twelve lessons:

  • System Safety Process;
  • Design your System Safety Program; and
  • All ten System Safety Analysis tasks.