Understanding System Safety Engineering: A Quick Guide, takes you through some key points of this complex subject.
Introduction
System safety engineering plays a crucial role in ensuring the safety of complex systems. In this post, we will explore the fundamental concepts of system safety engineering and its importance in the realm of systems engineering.
System Safety Engineering Explained
System safety engineering, as the name implies, focuses on engineering safety within a systems-engineering context. It involves deliberately integrating safety measures into the framework of complex systems.
Read on, or watch this short video for some pointers:
What is System Safety Engineering?
Key Points of System Safety Engineering
1. Consider the Whole System
In system safety engineering, a holistic approach is essential. It’s not just about hardware and technical aspects; it includes software, operating environments, functions, user interactions, and data. This comprehensive view aligns with systems theory, ensuring a thorough safety assessment.
2. A Systematic Process
System safety engineering follows a systematic process. Starting with high-level requirements, it meticulously analyzes potential risks, safety obligations, and components. The V model illustrates this structured approach, emphasizing the importance of verification and validation at every stage.
The Systems Engineering ‘V’ Model
3. Emphasis on Requirements
Unlike simple commodities like toasters, complex systems require rigorous requirement analysis. System engineers meticulously decompose the system, defining boundaries, interactions, and functionalities. These requirements undergo rigorous validation, minimizing surprises and ensuring safety from the start.
Bowtie showing the Foundations of System Safety
4. Think Safety from the Start
A significant aspect of system safety engineering is the early integration of safety considerations. By addressing safety concerns right from the beginning, potential issues are identified and resolved cost-effectively. This proactive approach enhances the overall safety of the system.
Which way should we go?
Summary
In summary, system safety engineering is characterized by its systematic approach to understanding the entire system, following a structured process, and integrating concepts from systems engineering and systems theory. By focusing on comprehensive requirements and thinking about safety from the start, system safety engineering ensures the safety and reliability of complex systems.
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!
Meet the Author
If you found this helpful, there’s more depth in this article, and you can also see System Safety FAQ. There’s a low-price introductory course on the System Safety Process – on Udemy (please use this link, otherwise Udemy takes two-thirds of the revenue).
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
Understanding System Safety Engineering: A Holistic Approach to Ensuring Safety – watch the Lesson Here.
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
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.
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.
Hi everyone, and welcome to The Safety Artisan. I’m Simon, your host. This is ‘How to Get the Most from The Safety Artisan #2’.
In my previous post (#1) I talk about the Start Here topic page. There you will find lessons that deal with fundamental issues – most of them are free.
This time I’m talking about two other topic areas, which are the main focus of The Safety Artisan – so far.
System Safety
The first topic is system safety. I spend a lot of time talking about system safety because it’s used in so many different industries. You can apply its principles to just about anything.
And because it takes a systematic approach to safety you can scale it up or down. It is used on the biggest, multinational, multi-billion dollar projects you can imagine. You can also tailor it so that it can be used sensibly on much smaller projects. You can get good results for a lot less money and time.
So I present a whole suite of sessions on system safety, in particular how to do system safety analysis according to a US Military Standard 882E. Whether you’re working on US military systems or not doesn’t matter. The principles, practices, and procedures in the standard will equip you to tackle almost any standard.
But you’ve got to understand your standard, and what it was designed to achieve. Then you can make it work for you.
WHS also contains and concepts like ‘So Far As Is Reasonably Practicable or SFAIRP/SFARP. These are often misunderstood and misapplied. This is a shame because the public guidance that is out there is excellent.
Even if you don’t work in Australia, you’ll find that many principles used in WHS law are found in other western nations. For example, I compared safety laws in the UK and Australia, based on my experience of working in both countries.
How to Get the Most from The Safety Artisan #3: Coming Soon…
Next time, I talk about how you can connect and interact with The Safety Artisan to get better learning results for you!
In ‘Reflections on a Career in Safety, Part 5’, I finally get around to reflecting on personal lessons learned from my own career.
Reflecting on a Career in Safety
Very briefly, I just wanted to pick out three things.
Learning and Practice
First, at university in my first degree and in my master’s degree and in studies I’ve done since then (because you never stop learning) you pick up a theoretical framework, which is fantastic. You learn to understand things from an abstract point of view or a theoretical point of view.
But there’s also practical experience, and the two complement each other. You can [start] a job. You’re usually doing the same thing over and over again. So you become very competent in that narrow area. But if you don’t have the theoretical framework to put it in, you’ve got all of these jewels of experience, but you can’t understand where they fit in in the big picture.
Wilhelmshaven, Picture by S. Di Nucci
And so that’s what your course here does. Whatever courses you do in the future, whatever learning you do in the future, the two complement each other, and actually they work together. Whether I turn up and I understand something from a theoretical point of view, or I’ve actually done it and learned the hard way (usually doing it the hard way is painful), the two are complementary and they’re [both] very useful to help you in your career.
Opportunism and Principles
Second, you’ve heard me say a couple of times I got into software by accident. I got into safety by accident. And it’s all true. An opportunity comes up and you’ve got to grab it either because you think, well, maybe this opportunity won’t come again or you’re trying to get out of a job that you don’t like or avoid doing something you don’t want to do, whatever it might be.
If you have an opportunity, I would say grab it, go for it, be positive and say yes to as many things as you can. And, if I dare to give you some career advice, it would be that.
But also, in safety, we’ve got to stick to our principles. And sometimes as a safety engineer or an engineer who does safety, you’re going to have to stick to something that costs you, whether it be a promotion or, whether people no longer listen to you because you said, “no, we can’t do that” when it’s something that they really want to do.
You have to understand the difference between things that matter and things that don’t. So if you end up in safety, if you’re working with the safety of people, [you must] learn the things that cannot be negotiated. There are certain requirements in the law and regulations, but they’re often not as onerous as people think. They’re often a lot simpler than people think. So understand: what has to be done and what is optional? What is merely beneficial. And then you can make a sound judgment.
Simplicity
The final point. Einstein once famously said that if you can’t explain something in simple terms, then you don’t really understand it. And what you and I will all be doing for years to come is dealing with complexity, big projects, politics. A technical challenge, with not enough time to do something, not enough budget to do something. So lots of challenges.
I think it’s always a struggle to reduce [a problem] to something simple that you can understand and think: right, this is the essential point that we need to keep hold of. Everything else is kind of fluff and distraction.
So I would say my career in safety has been a constant effort to simplify and to understand the simple things that are important. And that’s what we need to stick to. And again, all of you, whether you do safety or not, you’re going to be dealing with complex systems. Otherwise, we’re not needed as systems engineers.
‘Decomposed’ F1 Racing Car, Brooklands. Photo Simon Di Nucci.
Q&A (Part 6) will follow next week!
New to System Safety? Then starthere. There’s more about The Safety Artisan here. Subscribe for free regular emails here.
In ‘Reflections on a Career in Safety, Part 3’ I continue talking about different kinds of Safety, moving onto…
Projects and Products
Then moving on to the project side, where teams of people were making sure a new aeroplane, a new radio, a new whatever it might be, was going to work in service; people were going to be able to use it, easily, support it, get it replaced or repaired if they had to. So it was a much more technical job – so lots of software, lots of people, lots of process and more people.
Moving to the software team was a big shock to me. It was accidental. It wasn’t a career move that I had chosen, but I enjoyed it when I got there. For everything else in the Air Force, there was a rule. There was a process for doing this. There were rules for doing that. Everything was nailed down. When I went to the software team, I discovered there are no rules in software, there are only opinions.
The ‘H’ is software development is for ‘Happiness’
So straight away, it became a very people-focused job because if you didn’t know what you were doing, then you were a bit stuck. I had to go through a learning curve, along with every other technician who was on the team. And the thing about software with it being intangible is that it becomes all about the process. If a physical piece of kit like the display screen isn’t working, it’s pretty obvious. It’s black, it’s blank, nothing is happening. It’s not always obvious that you’ve done something wrong with software when you’re developing it.
So we were very heavily reliant on process; again, people have got to decide what’s the right process for this job? What are we going to do? Who’s going to do it? Who’s able to do it? And it was interesting to suddenly move into this world where there were no rules and where there were some prima donnas.
We had a handful of really good programmers who could do just about anything with the aeroplane, and you had to make the best use of them without letting them get out of control. Equally, you had people on the other end of the scale who’d been posted into the software team, who really did not want to be there. They wanted to get their hands dirty, fixing aeroplanes. That’s what they wanted to do. Interesting times.
From the software team, I moved on to big projects like Eurofighter, that’s when I got introduced to:
Systems Engineering
And I have no problem with plugging systems engineering because as a safety engineer, I know [that] if there is good systems engineering and good project management, I know my job is going to be so much easier. I’ve turned up on a number of projects as a consultant or whatever, and I say, OK, where’s the safety plan? And they say, oh, we want you to write it. OK, yeah, I can do that. Whereas the project management plan or where’s the systems engineering management plan?
If there isn’t one or it’s garbage – as it sometimes is – I’m sat there going, OK, my just my job just got ten times harder, because safety is an emergent property. So you can say a piece of kit is on or off. You can say it’s reliable, but you can’t tell whether it’s safe until you understand the context. What are you asking it to do in what environment? So unless you have something to give you that wider and bigger picture and put some discipline on the complexity, it’s very hard to get a good result.
So systems engineering is absolutely key, and I’m always glad to work with the good systems engineer and all the artifacts that they’ve produced. That’s very important. So clarity in your documentation is very helpful. Being [involved], if you’re lucky, at the very beginning of a program, you’ve got an opportunity to design safety, and all the other qualities you want, into your product. You’ve got an opportunity to design in that stuff from the beginning and make sure it’s there, right there in the requirements.
Also, systems engineers doing the requirements, working out what needs to be done, what you need the product to do, and just as importantly, what you need it not to do, and then passing that on down the chain. That’s very important. And I put in the title “managing at a distance” because, unlike in the operations world where you can say “that’s broken, can you please go and fix it”.
Managing at a Distance
It’s not as direct as that. You’re looking at your process, you’re looking at the documentation, you’re working with, again, lots and lots of people, not all of whom have the same motivation that you do.
Industry wants to get paid. They want to do the minimum work to get paid, [in order] to maximize their profit. You want the best product you can get. The pilots want something that punches holes in the sky and looks flash and they don’t really care much about much else, because they’re quite inoculated to risk.
So you’ve got people with competing motivations and everything has got to be worked indirectly. You don’t get to control things directly. You’ve got to try and influence and put good things in place, in almost an act of faith that, [you put] good things in place and good things will result. A good process will produce a good product. And most of the time that’s true. So (my last slide on work), I ended up doing consultancy, first internally and then externally.
Part 4 will follow next week!
New to System Safety? Then starthere. There’s more about The Safety Artisan here. Subscribe for free regular emails here.
In ‘Reflections on a Career in Safety, Part 2’ I move on to …
Different Kinds of Safety
So I’m going to talk a little bit about highlights, that I hope you’ll find useful. I went straight from university into the Air Force and went from this kind of [academic] environment to heavy metal, basically. I guess it’s obvious that wherever you are if you’re doing anything in industry, workplace health and safety is important because you can hurt people quite quickly.
Workplace Health and Safety
In my very first job, we had people doing welding, high voltage electrics, heavy mechanical things; all [the equipment was] built out of centimeter-thick steel. It was tough stuff and people still managed to bend it. So the amount of energy that was rocking around there, you could very easily hurt people. Even the painters – that sounds like a safe job, doesn’t it? – but aircraft paint at that time a cyanoacrylate. It was a compound of cyanide that we used to paint aeroplanes with.
All the painters and finishers had to wear head-to-toe protective equipment and breathing apparatus. If you’re giving people air to breathe, if you get that wrong, you can hurt people quite quickly. So even managing the hazards of the workplace introduced further hazards that all had to be very carefully controlled.
And because you’re in operations, all the decisions about what kind of risks and hazards you’re going to face, they’ve already been made long before. Decisions that were made years ago, when a new plane or ship or whatever it was, was being bought and being introduced [into service]. Decisions made back then, sometimes without realizing it, meant that we were faced with handling certain hazards and you couldn’t get rid of them. You just had to manage them as best you could.
Overall, I think we did pretty well. Injuries were rare, despite the very exciting things that we were dealing with sometimes. We didn’t have too many near misses – not that we heard about anyway. Nevertheless, that [risk] was always there in the background. You’re always trying to control these things and stop them from getting out of control.
One of the things about a workplace in operations and support, whether you’re running a fleet of aeroplanes or you’re servicing some kit for somebody else and then returning it to them, it tends to be quite a people-centric job. So, large groups of people doing the job, supervision, organization, all that kind of stuff. And that can all seem very mundane, a lot of HR-type stuff. But it’s important and it’s got to be dealt with.
So the real world of managing people is a lot of logistics. Making sure that everybody you need is available to do the work, making sure that they’ve got all the kit, all the technical publications that tell them what to do, the information that they need. It’s very different to university – a lot of seemingly mundane stuff – but it’s got to be got right because the consequences of stuffing up can be quite serious.
Safe Systems of Work
So moving on to some slightly different topics, when I got onto working with Aeroplanes, there was an emphasis on a safe system of work, because doing maintenance on a very complex aeroplane was quite an involved process and it had to be carefully controlled. So we would have what’s usually referred to as a Permit to Work system where you very tightly control what people are allowed to do to any particular plane. It doesn’t matter whether it’s a plane or a big piece of mining equipment or you’re sending people in to do maintenance on infrastructure; whatever it might be, you’ve got to make sure that the power is disconnected before people start pulling it apart, et cetera, et cetera.
And then when you put it back together again, you’ve got to make sure that there aren’t any bits leftover and everything works before you hand it back to the operators because they’re going to go and do some crazy stuff with it. You want to make sure that the plane works properly. So there was an awful lot of process in that. And in those days, it was a paperwork process. These days, I guess a lot would be computerized, but it’s still the same process.
If you muck up the process, it doesn’t matter whether [it is paper-based or not]. If you’ve got a rubbish process, you’re going to get rubbish results and it [computerization] doesn’t change that. You just stuff up more quickly because you’ve got a more powerful tool. And for certain things we had to take, I’ve called it special measures. In my case, we were a strike squadron, which meant our planes would carry nuclear weapons if they had to.
Special Processes for Special Risks
So if the Soviets charged across the border with 20,000 tanks and we couldn’t stop them, then it was time to use – we called them buckets of sunshine. Sounds nice, doesn’t it? Anyway, so there were some fairly particular processes and rules for looking after buckets of sunshine. And I’m glad to say we only ever used dummies. But when you when the convoy arrived and yours truly has to sign for the weapon and then the team starts loading it, then that does concentrate your mind as an engineer. I think I was twenty-two, twenty-three at the time.
Somebody on [our Air Force] station stuffed up on the paperwork and got caught. So that was two careers of people my age, who I knew, that were destroyed straight away, just by not being too careful about what they were doing. So, yeah, that does concentrate the mind. If you’re dealing with, let’s say you’re in a major hazard facility, you’re in a chemical plant where you’ve got perhaps thousands of tonnes of dangerous chemicals, there are some very special risk controls, which you have to make sure are going to work most of the time.
And finally, there is ‘airworthiness’: decisions about whether we could fly an aeroplane, even though some bits of it were not working. So that was a decision that I got to make once I got signed off to do it. But it’s a team job. You talk to the specialists who say, this bit of the aeroplane isn’t working, but it doesn’t matter as long as you don’t do “that”.
So you have to make sure that the pilots knew, OK, this isn’t working. This is the practical effect from your [operator’s] point of view. So you don’t switch this thing on or rely on this thing working because it isn’t going to work. There were various decisions about [airworthiness] that were an exciting part of the job, which I really enjoyed. That’s when you had to understand what you were doing, not on your own, because there were people who’d been there a lot longer than me. But we had to make things work as best we could – that was life.
Part 3 will follow next week!
New to System Safety? Then starthere. There’s more about The Safety Artisan here. Subscribe for free regular emails here.
This is Part 1 of my ‘Reflections on a Career in Safety’, from “Safety for Systems Engineering and Industry Practice”, a lecture that I gave to the University of Adelaide in May 2021. My thanks to Dr. Kim Harvey for inviting me to do this and setting it up.
The Lecture, Part 1
Hi, everyone, my name Simon Di Nucci and I’m an engineer, I actually – it sounds cheesy – but I got into safety by accident. We’ll talk about that later. I was asked to talk a little bit about career stuff, some reflections on quite a long career in safety, engineering, and other things, and then some stuff that hopefully you will find interesting and useful about safety work in industry and working for government.
Context: my Career Summary
I’ve got three areas to talk about, operations and support, projects and product development, and consulting.
I have been on some very big projects, Eurofighter, Future Submarine Programme, and some others that have been huge multi-billion-dollar programs, but also some quite small ones as well. They’re just as interesting, sometimes more so. In the last few years, I’ve been working in consultancy. I have some reflections on those topics and some brief reflections on a career in safety.
Starting Out in the Air Force
So a little bit about my career to give you some context. I did 20 years in the Royal Air Force in the U.K., as you can tell from my accent, I’m not from around here. I started off fresh out of university, with a first degree in aerospace systems engineering. And then after my Air Force training, my first job was as an engineering manager on ground support equipment: in General Engineering Flight, it was called.
We had people looking after the electrical and hydraulic power rigs that the aircraft needed to be maintained on the ground. And we had painters and finishers and a couple of carpenters and a fabric worker and some metal workers and welders, that kind of stuff. So I went from a university where we were learning about all this high-tech stuff about what was yet to come in the aerospace industry. It was a bit of the opposite end to go to, a lot of heavy mechanical engineering that was quite simple.
And then after that, we had a bit of excitement because six weeks after I started, in my very first job, the Iraqis invaded Kuwait. I didn’t go off to war, thank goodness, but some of my people did. We all got ready for that: a bit of excitement.
After that, I did a couple of years on a squadron, on the front line. We were maintaining and fixing the aeroplanes and looking after operations. And then from there, I went for a complete change. Actually, I did three years on a software maintenance team and that was a very different job, which I’ll talk about later. I had the choice of two unpleasant postings that I really did not want, or I could go to the software maintenance team.
Into Software by accident as well!
I discovered a burning passion to do software to avoid going to these other places. And that’s how I ended up there. I had three, fantastic years there and really enjoyed that. Then, I was thinking of going somewhere down south to be in the UK, to be near family, but we went further north. That’s the way things happen in the military.
I got taken on as the rather grandly titled Systems and Software Specialist Officer on the Typhoon Field Team. The Eurofighter Typhoon wasn’t in service at that point. (That didn’t come in until 2003 when I was in my last Air Force job, actually.) We had a big team of handpicked people who were there to try and make sure that the aircraft was supportable when it came into service.
One of the big things about the new aircraft was it had tons of software on board. There were five million lines of code on board, which was a lot at the time, and a vast amount of data. It was a data hog; it ate vast amounts of data and it produced vast amounts of data and that all needed to be managed. It was on a scale beyond anything we’d seen before. So it was a big shock to the Air Force.
More Full-time Study
Photo by Mike from Pexels
Then after that, I was very fortunate. (This is a picture of York, with the minister in the background.) I spent a year full-time doing the safety-critical systems engineering course at York, which was excellent. It was a privilege to be able to have a year to do that full-time. I’ve watched a lot of people study part-time when they’ve got a job and a family, and it’s really tough. So I was very, very pleased that I got to do that.
After that, I went to do another software job where this time we were in a small team and we were trying to drive software supportability into new projects coming into service, all kinds of stuff, mainly aircraft, but also other things as well. That was almost like an internal consultancy job. The only difference was we were free, which you would think would make it easier to sell our services. But the opposite is the case.
Finally, in my last Air Force job, I was part of the engineering authority looking after the Typhoon aircraft as it came into service, which is always a fun time. We just got the plane into service. And then one of the boxes that I was responsible for malfunctioned. So the undercarriage refused to come down on the plane, which is not what you want. We did it did get down safely in the end, but then the whole fleet was grounded and we had to fix the problem. So some more excitement there. Not always of the kind that you want, but there we go. So that took me up to 2006.
At that point, I transitioned out of the Air Force and I became a consultant
So, I always regarded consultants with a bit of suspicion up until then, and now I am one. I started off with a firm called QinetiQ, which is also over here. And I was doing safety mainly with the aviation team. But again, we did all sorts, vehicles, ships, network logistics stuff, all kinds of things. And then in 2012, I joined Frazer-Nash in order to come to Australia.
So we appeared in Australia in November 2012. And we’ve been here in Adelaide all almost all that time. And you can’t get rid of us now because we’re citizens. So you’re stuck with us. But it’s been lovely. We love Adelaide and really enjoy, again, the varied work here.
Adelaide CBD, photo by Simon Di Nucci
Part 2 will follow next week!
New to System Safety? Then starthere. There’s more about The Safety Artisan here. Subscribe for free regular emails here.
Our website uses cookies to provide you with the best experience. By continuing to use our website, you agree to our use of cookies. For more information, read our Privacy Policy on the "About" Page.
