Realizing Complex System Design (Anthony P. Ambler John W. Sheppard) (Z-Library)

Realizing Complex System Design The creation of complex integrated systems is, in itself, complex. It requires immense planning and a large team of people with diverse backgrounds based in dispersed geographical locations (and countries) supposedly working to a coordinated schedule and cost. The systems engineering task is not new, but recent scales most definitely are. The world is now capable of designing and manufac‑ turing systems whose complexity was not considered possible 10 years ago. While many are trained to think in terms of a complete system, where ‘everything’ is designed and produced by a single project team, today such systems involve integrating subsystems and components (which are also complex) that have been developed by other project teams. Inevitably, this introduces additional complexities, involving elements out of the direct control of the project, but which are essential to its overall success. In addition to traditional systems engineering topics of hardware and software design, testability, and manufacturability, there are wider issues to be contemplated: project planning; communica‑ tion language (an issue for international teams); units of measure (imperial vs. metric) used across members of the team; supply chains (pandemics, military action, and natural disasters); legal issues based on place of production and sale; the ethics associated with target use; and the threat of cyber‑ attack. This book is the first attempt to bring many of these issues together to highlight the complex‑ ities that need to be considered in modern system design. It is neither exhaustive nor comprehensive, but it gives pointers to the topics for the reader to follow up on in more detail.

Realizing Complex System Design Edited by Anthony P. Ambler and John W. Sheppard

Cover: www.shutterstock.com First edition published 2025 by CRC Press 2385 NW Executive Center Drive, Suite 320, Boca Raton FL 33431 and by CRC Press 4 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN CRC Press is an imprint of Taylor & Francis Group, LLC © 2025 selection and editorial matter, [Anthony P. Ambler and John W. Sheppard]; individual chapters, the contributors 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 acknowl‑ edged 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 pho‑ tocopying, 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, access www.copyright.com or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978‑750‑8400. For works that are not available on CCC please contact mpkbookspermissions@tandf.co.uk Trademark notice: Product or corporate names may be trademarks or registered trademarks and are used only for identification and explanation without intent to infringe. ISBN: 9781032036533 (hbk) ISBN: 9781032036601 (pbk) ISBN: 9781003188377 (ebk) DOI: 10.1201/9781003188377 Typeset in Times by codeMantra

v Contents Preface...............................................................................................................................................ix Editors ...............................................................................................................................................xi Contributors .....................................................................................................................................xii Chapter 1 An Overview of Complex System Design ....................................................................1 John W. Sheppard PART 1 System Planning Chapter 2 Requirements Types – Design and Test ..................................................................... 19 Satyajit “Sat” Ketkar and Jason Smith Chapter 3 Project Planning .........................................................................................................26 Lila Carden Chapter 4 System Decomposition ...............................................................................................36 Satyajit “Sat” Ketkar and Jason Smith Chapter 5 Systems Engineering Vee ........................................................................................... 41 Satyajit “Sat” Ketkar and Jason Smith Chapter 6 Economics of Design and Test ................................................................................... 55 Anthony P. Ambler Chapter 7 Cyber‑Physical Systems ............................................................................................. 62 Wm. Arthur Conklin Chapter 8 Logistics and Supply Chain Management ..................................................................68 Matthew Hu, Margaret Kidd, Zheyong Bian, Kailai Wang, Harjot Singh Pooni, and Suhaib Kaissi PART 2 System Design Chapter 9 Chip‑Level Design and Test ....................................................................................... 89 Mark McDermott

vi Contents Chapter 10 Board‑Level Design and Test ................................................................................... 118 Datong Liu, Dawei Pan, and Shengwei Meng Chapter 11 Power Distribution .................................................................................................... 135 Michael Seavey Chapter 12 Design Patterns and Reusability .............................................................................. 139 Clemente Izurieta Chapter 13 Test‑Driven Development ......................................................................................... 157 Madhusudan Srinivasan and Upulee Kanewala PART 3 System Analysis Chapter 14 Reliability ................................................................................................................. 171 Christian K. Hansen Chapter 15 Availability ............................................................................................................... 190 Christian K. Hansen Chapter 16 Maintainability .........................................................................................................209 David R. Carey Chapter 17 Performance Evaluation ........................................................................................... 218 Byeong Kil Lee Chapter 18 Optimizing Complex Systems Operation .................................................................230 William Ross PART 4 System Testing Chapter 19 Types of Testing .......................................................................................................249 Michael Seavey Chapter 20 Software Test ............................................................................................................ 247 Upulee Kanewala

