Fractionated Space Systems: Decoupling Conflicting Requirements and Isolating Requirement Change...

American Institute of Aeronautics and Astronautics

1

Fractionated Space Systems: Decoupling Conflicting

Requirements and Isolating Requirement Change

Propagation

Alejandro Salado1 and Roshanak Nilchiani

2

Stevens Institute of Technology, Hoboken, NJ, 07030

The fractionated space systems vision can potentially provide various levels of flexibility

and adaptability that make a space system capable of overcoming a number of uncertain

scenarios during its development and operational lifetime. Significant research is being

performed on the benefits and drawbacks of such systems under operational scenarios, but

their capabilities during development phase remain rather unknown. This paper evaluates

how fractionated space systems can respond to requirements change during their

development with higher level of adaptability and, specifically, how fractionation can

facilitate the detection and resolution of conflicting requirements. We will also study how

fractionation helps in isolating the effects of change propagation in requirements during

system development. We suggest two frameworks for those purposes, which in addition

provide analytical capabilities to evaluate the difficulty induced by a set of requirements that

need to be fulfilled simultaneously and trade it against a variety of architectural design

choices.

I. Introduction

HE concept of Fractioanted Space Systems brings a new degree of responsiveness in the space industry1. The

idea of fractionation is simple: a monolithic satellite that carries all platform subsystems and instruments under

a common housing is split into several modules that fly freely as a cluster and communication wirelessly². Each

module provides one or more capability of the traditional monolithic satellite.

In short, the fractionation vision is to provide levels of flexibility and adaptability that make a space system

capable of overcoming a number of uncertain scenarios during its development and operational life. Significant

research has been performed on the benefits and drawbacks of such systems under operational scenarios1-4

. In

particular, the adaptability value of fractionated space systems has been calculated under uncertainty during

operation as basis for the calculation. These uncertainties include among others funding uncertainty, launche failure

uncertainty, collision uncertainty, abnormal radiation level uncertainty, or component failure. However, their

benefits and drawbacks during system development remain highly unexplored. In this paper, we study how

fractionated space systems react or are affected by two aspects of a system development in contrast to monolithic

satellites. The first aspect treats how fractionated space systems can decouple requirements that are conflicting when

satisfied by a monolithic satellite. For the second aspect, we study how fractionated systems are more robust against

changes in requirements during development by their inherent requirement isolation.

We consider the topics of conflicting requirements and requirement change propagation of primary importance

because an

rr r r ”5. As a matter of fact, requirements engineering is considered by some

researchers the cornerstone of the systems engineering process6 and it has been shown that the application of good

requirements engineering practices is correlated with the success or failure of the development of a system7-13

.

This paper is organized as follows. Section II provides a review of existing literature on the topics of fractionated

space systems, conflicting requirements, and change propagation. Section III presents two frameworks that enable

assessing the level of conflict level between a set of requirements for a given system development on one hand, and

1 Doctoral candidate, School of Systems and Enterprises, Castle Point on Hudson, Hoboken, NJ 07030. AIAA

Member. 2 Assistant Professor, School of Systems and Enterprises, Castle Point on Hudson, Hoboken, NJ 07030. AIAA

Associate Member.

T


2

determining how the effects of changing a requirement propagate through the rest of the requirements within the

given set on the other hand. Both frameworks are applied to a case study in section IV to evaluate how a monolithic

satellite and a fractionated system react during their developments to the existence of conflicting requirements and

to changes in requirements. The paper concludes with a short summary of the conclusions and a proposal for future

work in section V.

II. Literature Review

A. Fractionated Space Systems

