Generic Architecture for Self-Organized Adaptive Platform System of Systems

Abstract

Future systems of systems (SoSs) must adapt rapidly to evolving environments and stakeholder needs, yet conventional system engineering approaches often lack the flexibility to accommodate such change without costly re-engineering. Addressing this gap, this study proposes a novel, generic architecture model for self-organized adaptive platform SoSs, emphasizing a modular, layered structure that enables dynamic integration and reconfiguration of sub-units for diverse missions. The research is grounded in a comprehensive review of complex SoS theory and platform system design, focusing on physical platforms with central management. Methodologically, this study develops a logical architecture for electronics and software, detailing the roles and interactions of each architectural layer and component. The model’s efficacy is demonstrated through its application to the F-35 Joint Strike Fighter, where it identified opportunities to enhance the aircraft’s adaptability and self-organization. Results indicate that early adoption of this generic architecture can significantly reduce design and redesign costs, prevent over-specification, and promote lifecycle adaptability across various platform types—including land, air, and sea systems. The proposed architecture thus offers a robust foundation for future adaptive SoSs, supporting efficient evolution in response to unpredictable operational demands.

1. Introduction

Platform systems of systems (SOSs) are complex systems [1,2] based on large-scale material-integrated solutions [3]. Studying complex systems in a unified framework has become a recognized gap [2,4,5]. Many systems surrounding us are complex, requiring common frameworks for their development. Understanding the properties of complex systems will pave the path to simplifying the system engineering (SE) processes of such systems [2,4,5]. Complexity in systems may be reflected when a change in one part of the system affects another, and these effects may cause system failures [1]. These effects can be caused by feedback loops or emergent behaviors of the system, and changes in the system environment and needs. Understanding self-organization, adaptation, and generic architectures is a major direction for a deeper understanding of complex SOSs [1]. Self-organization is a fundamental characteristic of adaptive systems that refers to the spontaneous emergence of order, patterns, or structures within a system without external control or direction [6].

According to Maier [7], SOSs share several common characteristics, including operational and managerial independence and emergent behavior. There are several types of SOSs, including directed, collaborative, virtual, and acknowledged [7,8]. This research will focus on a physical platform, which is a complex directed SOS [7]. Physical platforms are designed to support a variety of adjustable sub-units (payloads) that provide a layered set of services for a range of mission support [9]. Due to the physical foundation of these platforms, once chosen, it is not easy or even possible to change. Therefore, defining the system architecture in advance is crucial to designing how the system components should be connected and allowing the system to be expanded in the future [10].

The system implementation phase combines technical and cost constraints [10]. Therefore, containing the required changes over time may lead to recurring redesign processes. Considering the cost and time of future changes, the infrastructure for making such changes should be embedded in the original system architecture. If not, sometimes the change does not justify the development costs, and consequently, developing a new system is preferred over upgrading the existing system. To avoid this, innovation is necessary at the primary stage of building the system architecture [11,12]. Our motivation is to develop a self-organized adaptive SOS to save future development costs and reduce time to operation.

From a 2050 perspective, systems are expected to become increasingly complex and must be able to operate effectively in a rapidly evolving environment [13]. Furthermore, future operational scenarios would involve only limited known information with high uncertainties [9,10,14]. Future systems need to adapt to the changing environment, their emergent behavior, and the stakeholders’ evolving and dynamic needs [10,15]. Contemporary SE methods define how to design and plan a system’s operation within several operational scenarios that can be predicted in advance. In future SE, we aspire that systems adapt to new operational scenarios that are unknown at their design [13]. Therefore, existing SE methods that design the system according to predefined scenarios are inadequate for responding to evolving needs [9,10]. The diversity of the technological components designed to be integrated into the platform significantly increases the complexity of the design process [16,17,18]. If the systems cannot be adapted to the evolving needs and changing environment, their value to the stakeholders will decrease [11].

New SE methods of a self-organized adaptive SOS need to focus on the system dynamics and define the system requirements for its required dynamics. Instead of designing what the system will do in a deterministic and static way, as is common in SE processes today, the dynamics of the change should be defined, thus responding to a greater variety of goals and operational scenarios. The system design will focus on the system dynamics by defining behavioral patterns and the rules to change them to enable future systems to adapt autonomously to new scenarios. When there is an indication that a change is needed, the systems will temporarily stretch their boundaries (of nominal state) while making the change [19]. Later, when an indication of stability is noticed, the system will return to the previous patterns (back to the normal, comfortable zone) or execute a phase transition to a new state as a new nominal state.

Generic architectures are generic high-level abstractions that do not depend on the specific details of a given system or implementation [20]. A generic architecture provides a solid basis for initial system design and allows adjustments to be made relatively simply. This simplicity is incorporated by implementing mechanisms that will enable the changes in the system architecture. Therefore, there is no need to carry out a significant redesign. The motivation for the architecture to be generic is to enable the support of different types of systems across a wide range of evolving contexts during the design and operational phases. Generic architecture focuses on general applicability rather than customization for specific requirements or constraints. This research provides design principles for future systems to address the need for system adaptation and self-organization by defining a generic architecture. This research is limited to the generic architecture of physical platform systems to provide a manageable scope. We use the term platform SOS as a class of systems to describe a stable physical structure SOS designed to support various missions by accommodating different mission-dependent payloads. The platform itself remains unchanged regardless of the mission type. It can operate across multiple environments—land, air, or sea—and is responsible for navigation, maneuvering, and reaching the mission area. Additionally, the platform provides the necessary resources, such as power and communication, to enable the payloads to perform their mission effectively.

An aerial platform SOS was chosen as a case study to demonstrate the benefits of the generic architecture model. The contribution of this research is to enable the effective design of future self-organized and adaptive platforms SOS and to define the specific architecture model enabling an inherent ability to change system dynamics. The generic architecture model may serve the system architect as a tool for the system design stage and when implementing a change.

This paper is organized as follows: Section 2 presents a literature review and background. Section 3 discusses the research method. Section 4 presents the generic architecture principles, while Section 5 defines a generic architecture model. Section 6 demonstrates the model through a case study and proposes improvements to the F-35 aircraft. Section 7 discusses and concludes this work with the required future research work.

2. Background

A platform (e.g., an airplane or a vehicle) is a complex SOS based on a large-scale material solution integrated with sensors, effectors, cyberinfrastructure systems, and information systems [3,21]. This research focuses on a platform system with a significant physical layer, a specific purpose, and central management as a directed SOS [7,22]. Unlike software applications, these properties force us to address the constraints of the physical elements. The central management allows us to discuss central components as part of the system architecture, unlike virtual SOS, where there is no central management.

