The Engineering Design of Systems E-Book

Dennis M. Buede

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 967

Veröffentlichungsjahr: 2024

Beschreibung

The Engineering Design of Systems

Comprehensive resource covering methods to design, verify, and validate systems with a model-based approach, addressing engineering of current software-centric systems

The newly revised and updated Fourth Edition of The Engineering Design of Systems includes content addressing model-based systems engineering, digital engineering, digital threads, AI, SysML 1.0 and 2.0, digital twins, and GENESYS software. The authors explore system and software-centric architecture, allocations, and logical and physical architecture development, including revised terminologies for a variety of subsections throughout.

Composed of 15 chapters, this book includes important new sections on modeling approaches for middle-out engineering, reverse engineering, and agile systems engineering, with a separate section on emerging trends within systems engineering to explore the most update-to-date methods. The authors include comprehensive diagrams and a separate chapter on a complete exercise of the System Engineering process, ranging from the operational concept to integration and qualification.

To aid in reader comprehension and retention of concepts, the text is embedded with problems at the end of each chapter, along with relevant case studies.

Sample topics covered in The Engineering Design of Systems include:

• Structural system models to executable models, verification and validation on systems of systems, and external systems and context modeling
• Digital engineering, digital threads, artificial/augmented intelligence (AI), stakeholder requirements, and scientific foundations for systems engineering
• Quantifying a context and external systems’ model, including intended and unintended inputs, both deterministic and non-deterministic
• Functional architecture development, logical and physical architecture development, allocated architecture development, interface design, and decision analysis for design trades

The Engineering Design of Systems is highly suitable as a main text for undergraduate and graduate students studying courses in system engineering design, systems architecture, and systems integration. The text is also valuable as a reference for practicing system architects, systems engineers, industrial engineers, engineering management professionals, and systems integrators.

Leseprobe

Table of Contents

Cover

Table of Contents

Title Page

Copyright

Dedication

Preface

About the Companion Website

Part 1: Introduction, Overview, and Basic Knowledge

Chapter 1: Introduction to Systems Engineering

1.1 INTRODUCTION

1.2 OVERVIEW OF THE ENGINEERING OF SYSTEMS

1.3 APPROACHES FOR IMPLEMENTING SYSTEMS ENGINEERING

1.4 MODELING APPROACHES FOR SYSTEMS ENGINEERING

1.5 INTRODUCING THE CONCEPT OF ARCHITECTURES

1.6 REQUIREMENTS

1.7 SYSTEM’S LIFE CYCLE

1.8 DESIGN AND INTEGRATION PROCESS

1.9 TYPES OF SYSTEMS

1.10 SUMMARY

PROBLEMS

Chapter 2: Overview of the Systems Engineering Design Process

2.1 INTRODUCTION

2.2 DESIGN PROCESS

2.3 KEY SYSTEMS ENGINEERING CONCEPTS

2.4 INTRODUCTION TO SysML

2.5 USE OF GENESYS SYSTEMS ENGINEERING TOOL

2.6 SUMMARY

PROBLEM

Chapter 3: Modeling and SysML Modeling

3.1 INTRODUCTION

3.2 MODELS AND MODELING

3.3 SysML MODELING

3.4 METASYSTEM MODELING

3.5 STATIC BEHAVIORAL PROCESS MODELING WITH IDEF0

3.6 DYNAMIC BEHAVIORAL PROCESS MODELING WITH EFFBDs

3.7 STRUCTURAL MODELING OF THE SYSTEM’S COMPONENTS

3.8 REQUIREMENTS MODELING

3.9 PERFORMANCE MODELING

3.10 SUMMARY

PROBLEMS

Chapter 4: Discrete Mathematics: Sets, Relations, and Functions

4.1 INTRODUCTION

4.2 SETS

4.3 RELATIONS

4.4 FUNCTIONS

4.5 SUMMARY

PROBLEMS

Chapter 5: Graphs and Directed Graphs (Digraphs)

5.1 INTRODUCTION

5.2 TERMINOLOGY

5.3 PATHS AND CYCLES

5.4 CONNECTEDNESS

5.5 ADJACENCY AND REACHABILITY*

5.6 UNARY RELATIONS AND DIGRAPHS

5.7 ORDERING RELATIONS*

5.8 ISOMORPHISMS*

5.9 TREES

5.10 FINDING CYCLES AND SEMICYCLES IN A GRAPH

5.11 REVISITING IDEF0 DIAGRAMS

5.12 SUMMARY

PROBLEMS

Notes

Part 2: Design and Integration

Chapter 6: Requirements and Defining the Design Problem

6.1 INTRODUCTION

6.2 REQUIREMENTS

6.3 DEFINITIONS

6.4 STAKEHOLDERS’ REQUIREMENTS DEVELOPMENT: DEFINING THE DESIGN PROBLEM

6.5 REQUIREMENTS CATEGORIES

6.6 REQUIREMENTS PARTITION

6.7 STAKEHOLDERS’ REQUIREMENTS DOCUMENT (StkhldrsRD)

6.8 CHARACTERISTICS OF SOUND REQUIREMENTS

6.9 WRITING REQUIREMENTS

6.10 OPERATIONAL CONCEPT

6.11 ECOSYSTEM MODEL

6.12 OBJECTIVES HIERARCHY FOR PERFORMANCE REQUIREMENTS

6.13 PROTOTYPING, ANALYSES, AND USABILITY TESTING

6.14 DEFINING THE STAKEHOLDERS’ REQUIREMENTS

6.15 REQUIREMENTS MANAGEMENT

6.16 SUMMARY

PROBLEMS

Chapter 7: Functional Architecture Development

7.1 INTRODUCTION

7.2 DEFINING TERMINOLOGY FOR A FUNCTIONAL ARCHITECTURE

7.3 FUNCTIONAL ARCHITECTURE DEVELOPMENT

7.4 DEFINING A SYSTEM’S FUNCTIONS

7.5 DEVELOPMENT OF THE FUNCTIONAL DECOMPOSITION

7.6 FINISHING THE FUNCTIONAL ARCHITECTURE

7.7 TRACING REQUIREMENTS TO ELEMENTS OF THE FUNCTIONAL ARCHITECTURE

7.8 SUMMARY

PROBLEMS

Chapter 8: Physical Architecture Development

8.1 INTRODUCTION

8.2 GENERIC VERSUS INSTANTIATED PHYSICAL ARCHITECTURES

8.3 OVERVIEW OF PHYSICAL ARCHITECTURE DEVELOPMENT

8.4 CREATIVITY TECHNIQUES

8.5 GRAPHIC REPRESENTATIONS OF THE PHYSICAL ARCHITECTURE

8.6 ISSUES IN PHYSICAL ARCHITECTURE DEVELOPMENT

8.7 SUMMARY

