Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

Manzano,, Wallace; Graciano Neto, Valdemar, Vicente; Nakagawa, Elisa, Yumi

doi:10.1093/comjnl/bxz028

Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

Manzano,, Wallace;Graciano Neto, Valdemar, Vicente;Nakagawa, Elisa, Yumi 2020-05-20 00:00:00 Abstract Systems-of-Systems (SoS) combine heterogeneous, independent systems to offer complex functionalities for highly dynamic smart applications. Besides their dynamic architecture with continuous changes at runtime, SoS should be reliable and work without interrupting their operation and with no failures that could cause accidents or losses. SoS architectural design should facilitate the prediction of the impact of architectural changes and potential failures due to SoS behavior. However, existing approaches do not support such evaluation. Hence, these systems have been usually built without a proper evaluation of their architecture. This article presents Dynamic-SoS, an approach to predict/anticipate at design time the SoS architectural behavior at runtime to evaluate whether the SoS can sustain their operation. The main contributions of this approach comprise: (i) characterization of the dynamic architecture changes via a set of well-defined operators; (ii) a strategy to automatically include a reconfiguration controller for SoS simulation; and (iii) a means to evaluate architectural configurations that an SoS could assume at runtime, assessing their impact on the viability of the SoS operation. Results of our case study reveal Dynamic-SoS is a promising approach that could contribute to the quality of SoS by enabling prior assessment of its dynamic architecture. 1. INTRODUCTION Software-intensive systems have been increasingly required to interoperate amongst themselves, communicating, exchanging, and using information exchanged.1 Consequently, a distinct class of systems known as Systems-of-Systems (SoS)2 has arisen. An SoS results from operationally and managerially software-intensive systems (called constituents) working together to fulfill missions [1, 2]. SoS will likely form the next generation of software-intensive systems [3, 4], often supporting missions in critical domains (such as emergency and crisis response management, medical applications, and national defense systems) and smart applications (such as smart cities, autonomous cars or vehicles and smart traffic control) [5, 6]. To guarantee a reliable operation for SoS, it is important to establish strategies to maintain an SoS operation in progress, despite a high degree of dynamism, with new constituents joining the SoS at runtime, others leaving it, or being replaced [5, 7–10]. Simulation techniques have been successfully used, especially in software engineering [11], to support the visualization of the system’s dynamic behaviors. Simulations can anticipate, at design time, failures and behaviors that can potentially occur at runtime. In particular, the simulation of software architectures can be achieved by using simulation models with dynamic reconfiguration to predict architectural configuration changes at runtime [12]. Dynamic Structure Discrete Event System Specification (DS-DEVS) [13, 14] is a simulation formalism for modeling behavior of systems from input, output and their states, as well as the coupling of these systems. Nevertheless, despite the suitability of simulation formalisms to predict behaviors with dynamic reconfiguration support, there is a lack of precision in simulating SoS software architectures, i.e. simulating the behavior of constituent systems and their relationship to each other, and to the environment. The simulation formalisms have limitations on the precise representation of SoS software architectures, including the representation of different types of systems, environment representation, and dynamic reconfiguration. Despite the formalism supporting the dynamic architecture representation, the mechanism to implement it is arbitrarily chosen by the user. The main research question addressed in this work is: How to provide a means to assure that the SoS operation is trustworthy, i.e. it will be maintained on-the-fly, despite the inherent SoS dynamic architecture? To address this question, the aim of this article is to present Dynamic-SoS, an approach for simulating SoS software architectures with dynamic reconfiguration support. The main contributions of this article are: (i) the proposition of a set of canonical dynamic reconfiguration operators for SoS software architectures; (ii) a model transformation capable of automatically generating a dynamic reconfiguration controller (DRC); (iii) the engineering of DRC itself, since such an idea could be used for other simulation formalisms; and (iv) the characterization of the process to implement the dynamic architecture operators for SoS software architectures. We evaluated our approach using three case studies in distinct domains: Flood Monitoring SoS, Smart Building SoS and Space SoS. For each case study, we performed a set of 150 architectural changes in the software architecture. We concluded our approach successfully supports simulation of SoS while accounting for dynamic architectures. As a result, our work may potentially be used to evaluate SoS dynamic architectures, enhancing SoS quality by enabling the visualization of possible problems that the SoS may exhibit besides predicting/anticipating SoS architectural behavior at runtime, thus evaluating whether the SoS can sustain their operation. This article is organized as follows: Section 2 provide the necessary background, Section 3 presents Dynamic-SoS, Section 4 presents our evaluation and results, and Section 5 contain final remarks and directions for future work. 2. BACKGROUND Software-intensive SoS are a combination of software-intensive systems and are resulted from the interoperability of several managerially and operationally independent software systems called constituents. Engineering of an SoS often happens in an unknown environment and surrounded by uncertainties [15, 16]. SoS often exhibit a well-defined set of characteristics postulated by Maier [1], which includes operational and managerial independence of constituents, evolutionary development, emergent behaviors and distribution. Besides that, interoperability, heterogeneity, and hierarchy are also considered important characteristics [17]. Constituents of an SoS can also be other entire and complex SoS, such as smart buildings, smart traffic control systems and flood monitoring SoS, which are themselves SoS, but are constituent parts of a larger SoS such as a smart city. Hence, it is imperative to investigate how to design such systems, predicting their behavior and structure still at design-time. SoS software architectures exhibit dynamic architectures as a consequence of their fundamental characteristics, in particular, operational independence of constituents, which states that a constituent is not exclusively dedicated to an SoS, but its operational independence is maintained [1]. Dynamic architectures exhibit a property called dynamic reconfiguration, i.e. their structure can change at runtime, inserting or removing parts, complying with the requirement of generating a new architectural arrangement that is still functional. Hence, a constituent can be part of an SoS for a finite period of time, contributing to the accomplishment of the SoS missions, later leaving it, demanding for a reorganization of the structure of the SoS to maintain its operation. However, the suitability of traditional operators for dynamic architectures of single systems and how to carry out such operators on SoS software architectures have not still been explored. SoS also exhibit an intrinsic relation among dynamic architectures, interoperability and emergent behavior. Emergent behaviors result from the interoperability among constituents, i.e. the ability of two or more constituent systems to purposefully exchange and use data and information [18]. Some emergent behaviors, so-called predicted emergent behaviors, are intentionally engineered by the systematic combination of the individual functionalities of constituents involved in an SoS [10, 19]. An SoS architecture enables interoperability (and emergent behaviors, as a consequence) when the SoS architecture is in a valid operational state. In this case, a valid operational state is such that the constituents necessary to allow the emergence of a behavior are properly connected to allow the information exchange to perform the emergent behavior. An architectural change to the SoS dynamic architecture is considered successful when, besides transforming an SoS from an architectural configuration (also known as coalition) toward a new one, it also moves the architecture of an SoS from one valid operational state to another one. The languages currently adopted to describe software architectures, such as Unified Modeling Language (UML3), Systems Modeling Language (SysML4) and Compass Modeling Language (CML5), lack sufficient accuracy to effectively describe SoS architectures, specially in regard to [2, 13, 20–24]: (i) dynamic architecture; (ii) the description of constituents unknown at design time; (iii) environment modeling; (iv) the combination of formal foundations and high-level abstraction notations; and (v) the concept of SoS software architecture with adequate detail to guarantee precision in representation. UML, for instance, does not support a suitable specification of SoS software architectures, as once a notation for specifying dynamic architectures is lacking [2]. UML diagrams must be adapted to tackle representation of multiple constituents through profiles, which do not represent SoS dynamism, including changes at runtime. In turn, SysML lacks specific structures to model various SoS architectural aspects such as dynamic architecture [2]. Moreover, simulating SoS using SysML often requires distributed simulation and simulators, requiring a heavy infrastructure and implementation to support the interoperability between simulations of single systems. CML is a formal language specially conceived for formal specification of Comprehensive Modeling for Advanced Systems of Systems (COMPASS) alliance [25]. However, it does not provide constructs for environment modeling, software architecture or dynamic architecture [26]. SosADL was conceived to support the specification of SoS architectures [8]. SosADL overcomes the drawbacks exhibited by the aforementioned languages. In SosADL, architectures are abstractly defined by coalitions, which represent temporary alliances among constituents that collaborate via mediators [27]. Such coalitions can be dynamically formed and changed at runtime. The link among architectural elements in SosADL are referred as bindings. Coalition behaviors document how constituents interoperate to accomplish a given set of missions. SosADL also allows the definition of software architecture for self-organizing SoS [19]. The architecture of an SoS defines policies for assembling systems and mediators as coalitions, which are further characterized by behavior, data type and gate declarations. Mediators are first-class elements representing communication links between two or more constituents [28], which can be TCP/IP connections, Zigbee connections or Bluetooth. Gates are abstractions that enable the establishment of connections. A connection can receive stimuli from or act upon the environment, enabling the communication among independent elements. Data types may have inherent functions, and functions can be associated to expressions. Mediators and systems may also be specified in terms of gates, data types and behaviors [8, 29]. SosADL prescribes the representation of dynamic architectures in its operational semantics, i.e. the recipe of how each language construct should be executed. However, an SosADL model is effectively executable only when an equivalent executable semantics is provided. Therefore, mechanisms such as simulation models are required to provide executable denotational semantics. Indeed, studies have mentioned how important simulation-based approaches are to be investigated in SoS context [11, 13, 30–34]. These approaches [11, 23, 34, 35]: (i) support validation of expected emergent behaviors; (ii) empower the observation of unexpected emergent behaviors; (iii) enable the prediction of errors, diagnosing them and permitting corrections; and (iv) provide a visual and dynamic viewpoint, reproducing stimuli that the system can receive from an operational environment. DEVS is a well-known simulation language [13, 36]. It consists of a modeling formalism based on the idea of atomic and coupled models. Atomic models represent individual entities in the SoS (for instance, systems), while coupled models represent a combination of atomic models. Such models exhibit the following elements [13]: (i) a labeled state diagram that performs transitions due to input or output events; (ii) variable initialization; and (iii) definition of abstract data types, global variables, ports and events. In turn, coupled models are composed of atomic models, i.e. coupled models represent the entire SoS. We base our approach on DEVS and adopt a DEVS dialect called DEVS Natural Language (DEVSNL) [13], which enables programming atomic and coupled models intuitive format using tools such as MS4ME.6 Despite its advantages, DEVS and other simulation approaches do not properly support the software architecture description of SoS [2]. DEVS deals with the system architecture, i.e. a simulation model in DEVS considers the software and hardware aspects of all the constituents that compose an SoS, and for the SoS itself. DEVS deals with several important characteristics of software architectures, such as data types, constituent systems (represented as atomic models), constituent behaviors (expressed as labeled state machines), SoS structure (comprising the overall organization of such constituents) and how constituent exchange data (coupled models), and events. However, there are some important specific details of the software architectures of SoS that are not tackled by DEVS. DEVS only deals with the notion of ports. There is no notion of connections and gates separately, which are a paradigm of software architectures (components, connections, values and constraints define a software architecture [37, 38]) used by SoS modeling [39]. Equivalently, there is no differentiation among the concepts of mediators, nor constituents nor stimuli generators. In DEVS, every major entity of an architecture is an atomic model. Thus, the SoS software architecture cannot be entirely characterized. The surrounding environment can be represented, but this is not natively supported, which is an important aspect of any software architecture, including SoS software architectures [38]. SosADL is capable of modeling SoS; while DEVS can simulate SoS models; then a Model-Based Engineering (MBE) can combine such models [15], harmonizing both formalisms, exploiting their advantages and overcoming their drawbacks. This model combination can be established by means of model transformations, which comprise a mapping between the constructs of a source and of a target language, supporting their automatic transformation [40]. Initiatives have separately investigated the description of SoS dynamic architectures and/or SoS simulation models, while other approaches have adopted model transformations to bridge architectural models (π-ADL, SySML, HLA, DoDAF7) and simulation formalisms (Go language, Simulink8) [22]. For instance, Cavalcante et al. [24] report a model transformation approach to map π-ADL architectural models in the Go software code. Although π-ADL provides architectural description models for concurrent and communication processes, the approach supports only dynamic architectures in isolated systems (i.e. it is not suitable for an SoS). Falker et al. [41] deal with simulation of SoS architectures and define an environment called MEDEA, an MDE-based system execution environment that models constituent systems for the evaluation and prediction of performance of the entire SoS. They adopt a platform-independent modeling language (implemented above GraphML), which supports the modeling of interfaces, behavior and workload in a manner independently of any intended execution platform. The code is generated using the Eclipse Graphic Modeling Environment (GME) code generation interpreter that transforms models into executable code. MEDEA works on SoS evolution, dealing with performance analysis when a new constituent is added to the SoS. However, no other details are provided about other possible changes in the SoS architectures. Moreover, it is important to observe that workload models comprise CPU, memory, and I/O issues. The authors deal with hardware issues, but do not deal specifically with software architectures. Xia et al. [23] report a model-driven approach that transforms the system architecture models described in Simulink into executable models. Their approach focuses on technical aspects of SoS, including the measurement of nonfunctional properties, such as feasibility and efficiency. However, dynamic architecture is not mentioned. Hence, what is still required is an approach that combines the advantages of simulation and the formalism of a suitable ADL for representing SoS, while providing dynamic architecture reconfiguration. Our approach for the simulation of SoS dynamic software architectures is presented in the next section. 3. DYNAMIC-SOS APPROACH Dynamic-SoS is a model-based approach to automatically create SoS simulations with dynamic reconfiguration. To support the dynamic reconfiguration, we defined a set of four dynamic reconfiguration operators: addition, deletion, replacement and reconfiguration. Our approach uses an SosADL to DEVS model transformation (SosADL2DEVS) that automatically generates simulation models from SoS software architecture specifications, based on an approach called ASAS [29]. In short, ASAS (Approach to Support Simulation of SmArt Systems [29]) maps SosADL and DEVS models to preserve the architectural descriptions and monitor SoS behaviors at runtime [29]. As shown in Fig. 1, ASAS uses an SosADL model as input to an Xtend script that constructs a model transformer. A functional code written in DEVS is generated as output, establishing an SosADL2DEVS transformation. Broadly speaking, the concepts of System and Mediator in SosADL are transformed into Atomic Models in DEVS. Behaviors are constructed as labeled state machines in DEVS, which configures the constituents operations. Coalitions become coupled models made up of the constituents and their couplings. Connections and gates become ports, and data types and functions are mapped, respectively, to data types and functions in DEVS [29]. However, in this study [29], the authors did not detail how dynamic reconfiguration can be implemented in SoS architectures and how to automatically generate SoS simulation models with support for dynamic architectures. Figure 1. View largeDownload slide A transformation approach to map SosADL models into DEVS simulation models [5]. Figure 1. View largeDownload slide A transformation approach to map SosADL models into DEVS simulation models [5]. In this article, we specifically present Dynamic-SoS, which was established by adding the generation and monitoring of dynamic architecture for that SosADL2DEVS transformation, as depicted in Fig. 2. Moreover, we established the following activities to use Dynamic-SoS: Figure 2. View largeDownload slide Dynamic-SoS approach. Figure 2. View largeDownload slide Dynamic-SoS approach. Activity 1 (A1). SoS architectures are specified by means of coalitions, which express the policies and define bindings among constituents. Duties are obligations to be performed by the gates of the mediator in the interface with a constituent. A coalition may involve many constituents, or exactly one constituent and multiple mediators. An SoS software architecture results from the selection, at runtime, of possible constituent systems that may participate in the SoS [8]. In our case, architecture concretion is performed at design time, using a method defined by Guessi et al. [42]. Considering a set of constituents, mediators are selected for intermediating the communication among constituents, establishing the initial coalition to be transformed, and generating the initial architectural arrangement for the simulation execution. Activity 2 (A2). Execution of the model transformation on the concrete model (in SosADL) to automatically produce a DEVS simulation code with support for the dynamic reconfiguration of an SoS architecture. Activity 3 (A3). Deployment, i.e. the process of managing files of the atomic and coupled models obtained as an outcome of the transformation, deploying them in the specific packages/directories of the project to be simulated in MS4ME (an environment for modeling and simulation of systems represented in DEVSNL); Activity 4 (A4). Simulation execution that consists of launching the simulation. Activity 5 (A5). Monitoring architectural reconfiguration using the dynamic reconfiguration operators (presented further in Section 3.1), comprising the observation of the SoS dynamics at runtime, and registering the execution traces in log files for posterior analysis. The remaining of this section is organized as follows: Section 3.1 presents the dynamic reconfiguration operators used in A5, Section 3.2 presents our approach to support the dynamic reconfiguration operators in simulation, Section 3.3 presents our approach to derive simulation models with dynamic architecture support through the architectural model. 3.1. Dynamic reconfiguration operations We established a set of dynamic reconfiguration operations based on the canonical set of changes proposed by Cavalcante et al. [39], as shown in Fig. 3. Cavalcante et al. observed single systems may have their architectures modified at runtime due to the creation of a new component, removal of a component, connection of a component that was created (attachment) and removal of a component for its deletion (detachment). For SoS software architectures, we reviewed such operators and defined four canonical operators to achieve dynamics in such architectures. We refer to them as canonical because any architectural change could be expressed using a single operator or a combination of more than one of them. In our approach, dynamic reconfiguration in an SoS software architecture is based on constituent addition (corresponding to creation and connection in [39]), constituent deletion (disconnection and remotion in [39]), constituent replacement (which is not common in single systems but useful and recurrent in SoS, and consists of a deletion and an addition) and architecture reorganization (which is not common for single systems as well, but it is common for SoS, as different architectural configurations can deliver more efficient behaviors). Changes in an SoS software architecture are realized as a systematic procedure composed of well-defined steps, explained as follows. Figure 3. View largeDownload slide Set of canonical operations for dynamic architectures of single systems and SoS. Figure 3. View largeDownload slide Set of canonical operations for dynamic architectures of single systems and SoS. 3.1.1. Constituent addition When using the constituent addition operator, a new constituent is created and added to the SoS architecture. The new constituent is linked to one of the constituents that already exist in the SoS architecture. The following steps are performed, as also shown in Fig. 4: Figure 4. View largeDownload slide Process for addition of a constituent in a simulation of SoS software architecture. Figure 4. View largeDownload slide Process for addition of a constituent in a simulation of SoS software architecture. Step 1: A request to add a particular constituent occurs (in this case the C3). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: A constituent (C3 in Scene 2) is initiated and added. Step 3: Other constituent(s) that will connect with C3 is (are) selected (in this case, the C2, Scene 3). Step 4: An appropriate mediator is created and added (in this case, the M2, Scene 4). Step 5: Necessary connections to connect C3 to C2 being mediated by M2 are established, culminating in the new functional architectural configuration for such an SoS (as shown in Scene 5). 3.1.2. Constituent deletion This operator is performed on a specific constituent to remove it from the SoS architecture. For that, the set of connection established with this constituent and also the mediators are removed. After that, the architecture is reorganized so that SoS remains in operation. The following steps are performed, as shown in Fig. 5: Figure 5. View largeDownload slide Process for deletion of constituent in simulation of an SoS software architecture. Figure 5. View largeDownload slide Process for deletion of constituent in simulation of an SoS software architecture. Step 1: A request to remove a particular constituent is performed (in this case, the C2). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: Constituent C2 is selected to be removed (as showed in Scene 2). Step 3: Connections established via mediators with C2 are selected, and they and C2 are removed (in this case, M1 and M2, Scene 3). Step 4: Other constituents that established connections with C2 are selected (in this case, C1 and C3, Scene 4). Step 5: An appropriate mediator is created and added (in this case, the M3, Scene 5). Step 6: Connections are added to link C1 to C3. They are mediated by M3, created in the last step (as shown in Scene 6). 3.1.3. Constituent replacement This operator is performed as a concatenation of both deletion and addition operators. In the replacement operation, removal of the constituent to be substituted is carried out, followed by addition of the new constituent. The following steps are performed, as shown in Fig. 6: Figure 6. View largeDownload slide Process for replacement of constituent in the simulation of an SoS. Figure 6. View largeDownload slide Process for replacement of constituent in the simulation of an SoS. Step 1: A request to replace a particular constituent is performed (in this case, the C1 will be replaced by C3). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: The constituent C1 is selected to be replaced (as shown in Scene 2). Step 3: The mediated connections with C1 are selected, and they and C1 are removed (in this case, the M1, Scene 3). Step 4: Other constituents that made connections with C1 are selected (in this case, the C2, Scene 3). Step 5: Constituent C3 is initiated and added (as shown in Scene 4). Step 6: An appropriate mediator is created and added (in this case, the M3, Scene 5). Step 7: Connections are established and added to link C3 to C2 being mediated by M3 (as shown in Scene 6). 3.1.4. Architecture reorganization Architectural reorganization process consists of the complete dissolution of a architectural configuration, and re-establishment of new connections among the constituents, leading to a new SoS operational state, as depicted in Fig. 7. In this process, all connections and mediators are removed. After that, arbitrary choices of constituents are made in the SoS architecture (a random process) to establish connections among constituents. This process is repeated until all elements are connected resulting in an architectural configuration that is divergent from the original one. Figure 7. View largeDownload slide Process for reorganization of architecture in the simulation of an SoS software architecture. Figure 7. View largeDownload slide Process for reorganization of architecture in the simulation of an SoS software architecture. 3.2. Dynamic reconfiguration controller Dynamic-SoS is a programmed exogenous reconfiguration approach [39]. It means an entity termed as Dynamic Reconfiguration Controller (DRC) is responsible for managing every architectural change that occurs in the whole structure. DRC is an artificial architectural element that has control over all elements of the software architecture and controls such changes. DRC is added to the simulation to support the user in conducting architectural changes at runtime through the dynamic reconfiguration operators. Figure 8 presents the state machine of DRC. From the DEVS simulation model perspective, the DRC is an atomic model, whose function is to execute the four dynamic reconfiguration operators while maintaining properties of the initial architecture configuration. Figure 8. View largeDownload slide State machine implemented in DEVS to materialize the four canonical reconfiguration operators performed by the Dynamic Reconfiguration Controller. Figure 8. View largeDownload slide State machine implemented in DEVS to materialize the four canonical reconfiguration operators performed by the Dynamic Reconfiguration Controller. For the addition of a constituent to the simulation, it is necessary to send a signal to the DRC. When an addition is invoked by the DRC, mediators are also created to establish the communication between existing constituents and the new one being added to the SoS. Stimuli generators also can be added during this process to feed the new constituent with the data necessary to trigger its interaction within the SoS simulation. For the removal, a signal is sent to the constituent to be removed. As a response, this constituent sends a reference of its own simulation object to the DRC, enabling direct access so that it can be removed. Mediators and connections that communicate with it are also removed. If necessary, new connections and mediators are added to re-establish the path inside the SoS architecture that enable the communication with other constituents that communicated with the constituent removed. The replacement of a constituent involves both a removal and an addition. In turn, for the reorganization of the architecture, a signal is sent to DRC, which removes all connections and mediators among the constituents. After that, DRC creates new connections and mediators among constituents to raise a new functional architectural configuration. For architectural reorganization, it is necessary to send a signal to DRC. Once the operator has been invoked, DRC removes all mediators and connections from the simulation and begins to choose constituents in a random way and will add them to the architecture to generate a new architectural configuration. 3.3. Adding support of dynamic reconfiguration through a model transformation All SosADL elements are mapped to DEVS to create a functional simulation. Transformation rules automatically create DRC from the concrete SosADL architecture and add it in the simulation model. This controller holds and makes available to the user the four dynamic reconfiguration operators, presented in Section 3.1. The model transformation generates three main elements related to the dynamic architecture of the target simulation model, which are DRC: As presented in Section 3.2, it consists of an atomic model that manages all changes in the simulation, as shown in Fig. 9. For that, it manages connections and mediators among constituents, so that the new arrangements remain consistent with the original architecture. Identification flags: In DEVS, there is no distinction between constituent systems and mediators, all of which are transformed into atomic models. However, this differentiation is necessary to maintain the functional architecture after running a dynamic reconfiguration operator. To artificially bring that to DEVS, we added two identification flags to the atomic models: one to check if the system is a mediator or not (a binary variable), and another that is the constituent type name, such as sensor, transmitter or gateway. Connections of all constituents with the DRC in the coupled model: This is necessary to enable the controller to communicate with all constituents and to remove some of them, if necessary. Figure 9. View largeDownload slide An illustration of the relation between Dynamic Reconfiguration Controller (DRC) and constituents being simulated. Figure 9. View largeDownload slide An illustration of the relation between Dynamic Reconfiguration Controller (DRC) and constituents being simulated. Listing 1 shows an excerpt of code of the model transformation.9 The shown method, specified in Xtend, adds dynamic reconfiguration support for all existing elements of the simulation. The reconfiguration support is added after the compilation of the SosADL models. All elements of the concrete architecture in SosADL are iterated, and before creating each compiled file, each element receives some code snippets referring to the communication with DRC, the identification flags, and the connections that support the controller operations in the simulation model. If the SosADL architectural element is a mediator or system, it will be handled in a similar way. If the input for the model transformation is an architecture, all required bindings will be added. In Listing 1, Line 2 shows the transformation code that checks whether sfile, which is the model being compiled, is a system or a mediator. If it is one between both options, the method performs the procedures in Lines 4–8, where Line 4 adds an external transition so that the model can receive the signal to remove it from the simulation, Line 6 adds output transitions so that the model can send its simulation reference to the controller to request its removal, and in Line 8, its identification flags. Otherwise, if the element being analyzed is an architecture, all necessary associations will be added to the coupled model (Lines 10–16). Next, we present the evaluation of our approach and results as well. Listing 1 A transformation excerpt that supports generation of DEVS simulation of SoS software architecture with support to dynamic reconfiguration. 4. EVALUATION In order to evaluate whether our approach successfully simulates SoS dynamic architectures, we conducted case studies in three distinct domains: Flood Monitoring SoS, Smart Building and Space SoS. For the planning of our case study, an evaluation protocol was constructed with respect to the following elements: Method: Executing architectural changes using all dynamic reconfiguration operators. In all, 60 additions, 40 removals, 30 replacements of constituents, and 20 architectural reorganizations, were made, totaling 150 architectural changes. Research Question: Are the architectural changes successful, giving rise to new SoS coalitions in a valid operational state? Rationale. This research question evaluates whether the simulation generated by the model transformation successfully supports the realization of the dynamic reconfiguration operators, showing that DRC was able to generate a new functional architectural configuration at runtime. Metric. Percentage of successful changes in the architecture configuration during simulation, i.e. the proportion of reconfigurations that leads the SoS to a new valid operational state and a corresponding coalition. Conduction of our case study was based on five activities introduced in Section 3, as shown in a summary in video.10 For reader convenience, all models used in each case study and full table with results are also externally available.11 The case study was conducted as follows: Specification of the SoS architecture and its constituents using SosADL (A1). Execution of the model transformation, generating correspondent DEVS models from the initial architecture configuration (A2). Definition of a set of dynamic reconfiguration operators to be sequentially applied to the architecture. Definition of a dataset to be sent to the constituents during simulation. Deployment of DEVS models in the MS4ME environment (A3). Simulation starts on the deployed DEVS models (A4). Simulation of the current architecture configuration. Use of predefined dataset. Registration of execution trace in log file (A5). Log file checking to verify and register if the operator execution has successfully generated a functional architecture configuration (A5). Checking if there is another operator in the set, perform it, and return to item 7. Otherwise, finish the simulation (A5). 4.1. Case 1: FMSoS A Flood Monitoring SoS (FMSoS) is part of a smart city. Such SoS is responsible for monitoring rivers that cross urban areas and notifying the population about potential floods that can quickly occur, causing huge damage and risk for population [36]. FMSoS is concerned with one specific mission: Emitting flood alerts to public authorities that can implement strategies and tactics to protect the population. FMSoS is a collaborative SoS with no central authority that orchestrates the constituents functionalities to accomplish missions. The FMSoS is deployed along the river12 and its sensors are spread on the riverbank’s edges with regular distance among them, and mediators are installed between successive pairs of sensors at pre-established distances. Data collected by sensors are transmitted to the gateway. Additionally, drones fly over the river and return to their bases to recharge and communicate flood threat alerts. In parallel, people walking close to the river can also contribute by communicating water level increases through a crowdsensing mechanism supported by mobile apps. In case of flood, gateways transmit alarms to public authorities, which take decisions to protect the population. It is important to remark that the types of constituents to compose such SoS were selected from a real scenario implemented in the city of São Carlos, Brazil. The SoS, which was originally composed of smart sensors, was enriched with other constituents (crowdsourcing systems and drones). Such novel constituents were also predicted in the initial specification of the FMSoS project carried out by a research team in Brazil, as it can be checked in their website.13 Such an SoS is created with five types of constituents, as shown in Fig. 10 [36]: Smart sensors: cyber-physical systems that monitor flood occurrences in urban areas, being located on riverbank edges. Gateways: which gather data from constituents and share them with other systems. Crowdsourcing systems: mobile applications used by citizens for the real-time communication of water levels. Drones: unmanned aerial vehicles (UAV) used to complement smart sensors by monitoring the river water level while they fly over a river, transmitting images if some change in the water level occurs. Drone bases: fixed bases from where drones depart, and return to battery recharging, data transmission, repair and storage. Figure 10. View largeDownload slide A Flood Monitoring System-of-System (FMSoS) architecture [36]. Figure 10. View largeDownload slide A Flood Monitoring System-of-System (FMSoS) architecture [36]. FMSoS exhibits the following characteristics [1, 8]14: Operational independence of the constituents: Constituents are not exclusively dedicated to an SoS, i.e. operations of the constituents are often used outside the SoS context. For instance, a drone being used by the FMSoS can be reallocated to transmit images related to plantation areas. Similarly, crowdsourcing systems are not also full-time part of the SoS, joining the SoS when a threat motivates people to communicate an imminent flood. Managerial independence of constituents: A diversity of stakeholders and enterprises might independently own, deliver, and manage different constituents that compose FMSoS. Moreover, each constituent has its own management strategy for transmission and energy consumption and will act under the authority of different city councils. Distribution: All constituents rely on a communication network that supports interoperability among them. Evolutionary Development: FMSoS may evolve as a consequence of changes to its environment, its mission or its constituents. Emergent behavior: Flood alerts are a result of the interoperability among involved constituents. One isolated constituent could not reliably deliver a flood alert by itself. For instance, if only one sensor, crowdsourcing system or drone performs its activities in an urban area, it may not be able to notify of a potential flood in time. Hence, a genuine flood alert arises from the interoperability among a diversity of constituents working in cooperation, spread along the riverbank. For this case study, we explain how Dynamic-SoS can support simulations of dynamic software architectures and is able to simulate changes in the architectural configuration at runtime. Data Preparation: To simulate the architecture, we used data collected by the sensors that are under the supervision of a Brazilian entity responsible for monitoring natural disasters (Brazilian Center for Monitoring and Warnings of Natural Disasters—CEMADEN) [43]. These data were parsed and stored in a text file. The input of these data triggers the constituents operation and their interoperability. After the data reach gateway, data received are processed. The outcome varies between positive or negative flood alerts. We also collected these data to analyze results. We carefully chose a data sample collected by sensors deployed along an actual river and selected data collected on a specific day (23 November 2015). This day was important because a real flood occurred in the place where the sensors are located. This enabled us to establish whether or not our simulation can deal with a diversity of situations. Data used were collected every five minutes by the sensors. We used a dataset with 1 920 samples, derived from drone, sensors and crowdsourcing data. We then created a dataset corresponding to the data. 4.1.1. Case study conduction The conduction of this case study was based on systematically performing the previously defined steps. We specified an SoS architecture composed of four sensors, one gateway, four drones, two drone bases, without a crowdsourcing system and one crowdsourcing system gateway (Activity A1, previously presented in Section 3). After defining concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). We prepared the dataset to be sent to the constituents during simulation. After that, we deployed both dataset and simulation models (A3) generated from activity A2 in the MS4ME simulation environment and executed the simulation, performing the set of predefined reconfigurations (A4). We used the entire defined dataset, recording the execution trace in log files. We analyzed log files to verify and register that if the operator execution has successfully generated functional architecture configurations in all cases (A5). 4.1.2. Case study results Simulation execution took about 5 h and 20 min. This simulation was executed on an Intel Core i7-5500U x64, 8GB RAM, 1TB HD, running Ubuntu 16.04.3 LTS 64bits. Figure 11 presents results of the simulation execution. It shows the number of changes performed in the SoS architecture (on the x-axis) by number of constituents that compose such SoS along changes are performed (on the y-axis), and point color represents the change performed in this architecture. Table 1 shows excerpts of data collected during the simulation execution. Figure 11. View largeDownload slide Results of simulation execution. Figure 11. View largeDownload slide Results of simulation execution. Table 1. A sample of changes performed in FMSoS architecture. # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes Table 1. A sample of changes performed in FMSoS architecture. # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes Table 1 presents a sample of collected data of the 150 architectural configurations. These data contains sequential number of the architecture configuration, change performed on architecture, amount of each constituent type, and if the change was successfully executed (Yes/No), i.e. if the change was successfully performed and the resulted architecture configuration is functional. The column Was successful? in full table version is ‘Yes’ in 100% of architectural configuration. With these data, we verified DRC was able to execute all four dynamic reconfiguration operators, successfully generating functional architectures. Hence, we can conclude our approach was able to generate simulation models that successfully support dynamic reconfiguration, being able to evaluate the behavior of FMSoS. 4.2. Case 2: smart building In the context of smart cities, smart buildings provide important services to their residents and visitors, such as energy savings by light control by sensors, and fire alarms in case they happen. Dynamic-SoS approach was also evaluated using a Smart Building SoS (SBS), as specified by Gassara et al. [44]. Such SoS is an important instance of problems addressed by Dynamic-SoS, in particular because such SoS is composed of constituents that are, themselves, other entire SoS. Such Smart Building is composed of three other SoS: Fire System, Lighting System and Room. In addition, SBS has a Smart Building Control Unity (SBCU), which is responsible for managing constituent systems of the building. Figure 12 exemplifies its architecture. Figure 12. View largeDownload slide A representation of a Smart Building SoS. Figure 12. View largeDownload slide A representation of a Smart Building SoS. Fire System is an SoS responsible for the control of fire alarm in smart building public areas and consists of Fire System Control Unities (FSCU): They are constituent systems that manage the Fire System receiving sensor data and, if necessary, triggering alarms and sprinklers in the area where fire was detected. Once fire is detected, FSCU informs SBCU about it. Smoke Detectors: They detect the presence of smoke and sends a signal to FSCU. Smoke Detector (an Ionization Smoke Detector was used) opens to receive air to assess the presence of smoke. Once smoke is detected, such signal is sent to the fire alarm. Heat Detectors: Temperature sensors that checks the ambient temperature and once it is higher than 58°C (136.4°F) it emits a signal to the fire sprinkler. Fire Sprinklers: Systems that, once triggered, fires water for the elimination of fire outbreaks. Fire Alarms: Systems that, once triggered, triggers audible alerts signaling that there is a fire in the Smart Building. Lighting System is an SoS responsible for lighting the public areas of the Smart Building and consists of Lighting System Control Unities (LSCU): They manage the Lighting System, receiving sensor data and, when necessary, turning lamps on. Light Sensors: They convert the energy of light (photons), visible or infrared, into an electrical signal (electrons). They capture environment light measured and sends such value to the sensor that covers area that should receive light. Presence Sensors: Devices that detect presence in an environment and sends along with the area to which sensor belongs. Lamps: Smart lamps that can be digitally controlled and can be turned on / off and have their intensity remotely controlled. Room consists of private environments, such as apartments, offices, stores and more. Room can contain elements already mentioned as Light Sensors, Presence Sensor, Lamp, Smoke Detector and Fire Alarm, besides having Room Control Unities (RCU): Systems that manages the room to which it is inserted and communicates with SBCU. RCU controls temperature and room lamps in addition to controlling the internal fire system and receiving/sending fire alerts to SBCU. Thermometers: Temperature sensors that collects the ambient temperature and sends it to RCU. Air Conditioners: Devices that cool environment and is triggered when the temperature is higher than a stipulated value and there is presence in the environment. Smart Building presents three main missions: fire contro, light management and air conditioning. To perform the fire control mission, Smart Building has the Fire System, which uses smoke sensors and heat sensors to detect a fire and notify FSCU. Fire System uses FSCU to trigger alarm to inform people about fire occurrence and an eminent need to evacuate the building, Fire Sprinklers try to put out the fire and notifies SBCU the fire occurrence. Rooms also may have sensors, alarms and sprinklers to assist Smart Building in the accomplishing of the fire control mission. The light management mission is accomplished through the interoperation of light sensors, presence sensors, smart lamps and LSCU. LSCU receives data from sensors and, if necessary, properly activate smart lamps at a suitable intensity. Rooms also have presence sensors and lamps to the internal lighting. The air conditioning is made internally in a room through thermometers, presence sensors and, air conditioners to keep the air conditioner on only if necessary. Smart Building also exhibits the following characteristics of a SoS [1, 8]: Operational independence of the constituents: Internal constituents of a Room are not exclusively dedicated to the Intelligent Building, since they may be performing internal missions and become unavailable to the Smart Building. Hence, the operational independence of constituents is preserved. Managerial independence of constituents: A diversity of stakeholders and companies can have Rooms in the Smart Building, each Room has its internal policy for internal composition and data availability for the Smart Building. Distribution: Smart Building needs a network to allow communication with its constituent systems to achieve its missions due to the interoperability constituent. Evolutionary Development: A Room may change its internal composition and make available new functionalities to the Smart Building to contribute to the Smart Building achieve new missions or improve the existing mission, consequently contributing to Smart Building evolution. Emergent behavior: For fire control, Smart Building needs that Rooms and Fire Systems notice SBCU that is having a fire in the building to SBCU sent an alarm for all Rooms and areas and sent an alert to firefighters. Smart Building also requires that Light System and Rooms interoperate to manage the lighting and energy consumption of the building. Hence, the entire Smart Building operation to accomplish pre-established missions are only possible due to behaviors that emergent from the interoperability of constituent systems. Data Preparation: To simulate a Smart Building, we built a realistic dataset to feed the simulation. Generated dataset was composed of data that represent 10 days. To stimulate Light Sensors, we used a type of data known as Lux (lx), which is the total luminous flux incident on a surface per unit area (illuminance). Such data were generated in a range between 0.1 lx (at night) and 10 000 lx (in broad daylight). The data received from Light Sensors by the BCU are used to turn external lamps on if the illumination is less than 100. To feed Presence Sensors, data were randomly generated between 10 and 60 presences per sensor per day. This data was used by BCU to switch lamps on in the Presence Sensor area. Data used to stimulate Smoke Sensors consisted of binary values (one, for smoke detected; and zero, for non-detected smoke), and 10 fires were chosen in a random area. This data was sent to an FSCU or RCU. If the data value was 1, the alarm was triggered and fire sprinklers were activated in the detected smoke area. Finally, data generated for thermometers were generated between 10°C (30°F) and 30°C (86°F). This data was used by RCU to turn the air conditioners on if there is a presence in the area and temperature is higher than a given value. 4.2.1. Case study conduction Conduction of the SBS case study was also based on the steps defined for Dynamic-SoS approach, being systematically followed. An SoS architecture was specified using SosADL for Smart Building (A1), involving one Fire System, one Lighting System, 20 Rooms and three Building Control Unities. Each Room contains two Thermometers, two Air Conditioners, one Presence Sensor, one Lamp, one Smoke Detector, one Fire Sprinkler, one Alarm and one Room Control Unity. Fire System is composed of 25 Smoke Detectors, five Heat Detectors, 10 Fire Sprinklers, 25 Fire Alarms, and three Fire System Control Unities. Lighting System is composed of 20 Presence Sensors, 40 Light Sensors, and 20 Lamps. Altogether, the initial architecture configuration contains 40 Thermometers (T), 40 Air Conditioners (AC), 20 Room Control Unities (RCU), 40 Light Sensors (LS), 40 Presence Sensors (PS), 40 Lamps (L), two (2) Lighting System Control Unities (LSCU), 45 Smoke Detectors (SD), five (5) Heat Detectors (HD), 30 Fire Sprinklers (FS), 45 Fire Alarms (FA), three (3) Fire System Control Unities (FSCU) and, three (3) Building Control Unities (BCU). After defining the concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). The dataset to stimulate constituents during simulation was also conceived. After that, the transformation produced simulation models in DEVS, which were deployed with the dataset in MS4ME simulation environment (A3). Simulation was executed for the first architectural configuration, performing a set with 60 additions, 40 removals and 30 replacement of constituents, as well as 20 architectural reorganizations, totaling 150 architectural changes. Removal operators were also applied to Control Units to check whether any available Control Units would substitute the removed one (A4). The entire dataset was executed. The execution traces were recorded in log files for analysis purposes. Log files were analyzed to verify whether the operators execution successfully generated functional architecture configurations (A5). 4.2.2. Case study results Simulation of SBS was performed in an Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, two TB HD, in a server running on Ubuntu Server 16.04.3 LTS and took about 9 hours and 40 minutes. Table 2 presents a sample of collected data of 150 architectural configurations. These data contain sequential number of the architecture configuration, change performed on the architecture, number of each constituent type, and if the change was successfully executed (Yes/No), i.e. if it was successfully performed and resulted an architecture configuration in a valid operational state. Column Was successful? in full table version is ‘Yes’ in 100% of architectural configurations. Thus, we verified that DRC was able to execute four dynamic reconfiguration operators on all types of constituents and activating redundant elements (Control Units) when a constituent was removed, thus maintaining the availability of the internal SoS to the Smart Building (Fire System, Lighting System, and Rooms), and sustaining the operation of Smart Building as long as at least one Control Unit remained in the architecture. Table 2. A sample of changes performed in Smart Building architecture. # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y Table 2. A sample of changes performed in Smart Building architecture. # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y 4.3. Case 3: space SoS We also evaluated our approach using a Space SoS as specified by Graciano Neto et al. [45] based on a real system called Environmental Data Collection System (SBCDA, in Portuguese). This Space SoS is operated and managed by the Brazilian National Institute for Space Research (INPE, in Portuguese). Space SoS is responsible to perform two concurrent missions: environmental data collection and image capture. To accomplish both missions, as shown in Figure 13, Space SoS is composed of Satellites: Artificial objects orbiting the Earth. Satellites are composed of two main part: (i) platform part, which includes solar panels, batteries, and reaction control system (this part is essential to keep the satellite in operation); and (ii) payload part, which includes sensors and infrared cameras used to accomplish the SoS missions. Three satellites comprise the SBCDA: two dedicated to data collection (SCD1 and SCD2) and one for remote sensing (CBERS-4). These satellites collect data from Data Collection Platforms (DCP) and capture images from the Amazon rainforest. Mission Center: It involves multiple information system constituents that are responsible for receiving records, as well as the processing, storage and distribution of images and environmental/meteorological data for users. Command and Control Center (C2): Located in São José dos Campos (São Paulo, Brazil, point B in Figure 13). C2 is responsible for managing the satellites throughout their lifetime so that they properly maintain their operation. Ground Station: Located in Cuiabá (Mato Grosso, Brazil, Point A in Figure 13), it is responsible for sending telecommands to satellites and receiving telemetry from satellite. It also temporarily stores payload data and satellites tracking. Data Collection Platforms (DCP), which are located along the Brazilian territory. SBCDA has four types of DCP: meteorological, hydrometeorological, agrometeorological and buoy. DCPs send their collected data to satellites once they are not close enough to directly send their data to the Ground Station. Figure 13. View largeDownload slide Illustration of the Brazilian Space SoS [45]. Figure 13. View largeDownload slide Illustration of the Brazilian Space SoS [45]. The first mission is a data forwarding mission that uses satellites to collect environmental data collected by DCP distributed throughout the Brazilian territory and send them to a Ground Station. The second mission is a business process-oriented mission, as shown in Fig. 14. The business process of the second mission is composed of the following activities, performed at this order [46]: Mission Center requests payload data for Command and Control Center (C2). C2 Center elaborates operation plan (telecommand15 and telemetry16) and schedules their execution. Ground Station schedules the reception of data and configures antenna and rotors. Ground Station establishes links with the Satellite. Ground station sends telecommand. Satellite runs telecommand. Satellite stores and send data packets. Ground Station receives and stores data. Mission Center extracts, manipulates and verifies data. Mission Center distributes payload data to the end-users. Figure 14. View largeDownload slide BPMN diagram illustrating a the image capture mission [46]. Figure 14. View largeDownload slide BPMN diagram illustrating a the image capture mission [46]. Space SoS also exhibits the following inherent SoS characteristics [1, 8]: Operational independence of the constituents: Constituents of the Space SoS are independent systems that contribute to such SoS, but are not exclusive to the aforementioned missions, such as TV signal transmissions or military application. They occasionally contribute to the accomplishment of the SoS missions, but preserving their operational independence. Managerial independence of constituents: DCP may be managed by different independent institutions. Space SoS satellites also are managed by different institutions, such as CBERS-4 that is operated by the Brazilian National Institute for Space Research (INPE) and China National Space Administration (CNSA). Distribution: DCPs are distributed throughout the Brazilian territory, requiring a wireless network for communication with the satellite. Evolutionary Development: Space SoS may evolve due to new resource provided by new satellites, enabling it carries out new functionalities. New PCDs may also contribute to the Space SoS evolution, enabling this SoS to cover a larger area or capture new environmental information. Emergent behavior: Due to geographic distribution, DCPs may be in areas of difficult access. DCPs need satellites to make the data available. Hence, it is only possible to emerge the climatic and environmental condition of the entire country due to an interplay among all constituents involved. Moreover, the image capture mission is only accomplished through the interoperability of satellites, Command and Control Center, and Mission Center to properly send telecommands and receive telemetries with collected image. Data Preparation: To feed the DCP, we used data provided by INPE, which made available data of 249 DCPs from 1 January 2017 to 31 October 2017. To generate the satellite orbits, we created a script to access the satellite data server to pick up coordinates and store them into a file, once a second for 2 days, to build a real orbit. We collected the coordinates from the China-Brazil Earth Resources Satellite 4 (CBERS-4) and Data-Collecting Satellite 1 and 2 (SCD-1 and SCD-2, in Portuguese). 4.3.1. Case study conduction To reinforce the evidence of effectiveness of Dynamic-SoS, this third case was also conducted based on steps previously defined, but in this case study using Space SoS architectural models specified in SosADL. We developed the SoS architecture with one Satellite, 60 meteorological DCPs, five (5) buoyed DCPs, 40 hydrometeorological DCPs, 10 agrometeorological DCPs, one Mission Center, one Command and Control Center and one Ground Station (A1). After defining the concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). DEVS models were deployed together with the dataset in the MS4ME simulation environment (A3). Simulation was executed according to the predefined set of architectural reconfigurations. Execution traces were recorded in log files, as in previous case studies (A4). We analyzed log files to verify whether the reconfigurations were well-succeeded, generating architecture configurations in valid operational states (A5). A set of 60 additions, 40 removals and 30 replacement of constituents, and 20 architectural reorganizations was performed, totaling 150 architectural changes. We split the dataset into 151 parts, one for the initial configuration and 150 for the architectural configuration generated by a dynamic reconfiguration operator. 4.3.2. Case study results The simulation was performed in an Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, two TB HD, in a server running on Ubuntu Server 16.04.3 LTS and took about 21 h and 30 min. Table 3 presents a sample of collected data of the 150 architectural configurations. These data contain a sequential number of the architecture configuration, change performed on architecture, number of each constituent type and a status denoting whether the change was successfully executed (Yes/No), i.e. if the change was successfully performed and resulted a new architecture configuration in a valid operational state. Column Was successful? in full table version is ‘Yes’ in 100% of architectural configuration. Thus, we concluded DRC was able to execute the four dynamic reconfiguration operators in all cases. Table 3. A sample of changes performed in Space SoS architecture. # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y Table 3. A sample of changes performed in Space SoS architecture. # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y 4.4. Triangulation Triangulation is a process by which results obtained in different scenarios of a case study are compared and combined according to a predefined set of parameters to draw conclusions and evidence with more strength. Triangulation is important to increase the precision of empirical research, as it takes different angles toward the studied object and thus providing a broader picture [47]. In this study, the matter of interest is the simulation of SoS dynamic architectures. We intended to observe whether Dynamic-SoS approach was well-succeeded for both (i) automatically providing simulation models that support dynamic reconfigurations, and (ii) supporting the analysis of the impact of such reconfigurations on the SoS architecture, in particular in regard to the sustainability of SoS emergent behaviors. We executed three different studies, involving FMSoS, Smart Building and Space SoS. For all of them, we applied the same set of architectural changes in the same order, and observed their impact on the data transmission rates (intimately aligned with the emergent behaviors provided by the SoS) expressed by the percentage of data that was successfully received in a gateway or that passed by an specific constituent in regards to the total number of data that was provided as stimuli to feed each simulation. Figure 15 shows data collected from simulations. This data presents the percentage of collected data during the case studies (y-axis) and performed operators. These data support us to analyze the SoS availability and performance to fulfill its missions during its execution and predict how changes in the architecture of SoS will impact its performance, allowing to anticipate eventual problems. Figure 15. View largeDownload slide Chart showing the rate of receipt of data throughout the case studies. Figure 15. View largeDownload slide Chart showing the rate of receipt of data throughout the case studies. Additionally, we can analyze the impact of executing operators in the architecture. Figure 16 shows the impact of addition operator on receiving data, i.e. the data reception rate before the operator performance minus the data reception rate per execution of the operator (y-axis) and shows in which constituent type was performed the operator. This chart allows us to analyze how the increase in the number of constituents affects data transmission. In all case studies, the addition of sensors/collectors decreased the data received, while the addition of constituents that receive these data increases the rate of data collection. This helps us to draw a trade-off on the acquisition of new constituents, making it possible, for instance, to conclude that adding a second gateway in the FMSoS increases the data reception rate by 20%, which is the same gain that happens when adding a second satellite to the Space SoS. Figure 16. View largeDownload slide Chart presenting the impact of the addition of a constituent in the simulation. Figure 16. View largeDownload slide Chart presenting the impact of the addition of a constituent in the simulation. Then, after analyzing and triangulating results obtained from three different independent studies, we can answer the raised research question for the case studies: Are the architectural changes successful, giving rise to new SoS coalitions in a valid operational state? The answer is Yes. In 100% of the cases in the three studies, Dynamic-SoS was successful to support dynamic reconfigurations in SoS software architectures, leading the architecture to valid operational states in all obtained coalitions. 4.5. Threats to validity We identify some threats to validity for our study: scale, correctness of the transformation rules, selection of dataset and selection of changes set. Scale is addressed through an increase in the number of constituents during the study, until reaching a couple hundred of systems being simulated. As a side effect, this hampers data visualization and processing, as a large number of constituents is difficult to visualize in a simulation and a more powerful processor would be required to execute simulation of a larger SoS. However, these problems were reduced by saving results in external files to be further properly analyzed. Regarding transformation correctness, we established correspondences between entities in SosADL and DEVS, and we performed a manual inspection in the models to alleviate this threat, assessing whether all entities in the SosADL model were correctly mapped into DEVS model, thus ensuring that the behavior of the DEVS simulation model corresponds to the specification of the SosADL model. After applying this procedure in all models, we verified that all models were correctly generated, pointing for a high precision and correctness of the SosADL2DEVS transformation rules. Selection of data might present a possible bias. However, in FMSoS, the day considered (i.e. 23 November 2015) has samples of any type of input the FMSoS can receive during an entire year. In particular, the day started dry, and the river exhibited an average water level (90 cm). Later, an intense rain made the water level reach 600 cm. The day were finished with the water level reduced to 100 cm. Hence, the sample exhibited a large variety of data, besides the occurrence of intense rains that enabled us to analyze the effectiveness of the simulation to reproduce the alarm triggering. For the simulation of Smart Building, we artificially constructed our dataset, which can lead to bias. To minimize this possible effect, we randomly created a diversity of events, such as presence and fire, increasing the diversity of scenarios being represented, and reducing bias by introducing casualty in the data produced and used to stimulate constituents. Regarding Space SoS, we obtained real data for the data collection platforms provided by INPE and collected data from the orbits of the satellites that are actually part of the SBCDA. Hence, bias was reduced by using real data, which are currently adopted by the real SBCDA during its operation. The set of reconfiguration operators and order in which changes occur were the last threat we identified. Different changes could be performed, substituting or eliminating constituents, or even reorganizing SoS configuration. However, the purpose of this study was to check whether our approach could successfully (i) support automatic generation of functional dynamic simulation models for SoS software architectures, (ii) reproduce effects of the reconfigurations in the SoS architecture, (ii) support analysis of the effect of different architectural configurations in the generation of new coalitions in valid operational states. Considering our approach was well-succeeded in all these endeavors, this threat does not influence our results. 4.6. Discussion In this study, we exercised the dynamics of SoS software architectures through a set of dynamic reconfiguration operators. We systematically followed well-defined steps prescribed in Dynamic-SoS approach, modeling three SoS from three different domains. Combination of high connectivity and ubiquity of current software-intensive systems and increase in the number of systems that can be part of a city, such as traffic systems, cell phones, sensors, radars, autonomous cars, smart buildings and other technologies, will lead to the rise of large-scale SoS consisting of thousands or even millions of constituents. Constituents intended to be part of these SoS have been developed using different technologies, heterogeneous means of communication, different platforms and different levels of complexity ranging from simple objects with sensors, such as those of IoT systems and cyber-physical systems (CPS), reaching complex information systems or other entire SoS (such as a Flood Monitoring SoS, which is an entire SoS, but still a constituent of a smart city SoS). Thus, a sustainable development of such systems requires addressing different granularities with which these systems appear, different technologies and full interoperability between them, while also predicting the impact of inherent dynamics of such systems. The high dynamics of the architecture will inevitably affect performance of the provided service, load of data transferring, possibility of connection and interoperability among different systems, possibly causing failures and demanding recovery strategies. Dynamic-SoS approach provides solutions for this emerging demand, since it is suitable for dealing with several of those concerns regarding the development of real-world SoSs. The simulation models originated by the model transformation enables system engineers to predict, at design-time, the impact of such architectural changes on the entire system, as well as the impact on quality attributes, such as performance, accuracy and efficiency. Such insights can assist SoS engineers to draw strategies to deal with potential failures, predicting scenarios and anticipating solutions, thus improving the quality provided by the services provided by such SoS to the society. In this study, we presented a solution to enable such analysis, focusing on the feasibility of each new architectural arrangement created. However, further extensions are planned to be done in forthcoming steps of this research, including the analysis of multiple quality attributes. With regard to this work, important contributions were brought: Characterization of SoS dynamic architectures operators: Providing dynamic architectures inherently depends on designing each possible change that can be performed on these architectures. Those changes should be well-defined and the final architecture should always deliver a valid operational state. Dynamic reconfiguration operators were previously established for single systems software architectures. However, when considering multiple interoperable systems present in an SoS, there was a gap to be bridged. Dynamic-SoS builds a remarkable contribution on previous advances by providing a robust and canonical set of dynamic changes that can be adopted to represent any change a SoS software architecture can suffer. We state this as a contribution that can be replicated in any context that requires SoS dynamic architectures. Generation of dynamic models from static models: Dynamic-SoS approach also provides a means to automatically derive SoS simulation models from static specification of SoS software architectures with a single initial coalition. This is possible because the dynamic reconfiguration operators are encapsulated in a controller that enables the aforementioned operations over the initial architectural configuration, conducting to other SoS functional architectural configurations, and making use of the underlying simulation mechanisms. A process to include dynamics in SoS software architecture models: By using a model transformation approach, we established a process that encompasses activities necessary to observe the dynamics of SoS via simulations, passing by the SoS software architecture specification step until reaching the assessment of different architectural configurations. Despite the reported advances, challenges still remain. For instance, Table 4 presents data about the maximum number of constituents reached in each simulation and the time to simulate it. Simulations required an average of more than 12 h to execute data feeding, architectural reconfigurations, and simulation execution of no more than 400 constituents. Hence, if a linear relation is established between such variables, simulation of an SoS with 1 million constituents could take more than 3 years, which is unfeasible. In the context of smart cities, New York city and São Paulo are intended to be composed of cell phones, autonomous cars, smart buildings, houses, and hospitals, with different granularities, potentially reaching 50 million constituents, which makes the simulation of such forthcoming cities currently unfeasible (it would take 76 years, following the same rationale). Hence, strategies, such as parallel processing and distributed simulations, combined with a huge computational processing power, should be established to deal with such huge dimensions of real-world forthcoming SoS. Hence, scale for SoS is still an open problem, in particular for simulation domain. Table 4. Comparison between number of constituents and time in different SoS simulations. SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 Table 4. Comparison between number of constituents and time in different SoS simulations. SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 Besides, Dynamic-SoS can be expanded to cover other purposes of study, such as measuring other specific quality attributes, analyzing the threshold or limit of constituents that still maintain the SoS feasible, applying a set of random reconfigurations and study the architecture behavior, and predicting the impact of specific constituents on the entire SoS architecture. Next section brings concluding remarks. 5. FINAL REMARKS SoS architectural design is a challenging task due to diverse architectural configurations a SoS can assume at runtime and the complexity of assessing the impact of such changes still at design time. Dynamic-SoS contributes to this scenario by providing an infrastructure that allows SoS architects to predict, via simulations automatically generated at design-time, the SoS dynamic architectures, besides visualizing the SoS dynamics, and its impact on the SoS associated behavior. We conducted three case studies in three different domains, generating simulation models and analyzing the impact of changes on the functionalities provided by the modeled SoS. Results brought evidences that Dynamic-SoS is a feasible and effective approach to predict SoS behavior, despite the inherent dynamics associated to its architecture. Motivated by these results, our future work involves dealing with real SoS dynamic architectures at runtime (i.e. after SoS deployment), advancing on models@runtime research branch. We intend to draw strategies for the synchronization between coalitions and SoS architectural specification, preserving SoS architectural consistency, avoiding degradation and assuring the quality of this class of systems that has been increasingly applied in several critical, complex application domains. ACKNOWLEDGEMENTS Authors also thank professor Dr Les Foulds (INF/UFG) for the language review. FUNDING The authors thank Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) (Grants: 2014/02244-7, 2017/06195-9 and 2017/17448-5). Footnotes 1 http://www.himss.org/library/interoperability-standards/what-is-interoperability 2 For sake of simplicity, the acronym SoS is used interchangeably to express singular and plural. 3 UML, http://www.uml.org/ 4 SysML, http://sysml.org/ 5 CML, http://www.compass-research.eu/approach.html 6 MS4ME, http://www.ms4systems.com/pages/ms4me.php 7 DoDAF, US Department of Defense Architecture Framework, 2010. 8 Simulink, www.mathworks.com/products/simulink/ 9 Some parts of the code are hidden for the reader convenience. 10 https://vimeo.com/222339631 11 https://goo.gl/iw4exH 12 Credits for the images used to compose the figure: http://goo.gl/TTOlAa, http://goo.gl/QCUAKY, http://goo.gl/a9Y0Dw, https://goo.gl/rFkYJ6, https://goo.gl/8YojYj, https://goo.gl/XyWEZw, https://goo.gl/VpftdV, https://goo.gl/dfMPLl. 13 AGORA research team: http://www.agora.icmc.usp.br/site/components/ 14 Our example scenario also covers constituents heterogeneity, autonomy, and SoS scale, characteristics that are commonly assigned to SoS, as well [3]. 15 Operation remotely sent to satellites requiring them to perform actions, such as, capturing images or opening of the solar panel. 16 Technical name given to the information received from the status of the satellite during its passage over the ground stations. References 1 Maier , M.W. ( 1998 ) Architecting principles for systems-of-systems . Syst. Eng. , 1 , 267 – 284 . Google Scholar Crossref Search ADS 2 Guessi , M. , Graciano Neto , V.V. , Bianchi , T. , Felizardo , K.R. , Oquendo , F. and Nakagawa , E.Y. ( 2015 ) A Systematic Literature Review on the Description of Software Architectures for Systems of Systems. ACM Sympos. Applied Computing (SAC), Salamanca, Spain, 13–17 April, pp. 1433–1440. ACM, New York, NY, USA. 3 Jamshidi , M. ( 2009 ) System of Systems Engineering—Innovations for 21st century Wiley Series in Systems Engineering and Management . Wiley , Hoboken, NJ, USA . 4 Boehm , B. ( 2006 ) A View of 20th and 21st Century Software Engineering. 28th Int. Conf. Software Engineering (ICSE), Shanghai, China, 20–28 May, pp. 12–29. ACM, New York, NY, USA. 5 Graciano Neto , V.V. ( 2017 ) A Model-based Approach Towards the Building of Trustworthy Software-Intensive Systems-of-Systems. 39th Int. Conf. Software Engineering Companion (ICSE-C), Buenos Aires, Argentina, 20–28 May, pp. 425–428. IEEE Press, Piscataway, NJ, USA. 6 Ruscio , D.D. , Malavolta , I. , Pelliccione , P. and Tivoli , M. ( 2016 ) Automatic Generation of Detailed Flight Plans from High-level Mission Descriptions. ACM/IEEE 19th Int. Conf. Model Driven Engineering Languages and Systems, Saint-Malo, France, 02–07 October, pp. 45–55. ACM, New York, NY, USA. 7 Heegaard , P.E. and Schoitsch , E. ( 2015 ) Introduction to the special theme - trustworthy systems of systems . ERCIM News , 2015 , 8 – 9 . 8 Oquendo , F. ( 2016 ) Formally Describing the Software Architecture of Systems-of-Systems with SosADL. 11th IEEE Syst. Syst. Eng. Conf. (SoSE), Kongsberg, Norway, 12–16 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 9 Nakagawa , E.Y. et al. ( 2017 ) Software Architecture and Reference Architecture of Software-Intensive Systems and Systems-of-Systems: Contributions to the State of the Art. 11th Eur. Conf. Software Architecture (ECSA), Canterbury, UK, 11–15 September, pp. 4–11. ACM, New York, NY, USA. 10 Graciano Neto , V.V. , Oquendo , F. and Nakagawa , E.Y. ( 2017 ) Smart Systems-of-Information Systems: Foundations and an Assessment Model for Research Development. In Boscarioli , C. , Araujo , R. and Maciel , R.S.P. (eds.) GranDSI-BR: Big Research Challenges in Information Systems in Brazil (2016-2026) . Brazilian Computer Society , Brazil . 11 de França , B.B.N. and Travassos , G.H. ( 2016 ) Experimentation with dynamic simulation models in software engineering: planning and reporting guidelines . Empir. Softw. Eng. , 21 , 1302 – 1345 . Google Scholar Crossref Search ADS 12 Bogado , V. , Gonnet , S. and Leone , H. ( 2017 ) DEVS-Based Methodological Framework for Multi-quality Attribute Evaluation Using Software Architectures. 2017 XLIII Latin Am. Comput. Conf. (CLEI), Cordoba, Argentina, 4–8 September, pp. 1–10. IEEE, Piscataway, NJ, USA. 13 Zeigler , B.P. , Sarjoughian , H.S. , Duboz , R. and Souli , J.-C. ( 2012 ) Guide to Modeling and Simulation of Systems of Systems . Springer , Berlin, Germany . 14 Seo , C. , Zeigler , B.P. , Coop , R. and Kim , D. ( 2013 ) DEVS Modeling and Simulation Methodology with ms4 me Software Tool. Sympos. Theory of Modeling & Simulation—DEVS Integrative M&S Symposium, San Diego, CA, USA, 12–15 April, pp. 33:1–33:8. Society for Computer Simulation International, San Diego, CA, USA. 15 Lana , C.A. , Souza , N.M. , Delamaro , M.E. , Nakagawa , E.Y. , Oquendo , F. and Maldonado , J.C. ( 2016 ) Systems-of-Systems Development: Initiatives, Trends, and Challenges. XLII Conferencia Latinoamericana de Informática (CLEI), Valparaiso, Chile, 10–14 October, pp. 1–10. IEEE Press, Piscataway, NJ, USA. 16 Bianchi , T. , Santos , D.S. and Felizardo , K.R. ( 2015 ) Quality Attributes of Systems-of-Systems: A Systematic Literature Review. IEEE/ACM 3rd Int. Workshop on Software Engineering for Systems-of-Systems (SESoS), Florence, Italy, 16–24 May, pp. 23–30. IEEE, Piscataway, NJ, USA. 17 Boardman , J. and Sauser , B. ( 2006 ) System of Systems—The Meaning of IEEE/SMC Int. Conf. System of Systems Engineering (SoSE), Los Angeles, CA, USA, 24–26 April, pp. 6–6. IEEE, Piscataway, NJ, USA. 18 IEEE 610-12 ( 1990 ) IEEE Standard Glossary of Software Engineering Terminology . IEEE , Piscataway, NJ, USA . 19 Oquendo , F. ( 2017 ) Software Architecture of Self-organizing Systems-of-Systems for the Internet-of-Things with SosADL. 12th Int. Conf. System of Systems Engineering (SoSE), Waikoloa, HI, USA, 18–21 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 20 Klein , J. and van Vliet , H. ( 2013 ) A Systematic Review of System-of-Systems Architecture Research. 9th Int. ACM Sigsoft Conf. Quality of Software Architectures (QoSA), New York, NY, USA, 17–21 June, pp. 13–22. ACM, New York, NY, USA. 21 Cavalcante , E. , Quilbeuf , J. , Traonouez , L. , Oquendo , F. , Batista , T. and Legay , A. ( 2016 ) Statistical Model Checking of Dynamic Software Architectures. 10th Eur. Conf. Software Architecture (ECSA), Copenhagen, Denmark, 28 November–02 December, pp. 185–200. Springer, Berlin, Germany. 22 Graciano Neto , V.V. , Guessi , M. , Oliveira , L.B.R. , Oquendo , F. and Nakagawa , E.Y. ( 2014 ) Investigating the Model-driven Development for Systems-of-Systems. 2014 Eur. Conf. Software Architecture Workshops (ECSAW), Vienna, Austria, 25–29 August, pp. 22:1–22:8. ACM, New York, NY, USA. 23 Xia , X. , Wu , J. , Liu , C. and Xu , L. ( 2013 ) A Model-Driven Approach for Evaluating System of Systems. Int. Conf. Engineering of Complex Computer Systems (ICECCS), Singapore, 17–19 July, pp. 56–64. IEEE, Piscataway, NJ, USA. 24 Cavalcante , E. , Oquendo , F. and Batista , T.V. ( 2014 ) Architecture-Based Code Generation: From π-ADL Architecture Descriptions to Implementations in the Go Language. 8th Eur. Conf. Software Architecture (ECSA), Vienna, Austria, 25–29 August, pp. 130–145. Springer, Berlin, Germany. 25 Woodcock , J. , Cavalcanti , A. , Fitzgerald , J. , Larsen , P. , Miyazawa , A. and Perry , S. ( 2012 ) Features of cml: A Formal Modelling Language for Systems of Systems. 7th Int. Conf. System of Systems Engineering (SoSE), Genova, Italy, 16–19 July, pp. 1–6. IEEE, Piscataway, NJ, USA. 26 Fitzgerald , J. , Foster , S. , Ingram , C. , Larsen , P.G. and Woodcock , J. ( 2013 ) Model-Based Engineering for Systems of Systems: The Compass Manifesto. Technical Report Manifesto Version 1.0. COMPASS Interest Group, Newcastle, UK. 27 Oquendo , F. ( 2016 ) Software Architecture Challenges and Emerging Research in Software-Intensive Systems-of-Systems. 10th Eur. Conf. Software Architecture (ECSA), Copenhagen, Denmark, 28 November–02 December, pp. 3–21. Springer, Berlin, Germany. 28 Wiederhold , G. ( 1992 ) Mediators in the architecture of future information systems . Computer , 25 , 38 – 49 . Google Scholar Crossref Search ADS 29 Graciano Neto , V.V. , Garcés , L. , Guessi , M. , Paes , C. , Manzano , W. , Oquendo , F. and Nakagawa , E.Y. ( 2018 ) ASAS: An Approach to Support Simulation of Smart Systems. 51st Hawaii Int. Conf. System Sciences (HICSS), Big Island, HI, USA, 2–6 January, pp. 5777–5786. IEEE, Piscataway, NJ, USA. 30 Mittal , S. and Rainey , L. ( 2015 ) Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering. Conf. Summer Computer Simulation (SummerSim), Chicago, IL, USA, 26–29 July, pp. 1–10. Society for Computer Simulation International, San Diego, CA, USA. 31 Nielsen , C.B. , Larsen , P.G. , Fitzgerald , J. , Woodcock , J. and Peleska , J. ( 2015 ) Systems of systems engineering: basic concepts, model-based techniques, and research directions . ACM Comput. Surv. , 48 , 18:1 – 18:41 . Google Scholar Crossref Search ADS 32 Michael , J.B. , Riehle , R. and Shing , M.T. ( 2009 ) The Verification and Validation of Software Architecture for Systems of Systems. 2009 Int. Conf. Systems-of-Systems Engineering (SoSE), Albuquerque, USA, 30 May–3 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 33 Sauser , B. , Boardman , J. and Verma , D. ( 2010 ) Systomics: toward a biology of system of systems . IEEE Trans. Syst. Man Cybern. , 40 , 803 – 814 . Google Scholar Crossref Search ADS 34 Wachholder , D. and Stary , C. ( 2015 ) Enabling Emergent Behavior in Systems-of-Systems through Bigraph-Based Modeling. 10th Int. Conf. Systems of Systems Engineering (SoSE), San Antonio, TX, USA, 17–20 May, pp. 334–339. IEEE, Piscataway, NJ, USA. 35 Michael , J.B. , Drusinsky , D. , Otani , T.W. and Shing , M.-T. ( 2011 ) Verification and validation for trustworthy software systems . IEEE Softw. , 28 , 86 – 92 . Google Scholar Crossref Search ADS 36 Graciano Neto , V.V. , Barros Paes , C.E. , Garcés , L. , Guessi , M. , Manzano , W. , Oquendo , F. and Nakagawa , E.Y. ( 2017 ) Stimuli-SoS: a model-based approach to derive stimuli generators for simulations of systems-of-systems software architectures . J. Braz. Comput. Soc. , 23 , 1 – 22 . Google Scholar Crossref Search ADS 37 Bass , L. , Clements , P. and Kazman , R. ( 2012 ) Software Architecture in Practice . Addison-Wesley Longman Publishing Co., Inc , Boston, MA, USA . 38 ISO/IEC/IEEE 42010:2011 ( 2011 ) ISO/IEC/IEEE Systems and Software Engineering—Architecture Description . IEEE , Piscataway, NJ, USA . 39 Cavalcante , E. , Batista , T.V. and Oquendo , F. ( 2015 ) Supporting Dynamic Software Architectures: From Architectural Description to Implementation. 12th IEEE/IFIP Conf. Software Architecture (WICSA), Montreal, Canada, 4–8 May, pp. 31–40. IEEE, Piscataway, NJ, USA. 40 Sendall , S. and Kozaczynski , W. ( 2003 ) Model transformation: the heart and soul of model-driven software development . IEEE Softw. , 20 , 42 – 45 . Google Scholar Crossref Search ADS 41 Falkner , K. , Szabo , C. , Chiprianov , V. , Puddy , G. , Rieckmann , M. , Fraser , D. and Aston , C. ( 2018 ) Model-driven performance prediction of systems of systems . Softw. Syst. Model. , 17 , 415 – 441 . Google Scholar Crossref Search ADS 42 Guessi , M. , Oquendo , F. and Nakagawa , E.Y. ( 2016 ) Checking the Architectural Feasibility of Systems-of-Systems Using Formal Descriptions. 11th Syst. Syst. Eng. Conf. (SoSE), Kongsberg, Norway, 12–16 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 43 Horita , F.E. , de Albuquerque , J.P. , Degrossi , L.C. , Mendiondo , E.M. and Ueyama , J. ( 2015 ) Development of a spatial decision support system for flood risk management in Brazil that combines volunteered geographic information with wireless sensor networks . Comput. Geosci. , 80 , 84 – 94 . Google Scholar Crossref Search ADS 44 Gassara , A. , Rodriguez , I.B. , Jmaiel , M. and Drira , K. ( 2017 ) A bigraphical multi-scale modeling methodology for system of systems . Comput. Electr. Eng. , 58 , 113 – 125 . Google Scholar Crossref Search ADS 45 Graciano Neto , V.V. , Manzano , W. , Rohling , A.J. , Ferreira , M.G.V. , Volpato , T. and Nakagawa , E.Y. ( 2018 ) Externalizing Patterns for Simulations in Software Engineering of Systems-of-Systems. 33rd Annu. ACM Sympos. Applied Computing (SAC), Pau, France, 09–13 April, pp. 1687–1694. ACM, New York, NY, USA. 46 Graciano Neto , V.V. , Garcés , L. , Paes , C.E.B. , Manzano , W. , Rohling , A.J. , Kassab , M. , Oquendo , F. and Nakagawa , E.Y. ( 2018 ) Evaluation of systems-of-systems behaviors: a simulation-driven and model-based approach . Softw. Pract. Ex. , X , 1 – 38 . Submitted. 47 Runeson , P. and Höst , M. ( 2009 ) Guidelines for conducting and reporting case study research in software engineering . Empir. Softw. Eng. , 14 , 131 – 164 . Google Scholar Crossref Search ADS Author notes Handling editor: George Loukas © The British Computer Society 2019. All rights reserved. For permissions, please e-mail: [email protected] This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model) http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png The Computer Journal Oxford University Press http://www.deepdyve.com/lp/oxford-university-press/dynamic-sos-an-approach-for-the-simulation-of-systems-of-systems-rC04wEyVa1