The platform perspective analysis can accelerate the development of families of SOSs for a particular problem domain, such as the aerial domain (e.g., airliner, fighter aircraft). The architecture of platforms consists of a core structure that integrates domain-specific components and general services. This core, known as the main platform, includes reusable physical and informational components that reflect the commonalities of SOSs within a particular domain. The architecture is designed to be modular, incorporating various payloads, which are variable elements that can be individually developed to create a diverse product line. These payloads interact with the main platform through standardized interfaces, ensuring compatibility and plug-and-play functionality within the domain infrastructure [9].

Interfaces in platform-based engineering are crucial for maintaining the integrity and performance of the system. They are designed to be stable and standardized, facilitating seamless integration between the main platform and its payloads. These interfaces define the rules and specifications for how different components interact, enabling rapid development and deployment of derivative products without necessitating changes in the core platform. By adhering to established conventions, these interfaces support modularity and flexibility, allowing the platform to evolve and adapt to new requirements while maintaining a consistent and reliable foundation [9].

Complex SOSs are adaptive and learn to evolve in response to the environment [2]. They continuously grow and improve through an evolutionary process while accommodating change during operation.

The architecture of an adaptable platform SOS must allow dynamic modification over time. This enables the system to seamlessly integrate new capabilities by adding, removing, or replacing elements and adjusting interfaces, ensuring continuous adaptability to evolving needs [11]. Adaptability is a critical property of an SOS, enabling it to respond effectively to environmental changes. Adaptability is the ability to modify a system’s behavior, structure, or function in response to external stimuli or internal emergent behavior. This property allows an SOS to maintain its performance and functionality even in disturbances or shifting conditions. Adaptability is linked to self-organization, where both properties contribute to the system’s overall resilience and ability to evolve [6].

To enable the system to reconfigure and change dynamically, the architecture should consist of control and learning components responsible for recognizing a new event or environmental change that requires reconfiguration. Adaptation may be achieved by monitoring the system functionality and processes and altering the system dynamics while operating [15,23]. When the change is made during the system’s operation, the system must identify the starting and ending points of the change and address the suitable behavioral characteristics of the system, such as messaging, faults, logic, etc. The architecture should be structured to facilitate future changes, even without foreseeing them in advance [24,25].

According to Zhou et al. [26], interfaces are examined through an obligation-based model within the SoS. The interfaces serve as a mutual obligation between sub-systems and ensure that each component of the system contributes to the overall functionality and coherence of the SoS. The use of mediators is common to make the change transparent. A mediator can be implemented physically or through software [15]. It reduces the coupling between system components by enabling them to communicate indirectly through the mediator. It may also assist in the system’s reconfiguration and component replacement at runtime by serving as a communication adapter between different system parts. Mediators are essential for effective transition management, bridging legacy and new components at runtime. Additionally, a mediator can be useful in connecting commercial off-the-shelf (COTS) and legacy systems, as adjustments can be made in the mediator component.

Self-organization is another fundamental characteristic of the platform SOS. It refers to the spontaneous emergence of order, patterns, or structures within a system without external control. The system evolves through cooperation and competition among its components over time [2]. Self-organization arises from the local interactions between individual components or agents within the system, leading to coherent behavior at a higher level of organization. Self-organization is crucial for the SOS to adapt and respond to environmental changes. It enables systems to reorganize and create new strategies for addressing challenges. Self-organization and adaptability are interrelated when self-organizing processes often facilitate adaptability, and adaptive behaviors potentially influence the self-organizing dynamics of the system. Understanding these properties provides valuable insights into the design and analysis of the SOS across various domains [6].

Self-awareness is a key capability enabling systems to monitor, analyze, and adapt their behavior. It refers to a system’s ability to collect and maintain knowledge about its state, behavior, and environment. Self-aware systems typically include components for monitoring, analyzing, and adapting behavior, often organized into patterns like the MAPE-K (Monitor, Analyzer, Planner, Executer, Knowledge). They maintain and update knowledge about themselves, which is crucial for informed decision-making, adaptation, and learning. Self-awareness enables systems to align behavior with high-level goals, adjusting actions based on current conditions and past experiences. This capability allows systems to adapt their behavior or structure to optimize performance or handle changing conditions [27].

Known patterns of self-awareness are Boyd’s OODA Loop [28]—observation, orientation, decisions, and action; the ODA model—observe, decide, and act [29]; and the DOODA—Dynamic OODA loop—which is a generic model of command and control based on Boyd’s OODA loop and cybernetic models [30]. The model-based learning, reasoning, and acting loop—LRA-M LOOP [31]—is also a self-awareness method. The ideas in these methods are similar, with a slightly different division of components where all have learning, decision-making, and execution components as part of the system architecture.

According to IEEE Standard 610.12 [32], architecture is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time. Another definition of architecture [33] is the embodiment of the concept, the allocation of physical and informational functions to elements and objects, and the definition of structural interfaces among the objects. Using the generic architecture may facilitate the work of the system architect, who may use it as a baseline architecture to verify that there are no missing logical or physical components. Generic architecture is a broad concept not tied to the specific details of any particular system or implementation [16,20]. The genericity is expressed in defining the system components at a high level of abstraction without considering the specific implementation. A generic architecture allows adjustments to be made relatively simply, without major redesign over time [20].

To facilitate the realization of generic architecture, it is necessary to stick to standardization [9,17,18,34] that is adjusted to the different content worlds. For example, there are differing standards in the automotive discipline, aviation, or the Internet of Things (IoT) space [9,12,17,34]. Another key principle in achieving a generic architecture is the implementation of loose coupling [32]. It enables system components to evolve independently, providing architecture flexibility.

Several established architectural frameworks for system engineering exist, including the Department of Defense Architecture Framework (DoDAF) [35], the Open Group Architecture Framework (TOGAF) [36], and the EPIC framework for enterprise processes integrative collaboration [23]. While these frameworks provide structured approaches to designing complex systems, their direct applicability to the unique challenges of physical SoSs, particularly concerning self-organization and adaptation, may be limited.

Def Stan 23-09 is a Generic Vehicle Architecture (GVA) standard produced by the British Ministry of Defence (MOD) [37]. Its purpose is to enable the MOD to realize the benefits of an open architecture approach to the design and integration of a ground platform, with a special focus on the platform infrastructure and the human–machine interface (HMI) that directly impact operations. The objective is to foster flexibility in development, minimize integration risks, and lower development costs. The system architecture is divided into a physical platform (platform), equipment relevant to the vehicle functions (role equipment), and the additions defined by the standard. Two infrastructure layers are defined: a common central infrastructure for energy distribution and a common central infrastructure for information distribution in the vehicle and between vehicles and other ground forces. Each of these infrastructures distributes the power/information through connectors to the various components. Connectivity to new and advanced components is carried out directly, while connectivity to old components (Legacy) is carried out through adapters. The standard defines additional components regarding an HMI and a Health and Usage Monitoring System (HUMS). However, as of today, the standard refers only to ground vehicle platforms and does not define all the required functional modules in the platform.

