Designing Complex Systems: Foundations of Design in the Functional Domain (Complex and Enterprise Systems Engineering) [1 ed.] 1420087533, 9781420087536, 9781420087543

Citation preview

DESIGNING COMPLEX SYSTEMS Foundations of Design in the Functional Domain

COMPLEX AND ENTERPRISE SYSTEMS ENGINEERING Series Editors: Paul R. Garvey and Brian E. White The MITRE Corporation www.enterprise-systems-engineering.com

Designing Complex Systems: Foundations of Design in the Functional Domain Erik W. Aslaksen ISBN: 1-4200-8753-3 Publication Date: October 17, 2008 Architecture and Principles of Systems Engineering Charles Dickerson and Dimitri N. Mavris ISBN: 1-4200-7253-6 Publication Date: January 30, 2009 Model-Oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems Duane W. Hybertson ISBN: 1-4200-7251-X Publication Date: February 15, 2009 Enterprise Systems Engineering: Theory and Practice George Rebovich, Jr. and Brian E. White ISBN: 1-4200-7329-X Publication Date: April 15, 2009 Leadership in Decentralized Organizations Beverly G. McCarter and Brian E. White ISBN: 1-4200-7417-2 Publication Date: May 15, 2009 Engineering Mega-Systems: The Challenge of Systems Engineering in the Information Age Renee Stevens ISBN: 1-4200-7666-3 Publication Date: June 25, 2009 Complex Enterprise Systems Engineering for Operational Excellence Kenneth C. Hoffman and Kirkor Bozdogan ISBN: 1-4200-8256-6 Publication Date: November 16, 2009 Social and Cognitive Aspects of Engineering Practice Stuart S. Shapiro ISBN: 1-4200-7333-8 Publication Date: March 30, 2010

RELATED BOOKS Analytical Methods for Risk Management: A Systems Engineering Perspective Paul R. Garvey ISBN: 1-5848-8637-4 Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective Paul R. Garvey ISBN: 0-8247-8966-0

DESIGNING COMPLEX SYSTEMS Foundations of Design in the Functional Domain

Erik W. Aslaksen

Complex and Enterprise Systems Engineering Series

Auerbach Publications Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2009 by Taylor & Francis Group, LLC Auerbach is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number-13: 978-1-4200-8753-6 (Hardcover) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Library of Congress Cataloging-in-Publication Data Aslaksen, E. (Eric) Designing complex systems : foundations of design in the functional domain / Erik W. Aslaksen. p. cm. -- (Complex and enterprise systems engineering) Includes bibliographical references and index. ISBN-13: 978-1-4200-8753-6 (alk. paper) ISBN-10: 1-4200-8753-3 (alk. paper) 1. Systems engineering. I. Title. II. Series. TA168.A73 1991 620.001’171--dc22 Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the Auerbach Web site at http://www.auerbach-publications.com

2008022872

Contents Preface ............................................................................................................ix

1

Introduction ...........................................................................................1 1.1 How the Subject Matter Is Approached...............................................1 1.2 Engineering ........................................................................................3 1.3 Epistemology and Functionality .........................................................7 1.4 Complexity .........................................................................................9 1.5 Systems .............................................................................................12 1.6 Bringing It All Together....................................................................13 Notes .........................................................................................................15

2

he Purpose of Design .........................................................................17 2.1 he Design Process and Measures of Success ....................................17 2.2 Return on Investment .......................................................................22 2.3 Philosophical Motivation ..................................................................25 2.4 he Concept of Value .......................................................................26 2.5 he Central Role of Money as a Measure ..........................................28 2.6 he Dynamics of the Design Process ................................................30 Notes .........................................................................................................32

3

he Design Methodology .....................................................................35 3.1 Outline .............................................................................................35 3.2 Deining Quality of Service ..............................................................38 3.3 Determining the Value of a Service ...................................................41 3.4 Assigning Cost to a Functionality .................................................... 42 3.5 Some Basic Rules for Developing Functional Elements .................... 44 3.6 Applying Functional Elements in Top-Down Design ...................... 46 3.7 he Basic Design Process ..................................................................48 Notes .........................................................................................................50

4

Functional Elements and the Functional Domain ...............................51 4.1 Functional Elements .........................................................................51 v

vi

n Contents

4.2 he Functional Domain ...................................................................60 4.3 he Functional Parameter Space .......................................................62 4.4 Structure of the Functional Domain ................................................ 66 4.5 Element States ...................................................................................70 4.6 Functions on State Space ..................................................................72 Notes .........................................................................................................73

5

Interactions and Systems ......................................................................75 5.1 he System Concept..........................................................................75 5.2 Interactions between Real Functional Elements ................................78 5.3 Functional Systems ...........................................................................80 5.4 Structure of Systems..........................................................................82 5.5 Systems of Imaginary Elements .........................................................87 Notes .........................................................................................................89

6

Properties of Systems............................................................................91 6.1 System States.....................................................................................91 6.2 Changes of State ...............................................................................94 6.3 Service Density Function and Superspace .........................................97 6.4 Availability ........................................................................................99 6.5 he Basic Design Process Revisited .................................................100 Notes .......................................................................................................102

7

Expanding the Irreducible Element....................................................103 7.1 Introduction ....................................................................................103 7.2 he System Life Cycle .....................................................................104 7.3 Cost Components ...........................................................................106 7.4 Subsystems and Cost Allocation ......................................................108 7.5 Stochastic Aspects ........................................................................... 110 7.5.1 A Stochastic System Performance Model ............................. 110 7.5.2 he Service Density Function φ(s;λ,∆)................................ 114 7.5.3 Temporal Aspects ................................................................ 117 7.6 A Set of First-Level Elements ...........................................................120 7.6.1 he First-Level System.........................................................120 7.6.2 he Service Delivery Element .............................................122 7.6.3 he Cost Element................................................................122 7.6.4 he Revenue Element ..........................................................123 7.6.5 he Return on Investment Element.....................................124 7.6.6 Classifying Service Elements ...............................................124 7.7 An Example: Underground Copper Mine .......................................125 7.8 Summary ........................................................................................127 Notes .......................................................................................................128

Contents

n

vii

8

Maintained Systems ...........................................................................129 8.1 Failure and Repair in the Two Domains .........................................129 8.2 Order, Information, and Entropy in the Two Domains ..................133 8.3 A Functional Element Representing Maintenance ..........................135 8.4 A Model with Binary Interactions...................................................137 8.5 Organizational Disorder .................................................................139 8.6 Coherence ....................................................................................... 141 Notes .......................................................................................................148

9

he System Designer’s Assistant .........................................................149 9.1 Introduction ....................................................................................149 9.2 Structure of the SDA ......................................................................150 9.3 he Model Worksheet ..................................................................... 151 9.4 Element Format .............................................................................. 153 9.5 Application and Further Development of the Methodology ............ 158 Notes ....................................................................................................... 159

Index ........................................................................................................... 161

Preface his book attempts to develop a rigorous basis for carrying out that early part of the design process that converts a set of requirements on the service to be provided by a system into requirements on a set of interacting functional elements, which then form the point of departure for the classical part of the design process — the conversion of functional requirements into a physical entity that, through its operation, will satisfy those requirements. he reason for including this book in a series dedicated to Complex Systems, that is, a class of systems where the elements are predominantly independent agents behaving and interacting in a dynamic fashion, is that, while the systems to which the design methodology applies are not generally in this class, the environment in which the design takes place exhibits these characteristics. In the not too distant past, engineers would exclude consideration of much of this environment from their scope of work, but this narrow focus and limitation of responsibility are no longer accepted, neither by our clients nor by society. On the contrary, the increasing intrusiveness of such engineered objects as highways, railways, ports, dams, mines, and factories, just to name a few, into our daily lives and environment, coupled with a much greater awareness of the wider consequences of engineering works, has led to the demand of both clients and society for a holistic approach to the design of these objects and to a greatly increased legal regime. As a result, the complexity of the environment in which design takes place is relected in the design process itself, and it is this complexity, rather than any complexity of the objects themselves, that systems engineering needs to address. he immediate purpose of the book is to introduce students and practitioners in the ield of system design to the basic issues raised by this complexity and to a methodology that addresses those issues in a rigorous and consistent, top-down fashion. A much more indirect purpose, and one with regard to which the book can, at best, initiate a discussion within the engineering profession, is to reassess the characteristics of engineering and its place within the ield of intellectual activity, in particular, to examine the creative aspects of design, as relected in the diference between an engineer and a technician.

ix

x

n

Preface

A central theme is the necessity for developing standardized functional elements, the building blocks of design in the functional domain and the counterpart of standardized construction elements in the physical domain. he argument for this is simple: Without standardized construction elements, such as nuts, bolts, bearings, beams, resistors, capacitors, etc., the design of physical equipment would be hopelessly ineicient, and engineers would be forever bogged down with redesigning these elements over and over again. Instead, a large part of design is now the application of these standard elements according to ixed rules, and can be carried out by technicians and design drafters, freeing the engineers for the unique and creative part of each project. Why should not the same be true in the functional domain, that is, in the domain of ideas and performance requirements, which must precede any physical realization? Only through such standardization will the signiicant increase in eiciency and quality, which systems engineering promises, be realized. he attitude that mental activity is spontaneous and somehow “efortless” only because it does not expend material resources must by now surely be well and truly outmoded, and all the efort that has gone into improving the eiciency of physical work, through time and motion studies and the like, now needs to be replicated for mental work. And just as machine tools increased the productivity of factory workers and CAD systems increased the productivity of drafters, new software tools can be developed to increase the productivity of system designers (as distinct from software for managing the design process). he work reported on in this book was undertaken in the years between 1998 and 2001 and subsequently reviewed by Terje Fossnes from the Royal Norwegian Navy. he work was sporadically updated and modiied as a result of other research undertaken by the author in the years since; however, the present version owes its genesis to the initiative and support of a group of engineers at MITRE, led by Brian White (as editor of the Taylor & Francis series Complex and Enterprise Systems Engineering), and, in particular, to the thought-provoking review carried out by Duane Hybertson. he support of the publisher, Rich O’Hanley, is also gratefully acknowledged. he book is divided into three parts, each with a somewhat diferent view of the complexity of the design process. Part A considers the purpose and basic features of design, and how the concept of value can provide a quantitative measure of that wider interaction of the engineered object with its environment. Part B develops the domain in which functional design takes place, and explores how the system concept, as the key to handling complexity, can be embedded in that domain. Finally, Part C proposes a number of functional design elements and develops them in considerable detail, and outlines how they could be applied as part of a coherent functional design framework, supported by a software tool. Finally, my sincere thanks go to my wife, Eli, without whose unstinting support my systems engineering work would not be possible.

Chapter 1

Introduction

1.1

How the Subject Matter Is Approached

he purpose of this book is to introduce the reader to a particular design methodology and to develop a rigorous theoretical basis for that methodology. Somewhat similar methodologies have been proposed and developed to varying degrees of completeness in the past, often under the general heading of “Systems Engineering,”1 but because they have lacked a solid foundation in engineering they have not been able to provide a basis for an ongoing development to which a wide cross section of the engineering community could contribute in a coherent manner, and have therefore failed to make a signiicant impact in many areas of engineering. Also, some of them have created the impression that a systems approach to anything necessarily means a fuzzy, verbose, and hand-waving approach, far from the intellectual rigor that characterizes classical engineering. Hopefully that impression will be dispelled by the approach taken here; a careful, detailed, and, to the extent that it is reasonable and useful, rigorous, step-by-step development of the methodology. However, as the ideas and concepts may not be familiar to some readers, a great deal of explanations, examples, and analogies have been included. he use of models in engineering and, in particular, in systems engineering, is very well established. With its roots in software engineering, there is the Uniied Modeling Language (UML) and its extension to systems engineering, SysML, both managed by the Uniied Modeling Group (UMG).2 he International Council on Systems Engineering (INCOSE) has a working group dedicated to modeling and associated tools,3 and there are numerous models promoted by individuals or small groups.4 It is probably fair to say that most of these modeling approaches result 1

2

n Designing Complex Systems

in descriptions of aspects of the behavior of deined physical objects, even if most often based on the requirements of yet-to-be-designed objects, and they are therefore basically diferent to the approach proposed in this book, which links engineering with business through the concept of the service provided by the system. On the other hand, the modeling of economic performance is also well established,5 but lacks the direct link to engineering and design. he irst part of the book introduces the basic ideas and concepts, in particular the concept of the functional domain. his deceptively simple concept lies at the heart of the methodology, and it is discussed from a number of points of view so that the reader can get a thorough understanding of it. We then look at the purpose of the design process, which leads, when pursued to its logical conclusion, to a particular view of the design process as the core activity within engineering. In this view, design becomes a value-neutral activity, guided only by the desire to provide the most cost-efective solutions to predetermined requirements, but with the value of achieving those requirements prescribed by the stakeholders. By stakeholders we will understand the totality of persons who are directly afected by a project, such as owners, operators, maintainers, and local residents, and of organizations that become involved as a result of their purpose, such as statutory bodies, environmental conservation organizations, and unions, just to mention a few. From the point of view of complex systems, predetermined requirements may appear to be an anachronism and the distinction between stakeholder and designer artiicial; the two together form the complex system, with requirements evolving through the dynamic interaction between them. However, it is a fact that engineering (and design) takes place within a contractual framework, which by its nature distinguishes parties to the contract and deines interfaces between them in the form of requirements, and any design methodology that does not recognize this is unlikely to be successful. Based on this understanding, the design methodology is outlined and its main characteristics discussed in some detail, and a number of rules for how to apply the methodology are developed. he second part contains the detailed development of the components of the design methodology. Functional elements are deined and their properties investigated before considering the nature of interactions between functional elements. his leads to the concept of systems in the functional domain, and it is shown how functional systems can be developed to the point where they provide all the features required by the design methodology. he third part develops some of the major applications of the methodology in considerably more detail, resulting in speciic models and procedures for carrying out system design and optimizing system performance in these cases. Again, while optimality may be an elusive concept in the context of complex systems, it must be understood here to relate to the contractual framework in which the design is undertaken. When introducing a new methodology, we are always faced with the choice of either irst explaining the process without having deined the elements on which

Introduction

n

3

the process operates, and then developing the elements later, or irst developing the elements without any justiication for why they are needed, and then introducing the process afterward. he approach taken here is a compromise, an iterative approach that alternates between elements and process. It starts out by introducing what at irst appear to be four relatively unrelated topics, and then goes on to show how they come together like the pieces of a puzzle to form an initial view of the subject matter, a view that is then expanded and reined in subsequent chapters. he topics are introduced in the next four sections, and are brought together in the last section of this chapter.

1.2 Engineering Engineering is an activity, it is a profession, it means diferent things to people associated with diferent aspects of the activity, and to most other people it is only a vague concept. For our purpose it will be necessary to have a clear deinition of engineering in order to precisely delineate the domain to which our methodology is to apply, even though this precision may result in a more limited deinition than that which would be accepted by most of the professional engineering bodies: Engineering consists of two largely distinct activities, developing technology and applying technology, where technology is the ability to achieve a desired efect in a repeatable and controlled manner through the application of natural science. Within this deinition of engineering, our focus will be entirely on the application of technology. his application of technology is a process, which we shall call the process of engineering, and it may be made more precise by the following deinition: he process of engineering converts an expressed need into an entity which, through its operating lifetime, meets the need in the most costefective manner. his deinition contains the seeds of many of the concepts that will be crucial in developing our design methodology. First, the conversion process that results in the entity (e.g., equipment or a system) contains all activities from concept design to production, supported by management and logistics. Second, the “need” places the focus on something outside engineering as the point of departure and the measure against which the success of the process is measured. hird, the “operating lifetime” emphasizes that the beneit of the entity comes only through its operation over time, necessitating a life-cycle approach to the whole conversion process and leading to a recognition of the importance of maintenance. Fourth, the words,

4

n Designing Complex Systems

“meets the need,” highlight the importance of what the entity does for the stakeholders, rather than any physical property of the entity itself. And inally, “costefective” sets engineering of from both science and art and encapsulates the need for engineering to be useful. Some of these concepts will be further detailed and deined more precisely in later chapters, but we can already at this point formulate the following deinitions: he need is deined in the stakeholder requirements (often in the form of a requirements deinition document or RDD). he activities related to meeting the need, and the timeframe in which they take place deine the project. he process of engineering is a part of the project. Within the process of engineering, we shall focus even more narrowly on the activity of design, a subprocess that converts the need into a complete description of the entity that is to meet the need, complete in the sense that it contains all the information required to produce the entity. As an activity, design has a long and well-documented history, with early testimony in the form of civil structures ranging from the pyramids through the Roman aqueducts to Brunelleschi’s dome in Florence; more recently in the form of machines such as steam engines, textile machines, cars, and airplanes; and most recently in the form of electrical and electronic devices. In every case, the design process started with the designers being able to visualize the inal physical object in their minds, documenting this vision in some form, and then utilizing their knowledge of the natural sciences to dimension the various elements of the design correctly. But this process did not start from scratch each time; over the centuries a vast collection of standard construction elements emerged, and engineering students were taught the properties of these elements and developed their visions of new objects in terms of them.6 Today we have literally millions of standard elements at our disposal, and the eiciency of the design of physical objects is only possible because of them. Imagine if we had to design every bolt and nut from scratch each time we needed one! For simple objects, or objects similar to ones that have been previously produced, this design process is a straightforward bottom-up process; it synthesizes new objects out of a set of existing construction elements, and the proof of correctness occurs only when the new object is created, through a test procedure that establishes that the performance of the object does indeed meet the original requirements. For more complex objects, the design process, that is, the synthesis step, requires considerable skill and experience on the part of the designer, and it is likely that the outcome of the test is that the object does not quite meet the requirements. A revision of the design is required before a repeated test establishes that the

Introduction

n

5

requirements have been met. As the complexity of the object increases, more and more iterations are required to reach a satisfactory result, and the design process becomes increasingly ineicient. An obvious solution to this problem of ineiciency is to somehow subdivide the process into a number of subprocesses, each of which results in a simpler object, but such that when all these simple objects are brought together and allowed to interact, they form an object that satisies the original, complex requirements. hat is, we precede the bottom-up process by a top-down process, in which the functional requirements are analyzed and partitioned into interacting subsets of functional requirements, or functional elements, each of which is simple enough to be eiciently realized through a bottom-up process. he two processes have two main diferences, as illustrated in Figure 1.1, where the (identical) requirements are shown as given in both cases.7 (he upper part of the igure should be thought of as a requirements space and the lower as an element space, with the design process making the transition between them.) First, in the case of the bottom-up design, the physical realizability in terms of known elements is guaranteed (manufacturability is something else), whereas, at the end of the top-down design, the system elements are still functional elements and their physical realizability is not guaranteed. Second, in the top-down approach, the requirements are (ideally) always, as an intrinsic part of the methodology, satisied through every step of the design process, whereas, in the bottom-up approach, the methodology provides no assurance of this. Requirements Initial solution Mismatch on first try

Analysis

Synthesis Elements to be developed

Initial choice

Existing base of elements Bottom-up

Figure 1.1 Comparison of the two design processes.

Top-down

6

n Designing Complex Systems

Relative Design Effort

his composite approach is, essentially, the approach taken in creating complex systems today, and there have been many notable successes (e.g., the public telephone network and the Apollo project), but also many less successful projects, and some disasters. he reason for this great variability in the outcome of the process lies in the fact that there is no established methodology or theoretical basis for the partitioning into interacting, physical objects; it is very much a case of using previous experience and the skill of the system designer. So we are again faced with a problem that is very similar to the one encountered in the synthesis process, except that the scale is increased by orders of magnitude, which makes iterations very expensive. he extent to which the top-down process is applied as a complexity-reducing pre-process depends on the complexity of the product to be designed. As it gets more and more complex, that is, consisting of more and more interacting construction elements and characterized by more and more parameters, the probability of picking a combination of elements that will result in a performance anywhere near the requirements becomes less and less, as does the probability of picking a new combination that will result in an improvement. Consequently, it becomes advantageous to spend more efort on the complexity-reducing pre-process, which is the core of systems engineering. his is illustrated in Figure 1.2. To conclude this section, there is one further point that needs to be brought out, which is that, in reality, particular engineering projects start at very diferent stages in the process of engineering. At the one end of the scale there is the project that starts at the pre-concept stage, as an idea for a possible investment, in which case the RDD contains almost only functional requirements. At the other end of the scale are projects where the design has been completed and the construction phase is about to begin, in which case the RDD contains only physical requirements. As our methodology is concerned only with the very early part of the design phase, we shall from now on understand that the stakeholder requirements are all functional requirements, unless particular reference is made to any physical requirements.

Top-down

Bottom-up

Complexity of the Product

Figure 1.2 The balance between top-down and bottom-up design effort.

Introduction

1.3

n

7

Epistemology and Functionality

Epistemology is that part of philosophy concerned with the theory of knowledge, and in the present case the question is: What can we know about an object? In particular, we are concerned with objects resulting from the process of engineering. Our knowledge of such objects falls into two groups; knowledge about what the object is, and knowledge about what the object does. In the irst group, the physical description, the physical characteristics of objects are deined in terms of their physical parameters, such as size, shape, weight, color, and material, and the values of these parameters. In the second group, the efect of objects on their environments, called variously performance, purpose, function, etc., but which we shall call their functionality, is deined in terms of functional parameters and their values, that is, the functional description. hese two types of descriptions may be considered complementary descriptions of a given object, but they relate to the object in quite diferent ways. he physical description, if it is complete (see also chapter 4), will allow the object to be reproduced or manufactured without any reference to what its purpose is, and while the same physical object may have many diferent uses, the physical description is unique to that object. We would say that two objects that have the same physical description are identical. But to a functional description there corresponds a whole set, perhaps with ininitely many members, of diferent physical objects that all have the same functionality. If we call the totality of all functional descriptions of objects the functional domain, and the totality of physical descriptions the physical domain, then we see that neither the mapping from the physical to the functional domain nor its inverse is single-valued. his may be best illustrated by considering an example, the functional element that efects the extraction of the cork from a corked bottle. You will be familiar with numerous diferent physical objects that satisfy this purpose, including many variants of the ordinary cork screw, a two-pronged device that is inserted between the cork and the bottle, and a gas-operated device that forces the cork out under pressure. But what is the functional element? Is it the collection of physical objects that have this functionality? No, it is not a physical object nor a collection of such objects; it is the description or deinition of the functionality, that is, the sentence “An object has the functionality of a decorker if, by applying it to a corked bottle, it allows the cork to be extracted.” hroughout this book, the term “functional” plays a major role; it appears in such central concepts as functional element, functionality, functional system, and functional parameter, and it is therefore essential to have an absolutely clear and unambiguous understanding of its meaning in the present context. It is arguably the case that many of the problems that arise in the development of large and/or complex systems have their roots in an inadequate understanding of this term and, in particular, in the attitude that it is not important to be precise about anything but the physical characteristics of systems. We shall therefore irst develop a basic under-

8

n Designing Complex Systems

standing of the term, and then reine and strengthen this understanding in numerous instances as we progress and get into the details of the design methodology. In the case of a physical description, we, as humans, can relate to it by visualizing it; even though the object has not been produced yet, we can imagine what it will look like, see it with our “inner eye.” his is possible even if the object has never existed, but because we have demanded that the physical descriptions must be complete in the sense of containing all the information necessary to (re)produce the object (at least theoretically, if not practically), there is a one-to-one mapping (isomorphism) between points in the physical domain and physical objects, and it is therefore often not necessary to diferentiate between the two. (hat is, we shall often, somewhat loosely, refer to either set as the physical domain.) But how can we relate to a functional element? here is no one physical object that corresponds to it; if it were to be visualized at all, it would have to be as an action. It can be diicult to visualize an action without at the same time visualizing an object that performs the action, particularly in such often-observed cases as that of removing a cork from a bottle, but it is not diicult to visualize (or imagine) actions that cannot possibly be performed by any physical object, such as transporting something over a inite distance in an arbitrarily short time. Being able to separate an action from any particular object is the starting point of lateral thinking; being able to recognize which actions are physically realizable diferentiates thinking from dreaming. At this point it is simply important to realize that we ind it considerably more diicult to think about functional elements than physical objects, and that to do so efectively may require some practice. Sometimes physical objects may be used to perform functions for which they were not designed, such as the many uses found for surplus military equipment. However, as we are concerned with design within engineering, such unintentional functionality will be mostly disregarded. A physical object does not have to have only one function; a Swiss army knife has many other functions besides that of a decorker. his example leads us into another aspect of physical objects and functional elements — what we naturally think of as objects and elements. We naturally think of the Swiss army knife as a single object, and would not generally think of its individual blades and other implements as individual objects unless we were, for example, looking at the process of manufacturing such knives. But the functionality of the corkscrew on the knife is an obvious element, whereas the functionality of the whole knife is not easy to formulate, except as the sum of individual elements. he underlying issue here is complexity, the topic of the next section. Before leaving this introduction to the concept of a functional element, we recognize that a functional element does not have to represent the complete functionality of a physical object. It can describe some part of that functionality (such as the decorker on the Swiss army knife), so that the complete functionality may be, on the one hand, represented by a single (large, complex) functional element or, on the other hand, by a set of functional elements, thus introducing a form of hierarchical

Introduction

n

9

ordering in the space of all functional elements. But, more importantly, even where the object appears to have only one function, in the common sense of the word, the functionality, that is, what the object does, can have many aspects, each one representing the view of a person with a diferent relationship to the object. he views of the manufacturer (return on investment), the retailer (proit, customer satisfaction), the user (utility), and the repairer (source of work) may all be represented by functional elements. hroughout this book, we shall use service to designate the more restricted meaning of functionality, the part concerned with the physical processes of the object.

1.4

Complexity

he third topic that plays a central role in understanding the methodology is complexity. We encountered this concept already in section 1.2, but what do we mean when we say that something is complex? hat it has many sides or aspects to it, needs many variables or parameters to describe it, or consists of many parts? Or that it is hard to understand, needs many words to explain, or is diicult to predict? Usually we mean an unspeciied combination of some or all of these and similar deinitions, with the emphasis depending on the particular case, but in one way or the other, complexity is related to the number of parameters required to describe behavior. In particular, complexity increases enormously as soon as humans are involved.8 Or any living organism, for that matter, as illustrated by the fact that we can predict the position of the planets ive years from now, but not the position of a dog ive minutes from now. Until recently, human behavior was considered to be outside the scope of engineering, an attitude that has resulted in engineering losing some of its importance in the business world. However, in the last twenty years or so there has been a renewed emphasis on the fact that if engineering is about providing solutions for people, a thorough understanding of the users and their requirements has to provide the point of departure for any engineering project. For example, in the case of the decorker, its esthetic appeal and ornamental features are signiicant aspects of its functionality, but not easy to measure in “engineering terms.” In addition, the rise of information technology has provided a close coupling between humans and technology, which results in design requirements that go far beyond the simple ergonomics of mechanical equipment. But if taking human nature and behavior into account increases the complexity of a design project, it is equally true that complexity itself is a thoroughly human concept. Something is considered complex because it is diicult for us, as humans, to come to grips with and to work with; it has to do with the capabilities of our brain. It makes no sense to say that something is complex in itself, without putting it in the context of whatever entity is going to operate on it; what is complex to a human may be very simple for a computer, and vice versa. he diiculty we

10 n

Designing Complex Systems

have in conceiving of something as a single entity once it has more than about ten parameters is a characteristic of the brain, and indeed, the success of our whole design methodology will depend on how well it exploits the strengths and avoids the weaknesses of our brains. In equating complexity to the number of parameters required to describe something, it is important to recognize that there are two essentially diferent cases. In the irst case, all (or almost all) of the parameters relate to diferent aspects of the entity being described, as would typically be true in a user requirements speciication. In the second case, the parameters fall into subsets of the same types of parameters, such as the case of a volume of gas, where, if each molecule is treated as a mass point, the state of each molecule is described by six parameters (or variables), but the number of each type of parameter might be in the order of 10E24, equal to the number of molecules. In the former case, one approach to handling the complexity is to combine sets of parameters into single “composite” parameters; one example of such a parameter is quality; another is cost. Another approach is to divide the parameters into classes of diminishing importance, and then treat the parameters in the irst class exactly, and those in the following classes as perturbations of increasingly higher order. In the latter case, the complexity is handled by taking a statistical approach, exempliied by statistical mechanics, and while this exact case does not occur often in engineering, a similar case does. Consider that the molecules in the gas volume all have slightly diferent mass; then it is possible to revert to the previous case by deining an “average” molecule (this may not be the arithmetic mean), and this approach is used frequently in engineering applications where system behavior is dependent on the behavior of a large number of similar elements, such as integrated circuits (numerous individual transistors), telecommunications systems (numerous subscriber loops), and defense systems (numerous units, down to individual soldiers). In a well-known paper,9 Weaver considered these two cases and called them organized complexity and disorganized complexity, respectively. He pointed out that in the case of, for example, a gas, we understand and can give an exact quantitative account of what happens when two molecules collide, whereas in the case of chemical substances we do not understand why one molecule is a poison while another, made up of exactly the same atoms but assembled in a mirror-image pattern, is completely harmless. In the former case, the complexity arises solely as a result of the large number of molecules in a useful volume of gas, whereas in the latter the complexity arises from the necessity of simultaneously treating a sizable number of factors that are interrelated into an organic whole. However, from the point of view of engineering (not science) there is no sharp distinction between these two cases; it is a matter of degree. Even if the details of the molecular interaction between the poison and the human body were understood, the macroscopic efect of the poison would still have a random component, for example, in the form of the probability of death as a function of the amount of poison ingested.

Introduction

n

11

So, for the purpose of design, in either case the complexity requires a statistical or probabilistic approach, and introduces uncertainty. his inherent uncertainty leads to risk in various forms, and this risk must be handled within the design methodology in the same manner as we handle acquisition cost and operating cost. In the design of complex systems, risk becomes itself a major design parameter, and the uncertainty is handled by letting the functional parameters become stochastic variables, characterized by probability density functions. he various measures of risk become expressions involving integrals of these function. Of course, uncertainty also leads to opportunity; risk and opportunity are the two sides of the same coin. And in some areas of engineering, particularly in the development of technology, this is an accepted and exploited part of the process. Another area where risk and opportunity go hand in hand is in the prospecting and exploration for minerals and gas and oil. But in engineering design the contractual framework has traditionally been heavily skewed toward the avoidance of risk through such measures as liquidated damages and other penalties; only in the last ten years or so have more innovative contracting methods, in the form of alliances, become accepted, in which the parties share gain and pain in a “best for project” culture.10 Figure 1.3 is a simpliied illustration of the prevailing situation in “hard dollar” contracts. he dash-dot line is the beneit, as deined by the contract, increasing linearly up to the required performance (which in this case has the value 1.0), but 2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8 1 Performance

1.2

1.4

1.6

Figure 1.3 A simplified illustration of the major parameters involved in a “hard dollar” contract. (The y-axis is the relative value of each parameter.) The thin, full line is the performance probability distribution, as estimated by the designer; the dash-dot line is the benefit, as stipulated by the contract; the dotted line is the estimated cost at completion; and the heavy, full line is the benefit/cost ratio.

12 n

Designing Complex Systems

then remaining constant above that. In other words, the contract acknowledges no beneit for achieving a greater performance than speciied, but would enforce penalties to make up for any deicit in the performance. Consequently, the designer has centered the performance distribution, represented by the thin, full line, around a performance value of 1.2 in order to leave only a very small probability of incurring a penalty. In choosing this performance value, he would have balanced the probability of winning the contract against the expectation value of the penalty. he result is that the cost, represented by the dotted line, is about 25% higher than it would be for a design centered around the required performance value, and the beneit/cost ratio, represented by the heavy, full line, is correspondingly lower.

1.5

Systems

he discussion on the nature of complexity in engineering leads quite naturally to the fourth topic — systems — because systems can be viewed as a means of handling complexity. he idea of partitioning an entity into a set of interacting elements for the purpose of getting a better mental grasp of it, and the recognition that the entity can have features that are not present in any of the elements, is not new. It lies at the center of what is usually known as general systems theory,11 and has been applied with varying degrees of rigor to most areas of our experience. Indeed, the word “system” has become so common that it is used without any precise understanding of its meaning or signiicance; it vaguely signiies something that consists of many parts, or has many sides to it — a few examples are telephone system, monetary system, and solar system. Dictionaries give such general deinitions as “complex whole, set of connected things or parts, and organized body of things;” we need to discuss how we want to use the concept. First of all, even though we shall restrict our attention to engineered systems when it comes to the development of the methodology, which excludes such systems as the solar system and the immune system, engineered systems are not different from systems in general as far as their system nature is concerned. hey are only diferent in that they relect an expressed intention on the part of their designer, and that we can therefore talk about such aspects as their cost-efectiveness in achieving that intent. Second, we recognize that there is nothing in the system concept that restricts it to physical systems; it applies equally well to concepts or ideas, in which case the elements are simpler (or better known) concepts and the interactions are formal relationships between these elements (i.e., inherent in their deinitions). Indeed, a major feature of our methodology will be the formulation of a functional description as a system of interacting, smaller descriptions, called functional elements. However, because physical systems are much easier to visualize, it is often easier to use well-known physical system to illustrate some important features of systems in general that therefore apply also to abstract or functional systems.

Introduction

n

13

hird, because of the interactions between the elements, a system can be thought of as introducing an ordering in a previously unordered set of elements, or of structuring the set. An example of this is when a set of non-interacting water molecules (as in a dilute gas of water molecules) are brought close enough to interact and form water, and inally brought even closer (by lowering the temperature) to form ice. he set of non-interacting molecules do not form a system, the molecules in the ice crystal do. his example also shows that the same set of elements can have quite diferent properties, depending on the interactions of the elements, and this can be further illustrated by a related example — a set of 12 hydrogen and 5 carbon atoms. When brought together they form pentane, but the pentane molecule comes in three varieties, the so-called isomers, each with a diferent structure and with diferent physical properties, such as boiling point. he concept of structure will play an important part in the theoretical developments in later chapters. Fourth, the elements in a system may themselves be treated as systems (or, perhaps, subsystems); in the case of pentane, in a system of pentane molecules (say, a small volume of penthane liquid) the elements are molecules, but the molecules may be treated as systems of atoms. Fifth, some of the elements in the systems we shall consider will consist of, or include, people in the form of operators and maintainers. We shall return to this most important aspect of our systems in various places throughout this book; here we just note that it is the inclusion of people that allows our systems to have a steady state through the capability of people to generate negative entropy (i.e., create or restore order) from an interaction with the environment, and also that we now have two groups of people, those inside the system and those outside. he latter group is the stakeholder group, and our design methodology will treat the two groups quite diferently. Finally, we note that while, strictly speaking, a system is a mode of description of an object in terms of a set of interacting elements, common language uses the word “system” to identify the object itself irrespective of how it is described. We shall use both meanings of the word; which one is meant in a particular case should be obvious from the context and not cause any confusion.

