THE SYSTEM ENGINEERING HIERARCHY Regardless of its domain of focus, system engineering encompasses a collection of

10.2 THE SYSTEM ENGINEERING HIERARCHY Regardless of its domain of focus, system engineering encompasses a collection of

top-down and bottom-up methods to navigate the hierarchy illustrated in Figure 10.1. The system engineering process usually begins with a “world view.” That is, the entire business or product domain is examined to ensure that the proper business or tech- nology context can be established. The world view is refined to focus more fully on specific domain of interest. Within a specific domain, the need for targeted system elements (e.g., data, software, hardware, people) is analyzed. Finally, the analysis,

CHAPTER 10

SYSTEM ENGINEERING

design, and construction of a targeted system element is initiated. At the top of the hierarchy, a very broad context is established and, at the bottom, detailed technical activities, performed by the relevant engineering discipline (e.g., hardware or soft- ware engineering), are conducted. 2

Stated in a slightly more formal manner, the world view (WV) is composed of a set of domains (D i ), which can each be a system or system of systems in its own right.

WV = {D 1 ,D 2 ,D 3 ,...,D n }

Each domain is composed of specific elements (E j ) each of which serves some role in accomplishing the objective and goals of the domain or component:

D i = {E 1 ,E 2 ,E 3 ,...,E m }

Good system engineering begins

Finally, each element is implemented by specifying the technical components (C k ) with a clear

that achieve the necessary function for an element: understanding of

context—the world

E j = {C 1 ,C 2 ,C 3 ,...,C k }

view— and then progressively narrows

In the software context, a component could be a computer program, a reusable pro- focus until technical

gram component, a module, a class or object, or even a programming language state- detail is understood.

ment. It is important to note that the system engineer narrows the focus of work as he or she moves downward in the hierarchy just described. However, the world view portrays a clear definition of overall functionality that will enable the engineer to understand the domain, and ultimately the system or product, in the proper context.

10.2.1 System Modeling

System engineering is a modeling process. Whether the focus is on the world view or the detailed view, the engineer creates models that [MOT92]

• ? Define the processes that serve the needs of the view under consideration.

What does a

system

• Represent the behavior of the processes and the assumptions on which the

engineering model accomplish?

behavior is based. • Explicitly define both exogenous and endogenous input 3 to the model. • Represent all linkages (including output) that will enable the engineer to bet-

ter understand the view. To construct a system model, the engineer should consider a number of restraining

factors:

2 In some situations, however, system engineers must first consider individual system elements and/or detailed requirements. Using this approach, subsystems are described bottom up by first considering constituent detailed components of the subsystem. 3 Exogenous inputs link one constituent of a given view with other constituents at the same level or other levels; endogenous input links individual components of a constituent at a particular view.

PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

1. Assumptions that reduce the number of possible permutations and variations, thus enabling a model to reflect the problem in a reasonable manner. As an example, consider a three-dimensional rendering product used by the enter- tainment industry to create realistic animation. One domain of the product enables the representation of 3D human forms. Input to this domain encom- passes the ability to specify movement from a live human actor, from video, or by the creation of graphical models. The system engineer makes certain assumptions about the range of allowable human movement (e.g., legs can- not be wrapped around the torso) so that the range of inputs and processing can be limited.

2. Simplifications that enable the model to be created in a timely manner. To illustrate, consider an office products company that sells and services a broad range of copiers, faxes, and related equipment. The system engineer is mod-

A system engineer eling the needs of the service organization and is working to understand the considers the following

factors when flow of information that spawns a service order. Although a service order can developing alternative

be derived from many origins, the engineer categorizes only two sources: solutions: assumptions,

internal demand and external request. This enables a simplified partitioning simplifications,

of input that is required to generate the service order.

limitations, constraints, and customer

3. Limitations that help to bound the system. For example, an aircraft avionics preferences.

system is being modeled for a next generation aircraft. Since the aircraft will

be a two-engine design, the monitoring domain for propulsion will be mod- eled to accommodate a maximum of two engines and associated redundant systems.

4. Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented. For example, the technol- ogy infrastructure for the three-dimensional rendering system described pre- viously is a single G4-based processor. The computational complexity of problems must be constrained to fit within the processing bounds imposed by the processor.

5. Preferences that indicate the preferred architecture for all data, functions, and technology. The preferred solution sometimes comes into conflict with other restraining factors. Yet, customer satisfaction is often predicated on the degree to which the preferred approach is realized.

The resultant system model (at any view) may call for a completely automated solution, a semi-automated solution, or a nonautomated approach. In fact, it is often possible to characterize models of each type that serve as alternative solutions to the problem at hand. In essence, the system engineer simply modifies the relative influ- ence of different system elements (people, hardware, software) to derive models of each type.

CHAPTER 10

SYSTEM ENGINEERING

10.2.2 System Simulation

In the late 1960s, R. M. Graham [GRA69] made a distressing comment about the way we build computer-based systems: "We build systems like the Wright brothers built air- planes—build the whole thing, push it off a cliff, let it crash, and start over again." In fact, for at least one class of system—the reactive system—we continue to do this today.

Many computer-based systems interact with the real world in a reactive fashion. If simulation capability That is, real-world events are monitored by the hardware and software that form the is unavailable for a

computer-based system, and based on these events, the system imposes control on reactive system,

project risk increases. the machines, processes, and even people who cause the events to occur. Real-time Consider using an

and embedded systems often fall into the reactive systems category.

iterative process model Unfortunately, the developers of reactive systems sometimes struggle to make that will enable you to

them perform properly. Until recently, it has been difficult to predict the performance, deliver a working

product in the first efficiency, and behavior of such systems prior to building them. In a very real sense, iteration and then use

the construction of many real-time systems was an adventure in "flying." Surprises other iterations to tune (most of them unpleasant) were not discovered until the system was built and "pushed

its performance. off a cliff." If the system crashed due to incorrect function, inappropriate behavior, or poor performance, we picked up the pieces and started over again.

Many systems in the reactive category control machines and/or processes (e.g., commercial aircraft or petroleum refineries) that must operate with an extremely high degree of reliability. If the system fails, significant economic or human loss could occur. For this reason, the approach described by Graham is both painful and dan- gerous.

Today, software tools for system modeling and simulation are being used to help to eliminate surprises when reactive, computer-based systems are built. These tools are applied during the system engineering process, while the role of hardware and software, databases and people is being specified. Modeling and simulation tools enable a system engineer to "test drive" a specification of the system. The technical

CASE Tools details and specialized modeling techniques that are used to enable a test drive are Modeling & Simulation discussed briefly in Chapter 31.