Model-Based Systems Engineering

16 downloads 0 Views 4MB Size Report
Model-based systems engineering: an introduction to the mathematical theory of discrete .... transfer functions, and the structure of the functionality cotyledon are defined .... statistics, economics, operations research, computer science, numerical analy ...... van Gigch, J. P. (1978) Applied General Systems Theory (2nd ed.).
Model-Based Systems Engineering

systems engineering series series editor A. Terry Bahill, University of Arizona The Art of Systems Architecting Eberhardt Rechtin, University of Southern California Mark Maier, University of Alabama at Huntsville Fuzzy Ruk'Based Modeling with Applications to Geophysical Biological and Engineering Systems Andras Bardossy, University of Stuttgart Lucien Duckstein, University of Arizona Systems Engineering Planning and Enterprise Identity Jeffrey O. Grady, JOG System Engineering Systems Integration Jeffrey O. Grady, JOG System Engineering Model-Based Systems Engineering A. Wayne Wymore, Systems Analysis and Design Systems Linear Systems Theory Ferenc Szidarovszky, University of Arizona A. Terry Bahill, University of Arizona The Road Map to Repeatable Success: Using QFD to Implement Change Barbara A. Bicknell, Bicknell Consulting, Inc. Kris D. Bicknell, Bicknell Consulting, Inc. Engineering Modeling and Design William L. Chapman, Hughes Aircraft Company A. Terry Bahill, University of Arizona A. Wayne Wymore, Systems Analysis and Design Systems The Theory and Applications o f Iteration Methods loannis K. Argyros, Cameron University Ferenc Szidarovszky, University of Arizona Systems Engineering Guidebook: A Process for Developing Systems and Processes James N. Martin, Texas Instruments Fuzzy Rule Based Computer Design John Newport, Newport Systems Incorporated System Validation and Verification Jeffrey O. Grady, JOG System Engineering System Engineering Deployment Jeffrey O. Grady, JOG System Engineering Systems Architecting of Organizations: Why Eagles Can't Swim Eberhardt Rechtin, University of Southern California

Model-Based Systems Engineering A. Wayne W ym ore

CRC P R E S S Boca Raton

London

New York W ashington, D .C .

Library of Congress Cataloging-in-Publication Data Wymore, A. Wayne Model-based systems engineering: an introduction to the mathematical theory o f discrete systems and to the tricotyledon theory of system design / by A. Wayne Wymore — 1st ed. p. cm. — (Systems engineering series) Includes bibliographical references and index. ISBN 0-8493-8012-X 1. Systems engineering— Mathematical models. 2. Engineering mathematics. 3. System design. I. Title. II. Series. TA168.W 912 1993 6 2 0 '.0 0 r i — dc20 92-37410 CIP

This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity o f all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microfilming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. The consent o f CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. Specific permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Tradem ark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation, without intent to infringe.

Visit the CRC Web site at www.crcpress.com © 1993 by CRC Press LLC No claim to original U.S. Government works International Standard Book Number 0-8493-8012-X Library o f Congress Card Number 92-37410 Printed in the United States of America 7 8 9 Printed on acid-free paper

Contents Preface

ix

1 Systems engineering Introduction . . . . . System requirements . System design . System life cycle Exercises.

1

1 6

. 18 . 20 . 53

2 Systems Introduction Discrete systems . . System experiments System modeling . . System theoretic properties of system models Cartesian products and system artifacts System parameterizations . Exercises . . . . . . . . . . . . . . . . . . . 3 System coupling Introduction . . . . . . . . . . . . . . . . System coupling recipes . . . . . . . . . . Taxonomy of system coupling recipes . Resultants of system coupling recipes . . Theory of system coupling . . . . Components and subsystems . Exercises . . . . . . . . . . . 4 System homomorphisms Introduction . . . . . . . . Homomorphisms . . . . . . .. System isomorphisms . . . . . . Homomorphisms of system resultants Exercises . . . . . . . . . . . . . . . . . . .

. . . .

57 . 57 . 57 . 63 . 70

.72

.. 76 . 85

103

109 109 110

114 118

138 156 158

167 167 168

184 188 193

vi

Model-based systems engineering

5 System modes Introduction . . System modes Implementation System modes in design . System mode hologenicity Exercises . . . . . . . . . . . .

201 . . .. . . .. .

201 205 227 240 245 265

. . . . . .. . . . .

275 275 278 291 294 308 310

6 Input/output requirements

Introduction . . . . . . . . . . . . . . . . . . . . . . . The space of input/ output requirements . . . . .. Satisfaction of input/ output requirements . . . . . The functionality space . . . . . . . . . . . . . . . . Homomorphisms of input/ output requirements . Exercises . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Technology requirements

Introduction . . Technologies . . . . . Buildability . . . . . . The buildability space Implementability in technologies The implementability space . Exercises . . . . . . . . . . . . . . .

317 . . . .. .. . . .

317 318 320 333 334 351 355

. . . . . . .

361 367 383 404 408 432

. . . . . .. . .

437 438 442 452 467 468

8 Performance, cost, and trade-of£ requirements

Introduction . . . . . . . . . . Figures of merit . . . . . . . . . . . . . . . . . . . Combining figures of merit . . . . . . . . . . . . Specification of performance, cost, and trade-off requirements Design of a service delivery system . . . . . . . Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361

9 System test requirements

Introduction . . . . . . . . . . . . . . . . . . . . . . . The system life cycle and system test requirements Testability . . . . . . . . . . . . . . . . . . . . . . Development of system test requirements . System design problems Exercises . . . . . . . . . . . . . . . . .

Appendix 1: System design language Introduction . . . . Sets . . . . . . . . . The real numbers .

437

473

. 473 . .. 473 . .. 485

Contents Alphanumerics . Vectors . Functions ... . Orders . . . . . . Standard combinations of functions .

vii

488 489 496 531 566

Appendix 2: T3SD notation

579

Appendix 3: Examples of systems

591

Appendix 4: Examples of system parameterizations

641

Appendix 5: Examples of system coupling recipes

653

Appendix 6: Examples of input/output requirements

657

Appendix 7: Examples of input/output requirement parameterizations

677

Appendix 8: Examples of technologies

681

Appendix 9: Examples of system design problems, system designs, and implementable system test items

685

Bibliography

693

Index

697

Preface This textbook is intended for a two-semester course for students of systems engineering. The material in the text was chosen to attain three principal objectives: • to provide the system theoretic foundations necessary to the study and practice of systems engineering, • to explicate mathematical system theory as the basis for the develop­ ment of models and designs of large-scale, complex systems consisting of personnel, machines, and software, and • to introduce the student to the tricotyledon theory of system design (T3SD) and to the considerations involved in applying the theory to the design of real systems. The introductory chapter informally discusses definitions of systems engineering, system design, system analysis, system life cycle, system require­ ments, system functional analysis, physical synthesis, and the work products of systems engineering. Chapter 1 provides motivation for the study of mathematical system theory and system design methodology. Chapter 2 introduces the discrete system as a mathematical construct consisting of a set of states, a set of inputs, a set of outputs, a next state function, and a readout function. Also discussed are the concepts of time scale, input trajectory, state trajectory, output trajectory, and system experiments. Stand­ ard notation is established for all these concepts. The discrete system was chosen as the basis for this development primar­ ily for pedagogical reasons: more general system constructs (see Wymore, 1977) require more mathematical considerations (for example, topological considerations of the real line); the objective of the work is systems engineer­ ing, not necessarily system theory; thus, the discrete system allows the shortest line to be drawn from system theory to systems engineering without sacrific­ ing rigor or even very much modeling power. Chapter 3 discusses the mathematical theory of system coupling: how systems can be put together by input/output relationships to create hierarchi­ cal models of more complex systems. This discussion requires the concepts of

Model-based systems engineering input ports, output ports, connectable sets of systems, connectivity functions, coupling recipes, and system resultants of coupling recipes. The usual classi­ fication of coupling recipes into conjunctive, cascade, feedback and mixed categories is discussed. The concepts of system component and subsystem are defined. The homomorphic relationship between systems is the subject of Chap­ ter 4. The related concepts of isomorphism and simulation are also discussed. These concepts are essential to understanding and applying system design methodology, for they are the keys to consistent elaboration and consistent simplification of system models, to the determination of when two models are essentially the same, and to the essence of implementation. In Chapter 5, the concept of system mode is introduced to model identi­ fiable "modes of behavior" of a given system such as failure mode, nonfailure or operational mode(s), and transient modes. The system mode concept is compared and contrasted to the concepts of component and subsystem. The importance of the system mode concept in system design and development is demonstrated through examples. Survival of system modes of components to determine system modes of resultants is discussed. For undergraduates in a three-semester credit course, the first semester might end at this point. The second semester begins with Chapter 6. Chapters 6 thorough 9 are concerned with the mathematical structure of system requirements based on the concept of system developed in Chapters 2 through 5 and with the implications of that structure for system design. Chapter 6 introduces T3SD and the structure of the statement of the problem of the design of a system as consisting of six mathematical artifacts: • the input/output requirement, • the technology requirement, • the performance requirement, • the cost requirement, • the trade-off requirement, and • the system test requirement. In Chapter 6, the input/output requirement is discussed in detail, as are the concepts of satisfaction of an input/output requirement by a system. The space of functional system designs (also called the functionality cotyledon), transfer functions, and the structure of the functionality cotyledon are defined and the implications of these for system design are discussed. Chapter 7 discusses specification of the available technology as part of the statement of the problem of the design of a system. The concept of a system buildable in a given technology is introduced and the space of all buildable system designs (also called the buildability cotyledon) is defined. A system is implementable in a technology if there exists a system buildable in the

Preface

XI

technology which implements the given system. The space of implementable system designs, also called the implementability cotyledon, is defined as the set of systems, each system of which satisfies the input/output requirement and is implementable in the technology. The statement of a system design problem in T3SD requires the definition of three orders, one each over the functionality, the buildability, and the implementability cotyledons, representing the mathematical structures of the performance requirement, the cost requirement, and the trade-off require­ ment, respectively. Chapter 8 is devoted to the problems associated with these definitions and to their implications. Orders, trade-off orders, performance indices, finite probability density functions, and figures of merit and their thresholds are the basic concepts. Standard compositions and standard scor­ ing functions are discussed as a method of combining several figures of merit into a single figure of merit. The design of a class of systems called service delivery systems is discussed to illustrate the concepts. The plan by means of which the real, final system will be tested is considered to be part of the statement of the problem in T3SD. Chapter 9 establishes a structure for the system test plan appropriate to its role in the statement of the problem. Defined and discussed are the concepts of testable system representations, testable component representations, implementable test items, test tolerance orders, testing functions, and system test require­ ments. The objectives of the system test requirement are to define how the system is to be observed for testing purposes, to define compliance of the system with the system requirements, to define conformance of the system with the model (design) on the basis of which it was built, and to define the criteria for acceptance of the system. Chapters 6 through 9 are summarized at the end of Chapter 9 in the formal definition of the system design problem. This problem consists of properly related mathematical constructs representing an input/output requirement, a technology requirement, a performance requirement, a cost requirement, a trade-off requirement, and a system test requirement. This statement of the problem of the design of a system is the objective of Phase 1 of the system life cycle, requirements development. To design a system in T3SD means to choose a point in the implementa­ bility cotyledon, preferably optimal with respect to the trade-off requirement. One strategy for defining such a point is a process composed of two related but distinct subprocesses: system functional analysis^ and physical synthesis. These processes are the principal tools of Phase 2 of the system life cycle, concept development. Explication of the mathematical theory underlying

t The systems engineering technique herein called system functional analysis is not the same as the mathematical field of study known as functional analysis. That is why the process discussed herein is called system functional analysis" instead of the shorter "functional analysis," which might be misconstrued.

xn

Model-based systems engineering

system functional analysis and physical synthesis must await the publication of another work. The development of necessary mathematical system theory and the sys­ tem design methodology is carried out in the text on the basis of the mathe­ matical theory of sets. The parts of the theory of sets utilized herein are explicated in Appendix 1. The concepts and development in Appendix 1 can be considered the basis for a formal system design language elaborated throughout the rest of the text. Appendix 1 is devoted to a review of the set and function theory necessary to the mathematical system theory discussed in the remainder of the text. Although the emphasis is on engineering appli­ cations rather than on theorem proving, the style throughout the book is mathematically rigorous, based on the set and function theory presented in Appendix 1. The basic set and function theory is standard, consistent with the theory to be found in Halmos and Lipschutz.^ Some special notions in function theory have been introduced because of their usefulness in system theory. The con­ cepts in Appendix 1 can be introduced and/or reviewed as they are encoun­ tered in other chapters. The Appendixes include detailed definitions of all examples discussed in the text and a list of all notation used. The material in this book is the result of over 30 years' efforts. When I first started to study systems engineering in 1958,1 found little knowledge of or interest in systems engineering in the academic community. The only sys­ tems engineering treated in academia applied strictly to very specialized cases, such as control engineering based on linear differential equations. Systems engineering in its more general sense, as applied to the design of large-scale, complex man/machine/software systems was practiced only in government and industry, primarily defense, aerospace, and telecommunica­ tions. I adopted the policy, therefore, of spending university holidays through­ out my academic career consulting in governmental and industrial organiza­ tions actively engaged in systems engineering, thereby involving myself in virtually every facet of systems engineering. During the academic year, my research consisted in developing methodology and mathematical theory use­ ful to solve the problems and dispel the confusion I uncovered in my consult­ ing work. For the opportunities for this kind of operation, I hereby acknow­ ledge a debt of gratitude to the University of Arizona and to the following organizations: Agency for International Development, Baker Manufacturing, Bechtel National, Bell Communications Research, Bull HN Information Sys­ tems, Canadian Department of Agriculture, Centro Agronómico Tropical de Investigación y Enseñanza (Turrialba, Costa Rica), Centro Internacional de Agricultura Trópica (Cali, Columbia), China National Off-Shore Oil Corpora­ tion, City of Tucson (Department of Energy and the Environment), Digital

t The mention of one or more authors' names is a reference to an entry in the bibliography.

Preface

xin

Equipment Corporation, Environmental Research Laboratory, General Re­ search Corporation, GE TEMPO, GTE Sylvania, Harvard School of Public Health, Hughes Aircraft, Hungarian Department of Industry, IBM General Products Division, IBM Federal Systems Division, Johannes Kepler Univer­ sity, Johns Manville, Lechner Engineering, Lockheed Georgia, Oscar Mayer, Pure Oil, RCA, Shanghai Institute of Mechanical Engineering, Siemens (Munich, Germany), Sigma One, Tokyo Institute of Technology, UCLA, UNISYS, UNIVAC, University of Maryland, University of Virginia, U.S. Army Ballistic Missile Defense Command, U.S. Army Communications Command, U.S. Army Computer Command, U.S. Army Electronic Proving Ground, U.S. Department of Agriculture (Agricultural Research Service). The theory herein discussed is mathematically rigorous yet addressed directly to the practical problems of systems engineering. My students and I have applied the theory and methodology successfully to systems in diverse functional and technological contexts. Accordingly, the creation and publica­ tion of this book are the result of constructive responses from students in my various courses in mathematical system theory over the years and it is to them that this book is dedicated. I acknowledge the contributions of my University of Arizona colleagues who have tried to use various drafts of the book in teaching. Lucien Duckstein, Bob Baker, and Terry Bahill have been the most consistent contributors. Terry Bahill and Ricardo Zapata, in particular, have made many recommendations resulting in greater readability and comprehensibility of the book. I have received valuable, though at times painful, feedback from all of them. Still I am grateful. The support of my wife Muriel and of all my family (Farrell, Giana, Teisha and Bryan, Darcy, Chris and Ashley, Mel and Gerry, and Les and Jerry) was and is absolutely essential. I am extremely fortunate; I cherish them all.