Existing SE methods are inadequate to plan the self-organized adaptive SOS [9,10]. Model-oriented SE science (MOSES) aims to address future systems’ SE by satisfying their unique requirements [2]. However, the model-oriented SE does not provide a generic architecture. Furthermore, it raises the question of whether any architectural view may be considered the dominant or base view for any system or should address a certain type of system and domain.

In conclusion, while the existing literature discusses various layers and system components, it lacks a comprehensive generic architecture for a physical platform SOS that incorporates all essential layers and core components, as presented in this study.

3. Methods

This paper follows a design and case study validation methodology. It presents design principles and a generic architecture model for a self-organized adaptive platform SOS designed to adhere to these principles. These principles were selected by reviewing the state of the art on the subject and identifying recurring themes. Our generic architecture model follows an extensive review of the recent literature and an evaluation of various proposed architectures, guided by personal experience and established best practices. The model is presented in a generic format, intentionally decoupled from any specific implementation domain or solution. The model was built in the form of layers [19] and describes the main components in each layer, as this approach simplifies the system’s structure and enhances comprehensibility. By developing the architecture incrementally, we arrived at a situation where reading additional sources did not add new layers or components; hence, a sense of completeness was obtained.

To test the model, we exemplify the architecture design using an aerial platform case study. Case studies are commonly used to document and analyze implementation processes [38]. The F-35 Joint Strike Fighter (JSF), one of the most innovative and advanced air platforms, was selected as a case study. We start by presenting the F-35 JSF’s first architecture of the aircraft and emphasize several design principles from our generic architecture model that were improved compared to previous generation aircraft. Then, we propose several improvements to its architecture, utilizing the principles and layers of the generic model to demonstrate its benefits. Then, we repeat these steps and present the F-35 JSF’s current fusion architecture, emphasizing the updates and improvements made since the initial version, which correspond with our model. We show that complying with our model may reduce the effort needed for architectural changes in the fusion architecture. Then, again, we propose several improvements to the current architecture.

The generic architecture model is intended to support diverse platforms, such as air, marine, or land platforms, with minimal modifications. Future case studies may be considered for different types of platforms to validate the model’s completeness.

4. Generic Architecture Principles for Platform SOS

This section outlines the primary architectural principles of a physical platform SOS, highlighting how they enable the platform’s self-organization and adaptability.

4.1. Modularity

Modularity is an important property that divides a system into several functional modules [39]. Systems with a modular architecture may require less effort to redesign. Modularity allows system architects to change modules with minimal influence on other system parts [39]. The modular system has several advantages, such as ease of assembly [40], ease of maintenance, and ease of architectural adaptability [11,41]. Additionally, as the system architecture has fewer dependencies (more modular), it increases the intuitive understanding and may require less design re-work [20,42,43].

A modular architecture is built from modular units interacting via defined interfaces [9,10]. The interfaces can be standardized or not, but if not, they limit the generality. To support different sub-systems, the modules should support standardized interfaces [44].

The principle of modularity is important when it comes to a self-organized adaptive platform. The platform interfaces should be designed to accommodate future adaptation. To properly design the architecture of an adaptive platform, separate functional modules within the different layers of the architecture must be integrated, and modularity must be required at each layer of the architecture. The main platform components are mandatory and are essential for the basic and proper functioning of mobility/flight, while the payloads can vary according to the mission. The main platform defines the core structure that can function without any payload, such as general C2 (command and control) components, navigation, steering, main voltage supply, communication, etc.

The main platform components can be replaced by other components based on different technologies that support the same functionality. If, for example, there is a need to replace the navigation unit, this will be supported by the architecture without re-designing the whole platform and with limited changes to communication protocols to interface with the new unit if necessary. The main platform architecture provides a central infrastructure for the payload’s proper functioning, including space, voltage supply, cooling systems, and cyber.

The payloads/sub-units are responsible for a specific mission and can vary according to the mission. For example, a drone-type aerial platform supports a photography mission where the payload may include cameras, data storage, and data transmission components. On the other hand, in a transportation mission, the payload may be the package to be delivered, a camera to photograph the shipment’s arrival at its destination, etc. The payload depends on the resources and services of the main platform and usually cannot provide the required functionality to perform their task by themselves.

4.2. Adaptability

Adaptability is a major requirement of a generic architecture structure. The architecture shall easily support certain classes of changes. These changes are explicitly included in the architectural structure and do not require a significant redesign. Moreover, a system architecture should be adaptable to different applications and use cases. It requires a scalable architecture that changes size or supports new capabilities through different system module orchestration [20]. Additionally, the system architecture shall be adaptive as the development process is evolutionary, which yields components, functions, and goals to be added, removed, and modified over time [45]. Replacing a system module should not lead to a re-design effort for adaptation [44], as the system shall apply to different scenarios, customer requirements, and technological capabilities. For example, when a system adopts new technologies to achieve better performance, legacy parts will still be part of the overall system. These legacy parts will continue functioning, although a new technology or interface will be added to the system [45].

Adaptability enables independent components to develop separately [32]. This can be supported by a loose coupling design. Integrated and federated architecture represent two distinct approaches to system design, each offering unique advantages and trade-offs. In avionic systems, the choice between integrated and federated architecture represents a significant shift in design philosophy. A federated architecture, traditionally used in older aircraft, involves separate, self-contained units for each avionics function. Each has its dedicated processing, input/output, and power supply, operating independently. This approach offers simplicity and clear functional boundaries but can increase weight, power consumption, and maintenance complexity. In contrast, integrated architecture, exemplified by Integrated Modular Avionics (IMA), consolidates multiple avionics functions into shared computing platforms. IMA employs common processing modules, standardized interfaces, and shared resources, allowing for more efficient use of hardware and reducing overall system weight and power requirements. This integration enables loose coupling, easier upgrades, and potentially lower lifecycle costs. The transition from federated to integrated architectures in avionics represents a move towards more sophisticated, efficient, and loosely coupled systems, responding to increasing computational demands and interconnectivity of modern aircraft systems [34].

Another key property in adaptive loosely coupled systems is the use of services, which plays a significant role in future systems. Each system component will generate information and publish it as a service to other system components. This approach supports adaptivity by eliminating the need to establish a direct logical interface (point-to-point) between the system components. Service-Oriented Architecture (SOA) enforces every system component to support information services, both for providing services and consuming them.

