Buede D.M. The Engineering Design of Systems Models and Methods

Подождите немного. Документ загружается.

and is quite useful in distinguishing between transient and permanent errors.

Time redundancy assumes that additional time exists for functional pe rfor-

mance to enable the needed error detection and recovery. On the plus side, time

redundancy can save signiﬁcantly on hardware and software, reducing cost,

weight, power, and other key suitability issues.

8.7 SUMMARY

The focus of this chapter has been the resources that comprise the system, called

the physical architecture. The system is ﬁrst segmented into its top-level compo-

nents; the segmentation progresses down to the conﬁguration items (CIs), or hard-

ware and software elements, facilities, people, procedures, and user’s manuals.

The physical architecture can be either generic or instantiated; the generic

physical architecture is an abstract separation of the system’s resources into

components before any key performance decisions are made. The instantiated

physical architecture speciﬁes the performance characteristics of each element

of the generic physical architecture to the degree needed for performance

modeling of the system.

Creativity techniques are important to aid the generation of alternate,

instantiated physical architectures. The morphological box was described in

detail and illustrated as an effective technique for gathering creative ideas and

increasing the chances of combining these creative ideas into a sound,

instantiated physical architecture. The morphological box is deﬁned by the

generic physical architecture and then provides slots for alternate ideas for

instantiated physical components of each segment.

Representing the physical architecture using a block diagra m was presented

in this chapter. Block diagrams are completely non-st andardized representa-

tions of the system’s components, showing the major ﬂows of electromecha-

nical energy between the components.

Finally, key concepts, such as centralized and decentralized and distributed

and client–server architectures were presented. The decentralization of trans-

formation and control functions and the distribution of functional and physical

elements of the architecture have become the norm in most system’s architec-

tures. These concepts were deﬁned and illustrated.

Redundancy in hardware, software, information, and time was presented

since achieving fault tolerance is often a critical design issue that the engineer of

the system must address. Hardware redundancy is the most commonly

discussed and implemented approach to achieving fault tolerance with the

physical architecture. Software redundancy is almost always too expensive to

develop. Information redundancy, adding extra bits to data elements for the

purpose of checking the meaningfulness of data elements later, is used

extensively on communications interfaces that become part of the physical

architecture. Utilizing unused data processing time to repeat computations,

time redundancy, is not a common approach.

8.7 SUMMARY 281

CASE STUDY: COMMERCIAL AIRCRAFT CRASH AT SIOUX CITY,

IOWA

On July 19, 1989, United 232 (a DC-10 aircraft) crashed into a corn ﬁeld

next to the Sioux City airport in Iowa while trying to make an emergency

landing after losing one of three engines. In all, 110 passengers and one

ﬂight attendant were killed during this emergency landing; 185 people

survived the accident, some without a scratch.

Engine failure is the most commonly trained maneuver in simulators.

The DC-10 has three engines; one on each wing and one on top of the

fuselage in the vertical tail (or horizontal stabilizer). United 232 lost the

engine on top of the fuselage due to the loss of a fan disk; the fan disk

separated from the engine and crashed through the tail. Pilots fought

through the engine loss by porpoising (rotating the thrust levels) the two

remaining engines to land in Sioux City. However, the descent rate of the

landing was too great; the aircraft caught ﬁre upon landing, tumbled, and

broke apart in corn and soybean ﬁelds.

The fan disk, about 300 pounds of titanium, on the number two engine

was missing; it had shattered into pieces and crashed through a chamber

designed to contain such a break-up. There are three independent

hydraulic systems on the DC-10 aircraft; a unique engine powers each

hydraulic system. The hydraulic system on an aircraft provides the

forcing function for the aircraft’s stabilization systems: the ailerons on

the wings that permit the aircraft to bank right and left, the rudder that

allows the aircraft to turn right and left, the elevators on the tail that

cause the aircraft’s nose to rotate up or down, and the ﬂaps and slots on

the wings that permit the aircraft to change the amount of lift generated

