What is System Engineering?

It seems as if everyone is a system engineer these days. This article describes the relatively new technical specialty of System Engineering - what it is, how it relates to design and management, and the several schools of System Engineering you may use or encounter. This article is based on several kickoff presentations I have given, and is not yet (and may never be) complete.

What is a System?

The best definition of a system I have heard is: A system is a collection of diverse elements or capabilities, which, when combined, provide an emergent property.

A system is not a question of size. Consider the concept figure below:

The above is obviously a system, containing hardware, software, interface specs and requirements, communication standards of several flavors - the works. This is what most people think of when they use the word "system". An emergent property is expressed - in this case, transit dispatchers know where specific mobile assets are at any time, and whether they are within operating tolerances based on established schedules and limits.

Now let's take a closer look at a component of this system - a bus in the far upper left hand corner, for example.

Notice that it has all the elements of a system - hardware and software components adhering to diverse operational requirements, communication standards, and functional roles. Presented this way, there is little conceptual difference between the overall system in the first figure and the vehicle system above. Since it is a stand alone component of a larger system, perhaps you would call it a "sub-system". But then, almost everything is a sub-system, as you will see below.

Let's zoom in a little further. Below is a block diagram of the Vehicle Processing Unit for the installation above, which can be found in the lower right hand corner of the Vehicle block diagram above. The green section below was implemented as a single printed circuit card assembly, but that is an implementation choice. Notice that this component still shows all the elements of a "system". It combines hardware, software and mechanical components, connected by interface protocols, to provide an emergent property - vehicle information processing to integrate the vehicle sensors to provide status and control of the vehicle.

We could zoom in once more an show that the Processor in this design is actually a System on Chip (SoC), with it's own components and interfaces, but I think I you get the idea.

There is a fractal like similarity between the three drawings. As you zoom in or out, the pattern repeats. Functional component sets are connected by communication channels. Several technologies combining to provide a specific emergent function, which none could exhibit alone. Zoom in, zoom out - you see the same thing, over and over.

So a system is not a matter of size. It is not a matter of complexity. It is the combination of differing techniques and technologies to provide an emergent function, no matter what level it is performed at. System engineering is performed at all levels of design.

A microwave oven is an excellent example. It has mechanical system, an electrical system, an RF system, and a user interface that includes some firmware, a processor, I/O, etc. It is a "system of systems", you can buy for $49. And it is a component in the kitchen system, which itself is part of your dwelling system, along with your heating/ventilation subsystem, security subsystem, waste disposal and cleansing system, entertainment system, etc.

Then what is System Engineering?

System Engineering is relatively new, when compared to mechanical engineering (200 years?), electrical engineering (100 years?), civil engineering (10,000 years?), etc. It is not a completely settled engineering specialty. But I will take a crack at defining it here.

The goal of System Engineering is to enable the individual to, for a wide range of disciplines:

• • Combine Requirement Inputs

  • Make Design Decisions, and

  • Generate Requirement Outputs for the components at the next lower level.

System Engineering methods have been developed with the goal of being technical specialty agnostic, to generalize the specification and test of complex requirements. These techniques have been developed allow a system engineer to tackle any combination of specialties, be able to develop designs, and allocate requirements and testing to address all concerns, regardless of their source or stability. If the method is general enough, then what works for waste treatment plant design, will work for artificial limb development.

And if you believe that, you will believe anything. But that is the objective, and hey, some of the techniques are starting to get there.

Several schools of System Engineering have evolved based on working with different emergent properties. You will find the methods taught by some schools handle socially interactive applications very well, others are primarily for adding functions to large software applications, and others have been developed using a civil/architectural paradigms, etc. When in doubt, look to the the development basis of the system structure you encounter. It may not be useful to apply a social/user acceptance system method to a train braking system, but hey, the results would be interesting.

Are you a System Engineer?

System engineering is a relative term. In the past, most engineers were specialists, with very narrow, deep technical skills (RF - Power - Software Operating System). Only a small number of engineers were "Multi-Disciplinary". Now, almost all engineers perform what would be defined as system engineering. Very few engineers are pure technical specialists anymore. So if you are a modern engineer, you probably are a System Engineer. Or use many of the techniques of one.

Since you are a System Engineer, you should be aware of the System Hierarchy. Then you will realize you are also a Design Engineer, and an Implementer, all at the same time.

No matter how large or small the system, there is a constant hierarchy that is applied to everyone in the design chain. If you are the designer, your System Engineer is one level up from you, and your Implementer is the next level down. You are in there somewhere. Understanding the Design Hierarchy will help you understand what your inputs and outputs should look like.

Design Hierarchy

System Design

Detail Design

Implementation Design

• • The person above you in the design Hierarchy is your SYSTEM Engineer.

  • The person below in the design Hierarchy is your IMPLEMENTER.

This pattern repeats, from the top (Chief of Naval Security, a subsystem of the Navy) to the lowest level (design of base entrance barriers, whose implementers are civil construction contractors). A system engineer communicates requirements to the designer, and the designer provides feedback to the system engineer. This relationship is the same as the designer to the implementer. Typically, the "system" engineer will communicate and integrate the effort of several designers, and a designer to several implementers.

If you need more on this there is a more detailed explanation here: System - Design - Implementation Hierarchy.

So any school of System Engineering must include methods to pass tasks to designers at the next level down in the design hierarchy. This is the one of the primary skills you must master as a designer. These methods must be understood and accepted by both the system engineer and the designer, and the designer and the implementer. Note that the System/Design interface method may differ greatly from the Design/Implementation method, or it may be precisely the same, depending upon the level and emergent properties involved.

Are You A System Designer or an Architect?

Using the classical definition, a designer trades off approaches using one technology, like software, electrical or mechanical design. An architect trades off between disciplines - glass, steel, wood, block. Also an architect may direct the topology, that is, how components are related to each other, and their overall roles. An architect may only provide this interrelation, without specifying details of interface and performance.

Example - The approach being considered has power dissipation issues. Existing techniques may not be sufficient to provide the required emergent property.

Do you:

• • Require more elaborate (and expensive) heat sinks,

  • Implement more efficient (and risky) electrical designs, or

  • Use aggressive (but unproven) software techniques to limit system activity, thus reduce power consumption?

The above would be considered an architectural decision, since there are many, orthogonal ways to approach the solution. Another way to remember this distinction is to consider a conventional architect: She must trade off between wood, concrete, glass and steel, a system that moves people, air, and light. Once the structure is chosen to be steel, for instance, then a specialist can be directed to design the structure.

How "System" Are You?

• • How many types of inputs can you accept? Hard requirements only? Do goals and value points drive you crazy? User, reliability, recurring cost, certification, political restrictions?

  • How many technologies or component types can you integrate into a solution?

  • How many types of output can you specify? Printed wiring boards? Software component design? User interface? Network protocols?

  • What design levels can you work at?