A generic architecture shall also support different system configurations divided into physical and logical parts. Physical reconfigurations include physical changes in system arrangement, which in most cases require changes in lower structuring levels. Logical reconfigurations include software changes in middleware or application layers [46]. To facilitate transparent data access and flexible reconfiguration, the generic architecture shall include a data module that supports several standards and communication protocols relevant to the architecture domain [44]. These reconfigurations change the system’s functionality or capacity and reduce integration efforts [11,46].

4.3. Interoperability

Interoperability describes how a human or a system works efficiently and effectively with others based on common goals, presently or in the future. Interoperability enables information sharing throughout operational processes through the robust networking of well-informed, geographically dispersed operations [23]. The interoperation of sub-systems requires a connectivity infrastructure for data to be transferred and processed, which creates a complete system operation [44,47]. The connectivity between system components can improve each component’s performance and create emergent behavior [47]. Supporting architectural interoperation requires a data model responsible for a common understanding of the data and connectivity infrastructure that supports internal and external communication. This data model may be part of the middleware, the so-called data management and integration broker. Legacy systems, which are incompatible with the data model, may be connected via adapters. When the components of an SOS are highly independent operationally and managerially, the modeler needs to have well-defined interfaces [7,44].

Platform interoperability ensures that diverse sensors and Internet of Things (IoT) devices, platforms, and services can communicate and exchange data seamlessly, regardless of their manufacturers or specific technologies. This is achieved using standardized protocols, data formats, and interfaces, which enable different components to work together efficiently [17].

4.4. Redundancy

Redundancy is a requirement that arises from the needs of stakeholders for reliability. Redundancy enables the system to remain operational even when a component fails or is being upgraded. Redundancy can exist at various levels, such as power source, communication, or responsibility for a specific action [9,34]. This can be accomplished through component duplication or by implementing diverse technologies that serve the same function.

When duplicating components, the same type of component is used at least twice, and in the case of a malfunction in one of the components, the other can be used as a fallback. For example, connecting two batteries in parallel to a system with an autonomous voltage supply allows, when one battery malfunctions, the other battery to provide the required energy for the entire system.

For achieving redundancy through diversity, the system should incorporate multiple technologies to perform the same function. For instance, GPS, inertial measurement, and radar can be used as diverse location-finding technologies. Combining diverse components for the same functionality ensures a backup when one component fails to avoid a single point of failure.

5. The Generic Architecture Model of a Self-Organized Adaptive Platform SOS

5.1. The Model

This section presents the holistic generic architecture model we developed based on personal experience, best practices, and recurring principles and elements from the reviewed literature. It focuses on the platform’s logical architecture of electronics and software because it is designed to apply to all platform types (land-based, aerial, or maritime). Therefore, mechanical considerations of specific platform types were not addressed. We detailed the architectural considerations and description of the generic architecture to encompass all core layers and components to provide a holistic deployment context [20]. This study focuses on several principles, such as modularity, adaptability, and interoperability, but does not discuss the redundancy principle. Furthermore, we present each component but do not justify all of them. Instead, we focus on justifying the connectivity layer and external components through a case study discussed in the next section.

We present the model in layers with the main components in each layer. Each component can be implemented by one or more entities in the system. The proposed layers and components provide specific boundaries between system components and support the modularity and adaptability principles. The model is generic and should be suitable for different types of SOS platforms. However, we point out the importance of maintaining the exact logic of modular composition and separation within physical or software implementation.

Figure 1 shows the generic logic architecture model of the system. The system consists of a main platform and sub-units. The architecture embodies a separation between several generic layers that handle information collection, information processing, platform management, mission management, and operation. There are several complementary transverse layers for connectivity infrastructure, power supply, cyber, and safety. Each layer’s main components are specified. A description of the layers and components is provided in the following subsections. Due to the scope of the study, we did not address the issue of maintenance and other complementary elements.

While various methods are available for creating modular platforms and visualizing component connections, such as Design Structure Matrices (DSMs), these approaches are unsuitable for this work because they address the interfaces between components in a traditional way. In our architectural model, we provide a different concept of connectivity layer that enables connectivity between all system components more generically, rather than adopting a point-to-point (P2P) connectivity approach.

Figure 2 shows a high-level view of the system’s physical architecture, including the division into the main platform and the connection of the sub-units. This figure illustrates the significant value of the system modularity that enables the design and operation of different payloads within the same main platform to support system adaptability in various missions. The figure focuses on the primary platform components, with sub-units interconnected via the connectivity infrastructure. Using mediators as part of the connectivity infrastructure is not mandatory but may be needed to accelerate interoperability and bridge between different technology generations. Inside the main platform are indicated necessary components such as the primary voltage supply, C2, components responsible for the mobility of the platform, etc. The components will be adjusted according to their unique requirements in each new system design.

Figure 3 shows a high-level view of a generic sub-unit physical architecture. It shows how it is connected to the main platform through a mediator and an external interface. The main components of the sub-unit are the local communication unit, local mission management, local power supply, I/O modules, operators, sensors, and effectors. The design of each system must be adapted according to its unique requirements. For example, a sub-unit can receive a power supply from the main platform’s power source with or without an independent power source. Local mediators may be incorporated into the design of the sub-unit or may use the main platform mediators embedded in the main platform connectivity infrastructure.

5.2. The Main Layers

In this section, we will describe each layer and component within the generic architecture of the system, which contains both the main platform and its sub-units. We describe a complete view of the generic architecture model with its layer breakdown to provide a clear understanding of each layer’s responsibility and boundaries. The following is the description of each layer in Figure 1, from the bottom to the top layer.

Data collection layer—The data collection layer’s main functionality is to collect raw data and processed information from internal and external sources and provide it to the other layers. The raw data are collected through onboard sensors and external offboard sensors through external communication. Processed information is obtained through external communication with other systems and platforms. The layer also includes time synchronization components required for high-accuracy coordination between components.

Data processing layer—The data processing layer handles data received from other layers. The data are being processed by means that vary from the basic sampling level to the advanced processing level using AI. The main functionality of this layer includes sampling, processing at various levels, calibration, storage, information management, video management, fusion, recording, and AI. The processed data are transferred via the connectivity infrastructure as services to the internal and external consumers. The data processing layer is essential in the digitalization of the platform, as well known in artifacts [48] that require data management and other digital modules.

C2 (command and control) layer—This layer is responsible for addressing situation awareness and event handling. It uses internal and external information to build a multi-layered situational picture and the event handling for command-and-control procedures of the platform.

Mobility layer—The mobility layer handles platform management and navigating to the destination entirely independently but coordinated with the mission management layer. Its main components are platform (and health) management, navigation, and steering (and stabilizing).