Problems

Chapter 9: Allocated Architecture Development

9.1 INTRODUCTION

9.2 OVERVIEW

9.3 ALLOCATE FUNCTIONS TO COMPONENTS

9.4 TRACE NON-INPUT/OUTPUT REQUIREMENTS AND DERIVE REQUIREMENTS

9.5 DEFINE AND ANALYZE FUNCTIONAL ACTIVATION AND CONTROL STRUCTURE

9.6 CONDUCT PERFORMANCE AND RISK ANALYSES

9.7 DOCUMENT ARCHITECTURES AND OBTAIN APPROVAL

9.8 DOCUMENT SUBSYSTEM SPECIFICATIONS

9.9 SUMMARY

PROBLEMS

Chapter 10: Interface Design

10.1 INTRODUCTION

10.2 OVERVIEW TO INTERFACE DEVELOPMENT

10.3 INTERFACE ARCHITECTURES

10.4 STANDARDS

10.5 OPEN SYSTEMS INTERCONNECTION ARCHITECTURE

10.6 COMMON OBJECT REQUEST BROKER ARCHITECTURE

10.7 INTERFACE DESIGN PROCESS

10.8 SUMMARY

PROBLEMS

Chapter 11: Integration and Qualification

11.1 INTRODUCTION

11.2 DISTINCTIONS AMONG ACCEPTANCE, VALIDATION, AND VERIFICATION TESTING

11.3 OVERVIEW OF INTEGRATION

11.4 ALTERNATE INTEGRATION PROCESSES

11.5 SOME QUALIFICATION TERMINOLOGY

11.6 DEFINING THE QUALIFICATION SYSTEM

11.7 QUALIFICATION METHODS

11.8 ACCEPTANCE TESTING

11.9 SUMMARY

PROBLEMS

Chapter 12: A Complete Exercise of the Systems Engineering Process

12.1 INTRODUCTION

12.2 OPERATIONAL CONCEPT

12.3 EXTERNAL SYSTEMS MODEL

12.4 FUNDAMENTAL OBJECTIVES

12.5 STAKEHOLDERS’ REQUIREMENTS

12.6 FUNCTIONAL ARCHITECTURE

12.7 PHYSICAL AND ALLOCATED ARCHITECTURES

12.8 INTERFACE DESIGN

12.9 INTEGRATION AND QUALIFICATION

12.10 BEGINNING THE SUBSYSTEM LAYER

Part 3: Supplemental Topics

Chapter 13: The Value of Systems Engineering

13.1 INTRODUCTION

13.2 VALUE PROPOSITIONS FOR SYSTEMS ENGINEERING

13.3 SUMMARY

Chapter 14: Decision Analysis for Design Trades

14.1 INTRODUCTION

14.2 ELEMENTS OF DECISION PROBLEMS

14.3 AXIOMS OF DECISION ANALYSIS

14.4 MULTIATTRIBUTE VALUE ANALYSIS

14.5 UNCERTAINTY IN DECISIONS

14.6 SAMPLE APPLICATION

14.7 SUMMARY

PROBLEMS

Chapter 15: The Science and Analysis of Systems

15.1 INTRODUCTION

15.2 GENERAL SYSTEM THEORY

15.3 SYSTEMS SCIENCE

15.4 NATURAL SYSTEMS

15.5 CYBERNETICS

15.6 SYSTEMS THINKING

15.7 QUANTITATIVE CHARACTERIZATION OF SYSTEMS

15.8 SYSTEM DYNAMICS

15.9 CONSTRAINT THEORY

15.10 FERMI PROBLEMS AND GUESSTIMATION

15.11 ARTIFICIAL (OR AUGMENTED) INTELLIGENCE AND MACHINE LEARNING

15.12 SUMMARY

PROBLEMS

Glossary

References

Historical References

Index

End User License Agreement

List of Tables

Chapter 1

TABLE 1.1 Definitions of Systems Engineering

TABLE 1.2 Race Car Example of Requirements and Tests

TABLE 1.3 Sample of Decisions Made During System Design

TABLE 1.4 Diagram Types for UML 2.0

TABLE 1.5 Diagram Types for SysML v1

TABLE 1.6 Typical Requirements Documents

TABLE 1.7 Comparison of the Relative Cost to Fix Software in Various Life Cy...

TABLE 1.8 The Cycles of the Cycle Model

TABLE 1.9 System Classification by Magee and de Weck [2004].

Chapter 2

TABLE 2.1 Functions of the Design Process

TABLE 2.2 Functions of the System-Level Design Problem

TABLE 2.3 Functions of the Integration and Qualification Process

TABLE 2.4 Sample Operational Concept Scenarios for an Elevator

TABLE 2.5 Sample Elevator Requirements for the Operational Phase

TABLE 2.6 Systems Engineering Classes in GENESYS

TABLE 2.7 Common Systems Engineering Relations

TABLE 2.8 Outline of System Description Document

Chapter 3

TABLE 3.1 Taxonomy of Models

TABLE 3.2 Representation of Process Modeling Techniques

TABLE 3.3 IDEF0 Page Hierarchy

Chapter 6

TABLE 6.1 Roles and Responsibilities during Requirements Generation

TABLE 6.2 Exemplary Requirement Dimensions

TABLE 6.3 Attributes of Requirements

TABLE 6.4 Sample Operational Concept Scenarios for an Elevator

TABLE 6.5 Metrics for Measuring Usability Elements.

Chapter 7

TABLE 7.1 Subsystems and Functions of Living Systems

Chapter 8

TABLE 8.1 WBS Elements and Related Life Cycle Phases for a Generic Aircraft ...

TABLE 8.2 WBS Elements for a Generic Air Vehicle (Level 3)

TABLE 8.3 Morphological Box for a Hammer

TABLE 8.4 VanGundy’s Typology of Brainwriting and Brainstorming

TABLE 8.5 Morphological Box for the Card Image Decompression Component

Chapter 9

TABLE 9.1 Original Fitts List from 1951

TABLE 9.2 A Taxonomy of the Distribution of Responsibility between Human and...

TABLE 9.3 Price’s Functional Allocation Principles

TABLE 9.4 SVM Site Location Analysis Summary

Chapter 10

TABLE 10.1 Summary of OSI Reference Model

Chapter 11

TABLE 11.1 Principal Integration Processes.

TABLE 11.2 Qualification Planning Functions.

TABLE 11.3 Qualification Methods.

TABLE 11.4 Testing Methods.

TABLE 11.5 Examples of Testing Facets.

TABLE 11.6 Black-Box, White-Box, and Gray-Box (or Grey-Box) Testing.

Chapter 12

TABLE 12.1 External Items and Associated Interfaces

Chapter 13

TABLE 13.1 Summary of Systems and Software Engineering Success and Failure

