arX

iv:1

608.

0094

4v1

[cs.

DC

] 2

Aug

201

6TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 1

Distributed or Monolithic?A Computational Architecture Decision Framework

Mohsen Mosleh, Kia Dalili, and Babak Heydari

Abstract—Distributed architectures have become ubiquitous inmany complex technical and socio-technical systems because oftheir role in improving uncertainty management, accommodatingmultiple stakeholders, and increasing scalability and evolvability.This departure from monolithic architectures provides a systemwith more flexibility and robustness in response to uncertaintiesthat it may confront during its lifetime. Distributed archi tecturedoes not provide benefits only, as it can increase cost andcomplexity of the system and result in potential instabilities.The mechanisms behind this trade-off, however, are analogous tothose of the widely-studied transition from integrated to modulararchitectures. In this paper, we use a conceptual decision frame-work that unifies modularity and distributed architecture o n afive-stage systems architecture spectrum. We add an extensivecomputational layer to the framework and explain how this canenhance decision making about the level of modularity of thearchitecture. We then apply it to a simplified demonstrationof the Defense Advanced Research Projects Agency (DARPA)fractionated satellite program. Through simulation, we calculatethe net value that is gained (or lost) by migrating from amonolithic architecture to a distributed architecture and showhow this value changes as a function of uncertainties in theenvironment and various system parameters. Additionally,weuse Value at Risk as a measure for the risk of losing the valueof distributed architecture, given its inherent uncertainty.

Index Terms—Modularity, fractionation, uncertainty, fraction-ated satellites, systems architecture, distributed architecture,computational systems architecture, complex systems, uncer-tainty management, modular open systems architecture (MOSA)

I. I NTRODUCTION

FOR many Engineering Systems, dealing with a growinglevel of uncertainty results in an increase in systems

complexity and a host of new challenges in design andarchitecting such systems. These systems need to respond toaset of changes in the market, technology, regulatory landscape,and budget availability. Changes in these factors are unknownto the systems architect not only during the design phase,but also during earlier phases, such as concept developmentand requirements analysis, of the system’s life cycle [1]. Theability to deal with a high level of uncertainty translates intohigher architecture flexibility in engineering systems whichenables the system to respond to variations more rapidly, withless cost, or less impact on the system effectiveness.

Mohsen Mosleh and Babak Heydari are with the School of Systems andEnterprises, Stevens Institute of Technology, Hoboken, NJ, 07093 USA (e-mail: mmosleh@stevens.edu, bheydari@stevens.edu).

Kia Dalili was with the School of Systems and Enterprises, Stevens Instituteof Technology, Hoboken, NJ, 07093 USA. He is now with Facebook Inc., NewYork, NY 10017.

This work was supported by Defense Advanced Research ProjectsAgency/NASA contract NNA11AB35C.

Distributed architecture is a common approach to increasesystem flexibility and responsiveness. In a distributed architec-ture, subsystems are often physically separated and exchangeresources through standard interfaces. Advances in networkingtechnology, together with increasing system flexibility require-ments, has made distributed architecture a ubiquitous themein many complex technical systems. Examples can be seenin many engineering systems: Distributed Generation, whichis an approach to employ numerous small-scale decentralizedtechnologies to produce electricity close to the end users ofpower, as opposed to the use of few large-scale monolithicand centralized power plants [2]; Wireless Sensor Networks,in which spatially distributed autonomous sensors collectdataand cooperatively pass information to a main location [3];and Fractionated Satellites, in which a group of small-scale,distributed, free-flying satellites are designed to accomplish thesame goal as the single large-scale monolithic satellite [4].

The trend towards distributed architectures is not limitedto technical systems, and can be observed in many social andsocio-technical systems, such as Open Source Software Devel-opment [5], in which widely dispersed developers contributecollaboratively to source code, and Human-based Computation(a.k.a. Distributed Thinking), in which systems of computersand large numbers of humans work together in order to solveproblems that could not be solved by either computers orhumans alone [6]. Despite the differences between the applica-tions of these systems, the underlying forces that drive systemsfrom monolithic, in which all subsystems are located in asingle physical unit, to distributed architectures, consisting ofmultiple remote physical units, have some fundamental factorsin common. For all these systems, distributed architectureenhances uncertainty management through increased systemsflexibility and resilience, as well as enabling scalabilityandevolvability [7].

In spite of the growing trend toward distributed architec-ture, studies concerning the systems-level driving forcesandcost/benefit analysis of moving from monolithic to distributedarchitecture have remained scarce1. These studies are essentialto decision models which determine the net value of migratingto distributed schemes. As we will argue in this paper and haveshown in our previous work [9], the fundamental systemicdriving forces and trade-offs of moving from monolithic todistributed architecture are essentially similar to thoseformoving from integrated to modular architectures. In both ofthese two dichotomies, increased uncertainty, often in the

1One attempt is [8]. However, the authors did not quantify costs/benefits oftransition from monolithic to distributed architecture based on systems-leveldriving forces.

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 2

environment, is one of the key contributors for pushing asystem toward moredecentralizedscheme of architecture, inwhich subsystems are loosely coupled. For example, considera processing unit. Depending on the relative rate of changeand uncertainty in the use, technology upgrade or budget, theCPU can be an integrated part of the system (e.g., Smartphone), becomes modular at discretion of the user (e.g.,PC), transitions to client-server architecture to accommodatesmoother response to technology upgrade, security threads, orcomputational demand, or migrate to a fully flexible systemwith dynamic resource-sharing (e.g., Cloud computing).

In this paper, we formulate these problems under theumbrella of the general concept ofmodularity. Modularityhas often been recognized as a general set of principles—asopposed to a mere design technique—that enhance managingcomplex products and organizational systems. Modularity inthe broadest sense of word, is defined as a mechanism tobreak up a complex system into discrete pieces that can theninteract with one another through standardized interfaces[10].This broad definition of modularity requires us to think ofmodularity as a continuous spectrum that includes a widerange of architectures which covers integrated, modular yetmonolithic, and distributed schemes. This framework can beused as a basis for computational methods for deciding aboutsystems architecture and flexibility calculations relatedtomodularity. We will use this broad definition of modularitytogether with the notion of a modularity spectrum to createa framework that can be used as a basis for computationalarchitecture decision methods and flexibility evaluation forsystems.

Engineers have long held the intuition that more decen-tralized schemes—i.e. higher levels of modularity—increasea system’s flexibility [11], [12]. They have used modularityfor complexity management in many domains, such as soft-ware [13], hardware architecture [14], the automotive industry[15], production networks [16], outsourcing [17], and masscustomization [18]. Furthermore, modularity has widely beenstudied and applied in organizational design and systemsarchitecture [19]; it has been argued that a loosely coupledfirm, in which each unit can function autonomously andconcurrently, can benefit from increasedstrategic flexibilitytorespond to environmental changes, due to reduced difficultyof adaptive coordination [20]. Proper use of modularity isalso argued to bring economies of scale, increase feasibilityof product/component change, increase product variety, andenhance product diagnosis, maintenance, repair, and disposal[21]. Finally, modularity is shown to help with increasingsystems flexibility and evolvability by reducing the cost ofchange and upgrade in the system on the one hand, andfacilitating product innovation on the other hand [14].

Despite these advantages of modularity, there are studiesthat show that many systems follow an opposite path towardmore integration, which suggest thinking about its downsidesand the underlying trade-offs [22], [23], [10], [24]. Whendiscussing such trade-offs, it is crucial to remember that mod-ularity is not a binary property but a continuum, representingthe degree of coupling between components of a system, anddescribes the extent to which a system’s components can

