Architecting Systems of Systems with Different Levels of Centralized Decision-Making ^†

Abstract

Systems developed and operated by different stakeholders are increasingly interconnected. When multiple systems collaborate in a shared environment and together provide emerging functionalities, they are referred to as systems of systems. These types of systems can be further classified by their level of centralized management and decision-making, reflecting the distribution of responsibilities and ownership among enterprises. This paper introduces two systems of systems architecting processes tailored to different levels of centralized decision-making. These processes aim to define the architectural design space, which is characterized by both the operations of the constituent systems and the composition of the systems of systems across various levels.

1. Introduction

In today’s interconnected world, engineered systems have become highly interconnected with other systems operating in the same environment. These systems can be increasingly recognized as part of a system of systems. The term system of systems refers to systems operating collaboratively while producing behavior that the individual systems cannot produce on their own. The systems composing a system of systems are referred to as constituent systems [1]. The passenger transport network is an example of a system of systems, where many different transport modes enable a passenger to undertake intra- or intercontinental journeys. In this context, aircraft are constituent systems that allow transport through the air, while buses and trains are constituent systems that enable transport on the ground. The characteristics of a system of systems are geographical distribution, emergent behavior, evolutionary development, operational independence, and managerial independence. The last two characteristics are recognized as the taxonomic classifiers distinguishing systems of systems from conventional large-scale systems [2]. Systems of systems can be further classified by their level of centralized management and authority. This level expresses that the coordination and decision-making can be distributed across the constituent systems. It indicates whether there is a central entity, such as an enterprise or a business unit, that has control over the entire system of systems or if the power of decision-making is more decentralized. Maier identifies three types of system of systems based on the level of centralized management and authority [2]: directed, collaborative, and virtual systems of systems. Additionally, Dahmann [3] recognizes the need for a fourth type of system of systems: the acknowledged system of systems. The four types of system of systems are depicted in Figure 1, ranging from highly central management to more distributed responsibilities and decision-making, characterized by the ownership of systems by enterprises.

The composition of a system of systems at multiple levels is shaped by the operational interplay among its constituent systems, with both composition and operations reciprocally influencing each other. In this paper, the composition and operations are referred to as the architecture of the constituent systems and the entire system of systems.

While developing the multiple constituent systems of a system of systems, many enterprises and stakeholders may be involved, all having their own interests. As the level of centralized management decreases, the challenge of aligning the diverse interests of these enterprises becomes more complicated. Well-defined methodologies are already essential when developing complex systems. Systems engineering provides a methodical approach that enables a structured, solution-agnostic development of complex systems.

A critical standard in this field is ISO 15288, which serves as a guideline across various sectors and lifecycle stages, covering both technical processes (e.g., architecture definition) and less or non-technical processes (e.g., decision management) to develop a system of interest [4]. The standard encourages the tailoring of its processes to meet the specific needs and context of the project (e.g., the system of systems). Among the technical processes, mission and business analyses define the strategic problem or opportunity, shaping the solution space and incorporating the perspectives of the enterprises that create value by developing or operating the system [5]. In this context, the Mission Engineering Guide [6], published by the U.S. Department of Defense, presents an approach for describing the mission, composed of mission tasks involving multiple systems, as a key driver for requirements, development, and decisions. The approach outlines how to quantify the effectiveness and performance of involved systems and their contribution to the overall success of a mission. Architecture frameworks provide standardized approaches and were originally derived from the military domain (e.g., DoDAF [7]), later evolving for commercial use, such as the Unified Architecture Framework (UAF) [8] to describe capabilities, missions or, similarly, operations, and interoperating systems within an enterprise context. While architecture frameworks provide views to describe a high-level perspective, the systems modeling language (SysML) offers a more detailed, technical modeling language specifically for engineering complex systems [9]. Because it captures interdependencies and enables integration, it is also well suited for systems of systems [10].

While there are established methodologies for developing complex systems and systems of systems, they overlook the issue of the distributed ownership of the constituent systems. This paper aims to introduce a process for architecting systems of systems that considers the level of centralized management overthe constituent systems.

2. Method

