Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

With the advent of “designing for affordability as a requirement” [1], various methods have been proposed to incorporate explicit cost and schedule considerations on top of performance parameters for affordability analysis during early-phase design of systems, programmes and portfolios. This is to minimize incidences of cost overruns and schedule delays in future. However, current methods for affordability analysis have been limited to tradeoffs between performance and total cost or performance and overall schedule, without holistic consideration of all three design drivers in tandem. Furthermore, these tradeoffs are conducted in static operating environments or in single point futures, without accounting for potential fluctuations in user needs, external constraints and operating contexts over time.

Without consideration of dynamic design elements, there is a risk of overlooking valuable design solutions that are more robust to performance, cost and schedule changes. To mitigate this risk, more emphasis can be placed on non-functional design criteria called “ilities”, which are system properties that often manifest and determine value after a system is put into initial use [2]. As designing for ilities concern wider impacts on design with respect to time and stakeholders, they can better promote successful design development as compared to solely performance criteria. By defining affordability as the property of becoming or remaining feasible relative to resource needs and resource constraints over time, affordability can be treated as an ility that drives the design of more affordable yet technically sound architectures [3, 4]. With affordability as a high-priority ility, Multi-Attribute Tradespace Exploration (MATE) [5] and Epoch-Era Analysis (EEA) [6] can be used to establish a method called Tradespace-based Affordability Analysis (TBAA). Through this method, designing for affordability in systems, programmes and portfolios can ensure consistent value delivery with greater cost and schedule effectiveness.

1.1 Affordability in Systems, Programmes and Portfolios

The key principle in applying affordability as an ility is the increased emphasis on resources upfront during design. Resource needs and resource constraints, together with performance needs and performance constraints, can be identified early on wherever possible [3, 4]. A resource is defined as the aggregation of cost, schedule and other non-monetary factors necessary for architecting, development and operation. Resource needs are then the set of resource requirements elicited from stakeholders. Similarly, performance needs are the set of performance requirements. Both performance and resource needs are direct reflections of stakeholder preferences and they quantify the respective benefit and expenditures expected in a desirable design solution.

The concepts of resource and performance constraints are introduced for affordability analysis. Resource constraints are the statements of restrictions on these requirements that limit the range of feasible design solutions. Specifically, they are upper-bound restrictions imposed on the range of resources that could be made available to stakeholders. They are independent of stakeholder preferences and are often imposed to actively prevent cost and schedule overruns. Rational stakeholders and designers will prefer to have greater flexibility in their resource expenditures so as to increase their range of design solutions, but resource constraints limit that range to keep solutions within realistic time and monetary budgets. Resource constraints thus provide a more accurate and genuine depiction of stakeholders, designers and their real environments, where time and money are often tightly controlled. Examples of such restrictions include budget caps for investment cost and delivery deadlines.

Performance constraints are different as they can represent external factors that place upper or lower bounds or both on the range of performance attributes. An example of an upper-bound constraint may be reducing the firing range of a weapon for safety considerations, and an example of a lower-bound constraint may be having a minimum workspace inside a manned spacecraft for adequate maneuverability. Rational stakeholders and designers will prefer to achieve the greatest performance range possible given available technology, rather than being limited in their design choices early on by requirements not directly related to technical feasibility. Similarly, they provide a more accurate and realistic depiction of stakeholders and their real environments, with respect to what is technically possible, what is minimally required and what is allowed in design. Therefore, the identification of all constraints can prevent the initial limiting of stakeholder preferences and discarding potential designs in a myopic manner simply to meet external limitations.

Resource needs, resource constraints, performance needs and performance constraints can change over time. Design solutions become feasible if they fulfill resource needs and function within the resource constraints for a fixed context, while fulfilling performance needs and remain within performance constraints concurrently. As needs and contexts change, solutions may remain in, enter, or exit the feasible set of solutions. Affordable solutions are thus those that remain in or enter the feasible set of solutions. Therefore, the goal of affordability analysis is to identify solutions that remain feasible throughout or at least for a large part of the system, programme or portfolio lifecycle. Using this operationalization, an affordable solution will be one that is capable of satisfying changing resource requirements and resource constraints, as well as satisfying changing performance requirements and performance constraints over time.