1.6

Bringing It All Together

In section 1.2, we argued that design is the core activity of engineering; it is the creative activity that distinguishes the engineer from the technician. It is a mental activity that takes place within the brains of individual engineers and consists of synthesizing a solution from a set of known construction elements. But it is limited by the capability of the brain to handle large or complex tasks and becomes ineficient as the complexity increases. What is required is a process of reducing the complexity before making the transition into the physical domain and the start of the classical design activity, a process we may describe as doing design in the func-

14

n Designing Complex Systems

tional domain. he discussion in section 1.3 indicates two reasons why functional elements provide this means. First, because the nature of functional elements, representing classes of physical objects, allows us to abstract from the details of a speciic physical object and therefore in itself constitutes a reduction of complexity. Second, because the functional domain ofers the possibility of proceeding from the stakeholder requirements in a top-down fashion, arriving at a set of functional elements of such limited complexity that each can be realized as physical objects without the iterations that make the current design methodology ineicient. But the elements in the set are not independent; it is the fact that they interact that allows relatively simple elements to represent complex behavior. he discussion in section 1.5 shows that the general theory of systems provides a framework within which functional elements can interact and thereby produce a behavior that is not evident in any one of the elements and one that also displays the correct hierarchical ordering of the elements. Finally, as handling complexity lies at the heart of the design activity, the discussion of complexity in section 1.4 shows that our design methodology will have signiicant statistical aspects. In some ways, this design methodology is to engineering what statistical mechanics is to mechanics. What emerges from this is a design methodology in which the design elements are functional elements and the end result is a system of functional elements that provides a service that satisies the stakeholder requirements, and in which the design rules ensure that the physical system that results from converting the functional elements into physical objects will represent the most cost-efective solution to meeting the stakeholder requirements. Before closing this introduction, it is appropriate to make a comment about the relationship between this proposed design methodology and the methodologies used to develop software, in particular structured and object-oriented programming. It will no doubt have occurred to most readers that the approach outlined above is very similar to that used in modern software development, and that functional elements are somehow related to the software representation of objects. To see what that relationship is, we recall that the objects of object-oriented programming are real, physical objects, such as persons, assets, accounts, etc., with real, physical attributes, or properties, such as name, address, quantity, date, etc., and the software describes interactions between objects in terms of operations on these attributes, called methods. he software is a language to describe what takes place in the physical world; it has no substance in itself. Functional elements, on the other hand, are a priori to any physical realization, and have an existence and meaning (and therefore “substance,” even though not physical) in their own right. Functional elements, describing what physical objects are capable of doing, are therefore related to methods rather than to objects; they are a type of generalized methods. hey can be described by software, and if an object-oriented approach is taken, they become a new set of abstract “objects.”

Introduction

n

15

Notes 1. A few representative references in the development of systems engineering, with particular emphasis on design rather than on management, are Blanchard, B.S. and Fabrycky, W.J., Systems engineering and analysis, 4th ed., New York: Prentice Hall, 2005; Bode, H., he systems approach, in Applied science — Technological progress, report to Committee on Science and Astronautics, US House of Representatives, 1967; Chestnut, H., Systems engineering methods, John Wiley & Sons, New York, 1969; Johnson, R.A., Kast, F.W. and Rosenzweig, J.E., he theory and management of systems, McGraw-Hill, New York, 1963; Kalman, R.E. et al., Topics in mathematical system theory, McGraw-Hill, New York, 1969; Mahelanahis, A., Introductory systems engineering, John Wiley & Sons, New York, 1982; Miles, R.F. (ed.), System concepts, John Wiley & Sons, New York, 1973; Sage, A.R., Methodology for large-scale systems, McGraw-Hill, New York, 1977; Warield, J., A science of generic design: Managing complexity through systems design, Iowa State University Press, Ames, IA, 1994; Wymore, A.W., A mathematical theory of systems engineering — he elements, John Wiley & Sons, New York, 1967; Systems engineering methodology for interdisciplinary teams, John Wiley & Sons, New York, 1976; Model-based systems engineering, CRC Press, Boca Raton, FL, 1993. 2. he roots of UML lie in object-oriented software development, as set out, for example, in Jakobson, I., Object-oriented software engineering; a use case driven approach, rev. print. ed., Addison-Wesley, Reading, MA, 1993. he UMG Web site is http:// www.omg.org, and an introduction and numerous links can be found in Wikipedia, at http://en.wikipedia.org/wiki/Uniied_Modeling_Language. 3. INCOSE, Web site of the Model Based Systems Engineering working group, http://www.incose.org/practice/techactivities/modelingtools/mdsdwg.aspx. See also Wymore, A.W., A mathematical theory of systems engineering — he elements, John Wiley & Sons, New York, 1967. 4. A listing of modeling tools can be found at http://www.SysMLforum.com. 5. A journal dedicated to economic modeling is Economic Modelling, Hall, S. and Pauly P., eds., Elsevier, New York; otherwise, a good starting point is the Web site http://zia. hss.cmu.edu/econ/. 6. Being a well-established subject, engineering design has a vast literature associated with it. A few references that document well the classical design process and the issues arising within it, albeit with a grounding mainly in mechanical/structural engineering, are Dhillon, B.S., Advanced design concepts for engineers, Technomic Publishing, Lancaster, PA, 1998; Ertas, E. and Jones, J.C. he engineering design process, John Wiley & Sons, New York, 1993; Lewis, W.P. and Samuel, A. E. Fundamentals of engineering design, Prentice Hall, New York, 1989. 7. his igure and the following one irst appeared in E.W. Aslaksen, Going up? Coming down!, Engineering World, 1, 4, 1991.

16 n

Designing Complex Systems

8. he issue was discussed at some length in the book by Stephen Kline, Foundations of multidisciplinary thinking, Stanford University Press, 1995; some other, more recent references to the complex systems literature are Braha, D., Minai, A., and Bar-Yam, Y., eds., Complex engineered systems: Science meets technology, Springer-Verlag, Heidelberg, 2006; Axelrod, R. and Cohen, M., Harnessing complexity: Organizational implications of a scientiic frontier, Simon and Schuster, New York, 1999; INCOSE, Web site of the Systems Science group, at http://incose.org/practice/techactivities/wg/sseg/. 9. Weaver, W., Science and complexity, American Scientist, 36, 536, 1948, available online at www.ceptualinstitute.com/genre/weaver/weaver-1947b.htm. 10. Some background to the development of this contracting method is contained in A resource and research bibliography, available online at www.mcmullan.net/eclj/Alliance_Contracting.htm. Legal aspects are discussed in Commonwealth procurement guidelines, available online at www.ags.com.au/publications/agspubs/legalpubs/commercialnotes/comnote04.htm. 11. Two of the most signiicant references in general systems theory are Laszlo, E., ed., he relevance of general systems theory, George Braziller, New York, 1972, and Von Bertalanfy, L., General Systems heory, George Braziller, New York, 1941.

Chapter 2

The Purpose of Design

2.1

The Design Process and Measures of Success

If we are to develop a methodology for designing systems, we irst have to answer the question: What constitutes a good design methodology? In a qualitative sense, the requirements of the methodology must include a high probability of the object resulting from the design meeting the user requirements (i.e., a successful outcome), low cost of performing the design, and applicability to as wide a range of potential design problems as possible. In addition, we would prefer a methodology that is logical and easy to learn and remember, and, perhaps particularly important, it should not be a hindrance to creative thinking, but on the contrary support it by providing reusable models that link our creative ideas to reality, without which they are just dreaming or wishful thinking. In this regard, it is useful to contrast what we are trying to achieve with other design methodologies, exempliied in particular by TRIZ, the inventive problem solving technique developed originally by Altshuller.1 Briely, the technique consists of four steps, as illustrated in Figure 2.1. he starting point is to view design as a problem-solving exercise, so the irst step is to understand (i.e., classify) exactly what the problem is. he second step is then to search through past experience to ind where analogous problems arose (they form a class), and in the third step select the most appropriate solution from those used to solve the problems in the class. he fourth step is then the adaptation of this solution to the speciics of the current problem. he technique is based on the observation that the vast majority of design problems are solved by modifying (to a greater or lesser extent) solutions to previous 17

18 n

Designing Complex Systems

My Problem

Analogous Previous Problem

Analogous Previous Solution

My Solution

Figure 2.1 Four-step representation of the TRIZ process.

problems. In efect, this creates a second level of reusable (standard) elements above the level of construction elements, and using this picture, what we are proposing is to create a third level, where reusable models (functional elements) are used to rationalize and support the creative or project-speciic part of the design process, as illustrated in Figure 2.2. hese qualitative requirements will be useful for guiding us through the development of the methodology, but it would be good to have some quantitative measure to tell us how successful we are as we go along, to somehow reassure us that we are on the right track. he diiculty with this is that the proof of success can only lie in having successful outcomes when the methodology is applied, which requires the methodology to be, irst, more or less fully developed and, second, accepted by at least some part of the engineering community. hus, the proof of success could only arrive some considerable time after the methodology has been developed. However, the situation is not that we want to develop a completely new methodology; many of the general ideas and concepts we shall be using have been used successfully before, and the basic approach of treating complex objects as systems is very old. he situation is that the design of systems runs into a number of problems well known to system engineers, the primary one being low eiciency (or high cost), which often makes the design process not cost-efective, and which leads to the adoption of existing solutions in new situations where they may not be

Increasing Level of Abstraction

Design Type

Supporting Elements

Top-down Design

Functional Elements

Adaptive Design

Previous Solutions

Bottom-up Design

Construction Elements

Figure 2.2 A view of design as consisting of three types of processes at differing levels of abstraction, with each type relying on supporting elements for efficiency.

The Purpose of Design

n

19

entirely appropriate. It is the underlying assertion of the present work that most of this ineiciency comes from a lack of a complete and rigorous foundation for the design process and, as a result, a lack of the standardization that is a prerequisite for eiciency. herefore, if we are able to develop a basis for system design that is suiciently rigorous to demonstrably support a program of standardization of functional elements, we shall deem our undertaking to have been successful. Realizing a standardization program will take many years. In answering the question about what constitutes a good design methodology, a signiicant component was, obviously, a high probability of achieving a successful outcome. But what is “a successful outcome”? What is good design? What are we trying to achieve by the design process? If we look upon the object resulting from the design purely as a physical object, that is, for what it is, we could try to come up with criteria of good design along the lines of “most appropriate materials,” “no waste of material,” “easy to manufacture,” “low energy consumption,” and so on, and these are all among the criteria traditionally used to judge a design. hey are all characterized by being criteria that can be applied to the object of the design as such, without knowing the application of the object, and where the judgment can be made by the designer’s peers. hey are most signiicant when applied to objects at the bottom of the complexity scale, that is, to the basic building blocks, to the components that represent our technology, but as we move upward on the scale, through modules, equipment, and up to systems, this group of criteria is displaced (or at least augmented) by a group concerned with what the object does, that is, its functionality. Functionality can only be judged when the object is actually operating, and the judges are the users, not designers. In the case of a semiconductor, the judges of good design are bound to be engineers, but the judges of good design of a telephone system are mainly the subscribers, and they do not care about the design of the semiconductors that are used in the system. his shift in focus from technology to functionality and from the judgment of the designers to that of the users is a major source of the complexity of system design, and must therefore have a great inluence on our design methodology. It follows from the above that the design of a system cannot be judged by considering the system by itself; a system design can only be judged relative to its intended stakeholder group. Conversely, the stakeholder group must be deined and fully characterized, in the form of the relationships of its constituents to the project, prior to the start of the design process. he stakeholder requirements should be deined prior to the start of design; this is commonly accepted and generally the case. And it is also accepted that there should be a deined process for handling the inevitable changes to these requirements, although the implementation of this process often leaves something to be desired. However, the clear and detailed deinition of the stakeholder group is much less common, and a unique relationship between the group and the requirements, in the sense that a change to the stakeholder group will result in a change to the requirements, is even more uncommon. A result of this is that dissatisfaction with the performance of a new system will just as often be

20

n Designing Complex Systems

due to an inadequate deinition and understanding of the stakeholder group and its dynamics as to any shortcoming in the subsequent design process itself, and herein lies a main cause of the complexity of systems engineering. he term “stakeholder group” should not be taken to imply that it is a group in the mathematical sense. It is actually just a set, and “subgroups” are subsets. he members of the group may include not only the users in the narrow sense, such as “the users of public transport” being the people who travel on the system, but in principle anyone who has a stake in the behavior of the system, such as the equity and debt providers. he members are not individuals; they represent a particular relationship between a system and a person, such as “investor,” and the same person can be represented by more than one member, such as “investor” and “traveler” in the case of the public transport system. his can also be expressed by saying that each member is interested in only particular aspects of the functionality. he members form a set by virtue of placing requirements (which may be very diferent) on the same system (or subsystem). In the following, we shall, for simplicity, refer to members of the stakeholder group as stakeholders, because the people within the system, although stakeholders in the sense deined in section 1.1, play no role in the functional domain. In chapter 1 we had noted that there are two groups of people related to a project, those within the system and those outside the system, that is, the group. In view of the foregoing paragraph, we should now strictly reformulate this in terms of roles rather than people, as the same person can be inside the system, for example, as an operator on the transport system, during working hours and outside, for example, as a traveler, outside working hours. However, for simplicity we shall not make the distinction between person and role, so that when we say “operator,” we mean the person occupying that role. he issue here is not the existence of a stakeholder group or not, because eventually every system is, of course, exposed to its stakeholder group. he issue is how to include the stakeholder group in the design methodology in such a manner as to increase the probability of a successful outcome of the design process, and the irst step in this direction is to develop an operational deinition of “stakeholder group,” in the sense that the concept can be manipulated as an object in the methodology. he deinition we shall adopt, and develop in more detail shortly, is that the stakeholder group is the set of persons, not included in the system, who determine the success of a project, where “project” denotes the whole life cycle of a system, in accordance with our deinition in chapter 1. At present this is a circular deinition; the stakeholder group is deined in terms of the concept of success, but success is deined by the stakeholder group, so it all comes back to the basic problem of inding an objective, universally applicable measure of the success of an engineering project. he value that this measure takes on in a particular case can then be determined by the stakeholder group. For any given project, the measure of success will generally be very complex, as it must somehow be related to the fulillment of the requirements that deine the

The Purpose of Design

n

21

purpose of the project, and the documents deining these requirements can run into hundreds of pages even for a medium-sized project. We can try to visualize this by thinking of the requirements as points in a “requirements space” and simplify this space to a plane; a project is then characterized by a certain area of this space. Similar projects will have areas that overlap to a large degree, dissimilar projects will have areas that overlap to only a small degree, as shown in Figure 2.3; but can two projects have completely disjoint areas? Or is there some purpose that is common to all projects, and which might therefore be the universal measure we are seeking? Before attempting to answer this question, let us explicitly recognize that we have now introduced two closely related, but still completely distinct concepts. One is that of functionality, which arose as a means of expressing what a physical object does, and as such is something that the designer can manipulate and about which he can make decisions. he other is that of purpose, which is an expression of what the stakeholders want. It is embodied in the stakeholder requirements, and it is the fulillment of this purpose that has a value. Value, purpose, and stakeholder requirements are all related to the stakeholders and are things over which the designer has no inluence; they are given at the outset of the design process, and will evolve in a dynamic fashion during the design. he two are closely related; irst, because the designer’s task is to ind that functional element (or system of functional elements) that has as its output a functionality that meets the stakeholder requirements and thereby fulills the stakeholders’ purpose, and, second, because the parameters describing the service must be related to the parameters of the stakeholder requirements in that the purpose must be able to be expressed as a function of the functional parameters. If this latter condition is not met, there is no way of connecting to the value and therefore no way of optimizing the design. But it is a serious mistake to simply equate functionality (or, more precisely, the service) with purpose (as was, unfortunately, implied in he Changing Nature of Engineering 2), and a irst illustration of that is given in the next section. As a very rough analogy, equating functionality with purpose is like equating the symptoms with Project B Project A

Project C

Figure 2.3 The purpose of three projects represented as areas in a “requirements space.” Projects A and C are similar, project B is dissimilar to A and C. Requirements are simply points in this space.

22 n

Designing Complex Systems

the disease. By having a complete set of symptoms we can, presumably, identify any disease, but this is not the same as knowing the disease, in the sense of what causes it, which becomes apparent when we look for a cure. Similarly, having a set of functional parameters that would be adequate for describing the functionality is not the same as knowing the purpose, which becomes apparent when we try to optimize our design. In summary, the point of departure for our design methodology is a set of requirements for the to-be-designed object, the stakeholder requirements. hese requirements fall into two main groups: physical parameters describing what the object should be, and functional parameters describing what the object should do. But in addition, the stakeholder requirements must describe what the object is supposed to achieve from the point of view of the stakeholders (which is its purpose), and this is done by associating a value with each of the functional parameters.

2.2

Return on Investment

If we recall the idea, introduced in section 1.6, of describing the functionality of a complex physical system in terms of a system of functional elements, the question posed at the end of the last section can be reformulated as “Is there a functional element that is common to all systems?” his would be the functional element that fulills the purpose common to all projects, if there is such a basic purpose. he argument for the existence of such an element, and the deinition of its parameters, is a crucial step in the development of the design methodology; because of the hierarchical ordering of functional elements alluded to in section 1.3 and discussed in more detail in chapter 4, every functional element will be related to this common element, and the development of all functional elements must start from this one element. he creation and operation of any system must involve an expenditure of resources in some form, such as labor, energy, information, and materials, and even forms that are not normally or easily measured in monetary terms. But would anyone incur a cost without any prospect of a return? he return might not be directly in terms of money; it can be in the form of personal well-being, absence of illness, peace of mind, a sense of achievement, and so on, but indirectly, as with the cost, this can, in principle, always be measured in monetary terms. he return can only occur once the system has been created and put into operation, so that the expenditure must come before the return and is therefore an investment. All engineering projects are subject to this cycle of investment, creation, and return, and as there are ininitely many possible projects, all competing for a inite set of resources, the fundamental purpose of the engineering process is to maximize the return on investment, in the sense that while all other considerations may be ignored in a process of simpliication, this one cannot be ignored or simpliied away without making the design process irrational. Or, in other words, the constraint

The Purpose of Design

n

23

of competition for limited resources is the essence of the process of engineering, that which makes it fundamentally diferent from a science. Engineering is not about truth, but about cost-efectiveness, with the efectiveness being judged by the stakeholders. Consequently, the functional element representing this fundamental purpose, return on investment (ROI), can be said to be an irreducible element, and it is not dependent on the particular system, but is, because it has its genesis in the process that creates all systems, universal to all systems. In order to produce a return on the investment, any system must put its functionality into operation, and that operation is described by the values taken on by the functional parameters. he design identiies the value each of the parameters needs to take on in order to meet the requirements of the stakeholders; they are the nominal design values for the particular system. he degree to which the system actually meets these requirements can, in principle, be characterized by a single variable, the system quality of service, or QoS, which is a function (often the weighted average) of the degree to which the individual parameters meet their nominal design values. his single performance parameter is denoted by S, and while it is called “quality,” it may in fact often be mostly, or even wholly, a measure of the quantity of whatever the system produces. It just depends on what is the most important feature of the system’s functionality, what Hitchins calls “prime directive.”3 As already stated, the creation and operation of any system must involve an expenditure of resources. his expenditure may take many forms, but in the context of engineering, they must all be converted to monetary terms, for example, dollars, and together they shall be termed the cost of the system, denoted by C. No system can continue to operate, producing a service and incurring costs (or expending resources), without receiving something in return that sustains the operation. his shall be called the revenue, and no matter in what form it is received, it must, within the context of the process of engineering, be expressed in monetary terms. As with the costs, this may not always be a simple matter, as is exempliied by such a return as “quality of life” in, for example, a foreign aid project; this is part of the vast increase in complexity that occurs once engineering goes beyond the traditional boundaries of objects and outcomes directly describable in terms of physics. he revenue will be denoted by R. All of the above takes place within a time period; no system can perform any service in an instant of time, nor can it be created instantly. he time period over which all activities associated with a system take place is its life cycle; in the terms of a living organism, this is the time period between conception and death. he duration of the life cycle, which may just be called the life of the system, will be denoted by L, and measured in units of time. Both the cost and the revenue are referenced to the beginning of the life cycle, that is, they are the sums of the present values of costs and revenues, respectively, incurred throughout the life cycle (see section 7.3).

24

n Designing Complex Systems

hese two parameters L and S, and the two variables R and C, are necessary and suicient for expressing the concept of ROI, which in the following will be denoted by Q,  R(S , L )  ROI = Q = 100  −1 %,  C(S , L )   

and constitute what we shall call the basic set. he two parameters S and L appear only implicitly, but that does not make them any less necessary. If the cost and the revenue did not depend on both the quality and the duration of the operation, well, then, why not ask for perfection and that it last forever? We can now deine a very special functional element, which we shall call the irreducible element, as that element which is common to all engineered objects and which has the unique property of unifying functionality and purpose. It can be represented graphically as shown in Figure 2.4, with the functional parameters (i.e., those parameters that enter into the deinition of the functionality) on the right-hand side, and the functional variables (i.e., those parameters describing the interaction with the outside world required in order for the element to provide its functionality) on the left-hand side. his irst example of a small functional element (albeit a very special one) already gives an idea of why we must diferentiate between functionality and purpose. he functionality of the irreducible element is to deliver a service, characterized by the two parameters S and L, by using resources, parameterized by the cost, C, and attracting a revenue, R. his is the most basic description of the functionality of any object in that it is an abstraction away from any speciics of the functionality; it can be expanded by expanding each of the four variables, that is, the cost can be subdivided into cost types and the revenue into revenue types, the service can be characterized by more parameters, and the lifetime can be subdivided into diferent parts. he ROI is the most basic expression of the purpose, and the four variables of the irreducible element are suicient for expressing the ROI as a function of them. A given object, such as a complex system, may be intended to fulill a multitude of S C purposes, usually represented by diferReturn on ent members of the stakeholder group, Investment and in order to fulill them, we need a L very complex functional element, or a R system of less complex elements, with many variables. However, and this is the Figure 2.4 The irreducible element crux of the matter, even in the case of a return on investment. very detailed (i.e., complex) description of functionality, ROI (for example) may

The Purpose of Design

n

25

be the only purpose. hat is, the functionality must be complex enough to allow us to fulill the purpose, but the purpose of an object with complex functionality may be simple.

2.3

Philosophical Motivation

he approach to the development of some of the basic concepts put forward above was inspired by the approach taken by Kant in his Critique of Pure Reason,4 in particular, by the section called “Transcendental Analysis.” While Kant’s purpose was to identify the basic characteristics and capabilities of the mind and so determine the limitations on mental activities, in particular as pertains to those that do not rely on any sensible input, the purpose of this work is very much more modest and of an altogether more limited and practical nature — to investigate the characteristics of the concepts used to think about engineering problems. Above all, there is no transcendental aspect involved in this investigation; engineering is irmly rooted in reality as experienced through our senses. However, despite these fundamental diferences, there are strong parallels between the two approaches. In the Critique of Pure Reason, Kant argued that a person’s thoughts appear to that person as a coherent whole (the unity of consciousness), within which thoughts can be related to one another, because they are generated by the mind using a ixed set of rules, or concepts. We interact with the external world through our senses, and through the representation of such inputs, or sensations, within a space-time framework, the mind creates intuitions. hat is, we (i.e., our minds) become aware of the external world through intuitions, but knowledge is only generated through the processing of intuitions by the faculty of understanding. he analogy between this and engineering can then be expressed by the following correspondences: Kant

Engineering

Creating knowledge through the faculty of understanding

Converting requirements into solutions through the process of engineering

Unity of consciousness

All systems have a functional element in common (the irreducible element)

Categories

Basic set

Concepts

Functional elements

Intuitions

User requirements

In Kant’s theory of the mind, the concepts generated by the understanding and used by it to give synthetic unity to a manifold of intuitions are themselves formed according to a set of rules; these are the categories, and they are the manifestation of

26 n Designing Complex Systems

pure reason. Correspondingly, in engineering, the functional elements arise from the irreducible element by the application of certain rules, and the starting point for formulating these rules is the basic set of parameters associated with the irreducible element. But the most important point of this analogy is the correspondence between the unity of consciousness and the irreducible functional element. he former is illustrated by the well-known example of the diference between six men each reading one word of a six-word sentence and one man reading the whole sentence; the meaning of the sentence emerges only when the six words are perceived by the same brain. he synthesis that takes place when the representations of the words are brought together is the “I think” of Descartes, and the fact that they can be brought together, that is, that completely disparate representations have something in common, is the unity of consciousness. It is what allows me to perceive the external world as a connected whole and that constitutes “me.” Similarly, what allows functional elements to be brought together and form complex functional systems is the fact that they are all derived from a common element, the irreducible element. he purpose expressed by the irreducible element, which we have termed ROI, is what binds the elements of the system together; they all participate in achieving that purpose. And also, without this unity of purpose, individual functional systems remain just that; they have nothing in common that identiies them as elements of the same process, the design process. Conversely, the purpose of ROI can, in this sense, be considered to be the essence of engineering; when we extract from all other diferences between engineering tasks, this purpose remains, common to them all.

2.4

The Concept of Value

he return arises through the value of the service provided by the system; the revenue is determined by (in the simplest case equal to) what the users perceive to be the value of the service to them, that is, what they are (or would be) willing to pay for the service. Clearly, the value of a given service is not an absolute measure; it exists only in relation to a particular user group. Indeed, this dependence of the value on the user group provides an alternative deinition of the user group — the group of all persons who have a say in determining the value of the service provided by the system. he concept of value is essential to the process of engineering; without it, design ceases to be a rational process.2 In the author’s experience, a greater proportion of poor designs is due to erroneous or inadequate value deinitions than to any other cause, and the reasons why it is diicult to deine value adequately are easily discernible. hey include such practical diiculties as achieving consensus within a diverse user group, making users understand the signiicance of the parameters used to characterize the service, and getting users to articulate and quantify what

The Purpose of Design

n

27

are often feelings, prejudices, and impressions rather than rational judgments. But they also include a lack of understanding and deinition of the process of engineering itself. On the one hand, there is the view, supported by a signiicant segment within the engineering community, that engineering is a science, albeit an applied science, and must not only remain securely anchored in the natural sciences, but must not allow itself to become tainted or diluted by “soft” issues that belong more properly to such ields as psychology, linguistics, philosophy, economics, etc. his view essentially makes engineering an incestuous occupation; “good engineering” becomes whatever advances our stock of technology, without any further measure of the usefulness of this technology. Of course, in the past, this was not a problem, because there was such a backlog of unsatisied needs that almost any new technology was eagerly picked up by the community and put to use in satisfying those needs through the production of capital goods. his situation is one of the hallmarks of the industrial society, but that is starting to change as the industrial era comes to an end, as elegantly argued by Danielmeyer.5 On the other hand, there is a view, among both engineers and in the community in general, that there is something morally, or even religiously, wrong with putting a (monetary) value on all services. In the extreme, this argument says that as all services are there to meet human needs, and humans, made in God’s image, are ininitely valuable, satisfying their needs is also ininitely valuable. Nonsensical as this argument is by any practical standards, it is astonishing to see how shades of it creep into many of the debates in the community about the level and priority of services. Both of the above views have the efect of limiting the relevance of engineering to society. Properly understood, engineering is a potent methodology for meeting many of the needs of society, but this must include an understanding of the value concept. It is the value concept that provides the coupling between the system and the stakeholder group, and it is only in terms of such two-component entities that engineering becomes relevant to society. Designing systems in isolation is an exercise in self-gratiication. But the coupling of system and stakeholder group allows the design methodology to become value neutral; while the deinition of a value function may be developed with the help of the designer, assigning numerical values to the parameters of the function is the responsibility of the stakeholder group. Questions relating to how value is to be allocated, what is the proper value in a given case, cannot be answered by the engineering methodology, and trying to make it do so only destroys its efectiveness. However, this does not mean that engineers, as members of the community, and as particularly well-informed members of the community in many cases, should not contribute to inding the answers; quite on the contrary. Deining the value of a service is perhaps the most diicult part of the process of converting a need into a set of stakeholder requirements, the stakeholder requirements deinition process. And again, it is possible to draw a parallel with Kant’s view of the mind; the requirements deinition process corresponds to the

28 n

Designing Complex Systems

W

Region of Interest

Figure 2.5

S

Typical form of the value function W(S).

sensibility, that part of the faculty of representation that converts a sensation into an intuition. he value of a particular service will, in general, depend on the values of the parameters describing the service; if a parameter can be varied without afecting the value, the parameter is superluous. herefore, as the description of a service is developed in a top-down fashion, with an increasing number of parameters to express the increasing level of detail, the expression for the value will need to be developed in this top-down manner as well. At the top level, the service is always represented by the irreducible element, ROI, and the value W is a function of the single parameter S, the quality. he function W(S) is often a highly non-linear function; for a number of reasons there is a relatively narrow range of S in which W(S) increases rapidly with increasing S.6 Below this range, the quality of the service is so poor that it is basically useless. Above this range, an increase in S brings hardly any further increase in the value; it is a region of saturation or “overkill,” as shown in Figure 2.5.

2.5

The Central Role of Money as a Measure

he development in this chapter has led to a view of engineering design as “creativeness under the constraint of cost-efectiveness.” At irst glance this seems very reasonable, even maybe a bit of a “motherhood statement.” Designers are always told to develop “cost-efective solutions,” and mostly believe this is what they are doing. However, once we start to look more closely at providing a precise deinition of “cost-efective,” such as the concept of ROI, we ind that what most solutions represent is “an acceptable solution at minimum cost.” his focus on the cost side of the equation does not arise because of an inherent parsimoniousness on the part of engineers, but because it is so much easier to determine the cost of a service than its value (which is the monetary expression of efectiveness). As anyone who has participated in value management or value engineering workshops knows, after a bit of lip-service to “value for money,” the workshop often quickly turns into a

The Purpose of Design

n

29

cost-cutting exercise, and relatively rarely is a monetary igure put on the value of a feature deleted as a cost-cutting measure. his one-sided approach does not allow any proper optimization, in the sense of inding the optimum balance between the opposing factors of value and cost. If the creativeness in design is considered to consist of recognizing a range of options as possible solutions to a requirement, then the lack of a well-deined measure of value, and thereby the lack of a criterion for deciding which one is the better option, is bound to result in a preference for options that have already been successfully applied. he uncertainty in the values of the untried options translates into a risk that often removes them from any further consideration. his restriction on creativeness is a manifestation of one of the central issues in the design of complex systems. It is not that we cannot, in principle, see how to ind an optimal solution; it is that the cost of doing so, in any one particular case, is so high that it appears unlikely to have a reasonable payback. Any design methodology must therefore not only demonstrate that it will lead to optimized solutions, but that it will do so at a cost that is clearly considerably less than the beneit expected from optimization. Before delving any further into the issue of assigning monetary value to a service, we note that there exists a very signiicant industry group where this is relatively straightforward and not in general controversial. hat is the resource industry, where the functionality is to produce a given product (ore, coal, oil, gas), but with relatively little responsibility for the features of that product, so that the value is proportional to the quantity produced. A typical case is the design of a mine. he service is to deliver ore to the processing plant, and optimizing the design means minimizing the total (i.e., on a life cycle basis) cost per ton of ore, and also taking into account the cost of inadequate delivery rate (i.e., the processing plant being idle, penalties on delivery contracts, etc.). In this case it is well-known how to develop, in a top-down fashion, a cost model of the mine and its operations that allows any design option or feature to be evaluated in monetary terms (but, as previously noted, it is time consuming). All that is required to arrive at a truly optimized design is then the “creativeness” part of the design process, a systematic search for and development of options for every facet of the operations. An example of where this approach, even in a rudimentary form, led to a good result is the Northparkes E26 underground copper mine in New South Wales, a joint venture between North Ltd. and Sumitomo, where the extraction costs are at or below world’s best practice levels.7 Because the top-down part of the design of this mine was limited and easy to explain, it will be used as an example in chapter 7, and will be referred to simply as “the Mine.” In advocating that money be used as a unit of measure, it needs to be emphasized that within the process of engineering there is no diference in principle between the use of money as a measure and the use of any physical measure, such as mass, and the choice of currency, for example, dollar or mark, is equivalent to the choice of mass unit, for example, kilogram or pound. However, in practice there are, of

30 n

Designing Complex Systems

course, signiicant diferences arising out of both issues relating to a currency as a unit of measure, such as a lack of time invariance (inlation) and lack of a ixed ratio between currencies, both of which are easily handled, and the subjective character of money as a measure, which is quite diicult to handle. We shall return to the practical diiculties associated with assigning a cost to a functional requirement in chapter 3. Why, then, is it so important to assign a monetary value to a service? Are not other parameters, such as human dignity and quality of life, more appropriate in certain circumstances? here is no argument about the importance of these and other parameters of a service; they have emerged as essential concepts in the discussion and assessment of broad aspects of our existence. But, besides the fact that some of these parameters are qualitative in nature, they are all limited in their applicability to a speciic context. hat is, not only the value of the parameter will vary from case to case, but the very meaning of the measure by which a value is assigned to the parameter will depend on the particular context in which the parameter is applied. If we want to develop a generally valid design methodology, the quantities with which the methodology operates must be given in terms of a context-free measure. Any theory of physical objects operates on quantities with measures deined in terms of the three basic measures for time, distance, and mass (i.e., the second, the meter, and the kilogram); in our present case, the composition of the basic set shows that we need a measure for cost and value. he only generally accepted context-free measure of these two quantities is money.

2.6

The Dynamics of the Design Process