viiContents Chapter 21 Error Handling ......................................................................................................... 257 Stephyn G. W. Butcher Chapter 22 Automated Test System Design ................................................................................269 David R. Carey Chapter 23 Interoperability and Design/Test Standards ............................................................. 276 Michael Seavey PART 5 System Health Chapter 24 Uncertainty and Uncertainty Propagation ............................................................... 283 Alessandro Ferrero Chapter 25 Fault Detection, Localization, and Isolation ............................................................ 298 Jason Rupe Chapter 26 Risk and Risk Analysis ............................................................................................ 317 Robert Taylor Chapter 27 Risk‑Based Prognostics and Health Management .................................................... 324 John W. Sheppard Chapter 28 Structural Health Monitoring ................................................................................... 341 Jamie Blanche, Ranjeetkumar Gupta, Daniel Mitchell, Sam Harper, and David Flynn PART 6 System Security Chapter 29 Risk Management Framework ................................................................................. 367 Derek Reimanis Chapter 30 Information Assurance, Vulnerability Analysis, and Remediation ......................... 383 William R. Simpson Chapter 31 Cryptographic Systems ............................................................................................402 Keith M. Martin

viii Contents Chapter 32 Software Security ..................................................................................................... 415 John Marchesini and Sean Smith PART 7 System Usage Chapter 33 Human System Interaction – Interface Design ........................................................ 441 Laura Stanley and Vishnunarayan Girishan Prabhu Chapter 34 Human and Privacy Rights ......................................................................................460 Razieh Nokhbeh Zaeem and K. Suzanne Barber Chapter 35 Humanitarian Well‑Being ........................................................................................ 476 Kristen Intemann Chapter 36 The Social Impacts of Complex Systems .................................................................484 Kristen Intemann Index .............................................................................................................................................. 493

ix Preface The creation of complex integrated systems is, in itself, complex. It requires immense planning and a large number of people with very diverse backgrounds based in dispersed geographical locations (and countries) supposedly working to a coordinated schedule and cost. Such a scenario is not new, but the scale most definitely is. The world is now capable of designing and manufacturing systems whose complexity was not considered possible 10 years ago. An individ‑ ual integrated circuit can be produced with a transistor count that surpasses that found in an entire product a decade ago, but today that same integrated circuit is only a part of a complete system. Consider the ‘complete’ system; it is also far easier to think in terms of a complete system where ‘everything’ is designed and produced by the project team. But the system will necessarily be produced using components already developed by other organizations that will need to be inte‑ grated into the new product. Inevitably, this will introduce significant perturbations in the attempt to control the creation of the new systems – parts out of the direct control of the project, but that are essential to its overall success. Of course, any project requires planning and project management, but the scales are literally unimaginable to a casual observer and necessitate a level of hierarchical project management and carefully applied oversight. Naturally, it depends on the application of the new system (domestic, industrial, or military), the scale/size (pocket calculator, smartphone, cellular phone network, satellite communication net‑ work, etc.), and even the laws of the producing nation, where the product is to be sold. Communication language is an issue for the project team. International projects where teams work in different languages is an obvious case, but even the languages used by different disciplines can lead to miscommunication and misunderstanding. If care is not taken in the project specifica‑ tion, even colleagues two desks apart might interpret the requirements sufficiently differently to cause a problem, neglecting the case where one team was working in imperial units and the other was assuming metric… very expensive and embarrassing! Of increasing importance is the issue of supply chain – with availability of materials, local mili‑ tary action, health pandemics, and critical infrastructure failures (e.g., blockage of the Suez Canal). Backup sources of components and materials are increasingly necessary. Integration of system functions and controls into single components makes testability and reli‑ ability an increasingly critical part of the design. The use of software, while extremely useful in reducing the size of the hardware, making the system more versatile, and allowing for continuous improvements, introduces immense scope for difficult‑to‑identify bugs, the introduction of viruses, and the threat of other forms of cyberattack, and that entails either economic/military/life‑safety issues. This book is the first attempt to bring many of the issues together to highlight the complexities that need to be considered in the modern world. The chapter list identifies many of the required topics. It is by no means exhaustive – possible future editions (!) may need to make huge additions to the material. This work is also not intended to provide all the information needed to implement a project team but gives pointers to the topics for the reader to follow up on in more detail. Note: the creation of complex systems is by no means purely technical  –  it embodies sales and marketing, creation of project definition commercial/military, division of the project into seg‑ ments for design and/or further segmentation across nations/companies/design teams, definitions of maintainability and repairability and speed of return‑to‑service, supply chain issues critical to both creation of systems and their use, final design, contracts, project design reviews, etc. But it is impor‑ tant not to overlook human factors in the design process, system use, and impact of the system on the environment. It is increasingly important for a significant proportion of those involved with the system creation to be at least aware of all these issues and the importance of their role in the overall