Designing for affordability requires satisfying multiple performance, cost and schedule needs of stakeholders over time. With the recent increase in demand for emergent capabilities realized only by System of Systems (SoS), a single system alongside other homogeneous or heterogeneous systems can be part of a larger programme, which itself can be part of a larger homogenous or heterogeneous portfolio alongside multiple independent or semi-independent programmes. Due to the greater scales and complexity in programme and portfolio designs, it is in the interest of this paper to build upon earlier studies [3] and extend the conduct of affordability analysis beyond programme levels to portfolio levels.

As a result, a progressive design approach from system to programme to portfolio is required as a logical first-step solution. System-level design precedes programme-level design since the latter requires joint consideration of multiple independent or semi-independent constituent elements, which are typically the system-level design solutions and other programme-level design considerations. Finally, if the programme is part of a larger portfolio, portfolio-level design can be performed, where new or legacy assets are selected and simultaneously invested into collectively provide a set of joint capabilities [7]. The bottom-up approach thus demands the aggregation of system-level affordability for each constituent system to establish programme-level affordability and finally portfolio-level affordability, thereby providing overarching guidance to architecting emergent capabilities within realistic bounds of cost and time. Through this approach, affordable solutions for system, programme and portfolio design can be found collectively.

2 Tradespace-Based Affordability Analysis

Tradespace-based Affordability Analysis (TBAA) can be employed when applying the bottom-up approach. Leveraging the increased availability of computation power, the search for affordable solutions and affordability analysis can be conducted through a synthesis of these methods: Multi-Attribute Tradespace Exploration (MATE) [5] and Epoch-Era Analysis (EEA) [6]. MATE and EEA have been modified from their original constructions to include affordability considerations. Depending on the intent and desired rigour of analysis, both MATE and EEA, or only MATE, can be applied at each level of analysis to select affordable design solutions.

2.1 MATE for Affordability Analysis

MATE in TBAA [3, 4] is the value-driven search for affordable designs by aggregating multiple performance and resource attributes, as well as stakeholder utility for each attribute, into a single utility metric (MAU: Multi-Attribute Utility [8]) and expense metric (MAE: Multi-Attribute Expense [9]) respectively. By enabling a model-based investigation into many design alternatives, MATE allows a holistic consideration of performance utility and resource expense during early-phase design while avoiding premature fixation on point designs and narrow requirements [10]. MATE thus enables the direct exploration, comparison and analysis of many design alternatives on a single tradespace to make more informed decisions during affordability analysis.

The general procedure and data flow for MATE in TBAA is shown in Fig. 1. MATE begins with the establishment of design variables (factors within the designer’s control that will drive the attributes), and epoch variables (factors that parameterize uncertain potential operating contexts, i.e. performance needs, resource needs, performance constraints, resource constraints) by stakeholders and architects of the system, programme or portfolio to be designed. To incorporate stakeholder preferences for each attribute, design-to-value mapping of performance, as well as all resource parameters, is conducted. Applying logical assumptions and scientific principles, design and epoch variables are used to produce a tradespace model that will generate design alternatives for each epoch (period of fixed contexts, needs and constraints), and calculate the MAU and MAE to enable evaluation of the alternatives.

Fig. 1
figure 1

Tradespace-based affordability analysis (TBAA)

Full size image

Tradespaces are two-dimensional plots populated by design alternatives and parameterized by their calculated MAU and MAE. With tradespaces, design alternatives can be evaluated and even compared in terms of multiple performance and resource attributes in tandem. Each performance attribute delivers a unique independent utility and can be combined with other performance attributes to produce an overall utility for a design using the MAU function. Similarly, each resource attribute has a unique independent expense and then combined in the same manner to produce an overall expense using the MAE function. MAU is a single number ranging from 0 to 1, where 0 is defined as minimally acceptable and 1 as the point where no further benefit is gained. The notion of MAE is akin to negative utility, where 0 denotes minimal dissatisfaction and 1 denotes complete dissatisfaction. Both MAU and MAE functions can be linearly weighted sums if performance and resource attributes independently contribute to the aggregate utility and expense respectively.