he preceding discussion of the design process and the importance of the stakeholders and their requirements at the start of the process may have given the impression that the process is a linear one, progressing in an immutable sequence of steps based on ixed requirements. If so, that needs to be emphatically corrected at this point; indeed, if it were the case, the methodology being developed would be of limited value. he complexity the methodology is intended to handle arises mainly because of the changes to what might be termed the boundary conditions of the project over time, both during the design and throughout the lifetime of the project. he two main sources of change are the stakeholder requirements on the one hand, and, on the other hand, the developments taking place in the technology available to meet those requirements. he latter are, in general, beyond any control of the engineer in the types of project considered here (i.e., mainly infrastructure in the widest sense), whereas the stability of the stakeholder requirements can be inluenced by a component of project management called stakeholder management (sometimes also called “managing stakeholder expectations,” although this is a somewhat more restricted and, to some extent, negative view of the matter). Stakeholder management has received a great deal of attention in the last decade,8 often in

The Purpose of Design

n

31

conjunction with customer relationship management (CRM) and/or quality management. Much of the literature is focused on corporations rather than on projects, but the basics and the principles are the same in both cases. It is not our purpose to go into this subject matter as such, what is important for us is to recognize that design is strongly inluenced by the changes to the stakeholder requirements and that the manner in which the design process handles these changes is a signiicant factor in the success (or otherwise) of the project. Combining the available technology and the stakeholder requirements under the concept of boundary conditions, there are several aspects to the issue of changes to these conditions. First, there is the dynamics of the interaction between boundary conditions and design, and in view of what was said earlier in this chapter, we can conceptualize this in terms of the dynamics of the change in the ROI, Q, in the following manner: Starting out with an optimized design (but at a very high level) with an ROI value of Q*0, then, if no account is taken of the changing boundary conditions as the design progresses into more detail, two changes take place. On the one hand, the value of Q will decrease due to the fact that the original requirements are not seen as so important by the stakeholders any more. On the other hand, the value of the optimal value of the ROI, Q*, will increase due to the possibility of taking advantage of new technology and the possibility of achieving additional value by meeting the new requirements. he result is a widening gap, ∆Q(t), between the ROI of the design and the optimal ROI value, as illustrated in Figure 2.6. his igure shows two critical times. he irst, t1, is the time at which ∆Q has become so large that a decision is taken to abandon the present design and start over again; the second, t2, is the time at which the ROI has fallen below the inancially viable value, and the project is either abandoned or restarted in a diferent form. Which one of these comes irst depends on the particular project and, of course, they may never occur, because what is missing from Figure 2.6 is the time scale in terms of the project stages. If the engineered object has been constructed and gone Q* ∆Qmax

Q*0

Q

Qmin

0

t1

t2

t

Figure 2.6 The actual, Q, and possible optimal, Q*, values of ROI, as functions of time for a project in which the design takes no account of changing boundary conditions.

32

n Designing Complex Systems

into operation before these points occur, then t1 becomes irrelevant and t2 the point at which a decision has to be taken whether to refurbish or shut down operations. However, any professionally led design process would not let the situation depicted above develop without taking any action; it would both respond to changing boundary conditions during design (and, to the extent possible, during construction) and endeavor to predict and take into account future changes. he extent to which this is done varies widely, and one reason for a less-than-adequate treatment in many cases is the cost and time of doing so. hat is, the efort required to do this by starting from scratch on a project-by-project basis is seen as detracting more from the “core” design efort and its completion time than it is worth. Another reason is that, as also illustrated in Figure 2.6, the changes to the boundary conditions usually change gradually, in many small steps, so that it is easy to dismiss each one with the argument that its efect on the project is too small to bother with, and by the time the accumulated efect becomes apparent, it is judged to be too late and disruptive to do anything about it except perhaps a quick, knee-jerk reaction, which often only makes matters worse. hat is why the proposed design methodology emphasizes the importance of building a model of the project, in the form of a system of functional elements, from the very beginning, and then continually expanding and reining this as the design progresses, so that we are at all times able to make an accurate assessment of any change to the boundary conditions.

Notes 1. No publication by the inventor of TRIZ, Genrich S. Altshuller, is known to the author, but a translation, by L. Shulyak, of a book by his son, Henry Altshuller, is available as he art of inventing (and suddenly the inventor appeared), Technical Innovation Center, Worcester, MA, 1994. he main promoter of TRIZ is Ideation International (www. ideationtriz.com), and a good introduction is available online at www.mazur.net/triz. 2. Aslaksen, E.W., he changing nature of engineering, McGraw-Hill Australia, 1996, ch. 7. 3. Hitchins, D.R., Systems engineering: A 21st century systems methodology, John Wiley & Sons, New York, 2007. 4. Kant, I., Kritik der reinen Vernunft, 2nd ed, 1787. A later complete reprint is that published by h. Knaur Nachf., Berlin, and the standard English translation is that by N. Kemp-Smith, Macmillan Press Ltd, which can also be found on line at http:// humanum.arts.cuhk.edu.hk/Philosophy/Kant/cpr/. A very good discussion of Kant’s ideas is given by R.P. Wolf, Kant’s theory of mental activity, Peter Smith, Gloucester, MA, 1970. 5. Danielmeyer, H.G., he industrial society, reported at the Portland Int’l Conf. on the Management of Engineering and Technology, Portland, WA, USA, July 1997; published in European Review, October 1997. 6. Aslaksen, E.W., he changing nature of engineering, McGraw-Hill Australia, 1996, ch. 13.

The Purpose of Design

n

33

7. he design is described in Tota, E.W., and Aslaksen, E.W. Implementing a high-technology mining strategy at Northparkes Mines, Conference on Robotics & Automation in Mining, Sydney, 4–5 September 1995 (AIC Conferences), and the successful operation of the mine is described in Aslaksen, E.W., Award-winning Northparkes Mine, What’s New in Process Engineering, February 1999. 8. Two recent books on stakeholder management (albeit from a corporate standpoint) are Post, J.E., and Preston, L.E., Redeining the corporation, Stanford University Press, 2002, and Huber, M., and Pallas, M., Customizing stakeholder management strategies, SpringerVerlag, Heidelberg, 2006. his latter book discusses the close connection between stakeholder management and such quality management processes as Six Sigma. An interesting publication, which emphasizes the fact that diferent stakeholders view success and failure quite diferently, is Hart, D., and Warne, L., Roles apart or bedfellows? Reconceptualising information systems success and failure, Information Systems Foundations Workshop, 2006, available online at: http://epress.anu.edu.au/infosystems02/mobile_devices/ch08.html. A view from the defense industry is presented in Bullard, S.G., A qualitative assessment and analysis of stakeholder expectations, Master’s hesis, Naval Postgraduate School, 2003, available online at: www.stormingmedia.us/35/3558/A355814.html

Chapter 3

The Design Methodology

3.1

Outline

Design in the functional domain starts with a set of stakeholder requirements and ends with a set of interacting functional elements, such that 1. the collective behavior of the elements satisies the requirements, 2. the choice of elements allows an eicient transition into the physical domain (physical realizability), and 3. the most cost-efective (physical) solution is among the set of solutions corresponding to the set of elements. From this rough description we can discern a number of the characteristics of the design process and some important issues that must arise in developing a methodology: Intellectual content of the process. he development of the functional requirements into a set of interacting functional elements is not a simple process of dividing up the requirements in the sense of dividing up a cake into pieces such that no matter what size or shape the pieces are, they always add up to the whole. To each possible partitioning, that is, choice of interacting elements, there is a corresponding set of physical systems that is a subset of the set of systems corresponding to the stakeholder requirements, and there is a considerable intellectual efort involved in inding that choice which results in the smallest subset still containing the most cost-efective solution. his efect of choosing a partitioning is illustrated in Figure 3.1. 35

36 n

Designing Complex Systems

B

A

C e

v w X

Y

Figure 3.1 The effect of choosing a particular partitioning, illustrated by a good (V) and a poor (W) choice. On the left is the space of all sets of requirements, A, in the middle is the functional domain, B, and on the right is the physical domain, C. X is the set of all functional systems that satisfy the set of requirements, and Y is the set of all physical systems that satisfy the requirements. The most cost-effective solution is denoted by e.

he use of functional elements. he design process is a manipulation of functional elements; they are the conceptual entities that our minds can conveniently grasp as forming single functional units, and they are the design elements in the same sense that capacitors, inductors, and resistors are the design elements of passive circuits and in the same sense that numbers are the elements of arithmetic. Consequently, the methodology must contain both rules for developing (or choosing) functional elements in a particular case, and the rules and techniques for manipulating functional elements. Top-down process. he purpose of the functional design process is to reduce the complexity of the initial set of requirements, which may consist of hundreds of individual functional parameters, by representing it in terms of a set of interacting functional elements. In order for this process to stay within the complexity of single functional elements, it must start out by deining a single functional element that represents the set of requirements, but to a very high level of abstraction (or, conversely, to a very low level of detail), and then, in a step-wise, top-down process, partition each element on one level into a small number of elements on the next level down that describe the same functionality in more detail, until all the detail in the set of requirements is represented. his immediately identiies an essential feature of the methodology; it must contain the means of determining the correct interactions between the elements, such that the functionality of the original element is preserved. he ability to handle cost. It is not suicient to ind a possible solution; out of all the possible solutions the methodology should identify the most cost-efective. his means that the methodology, even though it operates in the functional domain, must be able to include cost as a design parameter.

The Design Methodology

n

37

Eiciency. After the end of the functional design process comes the transition into the physical domain and the classical design, which then allows the system to be produced. Again, even though the methodology operates in the functional domain, it must ensure that the subsequent bottom-up design is as simple as possible. he top-down approach is an essential feature; each design project must start with the irreducible element and the basic set of variables, and then develop that element into a system of elements in a stepwise process that limits the size of each step such that both the identiication of the possible options for further partitioning as well as the veriication of the chosen option can be performed eiciently. From this, then, emerges an outline of a design methodology consisting of the following steps: 1. Determine a description of the irreducible element that is appropriate to the project. In particular, this means deciding on an expression for the quality of service, S, in terms of parameters relevant to the functionality of the object to be designed. 2. Determine cost and revenue (value) as functions of S. 3. Carry out an initial estimate of a set of parameter values, called an operating point, and an acceptable range for each parameter. (here may, of course, be no operating point that meets all the requirements, in which case one needs to go back to the stakeholders to see if the requirements can be modiied.) 4. Investigate the extent to which these parameter values determine system features (architecture, technology, etc., as appropriate to the level of detail), and use this to determine how to expand (subdivide) the parameters to increase the level of detail. 5. Regroup the new parameters into new functional elements. 6. Determine functions between the parameters within each element and the interactions between the elements such that the original functions are preserved and the ROI remains optimized. 7. Repeat (4), (5), (6) until all the requirements are covered by parameters. he repetitive subprocess consisting of steps (4), (5), (6) is called the basic design process (BDP), which we shall examine in more detail at the end of this chapter. And we remind ourselves again that, as was pointed out at the end of the last chapter, although one could get the impression that this subprocess is applied in a linear, ever-advancing fashion, the dynamic nature of what we called the project boundary conditions will require us to go back, reassess previous decisions, and possibly set out in a new direction several times during a project. Buried in this outline are a number of diiculties that will have to be overcome in order to make the methodology practical. For example, “decide on an expression for the quality of service” is easily said, but how should we go about actually doing it? Is there a unique solution? If not, how do we measure what is the “best” solution? And similar diiculties arise in carrying out the other steps in the above outline of the methodology. Each step will be addressed in the following sections

38 n Designing Complex Systems

of this chapter, but before doing so, it is worthwhile emphasizing an issue that arises again and again when discussing the concept of design in the functional domain. Just as in the physical domain, design remains a creative activity, and no matter how much we support this activity and improve its eiciency through a rigorous foundation and a program of standardization for the elements, the process retains a signiicant demand for human input in the form of what we term intuition, lair, insight, imagination, and so on. In particular, the choices involved in partitioning a set of requirements into a set of interacting functional elements will depend on the individual designer, and some designers will consistently come up with better designs than others. (And we have already agreed on what “better” means here.) It is perhaps tempting to imagine that we could try out all possible choices, much in the same way that a chess program tries out all possible moves, but while in chess the possible moves are strictly limited by the rules of the game, in partitioning a set of requirements there is no limitation on the number of possibilities, because the interactions between the elements can be arbitrarily complex.

3.2

Defining Quality of Service

he quality of service (QoS) expresses both the purpose and the performance of a system in a single parameter; the deinition of the QoS in terms of the functional parameters describes the purpose, and the value assigned to the QoS is a measure of the level of performance of the system. But as a requirements deinition document for a complex system may contain hundreds of functional parameters, deciding on an initial deinition of the QoS in terms of a few parameters may appear a daunting task. In practice, this turns out not to be the case, and there are a couple of reasons for this. First of all, in the current context of ROI, the stakeholder requirements fall into two broad classes: a. hose that are efectively characterized by a single binary parameter (present or not present, true or false), in that they need to be satisied in order for the stakeholders to consider a system an acceptable solution. hey may arise directly from the stakeholders or from standards, statutory requirements (e.g., safety-related parameters), and common practice. A typical example would be the requirement “he state (open or closed) of all doors shall be indicated to the operator.” b. hose requirements where the designer has a real choice, where there is a possible trade-of between value and cost of this requirement, that is, where a value function has been identiied. his may also include requirements on functionality introduced by the designer as part of the requirements analysis process (see chapter 4). Only parameters in the last class are of interest for the purpose of deining a QoS.

The Design Methodology

n

39

In connection with the above classiication, we need to realize that the word “value” has two diferent meanings and that this can easily lead to confusion. On the one hand, “the parameter value” or “the value of the parameter” can mean its numerical value measured in its own units, such as meters for a length, or per unit time for a failure rate. On the other hand, this same wording can mean the value, measured in dollars, attached to a parameter in the form of a value function. We also note that it is a feature of the dynamics of the project boundary conditions that functional parameters may move between (a) and (b) above; this is part of the complexity that the design process should be able to handle. he second reason is that most engineered objects have a main purpose, as was already mentioned in chapter 2, and if the parameters in class (b) above are ordered according to their inluence on this purpose, it is generally true that a few stand out as being very signiicant, whereas the rest are of decidedly lesser signiicance. For example, if the purpose is to provide education or training of some form, the two signiicant parameters might be the number of students taking the course and the average grade achieved. In the case of the Mine, the purpose is to deliver a certain yearly tonnage of ore, and the two signiicant parameters are the nominal production rate and the availability. However, the role of experience in choosing a useful and signiicant deinition of the QoS should not be underestimated—not only the engineers’ experience, but also that of the stakeholders, and this again shows the importance of the close interaction between engineers and stakeholders and the role this plays in the dynamic evolution of the stakeholder requirements. But important as this stakeholder management is, it is one of the many activities in an engineering project that sit under the general umbrella of “project management.” Our concern in this book is with another activity, design, and in that activity, the stakeholder requirements are seen as part of the environment in which design takes place; in particular, that part of the environment we have called the project boundary conditions, consisting of the stakeholder requirements and the available technology. here are many other components of this environment, such as the skill level and morale of the design team, just to mention two, that have to be the concern of the engineers, but they are not considered in the present context. he sole purpose of the methodology put forward in this book is to improve the eiciency and efectiveness with which the complexity introduced by the greatly increased number of requirements, their interactions, and dynamic nature in any of today’s engineering projects is handled by the design process. Having chosen the relevant functional parameters, we are still faced with combining them to form a single parameter, the QoS. Again, with some knowledge of the industry in which the project is embedded, this is not usually a problem, and a few simple rules provide guidance. First, the QoS should represent the performance in an intuitive fashion, so that an increase in the value of the QoS is an increase in performance, and the magnitude of the increase in QoS should bear a simple relation to the magnitude of the increase in performance (the relationship

40 n

Designing Complex Systems

does not necessarily have to be linear). Second, the QoS should be a single-valued function of its deining parameters. And third, even though the parameter values might in practice only vary over a limited range, the QoS should show a reasonable behavior for limiting values of the parameters. For example, in the case of the Mine, if either the nominal capacity or the availability go to zero, the QoS should go to zero, so that the combination is that of a product rather than a sum of the two parameters. We recognize that expressing the performance of a possibly very complex system by a single parameter is a great simpliication, and that the purpose of doing so is simply as part of creating a starting point for the top-down design process by making the irreducible element speciic to a particular project. As the design progresses, the QoS will be expressed in terms of more and more parameters, and in the end by all the parameters in the class (b) above. Two further examples illustrate this approach. he irst is the well-known public switched telephone network (PSTN, also known as POTS, plain old telephone system). At the highest level, that is, at the beginning of the design process, the purpose of a telephone system, which is to connect subscribers, can be characterized by a single parameter, which is therefore also called the QoS, and deined as the probability of making a connection on the irst try, assuming the called subscriber is not busy. he value of this parameter is the one over which the system designer has the greatest inluence and which is most signiicant in the early design decisions (network topology, trunk capacities, etc.). here are a number of other parameters that are very important to the users, such as intelligibility, to take just one, but international design standards ensure that the value of these parameters stay within relatively narrow bounds. hen there are a number of features that contribute to the overall quality of the service, such as pulse or tone dialing, the availability of call waiting, caller identiication, etc. And, inally, there are the parameters that are essentially given and that the designer has no inluence over, such as the number of subscribers and their geographic distribution. he second example is an air defense system.1 At the highest level, the service provided by such a system could be deined as “ensuring that all enemy aircraft entering the country’s airspace are destroyed before they reach the country,” and the QoS could then be deined as the probability of meeting this requirement. his deinition would be adequate for the high-level optimization implied by the irreducible element, but in order to make the concept precise and measurable, it needs to be deined in terms of more detailed parameters. For example, the QoS could be expressed as the product of the probability of detecting enemy aircraft and the probability of destroying a detected aircraft; the probability of detecting enemy aircraft would depend on detecting any aircraft and determining whether an aircraft is a friend or foe; and this decomposition can go on to any desired level of detail. hen there would be a number of parameters deining the meteorological conditions under which the system is to operate, parameters deining the characteristics of the aircraft to be detected (i.e., the scattering cross section), and so on.

The Design Methodology

n

41

his second example can be used to illustrate an important issue in system design — the degree of detail in the user requirements versus the deiniteness or completeness of the user requirements. A requirement can be completely unambiguous and deinite without being detailed; it just means that the user does not care about the details. he above deinition of the service is not quite deinite; the word “all” is open to interpretation. Does it mean “all existing aircraft,” or “all aircraft known to the designer,” or “all existing and future aircraft” (in which case, how far into the future?)? If we decide on “all existing aircraft,” then this makes the requirement quite deinite, but not very practical, as it puts the onus on the designers to ind out about all existing aircraft, which would require them to have a sizable intelligence organization at their disposal. To make the requirement more useful to the designers, it needs to be more detailed.

3.3

Determining the Value of a Service

From the brief discussion in chapter 2, the concept of the value of a service is obviously very closely coupled to that of the QoS. Why have both? he QoS, deined above, and its reinement into a set of functional parameters, is characteristic of a class or type of system. It is a characteristic of the service provided by the entity that will satisfy the stakeholder requirements; it is a characteristic of the solution to the design problem. Value, and its reinement into components (in the same way as cost is reined into components), is a characteristic of the stakeholder group and its requirements, that is, of the environment, or market, in which the system operates. And while value and QoS are linked, it is precisely the task of determining the efect of that linkage that is an essential part of the design process. If the value associated with the service is not deined explicitly in the requirements deinition document in terms of the functional parameters belonging to the class (b) in the previous section, we could, in principle, ind out what the stakeholder group is willing to pay for a service, and deine this as its value, but in practice there are a number of well-known reasons why this is not a straightforward and unambiguous procedure. First, price is determined not only by the stakeholders, but also by the other suppliers, that is, by the competition. Second, in the case where the service has a social component, the price may be determined by legislation rather than by the stakeholders. hird, the perceived value of a service can be inluenced by advertising. Fourth, the price obtainable for a service may be highly time-dependent, so that the value determined prior to design is quite diferent from the price actually obtained when the service is available. Fifth, stakeholders may not be willing to disclose the true value they place on a service (or feature of a service) for fear of alerting the competition. And inally, even disregarding all these diiculties, determining what value stakeholders put on a particular feature of a service may be very diicult, as is illustrated by the case of trying to determine what value travelers

42 n

Designing Complex Systems

put on air safety. How much more would they be willing to pay for their tickets if the probability of a fatal accident could be reduced by a factor of two? However, while these issues may make it more diicult to specify the value of a service, they do not make it any less imperative to do so. Every requirement in the user requirements must have been put there by at least one of the stakeholders, so this stakeholder (or group of stakeholders) should be able to give an indication of why this requirement had to be included and what the value of fulilling it is, and there are many diferent, well-documented approaches to determining what value a user group assigns to a service.2 As far as our current concern with deining the irreducible element, we shall assume an expression for value of the form m

W = W0

∏ 1

   1 + c  xi −1  i 0    xi 

(3.1)

Here xi is one of the m parameters used to deine the QoS, xi0 is its nominal value, W0 is the nominal value of the service, and ci is a measure of the importance the stakeholder group assigns to the i-th service parameter. he reason for making this (simplifying) assumption is to be found in the S-shape of the function expressing the dependence of value on any one single parameter, as shown in Figure 2.3. he signiicant variation in value takes place over a limited range of variation of the parameter around its nominal value, and within this range of interest a linear approximation is usually a reasonable one. Consequently, that range has to be speciied for each of the parameters in equation (3.1). Again, as with the QoS, as the design progresses, the deinition of W will depend on more and more of the parameters in the class (b) in the previous section, and the functional dependence may be diferent from the simple one assumed above.

3.4

Assigning Cost to a Functionality

By now, hopefully it is clear how necessary it is to be able to measure cost and value in monetary terms, and we have discussed some of the issues that arise when we attempt to put a monetary value on a service. hat costs should be measured in monetary terms is not controversial, but how can we ascribe a cost to a functionality? Costs are normally associated with particular physical objects and depend on physical characteristics such as material, surface inish, and dimensional tolerance. And to complicate the issue even more, they depend on exchange rates, interest rates, salary and award rates, and so on. Is it sensible to talk about the cost of a concept? Our approach to this issue must be the same as we employ in the physical domain; the costs are always cost estimates based on previous experience, and the

The Design Methodology

n

43

accuracy of the estimates increases with the level of detail of the design. As the accuracy at the start of the physical design process, that is, conceptual design, is typically ±30%, the accuracy at the end of the functional design process should approach this value. However, the accuracy of the absolute values of costs is not always so important; often the accuracy of the relative values of cost components is more important when it comes to optimizing a design, trading of costs in one area against savings in another, and this will be illustrated in the case of the Mine in chapter 7. he cost estimates associated with a functional element in any particular design project will be a matter for the individual designer, and will depend on the designer’s experience, cost data available within the designer’s organization, etc. But once there exists a body of standard functional elements, the parameterization of cost information will be uniform across projects and organizations, and the access to and exchange of cost data will be much improved. he situation is in one way similar to the current situation in the physical domain, where we have catalogs of standard (commercial-of-the-shelf, or COTS) components from which physical objects can be synthesized, and where price lists are available for many of these components. here must be millions of such components, organized by the areas of engineering to which they apply, and the same sort of database would have to be built up for functional elements. But there are two major diferences. First, as we have already remarked, in the functional domain the design process starts from the most general element and proceeds in a top-down fashion to a more detailed description using less general elements, which is the reverse of the process in the physical domain. Consequently, at the start of the process we need the estimate for a single cost parameter, the C in the basic set, but for a vast number of diferent applications. hat is, in the physical domain we have a vast array of components, and each component, such as a metric hex nut, can be used in a vast number of diferent applications, but the cost is tied to the component, not to the application, whereas in the functional domain, we have a single element that can be used in a vast number of applications (in all, actually), but the cost is tied to the application. (he same goes for the other three variables in the basic set, too.) In this context, we note that the cost is dependent on not only the functional parameters in class (b) in section 3.2, but also on those in class (a). However, the latter cost does not (at least, not to a irst approximation) change as the functional design progresses. Second, even when the functional design process is completed and we have arrived at a set of interacting functional elements, there corresponds to each element a whole set of functionally equivalent physical objects, each of which will have a (somewhat) diferent cost. he inal choice of the most cost-efective solution can only be made in the physical domain, usually determined by non-functional user requirements, as will be discussed later (see Figure 4.2). However, if we keep these two diferences in mind, there is no reason why a database of parameter values (including cost) could not be developed, once the parameters themselves are deined in terms of functional elements. he data, which

44

n Designing Complex Systems

simply relect past experience, are, of course, present today; they are just not easily available in a usable form because the applications are parameterized (i.e., described) in so many diferent ways. he use of standardized functional elements would provide a framework into which all the data could be itted and thereby made much more accessible.

3.5

Some Basic Rules for Developing Functional Elements

Because functional elements are the objects on which the mind has to operate if we want to do design in the functional domain, we need to ensure that there is compatibility between the objects and the capability of the mind. Just as production managers utilize the capabilities of their machine tools in order to obtain the greatest productivity, and would not try to produce a shaft using a milling machine, engineering managers must ensure that the objects with which they let their engineers grapple are deined in a manner that makes them suitable for the mind to handle. For example, engineering managers must know what they expect the mind to process and what they expect to be processed by computers, and they must realize that the capabilities of the two are very diferent. In the following, we formulate three rules that are useful in developing functional elements that are convenient for the brain to work with. he irst rule arises from the realization that all functional elements are related. Consider a particular function, such as the function “transport,” that is, to move something from one location in Systems space to another. his can be subdivided into a number of elements, for example, according to what is being transported, such as material goods, electrical power, Transport or information. he latter element can systems be further subdivided according to whether it is point-to-point or broadcast, and so on. It simply illustrates that functional elements are related in a hierCommunications archical structure, with an element on systems a particular level of the structure representing a class of elements on a lower Figure 3.2 An illustration of the hierlevel, as illustrated in Figure 3.2. archy of the classes of systems. (From In particular, following this arguAslaksen, The changing nature of ment to its logical conclusion, it must be engineering, McGraw-Hill, New York, true that all elements in a class inherit 1996, section 10.5.)

The Design Methodology

n

45

the characteristics of the element from which the class was derived (the parent element), in the sense that the functionality of an element in a class is an instant of the functionality of the parent element, and that the class must contain all instances of the parent element. As an example of this, consider the class of elements that have the irreducible element as its parent element. All elements in this class must be instances of how one can obtain a return on investment and, more importantly, there can be no element outside this class that has this functionality. If we want to limit the number of elements in a class to a small number, then we must demonstrate that any system that has the functionality of the parent element can be represented by a set of interacting elements, each one of which belongs to the class. he rule that follows from this is therefore that functional elements must be developed in a top-down fashion, that is, from the general to the more detailed. Every element, except the irreducible element, must belong to a class, that is, must have a parent element, otherwise it is not possible to determine how it contributes to the ultimate purpose of producing a return on investment. hree comments may be made with regard to this rule. First, when we say “developed,” we understand a parent-to-child partitioning. However, the choice of the “children” may very well be made on the basis of common practice or previous experience, which most likely arose in a bottom-up fashion, because what we create are the individual items, and only later do we perceive the similarities and diferences that lead to a structure. Second, if we compare the functional domain with the physical domain, we see that in the former the higher up in the hierarchy the elements are, the greater applicability they have (but also the less powerful they are), whereas in the latter, elements lower down have the greatest applicability (e.g., an M6 hex nut has tremendously wide applicability). his is one illustration of how the two domains may be considered to be conjugate. hird, a very signiicant characteristic of the mind is its ability to form associations; it is much easier to work with an object (model, concept) that relates to other objects already in the mind, that its into our mental framework, so to speak. he above rule ensures that we develop such a framework, rather than a scattering of unrelated models. he second rule is closely related to the irst; it says that the concepts (variables or functional parameters) used to describe functional elements must show a continuous development from higher to lower levels of the hierarchy. he meaning of this rule is best illustrated by taking a particular concept, such as cost. Any project that aims to provide a service will have a cost associated with it, so that the concept of cost can be deined for the functional element that represents all projects. At the next level down, the element is partitioned into two sub-elements, one representing the creation of the object that is to provide the service, and one representing the operation of the object to actually provide the service. With the irst we can associate a non-recurring cost, with the second a recurring cost. At the next level down, the concept of recurring cost can be developed in more detail by deining operating and

46 n

Designing Complex Systems

maintenance costs, and these can again be developed in greater detail by deining further cost elements, and so on. At no level does a cost parameter suddenly appear that has no relationship to any cost parameter deined on a higher level. A corollary to this second rule is that whatever concepts are used to describe the most general functional element (i.e., the element at the top of the hierarchy) must be adequate to encompass all possible functional parameters. Or, in other words, the set of all possible functional parameters can be partitioned into disjoint subsets such that all the parameters in one subset are related to one of the concepts used to describe the most general element, ultimately the irreducible element. he third rule is again tied to the way our brain works — it arises from our desire as engineering managers to design tasks to be ergonomically correct, only in this case we are concerned with the “ergonomics” of the mind rather than of the body. In order for us to be able to think of something as an entity, as a single object, and to manipulate it in our minds, it must not be too complex in the sense of needing a lot of variables to describe it. We ind that once something needs more than about 5–10 variables to describe it, it becomes too diicult to think of as a single entity,3 and we either neglect some of the variables, or split the object up into two entities that can be thought about one at a time. he third rule can therefore be formulated by saying that functional elements should not be more complex than that they can be described by at most ten variables. hese three rules are important guidelines for developing functional elements, but they are not detailed or speciic enough to uniquely deine a consistent set of elements. here are innumerable ways is which diferent sets could be developed, and the choice of a particular set can only be justiied by its usefulness. here may be many diferent sets that can be useful in diferent circumstances, but in any case the usefulness comes to a large extent from being able to utilize a set of standardized elements — elements that have already been developed and that it together to form complete classes, and that are immediately recognized and understood by other people. If you were the only person in the world using metric thread, your metric hex nut would not be very useful, and similarly, the whole idea of design in the functional domain rests on our ability to develop standardized sets of functional elements.

3.6

Applying Functional Elements in Top-Down Design

In the outline of the design process given in section 3.1, the wording was in terms of a development process in order to demonstrate how the design progresses. From the above, we now know that the process has to be much more a case of selecting functional elements from an existing set rather than developing them for each application. So, assuming that we have a large collection of functional elements at

The Design Methodology

n

47

our disposal, how do we go about picking the most appropriate ones? Well, the situation is not so diferent from two well-known ones from other ields of engineering. he irst is to select a suitable complete orthonormal set of functions in which to expand the functions involved in a particular problem. We pick a set of coordinates that suits the geometry of the situation, and then the orthonormal set of functions on these coordinates that best its the boundary conditions. he second is the choice of components for an electronic circuit. We irst look at the environmental conditions, such as temperature and acceleration, to see if we need MIL-spec components, then we look at cost and design life to select the most appropriate encapsulation of components, power consumption limitations to select the technology, and inally, within the appropriate family of components, those with the right functionality and performance. Only if no suitable ones could be found would we consider designing our own, and then only for large production quantities. Selecting the most appropriate set of functional elements is essentially the same as choosing the best partitioning of the functional user requirements, and the approach advocated here (to be developed somewhat further in chapter 7) is based on the assertion that any functionality (or more correctly, service, as will be explained in chapter 4) can be expressed in terms of three types of functional elements: 1. transport elements 2. storage elements 3. transformation elements he irst step in the selection process is therefore to determine which of these three types of functionality are involved in meeting the user requirements, and to group the user requirements into groups relating to each type of functionality. For certain parameters, such as reliability, this may entail subdividing the original requirement. If only one type is involved, we look within the subdivision of this type to see which main subtypes are involved. Having now partitioned the user requirements into a small number of groups of requirements, say, three to ten, each group can be considered as expressing the requirements of the performance of a physical object, for which an irreducible element can be found. However, these irreducible elements are not independent; by virtue of their derivation from a common element, there are relations between some or all of their parameters; they form a system of functional elements. A word of caution is appropriate regarding the use of the word “irreducible” for the elements representing these system components. By deinition, every physical object will have an irreducible element associated with it; indeed, there is only one such element that is common to all physical objects — the element representing ROI. But in order to evaluate the ROI for a particular object, we need the value function, and there is in general no simple or explicit relationship between the value of the service provided by the components in a system and the value provided by the system. he whole value of the service provided by the system may relate to an

48 n

Designing Complex Systems

emergent property of the system, one that is not present in any of the components. herefore, in the case of the components, the irreducible element is not of interest in order to evaluate the ROI, but in order to provide a point of departure for expanding the set of parameters describing the functionality of the component. However, in addition to the user requirements that relate directly to what the system is supposed to do, there are a number of requirements that describe how well it should do it (e.g., how reliably), what it should cost to do it, and so on, and the functional elements describing these aspects of the functionality must also be subdivided in the partitioning process. But rather than a decomposition into different types of elements, they are decomposed into elements of the same type, but to a greater degree of detail. It can therefore be helpful to consider the partitioning process as two-dimensional; one dimension is the type of functionality, the other is the level of detail, and the process alternates between the two. Starting with the irreducible element for the whole, we increase the level of detail by including more and more parameters. hen we split this more complicated element into a small number of elements, each with fewer parameters. hen we expand the level of detail of each of these elements, then split each into a set of smaller elements, and so on. he theoretical foundations of this process, and the nature and deinition of the two types of elements involved, are presented in chapter 4, but it is clearly an iterative process, with each iteration consisting of an expansion in the level of detail followed by a splitting, but with interactions between the new elements such that the overall functionality of the original element is preserved. his is the basic design process introduced earlier and discussed in the next section.

3.7

The Basic Design Process

he basic design process (BDP) was described in detail in he Changing Nature of Engineering,4 and shall therefore just be summarized here. he process starts out with a given functional element, that is, a description of either the functionality of some physical object or some aspect of such functionality; in either case the description involves a number of variables and the relationships between them. Of these variables, a number are involved in describing what the element does (as opposed to how well it does it), what we might call the purpose of the element, and the irst step in the BDP is to express this purpose as being achieved through a combination of two or more functions by a process of analysis. For example, in the air defense system introduced in section 3.2, the purpose of detection can be subdivided into the production of radiation of a suitable kind, the transport of this radiation to the target, the transformation process that takes place at the target (i.e., the scattering process), the transport of the scattered radiation back to a receiver, and the conversion of the received radiation into an electric signal. Each of these functions can be looked upon as the purpose of a separate functional element, and the description of this element can then be completed by adding further variables to describe how