x Preface success (however measured). For this reason, many institutions of higher learning have been offer‑ ing graduate programs in engineering management for some time and have gradually been pushing some of the material into undergraduate programs. This book will serve not only as a textbook but as a reference and handbook for the practitio‑ ner. Because of this, very little “theory” will be included. It is aimed at graduate students, project managers, practitioners, and others who are embarking upon a modern complex project. It may also suggest to curriculum designers and licensing authorities to broaden the scope of education and professional requirements away from a narrow disciplinary direction. Finally, a note of thanks. When we set out to undertake this project, we had no idea that writing such a work would, in itself, seem to follow the process of realizing a complex system design. For us, the design was in the book organization itself. As with any complex design process, this means a large number of people played a variety of roles in making this happen. We begin by acknowledging and thanking the staff at Taylor & Francis for their guidance and support while this project unfolded, in particular Nora Konopka and Swapnil Joshi. We depended on their expertise to make sure the process would unfold as smoothly as possible, and they did not disappoint. This work also draws on a very large number of expert authors, bringing a variety of back‑ grounds and perspectives to the task at hand. Neither of the editors are experts in all areas of this book, so we relied on the expertise of these authors, not only to provide the content of the chapters, but to write in a way that could be integrated into a cohesive work and lead toward the same goal. Each of the authors is identified below, with their affiliations, but here we wish to say thank you. We also thank those who provided facility support or funding. Tony Ambler received facility support from the Provost and President of the University of Houston. John W. Sheppard received financial and facility support from Montana State University and from a variety of other sources, most notably the U.S. Navy, while completing this work. In fact, the project was initiated during a funded sabbatical from MSU. Finally, we thank our families, and without their support, this project would never have been completed. Anthony P. Ambler John W. Sheppard 2025

xi Editors Anthony P. Ambler is a fellow of the IEEE, elected ‘For contributions to economics of testing complex digital devices and systems’. His research interests are in test economics, system test, and diagnosis. He received his B.Sc., M.Sc., and Ph.D. from the University of Manchester Institute of Science and Technology. He was appointed to a chair in Test Technology at Brunel University (UK) and then moved to the USA. He became chairman of Electrical & Computer Engineering at the University of Texas at Austin, then dean of Engineering & Computing at the University of South Carolina, and recently as dean of Technology at the University of Houston. In addition to his research work, he created the MS degree program in Engineering Management at UT Austin. He has acted as chair of the Organizing Committee of the European Design and Test Conference, general chair and program chair of IEEE International Test Conference and of IEEE International Conference on Computer Design. He has created a number of Workshops including on Test Economics, System Test and Diagnosis, and Production Test Automation. John W. Sheppard is a Norm Asbjornson College of Engineering Distinguished Professor in the Gianforte School of Computing at Montana State University. His research interests include fault diagnosis/prognosis of complex systems, model‑based and Bayesian reasoning, explainable and eth‑ ical artificial intelligence, and distributed population‑based algorithms. He is a fellow of the IEEE, elected ‘for contributions to system‑level diagnosis and prognosis’. He received his BS in com‑ puter science from Southern Methodist University and his MS and PhD in computer science from Johns Hopkins University. Before entering academia full‑time, he was a member of the industry for 20 years where his prior position was as a research fellow at ARINC Incorporated. He has been a long‑time leader in the IEEE Standards Association, chairing several working groups focused on publishing standards related to complex system test and diagnosis. Previously, he also served as the “designated representative” from the IEEE Computer Society to the IEEE Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems.