The methodology proposed in this section shows how to derive the architecture of a system of systems during the concept and development stages of its lifecycle. It builds on the initial phase of problem definition, which clearly describes the problem that the solution aims to address, and the system specification, which translates the problem into requirements that define the solution. These processes are not covered in this paper. The system of interest to be developed depends on the type of system of systems and the perspective taken, and may refer to either a constituent system or the entire system of systems. The resulting architecture includes both the composition and the conceptualized operations, with operations represented through their respective functions. The methodology consists of a process, a method, and a tool, whereas the last two aspects comprise the implementation of the process. The process consists of a sequence of tasks that are intended to serve as a guideline for the engineer to architect the system of interest (adapted from [11]). The process is further divided into four main segments, three of which refine the architecting process. The fourth segment is supplementary, aimed at defining the abstract concept regarding the system of interest. In this segment, the enterprise’s strategic orientation plays a significant role independent of the technical problem that needs to be solved. The architecture of the system of interest is developed iteratively, beginning with operational architecting. The operational architecture describes the interactions among the constituent systems within the operational environment, as well as the operations of each individual constituent system. Subsequently, the functional architecture derives functions that outline what needs to be done. With the help of these functions, the logical architecture identifies elements capable of fulfilling the functions and, together, composing the system of systems.

The methodology considers the distributed decision-making power that is often found in a system of systems. Based on the four types of systems of systems outlined in the preceding section, four instances of the process, which depend on the type at hand, were identified. Depending on the level of centralized management, decision-making power can either be concentrated in one high-level decision-maker or distributed among the enterprises of the various constituent systems. This indicates that decision-making regarding different tasks of the process may be handled by a single high-level enterprise conducting all the architecting activities, or by several decision-making enterprises involved in the process. This paper will introduce two of the four instances of the process, namely for the directed and the collaborative types of systems of systems. The directed type involves a high-level entity, while the collaborative type does not. The tasks will be detailed and the differences between the processes will be highlighted. The schematic representation of the two instances of the process can be found in Figure 2.

For the methodology to be complete, the process must be practiced in a compatible environment of methods and tools, or, as in this paper, with a single tool and method. The DLR in-house tool ADORE [12] is used and the function–means tree method for logical architecting is adapted to the broader field of system of systems architecting, including operations. The outcome of following the methodology is the creation of a model which is an abstraction of a real-life system of interest.

2.1. Directed Systems of Systems

The purposes of the individual constituent systems are subordinated to the purpose of the entire system of systems when referring to the directed type of system of systems. Accordingly, this applies to the enterprises that are the owners of the constituents and to those that have decision-making power over the entire system of systems. Therefore, the system of interest that the process is addressing is the overall system of systems dictating the main purpose of all constituent systems. The detailed tasks within the process are illustrated in Figure 3, beginning with concept definition, which aligns the overarching strategic orientation of the enterprise with the solution to be provided. Firstly, the goals and objectives of the enterprise need to be identified. Quantifiable measures (performance metrics and success criteria) can be established to set constraints for further developments. The next step is to identify the high-level capabilities of the system of systems that are required to achieve the goals and objectives. The capabilities help to refine the requirements of engineering developments and refer to the stakeholder needs that are defined in the previous phase of problem definition. Afterward, the concept of operations (ConOps) is defined, which helps to transition from an abstract vision of the solution to the more concrete solution-centered approach. This activity does not go into technical detail, but describes generically how the system of systems is to be operated. In other words, it expresses the operational strategy and with that narrows down the solution space. It is shaped by the overarching strategic orientation of the enterprise that controls the system of systems. In parallel, the previously defined capabilities can be decomposed to address potential constituent systems.

As part of operational architecting, and based on the high-level capabilities required as well as the ConOps, the global operational activities that must be carried out are defined. On that basis, operators are identified which are supposed to coordinate these operations. The operational context additionally describes the conditions, including, e.g., technical infrastructure, under which the solution is achieved. Based on this input, decomposed operational activities are described, which help fulfill the previously defined decomposed capabilities. Operations increasingly refer to the operations of specific constituent systems. These decomposed and suggested operational activities also contribute to the architectural design space, primarily because of alternative operational activities.

Representing different choices can achieve the same capability. This design space is next restricted by the early identification of desired and undesired behaviors when multiple operational activities are combined. Following this, functional architecting introduces functions as a means of translating the operational architecture into functional expectations that the system of systems must perform at any level of interest. These detailed functional expectations are decomposed, and a functional structure is established.

Ultimately, the logical architecture, which describes the structural composition, is created. First, functions are assigned to the logical elements that perform these functions. The elements are then broken down in concurrence with the decomposition of the functions. With a preliminary logical structure in place, the interfaces between the logical elements are also identified. The logical structure reveals the emergence of induced functionalities within the architecture. Logical architecting contributes to the architectural design space with alternative logical elements fulfilling the same functions. Two aspects characterize the architectural design space: alternative operational activities to fulfill the required capabilities and alternative logical elements that fulfill the functions. Both elements in the design space are interlinked and cannot be regarded as independent.