Wayne Wymore Tucson, Arizona

Author A. Wayne Wymore is the Principal Systems Engineer of SANDS (Systems Analysis and Design Systems) and Professor Emeritus of Systems and Indus­ trial Engineering at the University of Arizona. He received a B.S. and M.S. in mathematics from Iowa State University in 1949 and 1950, respectively, and a Ph.D. in mathematics from the University of Wisconsin, Madison, in 1955. He was the first Chairman of the Department of Systems Engineering and the first Director of the Computer Center at the University of Arizona. Dr. Wymore has consulted nationally and internationally for many government agencies and private corporations. He is the author o i A Mathematical Theory o f Systems Engineering: The Elements, John Wiley & Sons, 1967 and Systems Engineering Methodology for Interdisciplinary Teams, John Wiley & Sons, 1976.

model-based systems engineering an introduction to the mathematical theory of discrete systems and to the tricotyledon theory of system design

chapter one

Systems engineering Introduction 1.1 The purpose o f this chapter is to motivate the mathematical theory developed in the rest o f the book; the purpose o f the mathematical theory is to support the systems engineering process described in this chapter. Before the definition of systems engineering is given, it is appropriate to discuss what systems engineering is not. Here is a short list of disciplines that systems engineering is not: applied mathematics, applied probability and statistics, economics, operations research, computer science, numerical analy­ sis, simulation, system theory, system science, human factors engineering, software engineering, agricultural engineering, civil engineering, electrical engineering, industrial engineering, manufacturing engineering, mechanical engineering. It has even been said that systems engineering is just good "blank" engineering, where the "blank" can be filled by any engineering descriptor whatever. "Blank" engineers ought to use the tools of systems engineering in their work and many do. It is rare, however, when "blank" engineers develop the intellectual tools to do a good job of systems engineering even in the very restricted field in which they are experienced, and almost never are "blank system" engineers able to apply their skills effectively in any other field. "Blank system" engineers are successful when they do not stray too far from the physical principles of their basic disciplines. It will become apparent, however, that systems engineering must start "above" the level of physics. Some have insisted that systems engineering is management. This is partly true, but systems engineering is more than management. Systems engineering, like any other human cooperative activity, must be managed, but nobody ever designed a good system by management without people who were skilled at the technical work of systems engineering. Each discipline in the preceding list deals with some aspect or aspects of systems engineering and systems engineering uses most of the tools repre­ sented in the above list, yet systems engineering is not the sum of the disci­ plines in the list. If one were to ask practitioners of any discipline in the

2

Model-based systems engineering

preceding list, they would characterize themselves as problem-solvers. Sys­ tems engineers, in contrast, are problem staters. The principal functions of systems engineering are: • to develop statements of system problems comprehensively, without disastrous oversimplification, precisely without confusing ambigu­ ities, without confusing ends and means, without eliminating the ideal in favor of the merely practical, without confounding the abstract and the concrete, without reference to any particular solutions or methods, • to resolve top-level system problems into simpler problems that are solvable by technology: hardware, software, and bioware, • to integrate the solutions to the simpler problems into systems to solve the top-level problem. By performing these functions, systems engineering becomes a bridge be­ tween the system problems generated by society and the solutions provided by technology. Systems engineering had to be invented because these functions have not been properly performed. Why are the functions of systems engineering so difficult to perform? The culprit lies in technical education. Everyone is taught to think in terms of solutions. Ask any person what he or she thinks about a current national problem; energy, juvenile delinquency, drugs— almost any problem will do for this test. That person will "know" or at least have an opinion about "the solution" to the problem. And the "better" educated we are, the more confident we will be that our solution is the "correct" one. Rarely will a person be found who will suggest that the problem is not well-under­ stood and that more resources should be invested in stating the problem before a "solution" is implemented. This orientation toward thinking about problems in terms of solutions begins even in the elementary grades, where the pupils are discouraged from asking questions about the problems or questions posed to them. The teacher rewards only "the answer." Pupils who question the problem statement are immediately banished to the "lunatic" fringe. Later on, in technical education, the student is given explicit techniques to solve relatively simple problems: Consider a spherical elephant(!)... and then assigned exercises in utilizing this technique on equally unrealistic problems. The students emerge from this educational experience as profes­ sionals with tool box mentalities, each one a Mr. Wrong Wrench going about the world looking for problems that they can solve with the tools in their tool boxes and, unfortunately, thinking that they find them or, at least, applying their tools willy-nilly, rarely even conscious that these tools were developed for problems much simpler than the one at hand! This tool-box mentality also explains, to an extent, the constant pursuit of and devotion to trendy new "solutions" to problems, such as statistics, information theory, cybernetics, operations research, control engineering.

Chapter one: Systems engineering biofeedback, computers, simulation, CIX (computer integrated anything), expert or knowledge-based systems. Each of these fields was heralded, by some, as the source of solutions to all problems; all of them have taken their appropriate and honorable places in the intellectual arsenal, but none have lived up to all the promises made for them. The reason is that not all problems can be stated in terms of a solution or class of solutions. Another culprit in education is mathematics. Here the student is taught to simplify problems as a technique for solving them. This is all right for problems involving relatively simple equations where the simplification pro­ cedures lead to perfectly equivalent problems. Blind simplification of largescale, complex system problems, however, almost always leads to disaster, because simplification procedures almost never lead to equivalent problemsl This is one reason that it is so important to characterize the set of all design solutions to a system design problem. ITiere is no discipline (except systems engineering) that teaches students how to state problems comprehensively, without disastrous oversimplifica­ tion, precisely without confusing ambiguities, without confusing ends and means, without eliminating the ideal in favor of the merely practical, without confounding the abstract and the concrete, and without reference to any particular solutions or methods. In the absence of such a problem statement, methodological errors are frequently perpetrated. For example, • Attempts are made to put together solutions to simple problems hop­ ing to solve a larger, though unstated, problem. The system is built from the bottom up: tying together islands of automation, etc. • A solution to an imprecisely stated problem is visualized and then the implementation of ti\at vision becomes the problem! This happens fre­ quently in industry and government as a result of "macho" or "politi­ cal" engineering. Basically, the error is to state the problem in terms of a "solution." If a system design problem has been stated only sketchily or hardly at all, then any system that is built will constitute a solution. Is this the reason that system design problems are not stated precisely and comprehensively: the fear that if the system design problem is stated precisely and comprehensively, then a favorite design might not be a solution? Or is it merely the innocent, but incorrect, perception that there is not enough time or other resources to do the job right? • A system is designed and built, but it turns out that it does not solve the real problem because the real problem was never stated. Then the real system itself becomes a real problem: to modify the real system so that it really does solve the original problem. Frequently, this retrofit­ ting must be accomplished by the users of the system at great expense. • Executives look first for technology to solve their problem before the problem is stated. To design a system, they call in the hardware and

Model-based systems engineering software vendors to see what they have that will "solve" their problem. This strategy will be employed by people who wouldn't dream of trying to build a building without an architect but wiU pay millions for hardware and software that will not solve the real problem. They wouldn't ask the plumbers, bricklayers, and electricians to design the buildings, but they would ask the hardware and software vendors (ignoring human factors) to design their systems! • The wrong people are assigned (or take it upon themselves) to design systems. Truck drivers cannot design trucks; no pilot would fly in an airplane designed entirely by airline pilots. Judges are not qualified to design systems for racial integration of schools. Physicians do not have the training to design health care delivery systems. Generally, a person cannot, and should not, design a system of which he or she is a component. Input of human components of systems is crucial to the design process for generating requirements, but rarely for designing systems. • Private and public foundations issue grants to support "applied" re­ search that neither science nor society knows how to "apply." There is certainly a place for pure science, but much research should be done within the context of an overall system design so that when the research is finished society and science know where it will fit and can be used. • Systems are designed and built to solve overly simplified problems and thus create more problems than they solve. • Systems are designed and built to solve problems, and society then finds that the system proponents cannot prove that they have accom­ plished anything! This seems to be especially true for social systems. • Acquisition of large-scale, complex systems seems typically to involve huge cost and schedule overruns and disastrous performance short­ falls. How can these methodological errors be avoided? These errors can be avoided or vastly ameliorated through the process of systems engineering carried out by well-trained systems engineers. What, then, is the systems engineering process? The definition of the systems engineering process has the following objectives: • to incorporate the total system point of view, • to incorporate the point of view that systems exist to serve human needs, • to incorporate the system life-cycle point of view, • to apply to the design of personnel/machine/software systems in any functional or technological context.

Chapter one: Systems engineering

5

• to be independent of but adaptable to any customer, • to be couched in informal and intuitive terms but to constitute the basis for mathematical definitions, • to provide the basis for professional education and activity, and • to clarify the concepts of system design and system analysis and the relationship of systems engineering to other disciplines. The definition of the process of systems engineering proposed herein is intended to be applicable to the design and implementation of any bioware/hardware/software system. This definition entails definitions of sys­ tems engineering as a discipline, system design, systems analysis, system modeling, system life cycle, system requirements, and systems engineering work products and their roles in the system life cycle. All definitions given in this chapter are generic in the sense that they are independent of the customer and of the technological or functional context. The assumptions behind such generic definitions are that the reports and reviews required by a particular customer can be derived from the data base generated for and recorded in the generic documents and that systems engi­ neering concepts are applicable to die design of a system in any technological or functional context. Definitions given in this chapter are informal, as distinguished from mathe­ matical. Key informal definitions, however, will constitute the basis for the intuition behind mathematical definitions that will appear in later chapters. 1.2 Definition: System s engineering is the intellectual, academic, and profes­ sional discipline the principal concern o f which is the responsibility to ensure that all requirements for a biowarelhardwarelsoftware system are satisfied throughout the life cycle o f the system. 1.3 Who does systems engineering? Every organization, by the very defini­ tion of the words organization and systems engineering, performs the func­ tions of systems engineering: The organization is a system that must be designed or must have been designed in some sense. Any systems produced by the organization must be or must have been designed and so it must have been for the production system itself. Some one or some group must accept or abnegate the responsibility for such systems at various crucial points through­ out their life cycles. Some organizations perform systems engineering func­ tions unconsciously; some hide systems engineering under the guise of man­ agement or product development or even marketing. Some do systems engineering well; most do systems engineering without skill or knowledge, clumsily or badly. 1.4 To what kinds of systems can systems engineering be applied? The pro­ cess of systems engineering herein discussed is applicable to the design of bioware/hardware/software systems in any context. To indicate the spectrum

6

Model-based systems engineering

of contexts intended, here is a short list of specific types of bioware/hard­ ware/software systems^ requiring disciplined and skillful systems engineer­ ing efforts: accounting, agricultural information, agricultural water quality, air pollution control, air traffic control, aircraft, antisubmarine, architectural, automobile, ballistic missile defense, biological control, communication, com­ puter, construction, day-care, distributed computer, earthquake warning, ecological management, education, emergency medical, energy production and distribution, equal opportunity, expert, farming, fire protection, food production and distribution, garbage recycling, health delivery, housing, information, inventory, juvenile delinquency control, language translation, law enforcement, mail, management information, manufacturing, mining, natural resource management, national park, navigation, nuclear energy, oceanographic, organizational modeling, payroll, pest control, publishing, queuing, railroad, rural transportation, safety assurance, school desegregation, sensory, service delivery, simulation, software, space colonization, systems engineering management, systems engineering software, telecommunica­ tions, urban planning, urban transportation, warehousing, waste manage­ ment, water resource, weapons, welfare. Communications (Hall), aircraft (Systems Management—Systems Engineer­ ing Management During Definition and Acquisition Phases and Systems Engineer­ ing Management Procedures), and weapons systems (Military Standard—Sys­ tems Engineering Management, MIL-STD-499) have been particularly important historically in the development of the concept and practice of systems engi­ neering (Goode and Machol). 1.5 Large-scale, complex, bioware, hardware, software systems: Most of these involve a large number of components and are said to be large-scale systems. Almost all require many interrelationships among the components and are characterized as complex. Substantial systems engineering efforts to ensure the satisfaction of all requirements are more easily justified for largescale, complex, bioware/hardware/software systems.

System requirements 1.6 System requirements and system life cycle: Note that all the systems in the preceding list are made to solve some human problem; they are designed, built, tested, operated, junked, and replaced. This observation will be built into the definition of the system life cycle. But first, the concept of system requirements must be clarified. If systems engineering is to be responsible to ensure that the system satisfies all its requirements, throughout the system's life cycle, what are system requirements and from where do they come? Informally, in the first t The systems in the following list are those in which the author, his colleagues, or his students at the University of Arizona have been involved.

Chapter one: Systems engineering

7

instance, requirements for a system can be developed by asking the following archetypal questions and helping the customer to answer them: • What is the system supposed to do? What is it supposed to accomplish? What inputs must be processed and what outputs produced? What is the essence of the system in technology-free terms? • What is available to build the system? Are there restrictions on what must be used or what can be used? • How well must the system do whatever it is that the system is supposed to do? By what criteria is the performance of the system to be judged? • What are the criteria for judging how well available resources have been used in building and operating the system? What are the cost requirements for the system? • What are the trade-offs between performance and cost? • How can it be proven that the system, when built and operating, does indeed perform and that resources have been utilized as predicted? How can it be proven that all requirements have been met? How can it be proven that the system is acceptable to the customer? Corresponding to these six types of questions, system requirements are classified into six categories: input/output requirements, technology require­ ments, performance requirements, cost requirements, trade-off requirements, and system test requirements. Such a categorization of system requirements assists systems engineers during the system design process: • to minimize the probability that something crucial will be missed, by providing a consistent, precise, and comprehensive structural checklist, • to define requirements with full knowledge of which requirements are independent of others and, when dependencies exist, exactly what the dependencies are, • to highlight and, to the extent possible, to isolate critical issues in the process of system requirements definition, • to avoid confusing the ends the system to be designed is to serve, with the means used by the system to accomplish those ends, • to be able to consider with equanimity, in order to gain insight, ideal, do-nothing, and other bizarre solutions as well as practical solutions, • to provide a context within which any solutions to a system design problem can be evaluated and compared, • to avoid confusing the abstract definition of a concept such as reliability with its estimate on the basis of a design and with the concrete defini­ tion for its observance or measurement for a real system, and

8

Model-based systems engineering » to avoid stating the problem in terms of a preconceived solution or class of solutions.

The last is a most damaging, yet the most common methodological error: to state a problem in terms of a preconceived solution or even a preconceived class of solutions. When a solution is chosen in advance, the real problem is never stated, and the solution fails because the world is not seen as it is but as the problem-solver wants it to be so that his or her solution will be the correct one. This methodological error guarantees failure because the design errors inherent in the class of solutions remain to prevent any solution in the class from solving the real problem. Furthermore, truly creative designs are elimi­ nated at the outset. 1.7 Definition: There are six categories o f system requirements: (i) (ii) (Hi) (iv) (v) (vi)