be separated and recombined [22]. The appropriate level ofmodularity is, among other factors such as technical designrequirements, determined by the flexibility required for thesystem to deal with the changes and uncertainties that thesystem confronts during its lifetime. The value that modularity,as a systems mechanism for managing uncertainty, adds tothe system has a diminishing return. Although a low degreeof modularity hampers response to environmental changes,over-modularity increases the overall cost of the system, givesrise to a host of potential problems at the interfaces. Hence,finding the appropriate level of modularity, correspondingtounderlying forces in the system’s environment, is a crucialstepin decision-making under uncertainty from the perspectiveofsystem architecture.

In this paper, we consider distributed architecture as apart of a modular architecture spectrum and analyze thetrade-offs associated with migrating from a monolithic to adistributed architecture for a real, yet simplified, case ofasatellite system that was a part of a demonstration for aDARPA/NASA program on fractionated satellites. We use aconceptual framework, developed in our previous work [9],to enhance architecture decisions according to the level ofcomposition or modularity for systems under uncertainty. Weadd an extensive computational layer to the framework, applyit in the context of space systems, and analyze the valueof design alternatives for various uncertainty parametersandsubsystems configurations. The proposed framework helps toidentify design alternatives based on the level of responsive-ness to environment uncertainty achievable by various levelsof modularity. This provides decision makers with systemicintuition when selecting and evaluating alternatives for agivenset of environment uncertainty parameters in the otherwiseintractable space of design alternative possibilities. Inorderto determine the value of moving toward more decentralizedschemes, we quantify the net gain in the value of the systemthat incorporates increased flexibility, and the associated costof adopting higher levels of modularity in the system. Tocompute this value, we add a stochastic simulation layer ontop of the proposed model that determines the conditions underwhich transition toward a distributed architecture is sensible.Results of this framework are calculated in the form of proba-bility distributions of the net value of an architectural change,to accommodate different decision makers with heterogeneousexpected costs or tolerance for risk.

The organization of the rest of the paper is as follows. InSection II, we describe the underlying conceptual systemsarchitecture framework [9] that is used in this paper, andexplain how it unifies modularity and distributed architectureon a five-stage spectrum and helps in selecting/evaluatingdesign alternatives. In Section III, we introduce the challengeof decision making for distributed architectures in spacesystems. In Section IV, we add a computational layer to theconceptual framework and build a mathematical model for asimplified case of satellite systems. Finally, in Section V,weillustrate and compare configuration alternatives for differentvalues of uncertainties in the environment and various systemparameters, and apply different measures, such as Value atRisk (VaR), for comparison.

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 3

•  System on a chip

!"#

!"#$"%&'()**+&,-."/01."%2&

!$#

3"45675#18*"&'9-."0-1*:()-4;5-1*2&

!%#

!5%)*10&'9-."0-1*:<$+#,41*2&

!&#

=.1;4>3,#.0,8)."%&'(014;5-1*:<$+#,41*2&

!'#

3+-16,4>3,#.0,8)."%&'(014;5-1*:()-4;5-1*2&

Decomposition Fractionation Splitting Resource sharing M+ Operation:

•  Smartphone

Mainboard •  PC Mainboard •  Client-server •  Cloud Computing

Fig. 1. Five-stage modularity and distributed architecture spectrum, and corresponding four M+ operations. Adaptability of the system increases as we moveright. Each operation assesses the aggregate value of moving one step for a given system, subsystem or component [9].

II. M ODULARITY AND DISTRIBUTED ARCHITECTURE

FRAMEWORK

In conventional systems engineering approaches, designalternatives are evaluated based on meeting requirements thatare derived from a set of probable scenarios, practical andtechnical limitations, and cost considerations. Requirement-driven approaches, by their very nature, are insufficient forassessing a system’s responsiveness to uncertainty. Unlessnon-functional requirements are explicitly quantified [25], onecannot use requirement-driven approaches to compare thegoodness of a more expensive design that exhibits smallercost growth when it faces an undesired uncertainty, vis-a-visa less expensive, yet inflexible design [4].

In this paper we use a value-centric design approach, whichhas been suggested as a way to overcome the shortcomingsof traditional approaches and to evaluate the flexibility ofdesign alternatives [26], [27], [28]. In this approach, thefocus is shifted from a requirement-centric to a value-centricperspective in which the designer compares the system netpresent value for different design alternatives over the lifetime.The system value may encompass costs and revenue streamsas well as the (real) option value of flexibility resulting frommodularity, scalablity, and evolvability [29].

Methods for deciding about systems architecture underuncertainty fall into two broad categories: Those that providea set of qualitative systemic intuition to select plausibledesignalternatives (e.g., [30], [31]), and those that take a fixed setof alternatives as input and determine theiroptimality basedon some exact methods (e.g., [32], [14]). In principle, onecan combine these two methods to first find a set of designalternatives based on systemic intuitions and then select themost appropriate one (see [33] for an example in spacesystems). However, this two-step process is not sufficientfor many problems where multiple iterations between thesetwo steps are needed. Under these circumstances, a unifiedframework that inherently includes both of these steps cansignificantly enhance the iterative process of nominating andselecting design alternatives.

As a unified framework, we employ a value-based decisionmaking framework developed in our previous work [9]. Thisframework is based on a systems architecture spectrum thatcovers a wide range of modularity/distributed architecture incomplex systems and classifies the degree of modularity intofive stages, as shown in Fig. 1. While in this paper we onlyevaluate transitions between stages in the framework, withineach stage, a continuous measure of modularity can be defined

depending on the specific problem and resolution needed,e.g., measures based on DSM for Modular (M2) systems [24]and network modularity index [34] for Dynamic-Distributed(M4) systems. The framework enhances systems architecturedecisions under uncertainty by limiting the search space topossible alternatives with various degrees of responsivenessto uncertainty. Selecting design alternatives from differentdefined stages in the architecture spectrum, together withquantifying the value of the transition from one stage toanother, effectively reduces the complexity of the designdecision problem and provides intuitions to systems architects.

The systems architecture framework [9] considers fivestages of modularity, indicated byM0 to M4. StageM0

describes fully integrated systems, in which components areconnected to each other in a way that neither physical norfunctional sub-parts can be identified, e.g., System on a Chip,in which several electronic systems are integrated into a singlechip.M0 is considered the minimum level of modularity andis the baseline in the modularity framework.M1 representssystems with identifiable sub-parts, each responsible for aspe-cific share of the overall system’s functionality. Componentsat this stage, although modular in function, cannot easily becustomized, replaced, or upgraded during later stages of thesystem’s lifecycle. Smartphone and tablet mainboards can beconsidered to be at this modularity stage.

At stageM2, similar toM1, functionalities can be brokendown and attributed to components. However, the relatedcomponents are connected to the rest of the system viastandardized interfaces. These standard interfaces allowthecomponents to be replaced or upgraded without disrupting therest of the system. As opposed to Smartphone mainboards,personal computers mainboards are at stageM2, which allowsusers to customize or upgrade components such as memoryand CPUs. WhileM0, M1 andM2 encompass all cases ofmodularization for monolithic systems—systems comprisedofa single physical unit—M3 andM4 cover systems with morethan one unit, in which communications between units is apossibility.

At M3, certain functionalities of the otherwise monolithicsystem are transferred to different, and often remote, physicalunits. Here, we refer to these units as systemsfractions. Afunction can be centralized in one or more fractions, creatinga client-server system in which a certain task can be delegatedby a majority of fractions that lack a certain functionality,to a fraction with a powerful version of that module. Acommunication channel is needed for pre-processed and post-

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 4

