Systems World

DAD.mov. Cannot see video? Go to http://www.apple.com/quicktime/ for QT browser plugin

• The file DAD.mov identified by urn:sha1:6XZUIHCZZAENRVC5Y3Y56JDVY44XVMEB is licensed to the public under the Attribution 3.0 Unported license.

"The art and science of creating optimal system solutions to complex problems".

 

Even simpler than that, Systems Engineering is creating systems by bringing together other systems: so, if you like, Systems Engineering is synthesising* from, or using, systems—always remembering that a system can be many different things: mann, machine, team, organization, company, etc. Compared with some of the horrendously complicated definitions/descriptions of systems engineering, then, here is the simplest definition of systems engineering:

"Systems engineering is synthesizing a complex system from less complex systems"

* Synthesize: combine a number of things/systems into a coherent whole.

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:-

Contents:-

• What is a system - real, mental construct?
• Are systems important?Why? What's the point?
• What is systems engineering?Engineering, management, common sense - none of these?
  • It Isn't Piecemeal Development
  • Systematic engineering
  • Essential Systems Engineering
• Can we define Systems Engineering?
• Whole System Principles
• Is systems engineering about product, or process?
• How does SE relate to Business?
• Different Approaches to "Global" Systems Engineering
• Systems Engineering Strategies
• Organization for Systems Engineering
• SEAMS - Systems Engineering Analysis and Management Support

What is a System?

Trickier than you might think.

• Gamblers say they have a "system" when they think they can beat the tables.
• Washing powder manufacturers have "washing systems".
• Aircraft have avionic systems, engine systems, airframe systems.

In fact, it seems to be one of the most over used words in the English language.

So, let's try this:-

System

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 behaviours. 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 creates wholes that are special in another sense, too: the whole is somehow greater than the sum of its parts, and it is 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':

A set of complementary, interacting parts with properties, capabilities and behaviors emerging      both from the parts and from their interactions to synthesize a unified whole

Perhaps the key feature of the definition is the word "interactions".

• What distinguishes a System from a pile of bits is that, in a system, the parts interact with each other to produce "properties, capabilities and behaviors" of the whole.
• So, while a pile of bits has properties - mass, volume, etc. - none of them emerges because of interactions between the bits.
• On the other hand, things like survivability, agility, intelligence, adaptability, situational awareness, strategic planning, etc., etc., do emerge because of interactions between the parts

Why is this important?

• Because of the interactions, a system is both dynamic and complex; systems may be able to do things, to exhibit whole system properties, capabilities and behaviors that none of their parts exhibits.

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:

• Some systems, it seems, comprise a variety of different parts which fit together - a watch is a system for telling the time.
• Other systems are processes, series of activities which together provide some service - the gambler's process for winning is his system. Washing powder manufacturers refer to their washing system - by which they mean that if:-
  
  • the right powder
  • the right water
  • the right washing action, and...
  • the right rinsing action

all come together, then the result is "whiter than white". A trivial example perhaps, but it does work.

• What emerges, white washing, does so because of the interactions between the parts.
• If any one of the parts is missing, the desired emergent property, white washing, will fail to emerge

Start

Are Systems Important?

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 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...

Start

What is Systems Engineering?

First, What Systems Engineering isn't:-

It Isn't Piecemeal Development

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.

• Perhaps it could be more reliable - let's give it long-life bearings.
• Why not do away with pulsing and produce a steady pressure, instead?
• It has to work for a very long time, so it will need a durable power source - nuclear, perhaps?
• ...and so on.

Some students trying this as an exercise produced a fine mechanical heart. But:-

• It would have been too large to fit into the body,
• it was so heavy that it would have unbalanced the "user",
• the power supply would have been harmful, long-term, to the rest of the body.

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.

It Isn't Systematic Engineering.

Systematic engineering:-

• Break processes into sub-processes, activities. Fit parts into plan. Follow plan.
• Standard method for Project Management and Business Process Re-engineering
• Insidiously plausible, but...
• ...ignores relationship between parts,
• ...ignores changing circumstances
• Better than piecemeal, but...
• ...far short of True Systems Engineering.
• Optimum Route to any Goal is not some predetermined, fixed path. Changes with Time, Threat and unfolding Situation.

Essential Systems 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 behaviours. 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 leading 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:

• detecting, locating, identifying and tracking a target - using a radar subsystem
• manoevring to an engagement configuration - using the various aircraft control and propulsion systems
• passing target coordinates to the air-to-air missile subsystem
• arming the missile
• launching the missile
• observing the results of the engagement
• ...all of which amounts to SATKA - surveillance, acquisition, tracking and kill assessment - in military speak.

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.

