A Practical Method for Tradespace Exploration of Systems of

Preparing to load PDF file. please wait...

0 of 0
100%
A Practical Method for Tradespace Exploration of Systems of

Transcript Of A Practical Method for Tradespace Exploration of Systems of

AIAA Space 2009 Pasadena, CA, September 14-17, 2009

A Practical Method for Tradespace Exploration of Systems of Systems

Debarati Chattopadhyay ∗

Adam M. Ross †

Donna H. Rhodes ‡
Massachusetts Institute of Technology, Cambridge MA 02139

Systems of Systems (SoS) are a current focus of many organizations interested in integrating assets and utilizing new technology to create multi-component systems that deliver value over time. The dynamic composition of SoS along with the managerial independence of their component systems necessitates systems engineering considerations and methods beyond those of traditional systems engineering, particularly during SoS concept design. Qualitative and heuristic-based guidance for SoS design is available in the literature, but there is a need for methods that will allow decision makers to quantitatively compare diverse multi-concept SoS designs in order to select value robust designs during concept exploration. In this paper, a quantitative method for SoS conceptual design, known as System of Systems Tradespace Exploration Method (SoSTEM), is presented. This method is based on the existing Dynamic Multi-Attribute Tradespace Exploration (MATE). MATE is a formal methodology for tradespace exploration during system design that allows the decision maker to make trades between both stakeholder preferences and systems early in the design process and includes the consideration of dynamic issues such as unarticulated stakeholder preferences and changing system context. SoSTEM enables the generation of SoS tradespaces where multi-concept architectures can be compared on the same performance and cost basis. This method allows the SoS designer to distinguish between component systems having high likelihood of participation in the SoS and those with lower likelihood of participation, based on the level of ‘Effective Managerial Authority’ that the SoS designer has over the component. In this paper, SoSTEM is demonstrated through application to two case studies, an Operationally Responsive System for Disaster Surveillance and a Satellite Radar System.
I. Introduction
Systems of Systems (SoS) are dynamic, higher-order systems that are composed of other independently managed component systems. SoS are of increasing importance as organizations today use highly networked but independently managed systems to generate unique capabilities beyond that available by independent operation of those systems. Due to the additional complexity of component systems that are independently managed, SoS engineering requires different considerations when compared to traditional systems engineering.
As the majority of engineering resources are committed in the concept exploration phase of systems engineering, one of the primary challenges in engineering system design is making decisions in the concept exploration phase that will result in designs that are valuable throughout the operational lifetime of the system. The problem is even more difficult when designing SoS, which often change in composition several times during the SoS lifetime, incorporating a different combination of both legacy and newly designed component systems at different times during the SoS operational life. Tradespace exploration methods are employed in system design to analyze design spaces and aid decision-makers in choosing ‘good’ design alternatives from among a potentially large set. As the emphasis on designing SoS is increasing, there is a
∗Research Assistant, Department of Aeronautics and Astronautics, 77 Massachusetts Avenue, Cambridge MA 02139. †Research Scientist, Engineering Systems Division, 77 Massachusetts Avenue, Cambridge MA 02139. AIAA Member ‡Senior Lecturer, Engineering Systems Division, 77 Massachusetts Avenue, Cambridge MA 02139. AIAA Member
1 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009
need for a tradespace exploration methodology that will allow designers to make informed design decisions early in the SoS conceptual design phase, as well as make informed operations and management decisions during operation of SoS. The System of Systems Tradespace Exploration Method (SoSTEM) is proposed as a method to generate and analyze tradespaces to support decision making in the SoS conceptual design phase. SoSTEM is then applied to two case studies in order to demonstrate the identification of value robust SoS designs and illustrate the design insights that can be obtained using this method.
II. Literature Review
Literature related to descriptions of Systems of Systems, the classification of SoS, and the need for new systems engineering methods for SoS design has been a growing field. There are several definitions of SoS that are currently available in the literature, though there is no commonly agreed upon definition. INCOSE1 defines Systems of Systems as
System of Systems applies to a system-of-interest whose system elements are themselves systems; typically these entail large scale inter-disciplinary problems with multiple, heterogeneous, distributed systems.
A variety of descriptions of SoS have also been put forth in the literature, with characteristics such as Operational and Managerial Independence from Maier2 ; Evolutionary Development and Geographical Distribution from Sage and Cuppan3 ; Autonomy, Belonging, Connectivity, Diversity and Emergence from Boardman4 .While these characterizations are either very detailed or broad enough to include a wide range of systems within their purview, there are a few traits common to most of the SoS descriptions, which can be summarized in the following statement - that SoS are systems, composed of a set of heterogeneous systems that maintain some level of independence while within the SoS and provide some emergent value within the SoS beyond their individual contributions.
From the characteristics differentiating SoS and traditional systems in the literature, it is evident that SoS have additional complexity compared to traditional systems. Due to this added complexity, there is a possible need for improved, or in some cases, new systems engineering methods to design SoS. Eisner5 and Keating6 describe the need for SoS Engineering methods beyond traditional systems engineering methods. Several heuristics (such as those proposed by Maier2 and Sage3) and qualitative frameworks for SoS engineering (as discussed by Carlock7 and DeLaurentis8) have been proposed to address SoS design. While qualitative frameworks provide much-needed guidelines for development of more rigorous methods for SoS design, there is still a need for more quantitative methods for SoS design. Recently there has been some research development in this area, using modeling and simulation to generate the performance of many SoS designs for quantitative comparison.
III. Motivation
A quantitative method of SoS conceptual design will enable the comparison of many more architecture options than is possible through qualitative methods alone, facilitating a more complete exploration of a SoS design space. Such a quantitative method needs to address the SoS-specific characteristics that distinguish SoS engineering from traditional systems engineering, and enable the decision maker to compare a large number of SoS designs consisting of heterogeneous components on an equal basis in order to aid the decision maker in selecting value robust SoS designs.
Tradespace exploration is a method that has been used in the conceptual design of traditional single systems in order to quantitatively compare a large number of design options on the same performance and cost basis. Extending an existing system tradespace exploration method to the SoS domain will lead to a quantitative SoS conceptual design method. In this paper, a SoS tradespace exploration method based on the existing Dynamic Multi-Attribute Tradespace Exploration (MATE) method9 is presented to address the need for a quantitative SoS conceptual design method to aid SoS decision makers.
IV. Identification of SoS-specific Design Considerations
To develop the SoS Tradespace Exploration Method, several SoS-specific design characteristics were identified that distinguish SoS conceptual design from that of traditional systems.
2 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009