processed resources between the client units and the serverfraction. Client-server computation systems are an exampleof systems at stageM3. Unlike M3, in which the divisionof labor among subsystems is static, inM4, the task can bedynamically distributed among various fractions that havedif-ferent capabilities in terms of the required functionality. Cloudcomputing systems are an example of systems atM4. Thearchitecture of systems atM4 can be represented by complexnetworks models where nodes represent subsystems and edgesrepresent interactions between the subsystems (subsystems’heterogeneous parameters can be modeled by nodes’ attributesand heterogeneity of subsystems’ interactions can be modeledby weighted links and multi-layered networks) [35], [36].

Moving to distributed architectures (i.e.,M3 andM4) cre-ates a more adaptable system, but this extra adaptability andflexibility come at a cost and, under certain conditions, mayresult in instability. The reason behind the increased chance ofinstability is that distributed architectures require complex taskcoordination schemes to allocate resources under uncertaindemand and there are often many paths for resource exchangeas well as multiple feedback loops between the componentsin a system with high levels of modularity (i.e., Static-Distributed). Moreover, the chance of instability increasesfurther in systems with even higher levels of modularity (i.e.,Dynamic-Distributed), in which components have a level ofautonomy and their goals are not necessarily aligned with thatof the whole system.

Four M+ operations are defined in the framework thatrepresent transitions from one stage of modularity to the nextin terms of required changes in the system architecture andthe increased degree of modularity. In order to identify theoptimal modularity, we have to quantify and compare thevalue of the system prior to the operation, to the value ofthe system afterward. Such evaluation requires knowledge ofthe system and its environment. The value of the system ateach modularity level can be calculated via any of the standardsystem evaluation methods (e.g., scenario analysis, discountedcash flow analysis) and should consider technical, economicand life cycle parameters.

It is worth noting that decisions in the proposed frameworkare based on the aggregate economic value that modulararchitecture can add to a system by increasing the responsive-ness to environment uncertainty. Hence, the framework canbe used to evaluate design alternatives that are technicallyviable, given factors such as physical constraints or perfor-mance requirements. The proposed model can complement thecontext dependent deterministic approaches for deciding aboutmodular architecture.

III. C ASE STUDY: MONOLITHIC AND DISTRIBUTED

ARCHITECTURES IN SPACE SYSTEMS

Space systems are often required to deal with a large set ofuncertainties throughout their lifecycles, which in turn makesdesign decisions challenging and, in many cases, intractable,i.e., a large number of possible design alternatives shouldbe evaluated against myriad number of uncertainty scenarios.There are various sources of uncertainty for space systems

including technology evolution, demand fluctuation, launchfailure, funding availability, and changes in stakeholders’requirements. Accommodating most of these uncertainties inconventional monolithic designs would result in increasedcost and complexity. For example, in response to componentsfailure, the conventional approach either suggests extrememeasures of reliability or the use of redundant parts, bothof which result in higher mass, cost, and in most caseshigher power. Addressing other types of uncertainties, such aschanges in technology or stakeholder requirements, is eithernot possible, or requires unconventional and often costlymethods [37], [38].

As a result of these problems, systemic flexibility is neededto deal with the increased levels of uncertainty. New methodshave been suggested, based on flexible and adaptable design,that enable spacecraft systems to respond to uncertainty morerapidly and at a reasonable cost. One approach is to deploya constellation progressively, commencing with a small andaffordable capacity, which can be increased, as needed, instages by launching additional satellites and re-configuring theexisting constellation in orbit [39]. Another approach is toprovide on-orbit servicing, which makes various options, suchas service for life extension or upgrade, available after thespacecraft has been deployed [37]. However, physical accessto a space system is very expensive. Instead, software upgradesand changes of function can be performed through informationaccess to the space system, providing some level of flexibilityto address uncertainty [40]. Another approach to increasespace systems’ responsiveness is fractionated satellites, adesign concept in which modules are placed into separatefractions that communicate wirelessly to deliver the capabilityof the original monolithic system [29].

Due to the inherent flexibility that comes with distributedand networked architectures, fractionated spacecraft arecon-sidered a viable solution for accommodating uncertainty inspace systems. This is a departure from large, expensive,and monolithic satellite systems to anetwork of small-scaleand less expensive free-flying satellites that communicatewirelessly. In this architecture, a new fraction can be launchedto become part of the network of satellites without disruptionof the rest of the system. This option enables incrementaldevelopment and deployment, and increases system respon-siveness [41], [38].

To decide about the level of flexibility of space systemsarchitecture—e.g., through fractionation—one has to considerthe level of uncertainty and changes in the environmenttogether with the cost associated with responding to them.Fractionated architecture—as a flexible architecture—does notcome without cost and is not always the best choice forspace systems. If applied inappropriately, fractionationmayadd no value, increase the cost and complexity, and causeinstability due to multiple paths and feedback loops betweenfractions. Hence, one has to calculate and compare the systemvalue over its lifetime for different design alternatives andbalance it against the potential costs of each alternative,takinginto account the effects of design variables and environmentuncertainty parameters, to find the optimal architecture.

Several studies have investigated the value proposition of

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 5

!"#"$%&"'(")*+#'%,&"$#%-.")'

/$01'&2"'10(3,%$*&4')5"6&$31'

7"$*."'1%&2"1%-6%,'/0$13,%-0#'0/'&$%#)*-0#'

05"$%&0$''

8"$/0$1')&062%)-6'

)*13,%-0#''

9%,63,%&"'(*)&$*:3-0#'0/'

.%,3"'(*;"$"#6"'

9015%$"'.%,3")'0/'

%,&"$#%-.")'

<#.*$0#1"#&'3#6"$&%*#&4'

%#(')4)&"1'5%$%1"&"$)'

Fig. 2. Steps for generating and evaluating design alternatives

fractionated architecture in space systems [42], [41]. However,decisions about the level of fractionation are challenginganddepend on a wide range of system components’ characteristicsand the environment uncertainty parameters. On the one hand,some studies have investigated the systems-level trade-offs inthe transition from monolithic to distributed architecture forspace systems [8]. These studies have not operationalized thesystemic trade-offs in quantifying the value that is gained(orlost) in the transition from one level of flexibility to anotherat the component-level. On the other hand, a wealth of studieshave developed quantitative frameworks to perform tradespaceexploration that often generate (enumerate) a large numberof design alternatives and then evaluate them against a rangeof scenarios [43], [44], [45], [46], [47]. Without consideringthe systemic trade-offs (i.e., those of moving from monolithicto distributed architecture) in the selection and evaluationof design alternatives, these quantitative frameworks do notscale well for a large number of possible design alternativesand uncertainty scenarios. A unified framework can bridgetwo approaches to more effectively select and evaluate designalternatives.

In this paper, by developing computational aspects of themodularity and distributed architecture spectrum explainedin Section II, we combine the systemic intuition (i.e., howmodularity can improve system responsiveness to uncertaintyand what are the associated advantages/disadvantages) in se-lecting design alternatives with their quantitative evaluation.This approach can enhance decision-making about systemsarchitecture by providing insights about the transition fromone level of system flexibility to another and aids in selectingand evaluation of different alternatives. The proposed approachcan complement existing methodologies for assessment ofthe value of flexibility in systems architecture design underuncertainty (e.g., [26], [48], [49]) by integrating the role ofmodularity in improving the system flexibility into the model.For example, the method suggested in [48] is based on afour-phase procedure (estimating the distribution of futurepossibilities, identifying candidate flexibilities, evaluating andchoosing flexible designs, and implementing flexibility), yet