• It makes intelligent choices, aware that it is impossible to know everything in advance.
• Systems Engineering continually re-evaluates, especially when situations change, unforeseen circumstances arise.
• Within the broad strategy, the route to the Goal is re-evaluated.
• If necessary, systems engineering will back-up and go around, or circumnavigate.
• Essential systems engineering continually seeks the most efficient and effective route to the Goal

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...

Start 

Whole System Principles

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

• conception
• design,
• optmization
• development,
• test,
• integration,
• proving,
• installation and
• introduction into use 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 in the figure.

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:

1. The original application of the Systems Methodology may have resulted in a number of requisite systems. This diagram could refer to the realization of all of those systems, or instead to only one of them, it being presumed that the others are being addressed elsewhere as part of an overall program.
2. Application of the Systems Methodology is likely to result in the specification of a nonlinear dynamic solution system. It is entirely possible for the parts/subsystems to be created as linear elements, using linear processes, yet for the whole system, when reconstituted from the parts/subsystems, to behave as a nonlinear dynamic solution system.
3. The diagrams immediately above this note are typical of those used to describe the organizational process/procedure of systems engineering in companies and corporations. What such diagrams can easily overlook is the nature and substrance of the activities being undertaken. 

Start

Different Approaches to "Global" Systems Engineering

 

• Western approaches, typified by US Innovative aerospace solutions e.g. Neil Armstrong on the Moon
• Japanese approaches - progressive improvement in production of traditional commercial consumer products e.g. Toyota car manufacture

USA                                                   Comparison                                    Japan

Profit                                                   Objective                                          Survival

Free                                                  Competition                          Between circles

Free Market                                        Regulation                                Indiginization

Production Push                                 Assembly                                      Market Pull

Cost Plus                                           Pricing                                    Market Minus

Adversarial                                        Contract                                       Synergistic

Specialist                                            Defence                                     Homogeneous

Hire and Fire                                      Labour                                          Jobs for Life

Specialization                                      Skills                                          Multi-skilled

Lowest Bid Wins                                Suppliers                           Vital source - protect

Supplier stocks                                Inventory                                   Nobody stocks

What's Driving the different approaches?

1. Defence-based systems engineering concerned directly with satisfying the customer and user
2. Commercially-based systems engineering concerned directly with business survival, profitability and growth which will require customer and user satisfaction, as a means to an end
3. ...and then, of course, there is space exploration, where the value of systems engineering is in the ability to achieve the goal - without systems engineering, it would probably not be achievable at all - at any cost!

Japan is already commercially-based. The West is struggling with transition, still dominated by its Cold War defence heritage. Both parties seem to be overlooking item 3.

Start

Systems Engineering Strategies

 

Waterfall Model

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.

Spiral, or Helical, Model

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 is produced and tried, with the creators learning as each prototype succeeds or fails. The spiral can be unwound, when it appears as a waterfall.

Concurrent/Simultaneous Engineering Model

Disguised waterfall, using an eclectic collection of techniques

Two main themes, both seeking reduced time to market

 

1. Telescope sequential activities

2. Team design

• contributions from development, manufacture, integration, commissioning, installation, operation and maintenance
• Item 2 de facto approach to waterfall since the 50s. Basis of multidisciplinary SE

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.

Goal-Oriented Systems Engineering

This is a straightforward approach, as the figure shows: follow the numbers to follow the process. 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.

• Focused on Future Vision and its EPs
• Inspires, leads through shared vision, does not control
• Holistic, true SE
• Avoids premature cost limitation, which emasculates solution
• EP strategies effective first, economic second
  • effective more important than economic
    • "ineffective" does not work, wastes time and money
• Correlating, harmonizing various strategies for different EPs
  • crucial to success
  • may require reappraisal of selected strategies
• Ideal for Unprecedented Systems and for managing development as parallel, semiautonomous projects

Start

Organization for Systems Engineering (from Putting Systems to Work, Prof. Derek K Hitchins, Wiley, 1992)

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:

Table of Specifications

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:

1. the operational system to be delivered;
2. the system for maintaining it during its development;
3. the simulation system needed to prove it prior to delivery;
4. the user's in service simulation facilities that will be rquired to maintain it in operational service; and
5. the in-service maintenance system needed to provide through-life support

The following diagram is an organization chart, showing typical influences, activities, considerations and outputs. Note that Project Support activities apply across the board.

 

Start

SEAMS - Systems Engineering Analysis and Management Support Environment

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 flavour 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.

Start

http://www.hitchins.nett