Tag: system-safety-engineering

Categories
Blog System Safety

Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety

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:

  1. Deals with the whole system, including software, data, people, and environment;
  2. Uses a systematic (rigorous) process;
  3. Concentrates on requirements (to cope with complexity);
  4. Considers safety early in the system life cycle; and
  5. Handles complexity cost-effectively and efficiently.

Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety

Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety – watch the Lesson Here.
get more like this for free

System Safety Engineering: Transcript

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.

Summary

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

Did I Miss Anything? Leave a Comment!

Categories
Blog System Safety

System Safety Principles

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 the US approach does not sit well.

This is the ten-minute preview of the full, 45-minute video.

Get the full lesson as part of the FREE Learning Triple Bundle.

System Safety Principles: Topics

  • Foundational statement
  • Planning
  • Management Authority
  • Safety Precedence
  • Safety Requirements
  • System Analyses Assumptions & Criteria
  • Emphasis & Results
  • MA Responsibilities
  • Software hazard analysis
  • An Effective System Safety Program

System Safety Principles: Transcript

Hello and welcome to The Safety Artisan where you will find professional pragmatic and impartial educational products. I’m Simon and it’s the 3rd of November 2019. Tonight I’m going to be looking at a short introduction to System Safety Principles.

Introduction

On to system safety principles; in the full video we look at all principles from the U.S. Federal Aviation Authority’s System Safety Handbook but in this little four- or five-minute video – whatever it turns out to be – we’ll take a quick look just to let you know what it’s about.

Topics for this Session

These are the subjects in the full session. Really a fundamental statement; we talk about planning; talk about the management authority (which is the body that is responsible for bringing into existence -in this case- some kind of aircraft or air traffic control system, something like that, something that the FAA would be the regulator for in the US).

We talk about safety precedents. In other words, what’s the most effective safety control to use. Safety requirements; system analyses – which are highlighted because that’s just the sample I’m going to talk about, tonight; assumptions and safety criteria; emphasis and results – which is really about how much work you put in where and why; management authority responsibilities; a little aside of a specialist area – software hazard analysis; And finally, what you need for an effective System Safety Program.

Now, it’s worth mentioning that this is not an uncritical look at the FAA handbook. It is 19 years old now so the principles are still good, but some of it’s a bit long in the tooth. And there are some areas where, particularly on software, things have moved on. And there are some areas where the FAA approach to system safety is very much predicated on an American approach to how these things are done.  

Systems Analysis

So, without further ado, let’s talk about system analysis. There are two points that the Handbook makes. First of all, these analyses are basic tools for systematically developing design specifications. Let’s unpack that statement. So, the analyses are tools- they’re just tools. You’ve still got to manage safety. You’ve still got to estimate risk and make decisions- that’s absolutely key. The system analyses are tools to help you do that. They won’t make decisions for you. They won’t exercise authority for you or manage things for you. They’re just tools.

Secondly, the whole point is to apply them systematically. So, coverage is important here- making sure that we’ve covered the entire system. And also doing things in a thorough and orderly fashion. That’s the systematic bit about it.

And then finally, it’s about developing design specifications. Now, this is where the American emphasis comes in. But before we talk about that, it’s fundamental to note that really we need to work out what our safety requirements are.

What are we Trying to Achieve?

What are we trying to achieve here with safety? And why? These are really important concepts because if you don’t know what you’re trying to achieve then it will be very difficult to get there and to demonstrate that you’ve got there – which is kind of the point of safety. Putting effort into getting the requirements right is very important because without doing that first step all your other work could be invalid. In my experience of 20-plus years in the business, if you don’t have a precise grasp of what you’re trying to achieve then you’re going to waste a lot of time and money, probably.

So, onto the second bullet point. Now the handbook says that the ultimate measure of safety is not the scope of analysis but in satisfying requirements. So, the first part – very good. We’re not doing analysis for the sake of it. That’s not the measure of safety – that we’ve analyzed something to death or that we’ve expended vast amounts of dollars on doing this work but that we’ve worked out the requirements and the analysis has helped us to meet them. That is the key point.

Safety in Different Jurisdictions

This is where it can go slightly pear-shaped in that this emphasis on requirements (almost to the exclusion of anything else) is a very U.S.-centric way of doing things. So, very much in the US, the emphasis is you meet the spec, you certify that you’ve met spec and therefore we’re safe. But of course what if the spec is wrong? Or what if it’s just plain inappropriate for a new use of an existing system or whatever it might be?

In other jurisdictions, notably the U.K. (and as you can tell from my accent that’s where I’m from, I’ve got a lot of experience doing safety work in the U.K. but also Australia where I now live and work) it’s not about meeting requirements. Well, it is but let me explain. In the UK and Australia, English law works on the idea of intent.

So, we aim to make something safe: not whether it has that it’s necessarily met requirements or not, that doesn’t really matter so much, but is the risk actually reduced to an acceptable level? There are tests for deciding what is acceptable. Have you complied with the law? The law outside the US can take a very different approach to “it’s all about the specification”.

Not Just the Specification

Of course, those legal requirements and that requirement to reduce risk to an acceptable level, are, in themselves, requirements. But in Australian or British legal jurisdiction, you need to think about those legal requirements as well. They must be part of your requirements set.

So, just having a specification for a technical piece of cake that ignores the requirements of the law, which include not only design requirements but the thing is actually safe in service and can be safely introduced, used, disposed of, etc. If you don’t take those things into account you may not meet all your obligations under that system of law.

So, there’s an important point to understanding and using American standards and an American approach to system safety out of the assumed context. And that’s true of all standards and all approaches but it’s a point I bring out in the main video quite forcefully because it’s very important to understand.

Get the full lesson as part of the
FREE Learning Triple Bundle.

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.

Categories
Mil-Std-882E Safety Analysis

System Safety Engineering Process

Photo by Bonneval Sebastien on Unsplash

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.
System Safety Process – this is the free demo.
buy the full-length video

Topics: System Safety Engineering Process

  • Applicability of Mil-Std-882E tasks;
  • General requirements;
  • Process with eight elements; and
  • Application of process theory to the real world

Transcript: Preliminary Hazard Identification

CLICK HERE for the Transcript

System Safety Process

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.

Learning Objectives

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.