A. Stakeholder Analysis Differences for SoS

SoS are composed of component systems that maintain some level of independence while participating in the

SoS. A component system has independent management that makes decisions about the system operation,

both when the system is participating in and also when it is outside of the SoS. By virtue of being systems

themselves, component systems have their own sets of stakeholders. Some of these local stakeholders may also

be pDaurte otfotshteakgelohboaldleSrosSetsstaaktehbooltdherthseet.loFcaiglucroem1piollnuesntrtastyess-this concept of local and gloer#s.1&6&1!?#"&94

tem level and global SoS level, a SoS designer is confronted

with a multi-level stakeholder value proposition with multiple

stakeholders at each level during stakeholder analysis. Multi-

stakeholder negotiations may require aggregating and trading

the preferences of decision makers, depending on the relations

between the local and global stakeholders. The designer must

incorporate local and global distribution of costs and benefits

into a multi-level value proposition for the SoS. In order to de-

sign a SoS that will be able to deliver the expected value to

the SoS stakeholders, the SoS designer must take into account

the independent decision making capability of each component system resulting in the risk of non-participation of a component when it is needed as well as strategies to maintain the desired SoS configuration by influencing the behavior of the SoS component systems.

F!ig"u#r$e%1&$. 'S(o&)S %L"o*c$a%l&and Global Stakeholde+rs,,$-re.s/u"lt%i(ng.0&i+n .a,1multi-level stakeholder
value proposition. Component systems have
lo!c.a2l s$t#a3ke&$h'ol(d&e4rs.;5th&+e3S1o,S.6ha1s global stake-
holders. Some local stakeholders may also
b7e 3p'ar$t6o8f#t&h9e"g6lo:b"al1s8,t8a"k'eholder set.

B. Dynamics of SoS Composition

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

-"%'2.)*+,3,)*4/*56#728%69*:%6*
SoS face changing conditions over time, such as component systems;6j#o'2in.&i#nn&d?%6#[email protected]%a1v*%in:*Ag(.t$2h7e.*S%:o* S, changes in
component systems available for inclusion i!n "th#e$S%o&S',$v(a)rio'*us"s+ta'k,eAh(-.o$.2ld7e/.Br)-*Cp$("r*e!"f%(e1r:02e16n21c
!"#$%&'(&)'#*+