by the wings. Losing engine number two should have only caused the loss

of one of the three hydraulic systems. However, the three independent

hydraulic systems converge in the tail at the exactly the location that the

fan disk ripped out, the single point of failure for all three hyd raulic

systems.

Experts believe there was a preexisting fracture on the fan disk.

Ultrasonic sensors are used to detect fractures during production.

However, these sensors do not provide good results when the fracture

is near the surface. The National Transportation Safety Board (NTSB)

investigators concluded that the fracture had been there since the fan disk

was built. The fracture would have grown with use; the maintenance crew

was blamed for not ﬁnding the fracture during routine maintenance

activities. Nonetheless, this does not dismiss the design ﬂaw of a single

point of failure for what were considered to be three redundant hydraulic

systems [Magnuson, 1989; Birnbaum, 1989].

282 PHYSICAL ARCHITECTURE DEVELOPMENT

PROBLEMS

8.1 Create a generic physical architecture for the ATM pro blem in Chapters

6 an d 7. Create a morphological box for your generic physical archi-

tecture of the ATM. Identify three instantiated phy sical architectures

based upon the morphological box.

8.2 Create a generi c physical architecture for the OnStar system in Chapters

6 an d 7. Create a morphological box for your generic physical archi-

tecture of OnStar. Identify three instantiated physical architectures

based upon the morphological box.

8.3 Create a generic physical architecture for a personal computer. Create a

morphological box for your generic physical architecture of a personal

computer. Identify three instantiated physical architectures based upon

the morphological box.

8.4 Create a generic physical architecture for a stereo system. Create a

morphological box for your generic physical architecture of a stereo

system. Identify three instantiated physical architectures based upon the

morphological box.

8.5 Create a generic physical architecture for the development system of an

air bag system. Create a morphological box for your generic physical

architecture of the development system. Identify three instan tiated

physical architectures based upon the morphological box .

8.6 Create a generic physical architecture for the manufacturing system of

an air bag system. Create a morphological box for your generic physical

architecture of the manufacturing system. Identify three instantiated

physical architectures based upon the morphological box .

8.7 Using the information in Figure 8.7 create a block deﬁnition diagram

and an internal block diagram for the ‘‘Aircraft Control Component,’’

which is inside the dotted lines of the ﬁgure. Be sure to use the semantics

and syntax of SysML. Note: You will have to ignore any arcs coming

from or going to components outside the dotted line.

8.8 You are on the elevato r design team and have just convinced the team

that the block decomposition at the subsystem level (Figure 3.14) is

incorrect. You have convinced the team to add a communications bus

so that the communications between the subsystems can be more

efﬁciently routed through the communication bus. Modify the block

deﬁnition diagram and internal block diagrams shown in Figures 3.14

and 3.16, respectively, for the elevator subsystems to sho w this design

change. Consider the communications bus to be a new component or

subsystem.

PROBLEMS 283

Chapter 9

Allocated Architecture

Development

9.1 INTRODUCTION

The development process for the allocated architec ture is the activity during

which the entire design comes together. The allocated architecture integrates

the requirements decomposition with the functional and physical architectures.

The process of developing the allocated architecture provides the raw materials

for the deﬁnition of the system’s external and internal interfaces and is the only

activity in the design process that contains the material needed to model the

system’s performance and enable trade-off decisions. The reader should not

infer from this discussion that the requirements development is started and

ﬁnished, followed by the functional architecture, followed by the physical

architecture, followed by the allocated architecture. Rather, the design process

is like peeling an onion; each of these activities in the design process should be

completed at a high level of abstraction (low level of detail), culminating in an

allocated architecture at this high level of abstraction for a set of subsystems

that comprise the system. Then the entire process is repeated at a lower level of

abstraction (greater detail) for the next tier of components (peel of the onion),

consistent with the Vee model discussed in Chapter 1. This repetition at lower

and lower levels of abstraction (greater and greater detail) is continued as long

