Safety Engineering Academy Webinars are on vital topics. I run them live every month, and you can get them all at the Safety Engineering Academy here.
These webinars draw on my practical experience of these tools and techniques, from my 25-year-plus career. In them, I provide not only theory but also pragmatic tips. I hope that you find them helpful.
Next Webinar: Risk Matrices
Learn how to use them properly! I will be covering a lot of content:
The most common questions;
What you do/don’t need a Risk Matrix for (and why); and
Problems with Risk Matrices and how to fix them!
There are 100 tickets for the webinar on EventBrite.
The webinar will be at 12:30 p.m. (ACST) on Thursday, December 14th. If you can’t make that time, then don’t worry, the recordings will always be available in the Safety Engineering Academy on Thinkific.
New Webinar Series: Tools to Get the Job Done
A new series of webinars started in November. They will cover the most sought-after safety tools and techniques – and explain how to do them! Here they are:
Risk Matrices – 14 Dec 23;
Risk Registers & Hazard Logs – Jan 24;
Causal Analysis – Feb 24;
Safety Audits – Mar 24;
HAZOP – Apr 24;
Event Trees – May 24;
Claim Argument Evidence & GSN – Jun 24; and
Fault Trees – Jul 24.
Past webinars are listed below. Again, they are always available in the Safety Engineering Academy on Thinkific.
In this webinar ‘Foundations of Safety Assessment’, I look at Mil-Std-882E, Tasks 201, 202, and 203. The associated lesson (inc. this webinar & much more) is here.
Identify & Analyze Functional Hazards
In this webinar ‘Identify & Analyze Functional Hazards’, I look at Mil-Std-882E, Tasks 201 and 208. The associated lesson (inc. this webinar & much more) is here.
Workplace Hazard Analysis
Workplace Hazard Analysis (Mil-Std-882E, Tasks 206/207) Let’s look at How to implement common workplace Hazard Analysis Tasks.
System Safety in Systems Engineering
Hazard Analysis in Systems Engineering (Mil-Std-882E, Tasks 204, 205 & 209). How do we conduct Hazard Analysis in a Systems Engineering framework?
Meet the Author
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!
Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety. To know that we first need to understand what Systems Engineering is…
Section 1: The Basics of Systems Engineering
It starts with needs and concepts, which may be quite abstract, and progressively breaks these down into concrete, specific requirements. We also determine how those requirements will be verified.
Section 2: The Transformative Process
We then transform those requirements into a logical architecture and then into a design. Then the design is translated into physical and functional components that can be developed or bought. Through all these transformations, the requirements are decomposed and flow down. Thus, we see how each component, or Configurable Item, contributes to meeting the requirements for the overall System.
Section 3: The Practice of System Safety Engineering
Finally, we must put the components together – integrate them – perhaps testing as we go to make sure that they work together. We can then verify the completed system, and support customer validation.
That’s the theory (albeit very briefly, I went on a week-long course just to learn the basics). In my experience, the practice of System Safety Engineering involves five things, it:
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.
Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety
What is system safety or system safety engineering? Well, as the name suggests, system safety is engineering safety in a systems-engineering context. Okay. So it’s safety that’s deliberately sat within a systems-engineering framework.
That drives everything about how we consider safety. Like systems engineering in general, it follows systems theory. But I’m not going to talk about systems theory now. That’s a huge subject.
I’m not actually an expert in [the theory], but I’m going to talk about three practical things that I’ve observed from doing system safety for 25 years or so.
Section 5: Considering the Whole System
First of all, we consider the system holistically. So it’s not just the technical stuff. It’s not just the hardware. It’s the software as well if there’s any software in the system.
It’s the operating environment around the system and what we’re doing with it, the functions that we’re asking it to do, all the applications that we’re putting it to, and we include the people who are using it. We include all the data that’s being used, all of the documentation, everything. So we are looking at the system as a whole in accordance with systems theory. That’s the first point.
Section 6: A Systematic Process
The second point is that it is systematic from a process point of view.
We’re following a rigorous process whereby maybe we start with some sort of high-level requirements, and we think about in safety terms what could go wrong. And we think about all of our safety obligations, what we must do. And then we decompose that, break down the problem piece by piece, systematically down to a component level. And then we consider all of the components, and then we systematically integrate it all back together.
And what I’m kind of indicating is the V model, where we start at the top left-hand corner with our requirements. And then from our requirements, we think about, well, how are we going to demonstrate that we’ve met those requirements at the end of the process? And then we carry on going down the decomposing into more detail but also thinking about how we’re going to verify and validate that we’ve done what we needed to do at every stage when we integrate and come back up the other side.
So that’s the systematic part of the process.
Section 7: Requirements and Safety
And then Thirdly, which are kind of hinted up already, is a big thing about requirements.
In systems engineering, we are talking about complex stuff. It’s hard to understand. It’s not a toaster. It’s not a simple commodity item, where we can just go, well, I want a toaster and everybody knows what a toaster does or should do and what it shouldn’t do. We want to want it to toast bread and other things, but we don’t want it to electrocute people.
You know what a toaster is. You don’t need to articulate the requirements of a toaster. But if it’s something more complicated, like a ship or a power station or a complex piece of information technology, you want to develop a big software system to do something, then that’s very complicated, and you need to consider the requirements in a systematic fashion, starting at the top level, thinking about big picture stuff, what’s the system and its boundaries, what does it interact with? What do we want it to do?
Then we need to go to a lot of effort to rigorously decompose that and come up with requirements, which you then verify and validate at the end of the project – or preferably before to avoid surprises. That’s a big part of systems engineering, as we’re dealing with complexity, and systems safety evolved to fit in with systems engineering. It uses all of those concepts, all of those are powerful levers to help us engineer safety into a system rather than just adding it on at the very end.
Section 8: Think Safety from the Start
I guess that’s the fourth big point. We start to think about safety right at the beginning, at the top left-hand corner of the V, not just at the end, and then add it on and hope everything will be all right, because that doesn’t usually work. And that’s a very, usually a very expensive and ineffective way to do things.
So that’s another point that system safety engineering. We are engineering safety into the system early because that is a more cost-effective way of doing it.
To summarise system safety engineering, remember:
It’s systematic in terms of the way we think about the system and all of its parts;
It’s systematic in terms of the process, the way we approach the task and break down the tasks rigorously and put them back together; and
It borrows from systems engineering and systems theory in the way we consider requirements.
Those three things are system safety engineering. For more on system safety try the FAQ post and the system safety assessment page.
Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety
The System Safety Engineering Process – what it is and how to do it.
This is the full-length (50-minute) session on the System Safety Process, which is called up in the general requirements of Mil-Std-882E. I cover the Applicability of Mil-Std-882E tasks, the General Requirements, the Process with eight elements, and the Application of process theory to the real world.
You Will Learn to:
Know the system safety process iaw 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 this and other standards.
Hi, everyone, and welcome to the Safety Artisan. I’m Simon, your host. Today I’m going to be using my experience with System Safety Engineering to talk you through the process that we need to follow to achieve success. Because to use a corny saying, ‘Safety doesn’t happen by accident’. Safety is what we call an emergent property. And to get it, we need to decide what we mean by safety, decide what our goals are, and then work out how we’re going to get there. It’s a planned systematic activity. Especially if we’re going to deal with very complex projects or situations. Times where there is a requirement to make that understanding and that planning explicit. Where the requirement becomes the difference between success and failure. Anyway, that’s enough of that. Let’s get on and look at the session.
Military Standard 882E, Section 4 General Requirements
Today we’re talking about System Safety Process. To help us do that, we’re going to be looking at a particular standard – the general requirements of that standard. And those are from Section Four of Military Standard 882E. But don’t get hung up on which standard it is. That’s not the point here. It’s a means to an end. I’ll talk about other standards and how we perform system safety engineering in different domains.
Our learning objectives for today are here. In this session, you will learn, or you’ll know, the system safety process in accordance with that Mil. Standard. You will be able to list and order the eight elements of the process. You will understand how to apply the eight elements. And you will be able to apply system safety with some skill using realistic processes. We’re going to spend quite a bit of time talking about how it’s actually done vs. how it appears on a sheet of paper. Also known as how it appears written in a standard. So, we’re going to talk about doing it in the real world. At the end of all that, you will be able to feel more confident dealing with multiple different standards.
The focus is not on this military standard, but on understanding the process. The fundamentals of what we’re trying to achieve and why. Then you will be able to extrapolate those principles to other standards. And that should help you to understand whatever it is you’re dealing with. It doesn’t have to be Mil. Standard 882E.
Contents of this Session
We’ve got four sets of contents in the session. First of all, I’m going to talk about the applicability of Military Standard 882E. From the standard itself and the tasks (you’ll see why that’s important) to understanding what you’re supposed to do. Then other standards later on. I’m going to talk about those general requirements that the standard places on us to do the work. A big part of that is looking at a process following the eight elements. And finally, we will apply that theory of how the process should work to the real world. And that will include learning some real-world lessons. You should find these useful for all standards and all circumstances.
So, it just remains for me to say thank you very much for listening. You can find a free pdf of the System Safety Engineering Standard, Mil-Std-882E,here.