A New Reality: Modelling & Simulation as a Service

NATO and nations use simulation environments for various purposes, such as training, capability development, mission rehearsal and decision support in acquisition processes. Consequently, Modelling and Simulation (M&S) has become a critical capability for the alliance and its nations. M&S products are highly valuable resources and it is essential that M&S products, data and processes are conveniently accessible to a large number of users as often as possible. However, achieving interoperability between simulation systems and ensuring credibility of results currently requires large efforts with regards to time, personnel and budget.

Recent developments in cloud computing technology and service-oriented architectures offer opportunities to better utilize M&S capabilities in order to satisfy NATO critical needs. M&S as a Service (MSaaS) is a new concept that combines service orientation and the provision of M&S applications via the as-a-service model of cloud computing to enable more composable simulation environments that can be deployed and executed on-demand. The MSaaS paradigm supports stand-alone use as well as integration of multiple simulated and real systems into a unified cloud-based simulation environment whenever the need arises.

NATO Modelling & Simulation Group MSG-136 (“Modelling and Simulation as a Service – Rapid deployment of interoperable and credible simulation environments”) investigated MSaaS with the aim of providing the technical and organizational foundations to establish the Allied Framework for M&S as a Service within NATO and partner nations. The Allied Framework for M&S as a Service is the common approach of NATO and nations towards implementing MSaaS and is defined by the following documents:

• Operational Concept Document
• Technical Reference Architecture
• Governance Policies

MSG-136 evaluated the MSaaS concept through various experiments and extensive gathering of stakeholder requirements and their assessment. The experimentation results and initial operational applications demonstrate that MSaaS is capable of realizing the vision that M&S products, data and processes are conveniently accessible to a large number of users whenever and wherever needed. MSG-136 strongly recommends NATO and nations to advance and to promote the operational readiness of M&S as a Service, and to conduct required Science & Technology efforts to close current gaps.

This article provides an overview of the MSG-136 results, the consolidated point of view of the global stakeholders, and outlines the way forward. From 2018-2021 the initial concepts are extended by MSG-164 (i.e., specification of issues and challenges not yet addressed) and validated through regular exercise participation and dedicated evaluation events. For this purpose, MSG-164 will focus on two main work streams:

1. To advance and to promote the operational readiness of M&S as a Service.
2. To investigate critical research and development topics to further enhance the benefits of M&S as a Service.

Introduction

Background

NATO and the nations use distributed simulation environments for various purposes, such as training, mission rehearsal, and decision support in acquisition processes. Consequently, modeling and simulation (M&S) has become a critical technology for the coalition and its nations. Achieving interoperability between participating simulation systems and ensuring credibility of results currently requires often enormous efforts with regards to time, personnel, and budget.

The NATO Modelling and Simulation Group (NMSG) is part of the NATO Science and Technology Organization (STO). The mission of the NMSG is to promote cooperation among Alliance bodies, NATO, and partner nations to maximize the effective utilization of M&S. Primary mission areas include: M&S standardization, education, and associated science and technology. The NMSG mission is guided by the NATO Modelling and Simulation Masterplan (NMSMP) [1]. The NMSMP vision is to “Exploit M&S to its full potential across NATO and the Nations to enhance both operational and cost effectiveness”. This vision will be achieved through a cooperative effort guided by the following principles:

• Synergy: leverage and share the existing NATO and national M&S capabilities.
• Interoperability: direct the development of common M&S standards and services for simulation interoperability and foster interoperability between Command & Control (C2) and simulation.
• Reuse: Increase the visibility, accessibility, and awareness of M&S assets to foster sharing across all NATO M&S application areas.

The NMSG is the Delegated Tasking Authority for NATO M&S interoperability standards. This is the rationale for the close relationship between NMSG and the Simulation Interoperability Standards Organization (SISO), which was formalized in a Technical Cooperation Agreement signed in July 2007.

Recent technical developments in the area of cloud computing technology and service oriented architecture (SOA) may offer opportunities to better utilize M&S capabilities in order to satisfy NATO critical needs. A new concept that includes service orientation and the provision of M&S applications via the as-a-service model of cloud computing may enable composable simulation environments that can be deployed rapidly and on-demand. This new concept is known as M&S as a Service (MSaaS).