!,!-../!0$""$12+"#))"!34")&)+)#!56!7#1245859:

23."45$6&3(#'8=$3>$?>"',-./-("(0'7"01

!"#$%&' (&)*"+)

,"-' (&)*"+)

!"#$%&' (&)*"+)

,"-' (&)*"+)

!"#$%&' (&)*"+)

,"-' (&)*"+)

<<<

7-78

7-79

%-./-("(0' 1&10".1

!"#$

2:

2;

!

!

7-7* 2*

Figure 2. Legacy and New Component Systems in Time-Varying SoS Composition

Figure 2 is a notional diagram representing the potential changing SoS composition, as well as the incorporation of legacy and new component systems within the SoS. It is important to identify value robust SoS designs (which are designs that maintain a certain level of value delivery under changing conditions) during the design process in order to aid the selection of designs that will remain useful over the SoS operational lifetime. Epoch-Era Analysis is an approach applied in Dynamic MATE to analyze systems that operate in a time-varying context9 and may help identify value robust SoS designs in the conceptual design

3 of 14 American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009
phase. In Epoch-Era Analysis, the SoS lifetime can be divided into a series of epochs, which are defined as time periods when significant system design characteristics, expectations, and context variables are fixed. Multiple consecutive epochs can be strung together to create an era, which represents a longer run view of the system evolution. Significant changes in the SoS or the SoS context - such as a component system joining or leaving the SoS - can be represented by defining a new epoch. Since SoS are often created to meet an urgent need, evolutionary development may be needed to build up capability over time through different configurations of component systems within the SoS. While a single epoch can give a SoS designer an idea of SoS designs that are valuable in a particular fixed context, arranging multiple epochs into longer periods called eras can provide a long-term view of the SoS evolution and help the SoS designer identify long-term strategies for sustaining the SoS.
C. Legacy and New Component Systems
SoS are often composed of both legacy and new systems, as well as existing and newly-designed interfaces between component systems. The SoS designer may not have the ability to affect enhancements and upgrades to legacy systems or interfaces. The ‘system shell’ concept10 may be a useful construct when the component system design cannot be altered. By designing a wrapper or shell around the legacy component, it can easily be integrated into the SoS and interfaced with other components without adversely affecting the legacy operation. This concept may also make it easier to switch components in and out of a SoS with minimum impact on the SoS operation. On the other hand, the SoS designer may have the power to define the design of a system that is being newly designed. Thus the SoS designer must take into account the differences in design control over legacy and new component systems during decision making in the conceptual design process.
V. Managerial Control, Influence and Participation Risk
As discussed in the previous section, the level of design control that the SoS designer effectively has over each component will affect the ultimate design of the SoS. To address this issue of SoS designer control over components, a framework for decision making that drives the participation of desired component systems in a SoS was developed. A SoS is comprised of component systems that retain some level of independent management and operation. The relationship between the SoS designer, responsible for SoS-level decisions, and the component system management, responsible for component system decisions, can be represented with two quantities - Managerial Control and Influence. Managerial Control is the amount of hierarchical control that the SoS designer has over the component system. Managerial Control has been previously used to classify SoS in the literature, for example by Maier.2 In cases where participation of component systems is voluntary, the SoS designer may employ various methods, collectively referred to as Influence, in order to persuade component systems to behave in a way that is beneficial to the SoS. The component system management may make decisions about the component system participation in the SoS based on their local perception of benefits and costs of participation. The change in ‘Perceived Net Benefit’ (PNB), which is the difference between local benefit and local cost as perceived by the component system management, is a metric that can be used by the component system management to determine whether to join the SoS. The SoS designer may be able to change the PNB for a component system by offering incentives or additional non-monetary value to influence the component system behavior.11
The ‘Effective Managerial Authority’ (EMA) that a SoS designer has over the component systems is composed of the Managerial Control described above, and the Influence exerted by the SoS designer to change the PNB of the component system, as shown in Figure 3. A greater EMA over a component system leads to greater likelihood of participation of the component system in the SoS. The risk of non-participation of a component system in the SoS is defined as the ‘Participation Risk’ (PR) of the component system, from the perspective of the SoS designer. Participation Risk is defined in Equation 1. In Figure 3, Participation Risk is shown by the ‘Gap’ indicated.
Participation Risk = 1 − (Effective Managerial Authority) (1)
= 1 − (Control(M C) + Inf luence(In)) where 0 ≤ (M C + In) ≤ 1
4 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

>[email protected]#+%-$"-5#,%+4>+-$<+-8+%,+5B+=-#+$-?+#+)[email protected]#-")-4-,"78"#+#$->6>$+7-C-,"*&=-?+7+D"%;-$"-5#,%+4>+-&",4&&6'8+%,+5B+=-B4&*+
7/&8)#"&9-!"7?5#4$5"A#I-A")-A!"S#$p%"a&-c4#e=-2(#0)&*0+9#,+-+78&"6+=-?6-.".-=+>[email protected]#+% Pasadena, CA, September 14-17, 2009
,+%$45#$6-5#-,"78"#+#$->6>$+7-84%$5,584$5"#-5#-.".