The Design Methodology

n

49

and how well this function is achieved, and functions between these variables to express the behavior of the element. However, these new elements are not independent; they interact by virtue of the fact that there are relationships between some of their variables. For example, each element will be characterized by reliability, but the sum of the failure rates of the elements must add up to the failure rate of the original detection element. he second step in the BDP is to optimize the values of the variables, which generally means an allocation of a total value of a variable in the original element (e.g., failure rate) to the same variable in the individual elements or a trade-of between two diferent sets of variables, such as performance and cost. In either case we have an expression for a quantity that is to be optimized, such as cost-efectiveness, and we are faced with the familiar problem of determining the maximum or minimum of a function of several variables. he third and inal step in the BDP is to verify that the overall performance of the system of elements is identical to the performance of the element we started out with. We might expect that the optimization process in the previous step would guarantee this, and in simple cases that will be true, but in general the behavior of a set of elements (and of the original element) is much more complex than what can be expressed by fulilling a single optimization criterion. Above all, the optimization usually relates only to the static functionality of the elements, whereas the representation of an element in terms of a system is often required to include both explicit time dependence (e.g., as in decay or wear) and the response to timedependent external inluences. herefore, we need to synthesize the original element from the set of elements by prescribing interactions between the elements, and then testing that this synthesized element behaves identically to the original one. he BDP is illustrated in Figure 3.3, and while the main features of this threestep process are relatively easy to understand, we also recognize that the above description has glossed over some of the details and problems, both conceptual and practical. But before we can make any further progress in detailing the methodology, we need to deine and understand the properties of the functional domain in Inputs and outputs Synthesize

Analyze

Optimize

Elements

Figure 3.3

The basic design process.

50

n Designing Complex Systems

much more detail, and that is the purpose of the next three chapters. At the end of chapter 6 we shall then return to the BDP and address much of the detail missing above.

Notes 1. Aslaksen, E.W., and Belcher, W.R. Systems engineering, Prentice Hall, Englewood Hills, NJ, 1992. 2. Aslaksen, E.W., he changing nature of engineering, McGraw-Hill, New York, 1996, section 10.5. 3. he seminal work in this area is a paper by G.A. Miller, he magical number seven, plus or minus two: Some limits on our capacity for processing information, he Psychological Review, 63, 81-97, 1956, available online at www.well.com/user/smalin/ miller.html. References to subsequent papers can be found at http://citeseer.nj.nec. com/context. A very simple model of short-term memory, demonstrating why the brain might ind it more eicient to work with smaller (but interacting) chunks, is contained in Aslaksen, E.W., he changing nature of engineering, section 3.2. 4. Aslaksen, E.W., he changing nature of engineering, section 2.4.

Chapter 4

Functional Elements and the Functional Domain

4.1

Functional Elements

As we discussed in section 1.3, to each physical object there correspond two basically diferent descriptions — the description of what the object is (its physical substance), and the description of what the object does (its functionality). he former consists of such data as size, shape, material speciication, surface inish, etc., presented in the form of drawings, schedules, etc., and is what is needed by someone who wishes to reproduce (manufacture) the object. he latter consists of a set of performance speciications, in the form of mathematical functions, graphics, or tables, and is, for example, what is needed by stakeholders to determine if the object will meet their requirements. Both descriptions refer to the same entity — the physical object, and while we shall develop a theoretical framework in which it is possible to operate without any knowledge of this object, the development uses the fact that there is an underlying physical reality in several places. Consequently, our irst step must be to deine what we mean by a physical object. Deinition 4.1: A physical object is an entity consisting of one or more inseparable material parts, all connected together by deinite physical relationships.

51

52 n

Designing Complex Systems

he deinite physical relationship may be that part A is bolted on to part B, or that part A is screwed onto part B, or that part A rotates within part B, or even that part A just sits in a particular position on top of part B, and so on. It follows that if two or more objects are connected together by deinite relationships, they form a new object, but if there are no relationships between them, they form simply a collection of objects. Deinition 4.2: he physical domain is the set of all physical descriptions of physical objects. In the case of physical descriptions, there is no limit to how many parameters we can use to describe a particular object; it just depends on the level of detail we want to go to. In principle we could give the type, position, and state of every atom in the object, but in practice just a few parameters describing shape and material are often adequate. he completeness of a physical description is therefore not an absolute characteristic of the object alone; it is deined only relative to a particular application. Deinition 4.3: A physical description is complete if it contains all the information required to reproduce the physical object in every detail required by its application. Before leaving the physical description of an object, we note that the very important aspect of safety of the object, in the sense of safety in design, is essentially a condition on its physical design, not on its functionality. he analysis required, such as Hazop, requires the functionality as an input, but the requirements resulting from the analysis are always requirements of the physical design, such as handrails on platforms, guards over moving parts, lifting devices, showers, etc. A physical object (or system) meets the stakeholder requirements by interacting with its operating environment, where the qualiier “operating” has been included only to distinguish it from the more popular meaning of “environment” as the natural environment of a species, in particular humans. he operating environment is, in principle, the complement of the object in the universe, that is, “everything else”; in practice it is, of course, much more restricted and determined (both explicitly and implicitly) by the stakeholder requirements. We now introduce a formal deinition of functionality, and then discuss some implications of this deinition: Deinition 4.4: he functionality of a physical object is its intended capability for interacting with its operating environment. he word “intended” has been included in order to exclude such incidental interactions as a bull becoming enraged by a red sports plane making an emergency landing in its pasture; this is not part of the plane’s functionality. On a more serious note, the word “intended” expresses a very signiicant diference between physical and functional descriptions; every statement in a physical description can be veriied by an examination of the physical object, whereas the functionality of

Functional Elements and the Functional Domain

n

53

an object depends on the intention of the designer, which again is determined by the requirements of the stakeholder group. he functionality cannot, in general, be deduced from looking at or performing measurements on an object, and there is not necessarily any functionality inherent in a physical object, that is, disconnected from the intention of its designer. Deducing the functionality of a physical object is, of course, what we call reverse engineering, and its accuracy will depend on what additional information is available. his deinition of functionality is signiicant and not universally accepted; another deinition is that the functionality of a physical object (or system) is what it does. In the author’s opinion, that simply begs the question: For whom? An engineered object provides a service to somebody, so unless one wants to always explicitly link the deinition of functionality with a deinition of that body of people, the only body that is implicitly related to the object is the stakeholder group, that is, the group that formulated the original requirements, against which the object was designed. hat the object can be used by other bodies for quite diferent purposes than originally intended is not a property of the object, but rather of the ingenuity of those bodies. he word “capability” has been included for two reasons. First, the interactions between the object and its operating environment are described in terms of a set of parameters, and to each of these parameters belong two variables, one deining the range or rated value of the parameter, and the other being its actual value. Only the former is a property of the object; the latter is a consequence of the operating environment. An example would be an electrical power plant; its interaction with its operating environment includes supplying electrical power, and one parameter characterizing that supply is power output. here are two variables associated with this parameter; the capacity to supply power (its rating), and the actual power low (generally given as a function of time in the form of a duty cycle). Second, “capability” signiies that the parameters involved in the interaction are related in a particular manner; the interaction takes place in a particular manner. his is the behavior of the object in response to changes in the operating environment. Also, it should be noted already at this point (although it will be discussed comprehensively later) that to a given set of stakeholder requirements there may correspond a number of diferent functional elements, that is, a particular set of stakeholder requirements may be satisied in a number of diferent ways. It follows, then, that the descriptions of functionality are, as far as engineered objects are concerned (and we are, as previously noted, limiting our considerations to these), the primary entities, while physical objects and their descriptions are secondary, arising in response to a demand for a particular functionality. But it is obvious that to a description of functionality there corresponds a number of (generally ininitely many) physical descriptions; consider only the diferent materials and/ or surface inishes that can be used to produce the same functionality. hus, the description of the functionality of a particular physical object deines a whole set of functionally equivalent physical objects in the physical domain. his was already

54

n Designing Complex Systems

implied in Figure 3.1. And the greater the level of detail in the description of functionality, the smaller the set of functionally equivalent objects. A description of functionality will generally require a number of variables and a number of functions deining the relations between these variables in order to fulill the many clauses of a typical requirements deinition document. hese variables and functions can often be grouped according to distinct subsets of the stakeholder requirements, and it is therefore possible to regard a description of functionality as made up of a number of individual parts, each one describing some aspect of the functionality. Examples of aspects are the capability of generating earnings (cost efectiveness), the capability of providing continuity of service (availability), the capability of surviving in a given environment (reliability), and the capacity for producing its service (size or rating). Deinition 4.5: A functional element is a description of one or more aspects of the functionality of a physical object, and consists of a set of variables and a set of functions between them, as well as any values required of the elements of these two sets. Deinition 4.6: he functional domain is the set of all functional elements. With regard to deinition 4.5 and our use of the functional element concept in the following, the fact that the variables and functions take on numerical values and that some or all of these form part of the deinition of a particular functional element will be understood and not mentioned explicitly every time. his is no diferent from what we do in the physical domain; for example, a resistor may be speciied by two parameters, resistance and rated power dissipation, and it is understood that a particular resistor will have speciic values attached to these two parameters. he main reason for introducing the concept of “aspect” is clarity of language, as it would be easy (and quite natural) to think of “functionality” as only the immediate, physical function of an engineered object, such as generate electricity, provide education, etc., which are, perhaps, closest to the interests of most engineers, and to neglect the interests of the wider stakeholder group in what the object does, such as, for example, provide an opportunity to build expertise (technology transfer), support political stability, etc. his is clearly illustrated in terms of the irreducible element. his element was labeled “return on investment” because that was the purpose it was able to express; now we can say that it is labeled “return on investment” because that is the aspect it describes, without necessarily tying it to a particular physical function. Two special types of functional elements, both of which play important roles in the development of the theory, can now be deined. he irst of these arises if we imagine a collection of all those persons who could have any relation whatsoever to this object; this would be the largest stakeholder group possible. he complete description of functionality referred to the corresponding stakeholder requirements

Functional Elements and the Functional Domain

n

55

will be called a maximal functional element, and the following deinition is an equivalent expression of the same concept: Deinition 4.7: A description of the functionality of a physical object is a maximal functional element if it describes all possible interactions of the object with the rest of the world. Of all the possible interactions, only a small fraction will have a signiicant probability of actually occurring in the life-time of the object. hose interactions that the designer intended to occur (in response to the stakeholder requirements) would normally have a probability close to one, but there may also be many other, unintended interactions that have a very small, but non-negligible probability of occurring. It was pointed out by D. Hybertson in reviewing the manuscript for this book that this situation is somewhat analogous to the description of the state of a volume of gas by means of statistical mechanics. Phase space encompasses all possible states of the gas, but the probability of the system trajectory passing through a region corresponding to a macroscopic deviation from equilibrium (e.g., all the gas molecules in one half of the volume) is vanishingly small. However, it is a current trend for the designer to be made responsible for considering a widening range of such unintended interactions, with a decreasing lower limit on their probability, in the design, and for taking appropriate action to ensure that a duty of care is maintained. Clearly, a maximal element is not an element we would ever use in carrying out a design activity; it is a limiting case we can approach more or less closely. he special feature of a maximal element is that it removes all reference to any particular stakeholder group and to any intention of a designer. Quite the opposite is the case with the second type of element — a complete element, the counterpart in the functional domain of a complete description in the physical domain. However, in order to deine completeness for functional elements, we irst need to look more closely at the deinition of a functional element. As deined above, a functional element consists of a set of variables and a set of functions between them. But the set of variables can be divided into subsets that have quite marked diferences, and it is recognizing and understanding these diferences that allow the concept of a functional element to be further developed and made more precise. To this end, we irst have to introduce the concept of the service: Deinition 4.8: he service provided by a physical object is the immediate purpose of its operation, its output to the subset of the stakeholder group usually called the users. Deinition 4.9: Functional parameters are the parameters describing a service. Referring to the deinition of “aspect” and the example of power generation above, the service provided by a power station is the supply of electrical power. Its rating is a functional parameter, whereas the actual value of the power low at any time is a variable characterizing the external demand.

56

n Designing Complex Systems

We note that while a service is always an “output” as far as a functional element is concerned (in the sense of presenting the capability to the user), the functional parameter may actually describe an input to the physical object. As an example, consider a garbage disposal plant (e.g., incinerator). Its functionality is to dispose of garbage; this is the service it provides to the users (the community). It is a functional output, and its capability for disposing of garbage is the associated functional parameter, even though the physical low of garbage is into the plant. Another example is a user command; the signal low is into the equipment, but the equipment has the capability of sensing the user’s command; it provides this capability to the user. he second subset is the one consisting of the additional variables describing interactions required in order to provide the service, such as power, materials, manpower, waste heat to the environment, etc. As all these other variables used to describe the functionality are only there because they are required by the functional parameters to be there, no subdivision into parameters and variables is required, and they may all be called dependencies. hey are all related to the functional parameters through the set of functions that forms part of the deinition of a functional element and describes the behavior of the element. Together with the functions between them, these two sets completely describe the functionality of the element, that is, the intended interactions with the rest of the world, and constitute what we might call the functional variables (or simply variables, when we are considering functionality). However, there is a third subset, consisting of those variables that, while they do not describe intended interactions, describe necessary interactions with the rest of the world. hese are normal (i.e., non-functional) variables, usually describing those characteristics of the environment in which the object operates that afect the values of the functional parameters, such as interest rate, state of technological development, availability of trained manpower, and political stability, just to mention a few that are diferent from those that spring irst to an engineer’s mind, such as temperature and humidity. heir values are given by the environment and cannot be changed by the functional element. (his restriction is in reality only satisied as an approximation, albeit most often a very good one, as any interaction implies the involvement of both parties to the interaction.) he variables in this third subset could be called inluences, and a symbolic representation of a functional element could therefore be as shown in Figure 4.1. his symbol is consistent with the one shown for the irreducible element in Figure 2.2. We can now deine the concept of completeness for functional elements; it is similar to the one deined in relation to the description of physical objects, but with one diference: Deinition 4.10: A functional element is complete if the set of functional parameters is adequate for expressing (or deining) all the functional requirements in a set of stakeholder requirements.

Functional Elements and the Functional Domain

n

57

Influences

Dependencies

Figure 4.1

Functions

Functional Parameters

Suggested symbolic representation of a functional element.

he diference is, of course, that while the deinitions of a physical object and its completeness were both in terms of properties of the object itself, the completeness of a functional element refers to something that exists prior to and independently of any object. his relects our desire, in developing our design methodology, to consider stakeholder requirements as the primary entities; the design process starts with a set of stakeholder requirements and without reference to any speciic physical object at all. It is a manifestation of the abstraction away from the physical domain that is an essential part of the theoretical foundations of the methodology; instead of deining functionality in terms of what any particular physical object does, we want to consider functional elements as descriptions of doing per se and therefore reusable as elements in models of the performance of various systems. he two “worlds” of physical interactions and stakeholder requirements come together in the concept of maximal element: heorem 4.1:

All maximal elements are complete.

Proof: A maximal element describes all interactions with the rest of the world, therefore also with all possible stakeholders, of which any set of stakeholders is a subset. he converse of this theorem is, of course, not true. he irreducible element is complete with respect to the single stakeholder requirement of producing a return on investment; it is the requirement of a stakeholder group consisting of an investor only. his immediately raises the issue of the physical realizability of a functional element. First, as functional elements are products of the mind, one can think of elements that cannot possibly be realized, because they contradict the laws of nature, for example, involving traveling at a speed exceeding that of light. Second, there are the elements that are currently not realizable, but for which there is no fundamental reason why they could not be realized in the future. Clearly, in order for our design methodology to be useful, we would want the elements that result from the functional design to be at least physically realizable, possibly even restricted to a smaller subset of existing objects (e.g., commercially of-the-shelf components). With each maximal element there is associated a set of elements that describe all the aspects of its functionality and all the possible combinations of these; it will be called the maximal set.

58 n

Designing Complex Systems

Deinition 4.11: he maximal set associated with a maximal element consists of all the complete functional elements that are derived from the maximal element by reducing the stakeholder requirements to a subset of the stakeholder requirements associated with the maximal element. his introduces a hierarchical ordering into the maximal set (and into the functional domain, as will be discussed in more detail later), in that an element that can be represented by combining two or more other elements can be said to be larger or more complex than those elements. he operation of adding one functional element, a, to another, b (e.g., adding an aspect to an existing element), will be formally denoted by a ⊕ b; the result is again a functional element. he operator ⊕ may be called the combination operator, and it is deined as follows: Deinition 4.12: Let A and B be two subsets of the stakeholder requirements associated with a maximal element, and let a and b be the corresponding complete functional elements. Let c be the complete functional element corresponding to the set of user requirements C = A ∪ B, then the combination operator, denoted by ⊕, is deined by c = a ⊕ b. he following theorem is self-evident: heorem 4.2:

he maximal set is closed under the combination operator.

he result of applying the combination operator to two elements results in more than just adding the two elements together; it creates a new element through an interaction between the elements. But what interaction? Is there just one possible interaction? he answer to the latter question is “yes,” and the reason is that we are dealing here not with any two functional elements, but only with elements belonging to the same maximal set. he interaction involved in combining two elements is the same interaction between the variables of the two elements as between these variables in the maximal element. If the two elements have variables in common, this duplication disappears in the combined element, and, in particular, a ⊕ a = a. his is not true of interactions between elements from diferent maximal sets, as will be discussed in later chapters; for example, the interaction of identical elements from diferent maximal sets constitutes a very interesting class of systems whose members can have characteristics widely diferent from those of the individual elements. Both types of partitionings, within a maximal element and into maximal elements will be used in our quest to develop the representation of a complex functional element in terms of a number of less complex, but interacting functional elements irst alluded to in section 1.3 and discussed further in section 3.1. Our aim is to develop a whole collection of standard, basic (i.e., of limited complexity) functional elements that gain wide acceptance within the engineering community

Functional Elements and the Functional Domain

n

59

because of their usefulness in the process of designing complex systems, but irst we need to achieve a much better understanding of the nature of such elements. Two comments need to be made with regard to the representation in Figure 4.1. First, the functions are not restricted to such between a dependency and a set of functional parameters, but include also functions between functional parameters only. (However, functions between dependencies only are not included; such functions would always be secondary in the sense of being derived from the functions determining the dependencies in terms of the functional parameters.) Second, interaction between two objects means that some property of the one object causes a change in the other object. his change can be caused either by a change in the irst object (i.e., by the object doing something and actively driving the change in the other object) or by the irst object having a certain property that by itself causes a change in the other object (i.e., the irst object is a passive partner in the interaction). An example of the latter is when the color of an object is intended to have an efect on an observer (the observer being the other object). Relating this grouping of interactions to the stakeholder requirements an object is intended to satisfy, one obtains a picture as shown in Figure 4.2 — some of the stakeholder requirements will be satisied by physical properties of the object, that is, by what the object is, rather than by active interactions, that is, by what the object does. herefore, if functionality is to represent what an object does, it follows that in the deinition of functionality, interaction must be restricted to mean active interaction, in the above sense. he division of the set of variables that describe a functional element into three subsets, as shown in Figure 4.1, arose because of our desire to focus on the user requirements as the point of departure for the design process. In particular, it arose because we allowed a functional element to represent less than the full functionality of a physical object; the functional parameters describe only that part of the functionality of interest to a particular user group. As a corollary, it follows that the variables associated with a maximal element are all functional parameters; the other two subsets are empty. hey only become populated in order to complement a limited set of functional parameters so that together they form a self-consistent description of functionality, in the sense that all the variables required by the set of Physical Object Functionality Stakeholder Requirements Physical Characteristics

Figure 4.2

Meeting stakeholder requirements.

60 n

Designing Complex Systems

functions belonging to the element are present. he functional parameters take on a primary importance in the deinition of a functional element; they describe the service ofered to the users, and all the consequential variables and all the functions are secondary, in the sense of describing how that service is provided. Also, the concept of an aspect of the functionality can now be made precise; it is simply the description of the behavior of a single functional parameter.

4.2

The Functional Domain

he functional domain is the set of all functional elements. What can be said about this set; does it have any structure; can it be subdivided into signiicant subsets, etc.? We have already identiied a class of subsets, the maximal sets, each of which contains all that can be known about the service provided by a given physical object, and within the maximal sets the combination operator introduced a hierarchical ordering. A irst question is then whether such a maximal set contains more than one primary element, or, in other words, is it possible for the description of the functionality of one object to be identical to a part of the description of the functionality of another object? he answer is given by the following theorem: heorem 4.3:

A maximal set contains one and only one maximal element, the one from which the set is derived.

Proof: Assume that the theorem is incorrect, and that a given maximal set contains a maximal element, say, x, in addition to the one from which the set is derived, say, y. Let Y be the set of functional parameters associated with y, and X the set of functional parameters associated with x. hen the functional parameters in X cannot have any linkage (functional relationship) to parameters in the complement of X in Y. But then the parameters in the complement of X in Y must also form a maximal set, so that the original physical object is really a collection of two independent (noninteracting) objects, which is contrary to the deinition of a physical object. hus, the assumption was incorrect, and x cannot be a maximal element. Another way of stating this theorem is to say that if the description of the functionality of a physical object can be separated into two separate parts, then the physical object is also composed of two separate objects. his may seem obvious, but it lies at the core of the systems engineering methodology, because it follows from this theorem that a collection of non-interacting physical objects can never result in any functionality that was not already contained in at least one of the objects. It is only interaction that results in new functionality, the so-called emergent properties, and a further study of this issue (in the next chapter) will lead to an understanding of what is meant by “interactions in the functional domain.” As a corollary to the above we can extend our previous statement about the difference between interactions within a maximal set, as expressed by the combination

Functional Elements and the Functional Domain

n

61

operator, ⊕, and interactions between elements of diferent maximal sets, by the atirst paradoxical statement that combining elements within a maximal set increases the level of detail of the description of the functionality of the corresponding physical object, but does not change the functionality. he intersection of maximal sets contains those aspects common to their maximal elements. In chapter 2 it was suggested that all maximal sets have one element in common, the functionality of return on investment. Any two maximal sets must difer in their maximal elements plus at least one other element; this is just saying that if two physical objects have the same functionality, in the sense that we cannot ind a single aspect that is diferent, they are represented by the same maximal element in the functional domain. It is not so simple to visualize the functional domain and its subsets, but one possible visualization is shown in Figure 4.3. he maximal elements are all points on a closed surface, shown here for convenience as a sphere. he complete elements are points in the interior of the sphere, and the irreducible element is close to the surface of the sphere so as to allow for elements of varying complexity. A maximal set is a “volume” (actually a collection of points) in the interior of the sphere, containing exactly one point on the surface (the maximal element) and at least two points in the interior, the irreducible element plus the element that distinguishes it from other maximal elements. In the picture presented by Figure 4.3, the surface can be considered as the boundary between the functional domain and the physical domain. here is a Primary set

Irreducible element

Complex maximal element

Simple maximal element

Figure 4.3 A graphical representation of the functional domain, with the maximal elements shown as points on the surface of a sphere, the complete elements as points in the interior of the sphere with the irreducible element close to the surface, and a primary set as a “volume” between the surface and the common element.

62

n Designing Complex Systems

mapping between each maximal element and a set of physical objects (those with the same functionality), but there is no direct relationship between elements within the sphere and objects outside it. It is therefore reasonable to start the exploration of the characterization of the functional domain with the maximal elements and their variables, the functional parameters, and then to generalize to all functional elements.

4.3

The Functional Parameter Space

With each functional element there is associated a set of functional parameters. hat is, if one considers the set of all possible functional parameters, the deinition of a functional element deines a mapping between functional elements and subsets in this set, and, in particular, this is true of the maximal elements. Because maximal elements are complete descriptions of functionality (of physical elements), the following deinition is relevant to both the physical and functional domains: Deinition 4.13: he complexity of a maximal functional element is its number of functional parameters. his deinition explains why the irreducible element was placed close to the surface (rather than in the center) of the sphere in Figure 4.3. Note, however, that Figure 4.3 is deceiving in that it implies that there is a limit to complexity (the size of the sphere). hat is, of course, not true, and is easily overcome by realizing that the scale of the igure is undeined; the irreducible element can be placed only an ininitesimal distance away from the surface. But the mapping between primary elements and subsets of functional parameters allows a much more interesting characterization of the structure of the set of maximal elements: Deinition 4.14: Let x and y be two maximal elements, and let X and Y be the corresponding sets of functional parameters. hen the distance between x and y, d(x,y), will be deined by d(x,y) = c(X∪Y) – c(X∩Y), where c(X) is the cardinality of X (the number of parameters in X). In practical terms the distance between two elements is a measure of their dissimilarity; the signiicance of the concept will become apparent in the next section. It is then straightforward to prove the following theorem: heorem 4.4:

he function d(x,y) deines a metric on the set of maximal functional elements.

Functional Elements and the Functional Domain

n

63

Proof: In order for d(x,y) to be a proper measure of distance that deines a metric, it must satisfy the following four conditions:1 1. 2. 3. 4.

d(x,x) = 0 d(x,z) ≤ d(x,y) + d(y,z) d(x,y) = d(y,x) If x ≠ y, then d(x,y) > 0.

Of these, only (2) does not follow directly from the deinition. First note that d(x,z) can also be written as c(X) + c(Z) – 2c(X∩Z). hen, ∆ ≡ d(x,y) + d(y,z) – d(x,z) = 2[c(Y) – c(X∩Y) – c(Y∩Z) + c(X∩Z)]. Let Y = YA ∪ Y B, such that YA ⊆ X∩Z, and Y B ∩ (X∩Z) = ∅, then c(X∩Y) + c(Y∩Z) ≤ 2c(YA) + c(Y B), and ∆ ≥ 2[c(YA) + c(Y B) – 2c(YA) – c(Y B) + c(X∩Z)] = 2[c(X∩Z) – c(YA)] ≥ 0. he above is valid for maximal elements, that is, points on the spherical surface in Figure 4.3. But maximal elements are of little practical use; useful functional elements with a limited number of functional parameters are points in the interior of the sphere. To see that the concepts developed for maximal elements can be generalized to all functional elements, consider any one maximal element and its associated set of variables (which are all functional parameters), X = {x}. According to the methodology in chapter 3, all the parameters in X arise from describing in more and more detail the functional parameters in the basic set (i.e., the two functional parameters S and L required to deine the irreducible element), and with return on investment seen as the central purpose of any project, the partial derivative ∂/∂x(ROI) must be a measure of the importance of the variable x in achieving this purpose. his is illustrated in Figure 4.4, where X is shown as a roughly circular area in the set of all functional variables, with the basic set in its center, and with the importance of the variables decreasing with distance from the basic set. he largest possible area X is that of a maximal element. In this picture, functional elements arise by reducing the set of variables, often by discarding the less important ones or by combining variables, as shown by the set A, but not necessarily. If we are interested in a detailed description of a particular aspect, the set might look something like the one labeled B. hat is, while all functional variables are derived from the basic set, it is not necessary for any member of the basic set to be included in the set of functional

64

n

Designing Complex Systems

X A B

Basic parameters

Importance of parameter

Distance from basic set

Figure 4.4 Declining importance of functional parameters away from the parameters of the basic set. Here X is the set of parameters associated with a maximal element, A are the parameters of a less-detailed description of the same functionality, and B are the parameters associated with a particular aspect of the functionality.

variables associated with a functional element. And while it is true that every complete functional element belongs to at least one maximal element, in the sense of being derived from that primary element by reducing the set of functional parameters, a functional element can also belong to two or more primary elements (the irreducible element belongs to all primary elements). So, we can now generalize the concept of a functional element beyond its being derived from a maximal element in the above manner, and thereby abstract it from its connection with a physical object, by redeining the concept of a functional element: Deinition 4.15: A functional element is a self-consistent description of the relationships between a set of functional variables. his deinition difers from deinition 4.5 in two respects. First, instead of a reference to a physical object, the deinition is wholly in terms of functional variables. hat is, it deines a mapping between certain subsets of the set of all functional variables and the set of all functional elements. Second, it introduces the notion of self-consistency, which was mentioned briely at the end of section 4.1. his arises because all functional variables are derived from the basic set in a top-down process, so that any one variable is linked to one or more other variables through this process. However, it is important to recognize that this “linking” has two completely diferent sides to it. On the one hand, there is the linking that arises through the top-down development of a variable in more detail, such as splitting cost into acquisition cost, operating cost, and maintenance

Functional Elements and the Functional Domain

n

65

cost. Acquisition cost and operating cost are both “linked” to cost in a parent/child relationship that requires the sum of the “children” to equal the parent. he choice of “children” is usually based on normal usage (e.g., accounting practice for cost), and there may be more than one choice (e.g., cost could have been split into recurrent and nonrecurrent cost). his process, subdividing variables into sets of variables that provide a greater level of detail in the description of functionality, will be called the decomposition process, with the converse process being called the condensation process, and we shall demand that the resulting parent/child relationships are uniquely deined by the condensation process. hat is, to any one parameter there corresponds one and only one set of parameters that will allow a condensation to another parameter (e.g., for operating cost this set is maintenance cost and acquisition cost, which allows the condensation to cost). On the other hand, there are the relationships that are inherent in a functional element in order for it to be a description of functionality (or an aspect of functionality). hus, as the set of variables is expanded from the basic set, relationships are created between the new (more detailed) variables. his is illustrated in Figure 4.5, where the rings represent successive levels of detail, and the fact that they are rings rather than disjoint “rays” radiating from the center is supposed to show that the variables within one level of detail are all related. herefore, if we have a stakeholder group that is only interested in a small number of parameters (or even just one), the corresponding functional element will need to include at least the variables to which these parameters are directly linked in order to be self-consistent; these additional variables are, of course, exactly what we have called dependencies in section 4.1. hen, if we want to go into more detail, we can expand the number of parameters considered, and thereby create a larger functional element. hat is, the functional parameters express the stakeholders’ view, and this subdivision into functional parameters and dependencies is what links a functional element to a stakeholder group. Basic set

Decomposition

Condensation

Figure 4.5 Levels of detail and relationships between functional variables. Variables in one ring are at the same level of detail and are related functionally, variables in different rings have a parent/child relationship.

66 n

Designing Complex Systems

At this point in the development it is appropriate to return to a statement made earlier (following the deinition of the maximal set, deinition 4.11) about the relationship between functional elements and the structure this introduces into the functional domain. A complex functional element can be said to include a number of less complex elements in the sense that these elements arise by reducing the number of functional parameters, either in order to achieve a simpliication by condensing subsets of parameters or in order to concentrate on a particular aspect, as discussed above. he condensation process comes to a halt whenever a smallest self-consistent set of variables is reached, and how far inward toward the basic set it can progress depends on the size of the initial set of functional parameters. Using the image of Figure 4.5, the process will only reach the basic set if the initial set includes a complete “ring” of variables, and this leads us to the following deinition: Deinition 4.16: he set of variables associated with a functional element consists of the variables of the element plus the variables that can be reached from them through the process of condensation. he associated set is also subdivided into functional parameters and dependencies; the process of condensation does not mix the two types of variables. Deinition 4.17: he included set of a functional element consists of all those functional elements that are generated by forming self-consistent subsets of the set of variables associated with the element. Recalling the deinition of a functional element (deinition 4.5) as a description of one or more aspects of the functionality of a physical object, the included set is the set of functional elements that describe those same aspects, but at higher levels (i.e., in less detail). As an example, if the aspect were reliability, the included set would be the descriptions corresponding to reliability block diagrams with less and less (larger and larger) blocks.

4.4

Structure of the Functional Domain

We can now extend the deinitions given earlier in the last section to functional elements in general, and in doing so we shall discover that the functional domain is not a simple set of unrelated points, but has a nontrivial structure. he deinition of complexity is straightforward: Deinition 4.18: he complexity of a functional element is equal to its number of functional parameters. his is slightly diferent from the previous deinition in that, for elements in general, the functional parameters make up only part of the variables involved in describing the functionality, whereas for primary elements they encompass all

Functional Elements and the Functional Domain

n

67

variables. he efect is to make the concept of complexity relect the users’ point of view; it relects the number of variables they are exposed to (or are interested in). he concept of distance cannot be generalized quite as easily, and an indication of why this is so can be gained by looking at Figure 4.3. As deined for maximal elements, the concept is conined to the distance between points on the spherical surface. When it comes to points in the interior, we must ask if the distance between two elements whose functional parameter sets are disjoint should be the same whether they belong to the same maximal set or not. Intuitively we would say no, because elements that belong to the same maximal set have something in common that elements belonging to diferent sets do not, and therefore the distance, which measures the diference between elements, should be less in the former case. Again, as with interactions between elements, there appears to be a basic diference between elements within the same maximal set and elements from diferent maximal sets. he outline of an answer to this question emerges if we realize that functional elements fall into two groups; those for which the included set contains the irreducible element, and those for which it does not. he former group includes the maximal elements and all those elements that result from reducing the complexity of maximal elements by condensing the associated set of functional parameters, as described above. To see what the latter group (i.e., all other elements) contains, we recall that the starting point of our design methodology is a set of stakeholder requirements, and that the outcome of our design in the functional domain is a large functional element (or, rather, a system of smaller functional elements, to be further deined in the next chapter) such that when we make the transition into the physical domain, the resulting system will meet all the functional stakeholder requirements. hat is, the functional element is an expression of the necessary and suicient conditions for the physical system to meet the functional stakeholder requirements. Consequently, if the included set of the functional element does not include the irreducible element, there is at least one functional stakeholder requirement that is not determined by the element. So, according to deinition 4.10, we can express this in the form of a theorem: heorem 4.5:

he included set of a complete functional element contains the irreducible element.

Proof: A complete functional element includes all aspects of the functional stakeholder requirements, therefore also the requirement for optimizing the ROI, as expressed by the irreducible element. he converse is, of course, not true; the included set of a functional element can contain the irreducible element without the element being complete. Completeness is not a property of the functional domain alone; it is deined only relative to a set of stakeholder requirements.

68 n

Designing Complex Systems