2.2. Collaborative System of Systems

Each individual constituent system in a collaborative system of systems has its own purpose, while simultaneously sharing a common purpose with the other constituents. This concept also applies to the enterprises that own these systems. When introducing a process with this in mind, it does not make sense to focus on the entire system of systems; rather, the system of interest shifts to a single constituent system. The collaborative aspect of the process is carried out, as depicted in Figure 2, through agreements between the collaborating partners at the system of systems level. Tasks, as shown in Figure 3, are either performed by a single constituent system or within the collaborative agreements.

The concept definition is equally important for each constituent system’s enterprise as it is for the collaborative system of systems level. Each enterprise has its own goals and objectives that reflect its strategic orientation. Similarly, the collaboration follows a shared strategic orientation that aligns with, rather than conflicts with, the enterprise’s goals and objectives. The high-level capabilities of the system of systems are identified collaboratively, based on the existing problem and the capability gap that needs to be closed. The enterprise identifies the capability it will address, which is a decomposed part of a higher-level capability and is based on the expertise the enterprise possesses. From a different perspective, the high-level capability emerges and is identified as the interplay of the individual capabilities. The same concept applies to the ConOps at both the constituent system level and the system of systems level. The constituent system’s ConOps is driven by the strategy the enterprise pursues to address a stakeholder need and is expected to align with the overall ConOps. Every enterprise contributes to the high-level ConOps.

Based on the high-level ConOps, operational activities involving multiple enterprises are detailed. These activities enable the fulfillment of the high-level capability, which cannot be achieved by a single partner but requires collaboration among several partners. In this context, the operators of the activities are identified and assigned to the responsible constituent system’s enterprise. This enables the enterprise of the constituent system to identify the operational activities needed to achieve the capabilities addressed in its enterprise strategy. Collaboratively, the partners identify both desired and undesired behaviors that emerge during collaborative interactions. Based on the identified operations, the global functions that must be fulfilled can be determined. The constituent system’s enterprise takes responsibility for the functions related to its addressed capabilities. It decomposes these functions until they reach a level of no further interest and establishes the functional hierarchy for its constituent system. Through this allocation of functions, the constituent system that forms part of the solution gradually becomes more concrete during the logical architecting process. Similarly, and concurrently with the functions, the logical structure of the constituent system is determined through decomposition until a level of no further interest is reached. On the collaborative side, agreements on interfaces play a significant role in the collaboration and are critical to the logical architecture of each constituent system. Additionally, induced functions are identified that may arise from one constituent system and impact another. In this way, the enterprises refine the architectures of their systems of interest. The architectural design space and alternative solutions are explored at different levels. The collaborative system of systems level may decide which constituent systems to include in the collaboration, as multiple options can deliver the required functionalities. The choice of alternative logical elements and operational activities impact one another. Selecting a constituent system may either be an iterative development process or be determined early by the enterprise that has agreed to participate in the collaboration and possesses specialized expertise. Within the enterprise, architectural decisions are made regarding alternative lower-level system elements.

3. Results

To demonstrate the validity of the methodology, two application cases, derived from the COLOSSUS project [13] are introduced in this section. The methodology will be applied to these application cases, serving as a proof of concept. The application cases showcase real-world examples, both involving aerial vehicles as a means of payload transport. The methodology is applied by following the process based on the system of systems type presented in the previous section, adopting the function–component approach, and using ADORE v1.5.1as the software.

3.1. Directed System of Systems Application Case: Wildfire Fighting Force

The first example represents a wildfire fighting force with the goal of preventing damage to human residences and natural environments caused by wildfires. This example illustrates a directed system of systems, where the wildfire fighting force acts as an enterprise at the system of systems level, controlling and managing lower-level enterprises, each of which maintains its managerial and operational independence. Multiple assets will be deployed to operate collaboratively in support of the wildfire fighting force’s goals.