NATO MSG-136 (“Modelling and Simulation as a Service – Rapid deployment of interoperable and credible simulation environments”) [2] is one of the technical working groups under the NMSG. This group investigated the new concept of MSaaS with the aim of providing the technical and organizational foundations for a future permanent service-based Allied Framework for MSaaS within NATO and partner nations. NATO MSG-136 started its three-year term of work in November 2014 and finished in November 2017. MSaaS is looking to provide a strategic approach to deliver simulation coherently against the NMSMP vision and guiding principles.

This paper provides an overview of the activities performed by MSG-136 and presents the results achieved, from the following perspectives:

• Operational concept of MSaaS: how it works from the user point of view;
• Technical concept of MSaaS: reference architecture, services metadata, and engineering process;
• Governance concept and roadmap for MSaaS within NATO.

Terminology

M&S products are highly valuable to NATO and military organizations and it is essential that M&S products, data and processes are conveniently accessible to a large number of users as often as possible. Therefore a new M&S ecosystem is required where M&S products can be accessed simultaneously and spontaneously by a large number of users for their individual purposes. This “as a Service” paradigm has to support stand-alone use as well as integration of multiple simulated and real systems into a unified simulation environment whenever the need arises.

This article uses the term service always in the sense of M&S service, unless stated otherwise, using the following definition:

The provided capability is implemented in a (distributed) system and/or organization.

Allied Framework for MSaaS

The Allied Framework for MSaaS is the common approach of NATO and Nations towards implementing MSaaS and is defined by the following documents:

• Operational Concept Document: The Operational Concept Document (OCD) describes the intended use, key capabilities and desired effects of the Allied Framework for MSaaS from a user’s perspective.
• Technical Reference Architecture: The Technical Reference Architecture describes the architectural building blocks and patterns for realizing MSaaS capabilities.
• Governance Policies: The Governance Policies identify MSaaS stakeholders, relationships and provide guidance for implementing and maintaining the Allied Framework for MSaaS.

The above mentioned documents define the blueprint for individual organizations to implement MSaaS. However, specific implementations – i.e. solutions – may be different for each organization.

Document Overview

This article is structured as follows:

• Section 2 discusses the Operational Concept for the Allied Framework for MSaaS. The purpose of the operational concept is to inform relevant stakeholders how the framework will function in practice. The capabilities and key characteristics of the proposed framework are discussed as well as the interactions of the users.
• Section 3 presents the technical concept of the Allied Framework for MSaaS. The technical concept is described in three volumes: Reference Architecture, Services Discovery, and Engineering Process.
• Section 4 discusses the governance concept. This covers roles, policies, processes, and standards for the management of the Allied Framework for MSaaS within NATO.
• Section 5 provides an overview of the experimentation performed. This includes experimentation to explore and test enabling technology for architecture building blocks from the reference architecture, and experimentation to test solutions for certain types of simulation services.
• Section 6 provides an overview of the evaluation activities performed.
• Section 7 discusses the next steps and the incremental development and implementation strategy for the Allied Framework for MSaaS.
• And finally, section 8 provides a summary and conclusions.

Operational Concept

MSaaS from the User Perspective

MSaaS enables users to discover new opportunities for training and working together and enables users to enhance their operational effectiveness, saving costs and efforts in the process. By pooling individual user’s requirements and bundling individual requests in larger procurement efforts, the position of buying authorities against industrial providers is strengthened.

MSaaS aims to provide the user with discoverable M&S services that are readily available on-demand and deliver a choice of applications in a flexible and adaptive manner. It offers advantages over the existing stove-piped M&S paradigm in which the users are highly dependent on a limited amount of industry partners and subject matter experts.

The MSaaS concept is illustrated in Figure 1. MSaaS is an enterprise-level approach for discovery, composition, execution and management of M&S services. MSaaS provides the linking element between M&S services that are provided by a community of stakeholders to be shared and the users that are actually utilizing these capabilities for their individual and organizational needs.

Figure 1: MSaaS concept. (Source Author)

The Allied Framework for MSaaS defines user-facing capabilities (front-end) and underlying technical infrastructure (back-end). The front-end is called the MSaaS Portal. The front-end provides access to a large variety of M&S capabilities from which the users are able to select the services that best suit their requirements, and track the experiences and lessons learned of other users. The users are able to discover, compose and execute M&S services through the front-end, which is the central access point that guides them through the process:

• Discover: The Allied Framework for MSaaS provides a mechanism for users to search and discover M&S services and assets (e.g., Data, Services, Models, Federations, and Scenarios). A registry is used to catalogue available content from NATO, National, Industry and Academic organizations. This registry provides useful information on available services and assets in a manner that the user is able to assess their suitability to meet a particular requirement (i.e., user rating, requirements, simulation specific information, and verification and validation information). The registry also points to a repository (or owner) where that simulation service or asset is stored and can be obtained, including business model information (i.e., license fees, pay per use costs).
• Compose: The Framework provides the ability to compose discovered services to perform a given simulation use case. Initially it is envisaged that simulation services will be composed through existing simulation architectures and protocols (e.g., using DIS, HLA, DDS) and can be readily executed on-demand (i.e., with no set up time). In the longer term, distributed simulation technology will evolve, enabling further automation of discovery, composition and execution than is possible today.
• Execute: The Framework provides the ability to deploy the composed services automatically on a cloud-based or local computing infrastructure. The automated deployment and execution allows to exploit the benefits of cloud computing (e.g., scalability, resilience). Once deployed and executed the M&S services can be accessed on-demand by a range of users (Live, Virtual, Constructive) directly through a simulator (e.g., a flight simulator consuming a weapon effects service), through a C2 system (e.g., embedded route planning functionality that utilizes a route planning service) or may be provided by a thin client or by a dedicated application (e.g., a decision support system utilizing various services like terrain data service, intelligence information service etc.). The execution services support a range of business models and are able to provide data relevant to those models (i.e., capture usage data for a pay-per-use business model).

The Allied Framework for MSaaS is the linking element between service providers and users by providing a coherent and integrated capability with a Technical Reference Architecture, recommendations and specifications for discovery, composition and execution of services, and necessary processes and governance policies.

Operational Concept Document

The purpose of the Operational Concept Document (OCD) for the Allied Framework for MSaaS is to inform relevant stakeholders how the framework will function in practice. The capabilities and key characteristics of the proposed framework are included in the OCD as well as how stakeholders will interact with the system.

Specifically, the main goals of the OCD are to inform the operational stakeholders how to evolve from their current operational stove-piped systems to the Allied Framework for MSaaS. It also serves as a platform for stakeholders to collaboratively adapt their understanding of the systems operation as new developments, requirements or challenges arise. Therefore, the OCD is written in the common language of all interested parties.

Vision and Goals

The MSaaS Vision Statement is defined as:

Technical Concept

The technical concept comprises several volumes:

• Volume 1: MSaaS Technical Reference Architecture: discusses layers, architecture building blocks and architectural patterns [15].
• Volume 2: MSaaS Discovery Service and Metadata: discusses services metadata and metadata for services discovery [16].
• Volume 3: MSaaS Engineering Process: discusses a services oriented overlay for the DSEEP [17].

This section will focus primarily on the MSaaS Reference Architecture (RA) and briefly explain the other volumes.

MSaaS Reference Architecture

Principles

The MSaaS RA is defined with a number of principles in mind. These principles are similar to the Open Group SOA Reference Architecture (SOA RA) [3] key principles and are the starting point for the architecture work by MSG-136. The principles are:

The MSaaS RA:

1. Should be a generic solution that is vendor-neutral.
2. Should be modular, consisting of building blocks which may be separated and recombined.
3. Should be extendable, allowing the addition of more specific capabilities, building blocks, and other attributes.
4. Must be compliant with NATO policies and standards (such as AMSP-01 [4] and STANAG 4603 [5]).
5. Must facilitate integration with existing M&S systems.
6. Should be capable of being instantiated to produce:
   1. Intermediary architectures
   2. Solution architectures
7. Should address multiple stakeholder perspectives.

Architecture Concepts

An architecture can generally be described at different levels of abstraction and the term reference architecture is typically used for a more abstract form of architecture. The purpose of the MSaaS RA is to provide a template for the development of an MSaaS intermediate architecture or of one or more specific MSaaS solution architectures. The MSaaS RA provides guidelines, options, and constraints for making design decisions with regards to an MSaaS solution architecture and solution implementation.