as useful to the design process. As details determine problems with the design,

decisions are reviewed and changes are implemented at the higher levels of

abstraction as needed.

The Engineering Design of Systems: Models and Methods, Second Edition. By Dennis M. Buede

r 2009 John Wiley & Sons, Inc.

284

This chapter describes the activities involved in developing an allocated

architecture in detail: alloc ate functions to subsystems; trace non-input/output

requirements and derive requirements; deﬁne and analyze functional activation

and control structure; conduct performance and risk analysis; document

architectures and obtain approval; and document subsystem speciﬁcations.

The methods introduced in this chapter match the functions that comprise the

development of the allocated architecture. Various methods are discussed for

allocating functions of the system in question to subsystems and components of

the system. The derivation of input/output, system-wide and techno-

logy, trade-off, and qualiﬁcation requirements is discussed as a key method

for providing the material to complete the component speciﬁcation. Three

methods for ﬂowing down system-wide and technology requirements that have

been traced to the system are described. Models for deﬁning and analyzing

functional activation and control structures are discussed in Chapter 12 and are

therefore not presented in this chapter. However, critical system-wide issues

associated with functional activation and control are discussed here. A norma-

tive model for conducting trade studies and risk analyses is presented in Chapter

13. Examples of common trade studies and risk analyses are discussed and

illustrated in this chapter. No new models are introduced in this chapter.

The exit criterion for ﬁnishing the allocated architectur e is the acceptance of

the design by the stakeholders. The acceptance of the design by the stake-

holders should involve a detailed understanding that the requirements devel-

opment process has met the major characteristics of the requirements, as

deﬁned in Chapter 6: thorough understanding of how the allocated architec-

tures of the systems in each life-cycle phase will meet the requirement s as

deﬁned, belief that the design trades have accurately reﬂected the trade-off

requirements, and agreement that the test or qualiﬁcation systems in each phase

of the life cycle are adequate for qualiﬁcation requirements as deﬁned.

9.2 OVERVIEW

The allocated architecture provides a complete description of the system design,

including the functional architecture allocated to the physical architecture,

derived input/output, technology and system-wide, trade off, and qualiﬁcation

requirements for each component, an interface architecture that has been

integrated as one of the components, and complete documentation of the

design and major design decisions.

There are ﬁve major activities associated with the development of the

allocated architecture:

. Allocate functions and system-wide requirements to physical subsystems

. Allocate functions to components

. Trace system-wide requirements to system and derive component-wide

requirements

9.2 OVERVIEW 285

. Deﬁne and analyze functional activation and control structure

. Conduct performance and risk analysis

. Document architectures and obtain approval

. Document subsystem speciﬁcations

Figure 9.1 shows these ﬁve functions in an IDEF0 (Integrated Deﬁnition for

Function Modeling) diagram for developing the allocated architecture; see

Appendix B for the full model. Note that Sections 9.3 and 9.4 address the two

subfunctions under the ﬁrst function (these were combined to make the

diagram easier to read). As can be seen by the ﬂow of information among

these activities, substantial interaction and feedback is required among the ﬁrst

four to make sure the design works; this feedback and control was discussed in

Chapter 7. However, viewing the development of the allocated architecture in

isolation would be inappropriate. The developments of the three architectures

(functional, physical, and allocated), which we have been discussing, all have to

proceed in parallel because insight or changes in one have repercussions in the

others. Figure 9.2 puts the allocated architecture development in context with

the other architectures and requirements development.

As discussed in the introduction, the design process proceeds through the

steps shown in Figure 9.2 several times, at decreasing levels of abstraction. The

more complex the system’s functionality and tightly coupled the system’s

components are, the more important is the repetition of the design process at

decreasing levels of abstraction (increasing detail). Initially, the design process

establishes functional and physical decompositions, which are united to form

the allocated architecture. The allocated architecture divides the design

problem into chunks, primarily along the lines of the physical architecture,

namely the system’s components. Naturally, these design decisions should not

