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

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!