The MSaaS RA uses several concepts for describing the architecture. These concepts and their relationships are illustrated in Figure 2.

Figure 2: Reference architecture concepts. (Source Author)

The MSaaS RA defines a number of capabilities in the form of architecture building blocks and organizes these capabilities in so-called layers. An architecture building block captures, amongst others, requirements, applicable standards, relationships with other building blocks, related architectural patterns, and references to (examples of) enabling technology. The particular connection between architecture building blocks that recur consistently in order to solve certain classes of problems is called a pattern. A pattern describes how architecture building blocks can be put together for creating proven solution architectures. The enabling technology provides means for the technical realization of an architecture building block.

The MSaaS RA layers are modelled after the SOA RA layers [3], while the content of each layer in terms of architecture building blocks is supplied by the NATO C3 Taxonomy [6].

Layers and Architecture Building Blocks

The MSaaS RA is decomposed in layers, similar to the SOA RA layering structure, and each layer includes a set of architecture building blocks that provide some capability. The 9 layers are illustrated in Figure 3. Some of the layers are cross-cutting layers. For example the architecture building blocks in the Quality of Service Layer affect the building blocks in the Operational System Layer up to the Integration Layer.

Figure 3: Reference architecture layers. (Source Author)

Note that the SOA RA layers are presented from technical infrastructure layers to consumer-facing layers in that order. Also, some naming may cause confusion between C3 Taxonomy users and the SOA RA users. For example, the Operational Systems Layer does not refer to the defence operations that the C3 Taxonomy’s Operational Capabilities layer does, but rather to the operational run-time capabilities in a SOA.

The architecture building blocks per layer are shown in Table 1.

Table 1: Layers and architecture building blocks. (Source Author)

Layer	Architecture Building Blocks
Operational Systems Layer	Infrastructure Services Communication Services
Service Components Layer	SOA Platform Services
Services Layer	M&S Specific Services
Business Process Layer	M&S Composition Services M&S Simulation Control Services M&S Scenario Services
Consumer Layer	M&S User Applications NATO User Applications
Integration Layer	M&S Message-Oriented Middleware Services M&S Mediation Services
Quality of Service Layer	SOA Platform SMC Services M&S Security Services M&S Certification Services
Information Layer	M&S Information Registry Services
Governance Layer	M&S Repository Services Metadata Repository Services

The architecture building blocks are aligned with the NATO C3 Taxonomy and necessary changes will be recommended.

As an example, the Business Process Layer provides the capabilities to compose and execute a simulation, and contains the following architecture building blocks:

• M&S Composition Services: compose a simulation environment from individual services that together meet the objectives of the simulation environment.
• M&S Simulation Control Services: provide input to, control, and collect output from a simulation execution.
• M&S Scenario Services: manage the simulation of scenarios.

Each of these architecture building blocks has associated requirements and other attributes. As an example, some requirements for the M&S Composition Services are listed in Table 2.

Table 2: M&S Composition Services requirements. (Source Author)

Function	Requirements
Manage Lifecycle	The M&S Composition Services shall provide the means to define a parameterized simulation composition. The M&S Composition Services shall provide the means to update, delete and retrieve a defined simulation composition.
Execute composition	The M&S Composition Services shall provide the means to start the execution of a simulation composition, and to provide composition parameter values. The M&S Composition Services shall provide the means to orchestrate, restart and stop the execution of a simulation composition.
Programmatic Interfaces	The M&S Composition Services shall provide APIs to the Manage Lifecycle and Execute Composition functionality.

The architecture building blocks of the MSaaS RA are organized in a taxonomy, in line with the NATO C3 Taxonomy (see Figure 4). Most of the architecture building blocks in Table 1 fall under the M&S Enabling Services, providing capabilities to create a simulation environment in which M&S Specific Services are brought together to fulfil the purpose of that simulation environment. M&S Specific Services are mostly Simulation Services and Composed Simulation Services, such as Synthetic Environment Services, Route Planning Services, or Report Generation Services.

Figure 4: Taxonomy of architecture building blocks. (Source Author)

Architectural Patterns