Chapter 15

TABLE 15.1 Threshold and Objective Performance Requirements for the Operatio...

TABLE 15.2 External Inputs, External Outputs, and Engineered Values for the ...

TABLE 15.3 Derived Values for Maximum Velocity of the Elevator in m/s

TABLE 15.4 Maximum Number of Building Floors to Meet Performance Constraints...

TABLE 15.5 Maximum Number of Building Floors to Meet Performance Constraints...

TABLE 15.6 Threshold and Objective Performance Requirements for the Operatio...

TABLE 15.7 External Inputs, External Outputs, and Engineered Values for the ...

TABLE 15.8 Range and Endurance Example for an Aircraft

TABLE 15.9 Rules to Determine Consistency of Mathematical Models

List of Illustrations

Chapter 1

FIGURE 1.1 Phases of the system life cycle.

FIGURE 1.2 Cost commitment and incursion in the system life cycle.

FIGURE 1.3 Systems engineering “Vee.”

FIGURE 1.4 “

g

–

g

” design region for a racecar.

FIGURE 1.5 Expertise required on the engineering team for a system.

FIGURE 1.6 Characterizing the broader systems’ design problem.

FIGURE 1.7 Traditional, top-down systems engineering.

FIGURE 1.8 Waterfall model.

FIGURE 1.9 Spiral model.

FIGURE 1.10 Architecture development in the engineering of a system.

FIGURE 1.11 Sample physical architecture (F-22 Type A Spec).

FIGURE 1.12 Life cycle physical architecture.

FIGURE 1.13 Design decomposition of architectures and specs.

FIGURE 1.14 Development period.

FIGURE 1.15 Period of pre-initial operational capability.

Figure 1.16 Period of operational use and refinement.

FIGURE 1.17 Retirement period.

FIGURE 1.18 Cycle model of systems engineering.

FIGURE 1.19 Five major functions of the engineering design of a system.

FIGURE 1.20 Detailed functions of systems engineering design.

FIGURE 1.21 Functions of the systems engineering integration process.

FIGURE 1.22 Summary of TTDSE.

Chapter 2

FIGURE 2.1 Depiction of the system, external systems, enabling systems, and ...

FIGURE 2.2 Many of the concepts and their relationships.

FIGURE 2.3 Ecosystem model view for the operational phase of an elevator.

FIGURE 2.4 Fundamental objectives hierarchy for operational phase of elevato...

FIGURE 2.5 Top-level function of the elevator.

FIGURE 2.6 First-level decomposition of the elevator system function.

FIGURE 2.7 Physical architecture of the elevator system.

FIGURE 2.8 Comparison of TTDSE and SysML.

Chapter 3

FIGURE 3.1 Exemplary use case diagram.

FIGURE 3.2 Exemplary sequence diagram.

FIGURE 3.3 Syntax for an IDEF0 function.

FIGURE 3.4 Syntax for an IDEF0 flow of material or data.

FIGURE 3.5 Labeling conventions for branches and joins.

FIGURE 3.6 Feedback semantics within an IDEF0 page.

FIGURE 3.7 IDEF0 functional decomposition.

FIGURE 3.8 Functional decomposition in an IDEF0 model.

FIGURE 3.9 Memory syntax in IDEF0.

FIGURE 3.10 Series function flow block diagram.

FIGURE 3.11 Concurrent control structure in an FFBD.

FIGURE 3.12 Selection and multiple-exit functions in an FFBD.

FIGURE 3.13 Selection, multiple-exit functions, and inputs/outputs between f...

FIGURE 3.14 Selection, multiple-exit activities, and inputs/outputs between ...

FIGURE 3.15 Semantic elements of a block definition diagram.

FIGURE 3.16 Exemplary block definition diagram (syntax) for an elevator.

FIGURE 3.17 Semantic elements of the internal block diagram.

FIGURE 3.18 Exemplary internal block diagram for subsystems of an elevator s...

FIGURE 3.19 Semantic elements for the block definition diagram used for perf...

FIGURE 3.20 Exemplary block definition diagram for the fundamental objective...

FIGURE 3.21 Semantic elements for the parametric diagram.

Chapter 4

FIGURE 4.1 Set inclusion.

FIGURE 4.2 Absolute complement.

FIGURE 4.3 Relative complement.

FIGURE 4.4 Set intersection.

FIGURE 4.5 Set partition.

Chapter 5

FIGURE 5.1 Sample-directed graph for “is the parent of.”

FIGURE 5.2 Samples of incidence.

FIGURE 5.3 Sample bipartite graph. The box nodes are in

A

and the circles in...

FIGURE 5.4 Digraph with a walk (

d

–

b

–

a

–

c

–

d

–

e

), closed walk, path, and a cycle...