be made prematurely; there should be adequate conﬁdence that little or no

modiﬁcations will be needed. Yet, as the design process evolves through

additional repetitions of the activities shown in Figure 9.2, the more detailed

simulation models and trade studies may provide justiﬁcation for modifying

earlier design decisio ns.

The primary beneﬁt of making major design decisions early using models

and trade studies built at a high level of abstraction is that these initial decisi ons

are aimed at dividing the design problem into manageable chunks that can

proceed concurrently with a reasonable chance of success. Dividing the

system’s design problem into completely independent chunks is not possible.

To accommodate this interaction there must be design interfaces just as there

are system interfaces. These design interfaces are part of the development

system that is being completed concurrently with the design of the operational

system. It is critical that the development system provide the time to review and

adjust the design chunks; this time can only be provided if the design process

begins at a high level of abstraction. Some engineers argue that this initial peel

of the onion should be completed within weeks (6–12) after having written a

286 ALLOCATED ARCHITECTURE DEVELOPMENT

USED AT:

CONTEXT:

NODE: TITLE: NUMBER:

AUTHOR:

PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:

REV:

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READERDATE

System-level

Operational

Concept

Candidate

Physical

Architectures

Subsystem

Design

Requirements,

Boundaries,

Missions,

Objectives

& Constraints

Architecture

Changes

Allocate

Functions &

System-wide

Requirements

to Physical

Subsystems

A1141

Define &

Analyze

Functional

Activation &

Control

Structure

A1142

Document

Architectures

& Obtain

Approval

A1144

Document

Subsystem

Specifications

A1145

System-level

Architectures

Function to

Subsystem

Allocation

Conduct

Performance

& Risk

Analyses

A1143

Analysis

Results

Suggested

Revisions

System-level

Functional

Architecture

Discrepancies in the

Specifications,

Interface Control,

and Acceptance

Test Plan

Interface

Architecture

System's

Qualification

System

Documentation

Engineering Design of a System

Dennis Buede

GMU Systems

Engineering

Program

05/24/99

Develo

p System Operational ArchitectureA114

Allocated

Architecture

Stakeholders’ &

System Requirements,

Objectives Hierarchy,

Boundary & Qualification

System Requirements

Alternative

System-level

Allocated

Architectures

Develop System Allocated Architecture

Risk Analysis,

System Design

Document,

Allocated

Architecture,

System Interface

Control Document

FIGURE 9.1 IDEF0 representation of developing the allocated architecture.

287

USED AT:

GMU Systems

Engineering

Program

CONTEXT:

NODE:

TITLE:

NUMBER:

AUTHOR: Dennis Buede

PROJECT: Engineering Design of a System

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:

REV:

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READER DATE

P. 5

05/24/99

Perform System-Level Desion Activities

A11

Allocated Architecture,

Changes to Requirements

Requirement

Changes

Functional

Architecture

Changes

Interface

Architecture

Physical

Architecture

Changes

Architecture

Changes

Candidate

Generic

Physical

Architectures

System-level

Operational

Concept

Design

System

Physical

Architecture

Develop

System

Functional

Architecture

Define

System

Level

Design

Problem

A111

Design

Changes

Lower

Layer

Changes to

Require-

ments

Inputs of Stakeholders

Stakeholders’ & System

Requirements, Objectives

Hierarchy, Boundary &

Qualification System Requirements

Stakeholders’

& System

Requirements

Documents

Stakeholders’

& System

Requirements

System-level

Physical

Architecture

System-level

Functional

Architecture

Candidate

Physical

Architectures

Develop

System

Allocated

Architecture

A114

Develop

Interface

Architecture

A115

Develop

Qualification

System

A116

A113

A112

Allocated

Architecture

System

Requirements

Interface

Architecture

Changes

Qualification

System

Changes

System’s

Qualification

System

Documentation

Subsystem

Design

Requirements,

Boundaries,

Missions,

Objectives

& Constraints

Risk Analysis,