Performance and resource constraints are incorporated into the evaluation process after the generation of tradespaces. Upper and lower bounds on performance attributes are aggregated using the MAU function to obtain the maximum and minimum performance constraint levels respectively. Likewise, the upper bounds on resource attributes are aggregated using the MAE function to obtain the maximum resource constraint level. Shown in Fig. 2, these constraint levels are reflected as horizontal and vertical planes that segment the tradespace. If there exists an intersection between the minimum utility constraint level and a design point, the vertical planes through this design is referred to as the derived minimum expected expense constraint level. The area on the tradespace bounded by the constraint levels is the affordable solution region. An affordable design solution will then be any design point that falls within the affordable solution region. The use of constraint levels can thus help stakeholders and designers easily identify the solutions that can become unaffordable due to changes in performance or resource constraints over time.

Fig. 2
figure 2

Multi-attribute tradespace exploration data flow for TBAA [3, 4]

Full size image

Therefore, affordable design solutions for each epoch can be obtained through MATE. However, to identify design solutions that become or remain affordable across different epochs, EEA can be applied thereafter. The affordable design solutions can then become design variables for the next level of analysis, since systems can be constituents of programmes and programmes can be constituents of portfolios.

2.2 EEA for Affordability Analysis

EEA can be used in conjunction with MATE to enable the evaluation and comparison of many different design alternatives through analysing changes in their value delivery and expense across different periods of operating contexts [3, 4]. These periods are called epochs and they are defined during MATE by the fixed set of epoch variables describing the needs and constraints in which the system, programme or portfolio operates. By analysing the affordable solution sets across different tradespaces and their corresponding epochs, design solutions that remain technically sound and affordable across all or for at least a desired number of epochs can be found. Epochs assembled into an ordered sequence form an era that can describe a potential progression of contexts over time. An era can simulate a conceivable lifecycle while multiple eras form the set of possible lifecycles that a design can undergo. EEA can thus be conducted over multiple epochs and multiple eras to evaluate system design concepts and to assess the temporal progression of performance and resource attributes for different design alternatives. Single-epoch, multi-epoch, single-era and multi-era analysis can be performed to assess the impacts of time and context on value delivery (utility and expense) under the effects of changing contexts and mission requirements.

EEA discretizes the lifecycle according to impactful changes in the operating contexts through the constructs of epochs and eras, instead of traditional system milestones. Figure 3a, b illustrate how performance-centric EEA and resource-centric EEA can be conducted. In both figures, the vertical columns represent the epochs that are time-ordered to form an era, while different colours of these epochs represent changes in context. In Fig. 3a, the vertical axis measures performance needs (utility), while the minimum and maximum utility constraint levels define the affordable solution region. In Fig. 3b, the vertical axis measures resource needs (expense), while the minimum and maximum expense constraint levels further define the affordable solution region. As needs and operating contexts change, the MAU and MAE for design alternatives also change, thereby reshaping the tradespaces and affordable solution regions obtained for each epoch.

Fig. 3
figure 3

a Original EEA for analysing performance attributes; b Modified EEA for analysing resource attributes [3, 4]

Full size image

Changes in MAU and MAE for a design alternative can be represented by a trajectory in the performance space and a trajectory in the resource space respectively. The trajectory of the design alternative over time in Fig. 3a can be interpreted in the following manner: The design alternative traverses all five epochs while staying within the affordable region unique to each epoch, thereby fulfilling all performance needs and performance constraints over time. Similarly, the trajectory in Fig. 3b can be interpreted in the following manner [3]: As the design alternative traverses through the first three epochs while staying within the affordable region unique to each epoch, the system is remaining affordable. In the transition to Epoch 4, the design alternative exceeded the maximum expense constraint level, thus becoming unaffordable by the end of the epoch. Finally, the system transits back to the affordable region in Epoch 5 and is regarded as becoming affordable. With respect to EEA principles, an affordable design solution is thus one that has both performance (utility) and resource (expense) trajectories that remain within the affordable solutions defined across all epochs or for at least a desired number of epochs [4]. Therefore, MATE and EEA can be used to establish TBAA and facilitate the search for affordable design solutions.