input/output requirements, technology requirements, performance requirements, cost requirements, trade-off requirements, and system test requirements.

1.8 Definition: The statement o f a system design problem consists o f explicit definitions o f the input/output requirement, technology requirement, performance re­ quirement, cost requirement, trade-off requirement, and the system test requirement. Collectively, these requirements are called the system design requirements. Note that a system design problem needs only one requirement in each category. This is because— as is developed in subsequent chapters—for any system design problem, the requirement in each category, no matter how complicated, is represented by a single system theoretic construct.

Input/output requirements 1.9 Inputs and outputs: Every system of interest to systems engineering accepts and processes inputs and produces outputs. For example, the input to a personal computer can be considered keystrokes delivered to the keyboard, electrical power, signals from a modem, and information on floppy disks. Each key on the keyboard could be considered an input port for the personal computer as could the power supply, modem receptacles, and the floppy disk drive. At any given time, "the" input to the personal computer would be considered the collective conditions of all the input ports at that instant of time. If a record were kept over a period of time of all the inputs to a personal computer, that record would be called an input trajectory. The output from the personal computer can be considered the monitor image, information on floppy disks, and signals to a modem, a printer, and other peripherals. Each pixel on the monitor could be considered an output

Chapter one: Systems engineering port for the personal computer, as could the power supply, modem recepta­ cles, and the floppy disk drive. At any given time, "the" output from the personal computer would be considered the collective conditions of all the output ports at that instant of time. If a record were kept over a period of time of all the outputs from a personal computer, that record would be called an output trajectory. The words "could be considered" used in the previous two paragraphs are an acknowledgment that the descriptions given in those paragraphs represent only one of many possible, and equally valid, ways to go about modeling a personal computer. 1.10 Definition: A trajectory is any function o f time. An input trajectory is a schedule or a time record o f the way in which inputs can (do, will, might, ought to) arrive at the input ports o f a system. An input trajectory can be thought o f as a history o f the input experience o f a system. An output trajectory is a schedule or time record o f the outputs produced by a system at its output ports over a period o f time. The statement of the problem of the design of any system must begin with the definition of the inputs that the existing system shall accept, process, or survive and the outputs that the system shall produce. 1.11 Definition: The input/output requirem ent for a system to be designed consists o f specifications o f (i)

(ii) (Hi) (iv) (v) (vi)

the length o f the operation al life o f the system to be designed, that is, the length o f the operations phase o f the system life cycle: see 1.53 and 1.105 (this sets a standard time scale for all input and output trajectories), the set o f inputs to be accepted by the system to be designed, the set o f input trajectories or histories which the system to be designed might experience, the set o f outputs producible by the system to be designed, the set o f output trajectories that are possible fo r the system to be designed, and the elig ibility function that matches outputs and inputs or input trajectories and eligible output trajectories; the eligibility function limits, or specifies, the behavior o f the system to be designed.

The input/output requirement determines a set of system designs called functional system designs. 1.12 Definition: A fu n ction al system design is a system design that satisfies the input/output requirement. A system design satisfies the input/output requirement if the design specifies the same inputs and outputs as specified by the input/output requirement and, in addition, the relation between inputs and outputs implied by the design is one of those specified as possible or permissible or eligible by the eligibility

10

Model-based systems engineering

function in the input/output requirement. A functional system design speci­ fies what the system should do in order to accomplish its mission. The set of all functional system designs is also called the space of functional system designs or the functionality cotyledon, 1.13 Cotyledons: The name cotyledon was adopted during the development of the theory expounded in this book when cartoons were drawn to help conceptualize the spaces of system designs of various kinds. No one knew, or knows, what these spaces "really" look like, but the cartoons always seemed to turn out to have a leaf shape. A student suggested that these leaf shapes were "cotyledons" (or seed leaves) because they were generated by the statement of the problem of the design of a system and the ultimate system design would eventually "flower" from these "cotyledons" (see the figures at 1.14,1.18, and 1.35). Since there are three basic spaces of system designs, the theory came to be known as the tricotyledon theory of system design, or T3SD for short. 1.14 Figure 1.1 is a caricature of the functionality cotyledon—the space of all functional system designs for a given system design problem.

Technology requirements 1.15 Functional system designs and technologies: A functional system de­ sign can be thought of as a logical design. The functional system design satisfies the input/output requirement and, hence, specifies what the system should do, not how the system can do what it should do. How the system can be built to perform as specified by a functional system design is determined by the technology requirement. The technology requirement for a system to be designed consists princi­ pally of limitations, specified by the customer, on what in the current or foreseeable technology is to be considered available to build the system to be designed. The customer may specify that certain components shall be used or that certain components shall not be used or both. The customer may specify that the available technology consists only of the equipment and personnel currently in the customer's organization. The technology requirement can be thought of as a catalog specifying which components are to be considered available to build the system to be designed. 1.16 Definition: The techn ology requirem ent for a system to be designed con­ sists o f the specification o f the set o f components—hardware, software, and human or bioware—considered, by the designers and the customer, to be available to build the system to be designed. The technology requirement is usually defined in terms of components or types of components that cannot be used or that must be used or both. No attempt is made to enumerate all the components in the technology unless the tech­ nology is severely restricted.

Chapter one: Systems engineering

11 Conceptually, each point Is a functional system design

Figure 1.1 Caricature of the functionality cotyledon— the space of all functional system designs for a given system design problem.

The technology requirement for a system to be defined is frequently referred to as the available technology or merely, the technology. 1.17 Definition: A bu ildable system design is a design specifying the system that results from coupling together components, all o f which are in the technology. A buildable system design specifies how a system is to be built in the technol­ ogy. The set of all buildable system designs is also called the space of buildable system designs or the buildability cotyledon. 1.18 Figure 1.2 is a caricature of the buildability cotyledon—the space of all buildable system designs for a given system design problem.

Performance requirements 1.19 Performance figures of merit: The performance requirement specifies how well the input/output requirement shall be met in terms, for example, of expected response time, the capacity to respond, and the expected quality of the response. These latter numbers are called performance figures of merit. For every system design that satisfies the input/output requirement, that is, for every functional system design, it must be possible to compute or estimate the value of such figures of merit. Ultimately, the performance requirement is stated so comprehensively that any two functional system designs under consideration can be compared with respect to how well each satisfies the input/output requirement, where "how well" is defined in terms of perform­ ance figures of merit.

12

Model-based systems engineering

Figure 1.2 Caricature of the buildability cotyledon- -the space of all buildable system designs for a given system design problem.

1.20 Definition: A perform an ce fig u re o f m erit is a function defined over the space o f functional system designs, over the functionality cotyledon. 1.21 Definition: P erform ance thresholds: For each real-valued performance fig ­ ure o f merit, an upper threshold and a lower threshold are defined. A functional system design that has a value for a figure o f merit smaller than the lower threshold for the figure o f merit is either impossible or unacceptable. Similarly, a system design that has a value for a figure o f merit larger than the upper threshold for the figure o f merit is either impossible or unacceptable. 1.22 For example, in the case of the design of an emergency medical system, the lower and upper thresholds for response time might be specified as 0 and 10 minutes, respectively. 1.23 Definition: The perform an ce requirem ent for a system to be designed is an algorithm by means o f which any two fu n ction al system designs can be com pared consistently with respect to how w ell each satisfies the input/output requirement. The performance requirement algorithm is usually defined in terms of per­ formance figures of merit and their thresholds. 1.24 Figure 1.3 is a caricature of the performance requirement determining contours of equivalent functional system designs in the functionality cotyledon.

Cost requirements 1.25 The cost requirement is based on what the system will cost to build and operate in terms, for example, of figures of merit representing expected capital

Chapter one: Systems engineering

13

Figure 1.3 Caricature of the performance requirement determining contours of equivalent functional system designs in the functionality cotyledon.

required, expected operations and maintenance costs, expected life-cycle cost, expected environmental and social costs, and the trade-offs among these cost figures of merit. For every buildable system design, it must be possible to compute or to estimate the value of such figures of merit. Ultimately, the cost requirement is stated so comprehensively that any two buildable system designs under consideration can be compared with respect to how much each would cost to build and to operate in all the dimensions in which these costs must be represented. 1.26 Definition: A co st figure o f m erit is a function defined over the space o f buildable system designs, over the buildability cotyledon. 1.27 Definition: C ost thresholds: For each real-valued cost figure o f merit, an upper threshold and a lower threshold are defined. A buildable system design that has a value for a figure o f merit smaller than the lower threshold fo r the figure o f merit is either impossible or unacceptable. Similarly, a buildable system design that has a value for a figure o f merit larger than the upper threshold for the figure o f merit is either impossible or unacceptable. 1.28 For example, in the case of the design of an emergency medical system, the lower and upper thresholds for operations and maintenance cost might be specified as $0 and $750,000 per year, respectively. 1.29 Definition: The co st requirement for a system to be designed consists o f an algorithm by means o f which any two bu ildable system designs can be com pared consistently. The cost requirement algorithm is usually defined in terms of cost figures of merit and their thresholds.

14

Model-based systems engineering

Figure 1.4 Caricature of the cost requirement determining contours of equivalent buildable system designs in the buildability cotyledon.

1.30 Figure 1.4 is a caricature of the cost requirement determining contours of equivalent buildable system designs in the buildability cotyledon. 1.31 Implementable system designs: Some functional system designs may not be buildable in the technology. For example, a functional system design could be defined to specify instantaneous mass transfer, a function not imple­ mentable in any technology known at the present outside of science fiction. Buildable system designs may not satisfy the input/output requirement. Who has not built a "system" that doesn't "work"? When a functional system design is implementable by a buildable system design, the pair of designs constitutes an implementable system design. The functional system design part of the implementable system design specifies what the system is sup­ posed to do in order to satisfy the system requirements, and the buildable system design part specifies how it is to be built. 1.32 Definition: A bu ildable system design im plem ents a fu n ction al system design when the buildable system design has a m ode o f behavior that exhibits the samefunctional capability, orfunctionality, as the behavior specified by thefunctional system design. Each o f the system functions specified by the functional system design is assigned for execution by one or more o f the components or subsystems specified in the buildable system design. 1.33 Modes of behavior: Every system exhibits several modes of behavior, at least a failure mode and an operational mode. In addition to these, a personal computer, for example, exhibits off and on modes, an internal checking mode when first turned on, waiting mode, and other modes depend­ ing on the controlling software: The behavior of the personal computer is

Chapter one: Systems engineering

The functionality cotyledon

The implementability cotyledon, the space of all implementable system designs

15

The bulldabillty cotyledon

Conceptually, each point in the Implementability cotyledon is an Implementable system design consisting of a functional system design FSD and a buildable system design that implements FSD

Figure 1.5 Caricature of the implementability cotyledon, the space of all pairs con­ sisting of a functional system design together with a buildable system design that implements the functional system design, for a given system design problem.

identifiably different when under the control of a word processor than when under the control of a spreadsheet program. 1.34 Definition: An im plem entable system design consists o f a functional system design together with a buildable system design that implements the functional system design. The set of all implementable system designs is also called the space of imple­ mentable system designs or the implementability cotyledon. 1.35 Figure 1.5 is a caricature of the implementability cotyledon, the space of all pairs consisting of a functional system design together with a buildable system design that implements the functional system design, for a given system design problem.

Trade-off requirements 1.36 Trade-off between performance and cost: The trade-off requirement specifies how the performance requirement is to be traded off against the cost requirement. Ultimately, the trade-off requirement must be stated so compre­ hensively that any two implementable system designs under consideration can be compared with respect to the trade-off between the performance requirement and the cost requirement. 1.37 Definition: The trad e-off requirem ent fo r a system to be designed consists o f an algorithm by means of which any two im plem en table system designs can

16

Model-based systems engineering

be com pared consistently with respect to a trade-off between the performance and cost requirements. Two implementable system designs can be compared both with respect to performance—^because each implementable system design includes a func­ tional system design—and with respect to cost—^because each implementable system design includes a buildable system design. If one implementable system design is preferred to another implementable system design with respect both to performance and cost, then the trade-off algorithm must result in the same preferences. The trade-off algorithm can only decide the preferences between two implementable system designs when they are equivalent with respect both to performance and cost or when the comparison with respect to performance does not agree with the comparison with respect to cost. This is the essence of a trade-off algorithm. (The system theoretic meaning of a trade-off between the perform­ ance and cost requirements is discussed in Chapter 8 and in Appendix 1.) A trade-off figure of merit is a function defined over the set of implementable system designs, that is, over the implementability cotyledon. The trade­ off requirement is usually defined in terms of performance, cost, and trade-off figures of merit and their thresholds. 1.38 Figure 1.6 is a caricature of contours of equivalent implementable system designs determined by the trade-off requirement.

System test requirements 1.39 The system test situation: By the comparison of candidate implementable system designs with respect to the performance, cost, and trade-off requirements, an implementable system design (ISD) is chosen and, on the basis of the ISD, a real system is built. The real system must be tested within the context determined by the system requirements and the ISD. 1.40 Definition: An im plem en table test item is a pair consisting o f an imple­ mentable system design and a real system built on the basis o f the implementable system design. 1.41 Definition: The system test requirem ent specifies for each possible imple­ mentable test item: • O bservance: How the real system shall be observed, sampled, measured, stimulated, simulated, and so forth, in order to estimate a value for each performance, cost, and trade-off figure o f merit. The set of estimates o f the values o f all these figures o f merit is called the test data. • C onform ance: How it shall be proved, in terms o f the test data, that the real system is in conformance with the implementable system design from which it was built. • C om pliance: How it shall be proved, in terms o f the test data, that the real system is in compliance with the system requirements.

Chapter one: Systems engineering

The functionality cotyledon

17

The buildability cotyledon

The Implementabillty cotyledon

Contours represent Implementable system designs equivalent with respect to the trade-off between the performance and cost requirements, generated by the trade-off requirement

Figure 1.6 Caricature of contours of equivalent in\plementable system designs deter­ mined by the trade-off requirement.

• A cceptance: How it shall be proved, in terms o f the test data, that the real system is acceptable to the customer. 1.42 Observance, conformance, compliance, and acceptance: For each pos­ sible implementable test item, the system test requirement specifies how and to what extent the real, final system shall be tested, observed, and measured and how, on the basis of the test data, values for all the figures of merit defined as part of the performance, cost, and trade-off requirements shall be estimated. This is called the observance specification. For each possible implementable test item, the system test requirement specifies, in terms of the test data, how to determine the compliance of the system with all the requirements. This is called the compliance specification. This determination can be independent of the implementable system design, models, or blueprints from which the real system was built. The relation of the real system to the implementable system design, models, or blueprints is handled in the conformance specification. For each possible implementable test item, the system test requirement specifies, in terms of the test data, how to determine the conformance of the real system to the implementable system design on the basis of which the real system was built. This is called the conformance specification. Depending on the way in which conformance and compliance are defined, it is possible that the real system can be in compliance with the system requirements but not in conformance with the implementable system design or that the real system can be in conformance with the implementable system design but not in compliance with the requirements. The point here is that it is the responsibility of system engineering to negotiate these specifications with the customer.