The architectural patterns show how architecture building blocks in the MSaaS RA are related, can be combined, how they interact, and what information is generally exchanged. The architectural patterns serve as reference for solution architectures and design patterns for solution architectures. An initial set of architectural patterns is documented, but the idea is that the architecture building blocks as well as the architectural patterns are governed as a “living document” and will evolve further as knowledge is gained and as technology evolves.

Figure 5 illustrates one example of an architectural pattern, in relation to the M&S Composition Services mentioned earlier.

Figure 5: Example of a pattern. (Source Author)

In this example, a user composes a simulation environment using an M&S Composer Application. This application, in turn, employs the capabilities of M&S Composition Services and the M&S Model Repository Services. This pattern provides support for the definition, update, retrieval, and deletion of compositions. The M&S Composer Application is user-facing while the other architecture building blocks operate “behind the scene”. The interactions in the figure also imply requirements on each architecture building block.

MSaaS Discovery Service and Metadata

Technical volume 2 [16] discusses information and standards related to the description of services and exchange of metadata. More specifically:

• provides an overview of standards related to services discovery and services interface description, and
• presents national initiatives related to the exchange of services metadata, and to information models that support the (automated) composition, deployment and execution of simulation environments.

This volume relates to several architecture building blocks in the MSaaS RA, such as the M&S Composition Services for automated composition, deployment and execution; and the M&S Model Repository Services for metadata standards.

MSaaS Engineering Process

Technical volume 3 [17] discusses a service-oriented overlay for the Distributed Simulation Engineering and Execution Process (DSEEP) [7], by adding an overlay for a service-oriented implementation strategy (besides HLA, DIS, and TENA). This volume discusses the activities or tasks related to this implementation strategy.

Governance Concept

Governance and Roles

A challenging aspect of establishing a persistent capability like the Allied Framework for MSaaS is to develop an effective governance model. Governance ensures that all of the independent service-based efforts (i.e. design, development, deployment, or operation of a service) combined will meet customer requirements.

MSG-136 developed policies, processes, and standards for managing the lifecycle of services, service acquisitions, service components and registries, service providers, and consumers. These are defined in the Allied Framework for Modelling and Simulation as a Service (MSaaS) Governance Policies [13], and are intended to be published as Allied Modelling and Simulation Publication AMSP-02.

The NMSG is the delegated NATO authority for M&S standards and procedures. Nations are encouraged to use the standards nationally or in other multi-national collaborations. After completion of the MSG-136 task group, the NMSG M&S Military Operational Requirements Subgroup (MORS) will become custodian of the governance policies. MORS is the custodian of best practices with regards to the use of M&S in the training domain and in other domains. The governance policies will be submitted to MORS for future maintenance, updates and dissemination with respect to operational needs of NATO agencies and national stakeholders.

The NMSG M&S Standards Subgroup (MS3) will become custodian of the MSaaS Technical Reference Architecture [15], and is responsible for the maintenance of the MSaaS technical aspects and standards documents.

General Policies

The general policies for instituting governance mechanisms of MSaaS-based solutions are:

• An MSaaS implementation shall conform to the governance policies as identified and established by the governance document.
• An MSaaS solution architecture shall comply with the MSaaS Technical Reference Architecture (see section 3, Technical Concept).
• Any M&S service shall conform to the practices and recommendations for Integration, Verification and Compliance Testing as defined by NATO MSG-134 [8].

The ability to effectively manage all stages of the service lifecycle is fundamental to the success of governing M&S services. The Service Lifecycle Management Process as defined in [9] contains a set of controlled and well-defined activities performed at each stage for all versions of a given service. Table 3 lists the sequential service provider lifecycle stages.

Table 3: Service provider lifecycle stages. (Source Author)

Lifecycle Stage	Description
Proposed	The proposed service’s needs are identified and assessed as to whether needs can be met through the use of services.
Definition	The service’s requirements are gathered and the design is produced based on these requirements.
Development	The service specifications are developed and the service is built.
Verification	The service is inspected and/or tested to confirm it is of sufficient quality, complies with the prescribed set of standards and regulations, and is approved for use.
Production	The service is available for use by its intended consumers.
Deprecated	The service can no longer be used by new consumers.
Retired	The service is removed from the Allied Framework and is no longer used.