Mission management layer—Mission management is expressed in an end-to-end process and activities required for the mission. This layer is responsible for resource management, payload management, and even sensor and effector management associated with the mission. This layer should be coordinated with the C2 and mobility layers. The platform is designed to support a variety of payloads for a range of missions. Each payload has unique characteristics and operations, of which the other layers, except the mission layer, do not have to be aware. The mission management layer is responsible for different missions, which may be carried out on the same platform depending on the variety of payloads and external information.

Operational layer—This layer is responsible for the actual operation of the platforms, including the User Interface (UI), effectors, and external effectors. The UI is influenced by information received from the platform services to provide the pilot with the required information in different ways (visual, hearing, etc.). The UI also provides commands to the C2, mission management, and other layers. The effectors enable performing activities in the system, while the external component in this layer allows the operation of external systems and platforms.

5.3. Transverse Layers

Connectivity infrastructure layer—This layer is the primary means for sharing information within the system components, between system layers, and with external entities. This layer includes connectivity infrastructure, which is a very strong communication bus, frequency management components, and governance components. This layer is the heart of the system, enabling the different components to dynamically communicate [9,24]. This layer supports the system’s modularity, interoperability, and loose coupling. It not only serves to connect but actively facilitates communication, coordination, and adaptability among system components [26]. The connectivity infrastructure allows for connections between different layers of the architecture, facilitating the creation of an integrated architecture that combines functionalities and enables resource sharing. It may include internal and external communication channels such as data or video, RF or wired, encryption or decryption, transmitter, receiver, etc.

Connectivity refers to the ability of the system components to establish and maintain communication links, ensuring continuous data flow and interaction within the system. The platform should support different types of interfaces, voltage levels, communication protocols, and information schemes. In the generic system design, it is important to adhere to known protocols and standards to accommodate as wide a variety of system components as possible. In the case of unique interfaces, it is more difficult to replace the technology of system components. The connectivity infrastructure functionality should support communication, routing, distribution, mediation, and governance. A main platform that contains all types of interfaces to support all kinds of payloads may affect the system weight, complexity, development time, energy resources, reliability, and performance. Therefore, to avoid a significant over-specification, a specific requirement engineering process must define which type of interfaces should be supported.

The mediation serves a central role, bridging between components in the case of different protocols or standards of communication and voltages. Its purpose is usually to mediate between legacy and new components in the system. Mediation can also facilitate transition phases during component replacement, easing the migration process from one element to another. A mediator can be either a virtual (software) component or a physical one. An example of a virtual mediator is a software task responsible for converting communication protocols from serial communication to Ethernet or a task that manages data transmission rate conversion. An example of a physical mediator would be a voltage converter, such as one converting from 28VDC to 5VDC. By using a mediator, over-specification can be avoided in the initial design phase, as the design does not need to address all voltage levels and communication types upfront. Obviously, there are costs to such a solution and constraints of required space, cooling, power, etc.

Governance should be integrated in the first stages of architecture design, derived from the interoperability risks. Governance in complex systems, such as platforms, involves the design, execution, and evolution of functions that ensure control, communication, coordination, and integration. It is essential for maintaining system performance, viability, and sustainability amidst internal and external changes [29,49]. Effective governance in these systems must account for non-linear dynamics, self-organization, and co-evolution among sub-units and processes. Establishing robust governance is essential to monitor system behavior and identify a required change in the system dynamics due to environmental change or emergent behavior.

Cyber layer—Cyber is a significant layer in the system architecture, essential to prevent a systemic colossal failure and protect the system from internal and external threats in self-adaptive systems [50]. In most cases, cyber realization is distributed between different components of the system. The right way to integrate cyber into the system architecture is to perform a threat analysis and provide solutions in the initial design phase [51]. It is much more difficult to address cyber requirements after deciding on the architecture structure. The main cyber mechanisms and services may be embedded in this layer in the main platform and serve components in the main platform and payloads. An example of such a mechanism might be blocking an unknown structure of information or an unknown source of information according to a trust mechanism.

Cyber is represented as a transverse layer because it can be present in both the main platform and its sub-units. For instance, when IPSEC encryption is used between the main platform and a sub-unit, each contains a cyber component that implements the protocol. Additionally, a cyber component might only be present on the main platform, such as when establishing one-way communication channels between systems of different classifications. This setup helps prevent information leakage from a high-classification system to a lower-classification system.

The cyber layer may also include a partitioning environment to provide the required interfaces under the Future Airborne Capability Environment (FACE™) Technical Standard for safety and security profiles [52]. It ensures partitioning between different applications to avoid information leakage or domino effect failure between different applications and modules.

Safety layer—Safety is a significant issue for many platforms. In most cases, safety is not realized through a single component but by decentralizing responsibility among some of the system’s components. The safety requirements can be related to the main platform only or also to the specific payload. The main safety mechanisms and services may be embedded in this layer in the main platform and serve components in the main platform and payloads. An example of such a mechanism might be a sealing safety information mechanism to ensure it is not corrupted while it flows from origin to destination.

Power and air conditioning layer—The main power and air conditioning are in the main platform. This layer provides power supply and air conditioning to the platform components and payloads. The payload may be utterly independent regarding power and air conditioning or rely on the platform’s resources. It is recommended that protections in the platform’s supply channels be integrated to prevent a situation in which a fault in the payload will damage the platform and vice versa. The sub-unit can rely on energy from the main platform or be completely independent. For example, a missile that has dedicated batteries for the benefit of flight is required to receive ground voltage from the main platform for safety checks and preparation processes for launch. In the case of a local unit with an independent battery, such as recording, it is not required to receive power from the main platform.

5.4. Main Components

In this section, we explain each layer’s components within the generic architecture, which contains both the main platform and its sub-units. This breakdown is intended to provide a clear understanding of each component’s responsibility, boundaries, and the way they work together to achieve the system’s goals.

The data collection layer includes the following components:

Sensor—A physical component that collects the required data to support the system’s needs, usually by converting physical values into movement or electrical signals. There are two main types of sensors—passive sensors and active sensors. The passive sensors measure the levels of existing energy, for example, sensors that measure pressure. The active sensors emit energy and measure their return level (e.g., radar). The sensors in the data collection layer transfer their raw data to the data layer and other layers.

External—The external component in this layer is responsible for handling information from external units into the system. External systems, such as a neighboring platform and a ground unit, can provide and receive information from the system and thus share resources between them. In the case of an aerial platform, an external unit may be the control tower that transmits information regarding takeoffs and landings. In a self-organized platform, the external component, combined with a strong connectivity infrastructure layer, enables communication with external components, thereby facilitating resource sharing and sensor sharing with other platforms.