18

Model-based systems engineering

For each possible implementable test item, the system test requirement specifies, in terms of the test data, how to determine the acceptance of the real system to the customer. This is called the acceptance specification. Typically, the criteria for acceptance of the real system to the customer will include the necessity for compliance with the requirements and conformance to the implementable system design, plus other criteria not included elsewhere in the system requirements. A distinction is made herein between development testing and system testing. The requirements for development testing may be different from those for system testing. This concludes the introductory discussion of the categories (input/output, technology, performance, cost, trade-off, and system test) of system requirements. This discussion is continued throughout the book at increasing levels of detail and mathematical rigor. There will be many more opportuni­ ties to deepen understanding of what has been discussed so far.

System design 1.43 Systems engineering takes the responsibility to ensure that the system satisfies all its requirements throughout its life cycle. There are six categories of system requirements: input/output, technology, performance, cost, trade­ off, and system test. These have been defined in terms of system design and system designs. What precisely does it mean to design a system, and what is a system design? 1.44 Definition: System design: To design a system is to develop a model on the basis o f which a real system can be built, developed, or deployed that will satisfy all its requirements.^ This definition should not be surprising because the products of engineers in every field are, and have always been, models: physical models, architectural drawings and specifications, prototypes, shop drawings, etc. On the basis of such models real systems are built. Engineers also develop mathematical models based on physical considerations, for example circuit equations, in which specified parameter values determine the building of the system. Many types of models of the system to be designed may be developed, for example, functional system designs (see the definition at 1.12), on the basis of which a system could not be built because they do not contain enough physical details. These may still be called system designs because they are necessary parts of or steps toward a system design on the basis of which a system could be built. Thus, the process of system design is not finished until t The earliest published introduction of the concept of model-based system design can be found in J. Rozenblitt and B. Zeigler, "Design and Modeling Concepts," in the International Enq/clopedia o f Robotics, R. Dorf, Ed., John Wiley & Sons, New York, 1988, pp. 308-322.

Chapter one: Systems engineering

19

a model has been developed on the basis of which a real system could be built, but many "designs" may have to be developed during the process. 1.45 System design is creative: The concept of system design is usually ap­ plied to a system to be created—one that has not existed before or one that is to replace an existing system. The concept of system analysis is similar to that of system design.

Systems analysis 1.46 Definition: System analysis: To analyze a system is to develop a model by means o f which a real system will be managed, controlled, augmented, evaluated, or modified in order to satisfy all its requirements. 1.47 System design and system analysis both depend on models: The con­ cept of system analysis is usually applied to a system that exists, where frequently the objective is to improve performance or reduce cost or to add a component, to control air pollution, for example, or to take advantage of new technology such as fiber optics. The concept of system analysis is sometimes applied also to a system that is presumed to exist but is actually represented only by a model and a computer simulation, where the objective is to evaluate the system. This latter type of system analysis is an intrinsic part of the system design process. The definitions of system design and system analysis imply that models, modeling, and the manipulation and exercise of models are important pre­ occupations of systems engineers. In a sense, the work involved in the pro­ cesses of system design and system analysis can be completely characterized as the creation and manipulation of models. If modeling is the essence of system design, what does it mean to model?

System modeling 1.48 Definition: To m odel a phenom enon is to select from a set o f models, on the basis o f predefined criteria, an element to represent the phenomenon. 1.49 Familiar example of modeling: The best known modeling context is linear regression wherein the set of models is the set of equations of the form Y = A ♦ X + B where A and B are any real numbers. A set of data of the form (XI, Y1),...,(XN, YN) is modeled in this set of models by choosing A and B according to the following criterion: the sum of squares of deviations is minimized. 1.50 Models for systems engineering: For the purposes of practical sys­ tems engineering, the set of models utilized includes not only all those models traditionally produced by engineers—physical models, prototypes, drawings, specifications, and mathematical models based on physics—^but also another

20

Model-based systems engineering

type of model better suited to describe and manipulate organizational prob­ lems—system theoretic models. System theoretic models are developed, ma­ nipulated, and managed by systems engineers throughout the life cycle of any large-scale, complex, bioware/hardware/software system. For the purposes of a mathematical theory of system design, the set of system theoretic models chosen for development in this book, for both prac­ tical and pedagogical reasons, is the set of discrete-time automata or state machines. The set of such models is designated DSYSTEMS. The several types of designs that have been identified in the definitions at 1.12, 1.17, and 1.34—functional system designs, buildable system designs, and implementable system designs—will be represented by system theoretic models in the set DSYSTEMS. A functional system design in the functionality cotyledon is a model that satisfies the input/output requirement, that is, a system model that accepts the inputs, produces the outputs, and performs the function specified by the input/output requirement. A buildable system design in the buildability cotyledon is a model buildable within the technology require­ ment, where each component in the technology is itself represented by a model in DSYSTEMS. An implementable system design in the implementability cotyledon is a model composed of a functional system design and a buildable system design such that the buildable system design is an implementation of the functional system design. The set DSYSTEMS of systems models contains, therefore, all possible designs for the system to be designed. The criteria for the selection of a model from this set to represent the system design—that will guide the building of the real system—shall be derived from the system requirements so that, on the basis of the model chosen, a real system can be built that will satisfy all its requirements. 1.51 Figure 1.7 is a caricature of the space of all possible system designs.

System life cycle 1.52 If systems engineering must ensure that the system satisfies all its requirements throughout its life cycle, the system life cycle must be thor­ oughly understood. The system life cycle is structured to enable systems engineering to assume the responsibility for ensuring that the system will satisfy all its requirements throughout the system's life cycle. Thus, the first phase of the system life cycle is that in which systems engineering establishes the system requirements. In the next phase, systems engineering must decide on the overall design of the system and the basic components and must establish requirements for the components and their interrelationships. In the third phase, the detailed design of the components is accomplished by hardware, software, and bioware (human factors) engineers coordinated by systems engineering. Note that in the first three phases, the system itself

Chapter one: Systems engineering

21

Figure 1.7 Caricature of the space of all possible system designs.

exists only in terms of models or designs, yet it is still the responsibility of systems engineering to ensure that a system that might be built on the basis of these models would indeed satisfy the requirements. In the fourth phase, the components are acquired, built, developed, or trained (as in the case of human or bioware components), the real components are coupled, and the real system is deployed imder the coordination of systems engineering. In the fifth phase, the real system is tested by systems engineering. In the sixth phase, the system is put into operation. In the seventh phase, the system is retired and replaced. 1.53

Definition: The system life cycle is defined in seven phases: Phase 1: Requirements development, Phase 2: Concept development, Phase 3: Full-scale engineering development. Phase 4: System development—production, manufacturing, deployment. Phase 5: System test and integration. Phase 6: Operations, support, and modification, and Phase 7: Retirement and replacement.

Phases 1 through 3 are called the system design cycle. Phases 1 through 5 are called the system acquisition cycle.

Model-based systems engineering

22

System life cycle Phase 1 1.54 Definition: In system life cycle P h ase 1, the requirements developm en t p h ase, systems engineering must perform the following tasks: Task 1.1: Understand the problem situation, identify the customer, and design the system SYNERGY, Task 1.2: Understand the customer's operational need. Task 1.3: Derive the system requirements. Task 1.4: Validate the system requirements, and Task 1.5: Design the subsystem SANITY. Systems engineering must also produce the following systems engineering docu­ ments: Document 1: The Problem Situation Document, Document 2: The Operational Need Document, Document 3: The System Requirements Document, and Document 4: The System Requirements Validation Document. 1.55 Systems engineering documents: In system life cycle Phases 1 and 2, seven systems engineering documents are written. These may or may not be presented to the client or customer as formal reports or deliverables. What these systems engineering documents represent in this development of a generic systems engineering methodology is the structure of a data base within which the design of the system will evolve. Any specific reports required by the client or customer that are different from the systems engi­ neering documents forming the systems engineering data base can be gener­ ated from this data base.

Phase 1 interdisciplinary input 1.56 In addition to essential inputs from the customer, systems engineering typically relies on interdisciplinary input for the accomplishment of Tasks 1.1 through 1.5 in Phase 1. Which disciplines are required depends on the context of the problem. If the problem is to design a rehabilitation system for juvenile delinquents, then, to achieve an appropriate statement of system require­ ments, systems engineering might need inputs from juvenile delinquents, parents, psychologists, school officials, judges, lawyers, sociologists, and po­ lice officials. The objective of Phase 1 is the development of system require­ ments, not solutions. These interdisciplinary inputs are necessary to ensure that the problem is viewed from many angles, that no system requirement is overlooked.

Chapter one: Systems engineering

23

System requirements must be stated completely, comprehensively. Mod­ em engineering is often accused of finding elegant technological solutions to the wrong problems. The reason is that the right problem was never stated or was stated in a vastly overly simplified form.

SYNERGY 1.57 SYNERGY—the SYstems eNgineERinG sYstem: Because the purpose of this book is to emphasize the technical work of systems engineering, issues specific to the management of systems engineering are not addressed directly. Of course, everything said about the technical work of systems engineers bears directly on the management of systems engineering. The design of the system, however, which will provide the systems engineering services for the system to be designed is an inescapable task of the systems engineering group itself. Sometimes the systems engineering management plan is defined in a separate document during Phase 1 (Military Standard— Systems Engineering Management, MIL-STD-499). The systems engineering management plan should be regarded as the design of a system (called SYNERGY) to provide systems engineering services and, as such, is susceptible to application of the systems engineering methodology being developed herein. With every system design project, at least three auxiliary systems are always involved: • SYNERGY—the systems engineering system to provide systems engi­ neering services tluoughout the life cycle of the system. • SANITY—the systems analysis and trade-off study (or trade study, for short) system to model, evaluate, and compare proposed system de­ signs in Phase 2 and subsequently as required. • REALITY—the system to test the real system in Phase 5. Two other systems that might also have to be designed are • DETAILED DESIGN SYSTEM—the system to accomplish the detailed design of the system in Phase 3, involving the design of hardware, definition of data structures and design of algorithms, and design of job descriptions and training programs and • SYSTEM DEVELOPMENT SYSTEM—the system to acquire the real components of the system and to deploy them in Phase 4, involving the purchase of off-the-shelf components, manufacture of hardware, cod­ ing and installation of software, recruitment and training of operators, and orientation of users. All these systems might be regarded as subsystems of SYNERGY or, more generally, of a system to acquire the system to be designed. In fact, the design of such a system could be approached as the design of the Phase 1 subsystem.

24

Model-based systems engineering

the design of the Phase 2 subsystem, and so on. In many mature organizations, the components of such a system to acquire the system will already be in place. This is the reason that emphasis herein is placed on SANITY and REALITY. The necessity to design SANITY and REALITY is rarely acknowledged. SANITY evaluates the system when the system is represented only by models or designs in Phase 2 and subsequently. REALITY evaluates the real system in Phase 5. The systems engineering documents are discussed below for an arbitrary or hypothetical system to be designed; this system is designated SYSTEMTBD.

The Problem Situation Document 1.58 Definition: Systems Engineering Document 3, the Problem Situation Docu­ ment for SYSTEMTBD: • is readable by systems engineering management, • records the customer's initial description o f the system to be designed, prefer­ ably by quoting from documents written by the customer, and gives the system to be designed a name (SYSTEMTBD, fo r example), • records a history o f the system design problem and o f the system design project, • describes the present system, if appropriate, and other similar existing systems, • identifies, characterizes, and relates groups and individuals who have the right or the responsibility to contribute to the development o f requirements for the system to be designed: bill-payers, owners, operators, users, beneficiaries, victims, etc., • proposes techniques fo r communicating with each individual and group in order to develop requirements: interviews, private conferences, public meet­ ings, and sample surveys, • records the design o f the system SYNERGY, the systems engineering System, that will provide systems engineering services throughout the life cycle o f the system to be designed in terms o f personnel, facilities, and a systems engineer­ ing management plan, • discusses the system design problem only in very general terms identifying the basic system function fo r the system to be designed, but does not otherwise discuss the solution, and • is kept current throughout the life cycle o f the system, particularly the historical section. The following is a proposed table of contents for the Problem Situation Document. It could be modified to fit any particular situation: 1.1 The Top-Level System Function of SYSTEMTBD 1.2 History of the Problem and the Project

Chapter one: Systems engineering

25

1.3 The Present System or Systems 1.4 The Customer 1.4.1 Owners 1.4.2 Bill-Payers: The Client 1.4.3 Users 1.4.4 Operators 1.4.5 Beneficiaries 1.4.6 Victims 1.4.7 Technical Representatives to Systems Engineering 1.4.8 Other Stakeholders 1.5 System Environment of SYSTEMTBD 1.5.1. Social/Economic Impact of SYSTEMTBD 1.5.2 Environmental Impact of SYSTEMTBD 1.5.3 Interoperability of SYSTEMTBD 1.6 Design of SYNERGY 1.6.1 System Life Cycle Phase 1 of SYSTEMTBD 1.6.2 System Life Cycle Phase 2 of SYSTEMTBD 1.6.3 System Life Cycle Phase 3 of SYSTEMTBD 1.6.4 System Life Cycle Phase 4 of SYSTEMTBD 1.6.5 System Life Cycle Phase 5 of SYSTEMTBD 1.6.6 System Life Cycle Phase 6 of SYSTEMTBD 1.6.7 System Life Cycle Phase 7 of SYSTEMTBD 1.6.8 Systems Engineering Management Plan for SYSTEMTBD 1.7 Exhibits 1.8 Bibliography 1.59 System function: For the Problem Situation Document, it is sufficient to provide a verbal description of the basic mission, purpose, or use of the sys­ tem to be designed, preferably in the client's own words. It is the purpose of the requirements development phase to translate this verbal description into a precise problem. It is also a good idea to give the system to be designed an appropriate name so that it begins to have an identity of its own. For the pur­ poses of the description of these generic documents, the name SYSTEMTBD is used. 1.60 Givers of requirements: One of the principal functions of the Problem Situation Document is to identify sources of requirements for SYSTEMTBD. In Phase 1, requirements development, the first task of systems engineering is to identify the individuals, groups, or organizations who should have the privilege of, or the responsibility for, specifying value judgments on the basis of which SYSTEMTBD will be designed and built: owners, operators, users, beneficiaries (or victims), and bill-payers. These people are sources of system requirements that must be developed in Phase 1. The identification of such people and their possible relationships to SYSTEMTBD may be a difficult task, perhaps the most difficult in the whole pro­ cess (Checkland, 1979a and 1979b). In the vast majority of cases, however, it

26

Model-based systems engineering