xii Contributors Anthony P. Ambler College of Technology University of Houston Houston, Texas K. Suzanne Barber Center for Identity University of Texas at Austin Austin, Texas Zheyong Bian Supply Chain and Logistics Technology University of Texas at Austin Austin, Texas Jamie Blanche James Watt School of Engineering University of Glasgow Glasgow, United Kingdom Stephyn G. W. Butcher Whiting School of Engineering Johns Hopkins University Baltimore, Maryland Lila Carden Technology Division, Cullen College of Engineering Construction Management Department Technology Project Management Program University of Houston Houston, Texas David R. Carey Department of Mechanical and Electrical Engineering The School of Business and Engineering Wilkes University Wilkes‑Barre, Pennsylvania Wm. Arthur Conklin Information Science and Technology Cullen College of Engineering University of Houston Houston, Texas Alessandro Ferrero Department of Electronics Polytechnic University of Milan Milan, Italy David Flynn James Watt School of Engineering University of Glasgow Glasgow, United Kingdom Ranjeetkumar Gupta National Composites Centre Feynman Way Central Bristol, United Kingdom Christian K. Hansen Department of Mathematics Eastern Washington University Cheney, Washington Sam Harper James Watt School of Engineering University of Glasgow Glasgow, United Kingdom Matthew Hu Industrial Engineering University of Houston Houston, Texas Kristen Intemann Center for Science, Technology, Ethics, and Society Montana State University Bozeman, Montana Clemente Izurieta Computer Science | Software Engineering and Cybersecurity Lab (SECL) Gianforte School of Computing Montana State University Pacific Northwest National Laboratory & Idaho National Laboratory Joint Appointments Bozeman, Montana

xiiiContributors Suhaib Kaissi Supply Chain and Logistics Technology University of Houston Houston, Texas Upulee Kanewala School of Computing University of North Florida Jacksonville, Florida Satyajit “Sat” Ketkar Velentium Richmond, Texas Margaret Kidd Supply Chain and Logistics Technology University of Houston Houston, Texas Byeong Kil Lee Department of Elecrical and Computer Engineering University of Colorado Colorado Springs, Colorado Datong Liu School of Electronics and Information Engineering Harbin Institute of Technology Harbin, China John Marchesini Identity Automation Houston, Texas Keith M. Martin Information Security Group Royal Holloway, University of London Egham, United Kingdom Mark McDermott ECE Department University of Texas at Austin Austin, Texas Shengwei Meng School of Electronics and Information Engineering Harbin Institute of Technology Harbin, China Daniel Mitchell James Watt School of Engineering University of Glasgow Glasgow, United Kingdom Dawei Pan School of Electronics and Information Engineering Harbin Engineering University Harbin, China Harjot Singh Pooni Supply Chain and Logistics Technology University of Houston Houston, Texas Vishnunarayan Girishan Prabhu School of Modeling, Simulation and Training University of North Carolina at Charlotte Charlotte, North Carolina Derek Reimanis Gianforte School of Computing Montana State University Bozeman, Montana William Ross Department of Program Manager for Automatic Test Systems (ATS) Naval Air Systems Command (NAVAIR) Aviation Support Equipment Program Office Eagle Systems, Inc. California, Maryland Jason Rupe CableLabs Louisville, Colorado Michael Seavey Northrop Grumman Palatine, Illinois John W. Sheppard Gianforte School of Computing Montana State University Bozeman, Montana William R. Simpson Institute for Defense Analyses Alexandria, Virginia