Time sync—A platform is a complex system that combines many components, some of which are permanent, and some can change (for example, different payloads). Some actions are sensitive to precise timings or require high-accuracy coordination between components, such as navigating, sensing, building situational pictures, data recording, and analysis [53].

The way to achieve this is by time synchronization between the system components. One way of implementation is to plan a primary synchronizing unit that connects to secondary synchronizing units for each sub-unit, or to rely only on the primary synchronizing. All the system components that are sensitive to precise timing will be synchronized. Time sync components may also serve for precise timings or require high-accuracy coordination with other platforms. Time sync is also needed in the Verification and Validation Tests (VVTs) to examine each component’s performance on a common timeline.

The data processing layer includes the following components:

Data processing—This component is responsible for sampling data sent from the data collection layer or information received from an internal or external source and provides certain processing before being transferred for use in other modules. Such processing may provide information correctness and completeness checks.

Data and video management—Data and video management refers to the processes and practices of organizing and maintaining data and video throughout the system. Data management ensures that accurate, up-to-date information is available to support all other modules for system operation and maintenance.

Storage/memory—A nonvolatile storage area will be used to store all intermediate information and code needed for the system operation. Physical storage may also be used for data recording and databases.

Recording—Data from the system are usually recorded in a physical storage. The storage can be a part of the system or an external component. The recorded data can be used in the development stage, the operational stage, or for maintenance. In addition to the recording ability, it is also advisable to emphasize the ability to retrieve data and allow replay at a specific timeline for debriefing and simulation.

Database—The database includes all system information set up for easy access, management, and updating to support system interoperability [52]. The database provides the different modules with the information needed for the system’s operation, including raw, processed, and analyzed information (the output of the AI components). The information in the database should include real-time, non-real-time, and historical information. In some cases, a central database is infeasible, and database links may be utilized instead to enable system interoperability.

Calibration—Calibration is required for the sensors connected to the system and the sampled data. For example, some components are sensitive to environmental conditions and need to be monitored and calibrated according to their status. Another important functionality is the calibration of the platform architecture, or in other words, the reconfiguration of the platform component activation to support changes in the system operation [6,15].

Fusion—Fusion typically refers to data fusion, which is the process of combining information from multiple sources to produce more comprehensive, accurate, and useful data. The main purpose of fusion is to enhance decision-making capabilities by providing a more complete situational picture, to improve accuracy by reducing uncertainties and errors in individual data streams, to optimize resource allocation and usage, to increase situational awareness in complex systems, and to enhance overall system performance.

Artificial intelligence (AI) and learning—AI is a high level of data processing. A system incorporating artificial intelligence mimics human intelligence to perform tasks and can interactively improve itself based on the information it gathers. AI generates new knowledge from the data or video. In our case, the self-organized and adaptive platform can use the AI component to learn about changes in system dynamics, environmental conditions, and emergent behaviors [31]. This shall support the identification of the required point to change in system behavioral patterns—the system phase transition point that enables adaptability. The AI can also create new information regarding learning trends and system failure to support learning mechanisms that change the system behavior to be more effective and adaptive to change.

The command and control (C2) layer includes the following components:

Event management—In the operation of a system, nominal events and non-nominal events occur; some of them are pre-planned, and some are not. An event can be a malfunction, a change in the environment, etc. The C2 layer incorporates logic to handle different events. Event management allows systems to provide information regarding event recognition, changes in state, or external stimuli; to be aware of this event’s impact; and to react by specific actions.

Situation awareness—Building a situation awareness picture is a necessary and core ability in a system. The situation picture is based on information collected by the data collection layer components and the data processing layer components. It integrates different types of information to support the operation layer and, specifically in an aircraft, the pilot’s situation awareness and decisions in controlling the mobility and mission.

The mobility layer includes the following components:

Platform management—The platform management is responsible for the proper functioning of the platform. This module allows management and control of different physical components and logical modules in the platform. The platform management works completely independently, regardless of the mission components. This module is also responsible for health management.

Platform steering—The platform steering is responsible for mobility and steering the platform to its destination as part of the main platform, regardless of the payload. It should function independently even when the payload does not exist. For example, the airplane continues to fly to its destination even when no missiles are attached. This module is also responsible for platform stabilization, such as ground robots.

Platform navigation—The platform has a navigation system, so it can calculate its location at any moment. Platform navigation can include components like an inertial measurement unit (IMU), a Global Positioning System (GPS), etc. The platform navigation component can be part of the main platform or as a payload. It may serve as a resource of information for components on the main platform and payload navigation if needed.

The mission management layer includes the following components:

Mission management—The mission management component is crucial for optimizing operations in platforms. It integrates data from various sources regarding the mission status, facilitates planning and monitoring, and supports decision-making during the mission. Additionally, mission management is responsible for managing several payloads and sensors, managing resources, and commanding various effectors. It also aids in post-mission analysis, contributing to operational improvements. Overall, the mission management component is essential for maximizing mission success and safety in platforms while coordinating multiple systems and resources.

Payload management—The payload management is responsible for controlling payload operation and performance while receiving commands from the mission management module. At the same time, it updates the platform management about its state and may also receive commands from the platform management module. For example, it obtains the current position of the platform and other information that could affect the mission from the payloads and provides it to mission management.

Resource management—Each payload has resource management that includes energy, time, condition to operate, etc. To design a self-organized adaptive platform that will support different types of payloads, we would prefer to reduce the coupling between the C2 layer and the specific payload. Therefore, the resource management of the payloads is part of the mission management layer. This shall ensure resource management according to the changing priority during the mission.

The operational layer includes the following components:

UI—The UI is the part of the system exposed to the user to support the human–machine interface. In the case of an airborne platform, it provides the pilot with the required information in different ways (visual, hearing, etc.) and supports the pilot’s decisions and actions. The user’s ability to influence the platform operation is carried out through the UI. A platform that supports different payloads may have a UI for the platform component and different complementary UIs for the payloads. However, an integrated UI is preferred.

Effector—An effector is a component that becomes active in response to a defined trigger. The trigger can be a command through communication or electric power. The effectors are used to follow the command of the platform management module or the mission management module. Effectors’ operation may be triggered by human command or may be generated by autonomous control components. An example of an effector controlled by humans is a steering stick that changes the platform positioning through the platform management module. Another example of an effector can be a component that performs pyrotechnical activation of a weapon by a command received from the pilot or by the mission management module.

External—Most platforms have an interface to outside units. Depending on the mission, the operation may include effectors on other platforms. In that case, there can be an interface between each platform to the central management unit (in one of the platforms) that controls a variety of different effectors to accomplish the mission. For example, a variety of different electronic warfare effectors may provide a better-coordinated defense for several neighboring aircraft in the same mission space.

6. Case Study

6.1. Overview