is not difficult to identify the persons who recognize the need for SYSTEMTBD and who have the wherewithal to procure the system and to identify the social, economic, and environmental sectors that might be affected by SYSTEMTBD. The responsibility for the identification of all the "players" in the system design project remains with systems engineering and implies that the systems engineer must be particularly sensitive to the person/machine, person/person, and system/society interfaces. The extent to which systems engineering can actually contact all the "players" for the purpose of establishing system requirements will depend on the resources available to systems engineering. The bill-payer is referred to as the client. Throughout the system design process, systems engineering must remain the advocate of the client even when enthusiastic supporters of advanced technology want to rim away with the design to produce a magnificent system but one that does not satisfy the client's need, or when the profit motive drives the engineers to design a system that is less than the client needs. Systems engineering must also be the advocate of the user, the benefici­ aries, and the victims of the system throughout the system design process, even when their requirements conflict with those of the clients. Difficulties in identification notwithstanding, such people or organiza­ tions are hereinafter referred to collectively as the customer of systems engi­ neering. The customer includes the client. The foregoing discussion can be summarized by saying that systems engineering is the advocate of the cus­ tomer throughout the system life cycle. In the requirements development phase, systems engineering works with the customer to state the customer's problem in the customer's terms, to produce the Operational Need Document, the System Requirements Document, and the System Requirements Valida­ tion Document. The ultimate objective is to achieve a statement of the "toplevel" problem first in human terms and then, consistently, in mathematical terms and to show that the mathematical problem has a solution in the real world. The statement of the customer's problem ought to be comprehensive, complete, consistent, and precise. Such a problem statement can only rarely be achieved by one systems engineer working alone with the customer or even by a group of systems engineers. Almost always a comprehensive, complete, consistent and precise statement of the problem of the design of a system can be achieved only by an interdisciplinary team looking at all aspects of the customer's problem. 1.61 Environmental, social, economic, and interoperability impacts: In the Problem Situation Document, systems engineering must also record the possible environmental, social, and economic aspects of SYSTEMTBD and identify those existing systems with which the SYSTEMTBD might have to interact. The latter are discussed under the heading "Interoperability." The information recorded under the general heading of "System Environment" may also lead to specific system requirements.

Chapter one: Systems engineering

27

1.62 SYNERGY, the systems engineering system for SYSTEMTBD: Another major category of information in the Problem Situation Document is the design of the system, SYNERGY, that will provide systems engineering serv­ ices throughout the life cycle of SYSTEMTBD, This involves identification of technical personnel and facilities that might be available or necessary to carry out the various phases of the system life cycle: Phase 1: Systems engineering personnel and consultants appropriate to the discovery and development of system requirements for SYSTEMTBD, and personnel and facilities necessary to the acquisition of the subsystem SANITY o f SYNERGY, Phase 2: Systems engineering personnel and technological consultants appropriate to concept development; personnel, and facilities necessary to the acquisition of the subsystem REALITY, Phase 3: Systems, hardware, software, and human factors engineering personnel, facilities, and subcontractors necessary for full-scale engineer­ ing development. Phase 4: Systems, manufacturing and industrial engineering personnel, hardware and software production personnel and facilities, and training per­ sonnel and facilities necessary to the actual production of the system com­ ponents of SYSTEMTBD, including the training of the operators and users. Phase 5: Systems and other engineering personnel and facilities neces­ sary for test and integration of SYSTEMTBD, Phase 6: Systems engineering personnel and facilities available for peri­ odic monitoring and evaluation of SYSTEMTBD and review of proposed engineering changes throughout the operational phase of the system, and Phase 7: Systems engineering personnel available to recommend and plan for the retirement and replacement of SYSTEMTBD, The systems engineering management plan is part of the design of SYNERGY, wherein the organization that will provide and coordinate all these personnel and facilities is described. In any case, systems engineering must apply the same rigorous systems engineering methodology to the design of SYNERGY and its subsystems SANITY and REALITY as would be applied to the design of any other largescale, complex bioware/hardware/software system! All the information recorded in the Problem Situation Document must be justified by exhibits of white papers, correspondence, minutes of meetings, etc., and bibliographical references and kept up to date throughout the system life cycle. Systems engineering adopts a point of view unique among the engineer­ ing disciplines: the systems engineer approaches, in the requirements devel­ opment phase, any system design or analysis problem without commitment to

28

Model-based systems engineering

any particular technology or solution technique. Systems engineering avoids stating the problem in terms of a preferred solution or class of solutions. The systems engineer tries, rather, to see the problem from a technology-free point of view. The systems engineer tries first to symbolize and then to attack the human problem that the system to be designed or analyzed will exist to solve, not, at the outset, the technological problem. Appropriate technological prob­ lems are derived, by systems engineering in the concept development phase, from the statement of the human problem. Systems engineering deals directly with the customer to help to state succinctly the operational need motivating the desire for a system to be designed. In other words, the principal objective of systems engineering in Phase 1 is to state comprehensively, precisely, and consistently the problem of the design of the system as the customer sees it.

The Operational Need Document 1.63 Definition: Systems Engineering Document 2, the Operational Need Docu­ ment fo r SYSTEMTBD: • is readable by both systems engineering management and the customer, • states the problem o f the design o f SYSTEMTBD, not the solution, • introduces the structure fo r defining system design requirements in mathe­ matical terms in the next document, • defines the system requirements in all categories but in nontechnical terms, • traces every requirement to an expressed and recorded opinion o f the customer, • states, if possible, the human problem to be solved, not the technical problem, • states the problem as the customer sees it, and • is kept current throughout the system life cycle. Proposed table of contents: 2.1 The Deficiency Motivating the Acquisition of SYSTEMTBD 2.2 Input/Output Requirement for SYSTEMTBD 2.3 Technology Requirement for SYSTEMTBD 2.4 Performance Requirement for SYSTEMTBD 2.5 Cost Requirement for SYSTEMTBD 2.6 Trade-off Requirement for SYSTEMTBD 2.7 System Test Requirement for SYSTEMTBD 2.8 Rationale for Operational Need Specifications 2.9 Exhibits 2.10 Bibliography 1.64 Requirements traceability—^the Operational Need Document: The Op­ erational Need Document is short—less than 20 pages, if possible. It is as free as possible of technical terminology, readable by both the customer and the

Chapter one: Systems engineering

29

management of systems engineering. The Operational Need Document dis­ cusses the problem, not the solution. The problem is stated as the customer sees it; the human problem to be solved is stated, not the technical problem. Requirements in all categories are relevant but are discussed in informal, nontechnical terms. In Section 2.8, Rationale for Operational Need Specifications, every sys­ tem requirement is traced to an expressed opinion of the customer as recorded in the minutes of a meeting, a memorandum, the results of a survey, an approval signature, etc. Furthermore, as changes in the statement of require­ ments occur, the old requirements are recorded here with the reasons for the changes. The Operational Need Document is kept current as the system design project proceeds. When the Operational Need Document has been written and approved, the next task, in the requirements development Phase 1 of the system life cycle, is to capture the operational need in system theoretic terms, comprehensively and precisely. By the definition at 1.44, to design a system is to choose a model on the basis of which a real system can be built, and, by the systems engineer­ ing definition at 1.2, systems engineering is concerned with designing a system that will satisfy all its requirements. Hence, the next step in Phase 1 is to turn the operational need statement of the problem into a mathematical problem whose solution is a model on the basis of which a real system can be built that will satisfy all its requirements. This mathematical problem state­ ment is recorded in the System Requirements Document. This book provides the mathematical structure of the system requirements and the statement of the mathematical problem that can be derived from the system requirements and how that problem can be solved.

The System Requirements Document 1.65 Definition: Systems Engineering Document 3, the System Requirements Document for SYSTEMTBD: • states a mathematical problem whose solution is a model on the basis o f which a real system can be built that will satisfy all system requirements stated in the Operational Need Document, • defines computable and testable figures o f merit in terms o f which system requirements in all categories are defined, • includes a requirements rationale section which ~ traces each mathematically defined requirement to a requirement recorded in the Operational Need Document and - justifies each mathematically defined requirement on the basis o f simula­ tions, analyses, literary citations, correspondence with the customer, min­ utes o f meetings, or expert opinions.

30

Model-based systems engineering • does not oversimplify the problem, and • avoids stating the problem in terms o f a solution or class o f solutions.

Proposed table of contents: 3.1 Introduction to the System Requirements for SYSTEMTBD 3.2 The Input/Output Requirement for SYSTEMTBD 3.2.1 Operational Life of SySTEMTRD 3.2.2 Inputs to SYSTEMTBD 3.2.3 Input Trajectories of SYSTEMTBD 3.2.4 Outputs from SYSTEMTBD 3.2.5 Output Trajectories from SYSTEMTBD 3.2.6 Eligibility Function for SYSTEMTBD 3.3 The Technology Requirement for SYSTEMTBD 3.3.1 Restrictions 3.3.2 Stipulations 3.3.3 Specification Functions 3.3.4 Models 3.4 The Performance Requirement for SYSTEMTBD 3.4.1 Notation for Performance Indices and Figures of Merit 3.4.2 Lower and Upper Threshold Values, Baselines, Weights, and Scoring Functions for Performance Indices and Figures of Merit 3.4.3 Definitions of Performance Indices 3.4.4 Definitions of Performance Figures of Merit 3.4.5 Definition of the Performance Requirement 3.5 The Cost Requirement for SYSTEMTBD 3.5.1 Notation for Cost Figures of Merit 3.5.2 Lower and Upper Threshold Values, Baselines, Weights, and Scoring Functions for Cost Figures of Merit 3.5.3 Definitions of Cost Figures of Merit 3.5.4 Definition of the Cost Requirement 3.6 The Trade-off Requirement for SYSTEMTBD 3.6.1 Notation for Trade-off Figures of Merit 3.6.2 Lower and Upper Threshold Values, Baselines, Weights, and Scoring Functions for Trade-off Figures of Merit 3.6.3 Definitions of Trade-off Figures of Merit 3.6.4 Definition of The Trade-off Requirement 3.7 The System Test Requirement for SYSTEMTBD 3.7.1 Observance 3.7.2 Compliance 3.7.3 Conformance 3.7.4 Acceptance 3.8 Rationale for System Requirements 3.9 Exhibits 3.10 Bibliography Appendix: T3SE>—^ASummary of the Theory

Chapter one: Systems engineering

31

1.66 The System Requirements Document states a mathematical problem: The System Requirements Document is typically very long. The ultimate objective of the System Requirements Document is to state a mathematical problem whose solution is a model from which a real system can be built that will satisfy all the requirements stated in the Operational Need Document. The System Requirements Document is very comprehensive, does not over­ simplify the problem, and captures the biggest problem the customer envi­ sions, not the simplest. The System Requirements Document avoids stating the problem in terms of a solution or even in terms of a class of solutions. Yet the System Requirements Document is very precise and expresses in rigorous mathematical terms the input/output requirement, the technology require­ ment, the performance requirement, the cost requirement, the trade-off re­ quirement, and the system test requirement. The definite article "the" is used here with the singular "requirement" because each of these six requirements for a specific system design problem is defined subsequently as a single mathematical structure, even if quite complex. All the headings in the proposed table of contents of the System Require­ ments Document are covered in subsequent chapters. The theoretical develop­ ment in the remainder o f this book is an absolutely essential prerequisite to the writing o f the System Requirements Document and subsequent documents in the system life cycle. Here, however, it is possible to indicate by cartoons the effects of the definitions of the system requirements. 1.67 The effect in the space of all possible system designs of defining the in­ put/output requirement is to eliminate from consideration all designs except those that satisfy the input/output requirement (see Figure 1.8). 1.68 Requirements traceability, the System Requirements Document: The System Requirements Document includes a Requirements Rationale Section in which the various aspects of the mathematical problem statement are related and traced to the Operational Need Document. Every requirement defined mathematically in the System Requirements Document must be justified by reference to a requirement defined informally in the Operational Need Document. The Operational Need Document may define informally a figure of merit that might require several mathematically defined figures of merit. All the latter figures of merit are justified by a reference to the informally defined figure of merit. Rationale might also be produced from minutes of meetings, relevant literature, correspondence, and expert opinion. It is neces­ sary to track changes in the definitions in the system requirements. 1.69 The effect in the space of all possible system designs of defining the technology requirement is to eliminate from consideration all designs except those that are buildable in the technology (see Figure 1.9). 1.70 The effect in the space of all possible system designs of defining perform­ ance figures of merit and their thresholds is to eliminate from consideration

32

Model-based systems engineering

Figure 1.8 The effect in the space of all possible system designs of defining the input/output requirement is to eliminate from consideration all designs except those that satisfy the input/output requirement.

Figure 1.9 The effect in the space of all possible system designs of defining the technology requirement is to eliminate from consideration all designs except those that are buildable in the technology.

Chapter one: Systems engineering

33

every functional system design for which the value of any performance figure of merit lies outside the thresholds for the performance figure of merit (see Figure 1.10). 1.71 The effect in the space of all possible system designs of defining cost figures of merit and their thresholds is to eliminate from consideration every buildable system design for which the value of any cost figure of merit lies outside its thresholds (see Figure 1.11).

The System Requirements Validation Document 1.72 Definition: Systems Engineering Document 4, the System Requirements Validation Document, demonstrates that • the system requirements defined in the System Requirements Document are not inconsistent, • the space o f system models that satisfy all the system requirements is not empty, and • a real system exists or could be built with very high probability that satisfies all the system requirements.

Figure 1.10 The effect in the space of all possible system designs of defining perform­ ance figures of merit and their thresholds is to eliminate from consideration every functional system design for which the value of any performance figure of merit lies outside the thresholds for the performance figure of merit.

34

Model-based systems engineering

lUnelimmated buildable Isystem designs whose lvalue for each cost figure Iof merit is within the Ithresholds

Figure 1.11 The effect in the space of all possible system designs of defining cost figures of merit and their thresholds is to eliminate from consideration every buildable system design for which the value of any cost figure of merit lies outside its thresholds.

Proposed table of contents: 4.1 4.2 4.3 4.4 4.5

Functional System Designs Implementable System Designs A Real System Exhibits Bibliography

1.73 The system requirements are usually validated by theory and by iden­ tification of existing systems: The System Requirements Validation Docu­ ment shows that the system requirements as defined in the System Require­ ments Document are not contradictory, that the space of system models that satisfy all the mathematical requirements is not empty, that there is at least one system that could be designed and built that satisfies all the system requirements. The first question that must be answered is: Is the functionality cotyledon empty? That the functionality cotyledon is empty is a theoretical possibility. Given that the functionality cotyledon is not empty, the next question is: Is the implementability cotyledon empty? It could happen that none of the func­ tional system designs in the functionality cotyledon is implementable by a system buildable in the technology. The buildability cotyledon is never empty because the technology itself cannot be empty and every component in the technology is buildable in the technology by default.

Chapter one: Systems engineering

35