Loading next page...

References (24)

(2009)
citation_publisher=Wiley, Hoboken, NJ, USA; System of Systems Engineering?Innovations for 21st century Wiley Series in Systems Engineering and Management
(2011)
citation_author=ISO/IEC/IEEE 42010:2011; citation_publisher=IEEE, Piscataway, NJ, USA; ISO/IEC/IEEE Systems and Software Engineering?Architecture Description
Shane Sendall, W. Kozaczynski (2003)
Model Transformation: The Heart and Soul of Model-Driven Software Development
IEEE Softw., 20
G. Wiederhold (1992)
Mediators in the architecture of future information systems
Computer, 25
V. Neto, C. Paes, Lina Rodriguez, Milena Guessi, Wallace Manzano, F. Oquendo, E. Nakagawa (2017)
Stimuli-SoS: a model-based approach to derive stimuli generators for simulations of systems-of-systems software architectures
Journal of the Brazilian Computer Society, 23
(1990)
citation_author=IEEE 610-12; citation_publisher=IEEE, Piscataway, NJ, USA; IEEE Standard Glossary of Software Engineering Terminology
(2017)
citation_publisher=Brazilian Computer Society, Brazil; GranDSI-BR: Big Research Challenges in Information Systems in Brazil (2016-2026)
M. Maier (1996)
Architecting Principles for Systems‐of‐Systems
, 6
K. Falkner, Claudia Szabo, Vanea Chiprianov (2016)
Model-driven performance prediction of systems of systems
Software & Systems Modeling, 17
C. Nielsen, P. Larsen, J. Fitzgerald, J. Woodcock, J. Peleska (2015)
Systems of Systems Engineering
ACM Computing Surveys (CSUR), 48
J. Michael, D. Drusinsky, Thomas Otani, M. Shing (2011)
Verification and Validation for Trustworthy Software Systems
IEEE Software, 28
(2012)
citation_publisher=Springer, Berlin, Germany; Guide to Modeling and Simulation of Systems of Systems
F. Horita, J. Albuquerque, L. Degrossi, E. Mendiondo, J. Ueyama (2015)
Development of a spatial decision support system for flood risk management in Brazil that combines volunteered geographic information with wireless sensor networks
Comput. Geosci., 80
P. Runeson, Martin Höst (2009)
Guidelines for conducting and reporting case study research in software engineering
Empirical Software Engineering, 14
(2018)
Evaluation of systems-of-systems behaviors: a simulation-driven and model-based approach
Amal Gassara, I. Rodriguez, M. Jmaiel, K. Drira (2017)
A bigraphical multi-scale modeling methodology for system of systems
Comput. Electr. Eng., 58
B. França, G. Travassos (2016)
Experimentation with dynamic simulation models in software engineering: planning and reporting guidelines
Empirical Software Engineering, 21
R. D'Addio, M. Domingues, M. Manzato (2017)
Exploiting feature extraction techniques on users’ reviews for movies recommendation
Journal of the Brazilian Computer Society, 23
(2012)
citation_publisher=Addison-Wesley Longman Publishing Co., Inc, Boston, MA, USA; Software Architecture in Practice
B. Zeigler (2012)
Guide to Modeling and Simulation of Systems of Systems
B. Sauser, J. Boardman, D. Verma (2010)
Systomics: Toward a Biology of System of Systems
IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, 40
P. Heegaard, E. Schoitsch (2015)
Introduction to the Special Theme - Trustworthy Systems of Systems
ERCIM News, 2015
L. Bass, P. Clements, R. Kazman (1999)
Software architecture in practice
(2015)
Systems of systems engineering: basic concepts, model-based techniques, and research directions
ACM Comput. Surv., 48

