Introduction to Systems Engineering

Systems engineering is defined in many texts. Rather than repeat the standard definitions at this time it is helpful to define these terms in the simplest possible manner. The reason is that having very simple definitions helps us to consider things from a fundamental point of view, which makes it easier to come up with new insights. Later traditional definitions are presented and comparing the two may give new insights. New insights are needed in order to understand new methods and, eventually, to develop improved methods. This chapter, presented in several articles, defines four fundamental tasks that systems engineers perform, provides definitions of systems engineering, compares the rolls of systems and design engineers and shows how systems engineers fit in a modern product development organization. The four systems engineering tasks are deliberately defined before defining systems engineering or systems engineering processes. Although this seems out of order it helps take a fresh look at systems engineering methods. To set the stage for defining the four tasks of systems engineering we look at the overall product development process or development cycle as it is usually called.

The Product Development Cycle

In the exercises at the end of the last post the reader was asked to define the product development cycle in simple terms a grandmother would understand, assuming the grandmother is not a systems engineer. The purpose of this question is to make the reader think about the fundamental tasks that comprise product development. Sometimes people get into the detail of their work to the point they lose sight of the fundamentals of what they are doing. Figure 3-1 illustrates what the reader might have said.

Figure 3-1 Product development consists of five tasks, or phases, at a fundamental level.

Product development organizations typically define the product development cycle in a much more complex diagram, or set of diagrams, that describe the tasks to be performed in much more detail than shown in Figure 3-1. However, it is important to step back and look at the fundamental tasks, or phases if you prefer, in as simple of terms as possible if we intend to improve the overall process. Starting with the simple flow chart in Figure 3-1 we define the work that systems engineering encompasses, again in simple terms, because our objective is to seek better methods for systems engineering. Note that Figure 3-1 leaves out the object of the verbs. This forces us to think about what it is that we are defining, designing, etc. For example, it’s necessary to define both the product and the program for developing the product. Decisions must be made about what will be designed, what will be tested and what will be produced. These decisions are product dependent and involve systems engineers if only as advisors. We can add some of the top level inputs and outputs of each step in Figure 3-1 as we think about what it is that we are defining, designing, etc. A result for one type of product might look like Figure 3-2.

The tasks shown are performed by a variety of managers, technicians, and engineers; systems engineers, design engineers, test engineers, etc. We seek to define just the tasks performed by systems engineers. Actually systems engineers are involved in all five tasks to some extent. Typically systems engineers are responsible for the specifications and plans that are produced in the “Define” task and contribute to or oversee work in the other four tasks. With these roles in mind we can think about the tasks the systems engineers perform. Recall that here nontraditional terminology is used at to describe the systems engineering work.

Figure 3-2 The outputs of a fundamental product development task are the inputs of the next task

Four Fundamental Tasks for Systems Engineers

A simple but useful terminology for defining systems engineering work is shown in Figure 3-3.

Figure 3-3 Four fundamental tasks performed by systems engineers during the product development cycle.

The four tasks listed in Figure 3-3 are not the only way to define systems engineering tasks, or are these are a complete description, but these four tasks help us understand the fundamentals, if we allow for some flexibility in our definitions. This becomes apparent as we examine in more detail the four tasks in later chapters.

Notice that the first three systems engineering tasks are shown as overlapping in time rather than being sequential in time. This is because these tasks should overlap in time. This is a good point to introduce one complexity in the fundamental task list shown in Figure 3-1, then we can return to defining systems engineering.

Progressive Freeze of Product Development

The product development tasks should not be rigidly sequential but should allow for some overlap in time, as indicated in Figure 3-4.

Figure 3-4   The fundamental product development tasks should be allowed to overlap in time.

Often major product development tasks, or phases, are gated by milestone reviews. This implies that all work must be completed on one phase of the product development before work can start on the next phase. It is not good practice to demand rigid adherence to the gating process. A better approach is to allow some work to begin as soon as the information needed for initiating the task is available. This is called progressive freeze, as discussed in previous  articles, and it adds flexibility to the work that offers benefits that outweigh the small additional risks incurred.

Progressive freeze is practiced by freezing an element of the engineering work, when the risk of freezing the work is acceptable and allowing work on the next phase to begin before the next milestone review. Engineering judgment is used to determine when the risk is acceptable that the continuing work on other elements of the development work won’t change the results of the frozen work element.