Participation Risk represents the uncertainty involved in

$45#$6-5#-

attaining a particular desired SoS design configuration. PR

allows the SoS designer to differentiate between easy to achieve

"78"#+#$+4>+=-?6-

SoS designs and relatively difficult to achieve SoS designs in the tradespace. In the SoS tradespace, PR can be used as a way

$-84%$5,584$5"#+4>5#@-5#)&*+#,+

to filter out difficult to achieve SoS designs. This information allows an SoS decision maker to compare designs on the basis of performance and cost as well as the risk of not achieving

those performance and cost values.

The PR of the component systems can be estimated by the

$4-+*/$=4&)[email protected]+>$4'$%"=")1=4A45+1+6$#"+*4()1&#)*4+1'4012*/$1%$4+#$4 &$1&"+**94&/#14&)4#$'/%F$i4g:u+#r&e"%";3+.&")E14fftive Managerial Authority,
C! omposed of Managerial Control and Influence. The ‘Gap’ Represents Participation
Risk.

SoS designer, based on approximations for the designer’s Managerial Control over the component and the estimated Influence, either monetary or otherwise, that the designer expects to have over the component. In this method, the Effective Managerial Authority (and the PR derived from it) is a vari-

able for that particular component. EMA can be varied over a

range generating many SoS designs which can them be plotted on the tradespace.

The PR for a particular SoS design can be derived from the PR estimates of the component systems in

the SoS. For example, if the PR for component system A is 0.8 and PR for component system B is 0.2, the

corresponding ‘Likelihood of Participation’ (LP) for each is (1−P R), or 0.2 and 0.8 for A and B, respectively.

Assuming that the participation of components is independent of each other, the combined Likelihood of

Participation for the SoS is the product of the individual components’ LP, i.e. 0.2*0.8 = 0.16. Therefore,

the combined PR for the SoS design AB would be (1 − LP ) = 0.84. This PR for each SoS design allows the

designer to compare within the tradespace the relative likelihood of achieving diverse SoS configurations.

The designer can identify high performance, low cost designs in traditional tradespace exploration, but the

newly added PR component enables the designer to also differentiate between configurations that are easy

to achieve versus those that are relatively difficult to arrange. This enables the SoS designer to compare

high performance-high risk designs with relatively lower performance-low risk designs that may be a more

attractive solution.

VI. Combining SoS Attributes to Quantify SoS Value Delivery
An integral part of the development of SoSTEM is the ability to estimate, in the concept exploration phase, the value generated by potential SoS designs. The SoS system value delivery is a function of the value delivery of the component systems, but is also greater than just the aggregation of the component system performance. Within the MATE framework, system attributes are decision maker perceived metrics used to measure the system value delivery to stakeholders. In SoSTEM, the component system attributes, as well as information about the concept of operations of components within the SoS, is used to model the SoS performance attributes. The classification of the component system attributes and the level of complexity of combination of the attributes is used to estimate the SoS integration cost. Combining attributes to model SoS value and estimate SoS cost impacts in order to generate SoS utility-cost tradespaces is a key aspect of SoSTEM.
According to Ross,12 system attributes can be classified on the basis of whether they are articulated by the decision maker, as well as the cost to display the attribute in the system. Attributes are classified into five categories by Ross,12 ranging from Class 0 to Class 4. Class 0 attributes are those that are traditionally considered in system design and are exhibited by the system by intentional design, whereas Class 1 attributes represent the existing latent value in the system, or the additional attributes beyond the Class 0 attribute set that can be utilized by the system designer at no additional cost. Class 2 attributes can be generated through combination of traditional component system attributes and system latent value, while Class 3 attributes are attainable through some change in the system at acceptable cost. Class 4 attributes are only available through drastic changes of the original system at prohibitive cost, or not achievable at all given the physical constraints of the original design and are thus not available to the SoS designer. The superset of attributes can be generated by combining the Class 0, 1, 2 and 3 attributes of all of the component systems available for the SoS provides the set of attributes that can potentially be displayed by the SoS design. Each SoS attribute is generated through a combination of one or more of the attributes in this superset.

