Concept

The INTERSECT open architecture approach roughly follows the U.S. Department of Defense Architecture Framework (DoDAF) [B5] with its different architectural viewpoints, such as (i) operational scenarios, (ii) composition, interconnectivity and context, (iii) services and their capabilities, (iv) policies, standards and guidance, and (v) capability. The major difference is that the INTERSECT open architecture splits these views over three different components (Fig. 3): (1) Science Use Case Design Patterns, (2) a System-of-Systems Architecture, and (3) a Microservices Architecture:

Science Use Case Design Patterns

Autonomous experiments, self-driving laboratories, smart manufacturing, and AI-driven design, discovery and evaluation are described as Science Use Case Design Patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. The basic template for a science use case design pattern is defined in a loop control problem paradigm. There are two classes in the Catalog of Science Use Case Design Patterns: strategic patterns and architectural patterns. Strategic Patterns define high-level solution methods using experiment control architecture features at a very coarse granularity. Architectural Patterns define more specific solution methods using hardware and software architecture features at a finer granularity. While the Architectural Patterns do inherit the features of certain parent Strategic Patterns, they also address additional problems that are not exposed at the high abstraction level of the Strategic Patterns. A specific solution may require Pattern Compositions.

System-of-Systems Architecture

The System-of-Systems Architecture clarifies used terms, architectural elements, the interactions between them, and compliance. It decomposes the federated hardware/software ecosystem into smaller and less complex systems and components within these systems. It permits the development of individual systems and components with clearly defined interfaces, data formats and communication protocols. This not only separates concerns and functionality for reusability, but also promotes pluggability and extensibility with uniform protocols and system/component life cycles. Instead of developing individual monolithic solutions for each science use case, the System-of-Systems Architecture provides one solution that can be easily adapted to different use cases using different compositions of systems. It offers operational and managerial independence of systems and of components within systems, geographical distribution with a physically distributed and federated ecosystem, emergent behavior based on the interplay between systems and components, and evolutionary development through pluggability and extensibility. Similar to the DoDAF, the System-of-Systems Architecture offers different architectural viewpoints: a Logical View, an Operational View, a User View, a Data View, a Physical View, and a Standards View.

Microservices Architecture

The Microservices Architecture maps the Science Use Case Design Patterns to the System-of-Systems Architecture with loosely coupled microservices and uniform interfaces. It defines Microservice Interaction Patterns and provides a Classification of INTERSECT Microservices that includes Microservice Capabilities for Infrastructure Services and Microservice Capabilities for Experiment Services. The microservices are defined to facilitate composition within the federated System-of-Systems Architecture. INTERSECT infrastructure microservices represent common service functionality and capabilities, such as data management, computing, messaging, and workflow orchestration that are likely to be generally useful across many science ecosystems without the need for customization. Experiment-specific microservices, on the other hand, represent services whose implementation may require detailed application knowledge, such as experiment planning or steering services that require knowledge of experiment-specific control parameters and their associated constraints. The Microservices Architecture also clarifies Orchestration of INTERSECT Microservices and Deployment of INTERSECT Microservices.

Fig. 3 Components of the INTERSECT architecture in the context of the INTERSECT Initiative’s activities.

This approach permits separating (a) coarse-grain architectural decisions, such as what objective a particular self-driving laboratory has and how that objective is being achieved, from (b) mid-grain architectural decisions, such as which instruments, robots, networks and computing systems are part of this self-driving laboratory and how do they communicate with each other, and from (c) fine-grain architectural decisions, such as which particular experiment control, data transfer and compute microservices are being used and how. The Science Use Case Design Patterns, System-of-Systems Architecture, and Microservices Architecture complement each other, just like the different viewpoints of the DoDAF. Practical Architecture Examples describe how each of these architecture components is applied to real-world use cases. The DOE‘s recent efforts in an Integrated Research Infrastructure Architecture are addressed as well, specifically the relationships between its Patterns and the Science Use Case Design Patterns.