This section explores the F-35 Joint Strike Fighter (JSF) aircraft architecture in three phases. The F-35 Lightning II is an advanced, multi-role stealth fighter jet that integrates the latest technologies to ensure air superiority [54,55]. First, we compare its upgrades from previous fighter generations. Second, we analyze changes in the F-35’s fusion architecture. Third, we present scenarios showing how the new architecture enhances adaptability and self-organization.

We applied the selected principles proposed in Section 4 to the F-35 architecture, demonstrating the role of platform-generic architecture in system design and adapting to new requirements. Our goal is to define a self-organized, adaptable platform SOS that can evolve without requiring extensive re-engineering, enabling changes and upgrades to support system dynamics, changes in requirements, or technology progress. The F-35 is suitable as a case study for several reasons: First, it was known from the beginning that the development process of the F-35 would be a long-term process, and the architecture concept was designed to incorporate changes following technological progress and changes in requirements [56]. Second, the F-35 design had to support the requirements of several countries and several operators (navy, marines, air force) without re-engineering the system [56,57]. Third, the aircraft is required to operate in the future battlefield where the construction of situation awareness depends on information sharing and fusion [56].

6.2. Upgrades from the Previous Generation of Fighters to F-35 JSF First Version

Integrated vs. federated architecture

A federated architecture is a decentralized system in which independent entities or sub-systems collaborate while maintaining autonomy. Each component operates independently, with separate governance, data management, and decision-making processes. Fighter jets of previous generations, such as the F-16 and F-15, had separate sub-systems for flight control and weapons. Each sub-system operated independently with limited integration. Sensors like radar, infrared, and electro-optical systems worked in isolation, and the decision-making process relied on isolated data from each system.

In contrast, in an integrated architecture, the different elements of the system are interconnected and rely on shared resources, data, and processes to function efficiently, requiring high coordination and synchronization. This approach offers key benefits like improved performance, streamlined communication, and reduced system complexity.

As part of the development process of the F-35 aircraft, many studies were carried out that led to an integrated architecture, a significant evolution from traditional federated systems [54]. This design approach enhances performance, affordability, and efficiency by reducing the amount of hardware requirements. The F-35’s integrated architecture blends sensors, communications, and flight control systems using high-speed fiber-optic data buses and powerful commercial off-the-shelf processors. The integrated architecture enables better data sharing, improving situational awareness and combat capabilities. It reduces system part count and aircraft size and weight, enhances reliability and maintainability, and makes the F-35 more cost-effective. Key features include the electro-optical targeting system, Distributed Aperture System (DAS), and sensor fusion. This design of the F-35 makes it a versatile platform in modern aerial warfare [54,58]. The main advantages of this architecture that supports interoperability are reflected in the connectivity infrastructure between all the processors in the integrated core processor (ICP) and the redundancy featured by using a variety of technologies and redundant components.

F-35’s first version architecture

The first version of the F-35 architecture is based on two sub-systems [59] as described in Figure 4: the vehicle (platform) systems (presented in a dashed frame) and the mission systems (all the other components in Figure 4). The mission systems are divided into two: avionics/integrated core processor (ICP) (presented in a blue background) and a variety of sensors connected to it (presented in a dotted frame). The ICP includes all components such as data processing, fusion, mission management, etc. Within the mission systems, the sensors are connected to the ICP via three communication buses: two-way connections, point-to-point, or point-to-many points. A semi-connectivity component exists within the ICP area of the architecture, to which all the units in the ICP are connected. The ICP unit serves as a buffer between the sensors and the vehicle systems. The vehicle systems are connected to the mission systems and do not control dedicated sensors.

Within the mission system area, there is an external component. This component is responsible for communication with external systems, such as neighboring F-35 aircraft or legacy aircraft systems. It is possible to communicate with a new array specially advanced for the F-35 aircraft through the Multifunction Advanced Data Link (MADL) system or legacy systems through DATALINK 16.

There are several limits regarding this F-35 architecture:

• Information sharing between the sensor and the vehicle system is enabled only through the ICP.
• Information sharing between effectors, such as fire control, is enabled only within the ICP.
• Lack of governance unit.
• Lack of cybersecurity and safety layers.
• There are no physical or virtual mediators in the general architecture to allow new information sharing with legacy components.

We propose several adjustments to improve the system architecture. First, a connectivity infrastructure layer should be added that enables information sharing between sensors and effectors for all system components. A central communication bus shall support information transfer requirements within the system (data, RF, and electrical signals). All system parts, including the effectors, are connected through the connectivity infrastructure layer. We eliminated the buffer between the sensors and the vehicle systems and between the sensors and the various units within the ICP. The governance unit monitors the system processes and performance, ensures that the system is functioning properly, and identifies a required change in the system dynamics due to environmental change or emergent behavior.

Second, we recommend incorporating a new component in the connectivity layer designed to interface with external capabilities. This component would serve as a versatile gateway, capable of integrating with external sensors, effectors, or network capabilities that extend beyond the individual platform. This addition allows the F-35 to seamlessly incorporate and utilize resources from a broader ecosystem of platforms, effectively creating a “platform cloud”. This architectural enhancement would significantly increase the aircraft’s adaptability and operational flexibility, allowing it to leverage distributed capabilities across multiple platforms. Such an approach aligns with the principles of modularity and interoperability, enabling the F-35 to evolve and adapt to emerging technologies and operational requirements without necessitating extensive redesigns. The communication infrastructure to external systems can be DATALINK 16 for communication with legacy aircraft or the MADL system for communication with aircraft from the F-35 generation.

Third, cyber and safety layers are important to protect from internal safety failures and cyberattacks. The system must allow connection only between trusted and authorized components. Generic cyber capabilities, such as authentication, authorization, monitoring, and encryption, shall support the security of the system and its data. Safety mechanisms are integrated into systems to prevent endangering human life or severe damage. These units can be independent or be integrated into other units, but in any case, they must be part of the system. Generic safety capabilities, such as safety information sealing and safety information completeness monitoring, shall support all other components.

6.3. Upgrades from the F-35 JSF First Version to the Fusion Architecture

The F-35’s current fusion architecture

Frey et al.’s research [56] shows the fusion architecture of the F-35 JSF as reproduced in Figure 5. This version was delayed due to the high complexity of integrating the fusion sub-system into the original design. There are several main layers in this version: information sources (data collection layer) and their virtual models (VIMs), fusion algorithms, and information consumers (the layers presented above the fusion layer). The flow of information is from various sensors, on-board and off-board (external), through the VIM to the fusion layer, and from there to the information consumers. The information consumers in the F-35 are the pilot’s helmet (UI), various weapons (effectors), etc. According to Frey et al. [56], one of the first steps in building the fusion architecture was to incorporate VIMs between the information sources and the fusion processor (fusion layer). The concept of the VIM was originally planned for one of the first software blocks [55] but was delayed. Another improvement in this version regards enabling information flow from external sources through the VIM.