As was already discussed briely after introducing deinition 4.10, the issue of completeness is related to the issue of physical realizability if we expand the meaning of this concept beyond the immediate one of containing relations that are contrary to the laws of nature to include “realizable as a system that meets the stakeholder requirements.” he situation here is the same as with a set of n variables and n linear equations between them; if we remove one of the equations we have a whole set of solutions (including the one obtained before the equation was removed). We often express this by saying that the (n – 1) equations have no solution, meaning they have no one solution. An example is reliability. On the one hand, a functional element expressing the behavior of reliability (i.e., its relationship to other variables) can be quite general and applicable to any system (or, at least, to a large class of systems), but it cannot, in itself, be realized as a physical object. here is no physical object that has as its purpose reliability; the purpose would always be to do something reliably. On the other hand, remove the aspect of reliability from a functional element, and there would be a large number of physical systems that would correspond to it, but only a small subset that would meet all the stakeholder requirements. We now introduce the following two deinitions: Deinition 4.19: A functional element is a real functional element if and only if its included set contains the irreducible element. Deinition 4.20: A functional element is an imaginary functional element if and only if its included set does not contain the irreducible element. It follows that the functional domain consists of two disjoint parts, the real and the imaginary functional domain; the main signiicance of this will become apparent when we introduce the notion of systems of functional elements in the next chapter. It is now clear that our earlier intuition about the distance concept was not quite correct; it is not so much a question of whether two elements belong to the same maximal set or not, as a question of whether they are both real elements. Between real elements the distance concept is a measure of what we would, in everyday language, consider to be the diference in functionality between the corresponding physical objects, whereas for imaginary elements we can only say that two elements either belong to the same (set of) concept(s) or to diferent ones, but it does not make sense to put a measure on the diference, as long as the elements are unrelated to any physical reality. Consequently, the earlier deinition of distance and the accompanying theorem should be limited to real functional elements and modiied as follows: Deinition 4.21: Let x and y be two real functional elements, and let X and Y be the corresponding sets of associated functional parameters. hen

Functional Elements and the Functional Domain

n

69

the distance between x and y, d(x,y), will be deined by d(x,y) = c(X∪Y) – c(X∩Y). heorem 4.6:

he function d(x,y) deines a metric on the set of real functional elements.

he proof of the theorem remains the same as before. However, despite the above, there is still a diference between real elements belonging to the same maximal set and elements in diferent maximal sets, and it may be helpful to visualize the diference in a modiied, two-dimensional version of Figure 4.3. Consider the real element space to be spanned by a polar coordinate system, with the irreducible element at the origin, as shown in Figure 4.6. he distance from the origin measures the level of detail of an element as measured by the number of functional parameters, the angle (from some arbitrary reference direction) the purpose of the element. hat is, the two elements a and b are describing the same purpose to diferent levels of detail, whereas the two elements a and c describe diferent purposes, but to the same level of detail. Clearly, all elements in any one maximal set lie on a radial line and, furthermore, because the set of parameters associated with a is a subset of the set of parameters associated with b, the distance between a and b is zero, whereas d(a,c) and d(b,c) take on values greater than zero. It follows that the distance between real functional elements that have the same functional parameters is zero, and that leads to the following deinition: Deinition 4.22: If the distance, d(a,b) between two real functional elements a and b is zero, the elements will be said to describe the same type of service. he concept of a service type deines an equivalence relation on the real functional domain; two functional elements are equivalent if they belong to the same b Irreducible element

r φ

a

c

Figure 4.6 Visualization of the distance concept for real elements in a twodimensional functional domain, with r representing the level of detail and ϕ the functionality.

70

n Designing Complex Systems

service type. A service type is a subset of the real functional domain, and the different elements within such a subset represent diferent ways (or quality levels) of delivering the service (e.g., as in the diference in the service delivered by a Suzuki and a Lexus). he type of service is determined by the set of functional parameters; the actual level of service provided in a given case depends on the values these parameters take on in that case, and the detailed behavior of the object can also depend on the relationships between the parameters. Let us summarize our development and understanding of functional elements so far. We developed the concept of a functional element from two points of view, on the one hand as representing the functionality of a physical object, on the other as representing the requirements of a user group, and it is this dual nature that makes functional elements central to our design methodology and its aim of assisting the designer to make the transition from user requirements to physical solution. he irst point of view resulted in such concepts as maximal elements and physical realizability, the second point of view led to the concept of completeness. Both of these views are uniied in the view of a functional element as an abstract entity representing functionality per se, consisting of a set of variables and a set of functions relating them to each other. his view would be devoid of any meaning and usefulness were it not for our axiomatic assertion that all variables are developed from the basic set. his process of decomposing the basic set, which is important in developing functional elements, and its converse, the condensation of variables, which is important in the design methodology, led to the concepts of included set, complexity, and real and imaginary elements. It is apparent that the functional domain has a fairly complex structure, characterized irst of all by the subdivision into two disjoint domains, the real and the imaginary domains. he concepts of complexity and combination operator apply in both domains; the combination of a real and an imaginary element is always a real element. But the concept of distance applies only in the real domain, as does the concept of service type. It makes sense to say that a sequence of real elements converges within a service type to a particular service, but a sequence of imaginary elements does not converge to anything.

4.5

Element States

In the previous section, we regarded the variables, and functional parameters in particular, as points in a set. But in any particular case these parameters take on speciic values, and it is one of the main tasks of the design process to determine their optimal values. By means of value functions, introduced in section 2.5, the users specify their requirements of the service, and for any given representation of this service in terms of a functional element (and in the next section, a set of functional elements) the designer will endeavor to ind an optimal set of values

Functional Elements and the Functional Domain

n

71

for the functional parameters of these elements under the constraint of the value functions. Each parameter can take on values in a range of values that may be discrete, continuous, or a combination of both. he smallest range is that consisting of two discrete values (e.g., 0 and 1, or true and false), the largest is the real line. However, the functional parameters of an element are not all independent; the functions between the variables of an element, and which form part of the deinition of the element, place restrictions on the sets of values that can be delivered by the element, and this is what the users see as part of the behavior or performance of the element. In particular, as was already mentioned toward the end of section 4.1, there can be functions involving only functional parameters, and each such function lowers the number of independent functional parameters by one. However, the concept of independence is not particularly relevant to the set of functional parameters belonging to an element (so long as one parameter is not simply a ixed function of another, for example, multiplied by a factor, squared, etc.), and it is not possible to formulate a general rule as to which functional parameters should be called independent and which ones dependent. his becomes quite obvious if we consider the application of a functional element to a particular design, in which case one or more of the functional parameters might have prescribed, ixed values. If we recall that all functional parameters are derived from the parameters in the basic set (i.e., S and L) through the process of decomposition and, additionally, forming functions of the new parameters, we could perhaps at irst think that decomposing S means describing the nature of the service, that is, what the element does, in more and more detail; the dependent parameters are, in a sense, additional measures of how well the element provides that service. However, a little further thought makes us realize that there is no actual diference between parameters arising from decomposition and those arising from subsequently forming functions of those parameters, because the decomposition process is completely free and only guided by what is useful. In some cases common usage makes certain variables more fundamental than others, but this is not relevant to our current investigations into the theoretical foundations of the top-down design methodology, and we shall simply consider all functional parameters as a set, but with constraints in the form of the stakeholder requirements and the functions deining the element. However, speaking of decomposition, we note that decomposing L means subdividing the lifetime of the element into more and more segments, such as design, implementation, operation, refurbishment, and decommissioning, and as a consequence, each component of S is subdivided into a parameter for each segment of L. In the limit, L is subdivided so inely that the components of S simply become functions of time. hus, a set of parameter values is a complete characterization of a functional element at a particular point in time, and this leads to the following deinition:

72 n Designing Complex Systems

Deinition 4.23: he state of a functional element is a set of parameter values, one for each functional parameter of the element, and the space spanned by the functional parameters is the state space of the element. As an element goes through its lifetime L, the state will pass along a trajectory in state space; the possible trajectories are limited by the constraints.

4.6

Functions on State Space

As we know, the deinition of a functional element will also contain a number of functions of the functional parameters that express stakeholder requirements, and in light of deinition 4.23, we would call them functions on state space. One such function is well known to us already — the return on investment (ROI) introduced in section 2.2, and we can now state the general applicability of this concept in diferent terms. heorem 4.7: For any real functional element, the ROI exists as a single-valued function on its state space. Proof: By theorem 4.5, the included set of a real functional element contains the irreducible element, and by deinition 4.16 the elements of the included set have variables that are related to the variables of the real element through the decomposition/condensation process. Consequently, the values of the variables of the basic set are determined by the values of the variables of the real element, and so is the value of the ROI. he single-valuedness follows from the deinition of the irreducible element in section 2.2 and the requirement that the decomposition/ condensation process results in unique mappings between parent and sets of child variables. here is nothing profound about this theorem, as it follows directly from the fundamental axiom of our theory (i.e., that maximizing the ROI is the ultimate purpose of every project), but it expresses neatly the fact that for any real element there exists a set of parameter values that is optimal. here is never any doubt about what is the “best” solution. We shall develop some further functions of this nature in later chapters, but let us just conclude this chapter by introducing a completely diferent type of function on state space. For a number of reasons, some of which were touched on briely in section 1.4, the values of some or all of the variables belonging to a functional element will not be known to us, but we do know their probability density distributions. As a result, some or all of the functional parameters become random variables, si, and the state of the element is described not by a set of values of the independent parameters, but by a distribution density function, φ(s,t), which we shall call the service density function. Here s is the set of functional parameters, and

Functional Elements and the Functional Domain

n

73

t represents whatever subdivision of L we have adopted. Such a state may be called a superstate, and the space of all such functions for an element (i.e., with the appropriate restrictions on the ranges of the variables si) may be called superspace.

Notes 1. Pervin, W. J., Foundations of general topology, Academic Press, New York, 1964, p. 99.

Chapter 5

Interactions and Systems

5.1

The System Concept

Let us start this chapter by recalling that our aim is to develop a design methodology that takes as its point of departure a set of stakeholder requirements and seeks to reduce the complexity of inding a physical object with a performance that will meet these requirements by a top-down process of subdivision of the requirements into smaller sets. he end result of this process of design in the functional domain is a set of interacting functional elements for which the transition into the physical domain is relatively simple and eicient. We now realize that this top-down process involves two basically diferent decompositions. On the one hand, there is the decomposition into functional elements that address one or more aspects of the functionality, and we know that these elements, which we called imaginary elements, all belong to the same maximal set and are related through the composition operator. he purpose of this decomposition is to be able to address diferent aspects of the functionality at diferent stages of the process; in particular, to be able to address global aspects (i.e., with a low level of detail) early in the process, when detailed design data are not yet available. On the other hand, there is the partitioning of the complete element corresponding to the whole set of stakeholder requirements into a set of interacting elements that we called real elements, each one of which is complete with respect to some subset of the stakeholder requirements. (Stakeholder requirements and stakeholder group can be used interchangeably in this context.) Both types of decomposition play important roles in our design methodology, and the deinition of a system, to be introduced shortly, does not distinguish between real and imaginary functional 75

76 n

Designing Complex Systems

elements. It is perfectly acceptable to have functional systems made up of imaginary elements; such systems represent only certain aspects of a physical system’s functionality. A well-known example is provided by reliability block diagrams. However, as our aim is to end up with a system of physically realizable elements, theorem 4.5 and deinition 4.19 indicate that we should at irst restrict our attention to real elements, and then, as required, extend any pertinent results to imaginary elements. Or, in other words, the decomposition into real elements may be considered to be the primary one in that it leads to the desired end result, whereas the decomposition into imaginary elements may be considered to be secondary in the sense that it supports the process of choosing the best primary decomposition. he concept of a system was introduced briely and in most general terms in section 1.5, and we recall that the basic idea behind the system concept was to be able to describe something complex, be it in the physical or functional domain, in terms of less complex entities, and thereby make it easier for the human mind to comprehend and manipulate. As such, the system concept is exactly what we require for our methodology, and this is the reason the methodology is part of what is called systems engineering, although this term is applied to a broad range of activities, including in particular the management of complex projects. In the latter application, which is an application in the physical domain, only the most rudimentary features of what might be called a general systems theory have so far been applied, and there has been no need for a rigorous theoretical treatment. But if we want to use this concept in an operational sense in our methodology, we need to make it much more precise and develop it in more detail. here is no single, agreed deinition of what a system is; there are a number of diferent deinitions in use, and the choice of deinition depends largely on what one wants to use it for or in conjunction with. In our case, the following deinition, which is valid for any type of system, not just functional systems, will be adopted:1 Deinition 5.1:

A system consists of three related sets:

n a set of elements; n a set of internal interactions between the elements; and n a set of external interactions between the elements and the rest of the world. It is important to note that the internal interactions do not represent anything (physical or functional) in addition to the elements; they express which of the possible interactions already inherent in the elements are realized in this system. hey might be called logical interactions; they are either present or they are not, and there are no variables associated with the interactions themselves.

Interactions and Systems n

77

he external interactions are required, on the one hand, for the system to provide its service; on the other hand, for the system to maintain its operational state. All engineered systems are open systems. In our case, the elements are, of course, functional elements, and the resulting system is itself a functional element. hus, the forming of a system can be viewed as the result of applying an “operator” to a functional element. It is not a normal, simple operator, such as addition or multiplication, for a number of reasons. First, it is not deined by its action on any one functional element, only in terms of its action on all functional elements. hat is, its action, which consists of identifying a set of elements and a set of interactions between them, depends on the particular element to which it is applied. Second, the operator is a composite operator, in the sense of a vector or a sequence of operators, such that each component in the sequence results in a system with more elements than that resulting from the preceding component but less than that resulting from the succeeding component. And third, it is not necessarily one-to-one, but may be one-to-many. hat is, there will in general not be a unique representation of a functional element in terms of a system with a given number of elements. As a result, it will not be possible to give an explicit representation of the operator, but despite these diiculties, the existence of this operator is a useful concept. Deinition 5.2: he partitioning operator is that operator which, when applied to a functional element, results in a representation of the element as a system of elements. he number of elements in the system will be called the order of the operator. he concept of a system introduces a hierarchy among elements; the elements making up a system can be considered to be at a lower (more basic) level than the element represented by the system. he design methodology in the functional domain is called top-down because it proceeds to partition a single, “large” element with complex functionality into successively more and more “smaller” elements with less complex functionalities, but with such interactions between the elements that the external functionality remains unchanged. his latter requirement on the partitioning process, the requirement of traceability, is a requirement on the partitioning operator, and it ensures that not only are the variables of the original element and of the resultant system the same, but the behavior of the two, as relected in the functions between the variables, is also the same. hus, an alternative view of the partitioning process is as a representation of the complex function between the external variables of the system in terms of a set of simpler functions, coupled together through additional variables internal to the system. his view should bring to mind the analogy we mentioned earlier (section 3.6) — the expansion of an arbitrary function in terms of an orthonormal set of functions. We are looking to develop “collections” of basic (i.e., relatively simple) functional elements such that any functionality can be expressed as a combination of such elements.

78 n

5.2

Designing Complex Systems

Interactions between Real Functional Elements

A functional element is deined by four sets; the set of functional parameters, the set of dependencies, the set of inluences, and the set of functions between the elements of the irst three sets. Both the irst two of these sets could be involved in an interaction, but as the main purpose of a functional element is to represent what an object does, in particular as seen from the users’ point of view, and the purpose of decomposing a functional element into a set of interacting elements is to partition the users’ functional requirements and thereby reduce the complexity of the design task, it would be preferable to deine interactions in terms of functional parameters. A starting point would therefore be the following deinition: Deinition 5.3: Two real functional elements interact if the values of one or more functional parameters in one element depend on the values of one or more functional parameters in the other element. his deinition can also be formulated by saying that two real elements interact if the states of the two elements are related. Note that the deinition does not introduce any direction of the interaction; functional interactions are always between two elements, even though the physical quantity involved in the interaction may low from one to the other. Also, the dependency may be of any form — analytical, statistical, etc. his deinition says nothing about how it is possible for there to be a relationship between a functional parameter in element B and a functional parameter in element A. From the deinition of a functional element, there are four diferent combinations of the two types of variables for each element, as shown in Figure 5.1. But in each case, the output of one element must be identical to the input in the other element. hat is, the possibility of the interaction must already be inherent in the two elements; a system is created when one or more of these possibilities are realized in a particular case. V P V P From deinition 5.3, it follows that the functional parameters involved in V P V P the description of the service provided by the system must be a subset of the functional parameters of the elements V P V P making up the system. In particular, if x and y are two elements with V P V P sets of functional parameters X and Y, respectively, then the set of functional Figure 5.1 The four possible types parameters, Z, belonging to the system of interactions. Here P denotes a z resulting from the interaction of x and functional parameter, and V a depeny satisies the relation Z ⊆ X ∪ Y. his dency. Parameters and dependencies is an important observation, because it not involved in the interaction are not means that any emergent properties, that shown.

Interactions and Systems n

79

is, properties of the system that were not present in the individual elements, can be completely described using the functional parameters of the elements; no new parameters are required. It may be much more convenient to introduce new functional parameters that directly characterize the emergent properties of the system, but these will always be related to, or expressible in terms of, the functional parameters of the elements. A little example from an important type of interaction, correlation, or coherence of identical elements, is given by considering a set of identical radiators being combined to provide the service of illuminating a small, remote spot with radiation. From the users’ point of view, a most useful functional parameter is beam-width, and they might not even be aware of the relationship between beam-width and the parameters of the individual radiators (relative position and phase angle). Another example, from a diferent type of interaction, elastic collision between mass points, is the characterization of a gas in terms of pressure and temperature and, if the “service” of the gas is its ability to absorb and release heat, the functional parameter heat capacity, all of which are related (albeit in a statistical manner) to the parameters describing the individual mass points. However, having said this, we note that there may be cases of practical importance where combining elements into systems creates emergent properties for which our (current) understanding of the elements provides no explanation. We believe that, with a more in-depth understanding of the elements and their ability to interact, we would eventually always be able to explain why the emergent properties occur; being able to predict the occurrence or details of the properties is a diferent matter. his is where the theme of this book series, complex systems and complexity theory, comes into play.2 In systems that have the ability to maintain themselves by creating order (or negative entropy) to counteract the inevitable tendency of a closed system to decay into a disordered equilibrium state, this same ability can be used to change the system itself and, for example, result in the system evolving in response to changes in its operating environment. But it can also give rise to completely unexpected changes in the system behavior, often perceived as catastrophes, but sometimes providing the opportunities for drastic, beneicial changes.3 he development of complexity theory now points in a direction that would allow us to explain or understand such behavior in terms of fundamental processes involved in the interactions between the system elements, but that would at the same time prove the inherent unpredictability of this behavior.4 he ability to create negative entropy and for a system to reorganize itself has been the distinguishing characteristic of what we would call living systems (although this distinction may now lose its absolute character and become a matter of degree), and in the case of the type of systems to which the methodology proposed in this book is applicable the living components are supplied by humans, mainly as operators and maintainers. Important as these components are for the viability of these systems, engineering has traditionally treated them as non-changing entities with ixed interactions with the non-living part of the systems, and even in this book, that is efectively the approach taken. he complexity we are aiming

80

n Designing Complex Systems

to handle with our methodology lies in the operational environment (technology and stakeholder requirements), not in the people within the system. With many of the systems now of interest to engineers being seen as enterprises, where the non-living part is seen as providing only a support to the human activities, the situation is in a way reversed, in that the behavior of the people within the system, treated as a subsystem of interacting elements, becomes the focus in understanding the performance of the overall, complex system, and many of the related issues are discussed in other books in this series.

5.3

Functional Systems

From deinition 5.1, a system consists of three sets, and let us for the time being denote them by X (elements), Y (internal interactions), and Z (external interactions), so that the composition of a system A can be shown explicitly as A = (X(A),Y(A),Z(A)). With this notation, we can formulate the following deinition: Deinition 5.4: Two systems A and B are identical if and only if X(A) = X(B), Y(A) = Y(B), and Z(X) = Z(B). Or, conversely, two systems are diferent if any one of the three sets difers. his deinition appears, at irst sight, to be trivial; its signiicance only becomes clear once we realize that it would have been possible to deine the identity relation diferently. We could have said that two systems are identical if and only if X(A) = X(B) and Y(A) = Y(B), but not required Z(A) to equal Z(B). hat is, we could have said that the external interactions are a matter of the users, that is, characterize the users and what they are interested in, or how the users perceive the system, thereby giving the system an existence independent of the users, as is true of a physical system. And, after all, a functional system tells us what a physical system does, so why should this version of the deinition not be appropriate for the functional system also? To see why this is not so, we need to recall our development of the concept of a functional element. It is true that we started out by recognizing that there are two aspects to describing a physical object — what it is and what it does — and this led us initially to the concept of a functional element. But then, in order to use this concept in our top-down design methodology, we abstracted from the physical origin of the concept and deined a functional element as “something” (that exists only in our minds, i.e., a thought element), which produces a service that satisies a set of user requirements. hat is, the concept of a functional element is now anchored in a set of user requirements rather than in physical reality, and this should be true of the concept of a functional system also. Taking the user requirements as the point of departure for our design, we would expect that systems resulting from diferent user requirements would be diferent, and this is relected in deinition 5.4. To illustrate this, consider two systems, A and B, such that X(A) = X(B) and

Interactions and Systems n

81

Y(A) = Y(B), but Z(A) ⊂ Z(B). As the elements in the two systems are identical, this means that some of the possible interactions between elements and the users (i.e., interactions inherent in the elements) are not used and remain undeined. In efect, user group A is saying “Yes, we want this service, but we are not interested in these aspects of it, we don’t care what values these functional parameters take on.” In particular, the parameters in the complement of Z(A) in Z(B) do not appear in the value function, and it would be a luke if the optimization process with and without these parameters led to the same result, seeing that the parameters are coupled via the functions within the elements. his brings up an important philosophical issue about who carries the responsibility for the outcome of the design process. he view advocated in this book is that the engineer is responsible for meeting the user requirements and that the values of parameters that are omitted from the user requirements may be chosen so as to minimize the cost. Of course, there are generally accepted requirements, such as statutory and other legal requirements, that the engineer is expected to be familiar with and comply with, but beyond that it is not appropriate for engineers to impose their own values on a design, nor should the users expect them to do so. Saying “we don’t care” about some aspect of a design does not relieve the users from their responsibility for that aspect. But what about aspects that the users are not aware of, but that either are or become known to the engineers? his is where the importance of the requirements deinition process comes in, a process that is very much a part of engineering and where the engineer has a leading role in both facilitating the process and ensuring that the result is unambiguous and complete (see, e.g., he Changing Nature of Engineering 5). However, this is a process completely separate from and very diferent in nature from the design process, and getting the two confused can lead to unsatisfactory results and serious contractual diiculties. Engineering is a creative activity, but it is a diferent creativeness from that of an artist. In a sense the two activities lie at opposite ends of a scale that measures the degree to which the creative activity is motivated by a desire to express oneself versus the desire to meet a challenge posed by someone else. he artist is creative for the sake of creativity itself; the engineer is creative as a means of solving a problem or meeting a challenge. Architecture lies somewhere between the two. In this connection, one could also consider that the two activities lie at opposite ends of a scale that measures the importance of previous work, with engineering heavily dependent on previous, successful designs (and the lessons learnt from the unsuccessful ones!). Returning to the subject matter proper, we have noted that applying the partitioning operator to a functional element and thereby ending up with a representation of the element in the form of a system (of elements) must leave the external interactions intact. Consequently, the external interactions in the deinition of a system are subdivided into the same three types as are the variables associated with an element: functional parameters, consequential variables, and inluences. In deinition 4.22 we deined the concept of a service type: two elements belong to the

82

n Designing Complex Systems

same service type if they have identical sets of functional parameters. Within the set of elements belonging to a particular system we can deine another relation: Deinition 5.5: Within the set of elements deining a system, two elements a and b are equivalent, a ↔ b, if and only if interchanging them leaves the values of the system functional parameters unchanged. Is there any diference between two elements being equivalent and them being identical? Yes, in a particular position within a system, the functionality inherent in an element may only be partially utilized, that is, some of its parameters are not used to interact with other elements, and this element is therefore equivalent to a simpler element that does not have this functionality in the irst place. Note, however, that this relation is not transitive; if a ↔ b and b ↔ c, this does not imply a ↔ c, and equivalent elements do not form an equivalence class (whereas elements providing the same type of service do). An easily visualized example of this is provided by people in an organization; a person on an intermediate level may have the capability (i.e., inherent functionality) to replace both a person on a lower level of the organization and one on a higher level, but the person on the lower level may not have the capability to replace the person on the higher level. But why introduce this notion of equivalence? If our aim is to reduce the complexity of the design process, would we ever want to use unnecessarily complex elements with unused functionality instead of elements with just the required functionality? he answer is to be found in the concept of structure, which will be introduced and discussed in the next section, but to end this section, we observe that equivalence allows us to subdivide functional systems into two types, homogeneous and heterogeneous: Deinition 5.6: A system is homogeneous if and only if all its elements are equivalent, otherwise it is heterogeneous. Homogeneous systems are of particular interest in studying emergent properties; heterogeneous systems range from systems with only two groups of equivalent elements to completely heterogeneous systems, where no two elements are equivalent.

5.4

Structure of Systems

In discussing the deinition of a system, we emphasized that the interactions between elements do not represent any functionality or have any parameters associated with them in their own right, they only indicate which possibilities for interactions between the elements are in fact realized in this particular system. hat is, they are “logical” interactions; they are either present or not. But there could be more than one sort of interaction between two elements, depending on which variables in the two elements are linked by the interaction, as the deinition of inter-

Interactions and Systems n

83

action allows more than one variable in each element to be linked, and so it would appear that an interaction will need some type of parameterization or indexation, that is, be characterized by a variable that can take on more than two values. For our present purposes, we will consider the interactions to be purely logical, present or not present, in the sense that we will not diferentiate between interactions between the same two elements. he situation is analogous to representing the level of water in a tank by a binary number; if the number has only one digit, we can only diferentiate between full or empty (which might be deined in diferent ways, but typically more or less than half full), whereas with more digits we can represent the level in greater detail. In the case of functional elements, the equivalent of increasing the number of digits is to subdivide the elements into smaller elements, until inally there is only at most one possibility of an interaction between any two of them. With this understanding, we can introduce the concept of an adjacency matrix, Deinition 5.7:

In a system with n elements, xi, with i = 1, ..., n, the adjacency matrix, A, with elements aij, with i,j = 1, ..., n, is deined by

1, if there is an interaction between eleements i and j aij =  0, otherwise 

with the convention that aii = 0, and the concept of structure follows immediately: Deinition 5.8: Two systems have the same structure if and only if their adjacency matrices are identical. In this simplest deinition of the adjacency matrix the interactions are between elements, not from one element to another, so the interactions have no direction, and the adjacency matrix is symmetric, that is, aij = aji. he concept of structure in the functional domain is very similar to the concept of structure in the physical domain, and we are familiar with many examples of both. he structure of molecules arising from the interactions of the constituent atoms and the structure of crystals arising from the interactions of molecules are examples of structure in the physical domain that come immediately to mind, but there are many other, perhaps somewhat subtler ones, such as the structure of an organism or of a building. Similarly, in the functional domain (and, more generally, in the domain of ideas and concepts), the concepts in terms of which we understand Nature had been structured already by Aristotle; Kant developed a structure for his categories (four groups of three categories each); and grammar, as the structure of sentences, was developed by Chomsky. An organization can be either physical

84 n

Designing Complex Systems

(i.e., with people as its elements) or functional (with functional elements, i.e., job descriptions, as elements), and in both cases we speak of a structure. In both domains, the concept of structure is used in two diferent ways. he irst relates to properties or features of systems that depend on structure alone, that is, properties that are independent of the nature of the elements. For example, crystals that belong to the same symmetry group have features, such as birefringence, in common. In the functional domain, a well-known example is the expression for the reliability of a system; it depends on the structure of the reliability block diagram (and reliability blocks are functional elements), but is independent of both the physical nature of the objects represented by the elements and the other aspects of their functionality. Another feature of systems that depends on structure only is the connectivity of a system: Deinition 5.9: he connectivity of a system with adjacency matrix A is given by the value of the expression 1 n(n −1)

∑a

ij

i, j

his expression can, as it stands, take on values between 0 and 1. However, in order for a set of n elements to form a single system there must exist a path from any element to every other element, otherwise the set decomposes into two or more disjoint subsystems (i.e., separate systems), which means that the minimum value of the connectivity is 2/n. he connectivity is, on the one hand, a measure of the internal complexity of the system; on the other hand, it is a measure of the resilience of the system to the failure of individual interactions. But the exact interpretation of the connectivity, for example, as a measure of redundancy, is only possible once the details of the elements and of the interactions are known. Figure 5.2 shows four diferent systems consisting of four elements, each with a diferent structure, and with the connectivity of each indicated. he second use of structure, and the one that has particular signiicance in the functional domain, is to consider some of the changes that take place in a system as a result of random failures and subsequent repair as changes to the structure, rather than changes to the elements themselves. Issues relating to maintained systems will occupy all of chapter 8; here we only want to develop the foundations for using the structure concept to describe such changes. he irst step is to consider all the systems that arise from a given system by removing one or more of the interactions between the elements; this will be called the associated set of systems. Deinition 5.10: System A is associated with system B if the set of internal interactions of system A is a subset of the set of internal interactions of system B, while the other two sets are identical between the

Interactions and Systems n

85

0.5

0.5

0.6

1

Figure 5.2 Four different structures of a four-element system. The number is the value of the connectivity for the structure.

systems, i.e., X(A) = X(B), Z(A) = Z(B), and Y(A) ⊂ Y(B). he set of all systems associated with system B is the associated set of system B. It is straightforward to show that the associated set, which includes the system itself and the sets of disconnected elements (which are not systems, but only called so for convenience in the present context) has ξ

∑ x !(ξξ−! x )! x =0

members, where ξ is the cardinality of the set Y of interactions, that is, the number of interactions between elements of the system. (his expression is just the number of ways we can select x elements out of a set of ξ elements, summed over all values of x.) Consider a system and its associated set. If the elements of the system are independent of time (i.e., all their internal parameters are constants), the only changes to the system are that one or more of the interactions may be inactive. hat is, the system is represented by one of the members of its associated set, and the member may change as a function of time. he service produced by the system is described by a set of parameter values, and each member of the associated set will produce this service with diferent values. Consequently, there is a one-to-one correspondence between the set of system states and the associated set, and a sum over states can be replaced by a sum over the associated set, with each member having a certain

86 n

Designing Complex Systems

probability of occurring (and the sum of these probabilities over the whole set being equal to one, of course). So far, nothing has been gained by introducing the associated set. However, in many systems there are groups of identical elements, and the structure of the system displays certain symmetries. he concept of symmetry, that is, the invariance of properties of a system under certain permutations of its elements, is as important in the functional domain as in the physical domain, but whereas in, for example, a crystal the permutations occur through actual rotation or relection in space, in the functional domain the permutations are symbolic, as is the visualization of the symmetry, but the symmetry is very real in the expressions for the property in question. he members of the associated set can be ordered into groups of systems that produce the same service and have the same probability of occurring, and a sum over states is reduced to a sum over groups, with corresponding multiplicity factors. We can illustrate this by a very simple example, a system consisting of four elements with the maximal connectivity, as shown in Figure 5.3. he associated set contains, according to the above formula, 64 members, ordered in Figure 5.3 according to the number of interactions that are removed from the original system. If two of the elements are identical, then the associated set is broken up into 24 groups of two associated systems each, plus 14 single associated systems, as follows (for the case when the two bottom elements are identical): (1a,1f) (1b,1d) (2a,2j) (2b,2n) (2c,2i) (2d,2m) (2f,2o) (2h,2l) (3a,3t) (3b,3g) (3c,3r) (3d,3e) (3f,3s) (3h,3q) (3i,3p) (3j,3o) (4a,4j) (4b,4f) (4c,4i) (4d,4h) (4e,4o) (4q,4m) (5b,5f) (5d,5e) If three of the elements are identical, the associated set is broken up into eight groups of three, four groups of nine, and four single associated systems each, as follows (for the case when the two bottom and the upper right-hand elements are identical): (1a,1c,1f) (1b,1d,1e) (2b,2e,2n) (2g,2h,2l) (4b,4f,4i) (4c,4k,4l) (5a,5b,5f) (5c,5d,5e) (2a,2c,2d,2f,2i,2j,2k,2m,2o) (3a,3d,3e,3f,3i,3k,3p,3s,3t) (3b,3c,3g,3h,3j,3m,3o,3q,3r) (4a,4d,4e,4g,4h,4j,4m,4n,4o) and if all four elements are identical, the associated set consists of six groups, with (1, 6, 15, 20, 15, 6, 1) members, respectively. hus, the number of terms in a sum over states reduces as a function of the symmetry (identical elements), as shown in the following table: Identical elements

0

2

3

4

Terms in sum

64

38

16

6

Clearly, this approach can result in a signiicant reduction in the work involved in calculating a sum over states (e.g., the expectation value of a functional parameter).

Interactions and Systems n

87

0

1 a

b

c

d

e

f

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

a

b

c

d

e

f

2

3

4

5

6

Figure 5.3 The associated set of a system of four maximally connected elements, ordered according to the number of inactive (or failed) interactions.

5.5

Systems of Imaginary Elements

he top-down design methodology relies on two diferent means of reducing complexity — the existence of simple functional elements with global parameters that still make signiicant statements about system properties, and the consideration of aspects of systems in isolation as a means of deciding between diferent options for further development of the design. he former will result in a hierarchy of real functional elements, starting with the irreducible element at the apex of the hierarchical structure, and with the branches of the structure arising from an increasing

88

n Designing Complex Systems