All service providers shall define levels for each service (e.g., regarding availability, etc.). Service Providers and users shall agree on a Service Level Agreement (SLA) prior to usage. Obviously, service providers are required to indicate the forecasted retirement date of a specific version of a service.

Security Policies

The approach to ensuring security is intrinsically related to the cloud computing service model (SaaS, PaaS, or IaaS) and to the deployment model (Public, Private, Hybrid, or Community) that best fits the Consumer’s missions and security requirements. The Consumer has to evaluate the particular security requirements in the specific architectural context, and map them to proper security controls and practices in technical, operational, and management classes. Even though the Cloud Security Reference Architecture [19] inherits a rich body of knowledge of general network security and information security, both in theory and in practice, it also addresses the cloud-specific security requirements triggered by characteristics unique to the cloud, such as decreased visibility and control by consumers. Cloud security frameworks including information management within an infrastructure shall support the cloud implementers, providers and consumers [10]. However, MSG-136 recognizes that a more tailored approach may be needed to exploit MSaaS specific capabilities and proposes to develop additional guidelines as part of follow-on work.

Compliancy Policies

Compliancy testing of individual components of a NATO or multi-national simulation environment is the ultimate responsibility of the participating organizations. Currently, NMSG and its support office (MSCO) do not provide compliancy testing services or facilities. Some existing HLA certification tools and services cover only basic testing (i.e., HLA Rules, Interface Specification and Object Model Template (OMT) compliance) and do not provide in-depth functional testing that is needed to support federation integration and validation. The available tools are also outdated. The current NMSG activity MSG-134 is addressing the next generation of compliancy testing and certification needs for HLA [8].

Experimentation

MSG-136 performed several experiments to test enabling technology for MSaaS. Two strands of experimentation were performed: (1) experimentation to explore and test enabling technology for architecture building blocks from the reference architecture, and (2) experimentation to test solutions for certain types of Simulation Services. Test cases were defined, tests performed, and test results recorded in an experimentation report [18]. A brief overview of the experimentation and test cases follows below.

Explore and Test Enabling Technology

Most test cases in this strand of experimentation evolve around container technology as the enabling technology for a number of architecture building blocks. This technology enables M&S Enabling Services and M&S Specific Services to run on a local host as well as in a cloud environment.

The experiment environment that was used for the test cases is illustrated in the following figure. The experiment environment is a collection of private clouds and a common cloud. The common cloud is Amazon Web Service (AWS), sponsored by NATO CSO.

Figure 6: Illustration of experiment environment. (Source Author)

Common components are:

• A private Docker Registry and a web-based front-end for the exchange of Docker container images (provided by NLD);
• A private GitHub repository for the description of container images in the Docker Registry, and for the exchange of software, configuration files and other developmental data (provided by USA).

The Docker Registry contains several container images for containerized HLA federates, from which various compositions can be created for the different test cases. Many of these images have been created following the design patterns in [11].

Test cases include:

• Container networking: explore different container networking models for connecting containerized HLA federate applications.
• Containerization of HLA federates: evaluate approaches in containerizing HLA federate applications (see also [11]).
• Metadata Repositories and Discovery: Demonstrate interoperation of repositories across nations.
• Simulation Composition: explore automated composition and execution of services.
• Container Orchestration Environments: evaluate two popular container orchestration environments for M&S (see also [12]).

Test Solutions for Simulation Services

Tests cases in this strand of experimentation concern the interoperation of applications with certain types of Simulation Services. Test cases include:

• Computer Generated Forces (CGF) – Synthetic Environment Service: connect a CGF simulator to a Synthetic Environment Service to request environment data in various formats.
• C2 Application – Route Planning Service: connect a C2 Application to a Route Planning Service to request route planning information.

Evaluation

The evaluation activities focus on whether MSaaS will reduce costs and integration time for creating a new instance of a simulation environment, compared to what it costs today. What is the main advantage of having an MSaaS-based solution? The premise of the evaluation activities is to answer this objectively based on the measurements performed and data collected. The evaluation activities of MSG-136 are currently ongoing and will be included in the MSG-136 Final Report.

Implementation Strategy and Next Steps

Implementation Strategy