A couple of examples help understand the progressive freeze concept. Consider a radio frequency (RF) sensor. Freeze the antenna architecture when the gain, antenna configuration and interfaces are determined; initiate the antenna design in parallel with other subsystem architecture trades. Hold a system design review (SDR) or architecture review, if required, when all subsystem architectures are frozen. Second, consider an infrared sensor. The telescope architecture can be frozen when the aperture size, the form, the optical subsystem f/# and interfaces are determined. The telescope design can then proceed while the focal plane, electronics and cooling architecture trades continue.

There are several benefits from beginning the design early for the RF antenna or the telescope in these two examples. The biggest is the flexibility in scheduling the skilled antenna and telescope designers. Critical skills such as these are often in high demand on several programs. By enabling early starts of the design work involving critical skills it increases the total time period for the design work to be accomplished without impacting the program schedule and helps avoid program delays due to the unavailability of critical skills.

A second benefit is that progressive freeze facilitates sequencing design decisions throughout a design phase. Product development involves thousands of decisions in each phase of the work. Delaying decisions until just before major design reviews complicates decision management to the point that the quality of the work can be threatened. Making decisions as soon as risk allows spreads the decisions throughout a development phase and makes decision management easier. We will return to this issue in a later chapter where we explore design decision management in more detail.

 Another benefit is that should a problem arise in the design that impacts other architecture the architecture changes can be made easily if these trades are still underway. For example, suppose the RF antenna designer discovers that the desired gain margin cannot be achieved within the constraints defined in the architecture trades. If the other trades are still underway it is much easier to decide how to accommodate the problem. It may be that a larger envelope is available or it may be that the lower gain is acceptable with tighter control of noise figure in the amplifier electronics. Finally, allowing more time for the designers to work on a design element may result in a better design. Sometimes engineers need to set work aside for a short period while they mull over a difficult design issue. Sometimes unforeseen difficulties arise in design and having extra time to work out these difficulties helps avoid program delays.

Evolution of Engineering Methods II

Introduction of Systems Engineering - Following WW II products like cars and airplanes became more complex and the chief engineers could no longer understand everything necessary to achieve a balanced design. This lead to the introduction of specialists in the design of various subsystems or analytical specialties like stress analysis or aerodynamics. For example instead of just mechanical engineers specialists in structural analysis and thermal analysis developed to support the designers. Soon it became impossible for the chief engineer to understand how the engineering data from all the various specialists impacted the overall design. That is when systems engineering emerged and a team of systems engineers replaced the chief designer. It is easy to see that as more and more specialists were needed the engineering design teams grew larger and larger. The large engineering teams of specialists and systems engineers developed some fantastic products such as the Boeing 747, the Space Shuttle and supersonic jet fighter planes.

It became difficult or impossible to co-locate the large teams and the communications needed to keep the systems engineers and the specialists teams current became complex and slow compared to the previous methods. As a result information latency grew along with the complexity of the products and the size of the engineering teams needed to develop the products. This lead to longer and longer development cycle times. The design process became a sequential process with periodic design reviews to evaluate status and design integrity. This evolution took place roughly between 1950 and 1980 and enabled very complex products to be developed. However, the product development cycles were often years long and exhibited undesirable cost and schedule overruns. In addition product quality was sometimes lacking. Examination of this process reveals four fundamental flaws:

1.      Too much time and money passes before design errors are found at design reviews

2.      Integration of knowledge required for product development is greatly complicated by the separation of specialists into functional groups

3.      There are attempts to specify cost, schedule and quality; however, only two are independent.

4.      Products often reach manufacturing before manufacturing processes are fully developed.

Introduction of Concurrent Engineering - New methods emerged in the 1980s and 1990s to address the flaws in the sequential process. These new methods emphasized concurrence. Manufacturing and test processes are developed concurrently with the product design. Concurrent systems engineering and design engineering replaces the sequential development of specifications and design. Concurrency is facilitated by early involvement of manufacturing, reliability, procurement, vendors etc. in the design process. The new methods emphasize preventing problems rather than fixing problems by incorporating verification and validation at each step.

The IEEE Std 1220-1998 document “IEEE Standard for Application and Management of the Systems Engineering Process” defines concurrent engineering as “The simultaneous engineering of products and life cycle processes to ensure usability, producibility, and supportability, and to control life cycle and total ownership costs.” Concurrent engineering is sometimes called integrated product development (IPD) or integrated product and process development (IPPD). Here the IEEE definition of concurrent engineering is used for the product design process and IPD for the way the product development personnel are organized to conduct concurrent engineering. There are no universal agreements for these definitions, or other systems engineering nomenclature, so the reader is again cautioned to be careful in interpreting systems engineering terms from different sources.