The next question that must be answered is: Does there exist a real system that satisfies all the requirements? The answer entails identifying some exist­ ing real system, call it REALSYSTEM, such that • REALSYSTEM satisfies the input/output requirement. • REALSYSTEM is buildable in the technology. • The values of all performance figures of merit for REALSYSTEM are within their thresholds. • The values of all cost figures of merit for REALSYSTEM are within their thresholds. • The values of all trade-off figures of merit for REALSYSTEM are within their thresholds. If such a system exists, why acquire SYSTEMTBD? The difficulty may be that REALSYSTEM belongs to a competitor or to another country. If REALSYSTEM does not quite satisfy all the system requirements as indicated above, then it must be shown that clearly there are modifications of REALSYSTEM that can be made, or with very high probability, that another version of REALSYSTEM can be designed and built that will satisfy all the system requirements. All this is typically accomplished by a detailed computer simulation of REALSYSTEM, The system described for the purpose of system requirements validation (called REALSYSTEM here) need not be the best available solution to the system design problem. The best solution will be found in Phase 2, concept development. All that is required at this point is the confidence that the system design problem can be solved and that it is worthwhile to proceed. These arguments—^that a real system exists, or could exist, that satisfies all the requirements—might have to be supported by analyses, simulations, citations from literature, or expert opinions. How much support for the argument can be generated will depend on the resources available to systems engineering. The typical difficulty in the system requirements that can lead to an invalid system design problem is that the client has specified more perform­ ance for the system than he or she is willing to pay for. 1.74 The system design process is iterative: If the System Requirements Validation Document cannot be written successfully, then the System Re­ quirements Document, and perhaps the Operational Need Document, will have to be renegotiated and modified. When the Operational Need, System Requirements, and System Requirements Validation Documents have been successfully written and accepted by management and the customer, then Phase 2, concept development, is initiated. The same iterative nature can be observed in many of the steps and documents discussed in this book: a step may not be taken or a document

36

Model-based systems engineering

may not be produced once and for all; the taking of subsequent steps and the production of subsequent documents, may throw some light on pre­ vious steps and documents and these may have to be revised. The whole process, especially in life cycle Phases 1 and 2, is a learning process; the customer learns about the systems engineering process and contributes to it while systems engineering is learning about the customer and his or her problem. SA N IT Y 1.75 SANITY—the Systems ANalysIs and Trade study sYstem: When sys­ tem life cycle Phase 1 has been completed and all documents accepted, then all the system requirements will have been stated mathematically and every mathematical entity necessary to the definition of system requirements such as performance indices, figures of merit, their thresholds and baselines and probability distributions will have been defined. Then systems engineering must initiate the design and development of another system, a system by means of which any two system designs for the original problem can be comprehensively compared within the context of the system requirements. This new system will be called, generically, SANITY, the Systems ANalysIs and Trade study sYstem. SANITY typically will be a computer system and involve the possibility of simulation studies as part of a trade-off analysis. SANITY can be designed to a certain level abstractly and can be perhaps completely designed and implemented for a class of system design problems of interest to a given systems engineering group. In any case, systems engineering must apply the same rigorous systems engineering methodology to the design of SANITY as would be applied to the design of any other large-scale, complex bioware/hardware/software system! SANITY is used to accomplish the first task in life cycle Phase 2.

System life cycle Phase 2 1.76 Definition In system life cycle Phase 2, the concept development phase, systems engineering must perform the following tasks: Task 2.1: Choose a system design concept, Task 2.2: Design the subsystem REALITY, Task 2.3: Perform system functional analysis. Task 2.4: Perform physical synthesis, and Task 2.5: Provide design requirements for system components. Systems engineering must also produce the following systems engineering documents: Document 5: The Concept Exploration Document,

Chapter one: Systems engineering

37

Document 6: The System Functional Analysis Document, and Document 7: The Physical Synthesis Document.

The system design concept 1.77 After the system requirements have been proven valid by producing at least one system concept that will solve the problem, systems engineering selects the best system design concept to pursue for the design of the final system. A system design concept, in this context, is a class of solutions all with the same general form and utilizing similar technology. Three system design concepts, as an extreme example, for a system to provide transportation across a river might be to design a series of bridges, or to design a system of ferry boats or to divert the river. In addition, the system design concept must be described or specified to a level of detail sufficient to provide the basis for "subcontracting" by systems engineering to in-house or outside subcontractors who will perform the de­ tailed design work in system life cycle Phase 3, full-scale engineering devel­ opment. (See the discussion at 1.52 and the definitions at 1.53 and 1.102.) It is the responsibility of systems engineering to select the best system design concept from all the perceived alternatives. This involves comparing the attractive alternative system design concepts with respect to the satisfac­ tion of the system requirements. The chosen system design concept will guide all future system functional analysis and physical synthesis activities. The best system design concept is selected on the basis of what is typically called a trade study (see below) implemented by the system SANITY. 1.78 Definition: A system design concept for a system design problem deter­ mines or is determined by a subset o f the technology specified in the system design problem and by a subset o f the set o f all functional system designs. These two subsets determine, then, a subset o f the set o f all implementable system designs.

Phase 2 interdisciplinary input 1.79 Systems engineering typically requires interdisciplinary input for the accomplishment of Tasks 2.1 dirough 2.5. The interdisciplinary team for these tasks will be different, however, than the team required for Tasks 1.1 through 1.5. In Phase 1, the objective was requirements development; in Phase 2, the objective is concept development. In Phase 1, systems engineering was working on the statement of the problem; in Phase 2, systems engineering is working on the solution of the problem. Hence, the experts needed in Phase 2 must represent the technologies that might be involved in the system design concepts on which the final design will be based. At the very least, systems engineering will require inputs from experts in hardware, software, and human factors, or bioware engineering. There may be, of course, experts required in narrower subfields. If, for example, the system is a health delivery

38

Model-based systems engineering

system, expertise might be required in the area of medical technology and hospital design.

The Concept Exploration Document 1.80 Definition: Systems Engineering Document 5, the Concept Exploration Document for SYSTEMTBD: • identifies the set o f alternative system design concepts, • describes a model for each alternative, • gives, for each alternative, a valuefor each figure o f merit defined in the System Requirements Document, • records how the numbers were derived or estimated, • records the trade-off analysis, • recommends an alternative to be chosen, • includes a sensitivity analysis, • includes rationale for the choice o f alternatives, the level o f modeling, and the methods for estimating the values o f the figures o f merit, and • is so complete that the decision analysis can be repeated. Proposed table of contents: 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9

System Design Concept Alternatives Models of System Design Concepts Estimation of the Values of Figures of Merit Trade-off Analysis Alternative Recommended Sensitivity Analysis Rationale for Alternatives, Models, and Methods of Estimation Exhibits Bibliography

1.81 The system design concept is chosen and documented through a trade study: The Concept Exploration Document contains descriptions and models of each of the alternatives considered. An estimate is given of the value for each alternative for each figure of merit defined in the System Requirements Document. The basis on which the estimate was derived and computational details are recorded, whether by analysis, simulation, expert opinion, or litera­ ture citation. All the computations required for the trade-off analysis are re­ corded. The computations and results from the sensitivity analysis with respect to crucial parameters are recorded. Rationale is provided for the choice of alternatives, level of modeling of the alternatives, and method for estimat­ ing the values of the figures of merit.

Chapter one: Systems engineering

39

This document must be so complete that the analysis and computations can be repeated any time in the future to arrive at exactly the same decision (if the documented assumptions are accepted.) Thus, a different decision would be reached only if new alternatives, different estimates of the values of the figures of merit, new criteria or different trade-off methodology were used, that is, given the system requirements as defined in the System Requirements Document, the given set of alternatives, the estimates of the values of the figures of merit, any systems engineer would arrive at the same decision. The responsibility of systems engineering for the system throughout its life cycle implies that all decisions concerning the system must be thoroughly documented. Only in this way can systems be improved from generation to generation. Lack of adequate documentation has long been one of the chief impediments to improvement in system design. If there is no record of the basis on which the system was designed in the first place, there is no basis for improving the system in the next generation. The system SANITY is designed to aid the performance of such trade studies. 1.82 The effect in the space of all possible system designs of choosing a sys­ tem design concept is to eliminate from consideration all designs except those buildable in the technology specified by the system design concept (see Figure 1.12).

REALITY 1.83 The real system test system: At this point, systems engineering has de­ cided what the real, final system will look like and the kind of technology to be involved in its development (for example, systems engineering now knows that the final system will be a series of bridges across the river and not a system of ferry boats). Systems engineering next must initiate the design and devel­ opment of yet another system, called REALITY. REALITY is the means by which the real, final system of the original problem (built and deployed in system life cycle Phase 4) can be integrated and tested in system life cycle Phase 5 on the basis of the system test requirements established in Phase 1 and the system design concept chosen in Phase 2. Again, systems engineering must apply the same rigorous systems engi­ neering methodology to the design of REALITY as would be applied to the design of any other large-scale, complex bioware/hardware/software system! REALITY will be used to accomplish the tasks in life cycle Phase 5. After the system design concept has been chosen, systems engineering in­ itiates the dual processes of system functional analysis and physical synthesis.

Systemfunctional analysis 1.84 System functions are represented by input/output requirements: The system function was characterized at 1.59 as a succinct description of the

40

Model-based systems engineering

Figure 1.12 The effect in the space of all possible system designs of choosing a system design concept is to eliminate from consideration all designs except those buildable in the technology specified by the system design concept.

basic mission, purpose, or use of the system to be designed. The precise definition of the system function is only achieved when all the system require­ ments have been developed, that is, when the complete system design prob­ lem has been defined. Thus, there is a close connection between the ideas of system function and system design problem. Among the system require­ ments, the input/output requirement is usually identified most closely with the intuitive idea of system function. In its simplest form the input/output requirement specifies the set of inputs that must be accepted, processed, or survived and the set of outputs for the system. In its most restrictive form, the input/output requirement specifies what output will be produced for every input and when. 1.85 Definition: System fu n ction al analysis^ is a process defined in three steps: Step 1: D ecom pose the top-level input/output requirement into an interrelated set o f input/output requirements each defined in the same format as, and consis­ tent with, the top-level input/output requirement. This decomposition is based on guidance from physical synthesis. At the top level, this guidance is in theform o f the system design concept. t The systems engineering technique herein called system functional analysis is not the same as and should not be confused with the classical mathematical field of study known as functional analysis.

Chapter one: Systems engineering

41

Step 2: D ecom pose the requirements in all the other categories o f the top-level system design problem as described in the System Requirements Document and a llo c a te them to the input/output requirements defined in Step 1. This step results in a resolution o f the top-level system design problem into an interrelated set o f system design problems for components. Step 3: Demonstrate that the system design problem resolution is consistent with the top-level system design problem. One criterion for this consistency is that, when functional system designs for each o f the input/output requirements in the resolution are combined according to the interrelations specified for the input/output requirement decomposition, the result is a functional system design for the original input/output requirement. Similarly, criteria are generated for buildable system designs and implementable system designs. Additional consis­ tency conditions in terms o f performance, cost, trade-off, and system test require­ ments can also be defined. Iteration : Apply Steps 1,2, and 3 to each system design problem in the resolution defined at the previous level. The primitive system design problems at the end o f any iteration are those that are as yet unresolved. 1.86 System functional analysis is an iterative development of system de­ sign problems for physical components: System functional analysis is the name of a process. The products of the process are decompositions of system functions, as represented by input/output requirements, and resolutions of system design problems. System functional analysis resolves iteratively the top-level system design problem into simpler system design problems. The objective is to define, iteratively and consistently, simple tasks and simpler system functions that can be performed by people, machines, and software that, when properly organized, will achieve the performance of the top-level system function. For example, the top-level system function for the design of an air traffic con­ trol system might be characterized roughly as the necessity to perform the sys­ tem hmction CONTROL AIRCRAFT. This top-level system fimction might be decomposed into the subfuntions, SCAN, DETECT, TRACK, COMMUNICATE, IDENTIFY, INSTRUCT, and VERIFY. These, in turn, would be decomposed into even simpler system functions. Such characterizations are useful for intuitive thinking but are made more precise, in the form of input/output requirements and requirements in other categories, for the purposes of system design. Furthermore, for each system function identified at a given stage, systems engineering defines a complete set of system requirements consistent with the system requirements defined at the previous stage. This is sometimes called requirements decomposition and allocation. The resulting collection of system design problems is called a resolution of the top-level system design problem. The decomposition of the top-level system function, although ideally conducted within the bounds of mathematical rigor, is not accomplished in a vacuum but is based, at each level, on guidance from physical synthesis.

Model-based systems engineering

42

That such guidance is necessary can be seen from the example of the system whose top level function might be characterized as: Provide means for people to travel from City A to City B on opposite sides of the river. This toplevel function would be decomposed one way if the design concept chosen is to build a bridge, another way if the chosen design concept is to build a system of ferry boats, and yet a third way if the chosen design concept is to divert the river. Another example might occur further along in the system functional analysis where if, in the process of physical synthesis, it is decided to imple­ ment some system functions with a human operator, then the system must perform various life-support functions which it otherwise would not have to perform if the physical synthesis did not include a human operator. Each physical synthesis decision may generate the necessity for additional or different system functions. The relationships among the system functions identified in a decomposi­ tion include what is commonly called flow of control and flow of data. Flow of control refers to the conditions for the execution of each system function. Flow of data refers to input/output relations among the system functions: which system functions provide output to be input to which other system functions. The latter are sometimes referred to as functional interfaces. Dually, at each level of system functional analysis, systems engineering identifies in increasing detail the people, machines, and software and their interrelationships that will be required to perform each identified system function. This process, called physical s mthesis, is distinct from system functional analysis just as the requirements development phase of the system life cycle is distinct from the concept development phase. System functional analysis can be thought of as requirements development/or components and physical synthesis as concept development/or components,

5

1.87 The effects of the first two iterations of system functional analysis are shown in Figure 1.13.

Physical synthesis 1.88 Definition: The p h y sical com ponents, sometimes called physical elements, o f the system to be designed are human operators, machines and software and combinations o f these. The top-level physical components are identified as part o f the system design concept, 1.89 Definition: P h y sical syn thesis is a process defined in five steps and is based on the assumption that the top-level specification o f the physical components is provided by the system design concept as described in the Concept Exploration Document: Step 1: Demonstrate the validity o f the system requirements o f each system design problem in the resolution produced at Step 2 o f system functional analysis, with techniques similar to those used to validate the system requirements o f the

Chapter one: Systems engineering

43

Figure 1.13 The effects of the first two iterations of system functional analysis.

top-level system design problem in Systems Engineering Document 4, the System Requirements Validation Document. Step 2: Choose a system design concept for the implementation o f each system function with techniques similar to those used to choose a system design concept for the top-level system design problem in Systems Engineering Document 5, the Concept Exploration Document, where each system function is represented by a system design problem in the resolution produced at Step 2 o f system functional analysis. Step 3: Assign each system function (represented by a system design problem in the resolution) to a physical component described in the Concept Exploration Document consistent with the design concepts chosen in Step 2 o f physical synthesis and with previous assignments o f system functions to physical elements. Step 4: Elaborate, that is, derive further detail in the specification of, the statement o f the problem o f the design o f each physical component described in the Concept Exploration Document on the basis o f the necessity to accommodate the new system functions assigned to the physical component. Step 5: Demonstrate that - all system functions will be performed, - all system requirements will be satisfied, and - all aspects o f each physical component described in the Concept Exploration Document are justified by the system requirements.

44

Model-based systems engineering

