Mark W. Maier

A satellite constellation is group of satellites, which may be identical or varying, but designed together to jointly operate. The architecture of a satellite constellation includes decisions on individual satellite capabilities, payload approaches, placements in orbits, and replenishment strategies. In all architecture studies, cost (including development, production, and launch) is a central concern, including the variance or uncertainty of cost. A common complexity in constellation studies is due to multiple different but nonindependent satellite designs. This article discusses methods for estimating cost variances using probabilistic models at the satellite configuration level extended to constellations of satellites and including correlations due to shared design content. This article uses the NOAA Satellite Observing System Architecture study as a worked example. An important application of estimates of partially correlated costs is assessing the significance of cost estimate differences among alternatives.

Between 2014 and 2018, the NOAA Office of Systems Architecture and Advanced Planning (OSAAP) conducted the NOAA Satellite Observing System Architecture (NSOSA) study to plan the long-term future of the NOAA constellation of operational environmental satellites. This constellation of satellites (which may include space capabilities acquired in lieu of U.S. government satellites) will follow the current GOES-R and JPSS satellite programs, beginning about 2030. This was an opportunity to design a modern architecture with no preconceived notions regarding instruments, platforms, orbits, etc., but driven by user needs, new technology, and exploiting emerging space business models. In this paper we describe how the study was structured, review major results, show how observation priorities and estimated costs drove next-generation choices, and discuss important challenges for implementing the next generation of U.S. civil environmental remote sensing satellites.

A key element of architecture studies, analyses-of-alternatives, and related trade studies is a quantitative value model (VM). The VM maps stakeholder preferences for baskets of capabilities to a single number. The mapping ideally has properties that allow for cost-benefit calculations and quantitative trades. An important and difficult element in building a VM is quantifying uncertainty. Uncertainty may stem from uncertainty in stakeholder prioritization, inexact scoring of alternatives against the VM, and the effects of issues outside the VM. This article presents several methods of quantifying uncertainty in the VM resulting from these sources and assessing the sensitivity of preferred alternative architectures to this uncertainty. We discuss methods focused on value uncertainty related to stakeholder consensus, performance scoring, and stakeholder preference uncertainty. Importantly, we include approaches for modeling the strong correlations that exist between alternatives. The methods are applied to a real case study of satellite constellation architecture, the NOAA Satellite Observing System Architecture study, which contains all of the above-mentioned complexities.

During the review process for the paper “Architecting Portfolios of Systems” in this issue one of the reviewers suggested that part of the reviewer‐author dialog be published because it clarified some issues beyond the paper itself and illustrated some different perspectives. This paper elaborates three major topics: The categorization of different types of collections of systems, the concept of requisite modeling in how we choose to model systems under development across a spectrum of rigor, and how to judge the success of research in systems engineering processes and methods.

A “portfolio‐of‐systems” is a collection of systems related by common management and budgeting, and at least some relationship to mission or missions. A portfolio‐of‐systems describes the not uncommon situation where an office is responsible for multiple systems in multiple phases of development but those systems are not related by common design, common manufacturing, or necessarily interconnected operationally. The relationship is fundamentally one of management, although other linkages might be present or designed if such additional linkages are deemed beneficial. The portfolio‐of‐systems concept differs from systems‐of‐systems and product‐line or family‐of‐systems constructs. This paper describes generalizations of architecting techniques for portfolio situations, particularly recognizing the presence of many largely independent components in multiple stages of development with an ongoing or episodic process. The paper presents two case studies of actual portfolios: One a portfolio of operational demonstration systems and the other a portfolio of weather satellites.

NOAA is beginning a study, the NOAA Satellite Observing System Architecture (NSOSA) study, to plan for the future operational environmental satellite system that will follow GOES and JPSS, beginning about 2030. This is an opportunity to design a modern architecture with no preconceived notions regarding instruments, platforms, orbits, etc., but driven by user needs. The NSOSA study team will develop and evaluate architecture alternatives, to include partner and commercial alternatives that are likely to become available. The objectives will include both functional needs and strategic characteristics (e.g., resiliency, flexibility, responsiveness, sustainability). The study will be informed by the Space Platform Requirements Working Group (SPRWG), commissioned by NESDIS. The SPRWG is charged to assess new or existing user needs and to provide relative impacts from different candidate observing systems in the future architecture. SPRWG results will serve as input to the process for new foundational (Level 0 and Level 1) requirements for the next generation of NOAA satellites that follow the GOES-R, JPSS, DSCOVR, Jason-3, and COSMIC-2 missions.

As the level of integration and the complexity of engineering systems increase, there is an increasing need to develop systems capabilities in engineers. Often, the demand for increased systems capabilities is automatically translated into a need to develop the systems capabilities of individuals. However, the systems capabilities of groups and organizations are what really matter for complex engineering systems, and individual capabilities do not automatically translate into group and organizational capabilities. This paper describes an integrated approach to developing systems professionals. To guide practitioners in utilizing relevant theoretical issues and research results, a five‐step plan to developing systems professionals is given. First, there is a description of how to frame the relevant problem space. Next, desired roles and competencies are linked to this problem spectrum. After describing how to develop an appropriate multi‐level strategy, the paper discusses how individual systems skills combine. Potential assessments for the development approach are shown. Since group and organizational issues can trump efforts to develop the systems capabilities of individuals, it is important to frame the relevant problem space, match the desired capabilities to that space, and create a multi‐level integrated strategy to develop those capabilities in individuals, groups, and organizations.

Large, complex systems today are increasingly software‐intensive. As a result, it is commonly essential that system development methods strongly facilitate good software development, even where to do so departs from traditional systems engineering practice. Unfortunately, the traditional state of the practice in systems engineering and system architecture descriptions are often not well suited to support complex software developments. For example, traditional systems engineering practice is to take a function‐first approach to definition, while software architectures are typically driven from the external interfaces inward, and are more often data‐based than function‐based. Moreover, the most successful very large system architectures typically take a strongly layered approach, with deliberate selection of convergence layers, a concept not typically found in traditional systems engineering practice. Each of these issues can be addressed through understanding of the elements of a good software architecture, appropriate ordering of systems engineering activities, and modeling methods extended to encompass layered system descriptions. While the example here is specific to software‐intensive systems, the methods applied can be extended to other types of domain integration. © 2006 Syst Eng 9: 146–159, 2006