System Design

Document,

Allocated

Architecture,

System Interface

Control Document

FIGURE 9.2 System-level design activities.

288

proposal and been awarded a contract. If the design segmentation is not

ﬁnalized until each component has been decomposed into several levels of

detail, there will be no time to adjust this design decision if the division of the

system into components is found to be ﬂawed. There is even less chance that the

ﬂaws will be found if too many details are analyzed too quickly.

Distinguishing between good decisions and good outcomes is important. If

we were in complete control of our environment, then decisions and the

outcomes associated with the decisions could be equated. However, as

discussed in detail in Chapter 13, decisions must be made in the face of

uncertainty with incomplete information and inadequate control of the out-

comes. Therefore, saying that a decision was good or bad because the outcomes

associated with that decision were good or bad, respectively, is illogical. A

decision can be considered good if the people with the best knowledge and

largest stake in the decision were involved in the decision, and these people did

discuss the relevant alte rnatives, values, and facts with clarity.

As an example, Ford Motor Company designed and introduced the Edsel in

1957. The Edsel had a large, elongated ‘‘0’’ built into the middle of the grill at

the front of the car that caused many people to react negatively on an artistic

basis. The Edsel was a complete failure at least partially because the automobile

industry was in a recession in 1957 and 1958. Were the design decisions

associated with the Edsel bad? It is not possible to tell without knowing more

about what design decisions were made and how the design process was carried

out. Seven years after the Edsel’s introduction, Ford Motor Company

introduced the Mustang, which has been a fantastically successful car and

has achieved classic status. Were the design decisions associated with the

Mustang good? Again, it is not possible to tell without knowing more about

them. With time it is much easier to tell whether the outcomes associated with a

decision are good or bad, but it becomes more and more difﬁcult to tell whether

the decisions that were made were good or bad, especially if those decisions are

not documented.

9.3 ALLOCATE FUNCTIONS TO COMPONENTS

After the deﬁnition of the functional and physical architectures, the systems

engineering team must assign functions from the functional hierarchy to the

subsystems and components in the physical architecture. When this is done, the

ﬁrst step in deﬁning the allocated architecture is completed. This allocation of

functions to components is often the most crucial design decision made by the

engineers of the system. Engineers prefer to alloc ate processing tasks to

software if there will be a future need to update the processing algorithms.

However, if speed of processing is critical, hardware can perform the computa-

tions much faster. Computer manufacturers experiment with moving some

processing tasks from hardware to software, but often ﬁnd that the speed of

processing suffers too much and revert to designing hardware for the

9.3 ALLOCATE FUNCTIONS TO COMPONENTS 289

processing tasks. Similar issues arise when considering the decision of allocat-

ing a function to people within the system or a combination of hardw are and

software. This allocation decision is discussed in more detail later.

Figure 9.3 expands upon Figure 9.4 for the allocation of the system’s

functions to subsystems and components. Clearly allowing the allocation

decision to be represented as a mathematical relation, and not a function, as

shown in the top left of Figure 9.3 is inadequate; there will be some functions

that are not allocated to any component and some functions that are being

processed by two or more components. Forcing the allocation of functions to

components to be represented as a mathematical function, as shown in the top

right of Figure 9.3, solves these problems. However, there may be some

components with no functions to perform; these components should either be

dropped from the system or the engineers should revisit their functional

architecture to ensure that the functional architecture is complete. There is

also the possibility that some functions will be performed by the same

component; there is nothing wrong with this because the functions can be

aggregated into a single function. If as expected all of the components are

Functions

Components

Function for the allocation

of functions to components

Functions

Components

One-to-one and onto

function for the allocation

of functions to components

Functions

Components

Onto, but not one-to-one

function for the allocation

of functions to components

Functions

Components

Relation for the allocation

of functions to components

FIGURE 9.3 Mathematical relations and functions for the allocation of engineering

functions to components.

290

ALLOCATED ARCHITECTURE DEVELOPMENT