Accompanying the development of concurrent engineering in the 1980s and 1990s were techniques for improving product quality. Two such techniques imported from Japan are Quality Functional Deployment (QFD) and Taguchi Design of Experiments. The term robust design emerged to describe engineering methodologies using these quality improvement techniques. Three excellent books on these subjects are:

“Total Quality Development-A Step-By-Step Guide to World-Class Concurrent Engineering” by Don Clausing, ASME Press, 1994

“Quality Engineering Using Robust Design” by Madhav Phadke, PTR Prentice Hall, 1989.

“Strategic Design: A Guide to Managing Concurrent Engineering” by Bart Huthwaite, 1994

Further Improvements in Design Methods - Engineering is inherently an iterative process due to the fact that engineers, just like other workers, make mistakes in their work. Engineering work involves making hundreds of decisions in each task and often involves complex analysis. It is almost impossible to do such work without making some mistakes on the first pass. A result of this fact is that design quality and design cost are linked by the number of design iterations performed. This is shown schematically in Figure 1 for a product of some specific complexity being developed with specific methods and tools.  If a design of quality q is desired then n iterations are needed and the cost will be c for the given set of design tools and methodologies. Notice that the schedule cannot be specified together with specifying cost and quality. If a certain schedule is required then either the cost or the quality can be specified, but not both. All three are not independent variables.

Also note that this simple diagram shows that if an organization wishes to lower costs, or shorten the design cycle, for a given quality it is necessary to introduce new tools, new methods or both. A major factor in determining the cost, quality and schedule relationships is whether the design team uses practices that prevent design problems rather than find and then fix problems. It is much cheaper and faster to prevent problems than it is to find and fix the problems. Two methodologies introduced to facilitate preventing problems rather than fixing problems are peer reviews and spiral development.

Peer Reviews - Rather than depend on design reviews to find problems peer reviews are held as soon as an individual or small team completes a task. Self-checks catch most mistakes but the best way to find errors after performing self-checks is for the engineer to review the work in detail with highly experienced peer engineers. Experienced peers provide an independent and often different experience background that helps reveal errors.

Catching errors at peer reviews allows the errors to be corrected before the results of the work are incorporated in following tasks. Thus little rework is involved in fixing errors found during peer reviews. In contrast errors found at periodic design reviews involve considerable rework because often the erroneous work has been incorporated in several following tasks that must also be reworked. It is this extensive rework due to errors found at design reviews on complex product developments that contributes to cost and schedule overruns.

Figure 1 Design quality is linked to design cost by the number of design iterations performed by relationships that are dependent on the product complexity and the engineering methods used.

If teams are disciplined in holding peer reviews then the design reviews can become more of a status and decision gate review to communicate to managers and customers the state of the design and to check that all required actions are complete per a design review checklist. Further, if any reviewers wish to go into detail on some design point the documentation engineers have previously used in the peer reviews serve for more detailed discussions. This reduces the time and costs involved in preparing for design reviews.

Spiral Development - Instead of designing the ultimately desired and often highly complex system in one step spiral development sets limited objectives for the first development effort, i.e., the first spiral. Lessons learned from the first spiral are then incorporated in the second spiral. Just like peer reviews spiral development recognizes the inherent iterative nature of product design engineering. The nature of spiral development can be understood from the diagram in Figure 1. A highly complex product would have a diagram with a very steep curve relating design iterations to cost. By developing a lower complexity product in the first spiral the relationship is less steep; that is the cost for a given number of iterations is lower. Similarly, the quality is higher for a given number of iterations for the lower complexity product. Thus the quality of the first spiral can be adequate for lower cost than for a more complex design. The same holds for later spirals. The lessons learned on any spiral are applied to later spirals, resulting in more favorable relationships between cost, schedule and quality than if the work is done in one spiral.

Progressive Freeze - Progressive freeze of design decisions is another technique introduced to manage schedule during the development of complex products. It involves freezing a design detail as soon as it becomes likely that further work won’t change it and before the next major design review. This enables more detailed design work to begin ahead of the design review intended to gate such detailed design. This provides schedule and staffing flexibility. More will be discussed about peer reviews and progressive freeze in later posts.

Concurrent engineering, IPD or IPPD, spiral development, and robust design represent the typical engineering processes for product development in use at the turn of the 21^st century and are still widely used. However, the engineering design process has not stopped evolving to match the ever increasing complexity of products. It is the newer methods that are the intended focus of this material. But before introducing these newer methods it is worthwhile to stop and review some fundamentals, which are the subject of the next post.