it does not consider the level of modularity (composition) ofdesign alternatives neither in identifying the candidatesnor inevaluating them.

We apply this approach to a case of space systems in whichmonolithic satellite systems and fractionated satellitescan be,respectively, considered to be at levels of modularityM2 andM3 in the architecture spectrum inspired by a general notionof modularity. Hence, we can apply the operationM2 →M3

for calculating the value of distributed architecture and graphit against different parameters. To accommodate stakeholders’risk tolerance, we use Value at Risk as a measure for the risk oflosing the value of distributed architecture. In this case study,we particularly compare monolithic (M2) and fractionated(M3) architecture. However, the proposed framework can alsobe used to evaluate the transition from fractionated to dynamic-distributed architecture (e.g., Federated satellites [50] andEarth observation sensor web [51]) in space systems usingthe operationM3 →M4.

The steps we took in calculating the value of distributedarchitecture are given in Fig. 2. First, we generate designalternatives based on the proposed modularity spectrum, i.e.,M2 andM3. Next, we derive the mathematical formulation ofthe transition operator. In our case we calculate the probabilitydistribution of replacements for subsystems as well as theassociated costs for each design alternative. Next, we run astochastic simulation based on the environment uncertaintyand the system parameters to find the probability distributionof the value of the transition. Finally, we compare and evaluatedesign alternatives based on economic measures such as Valueat Risk.

IV. COMPUTING VALUE OF DISTRIBUTED ARCHITECTURE

In this section, we calculate the value of distributed archi-tecture and illustrate it for a particular case in satellitesystems,based on a simplified variation of fractionated architecturedeveloped as part of System F6 [53], [52]. We assume asatellite system that processes the data collected by a sensorpayload and transmits them to earth via a high-speed downlink.Moreover, a data connection link from Earth can be estab-lished for maintenance purposes. In a conventional design,all of the subsystems are integrated and have to be launchedtogether. However, in the fractionated design, subsystemscanbe separated in flying fractions and launched independently.The conventional monolithic system is at levelM2 and thefractionated system is at levelM3 in the five-stage architecturespectrum introduced in Fig. 1.

Subsystems communicate internally through the spacecraftbus, which also supplies power to the subsystems. The type(and cost) of a spacecraft bus is determined by the totalmass of the subsystems it supports. Fractions communicatethrough an extra Tech Package (F6TP, in the case of SystemF6) that enables wireless communications among fractions.The subsystems involved in our analysis are as follows:(1) Payload: a sensor, (2) Processor: a high performancecomputing unit, (3) Downlink: a high-speed downlink fortransmitting data to earth, (4) Communications module: abroadband access to a ground network through Inmarsat I-4

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 6

Bus0

Bus1

F6TP

Bus3

DL F6TP

Bus2

PL F6TP

Bus4

CM F6TP

PR

PL

DL

CM

PR

(a) (b)

Fig. 3. (a) Monolithic satellite system (b) Fractionated satellites system, PR: Processor, DL: Downlink, CM: Communications Module, F6: F6TP, PL: Payload[52].

TABLE ICOMPONENT COST, MASS, AND RELIABILITY PARAMETERS .α IS THE

SCALE PARAMETER ANDβ IS THE SHAPE PARAMETER OF THEWEIBULL

DISTRIBUTION THAT REPRESENTS SUBSYSTEMS RELIABILITY(MON.:MONOLITHIC, FRAC.: FRACTIONATED, PR: PROCESSOR, DL: DOWNLINK ,

CM: COMMUNICATIONS MODULE, F6: F6TP, PL: PAYLOAD )

Component α β Cost(K$) Mass(kg)Payload 15 1.7 27,000 50Communications 870 1.7 35,000 70Downlink 190 1.7 40,000 10Processor 90 1.7 30,000 20F6TP 600 1.7 2,000 5Bus (Mon.) 108 1.7 34,000 260PL Bus (Frac.) 108 1.7 28,000 180CM Bus (Frac.) 108 1.7 29,000 200DL Bus (Frac.) 108 1.7 25,000 150PR Bus (Frac.) 108 1.7 26,000 160

GEO constellation, (5) Bus: spacecraft bus that accommodatessubsystems on board, and (6) F6TP: F6 Tech Package thatenables the communications between the fractions while flyingin formation.

Fig. 3 shows the conceptual arrangement of subsystems forthe monolithic system and a possible allocation of subsystemsfor a fractionated configuration. In Fig. 3a, all of the subsys-tems are integrated and communicate internally through thebus without requiring an F6TP. In Fig. 3b, however, each ofthe four main subsystems is located in a separate fraction,along with a bus and an F6TP.

A. Value of distributed architecture

In the analysis of this case, we compare the value ofsystems with different architectures, composed of similarmainsubsystems, that fulfill the same overarching goal. Moreover,we assume the systems have to function at an acceptable levelof performance until the end of the project lifetime. Hence,one way to quantify the value difference between two systemsis to compare the cost of designing, building, launching andoperating them over a fixed project lifetime. Particularly,inour case, we calculate the value of distributed architectureas the difference in cost of running a fractionated systemversus the monolithic system. Note that the value of distributedarchitecture could potentially be much higher than what isobtained through the method presented here, as distributedarchitectures also enable scalability and evolvability inthelong run. As a result, this method is a conservative approach,especially in the long run and the net value calculated here

can be considered as a lower bound for a given set of systemparameters.

Since we assumed that the system has to function to theend of the project lifetime, we can calculate the cost ofrunning a system as the total cost of building and launchingits fractions in the beginning of the project and the costof replacing them, given uncertainty over the lifetime. Wedo not consider component costs that are identical for botharchitectures, e.g., subsystem design cost. We also assumethat the cost of building and the mass of a fraction are equalto the sum of its subsystem costs of building and masses,respectively. Additionally, we assume a linear launch cost,proportional to the total mass of the fraction.

It is worth noting that the case study is intended to showhow the proposed framework can be applied to a real-worldsystem and present the trade-offs of distributed versus mono-lithic architecture for different possible distributed architec-ture designs. To this end, we used typical values for spacesystems and made few simplistic assumptions. For example,we did not consider the integration cost, however, this canbe integrated into the model as an additional cost for eachsubsystem, which results in a shift in the value curve of designalternatives. Additionally, we assumed linear launch costanddid not consider common costs in comparing the value oftwo systems. Although these could substantially change thenumerical results of our illustrative case, the model can beeasily extended to take more realistic assumptions to studyaparticular real-world system.

B. Modeling uncertainty

We take into account technological obsolescence and sub-system failure as two uncertainties that may affect the systemover the lifetime. Other uncertainties can be integrated intoour model in a similar way. We assume that the uncertaintieshave known probability distributions that can be approximatedfrom historical data. We classify launch failure and in-orbitcollisions as bus failure so the failure of each subsystemwill be only attributed to its own reliability parameters andwe assume that subsystem failure times are independent. Inaccordance with [29], we use the Weibull probability distri-bution for subsystem failure with probability characteristicspresented in Table I. For technological obsolescence, we use aLog-normal distribution and assume subsystem obsolescencetimes are independent. We assume that a subsystem has to

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 7

be replaced when it fails or becomes obsolete in the sensethat a new technology is introduced and the subsystem hasto be upgraded through replacement in order to receive thebenefits of the new technology. We do not consider factorssuch as market competition, demand, and performance levelin the decision for replacement of obsolete subsystems.

We calculate the probability density function (PDF) ofreplacement time for subsystems as follows. Suppose obso-lescence time and failure time of subsystemi are given bythe random variablesOi andFi, respectively, and the randomvariableTi denotes time of replacement. The PDF,gi(t), andCDF (cumulative distribution function),Gi(t), of replacementtime for subsystemi can be calculated as follows:

Gi(t) = p(Ti ≤ t) = 1− p(Ti > t)

= 1− p(Oi > t, Fi > t)

= 1− p(Oi > t)p(Fi > t)

= 1− (1− Φi(t))(1 −Ψi(t)).

(1)

Differentiating both sides of Eq. 1 yields the following:

gi(t) = ϕi(t)(1 −Ψi(t)) + ψi(t)(1 − Φi(t)) (2)

whereΦ andϕ are the CDF and PDF for obsolescence time,respectively, andΨ andψ are the CDF and PDF for failuretime, respectively.

C. Value at Risk

In this study, we incorporate the perspective of a singlestakeholder and the risk-taking thresholds. Given the uncer-tainty of the input parameters, the deterministic presentationof each alternative value (e.g., expected value) is not sufficientfor decision makers. A decision maker might prefer a highercost solution with a lower risk to a lower cost solution with ahigher risk. Hence, the result of the model will be presentedin the form of the probability distribution of the net value ofchanges of a distributed architecture compared to its equivalentmonolithic architecture.

As a measure for risk in evaluating alternatives, we useValue at Risk (VaR), a commonly-used measure for the riskof loss of an uncertain value in financial risk management, aswell as in many non-financial applications [54]. For a givenuncertain value, time horizon, and probabilityp, the 100p%VaR is defined as a threshold loss measure, such that theprobability that the loss over the given time horizon exceedsthis figure isp [55].

For each comparison of alternatives, we obtain the distribu-tion of the system’s value over the given lifetime. Next, we finda threshold below which the area under the distribution curverepresents 100p% of the whole area under the curve. Here,p

is the probability that the fractionation value falls belowthethreshold.

V. RESULTS AND DISCUSSIONS

In this section, we calculate the probability distributions ofthe cost of operating a system with a distributed architectureand that of an equivalent monolithic system over a givenlifetime. This calculation is based on the cost of building and

launching subsystems and the probability distributions oftheirreplacement times.

In a distributed architecture, a fraction has to be deployedand launched once one of its subsystems requires replacement.Similarly, for a monolithic architecture, we can consider asystem with only one fraction such that the whole systemhas to be replaced if one of its subsystems becomes obsoleteor fails. Hence, in order to find the value of a distributedarchitecture, we can compare the cost imposed by each sub-system replacement in a distributed architecture with thatofan equivalent monolithic architecture over the project lifetime.Note that we assume the revenue which is generated bydifferent distributed and monolithic design alternativesis thesame and we only calculate the cost of operating the system.Calculating the revenue generated by each design alternativerequires modeling the market uncertainty, the feedback of thesystem to its market, and the system scalability.

We formulate the cost of running the system as follows.For each fractionj, suppose a sequence of random variablesR1j , R2j , . . . , Rnj represents the time between two consecu-tive replacements. A new instance of a fractionj has to bedeployed at timesR0j = 0,

∑1

i=0Rij , . . . ,

∑n

i=0Rij for the

system to function without interruption until the end of itslife-time, wheren is the largest integer such that

∑n

i=0Rij < T ,

where T is the project lifetime. Suppose that the cost ofbuilding and launching a new instance of a fractionj is CFj .The cost of running a system,C, with m fractions is the totalcost of replacing its fractions, discounted to present time.

C =CF1

n∑

i=0

e−r

∑

i

k=0Rk1 + CF2

n∑

i=0

e−r

∑

i

k=0Rk2+

· · ·+ CFm

n∑

i=0

e−r

∑

i

k=0Rkm .

(3)

We use simulation to calculate the cost of running two sys-tems with different architectures under similar conditions forsubsystem replacements. For each incident of replacement ofa subsystem, we calculate the associated cost of each architec-ture. Note that the probability of replacement for subsystemsthat are located in a fraction are dependent. Hence, once asubsystem in a fraction is replaced, we reset the replacementtimes for other subsystems in that fraction. Our simulationsetup is as follows. First, we sample subsystem replacementtimes based on their probability distribution. Next, we findthe subsystem with the earliest replacement time and calculatethe cost associated with its replacement in each architecture.Next, we update the replacement time for the subsystemsthat are affected by the replacement. We continue this foreach architecture until the earliest replacement time is greaterthan the lifetime. Finally, for each run of the simulation, wecalculate the cost of running each system and discount it to thepresent time. Repeating this process a large number of timesyields an approximation of the costs of running a distributedarchitecture and the equivalent monolithic architecture.

In our simulation, we use typical values for analysis ofsatellite systems according to [29]; however, the same sim-ulation approach can be applied for a more specific case.

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 8

Fig. 4. Total cost of monolithic (M2) vs. fractionated (M3) architecturediscounted to present time graphed against project lifetime for 10,000 trials.The curves represent expected values, and the boxplots depict quartiles of thecost.

The input to the simulation includes subsystem costs, masses,and failure and obsolescence probability distribution param-eters. Table I shows the estimates for costs and masses ofthe main subsystems (e.g., Payload, Communication module,and Downlink), F6 Tech-Package and spacecraft buses thataccommodate subsystems on board. The values for spacecraftbuses are based on commercially available spacecraft buses,which are chosen according to the subsystems on board andtheir total masses.α and β in Table I respectively representthe scale parameter and the shape parameter of the Weibulldistribution2 for subsystem failure. We assume a mean valueof 1 year3 with a standard deviation of 3 years for the obso-lescence probability distribution. We also assume that busesand F6TP do not become obsolete. Moreover, we consider$30k per kg for launch cost, which is the average cost forcommercially available launch vehicles [56]. The discountrate in our simulation is 2%, which is based on a forecastof real interest rates from which the inflation premium hasbeen removed and based on the economic assumptions from2014 for 30+ year programs [57]. We run our simulation fora project lifetime of up to 30 years, which is well beyondthe standard design lifetime of 10 years [29]. All simulationresults are based on 10,000 trials.

A. Comparing fractionated and monolithic satellite systems

Fig. 4 illustrates the cost of operating a fractionated satellitesystem, in which each main subsystem is assigned to aseparate fraction, and that of a monolithic system. All costs are

2The PDF and CDF of the Weibull distribution are as follows:

f(x) =