The analysis begins with the strategic orientation of the enterprise in the concept definition. The wildfire fighting force does not have profit as its primary goal. Its identified objective is to extinguish wildfires with the aim of minimizing environmental impact at the lowest deployment cost. The high-level capability, shown at the top of the graph in Figure 4, is to fight wildfires in rural areas. Various ConOps are identified, each representing a different strategy for combating the fire. The wildfire fighting force can operate solely on the ground, without any tools, or using a combination of ground and aerial modes. The latter option is chosen and further analyzed. The global operations required to fight the fire are divided into several main tasks, such as detecting and extinguishing the fire. Using the function–component approach, these tasks are also represented as functions. For simplicity, the operators and operational context are not further examined here. Instead, the operational tasks are connected to different operational methods, which represent the lower-level activities that fulfill the decomposed capabilities. To detect the fire, there is a choice between the use of conventional aerial images or thermal images. To extinguish the fire, different methods can be considered, such as shooting pressurized water or releasing water incrementally by gravity. These alternative ways of performing the operations depict choices from among which the engineers can choose. Afterward, functions are identified to describe the elements which can conduct these operations. The main function, which is induced by the different ways to extinguish a fire, is to transport a payload. The following procedure combines functional architecting with logical architecting by leveraging the natural flow between functions and the elements that fulfill them. The choices that fulfill the main function of transporting a payload include different types of aerial vehicles or a combination of multiple vehicles. Each vehicle has its own set of functions to be fulfilled. In the case of aerial vehicle 2, two functions are further analyzed. Depending on the choices for extinguishing the fire, different architectural elements are required, such as a water drop mechanism or a water cannon. To provide propulsive power, a propulsion subsystem is necessary. These subsystems, in turn, induce the need for another system outside the aerial vehicle’s boundaries: a reenergizing subsystem for the propulsion system. Depending on the propulsion, specific reenergizing stations are required.

3.2. Collaborative System of Systems Application Case: Urban Air Mobility

The second example represents an urban air mobility network aimed at transporting payloads, in this case passengers, in urban areas. This example illustrates a collaborative system of systems, with no higher-level entity controlling or managing lower-level enterprises. Instead, voluntary agreements and decisions are made at the higher level, allowing all individual enterprises involved to benefit from the collaboration. Multiple constituent systems are engaged in fulfilling the purpose of transporting passengers in urban areas, including vehicles as well as take-off and landing facilities. Each enterprise owning a constituent system has its own strategic orientation. For example, one enterprise may operate short-distance aerial electric vehicles with the goal of entering the intra-city transport market, while another might aim to provide recharging facilities for all types of electric vehicles. These enterprises come together to combine forces and deliver a system of systems for an urban air mobility network to achieve the agreed-upon goals and objectives. There are two different perspectives from which the system of systems can be regarded: first, from the constituent system perspective, and second, from the high-level perspective, where all of the system of systems’ interactions and its entire structure are considered. The second perspective does not focus on the design of the constituent systems. In the described example, the agreed ConOps requires aerial transport. The operational activities within the operational architecting include conducting transport flights, on- and offboarding passengers, and recharging vehicles. Based on these high-level operations, the operations of aerial vehicles can be outlined. The design requirements of the vehicles depend on the agreed locations of ground infrastructure. There is a natural decision of which systems suit the operations. From the system of systems perspective, decisions are made between alternative constituent systems.

4. Discussion and Conclusions

This paper introduces a methodology for architecting systems of systems. The underlying processes described are tailored to a particular type of system of systems. Based on the taxonomic classification of systems of systems according to their level of centralized management, this results in four different variations in the process. The processes, two of which are detailed here, are solution-agnostic and independent of any specific tool or method and result in an architectural design space for the system of systems. However, in this paper, the methodology is applied to two application examples using a specific method and tool. These different processes emphasize the distribution of decision-making power and responsibility, considering the enterprises that own the constituent systems or the entire system of systems. Addressing distributed ownership is essential in system of systems development, as the fundamental definition of a system of systems underlines the operational and managerial independence of the constituent systems, which inherently include multiple, independent enterprises. As a result, decisions made during development can be viewed from various perspectives. Each constituent system’s enterprise may have its own distinct purpose, while the overarching perspective of the system of systems may also be considered. Consequently, the decision-making process, incorporating these differing viewpoints, requires further investigation. When considering multiple constituent systems, it is crucial to account for the interactions between them, as these operations reciprocally influence the compositions, resulting in the architectural design space. Therefore, during the concept and development stages, it is essential to consider the operational stage thoroughly. This approach offers the potential for a more integrated and holistic solution, which could ultimately be more effective. The architecting of a system of systems described here is not an isolated activity, but is closely connected to the preceding process of problem definition and iterative interactions with requirements engineering. Following the identification of the architectural design space, the next steps involve evaluation and optimization. The process outlined here concludes with logical architecting, while the actual solution can be acquired or the actual design activities may be delegated to another enterprise. All in all, this approach delivers a new way of approaching the development and architecting of systems of systems. Future work will include a more detailed exploration of all four instances of the process to elaborate on their differences. The processes must also be validated with real-world challenges of multi-system operations.