level of detail in the description of the functionality coupled with an increasing degree of specialization of the functionality itself. he latter will result in a similar hierarchy of imaginary functional elements, but when it comes to forming systems, the two types of elements show considerable diferences. A system of real functional elements arises from the partitioning of a complex element into a set of less complex, but interacting elements, and these elements may have very diferent functionalities in order to represent the complex behavior of the original element. With the original element there are associated a number of aspects, such as, for example, cost, reliability, productivity, etc., each of which may be represented by an imaginary functional element if we want to consider this aspect in isolation. However, while, as a result of the partitioning, the elements representing this aspect will be at a greater level of detail, they will still be representing the same aspect; they have only resulted from subdividing the original imaginary element, and the partitioning proper refers to real elements only. he “interaction” between imaginary elements is a simple one, such as addition (for cost elements) or logical combination (for reliability elements); the resulting “system” does not have a structure of its own, but mirrors that of the system of real elements, and there is no question of emergent properties. Nevertheless, such sets of interacting imaginary elements meet all the requirements for being considered as systems, and in many ways they provide the bestknown examples of functional systems. Models that represent particular aspects are commonplace: just think of cost models, reliability models, safety (or risk) models, distortion models (for transmission/ampliication), delay models (in transport systems), and so on. However, their nature as functional models has been obscured by the way they have been applied, in modeling the behavior of a particular physical object, as a means of analyzing the behavior of a physical object to see if it meets given requirements. What is called a functional element in one case and a model in the other is exactly the same thing, in the sense of being a collection of variables and functions between them, and indeed, the reason for using them is also the same in both cases (simpliication by concentrating on one aspect); what is very diferent is how and to what they are applied. By using the word “model” we imply that they represent a feature of a real physical object, and that we can verify the accuracy or otherwise of the model by making measurements on the object. A functional element, on the other hand, does not refer to any particular physical object; it was derived from a reference to a class of objects, but the application of them in our design methodology takes place before there is any consideration of physical realization. hey are purely abstract. he distinction between model and functional element may at irst seem contrived and irrelevant, but that is mainly because we are so overwhelmingly used to the “model” interpretation that we ind it diicult — for many almost impossible — not to automatically visualize the functionality in physical terms, in which case there is no distinction, of course. Our technology has been developed by studying and understanding Nature; the physical world has been the origin of everything we

Interactions and Systems n

89

have developed so far. All our theories and representations, no matter how abstract they appear to be, are anchored in the physical world. What we are attempting to do with our top-down design methodology is to make functional user requirements the primary entities, with the eventual physical realization a secondary matter. he above statements regarding the use of models in engineering need to be qualiied in (at least) two regards. he irst is in regard to software engineering, and in particular object-oriented software engineering. While individual objects themselves are often representations of physical objects, such as persons, accounts, etc., they are seen as instances of abstract classes. Such classes are very close in nature to our functional elements, and building models of software applications in terms of them is a cornerstone of modern software engineering.6 he second is in regard to complex systems, mentioned earlier, where abstract models form the basis of studying types of behavior. Two very simple examples of such models are included in chapter 8, illustrating what is really a seamless interface between our approach and the current work in complex systems science.

Notes 1. Aslaksen, E.W. and W.R. Belcher, Systems Engineering, Prentice Hall, 1992, p.8. 2. Complex systems engineering and complexity theory have seen a huge upsurge in activity in the last decade, and this series of books is a testimony to that. For a discussion of recent developments and numerous literature references, a special issue of the INCOSE Insight newsletter, 11(1), January 2008, is a good start. For an in-depth discussion of the relationship between traditional and complex systems engineering, the reader is referred to another book in the present Taylor & Francis series, Model oriented systems engineering: A unifying framework for traditional and complex systems, by D. Hybertson. he relationship between complex systems and enterprise systems engineering is considered in Kuras, M.I., and White, B.E. Engineering enterprises using complex systems engineering, Proceedings of the 15th Symposium of the International Council on Systems Engineering, Rochester, NY, July 2005. 3. A very engaging discussion of unexpected happenings, our attitude to them, and how that attitude prevents us from adjusting our behavior appropriately can be found in he black swan: he impact of the highly improbable, by N.N. Taleb, Random House, New York, 2007. And with regard to abstraction, in the “Learning to learn” section of the Prologue, Taleb says “We don’t learn rules, only facts…. We scorn the abstract, we scorn it with passion.” 4. A very readable introduction to the implications of some of the developments in complex systems science is the book he end of certainty, by I. Prigogine, Free Press, New York, 1997. 5. he requirements deinition process and the structure of requirements documentation have been major topics in systems engineering from its inception, and in INCOSE there is a separate working group dedicated to this subject matter; see www.incose. org/rwg. An extensive bibliography is available at www.ida.liu.se/labs/aslab/people/

90 n

Designing Complex Systems

joaka/re_bib.html, and an approach used on industrial projects is described in Aslaksen, E.W., he changing nature of engineering, McGraw-Hill, New York, 1996, Sec. 9.2. 6. Jakobson, I. Object-oriented software engineering; a use case driven approach, rev. print. ed., Addison-Wesley, Reading, MA, 1993.

Chapter 6

Properties of Systems

6.1

System States

Seen from the outside, a system is identical to a functional element; the representation of a functional element in the form of a system is just a means of reducing its complexity by introducing an internal structure. Consequently, the external interactions of a system are the same as the interactions of an element with the rest of the world, and can therefore be subdivided into the same three types of interactions as was done for elements in chapter 4. hat is, we have functional parameters, dependencies, and inluences, and, most importantly, these sets of (system) variables are subsets of the union of the corresponding element variables. As we know, the interactions themselves do not contain any functionality and do not introduce any new variables, and any so-called emergent properties of a system can be expressed in terms of the variables of the constituent elements (albeit that it may, as stated earlier, be more convenient to introduce some new variables that are functions of the element variables, much in the same sense that it is more convenient to transform to a new set of coordinates). he issue of emergence and emergent properties of systems has been (and, to some extent, still is) the subject of discussion within the systems engineering community.1 We shall take a very simple and straightforward view of this, consistent with our understanding of a system as a mode of description: Consider an engineered object and a description of it in terms of a system, that is, as a set of interacting elements. hen the emergent properties of the system are those that are not present if the interactions between the elements are inhibited. hat is, emergent properties are only deined relative to a particular description of an object as a 91

92 n

Designing Complex Systems

system. In the case of the description of an object as a single element there are no emergent properties; all the properties of the object are simply that. As was the case with elements, it is the functional parameters that are of particular importance, and for the same reason; the point of departure for our design methodology is a set of user requirements expressed in terms of these functional parameters. And, as for elements, we will introduce the concept of a system state: Deinition 6.1: A system state, φ, is a particular combination of (system) parameter values. he set of all system states, Φ = {φ}, is called state space. he relationship between system states and element states can be developed further if we introduce the concept of basic system states: Deinition 6.2: Let a system consist of n elements, each with a set of states Ei, with i = 1, ..., n. hen the set of basic system states, Φ0, is deined as the Cartesian product of the sets of element states Φ0 = E1 × E2 × ... × En. he sought-after relationship is expressed by the following theorem: heorem 6.1: here exists a one-to-one correspondence between the set of system states and a partitioning of Φ0 into mutually disjoint subsets. Proof: he proof proceeds in three steps: 1. Let Ui be the set of functional parameters characterizing the i-th element, and U the set of all element functional parameters U = ∪Ui. Let W be the set of functional parameters characterizing the system, then W ⊂ U. Assuming that this is incorrect, there then exists a system functional parameter that depends on at least one functional parameter that is not also a functional parameter of one of the elements. hat implies that the interactions between the elements create functionality not already inherent in the elements, which in turn contradicts the deinition of a system. 2. Let σ be the mapping σ: Φ0 → Φ. hen, for each φ0 ∈ Φ0 there exists one and only one φ ∈ Φ such that σ(φ0) = φ. hat is, σ maps onto Φ (but not generally one-to-one). From (a) it follows that giving values to all the element functional parameters determines the values of the system functional parameters, which, by deinition 6.1, uniquely deines a system state. 3. Let the equivalence relation ∼ be deined by φ10 ∼ φ20 if and only if σ(φ10) = σ(φ20). his equivalence relation partitions Φ0 into mutually disjoint subsets, and the mapping σ(φ0) → φ0*, where φ0* is the equivalence class containing φ0, is a one-to-one correspondence according to (b). he content of this theorem can perhaps best be illustrated by a simple example (which we will come back to in chapter 8). Consider a system consisting of n equal

Properties of Systems n

93

elements, each contributing an amount Q to the service being produced by the system, and with each element being characterized by a single parameter that can take on only one of two values, 1 if the element is operating, and 0 if the element has failed. Consequently, there are n element parameters, and 2n basic system states (i.e., Φ0 is a discrete set with 2n members). Assume now that the users are only interested in whether the service level equals or exceeds mQ or not, with m < n, so that there is only one system parameter, s, which also takes on only two values, 0 and 1. he subset of Φ0 that corresponds to the state s = 0 then has a number of members, depending on m, which equals m−1

∑ x !(nn−! x )! x =0

and we could say that these basic states have condensed into the one system state. As this example shows, and as is also implicit in both the theorem and in the system concept itself, there are always fewer system parameters than element parameters. But it is not possible to formulate a theorem similar to theorem 6.1 for the parameters; there is, in general, no correspondence between system parameters and disjoint subsets of the element parameters. If we visualize the content of theorem 6.1 by graphically overlaying Φ on Φ0, as shown in Figure 6.1 for a simple case where the system has only six states, then it is tempting to do the same for the parameters by overlaying W on U (as deined in the proof), but this is obviously not correct. It is important not to confuse the partitioning operator with the decomposition process; the irst applies to elements, the second to parameters. his also explains why theorem 6.1 in no way excludes emergent properties; in general, the set of system functional parameters includes parameters from more than one element. However, and this Ф0 is most important to note, even if the system parameters are those of a single element, the behavior (i.e., time depenФ dence) of those parameters can be completely diferent to that of the isolated element, due to the interaction between elements. he reduction in the number of parameters and in the number of states that occurs when a set of interacting ele- Figure 6.1 The set of system states, ments (i.e., a system) is represented as a Φ, here shown as six dots, overlaid single element are both aspects of what, on the set of basic system states, Φ0, in the area of object-oriented software subdivided into the six corresponding subsets. design, is called information hiding.

94 n Designing Complex Systems

6.2

Changes of State

If the concept of a system state is going to be useful in our design methodology, we have to understand what determines the state of a system or, conversely, what makes a system change its state. But before doing so, we need to return to an issue that has been mentioned briely a couple of times in earlier chapters, and that is the role of people in our methodology and view of a physical object as a system. Already in section 1.5 we distinguished two groups of people: he ones within the system carrying out roles as parts of functional elements, such as operators and maintainers, and the ones outside the system, but who determine the success of the system in the sense of its meeting their requirements; they are the stakeholders. In our view, the people within the system are treated in a mechanistic fashion; their behavior is considered to be deterministic, albeit that it might require many parameters to describe it and that many of them might be in the form of distributions. In other words, they are treated as no diferent from other (non-living) components of the elements; the description of the behavior of such components may also include distributions, such as for the time between failures. Achieving the desired behavior is an important part of the engineering efort; operators and maintainers are not designed and manufactured, they are trained, and designing that training is just as much part of the system design as designing an electronic circuit. his view, which is anathema to true complex systems engineers, is valid simply because we have limited the applicability of our methodology to systems where the purpose of the system is achieved mainly by means of the non-living components; the people play mainly a supporting and supervising role. In some of these systems it is even true that some operator functions are redundant and exist only due to stakeholder perception, such as drivers on trains. In true complex systems, mainly in the form of enterprises, it is the other way around, and the equipment plays only a supporting role. We can now immediately discern three main causes of change: 1. Changes to one or more of the elements of the system during design, that is, as part of the optimization process. Each possible design option will result in a particular system state and therefore a particular value of the ROI, and our design methodology is a structured, systematic approach to identifying the option with the greatest ROI. 2. Changes occurring during “operation” of the system, for example, through wear, failure, and maintenance actions, but possibly also through changes in the operating environment, as described by the inluences and dependencies. Of course, we cannot be talking about real operation here, as there is as yet no physical system; it is the relection of the time-dependence of the functional elements. It is another example of the same type of abstraction that allowed us to deine functionality, and operation in this context is the behavior of functionality under the passage of time (i.e., a model of the intended performance).

Properties of Systems n

95

3. Changes that occur as a result of actions by the users (i.e., that subset of the stakeholders that use the service provided by the system). For example, the ROI depends on the revenue, which depends on the value function, which depends again on the attitude of the users (or a subset of them). Let us examine this last type of change irst, because it reveals an interesting characteristic of the interface between a system (i.e., service provider) and the users, or, more precisely, a statement about the consistency of the stakeholder requirements. We had previously noted that to each functional parameter there belong two types of values, the rated value and the actual value. We now note that some parameters have only the irst type of value; typical examples are such functional requirements as “the total harmonic distortion will not exceed 5%,” “the capacity will be adequate for a 1-in-100-year storm,” and “the repetition frequency will lie in the range 1–4 per month.” hese values are not changed or inluenced by the users during operation. However, a parameter such as power output has a rated value, say 500 MW, which is not changed or inluenced by the users during operation, but it also has an actual value (i.e., the load) determined by the users, say, anywhere in the range 50–500 MW. here would be other stakeholder requirements that depend on the actual value of the power output; for example, the ROI would depend on the value over time, that is, the duty cycle, and it is not possible to determine the optimal system solution without knowledge of this duty cycle. If that information is lacking from the stakeholder requirements, they are not consistent; that is, it is not possible to demonstrate that all the requirements are met. his check on the consistency of the stakeholder requirements as the system of functional elements is developed is a side beneit of the methodology. But it is more than that; it brings out an important aspect of the very early phase of a project, what in defense is called capability development and in other industries something like business case development. In principle, this activity starts with some of the future stakeholders that want to do something, to carry on a business. In analyzing what it takes to be able to do this, they ind that they need certain capabilities, and that some or all of these will require the application of technology. hey will also require the involvement of other parts of the community, in the form of suppliers, partners, distributors, etc., so that at the end of this early phase, the description of the required capability has evolved from “a good idea” to a complex model not only of the business activity itself, but, above all, of the environment in which it is to take place and the interaction between the two. Both of these will in general be complex in the sense of being described by many variables, being dynamic, and being unpredictable, and that complexity needs to be relected in the stakeholder requirements for the systems that are to support the business activity. he enterprise carrying out the business is the complex system, in the sense of the other books in this series; it is the system that has to be agile and adapt to the variations in its environment. However, the designer of the supporting (or infrastructure) systems that our methodology targets needs to understand this complexity and the strategy the

96 n

Designing Complex Systems

enterprise is intending to adopt to handle it, in order to optimize the design. he adaptability of these systems has to be designed in; they are not, in general, able to accommodate unforeseen changes in their operating environment. he result of this is, then, that the requirements of the service itself are only part of the functional stakeholder requirements; the other part is made up of the numerous additional requirements arising from the conditions under which the service is to be provided, and it is the formulation of the implications of these additional requirements of the functionality of the system that involves the actual values of some of the parameters and opens up a whole new dimension of complexity as far as the design process is concerned. A diferent way of expressing this same change to what is expected of the design is that, whereas there used to be an information wall between the designer and the client, with the client specifying what he wanted, but not why he wanted it, today that wall is disappearing, and “client satisfaction” demands a much greater inluence and relection of the client’s business in the design process. he second type of changes of state, item (2) above, are intrinsic to the system, but they generally depend on external inluences, which may range from physical variables, such as temperature, to such socio-economic factors as educational level or income level. hey may also depend on the input variables, so that the changes of type (2) and type (3) are not independent. Changes of type (2) are always present, because only an ordered collection of elements can produce a service (complete disorder produces nothing), and any order is subject to deterioration (i.e., the entropy cannot increase) and must be restored by carrying out maintenance, but their importance may vary considerably from case to case. Chapter 8 is dedicated to studying the efects of changes of type (2). From the point of view of our purpose, to develop the foundations of a topdown design methodology, changes of the irst type, item (1) above, are of particular interest. hey arise because, at every point in the design process, the designer has a number of options when it comes to fulilling the requirements at that level, and each option must be characterized by having diferent values of some variables. But which variables are they? hey cannot be the functional parameters, nor the inluences, and the dependencies arise because they are demanded by the functional parameters. So that leaves only the functions that relate the variables to one another — in other words, the choice of elements used in the partitioning and the values assigned to the parameters involved in describing the functionality of them. he choice of elements, that is, the choice of partitioning, is, of course, the essence of the design process, and remains a creative activity dependent on the individual designer. he purpose of our methodology is to support this process by, on the one hand, ofering a collection of functional elements that are useful in very many applications, and, on the other hand, giving a clear prescription for how to determine the optimal solution. Our approach to both of these objectives is further advanced in part C of the book.

Properties of Systems n

6.3

97

Service Density Function and Superspace

Returning to our comments on the changes of type (a), we recognize that our descriptions of functionality so far, as exempliied by the irreducible element, contain a very major simpliication: he descriptions are static, and the parameter values must, in some way, be averages over time. If we now want to take the time dependence into account, the previous discussions (starting already with section 1.4) show that this time dependence must be of two kinds: an explicit dependence, arising, for example, from a deined duty cycle, and a statistical dependence, arising from the stochastic nature of some of the parameters, such as the time of failure. In addition to this statistical time dependence, there is uncertainty attached to the dependencies, arising from the lack of detailed knowledge early in the design process and from the fact that design addresses the future. It is common practice in engineering to make a distinction between the two types of unpredictable variations, that is, stochastic and due to uncertainty, and to treat the two somewhat diferently. he latter is usually treated by means of sensitivity analysis and some associated decision criterion, such as Minimax or Hurwicz’ criterion,2 the stochastic variations are handled by making the actual values of the relevant functional parameters (i.e., those that are not given as only ixed values, as discussed above) random variables and assigning a density distribution function φ(x,t) to each output parameter x, such that the probability of x having a value between x’ and x’ + dx at time t = t’ is given by P(x’ ≤ x ≤ x' + dx; t = t') = φ(x',t')dx, with the condition ∫φ(x,t)dx = 1, for all t. he introduction of this probability density distribution function needs some further consideration. What does “the probability of having a value ....” actually mean? It can only mean that if we had a very large number (in the limit, ininitely many) of identical systems operating under identical conditions (called an ensemble in statistical mechanics), and we measured the value the parameter x at time t = t’ for all of them, then φ(x',t')dx is the proportion of the measured values that would lie in the range x’ ≤ x ≤ x' + dx. But, given that in most cases we have either a single system or a small number of identical systems, what is the practical use and interpretation of φ? he common interpretation is that the distribution over many systems at one point in time is identical to the distribution over many points in time for a single system. For this to be true, however, there can be no t-dependence in φ; the distribution must be time invariant. While this may be true for some systems, and may be a very convenient approximation in many cases, we know that it cannot be true in general; just think of all the systems that are subject

98 n Designing Complex Systems

to ageing. he approach to this issue comes through realizing that while the distribution φ(x) provides information about the luctuations in x, it is not an exhaustive characterization of these luctuations; in particular, it gives no information about the frequency or time dependence of the luctuations. his is best illustrated by a very simple example: Let the parameter x be restricted to the range 0 ≤ x ≤ 1, and assume that the luctuations in the value of x are periodic, with period τ, and in the form of a square wave with x = 1 for a fraction a of the period and x = 0 for a fraction (1 – a) of the period. In this case, φ(x) = (1 – a)δ(x) + aδ(x – 1). Now, if τ is very much smaller than the lifetime of the system, say T, then it is justiied to set the ensemble distribution equal to the temporal distribution. But if τ is of the order of T, then this is not justiied, and the concept of a probability distribution is not useful as far as system design is concerned, even though the distribution function is independent of τ. Now let a be a function of time, and let T’ be the time it takes for the value of a to change signiicantly. hen the above reasoning holds, but with T’ substituted for T, so that the t-dependence of φ only makes sense if τ is much smaller than T', or, in other words, splitting the temporal variation of x into a random part, characterized by φ(x), and a part characterized by the time dependence of φ, only makes sense if the luctuations are rapid compared to the rate of change in the probability distribution. his is an implicit assumption whenever the notation φ(x,t) is used, and we recognize it as essentially the same limitation as we are familiar with from equilibrium thermodynamics. It goes almost without saying that as a result of functional parameters having distribution functions attached to them, so do the aspects deined in terms of them. Focusing for the moment on the case of the irreducible element, the only element we have deined so far, there is only one functional parameter that could have uncertainty attached to it, the quality of service, S, and if we denote the corresponding random variable by s, the distribution φ(s,t) will be called the service density function (SDF). he explicit time dependence will vary from system to system, but there is one step in expanding the level of detail used in describing the irreducible element we can take without impacting the universal applicability of the element, arising from the fact that the system must be created before it can go into operation and provide its service. he distinction between creation and operation is therefore fundamental to the concept of a life cycle, and while the relative lengths of the two time periods in the life cycle may vary from almost all of one to almost all of the other, in general they both have to be present. hey will be denoted by l1 and l2, and are measured in accounting periods. An accounting period may be any time period, but is most often a year. Also, it will be most convenient to choose the origin of time to be the transition between the two time periods, that is, the time at which the system goes into operation. With these deinitions, the relationship between φ(s,t) and S is given by

Properties of Systems n

1 S= l2

I2

∞

0

0

∫ ∫ sϕ(s,t )dsdt.

99

(6.1)

his introduction of the stochastic nature of the service delivered by the system is of fundamental importance to the view of engineering presented here; ignoring it by using a deterministic variable is an unwarranted simpliication that has led to numerous erroneous claims about what engineering can and cannot do. hat the behavior of the service may be deterministic at a level of much greater detail, say at the level of individual atoms, is a diferent matter. his level of detail is not available to the engineer, and therefore, as far as engineering is concerned, the stochastic behavior of the service is inherent. Of course, to this must be added any uncertainty arising from averaging over the known behavior of a variable, or from neglecting the inluence of certain variables. his uncertainty is not due to any lack of knowledge, but to a deliberate simpliication in the sense of an approximation. At any particular time, the function φ(s,t) becomes a function of s only. he distribution φ(s) may be called a superstate, and the space of all such distributions may be called superspace. As time evolves, φ(s) for a particular system will describe a trajectory in superspace; if φ(s,t) is time invariant, this trajectory degenerates to a point. he domain of φ(x) is the set of values x can take on; in general this set will consist of intervals on the real line plus a countable number of discrete points. At a discrete point, say x = x’, φ(x) will be proportional to δ(x – x’). he above expression for S is an example of a function on superspace; another example (availability) is given in the next section. Such functions are called functionals, and a whole special area of mathematics is devoted to their analysis.

6.4 Availability While the superstate of a system is given by the service density function φ, the quality of service seen by the users at any particular point in time is some particular value of s, and when s goes below some minimal acceptable value, s1, the system is said to have failed. An important aspect of the operation of maintained systems, which would include the majority of systems, is the availability of the service, denoted by A. It is the proportion of time the system is in its operating state and is, still limited to the description in terms of the irreducible element, deined by 1 A= l2

I2

∞

∫ ∫ ϕ(s,t )dsdt . t =0 s=s1

(6.2)

100 n

Designing Complex Systems

In the most common case of time invariance as far as the maintenance regime is concerned, the service density function φ(s,t) is a function of of s only, and the availability is also time invariant. Otherwise, the above expression deines the availability of the service as an average over the operating time period, and any reinement is only possible once the lifecycle is further subdivided, so that A can become a function of time. A time-invariant availability, as deined above, makes perfectly good sense. his is not so with the concept of reliability; a time-invariant reliability makes no sense. Reliability is deined as the probability that the system will operate, under deined operating conditions, for a time period T without failure; it is an inherently timebased concept, and as such, it is impossible to determine the system reliability from a knowledge of φ alone. It is necessary to know the time dependence of the luctuations, such as the value of τ in the simple example at the end of the last section, and in the next chapter we develop a model that is of fairly wide applicability, although there will be situations to which it is not directly suited.

6.5 The Basic Design Process Revisited With the understanding we have now gained of functional elements and systems of such elements, we can add some detail to the steps of the basic design process (BDP) introduced at the end of chapter 3. In the irst step, the analysis step, a part of the system represented by a single functional element at that point in the design process is partitioned into a number of smaller, interacting functional elements. From the discussion in section 4.4, we can now add that the element being partitioned, as well as the elements into which it is being partitioned, must be real elements. he partitioning process relates to the user requirements, and the elements at each level in the step-wise process satisfy subsets of the user requirements. However, the union of all these subsets does not normally equal the set of user requirements — there is a subset of the user requirements that is satisied by the interactions of the elements; they are the emergent properties. With the real elements at any one level there will be associated a number of imaginary elements that describe such aspects as cost and reliability. In the analysis step of the BDP the elements at one level get subdivided (rather than partitioned) into the elements of the same type at the next lower level; it is a process that is sometimes referred to as requirements lowdown or requirements allocation. But what we now also understand is how this analysis step is supported in our methodology. Every real element can be condensed into an irreducible element, and that becomes our starting point. he irreducible element is then expanded by increasing the number of variables used to describe the functionality; that is, the single functional parameter quality of service (QoS) is expressed in terms of a few of its component parameters, and each one of these becomes the QoS of a new (smaller, simpler) element. At the same time, the other variables are expressed in terms of

Properties of Systems n

101

more detailed variables, and new imaginary elements are formed to describe those aspects that are of interest at this particular level of the design process. hree comments need to be made with regard to this step. First, when we speak of our design methodology as a “top-down” methodology, we realize that this relates to the expansion from the general (condensed) to the detailed and not only (or even primarily) to the partitioning process. Second, the expansion of the irreducible element is clearly a central activity, and the whole next chapter is dedicated to exploring it. hird, and perhaps most important, there is usually more than one possible partitioning of a given element, and we have not given any rule for how to choose a partitioning or, more correctly, a set of partitionings, as discussed below. And there probably is no one, universally applicable rule; the choice will always, to some extent, rely on the experience and judgment of the designer. However, the task will be very much easier and less time consuming if we have a catalog of elements to choose from, and we have noted in several places throughout the development of our methodology that the creation of such a catalog of standardized elements is a prerequisite to a widespread acceptance of the methodology. Chapter 9 makes a small start on this task by proposing a practical development framework. he second step in the BDP is the optimization step. We have already deined the optimal design as the one that maximizes the ROI, and because the partitioning preserves the deinition of the ROI, this is in principle straightforward. But there are at least three issues that complicate the process. First, the optimization takes place on two levels — the choice of the best partitioning, and then the optimization of the parameters of the elements involved in that partitioning. he latter is the well-known problem of inding the maximum of a function of several variables, and needs no further elaboration here. But how do we know that the optimal partitioning is among the set of partitionings we have chosen to optimize? And how do we make that set as small as possible, in order to increase the eiciency of the process? As noted above, the main tool here is the existence of a catalog of standardized elements; this will certainly allow us to choose a small set of partitionings. But optimizing a couple of partitionings may be unavoidable, and this leads us to the second issue, the accuracy of the information available. All design in the functional domain is based on estimates, and the higher up in the top-down process we are, the less accurate are the estimates available to us. It may therefore happen that the accuracy of the optimization is not good enough to discriminate between two possible partitions, in which case both will have to be pursued to the next level down in the process, with a corresponding increase in the design efort. But maximizing the ROI may not be the only decision criterion, and may well not be the appropriate one at a particular level. For example, if the various possible partitionings represent basically diferent system architectures, then reliability may be the appropriate criterion; only one of the architectures can (at any practical cost) meet the reliability requirement. his is the third complicating issue — inding those aspects of the functionality that are particularly relevant to the choice of partitioning at that point in the design process, and this means choosing the appropriate

102 n Designing Complex Systems

imaginary elements. Again, a catalog of such elements is the answer (or at least a very substantial part of the answer). he inal step in the BDP is veriication through synthesis, that is, the elements are combined through their interactions to form a system, and the performance of that system is calculated or simulated in order to demonstrate that it corresponds to the performance of the single element from which the partitioning into a system arose, much as one does in verifying a design in the physical domain through computer-based emulators or through building a prototype and testing it. In the case of the BDP this step is, of course, potentially almost trivial if we already have the models of the individual elements, and if these models are all compatible, in the sense that they have all been derived through the same top-down process so that all elements on the same level it seamlessly together.

Notes 1. Recent discussions of emergence in systems engineering can be found in Hitchins, D.K., Systems engineering: 21st century systems methodology, John Wiley & Sons, 2007; Ryan, A., Emergence in systems engineering, Insight, 11, 2008, 23–24. Emergence in complex systems and, in particular, organizations, is the subject of a separate journal, see http://emergence.org/. 2. Aslaksen, E.W., and Belcher, W. R. Systems engineering, Prentice Hall, New York, 1992, section 5.3.3.

Chapter 7

Expanding the Irreducible Element

7.1 Introduction So far, we have deined the concept of a functional element and developed many of the characteristics of this concept, but we have really only deined a single functional element, the irreducible element. According to our theory, we should now be able to develop all functional elements from this single element, and the last three chapters of this book are devoted to making a start on that task. However, before we start, it might be good to once again state the scope and nature of this task, as a clear understanding of the objectives is required in order not to lose our way. he purpose of functional elements is to act as the elements of design in the functional domain, just as standardized components (bolts, bearings, resistors, ICs, etc.) act as the elements of design in the physical domain. And the criterion for making something into an element is the same in both cases — usefulness. here is no law of Nature that proves the necessity of an element in either domain; elements exist because they have proven themselves to be useful. he usefulness of an element has two sources. On the one hand, it arises because the features of the element are those required in many situations. On the other hand, it arises from the fact that the element has achieved wide acceptance, possibly having been incorporated into a national or international standard. here is therefore something self-fulilling about the usefulness of a standard design element, and this is particularly true when it comes to the exact details of an element. Many 103

104 n

Designing Complex Systems

design elements would be just as useful if they were slightly diferent (e.g., a brick if it were 10% larger than a standard one), but would not be useful if they were not standardized. his same issue is vividly illustrated when it comes to measures; the concept of a standard unit of length is clearly extremely useful, but the choice of unit, say, in terms of a particular wavelength of light or the circumference of the earth, is largely arbitrary. If the meter were 10% longer than it is today, it would be just as useful; its usefulness lies solely in its universal acceptance. A inal example is the way in which we express a number as a sequence of digits with a particular signiicance to the position of a digit; this way of expressing it would be just as useful if we had chosen the base as, say, eight instead of ten. he usefulness lies in the universal acceptance of the notation. With this in mind, most of what is presented in this chapter is not new; on the contrary, in order to make it as acceptable as possible it conforms largely to what has been standard practice over many years.1 However, because the details of that practice vary from author to author and from application to application, we want to be as prescriptive as possible in order to provide a starting point for a standardization process.

7.2

The System Life Cycle

Let us start the expansion of the irreducible element by considering the temporal dependence of the aspect expressed by the element, the return on investment. he fact that the return must come after the investment implies that time must play a signiicant role, and in the irreducible element time is represented by a single parameter — the system lifetime, L. his global parameter will normally be hiding a great deal of detailed information about the system, and the lack of this information limits the use we can make of the element. For example, we already saw, in section 6.2, that it was not possible to deine the relationship between the basic variable S and the stochastic variable s without some further information about the temporal behavior of the system, and the same was true of the deinition of availability in section 6.3. But the parameter L is useful even if it hides much detailed information — it can be identiied for every system, and it allows a number of quantities to be deined, such as total cost and total revenue. Any parameters resulting from a subdivision of the lifetime should meet the same criteria of usefulness — it must be possible and convenient to identify them for (almost) all systems, and forming averages and totals over their respective time periods must be signiicant and useful. So, if we consider the three other basic variables, we should try to identify time periods within the system lifetime in which summing or averaging these variables makes sense; these periods will be called phases of the system life cycle.

Expanding the Irreducible Element

n

105

First, both the performance (i.e., QoS) and the revenue are only diferent from zero during that part of the lifetime the system is operational, so this period is signiicant when it comes to deining total revenue and average performance. Deinition 7.1: he operational phase is the time period that starts when the system has been created and is available to provide its intended service and ends when the system will not be available to provide its intended service at any point in the future. However, we recognize that the lifetime of a system does not necessarily end when operation ceases. We cannot generally just walk away from a system at the end of its operational phase; there are often signiicant activities and costs associated with decommissioning a system. It is a second time period that can be clearly identiied, and it is useful in deining, for example, total decommissioning costs. Deinition 7.2: he decommissioning phase starts at the end of the operational lifetime and ends when no further cost and/or revenue related to the system will accrue to members of the system’s stakeholder group. In the wording of this deinition, we have deliberately narrowed our focus to the stakeholder group, as otherwise the efects of a system propagating outward through society and through time would leave the decommissioning period of most systems completely open ended. However, even with this limitation the decommissioning phase will include the product liability period and any litigation that may result from such liability. here now remains the time period required to create the system, that is, the time period from the beginning of the system lifetime to the beginning of the operational lifetime. Within this phase we can distinguish two sub-phases in which the activities and associated costs are of quite diferent nature; the design and development phase and the implementation and test phase. Deinition 7.3: he design phase starts with the irst expenditure attributable to the system and ends when the system design is fully documented and approved. Deinition 7.4: he implementation phase starts with the end of the design phase and ends with the start of the operational phase. While the activities from which these two phases arise are quite diferent, the time periods during which they are actually performed may in many case overlap. hat is, design may have inished and construction started on some part of the system while another part is still being designed. In the above deinition, any such overlap is minimized by restricting the design in the design phase to system design, leaving detailed design to be carried out in the implementation period. Deining the transition between the two phases at that particular point in the system life

106 n

Designing Complex Systems

cycle is also in conformance with common practice, as the inancial decisions and the project go-ahead are most often tied to the end of system design (sometimes called preliminary design), and detailed design may be contractually combined with construction in a design and construct package. Whatever overlap is still present is included in the design phase. As a result of the above considerations, we have expanded the single parameter L into a life cycle vector L with components li, with i = 1,2,3,4, as follows: Design phase Implementation phase Operational phase Decommissioning phase

l1 l2 l3 l4

he relationship between these durations and the basic parameter L is simply 4

L=

∑l

i

(7.1)

i=1

7.3

Cost Components

In the basic set there is a single variable, C, which characterizes all costs associated with the system and, as such, it hides all details about diferent types of costs and when these costs occur; it is a total cost over the whole lifetime of the system. To bring out the details in C, we start by dividing up the cost according to the time period in which it occurs and to characterize it further by when it occurs within each time period. he total cost can then be considered to be a vector, c, with four components: 1. 2. 3. 4.

Design and development costs, Implementation and test costs, Operating (and maintenance) costs, Decommissioning costs,

c1 c2 c3 c4