In the existing fusion architecture, several principles have been implemented as we proposed in this work. First, there is loose coupling between the sensor layer (data collection layer) and the data processing layer, which includes the fusion component. There is a fusion of information from on-board and off-board sensors, where the latter is presented as an external component in the data collection of the proposed generic architecture in this paper.

There are several issues regarding the F-35 fusion architecture that require attention:

• Information sharing between the sensor and vehicle system/mission system flows via the fusion algorithms and creates a single point of failure.
• Lack of information sharing between effectors and all other components.
• Lack of governance unit.
• Lack of cybersecurity and safety layers.

To overcome these issues, we propose several architectural upgrades as depicted in Figure 6. The white spaces cover the new or adjusted layers and components to comply with the generic architecture model in Figure 1, while the gray layers and blue components already exist in the architecture. First, we recommend broadening the VIMs into a full-fledged connectivity infrastructure layer to connect all the layers of the architecture—sensors, information consumers, and processing units. By creating a connectivity infrastructure layer, consumers will be able to directly receive raw information from the various sensors without accessing the fusion processor in the avionics, as well as fused processed information; this eliminates the fusion algorithm component as a single point of failure for data flow from the sensors to the vehicle systems and effectors. Integrating the VIM into the connectivity infrastructure by adding physical or virtual mediators may support the principle of loose coupling. Trusted external interfaces will also be connected to the connectivity infrastructure layer so that information consumers can directly send or receive information from external aircraft in addition to local sensors. The governance unit should be included, as mentioned in the recommendations for the first version. A frequency management component should be added.

Second, cyber and safety layers should be included, as mentioned in the recommendations for the first version. Third, several components are essential for better system interoperability and adaptivity, such as time synchronization, main database, AI and learning, external operators, etc. [60,61]. Fourth, separating the C2, mobility, and mission layers is crucial to guarantee modularity.

7. Discussion

As demonstrated in the F35 case study, the contribution of a generic architecture for a platform SOS is realized in two ways. The first is in improving the design process to allow the system architect to use the proposed architecture and principles to ensure that system components and services are not forgotten. Furthermore, ensure the architectural structure complies with the presented model to guarantee the efficient functionality of a self-organized platform SOS. The second aspect is incorporating changes in an existing system designed according to the generic architecture principles. The adaptability property is embedded in the generic architecture model to allow for the adaptation to future changes that are not known when design begins, more easily, without a major system architecture redesign.

Validation of the genericity and adaptability of the model in a qualitative method exemplified the value of this architecture in the case study. We refer to the initiative’s design phase contribution and the flexibility to adopt changes in further versions.

The F-35 case study has several limitations as a restricted exploration of the applicability of the generic architecture model. Firstly, it relies solely on publicly available information, without access to internal project considerations, which may obscure deeper design insights. Secondly, it does not address cost factors or commercial motivations.

The main limitations of this research are as follows: First, we provide one major case study for an aerial platform, but a deeper validation of the model is required to gain more insights by deploying this model in different types of platforms, such as land- and sea-based systems. Notwithstanding, there will always be future changes that cannot be forecasted and cannot be validated. They will be those that challenge our approach the most. This limitation cannot be removed but can be managed by testing additional use cases. Second, risk analysis is required to ensure that the proposed architectural structure does not broaden the system’s exposure to risks.

To amplify the utility of the generic architecture model, it might be coupled with existing architecture frameworks such as DoDAF [35] and TOGAF [36], to enhance their capabilities. Such coupling may be achieved by a new functional layer to support different classes of systems, such as a physical platform SOS.

8. Conclusions

This work presents a generic architecture model for a self-organized adaptive platform SOS designed to meet future challenges. The model relies on several key principles for system engineers to consider when designing such systems and presents a holistic, generic architecture encompassing required layers and components. This research offers a generic model for a wide range of platform SOSs, from advanced aircraft to other complex systems requiring adaptability and self-organization. By proposing a generic architecture model for self-organized adaptive platforms, we addressed a significant gap in the field of SOS engineering.

The generic architecture model presented in this work offers several key advantages:

• Adaptability: by incorporating principles of modularity and standardization, the model enables platforms to adapt to new scenarios and requirements that may not have been foreseen during the initial design phase.
• Simplified system engineering: the generic architecture serves as a valuable tool for system architects, providing a baseline structure that ensures all necessary logical and physical components are considered; this approach can significantly streamline the design process and reduce the likelihood of overlooking critical elements.
• Cost and time efficiency: by embedding the infrastructure for change within the system architecture, the model minimizes the need for extensive redesign and redevelopment when modifications are required; this can lead to substantial savings in both cost and time over the system’s lifecycle.
• Enhanced interoperability: the emphasis on standardized interfaces and modular design facilitates easier integration of new components and payloads, promoting a “plug-and-play” functionality that can extend the platform’s capabilities over time.
• Futureproofing: the architecture’s focus on self-organization and adaptability prepares platforms to handle unforeseen operational scenarios and evolving stakeholder needs, ensuring their continued relevance and effectiveness.

We demonstrated our principles and generic architecture model using the F-35 fighter jet, one of the most advanced air platforms available today. The F-35 shows significant progress in architecture compared to previous generations. However, we argue that the improvements proposed in this work will advance the F-35 architecture into a future system capable of adapting and accommodating changes. By embedding adaptability into the architecture, future changes, though unknown, can be more easily incorporated.

Future research directions could include the following:

• Explore the application of this generic architecture model to other domains beyond aerial platforms (land or sea platforms). Demonstrate additional test cases and their improvement using additional elements in the generic architecture.
• Deepen the design of the components of the connectivity layer.
• Explore how to identify the need for a change in the system state and the essence of the change in the system. Future research is required to complete the logic that identifies the change and determines the necessary adjustments. This work suggests that the AI and governance components incorporated into the architecture can implement this logic.
• Architecture model quantitative validation.
• Quantitative risk analysis to address the model redundancy and handle single points of failure. Furthermore, quantitative examination of the number of connections in a system when designed according to the model, where the connectivity layer connects all system components.
• Expand the architectural model to collaborative and virtual SOSs.
• Amplify the utility of the generic architecture model by coupling it with existing architecture frameworks, such as DoDAF.

In conclusion, this work contributes to the evolving field of SOS engineering by providing a framework for designing future-ready platforms. As we enter an era of unprecedented technological change and operational uncertainty, such adaptable generic architectures will become vital in ensuring systems remain viable and effective in the long run.