Service-based approaches rely on a high degree of standardization and automation in order to achieve their goals. Therefore the development and implementation of a recommended set of supporting standards is a key output of the reference architecture. MSG-136 research has identified the importance for the following capabilities:

• M&S Composition Services: create and execute a simulation composition. A composition can be created from individual simulation services or from smaller compositions.
• M&S Repository Services: store, retrieve and manage simulation service components and associated metadata that implement and provide simulation services, in particular metadata for automated composition.
• M&S Security Services: implement and enforce security policies for M&S services.

MSG-136 proposes an incremental development and implementation strategy for the Allied Framework for M&S as a Service. The incremental approach facilitates a smooth transition in the adoption of an Allied Framework for M&S as a Service and describes a route that will incrementally build an Allied Framework for M&S as a Service.

The proposed strategy also provides a method to control the rate of expansion of the new framework permitting the iterative development and training of processes and procedures. Finally, it permits those nations that have been early adopters of an Allied Framework for M&S as a Service and have national capabilities to accrue additional benefits from their investments and highlight the benefits as well as providing lessons learned and advice to those nations considering similar investments.

As illustrated in Figure 7, the implementation strategy is broken down into three phases:

1. Phase 1: “Initial Concept Development”
   The Initial Concept Development (2015 until end of 2017) is executed by NMSG-136 and consists of concept development and initial experimentation. For this period an MSaaS Portal and individual M&S services were provided by individual members of MSG-136 for trial use.
2. Phase  2: “Specification & Validation”
   From 2018-2021 MSG-164 will mature MSaaS in an operationally relevant environment and conduct necessary research and development efforts to evolve and extend the initial concepts as developed by MSG-136. This phase includes development of suitable STANAGs or STANRECs, and moving from prototype implementation to operationally usable and mature systems.
3. Phase 3: “Implementation”
   By 2025 Full Operational Capability (FOC) is achieved which includes adaptation of many existing simulation related services to the MSaaS Reference Architecture. This is achieved primarily by adding services to the Allied Framework for M&S as a Service.

Figure 7: MSaaS Implementation strategy. (Source Author)

Next Steps

The next steps in defining and evolving the Allied Framework for MSaaS are executed by MSG-164 (see previous section). MSG-164 kicked off in February 2018 and will finish in 2021. Building upon the Allied Framework for M&S as a Service developed by MSG-136 this activity addresses three main objectives:

1. To advance and to promote the operational readiness of M&S as a Service.
2. To align national efforts and to share national experiences in establishing MSaaS capabilities.
3. To investigate critical research and development topics to further enhance MSaaS benefits.

MSG-164 will specify and test an MSaaS infrastructure that is suitable for use in an operationally relevant environment and will support continued MSaaS experimentation and evaluation efforts. This activity will also deliver a Technical Report and recommendations with regards to the organizational perspective of introducing MSaaS in NATO and in the Nations.

To address the objectives, MSG-164 will cover the following topics:

1. Demonstrate MSaaS application in an operationally relevant environment through operational experimentation as part of exercises and integration into simulation applications (like simulation-based capability development). Annual participation in CWIX to develop MSaaS to maturity through a phased approach.
2. Maintain and enlarge the MSaaS Community of Interest.
3. Establish interim governance structure and collect experiences w.r.t. MSaaS governance.
4. Collect and share experiences in establishing MSaaS capabilities and providing M&S services.
5. Conduct research on M&S-specific service discovery and service composition.
6. Conduct research and development activities on M&S-specific federated cloud environments, federated identity management and cyber secure communications.
7. Conduct research on enabling services like scenario specification services, etc.

Additionally, MSG-164 will

1. Act as governance body for the Allied Framework for M&S as a Service, maintaining and updating (if needed) the therein included documents, i.e. AMSP-02 (MSaaS Governance Policies), the MSaaS Operational Concept Description, and the MSaaS Technical Reference Architecture) with associated technical documents.
2. Collaborate with international standards bodies (like SISO, IEEE, etc.).
3. Inform and engage stakeholders in NATO, Academia, and Industry about MSaaS.

Summary and Conclusions

SG-136 investigated the concept of M&S as a Service (MSaaS), a new concept for the discovery, composition, execution, and management of M&S services. The concept is described from different perspectives:

• Operational concept of MSaaS: how it works from the user point of view;
• Technical concept of MSaaS: technical reference architecture, services discovery metadata, and engineering process;
• Governance concept and roadmap for MSaaS within NATO.

Technical implementations of MSaaS have been developed and evaluated in several experiments and demonstrations (TRL 4). MSG-136 also proposed an MSaaS governance approach. The conclusion is that MSaaS is a promising innovation towards more accessible and more cost effective M&S capabilities.

The participating nations and NATO organizations are currently implementing MSaaS using cloud technology, based on the MSG-136 research and experimentation and to inform the user community. MSG-136 plans to further investigate a number of areas including discovery and composability of M&S services; and to address security aspects of cloud based solutions in more detail. A new technical activity is being prepared and will be submitted to NMSG for approval in the fall of this year.

The NMSG will continue to participate in the SISO Cloud-based M&S Study Group and share its approach and experiences. The goal is that our work will contribute to a set of open standards and recommendations for MSaaS.

Acknowledgement

The authors would like to acknowledge the contributions of the MSG-136 team members for the ideas and results that are included in this paper.

References

1. NATO Modelling and Simulation Master Plan NMSMP v2.0 (AC/323/NMSG(2012)-015).
   https://www.sto.nato.int/NATODocs/NATO Documents/Public/NATO_MS_Master_Plan_Web.pdf
2. https://www.sto.nato.int/Pages/activitieslisting.aspx?FilterField1=ACTIVITY_NUMBER&FilterValue1=MSG-136
3. SOA Reference Architecture, C119, Open Group Standard, 2011
4. NATO AMSP-01 (NATO Modeling and Simulation Standards Profile), Edition C version 1, NATO Standardization Office, March 2015
5. STANAG 4603 Edition 2, Modeling and Simulation Architecture Standards for Technical Interoperability: HLA, NATO Standardization Office, 17 February 2015
6. C3 Classification Taxonomy, Baseline 1.0, NATO Allied Command Transformation (ACT) C4ISR Technology and Human Factors (THF) Branch, 15 June 2012
7. IEEE 1730-2010: Recommended Practice for Distributed Simulation Engineering and Execution Process (DSEEP)
8. NATO Distributed Simulation Architecture & Design, Compliance Testing and Certification. STO Technical Report STO-TR-MSG-134. To be published.
9. Federal Aviation Administration (FAA): “System Wide Information Management (SWIM) Governance Policies”, Version 2.0, 12 March 2014.
10. NATO Consultation, Command and Control Board (C3B): “NATO Cloud Computing Policy”, AC/322-D(2016)0001, 7 January 2016.
11. Guidelines and best practices for using Docker in support of HLA federations; 2016-SIW-031; SISO SIW Fall 2016; T.W. van den Berg, A. Cramp, B. Siegel.
12. Container orchestration environments for M&S; 2017-SIW-006; SISO SIW Fall 2017; T.W. van den Berg, A. Cramp.
13. NATO STO: Allied Framework for Modelling and Simulation as a Service (MSaaS) – Governance Policies. 16 January 2018.
14. NATO STO: Operational Concept Document (OCD) for the Allied Framework for M&S as a Service. AC/323(MSG-136)TP/830. STO-TR-MSG-136-Part-III. 16 January 2018.
15. NATO STO: Modelling and Simulation as a Service, Volume 1: MSaaS Technical Reference Architecture. AC/323(MSG-136)TP/831. STO-TR-MSG-136-Part-IV. 16 January 2018.
16. NATO STO: Modelling and Simulation as a Service, Volume 2: MSaaS Discovery Service and Metadata. AC/323(MSG-136)TP/832. STO-TR-MSG-136-Part-V. 16 January 2018.
17. NATO STO: Modelling and Simulation as a Service, Volume 3: MSaaS Engineering Process. AC/323(MSG-136)TP/833. STO-TR-MSG-136-Part-VI. 16 January 2018.
18. NATO STO: MSaaS Concept and Reference Architecture Evaluation Report. AC/323(MSG-136)TP/829. STO-TR-MSG-136-Part-II. 16 January 2018.
19. National Institute of Standards and Technology: NIST Cloud Computing Security Reference Architecture, NIST Special Publication 500-299, Draft, 15 May 2013.