Where a project consists of several systems of the same type, design and development costs are assumed to be incurred only once, whereas the implementation and test costs as well as the decommissioning costs are assumed to be incurred equally for each system. Within a period, costs occur at various times, but it is more convenient and useful to divide time up into discrete periods, called accounting periods, and account for all costs incurred during an accounting period at the end of that period. he accounting period may be anything, with something between a week and a year

Rate of Cost

Expanding the Irreducible Element

n

107

Time l1

l2

l3

l4

Figure 7.1 The assumed rates at which costs are incurred in the different phases of the system life cycle.

being the most common. he durations of the phases are then also measured in accounting periods. Of the four cost components, c3 is always given as a cost per accounting period, whereas the other three are lump sums for the corresponding phase; this is in accordance with common usage. he next step in detailing the costs is then to specify how the costs in the three phases are incurred, that is, at what rate. We shall assume that the implementation cost and the decommissioning cost are incurred at a constant rate, but that the development cost is incurred at a linearly increasing rate. his assumption is a good one for many projects, but even where it is clearly wrong, it can still be perfectly useful, because for any system feature that does not in itself depend on the manner in which the cost is incurred, just on the present value (see below), we can always deine an efective cost that results in the same present value. With the above assumptions, the rate of cost over the system life cycle will have the general form shown in Figure 7.1. In order to operate with costs that are incurred at diferent times, we need to reference them to a common point in time. his point in time is often referred to as “the present,” even though it can obviously not be the present in its true sense to the reader, and the result of translating a cost (or a revenue) to this reference point is called its present value (PV). We shall make the following deinition: Deinition 7.5:

he reference point in time for all PV calculations will be the start of the operational phase.

Finally, we need to give a name to the sum of the PVs of all costs: Deinition 7.6: he sum of the PVs of all costs associated with a system over its life cycle will be called its life cycle cost (LCC). We are now in a position to transform the cost vector into the LCC by forming the cost transformation vector, h, with components hi, i = 1,2,3,4, given by

108 n

Designing Complex Systems

h1 = =

2(1 + p)l1+l2 l1 (l1 + 1)

l1

∑n(1+ p)

−n

n=1

2(1 + p)l2 [(1 + p)(l1+1) − p(l1 + 1) −1] p 2l1 (l1 + 1)

(7.2)

h2 =

(1 + p)l2 −1 pl2

(7.3)

h3 =

(1 + p)l3 −1 p(1 + p)l3

(7.4)

h4 =

(1 + p)l4 −1 p(1 + p) l3+l4

(7.5)

In these expressions, p is the discount rate per accounting period. As it is most common to express costs in constant dollars, that is, ignoring inlation, this discount rate is the actual interest rate (cost of money for the project) minus the inlation rate. he LCC is then given by the scalar product of the two vectors, LCC = c · h .

(7.6)

As always, we need to demonstrate the relationship between these new, more detailed cost variables and the basic variable, C, and it is obviously given by C = LCC(1 + p)−(l1+l2 )

7.4

(7.7)

Subsystems and Cost Allocation

In the irreducible element, functionality is characterized by a single parameter, the quality of service, S, and as such, this parameter hides all the details of the processes taking place within the system in order to produce the service. hese processes will, of course, vary from system to system, and the question is whether there is a more detailed description that is still of (almost) general validity and, most importantly, would serve a useful purpose in our design methodology.

Expanding the Irreducible Element

n

109

We can approach this question by observing that any system represents an ordering of its parts; an unordered or random collection of parts is extremely unlikely to produce a speciied service. And we also know that any order tends to decay (i.e., become disordered) due to random (thermal) interactions with its environment unless work is performed within the system using energy extracted from the environment (this is the process of generating negative entropy mentioned earlier); the ease and economy with which the order can be sustained is termed the maintainability of the system. Consequently, most (but not all) systems contain within them not only the processes that produce the service, that is, what we have been calling the functionality of the system, but also processes that maintain the functionality and thereby allow the QoS to remain constant, or above a certain level, over the operational phase of the system’s life cycle. he system can then be represented not by a single functional element, but by two interacting elements, and this representation will be pursued in detail in the next chapter. Staying with our current objective of expanding the variables of the irreducible element to obtain a more detailed description of the ROI while still representing it as a single element, we can go one step further by observing that in most (physical) systems both the service processes and the maintenance processes involve a combination of equipment and personnel, interacting through what in most general terms might be called person-machine interfaces (PMIs). As a result, the internal structure of a system may be represented by the block diagram shown in Figure 7.2 (this view of a system was proposed already in section 13.3.1 of he Changing Nature of Engineering 1). he production subsystem contains the equipment (i.e., hardware and software) needed to produce the service, whereas the operations subsystem encompasses the humans involved in producing the service. he maintenance subsystem is that part concerned with the direct maintenance of functional subsystems and, while it contains both human and equipment elements (e.g., a maintenance management system), the element of human involvement is predominant. he support subsystem

In

Production

Out PMI

Maintenance

Operations

Support Support Input

Figure 7.2

The four main subsystems of a system.

110 n Designing Complex Systems

provides the support functions that allow the human involvement to be sustained and also provides the auxiliary (non-production) interface with the outside world (e.g., recruiting and spare parts provisioning). Besides the fundamental reason given above, a reason for the partitioning into a production and a support process is to be found in the normal subdivision of costs into acquisition costs and operating/maintenance costs, or into non-recurring and recurring costs, and this is, of course, also the major reason for choosing the reference point in time for the PV calculations as the beginning of the operational phase. he reasons for subdividing each of these two processes further into a human and an equipment-based process are also partly to be found in the type of costs associated with these two subsystems, but partly because it leads to such characterizations as degree of automation and productivity. As a result of introducing this internal structure for the purpose of cost allocation, the cost incurred in each phase of the life cycle can be subdivided into four types of cost: 1. 2. 3. 4.

Cost associated with the production subsystem Cost associated with the operating subsystem Cost associated with the maintenance subsystem Cost associated with the support subsystem

and consequently we can deine a cost matrix, C, with elements Cij, where the irst index indicates the subsystem, and the second index indicates the phase. Some typical contributors to these cost elements are indicated in Table 7.1. he LCC can then also be correspondingly subdivided into four components, one for each type of cost,

4

LCC =

with

∑(lcc)

i,

(7.8)

i=1

4

(lcc )i = hi

∑C

ij

.

j=1

7.5 7.5.1

Stochastic Aspects A Stochastic System Performance Model

As we mentioned at the end of section 6.3, certain aspects of system behavior, such as reliability, cannot be treated in a static or averaged limit, that is, what in section 6.2 we compared to the thermodynamic limit. he random luctuations in the

Expanding the Irreducible Element

Table 7.1

n

111

Contributors to the Individual Cost Elements

Element

Typical Contributors to the Cost Element

11

Feasibility studies, system design, detailed design

12

Acquisition, construction, system integration, testing, V&V

13

Raw materials, services (including power), repair parts, consumables

14

Tear-down, demolition, site amelioration, disposal

21

Operations analysis, organization development

22

Not used

23

Operating staff salaries

24

Redundancy payments

31

Maintenance subsystem design

32

Test equipment, maintenance software, maintainability demonstration

33

Maintenance personnel salaries, support equipment maintenance

34

Not used (included in 14)

41

Logistic support analysis, support system design (stores, etc.), training course design

42

Personnel hiring, initial training, documentation

43

Personnel management, ongoing training

44

Disposal

service provided by the system cannot be described just by their statistics, that is, long-term averages; the temporal or spectral properties must be taken into account. To this end, we expand our description of the irreducible element by a model that relects the most basic aspects of probabilistic system behavior with a minimum of assumptions. he model is based on the view that the service is produced by the interaction of numerous elements, and that the luctuations in QoS occur as a result of these elements and/or the interactions between them undergoing changes in the form of failures and repairs. he nature of these failures (and the subsequent repairs) does not need to concern us at this stage; we are only interested in the efect on the QoS, and we will call each decrease in s an element failure and each increase an element repair, even though we do not at any stage identify any elements. he word “element” simply refers to something that takes place on the element level, as opposed to the system level. In particular, as we do not identify any elements, we are really assuming that all the elements are equal, or that they can efectively be represented by an average element, deined by the efect it has on the system. As before, we will say that the system has failed whenever s < s1. Our model is based on the following four assumptions:

112 n

Designing Complex Systems

1. he element failures occur at random with a constant failure rate λ per unit time (i.e., they are the result of a stationary Poisson process). [Note that 1/λ is not the mean time between failures (MTBF) of a single element.] 2. he decrease in s resulting from an element failure, denoted by δ, is a random variable with a probability density distribution that decreases linearly from a value of 2∆ at δ = 0 to zero at δ = ∆. 3. he time it takes for an element failure to be rectiied, denoted by tf, is a random variable with a triangular probability density distribution, rising linearly from zero at tf = 10 to a value of 0.066667 at tf = 20, then falling linearly to zero at tf = 40. he mean time to repair a failed element (which is equal to 1/µ, with µ being the repair rate applicable to each element failure) is therefore equal to 23.333 units of time. 4. he system starts its operation at t = 0, in what we will call its design state, that is, s = s*. he value of s* is determined by the following consideration: he mean value of δ equals ∆/3, so that as all the elements contribute equally to the QOS, there are 3/∆ such elements, and the element failure rate is λ∆/3. As the mean time to repair a failed element is 23.333 units of time, the value of s* equals 1/(1 + 7.77778∆λ). In the following, we round of the above values and set the mean time to repair (MTTR) equal to 23, and s* equal to 1/(1 + 7.8∆λ). he choice of the two probability density distributions is to a certain extent arbitrary, but they have been chosen so as to be reasonable relections of reality in a large number of existing systems. In particular, the triangular distribution of δ was chosen in preference to an exponential one, as we do not want a single element failure to result in a system failure. Assumption (c) ties the repair rate to the unit of time; that is, our model operates with a unit of time that equals 0.043/µ units of the time in which µ is measured (e.g., hours or accounting periods). herefore, µ does not appear in the equations and λ is measured in this new unit of time, but at the end of the calculations, all time-dependent values have to be converted back to accounting periods. he service density function, φ(s), is a smooth, continuous function of s, except at the point s = 1, which is a singular point. To determine the value of the singularity, which will be denoted by χ(∆,λ), we use the fact that, within our simpliication of identical elements, each element has a probability of being in the failed state equal to 7.8∆λ/(1 + 7.8∆λ). Allowing a Poisson distribution for the number of elements in the failed states, the probability of inding the system in the state where no element is in the failed state is given by

χ(∆,λ ) = exp

−23λ 1 + 7.8∆λ

he function χ(∆,λ) is shown in Figure 7.3.

(7.9)

Expanding the Irreducible Element

n

113

1

Spike

0.1

0.01

0.001 0

0.05

0.1

0.15 0.2 Failure Rate

0.25

0.3

Figure 7.3 The probability of s = 1, as a function of the rate of element failures, λ, with the failure effect, ∆, as parameter, ∆ = 0.1, 0.05, and 0.02, from top to bottom.

Consequently, the service density function is made up of two components, φ(s) = φ*(s; ∆,λ) + χ(∆,λ)⋅δ(s – 1)

(7.10)

and we will call χ the spike, so that when s = 1, the system is “in the spike.” Also, let us call the event that s becomes 1 a strike, that is, the QoS “strikes the spike.” he distribution function φ(s) is not a simple function that can be expressed in closed form, but it can be evaluated by simulating system operation, stepping through time unit by unit. At each step, element failures may or may not take place, and the calculation accounts for up to two element failures per unit time. (his puts an upper bound on the failure rate of about λ = 0.3, at which point the error in the failure rate arising from neglecting higher order terms is about 1.6%).2 When an element failure occurs, random values of δ and tf are determined according to their distributions, and δ is subtracted from s in this time step and added to s tf steps later. At each step, a histogram vector for s is updated by having one of its components incremented by 1. he calculation is started with s = s* and by assuming the previous 3(1 – s0)/∆ steps resulted in failures with δ = ∆/3. A step counter, n, is incremented after each step, and the value of s is compared with the value of s1. If s ≥ s1 for n = n’ – 1 and s < s1 for n = n’, then the value of n’ is entered into a failure register, and a failure counter incremented. Furthermore, if s < 1 for n = n’ – 1 and s = 1 for n = n’, then the strike counter is incremented, and for each step with s = 1, the spike counter is incremented. Once the failure counter reaches a preset value, the simulation run is

114

n Designing Complex Systems

1.20E + 01 1.00E + 01

p(s)

8.00E + 00 6.00E + 00 4.00E + 00 2.00E + 00

0. 80 5 0. 81 5 0. 82 5 0. 83 5 0. 84 5 0. 85 0. 5 86 5 0. 87 5 0. 88 5 0. 89 5 0. 90 5 0. 91 5 0. 92 5 0. 93 5 0. 94 5 0. 95 5 0. 96 5 0. 97 5 0. 98 0. 5 99 5

0.00E + 00

s

Figure 7.4 The service density function, φ*(s), for the case of ∆ = 0.05 and λ = 0.2.

terminated, and the function φ*(s), the histogram of time between failure, and the statistics, including MTBF, MTTR, MTBS (mean time between strikes), and χ, are generated and displayed. We will irst consider the function φ*(s), and a representative result, for the parameter values s1 = 0.8, ∆ = 0.05, and λ = 0.2, is shown in Figure 7.4.

7.5.2

The Service Density Function φ(s;λ,∆)

he shape of the curve shown in Figure 7.4 leads us to suspect that the function φ*(s) can be approximated by a function of the form

G − ϕ * (s ;λ , ∆ ) = e σ

( s−s0 ) 2σ

α

,

(7.11)

where the three parameters s0, σ, and α are functions of λ and ∆. G is simply a normalization factor that ensures that the integral of the SDF over the range 0 to 1 equals 1. By comparing with the results of the simulation described in the previous section, it can be shown that a reasonable approximation can be achieved with a constant value of α, α = 1.6. he errors encountered in choosing a constant value of α, rather than letting α be a function of λ and ∆, are not signiicant enough at this high level of the design process to warrant the additional complexity of varying α. Choosing this value of α, the values of s0 and σ that provide the best it for each set of (λ,∆)-values can be determined, and a typical example is shown in Figure 7.5.

Expanding the Irreducible Element

n

115

8.00E + 00 7.00E + 00 6.00E + 00

Phi(s)

5.00E + 00 4.00E + 00 3.00E + 00 2.00E + 00 1.00E + 00 0.00E + 00 6

9

88

7 0.

10

8 0.

2

32

8 0.

9

53

8 0.

2

5

75

8 0.

97

8 0.

8

18

9 0.

5

40

9 0.

1

62

9 0.

8

83

9 0.

s

Figure 7.5 The fit of the simple exponential function to the result of the simulation, for ∆ = 0.1 and λ = 0.1 (shown dotted).

Obviously, the lack of symmetry in the simulated function does not allow a perfect it by using the simple, symmetric (about s*) exponential function, but again, at this high level of system design, it is adequate. By running the simulation for a large number of values of λ and ∆, and each time determining the best it of the function in equation 7.11, it is found that the functions s0(λ,∆) and σ(λ,∆) can be approximated by the following expressions:

and

s0 = 1 − 4.8 ∆λ ,

(7.12)

σ = 0.765λ 0.205∆ .

(7.13)

Both (1 – s0) and σ go to zero in the limits λ → 0 and ∆ → 0, as they must. Before going any further, it is probably good to stop and review what we have done so far in this subsection, so as to clearly see its signiicance and limitations. At irst glance the many simpliications and assumptions could lead one to dismiss it as simply an exercise in numerical analysis. But let us take a look at these simpliications and assumptions again: a. he system delivers a service, either directly or by means of a product. It would be diicult to think of an engineered system where this was not true.

116 n Designing Complex Systems

b. he service can be characterized by a single parameter, the quality of service (QoS), with value s, such that it is desirable for s to be as large as possible. Conceptually, there should be no problem with this; in practice there may not be an obvious choice. For example, take a mobile telephone service; there are a number of important features of this service, such as the normal QOS (probability of connection on the irst try if the called subscriber is not busy), coverage, transmission rate, etc., and forming a combination of them that is representative of the overall performance of the system would be a matter of deinition rather than a compelling necessity. c. he range of s is 0 – 1. his is just a matter of convenience, and can always be achieved by a transformation of scale. d. Element failures occur at random, with a constant system failure rate. hat they occur at random is always true; if we knew when an element was going to fail, we would replace it before it failed. A constant failure rate is deinitely not true of each type of element, but it becomes true for the system in the limit of a large number of elements once the efect of the initial condition (all elements in mint state) wears of, so that it is a reasonable assumption for the types of systems (large, with many elements) we are considering in this book. e. he efect of failure, δ, has a density distribution function with a simple, universal form and characterized by a single parameter, ∆. It is true of all engineered systems (and many naturally occurring systems, too, such as storms, earthquakes, etc.) that the impact of failures is a decreasing function of their frequency. he exact form of the function is not important for our present, high-level development, but it must satisfy the condition that the maximum impact be (signiicantly) less than 1. f. he time to repair a failure has a density distribution function with a simple, universal form and characterized by a single parameter, the mean time to repair. Between each type of element, both the MTTR and the shape of the density distribution function may vary greatly, but much of this variability will be averaged out, as seen from the system level. And it is generally true that the repair times will be clustered around some central value, determined by the criticality of the system and the corresponding design of the maintenance subsystem. g. All elements contribute equally to the QoS. his assumption, which is obviously not true in general, is used to establish the connection between the element level and the system level by connecting the number of elements to the parameter ∆. hat is, what we are really saying here is that if the stochastic luctuations in s are ine-grained (as in, say, the telephone system), the system contains a large number of elements; if they are coarse-grained (as in, say, a power generating system with four generators), the system contains a small number of elements. he assumption is just the simplest possible expression of this observation.

Expanding the Irreducible Element

n

117

So, while the degree to which our assumptions are fulilled will vary from system to system, it would be rare for them to be unreasonable. What we have constructed is a model of the stochastic aspect of system behavior that is adequate for the purpose of providing a continuity of description of an engineered object from that of a single element to a system of elements. he model is neither unique nor of any other fundamental importance; its aim is simply to be useful in conceptualizing the behavior of complex systems. However, with this in mind, it is still of interest to compare the density distribution φ(s; λ, ∆) with a famous one, the Maxwell distribution for the momentum of particles, with mass m, in a gas at temperature T, f ( p;T ) = (2πmkT )−3/2 e− p

2

/ 2mkT

.

he derivation of this distribution involves some assumptions and approximations, in particular regarding randomness and the nature of the interaction between the particles, and it characterizes the system it refers to by only two parameters, the particle mass and the system temperature (i.e., neglecting any other characteristics). Despite that, it applies with a high degree of accuracy to a large number of situations and is both conceptually and practically of great value. One further comment: he above description of system behavior related to random failures and their repair, that is, to corrective maintenance; it does not consider preventive maintenance in the form of scheduled shutdowns. hat is, the model applies only to the time periods between such shutdowns. In practice, then, whenever we need to operate on the function φ(s) for a given set of (λ,∆,)-values, for example, integrate the product of this function with another function, such as the value function, we irst call a small subroutine that generates the parameter values s0 and σ and normalizes the resulting function (taking account of χ(λ,∆,), of course), and then use the exponential approximation.

7.5.3

Temporal Aspects

As previously noted, the service density function φ(s), being a long-term average, contains no information about the temporal or spectral (frequency) characteristics of the stochastic behavior of the system. Of particular interest are the MTBF and the MTTR, which are related to the availability by

Availability =

MTBF − MTTR . MTBF

(7.14)

he distribution of the time between failures is an output of the simulation program, and a typical example is shown in Figure 7.6. Clearly, this is very far from

118 n

Designing Complex Systems

70.000 60.000 50.000 40.000 30.000 20.000 10.000 0.000 00 356 766 421 470 147 832 127 999 994 586 733 769 827 119 586 734 971 550 475 2 4 6 1 0 0 1 7 8 6 4 0. 0. 0. 0. 0. 0. 1. 1. 2. 4. 7. 11.9 19.1 30.7 49.1 78.6 25.8 01.4 22.3 1 2 3 TBF/MTBF

01

0.

Figure 7.6 Histogram of time between failures, for the case s1 = 0.8, ∆ = 0.05, and λ = 0.2, created by running the simulation until 5000 failures had occurred. The vertical scale is the percentage of times between failures falling within an interval; the numbers on the horizontal scale are the upper limit of the interval relative to the MTBF.

an exponential distribution, particularly when we consider the nonlinear interval scale. Both MTBF and MTTR are functions of three parameters, λ, ∆, and s1, and before we attempt to obtain useful approximate expressions for these functions, we need to consider the relationship between failures and the spike (introduced in section 7.5.1). Let us introduce two parameters, similar to MTBF and MTTR, for the spike, mean time between strikes (MTBS), and mean time in strike (MTIS). hese two parameters are functions of λ and ∆, but, of course, do not depend on s1. It is then straightforward to see that the following relationships must hold: and

lim(s1 → 1) MTTR = MTBS – MTIS lim(s1 → 1)MTBF = 1/λ

(7.15)

his limiting value of the MTTR is shown in Figure 7.7, and it is, as we would expect from Figure 7.3, only slightly dependent on ∆. Running the simulation program for a range of values of λ, ∆, and s1, values for the MTBF are obtained, resulting in curves of the form shown in Figure 7.8. For constant values of λ and s1, the values of MTBF as a function of ∆ produced by the simulator are reproduced very closely by a function of the following form

n

Expanding the Irreducible Element

119

10000

MTTR

1000

100

10

0

0.05

0.1

0.15 λ

0.2

0.25

0.3

Figure 7.7 The MTTR in the limit of s1 → 1, for ∆ = 0.1, 0.03, and 0.01, from top to bottom. As λ → 0, the value of MTTR equals the mean value of the element MTTR, i.e., 23 units of time. 1000000

MTBF

100000 10000 1000 100 10 1 0.05

0.1

0.15

Δ

0.2

0.25

0.3

Figure 7.8 The MTBF as a function of ∆ with λ as a parameter 0.01, 0.02, 0.05, and 0.1 from top to bottom, with s1 = 0.9. b

MTBF (∆) = ae ∆−c .

By considering the dependence of a, b, and c on λ, and taking account of the limiting value for MTBF in equation 7.15, a function that reproduces the MTBF values obtained from running the simulator is given by equation 7.16.

   s 3.11  (1 − s1 )e−17λ . MTBF =  1 + 1065(1 − s1 )λ  exp  1/ 2  λ 0 . 0284 ( ∆ 0 . 08 λ ) − s    1 

(7.16)

n Designing Complex Systems

120

here is, of course, nothing unique about this expression for the MTBF; the purpose of developing it is simply to give a quantitative expression to the relationships that must exist between the expanded parameters of the irreducible element. he availability is given by the expression 1

A(s1 ,λ , ∆) =

∫ ϕ(s,λ, ∆)ds ,

(7.17)

s1

and the MTTR then follows from equation 7.14.

7.6

A Set of First-Level Elements

7.6.1

The First-Level System

As a result of the developments in the foregoing sections of this chapter, we have now arrived at an expansion of the basic set to the set of variables in Table 7.2. he functional element that contains all these variables is a real element, because its included set contains the irreducible element, but it is a complex element and, in accordance with our methodology, it should now be represented by a system of simpler elements. If the irreducible element is considered to be the zeroth level representation of functionality, in that it is a single element and no system at all, then the irst breakdown into a representation by a system will be called a irst-level representation, and the additional elements making up the system will be called irst-level elements. In Figure 7.9, a representation in terms of ive elements is shown, in which the Table 7.2 An Expansion of the Basic Set Basic Set Variables Cost, C

Expanded Variables 4 cost types (related to subsystems), subdivided into 16 cost elements, cij Cost transformation vector, h

Revenue, R

Value function, W(s)

Quality of Service, S

System failure limit, s1

Service distribution function, ϕ(s) (represented by s0 and σ) Availability, AVAY Reliability, MTBF Repair, MTTR

Lifetime, L

4 phases, with durations li

Expanding the Irreducible Element

Level 1

121

Level 0

Cost

Input Parameters

n

C Return on Investment

Life Cycle Revenue

R

Service Delivery

Figure 7.9 A representation of the ROI aspect of functionality in terms of a system of five elements, four on Level 1, expanding the Level 0 variables, and the irreducible element, as always, on Level 0. The life cycle element is a “virtual” element.

elements have been chosen so as to group the variables and the properties of the overall element in a natural manner, relecting the way in which we would calculate the ROI using these variables. However, these ive elements are not of the same type; only the ROI element is a real element. It is the same element as the irreducible element, except that the implicit dependence on S and L has been removed and made explicit by means of other elements. Of the four other elements, which are imaginary elements, the life cycle element is a special case, in that it does not actually relect any aspect of the functionality of the system, but contains the deinitions of the four phases of the life cycle. In this sense it acts as a ilter, and extracts the phase durations from the information contained in L. Perhaps the best analogy is the header or declaration part of a software module. However, it must still be considered a bona ide imaginary functional element, as it expresses the life cycle aspect of the system. Figure 7.9 is an illustration of the understanding of functional elements we developed in chapter 4. he irst-level functional element, represented as a system of ive elements in Figure 7.9, is a real element, because if we condense the set of variables, we arrive at the irreducible element. he four imaginary irst-level elements make up what would be the innermost ring in Figure 4.5. However, if we now imagine that one of these elements, say, the cost element, was expanded in terms of a set of second-level elements, then the condensation of this set does not end with the irreducible element; it ends with the (imaginary) irst-level cost element. An illustration of this nomenclature is shown in Figure 7.10.

122 n Designing Complex Systems

0

0

0

1

1

1

2

2

2

(a)

(b)

(c)

Figure 7.10 Three different types of functional elements. (a) is a first-level real element, (b) is a first-level imaginary element, and (c) is a first-level imaginary element expanded to the second level.

7.6.2

The Service Delivery Element

he irst-level service delivery element is in its most general form, as we have not yet specialized to any particular service. It models the stochastic aspects of the system behavior; it models the efects of internal failures and repairs on the system performance, which is still characterized by the single parameter QoS. he functional parameters are: Service density function parameters Mean time between failures Mean time to repair Availability

s0 and σ MTBF MTTR AVAY

he dependencies are: Performance limit Rate of element failures Element repair rate Element failure efect parameter

s1 λ µ ∆

here are no inluences associated with this element. he functionality, that is, the relationships between the parameters and the variables, is given by equations 7.9, 7.10, 7.11, 7.12, 7.13, 7.14, 7.16, and 7.17. Note that the element repair rate, µ, needs to be included as one of the dependencies in order to deine the time scale (as discussed in section 7.5.1).

7.6.3

The Cost Element

he element representing the cost aspects of the ROI in Figure 7.9 relates cost to time and to the four functional subsystems, as expressed by equations 7.2–7.8. his relationship also contains a deinition aspect, as was discussed in conjunction with the life cycle element, in that the information about the time dependence of the costs must be present in the input data; the deinition of the life cycle phases simply allows this time-dependent cost to be allocated to the phases.

Expanding the Irreducible Element

n

123

he element also takes into account the cost of failure. he cost of a single failure, COF, is a dependency, as is the MTBF, and they are combined by deining a total cost of failure as the COF times the ratio of l3 to MTBF, and then spreading this cost evenly over l3, as it is not known when the failures will actually occur. his element has only one functional parameter: System cost

C

he dependencies of this element are: he fourteen elements of the cost matrix he four components of the life cycle vector he cost of failure he mean time between failure here is one inluence: Discount rate

7.6.4

Cij lj COF MTBF p

The Revenue Element

his element calculates the PV of the W0 revenue as the expectation value of the value function W(s) with respect to ϕ(s). he value function W(s) is given in terms of a nominal value per accounting period, W0 (i.e., the value produced if s s1 s2 were identically equal to 1 throughout 0 1 the whole period), and a value of the QOS, s2, such that the value function Figure 7.11 The value function W(s). W decreases linearly from W0 to zero as s decreases from s2 to s1, as shown in Figure 7.11. his element has only one functional parameter: System revenue

R

he dependencies of this element are: he service density function parameters he nominal value per accounting period he nominal value limit he three components of the life cycle vector here is one inluence: Discount rate

s0 and σ W0 s2 l1, l2, and l3 p

124 n

Designing Complex Systems

7.6.5

The Return on Investment Element

his element, which is extremely simple, calculates the return on investment (ROI) as a function of the cost and the revenue, as deined in section 2.2. As the ROI is only a function of the ratio of the two, the reference point in time does not matter (as long as it is the same for both), and the values transferred from the cost and revenue elements are the present values.

7.6.6

Classifying Service Elements

So far, in our quest to develop functional elements, we have identiied an element common to all systems, the irreducible element representing ROI, and it is implicit in this element that the ROI results from providing a service. But we have not made any attempt to diferentiate between types of service. here is no single, unique way of subdividing functionality into a hierarchy of classes based on type of service and, as with most other aspects of this system design methodology, it will ultimately depend on what is perceived by the engineering community as being useful. hat is also the reason why this subject matter is treated rather briely; the development of classes cannot be done by one person in isolation, it requires interaction and discussion within a large user group. What is put forward here are suggestions, and must not in any way be interpreted as statement of facts. Having said that, some suggestions may be more plausible than others, and there are also two general criteria that would appear to be non-controversial: 1. he deinition of a class should be simple and unambiguous, so that it is easy to determine if an element belongs to it or not. 2. At each level in the top-down development (and remember, the top-down development, starting with the irreducible element, is an axiom of our methodology), the union of all the classes must be able to contain every conceivable element. he irst-level subdivision of functionality is suggested by the fact that any activity is perceived by us to take place within a space-time framework (again, an acknowledgment of Kant’s inluence is appropriate at this point) and by the fact that functionality always involves doing something to something. hat is, there is activity in the narrower, more abstract sense of doing per se, which then becomes concrete by specifying the objects to which it is applied. he class of transport elements. A transport element moves a collection of objects from one set of positions in space to another, without altering anything about the objects themselves.

Expanding the Irreducible Element

n

125

he class of storage elements. A storage element moves a collection of objects from one set of points in time to another, without altering anything about the objects themselves. he class of transformation elements. A transformation element transforms a collection of objects into another, without any reference to space and time as far as the objects themselves are concerned. (However, the transformation process itself exists in space-time, so that we can, for example, speak of the MTBF of the process.) An initial attempt at developing these three classes of functional elements was outlined in he Changing Nature of Engineering 3 and will not be repeated here. Further development of service elements will be most efective if it is done in conjunction with the development of real projects, as the front end of the conceptual design phase.

7.7

An Example: Underground Copper Mine

As was indicated in chapter 2, an early and very successful application of the topdown approach was the development of the design for the Northparkes E26 underground copper mine. Because in this case the ore body was in the shape of a cylinder of about 80 m diameter and 500 m depth downward from just under the surface and heavily veined with calcium, it was ideally suited for a mining method called block caving. his method consists of excavating a few parallel tunnels at the bottom of the ore body and interconnecting them with a large number of cross-passages. In the roof of each cross-passage a funnel-shaped shaft is excavated upward for about 20 m, and then a horizontal slice is excavated out of the ore body at this point. As the extension of this slice grows, the ore body above it will start to crumble under its own weight, and the resulting pieces of ore (rocks) fall down through the funnels and form heaps in the cross-passages, which are then known as draw points. he ore is extracted from the draw points using special front-end loaders known as load-haul-dump trucks, or LHDs. Consequently, once the mine is developed (which involves, of course, a very signiicant initial investment), there is no further mining required in the traditional sense of drilling and blasting; the mine becomes what can be characterized as a rock factory, and the primary production activity is ore handling. Before describing the development of the performance model, we need to understand the requirements on the output of the mine. he ore, which must have a rock size of 300 mm or less, is delivered to a concentrator plant that requires a steady input of about 800 tons of ore per hour and operates continuously except for a major shut-down each year. At the input end, the plant incorporates a stockpile that provides a bufer for up to 24 hours’ interruption of the low of ore from the mine; for any interruptions of longer duration, there is a signiicant penalty

126

n

Designing Complex Systems

(e.g., $250,000 per day). Aside from the size limitation, there are no other quality requirements on the ore production, so it is not necessary to assign any value to the product; the service provided by the mine is characterized solely by availability (outside of the yearly shut-down) and cost. In the initial, or top-level, model of the mine the service delivery model was a single element, characterized by the following parameters: Production rate, the tons per hour that the mine was designed to deliver when operating at full capacity (this was the only operating mode considered, that is, all or nothing). MTBF and MTTR of the ore delivery, which then determined the availability. Non-recurring costs, consisting of a ixed part and a part depending on the production rate. Recurring costs, which included personnel costs, spare parts and consumables, and power costs. he production rate was determined by dividing the rate required by the concentrator by the availability, and the values of the other parameters were at irst determined by comparison with recent similar operations. he output of the model was the LCC, determined by the same four elements as shown previously in Figure 7.9 (although these were all represented on the same worksheet). However, the stochastic aspects of the system performance was in this case handled somewhat diferently to that outlined in section 7.5, in that instead of using a service density function, φ, the likely performance was determined using a Monte Carlo technique. he application of this very simple model was in deciding between two diferent ore handling schemes; either trucking the extracted ore to the surface and crushing it there, or installing an automated ore handling system, which would require crushing the extracted ore underground. Even allowing for the great uncertainty of the results, the model was able to clearly diferentiate between the LCC values of the two schemes, coming out clearly in favor of the automated system due to its lower recurring costs. he service delivery model was then expanded to four elements — extraction, crushing, horizontal transport (meaning belt conveyors), and vertical transport (meaning hoisting) — each element characterized by a somewhat expanded (more detailed) set of the parameters of the single-element model, such that when summing up, the model produced the inputs to the single-element model and thereby provided continuity in the development and reinement of the LCC. he irst use of this model was to decide on the split between conveyors and hoisting; hoisting turned out to be signiicantly more economical than conveying, so that the latter was conined to bridging the distance between the extraction point and the loading station of the hoisting system, as the hoisting shaft needed to be well away from the ore body.

Expanding the Irreducible Element

n

127

Crushing A Extraction

Conveying

Buffering

Hoisting

Crushing B

Figure 7.12

The service delivery model of the mine.

