By Joseph S. Bobinis

This series explores the relationships of methodology for robust engineering and the possible effects of that method in order to accelerate the evolution of systems. The goals are to determine how systems evolve or progress; the principles involved in that progression and; whether robust engineering methods can influence those engineering principles toward evolution and progress. The following is Part Two of a three part series. Part One discussed the nature of engineering progress known as teleology and Part Two explores the causes of system evolution.

The Causes of System Evolution
The concept of quality can be determined by how purpose is translated to a system. There is a one-to-one correlation between purpose (requirements) and system (behaviors). Systems can evolve because there is no one-to-one correlation among requirements and behaviors (identity or contradiction) and as the goal is approximated it increases the amount of quality in the system. The Theory of Inventive Problem Solving expert, Vladimir Petrov, refers to this as the “degree of ideality.” The degree of ideality is determined by how the system parts work in harmony “irregular evolution of the parts,” the degree of system dynamics (complexity), the control or coordination of that complexity, and the forces between the system and the environment. This can be static (instance in time) or dynamic (over time).1

Evolution occurs when there is a lack of control over any of these factors. They could negatively influence the mapping of system purpose to system behavior. All systems evolve (progress) based on their failures. “An idea that unifies all of engineering is the concept of failure. Inventions are successful only to the extent that their creators properly anticipate how a device can fail to perform as intended.”2

Evolutionary Design or How Engineers Manage Failure
In his paper, “When Systems Engineering Fails – Toward Complex Systems Engineering,” physicist Yaneer Bar-Yam takes the position that engineering complex, networked-based systems like air traffic control systems, in many cases, fail because the traditional systems’ engineering process is inadequate.3

“A fundamental reason for the difficulties with modern large engineering projects is their inherent complexity. Complexity is generally a characteristic of large engineering projects today. Complexity implies that different parts of the system are interdependent so that changes in one part may have effects on other parts of the system. Complexity may cause unanticipated effects that lead to failures of the system. These indirect effects can be discussed in terms of multiple feedback loops among portions of the system and in terms of emergent collective behaviors of the systems as a whole.”3

Bar-Yam’s solution is to include functions of complex systems that allow an individual to discover, measure and implement design activities during the entire life cycle of the system. It implies that an individual cannot know all the functions of deployed complex systems and that an evolutionary approach to design is required. Additionally, it implies the need for the on-going activity of engineering control; as unaccounted variables emerge from the contradictions that are misidentified between system purpose and system behavior.

Bar-Yam provides several unique design methods. Incremental engineering is a process where portions of the system are redesigned and operate in parallel to other parts of the system (control of internal relationships of the working unit). Bar-Yam suggests that spiral development is an instantiation (simplified representation) of evolutionary acquisition and design. “Recent extensions that adopt some complex systems ideas include spiral development and evolutionary acquisition and adaptive programming. A complex systems perspective provides a large conceptual framework – evolution from which to understand how incremental change can enable rapid innovation.”3

Evolutionary design implies that since an individual cannot iteratively account for all functions and processes of complex system they must provide a design process which allows them to inductively determine system behaviors and processes, after the system is fielded (control of the external relationships between the working unit and the environment). Through this process an individual can apply traditional methods in changing small parts of complex systems during its life cycle, rather than trying to change the whole system. What is the correlation to how robust engineering experiments are to be designed?

Evolutionary design implies that on-going discovery and re-design is a life cycle function of the system (increasing idealization through resolution of contradiction and identity). The system must have a means of monitoring its own state (self identity?). An example of this is the modern application of prognostics in complex platforms where system states can be collected, analyzed and understood. This can happen to the extent that an individual is provided the “patterns of system behavior” to be able to predict and/or design system failures, failure modes and use cases that the system may not have been designed for (elimination of contradiction). Must an individual wait for the system to be fielded to account for environmental and variability use to occur in order to discover failure that will cause the evolutionary cycle of the system to begin?

Robust Engineering and System Evolution
Engineering practices already account for design failure. That is what is achieved during integration and testing of a design process. Does that mean that an individual is looking for failure during integration and testing? The answer is no. Typically individuals are looking for success; the goal of integration and test is validation and verification. Certainly failures emerge as part of the process, but failure of discovery is not the goal or target. The value of the integration and test process is to gain control of the internal relationships of the working unit.