Publisher: Oxford University Press
Copyright: © The British Computer Society 2019. All rights reserved. For permissions, please e-mail: [email protected]
ISSN: 0010-4620
eISSN: 1460-2067
DOI: 10.1093/comjnl/bxz028
Publisher site: See Article on Publisher Site

Abstract

Abstract Systems-of-Systems (SoS) combine heterogeneous, independent systems to offer complex functionalities for highly dynamic smart applications. Besides their dynamic architecture with continuous changes at runtime, SoS should be reliable and work without interrupting their operation and with no failures that could cause accidents or losses. SoS architectural design should facilitate the prediction of the impact of architectural changes and potential failures due to SoS behavior. However, existing approaches do not support such evaluation. Hence, these systems have been usually built without a proper evaluation of their architecture. This article presents Dynamic-SoS, an approach to predict/anticipate at design time the SoS architectural behavior at runtime to evaluate whether the SoS can sustain their operation. The main contributions of this approach comprise: (i) characterization of the dynamic architecture changes via a set of well-defined operators; (ii) a strategy to automatically include a reconfiguration controller for SoS simulation; and (iii) a means to evaluate architectural configurations that an SoS could assume at runtime, assessing their impact on the viability of the SoS operation. Results of our case study reveal Dynamic-SoS is a promising approach that could contribute to the quality of SoS by enabling prior assessment of its dynamic architecture. 1. INTRODUCTION Software-intensive systems have been increasingly required to interoperate amongst themselves, communicating, exchanging, and using information exchanged.1 Consequently, a distinct class of systems known as Systems-of-Systems (SoS)2 has arisen. An SoS results from operationally and managerially software-intensive systems (called constituents) working together to fulfill missions [1, 2]. SoS will likely form the next generation of software-intensive systems [3, 4], often supporting missions in critical domains (such as emergency and crisis response management, medical applications, and national defense systems) and smart applications (such as smart cities, autonomous cars or vehicles and smart traffic control) [5, 6]. To guarantee a reliable operation for SoS, it is important to establish strategies to maintain an SoS operation in progress, despite a high degree of dynamism, with new constituents joining the SoS at runtime, others leaving it, or being replaced [5, 7–10]. Simulation techniques have been successfully used, especially in software engineering [11], to support the visualization of the system’s dynamic behaviors. Simulations can anticipate, at design time, failures and behaviors that can potentially occur at runtime. In particular, the simulation of software architectures can be achieved by using simulation models with dynamic reconfiguration to predict architectural configuration changes at runtime [12]. Dynamic Structure Discrete Event System Specification (DS-DEVS) [13, 14] is a simulation formalism for modeling behavior of systems from input, output and their states, as well as the coupling of these systems. Nevertheless, despite the suitability of simulation formalisms to predict behaviors with dynamic reconfiguration support, there is a lack of precision in simulating SoS software architectures, i.e. simulating the behavior of constituent systems and their relationship to each other, and to the environment. The simulation formalisms have limitations on the precise representation of SoS software architectures, including the representation of different types of systems, environment representation, and dynamic reconfiguration. Despite the formalism supporting the dynamic architecture representation, the mechanism to implement it is arbitrarily chosen by the user. The main research question addressed in this work is: How to provide a means to assure that the SoS operation is trustworthy, i.e. it will be maintained on-the-fly, despite the inherent SoS dynamic architecture? To address this question, the aim of this article is to present Dynamic-SoS, an approach for simulating SoS software architectures with dynamic reconfiguration support. The main contributions of this article are: (i) the proposition of a set of canonical dynamic reconfiguration operators for SoS software architectures; (ii) a model transformation capable of automatically generating a dynamic reconfiguration controller (DRC); (iii) the engineering of DRC itself, since such an idea could be used for other simulation formalisms; and (iv) the characterization of the process to implement the dynamic architecture operators for SoS software architectures. We evaluated our approach using three case studies in distinct domains: Flood Monitoring SoS, Smart Building SoS and Space SoS. For each case study, we performed a set of 150 architectural changes in the software architecture. We concluded our approach successfully supports simulation of SoS while accounting for dynamic architectures. As a result, our work may potentially be used to evaluate SoS dynamic architectures, enhancing SoS quality by enabling the visualization of possible problems that the SoS may exhibit besides predicting/anticipating SoS architectural behavior at runtime, thus evaluating whether the SoS can sustain their operation. This article is organized as follows: Section 2 provide the necessary background, Section 3 presents Dynamic-SoS, Section 4 presents our evaluation and results, and Section 5 contain final remarks and directions for future work. 2. BACKGROUND Software-intensive SoS are a combination of software-intensive systems and are resulted from the interoperability of several managerially and operationally independent software systems called constituents. Engineering of an SoS often happens in an unknown environment and surrounded by uncertainties [15, 16]. SoS often exhibit a well-defined set of characteristics postulated by Maier [1], which includes operational and managerial independence of constituents, evolutionary development, emergent behaviors and distribution. Besides that, interoperability, heterogeneity, and hierarchy are also considered important characteristics [17]. Constituents of an SoS can also be other entire and complex SoS, such as smart buildings, smart traffic control systems and flood monitoring SoS, which are themselves SoS, but are constituent parts of a larger SoS such as a smart city. Hence, it is imperative to investigate how to design such systems, predicting their behavior and structure still at design-time. SoS software architectures exhibit dynamic architectures as a consequence of their fundamental characteristics, in particular, operational independence of constituents, which states that a constituent is not exclusively dedicated to an SoS, but its operational independence is maintained [1]. Dynamic architectures exhibit a property called dynamic reconfiguration, i.e. their structure can change at runtime, inserting or removing parts, complying with the requirement of generating a new architectural arrangement that is still functional. Hence, a constituent can be part of an SoS for a finite period of time, contributing to the accomplishment of the SoS missions, later leaving it, demanding for a reorganization of the structure of the SoS to maintain its operation. However, the suitability of traditional operators for dynamic architectures of single systems and how to carry out such operators on SoS software architectures have not still been explored. SoS also exhibit an intrinsic relation among dynamic architectures, interoperability and emergent behavior. Emergent behaviors result from the interoperability among constituents, i.e. the ability of two or more constituent systems to purposefully exchange and use data and information [18]. Some emergent behaviors, so-called predicted emergent behaviors, are intentionally engineered by the systematic combination of the individual functionalities of constituents involved in an SoS [10, 19]. An SoS architecture enables interoperability (and emergent behaviors, as a consequence) when the SoS architecture is in a valid operational state. In this case, a valid operational state is such that the constituents necessary to allow the emergence of a behavior are properly connected to allow the information exchange to perform the emergent behavior. An architectural change to the SoS dynamic architecture is considered successful when, besides transforming an SoS from an architectural configuration (also known as coalition) toward a new one, it also moves the architecture of an SoS from one valid operational state to another one. The languages currently adopted to describe software architectures, such as Unified Modeling Language (UML3), Systems Modeling Language (SysML4) and Compass Modeling Language (CML5), lack sufficient accuracy to effectively describe SoS architectures, specially in regard to [2, 13, 20–24]: (i) dynamic architecture; (ii) the description of constituents unknown at design time; (iii) environment modeling; (iv) the combination of formal foundations and high-level abstraction notations; and (v) the concept of SoS software architecture with adequate detail to guarantee precision in representation. UML, for instance, does not support a suitable specification of SoS software architectures, as once a notation for specifying dynamic architectures is lacking [2]. UML diagrams must be adapted to tackle representation of multiple constituents through profiles, which do not represent SoS dynamism, including changes at runtime. In turn, SysML lacks specific structures to model various SoS architectural aspects such as dynamic architecture [2]. Moreover, simulating SoS using SysML often requires distributed simulation and simulators, requiring a heavy infrastructure and implementation to support the interoperability between simulations of single systems. CML is a formal language specially conceived for formal specification of Comprehensive Modeling for Advanced Systems of Systems (COMPASS) alliance [25]. However, it does not provide constructs for environment modeling, software architecture or dynamic architecture [26]. SosADL was conceived to support the specification of SoS architectures [8]. SosADL overcomes the drawbacks exhibited by the aforementioned languages. In SosADL, architectures are abstractly defined by coalitions, which represent temporary alliances among constituents that collaborate via mediators [27]. Such coalitions can be dynamically formed and changed at runtime. The link among architectural elements in SosADL are referred as bindings. Coalition behaviors document how constituents interoperate to accomplish a given set of missions. SosADL also allows the definition of software architecture for self-organizing SoS [19]. The architecture of an SoS defines policies for assembling systems and mediators as coalitions, which are further characterized by behavior, data type and gate declarations. Mediators are first-class elements representing communication links between two or more constituents [28], which can be TCP/IP connections, Zigbee connections or Bluetooth. Gates are abstractions that enable the establishment of connections. A connection can receive stimuli from or act upon the environment, enabling the communication among independent elements. Data types may have inherent functions, and functions can be associated to expressions. Mediators and systems may also be specified in terms of gates, data types and behaviors [8, 29]. SosADL prescribes the representation of dynamic architectures in its operational semantics, i.e. the recipe of how each language construct should be executed. However, an SosADL model is effectively executable only when an equivalent executable semantics is provided. Therefore, mechanisms such as simulation models are required to provide executable denotational semantics. Indeed, studies have mentioned how important simulation-based approaches are to be investigated in SoS context [11, 13, 30–34]. These approaches [11, 23, 34, 35]: (i) support validation of expected emergent behaviors; (ii) empower the observation of unexpected emergent behaviors; (iii) enable the prediction of errors, diagnosing them and permitting corrections; and (iv) provide a visual and dynamic viewpoint, reproducing stimuli that the system can receive from an operational environment. DEVS is a well-known simulation language [13, 36]. It consists of a modeling formalism based on the idea of atomic and coupled models. Atomic models represent individual entities in the SoS (for instance, systems), while coupled models represent a combination of atomic models. Such models exhibit the following elements [13]: (i) a labeled state diagram that performs transitions due to input or output events; (ii) variable initialization; and (iii) definition of abstract data types, global variables, ports and events. In turn, coupled models are composed of atomic models, i.e. coupled models represent the entire SoS. We base our approach on DEVS and adopt a DEVS dialect called DEVS Natural Language (DEVSNL) [13], which enables programming atomic and coupled models intuitive format using tools such as MS4ME.6 Despite its advantages, DEVS and other simulation approaches do not properly support the software architecture description of SoS [2]. DEVS deals with the system architecture, i.e. a simulation model in DEVS considers the software and hardware aspects of all the constituents that compose an SoS, and for the SoS itself. DEVS deals with several important characteristics of software architectures, such as data types, constituent systems (represented as atomic models), constituent behaviors (expressed as labeled state machines), SoS structure (comprising the overall organization of such constituents) and how constituent exchange data (coupled models), and events. However, there are some important specific details of the software architectures of SoS that are not tackled by DEVS. DEVS only deals with the notion of ports. There is no notion of connections and gates separately, which are a paradigm of software architectures (components, connections, values and constraints define a software architecture [37, 38]) used by SoS modeling [39]. Equivalently, there is no differentiation among the concepts of mediators, nor constituents nor stimuli generators. In DEVS, every major entity of an architecture is an atomic model. Thus, the SoS software architecture cannot be entirely characterized. The surrounding environment can be represented, but this is not natively supported, which is an important aspect of any software architecture, including SoS software architectures [38]. SosADL is capable of modeling SoS; while DEVS can simulate SoS models; then a Model-Based Engineering (MBE) can combine such models [15], harmonizing both formalisms, exploiting their advantages and overcoming their drawbacks. This model combination can be established by means of model transformations, which comprise a mapping between the constructs of a source and of a target language, supporting their automatic transformation [40]. Initiatives have separately investigated the description of SoS dynamic architectures and/or SoS simulation models, while other approaches have adopted model transformations to bridge architectural models (π-ADL, SySML, HLA, DoDAF7) and simulation formalisms (Go language, Simulink8) [22]. For instance, Cavalcante et al. [24] report a model transformation approach to map π-ADL architectural models in the Go software code. Although π-ADL provides architectural description models for concurrent and communication processes, the approach supports only dynamic architectures in isolated systems (i.e. it is not suitable for an SoS). Falker et al. [41] deal with simulation of SoS architectures and define an environment called MEDEA, an MDE-based system execution environment that models constituent systems for the evaluation and prediction of performance of the entire SoS. They adopt a platform-independent modeling language (implemented above GraphML), which supports the modeling of interfaces, behavior and workload in a manner independently of any intended execution platform. The code is generated using the Eclipse Graphic Modeling Environment (GME) code generation interpreter that transforms models into executable code. MEDEA works on SoS evolution, dealing with performance analysis when a new constituent is added to the SoS. However, no other details are provided about other possible changes in the SoS architectures. Moreover, it is important to observe that workload models comprise CPU, memory, and I/O issues. The authors deal with hardware issues, but do not deal specifically with software architectures. Xia et al. [23] report a model-driven approach that transforms the system architecture models described in Simulink into executable models. Their approach focuses on technical aspects of SoS, including the measurement of nonfunctional properties, such as feasibility and efficiency. However, dynamic architecture is not mentioned. Hence, what is still required is an approach that combines the advantages of simulation and the formalism of a suitable ADL for representing SoS, while providing dynamic architecture reconfiguration. Our approach for the simulation of SoS dynamic software architectures is presented in the next section. 3. DYNAMIC-SOS APPROACH Dynamic-SoS is a model-based approach to automatically create SoS simulations with dynamic reconfiguration. To support the dynamic reconfiguration, we defined a set of four dynamic reconfiguration operators: addition, deletion, replacement and reconfiguration. Our approach uses an SosADL to DEVS model transformation (SosADL2DEVS) that automatically generates simulation models from SoS software architecture specifications, based on an approach called ASAS [29]. In short, ASAS (Approach to Support Simulation of SmArt Systems [29]) maps SosADL and DEVS models to preserve the architectural descriptions and monitor SoS behaviors at runtime [29]. As shown in Fig. 1, ASAS uses an SosADL model as input to an Xtend script that constructs a model transformer. A functional code written in DEVS is generated as output, establishing an SosADL2DEVS transformation. Broadly speaking, the concepts of System and Mediator in SosADL are transformed into Atomic Models in DEVS. Behaviors are constructed as labeled state machines in DEVS, which configures the constituents operations. Coalitions become coupled models made up of the constituents and their couplings. Connections and gates become ports, and data types and functions are mapped, respectively, to data types and functions in DEVS [29]. However, in this study [29], the authors did not detail how dynamic reconfiguration can be implemented in SoS architectures and how to automatically generate SoS simulation models with support for dynamic architectures. Figure 1. View largeDownload slide A transformation approach to map SosADL models into DEVS simulation models [5]. Figure 1. View largeDownload slide A transformation approach to map SosADL models into DEVS simulation models [5]. In this article, we specifically present Dynamic-SoS, which was established by adding the generation and monitoring of dynamic architecture for that SosADL2DEVS transformation, as depicted in Fig. 2. Moreover, we established the following activities to use Dynamic-SoS: Figure 2. View largeDownload slide Dynamic-SoS approach. Figure 2. View largeDownload slide Dynamic-SoS approach. Activity 1 (A1). SoS architectures are specified by means of coalitions, which express the policies and define bindings among constituents. Duties are obligations to be performed by the gates of the mediator in the interface with a constituent. A coalition may involve many constituents, or exactly one constituent and multiple mediators. An SoS software architecture results from the selection, at runtime, of possible constituent systems that may participate in the SoS [8]. In our case, architecture concretion is performed at design time, using a method defined by Guessi et al. [42]. Considering a set of constituents, mediators are selected for intermediating the communication among constituents, establishing the initial coalition to be transformed, and generating the initial architectural arrangement for the simulation execution. Activity 2 (A2). Execution of the model transformation on the concrete model (in SosADL) to automatically produce a DEVS simulation code with support for the dynamic reconfiguration of an SoS architecture. Activity 3 (A3). Deployment, i.e. the process of managing files of the atomic and coupled models obtained as an outcome of the transformation, deploying them in the specific packages/directories of the project to be simulated in MS4ME (an environment for modeling and simulation of systems represented in DEVSNL); Activity 4 (A4). Simulation execution that consists of launching the simulation. Activity 5 (A5). Monitoring architectural reconfiguration using the dynamic reconfiguration operators (presented further in Section 3.1), comprising the observation of the SoS dynamics at runtime, and registering the execution traces in log files for posterior analysis. The remaining of this section is organized as follows: Section 3.1 presents the dynamic reconfiguration operators used in A5, Section 3.2 presents our approach to support the dynamic reconfiguration operators in simulation, Section 3.3 presents our approach to derive simulation models with dynamic architecture support through the architectural model. 3.1. Dynamic reconfiguration operations We established a set of dynamic reconfiguration operations based on the canonical set of changes proposed by Cavalcante et al. [39], as shown in Fig. 3. Cavalcante et al. observed single systems may have their architectures modified at runtime due to the creation of a new component, removal of a component, connection of a component that was created (attachment) and removal of a component for its deletion (detachment). For SoS software architectures, we reviewed such operators and defined four canonical operators to achieve dynamics in such architectures. We refer to them as canonical because any architectural change could be expressed using a single operator or a combination of more than one of them. In our approach, dynamic reconfiguration in an SoS software architecture is based on constituent addition (corresponding to creation and connection in [39]), constituent deletion (disconnection and remotion in [39]), constituent replacement (which is not common in single systems but useful and recurrent in SoS, and consists of a deletion and an addition) and architecture reorganization (which is not common for single systems as well, but it is common for SoS, as different architectural configurations can deliver more efficient behaviors). Changes in an SoS software architecture are realized as a systematic procedure composed of well-defined steps, explained as follows. Figure 3. View largeDownload slide Set of canonical operations for dynamic architectures of single systems and SoS. Figure 3. View largeDownload slide Set of canonical operations for dynamic architectures of single systems and SoS. 3.1.1. Constituent addition When using the constituent addition operator, a new constituent is created and added to the SoS architecture. The new constituent is linked to one of the constituents that already exist in the SoS architecture. The following steps are performed, as also shown in Fig. 4: Figure 4. View largeDownload slide Process for addition of a constituent in a simulation of SoS software architecture. Figure 4. View largeDownload slide Process for addition of a constituent in a simulation of SoS software architecture. Step 1: A request to add a particular constituent occurs (in this case the C3). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: A constituent (C3 in Scene 2) is initiated and added. Step 3: Other constituent(s) that will connect with C3 is (are) selected (in this case, the C2, Scene 3). Step 4: An appropriate mediator is created and added (in this case, the M2, Scene 4). Step 5: Necessary connections to connect C3 to C2 being mediated by M2 are established, culminating in the new functional architectural configuration for such an SoS (as shown in Scene 5). 3.1.2. Constituent deletion This operator is performed on a specific constituent to remove it from the SoS architecture. For that, the set of connection established with this constituent and also the mediators are removed. After that, the architecture is reorganized so that SoS remains in operation. The following steps are performed, as shown in Fig. 5: Figure 5. View largeDownload slide Process for deletion of constituent in simulation of an SoS software architecture. Figure 5. View largeDownload slide Process for deletion of constituent in simulation of an SoS software architecture. Step 1: A request to remove a particular constituent is performed (in this case, the C2). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: Constituent C2 is selected to be removed (as showed in Scene 2). Step 3: Connections established via mediators with C2 are selected, and they and C2 are removed (in this case, M1 and M2, Scene 3). Step 4: Other constituents that established connections with C2 are selected (in this case, C1 and C3, Scene 4). Step 5: An appropriate mediator is created and added (in this case, the M3, Scene 5). Step 6: Connections are added to link C1 to C3. They are mediated by M3, created in the last step (as shown in Scene 6). 3.1.3. Constituent replacement This operator is performed as a concatenation of both deletion and addition operators. In the replacement operation, removal of the constituent to be substituted is carried out, followed by addition of the new constituent. The following steps are performed, as shown in Fig. 6: Figure 6. View largeDownload slide Process for replacement of constituent in the simulation of an SoS. Figure 6. View largeDownload slide Process for replacement of constituent in the simulation of an SoS. Step 1: A request to replace a particular constituent is performed (in this case, the C1 will be replaced by C3). Scene 1 represents the configuration of the SoS software architecture at that time. Step 2: The constituent C1 is selected to be replaced (as shown in Scene 2). Step 3: The mediated connections with C1 are selected, and they and C1 are removed (in this case, the M1, Scene 3). Step 4: Other constituents that made connections with C1 are selected (in this case, the C2, Scene 3). Step 5: Constituent C3 is initiated and added (as shown in Scene 4). Step 6: An appropriate mediator is created and added (in this case, the M3, Scene 5). Step 7: Connections are established and added to link C3 to C2 being mediated by M3 (as shown in Scene 6). 3.1.4. Architecture reorganization Architectural reorganization process consists of the complete dissolution of a architectural configuration, and re-establishment of new connections among the constituents, leading to a new SoS operational state, as depicted in Fig. 7. In this process, all connections and mediators are removed. After that, arbitrary choices of constituents are made in the SoS architecture (a random process) to establish connections among constituents. This process is repeated until all elements are connected resulting in an architectural configuration that is divergent from the original one. Figure 7. View largeDownload slide Process for reorganization of architecture in the simulation of an SoS software architecture. Figure 7. View largeDownload slide Process for reorganization of architecture in the simulation of an SoS software architecture. 3.2. Dynamic reconfiguration controller Dynamic-SoS is a programmed exogenous reconfiguration approach [39]. It means an entity termed as Dynamic Reconfiguration Controller (DRC) is responsible for managing every architectural change that occurs in the whole structure. DRC is an artificial architectural element that has control over all elements of the software architecture and controls such changes. DRC is added to the simulation to support the user in conducting architectural changes at runtime through the dynamic reconfiguration operators. Figure 8 presents the state machine of DRC. From the DEVS simulation model perspective, the DRC is an atomic model, whose function is to execute the four dynamic reconfiguration operators while maintaining properties of the initial architecture configuration. Figure 8. View largeDownload slide State machine implemented in DEVS to materialize the four canonical reconfiguration operators performed by the Dynamic Reconfiguration Controller. Figure 8. View largeDownload slide State machine implemented in DEVS to materialize the four canonical reconfiguration operators performed by the Dynamic Reconfiguration Controller. For the addition of a constituent to the simulation, it is necessary to send a signal to the DRC. When an addition is invoked by the DRC, mediators are also created to establish the communication between existing constituents and the new one being added to the SoS. Stimuli generators also can be added during this process to feed the new constituent with the data necessary to trigger its interaction within the SoS simulation. For the removal, a signal is sent to the constituent to be removed. As a response, this constituent sends a reference of its own simulation object to the DRC, enabling direct access so that it can be removed. Mediators and connections that communicate with it are also removed. If necessary, new connections and mediators are added to re-establish the path inside the SoS architecture that enable the communication with other constituents that communicated with the constituent removed. The replacement of a constituent involves both a removal and an addition. In turn, for the reorganization of the architecture, a signal is sent to DRC, which removes all connections and mediators among the constituents. After that, DRC creates new connections and mediators among constituents to raise a new functional architectural configuration. For architectural reorganization, it is necessary to send a signal to DRC. Once the operator has been invoked, DRC removes all mediators and connections from the simulation and begins to choose constituents in a random way and will add them to the architecture to generate a new architectural configuration. 3.3. Adding support of dynamic reconfiguration through a model transformation All SosADL elements are mapped to DEVS to create a functional simulation. Transformation rules automatically create DRC from the concrete SosADL architecture and add it in the simulation model. This controller holds and makes available to the user the four dynamic reconfiguration operators, presented in Section 3.1. The model transformation generates three main elements related to the dynamic architecture of the target simulation model, which are DRC: As presented in Section 3.2, it consists of an atomic model that manages all changes in the simulation, as shown in Fig. 9. For that, it manages connections and mediators among constituents, so that the new arrangements remain consistent with the original architecture. Identification flags: In DEVS, there is no distinction between constituent systems and mediators, all of which are transformed into atomic models. However, this differentiation is necessary to maintain the functional architecture after running a dynamic reconfiguration operator. To artificially bring that to DEVS, we added two identification flags to the atomic models: one to check if the system is a mediator or not (a binary variable), and another that is the constituent type name, such as sensor, transmitter or gateway. Connections of all constituents with the DRC in the coupled model: This is necessary to enable the controller to communicate with all constituents and to remove some of them, if necessary. Figure 9. View largeDownload slide An illustration of the relation between Dynamic Reconfiguration Controller (DRC) and constituents being simulated. Figure 9. View largeDownload slide An illustration of the relation between Dynamic Reconfiguration Controller (DRC) and constituents being simulated. Listing 1 shows an excerpt of code of the model transformation.9 The shown method, specified in Xtend, adds dynamic reconfiguration support for all existing elements of the simulation. The reconfiguration support is added after the compilation of the SosADL models. All elements of the concrete architecture in SosADL are iterated, and before creating each compiled file, each element receives some code snippets referring to the communication with DRC, the identification flags, and the connections that support the controller operations in the simulation model. If the SosADL architectural element is a mediator or system, it will be handled in a similar way. If the input for the model transformation is an architecture, all required bindings will be added. In Listing 1, Line 2 shows the transformation code that checks whether sfile, which is the model being compiled, is a system or a mediator. If it is one between both options, the method performs the procedures in Lines 4–8, where Line 4 adds an external transition so that the model can receive the signal to remove it from the simulation, Line 6 adds output transitions so that the model can send its simulation reference to the controller to request its removal, and in Line 8, its identification flags. Otherwise, if the element being analyzed is an architecture, all necessary associations will be added to the coupled model (Lines 10–16). Next, we present the evaluation of our approach and results as well. Listing 1 A transformation excerpt that supports generation of DEVS simulation of SoS software architecture with support to dynamic reconfiguration. 4. EVALUATION In order to evaluate whether our approach successfully simulates SoS dynamic architectures, we conducted case studies in three distinct domains: Flood Monitoring SoS, Smart Building and Space SoS. For the planning of our case study, an evaluation protocol was constructed with respect to the following elements: Method: Executing architectural changes using all dynamic reconfiguration operators. In all, 60 additions, 40 removals, 30 replacements of constituents, and 20 architectural reorganizations, were made, totaling 150 architectural changes. Research Question: Are the architectural changes successful, giving rise to new SoS coalitions in a valid operational state? Rationale. This research question evaluates whether the simulation generated by the model transformation successfully supports the realization of the dynamic reconfiguration operators, showing that DRC was able to generate a new functional architectural configuration at runtime. Metric. Percentage of successful changes in the architecture configuration during simulation, i.e. the proportion of reconfigurations that leads the SoS to a new valid operational state and a corresponding coalition. Conduction of our case study was based on five activities introduced in Section 3, as shown in a summary in video.10 For reader convenience, all models used in each case study and full table with results are also externally available.11 The case study was conducted as follows: Specification of the SoS architecture and its constituents using SosADL (A1). Execution of the model transformation, generating correspondent DEVS models from the initial architecture configuration (A2). Definition of a set of dynamic reconfiguration operators to be sequentially applied to the architecture. Definition of a dataset to be sent to the constituents during simulation. Deployment of DEVS models in the MS4ME environment (A3). Simulation starts on the deployed DEVS models (A4). Simulation of the current architecture configuration. Use of predefined dataset. Registration of execution trace in log file (A5). Log file checking to verify and register if the operator execution has successfully generated a functional architecture configuration (A5). Checking if there is another operator in the set, perform it, and return to item 7. Otherwise, finish the simulation (A5). 4.1. Case 1: FMSoS A Flood Monitoring SoS (FMSoS) is part of a smart city. Such SoS is responsible for monitoring rivers that cross urban areas and notifying the population about potential floods that can quickly occur, causing huge damage and risk for population [36]. FMSoS is concerned with one specific mission: Emitting flood alerts to public authorities that can implement strategies and tactics to protect the population. FMSoS is a collaborative SoS with no central authority that orchestrates the constituents functionalities to accomplish missions. The FMSoS is deployed along the river12 and its sensors are spread on the riverbank’s edges with regular distance among them, and mediators are installed between successive pairs of sensors at pre-established distances. Data collected by sensors are transmitted to the gateway. Additionally, drones fly over the river and return to their bases to recharge and communicate flood threat alerts. In parallel, people walking close to the river can also contribute by communicating water level increases through a crowdsensing mechanism supported by mobile apps. In case of flood, gateways transmit alarms to public authorities, which take decisions to protect the population. It is important to remark that the types of constituents to compose such SoS were selected from a real scenario implemented in the city of São Carlos, Brazil. The SoS, which was originally composed of smart sensors, was enriched with other constituents (crowdsourcing systems and drones). Such novel constituents were also predicted in the initial specification of the FMSoS project carried out by a research team in Brazil, as it can be checked in their website.13 Such an SoS is created with five types of constituents, as shown in Fig. 10 [36]: Smart sensors: cyber-physical systems that monitor flood occurrences in urban areas, being located on riverbank edges. Gateways: which gather data from constituents and share them with other systems. Crowdsourcing systems: mobile applications used by citizens for the real-time communication of water levels. Drones: unmanned aerial vehicles (UAV) used to complement smart sensors by monitoring the river water level while they fly over a river, transmitting images if some change in the water level occurs. Drone bases: fixed bases from where drones depart, and return to battery recharging, data transmission, repair and storage. Figure 10. View largeDownload slide A Flood Monitoring System-of-System (FMSoS) architecture [36]. Figure 10. View largeDownload slide A Flood Monitoring System-of-System (FMSoS) architecture [36]. FMSoS exhibits the following characteristics [1, 8]14: Operational independence of the constituents: Constituents are not exclusively dedicated to an SoS, i.e. operations of the constituents are often used outside the SoS context. For instance, a drone being used by the FMSoS can be reallocated to transmit images related to plantation areas. Similarly, crowdsourcing systems are not also full-time part of the SoS, joining the SoS when a threat motivates people to communicate an imminent flood. Managerial independence of constituents: A diversity of stakeholders and enterprises might independently own, deliver, and manage different constituents that compose FMSoS. Moreover, each constituent has its own management strategy for transmission and energy consumption and will act under the authority of different city councils. Distribution: All constituents rely on a communication network that supports interoperability among them. Evolutionary Development: FMSoS may evolve as a consequence of changes to its environment, its mission or its constituents. Emergent behavior: Flood alerts are a result of the interoperability among involved constituents. One isolated constituent could not reliably deliver a flood alert by itself. For instance, if only one sensor, crowdsourcing system or drone performs its activities in an urban area, it may not be able to notify of a potential flood in time. Hence, a genuine flood alert arises from the interoperability among a diversity of constituents working in cooperation, spread along the riverbank. For this case study, we explain how Dynamic-SoS can support simulations of dynamic software architectures and is able to simulate changes in the architectural configuration at runtime. Data Preparation: To simulate the architecture, we used data collected by the sensors that are under the supervision of a Brazilian entity responsible for monitoring natural disasters (Brazilian Center for Monitoring and Warnings of Natural Disasters—CEMADEN) [43]. These data were parsed and stored in a text file. The input of these data triggers the constituents operation and their interoperability. After the data reach gateway, data received are processed. The outcome varies between positive or negative flood alerts. We also collected these data to analyze results. We carefully chose a data sample collected by sensors deployed along an actual river and selected data collected on a specific day (23 November 2015). This day was important because a real flood occurred in the place where the sensors are located. This enabled us to establish whether or not our simulation can deal with a diversity of situations. Data used were collected every five minutes by the sensors. We used a dataset with 1 920 samples, derived from drone, sensors and crowdsourcing data. We then created a dataset corresponding to the data. 4.1.1. Case study conduction The conduction of this case study was based on systematically performing the previously defined steps. We specified an SoS architecture composed of four sensors, one gateway, four drones, two drone bases, without a crowdsourcing system and one crowdsourcing system gateway (Activity A1, previously presented in Section 3). After defining concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). We prepared the dataset to be sent to the constituents during simulation. After that, we deployed both dataset and simulation models (A3) generated from activity A2 in the MS4ME simulation environment and executed the simulation, performing the set of predefined reconfigurations (A4). We used the entire defined dataset, recording the execution trace in log files. We analyzed log files to verify and register that if the operator execution has successfully generated functional architecture configurations in all cases (A5). 4.1.2. Case study results Simulation execution took about 5 h and 20 min. This simulation was executed on an Intel Core i7-5500U x64, 8GB RAM, 1TB HD, running Ubuntu 16.04.3 LTS 64bits. Figure 11 presents results of the simulation execution. It shows the number of changes performed in the SoS architecture (on the x-axis) by number of constituents that compose such SoS along changes are performed (on the y-axis), and point color represents the change performed in this architecture. Table 1 shows excerpts of data collected during the simulation execution. Figure 11. View largeDownload slide Results of simulation execution. Figure 11. View largeDownload slide Results of simulation execution. Table 1. A sample of changes performed in FMSoS architecture. # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes Table 1. A sample of changes performed in FMSoS architecture. # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes # Changes Sensor Gateway Crowd Drone Drone basis Was successful? Initial set 4 1 0 4 2 Initial set 1 Addition of a crowd 4 1 1 4 2 Yes 2 Addition of a crowd 4 1 2 4 2 Yes 3 Addition of a crowd 4 1 3 4 2 Yes 4 Addition of a crowd 4 1 4 4 2 Yes 11 Architecture Reorganization 4 1 10 4 2 Yes 12 Removal of a crowd 4 1 9 4 2 Yes 77 Removal of a drone 14 6 5 17 2 Yes 99 Replacement of a Sensor 14 6 5 14 7 Yes 129 Removal of a gateway 9 4 5 9 7 Yes 150 Replacement of a Sensor 9 1 5 9 7 Yes Table 1 presents a sample of collected data of the 150 architectural configurations. These data contains sequential number of the architecture configuration, change performed on architecture, amount of each constituent type, and if the change was successfully executed (Yes/No), i.e. if the change was successfully performed and the resulted architecture configuration is functional. The column Was successful? in full table version is ‘Yes’ in 100% of architectural configuration. With these data, we verified DRC was able to execute all four dynamic reconfiguration operators, successfully generating functional architectures. Hence, we can conclude our approach was able to generate simulation models that successfully support dynamic reconfiguration, being able to evaluate the behavior of FMSoS. 4.2. Case 2: smart building In the context of smart cities, smart buildings provide important services to their residents and visitors, such as energy savings by light control by sensors, and fire alarms in case they happen. Dynamic-SoS approach was also evaluated using a Smart Building SoS (SBS), as specified by Gassara et al. [44]. Such SoS is an important instance of problems addressed by Dynamic-SoS, in particular because such SoS is composed of constituents that are, themselves, other entire SoS. Such Smart Building is composed of three other SoS: Fire System, Lighting System and Room. In addition, SBS has a Smart Building Control Unity (SBCU), which is responsible for managing constituent systems of the building. Figure 12 exemplifies its architecture. Figure 12. View largeDownload slide A representation of a Smart Building SoS. Figure 12. View largeDownload slide A representation of a Smart Building SoS. Fire System is an SoS responsible for the control of fire alarm in smart building public areas and consists of Fire System Control Unities (FSCU): They are constituent systems that manage the Fire System receiving sensor data and, if necessary, triggering alarms and sprinklers in the area where fire was detected. Once fire is detected, FSCU informs SBCU about it. Smoke Detectors: They detect the presence of smoke and sends a signal to FSCU. Smoke Detector (an Ionization Smoke Detector was used) opens to receive air to assess the presence of smoke. Once smoke is detected, such signal is sent to the fire alarm. Heat Detectors: Temperature sensors that checks the ambient temperature and once it is higher than 58°C (136.4°F) it emits a signal to the fire sprinkler. Fire Sprinklers: Systems that, once triggered, fires water for the elimination of fire outbreaks. Fire Alarms: Systems that, once triggered, triggers audible alerts signaling that there is a fire in the Smart Building. Lighting System is an SoS responsible for lighting the public areas of the Smart Building and consists of Lighting System Control Unities (LSCU): They manage the Lighting System, receiving sensor data and, when necessary, turning lamps on. Light Sensors: They convert the energy of light (photons), visible or infrared, into an electrical signal (electrons). They capture environment light measured and sends such value to the sensor that covers area that should receive light. Presence Sensors: Devices that detect presence in an environment and sends along with the area to which sensor belongs. Lamps: Smart lamps that can be digitally controlled and can be turned on / off and have their intensity remotely controlled. Room consists of private environments, such as apartments, offices, stores and more. Room can contain elements already mentioned as Light Sensors, Presence Sensor, Lamp, Smoke Detector and Fire Alarm, besides having Room Control Unities (RCU): Systems that manages the room to which it is inserted and communicates with SBCU. RCU controls temperature and room lamps in addition to controlling the internal fire system and receiving/sending fire alerts to SBCU. Thermometers: Temperature sensors that collects the ambient temperature and sends it to RCU. Air Conditioners: Devices that cool environment and is triggered when the temperature is higher than a stipulated value and there is presence in the environment. Smart Building presents three main missions: fire contro, light management and air conditioning. To perform the fire control mission, Smart Building has the Fire System, which uses smoke sensors and heat sensors to detect a fire and notify FSCU. Fire System uses FSCU to trigger alarm to inform people about fire occurrence and an eminent need to evacuate the building, Fire Sprinklers try to put out the fire and notifies SBCU the fire occurrence. Rooms also may have sensors, alarms and sprinklers to assist Smart Building in the accomplishing of the fire control mission. The light management mission is accomplished through the interoperation of light sensors, presence sensors, smart lamps and LSCU. LSCU receives data from sensors and, if necessary, properly activate smart lamps at a suitable intensity. Rooms also have presence sensors and lamps to the internal lighting. The air conditioning is made internally in a room through thermometers, presence sensors and, air conditioners to keep the air conditioner on only if necessary. Smart Building also exhibits the following characteristics of a SoS [1, 8]: Operational independence of the constituents: Internal constituents of a Room are not exclusively dedicated to the Intelligent Building, since they may be performing internal missions and become unavailable to the Smart Building. Hence, the operational independence of constituents is preserved. Managerial independence of constituents: A diversity of stakeholders and companies can have Rooms in the Smart Building, each Room has its internal policy for internal composition and data availability for the Smart Building. Distribution: Smart Building needs a network to allow communication with its constituent systems to achieve its missions due to the interoperability constituent. Evolutionary Development: A Room may change its internal composition and make available new functionalities to the Smart Building to contribute to the Smart Building achieve new missions or improve the existing mission, consequently contributing to Smart Building evolution. Emergent behavior: For fire control, Smart Building needs that Rooms and Fire Systems notice SBCU that is having a fire in the building to SBCU sent an alarm for all Rooms and areas and sent an alert to firefighters. Smart Building also requires that Light System and Rooms interoperate to manage the lighting and energy consumption of the building. Hence, the entire Smart Building operation to accomplish pre-established missions are only possible due to behaviors that emergent from the interoperability of constituent systems. Data Preparation: To simulate a Smart Building, we built a realistic dataset to feed the simulation. Generated dataset was composed of data that represent 10 days. To stimulate Light Sensors, we used a type of data known as Lux (lx), which is the total luminous flux incident on a surface per unit area (illuminance). Such data were generated in a range between 0.1 lx (at night) and 10 000 lx (in broad daylight). The data received from Light Sensors by the BCU are used to turn external lamps on if the illumination is less than 100. To feed Presence Sensors, data were randomly generated between 10 and 60 presences per sensor per day. This data was used by BCU to switch lamps on in the Presence Sensor area. Data used to stimulate Smoke Sensors consisted of binary values (one, for smoke detected; and zero, for non-detected smoke), and 10 fires were chosen in a random area. This data was sent to an FSCU or RCU. If the data value was 1, the alarm was triggered and fire sprinklers were activated in the detected smoke area. Finally, data generated for thermometers were generated between 10°C (30°F) and 30°C (86°F). This data was used by RCU to turn the air conditioners on if there is a presence in the area and temperature is higher than a given value. 4.2.1. Case study conduction Conduction of the SBS case study was also based on the steps defined for Dynamic-SoS approach, being systematically followed. An SoS architecture was specified using SosADL for Smart Building (A1), involving one Fire System, one Lighting System, 20 Rooms and three Building Control Unities. Each Room contains two Thermometers, two Air Conditioners, one Presence Sensor, one Lamp, one Smoke Detector, one Fire Sprinkler, one Alarm and one Room Control Unity. Fire System is composed of 25 Smoke Detectors, five Heat Detectors, 10 Fire Sprinklers, 25 Fire Alarms, and three Fire System Control Unities. Lighting System is composed of 20 Presence Sensors, 40 Light Sensors, and 20 Lamps. Altogether, the initial architecture configuration contains 40 Thermometers (T), 40 Air Conditioners (AC), 20 Room Control Unities (RCU), 40 Light Sensors (LS), 40 Presence Sensors (PS), 40 Lamps (L), two (2) Lighting System Control Unities (LSCU), 45 Smoke Detectors (SD), five (5) Heat Detectors (HD), 30 Fire Sprinklers (FS), 45 Fire Alarms (FA), three (3) Fire System Control Unities (FSCU) and, three (3) Building Control Unities (BCU). After defining the concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). The dataset to stimulate constituents during simulation was also conceived. After that, the transformation produced simulation models in DEVS, which were deployed with the dataset in MS4ME simulation environment (A3). Simulation was executed for the first architectural configuration, performing a set with 60 additions, 40 removals and 30 replacement of constituents, as well as 20 architectural reorganizations, totaling 150 architectural changes. Removal operators were also applied to Control Units to check whether any available Control Units would substitute the removed one (A4). The entire dataset was executed. The execution traces were recorded in log files for analysis purposes. Log files were analyzed to verify whether the operators execution successfully generated functional architecture configurations (A5). 4.2.2. Case study results Simulation of SBS was performed in an Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, two TB HD, in a server running on Ubuntu Server 16.04.3 LTS and took about 9 hours and 40 minutes. Table 2 presents a sample of collected data of 150 architectural configurations. These data contain sequential number of the architecture configuration, change performed on the architecture, number of each constituent type, and if the change was successfully executed (Yes/No), i.e. if it was successfully performed and resulted an architecture configuration in a valid operational state. Column Was successful? in full table version is ‘Yes’ in 100% of architectural configurations. Thus, we verified that DRC was able to execute four dynamic reconfiguration operators on all types of constituents and activating redundant elements (Control Units) when a constituent was removed, thus maintaining the availability of the internal SoS to the Smart Building (Fire System, Lighting System, and Rooms), and sustaining the operation of Smart Building as long as at least one Control Unit remained in the architecture. Table 2. A sample of changes performed in Smart Building architecture. # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y Table 2. A sample of changes performed in Smart Building architecture. # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y # Modification T AC RCU LS PS L LSCU SD HD FS FA FSCU BCU Was successful? Initial state 40 40 20 40 40 40 2 45 5 30 45 5 3 1 Addition of a AC 40 41 20 40 40 40 2 45 5 30 45 5 3 Y 2 Addition of a AC 40 42 20 40 40 40 2 45 5 30 45 5 3 Y 3 Addition of a AC 40 43 20 40 40 40 2 45 5 30 45 5 3 Y 4 Addition of a AC 40 44 20 40 40 40 2 45 5 30 45 5 3 Y 11 Reorganization of architecture 40 50 20 40 40 40 2 45 5 30 45 5 3 Y 12 Removal of a AC 40 49 20 40 40 40 2 45 5 30 45 5 3 Y 77 Removal of a BCU 45 45 20 45 40 50 1 45 10 35 45 5 2 Y 99 Replacement of a FSCU 45 45 20 45 40 50 3 45 10 35 45 4 3 Y 129 Removal of a BCU 40 45 15 45 40 50 2 45 10 35 45 4 2 Y 150 Replacement of a LS 40 45 15 45 40 50 2 45 10 35 45 2 1 Y 4.3. Case 3: space SoS We also evaluated our approach using a Space SoS as specified by Graciano Neto et al. [45] based on a real system called Environmental Data Collection System (SBCDA, in Portuguese). This Space SoS is operated and managed by the Brazilian National Institute for Space Research (INPE, in Portuguese). Space SoS is responsible to perform two concurrent missions: environmental data collection and image capture. To accomplish both missions, as shown in Figure 13, Space SoS is composed of Satellites: Artificial objects orbiting the Earth. Satellites are composed of two main part: (i) platform part, which includes solar panels, batteries, and reaction control system (this part is essential to keep the satellite in operation); and (ii) payload part, which includes sensors and infrared cameras used to accomplish the SoS missions. Three satellites comprise the SBCDA: two dedicated to data collection (SCD1 and SCD2) and one for remote sensing (CBERS-4). These satellites collect data from Data Collection Platforms (DCP) and capture images from the Amazon rainforest. Mission Center: It involves multiple information system constituents that are responsible for receiving records, as well as the processing, storage and distribution of images and environmental/meteorological data for users. Command and Control Center (C2): Located in São José dos Campos (São Paulo, Brazil, point B in Figure 13). C2 is responsible for managing the satellites throughout their lifetime so that they properly maintain their operation. Ground Station: Located in Cuiabá (Mato Grosso, Brazil, Point A in Figure 13), it is responsible for sending telecommands to satellites and receiving telemetry from satellite. It also temporarily stores payload data and satellites tracking. Data Collection Platforms (DCP), which are located along the Brazilian territory. SBCDA has four types of DCP: meteorological, hydrometeorological, agrometeorological and buoy. DCPs send their collected data to satellites once they are not close enough to directly send their data to the Ground Station. Figure 13. View largeDownload slide Illustration of the Brazilian Space SoS [45]. Figure 13. View largeDownload slide Illustration of the Brazilian Space SoS [45]. The first mission is a data forwarding mission that uses satellites to collect environmental data collected by DCP distributed throughout the Brazilian territory and send them to a Ground Station. The second mission is a business process-oriented mission, as shown in Fig. 14. The business process of the second mission is composed of the following activities, performed at this order [46]: Mission Center requests payload data for Command and Control Center (C2). C2 Center elaborates operation plan (telecommand15 and telemetry16) and schedules their execution. Ground Station schedules the reception of data and configures antenna and rotors. Ground Station establishes links with the Satellite. Ground station sends telecommand. Satellite runs telecommand. Satellite stores and send data packets. Ground Station receives and stores data. Mission Center extracts, manipulates and verifies data. Mission Center distributes payload data to the end-users. Figure 14. View largeDownload slide BPMN diagram illustrating a the image capture mission [46]. Figure 14. View largeDownload slide BPMN diagram illustrating a the image capture mission [46]. Space SoS also exhibits the following inherent SoS characteristics [1, 8]: Operational independence of the constituents: Constituents of the Space SoS are independent systems that contribute to such SoS, but are not exclusive to the aforementioned missions, such as TV signal transmissions or military application. They occasionally contribute to the accomplishment of the SoS missions, but preserving their operational independence. Managerial independence of constituents: DCP may be managed by different independent institutions. Space SoS satellites also are managed by different institutions, such as CBERS-4 that is operated by the Brazilian National Institute for Space Research (INPE) and China National Space Administration (CNSA). Distribution: DCPs are distributed throughout the Brazilian territory, requiring a wireless network for communication with the satellite. Evolutionary Development: Space SoS may evolve due to new resource provided by new satellites, enabling it carries out new functionalities. New PCDs may also contribute to the Space SoS evolution, enabling this SoS to cover a larger area or capture new environmental information. Emergent behavior: Due to geographic distribution, DCPs may be in areas of difficult access. DCPs need satellites to make the data available. Hence, it is only possible to emerge the climatic and environmental condition of the entire country due to an interplay among all constituents involved. Moreover, the image capture mission is only accomplished through the interoperability of satellites, Command and Control Center, and Mission Center to properly send telecommands and receive telemetries with collected image. Data Preparation: To feed the DCP, we used data provided by INPE, which made available data of 249 DCPs from 1 January 2017 to 31 October 2017. To generate the satellite orbits, we created a script to access the satellite data server to pick up coordinates and store them into a file, once a second for 2 days, to build a real orbit. We collected the coordinates from the China-Brazil Earth Resources Satellite 4 (CBERS-4) and Data-Collecting Satellite 1 and 2 (SCD-1 and SCD-2, in Portuguese). 4.3.1. Case study conduction To reinforce the evidence of effectiveness of Dynamic-SoS, this third case was also conducted based on steps previously defined, but in this case study using Space SoS architectural models specified in SosADL. We developed the SoS architecture with one Satellite, 60 meteorological DCPs, five (5) buoyed DCPs, 40 hydrometeorological DCPs, 10 agrometeorological DCPs, one Mission Center, one Command and Control Center and one Ground Station (A1). After defining the concrete architecture model in SosADL, we submitted it to the model transformation to generate a DEVS simulation model (A2). DEVS models were deployed together with the dataset in the MS4ME simulation environment (A3). Simulation was executed according to the predefined set of architectural reconfigurations. Execution traces were recorded in log files, as in previous case studies (A4). We analyzed log files to verify whether the reconfigurations were well-succeeded, generating architecture configurations in valid operational states (A5). A set of 60 additions, 40 removals and 30 replacement of constituents, and 20 architectural reorganizations was performed, totaling 150 architectural changes. We split the dataset into 151 parts, one for the initial configuration and 150 for the architectural configuration generated by a dynamic reconfiguration operator. 4.3.2. Case study results The simulation was performed in an Intel(R) Xeon(R) CPU E5-2620 v3, with 30 GB RAM, two TB HD, in a server running on Ubuntu Server 16.04.3 LTS and took about 21 h and 30 min. Table 3 presents a sample of collected data of the 150 architectural configurations. These data contain a sequential number of the architecture configuration, change performed on architecture, number of each constituent type and a status denoting whether the change was successfully executed (Yes/No), i.e. if the change was successfully performed and resulted a new architecture configuration in a valid operational state. Column Was successful? in full table version is ‘Yes’ in 100% of architectural configuration. Thus, we concluded DRC was able to execute the four dynamic reconfiguration operators in all cases. Table 3. A sample of changes performed in Space SoS architecture. # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y Table 3. A sample of changes performed in Space SoS architecture. # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y # Modification Satellite Meteorological DCP Buoyed DCP Hydrometeorological DCP Agrometeorological DCP Was successful? Initial State 1 60 5 40 10 1 Addition of a PCDMet 1 61 5 40 10 Y 2 Addition of a PCDMet 1 62 5 40 10 Y 3 Addition of a PCDMet 1 63 5 40 10 Y 4 Addition of a PCDMet 1 64 5 40 10 Y 11 Reorganization of architecture 1 70 5 40 10 Y 12 Removal of a PCDMet 1 69 5 40 10 Y 77 Removal of a PCDQagua 1 65 18 45 19 Y 129 Removal of a Satellite 4 60 15 40 19 Y 150 Replacement of a Satellite 1 60 15 40 19 Y 4.4. Triangulation Triangulation is a process by which results obtained in different scenarios of a case study are compared and combined according to a predefined set of parameters to draw conclusions and evidence with more strength. Triangulation is important to increase the precision of empirical research, as it takes different angles toward the studied object and thus providing a broader picture [47]. In this study, the matter of interest is the simulation of SoS dynamic architectures. We intended to observe whether Dynamic-SoS approach was well-succeeded for both (i) automatically providing simulation models that support dynamic reconfigurations, and (ii) supporting the analysis of the impact of such reconfigurations on the SoS architecture, in particular in regard to the sustainability of SoS emergent behaviors. We executed three different studies, involving FMSoS, Smart Building and Space SoS. For all of them, we applied the same set of architectural changes in the same order, and observed their impact on the data transmission rates (intimately aligned with the emergent behaviors provided by the SoS) expressed by the percentage of data that was successfully received in a gateway or that passed by an specific constituent in regards to the total number of data that was provided as stimuli to feed each simulation. Figure 15 shows data collected from simulations. This data presents the percentage of collected data during the case studies (y-axis) and performed operators. These data support us to analyze the SoS availability and performance to fulfill its missions during its execution and predict how changes in the architecture of SoS will impact its performance, allowing to anticipate eventual problems. Figure 15. View largeDownload slide Chart showing the rate of receipt of data throughout the case studies. Figure 15. View largeDownload slide Chart showing the rate of receipt of data throughout the case studies. Additionally, we can analyze the impact of executing operators in the architecture. Figure 16 shows the impact of addition operator on receiving data, i.e. the data reception rate before the operator performance minus the data reception rate per execution of the operator (y-axis) and shows in which constituent type was performed the operator. This chart allows us to analyze how the increase in the number of constituents affects data transmission. In all case studies, the addition of sensors/collectors decreased the data received, while the addition of constituents that receive these data increases the rate of data collection. This helps us to draw a trade-off on the acquisition of new constituents, making it possible, for instance, to conclude that adding a second gateway in the FMSoS increases the data reception rate by 20%, which is the same gain that happens when adding a second satellite to the Space SoS. Figure 16. View largeDownload slide Chart presenting the impact of the addition of a constituent in the simulation. Figure 16. View largeDownload slide Chart presenting the impact of the addition of a constituent in the simulation. Then, after analyzing and triangulating results obtained from three different independent studies, we can answer the raised research question for the case studies: Are the architectural changes successful, giving rise to new SoS coalitions in a valid operational state? The answer is Yes. In 100% of the cases in the three studies, Dynamic-SoS was successful to support dynamic reconfigurations in SoS software architectures, leading the architecture to valid operational states in all obtained coalitions. 4.5. Threats to validity We identify some threats to validity for our study: scale, correctness of the transformation rules, selection of dataset and selection of changes set. Scale is addressed through an increase in the number of constituents during the study, until reaching a couple hundred of systems being simulated. As a side effect, this hampers data visualization and processing, as a large number of constituents is difficult to visualize in a simulation and a more powerful processor would be required to execute simulation of a larger SoS. However, these problems were reduced by saving results in external files to be further properly analyzed. Regarding transformation correctness, we established correspondences between entities in SosADL and DEVS, and we performed a manual inspection in the models to alleviate this threat, assessing whether all entities in the SosADL model were correctly mapped into DEVS model, thus ensuring that the behavior of the DEVS simulation model corresponds to the specification of the SosADL model. After applying this procedure in all models, we verified that all models were correctly generated, pointing for a high precision and correctness of the SosADL2DEVS transformation rules. Selection of data might present a possible bias. However, in FMSoS, the day considered (i.e. 23 November 2015) has samples of any type of input the FMSoS can receive during an entire year. In particular, the day started dry, and the river exhibited an average water level (90 cm). Later, an intense rain made the water level reach 600 cm. The day were finished with the water level reduced to 100 cm. Hence, the sample exhibited a large variety of data, besides the occurrence of intense rains that enabled us to analyze the effectiveness of the simulation to reproduce the alarm triggering. For the simulation of Smart Building, we artificially constructed our dataset, which can lead to bias. To minimize this possible effect, we randomly created a diversity of events, such as presence and fire, increasing the diversity of scenarios being represented, and reducing bias by introducing casualty in the data produced and used to stimulate constituents. Regarding Space SoS, we obtained real data for the data collection platforms provided by INPE and collected data from the orbits of the satellites that are actually part of the SBCDA. Hence, bias was reduced by using real data, which are currently adopted by the real SBCDA during its operation. The set of reconfiguration operators and order in which changes occur were the last threat we identified. Different changes could be performed, substituting or eliminating constituents, or even reorganizing SoS configuration. However, the purpose of this study was to check whether our approach could successfully (i) support automatic generation of functional dynamic simulation models for SoS software architectures, (ii) reproduce effects of the reconfigurations in the SoS architecture, (ii) support analysis of the effect of different architectural configurations in the generation of new coalitions in valid operational states. Considering our approach was well-succeeded in all these endeavors, this threat does not influence our results. 4.6. Discussion In this study, we exercised the dynamics of SoS software architectures through a set of dynamic reconfiguration operators. We systematically followed well-defined steps prescribed in Dynamic-SoS approach, modeling three SoS from three different domains. Combination of high connectivity and ubiquity of current software-intensive systems and increase in the number of systems that can be part of a city, such as traffic systems, cell phones, sensors, radars, autonomous cars, smart buildings and other technologies, will lead to the rise of large-scale SoS consisting of thousands or even millions of constituents. Constituents intended to be part of these SoS have been developed using different technologies, heterogeneous means of communication, different platforms and different levels of complexity ranging from simple objects with sensors, such as those of IoT systems and cyber-physical systems (CPS), reaching complex information systems or other entire SoS (such as a Flood Monitoring SoS, which is an entire SoS, but still a constituent of a smart city SoS). Thus, a sustainable development of such systems requires addressing different granularities with which these systems appear, different technologies and full interoperability between them, while also predicting the impact of inherent dynamics of such systems. The high dynamics of the architecture will inevitably affect performance of the provided service, load of data transferring, possibility of connection and interoperability among different systems, possibly causing failures and demanding recovery strategies. Dynamic-SoS approach provides solutions for this emerging demand, since it is suitable for dealing with several of those concerns regarding the development of real-world SoSs. The simulation models originated by the model transformation enables system engineers to predict, at design-time, the impact of such architectural changes on the entire system, as well as the impact on quality attributes, such as performance, accuracy and efficiency. Such insights can assist SoS engineers to draw strategies to deal with potential failures, predicting scenarios and anticipating solutions, thus improving the quality provided by the services provided by such SoS to the society. In this study, we presented a solution to enable such analysis, focusing on the feasibility of each new architectural arrangement created. However, further extensions are planned to be done in forthcoming steps of this research, including the analysis of multiple quality attributes. With regard to this work, important contributions were brought: Characterization of SoS dynamic architectures operators: Providing dynamic architectures inherently depends on designing each possible change that can be performed on these architectures. Those changes should be well-defined and the final architecture should always deliver a valid operational state. Dynamic reconfiguration operators were previously established for single systems software architectures. However, when considering multiple interoperable systems present in an SoS, there was a gap to be bridged. Dynamic-SoS builds a remarkable contribution on previous advances by providing a robust and canonical set of dynamic changes that can be adopted to represent any change a SoS software architecture can suffer. We state this as a contribution that can be replicated in any context that requires SoS dynamic architectures. Generation of dynamic models from static models: Dynamic-SoS approach also provides a means to automatically derive SoS simulation models from static specification of SoS software architectures with a single initial coalition. This is possible because the dynamic reconfiguration operators are encapsulated in a controller that enables the aforementioned operations over the initial architectural configuration, conducting to other SoS functional architectural configurations, and making use of the underlying simulation mechanisms. A process to include dynamics in SoS software architecture models: By using a model transformation approach, we established a process that encompasses activities necessary to observe the dynamics of SoS via simulations, passing by the SoS software architecture specification step until reaching the assessment of different architectural configurations. Despite the reported advances, challenges still remain. For instance, Table 4 presents data about the maximum number of constituents reached in each simulation and the time to simulate it. Simulations required an average of more than 12 h to execute data feeding, architectural reconfigurations, and simulation execution of no more than 400 constituents. Hence, if a linear relation is established between such variables, simulation of an SoS with 1 million constituents could take more than 3 years, which is unfeasible. In the context of smart cities, New York city and São Paulo are intended to be composed of cell phones, autonomous cars, smart buildings, houses, and hospitals, with different granularities, potentially reaching 50 million constituents, which makes the simulation of such forthcoming cities currently unfeasible (it would take 76 years, following the same rationale). Hence, strategies, such as parallel processing and distributed simulations, combined with a huge computational processing power, should be established to deal with such huge dimensions of real-world forthcoming SoS. Hence, scale for SoS is still an open problem, in particular for simulation domain. Table 4. Comparison between number of constituents and time in different SoS simulations. SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 Table 4. Comparison between number of constituents and time in different SoS simulations. SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 SoS type Maximum number of constituents Total simulation time (h) FMSoS 52 5.33 Smart Building 395 9.66 Space SoS 155 21.5 Besides, Dynamic-SoS can be expanded to cover other purposes of study, such as measuring other specific quality attributes, analyzing the threshold or limit of constituents that still maintain the SoS feasible, applying a set of random reconfigurations and study the architecture behavior, and predicting the impact of specific constituents on the entire SoS architecture. Next section brings concluding remarks. 5. FINAL REMARKS SoS architectural design is a challenging task due to diverse architectural configurations a SoS can assume at runtime and the complexity of assessing the impact of such changes still at design time. Dynamic-SoS contributes to this scenario by providing an infrastructure that allows SoS architects to predict, via simulations automatically generated at design-time, the SoS dynamic architectures, besides visualizing the SoS dynamics, and its impact on the SoS associated behavior. We conducted three case studies in three different domains, generating simulation models and analyzing the impact of changes on the functionalities provided by the modeled SoS. Results brought evidences that Dynamic-SoS is a feasible and effective approach to predict SoS behavior, despite the inherent dynamics associated to its architecture. Motivated by these results, our future work involves dealing with real SoS dynamic architectures at runtime (i.e. after SoS deployment), advancing on models@runtime research branch. We intend to draw strategies for the synchronization between coalitions and SoS architectural specification, preserving SoS architectural consistency, avoiding degradation and assuring the quality of this class of systems that has been increasingly applied in several critical, complex application domains. ACKNOWLEDGEMENTS Authors also thank professor Dr Les Foulds (INF/UFG) for the language review. FUNDING The authors thank Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) (Grants: 2014/02244-7, 2017/06195-9 and 2017/17448-5). Footnotes 1 http://www.himss.org/library/interoperability-standards/what-is-interoperability 2 For sake of simplicity, the acronym SoS is used interchangeably to express singular and plural. 3 UML, http://www.uml.org/ 4 SysML, http://sysml.org/ 5 CML, http://www.compass-research.eu/approach.html 6 MS4ME, http://www.ms4systems.com/pages/ms4me.php 7 DoDAF, US Department of Defense Architecture Framework, 2010. 8 Simulink, www.mathworks.com/products/simulink/ 9 Some parts of the code are hidden for the reader convenience. 10 https://vimeo.com/222339631 11 https://goo.gl/iw4exH 12 Credits for the images used to compose the figure: http://goo.gl/TTOlAa, http://goo.gl/QCUAKY, http://goo.gl/a9Y0Dw, https://goo.gl/rFkYJ6, https://goo.gl/8YojYj, https://goo.gl/XyWEZw, https://goo.gl/VpftdV, https://goo.gl/dfMPLl. 13 AGORA research team: http://www.agora.icmc.usp.br/site/components/ 14 Our example scenario also covers constituents heterogeneity, autonomy, and SoS scale, characteristics that are commonly assigned to SoS, as well [3]. 15 Operation remotely sent to satellites requiring them to perform actions, such as, capturing images or opening of the solar panel. 16 Technical name given to the information received from the status of the satellite during its passage over the ground stations. References 1 Maier , M.W. ( 1998 ) Architecting principles for systems-of-systems . Syst. Eng. , 1 , 267 – 284 . Google Scholar Crossref Search ADS 2 Guessi , M. , Graciano Neto , V.V. , Bianchi , T. , Felizardo , K.R. , Oquendo , F. and Nakagawa , E.Y. ( 2015 ) A Systematic Literature Review on the Description of Software Architectures for Systems of Systems. ACM Sympos. Applied Computing (SAC), Salamanca, Spain, 13–17 April, pp. 1433–1440. ACM, New York, NY, USA. 3 Jamshidi , M. ( 2009 ) System of Systems Engineering—Innovations for 21st century Wiley Series in Systems Engineering and Management . Wiley , Hoboken, NJ, USA . 4 Boehm , B. ( 2006 ) A View of 20th and 21st Century Software Engineering. 28th Int. Conf. Software Engineering (ICSE), Shanghai, China, 20–28 May, pp. 12–29. ACM, New York, NY, USA. 5 Graciano Neto , V.V. ( 2017 ) A Model-based Approach Towards the Building of Trustworthy Software-Intensive Systems-of-Systems. 39th Int. Conf. Software Engineering Companion (ICSE-C), Buenos Aires, Argentina, 20–28 May, pp. 425–428. IEEE Press, Piscataway, NJ, USA. 6 Ruscio , D.D. , Malavolta , I. , Pelliccione , P. and Tivoli , M. ( 2016 ) Automatic Generation of Detailed Flight Plans from High-level Mission Descriptions. ACM/IEEE 19th Int. Conf. Model Driven Engineering Languages and Systems, Saint-Malo, France, 02–07 October, pp. 45–55. ACM, New York, NY, USA. 7 Heegaard , P.E. and Schoitsch , E. ( 2015 ) Introduction to the special theme - trustworthy systems of systems . ERCIM News , 2015 , 8 – 9 . 8 Oquendo , F. ( 2016 ) Formally Describing the Software Architecture of Systems-of-Systems with SosADL. 11th IEEE Syst. Syst. Eng. Conf. (SoSE), Kongsberg, Norway, 12–16 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 9 Nakagawa , E.Y. et al. ( 2017 ) Software Architecture and Reference Architecture of Software-Intensive Systems and Systems-of-Systems: Contributions to the State of the Art. 11th Eur. Conf. Software Architecture (ECSA), Canterbury, UK, 11–15 September, pp. 4–11. ACM, New York, NY, USA. 10 Graciano Neto , V.V. , Oquendo , F. and Nakagawa , E.Y. ( 2017 ) Smart Systems-of-Information Systems: Foundations and an Assessment Model for Research Development. In Boscarioli , C. , Araujo , R. and Maciel , R.S.P. (eds.) GranDSI-BR: Big Research Challenges in Information Systems in Brazil (2016-2026) . Brazilian Computer Society , Brazil . 11 de França , B.B.N. and Travassos , G.H. ( 2016 ) Experimentation with dynamic simulation models in software engineering: planning and reporting guidelines . Empir. Softw. Eng. , 21 , 1302 – 1345 . Google Scholar Crossref Search ADS 12 Bogado , V. , Gonnet , S. and Leone , H. ( 2017 ) DEVS-Based Methodological Framework for Multi-quality Attribute Evaluation Using Software Architectures. 2017 XLIII Latin Am. Comput. Conf. (CLEI), Cordoba, Argentina, 4–8 September, pp. 1–10. IEEE, Piscataway, NJ, USA. 13 Zeigler , B.P. , Sarjoughian , H.S. , Duboz , R. and Souli , J.-C. ( 2012 ) Guide to Modeling and Simulation of Systems of Systems . Springer , Berlin, Germany . 14 Seo , C. , Zeigler , B.P. , Coop , R. and Kim , D. ( 2013 ) DEVS Modeling and Simulation Methodology with ms4 me Software Tool. Sympos. Theory of Modeling & Simulation—DEVS Integrative M&S Symposium, San Diego, CA, USA, 12–15 April, pp. 33:1–33:8. Society for Computer Simulation International, San Diego, CA, USA. 15 Lana , C.A. , Souza , N.M. , Delamaro , M.E. , Nakagawa , E.Y. , Oquendo , F. and Maldonado , J.C. ( 2016 ) Systems-of-Systems Development: Initiatives, Trends, and Challenges. XLII Conferencia Latinoamericana de Informática (CLEI), Valparaiso, Chile, 10–14 October, pp. 1–10. IEEE Press, Piscataway, NJ, USA. 16 Bianchi , T. , Santos , D.S. and Felizardo , K.R. ( 2015 ) Quality Attributes of Systems-of-Systems: A Systematic Literature Review. IEEE/ACM 3rd Int. Workshop on Software Engineering for Systems-of-Systems (SESoS), Florence, Italy, 16–24 May, pp. 23–30. IEEE, Piscataway, NJ, USA. 17 Boardman , J. and Sauser , B. ( 2006 ) System of Systems—The Meaning of IEEE/SMC Int. Conf. System of Systems Engineering (SoSE), Los Angeles, CA, USA, 24–26 April, pp. 6–6. IEEE, Piscataway, NJ, USA. 18 IEEE 610-12 ( 1990 ) IEEE Standard Glossary of Software Engineering Terminology . IEEE , Piscataway, NJ, USA . 19 Oquendo , F. ( 2017 ) Software Architecture of Self-organizing Systems-of-Systems for the Internet-of-Things with SosADL. 12th Int. Conf. System of Systems Engineering (SoSE), Waikoloa, HI, USA, 18–21 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 20 Klein , J. and van Vliet , H. ( 2013 ) A Systematic Review of System-of-Systems Architecture Research. 9th Int. ACM Sigsoft Conf. Quality of Software Architectures (QoSA), New York, NY, USA, 17–21 June, pp. 13–22. ACM, New York, NY, USA. 21 Cavalcante , E. , Quilbeuf , J. , Traonouez , L. , Oquendo , F. , Batista , T. and Legay , A. ( 2016 ) Statistical Model Checking of Dynamic Software Architectures. 10th Eur. Conf. Software Architecture (ECSA), Copenhagen, Denmark, 28 November–02 December, pp. 185–200. Springer, Berlin, Germany. 22 Graciano Neto , V.V. , Guessi , M. , Oliveira , L.B.R. , Oquendo , F. and Nakagawa , E.Y. ( 2014 ) Investigating the Model-driven Development for Systems-of-Systems. 2014 Eur. Conf. Software Architecture Workshops (ECSAW), Vienna, Austria, 25–29 August, pp. 22:1–22:8. ACM, New York, NY, USA. 23 Xia , X. , Wu , J. , Liu , C. and Xu , L. ( 2013 ) A Model-Driven Approach for Evaluating System of Systems. Int. Conf. Engineering of Complex Computer Systems (ICECCS), Singapore, 17–19 July, pp. 56–64. IEEE, Piscataway, NJ, USA. 24 Cavalcante , E. , Oquendo , F. and Batista , T.V. ( 2014 ) Architecture-Based Code Generation: From π-ADL Architecture Descriptions to Implementations in the Go Language. 8th Eur. Conf. Software Architecture (ECSA), Vienna, Austria, 25–29 August, pp. 130–145. Springer, Berlin, Germany. 25 Woodcock , J. , Cavalcanti , A. , Fitzgerald , J. , Larsen , P. , Miyazawa , A. and Perry , S. ( 2012 ) Features of cml: A Formal Modelling Language for Systems of Systems. 7th Int. Conf. System of Systems Engineering (SoSE), Genova, Italy, 16–19 July, pp. 1–6. IEEE, Piscataway, NJ, USA. 26 Fitzgerald , J. , Foster , S. , Ingram , C. , Larsen , P.G. and Woodcock , J. ( 2013 ) Model-Based Engineering for Systems of Systems: The Compass Manifesto. Technical Report Manifesto Version 1.0. COMPASS Interest Group, Newcastle, UK. 27 Oquendo , F. ( 2016 ) Software Architecture Challenges and Emerging Research in Software-Intensive Systems-of-Systems. 10th Eur. Conf. Software Architecture (ECSA), Copenhagen, Denmark, 28 November–02 December, pp. 3–21. Springer, Berlin, Germany. 28 Wiederhold , G. ( 1992 ) Mediators in the architecture of future information systems . Computer , 25 , 38 – 49 . Google Scholar Crossref Search ADS 29 Graciano Neto , V.V. , Garcés , L. , Guessi , M. , Paes , C. , Manzano , W. , Oquendo , F. and Nakagawa , E.Y. ( 2018 ) ASAS: An Approach to Support Simulation of Smart Systems. 51st Hawaii Int. Conf. System Sciences (HICSS), Big Island, HI, USA, 2–6 January, pp. 5777–5786. IEEE, Piscataway, NJ, USA. 30 Mittal , S. and Rainey , L. ( 2015 ) Harnessing Emergence: The Control and Design of Emergent Behavior in System of Systems Engineering. Conf. Summer Computer Simulation (SummerSim), Chicago, IL, USA, 26–29 July, pp. 1–10. Society for Computer Simulation International, San Diego, CA, USA. 31 Nielsen , C.B. , Larsen , P.G. , Fitzgerald , J. , Woodcock , J. and Peleska , J. ( 2015 ) Systems of systems engineering: basic concepts, model-based techniques, and research directions . ACM Comput. Surv. , 48 , 18:1 – 18:41 . Google Scholar Crossref Search ADS 32 Michael , J.B. , Riehle , R. and Shing , M.T. ( 2009 ) The Verification and Validation of Software Architecture for Systems of Systems. 2009 Int. Conf. Systems-of-Systems Engineering (SoSE), Albuquerque, USA, 30 May–3 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 33 Sauser , B. , Boardman , J. and Verma , D. ( 2010 ) Systomics: toward a biology of system of systems . IEEE Trans. Syst. Man Cybern. , 40 , 803 – 814 . Google Scholar Crossref Search ADS 34 Wachholder , D. and Stary , C. ( 2015 ) Enabling Emergent Behavior in Systems-of-Systems through Bigraph-Based Modeling. 10th Int. Conf. Systems of Systems Engineering (SoSE), San Antonio, TX, USA, 17–20 May, pp. 334–339. IEEE, Piscataway, NJ, USA. 35 Michael , J.B. , Drusinsky , D. , Otani , T.W. and Shing , M.-T. ( 2011 ) Verification and validation for trustworthy software systems . IEEE Softw. , 28 , 86 – 92 . Google Scholar Crossref Search ADS 36 Graciano Neto , V.V. , Barros Paes , C.E. , Garcés , L. , Guessi , M. , Manzano , W. , Oquendo , F. and Nakagawa , E.Y. ( 2017 ) Stimuli-SoS: a model-based approach to derive stimuli generators for simulations of systems-of-systems software architectures . J. Braz. Comput. Soc. , 23 , 1 – 22 . Google Scholar Crossref Search ADS 37 Bass , L. , Clements , P. and Kazman , R. ( 2012 ) Software Architecture in Practice . Addison-Wesley Longman Publishing Co., Inc , Boston, MA, USA . 38 ISO/IEC/IEEE 42010:2011 ( 2011 ) ISO/IEC/IEEE Systems and Software Engineering—Architecture Description . IEEE , Piscataway, NJ, USA . 39 Cavalcante , E. , Batista , T.V. and Oquendo , F. ( 2015 ) Supporting Dynamic Software Architectures: From Architectural Description to Implementation. 12th IEEE/IFIP Conf. Software Architecture (WICSA), Montreal, Canada, 4–8 May, pp. 31–40. IEEE, Piscataway, NJ, USA. 40 Sendall , S. and Kozaczynski , W. ( 2003 ) Model transformation: the heart and soul of model-driven software development . IEEE Softw. , 20 , 42 – 45 . Google Scholar Crossref Search ADS 41 Falkner , K. , Szabo , C. , Chiprianov , V. , Puddy , G. , Rieckmann , M. , Fraser , D. and Aston , C. ( 2018 ) Model-driven performance prediction of systems of systems . Softw. Syst. Model. , 17 , 415 – 441 . Google Scholar Crossref Search ADS 42 Guessi , M. , Oquendo , F. and Nakagawa , E.Y. ( 2016 ) Checking the Architectural Feasibility of Systems-of-Systems Using Formal Descriptions. 11th Syst. Syst. Eng. Conf. (SoSE), Kongsberg, Norway, 12–16 June, pp. 1–6. IEEE, Piscataway, NJ, USA. 43 Horita , F.E. , de Albuquerque , J.P. , Degrossi , L.C. , Mendiondo , E.M. and Ueyama , J. ( 2015 ) Development of a spatial decision support system for flood risk management in Brazil that combines volunteered geographic information with wireless sensor networks . Comput. Geosci. , 80 , 84 – 94 . Google Scholar Crossref Search ADS 44 Gassara , A. , Rodriguez , I.B. , Jmaiel , M. and Drira , K. ( 2017 ) A bigraphical multi-scale modeling methodology for system of systems . Comput. Electr. Eng. , 58 , 113 – 125 . Google Scholar Crossref Search ADS 45 Graciano Neto , V.V. , Manzano , W. , Rohling , A.J. , Ferreira , M.G.V. , Volpato , T. and Nakagawa , E.Y. ( 2018 ) Externalizing Patterns for Simulations in Software Engineering of Systems-of-Systems. 33rd Annu. ACM Sympos. Applied Computing (SAC), Pau, France, 09–13 April, pp. 1687–1694. ACM, New York, NY, USA. 46 Graciano Neto , V.V. , Garcés , L. , Paes , C.E.B. , Manzano , W. , Rohling , A.J. , Kassab , M. , Oquendo , F. and Nakagawa , E.Y. ( 2018 ) Evaluation of systems-of-systems behaviors: a simulation-driven and model-based approach . Softw. Pract. Ex. , X , 1 – 38 . Submitted. 47 Runeson , P. and Höst , M. ( 2009 ) Guidelines for conducting and reporting case study research in software engineering . Empir. Softw. Eng. , 14 , 131 – 164 . Google Scholar Crossref Search ADS Author notes Handling editor: George Loukas © The British Computer Society 2019. All rights reserved. For permissions, please e-mail: [email protected] This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)

Journal

The Computer Journal – Oxford University Press

Published: May 20, 2020

Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 7-Day Trial for You or Your Team.

Learn More →

Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 7-Day Trial for You or Your Team.

Learn More →

Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

Dynamic-SoS: An Approach for the Simulation of Systems-of-Systems Dynamic Architectures

References (24)

Abstract

Journal

Recommended Articles

There are no references for this article.

Our policy towards the use of cookies