Iteration : Apply Steps 1, 2, 3, 4, and 5 to the system functions identified at each level by system functional analysis. 1.90 The effects of concept exploration and the first physical synthesis itera­ tion after the first system functional analysis iteration are shown in Figure 1.14. 1.91 Physical synthesis enables full-scale engineering development: The physical components of the system being designed are people, machines, software, and combinations of these, distinguished from the system functions. In order to end the concept development phase, systems engineering writes, for each physical component, a system design problem in order that hardware, software, and bioware or human factors engineers can develop the detailed design of each physical component in the full-scale engineering development phase. The processes by which these system design problems are developed are system hmctional analysis (which here includes requirements analysis and allocation of requirements to system functions) and physical synthesis (which here includes choice of physical elements and assignment of system functions to physical components). There is not room in this book for a theoretical treatment of system functional analysis and physical s)mthesis; that theory will appear in a subsequent book. 1.92 System functional analysis and physical synthesis: System functional analysis and physical synthesis are two distinct thought processes that must be carefully orchestrated. (See Figure 1.15.)

Figure 1.14 The effects of concept exploration and the first physical synthesis iteration after the first system functional analysis iteration.

Chapter one: Systems engineering

45

To accentuate the distinction, the grammar typically employed in the two processes is different: system functional analysis is expressed, informally, in terms of verbs in the imperative mood (SCAN, DETECT, TRACK, DISCRIMINATE) and adverbs. Physical synthesis is expressed, informally, in terms of nouns (sensor, radar, data processor) and adjectives. System functional analysis is concerned with what the system to be designed must do in order to satisfy the operational need. Physical synthesis is concerned with what can be built and how the system functions can be performed to satisfy the operational need. System functional analysis deals with functional, input/output, imple­ mentation-free descriptions of the system, that is, with functional system designs, whereas physical synthesis deals with buildable system designs. This bifurcation of the concept development phase into system functional analysis and physical synthesis is so crucial that systems engineering assigns these processes to different teams if resources allow. Even if systems engineer­ ing consists only of one person, however, that person must be aware of the interdependencies as well as distinctions between system functional analysis and physical synthesis. Systems Engineering Document 6, the System Functional Analysis Docu­ ment, and Systems Engineering Document 7, the Physical Synthesis Document, are produced in stages as system functional analysis and physical synthesis proceed iteratively and interactively. The version of each document will be denoted, respectively, the 6.K * System Functional Analysis Document and the 7.K‘^ Physical Synthesis Document. If the processes end at Stage N, then System Fimctional Analysis Document 6.N becomes the System Function Analysis Document 6 and Physical Synthesis Document 7.N becomes the Physical Synthesis Document 7. 1.93 Figure 1.15 shows the processes of system functional analysis and physi­ cal synthesis.

The System Functional Analysis Document 1.94 Definition: System s Engineering D ocum ent 6.K, The K th System Func­ tion al A nalysis Document: The 6.0^^ System Functional Analysis Document is the System Requirements Document, Systems Engineering Document 3. For K greater than 0, the 6.¥}^ System Functional Analysis Document • includes System Functional Analysis Document 6.(K -1), • describes the decomposition o f each o f the input/output requirements corre­ sponding to system functions defined in the K-V^ System Functional Analy­ sis Document by “ describing each decomposition in three modes: (1) plain English, (2) graph or figure showing both the flow o f control and flow o f data, and (3) system theoretic terms and

46

Model-based systems engineering Start

Customer

Task 1.1

Problem Situation S/E Document 1

(Begin acquisition of SYNERGY) Customer’s Requirements

Task 1.2

Operational Need S/E Document 2 Start Physical Synthesis

Operational Need. S/E Document 2

Task 1.3

System Requirements S/E Document 3

Task 1.4

(Begin acquisition of SANITY)

System Requirements Validation S/E Document 4

Start System Functional Analysis Concept Exploration S/E Document 5 (Begin acquisition of REALITY)

Task 2.1

K= 1 Concept Exploration S/E Document 5

Task 2.2.1

First System Functional Analysis S/E Document 6.1

Task 2.3.1

First Physical______ Synthesis S/E Document 7.1

K: = K + 1