Even if one of the primary goals of integration and testing is to discover failure, is it possible to simulate all causes of failure? Can the integration and testing environment simulate the complexity of the environment and use cases that the system will interact with in the real world (super system)? Usually the integration and testing process goal is one of harmonizing the internal relationships of the working unit – system level behaviors caused by the interaction of its parts. In order for the integration and testing to be complete, that the map to the real world would be more complex than the system under design. The integration and testing process would seek to gain control of the external relationships between the working unit and the environment.

What methods are available to the designer to accelerate or induce failure of the system? What would a method look like that would be inductive in nature and simulate the variables that influence system function? How can an individual quickly and efficiently approximate the end state of the system to its ideal state (ideality)? “In every engineered system, there exists some form of perfect or ideal relationship between input to the system and the output. Robust engineering seeks to attain that ideal state, referred to as the design’s ideal function. Achieving efficiency in this transformation of energy – represents the strategic thinking supporting the ideal function concept.”4

Robust engineering is a method to measure quality. Quality is an approximation of the system functions to an ideal state. Genichi Taguchi, developer of the Taguchi methods that improve engineering productivity, calls this the “design target.” Any variation of the system behavior to the design target is considered a “loss of quality.” Those deviations in quality will result in loss of economic value. This includes loss of economic value to the designer, manufacturer as well as consumer (and in general) loss of economic value to society. “Dr. Taguchi defines “robustness” as: the state where the technology, product or process performance is minimally sensitive to factors causing variability (either in the manufacturing or user’s environment) and aging at the lowest unit manufacturing cost.”5 The measure of robustness is the determination of signal to noise ratio. Signal to noise ratio is the measurement of variation of all processes and relationships (internal to external) that influence the ability of the system behaviors in order to map to its system purpose.

Given the measurement metrics for robust design, the cost of quality measurement can be applied to all relationships of the system (external environment) influences (boundary variables or working unit relationships) and uses of a product (system uses and users). This allows design engineers to measure the effectiveness (approximation to ideality) of their architectures in terms of physical, functional, operational and support while not requiring that the architect be bound by the physical boundary or deductive decomposition of the system under design.

This activity or measurement is performed by conducting experiments designed to simulate a subset of noise originators (internal = process variation) and (external = sensitivity to the environment) during the design process, where it is most cost effective. It is an activity to find and measure failure and its causes.

The activity requires an inductive methodology to test contradictions of the (system) design; where the system is exposed to (implied or predicted) environments (external, unit-to-unit, deterioration noise). This requires the engineer to understand sources of noise (internal and external) and a method to eliminate or reduce the effects of noise in the design with the use of “design countermeasures.”

Robust engineering measures and minimizes failure during design. It takes into account all qualities of how systems are designed. It also takes into account and attempts to measure:

• The source of system purpose – customer intent
• The signal factor – a translation of purpose to requirements
• A measure of the efficient transformation of energy – quality characteristics
• The effects of noise factors – the relationship between system and environment

In the final section of this three part series the author will define conclusions and applications to robust product design.

References

1. Vladimir Petrov. The Laws of System Evolution. The TRIZ Journal, March 2002.
2. Henry Petroski. Invention by Design How Engineers Get from Thought to Thing. Harvard University Press, pg.89; 1996.
3. Yaneer Bar-Yam. When Systems Engineering Fails – Toward Complex Systems Engineering; IEEE International Conference, Volume: 2, pg: 2022; October 5-8, 2003.
4. G.Taguchi, S. Chowdhury, S. Taguchi. Robust Engineering; McGraw Hill, pg. 6; 2000.
5. W. Fowlkes, C. Creveling, Addison-Wesley. Engineering Methods for Robust Product Design; pg.11; 1954.

About the Author:
Joseph S. Bobinis is a project management professional and has written several papers on product development, systems engineering and logisitics. He holds a B.A. in philosophy from Ithaca College. He currently specializes in Sustainment Architecture, IT architecture and engineering processes. Contact Joseph S. Bobinis at joseph.bobinis (at) lmco.com.