Fractionated satellite system is a future vision of spacecraft design suggested by DARPA (Defense Advanced

Research Project Agency) and encapsulated in F6 program ((Future Fast, Flexible, Fractionated, Free-Flying

Spacecraft united by Information exchange). A single monolithic spacecraft in physically separated into fractions.

The fractions or free flying modules operate and connected by wireless communication. Fractionation primarily has

various advantages over monolithic satellite including: Increasing upgradability (replacing the fraction), Reducing

technical risk, Increasing robustness and decreasing barrier to entry for small space companies1-4

.

B. Conflicting Requirements

Conflicting requirements can be defined as tho r q r rohibits

g r”14

. This definition can be generalized by considering conflicting requirements a continuous

variable instead of a discrete one. Under these terms, two or more requirements will have a certain level of conflict

or tension, being their extremes orthogonality, i.e., requirements are actually independent, and mutually exclusive, a

solution does not actually exist for some requirements.

Recent studies on cost growth in space systems have found that conflicting objectives or requirements correlate

with expected cost growth15-19

. Independent studies have also shown that the cost of correction increases as system

development advances20-21

. We therefore assert that early identification and decoupling of conflicting requirements

can facilitate reducing cost growth uncertainty.

Research in identification, representation, and analysis of conflicting requirements is however scarce in the

domain of space systems and, more generally, in large-scale systems. Some work has been done in the field of

software systems, where a variety of approaches have been proposed:

Concatenate logical statements to identify and analyze logical contradictions between scenarios, states,

and actions22-23

.

Use heuristics to assess difficulty to satisfy two or more requirements simultaneously24

.

Use patterns to identify types of requirements or scenarios that often result in the emergence of

conflict24

.

Use pair-wise comparisons supported in some cases by graph theory to evaluate the level of conflicts

between pairs of requirements25-26

.

Existing work addressing the identification of conflicts between requirements for hardware-intensive systems

seems to tend towards using pair-wise comarisons supported in some cases by heuristics to reduce computing

effort27-28

. Thefeore, conflicts between requirements have been majoritarily represented using two techniques:

Design Structure Matrices, where each element of the outer column and raw represents a requirement

and each inner cell represents the level of conflict.

Graphs, where each node represents a requirement and each link the level of conflict.

C. Uncertainty and Change Propagation

Change during system development is a natural state in current practice in the space industry and a result of

uncertainty surrounding the system development29

. It is widely known that changes at that stage have negative

consequences in terms of cost, schedule, and quality30

. As a result, a significant amount of research is addressing

how change propagates throughout the different elements of a system under development so that control

mechanisms can be put in place31-36

.

Given a set of requirements, various interdependencies may exist37-42

. Therefore, some authors have reconized

that changes in requirements can also propagate to other requirements across the system decomposition43

, but also

within a given system level36,42

.

Since flexible products seem to absorb more seamlessly such changes44

, we argue that Fractionated Space

Systems would also provide higher levels of adaptability during system development against changes in

requirements than traditional monolithic satellites.


3

Change propagation throughout system components is generally visualized using one or more of the following

techniques45

:

Design Structure Matrix (DSM), where the elements of the outer column and row represent system

components and the inner cells propagation links.

Change Risk Plot, which is based on the DSM but include information about the criticality of the

propagation risk.

Propagation Networks, where each node represents a system component and each link represents a

propagation link.

Propagation Tree, which is based on the Propagation Networks, but nodes are repeated in order to

provide better visualization of clustering elements.

All four methods can also be used to visualize propagation of requirement changes, where requirements would

take the role of components36

.

III. Conflicting Requirements and Requirement Dependency Frameworks

In this section we present two frameworks that will support the case-study to showcase how fractionated space

systems are different with respect to monolithic satellites with regards the reaction to conflicting requirements and

requirement changes during their developments. Because the frameworks only serve a supporting purpose, they have

been kept simple yet effective in this paper.

A. Conflicting Requirements Framework

We propose a framework to assess the level of conflicts within a given set of requirements that is based on pair-

wise comparisons. We acknowledge that such framework may not provide complete information about the existence

of conflicts, i.e., the conflict space may not be exhaustively explored. However, we assert that:

(1) The results of the case-study in this paper are not affected by the level of exhaustiveness to which conflicts

are identified. Consequently, the important criterion is that both candidate solutions, i.e., the monolithic satellite

and the fractionated space system, face identical sets of conflicts.

(2) Its simplicity to visualize and calculate level of conflict seems adequate to convey the key messages of this

paper, namely how fractionated space systems can decouple conflicting requirements during their development.

Under these premises, we define a framework under which the level of conflict between two requirements is

determined based on two variables:

(1) The Inherent Difficulty to fulfill each requirement as an independent element given the programmatic

constraints of the project, such as schedule and cost.

(2) The Social Difficulty, which represents the difficulty to fulfill r q r context in which other

requirements have to be fulfilled as well. This implies that only requirements at a given level of a system

decomposition contribute to the conflict level calculation.

The inherent difficulty r q r r r g r - Within the

context of this research a 1-to-5 scale where 1 represents an easy requirement and 5 r r a difficult

requirement. Specific valuation for each requirement is performed on this paper by engineering judgement

Representation and assessment of social difficulty requires a more sophisticated method. The present research

proposes to repr r r q r

Social difficultyInherent difficulty

Conflicting Requirements

Figure 1. Elements of the Conflicting Requirements Framework.


4

g connectivity of requirements in this case is evaluating conflict, the

following definitions are used

Opposing force (1 to 5): combination of requirements reduces solution trade

Orthogonality (blank; no link shown): requirements are independent or dependent through a neutral

relation. In any case, the solution space is not affected by the inter

Pr g rk DSM’ r r to represent the relations between the different

requirements. The existence of a link and its level of influence have been determined by engineering judgment. Each

link is assigned a type of relation, as and the level of existing influence in a 1-to-5 scale where 1

represents a low conflict and 5 represents a sever conflict that could even lead to mutual exclusion r

rr r r r q r r

The resulting difficulty of fulfilling a set r q r r g following calculation,

where Ceq is the resulting conflict level, Dinh is the inherent difficulty, and Dsoc is the social difficulty:

∑ ∑ (1)

We acknowledge that using ordinal numbers for such type of calculation comes with significant mathematical

flaws. However, it is our opinion that these do not affect the main purpose of the paper, while provide adequate

simplicity to convey the key messages.

B. Requirements Dependency Framework

In this paper, we use a modified variant of the results of our previous work REF to determine and visualize

requirement dependencies.

Dependencies are determined by evaluating how the fulfillment of one requirement is affected by the fulfillment

of each other requirement. Those relationships are first visualized using propagation networks. Each link is assigned

either a (+) when improving the fulfillment of one requirement increases the chances of fulfilling another

requirement or a (-) when improving the fulfillment of one requirement decreases the chances of fulfilling another

requirement and vice versa.

Once dependencies have been determined, they are also displayed in a DSM.

IV. Notional Case-Study: Fractionated Spacecrafts

In this section, we present a notional case-study in which we explore how the developments of a monolithic

space system and of a fractionated space system are affected by the existence of conflicting requirements and by

changes in requirements they are expected to fulfill. First, the problem is presented through a set of stakeholder

needs that are used to originate system requirements, from which design parameters are specified. The sets are

incomplete, but present the necessary information for the purpose of this paper. Then, both candidate solutions, i.e.,

the notional monolithic space system and the notional fractionated space system, are presented. Finally, we evaluate

the impacts on development difficulty and the impacts of requirement changes for both solutions.

A. Problem Formulation

L ’ gr k r 1 k r

needs that will be the basis for the notional case-study used in this paper to showcase the application of how the

developments of fractionated space systems and monolithic space systems are affected or react to conflicting

requirements and requirements changes. In essence, stakeholders need a system that provides continuous high-

resolution imaging in a variety of spectral ranges, which include VNIR, SWIR, and X bands. Given the nature of

such bands, those needs imply imaging using passive optical instruments and active microwave instruments.

Table 2 lists a subset of system requirements that are derived from the stakeholder needs listed in Table 1. It is

important to note that they do not include any design dependent requirement and, consequently, could be fulfilled by

both a monolithic space system and a fractionated space system. In addition, because the objective of this paper is to

Table 1. Stakeholder needs for notional case-study.

ID Description

N1 Continuous high-resolution real-time image information in VNIR/SWIR spectral ranges (optical).

N2 Continuous high-resolution real-time image information in X spectral range (RADAR).


5

evaluate the effect of conflicting requirements and requirement changes into their developments, programmatic

requirements (and eventual performance) such as cost or schedule have not been included. Again, the given subset is

incomplete, but it provides the necessary elements for the purpose of this paper. Finally, actual values have not been

allocated to the different requirements in order to provide generality to the case-study.

Fulfulling the requirements presented in Table 2 would require the fulfillment of various design parameter or

lower level requirements. A subset is presented in Table 3, followed by a traceability matrix in Table 4 between

those design parameters and the system requirements presented in Table 2. The subset is of course incomplete, but it

provides the necessary elements for the purpose of this paper. In addition, actual values have not been allocated to

the different design parameters in this case either in order to provide generality to the case-study.

B. Candidate Systems: Monolithic Versus Fractionated Satellites

As presented earlier, the developments of two candidate systems are evaluated in this paper. In particular, the

developments of a monolithic space system (or satellite specifically in this case) and of a fractionated space system

are compared.

The following assumptions are applicable to both systems:

(1) The system fulfills all its requirements.

Table 2. System requirements subset for notional case-study.

ID Description Justification

R1 The system shall image Earth surface in VNIR/SWIR

spectral range with performance A better than X units.

Satisfy N1.

R2 The system shall image Earth surface in X band (RADAR)

with performance B better than Y units.

Satisfy N2.

R3 The system shall transmit image data in less than Z s after

image acquisition.

Elicited for completeness of N1 and

N2.

R4 The system shall continuously image Earth surface. Elicited for completeness of N1 and

N2.

R5 The system shall image Earth surface in both spectral

ranges at accuracy of 0.1 s (synchronization).

Satisfy N1 and N2, elicited for their

completeness.

Table 3. Design parameters for notional case-study.

ID Description

TP1 Pointing accuracy optical sensor.

TP2 Pointing accuracy microwave sensor (RADAR).

TP3 Pointing accuracy transmitter antenna (data).

TP4 Power dissipation.

TP5 Data processing capability.

TP6 EIRP data transmitter.

TP7 Optical performance.

TP8 Radar performance.

TP9 Image synchronization.

Table 4. Traceability matrix for notional case-study.

TP1 TP2 TP3 TP4 TP5 TP6 TP7 TP8 TP9

R1 X X X

R2 X X

R3 X X X

R4 X X X

R5 X


6

(2) Programmatic requirements such as cost and schedule are not part of the evaluation.

(3) Only the requirements and design parameters presented in the previous section are used for the study.

(4) The system is notional.

The notional monolithic space system is presented in Figure 2. A single satellite is used to ultimately satisfy all

stakeholder needs listed in Table 1. As a result, it incorporates two main payloads: (1) a passive optical instrument

that is used to image the Earth surface in VNIR and SWIR spectral bands and (2) a RADAR that is used to actively

image the Earth surface in X band.

The notional fractionated space system is presented in Figure 3. Three fractions form the fractionated space system

or cluster. One fraction provides traditional platform capabilities such as power generation and distribution,

command and control, attitude determination and orbit control, and communication to Earth. A second fraction

consists of a passive optical instrument that is used to image the Earth surface in VNIR and SWIR spectral bands.

The third fraction consists of a RADAR that is used to actively image the Earth surface in X band. Both payload-

type fractions could also incorporate some life-support elements such as inter-fraction communication systems or

internal power distribution systems.

Design parameters as presented in Table 3 can be allocated to the different systems as described in Table 5. It shall

be noted that TP4 has not been assigned to Fraction 2 because it is a limitation imposed by the performance of the

optical instrument into the boundaries of the RADAR instrument. In addition, the allocation of some design

parameters such as TP9 has been simplified in order to provide guarantee visibility of the case-study results.

Platform

Optical instrument

RADAR

Monolithic satelliteGro

un

d C

on

tro

l Seg

men

t

Eart

h s

urf

ace

Image dataVNIR/SWIR radiationX band transmission & reflection

Figure 2. Notional monolithic space system.

Platform

Optical instrument

Fractionated satellite

Gro

un

d C

on

tro

l Seg

men

t

Eart

h s

urf

ace

Fraction 1

Image dataVNIR/SWIR radiationX band transmission & reflection

RADAR

Fraction 3

Fraction 2

Life support system

Life support system

Figure 3. Notional fractionated space system.


7

C. Decoupling Conflicting Requirements

The study on conflicting requirements is performed at the system requirements level. Level of conflict is

evaluated for each candidate solution independently. Assessments of inherent and social difficulties are performed

using engineering judgement. It should be noted that the allocation of those levels is qualitative and for illustrative

purposes only.

Figure 4 shows two graphs that represent the inherent and social complexities for the given set of requirements

when allocated to a monolithic satellite and to a fractionated space system. Moreover, they include the calculation of

the total conflict level in both cases. Table 6 discusses the differences in inherent and social difficulties between

both solutions.

Table 5. Design parameter allocation.

Design

parameter

Monolithic

satellite

Fractionated Space System

Fraction 1 Fraction 2 Fraction 3

TP1 X X

TP2 X X

TP3 X X

TP4 X X X

TP5 X X

TP6 X X

TP7 X X

TP8 X X

TP9 X X

Figure 4. Conflicting requirements in both candidate solutions.


8

As can be seen from the assessment, even though the total inherent difficulty increases when the system is

fractionated, the total conflict level becomes lower than for the monolithic satellite. This finding is very interesting,

as it conveys two main messages:

(1) Fractionation facilitates reduction of social difficulty, at the expense of increasing the difficulty of inherent

difficulties.

(2) A decision on whether to use a monolithic solution or a fractionated one is not trivial. Instead, rigorous

assessment and allocation of difficulty levels is necessary in order to deliver sound decisions.

D. Isolating Requirements Change Propagation

Since both candidate solutions are expected to fulfill all system requirements, change propagation is studied on

the design parameters. Figure 5 shows the different interdepdencies between the design parameters for the

monolithic satellite. Table 7 summarizes them in a DSM form and Table 8 justifies why the interdependencies exist.

It should be noted that some relationships have been kept at a very simple level, for example linking optical and

radar performances to single parameters. This is not the case in actual systems, but it provides sufficient rigor to

convey the main messages of this paper.

Table 6. Justifications for differences between monolithic and fractionated solutions.

Element Justification for differences

R5 Synchronization to a great accuracy is significantly more difficult to achieve using wirelessly

connected components that hardwired connections.

R1-R2 Active RADAR in X band and passive optical imaging in SWIR require different operating

envirnoments to achieve high performance. Whereas RADAR require high power, which results in

high power dissipation, optical imaging in SWIR spectral range demands low temperature

distortions. Consequently, achieving the required performance when both instruments share housing

is considered very difficult (monolithic solution). In contrast, both instruments are split into

different fractions in the fractionated solution and, consequently, both requirements become

orthogonal.

R1-R3 Similarly to the previous case, transmission of data may induce thermal distortions that affect the

performance of passive optical equipment in the SWIR spectral range. Fractionation helps in the

sense that half of the data is transmitted through an orthogonal path.

TP2Point. Acc.

RADAR

TP4Power

dissipation

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L4

L5L6

L7

L8

L9 (-)

(+)

(-)

(-)(-) (+)

(+)

(+)

Monolithic

Figure 5. Interdepdencies of the monolithic satellite.


9

Breaking the monolithic satellite in various fractions to form the fractionated space system automatically breaks

dependencies between design parameters, as shown in Figure 6. We acknowledge that new design parameters may

emerge, but they are considered irrelevant for the study in the present paper. Dependencies are summarized in DSM

form in Table 9, Table 10, and Table 11, for Fraction 1, Fraction 2, and Fraction 3, respectively. As can be seen,

fractionation has automativally removed L4 and L5. In addition, TP4 no longer exists. Since this design parameter

was defined to ensure proper interface to the optical instrument, it is no longer needed in any of the fractions. As a

result, L6, L8, and L9 are also automatically removed. Overall, fractionation has reduced the amount of

interdependencies between requirements from 9 to 4.

Table 7. Dependency matrix between design parameters for notional monolithic

system.

Monolithic TP1 TP2 TP3 TP4 TP5 TP6 TP7 TP8 TP9

TP1 L1

TP2 L2

TP3 L3

TP4 L4 L5

TP5 L6 L7

TP6 L8

TP7

TP8 L9

TP9

Table 8. Requirement interdependencies justifications.

Interdependency Justification

L1 For the given mission, optical performance depends positively on the

pointing accuracy.

L2 For the given mission, RADAR performance depends positively on the

pointing accuracy.

L3 The necessary EIRP to achieve the given Bit Error Rate depends negatively

on the pointing accuracy of the transmitter. The more accurate pointing is,

the less EIRP is needed.

L4 Because pointing accuracy depends on themoelastic deformation, the higher

the temperature the higher the risk of achieving proper pointing accuracy.

Moreover, the more power that is dissipated, the higher the temperature,

including gradients if dissipated power is pulsed (which is the case for

RADAR’ ) H r x g r en power

dissipation and pointing accuracy.

L5 The optical performance in VNIR and in particular SWIR depends

negatively on the surrounding temperature. Using the same rationale as in

L4, there exists a negative relationships between power dissipation and

optical performance.

L6 The more processing power that is needed, the higher the power

consumption and hence dissipation of electronic equipment.

L7 The more onboard data processing that is available, the less data needs to be

transmitted to ground and, as a result, lower EIRP is needed. And vice versa.

L8 The higher the EIRP, the higher the power dissipation.

L9 Radar performance depends positively on the ouput power of the RADAR

antenna, i.e., higher power levels improve performance. Using the same

rationale as in L8, higher RADAR performance implies higher power

dissipation.


10

In the following, three cases in which a requirement change is needed are studied. The impact of the requirement

change is evaluated on both candidate solutions: the monolithic satellite and the fractionated space system.

Case 1. Higher RADAR performance.

In this case, it is assumed that higher performance for the RADAR instrument is required. Therefore, TP8 needs

to be more stringent. Using the propagation network for the monolithic satellite, it is easy to see that higher RADAR

performance implies higher power dissipation and, as a result, fulfillments of TP1 and, in particular of TP7, are

TP2Point. Acc.

RADAR

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L7

(-)

(+)

(-)

Fraction 3

Fraction 1Fraction 2

Figure 6. Interdepdencies of the fractionated space system.

Table 9. Dependency matrix between

design parameters for Fraction 1 of the

notional fractionated system.

Fraction 1 TP3 TP5 TP6 TP9

TP3 L3

TP5 L7

TP6

TP9

Table 10. Dependency

matrix between design

parameters for Fraction 2

of the notional fractionated

system.

Fraction 8 TP1 TP7

TP1 L1

TP7

Table 11. Dependency

matrix between design

parameters for Fraction 1

of the notional fractionated

system.

Fraction 3 TP2 TP8

TP2 L2

TP8


11

endangered (see Figure 7). Consequently, accepting a change of TP8 would result in additional rework, potentially

on the optical instrument, to fulfill TP1 and TP7 as well because of the change propagation.

In the fractionated case, since L4 and L5 no longer exist, the change of TP8 does not propagate outside Fraction

3. Consequently, the change can be accepted without compromising the development of Fraction 1 and Fraction 2

(see Figure 8).

Case 2. Higher Optical performance.

In this case, it is assumed that higher performance for the optical instrument is required. Therefore, TP7 needs to

be more stringent. Using the propagation network for the monolithic satellite, it is easy to see that higher optical

performance requires lower pointing accuracy (TP1) and/or lower power dissipation (TP4). As a result, fulfillment

TP2Point. Acc.

RADAR

TP4Power

dissipation

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L4

L5L6

L7

L8

L9 (-)

(+)

(-)

(-)(-) (+)

(+)

(+)

Monolithic

Figure 7. Case 1 – Change propagation in monolithic satellite.

TP2Point. Acc.

RADAR

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L7

(-)

(+)

(-)

Fraction 3


Figure 8. Case 1 – Change propagation in fractionated space system.


12

of TP1, and in particular TP4, are endangered. Consequently, accepting a change of TP7 would result in additional

rework, potentially on the RADAR and platform parts, to fulfill TP1 and TP4 as well because of the change

propagation (see figure 9).



(see figure 10).

Case 3. Lower processing capability.

TP2Point. Acc.

RADAR

TP4Power

dissipation

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L4

L5L6

L7

L8

L9 (-)

(+)

(-)

(-)(-) (+)

(+)

(+)

Monolithic


TP2Point. Acc.

RADAR

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L7

(-)

(+)

(-)

Fraction 3




13

In this case, it is assumed that the initial expected processing power cannot be achieved. Therefore, TP5 needs to

be relaxed at the expense of inreaseing EIRP (TP6). Using the propagation network for the monolithic satellite, it is

easy to see that fulfillments of TP1 and, in particular of TP7, are endangered because of the higher power dissipation

due to the increase in EIRP. Consequently, accepting a change of TP5 would result in additional rework to fulfill

TP1 and TP7 as well because of the change propagation (see Figure 11).



(see Figure 12).

TP2Point. Acc.

RADAR

TP4Power

dissipation

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L4

L5L6

L7

L8

L9 (-)

(+)

(-)

(-)(-) (+)

(+)

(+)

Monolithic


TP2Point. Acc.

RADAR

TP3Point. Acc. TX

TP1Point. Acc.

Optical

TP5Data proc.

TP6EIRP TX

TP7Optical perf.

TP8RADAR perf.

TP9Image sync.

(+)

L1

L2

L3

L7

(-)

(+)

(-)

Fraction 3




14

V. Conclusion

In this paper, we looked at the concept of identifying the requirement conflict and change propagation of

requirement for space system with a particular attention to the concept of fractionated space systems. We proposed

two intial frameworks: the first framework suggests a methodology to identify the level of conflict and difficulty of

fulfillment of the requirements at hand; and the second framework suggests a basis to map the uncertainty and

change propagation of a requirement and how it affects the design. We presented a case study that focused on a

different design paradigm, fractionated space systems, in ccomparison with the traditional monolithic space system.

The two frameworks were applied to the monolithic satellite as well as a case of fractionated space systems under

three different emphasis (higher radar performance, higher radar performance, and lower processing capability). The

finding of the case study shows that the fractionated space systems paradigm facilitates identification of the

conflicting requirements and therefore by fractionating, the decoupling and minimizing the conflicts becomes a

practical option. The case study also shows that due to the nature of fractionation, the change in requirements in

certain cases can be localized and limited to a single fraction (or more fractions) rather than being a change that

propagates and affects the whole space system.

Acknowledgments

The authors thank Dr. Owen Brown for proposing the research questions leading to the research presented in this

paper and providing us with the sample requirements for the case study, and Dr. Owen Brown, Dr. Dinesh Verma,

Dr. Wiley J. Larson, and Dr. Yu Tao for their comments and recommendations on the elements presented in this

paper.

This work was supported in part by the DARPA/NASA Ames Contract Number NNA11AB35C on the

Fractionated Space Systems F6 project.

References 1Brown, O. and Eremenko, P., Fractionated Space Architectures: A Vision for Responsive Space ” 4th Responsive Space

Conference, Los Angeles, CA, 2006.

²Brown, O. and Eremenko, P., The Value Proposition for Fractionated Space Architectures ” AIAA Space 2006, San Jose,

CA. 3N R E k M D K Measuring the Value of Adaptability of Fractionated Spacecrafts ” In

proceedings of Annual INCOSE symposium 2012, Rome, Italy, 2012 4E k M N R E U gr Fr S S A R O

A r ” AIAA Space 2012, San Diego, CA, 2012. 5Brace, W. and Thramboulidis, K., Fr R q r D g S – A F r A r ” International

Design Conference – Design 2010, Dubrovnik – Croatia, May 17-20, 2010. 6Buede, D. M., The Engineering Design of Systems: Models and Methods, 2nd ed., Wiley Series in Systems Engineering and

Management, 2009. 7Weinberg, J., Quality Software Management. Volume 4 Anticipating Change, Dorset House, New York, 1997. 8Lyytinen, K. and Hirschheim, T., I r r – a survey and classification of the r r r ”

Oxford Surv. Inf. Technolo., Vol. 4, No. 1, 1987, pp. 257-309. 9K Y Cr r r r r ” I J Pr M g 20 (3) 241-246, 2002. 10Dada, D., r E-government in developing countries: a literature review,” Electron. J. Inf. Syst. Dev. Ctries.,

Vol. 26, No. 7, 2006, pp. 1-10. 11El Emam, K. and Birk, A., V g ISO/IEC 15504 r r r q r nts analysis process capability,”

IEEE Trans. Softw. Eng., Vol. 26, No. 6, 2000, pp. 541-566. 12Boehm, B. W. and Papaccio, P. N., U r g r g r ,” IEEE Trans. Softw. Eng., Vol. 4, No.

10, 1988, pp. 1462-1477. 13McConnell, S., Fr r – an ounce of prevention,” IEEE Softw., Vol. 18, No. 3, 2001, pp. 5-7. 14Robertson, S. and Robertson, J., Mastering the requirements engineering process. Getting requirements right, 3rd edition,

Addison-Wesley, 2012. 15M P A g r H S k S S rk S U r les unique cost estimating requirements,” IEEE

Aerospace Conference, 2013. 16Malone, P. and Wolfarth, L Measuring system complexity to support development cost estimates,” IEEE Aerospace

Conference, 2013. 17Dwyer, M., Selva, D., Cameron, B., Crawley, E., and Szajnfarber, Z The impact of technical complexity on the decision

to collaborate and combine”, IEEE Aerospace Conference, 2013.


15

18Bearden, D A A complexity-based risk assessment of low-cost planetary missions: when is a mission too fast and too

cheap?,” Acta Astronautica, Vol. 25, No. 2-6, 2003, pp. 271-279. 19Leising, C. J., Wessen, R., and Ellyin, R Spacecraft complexity subfactors and implications on future cost growth,” IEEE

Aerospace Conference, 2013. 20Boehm, B. and Papaccio, P. N., Understanding and controlling software costs,” IEEE Trans. Softw. Eng., Vol. 4, No. 10,

1988, pp. 1462-1477. 21Honour, E Understanding the value of systems engineering,” INCOSE Int Symp, Toulouse, France, 2004. 22Gervasi, V. and Zowghi, D Reasoning about inconsistencies in natural language requirements,” ACM Transactions on

Software Engineering and Methodology, Vol. 14, No. 3, July 2005, pp. 277-330. 23Ali, R., Dalpiaz, F., and Giorgini, P Reasoning with contextual requirements: Detecting inconsistency and conflicts,”

Information and Software Technology, Vol. 55, 2013, pp. 35-57. 24van Lamsweerde, A., Darimont, R., and Letier, E Managing conflicts in goal-driven requirements engineering,” IEEE

Transactions on Software Engineering, Vol. 24, No. 11, Novermber 1998, pp. 908-926. 25Liu, X. F. and Yen, J An analytic framework for specifying and analyzing imprecise requirements,” Proceedings of ICSE-

18, 1996, pp. 60-69. 26Hausmann, J. H., Heckel, R., and Taentzer, G Detection of conflicting functional requirements in a use case-driven

approach,” Proceedings of the 24rd IEEE International Conference on Software Engineering ICSE 2002, 2002, pp. 105-115. 27Stechert, C., Bauer, S., Franke, H.-J., and Meerkamn, H Requirements management in early stages of mechatronic design

by visualisation of interdependencies,” International Design Conference – DESIGN 2008, Dubrovnik, Croatia, May 19-22, 2008. 28D K H r M -scale complexity measures and heur r rk r q r ”

Unpublished. 29Salado, A., Nilchiani, R., and Efatmaneshnikh, M., x C g r U r S S

A M r V A ” AIAA Space Conference 2012, Pasadena, CA. 30Peterson, C., Paasch, R. K., and Dietterich, P., Pr r r r ign under changing

requirements,” International Conference on Engineering Design ICED07, 28 – 31 August 2007, Cite des Sciences et de

’I r P r Fr 31Hassan, A. E. and Holt, R. C., Pr g C g Propagation in Software Systems,” Proceedings of the 20th IEEE

International Conference on Software Maintenance, 2004, Pages 284-293, IEEE Computer Society, Washington, DC, USA. 32Keller, R., Eckert, C. M., and Clarkson, P. J., H r r change prediction,” International Design Conference DESIGN

2006, Dubrovnik, Croatia, May 15-18, 2006. 33Clarkson, P. J., Simons, C., and Eckert, C., Pr g ge propagation in complex design,” Proceedings of DETC’01,

ASME 2001 Design Engineering Technical Conference and Computers and Information in Engineering Conference, Pittsburgh,

Pennsylvania, September 9-12, 2001. 34Oduncuoglu, A. and Thomson, V., E g the risk of change propagation,” International Conference on Engineering

Design ICED’11, 15-18 August 2011, Technical University of Denmark. 35Giffin, M., de Weck, O., Bounova, G., Keller, R., Eckert, C., and Clarkson, P. J., C g Pr g A is in

Complex Technical Systems,” Journal of Mechanical Design, August 2009, Vol. 131 / 081001-1. 36Salado, A. and Nilchiani, R Assessing the impacts of uncertainty propagation to system requirements by evaluating

requirement connectivity,” INCOSE International Symposium, Philadelphia, PA, 2013. 37Carlshamere, P., Sandahl, K., Lindvall, M., Regnell, B., and Dag, N. D., A r r r q r

interdependencies in software product release planning,” RE '01 Proceedings of the Fifth IEEE International Symposium on

Requirements Engineering, 2001. 38Pohl, K., Process-Centered Requirements Engineering, John Wiley & Sons, Inc. New York, NY, USA, 1996. 39Zhan, W., Mei, H., and Zhao, H., A r -oriented approach to modeling requirements dependencies,” Proceedings of

IEEE 13th International Conference on Requirement Engineering (RE’05), 2005. 40Robinson, W. N., Pawloaski, S. D., and Volkov, V., R quirement interaction management,”

http://www.cis.gsu.edu/~wrobinso/papers/GSUCIS99-7.PDF. Department of Computer Information Systems, Georgia State

University, Atlanta, GA 30302; [email protected] (This online publication was first accessed around December 2008). 41Kulshreshtha, V., Boardman, J., and Verma, D., rg r q r rk for requirements inter-

dependencies,” Int. J. Computer Applications in Technology, Vol. 45, No. 1, 2012. 42Eben, K. G. M. and Lindemann, U., S r r r q r – Interpretation of structural criterions,” 12th

International Dependency and Structure Modelling Conference DSM’10, 22 – 23 July 2010, Cambridge, UK. 43Koh, E. C. Y, and Clarkson, P. J., A g od to manage change propagation,” International Conference on

Engineering Design ICED’09, 24-27 August 2009, Stanford University, Stanford, CA, USA. 44Bischof, A. and Blessing, L., D g r x k g r visions for requirement changes,” International Conference

on Engineering Design ICED07, 28 – 31 A g 2007 C S ’I r P r Fr 45Keller, R., Edger, T., Eckert, C. M., and Clarkson, P. J., V g g r g ” International Conference on

Engineering Design ICED 05, Melbourne, August 15-18, 2005.

Fractionated Space Systems: Decoupling Conflicting Requirements and Isolating Requirement Change...

Documents

Transcript of Fractionated Space Systems: Decoupling Conflicting Requirements and Isolating Requirement Change...