Article - Issue 6, November 2000
Systems engineering – an educational challenge
Ken Hambleton FREng
Systems never go wrong – it’s the people involved that do
This article is not meant to be a definitive treatment of Systems Engineering, nor is it intended to offer a recipe for teaching it in Universities. It draws on the content of an address, slightly amplified in parts, that I gave to The Royal Academy of Engineering Visiting Professors’ Workshop at Churchill College, Cambridge, in September 1999. The aim of last year’s lecture was to stimulate discussion on the need for Systems Engineering, to indicate its essential features and to suggest how it might best be taught to aspiring systems engineers. If this article stimulates a similar discussion amongst Ingenia readers, then it will have admirably served its purpose.
The three working groups that were convened after my address at the Workshop last year all agreed that Systems Engineering is an increasingly important subject which needs to be incorporated into University teaching. They concluded that the basic principles of systems thinking should be introduced into all first degree engineering courses but that Systems Engineering is best taught as a specialist subject at postgraduate level. Students with experience in the challenges of applying a single-discipline engineering subject are better able to appreciate why a holistic systems view is necessary and what benefits it can offer.
So, what is Systems Engineering?
A System is what it is defined to be
As the name implies, Systems Engineering is concerned with studying a system in its entirety and not focusing on a single sub-system or technology area, as is often done by traditional single-discipline engineers. This implies an ability to define clearly what constitutes the system in question, in other words, ‘Where is the system boundary?’ This seemingly innocuous question lies at the heart of many systems engineering problems. Clearly, a system boundary has to be defined in order that the system can be referred to as an entity, i.e. as a system. Often the boundary is taken as read, or as obvious. But is it? Trains and railways frequently hit the news headlines, raising issues of system boundaries and divisions of responsibility. Both major political parties have referred to the need for a national transport policy and most of the electorate would sign up to this as an excellent idea. Many would say that it is essential to the well-being and wealth creation of a modern industrial nation. But what constitutes a ‘National Transport System’? Where is the system boundary? Does the word ‘National’ imply designing and building the system in this country as well as operating it in this country? Figure 1 illustrates the fundamental difficulty of defining a system boundary. There is no right or wrong way of defining a system boundary and the same system may be defined in different ways by different people for different purposes. At the end of the day the boundary can be drawn where the people concerned wish it to be drawn and, ‘The system is what it is defined to be.’ However, all the system stakeholders must agree with the definition for the purpose in question. A related issue that triggers much debate is whether the user should be included within the system boundary or not. The answer is ‘Yes’ and ‘No’. When considering system performance the user must be treated as an integral part of the system itself, as the system cannot be effective unless the user is present, but from a design and manufacturing point of view the user is usually treated as an external entity, albeit a very important one. Even the question of, ‘Who is the user?’ may be difficult to answer. Is the user of a large and complex medical instrument (such as a body scanner) the doctor, the clinical technician or the patient?
Physicists and mathematicians have been much concerned with defining system boundaries and with analysing system behaviour within those boundaries, but they have usually simplified or ignored the boundary conditions in so doing. Hence the concept of a ‘closed system’, defined as one that has no interaction with its environment in terms of energy or information exchange. Such systems are amenable to mathematical or physical reasoning as powerful aids to understanding. Unfortunately, all manmade systems are designed to interact strongly with their environment and to change it in some way or other. Why else would we spend time and effort in designing and building them? In other words, any practical system exists in order to interact with its environment and hence it cannot be considered as a closed system. A perfectly closed system can never be detected, let alone change the world.
The role of Systems Engineers
Look upwards and outwards as well as downwards and inwards
After defining the system boundary as their first activity, systems engineers must next consider the interaction of the system across its boundary with the environment. It is this interaction that gives the system its purpose, its raison d’etre. In other words, a holistic view of the system itself is not enough. The interface between the system and its environment is central to systems engineering. The requirement specification for a system can be considered to be the definition of its external interface, since it determines how the system must react to and react on its environment. Systems engineers must therefore look upwards and outwards into the environment as well as downwards and inwards into the system itself. Engineers have traditionally been good at the latter, but have not always thought sufficiently about the former. Hence the need for more education in Systems Engineering. I often illustrate this with the analogy of a jig-saw puzzle. There is little point in focusing only on the internal design and colours of a particular piece without ensuring that its external size, shape and the colours at the edges will fit correctly with the rest of the jig-saw.
It must also be remembered that the interaction of a system with its environment is reciprocal and dynamic. If a system is reacting with and changing its environment, then the environment will react back on the system in question, possibly leading to the need for further modification if the desirable performance is to be fully achieved, a lesson that those who drive around London each day on the M25 have learnt the hard way. The changed driving habits resulting from the existence of the London outer ring road have already rendered it virtually obsolete and in need of much higher capacity. Hence the role of the system engineer does not cease when a system is delivered but continues throughout the operational life of the system, in considering, designing and implementing improvements and in rectifying deficiencies. The safe disposal of a system also impacts on the responsibility of the systems engineer and, in the current climate of concern for the environment, this must be given due consideration during the design and development stages.
Why do we need Systems Engineering?
Modern systems are much more than a single headful
Why is there so much current debate on systems engineering? Is it merely a buzzword for an activity that good engineers have always carried out, or is it a specific subject that needs more attention today than has been given to it in the past?
It is widely accepted that systems are far more complex than they used to be, but what is complexity? Several factors are involved, of which the most obvious are size, topology, technology and convergence, together with the multi-disciplinary nature of most modern systems. The fact that interfaces between system elements are increasingly dominated by software also compounds the complexity due to the intangible nature of software and the difficulty of removing the unwanted emergent properties commonly known as ‘bugs’.
The term ‘convergence’ may need a brief explanation. Some years ago the sub-systems forming a system tended to be relatively independent, as classical system theory said they should be. For example an early aircraft cockpit had an array of independent dials, each connected to its own independent sensor. Today, a sensor may be multi-purpose and much of the information is presented on multifunction displays. The separate systems have converged into a macro-system in that they have to produce and handle data in a common format, a requirement which imposes significant additional constraints on the individual sub-system designers. Similarly, what used to be separately taught topics in electrical engineering, such as communications, computing, video and entertainment, have all coalesced into an amorphous mass of Information Technology which is in danger of becoming too much to grasp as a single subject. I believe that the convergence of technologies and disciplines is the dominant reason that Systems Engineering is a necessary and challenging topic for all engineers to study.
All these complexity factors lead to the same result. Modern systems are simply too large for a single person to fully comprehend in detail; they are bigger than a ‘headful’. Dividing or partitioning them into smaller, manageable sub-systems is a powerful technique but must be carried out with experience if it is to be effective. Partitioning also implies the need to manage the interfaces between the subsystems and if the effort involved in doing so becomes too large then nothing will have been gained. In this respect, system partitioning is more than simple reductionism where the individual parts are assumed, either implicitly or explicitly, to have minimum impact on each other. When partitioning systems, designers should aim for minimum interactions between sub-systems, but must recognise that in practice this cannot be achieved, since it is the interactions between the sub-systems that result in the emergent properties of the overall system. Successful partitioning and the subsequent integration and testing are therefore key activities in successful Systems Engineering, involving the understanding and control of all interactions across the internal interfaces as well as of the emergent properties which impact on the external environment.
The golden rule for partitioning is not to create interfaces where the interactions are complex and difficult to manage; otherwise the subsequent integration and testing will be unduly complicated, with a high probability that the emergent properties of the system will be impossible to predict and control. Returning to the earlier theme of transport systems, the division of the rail transport system into separate track and train companies provides a salutary example. The mechanical interface between train and track may be relatively simple and easy to specify, but the information interface, including the safety and signalling features, is more challenging. Finally, the contractual and legal interfaces compound the engineering problems and add to the risk that investment and management decisions may not be able to be taken for the good of the transport system as a whole.
The basic Systems Engineering Process – the simplified ‘V’ diagram
Don’t divide where you can’t reassemble and test
Several different Systems Engineering process models have been proposed for the design and manufacture of complex systems, each with its own strengths and weaknesses and each with its own enthusiastic advocates. One commonly used model is the simple linear ‘Waterfall’ process shown in Figure 2, often attributed to Royce1 and originally used to depict the design and implementation of software. A derivative of the ‘Waterfall’ model is the ‘V’ diagram shown in Figure 3 (see for example Forsberg and Mooz2), which illustrates the need for feedback and iteration between successive stages and which is folded to show the relationships between the early design activities and the subsequent integration and testing, emphasising that the whole process must be carefully planned from the start.
The bare bones of the process are shown in Figure 4, which strips it down to five basic activities, namely design, partition, manufacture, integrate and test. Design, manufacture and testing are already taught as part of most specialist engineering courses as they are the essence of all engineering projects. The problems associated with increasing system complexity introduce the need for the other two activities, namely partitioning and integration. Figure 4 illustrates the complementary relationship between these two activities and the need to plan them together rather than treat them as separate activities with the hope that integration ‘will be all right on the night.’
A hierarchy of systems
One man’s sub-system is another man’s system
Having partitioned a system into its main sub-systems, these in turn can be partitioned into assemblies, which in turn can be partitioned into subassemblies, and so on down to the level of indivisible components such as nuts and bolts. There is no good reason why sound systems engineering principles should not be applied at all levels of partitioning. In other words, a hierarchy of systems exists, with each system at any level being composed of smaller sub-systems whilst at the same time being merely a sub-system of a higher level system. Figure 5, taken from Putting systems to work by Hitchins3, illustrates the principle of hierarchy clearly and simply for a generic ‘Application System’. At any level in the hierarchy, the levels above and below are equally important. A competent system engineer must consider the interfaces with systems in the surrounding environment at the higher level, as well as the lower level sub-systems which must operate together to produce the emergent properties of the system in question. Hence, as said earlier, systems engineers must look upwards and outward into the environment as well as downwards and inwards into the system itself. They need a broad perspective as well as a grasp of detail. When designing a new system it is necessary to establish how far to look up and down the hierarchy in order to anticipate and control the risks and uncertainties involved. The wrong nuts and bolts at the bottom level can prevent the total system from working correctly. A wrong assumption about the external operating environment can be equally disastrous.
How can we best teach Systems Engineering?
A little knowledge may be dangerous, but it is better than ignorance
The Royal Academy held a two-day Visiting Professors’ Workshop at Churchill College, Cambridge, in September 1999. There were approximately 120 attendees, mainly industrial Visiting Professors appointed by The Academy to foster relations between academia and industry, together with leading academics from UK Universities. The format consisted of addresses by three keynote speakers on hot topics, each followed by parallel discussion groups with a rapporteur on each topic to relay the conclusions back to a plenary discussion session. The three topics chosen were, ‘Good Practice in the Teaching of Engineering Design’, ‘Systems Integration – the Challenge for Higher Education’ and ‘Sustainable Development Indicators’. I was the invited speaker for the second topic. My talk considered the educational challenges associated with Systems Integration and Systems Engineering, reflecting many of the above points, and I deliberately refrained from taking part in the discussion groups in order not to influence their debate.
After the inevitable discussion of what constitutes systems engineering, all three groups readily agreed that Systems Engineering needs to be more widely understood and that higher education has an important part to play in this process. They reached similar conclusions to my own, namely that Systems Engineering as a specialist subject is best taught at postgraduate level when students have cut their teeth in their own specialist area and have experienced the difficulty of designing and building individual system elements. However, there was also a widely held view that the basic principles of Systems Engineering should be included in all engineering first-degree courses, with examples and case studies drawn from the particular engineering specialism, in order to teach students the value of taking a holistic approach to practical problems.
Again using the theme of rail transport, a good example for Mechanical and Civil Engineering Courses could be the Channel Tunnel. I have heard it said, but unfortunately I cannot remember who said it, that to build the tunnel and operate one train a day requires good engineering, but to build the tunnel and be able to operate 20 trains an hour requires good systems engineering. The example would teach students the need to consider the wider issues of rail operating infrastructure and management in addition to the mechanical and civil engineering issues involved. In other words it would illustrate the need to look upwards and outwards as well as downwards and inwards. A related example for Electrical and Electronic Engineering Courses could be drawn from the problems of railway signalling, which involves sensing and processing the necessary information and displaying it reliably to the train driver. As well as highlighting the principles of system partitioning and integration, this would emphasise the need for the engineering design to consider undesirable emergent properties such as earth loops or transient interference from other electrical equipment. Readers will no doubt quickly think of suitable examples from other engineering disciplines.
It should therefore be relatively straightforward to introduce the rudiments of Systems Engineering into undergraduate engineering courses, although it raises the question of whether a common syllabus should be adopted and if so who should define it. As mentioned above, design, manufacture and testing are already taught in specialist engineering courses. It would be a simple extension to include the concepts and basic principles of partitioning and integration, together with an appreciation of the different types of systems architecture. It is often argued that engineering curricula are already bursting at the seams, so that nothing can be omitted to make room for new material, but this has not prevented recent syllabus changes to encompass ‘Engineering with Business Finance’ or ‘Engineering with Management’ at many of the forward-looking universities.
The relationship between Systems Engineering and Management
Systems Engineering and Project Management are two sides of the same coin
Speaking of management neatly brings me on to the need to manage systems engineering and to the convergence between Systems Engineering and Project Management. These two subjects are often portrayed as separate disciplines but they have many common features and their practitioners should be working towards a common goal – that of producing a system to satisfy given requirements of performance, timescale and cost.
I have always believed that engineering and management are two sides of the same coin. Complex systems cannot be engineered properly without proper management and they cannot be managed properly by people who don’t understand the engineering involved. Hence I believe that they should be taught together as a single discipline and it is no coincidence that the MSc Course in Defence Systems Engineering which I have been teaching successfully for almost a decade has about a third of its syllabus devoted to management topics.
There are positive signs at the present time that both systems engineers and project managers are recognising the need to co-operate more closely together, exchanging views and challenges in meetings and conferences, and I believe that this convergence should be given every encouragement.
If systems engineering is largely common sense, then why is it so rarely practised?
Readers may feel that most of what has been said in this paper is no more than common sense – and I would agree. The problem is that common sense is just as difficult to define as Systems Engineering. As the jazz pianist Fats Waller once said when asked to define rhythm, ‘Lady, if you got it you know what it is. If you ain’t got it, it ain’t no use me trying to tell you what it is.’
As my quotation at the start of this paper implies, Systems Engineering is not merely an engineering discipline but is also a people-related activity concerned with structuring and managing the teams of multidisciplinary specialists that must work harmoniously together if complex systems are to be designed, implemented and operated effectively. It is underpinned by sound engineering principles, but it is still a relatively immature subject when compared with the traditional engineering disciplines, so the precepts, processes and practices are still being debated, developed and improved. Common sense is needed to apply the principles and processes effectively. In any event, too rigid adherence to processes can stifle the creative flair that is a necessary part of system design. As Leonardo da Vinci is reported to have said, ‘Study the science of art and the art of science. Learn to see and remember that everything is connected to everything else,’ a statement that would alone have qualified him to be labelled a systems engineer had his many other activities not already done so.
Hence, we should apply common sense in the teaching of Systems Engineering, relating it to the aptitude and experience of the students concerned. This is consistent with an introduction at undergraduate level, framed in the language and examples of the individual engineering disciplines but with the recognition that the concepts and principles have wider application and that systems transcend traditional engineering boundaries. On graduation, the students will then be equipped to recognise that many of the engineering challenges with which they are faced stem from properties of the system as a whole and will become eager to understand more about Systems Engineering as a multidisciplinary activity. Specialist courses which offer this deeper understanding already exist at postgraduate level, building on the experience of the students in their individual disciplines and broadening them for their future roles as systems engineers or project managers. The challenge at the higher educational levels is to ensure commonality in terms of the language, semantics and principles taught, whilst not stifling the flexibility and freedom of thought necessary for Systems Engineers to develop creative and innovative solutions to future system problems.
Finally, Figure 6 summarises the main themes of the paper in phrases that may stick in the memory when the text has been long forgotten.
Royce, W. (1970) Managing the development of large software systems: concepts and techniques, WESCON, August; reprinted in Ninth International Conference on Software Engineering, IEEE Computer Society Press, pp. 328–338.
Forsberg, K. and Mooz, H. (1991) The relationship of system engineering to the project cycle, proceedings of the National Council for Systems Engineering (NCOSE) Conference, Chattanooga, TN, October 1991, pp. 57–61.
Hitchins, D.K. (1992) Putting Systems to Work, John Wiley & Sons.
Professor Ken Hambleton FREng
Professor of Defence Engineering, University College, London