3 Design Case Study: Federated Satellite Systems

TBAA is applied to a case study, which entailed the design and implementation of Federated Satellite Systems (FSS) [4]. The FSS comprises many heterogeneous satellite constellations or monolithic satellites in Low-Earth Orbit (LEO) working together to function as a supplier base for in-orbit data storage and processing capacity [11]. The FSS can be catered to customer spacecraft in other orbits that do not have direct access to ground stations during critical periods of time in operation and choose to transfer data via inter-satellite links (ISL) to supplier spacecraft for temporary storage or processing in situ. The FSS can thus revolutionize the design and operation of future spacecraft, which can leverage the communications and data handling capabilities of existing spacecraft in the FSS and operate without dedicated subsystems for these capabilities.

Based on a high-level assessment of its design and mission requirements, the FSS can be regarded as a homogeneous SoS that requires multiple phases of development and launching different satellite constellations to achieve its desired capability. In view of decreasing budgets and little margin for schedule overruns, it can be complex to design the FSS for affordability given the multitude of performance, cost and schedule attributes to be considered for every satellite and every constellation. Stakeholders at different levels of FSS development may also have different preferences towards performance and resource attributes depending on the operating context of their satellite constellations. Also, the development of new satellites often encounter constraints related to national security, safety, budgets and congressional decisions, which are usually considered external to the design process but can impact the selection of preferred designs.

The complexity and scale of this design problem would thus benefit from the use of TBAA in the design for affordability of the FSS. The development of the FSS could be considered as the development of a homogeneous portfolio of various satellite constellation programmes. With the application of TBAA using the bottom-up approach, preferred designs for the FSS could remain affordable at the system, programme and portfolio levels over time.

3.1 System-Level Designs and Analysis

A hypothetical development timeline for the FSS was proposed to facilitate epoch and era construction. Four operating contexts and six sets of mission needs were proposed, yielding 24 possible epochs. However, only seven of the 24 epochs were analysed. This was because the case study assumed that the development of the FSS could be conducted over seven phases, which could be described by seven sequenced epochs to form an era. This era was hypothetically imposed over the years 2016–2055. Each epoch or phase would represent 5 years, apart from the first epoch that would represent 10 years. Only one satellite constellation would be designed and launched in each epoch by a unique stakeholder with unique preferences and constraints. The FSS would thus comprise seven different satellite constellations operated by seven stakeholders, which would deliver the full operational capability over 2016–2055 (Table 1).

Table 1 Design Variables (DV), Performance Attributes (PA) and Resource Attributes (RA) for System-, Programme- and Portfolio-level design
Full size table

MATE was conducted for system-level TBAA. With knowledge of epoch variables, system design variables, system performance attributes, system expense attributes and their interactions, the system tradespace model was developed. 34560 design alternatives were generated for all 24 epochs. Stakeholder preferences were hypothetically established based on the different missions conducted in different contexts. Design-to-value mapping was performed and utility and expense curves were obtained for all the attributes. MAE and MAU values were then calculated for all design alternatives in every epoch, yielding 24 tradespaces. The seven tradespaces corresponding to the seven development phases were then selected and their Pareto frontiers were identified (coloured in red as shown in Epoch 1 of Fig. 4). Design alternatives not on the Pareto frontiers were removed to facilitate analysis.

Fig. 4
figure 4

Results of MATE across seven sequenced epochs [4]. High-, medium- and low-risk designs were chosen from the affordable solution region in each epoch

Full size image