he model also showed that the hoisting was now the most expensive component, so that it became important to look at ways of minimizing the cost of it. hat meant minimizing its capacity, which again meant ensuring that it would never be idle due to a lack of upstream ore supply. he most critical upstream element was the crushing, and the model demonstrated that having two crushing stations rather than one, with a degree of redundancy, would be more cost-efective. But even with this improvement in the availability upstream of the hoisting the model indicated a strong dependence of the hoisting cost on this availability, so consequently, a storage bufer was inserted in front of the loading station, and the size of this bufer was optimized, together with the degree of redundancy in the crushers, using the model (i.e., minimizing the LCC value). he model now consisted of six elements, shown in Figure 7.12, represented by six worksheets, all linked to the worksheet that represented the single-element version and that produced the LCC values. At this point in the design development, a number of important design decisions had been taken and rigorously justiied without producing a single design drawing. In the further development of the design the model was continuously reined with more details as these became available from design calculations and from suppliers, and many choices between options, for example, for major equipment, were justiied by showing that they minimized the LCC. Of course, this was a relatively simple application, not least because it was possible to ignore what is usually the other half of the problem — modeling the value of the service. It demonstrated the usefulness of the approach, but it also demonstrated the problem of developing the model from scratch. It was quite time consuming, and under the time constraints of this project (i.e., a loss to the client in the order of $250,000 for each day delay) it was often diicult to maintain the model as a decision tool rather than as an after-the-fact means of justiication.

7.8

Summary

In this chapter, we have suggested how the irreducible element could be described in more detail by representing the element as a system of smaller elements, each representing an aspect of the functionality. his subdivision into interacting elements was carried out by irst expanding the basic set of variables through using more

128

n Designing Complex Systems

variables to describe the same concepts in more detail. he boundaries between the elements are, to a certain extent, arbitrary, and an element will survive in this particular form only if it is deemed to be useful. Each element now provides the point of departure for a further detailing of the corresponding functionality or aspect; for example, the cost element can be further developed using a subdivision of costs into various categories of labor costs and material costs, and the performance element can be developed into elements describing particular services. More important than the exact form of the elements, which is likely to change as the result of any standardization program, is the methodology used to develop them and, in particular, the fact that it guarantees traceability. No new variable is introduced without its relationship to a variable on the level above being clearly deined.

Notes 1. Aslaksen, E.W., he changing nature of engineering, McGraw-Hill, New York, 1996, section 13.3.1. 2. As the failures occur at random, their occurrence is described by the Poisson distribution, F(x;λ), this being the probability of having x or less failures per unit time. he error, ε, in the number of failures occurring over a (large) time interval is then given by

ε=

1 − F ( 2; λ ) F ( 2 ; λ ) − F (0 ; λ )

and for λ = 0.3, the value of ε is 0.016, i.e., an error of 1.6%. 3. Aslaksen, E.W., he changing nature of engineering, McGraw-Hill, New York, 1996, chapter 11.

Chapter 8

Maintained Systems

8.1

Failure and Repair in the Two Domains

From our daily experience, we would conclude that maintenance seems to be an inescapable feature of systems. Cars need regular maintenance and occasional repairs, houses need to be maintained (painted, repaired), all appliances develop faults and are either repaired or replaced, organizations need constant management attention and training in order to remain eicient, and so on. To get a better understanding of what drives this need for maintenance, we must, for a moment, go back to the physical domain and consider some general characteristics of physical systems, as the reasons for maintenance in the systems we are considering are mainly physical in nature. However, that should not obscure the fact that there are many objects in engineering for which the need for maintenance is not driven by any physical deterioration, such as the methodologies that need updating in light of accumulated experience, data banks (as more accurate data becomes available), and even basic theories, such as the extending of the laws of physics to take into account relativity. Physical systems are made up of interacting physical elements; it is these interactions that bind the elements together into a system. Each element is again a system of smaller interacting elements, and so on, until at some low level the elements are electrons and nuclei, and the systems are called atoms. he elements are bound together by a combination of short-range repulsive forces and long-range attractive forces, and the binding of each element can be expressed in terms of a potential energy that equals the work required to remove the element from the system. But, in addition to this potential binding energy, the elements also possess a kinetic energy; we may think of it as the elements rattling around in the “cage” formed by 129

130 n

Designing Complex Systems

the potential energy. If this kinetic energy of an element becomes comparable to the potential energy, the binding may be overcome and the system (i.e., the atom) undergoes a change. To restore it to its original condition, we would have to supply a “spare” element (i.e., electron); this would be a maintenance action. his picture of a system existing in a realm of two competing energies — the constitutive potential energy and the destructive kinetic energy — is very useful, even though it is highly simpliied. At the next level up in the hierarchy of systems, atoms are the elements in systems called molecules. he potential energy binding atoms together is called a (chemical) bond, and each atom has an amount of kinetic energy in the form of vibration within the conines of the bond. (It is sometimes useful to think of the bond as a spring or a rubber band between the atoms.) An atom of type A and an atom of type B may or may not be able to form a bond, and this information is carried in the structures of the atoms, that is, in how the elements are arranged within the system. But where two atoms can form a bond, there may be more than one type of bond possible, so that a set of atoms may result in one of several molecules. (Molecules with the same chemical formula but diferent structures are called isomers.) What emerges from this picture is that, in addition to the potential and kinetic energies of the elements, a system is characterized by an amount of information; the information carried in the structure of the system. he atom carries the information about how the electrons are arranged around the nucleus, that is, its structure (and which determines what bonds are possible); the molecule carries the information about which of the possible arrangements of atoms is realized in this particular molecule. Continuing up to the next level, molecules combine to form materials, and again there is an amount of information that describes how, out of the many possible ways in which molecules can form materials, this particular material is constituted and structured. here are binding forces between the molecules (potential energy) and kinetic energy in the form of vibrations of the molecules, but because there are normally very many (say, on the order of 1022) molecules in a piece of material used in any engineering design (except possibly in nanotechnology), it is neither practical nor necessary to look at the state of individual molecules, but rather to treat the collection of interacting molecules (i.e., the system, on this level) in a statistical fashion. his treatment, statistical mechanics, forms the link between atomic physics and the description of matter on a macroscopic level, called thermodynamics. For example, the kinetic energy is represented by the temperature, and as the temperature rises, the bonds between the molecules come under increasing strain, until at some point they begin to break and the material disintegrates or melts. At this point in our journey upward in the hierarchy of systems a decisive change takes place. So far, the possible systems have been determined by the laws of Nature; the human inluence has, at most, been in the selection of a desired system (e.g., molecule or material) out of the set of possible ones through the process used to create the system (e.g., pressure and temperature conditions in forming

Maintained Systems

n

131

materials out of components). Or, to put it another way, the information contained in the system arises from the laws of Nature, not from any human input. But when we go to the next level up, the elements are components formed or machined out of materials in a manner determined by human design, and the way in which the elements are combined to form a system is also the result of human design. he system is a representation of the information contained in the design, originally contained in the designer’s mind, then transferred to speciications, drawings, and other data forms. As a consequence, designed or engineered systems have some very signiicant characteristics not found in the lower-level systems. First, every engineered system has a purpose — the purpose in the engineer’s mind when the system was designed or, more precisely, in the terms of the earlier discussions in this book, the purpose expressed by the stakeholder requirements. A molecule or material, as such, has no purpose. Second, while the system is a (more or less good) representation of that purpose, knowing all the information contained in a system does not necessarily allow one to deduce the purpose (reverse engineering). Both of these characteristics have a decisive inluence on our investigations into the, by far, most interesting of all systems, the human being. Does the human being have a purpose? If yes, this implies a designer (usually called God). On the other hand, even when we, as will soon be the case, know all the information contained in that system, it is highly unlikely that we will be able to reverse engineer it and so be able to determine if there is a purpose and what that purpose is. hird, and closely related to the irst characteristic, is the concept of a system’s functionality, that is, that the system does something. A molecule or material does nothing, it only is; however, letting the molecules in a (suitable) set interact may result in an object (system) that does something, as in a living cell. his self-organization is one of the most fascinating issues in complex systems science. In the case of engineered systems (“engineered” taken here in the widest sense), the organization and the resulting functionality arise as a result of the work of the designer, and improving our ability to work in the functional domain is the aim of this book. Finally, and of greatest importance with regard to the present subject matter, maintenance, is the manner in which statistics is used in the two cases (i.e., engineered and non-engineered systems) and the signiicance of the results. Take as an example of a non-engineered system one of the simplest, but also easily visualized systems, that of a ixed volume of a dilute gas. At any given point in time any particular gas molecule will have a deinite position and momentum, or, equivalently, be represented by a point (p,q) in a six-dimensional phase space. However, in the absence of an external potential, a molecule is equally likely to be found in any part of the volume, so that, as far as the state of the gas is concerned, we need only consider the three momentum variables. hrough collisions with the walls of the container and with other molecules the values of these three momentum variables change frequently, but as there are very many (say, 1022) identical molecules in the volume, the state of the gas can be described in terms of a probability distribution

132

n

Designing Complex Systems

f(p), such that the probability of inding a molecule with momentum between p and p + dp is given by f(p)dp. As is well known, in this simple case the function f(p) is the Maxwell distribution, from which can be derived the equation of state for a mole of a perfect gas, PV = RT (R being the gas constant), and other distribution functions apply to more general cases. he details of this case are not important, it is meant to illustrate one thing only; the manner in which statistics is used to connect a macroscopic quantity, such as the pressure P, to properties on a microscopic (molecular) level, and that this connection relies on the “most likely” or “equilibrium” distribution of the microscopic variables. Similarly, but using a variety of often complex distribution functions, changes on the microscopic level due to the “competition” between kinetic and potential energies can be expressed as changes to macroscopic parameters of the components that are the building blocks of engineered systems and, in particular, to the failure rates of such components. However, the “normal” state of an engineered system does not arise from the most likely distribution of the component parameters; it is a state that, in the sense of thermodynamics, is a highly non-equilibrium state, and statistics are used to determine deviations from this state. If we now leave the physical domain and return to the functional domain, the concept of failure and the use of statistics to connect changes at the element level to changes at the system level need some thought. On the face of it, as we have endeavored to make functional elements independent of any physical realization, there is no direct connection between physical failure mechanisms and system behavior, with or without the use of statistics. his situation does not change when we subdivide the system into smaller and smaller functional elements; in principle, a functional element remains a functional element no matter how small it is, and so it would seem that the concept of failure and the need for maintenance do not apply to the functional domain. A thought-element can neither fail nor be maintained. To resolve this apparent dilemma we only have to recall two features of the functional domain. First, that functional elements are not representations of physical elements; they are representations of what physical elements do. In order to represent failure and restoration (maintenance), a functional element does not itself have to “fail” or be “restored.” Second, that whereas the physical domain is in its nature “bottom-up,” progressing from the physics of the basic building blocks upward to more complex devices, equipment, and systems, the functional domain is “top-down,” starting with the stakeholder requirements. herefore, the relationship between element and system reliability (or availability or maintainability) is not one of cause and efect, but one of allocation. However, if a functional element is going to represent the failures of physical elements, it must also represent the fact that these failures occur at random, so that the treatment in the functional domain must also be a statistical one. hat was the motivation for the statistical performance model introduced in section 7.5, and later in this chapter we will develop some models of the element-system relationship on this basis. But irst we should

Maintained Systems

n

133

explore the extension of a further concept from the physical domain into the functional domain — the concept of entropy.

8.2

Order, Information, and Entropy in the Two Domains

he statistical treatment of a gas introduced in the previous section is a relection of our lack of detailed knowledge about individual molecules in the gas. Any one particular molecule will, of course, have a deinite position and momentum at a given point in time, and so at any given point in time, the microstate of the gas is represented by a point in a 6N-dimensional phase space, if there are N molecules in the volume of gas. As time progresses and the individual molecules go through their trajectories and undergo collisions, the point representing the microstate of the system will also move around in phase space, and for a given thermodynamic state (i.e., macrostate) there is a deinite probability of inding the system in a particular region (i.e., microscopic volume) of phase space. he central issue in statistical mechanics is therefore to ind the relationship between thermodynamic states and their distribution functions. he relationship turns out to hinge on the concept of entropy, S, as was irst realized by Boltzmann. In thermodynamics, S is the extensive variable conjugate to the intensive variable T, the thermodynamic temperature, in the sense that the internal energy, U, can be expressed as a sum of products of intensive and extensive variables. For example, for a system with pressure, P, and volume, V, as the only mechanical variables, U = TS – PV, and the relationships between the extensive and intensive variables is given by diferentials of U, such as T = (∂U/∂S)V. If f(q,p) is a distribution function, with q and p being 3N dimensional vectors, then the relationship between entropy and distribution function is given by

S =−k

∫ f ln( f )dqdp

(8.1)

where k is the Boltzmann constant. For our purposes, the interesting feature of this equation is that it shows entropy to be a measure of the order of the system, that is, of the degree to which we are certain that the system is in a particular state. he more disordered the system, the less information we have about what state it is in, and the greater the entropy of the system. If we know for certain exactly what microstate the system is in, then the distribution function is a 6N-dimensional δ-function, and the entropy is zero. If we know nothing about what microstate the system is in (total disorder), it is equally likely to be in any state, and f is a constant equal to the reciprocal of the allowable

134

n

Designing Complex Systems

phase space volume (limited, e.g., by the internal energy of the system and the size of the container), and the entropy takes on its maximum value. In the case of a functional system, there is also a lack of information, in the sense that we do not know what state the system is in at any given point in time; this was the reason for introducing the service density function, φ(s;λ,∆), in section 7.5. he above relationship between disorder and entropy for a physical system then suggests that there might be an equivalent concept for functional systems, a functional entropy, E, deined by 1

∫ ϕ(s;λ, ∆)1n(ϕ(s;λ, ∆))ds.

E =−

0

(8.2)

he entropy E depends, within the accuracy of the numerical expressions introduced in the previous chapter, on λ alone and not on ∆, as we would expect as long as ∆ remains much smaller than 1. However, before we display the result of evaluating equation 8.2, we will change the independent variable from the failure rate λ to the repair rate µ, as this will be more suitable for discussing maintenance in the rest of this chapter. hat is, we will consider systems where λ is ixed (by the hardware and software design), but where µ can be varied by changing the maintenance regime. In the model developed in chapter 7, the variable λ is the element failure rate, but measured in units of 23.3µ', where µ is the element repair rate, and the prime indicates that it is measured in ixed time units, for example, per hour. Consequently, λ' = λ⋅23.3⋅µ', or λ = 0.0429(λ'/µ'). If we now measure the repair rate in units of λ', that is, µ' = µλ', then µ = 0.0429/λ. With this understanding, the integral in equation 8.2 can be evaluated as a function of µ, and the result is shown in Figure 8.1. As we would expect, the system entropy (i.e., the disorder) increases as we reduce the repair rate. However, remember that the results of the previous chapter were limited to λ < 0.3, or now µ > 0.15; as µ becomes smaller than this value, the entropy must eventually start to decrease and become zero again for µ = 0, as can be seen from considering the case of a functional system starting out in the state φ(s) = δ(s – 1) and with entropy zero. If it is left to itself, that is, without maintenance, the service density function will broaden out, and the entropy increases, as shown above. But in the end, all interactions between the elements will have failed, and φ(s) will equal δ(s), and the entropy will again be zero, which at irst seems to make little sense within the analogy with the physical case. his shows that, while the above similarity between the concepts of entropy in the two domains is intuitive, and the equations relating entropy to distribution function are identical, there is also a very signiicant diference between the two cases. In the physical case, for example, in the case of a perfect gas, the equilibrium state is the most likely state, the one in which the kinetic energy is distributed

Entropy

Maintained Systems 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0

0.1

1

μ

10

n

135

100

Figure 8.1 The system entropy, E, as a function of the element repair rate, µ.

equally over the molecules, and left to itself, the gas will attain this state, even if it starts out in the highly unlikely state where the whole kinetic energy is carried by one of the molecules. Correspondingly, the entropy goes from zero to its maximum value for this particular value of the total kinetic energy, as noted above. his process of entropy increase is irreversible; the entropy of an isolated volume of gas can never decrease of its own accord, whereas for a functional system, while the process is also irreversible, the entropy irst increases, but then decreases to zero. he explanation of this apparently paradoxical behavior of the system entropy is to be found in the deinition of the two variables f and s in equations 8.1 and 8.2. he variable f indicates the state of the system; the possible values of f correspond to the possible states of the system, but it is not a measure of the energy of the system. On the contrary, in an isolated system the energy remains constant as the system moves toward equilibrium. he variable s is only indirectly a measure of the state of the system; it is a measure of the service provided by the system, which requires an expenditure of energy. To make the analogy with physics, we have to consider s to be a function not only of the coniguration of the system (in the sense of the interactions between the elements), but also of the “energy” of the system (in the sense of being able to do something). As s goes toward zero, not only does the structure decay, but so, of course, does the capacity of the elements to do something (anything). he state s = 0 corresponds to a physical system (e.g., a gas) at a temperature of zero Kelvin, and it then also has an entropy of zero. Another view of this issue is discussed in section 8.5.

8.3

A Functional Element Representing Maintenance

Keeping in mind the purpose of this book, to develop functional elements that are useful in describing what systems do, that is, their capabilities, we now realize that most complex systems are capable of doing two things — producing a service, and

136

n Designing Complex Systems

maintaining this production over a period of time. herefore, the next step in the process of describing the functionality in more detail is to introduce a separate element to account for the maintenance function, resulting in a subdivision of what in Figure 7.9 was represented as a single element, the service delivery element, as shown in Figure 8.2. he output of the maintenance element, that is, what it delivers to the service element to maintain the performance of the latter, is characterized by the parameter µ, which can be viewed as a generalized repair rate. It was introduced in chapter 7, together with the failure rate, λ, to account for the stochastic nature of system performance in a most general fashion, without relating either failure or repair to any speciic internal features of the system, although it was perhaps natural to assume that the luctuations in performance resulted from failures and repairs of whatever elements the system was made up of. And indeed, in the deinition of a system in section 5.1 we emphasized that the interactions do not in themselves represent any functionality; they simply indicate which of the possibilities for interactions inherent in the elements are utilized in a particular system. hus, it would follow that interactions cannot fail or be repaired; it is always one of the elements involved in the interaction that fails or is repaired. However, in the following three sections we will develop three diferent models of the failure and repair process in which it is very convenient to use the interactions, rather than the elements, as the entities that fail and are repaired. With regard to the two-element system representation in Figure 8.2, we see that while the maintenance parameter, µ, is an important input to the service element, and the value of this parameter is of great consequence to the service seen by the users, the manner in which this value is achieved is not directly important to the users. As a consequence, there is a tendency to concentrate on the design and optimization of the service element and to ignore, or leave as something to be considered later, the fact that the maintenance element may be a system of equal complexity as the service element, and that an optimized system design can only be achieved by optimizing the two elements together. And because the service Service Input

Service Element With Failure Parameter λ Maintenance Parameter µ

Maintenance Input

Maintenance Element

Figure 8.2 Separating out the maintenance function.

Service Output

Maintained Systems

n

137

element is the one directly visible to the users, it is also quite common to speak of “the system” as being the service element only. We implicitly adopted this common usage in chapter 7 when we discussed classes of systems; these classes were classes of service elements only, but this is in no way meant to diminish the role of the maintenance element. A development of that element into classes could be the subject of a separate work.

8.4

A Model with Binary Interactions

Consider a system consisting of n functional elements, and let us assume that the system functionality has been so inely subdivided into elements (i.e., that n is so large) that the interactions between elements may be approximated by binary interactions. hat is, an interaction is either operating or failed, and the system functionality is completely described by the functionalities of the elements plus the adjacency matrix, A, as already discussed in section 5.4. he maximum number of interactions between the elements is n(n – 1)/2; however, not every element will have the capability of interacting with every other element, and we shall represent the set of all possible interactions that are not already included in A by the matrix H, in which hij = 1 if an interaction between the elements i and j is possible and aij = 0, and 0 otherwise. As all interactions are bidirectional, the matrices A and H are both symmetrical, and if, as previously stipulated, the diagonal elements are deined as all equal to zero, the sets of interactions can be represented by upper triagonal matrices. An interaction is characterized by a failure rate, and we shall, at least initially, assume that the failure rate is the same for each interaction, and denote it by λ. Each interaction is also characterized by a common repair rate, µ; however, when a failed interaction is repaired, there is a certain probability that the repair is done incorrectly, such that, instead of linking the two elements that were previously linked, it links one of them with another element, if another such link is allowed. At any point in time, the interactions actually operating are represented by the (upper triangular) matrix X. he repair process is modeled as follows: Let the index pair of a failed interaction be (u,v), and deine two associated sets, U and V, U = {uj = huj; j = u + 1, ...., n }, V = {vi = hiv; i = 1, ...., v – 1}, and let

138 n

Designing Complex Systems

U=

∑u

j,

j

V=

∑v . i.

i

If U + V ≠ 0, there exists at least one allowed, incorrect interaction, and there is then a probability, to be denoted by ρ and satisfying the condition ρ < 0.1 (an arbitrary, but reasonable limit), that the repaired interaction will be one of the allowed, incorrect interactions rather than the original one, with each of the incorrect ones being equally likely. However, once an incorrect interaction has been activated, the corresponding correct interaction (i.e., the original one that failed) is blocked, and cannot be repaired until the incorrect one has failed. he measure of the state of the system is the degree to which the current matrix, X, coincides with the design matrix, A, and the correlation, χ, is deined by χ=

∑a ∏ 1

aij xij ,

ij

(8.3)

remembering that the matrices are triangular. A small Visual Basic program was developed to simulate the system behavior; it steps through time in steps of a length that is the inverse of the units in which the failure rate λ is measured. For example, if λ is measured per hour, then the step length is one hour. he program starts with the initial condition X = A and steps through a total of 1000⋅Steplength/λ steps, calculating the value of χ after each step, and forms the average value of χ from the last 90% of the steps (to eliminate the efect of the transient behavior before the steady state is reached). As an example, the following A and H matrices were chosen (a and h signify the elements that are equal to 1 in the respective matrices): h

0

h

a

0

0

0

0

h

0

a

0

0

0

0

0

a

h

0

0

0

a

0

h

0

0

a

a

a

a

0

0

h

h

0 h

Maintained Systems

n

139

1

Correlation

0.9 0.8 0.7 0.6 0.5 0.4

1

10 μ/λ

100

Figure 8.3 Correlation in the error-prone structure model as a function of the repair level, for three values of the error parameter, ρ = 0 (top), 0.01 (middle), and 0.1 (bottom).

and the results are shown in Figure 8.3 for three values of the error parameter ρ, 0, 0.01, and 0.1. he upper curve in Figure 8.3 (with ρ = 0) relects the normal behavior of a maintained system, in that the correlation goes rapidly toward 1 (i.e., the system is in its intact state most of the time) as µ/λ >> 1. But for ρ > 0 the behavior is diferent; not only does the correlation decrease with increasing ρ (as we would expect), but the dependence on µ/λ shows a “lattening out.” his is due to the special feature of the model that does not allow errors to be repaired.

8.5

Organizational Disorder

Following on from the model developed in the previous section, we shall continue to use the interactions to describe the changes taking place in the system, but consider that the changes are purely changes to the structure of the system and not caused by any failures as such. hat is, an interaction, xij, may change by one or the other of the indices changing its value, but the number of interactions remains unchanged; such a change will be called a mutation, and the rate at which an interaction mutates will be denoted by λ. he state of such a system is completely described by its structure, and the role previously played by the space of basic system states is now played by the space of allowable structures, and an allowable structure will be denoted by X; it is a matrix with elements xij, where i and j take on values from 1 to n, the number of elements in the system. he number of elements in the set of allowable structures is determined as follows: Using the upper triangular notation of the previous section, let the number of interactions in the adjacency matrix A be denoted by a and the number of additional allowed interactions in the matrix H by h, then the number of ways a set of a interactions can be selected from the total set of allowable interactions, say m, is given by

140 n Designing Complex Systems

m=

(a + h)! . a!h!

Let us denote the set of allowable structures by M, then the superstate of the system is a probability distribution on M, which we may denote by f i, i = 1, ..., m. Initially, of course, the superstate is a single basic state, the one given by the adjacency matrix A, and f i takes on the value 1 for the corresponding value of i and is zero for all other values of i, so that the entropy, as deined by the equivalent of equation 8.2, is zero. But left to itself, such a system will change its structure in a random fashion, and after a while will be equally likely to have any one of the allowable structures. hat is, the “equilibrium” superstate is a uniform distribution over M, and the entropy takes on its maximum value, ln(m). In this model of system behavior, the concept of entropy is similar to the one we are used to from thermodynamics, and does not display the peculiar behavior we saw at the end of section 8.2. However, we have achieved this by deining entropy in terms of structure, a variable that is once removed from the performance (parameterized, e.g., by the quality of service), so that we now have the problem of relating structure to performance. But we can now also get another perspective on why the problem at the end of section 8.2 arose. In both the case of thermodynamics (i.e., the perfect gas) and that of system structure, the changes on a microscopic level, that is, the individual collisions of the gas molecules and the mutations of the individual interactions, are reversible. he irreversibility of the macroscopic process arises solely as a result of the statistics; the macroscopic process is irreversible because reversing it is so highly unlikely. But in the case where the macroscopic change is due to the failure of elements, the microscopic process, that is, the failure of an individual element, is itself irreversible, and no equilibrium state is reached, only a state of total destruction. In most systems of practical interest, the structure is not allowed to change unchecked; maintenance is done in order to maintain the original structure or one as close to it as possible. his maintenance efort can be parameterized by a restoration rate, µ, deined as the probability per unit time that an interaction in X not in A will be changed back to an interaction in A, additional to any change due to the mutation rate, λ. As a result, the distribution function f i will peak around the A structure, and the entropy will take on some value intermediate between zero and ln(m). Obtaining an explicit expression for this distribution as a function of µ is not practical nor would it be particularly useful; what we can obtain is, as in the previous section, the expectation value of the correlation between A and X, χ(µ). his function must satisfy the boundary conditions χ(0) = a/h and χ(∞) = 1, and an example is shown in Figure 8.4 for the nine-element system used as an example in section 8.4. In this igure, the upper curve is for the H-matrix used in the previous section, that is, with a/h = 0.5, whereas the lower curve is for the case when the

Maintained Systems

n

141

Correlation

1 0.8 0.6 0.4 0.2

0

2

4

μ/λ

6

8

10

Figure 8.4 Correlation for the mutation model for two different H-matrices; the top one with a/h = 0.5, the lower one with a/h = 0.22.

allowable interactions equal the total number of possible interactions, that is, 36 interactions and a/h = 0.22. he shape of the curves in Figure 8.4 is similar to that of the ρ = 0 curve in Figure 8.3 (but note the diferent µ/λ-scales); however, in that previous case, the a/h ratio was irrelevant. What this model demonstrates is the (not surprising) fact that the greater the freedom (i.e., the possibilities for change) the greater the efort required to maintain a particular structure (organization).

8.6 Coherence In this last model of the process of failure and repair we shall consider a large group of systems in which the elements are either identical or similar, and all cooperate in producing the system output. Examples of such systems are all types of organizations (companies, military units, sports teams, political parties, etc.), markets (consumers), physical many-body systems (lasers), and engineered systems (phased arrays). In particular, we shall investigate a common feature of these systems called coherence, and to this end we consider a simpliied, generalized system consisting of n identical elements, each producing an output characterized by two parameters, an amplitude, which, because the elements are identical, we may set equal to 1, and a phase, φ, which can take on any value in the range –π to +π. hat is, the element output can be represented by a two-dimensional vector in a polar coordinate system, with a ixed length of 1, and the system output will be the sum of these n vectors. his work was previously reported in Systems Engineering.1 Each element is subject to an inluence that tends to change the phase in a random fashion; such changes take place at a constant failure rate, λ. But there is also an interaction between the elements that tends to align their outputs. Each element sees the combined output of the other n – 1 elements, called the interaction, and, at a constant repair rate µ, the phase of each element is aligned with

142 n Designing Complex Systems

the interaction phase. However, the model takes account of the fact that in many systems the interaction is limited to nearest neighbors or some other small group of elements (just think of people in society, in an organization, etc.) with, say, n 0 members, by multiplying the interaction amplitude by the factor

n

− n0 (1 − e n0 ) . n

he behavior of this system is qualitatively as follows: If the system is initially in a state where all the element phases are identical, the coherence χ is initially 1, but under the inluence of the failure process, the phases of the element outputs will start to difer from one another and the system output will start to decrease in a random manner. hat is, both the system amplitude and the system phase become stochastic variables. For reasons that will become clear in a moment, it is preferable to use the amplitude as a measure of system performance, and the expectation value of the relative amplitude will be called the coherence of the system and be designated by χ; it takes on values in the range 0 – 1. If there is no repair process, that is, µ = 0, the coherence decays to its minimum value, which may be denoted by η and is a function of n. he function η(n) was determined by the Monte Carlo method, and the result is shown in Figure 8.5. But if µ > 0, then the coherence will stabilize at some steady-state value greater than η, as will be shown presently.

Steady-state Relative Amplitude

0.35 0.3 0.25 0.2 0.15 0.1 0.05 0

0

100

200 300 Number of Elements, N

400

500

Figure 8.5 The value of the coherence, defined as the amplitude at t = ∞ divided by the number of elements in the system, n, for random distribution of the element phases, as a function of n.

Maintained Systems

n

143

If the system is initially in a chaotic state where each element phase is equally likely to be anywhere in the range –π to +π, the coherence χ starts out being equal to η and then increases to its steady-state value, determined by µ/λ as above. his occurs because the element phases lock together and luctuate around the phase of the system output, but the value of this system phase is arbitrary, and it also “drifts” in either direction. hat is, the frequency spectrum of the system phase has signiicant components at both high and low frequencies, whereas the frequency spectrum of the amplitude decreases rapidly with decreasing frequencies (beyond a certain frequency, as we shall discuss shortly). his is the reason why the amplitude is a more convenient measure of system performance than the phase. In order to study this behavior in a more quantitative way, a small Visual Basic program was developed that simulates the system behavior by stepping through time, again in steps with a duration equal to the unit of time in which λ is measured, with the element phase angles at the beginning of the step equal to ϑ1(i), i = 1, ..., n, (called the “old” values), after the calculations equal to ϑ2(i) (called the “new” values), and then, at the end of each step, ϑ1(i) = ϑ2(i). he calculation starts from one of two initial conditions; either a uniform probability distribution of element phases (mode = 1), or all element phases equal to 0 (mode = 0). hen, for each element, the following sequence of calculations is carried out: First, if a random number is less than λ, the element phase is set to a random value within the range –π to +π. hen the interaction amplitude A i (i.e., the combined output from the n – 1 other elements) at the element is calculated from ϑ1, and if µA i/(n – 1) is greater than a random number, the element phase is set equal to the interaction phase. Once this has been completed for all n elements, the system amplitude and phase is calculated by converting each element vector to rectangular coordinates, adding the x- and y-components, and converting the result back to polar coordinates. hirty of these steps are combined to form a GroupStep by taking the average of the amplitude and phase, and 20 such GroupSteps form a single Run. For each set of parameter values, ten Runs are completed, and the mean and standard deviation of amplitude (and phase, but that is not yet relevant, as was explained earlier) for each GroupStep calculated. he result of a calculation for a system with 10 elements is shown in Figure 8.6, and Figure 8.7 shows the results for the same parameter values, but for a system of 100 elements. At this point, it may be appropriate to comment briely on the statistics involved in this and the previous two models and, indeed, in any model that considers the dynamics of stochastic processes of this nature. At each time step, the measure of system performance (correlation, coherence) changes in a “random” fashion. he word “random” has been put in quotes because it needs to be qualiied. If we understand “random” to mean “unpredictable,” then it applies to our models. But if we understand “random” to also imply “equally likely to lie anywhere within its range,” then this is not correct, and the reason is that there is a correlation between values of the stochastic variable that depends on the time interval between the values. In particular, if the rate of change of the variable (e.g., the failure rate λ) is comparable

144 n Designing Complex Systems

1.00

0.3500

0.90

0.3000 0.2500

Amplitude

0.70 0.60

0.2000

0.50 0.1500

0.40 0.30

0.1000

Standard Deviation

0.80

0.20 0.0500

0.10 0.00

0.0000 1

3

5

7

9 11 Time Steps

13

15

17

19

1.00

0.2000

0.90

0.1800

0.80

0.1600

0.70

0.1400

0.60

0.1200

0.50

0.1000

0.40

0.0800

0.30

0.0600

0.20

0.0400

0.10

0.0200

0.00

Standard Deviation

Amplitude

Figure 8.6 Mean (heavy line) and standard deviation of the amplitude for a system of 10 elements with λ = 0.0005 per unit time, µ = 0.02 per unit time, and n0 = n. The time step equals 30 units of time.

0.0000 1

3

5

7

9 11 Time Steps

13

15

17

19

Figure 8.7 The same calculation as in Figure 8.6, using the same parameter values, but for a system with 100 elements.

to or less than the inverse of the interval between values, then two adjacent values are increasingly likely to be equal. he efect of this is best demonstrated by a very simple example: Let x be a stochastic variable that is equally likely to have a value anywhere in the range 0 – 1, and let the probability of x changing its value in a unit time interval equal λ. Start out with x = 0.5, and step through time in unit

Maintained Systems

n

145

intervals, at each step generating a random number in the range 0–1 and checking if this number is less than λ. If yes, a new random number is generated and the value of x changed to it; if no, the value of x remains unchanged. For the moment, assume that λ = 1; then a very long sequence of (truly) random values of x is generated, say, 10,000 values, and the average value, which will be denoted by x 0, and the standard deviation, which will be denoted by σ1, can be calculated. As we know, as the number of steps in the sequence increases, these values are increasingly likely to lie increasingly close to the values x 0 = 0.5 and σ1 = 0.2887. Now, group the values of x into groups of n consecutive values (i.e., in the language of statistics, each group forms a “sample” from the original “population” of values) and form the averages of the values in each group; we end up with a new sequence of random numbers, but with only 1/n the number of members as compared to that of the original sequence. he average of these new values obviously remains equal to x 0, but the standard deviation takes on a new value, σn, and from basic sampling theory we know that σn = σ1/√n. So far so good; this is all very basic, but what happens as the value of λ starts to decrease from 1? he values of x within a group are no longer independent; indeed, if λ