xiv Contributors Jason Smith Growth & Communications Strategist Raleigh, North Carolina Sean Smith Department of Computer Science Dartmouth College Hanover, New Hampshire Madhusudan Srinivasan Department of Computer Science East Carolina University Greenville, North Carolina Laura Stanley Gianforte School of Computing Montana State University Bozeman, Montana Robert Taylor College of Business and Engineering Wilkes University Wilkes‑Barre, Pennsylvania Kailai Wang Supply Chain and Logistics Technology University of Houston Houston, Texas Razieh Nokhbeh Zaeem Centre for Identity University of Texas at Austin Austin, Texas

DOI: 10.1201/9781003188377-1 1 1 An Overview of Complex System Design John W. Sheppard This book is focused on the broad issues surrounding “realizing complex integrated systems.” What do we mean by this? It might be helpful to break down our title, one word at a time. To do this, we start at the end. What is a “system”? We start this introductory chapter by addressing that question. We pose a number of possible definitions and perspectives, but leave open the opportunity to con‑ sider the system from the target context where it will be used. Once we have a system in mind, we acknowledge the fact that this system needs to “integrate” a variety of pieces, components, and subsystems, in order for it to accomplish its task. Therefore, we concern ourselves with the boundaries and interfaces of different technologies and disciplines in order to determine how best to achieve that integration. Next we raise the specter that this integrated system is going to be “complex.” Complexity can be defined in a number of ways. For one, the sheer number of subsystems or components can be a mea‑ sure of complexity. Alternatively, we could consider the functions being performed by the system and how those functions interact with one another. Alternatively, we could consider computational aspects such as the amount of time or the amount of memory that may be needed to accomplish one or more tasks. The extent to which new behaviors might emerge from the system can also be regarded as an element of complexity. In the end, complexity is that characteristic of a system that defines the associated challenges along the life of the system, so in this book, we are concerned with how to go about managing that complexity. Finally, we suggest that “realization” refers to the process by which our complex integrated system moves from concept to deployment and subsequent support. It refers to the entire design, development, manufacture, deployment, operation, and support life cycle. Of particular interest here, however, is that we focus on systems that, by their very nature, are “complex.” In other words, we are interested in large, complicated, interacting beasts that are intended to perform difficult tasks and meet a wide variety of end‑user needs. 1.1 COMPLEX SYSTEMS 1.1.1 SyStemS Definition To begin our discussion of realizing the design of complex systems, we first must talk about what constitutes a system. There are a variety of definitions one could use, and to be sure, many of these definitions will apply here. The natural place to begin is with the dictionary. Here are two diction‑ ary definitions: Definition 1: (Oxford English Dictionary) A system is a set of things working together as parts of a mechanism or an interconnecting network; a complex whole (OED, 2018). Definition 2: (Merriam‑Webster Dictionary) A system is a regularly interacting or interde‑ pendent group of items forming a unified whole (Merriam, 2018).

