Arbutus Technical Consulting

At the INCOSE UK 2008 Autumn Assembly, Professor Philip M’Pherson discussed some interim findings from a survey of views on the value of systems engineering. He confronted the assembled systems engineers with two apparent anomalies;

• Although systems engineers like to keep the word ‘engineering’ in the title of their discipline, most of the activities that they report that they perform would fall within the scope of what most people would call ‘management’
• Although most of the papers in systems engineering journals and conferences discuss the creation of new systems, most systems engineers spend their time maintaining and changing existing ones

Both of these observations resonated with me and I’d like to return to the first point in a later article.

Let’s take the second point here. It struck a chord with me because I had been working in rail systems engineering and there is an extent to which, since Brunel and Stephenson, the rail industry has hardly ever created a brand new system. Almost all the time, even if we are building new trains or signalling systems, the hard part is to fit them into the existing railway system and, at this level, we are always changing and maintaining something that exists.

I had recently been attached, as a systems engineer, to a project concerned with replacing the points at the approach to a major UK railway station. It was perfectly obvious to me that hard problems in the project were systems problems. Let me give you an example.

Before the project a large number of cables had been threaded through the ‘ballast’ (the gravel that the rails are laid on). However, modern standards prohibited this and some other solution had to be used, such as putting the cables on a bridge over the tracks, putting them in a tunnel under the tracks or threading them through hollow sleepers. Considerations to be taken into account included:

• Making sure that any bridge would not interfere with drivers’ view of signals
• Making sure that it was possible to erect a crane near the site of any bridge in order to construct it
• Making sure that any tunnel would not interfere with the foundations of anything else
• Making sure that there was time in the very tight construction schedule to build any tunnel
• Making sure that there was time in the very tight construction schedule to test any equipment affected by moving the cables. The geometry of the solution would make a difference. If cables could be moved without cutting them, less time would be needed
• Making sure that any hollow sleepers would hold the rail at the right angle, which changes as one approaches points

All the individual parts of the design are reasonably straightforward; the problems are with how it all fits together. As I said, a true ‘systems problem’.

However I found it frustratingly hard to deliver value using traditional systems engineering methods, such as requirements engineering and architectural design. It felt a bit like trying to use a metric socket set on an old British car with imperial nuts and bolts – the tools were obviously designed for this sort of thing but they did not quite fit the problem to hand.

I formed the view that a large part of this was because the methods were intended for constructing new systems and the problem here was to change an existing system. For some while, I thought that this was a problem which was peculiarly acute in the rail sector but INCOSE members familiar with other sectors put me right. Changing military communications systems has all of the same problems. As another example, an aircraft carrier will stay in service for several decades and will be fitted, during the course of its life, with technology that was not conceived of when it was first built.

To cut a long story short, I had the privilege to lead a cross-sector INCOSE UK working group to investigate this problem further. We have recently delivered our report (which you can read here). We concluded that, while the principles underpinning SE remained the same whether one was building a new system or maintaining an old one, guidance on systems engineering of existing systems could be improved in six areas:

• Through-life Validation: Establishing whether the system and the user needs have drifted apart and some action  is required.
• Domain Knowledge: Obtaining relevant facts about the environment of the system to be built.
• Architecture Design: How to change an systems architecture, rather than how to create one. And how to find out what the current architecture is if no-one has written it down
• Incremental Acquisition : Planning out a process which breaks the work down into small bits so that the system can be returned to service after each bit has been done
• Configuration Management (CM): Integrating project CM with system CM:
• Information Management: Maintaining accessibility and modification of information throughout the life of the system

We are fairly sure that each of the ‘gaps’ above is real but doubt that we have got them all. The working group will carry the work forward in 2009 but now with international involvement.

I think this work is important. If you want to be involved or to be kept informed, please let me know.