Cannot see video? Go to http://www.apple.com/quicktime/ for QT browser plugin
Cannot see video? Go to http://www.apple.com/quicktime/ for QT browser plugin
by Prof. Derek K Hitchins
If you've never heard of systems engineering, you probably have some questions. If you have been a systems engineer for years, chances are you still have some questions, which you have put to one side while you get on with work. So, first off, why not take a few minutes to watch the Video Blog above - you might find it controversial... For a start, it suggests that systems engineering may not be exactly what a lot of people think it is!
Then, if you want more, there's plenty below:-
Trickier than you might think.
In fact, it seems to be one of the most overused words in the
English language.
So, let's try this:-
The simplest view of a system - yet one that is frequently overlooked - is that it is a 'whole' something or other: a whole person; a whole aircraft (including the crew); a whole set of laws; a whole enterprise or business; a whole platoon of soldiers; and so on. Why is this view of the 'whole' important? It became important when people observed that only wholes were complete, and only when complete could they exhibit properties, capabilities and behaviors. So, the aircraft without its crew is an inert artifact, sitting in a hangar, perhaps, leaking oil and aviation fuel into strategically placed drip trays. Add the crew to create the whole, and the combination of crew and craft can, together, take off, fly, perform some mission, recover, etc., etc. In other words, once whole and complete, it becomes a purposeful, functioning system
It was observed, too, that Nature made wholes: whole cells, whole animals, whole plants, whole everything. And that Nature seemed to be able to pack an awful lot into a very small whole; engineering, even at its best, is unable to create something as basic, yet powerful and sophisticated as a mayfly, which may live for only a day, yet which can fly, sense, smell, search out a mate, copulate, and so propagate its species...Nature created wholes that were special in another sense, too: the whole was somehow greater than the sum of its parts, and it was not possible to attribute any of these 'properties of the whole' to any of the rationally-separable parts...
This then was, and is, holism. Holism observes that wholes are special, that Nature makes wholes, that wholes may be more than the sum of their parts, and that these 'extra' properties, capabilities and behaviors could not be exclusively attributed to any of their rationally separable parts.
All of which helps us to formulate a useful defintion of 'system':
Perhaps the key feature of the definition is the word "interactions".
Why is this important?
But let's not get carried away - meanwhile, back at the definition. It may appear complicated, but then it has to cover a lot of cases:
all come together, then the result is "whiter than white". A trivial example perhaps, but it does work.
Systems have turned out to be very important. As the world becomes inexorably more complex, a systems view of the world becomes important to enable us to see the wood for the trees. Using systems ideas and systems methods we can solve complex problems, resolve complex issues, that could not be solved by conventional reductionist methods. And that involves addressing whole problems and creating whole system solutions to those problems - addressing only part of the whole problem may, in practice, make matters worse, not better. So, the idea of systems is important - it's a way of managing complexity.
The Thames Barrier is (part of) a complex system for combating flooding in low-lying areas of London. The Barrier is an example of how systems engineering can produce innovative - unprecedented - systems. If the Barrier were put in the wrong place, or if the designers had underestimated the tidal extremes that the barrier was intended to combat, then the Barrier would not work. Worse, it could cause flooding rather than prevent it.
So...yes, systems are important.
Sometimes it's easier to see what happens when people try to create complex systems and don't use systems engineering. Hubble was a recent, high-profile example. When the telescope was launched, it was discovered that the mirror had not been ground correctly. Perhaps the engineers should have tested all the parts together before launch, rather than wait until after launch to find the problem? At least, that's what sound systems engineering would have proposed.
So, why didn't NASA do full, pre-launch integration and test? I
believe the reason was "to save money". If so, the saving plan
cost a reputed $550M to rectify. Mind you, putting the
telescope right was turned into a PR triumph, and perhaps all is well
that ends well...
Sometimes it's easier to start-off by saying what you are not talking about - getting it out of the way, so to speak. Piecemeal does not address the whole problem: piecemeal development treats each part of some eventual system as independent. In the process, the developers of each separate part do their best, we might hope and expect, to produce the optimum part or product. So far, so good, but...
...Optimizing part of any system de-optimizes the rest. This message is pretty obvious if you think about it. Imagine some surgeon-type deciding to optimize the human heart by creating a new mechanical replacement.
Some students trying this as an exercise produced a fine mechanical heart. But:-
You see what happens when you try to optimize a part, instead of the whole system?
There are ways to optimize... The general approach is to measure the whole system in some way, and to vary internal parts until the whole system measure indicates some optimum point. This approach allows interactions and reactions to take place between the parts, which result in changed emergent properties, capabilities and behaviors...from whcih it is possible to determine the optimum arrangement/configuration of the various system parts such that they cooperate, complement, coordinate and contribute to best overall advantage.
Systematic engineering:-
We noted above that the properties, capabilities and behaviors of some wholes could not be attributed exclusively to any of their rationally separable parts - this is emergence. Essentially, systems engineering seeks to understand emergence, and to create wholes with emergent properties, capabilities and behaviors. See Designing and Creating Emergence, where the task facing systems designers and systems engineers becomes clearer...
Or, to boil it down to its essence, systems engineering selects the right parts, brings them together to interact in the right way, and orchestrates those interactions to create cooperation, coordination, complementation and contribution between the parts leadiing to synergisms and requisite emergent properties, capabilities and behaviors. 'Requisite' indicates that these synergisms are required to solve some original problem... This 'orchestration' can be quite complex: so much so, that it can become overlooked, not so much in the design process, but in the subsequent engineering processes, where the whole may be realized as separate parts which have to be joined. The 'joining' has to reconstitute the complete orchestration, else the emergent properties, capabilities and behaviors will not accrue. In some cases, this issue can be ameliorated by bringing together a number of subsystems which already contain their own, internal 'orchestrations,' such that the joing together of subsystems to create actions, interactions and reactions is greatly simplified.
To illustrate this important point, the figure illustrates how orchestration may be complex. (This is a repeat of the figure in Designing and Creating Emergence). Orchestration is shown as activating and coordinating all of the actions, routines and sequences that constitute a Primary Mission Function (PMF), while at the same time activating and coordinating a number of PMFs. This is, essentially, how a complex system such as the human body works, with the brain coordinating alll of the discrete sensor and motor activities which go to make up our PMFs, such as walking, running, jumping, hunting, gathering, shooting, etc., etc.
The following figure indicates that subsystems may be envisaged which containe much of this orchestration internally. For instance, a fighter interceptor aircraft might include in its list of PMFs 'conduct missile interception,' and 'defend against air attack.' Conducting a missile interception might involve:
During this SATKA routine, the fighter interceptor may itself be subject to attack by an enemy fighter, so it may have to deploy its own air defence systems - flares, short-range air-to-air weapons, guns, etc. - all of which may be complex, interacting subsystems.
Where extant subsystems are brought together, then, much of the 'orchestration; infrastructure may be contained within each subsystem, such that integration of the various subsystems may be simplified - but nonetheless vital. In the fighter interceptor example, the whole may exhibit emergent properties, capabilities and behaviors such as effectivess, survival, integrity, etc... But, it is all too easy in the process of integrating the parts to reconstitute the whole, to overlook essential interactions, such that the whole either behaves counterintuitively, sub-optimally, or even not at all.
Systems Engineering creates a broad strategy to reach a Goal, using the best information available at the time.
So, Systems Engineering is adaptable rather than rigid-prescriptive. It is truly dismaying to watch people trying to come to terms with systems engineering. Almost without exception, the first thing they try to do is to divide processes, products, etc., into separate boxes and bits. Imagine a surgeon trying to cure you by cutting out all your organs, putting them in a pile, examining and treating each one separately and then reassembling you. Woops.
This is the antithesis of systems engineering - the very problem that systems engineering is designed to overcome. Yet we seem so ingrained with Cartesian reductionism that we find it really hard to approach design and development in any other way. Just think a different way for a moment.
That surgeon uses X-rays and scanners to inform about the goings-on inside your body. He, or she, does not pull everything apart. Instead the surgeon works on any organ while it is in operation, intimately and dynamically connected to all the other organs. We must learn to do the same, not only when maintaining systems, but also when conceiving, designing and creating them, too. Instead of decomposition, we must learn to "magnify", to elaborate, to look inside at the detail while it is still in place, working and interacting in an environment provided by all the other parts and their interactions. So, elaboration is the order of the day; not, as I was taught, functional decomposition, which is closet reductionism...
Well, there seem to be as many definitions as there are systems engineers. Most definitions are a bit complicated, so let's try something really simple:-
The first definition emphasizes holism, and presumes that the solution system will have a lifetime, and implies a technological/business ethic. The second, broader, definition emphasizes optimality as opposed to effectiveness, and considers the problem or issue that requires solving. Both definitions identify systems engineering as both a science and an art.
- First Principle of Systems:-
- The properties, capabilities and behaviors of a system derive both from its parts and from the interactions between those parts.
- Corollary to the First Principle:-
- Altering the properties or behavior of any of the parts, or any of their interactions, affects other parts, the whole system and interacting systems
It follows from this that neither piecemeal, nor systematic, engineering have any real chance of success.
Using these principles as a guide, systems engineering creates processes which result in the careful
of systems. The processes are designed to create systems and services which are effective, adaptable and durable. The processes also address issues of "senility" decommissioning, so covering the full life cycle.
Clearly, systems engineering is about both
process and
product. Commercial systems engineering emphasizes the
process , while unprecedented systems engineering may
emphasize the (one-off?) product or process. There is no
real consensus about a standard process model for systems
engineering. Indeed it may be that there is no such thing as a
standard process model, since this implies that it is possible to
take a single approach to any problem.
Nevertheless, the following figure shows a high-level process model:-
The view presented above is an overview of the process. In practice, this apparently sequential series of activities may turn out to be less ordered than might be expected, as situations unfold. The figure also skates over the derivation of the requirement, and the exploration of the problem space - which must, presumably, have been undertaken at some stage. The whole model is set out to be systematic, and does not reveal the essential aspects of systems engineering, i.e., creating an optimal, balanced system solution that demonstrably solves some complex problem. It may be all there, but is not visible.
The following figure takes a different stance:
The top level shows the development of a solution concept, and refers to Steps 1-6 of the Systems Methodology. The output, the preferred system option, will be a set of matched systems specifications, devoid of any solution such as specific people, process or technology, which will be realized in the lowest, project row.
The second, or middle row, looks at the business aspects of the project. It reveals that part of the role of systems engineering is to design the impending project, and in particular identify the process an the tools and methods to be employed. The project will not be run by a systems engineer, however, but by a project manager, who will execute a project management plan agreed between himself and the system engineering process designers. The project team will employ, inter alia, systems engineers along with equipment engineers, reliability and maintainability engineers, software engineers, etc., etc. So, systems engineering can be seen in each of the three levels in the diagram: exclusively in the top row; working with business and project management in the second row; and working for the project manager in the bottom row.
Looking specifically at the bottom row, it can be seen that Steps 2 to 7 of the Systems Methodology are being applied. So, although this model is systematic, it is also systems engineering. Note particularly that the final proving sessions will include the original symptoms from the Problem Space - top left - so proving the overall process has, indeed, resulted in an optimal solution system to the original complex problem.
Note:
|
USA |
|
Japan |
|---|---|---|
|
Profit |
|
Survival |
|
Free |
|
Between circles |
|
Free Market |
|
Indiginization |
|
Production Push |
|
Market Pull |
|
Cost Plus |
|
Market Minus |
|
Adversarial |
|
Synergistic |
|
Specialist |
|
Homogeneous |
|
Hire and Fire |
|
Jobs for Life |
|
Specialization |
|
Multi-skilled |
|
Lowest Bid Wins |
|
Vital source - protect |
|
Supplier stocks |
|
Nobody stocks |
Japan is already commercially-based. The West is struggling with transition, still dominated by its Cold War defense heritage. Both parties seem to be overlooking item 3.
The archetypal modern approach. Often criticized for being slow, since each stages is required to be finished and completed before going on to the next. This waterfall approach has the effect of maintaining proper balance between the developing parts, however, and the waterfall approach is much easier to manage than other approaches, all of which can be seen as variations on this archetype.
the Spiral is employed where those creating the solution are uncertain as to the technology, or perhaps even the overall solution. A series of prototypes are produced and tried, with the creators learning as each prototype succeeds or fails. The spiral can be unwound, when it appears as a waterfall.
Disguised waterfall, using an eclectic collection of techniques
Concurrent engineering is popular as a means of reducing time to market, and of cost - which is often seen as proportional to time. There is something of a risk, in the context of telescoping activities, that crucial information will emerge only late in the execution of some activity, rendering earlier outputs from that activity in adequate or even incorrect. If the earlier outputs have been used by successive activates, it may be necessary to rework some of the activity network. In the worst case, there can be a ricochet through the project. Essentially, then, concurrent engineering can result in a project that is somewhat brittle, i.e., susceptible to shock.
This is a straightforward approach, as the figure shows. It totally eschews all notions of reduction, being instead entirely based on synthesis. It presumes that the customer knows what he/she wants and needs - not always the case. Customers sometimes know what they want, but rarely know what they need.
One view of systems engineering is of a series of procedural phases. This is, to be sure, much more a view of systematic engineering than of creative systems engineering. However, it is a view held by many engineers, and so is included here.
The figure above shows one notional phase, Phase N. The input to this phase is the output from a previous phase, namely a specification of some kind. This is largely a data-driven view of systems engineering, i.e., that what flows through the project is an ever-increasing tide of information describing every aspect of the future solution system. See the table of specifications below:
In keeping with this notion of creating a tide of data and information about the solution system, a wide variety of skills is envisaged. A typical list follows:
The SE Project phases can be shown in waterfall form, see below. Note that Equipment Engineering and Software Engineering are not considered as Systems Engineering, per se, but are viewed as classic engineering, with all that implies in terms of reductionism, decomposition, etc., all of which are alien to systems engineering.
The same is true for the following diagram, which shows the outputs expected from each project phase.
The five project subsystems referred to are:
The following diagram is an organization chart, showing typical influences, activities, considerations and outputs. Note that Project Support activities apply across the board.
It may be practicable to organize all of the above into one machine-supported system for conceiving and creating system solutions to complex problems. The picture above presumes a number of such systems at various sites. The whole program would consist of a set of projects, with the whole set constituting the whole solution system. Each major part/subsystem/partition of the overall solution system would itself be a major system, and would be subject to a team of analysts and engineers using SEAMS to support their activities. Built into SEAMS would be, not only the specifications from above, but also the tools from the so-called Shadowboard below, which shows the range of tools, methods and techniques often used by system engineers and others working on systems projects.
Well, that's just a flavor of one of the most important subjects about at the present time. If you want to know more then you might consider joining INCOSE the International Council on Systems Engineering.
Last updated: 2007