2 Realizing Complex System Design A unifying theme in these two definitions is the notion of parts working together as a whole. Given this, we also consider definitions drawn from different sources focusing on systems engineering. Here are three. Definition 3: A system is the combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equip‑ ment, facilities, personnel, processes, and procedures needed for this purpose; that is, all things required to produce system‑level results. The results include system‑level qualities, properties, characteristics, functions, behavior, and performance (NASA, 2007). Definition 4: A system is an open set of complementary interacting parts, with properties, capabilities, and behaviors emerging, both from the parts and from their interactions, to synthesize a unified whole (Hitchins, 2007). Definition 5: A system is a set of interrelated components working together toward some common objective (Kossiakoff et al., 2011). The theme persists; however, we are now beginning to see the idea emerge that a system accom‑ plishes some function. If it fails to accomplish that function, then the system does not meet its purpose and is not useful. From an engineering perspective, this translates into the system failing to satisfy its requirements. From the perspective of one of the editors of this work, we also need to consider what we mean by “system” from the perspective of managing that system’s health. Thus, we need to consider how system health can be incorporated into the design process. To do so, we acknowledge that one of the added performance requirements for a system is that it needs to be able to be monitored in such a way that its health can actually be determined. However, a related issue in systems engineering arises from the fact that the systems, due to their interacting “qualities, properties, characteristics, functions, behavior, and performance” involve complexities that can make such monitoring prob‑ lematic. Using this observation, Sheppard and Simpson define a system in the context of system diagnostics as follows: Definition 6: A system is any aggregation of related elements that together form an entity of sufficient complexity for which it is impractical to treat all of the elements at the lowest level of detail (Sheppard and Simpson, 1998). One of the key drivers in any design activity is managing complexity. As the Sheppard and Simpson definition suggests, a system by its very nature has a level of complexity that makes full‑system analysis generally impractical. To support the design, analysis, and support of systems, we therefore need to employ carefully crafted design practices that draw on a variety of domains and disciplines. 1.1.2 SyStemS DomainS In a large number of engineering disciplines, system design is presented in a vacuum. Perhaps the three biggest exceptions would be industrial engineering, software engineering, and systems engi‑ neering. For our purposes, we approach the engineering problem from the systems engineering per‑ spective. Doing so, we recognize and affirm that successful system design must draw from a variety of domains, including the specific technical domain(s) within which the system is being developed. Kossiakoff et  al. (2011) suggested that the domains of systems engineering can be described like faces on a Rubik’s cube with each face of the cube representing a key domain (Figure 1.1). Specifically, they list the following domains as being central to systems engineering: • Engineering: Applies tools to support system design, such as computer‑aided design (CAD) tools, modeling and simulation tools, version control tools, etc.

3An Overview of Complex System Design • Technical: Incorporates the technical knowledge from the appropriate engineering disci‑ plines, such as electronics, embedded software, propulsion, materials, etc. • Management: Utilizes project management skills, such as scheduling, cost estimation, resource allocation, risk assessment, etc. • Legal: Focuses on issues surrounding contracting, generation of intellectual property, licensing, subcontracting, etc. • Human: Addresses interpersonal dynamics, team building, employment, etc.; could also be interpreted to include human factors engineering; however, this is better placed in the context of one of the technical disciplines. • Social: Assesses and influences the design in ways that make positive impacts on the world around us. Evaluates those impacts on societal, economic, political, and environmental factors. As one might expect, these “faces” are not independent. They interact in ways similar to the chal‑ lenges associated with solving the Rubik’s Cube. By turning one face, it can affect the neighbor‑ ing faces in unanticipated ways. Thus, systems engineering needs to apply rigorous, disciplined approaches at the intersection of these domains to ensure an effective engineering process. 1.2 SYSTEMS ENGINEERING In general, when one thinks about approaching an engineering design problem, they start by consid‑ ering the specific engineering discipline central to that design. Such engineering disciplines include electrical, civil, mechanical, computer, industrial, petroleum, chemical, biological, etc. Systems engineering, however, sits above these disciplines since it is focused on how to draw the technical aspects of several of these disciplines together to create a complete, integrated system. FIGURE 1.1 Systems engineering as a Rubrik’s Cube.

4 Realizing Complex System Design 1.2.1 DiSciplineS in SyStemS engineering To understand systems engineering, we can consider the Venn diagram in Figure 1.2. Here we see that the system design process draws from skills specific to systems engineering as well as the rel‑ evant engineering fields and technical management. In addition to these major disciplines, we also draw on the following sub‑disciplines, each of which lies at the intersection of these three areas. • Modeling and Simulation: Computer‑based models are developed to validate system per‑ formance and effectiveness as well as to determine whether or not specific requirements are being satisfied by the design. Modeling and simulation are usually employed by the engineering disciplines. • Operations Research: Systems design and engineering is a process that involves mak‑ ing decisions that trade, for example, specific performance characteristics with the cost to obtaining the desired performance. Operations research is a field devoted to optimal decision‑making and includes several areas relevant to system design, including financial engineering, decision analysis, and logistics and supply chain management. • Project Management: Developing a complex system is, by necessity, a team‑based process. To be successful, the systems engineering process draws on sound project and technical management to ensure the right resources are available to the team, proper com‑ munication occurs among team members, and schedules and deliverables are maintained. • Quality Assurance: Fundamentally, system or product quality depends on system/prod‑ uct health. Quality assurance applies design principles to maximize system quality and incorporates process monitors to ensure that quality is maintained. Technical debt, which is a measure of system quality, is a concept that has arisen in the software engineering discipline that captures the cost of trading strategic decisions in system design for tactical decisions (Allman, 2012). The marketing slogan for FRAM oil filters of “pay me now, or pay me later” is captured formally when estimating technical debt. For example, one of the first decisions in system design that increases technical debt (by increasing life‑cycle cost) is to delay addressing system test/system health requirements. The principal challenge in systems engineering and systems design is balancing various disciplines. Designing a system that meets a vast array of requirements, including functional requirements, reliability and availability requirements, performance requirements, packaging requirements, and FIGURE 1.2 Systems engineering fields.

