System Adaptability
Lead Authors: Haifeng Zhu and Eileen Arnold
Need introductory text.
Overview
Dictionary Definition
The term adapt means “to make fit (as for a new use) often by modification” (Merriam-Webster, Inc. n.d.). The term adaptation is traditionally used in natural ecosystems as “modification of an organism or its parts that makes it more fit for existence under the conditions of its environment” where the conditions can be either positive or negative (Andersen & Gronau, 2005).
Systems Engineering Meaning
[Art: A Google Search for "Systems Engineering Meaning" will pull this up - suggest perhaps rewording. Maybe "Adaptability in Systems Engineering"]
Following the dictionary definition, System Adaptability is a system’s ability to satisfy mission and requirement changes, with or without modifications (Zhu, 2015) (Jackson, 2016) (Zhu, et al., 2016). A system is more adaptable if it supports mission and requirement changes at less cost which is an indication how difficult a system is to adapt.
The adaptability concept is applicable to both real and conceptual systems as defined in (Sillitto, Hillary, et al. , 2017).
There are concepts that are related to system adaptability such as system resilience, flexible design, and design reuse. System resilience has traditionally focused on graceful degradation and recovery of a system's performance, triggered by adverse events and planned for in advance. System adaptability focuses on solutions for changes caused by either adversarial or beneficial events. Flexible design in industrial engineering (Saleh, Mark, & Jord, 2009) often requires up-front investment and justification of redundant designs or facilities, with more than 50 kinds of flexibilities defined and studied. System adaptability looks into future changes to inform the current design choices for reduction of unnecessarily redundant designs. System adaptability encourages reuse, but does not promote it at the expense of higher cost.
Three Fundamental Factors
To compare the adaptabilities among different systems, Mission and Requirement Evaluation Space (MRES), Design Space and Switching Cost are the three minimum factors needed.
Mission and Requirement Evaluation Space (MRES)
Current practices assume each requirement is for current needs and is often subject to budget constraint perceptions. MRES differs in that it uses systems thinking to project to the future, and identifies requirements with high risk of change. These uncertain requirements may come from stakeholder’s decisions, market changes, technology progresses and engineering uncertainties, etc. (Zhu, 2023) which are optional potential needs. MRES is a collection of current needs (i.e. requirements and missions) and optional potential needs, that can be distinguished with a “required/optional” attribute as an example. These projections into the future provide valuable information to the current design for adaptability.
Design Space
To have a comparison function defined, one needs to have at least two systems. A collection of different systems being designed is called Design Space (or Trade Space) in which Tradeoff Studies (or Trade Studies) (Cilli & Parnell, 2014) (NASA, 2016) are performed to select a design, based on a set of decision factors, one of which can be the systems’ adaptabilities.
Switching Cost
If the adaptation needs modifications, the ease of modifications indicates the degree of adaptability. The cost of switching from one system design/state to another design/state is called Switching Cost which is a good indicator of how difficult it is to adapt.
Note that the cost here may not necessarily be a financial cost, and can be time, fuel, complexity as adopted in (Zhu, et al., 2016) or any metric that the designers and/or users are concerned about with regard to the difficulty of modifications. Traditional financial cost estimation assumes a system is developed from scratch, which in reality is rarely exercised. Many products are developed by modifying designs from prior products, where the cost is actually a switching cost. Methods of estimating the switching cost for a complete generic system, rather than individual components or systems of a specific kind, were initiated mainly by two research teams: a process-based method was developed and later reported in (Zhu, 2018) and a parametric approach was developed in COSYSMO (Alstad, 2019).
Summary
MRES, Design Space and Switching Cost are three factors that are highly recommended when comparing adaptable systems, based on the development history of system adaptability.
Development History
There are two other major prior works on system adaptability, by (Gu, Hashemian, & Nee, 2004) and (Ross, Rhodes, & Hastings, 2007). (Gu, Hashemian, & Nee, 2004) defines adaptability as a normalized saving in switching from one product to another, emphasizing the costs as the main considerations. In (Ross, Rhodes, & Hastings, 2007), for a design A and another design B, if A can be modified to become B, a link is created between A and B. They define the adaptability of a design as the outdegree or filtered outdegree from that design. A design’s outdegree counts the links from this design to the other designs. In a design space, some designs support the mission better than others. Without considering the support to missions or requirements, measuring the cost to switch to another design (Gu, Hashemian, & Nee, 2004) or how many other designs one design can switch to (Ross, Rhodes, & Hastings, 2007) can result in inverted measures, where an entity that would receive a higher value of the measurement result than another entity receives with a lower value result. A design that is able to switch with low cost to many other designs that are of no or low value for missions may receive a higher adaptability score than another design that actually supports the needed missions.
Fundamentally, these two works capture only two of the three fundamental factors described in Section 1.3 without the MRES factor, which is needed to prevent inverted measures.
In an eco-system, a species adapts in order to survive and exist longer. In systems engineering, being able to support future missions/requirement needs prolongs the service life of the system and extends its existence, which is well aligned with the eco-system definition of adaptability.
There are domain-specific definitions of adaptability and switching costs in IT, control and self-adaptive systems areas. For details, please refer to the “Related Areas” section in (Zhu, et al., 2016).
Demonstrating Adaptability: An Aerospace Example
In the following example, a high-level abstraction of an aircraft engine is used to illustrate how to evaluate the adaptability of system designs (Zhu, et al., 2016) using MRES, Design Space and Switching Costs.
MRES
Capturing the flight missions for our engine example is the first step. The following operations set the stage for our key mission requirements:
- One engine inoperative
- Takeoff Gradient of Climb
- Climb Rate
- Cruise Range
Three typical types of aircraft are used in commercial airline operations:
- a city-to-city short range aircraft,
- a regional jet and
- a transatlantic jet.
One engine inoperative support is required per aviation regulations. In addition, Takeoff Gradient of Climb, Climb Rates, and Cruise Range are as indicated in Table 1.
| Aircraft Type | Takeoff Gradient | Climb Rate (Ft./Min.) | Cruise Range (Nautical Miles) |
|---|---|---|---|
| City-to-City Aircraft | 1.2% (low) | 1000 (low) | 700 (short-range) |
| Regional Jet | 1.2% (low) | 1500 (high) | 2000 (mid-range) |
| City-to-City Aircraft | 1.2% (low) | 1500 (high) | 4000 (long-range) |
Suppose a customer wants to build a customized aircraft that has different mission preferences beyond the regular 3 types of aircraft, and the engine supplier is asked to design an engine to support the customization. If enumerating all possible values for each mission parameter, where each parameter takes 3-values (e.g. low, median and high values), there would be a total of 27 missions. However, the customer prefers to consider only the 6 missions described in Table 2 and the remaining missions are deemed as not needed and should not be considered in the design space. In this table, the “optional” preferences mean the customer reserves those mission supports as possible future needs.
| Missions | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| Takeoff Gradient | low | low | low | high | high | high |
| Climb Rate | low | low | low | low | low | low |
| Cruise Range | long-range | mid-range | short-range | long-range | mid-range | short-range |
| Preference | optional | required | required | optional | optional | optional |
Design Space
In this top abstraction level, an exhaustive search for all possible engine designs is conducted and 12 design architectures are found. Each engine architecture may support one or more of these 6 missions. To simplify our discussion, 3 representative architectures were selected and shown in Figure 1 which will be used to illustrate how architecture optimization is performed.
[Figure 1. Selected Engine Architectures]
Note: Purple links represent the mechanical path and green links represent the gas path.
Switching Cost
In this aircraft engine example, costs of switching from each architecture to each of the other 11 architectures are calculated.
Architecture Optimization
When deciding which architecture to pick, a naïve approach would be picking the one that supports most of the missions in MRES. This often leads to a costly design that requires significant investment upfront that is undesirable. One of the advantages of developing a system with adaptability in mind is that it does not require significant investment upfront. For example, let us assume Architecture 3 and 9 can both meet the current needs, but there is a decent chance that changes may be needed such that only Architecture 6 is capable of supporting the future needs. If Architecture 3 and 9 are both acceptable in cost, but the switching cost from Architecture 3 to Architecture 6 is much higher than the switching from Architecture 9 to Architecture 6, one might want to choose Architecture 9. Indeed, it is a straightforward preference and the right way to obtain a sustainable design.
This discussion only considers the system adaptability factor. If more factors are considered, such as schedule, company strategy, etc., one can include all these as decision factors in the trade study.
Other Applications
The same concept can be applied to any other system domain, such as Heating, Ventilation and Air Conditioning (HVAC) systems (Zhu, 2019), medical systems, transportation systems or social systems.
Quantification
System adaptability can be quantitatively summarized to a metric, the Adaptability Metric (Zhu, et al., 2016) which can be conveniently used as a rule of thumb for engineers to judge how adaptable their system design is, especially when they have a fixed and limited budget. The metric has a range of [0, 1] where a higher value indicates the system is more adaptable:
- Perfectly Adaptable: when a design supports all missions/requirements in MRES, the adaptability metric is 1. The “support” to missions and requirements factor into weighted parameters of stakeholder determination for both the current needs and potential future needs.
- Mostly Adaptable: If a design cannot support all of the MRES but can switch to one of the other designs supportive of all needs, with a switching cost that is within a user-specified threshold, the adaptability metric is between 0.5 and 1, where a higher value indicates a lower switching cost. The user-specified cost threshold indicates how much additional cost the vendor is willing to pay after the product is developed, should potential future changes be needed.
- Partially Adaptable: If a design can support, or within the user-specified switching cost threshold switch to another design to support, all the current needs but only part of the optional needs in MRES, this design is Partially Adaptable. Its adaptability metric receives a value between 0 and 0.5, with higher values indicating that below the switching cost threshold, more optional needs are supported.
- Non-Adaptable: If an adaptability metric is 0, it indicates the design can only support current needs in MRES. Supporting any optional ones will exceed the cost threshold.
As a result of the above aircraft engine example: Architecture 9 is perfectly adaptable, achieving an adaptability metric of 1. Architecture 3 is mostly adaptable receiving a metric of 0.6, and architecture 6 is partially adaptable receiving a metric of 0.25.
Technology and Engineering Management Phase
Such a metric is useful in system development and management (Zhu, 2015) whereby each design’s adaptability metric is calculated and factored into trade studies for down-selections.
[Figure 2. Adaptable Design Process]
“Switching costs also significantly influence managerial decisions. They have been shown to influence the competitive strategies that managers adopt” (Whitten, 2009) summarized from (Eliashberg & Robertson, 1988). The adaptable design process (Figure 2) evolves with varying stakeholders, e.g. management, customers and technical teams. At the beginning of defining a system design, information such as requirements, financial budget information, management vision and a roadmap are generated, where missions and requirements are collected into MRES along with possible change estimations. The technical team then generates different designs within the Design Space where the adaptability metric is calculated for each design. The metric can then be used for design selections. Comparisons of using an adaptability metric instead of a conventional design process showed two major differences: 1) the use of MRES to systematically and formally capture future needs, as opposed to having them informally and partially discussed in an ad hoc manner and 2) the calculation of an adaptability metric allows the sustainability of designs factored in anticipatory decision making.
Similar processes can also be used in government acquisition, where each bidder would be required to submit the adaptability metric along with their proposed solution. A higher adaptability indicates that the proposed solution likely requires fewer costs in the future when the government follows up on additional changes.
References
Works Cited
Alstad, J.P. 2019. "Development of COSYSMO 3.0: An Extended, Unified Cost Estimating Model for Systems Engineering." Procedia Computer Science, Volume 153: 55-62.
Andersen, K., & Gronau, N. 2005. "An Approach to Increase Adaptability in ERP Systems: Managing Modern Organizations with Information Technology." Information Resources Management Association International Conference.
Cilli, M.V., & Parnell, G. S. (2014). "Systems Engineering Tradeoff Study Process Framework." INCOSE International Symposium, Philadelphia, PA, USA.
Eliashberg, J., & Robertson, T.S. 1988. New product preannouncing behavior: A market signaling study. Journal of Marketing Research.
Gu, P., Hashemian, M., & Nee, A. 2004. "Adaptabile Design." CIRP Annals, Manufac.Tech.
Jackson, S.(2016. Evaluation of resilience principles for engineered systems. University of South Australia. Merriam-Webster, Inc. (n.d.). Merriam-Webster Dictionary. Merriam-Webster, Inc.
NASA. 2016. NASA Systems Engineering Handbook, Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
Ross, A.M., Rhodes, D.H., & Hastings, D.E. 2007. "Defining System Changeability: Reconciling Flexibility, Adaptability, Scalability, and Robustness for Maintaining System Lifecycle Value." Proceedings of the INCOSE International Symposium.
Saleh, J.H., Mark, G., & Jord, N.C. 2009. "Flexibility: a multi-disciplinary literature review and a research agenda for designing flexible engineering systems." Journal of Engineering Design. 307-323.
Sillitto, Hillary, et al. 2017. "Defining 'system': A comprehensive approach." Proceedings of the INCOSE International Symposium, July 15-20, 2017, Adelaide, Australia.
Whitten, D. 2009. "Adaptability in IT Sourcing: The Impact of Switching Costs." Americas Conference on Information Systems (AMCIS). Texas A & M University.
Zhu, H. 2015. Designing Systems with Adaptability in Mind. Proceedings of the International Conference in Complex System Design and Management (CSD&M). Paris.
Zhu, H. 2018. "Developing Case‐Based Costs Estimation: A Recursive Approach and Case Study." Proceedings of the INCOSE International Symposium, July 7-12, 2018, Washington, DC, USA.
Zhu, H. 2019. "Controlling Costs and Margins of Engineered Systems." INCOSE INSIGHT Magazine. 22(1): 27-40. 29 May 2019.
Zhu, H. 2023. "A Development Procedure for Discovering Uncertain Requirements." Proceedings of the IEEE Systems Conference, April 17-20, 2023, Vancouver, Canada.
Zhu, H., Murray, B., de Weck, O., Skelding, R., Shougarian, N., Zeidner, L., et al. 2016. "Adaptability Metric Analysis for Multi‐Mission Design of Manufactured Products and Systems." Proceedings of the INCOSE International Symposium, July 18-21, 2016, Edinburgh, Scotland.
Primary References
Alstad, J. P. 2019. Development of COSYSMO 3.0: An Extended, Unified Cost Estimating Model for Systems Engineering. Procedia Computer Science.
Martin H., J., et. al. 2009. Adaptation, Anticipation and Rationality in Natural and Artificial Systems: Computational Paradigms Mimicking Nature. Natural Computing.
Zhu, H. 2015. Designing Systems with Adaptability in Mind. Proceedings of the International Conference in Complex System Design and Management (CSD&M). Paris.
Zhu, H., Murray, B., de Weck, O., Skelding, R., Shougarian, N., Zeidner, L., Arnold, E. 2016. Adaptability Metric Analysis for Multi‐Mission Design of Manufactured Products and Systems. Proceedings of the INCOSE International Symposium.
Zhu, H. 2018. Developing Case‐Based Costs Estimation: A Recursive Approach and Case Study. Proceedings of the INCOSE International Symposium.
Additional References
Chan, H., & Chan, F. 2010. Comparative Study on flexibility and adaptability. Decision Support Systems. Gu, P., Hashemian, M., & Nee, A. (2004). Adaptabile Design. CIRP Annals, Manufac.Tech.
Horbach, S., et. al. 2011. Building blocks for adaptable factory systems. Robotics & Comp. integrated Manufacturing.
Ross, A. M., Rhodes, D. H., & Hastings, D. E. 2007. Defining System Changeability: Reconciling Flexibility, Adaptability, Scalability, and Robustness for Maintaining System Lifecycle Value. INCOSE International Symposium.
Shaw, et. al. (2001). Development of the Quantitative Generalized Information Network Analysis (GINA) Methodology for Satellite Systems. Journal Spacecraft & Rockets.
Silver, M., & de Weck, O. (2007). Time-Expanded Decision Networks: A Framework for Designing Evolvable Complex Systems. Systems Engineering, 10 (2), 167-186.
Wang, G., et. al. (2009a). Harmonizing Systems and Software Cost Estimation. INCOSE International Symposium, (pp. 232-252). Wang, G., Valerdi, R., & Fortune, J. (2010). Reuse in systems engineering. IEEE Systems Journal, 376-384.
Zhu, H., “Designing Systems with Adaptability in Mind”, Complex System Design and Management (CSD&M), 2015.
Zhu, H., et. al., “Exploring Early Stage Cost-Estimation Methods Using Off-the-Shelf Tools: A Preliminary Study”, Complex System Design and Management (CSD&M), 2016.
Zhu,H., “Optimizing DTC in Case-Based Development with Parametric Modeling Tools”, IEEE International Symposium on Systems Engineering (ISSE), 2017.
Zhu, H., “Exploring empirical semantic comparison assistance”, IEEE Systems Conference, 2018.
Zhu, H., “Applying Mission-based Adaptability to Discipline Design”, INCOSE International Symposium, 2019.
Zhu, H, “A Development Procedure for Discovering Uncertain Requirements”, IEEE Systems Conference, 2023