5 of 14 American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009

As Class 0 and 1 attributes are more readily available to the SoS designer than Class 3 attributes, which
require modification of or addition to the!sy"s#tem$s%&a%t&s'o(m!e"c#ost),"S&oS*&at+t(r,ib-u.te+*s #tha( t utilize Class 0 and Class 1coamtptroibnuentetssyosfttehme actotmripbuonteesn.t systems /ar+e+0%m$o1r+e*e.a(s+i"ly(2ac*h&ie*va0b3l+e*c(,om"p,a(r4ed35t1o*those that require Class 3

!"#)"&*&+(,-.+*#.

!""#$%&"'

/ 6

!""#$%&"'

!""#$%&"'
!

!"#$%&'( )**+%$,*'-(
63.*7("&( /++0%$1+*(!53..*.8(
9*:*5(";( !"#$%&3+%"&

,",(/++0%$1+* ,",(!".+

!"#$#"%

,-.+*#(3++0%$1+*.(30*(7*?%.%"&(#[email protected]*0()*0?*%:*7( #*+0%?.(+A3+(30*(1.*7(+"(#*3.10*(+A*(.-.+*#(:351*( 7*5%:*0-

!"#)"&*&+(.-.+*#(3++0%$1+*.(30*(?"#$%&*7(+"( '*&*03+*(+A*(,",(1+%5%+-B(/++0%$1+*(?"#$%&3+%"&(A3.(3&( %#)3?+("&(,",(?".+.B(

!

!

,",(<15+%= /++0%$1+*
>+%5%+-

&'("

"

Figure 4. Combining Component Attributes to Obtain SoS-level Attributes in SoSTEM
Component attributes can be combined to generate a SoS-level attribute by selecting a level of combination complexity, effectively approximating the complexity of the interface required between components to generate the SoS attribute in the absence of more detailed information early in the design phase. The way in which the SoS components interact during SoS operation is an integral consideration in determining the interfaces between the components and also in determining how component attributes can be combined to achieve the SoS attributes. In early concept exploration, there are few constraints on the design space, so the SoS designer needs to explore the possible methods of attribute combination to determine which type is suitable for the particular SoS design. As this space of possibilities is large, as a first-order estimate, three types of attribute combination methods can be defined: low level, medium level and high level complexity. It is assumed that the higher the complexity of attribute combination, the higher the cost for creating an interface capable of this kind of combination. Low level methods may involve taking the best performance in a particular SoS attribute from the set of components in the SoS. If the SoS attributes are such that the mission is differentiated between the components (in other words, each component system provides a unique subset of attributes), then this may be the level of attribute combination that is required. Medium level attribute combination is required when there are more complex SoS concepts of operation. For example, when there is a handoff between different assets in the SoS, such that multiple components are involved in delivering a single attribute performance, the resulting SoS attribute performance is a combination of the two component attribute performances. Methods used for SoS attribute combination at the medium level may involve time-weighted averaging, such as the concept of time-weighted average utility.13 The highest level of attribute combination is required when multiple SoS components deliver performance relating to the same SoS attribute simultaneously. In this case, fusion of the attributes at a more detailed level than just averaging is required. A possible set of methods for combination of attributes at this level is data fusion. Data fusion is a well-developed field with methods available for combining data-related attributes, such as image resolution. Data fusion is defined as the combining of data from multiple sources along with database information to draw inferences beyond that obtainable through a single data source alone.14 The SoS designer can select a particular data fusion method for attribute combination in order to obtain the SoS attribute from multiple component sensors.
Once the method to combine attributes, dependent on the level of combination complexity chosen, is selected, the SoS attribute value is obtained as a function of the component system attributes.
SoS attribute value = f n(componentA attribute, componentB attribute, componentC attribute...) (2)
The described framework of combining attributes is utilized within SoSTEM to quantitatively model the SoS performance using any set of component systems, and enables the consideration of diverse multi-concept design configurations on the same tradespace. Figure 4 shows the steps of component system attribute combination leading to quantification of SoS utility in order to generate SoS tradespaces in SoSTEM.
6 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009
VII. System of Systems Tradespace Exploration Method (SoSTEM)
The SoS Tradespace Exploration Method (SoSTEM), pictorially represented in Figure 5, was developed as a method to aid decision makers in SoS tradespace exploration in the early conceptual design phase. The concepts of Participation Risk of components, combination of component system attributes to generate SoS attributes and studying the time-varying SoS value delivery through multi-epoch analysis are integrated into a quantitative method for SoS conceptual design that enables the modeling and comparison of a large number of design alternatives.
Figure 5. SoS Tradespace Exploration Method (SoSTEM)
The ten steps of the method are described in Table 1.
VIII. Case Applications
Aspects of SoSTEM were developed through application to a case study that involved the conceptual design of a Operationally Responsive Disaster Surveillance System. This was followed by the application of SoSTEM to the conceptual design of a Satellite Radar System.
A. Operationally Responsive Disaster Surveillance System The Operationally Responsive System for Disaster Surveillance is an example case to demonstrate the usefulness of the SoS tradespace exploration method in dealing with multi-stakeholder and multi-concept design problems, and to show that even with limited resources and functional modeling, this method can provide practical insights to the SoS decision maker. The case study research was conducted by a team of researchers from MIT and the Charles Stark Draper Laboratory. Given the numerous severe natural disasters in the recent past, such as Hurricane Katrina in New Orleans in 2005, the California wildfires of 2007 and 2008, and the Sichuan earthquake in China in 2008, there is a clear need for effective and timely observations of disaster locations in order to aid first responders. For disaster surveillance information to be of use to first-response and disaster relief efforts, it must be provided as soon as possible after unforeseen events in unknown locations. In other words, an operationally responsive system with short response time is necessary to generate disaster observing data that is useful for time-critical disaster relief.
To address the question of multiple SoS stakeholders, two SoS stakeholders - a firefighter and the Operationally Responsive System owner - were simultaneously considered in the stakeholder analysis. Heterogeneous SoS consisting of multiple single system concepts, both legacy and new, were compared on the same performance and cost basis in a tradespace, alongside single system concepts. Finally, the analysis of the effects of dynamic context changes including changes in stakeholder preference on the system through Epoch-Era Analysis was used to identify potentially value robust designs. While the full SoS tradespace ex-
7 of 14 American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009

Step Determining the SoS Mission Generating a List of Component Systems
Identifying Stakeholders and Decision Makers for SoS and Component Systems
Classifying Component Systems According to Managerial Control and Participation Risk
Defining SoS Attributes and Utility Information Defining SoS Context Changes
Modeling SoS Performance and Cost Tradespace Analysis Epoch-Era Analysis
Selecting Value Robust SoS Designs

Description
The SoS mission is the problem that the SoS must solve or capability gap that the SoS must fulfill, generated through interaction with the SoS stakeholders.
A list of legacy systems that may fully or partially fulfill the mission need is generated, and new system concepts can be proposed to fill any capability gaps. The output of this step of the method is a list of potential component systems for the SoS.
Local component system stakeholders and SoS level stakeholders are identified. In SoSTEM, it is assumed that the SoS and each legacy component system have a single decision maker each - this may require an aggregation of stakeholder preferences by defining a benevolent dictator. The benevolent dictator is a primary decision maker who takes actions to allocate resources in such a way as to satisfy the stakeholder network he/she represents.
The identification of the primary decision-maker for the SoS and each of the potential component systems enables the SoS designer to estimate the amount of managerial control that the SoS decision-maker has over each of the component systems. This is necessarily an iterative step, as the estimation of managerial control may not be accurate at this stage, due to limited available information.
Attributes (performance metrics used to measure system value delivery to the stakeholders) and utility (used to represent aggregate stakeholder satisfaction based on system performance on the tradespace) information is obtained through interviews of the SoS stakeholder.
A number of possible future context changes, such as SoS stakeholder preference changes, changes in control and participation risk, and changes in availability of component systems for inclusion in the SoS, are identified in order to study the changes in SoS value delivery over time in Epoch-Era Analysis.
Includes modeling legacy systems as well as clean-sheet systems, as well as modeling the SoS in terms of utility and cost in order to generate tradespaces where each design is represented in terms of performance and cost.
Tradespaces including both single system designs and multiconcept SoS can be analyzed and the Pareto Set of designs can provide a means to select SoS designs that are suitable for further study.
The models created for the SoS performance calculation can be repeatedly run for each future epoch described by the context changes defined earlier in the method. Thus many tradespaces are obtained, and tradespace statistics can be run over a string of epochs which compose an era. An era represents a potential future scenario for the SoS.
Tradespace statistics such as Pareto Trace Number can be used to select designs that are value robust over multiple epochs, or eras.

Table 1. Description of the Steps of the System of Systems Tradespace Exploration Method

ploration method was not applied to this case study, the demonstration of significant aspects of the method through the case study demonstrates the practical usefulness of aspects of the method as a prescriptive tool for decision analysis during early conceptual design.
Three different single system concepts were considered in the first application of the method to the case - satellites, aircraft and sensor swarms. Using SoSTEM, the component systems performance and cost could be modeled individually, and then through combining attributes, SoS consisting of multiple single systems (such as an aircraft and a satellite together) could also be modeled. The single systems and multi-concept SoS were then represented on the same tradespace. A second application of SoSTEM was used with more detailed aircraft and satellite models, and multi-epoch analysis was conducted with a number of potential context changes. For example, a change in the location of the target area of interest may occur during the
8 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009

system lifetime. In the case of this disaster surveillance system, it is expected that the system will need to observe a large number of different types of disasters on different locations on the globe during its operational lifetime. To demonstrate the application of SoSTEM to this type of context change, three different scenarios were considered in this analysis a) a hurricane disaster area, modeled on the Hurricane Katrina disaster area, b) a forest fire disaster, based on the Witch Creek Fire in California, and c) a cyclone disaster area, associated with the Myanmar cyclone in 2007.
Figure 6 shows an example of three epochs in which the target surveillance area is the context change under consideration. Tradespace statistics such as Pareto Trace Number15 are then used to identify passively value robust designs among the single system and SoS design concepts, which are then used as the set of designs to consider in further detail.

AOI 1, Utility v. Utility Tradespace 1

AOI 2, Utility v. Utility Tradespace 1

AOI 3, Utility v. Utility Tradespace 1

0.99

0.99

0.99

ORS Owner Utility ORS Owner Utility ORS Owner Utility

0.97

0.95 0.95

0.97

0.99

1

Firefighter Utility

(a) Katrina Disaster

0.97

0.95 0.95

0.97

0.99

1

Firefighter Utility

(b) Witch Creek Fire

0.97

0.95 0.95

0.97 Firefighter Utility

Aircraft Satellite SoS

0.99

1

(c) Myanmar Cyclone

Figure 6. Epoch-Era Analysis in SoSTEM with Varying Target Locations, Showing Multiple Single Concepts Along with SoS on the Same Tradespace (AOI = Area of Interest)

Design Num
2116 2764 925
1061

Concept
Aircraft Satellite SoS
SoS

Description
existing ScanEagle 120 km, sun-synch orbit, IR payload aircraft (small UAV w/ piston) + satellite (800 km, sun-synch orbit, IR payload) aircraft (existing Cessna 206) + satellite (120 km, 23 deg inclination orbit, IR payload)

Lifetime Cost ($M)
0.7 12.4 3.862
3.22

Normalized Pareto Trace1 (N=3)
1.00 1.00 1.00
0.67

Pareto Efficient For

Katrina Disaster
Yes Yes
Yes

Witch Creek Fire
Yes Yes
Yes

Myanmar
Cyclone Yes Yes
Yes

Yes

Yes

No

1 Normalized Pareto Trace Number is the Pareto Trace Number normalized over the number of epochs considered. In this example, 3 epochs were considered.

Table 2. Selected Pareto Designs for Three Epochs with Change in AOI

The set of Pareto efficient designs that provide high value to both stakeholders can be obtained for each of the three AOI considered. These designs are Pareto efficient for the utility-utility-cost objective, meaning that they are non-dominated designs that are the lowest cost solutions that can maximize the utility perceived by both stakeholders. It may be possible to find designs that are within the Pareto set for all of the AOIs. Other designs may perform well in one AOI, but not in others. Some sample designs from the Pareto sets for the selected AOI are shown in Table 2, to illustrate this point. SoS designs are found in the utility-utility-cost Pareto set as SoS provide high utility, and are comparable cost to some satellites and

9 of 14 American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes

AIAA Space 2009 Pasadena, CA, September 14-17, 2009
aircraft due to the assumption in this particular scenario that the SoS assets are only partially paid for by the SoS designer (as might happen if the SoS designer pays to lease the component systems owned by other organizations, instead of acquiring them), whereas costs for the aircraft and satellites are assumed to be fully paid by the decision maker (this assumption can be changed to look at other financing options in the future). The first three designs listed in Table 2 are designs that are high performance in all three selected AOI, while the fourth is a valid option if the system were only used for the continental U.S..
From Table 2, it is evident that the SoS tradespace exploration method enables the consideration of a diversity of concepts on the same basis, allowing the designer to consider many different Pareto efficient options that would have been unavailable if conceptual design had been conducted based on a single concept or single mission context.
SoSTEM enables the system designer starting with a large design space to consider many possible options with a relatively small amount of modeling and analysis effort, and then identify a smaller set of value robust designs suitable for further detailed study. The quantitative comparison of a variety of single and multiconcept designs leading to the selection of options for detailed design is in contrast to the simple narrowing of the concept design space early as is sometimes done in traditional systems design. As a result, a larger number of value robust designs can be identified with SoSTEM than with qualitative methods or traditional concept exploration methods alone. While the case used for this study was a hypothetical one, the insights obtained through analysis using this method clearly show that the method can provide valuable information to decision makers who are trying to select value robust designs early in the conceptual design phase.
This case study is discussed in more detail in Chattopadhyay, et al.16
B. Satellite Radar System
The steps of SoSTEM were also applied to the conceptual design of a Satellite Radar SoS, consisting of a Satellite Radar (SR) and airborne radar assets such as JSTARS and Global Hawk. The Satellite Radar System analysis is part of a larger discussion of Intelligence, Surveillance and Reconnaissance (ISR) within the DoD. In a report from the Joint Defense Science Board and the Intelligence Science Board Task Force on Integrating Sensors,17 an in-depth discussion of the current state of integration of sensor intelligence, as well as potential future capability gaps is provided. As part of the emphasis on net-centric communications to integrate assets, the DoD is making use of legacy systems in SoS that provide enhanced capabilities for ISR. SoSTEM enables the consideration and comparison of SoS that include the Satellite Radar as a component, assisting decision makers in comparing the merits of a large number of designs. Application of SoSTEM to Satellite Radar may lead to interesting insights that can inform the discussion about this system in the future. Ross, et al.18 provides an introduction to the Satellite Radar design problem.
The component systems were classified according to the Managerial Control available to the SoS designer (in this case, the Satellite Radar program manager) over the component systems. The SR program manager is assumed to have complete Managerial Control over the SR component system and a lower level of Managerial Control over the JSTARS and Global Hawk component systems. The SoS attributes and utility information was defined through interviews of proxies for the SR program manager as well as satellite contractor organizations and user proxies. The attributes were categorized into two major sets - attributes focused on imaging-related system performance, and attributes focused on target tracking-related system performance. The target tracking attributes were primary for the initial SoS design, with three of the attributes -target track life, minimum detectable velocity and minimum target radar cross section (RCS) selected as the main attributes for the SoS design. Attributes were mapped to component systems within the SoS in order to define the modeling process.
Each of the component systems was modeled using parametric computer models for new component systems or look-up tables of existing component system performance statistics. The SR component system was modeled in detail using a parametric model relating the SR design variables to the attributes, while the existing JSTARS and Global Hawk system performance was modeled using publicly available performance statistics in those attributes. The SoS consisting of pairs of component systems - SR and JSTARS, and SR with Global Hawk - was modeled first using a low level of attribute combination, and then a medium level of attribute combination each representing a chosen concept of operations for the SoS. In the first case, there is simultaneous operation of the SoS component systems, during which the component system attribute with the best value is chosen as the corresponding SoS attribute performance. This represents a low level of attribute combination complexity, as a selection is made between two simultaneously tracked attributes. A situation like this would potentially arise when the imaging attributes of the SoS are primarily derived from
10 of 14
American Institute of Aeronautics and Astronautics
(c) 2009 by D. Chattopadhyay, A.M. Ross, and D.H. Rhodes
SosComponent SystemsSos DesignerSystemsSostem