5An Overview of Complex System Design system maintenance requirements, requires careful management and utilization of the right techni‑ cal resources. 1.2.2 SyStem DecompoSition One of the key elements in designing a complex system is arriving at an appropriate decomposition of the system into manageable parts. A variety of approaches have been developed to accomplish this. Generally, at the core of such decomposition, is a recognition that systems are often hierarchi‑ cal in nature. Systems are made up of subsystems, which are made up of sub‑subsystems and so forth until we get to the constituent parts. Reversing this, we can think of each of these intermediate steps as building blocks for the next level up in the hierarchy. Often, when considering how to decompose a system into its constituent building blocks, we need to consider both the physical decomposition and the functional decomposition. For example, consider a personal computer (PC) as our system. The PC system is decomposed physically into a monitor, keyboard, and computer, where the computer is then decomposed into a motherboard, a power supply, etc. Things start to get a bit murky in the hierarchy when we consider different types of cards and integrated circuits in the system. For example, should we regard a GPU that is plugged into the backplane at the same level as the CPU that is plugged directly into the motherboard? Each of them provides processing capabilities, but one is an IC and one is a card. This is when we run into the issues of functional decomposition. In the same PC, a CPU and a GPU provide similar functional capabilities (albeit differently), so, functionally, they may be con‑ sidered to be at the same level. However, consider a single dual in‑line memory module (DIMM). We may also wish to group several memory modules together by plugging them into multiple slots on the motherboard so as to form a functional unit corresponding to the computer’s random access memory (RAM). In this case, we cross the simple physical boundaries of individual DIMM cards and simply combine all of the memory ICs (and supporting circuitry) together. In modern systems, we also begin to blur the lines between hardware and software. A given function often requires both, so pure functional decomposition breaks down. Similarly, with the increased prevalence of using field programmable gate arrays (FPGA), the distinction between hardware and software blurs. This tends to drop us into the realm of hardware/software co‑design. Schaumont (2010) describes the hardware/software co‑design space where the intended application for the system being designed defines the design context. We can then think of different levels of complexity for different hardware architectures. For example, ranging from the general purpose reduced instruction set computer (RISC)‑based systems that provide maximum flexibility but mini‑ mum efficiency to application‑specific integrated circuit (ASIC)‑based systems that provide mini‑ mum flexibility but maximum efficiency, the software is integrated into the respective designs using a variety of programming languages and tools. Once the appropriate model of system decomposition is determined, the designer must then con‑ sider the nature of the interfaces between various system building blocks. The design of the hard‑ ware interfaces must consider physical constraints, pin layouts, and routing/connectivity with other system components. Software interfaces must consider the nature and type of data being passed between the components. Once again, these two domains become blurred when we are connecting hardware to software. For example, bus systems provide the physical backbone over which signals propagate within a system, and the signals encode the data to be transmitted. Different approaches exist for handling the hardware/software interface (Schaumont, 2010). The memory‑mapped interface uses memory within a microprocessor as the means for communication via load/instructions. The coprocessor interface employs a separate coprocessor port on a micro‑ processor as the means for using software to control the hardware. Finally, a custom‑instruction interface can be used to integrate custom, software‑controlled functionality directly into the micro‑ processor architecture.