## 2 Related Work
Various types of software, including scientific software, compilers, libraries, and neural simulators are pre-installed on each VM. The platform allows users to request the assignment of a set of VMs to build and run a scientific simulation, according to specific requirements. Differently, OCEAN [15] is a MSaaS platform based on OpenStack and specifically designed and developed for supporting training and simulation-based exercises in the context of NATO-funded military research programs. Similar to the ArTIC-MS platform, OCEAN's architecture includes a cloud infrastructure, a service repository, and a portal that allows users to discover, select, compose, and deploy M&S components. Moreover, it also shares the potential target audience. The main difference is that OCEAN is not specifically designed to support inter-cloud interoperability. Its orchestration engine (i.e., OpenStack HEAT [29]) requires the use of an implementation-specific technology, namely HOT (Heat Orchestration Template) [30], for the description of a simulation application, while ArTIC-MS makes use of the TOSCA standard. Regarding the orchestration of service composition, the architecture proposed in [14] exploits MDE-based approaches and techniques to automate the application-level orchestration of M&S services according to an abstract composite service specified by use of different standards and notations, e.g., the unified modeling notation (UML) and the business process modeling and notation (BPMN). As already mentioned in Section 5, ArTIC-MS deals with the infrastructure-level orchestration, e.g., the execution of actions required for deploying and executing the several M&S services onto the required execution platform. Finally, a preliminary version of ArTIC-MS was proposed in a previous work that this paper extends [12]. It should be underlined that the novel contribution this paper provides is not limited to a revision of ArTIC-MS building blocks. Differently, the two papers are quite different from each other and they do not address the same objectives. Moreover, the completeness of this work goes far beyond what we discussed in the previous contribution. Specifically, the previous paper aims to provide a preliminary description of ArTIC-MS, which focuses on the identification of architecture's building blocks. Such a description does not give any detailed view of the capabilities of each component and does not discuss the conceptual approach used for its specification. Moreover, the previous paper discusses an example application for assessing the feasibility and limitations of standards, principles, and technologies at the basis of the proposed approach. Differently, this work illustrates the complete methodological and architectural approach that has been used to specify ArTIC-MS, as discussed in Sections 4.2 and 4.3, respectively. Moreover, this paper provides a complete description of ArTIC-MS from functional and operational points of view, as outlined in Sections 5 and 6, respectively. Specifically, the architecture is described in terms of:  
* The adopted conceptual architectural approach, clarifying how ArTIC-MS was derived from a reference architecture, and how concrete implementations might be based on ArTIC-MS;
* The capabilities of ArTIC-MS;
* The operational view of ArTIC-MS, which is described throughout the specification of ArTIC-MS actors and use cases that specifically address the federation of heterogeneous infrastructure. From a concrete point of view, this work discusses an example application carried out as part of the MASTER research project, which addresses a federation of two heterogeneous cloud infrastructure (OpenStack [16] and Alien4 Cloud [31]) to show how ArTIC-MS can be used for supporting the FAIR principles (findability, accessibility, interoperability, and reusability) of a MSaaS platform.