4. Breaking it Down

One thing I do a lot with any engineering problem is break it down into smaller elements. This approach works with many different types of “thing”:

• Breaking a single broad requirement into smaller, more achievable requirements

• Taking a safety goal for a system to be safe and developing arguments that must be satisfied for that to be the case

• Breaking down a hazard into contributing causes, faults and failures

• Breaking down a system into subsystems and components

• Learning a complex topic by breaking it down into smaller bitesize chunks

This approach is something that is quite intuitive, and many people probably do it without thinking. But by formalising it, documenting it and even diagramming it, it becomes a more powerful tool.

Let’s start with the idea of our rocket. We need a rocket, and we need some way to launch it. So, in order to achieve a demonstrator, there are two key systems required:

What is the rocket though? We don't know exactly yet, but we will need some sort of body. And most rockets have fins don’t they? And they are a bit pointy at the front; more pointy than an inverted water bottle in any case. So:

A launcher needs to be able to support the water-laden rocket. It also needs to be able to pressurise it. It may also need some way to control the launch.

There we go. All sorted. We could check this diagram against our requirements. If we can show that all of our user requirements would be met by this, we can get on with designing. However, there are a few things missing.

Not only do I want to show some exciting rocket launches, but I also want to use the experience to teach students some STEM concepts. So although it’s not strictly a system, I am going to add this information too. This need is also reflected in my user requirements.

Education will be mostly maths and physics, but also the concept of engineering. (Students will study maths and physics but not necessarily have awareness of how they can be applied to engineering. One key aim of my work in STEM is to show how the subjects relate to real world engineering.)

Safety is clearly important, but why does it have its own section in this structure? Isn’t it inherent within making a demonstrator that is suitable for schools? Yes, but...

Safety is a big part of my proper job. The efforts that engineers go to when working with safety critical systems is extraordinary, and I recalled a visit to a manufacturer when thinking about developing a project like this. Whilst I was there, I witnessed a system being emulated by two machines. They were essentially PCs in a box, but the hardware required for them to behave as the real system seemed to involve getting hold of the noisiest relays I’ve ever heard.

Being able to explain the clicking and clunking of a system running through its checks before operating seemed like a useful way to inspire students. Interlocks, state indicators, warning lights, etc. should all add a bit of excitement. Even the humble switch can be brought to life when you show a guarded aircraft-grade switch to a class and ask them to suggest why there is a yellow and black cover, and why it’s so difficult to operate.

The other side of this particular coin is that I would like to learn more about how such systems are designed, the considerations that are taken and how it affects the result. So with all that in mind, I would like to be able to demonstrate how the rocket and its launcher can be kept in a safe state until it is ready to operate, and how that is assured by the design.

Breaking down my idea into a group of different, but related packages of work, systems or subsystems will allow us to focus time on specific elements. This is helpful, but what we must also remember is that there are often interdependencies between different systems or packages. The work breakdown structure brings with it the risk of getting stuck in silos, something which we must take time to test for and prevent as much as possible.