FIGURE 5.5 Digraph with two cycles (

a

–

b

–

c

and

c

–

d

–

e

) and a circuit (

c

–

a

–

b

–

c

–

FIGURE 5.6 Digraph with a semipath (

b

–

a

–

c

–

d

–

e

) and semicycle (

d

–

b

–

a

–

c

).

FIGURE 5.7 Reflexive and irreflexive relations.

FIGURE 5.8 Digraph of a symmetric relation.

FIGURE 5.9 Digraph of a transitive relation.

FIGURE 5.10 Transitive version of the digraph in Figure 5.8.

FIGURE 5.11 Partial order on a set

A

, Hasse diagram, and partial orderings o...

FIGURE 5.12 Second Hasse diagram example.

FIGURE 5.13 Sample tree.

FIGURE 5.14 Sample nondirected and directed trees.

FIGURE 5.15 Quasi-strongly connected digraph.

FIGURE 5.16 Levels of a directed tree.

FIGURE 5.17 Sample directed forest.

FIGURE 5.18 ICOM labels converted to nodes.

FIGURE 5.19 IDEF0 page with divide and paste functions added.

Chapter 6

FIGURE 6.1 Requirements hierarchies.

FIGURE 6.2 Depiction of the system, external systems, enabling systems, and ...

FIGURE 6.3 IDEF0 diagram of the system-level design process.

FIGURE 6.4 Objectives hierarchy, requirements partition, and trade space.

FIGURE 6.5 Outline of stakeholders’ requirements document.

FIGURE 6.6 Alternate operational concepts for Apollo’s moon landing.

FIGURE 6.7 Sequence diagram of first elevator scenario.

FIGURE 6.8 External systems’ model diagram view for operational use of an el...

FIGURE 6.9 Fundamental objectives’ hierarchy for operational phase of elevat...

FIGURE 6.10 Objectives’ hierarchy with value curves.

FIGURE 6.11 Summary of stakeholders’ requirements development.

Chapter 7

FIGURE 7.1 Process for developing a functional architecture.

FIGURE 7.2 Architecture template of Hatley and Pirbhai [1988, p. 195].

FIGURE 7.3 Elevator functions within the Hatley–Pirbhai template.

FIGURE 7.4 Exemplary functional decomposition.

FIGURE 7.5 Open and closed-loop control processes.

FIGURE 7.6 Illustration of feedback control in the development of the system...

FIGURE 7.7 Scenario trace on the context model diagram.

FIGURE 7.8 Scenario trace continued in the first level decomposition diagram...

FIGURE 7.9 Scenario trace continued in the first subfunction diagram.

FIGURE 7.10 Scenario trace continued in the first sub-subfunction diagram.

FIGURE 7.11 Scenario trace continued in the second sub function diagram.

FIGURE 7.12 Scenario trace completed in the third sub function diagram.

FIGURE 7.13 Concept map for fault tolerance terms.

FIGURE 7.14 Tracing a sample of input/output requirements to a sample of fun...

Chapter 8

FIGURE 8.1 Sample physical architecture (F-22 Type A Spec).

FIGURE 8.2 Generic physical architecture from the elevator case study.

FIGURE 8.3 Development process for the physical architecture.

FIGURE 8.4 Need for a one-to-one and onto functional allocation of functions...

FIGURE 8.5 Morphological box for automobile navigation support system.

FIGURE 8.6 Pairwise infeasible combinations.

FIGURE 8.7 Block diagram of an aircraft control system.

FIGURE 8.8 Flowchart of alternate functional design allocation options with ...

FIGURE 8.9 TMR and triplicated TMR.

FIGURE 8.10 Software implementation of voting for triplicated TMR.

FIGURE 8.11 Hardware duplication with comparison.

FIGURE 8.12 Standby sparing with N-1 replicas.

FIGURE 8.13 Pair-and-a-spare active hardware redundancy.

Chapter 9

FIGURE 9.1 IDEF0 representation of developing the allocated architecture.

FIGURE 9.2 System-level design activities.

FIGURE 9.3 Mathematical relations and functions for the allocation of engine...

FIGURE 9.4 Sample objectives hierarchy for functional allocation.

FIGURE 9.5 Interactions among PDTs for the small V-8 Engine Project at Gener...

FIGURE 9.6 Reorganized DSM with four aggregate teams.

FIGURE 9.7 Allocating functions to components using SysML.

FIGURE 9.8 Derived objectives hierarchies for the elevator case study.

FIGURE 9.9 Sensitivity of value for system reliability tradeoffs to derived ...

FIGURE 9.10 Wait-for-resource graph depicting deadlock.

FIGURE 9.11 Physical architecture diagram for GNSS testbed.

Chapter 10

FIGURE 10.1 Development process for the interface architecture.

FIGURE 10.2 Network architectures.

FIGURE 10.3 Communication in the OSI reference model.

FIGURE 10.4 OSI process of adding and stripping PCIs and ICIs.

FIGURE 10.5 CORBA overlaid on OSI seven-layer model.

FIGURE 10.6 ORB interactions with clients and servers.

FIGURE 10.7 Interface design process.

FIGURE 10.8 Sample interface design between elevator and the building housin...

Chapter 11

FIGURE 11.1 Verification, validation, and acceptance.

FIGURE 11.2 Two qualification chains. The high-level chain consists of conce...

FIGURE 11.3 Bottom-up integration process.

FIGURE 11.4 Major integration functions for component integration.

FIGURE 11.5 Logic diagram for subsystem integration.

FIGURE 11.6 Integration control structure and data/material/energy flows.

FIGURE 11.7 The process for developing the qualification system.

FIGURE 11.8 Repeated application of TTDSE to the layers of the system’s desi...

Chapter 12

FIGURE 12.1 Modified

N

2

chart for the first usage scenario.

FIGURE 12.2 Modified

N

2

chart for all usage scenarios.

FIGURE 12.3 SysML activity diagrams of the external systems and context.

FIGURE 12.4 Fundamental objectives of the soda machine.

FIGURE 12.5 Fundamental objectives with swing weights.

FIGURE 12.6 SysML activity diagram showing the first level functional archit...

FIGURE 12.7 Allocated architecture for the soda machine.

Chapter 13

FIGURE 13.1 Comparison of traditional requirements and goal-based approaches...

FIGURE 13.2 Gaining closure with stakeholders.

FIGURE 13.3 Gaining closure with design engineers.

FIGURE 13.4 An exemplary risk matrix.

Chapter 14

FIGURE 14.1 Common types of value curves.

FIGURE 14.2 Balance beam analogy for paired comparisons.

FIGURE 14.3

x

i

as a subset of the universal event, which is partitioned by

Y

FIGURE 14.4 Relevance diagrams for two variables.

FIGURE 14.5 Notional relevance diagram for elevator design.

FIGURE 14.6 Relevance diagram with survey data on power technology.

FIGURE 14.7 Decision tree for buy versus build decision.

FIGURE 14.8 Decision tree for calculating VwPI for build versus buy decision...

FIGURE 14.9 Influence diagram for build–buy decision.

FIGURE 14.10 Sample influence diagram for requirements allocation.

FIGURE 14.11 Summary of requirements allocation case study.

FIGURE 14.12 Comparison of two lotteries.

FIGURE 14.13 Simple risk preference assessment queries.

FIGURE 14.14 Illustration of the zero effect.

FIGURE 14.15 Assessment queries for risk preference function.

FIGURE 14.16 Assessed risk preference points.

FIGURE 14.17 Buying and selling prices are equal for exponential risk prefer...

FIGURE 14.18 Risk aversion coefficient lottery.

FIGURE 14.19 External systems diagram for MPWS.

FIGURE 14.20 Operational effectiveness performance parameters.

FIGURE 14.21 Utility curve for helicopter transportability, measured in tons...

FIGURE 14.22 Utility curve for V80, speed on the best 80% of terrain.

FIGURE 14.23 Utility curve for % no go, % of terrain that is not negotiable....

Chapter 15

FIGURE 15.1 Generic feedback control system block diagram.

FIGURE 15.2 Automatic flight control system simplified block diagram.

FIGURE 15.3 Systems thinking archetype of tragedy of the commons.

FIGURE 15.4 Systemigram of an elevator system context.

FIGURE 15.5 Soda machine system dynamics model.

FIGURE 15.6 Directed bipartite graph of elevator system objectives hierarchy...

FIGURE 15.7 Constraint matrix of elevator system objectives hierarchy.

Guide

Cover

Table of Contents

Title Page

Copyright

Dedication

Preface

About the Companion Website

Begin Reading

Glossary

References

Historical References

Index

End User License Agreement

Pages

iii

iv

v

ix

x

xi

xii

xiii

xv

1

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

127

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

433

434

435

436

437

438

439

440

441

442

443

444

THE ENGINEERING DESIGN OF SYSTEMS

MODELS AND METHODS

Fourth Edition

DENNIS M. BUEDE

ITA International LLC

Reston, Virginia

WILLIAM D. MILLER

ITA International LLC

Berkeley Heights, New Jersey

Copyright © 2024 by John Wiley & Sons, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permission.

Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data

Names: Buede, Dennis M., author. | Miller, William D., 1949- author.

Title: The engineering design of systems : models and methods / Dennis M.  Buede, ITA International LLC, William D. Miller, ITA International LLC.

Description: Fourth edition. | Hoboken, New Jersey : John Wiley & Sons,  Inc., [2024] | Includes index.

Identifiers: LCCN 2023057866 (print) | LCCN 2023057867 (ebook) | ISBN  9781119984016 (hardback) | ISBN 9781119984023 (adobe pdf) | ISBN  9781119984030 (epub)

Subjects: LCSH: Systems engineering. | Engineering design. | System design.

Classification: LCC TA168 .B83 2024 (print) | LCC TA168 (ebook) | DDC  620.001/171–dc23/eng/20240102

LC record available at https://lccn.loc.gov/2023057866

LC ebook record available at https://lccn.loc.gov/2023057867

Cover Design: WileyCover Image: © William D. Miller. Ralf Hiemisch/Getty Images

Dennis: In Memory of my Mother and Father

Bill: To John Lewis, Mal Buchner, Jake Schaefer,and Les Kleinberg who inspired andnurtured this nascent systems engineer

Preface

This book is meant to be a basic text for courses in the engineering design of systems at both the upper-division undergraduate and beginning graduate levels. The book is the product of many years of consulting on numerous portions of the system development process, research into the use of systems engineering in industry, and six years of developing a course on the engineering design of systems. During the development of this book, I found that many engineers did not understand systems engineering. Even those who do may not have a good perspective on a complete and unified process for engineering a system. The desire to suppress the number of decisions being made during design is quite strong in most engineers. While engineers have learned modeling throughout their academic lives, and most have developed models during the practice of engineering, very few engineers working on systems are knowledgeable of the modeling techniques required in systems engineering. In addition, most engineers are not aware of methods for using models during the systems engineering process. As a result, I adopted the following themes in formulating this book:

Defining the design problem in systems engineering is one of several keys to success and can be approached systematically using engineering techniques.

The design problem in systems engineering is defined in terms of requirements. These requirements evolve from a high-level set of mission and stakeholders’ requirements to detailed sets of derived requirements.

The design process will fail if the requirements are defined too narrowly, leaving little if any room for design decisions and raising the possibility that no feasible solution exists. The design problem should be well defined and decision rich.

For the design problem to be well defined, the evolving sets of requirements must be complete (none missing), consistent (no contradictions), correct (valid for an acceptable solution), and attainable (an acceptable solution exists). While it is not possible at this time to state requirements mathematically and prove these properties, it is possible to develop mathematical and heuristic representations of the design problem to assist in evaluating the presence of these properties.

These characteristics of the requirements will not be achieved if scenarios defining how the system will be used are not elaborated in detail, the interactions among the system and other systems are not defined, and the stakeholders’ objectives are not understood. Each of these requires a different kind of modeling to be successful.

The design problem is not likely to be well defined if the requirements do not address every relevant phase of the system’s life cycle.

The design problem is not likely to be well defined if the requirements do not contain stakeholder preferences for comparing feasible designs against each other.

The keys to understanding many of the modeling techniques for developing requirements, defining architectures, and deriving requirements are found in discrete mathematics: set theory, relations and functions, and graph theory.

Integration requires a well-defined design, including a design of the qualification process for verification, validation, and acceptance. A systematic process of design provides all the necessary inputs for defining the qualification process.

Early validation of the evolution of the definition of the design problem needs to be pursued vigorously to ensure that the definition of the design problem does not change as the problem is defined in greater detail.

Qualification of the system is the key issue in integration. Qualification includes verification and validation of both the requirements and the system design, followed by the stakeholders’ acceptance. There are many methods for qualifying the system; these methods must be chosen judiciously.

The successful qualification also requires that decisions about what should be tested be made in a systematic way that balances the two conflicting objectives of not wasting resources and obtaining stakeholder acceptance.

The above themes for the methods and models in this book are fundamental to the engineering of systems that have been validated in use beginning in the twentieth century CE and are independent of and realizable using the several systems modeling standards introduced in the twenty-first century CE including the Object Management Group (OMG) Systems Modeling Language (SysML®), ISO/PAS 19450 Object-Process Methodology (OPM), and the Lifecycle Modeling Organization (LMO) Lifecycle Modeling Language (LML).

The major changes for the fourth edition reflect the emphasis on SysML to visualize system models while still keeping legacy IDEF0 diagrams to visualize systems engineering process modeling. Chapter 1 was rewritten to address the updates that were made throughout the original chapters. As SysML2 becomes available as a standard and is implemented in software tools, the SysML diagrams in the book will be revised as SysML 2.0 diagrams and will be available on the Wiley companion website. The chapter on graphical modeling techniques was removed from the book but will still be available on the Wiley companion website for this book.

The book is divided into three major parts: (1) Introduction, Overview, and Basic Knowledge, (2) Design and Integration Topics, and (3) Supplemental Topics. The first part introduces the issues associated with the engineering of a system. Next, an overview of the engineering process is provided so that readers will have a context for the more detailed material. Finally, the basic knowledge needed for the core material is presented. Homework problems are provided at the end of each chapter.

Chapter 1 defines a system, systems engineering, the life cycle of a system and then introduces systems engineering processes. This material sets the stage for the details that follow.

Chapter 2 provides an overview of the details that are to come by presenting a number of basic concepts; these concepts include an operational concept, objectives, requirements, functions, items, components, interfaces verification, validation, and acceptance. The relations among these concepts are also addressed.

Chapter 3 provides an overview of modeling and the types of modeling needed in engineering systems. Modeling methods associated with SysML are then introduced and described. While IDEF0 is not part of SysML, this topic has been kept in Chapter 3 as an important part of the modeling concepts described in this book.

Chapter 4 presents basic discrete mathematics. The purpose of discrete mathematics is to demonstrate the mathematical rigor for which systems engineering must strive and to provide a language with which we can discuss key issues. Examples of such important concepts are the distinction between a relation and a function and why this is critical for engineering a system, a partition of the elements of a set that can be applied to many systems engineering concepts (e.g., requirements), and partial orders of functional execution.

Chapter 5 extends the discussion of discrete mathematics to graph theory, so that the graphical communication structures commonly used in the engineering of systems can be seen to have substantial problems as rigorous mathematical representations. On the other hand, the difficult concepts in Chapter 4 can be effectively represented with graphs for analysis and communication.

Part 2 covers the critical material required to understand the major elements needed in the engineering design of any system: requirements, architectures (functional, physical, and allocated), interfaces, and qualification.

Requirements development is approached as a systematic process in Chapter 6. This systematic process involves the definition of an operational concept of the system (including usage scenarios), a description of the involvement of the system with other systems, and an objectives hierarchy of the stakeholders across all phases of the system’s life cycle. A partition of requirements is employed to discuss the systematic approach to defining requirements.

Definitions of the functional, physical, and allocated architectures are provided as well as the detailed methods for developing these architectures in Chapters 7–9. Chapter 7 begins with several definitions that are needed to enable a meaningful discussion of the topic. The notion of a functional architecture is defined. An emphasis is placed on process modeling in Chapter 7. However, additional material is presented in Chapter 3 and the graphical modeling techniques on the companion website on data and behavioral modeling methods, as well as other approaches for process modeling. (This material can be used while discussing Chapters 7–9.) Modeling approaches for partitioning a function into segments are discussed. Key topics are feedback and control within the functional decomposition and evaluating the architecture for shortfalls and overlaps. Chapter 7 also addresses the functionality needed for error detection and recovery as well as tracing the input/output requirements to functions and items.

Chapter 8 introduces the distinction between generic and instantiated physical architectures. The morphological box is used to demonstrate the generation of multiple instantiated physical architectures. The graphical representation of the physical architecture is discussed along with notions of centralized, decentralized, and distributed architectures. Finally, fault-tolerant architectures are described.

Chapter 9 defines the allocated architecture and discusses the allocation of functions to components, the tracing and derivation of requirements, the analysis of activation and control structures, and the conduct of various analyses (risk, performance, and trade-off).

Chapter 10 characterizes interfaces, discusses the functions associated with interfaces in several contexts (communications systems and software design), describes interface architectures, and discusses interface design as it impacts system performance as part of the design process.

Finally, qualification of the system (Chapter 11) during integration requires an understanding of the stakeholders’ needs and the qualification methods that are typically used. Deciding what to test and how to test it is critical in this phase of the development process.

Chapter 12 provides a comprehensive review of Chapters 6–11, which is a very useful way to end a quarter or semester by tying everything together with a simple system – an automated soda machine.

All these topics in Chapters 6–12 are addressed in a rigorous and systematic manner, consistent with the general practical application of systems engineering in industry.

Homework exercises are provided on each of these topics from Part 2 for several real but simple systems that are familiar to all students: an automatic teller machine, an airbag, and the OnStar system of Cadillac. A case study is available on the web to give the students a sample of the solutions to the homework. Readers are encouraged to access and apply commercial system engineering software products to enhance the conduct of these homework exercises and the educational mission of this book.

Finally, three additional key topics are introduced in the third part: decision analysis, system science and analytics, and the value of systems engineering. Chapter 13 presents ideas on the value of systems engineering. This chapter identifies six key value propositions that should interest most stakeholders: problem and solution discovery, communication, identification and solution of show stoppers as early as possible, error reduction in both the product and design systems, risk reduction in both the product and design systems and continuous improvement of the design system.

Chapter 14 presents the key topics of decision analysis as an integrative way of supporting the many decisions that are part of the design and integration of a system. These decision analytic topics include the development and quantification of values (objectives, value functions, and trade-offs), and the modeling of uncertainty regarding facts.

Chapter 15 addresses the bedrock of the science of systems in general systems theory, systems science, natural systems, cybernetics, and systems thinking. Engineering successful systems accounts for the pervasiveness of uncertainty throughout the system lifecycles. Successful engineering is critically dependent on system analytics: quantitative characterization of systems, system dynamics, constraint theory, and approximate methods. Illustrative examples are aircraft performance, flight control system stability, elevator system performance, soda machine performance, and Fermi’s classic problem to estimate the number of piano tuners in Chicago. The chapter also introduces the challenges of artificial (or augmented) intelligence and machine learning (AI/ML) embedded in systems and approaches to ensure desired behaviors and mitigate undesired behaviors.

The homework problems and the case study of the elevator are defined with the express purpose of having the student demonstrate the level of understanding necessary to perform the engineering activities described in the book. In developing these homework exercises, I have taken the position that demonstrating an ability to discuss how to do systems engineering is a necessary but not a sufficient level of understanding. The GENESYS software (that is appropriate for use with this book and is available as a downloadable package via the web: http://www.vitechcorp.com) takes the tedium out of performing these systems engineering activities as well as reinforcing the basic concepts behind the activities. The case material related to an elevator system can be downloaded from the companion website.

Several colleagues have provided many useful comments and suggestions. We wish to thank Kathryn Laskey, Bob Kenley, Mike Pennotti, and Tony Barrese.

Several students and teaching assistants have contributed to sections of these notes. Cathy Brown provided a substantial extension of the requirements for the elevator case study. John Van Ormer extended the physical architecture of the elevator. Jahan Araghi extended my initial case study on the automatic teller machine (ATM) as part of his master’s project. Tong Zhang and Parham Pasha provided some examples of sets, relations, and graphs. Christine Salter provided extensive support in addressing topics that needed revision, developed solutions for homework problems, and provided solution material for the OnStar and ATM problems. Several student groups provided material on which the airbag case is based. Meg Giordana and Barry Liner provided extensive comments on the qualification material. Tim Parker developed two case studies for use in Chapters 8 and 9: the FBI Fingerprint Identification System and the Wide-Area Augmentation System of the Federal Aviation Administration. Steve Charbonneau provided interesting insights about state charts as part of his MS thesis. The SYST 520 class at George Mason University during the spring of 1998 provided many extensive and useful comments on an early draft of the first edition.

We wish to thank all these individuals, as well as many others with whom we have conversed on these topics, for stimulating me to complete this effort.

One of the most difficult aspects of writing this book has been to decide which material to include and which to leave out. There is still a great deal more to be said on the topics covered in this book and on some additional topics that were not included. More importantly, there is still a great deal more to discover, at least on our part. The following Wiley Companion Website contains some material that we have dropped from the third edition and some material that will be posted as the second version of SysML is released.

DENNIS M. BUEDEReston, Virginia

WILLIAM D. MILLERBerkeley Heights, New JerseyAugust 2023

About the Companion Website

This book is accompanied by a companion website

www.wiley.com/go/engineeringdesignofsystems4e

Once registered at the website, the student will receive access to:

Elevator Case Study

Power Point Slides

Related Links

Solutions Manual for Instructors Only

Part 1Introduction, Overview, and Basic Knowledge

Chapter 1Introduction to Systems Engineering

1.1 INTRODUCTION

A system is commonly defined to be “a collection of hardware, software, people, facilities, and procedures organized to accomplish some common objectives.” The stakeholders in the system hold these objectives. Never forget that the system being addressed by one group of engineers is the subsystem of another group and the supersystem of yet a third group. The objective of the engineers for a system is to provide a system that accomplishes the primary objectives set by the stakeholders, including those objectives associated with the creation, production, and disposal of the system. To accomplish this engineering task, the engineers must identify the system’s stakeholders throughout the system’s life cycle and define the objectives of all of these stakeholders. These objectives typically address the triad of cost, schedule, and performance – cheaper, faster, and better.

A system of systems is a “set of systems or system elements that interact to provide a unique capability that none of the constituent systems can accomplish on its own” [ISO/IEC/IEEE 21841, 2019; Maier, 1998; Dahmann, 2015; DoD, 2010]. A system of systems (SoS) is characterized by the managerial and operational independence of its constituent systems. A SoS exhibits emergent capabilities beyond the mere aggregation of the constituent systems, just as a system has its own emergent capabilities. SoS categories are acknowledged, collaborative, directed, and virtual. Acknowledged SoS fall between directed and collaborative SoS and have recognized objectives, a designated manager, and resources; changes in the constituent systems are based on collaboration between the SoS and the system, for example, an aircraft carrier battle group of several ships, an embarked air wing, and other assets. Collaborative SoS have component systems interacting more or less voluntarily to fulfill agreed-upon central purposes, for example, the Internet, which originated as a directed SoS but evolved. The Internet Engineering Task Force (IETF) works out standards but has no power to enforce them. Agreements among the central players on service provision an rejection provide what enforcement mechanism there is to maintain standards. Directed SoS are created and managed to fulfill specific purposes, and the constituent systems are subordinated to the SoS; for example, US ballistic missile defense managed by the Missile Defense Agency (MDA) directly reporting to the US Department of Defense (DoD). Virtual SoS lack a central management authority and a centrally agreed-upon purpose for the SoS, for example, national economies.

A major characteristic of the engineering of systems is the attention devoted to the entire life cycle of the system. This life cycle has been characterized as “birth to death” and “lust to dust.” That is, the life cycle begins with the gleam in the eyes of the users or stakeholders, is followed by the definition of the stakeholders’ needs by the systems engineers, includes developmental design and integration, goes through production and operational use, usually involves refinement, and finishes with the retirement and disposal of the system. Ignoring any part of this life cycle while engineering the system can lead to sufficiently negative consequences, including failure at the extreme. In particular, developing a system that has not adequately addressed the stakeholders’ needs leads to failures such as the “highway to nowhere” near San Francisco, which was stopped by political pressure brought to bear by homeowners on the surrounding hills overlooking the bay. The view of the bay that these homeowners enjoyed and thought was an associated right of the property they owned would have been blocked by the highway. Similar commercial failures that did not consider the needs of the stakeholders in sufficient detail include the personal computers IBM PC Jr. and Apple LISA. This is not to say that the adherence to the methods and models put forth in this book or any other will guarantee success or even the absence of failure. Rather, the methods and models proposed here do attend to the entire life cycle of the system and provide a process that makes sense, can be tailored to various levels of detail as dictated by the complexity of the system being addressed, and attend to all the details that many engineers during years of practice in systems engineering have determined to be useful.

The concepts of design and integration are critical to the methods addressed in this chapter and the book. The word design is used by many professions (artists, architects, all disciplines of engineering) and is claimed by each.

The American Heritage Dictionary [Berube, 1991] defines design as:

de-sign (di-zin’) v. - signed, - sign.ing, - signs. —tr. 1. To conceive in the mind; invent: designed his dream vacation. 2. To form a plan for: designed a marketing strategy for the new product. 3. To have a goal or purpose; intend. 4. To plan by making a preliminary sketch, outline, or drawing. 5. To create or execute in an artistic or highly skilled manner. –intr. 1. To make or execute plans. 2. To create designs. –n. 1. A drawing or sketch. 2. The invention and disposition of the forms, parts, or details of something according to a plan. 3. A decorative or artistic work. 4. A visual composition; pattern. 5. The art of creating designs. 6. A plan; project. 7. A reasoned purpose; intention. 8. Often designs. A sinister or hostile scheme: He has designs on my job…

All but the third and eighth definitions for noun usage will apply at various times in this book. Design during the engineering of a system, as discussed in this book, is the preliminary activity that has the purpose of satisfying the needs of the stakeholders; it begins in the mind of the lead engineer but has to be transformed into models employing visual formats in a highly skilled manner for success to be achieved. While this book addresses the engineering methods and models used during the design process, there is always an element of artistry that is required for the design process and the system to be successful.

Integration brings all the detailed elements of the overall design together through a process of testing (or qualification) to achieve a valid system for meeting the needs of the stakeholders. Engineers of appropriate disciplines perform integration according to the specifications defined by the design of the system’s engineers. The integration process involves testing or qualification of both the elements of the system and the system itself to ensure that the system meets the ultimate needs of the stakeholders.

This chapter first provides an overview of the issues and processes associated with the engineering of a system. This overview addresses the phases of the system’s life cycle, describes the importance of performing the engineering of a system well, provides a definition for the engineering of a system, introduces the key process model for the engineering of a system called the Vee model, describes the richness of decisions that are inherent in the engineering process, and discusses the diversity of expertise required for this engineering process. Section 1.3 describes process models that have been adopted by the software engineering community. Architectures play a key role in the engineering of systems and are introduced next. Requirements, Section 1.5, play a major role in the engineering of a system because they serve the role of defining the engineering design problem and capturing the key information needed to describe design decisions. The life cycle of the system is next examined in more detail. Finally, the Vee model for engineering a system is described in more detail.

The key method addressed in this chapter is the process used to perform the engineering of systems. Supplementing this discussion of the engineering method are discussions of the key concepts needed to understand the method at an introductory level. This method is presented as a process model; models and modeling are discussed in detail in Chapter 3, so the reader is asked to accept the notion of the process discussion as a discussion of a model until more detail on models can be provided in Chapter 3.

1.2 OVERVIEW OF THE ENGINEERING OF SYSTEMS

The development process in systems engineering is commonly viewed [Forsberg and Mooz, 1992; Lake, 1992] as a decomposition (or design) process followed by a recomposition (or integration) process (see Sidebar 1.1). During the decomposition process, the stakeholders’ requirements are analyzed and defined in engineering terms and then partitioned into a set of specifications (or specs) for several segments, elements, or components. It is critical that this design process be broad in perspective so that nothing is left out and every contingency is considered. Systems engineers must be “big picture” people. Depth is only achieved by many iterations through the design process, as many as are needed, until the system’s specifications are sufficiently detailed for individual configuration items (CIs) to be built or purchased. This design process defines what the system must do, how well the system must do it, and how the system should be tested to verify and validate the system’s performance. To do this, the systems engineers must maintain a very clear focus on the objectives that the system’s stakeholders (users, owners, manufacturers, maintainers, trainers, etc.) have defined for the system.

One of many possible representations of the life cycle of a system is shown in Figure 1.1, beginning with the identification of the need for the system and progressing through the retirement of the system. Some of the phases of the life cycle are accomplished in parallel, as the diagram tries to depict; exactly which phases occur in parallel depends upon the type of system, the organization, and the context. For additional details, see Driscoll [2007].

As shown in Figure 1.1, the design includes the preliminary system design as well as parts of the identification of need and concept definition. Parts of the identification of need and concept definition include the development of a basic idea and the first embodiment of the idea; these two initial activities are often called invention and are usually not part of the engineering of a system. The invention has a heavy technological and scientific focus. The last portions of the identification of need and concept design phases, plus preliminary system design, address the initial or follow-on commercialization of the idea based upon a specific statement of stakeholders’ needs.

FIGURE 1.1 Phases of the system life cycle.

SIDEBAR 1.1

The term systems engineering dates back to Bell Telephone Laboratories in the 1940s [Schlager, 1956; Hall, 1962; Fagen, 1978]. Fagen [1978] traces the concepts of systems engineering within Bell Labs back to the early 1900s, performing system development engineering emphasizing first principles for an exponentially growing nationwide telephone system spanning the continent [Dixon, 1926; Findley, 1926]. Mindell [2002] describes major applications of systems engineering from the 1920s through World War II. Systems engineering in the context of Bell Labs and the Bell System is detailed by Mervin Kelly in a lecture to the Royal Society [1950]. RCA used the “systems approach” during the research and development of the electronically scanned, black-and-white television [Engstrom, 1957]. In 1943, the National Defense Research Committee established a Systems Committee with Bell Laboratories’ support to guide a project called C-79, the first task of which was to improve the communication system of the Air Warning Service. An unpublished chapter on systems engineering in the Bell system suggested that the first use of the phrase “systems engineering” within the Bell system was in a memo in the summer of 1948. Systems engineering was identified as a unique function in the organizational structure of Bell Laboratories in 1951. Personnel at the Massachusetts Institute of Technology (MIT) worked with Bell Labs on radars during World War II. Ivan Getting at MIT discovered that electrical noise caused two components of a fire control system to behave differently when they worked together than when they worked independently. His group at MIT became a systems integrator for the Navy after the war. As a result of these efforts, the following statement appeared in what is called the Ridenour Report (Research and Development in the United States Air Force) dated 21 September 1949: “The role of systems engineering should be substantially strengthened, and systems projects should be attacked on a ‘task force’ basis by teams of systems and components specialists organized on a semi-permanent basis” [Johnson, 2002].

Involvement in the earliest intercontinental ballistic missile (ICBM) program, starting with Atlas, is the most well-known of early systems engineering activities. Simon Ramo, previously with GE Labs and Hughes, and Dean Wooldridge, previously with Bell Labs and Hughes, formed a company (R-W) in 1954 to perform systems engineering for the Air Force’s ICBM program. In 1956, R-W and the Air Research and Development Command (under the direction of Bernard Schriever) reached a legal definition of systems engineering: (1) The solution of interface problems among all weapon system subsystems to insure technical and schedule compatibility of the systems as a whole. (2) The surveillance over detailed subsystems and overall weapon design to meet Air Force required objectives. (3) The establishment and revision of program milestones and schedules and monitoring of contractor progress in maintaining schedules, consistent with sound technical judgment and rapid advancement of the state of the art [Johnson, 2002]. R-W later became TRW.

Hall [1962] asserts that the first attempt to teach systems engineering as we know it today came in 1950 at MIT by George W. Gilman, Director of Systems Engineering at Bell [1953]. The first book on Systems Engineering was written by Goode and Machol in 1957, titled System Engineering – An Introduction to the Design of Large-Scale Systems.

Hall [1962] defined systems engineering as a function with five phases: (1) system studies or program planning; (2) exploratory planning, which includes problem definition, selecting objectives, systems synthesis, systems analysis, selecting the best system, and communicating the results; (3) development planning, which repeats phase 2 in more detail; (4) studies during development, which includes the development of parts of the system and the integration and testing of these parts; and (5) current engineering, which is what takes place while the system is operational and being refined.

The RAND Corporation was founded in 1946 by the United States Air Force and created systems analysis, which is certainly an important part of systems engineering.

The Department of Defense entered the world of systems engineering in the late 1940s with the initial development of missiles and missile defense systems [Goode and Machol, 1957].

Paul Fitts addressed the allocation of the system’s functions to the physical elements of the system in the late 1940s and early 1950s [Fitts, 1951].

There is a special bibliography on the Wiley website for this book devoted to historical references.

The products of the design process serve as inputs to the hardware and software design of detailed CI design. The CIs then reenter the systems engineering process during system integration for integration testing, verification, and validation. Further adjustments to the design occur during the refinement phase. The life cycle phases associated with the engineering of the system are shaded in Figure 1.1. The term concurrent engineering simply means that the systems engineering process should be done with all of the phases (and their associated requirements) of the system life cycle in mind [Prasad, 1996]. This notion of concurrent engineering is a key concept addressed in this book.

The importance of systems engineering is highlighted by examining a generally accepted relationship between the phases of the system life cycle and the commitment versus the incursion of costs. The time associated with the system’s life cycle is plotted on the x-axis; note that the time increments are notional and should not be interpreted as equal to the relative length of the four stages being addressed. See Prang [1992] for an illustration based on computer boards. (Prang is also referenced in Scheiber [1995].) Figure 1.2 shows the major phases of the system life cycle on the horizontal axis. The curves represent the cost committed, based upon engineering design decisions, and the cost incurred, based upon actual expenditures. As can be seen, about 80% of the cost of the system is committed by the end of design and integration, while only about 20% of the actual cost for the system has been spent. Obviously, mistakes made in the front end of the system life cycle can have substantially negative impacts on the total cost of the system and its success with users and bill payers.

FIGURE 1.2 Cost commitment and incursion in the system life cycle.

There have been many definitions of systems engineering put forward since the 1950s when systems engineering became a profession. Table 1.1 provides several of these definitions. There are two important trends to note over the 20-year span of these definitions. First, the role of management in the systems engineering process is made explicit in the definitions from the 1990s. Second, the three pillars of engineering success (cost, schedule, and technical performance) from the 1970s evolved into concerns over the life cycle, namely concurrent engineering.

The American Heritage Dictionary [Berube, 1991] defines engineering as:

The application of scientific and mathematical principles to practical ends such as the design, construction, and operation of efficient and economical structures, equipment, and systems.

The following definitions of engineering and the engineering of systems are adopted here:

Engineering