Expense budget risks were also accounted for through the application of lognormal distributions with different variances to the Pareto frontier solutions. Performance and resource constraint levels were applied to determine the affordable solution regions. No maximum performance constraints were assumed in this study. Three preferred system design solutions (High-Risk, Medium-Risk, Low-Risk) were down-selected. Their design variables and attributes were further investigated to identify commonalities that might reveal key design principles. The preferred system design solutions were the affordable system solutions and they were used as design variables for programme-level analysis. No EEA was conducted for system-level analysis.

3.2 Programme-Level Designs and Analysis

MATE was conducted for programme-level design and analysis. Programme performance and resource attributes were made up of aggregated system attributes as well as new attributes that measured emergent behaviours from operating multiple homogenous satellites in a constellation. 1080 programme design alternatives were generated. Similarly, programme design alternatives not on the Pareto frontiers were removed and lognormal distributions were applied to the remaining alternatives to simulate programme budget risk. Based on programme budget risk levels, two or three affordable programme design solutions were selected from each epoch thereafter for EEA (See Fig. 5).

Fig. 5
figure 5

Identifying affordable programme design solutions using EEA [4]

Full size image

Through analysing the utility and expense trajectories, programme design solutions that remained affordable from their epoch of launch and deployment were identified. Combining all identified programme solutions per epoch, 72 portfolio designs were obtained.

3.3 Portfolio-Level Designs and Analysis

Finally, portfolio-level design and analysis was conducted. MATE was performed with portfolio design variables, performance attributes and resource attributes. Similarly, these attributes were aggregates of programme attributes and represented the emergent behaviours of leveraging multiple satellite constellations in the FSS configuration to perform various science missions as well as provide onboard data processing capabilities. The portfolio design variables are the affordable programme solutions found in each epoch using EEA. No new variables or attributes were introduced at portfolio analysis. A portfolio budget was introduced as a new resource constraint, which was fixed for all portfolio designs. A tradespace with 72 portfolio designs was generated and three Pareto frontier portfolio solutions were selected for further analysis. More detailed analysis was performed to determine the resource expenditure and performance profiles of individual constellations, and ultimately the selected portfolios.

The general profiles of the three portfolio solutions were ‘Mid-Utility/Mid-Expense’ (Portfolio 43/72), ‘High-Utility/High-Expense’ (Portfolio 19) and ‘Highest-Utility/Highest Expense’ (Portfolio 1). The resource expenditure profile over time of each portfolio was analysed by determining the various costs and total cost committed annually to operationalizing the FSS. The performance profile over time of each portfolio was analysed by determining the overall annual data capacity and the overall science value delivered (measured in data packet volumes). Comparing and analysing the three portfolios, only Portfolio 19 was found to have not exceeded the portfolio budget at any point in time (See Fig. 6). Portfolio 1 and 43 breached the budget in one or more years during their development lifecycles. Compared to Portfolio 1, Portfolio 19 was less risky in terms of resource expenditure and offered more progressive performance levels. Compared to Portfolio 43, Portfolio 19 offered better performance during the earlier years with rising budgets and would still be able to sustain FSS operations even at its lowest data capacity. Therefore, an affordable portfolio solution (Portfolio 19), alongside affordable programme and system design solutions were collectively obtained at the end of TBAA using a bottom-up approach.

Fig. 6
figure 6

Resource expenditure and performance profiles for Portfolio 19 [4]

Full size image

4 Discussions and Conclusion

Applying TBAA with a bottom-up approach is a logical first-step solution that can facilitate the design for affordability from system to programme to portfolio through the holistic consideration of performance needs, resource needs, performance constraints, and resource constraints over multiple epochs and multiple eras. The FSS case study demonstrated its feasibility, where a single portfolio design along with system and programme designs for the affordable development and deployment of FSS satellite constellations was obtained. For further analysis, more than three preferred designs could be picked at each level of analysis and TBAA could be conducted iteratively with affordable solution sets of different sizes until the most desirable solutions could be obtained. Therefore, TBAA could be applied to a complex SoS with homogeneous constituent systems [7] whose development roadmap resembles the bottom-up nature of the FSS. TBAA thus has immense potential in the architecting of complex systems, programmes and portfolios with greater cost and schedule effectiveness.