( K - I f Physical Task 2.2.K Synthesis S/E Document 7 .(K -1 ) ----X----

System Functional Analysis S/E Document 6.K

K: = K + 1

Task 2.3.K

Physical Synthesis S/E Document 7.K

NO YES

System Functional Analysis S/E Document s = S/E Document 6.N

N*" Physical Synthesis S/E Document 7 = S/E Document 7.N

r iiiiig 3: riiit llfraii fiiifilKiiifititf Figure 1.15 The processes of system functional analysis and physical synthesis.

- specifying interrelations between the inputloutput requirements by identifying input variables with output variables or by specifying connections between input ports and output ports,

47

Chapter one: Systems engineering

• allocates a complete set (inputloutput, technology, performance, cost, trade­ off, system test) o f system requirements to each new system function to develop a resolution o f each system design problem in the System Functional Analysis Document,

• demonstrates the consistency o f each decomposition with the decomposed system function, and • includes rationale fo r the selection o f the system functions and their interrela­ tionships in each decomposition and fo r each allocated requirement.

1.95 Requirements traceability, system functional analysis: It is shown in the 6.K*^ System Functional Analysis Document that performance of the system subfunctions with their defined relationships implies performance of the system function of which the subfunctions constitute a decomposition. The system requirements are traced to the system requirements at the K-l®* level; for example, the cost budgets allocated to the system subfunctions add up to the cost budget of the system function of which the system subfunctions are a decomposition and the reliability requirements at the level imply the reliability requirement at the K-1®* level. Rationale is provided for the choice of subfunctions, their interrelationships, and the requirements allocated.

The Physical Synthesis Document 1.96 Definition: System s Engineering D ocum ent 7.K, The K th P hysical Syn­ thesis D ocum ent: The 7.0*^ Physical Synthesis Document is the Concept Explora­ tion Document. For K greater than zero, the 7.Kf^ Physical Synthesis Document

• includes Physical Synthesis Document 7 .(K -1 ), • records the demonstration o f the validity o f system requirements fo r each system function defined in the

System Functional Analysis Document,

• reports the choice o f a system design concept fo r each system function defined in the System Functional Analysis Document,

• records the assignment o f each system function identified in the

System Functional Analysis Document to a physical component consistent with the assignments asserted in the K-V^ Physical Synthesis Document,

• updates the statement o f the system design problem fo r each physical compo­ nent according to the system junctions assigned to it, • records demonstrations that -

every system function defined in the Document will be performed,

System Functional Analysis

- all system requirements described in the

System Functional Analysis

Document will be satisfied, and

48

Model-based systems engineering -

the updated system design problem fo r each physical component is justified by the system requirements defined in the System Functional Analysis Document, and

• provides rationale fo r the design concepts proposed, the interrelationships specified, assignment o f system functions to physical components, alternatives considered, and models developed.

Allocation of system functions to physical elements 1.97 The 7.0‘^Physical Synthesis Document is the Concept Exploration Docu­ ment, Systems Engineering Document 5. For K greater than zero, the 7.K^ Physical Synthesis Document first demonstrates that the system requirements associated with each system func­ tion are valid. Then the 7.K*^ Physical Synthesis Document describes a design concept for each system function defined in System Functional Analysis Document 6.K, thus providing guidance for the allocation of the system function to already identified physical components. The system functions are then partitioned for assignment to physical components. This assignment must be consistent with the assignment that occurred at the level. If system function F was assigned to physical component P at the K-1®* level, and F I ,.. .,Fm, are the system functions defined to decompose F, then all the system functions Fl,...,Fm must be assigned to physical component P, but the system functions F I,.. .,Fm may be assigned to new physical components within P. For example, it may be that FI may require a new software component of P and F2 may require more actions from a human operator. Such assignments will imply more detailed descriptions of the physical component P in order to implement the system functions Fl,...,Fm . If the new description is denoted Q, then Q must be consistent with P. It must then be demonstrated that all the system functions will be per­ formed, that all system requirements will be satisfied, and that all aspects of the physical components are justified by the system requirements. Rationale is provided for the design concepts proposed, the interrelation­ ships specified, functional areas defined, allocation of functional areas to physical components, alternatives considered, and models developed. The rationale can be in terms of analyses, simulations, estimates, trade studies, and expert opinions. Finally, the 7.K^ Physical Synthesis Document provides guidance for the K+1®* level of system functional analysis. 1-98 Figiue 1.16 shows the joint effects in the space of all possible system designs of the input/output, technology, performance, and cost requirements, concept exploration, system functional analysis, physical synthesis, and thresholds of figures of merit. (See Figures 1.7-1.14.)

Chapter one: Systems engineering

49

Termination of system functionai anaiysis and physicai synthesis 1.99 How big is N? The criteria for ending the processes of system functional analysis and physical synthesis at the level can be very much contextdependent. Two objective criteria that can be cited are that system functional analysis and physical synthesis continue until a level is reached (1) at which every identified system function is assigned to a single physical component and (2) at which no new performance or cost requirements are generated. In practice, N is rarely greater than 3 before system functional analysis and physical synthesis stop and the full-scale engineering design phase is begim. If there are no hardware, software, or human factors engineers to whom the 6 .N * System Functional Analysis Document and the 7.N*^ Physical Syn­ thesis Document can be handed off for full-scale engineering development, then system functional analysis and physical synthesis must continue until every physical component is available off-the-shelf. This is almost always the case when one is designing a personal system such as a family transportation system (a car, perhaps). In most larger organizations, however, there is always the possibility of internal or external subcontracting for full-scale engineering development. The principal criterion for initiating such subcontracts is the confidence systems engineering must have that, when full-scale engineering development

Figure 1.16 The joint effects in the space of all possible system designs of the input/output, technology, performance, and cost requirements, concept exploration, system functional analysis, physical synthesis, and thresholds of figures of merit.

50

Model-based systems engineering

is finished and the results are delivered to systems engineering, then systems engi­ neering will be able to integrate the physical components into a system that will satisfy the customer's operational need. This is a subjective criterion, depending

on systems engineering's perception of the competence and level of sophisti­ cation of available hardware, software, and human factors engineers and implies something about the level of detail that might be required before the requisite confidence is generated. The decision, however, must be made within the resources available to systems engineering. In many cases there is a choice to be made between acquiring a component off-the-shelf or designing a special version for manufacture or development: the so-called make/buy decision. All such decisions must be made on the basis of a trade study.

The trade study, computer simulation, and SANITY 1.100 The trade study: The trade study is the fundamental tool for decision­ making throughout the system design cycle. The basic problems that the trade study is designed to solve are these: "Among all perceived alternatives, find the best X to satisfy the system requirements," where X might be any one of design concept, functional decomposition, requirements allocation, physical components to implement functions, assignment of system functions to physi­ cal components, components, parts, input/output functional design, buildable system design, or implementable system design. The trade study is perhaps that aspect of system design closest to the scientific method. Every trade study should be complete, objective, repeatable, and communicable. In systems engineering, an accountability problem fre­ quently appears during the review of a system design: "Who made the decision to do it this way and why?" The trade study provides the ideal design rationale: "All these alternatives were considered with respect to all these criteria and these trade-offs among the criteria, and this alternative was the best." It should be possible to repeat the trade study and to arrive at exactly the same decision, given the same set of alternative models, criteria, and trade-offs among the criteria. The system requirements developed in all six categories already defined represent a complete set of criteria for comparison of alternatives as well as trade-offs among the criteria within a given system design project. The set of alternatives is identified, and each alternative is represented by an appropriate model. For each alternative, on the basis of its model, a value for each figure of merit is computed or estimated and all the necessary trade-off numbers are com­ puted. On the basis of these numbers, the best alternative can be selected. The trade study includes a sensitivity analysis to appraise the stability of the best choice with respect to small changes in judgmental parameters or estimated quantities. The trade study is documented for inclusion in the appropriate sys­ tems engineering document. For a given system design project, the machinery for doing trade studies will be incorporated into the system SANITY (see 1.75).

Chapter one: Systems engineering

51

1.101 Computer Simulation: Computer simulation of functional system de­ signs and buildable system designs based on models developed by systems engineering usually provides the best estimates of performance indices and figures of merit, especially for highly detailed models developed in the later stages of system functional analysis and physical synthesis. The design of such computer simulation systems must always be regarded as a system design project in its own right because of the time and money involved. For a given system design project, the machinery for doing simulations studies will be incorporated into the system SANITY. The seven systems engineering documents produced in Phases 1 and 2 collectively define the problem of the design of the system in question and, in a structured and stepwise manner, ineluctably lead to the definition of the model from which the real, final system will be built. At the end of system life cycle Phase 2, concept development, each sys­ tem design problem in the System Functional Analysis Document is assigned to hardware, software, or human factors engineers and becomes ''design-to" specifications for the hardware, software, and human factors engineers to initiate system life cycle Phase 3, the full-scale engineering development phase.

System life cycle Phase 3 1.102 Definition: In system life cycle P hase 3, the fu ll-sc a le engineering d ev elop m en t ph ase, hardware, software, and human factors engineers coordinated by systems engineering produce the detailed specifications necessary for the produc­ tion and manufacture o f the hardware and software elements and the training o f the human operators and users, based on the requirements generated by systems engineering fo r each physical component as recorded in the System Functional Analysis Document and the Physical Synthesis Document.

System life cycle Phase 4 1.103 D efinition: In system life cycle P hase 4, the system developm en t ph ase, systems engineering oversees and coordinates the efforts o f industrial and manufacturing engineers who have the primary responsibility for the production, manufacture, installation, and deployment o f the system during the system develop­ ment phase on the basis of the detailed designs produced during the full-scale engineering development phase.

System life cycle Phase 5 1.104 Definition: System life cycle P hase 5, the system test and integration p h ase: When the physical components o f the system have been produced, the system test and integration phase begins, wherein systems engineering supervises and coordinates integration o f the physical components into a system whose physical

52

Model-based systems engineering

components will work together to satisfy the customer's operational need. Then systems engineering uses the system REALITY (see 1.83) to test the real system and document the test results. H ere, the systems engineer must avoid becoming a physical component of the system; the system must work without the systems engineer or it has not been properly integrated.

System life cycle Phase 6 1.105 Definition: In system life cycle P hase 6, the operations, support, and m od ification p h ase, systems engineering periodically reevaluates the system in operation to ensure that the system continues to satisfy all its requirements, reviews engineering changes proposed fo r the purpose o f improving the performance or reducing the operating costs, and supervises implementation o f those changes that will improve the system over all.

System life cycle Phase 7 1.106 Definition: System life cycle P h ase 7, the retirem ent and replacem en t p h ase: The acquisition cycle begins again. Systems engineering is responsible for recommending the retirement o f the system at the appropriate time and fo r writing the proposal fo r its replacement. 1.107 Development and manipulation of system theoretic models is the technical work of systems engineering: Systems engineering can manage these many responsibilities through the development and manipulation of system theoretic models. The theory developed in this book is focused primar­ ily on the activities of systems engineering in the system requirements phase, the concept development phase, and the system test and integration phase. In order for the system theoretic models to be useful tools for system design and analysis, they must be perfectly precise—and that means mathe­ matically rigorous. That is why Chapter 2, which defines a class of system theoretic models useful for systems engineering, is based on set theory. Appendix 1 reviews the concepts of set theory relevant to the development herein. Chapter 3 deals with the structural and behavioral comparison of system models: When are two system models essentially the same? When is one system model a simplification of another system model? Chapter 4 discusses how to create models of complex phenomena by developing models of simpler phenomena and coupling them together. The concept of system mode is the subject of Chapter 5. The last four chapters deal with system design methodology based on the system theory discussed in Chapters 2, 3, 4, and 5. The structure of the system requirements, the statement of the problem of the design of a system, and constructs relative to problem statements are discussed in Chapters 6 through 9.

Chapter one: Systems engineering

53

With the concepts and language discussed in Chapters 1 through 9 as background and with some skill in developing system theoretic models of engineering phenomena attained through exercises, the student of systems engineering will be well-prepared to perform systems engineering functions and to support and implement the systems engineering point of view.

Exercises 1.108 What is systems engineering? 1.109 What are the six system requirements for a system design problem? 1.110 What are the six parts of the input/output requirement for a system? 1.111 What is the relation between an input/output requirement and a system that satisfies it? 1.112 What is the functionality cotyledon? 1.113 What is a technology requirement? 1.114 When is a system buildable in a technology? 1.115 What is the buildability cotyledon? 1.116 What is a performance requirement? 1.117 What is a performance figure of merit? 1.118 What is a performance figure of merit threshold? 1.119 What is a cost requirement? 1.120 What is a cost figure of merit? 1.121 What is a cost figure of merit threshold? 1.122 How is a functional system design implemented in a technology? 1.123 What is a mode of behavior of a system? 1.124 What is an implementable system design? 1.125 What is the implementability cotyledon? 1.126 What is a trade-off figure of merit? 1.127 What is a trade-off requirement? 1.128 What decisions can be made by a trade-off algorithm? 1.129 What is an implementable test item? 1.130 What is a system test requirement? 1.131 What is the observance part of a system test requirement?

54

Model-based systems engineering

1.132 What is the compliance part of a system test requirement? 1.133 What is the conformance part of a system test requirement? 1.134 What is the acceptance part of a system test requirement? 1.135 What does it mean to design a system? 1.136 What is systems analysis? 1.137 What does it mean to model a phenomenon? 1.138 What are the seven phases of the system life cycle? 1.139 What is the system design cycle? 1.140 What is the system acquisition cycle? 1.141 What are the systems engineering tasks and work products from system life cycle Phase 1? 1.142 What is the fimction of the interdisciplinary team in Phase 1? 1.143 What is the function of the system SYNERGY? 1.144 What is the content of Systems Engineering Document 1? 1.145 What is the content of Systems Engineering Document 2? 1.146 What is requirements traceability in Systems Engineering Document 2? 1.147 What is the content of Systems Engineering Document 3? 1.148 What is requirements traceability in Systems Engineering Document 3? 1.149 What is the difference in style between Systems Engineering Docu­ ments 2 and 3? 1.150 How are system requirements validated? 1.151 What is the content of Systems Engineering Document 4? 1.152 Characterize the principal decision-making tool/technique used by systems engineering throughout the system life cycle. 1.153 What is the function of the system SANITY and when is it designed? 1.154 What are the systems engineering tasks and work products from system life cycle Phase 2? 1.155 What is a system design concept? 1.156 What is the objective of concept exploration? 1.157 What is the function of the interdisciplinary team in Phase 2? 1.158 What is the content of Systems Engineering Document 5?

Chapter one: Systems engineering

55

1.159 What is the function of the system REALITY and when is it designed? 1.160 What is system functional analysis? 1.161 What is the content of Systems Engineering Document 6? 1.162 What is physical synthesis? 1.163 What is the content of Systems Engineering Document 7? 1.164 What does it mean to allocate system requirements to system functions and what is a resolution of a system design problem? 1.165 What does it mean to allocate system functions to physical elements? 1.166 What are some criteria for terminating the system functional analysis/physical synthesis iteration? 1.167 What are the responsibilities of systems engineering in system life cycle Phase 3? 1.168 What are the responsibilities of systems engineering in system life cycle Phase 4? 1.169 What are the responsibilities of systems engineering in system life cycle Phase 5? 1.170 What are the responsibilities of systems engineering in system life cycle Phase 6? 1.171 What are the responsibilities of systems engineering in system life cycle Phase 7? 1.172 Write Problem Situation and Operational Need Documents for the design of a personal transportation system for a specific customer. 1.173 Write Problem Situation and Operational Need Documents for the design of an intraoffice or intrahome message system for a specific customer. 1.174 Write Problem Situation and Operational Need Documents for the design of a home security system for a specific customer. 1.175 Write Problem Situation and Operational Need Documents for the design of a home recycling system for a specific customer. 1.176 Write Problem Situation and Operational Need Documents for the design of a home heating/cooling system for a specific customer. 1.177 Write Problem Situation and Operational Need Documents for the design of a home management system for a specific customer. 1.178 Write Problem Situation and Operational Need Documents for the design of an educational system for the children of a specific customer.

Bibliography A FSC M (1964) Systems Management— Systems Engineering Management D uring Definition and Acquisition Phases, No. 375-1. AFSCM (1966) Systems Engineering Management Procedures, No. 375-5. Blanchard, B. and W. Fabrycky (1981) Systems Engineering and Analysis. Prentice-Hall, Englewood Cliffs, NJ. Booth, T. L. (1967) Sequential Machines and Automata Theory. John Wiley and Sons, New York. Breddan, J. (1978) Multiattribute Utility Assessment for an Interdisciplinary System Design Project: Evaluating Sites for Nuclear Fuel Reprocessing, Ph.D. dissertation. Depart­ ment of Systems and Industrial Engineering, University of Arizona, Tucson. Casti, J. L. (1977) Dynamical Systems and Their Applications: Linear Theory. Academic Press, New York. Cellier, F. E. (1984) How to Enhance the Robustness of Simulation Software. In: T. I. Oren et al., eds.. Simulation and Model-Based Methodologies: A n Integrative View. Springer-Verlag, Berlin, pp. 519-536. Chapman, W. L., A. T. Bahill, and A. W. Wymore (1992) Engineering Modeling and Design. CRC Press, Boca Raton, FL. Charette, R. (1986) Software Engineering Environments. McGraw-Hill, New York. Checkland, P. B. (1979a) Techniques in Soft Systems Practice— 1. Systems Diagrams— Some Tentative Guidelines. Journal of Applied Systems Analysis, Vol. 6, April, pp. 33-40. Checkland, P. B. (1979b) Techniques in Soft Systems Practice— 2. Building Conceptual Models. Journal of Applied Systems Analysis, Vol. 6, April, pp. 4 1 -4 9 . Csaki, C. (1985) Simulation and Systems Analysis in Agriculture. Akademia Kiado, Budapest. Davis, M. (1958) Computability and Unsolvability. McGraw-Hill, New York. Denning, P. J., J. B. Dennis, and J. E. Qualitz (1978) Machines, Languages and Computation. Prentice-Hall, Englewood Cliffs, NJ. Department of the Army (1969) A Guide to Systems Engineering, TM 38-760 (draft). Washington, D.C. Faurre, P. and M. Depeyrot (1977) Elements of System Theory. North-Holland, New York.

694

Model-based systems engineering

Fertig, J. and R. Zapata (1977) A Mathematical Foundation for System Synthesis. In: Proceedings of the First International Conference on Applied General Systems Research: Recent Developments and Trends, State University of New York at Binghamton. Freeman, H. (1965) Discrete-Time Systems. John Wiley and Sons, New York. Gasparski, W. (1984) Understanding Design: The Praxiological-Systemic Perspective. Intersystems Publications, Seaside, CA. Gheorghe, A. (1982) Applied Systems Engineering. John Wiley and Sons, New York. G ill, A. (1962) Introduction to the Theory of Finite-State Machines. McGraw-Hill, New York. Ginsburg, S. (1962) A n Introduction to Mathematical Machine Theory. Addison-Wesley, Reading, MA. Goicoechea, A., D. Hansen, and L. Duckstein (1982) Multiobjective Decision Analysis with Engineering and Business Applications. John Wiley and Sons, New York. Goode, H. H. and R. E. Machol (1957) System Engineering, A n Introduction to the Design of Large-Scale Systems. McGraw-Hill, New York. Hall, A. D. (1962) A Methodology for Systems Engineering. Van Nostrand, Princeton, NJ. Halmos, P. R. (1974) Naive Set Theory. Springer-Verlag, New York. Hartmannis, J. and R. E. Steams (1966) Algebraic Structure Theory of Sequential Machines. Prentice-Hall, Englewood Cliffs, NJ. Jerger, J. L. (1960) Systems Preliminary Design, Principles of Guided Missile Design. Van Nostrand, Princeton, NJ. Kalman, R. E., P. L. Falb, and M. A. Arbib (1969) Topics in Mathematical System Theory. McGraw-Hill, New York. Kaplansky, I. (1972) Set Theory and Metric Spaces. Allyn and Bacon, Boston. Klir, G. J. (1984) General Systems Framework for Inductive Modelling. In: T. I. Oren et al., eds.. Simulation and Model-Based Methodologies: A n Integrative View. SpringerVerlag, Berlin, pp. 69-90. Klir, G. J. (1985) Architecture of Systems Problem Solving. Plenum Press, New York. Koestler, A. (1978) Janus: A Summing Up. Random House, New York. Lipschutz, S. (1964) Set Theory and Related Topics. Schaum's Outline Series, McGrawHill, New York. Lucas, W. F., F. S. Roberts, and R. M. Hall, eds. (1976) Discrete and System Models. Springer-Verlag, New York. Mayers, R. (1979) A Topological Approach to General System Stability, Ph.D. dissertation. Department of Systems and Industrial Engineering, University of Arizona, Tucson. M cClam roch, N. H. (1980) State Models of Dynamical Systems. Springer-Verlag, New York. McNaughton, R. and S, Papert (1971) Counter-Free Automata. M.I.T. Press, Cambridge, MA. Mesarovic, M. D. and Y. Takahara (1975) General Systems Theory: Mathematical Founda­ tions. Academic Press, New York. Moore, E. F. (1964) Sequential Machines. Addison-Wesley, Reading, MA. Nadler, G. (1967) Work Systems Design: The ID E A L S Concept. R. D. Irwin, Hammond, IL.

Bibliography

695

Oren, T. I. (1983) Quality Assurance of System Design and Model Management for Complex Problems. In: H. Wedde, ed.. Adequate Modeling of Systems. SpringerVerlag, Berlin, pp. 205-221. Oren, T. I. (1984) GEST— A Modelling and Simulation Language Based on System Theoretic Concepts. In: T. I. Oren et al., eds.. Simulation and Model-Based Method­ ologies: A n Integrative View. Springer-Verlag, Berlin, pp. 281-336. Padulo, L. and M. Arbib (1974) System Theory: A Unified State-Space Approach to Continuous and Discrete Systems. Saunders, Philadelphia. Pichler, F. (1984) Symbolic Manipulation of System Models. In: T. I. Oren et al., eds.. Simulation and Model-Based Methodologies: A n Integrative View. Springer-Verlag, Berlin, pp. 217-234. Salomaa, A. and M. Soittola (1978) Automata— Theoretic Aspects of Formal Power Series. Springer-Verlag, New York. Schwaertzel, H. (1986) Informatik in der Praxis. Springer-Verlag, Berlin. Shannon, C. E. and J. McCarthy, eds. (1956) Automata Studies, Princeton University Press, Princeton, NJ. Smith, J. (1987) Mathematical Modeling and Digital Simulation for Engineers and Scientists. John Wiley and Sons, New York. Smyth, D. S. and P. Checkland (1976) Using a Systems Approach: The Structure of Root Definitions. Journal of Applied Systems Analysis, Vol. 5, No. 1, pp. 7 5-83. Spedding, C. (1979) A n Introduction to Agricultural Systems. Applied Science Publishers, London. Steiglitz, K. (1974) A n Introduction to Discrete Systems. John Wiley and Sons, New York. Turnbach, R. (1984) Decomposition of System Design Problems, Ph.D. dissertation. Department of Systems and Industrial Engineering, University of Arizona, Tucson. USAF (1969) M ilitary Standard— Systems Engineering Management, MIL-STD-499. van Gigch, J. P. (1978) Applied General Systems Theory (2nd ed.). Harper and Row, New York. Wallace, R., J. Stockenberg, and R. Charette (1987) A Unified Methodology for Developing Systems. McGraw-Hill, New York. Wiberg, D. M. (1971) State Space and Linear Systems. Schaum's Outline Series, McGrawHill, New York. Wilson, B. (1984) Systems: Concepts, Methodologies and Applications. John Wiley and Sons, New York. Wymore, A. W. (1969) Discrete Systems and Continuous Systems. In: P. C. Hammer, ed.. Advances in Mathematical Systems Theory. Pennsylvania State University Press, University Park, pp. 9-43. Wymore, A. W. (1972) A Wattled Theory of Systems. In: G. Klir, ed.. Trends in General Systems Theory. John Wiley, New York, pp. 270-300. Wymore, A. W. (1976) Systems Engineering Methodology for Interdisciplinary Teams. John Wiley, New York. Wymore, A. W. (1977) A Mathematical Theory of Systems Engineering: The Elements. Robert E. Krieger, Huntington, NY.

696

Model-based systems engineering

Wymore, A. W. (1981) Applications of Mathematical System Theory to System Design, Modelling and Simulation. In: T. I. Oren et al., eds.. Proceedings of the 1981 Winter Simulation Conference. IEEE, Piscataway, NJ, pp. 209-219. Wymore, A. W. (1982) Design of Service Delivery Systems. In: L. Troncale, ed., A General Survey of Systems Methodology, Proceedings of the 26th Annual Meeting of the Society for General Systems Research. Systems Science Institute, University of Louisville, pp. 585-595. Wymore, A. W. (1983) T3SD as a Modelling Methodology. In: H. Wedde, ed.. Adequate Modeling of Systems. Springer-Verlag, Berlin, pp. 185-199. Wymore, A. W. (1984a) Theory of Systems. In: C. R. Vick and C. V. Ramamoorthy, eds.. Handbook of Software Engineering. Van Nostrand Reinhold, New York, pp. 119-133. Wymore, A. W. (1984b) The Tricotyledon Theory of System Design. In: T. I. Oren et al., eds.. Simulation and Model-Based Methodologies: A n Integrative View. SpringerVerlag, Berlin, pp. 119-132. Zapata, R. and J. Fertig (1977) Systems Synthesis: Structuring Alternative Solutions. Proceedings of the 1977 International Conference on Cybernetics and Society, Washing­ ton, D.C., pp. 19-21. Zapata, R. and J. Fertig (1978) System Synthesis: Theory and Practice. Proceedings of the Fourth European Meeting on Cybernetics and Systems Research, Linz, Austria, pp. 2 9 -3 1 . Zeigler, B. P. (1976) Theory of Modelling and Simulation. John Wiley and Sons, New York. Zeigler, B. P. (1984a) Multifacetted Modelling and Discrete Event Simulation. Academic Press, New York. Zeigler, B. P. (1984b) System Theoretic Foundations of Modelling and Simulation. In: T. I. Oren et al., eds.. Simulation and Model-Based Methodologies: An Integrative View. Springer-Verlag, Berlin, pp. 91-118. Zeigler, B. P. (1984c) Theory and Application of Modeling and Simulation: A Software Engineering Perspective. In: C. R. Vick and C. V. Ramamoorthy, eds.. Handbook of Software Engineering. Van Nostrand Reinhold, New York, pp. 1 -2 5 . Zissos, D. (1984) System Design with Microprocessors. Academic Press, London.