{

βα( xα)(β−1)e−(x/α)β x ≥ 0

0 x < 0

F (x) =

{

1− e−(x/α)β x ≥ 0

0 x < 0

3This is based on the assumption that in modular and fractionated satellitesystems, computational and sensing subsystems will most likely be silicon-based whose obsolescence follows Moores law.

Fig. 5. Probability distribution for the value obtained through transition fromM2 (Integral) toM3 (Fractional) in the modularity and distributed spectrum,i.e., project lifetime = 15 years. The vertical line at 0 represents Value at Risk55% is 0, meaning that area to the left represents 55% of the total area underthe curve.

discounted to present time. The curves in Fig. 4 represent theexpected cost of each architecture during the project lifetime.The curves have relatively low slopes in the beginning of thesystem lifetime, due to the low probability of obsolescenceand failure in the early years. The initial cost of runningthe fractionated system is greater than that of the monolithicsystem due to fractionation cost, i.e., the cost of buildingadditional subsystems, such as F6TP. However, the expectedlifetime cost of the monolithic system increases faster overtime because the whole system must be deployed and launchedonce again when a subsystem fails or becomes obsolete.

The boxplots in Fig. 4 depict the probability distributionof cost for every 3 years. The cost variance at each pointis the result of two opposing forces. On the one hand, theintrinsic property of the underlying stochastic process resultsin an increase of cost variance by time. On the other hand,over the project lifetime, whenever a subsystem is deployedand launched due to failure or obsolesce, the time to replaceitis also reset, which reduces the cost variance. In the monolithicarchitecture, when a component fails, the time of replacementfor the whole system is reset with a high cost. However, in thecase of failure of the equivalent component in the fractionatedarchitecture, the times to replace the other components do notchange. Instead, a failure results in a lower cost. Fig. 4 showsthat the cost variance for the two systems increases by time.However, the monolithic architecture has a higher varianceinevery time step. This is due to the dominance of the impactof costs associated with each subsystem replacement incident.

Fig. 5 depicts the probability distribution of the value ofa distributed architecture having each main subsystem in aseparate fraction atT=15 years. As a measure of value lossunder uncertainty, we use Value at Risk (VaR). As depicted inFig. 5, forp = .55 the net positive gains in transitioning fromM2 to M3 is positive, meaning that there is a 0.55 probabilitythat the value of distributed architecture falls below zero.

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 9

TABLE IIVALUE OF DISTRIBUTED ARCHITECTURE FORDIFFERENTPAYLOADS (EV: EXPECTEDVALUE , VAR: VALUE AT RISK, p = .25)

year 5 year 10 year 15 year 20 year 25 year 30Cost(K$) Weight(Kg) EV VaR EV VaR EV VaR EV VaR EV VaR EV VaR

Payload 1 31,652 230 -73 -96 -38 -96 -8 -96 20 -85 45 -66 67 -50Payload 2 34,132 260 -66 -96 -21 -96 18 -96 54 -64 87 -45 118 -26Payload 3 40,332 335 -58 -96 4 -96 57 -96 106 -50 150 -17 190 10.13

B. Effects of payloads’ attributes on system value

In this section, we run the simulation for different pay-load attributes and calculate the probability distribution ofthe value that is obtained in transition from monolithic todistributed architecture. Table II shows the effect of payloadcharacteristics (i.e., cost and weight) on the value of distributedarchitecture. For each payload, Table II shows the expectedvalue (EV) and Value at Risk (VaR,p=0.25) of the value ofdistributed architecture every five years in the project lifetime.Payload 1, Payload 2, and Payload 3 are progressively heavierand more expensive. The results in Table II show that for agiven moment in time during the project lifetime, distributedarchitecture creates higher value for a system with a moreexpensive payload and higher mass. It can be observed that adistributed architecture does not add any value to the systemwith Payload 1 in the first half of the lifetime (e.g., EV=-8@year=15). However, it does add value earlier in the lifetimeof the system with Payload 2 (e.g., EV=18 @year=15) andPayload 3 (e.g., EV=4 @year=10). Table II shows that, inthis case, a distributed architecture is a better choice formoreexpensive payloads with higher masses over a shorter lifetime,all other things being equal. This is because in a monolithicsystem with an expensive payload, a failure in any subsystemwill result in replacement of the payload, which imposesa high cost on the system. However, in the fractionatedsystem, the payload is only replaced once a component inthe payload’s fraction—e.g., F6TP, bus or the payload itself—fails or becomes obsolete. Hence, when the payload is moreexpensive, the cost of fractionation is dominated by the savingsdue to elimination of unnecessary payload replacements in thefractionated architecture.

C. Effects of F6TP’s reliability parameters on system value

Since F6TP is an additional subsystem required for com-munications between fractions in a distributed architecture, itis important to analyze how its parameters affect the valueof a distributed architecture. Fig. 6 shows the effects ofthe F6TP reliability parameters on the value of distributedarchitecture for the project lifetime of 15 years. In this figure,β is the shape parameter of the Weibull distribution that iscommonly used in modeling satellite reliability. A Weibullshape parameter greater than one represents an increasingfailure rate or “wear-out”.β = 1.7 is a typical value inmodeling reliability of satellites [58]. The value of distributedarchitecture is highly sensitive to F6TP reliability parametersfor its shorter average lifetime. The curves which belong tohigher values ofβ represent higher increase rate of the valueof distributed architecture against the F6TP’s average lifetime.For a given shape parameter, when the average lifetime of the

Fig. 6. Effects of F6TPs reliability parameters on value of distributedarchitecture (i.e., project lifetime=15 years).

F6TP is short, there will be a huge cost to keep the systemfunctional, due to the large number of replacements of wholefractions resulting from the F6TP failure and a monolithicarchitecture is always superior, as expected. Therefore, F6TP’saverage lifetime has to be above a certain threshold so thatfractionation is sensible. Moreover, beyond a certain value ofthe F6TP’s average lifetime (e.g., 100 years forβ = 1.7),the value of fractionation is not much affected by the F6TP’sreliability parameters because the number of replacementsof F6TP due to failure is negligible in the given lifetime(i.e., F6TP’s average lifetime is much greater than the projectlifetime).

D. Comparing design alternatives with different distributionsof subsystems

Distributed architecture (levelM3 in the proposed spectrum)includes a range of architectures with different numbers offractions and allocations of subsystems. In this section, westudy the effect of subsystem allocation on the value offractionation. In our case, there are 15 (B4 = 15 [59]) possi-ble allocations of subsystems into fractions. We demonstratethe comparison of design alternatives for four architectures(including the monolithic architecture) with different numberof fractions. However, the same analysis can be applied toall possible alternatives with the model being fairly tractable.We compare the fractionation value for the three architecturesdepicted in Fig. 7 based on the monolithic equivalent archi-tecture.

The architecture in Fig. 7a has two fractions. The Processorand Payload are placed in one, and the Communications mod-

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 10

TABLE IIIVALUE OF DISTRIBUTED ARCHITECTURE FORDIFFERENTNUMBER OF FRACTIONS FOR THE CONFIGURATIONS GIVEN INFIG. 7 (EV: EXPECTED

VALUE , VAR: VALUE AT RISK, p = .25)

year 5 year 10 year 15 year 20 year 25 year 30EV VaR EV VaR EV VaR EV VaR EV VaR EV VaR

Architecture (a) -15 -34 11 -34 34 -50 54 -53 74 -51 92 -46Architecture (b) -44 -68 -10 -68 18 -68 47 -68 71 -65 94 -50Architecture (c) -72 -102 -29 -101 11 -102 45 -73 76 -55 106 -35

ule and Downlink are placed in another fraction. Fig. 7b de-picts a system with three fractions. The Payload and Processorare in their own fractions, while Communications module andDownlink are located together in the same fraction. Finally,Fig. 7c represents a system in which each subsystem is placedin a separate fraction.

We calculate the probability distribution of the value oftransition from monolithic to distributed architecture for eacharchitecture independently and compare the results. The ar-chitectures in Fig. 7 are progressively—from a to c—moreflexible but more expensive to build. Table III shows theexpected value (EV) and Value at Risk (VaR,p=0.25) of thedistributed architecture every five years in the project lifetimefor the systems conceptually depicted in Fig. 7. For eachfraction in these architectures, we estimated mass and costof the spacecraft bus based on the total mass of subsystemsthat are on board and according to commercially availablespacecraft buses.

Table III shows that systems with a larger number offractions have a lower value in the earlier years of theirlifetime. This is due to the dominance of high fractionationcost in the beginning of the lifetime—i.e., the higher cost oflaunching more fractions and the cost of additional subsys-tems. However, later in the system lifetime, the value of adistributed architecture in the systems with a larger number offractions outgrows that of systems with a smaller number offractions. This shows that the benefits of responsiveness ofthesystem with a larger number of fractions becomes dominantover a longer lifetime. The results in Table III demonstratethetrade-off between higher flexibility and its associated costsi.e., higher flexibility results in less cost in responding toenvironment uncertainty, yet making the system more flexibleis costly. The results suggest that for projects with longerexpected lifetime, it is worth investing on the flexibility ofthe system through higher number of fractions.

VI. CONCLUSION

Building on a conceptual systems architecture frameworkin this paper, we developed a computational approach fordecisions about the level of modularity of system architecture.We quantified the value that is gained (or lost) in the transitionfrom a monolithic system architecture to a distributed systemarchitecture. We applied this approach to a simplified case ofa space system, and compared the value difference betweenthe two architectures as a function of uncertainties in varioussystem and environment parameters, such as cost, reliability,and technology obsolescence of different subsystems, as wellas the distribution of subsystems among fractions. We usedValue at Risk, a commonly-used measure for the risk of

!"#$%

&'% ()%

(a)

&*%

!"#+%

,-% ()%.*%

!"#$%

()%&*%

!"#+%

,-% ()%.*%

!"#$%

()%&'%

!"#$%

()%&*%

!"#$%

()%&'%

!"#$%

()%.*%

!"#$%

()%,-%

(b) (c)

Fig. 7. Allocation of subsystems between fractions together with the numberof fractions in Table III, (a) two fractions, (b) three fractions, (c) four fractions(PR: Processor, DL: Downlink, CM: Communication Module, F6: F6TP, PL:Payload)

loss of an uncertain value, to accommodate the stakeholders’threshold of risk.

Distributed architectures—and in the case study of thispaper, fractionated satellites—also increase scalability andresilience and foster innovation. For example, to accommodateuncertainty in the demand, additional modules can be launchedthroughout the lifetime of the system and become part of it.Similarly, upon failure of a module the fraction can evolveso that the system continues to function. None of theseadvantages were explicitly considered in assessing the value offractionation in our model, which was focused solely on flex-ibility and uncertainty management. Ignoring these additionaladvantages, our proposed approach represents a lower boundfor the value that is obtained in the transition to distributedarchitecture for the given set of system parameters. We alsobelieve that resilience mechanisms can, in theory, be modeledand integrated into the proposed framework. However, theeffect of architecture on scalability needs to be modeled byconsidering the feedback of the system to its market, some-thing that requires an additional layer on top of the proposedframework. Quantifying the impact of distributed architectureon creativity mechanisms is even more challenging due to aneed to simultaneously integrate technological, behavioral, andeconomic factors into the model. Thus, it is often best to keepmodels of these systems features semi-qualitative and separatefrom flexibility models, unless the exact context and path ofthe system is known. This is rarely the case and often defeatsthe original purpose of moving toward distributed architecturesin the first place.

Additionally, in this paper we used a single criteria stochas-tic decision model under uncertainty to find the architecturethat optimally respond to the uncertainty in the environ-ment. Future research is needed to integrate multiple criteriaand multiple stakeholders decision models into the proposedmodel.

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 11

ACKNOWLEDGMENTS

The authors would like to thank DARPA and all the gov-ernment team members for supporting this work as a part ofthe System F6 program. In particular, we would like to thankPaul Eremenko, Owen Brown, and Paul Collopy, who leadthe F6 program and inspired us at various stages during thiswork. We would also like to thank Steve Cornford from JPLfor his constructive feedback at various stages of this project.Our colleagues at Stevens Institute of Technology, especiallyDr. Roshanak Nilchiani, were a big support of this project. Wewould also like to thank other members of our research group,Complex Evolving Networked Systems lab, especially PeterLudlow, for various comments and feedback that improvedthis paper.

REFERENCES

[1] B. Heydari and K. Dalili, “Optimal system’s complexity,an architectureperspective,”Procedia Computer Science, vol. 12, pp. 63 – 68, 2012.

[2] “Distributed generation—educational module,”http://www.dg.history.vt.edu/, accessed: 2016-1-11.

[3] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,”Computer networks, vol. 52, no. 12, pp. 2292–2330, 2008.

[4] O. C. Brown, P. Eremenko, and P. D. Collopy,Value-centric designmethodologies for fractionated spacecraft: Progress summary fromphase 1 of the DARPA System F6 program. Defense TechnicalInformation Center, 2009.

[5] B. Kogut and A. Metiu, “Open-source software development and dis-tributed innovation,”Oxford Review of Economic Policy, vol. 17, no. 2,pp. 248–264, 2001.

[6] A. J. Quinn and B. B. Bederson, “A taxonomy of distributedhumancomputation,”Human-Computer Interaction Lab Tech Report, Univer-sity of Maryland, 2009.

[7] A. S. Tanenbaum and M. van Steen,Distributed systems. Prentice HallUpper Saddle River, 2002, vol. 2.

[8] E. Crawley, B. Cameron, and D. Selva,Systems Architecture: Strategyand Product Development for Complex Systems. Prentice Hall, 2015.

[9] B. Heydari, M. Mosleh, and K. Dalili, “From modular to distributed openarchitectures: A unified decision framework,”Systems Engineering, vol.[in press], 2016.

[10] R. N. Langlois, “Modularity in technology and organization,” Journalof Economic Behavior & Organization, vol. 49, no. 1, pp. 19–37, Sep.2002.

[11] N. P. Suh,The principles of design. Oxford University Press New York,1990, vol. 990.

[12] K. T. Ulrich, S. D. Eppingeret al., Product design and development.McGraw-Hill New York, 1995, vol. 384.

[13] K. J. Sullivan, W. G. Griswold, Y. Cai, and B. Hallen, “The structureand value of modularity in software design,”ACM SIGSOFT SoftwareEngineering Notes, vol. 26, no. 5, pp. 99–108, 2001.

[14] C. Y. Baldwin and K. B. Clark,Design rules, Volume 1: The power ofmodularity. MIT Press, 2000, vol. 1.

[15] J. Pandremenos, J. Paralikas, K. Salonitis, and G. Chryssolouris, “Mod-ularity concepts for the automotive industry: A critical review,” CIRPJournal of Manufacturing Science and Technology, vol. 1, no. 3, pp.148–152, 2009.

[16] T. J. Sturgeon, “Modular production networks: a new american model ofindustrial organization,”Industrial and corporate change, vol. 11, no. 3,pp. 451–496, 2002.

[17] J. H. Mikkola, “Modularity, component outsourcing, and inter-firmlearning,” r&d Management, vol. 33, no. 4, pp. 439–454, 2003.

[18] N. Liu, T.-M. Choi, C. Yuen, and F. Ng, “Optimal pricing,modularity,and return policy under mass customization,”Systems, Man and Cyber-netics, Part A: Systems and Humans, IEEE Transactions on, vol. 42,no. 3, pp. 604–614, 2012.

[19] M. A. Schilling and H. K. Steensma, “The use of modular organizationalforms: an industry-level analysis,”Academy of Management Journal,vol. 44, no. 6, pp. 1149–1168, 2001.

[20] R. Sanchez and J. T. Mahoney, “Modularity, flexibility and knowledgemanagement in product and organization design,”Managing in theModular Age: Architectures, Networks, and Organizations, p. 362, 2002.

[21] C.-C. Huang and A. Kusiak, “Modularity in design of products andsystems,”Systems, Man and Cybernetics, Part A: Systems and Humans,IEEE Transactions on, vol. 28, no. 1, pp. 66–77, 1998.

[22] M. A. Schilling, “Toward a general modular systems theory and itsapplication to interfirm product modularity,”Academy of managementreview, vol. 25, no. 2, pp. 312–334, 2000.

[23] D. M. Sharman and A. A. Yassine, “Characterizing complex productarchitectures,”Systems Engineering, vol. 7, no. 1, pp. 35–60, 2004.

[24] K. Holtta-Otto and O. De Weck, “Degree of modularity in engineeringsystems and products with technical and business constraints,” Concur-rent Engineering, vol. 15, no. 2, pp. 113–126, 2007.

[25] A. M. Ross and D. H. Rhodes, “Towards a prescriptive semantic basisfor change-type ilities,”Procedia Computer Science, vol. 44, pp. 443–453, 2015.

[26] P. D. Collopy and P. M. Hollingsworth, “Value-driven design,” Journalof Aircraft, vol. 48, no. 3, pp. 749–759, 2011.

[27] P. D. Collopy, “Value modeling for technology evaluation,” AmericanInstitute of Aeronautics and Astronautics, 2002.

[28] P. D. Collopy, “Economic-based distributed optimal design,” AIAAPaper, vol. 4675, 2001.

[29] O. Brown, A. Long, N. Shah, and P. Eremenko, “System lifecyclecost under uncertainty as a design metric encompassing the value ofarchitectural flexibility,” AIAA Paper, vol. 6023, 2007.

[30] E. C. M. de Weck Olivier and C. P. John, “A classification of uncertaintyfor early product and system design,”In: International conference onengineering design, Paris, France, ICED07/No.480, 2007.

[31] E. Fricke and A. P. Schulz, “Design for changeability (dfc): Principlesto enable changes in systems throughout their entire lifecycle,” SystemsEngineering, vol. 8, no. 4, 2005.

[32] M. R. Silver and O. L. de Weck, “Time-expanded decision networks:A framework for designing evolvable complex systems,”Systems Engi-neering, vol. 10, no. 2, pp. 167–188, 2007.

[33] D. Selva and E. F. Crawley, “Integrated assessment of packagingarchitectures in earth observing programs,” inAerospace Conference,2010 IEEE. IEEE, 2010, pp. 1–17.

[34] M. E. Newman and M. Girvan, “Finding and evaluating communitystructure in networks,”Physical review E, vol. 69, no. 2, p. 026113,2004.

[35] B. Heydari, M. Mosleh, and K. Dalili, “Efficient networkstructures withseparable heterogeneous connection costs,”Economics Letters, vol. 134,pp. 82–85, 2015.

[36] B. Heydari and K. Dalili, “Emergence of modularity in system ofsystems: Complex networks in heterogeneous environments,” IEEESystems Journal, vol. 9, no. 1, pp. 223–231, March 2015.

[37] J. H. Saleh, E. S. Lamassoure, D. E. Hastings, and D. J. Newman,“Flexibility and the value of on-orbit servicing: New customer-centricperspective,”Journal of Spacecraft and Rockets, vol. 40, no. 2, pp. 279–291, 2003.

[38] O. Brown, P. Eremenko, and B. Hamilton, “The value proposition forfractionated space architectures,”Sciences, vol. 99, no. 1, pp. 2538–2545, 2002.

[39] O. de Weck, R. de Neufville, and M. Chaize, “Enhancing the economicsof communications satellites via orbital reconfigurationsand stageddeployment,”American Institute of Aeronautics and Astronautics, 2003.

[40] R. Nilchiani and D. E. Hastings, “Measuring the value ofspace systemsflexibility: a comprehensive six-element framework,” inPhD thesis inAeronautics and Astronautics. Massachusetts Institute ofTechnology,2005.

[41] C. Mathieu and A. Weigel, “Assessing the flexibility provided byfractionated spacecraft,” inProc. of AIAA Space 2005 Conference, LongBeach, CA, USA, 2005.

[42] M. G. O’Neill and A. L. Weigel, “Assessing fractionatedspacecraft valuepropositions for earth imaging space missions,”Journal of Spacecraftand Rockets, vol. 48, no. 6, pp. 974–986, 2011.

[43] D. McCormick, B. Barrett, and M. Burnside-Clapp, “Analyzing fraction-ated satellite architectures using raftimate-a boeing tool for value-centricdesign,”AIAA Paper, vol. 6767, p. 2009, 2009.

[44] D. Maciuca, J. K. Chow, A. Siddiqi, O. L. de Weck, S. Alban, L. D.Dewell, A. S. Howell, J. M. Lieb, B. P. Mottinger, J. Pandyaet al.,“A modular, high-fidelity tool to model the utility of fractionated spacesystems,”AIAA Paper, vol. 6765, p. 2009, 2009.

[45] J. M. Lafleur and J. H. Saleh, “Exploring the f6 fractionated spacecrafttrade space with gt-fast,” inAIAA SPACE 2009 Conference & Exposition,2009, pp. 1–22.

[46] S. Cornford, R. Shishko, S. Wall, B. Cole, S. Jenkins, N.Rouquette,G. Dubos, T. Ryan, P. Zarifian, and B. Durham, “Evaluating a fraction-

TO APPEAR IN IEEE SYSTEMS JOURNAL, DOI: 10.1109/JSYST.2016.2594290 12

ated spacecraft system: A business case tool for darpa’s f6 program,” inAerospace Conference, 2012 IEEE. IEEE, 2012, pp. 1–20.

[47] S. Cornford, S. Jenkins, S. Wall, B. Cole, B. Bairstow, N. Rouquette,G. Dubos, T. Ryan, P. Zarifian, and J. Boutwell, “Evaluating fractionatedspace systems-status,” inAerospace Conference, 2013 IEEE. IEEE,2013, pp. 1–10.

[48] R. De Neufville and S. Scholtes,Flexibility in engineering design. MITPress, 2011.

[49] G. A. Hazelrigg, “A framework for decision-based engineering design,”Journal of mechanical design, vol. 120, no. 4, pp. 653–658, 1998.

[50] A. Golkar and I. L. i Cruz, “The federated satellite systems paradigm:Concept and business case evaluation,”Acta Astronautica, vol. 111, pp.230–248, 2015.

[51] L. Di, K. Moe, and T. L. van Zyl, “Earth observation sensor web: Anoverview,” Selected Topics in Applied Earth Observations and RemoteSensing, IEEE Journal of, vol. 3, no. 4, pp. 415–417, 2010.

[52] M. Mosleh, K. Dalili, and B. Heydari, “Optimal modularity for fraction-ated spacecraft: The case of system f6,”Procedia Computer Science,vol. 28, no. 2014, pp. 164–170, 2014.

[53] “System f6,” http://www.darpa.mil/OurWork/TTO/Programs/\System F6.aspx,accessed: 2013-12-18.

[54] A. J. McNeil, R. Frey, and P. Embrechts,Quantitative Risk Manage-ment: Concepts, Techniques and Tools: Concepts, Techniques and Tools.Princeton university press, 2015.

[55] P. Jorion,Value at risk: the new benchmark for managing financial risk.McGraw-Hill New York, 2007, vol. 3.

[56] Corporartion, Futron, “Space transportation costs: Trends in price perpound to orbit 1990-2000,” 2002.

[57] OMB Circular No. A-94: Appendix C, “Discount ratesfor cost-effectiveness, lease purchase, and related analyses,”http://www.whitehouse.gov/omb/circularsa094/a94appx-c, accessed:2016-12-7.

[58] R. Dezelan, “Mission sensor reliability requirementsfor advanced goesspacecraft,”Aerospace report no. ATR-2000 (2332)-2, 1999.

[59] “Bell or exponential numbers: number of ways to partition a set of nlabeled elements.” http://oeis.org/A000110, accessed: 2016-1-11.