Systems‐of‐systems modeling using a comprehensive viewpoint‐based SysML profile

In recent years, more and more efforts have been devoted in supporting the design of systems‐of‐systems (SoS). Designing such systems is a multidisciplinary problem which involves considering emergent phenomena, assuring the achievement of dependability/security requirements, guaranteeing system responsiveness, and supporting dynamicity/evolution and multicriticality of provided services. A first step towards a viable design approach is to provide a conceptual model of SoS which captures SoS concepts, and their interrelationships aiming at enhancing the understandability of SoS to stakeholders and providing the basis for further automated analysis. In this context, the AMADEOS European project is bringing together researchers and practitioners to provide the support to design SoS starting from the definition of a domain specific ontology serving as a vocabulary for SoS. Our contribution consists in the modeling of the key SoS concepts and relationships defined in AMADEOS adopting a systems modeling language visual modeling language. We propose a systems modeling language profile for SoS, and we show its applicability in a Smart Grid scenario. We show how to use the profile in a model‐driven engineering process to support different types of analyses, and we discuss how to integrate the profile in a user‐friendly model‐driven engineering tool for SoS rapid modeling, validation, code‐generation, and simulation.

Based on the outcomes achieved in the context of the AMADEOS 3 project, 1 seven viewpoints have been selected and explored to define a generic SoS architectural framework and design methodology. Under these viewpoints, we studied SoS in different domains (railway, automotive, smart energy grids, global automated teller machine network, and crisis management) and proposed a meta-requirement model 4 to describe a generic SoS and to support its design, development, and evolution. The identified viewpoints are the following: structure, dynamicity, evolution, dependability, security, time, multicriticality, and emergence. 5 Structure represents architectural concerns of an SoS. In particular, it defines the manner in which CSs are composed 6 and how do they exchange semantically well-defined messages 7 through their interfaces. 8 Dynamicity represents variations to the operation of SoS that have been considered at design time to reconfigure the SoS in specific situations, eg, either after a fault or after the variation of an external condition. 9 Evolution represents changes that have been introduced later to accommodate modified or new requirements by means of including, removing, or modifying system functions. 10 Dependability and security 11 consists of nonfunctional critical requirements as availability, reliability, safety, privacy, or confidentiality.
Multicriticality aims at integrating together subsystems providing services with different levels of criticality corresponding to different dependability and security requirements. 12 Time is fundamental since SoS are sensitive to the progression of time, and it is necessary to design responsive SoS able to achieve reliably time-dependent requirements. 13 Emergence mainly denotes the appearance of novel phenomena at the SoS level that are not observable at CSs level; managing emergence is essential to avoid undesired, possibly unexpected situations generated from CSs interactions and to realize desired emergent phenomena being usually the higher goal of an SoS. 14 Following the viewpoint based analysis, in this paper, we propose a semiformalization of the SoS conceptual model that serves as a domain-independent vocabulary for SoS. To this end, we rely on the systems modeling language (SysML), 15 which is adopted as the mainstream ADL for SoSE. In particular, we define an SoS profile that extends the SysML reference metamodel with specific language constructs, eg, stereotypes and their associations. By using our profile a designer could dynamically apply the SoS concepts to a SysML model of an existing system, effectively elevating the abstraction level from a systems-only perspective to an SoS perspective. Our profile consolidates identified SoS characteristics under well-defined SoS concepts; thus, it decreases cognitive complexity concerning the modeled viewpoints and helps stakeholders to implement desired SoS goals. To demonstrate the clarification effects and overall usefulness of our profile, we applied it in a smart grid use case. We show how to use the profile (1) to model the high-level design of the target SoS architecture, (2) to support different types of analyses in a model-driven engineering (MDE) tool chain, and (3) to solve scalability and usability concerns through its integration in a user-friendly MDE tool for SoS rapid modeling, validation, code generation, and simulation.
We remark that a SysML profile can be rarely considered carved in stone, and minor updates can be identified also once it reaches maturity. The 4.0 version that we report here has reached maturity at the end of a 3-year process, during which the profile has been extensively discussed with members of the AMADEOS project, 16 the External Advisory Board, and the scientific community. 17,18 Further, it has been exercised in use cases whose requirements are defined by industries. 16 This paper is an extended version of Mori et al. 17 With respect to Mori et al, 17 we present an extensive discussion on the relevant concepts of the conceptual model, and we clarify how they are coded into an SysML profile including graphical examples from selected viewpoints. Further, this work includes 2 additional viewpoints, namely, dependability and security, and enhances the emergence viewpoints; these changes are included to align our description to the final definition of the profile. Additionally, we introduce a user-friendly MDE tool that integrates the SysML profile enabling the design, validation, code generation, and simulation of SoS.
The paper is structured as follows. Section 2 introduces a motivating smart grid scenario in the energy domain for showing the applicability of the SoS profile. Section 3 provides a short introduction of the basic SysML elements and diagrams that will be used in the rest of the paper. The SysML profile for SoS is then presented in Section 4 along with the conceptual model it is based on. Section 5 shows the application of the profile to the scenario thus opening it for viewpoints-driven design and analysis. Section 6 discusses how to use the profile in a MDE process to support different types of analyses, and how to integrate the profile in a user-friendly MDE tool for SoS rapid modeling, validation, code generation, and simulation. Section 7 presents a viewpoint-driven gap analysis for SoS design approaches found in the literature, and Section 8 concludes the paper showing possible future work directions.

| MOTIVATING SCENARIO
In a smart grid household scenario, different operationally independent subsystems aim at delivering the desired emergent phenomenon of improving the efficiency and the reliability of the production and distribution of electricity through communication facilities. Requests for energy coming from electronic appliances are forwarded towards the subsystems in charge of granting or denying each request while achieving the smart grid goal, ie, keeping balanced the production and consumption rates for connected households. shows consumption rates and enables inhabitants to interact with their own energy control system. The energy management gateway (EMG) controls the flexible loads and the DER based on measurements received from the SM and in agreement with the coordinator to establish optimal energy distribution. The coordinator is connected to the neighborhood network access point with the aim of keeping the 1 The objective of the AMADEOS 15 FP7 project is to bring time awareness and evolution into the design of SoS, to establish a sound conceptual model, a generic architectural framework, and a design methodology, supported by prototype tools, for the modeling, development, and evolution of time-sensitive SoS with possible emergent behaviors. production and the consumption of energy for a set of connected households balanced. A distribution system operator regulates consumption and production rates at the country level. By means of its load management optimizer, a distribution system operator receives information from a meter aggregator and enacts control decisions in cooperation with the coordinator. The access to the household is provided by one or more local network access points connected to a neighborhood network access point. All the above mentioned components require proper interfaces to exchange control messages and physical energy entities within and outside the household smart grid.
In a household, electrical appliances have to request when they want to switch on, but they may freely switch off. Consequently, they dynamically connect and disconnect to the grid. However, a decision to turn on electrical appliances is taken at a higher level, as follows: First, the electrical appliance sends a request to the EMG, which periodically receives aggregated consumption and production rates from the SM. Then the EMG, which cannot directly determine how much energy is available in the smart grid, forwards the request to the connected coordinator. The coordinator decides according to the information received by the EMG and on the basis of the current global energy consumption and production rates of the neighborhood, if the request for energy can be satisfied. In a last step, this decision is sent back to the EMG which finally grants or denies the energy request of the initiator electrical appliance. This interaction pattern occurs for many electrical appliances which possibly concurrently request energy in many households contributing to a highly dynamic and-without appropriate modeling techniques-complex smart grid behavior.
Dynamic interactions may also lead to undesired smart grid behaviors that need to be discovered and prevented. In case of an exceptional lighting of a specific public space, a peak of energy request comes from an external EMG (in the neighborhood). Let us now suppose that the corresponding SM fails in transmitting aggregated consumption and production values to its EMG. The latter forwards wrong information to the coordinator which consequently fails in maintaining balanced consumption values, eg, by allowing more request to the households then it is possible. This will then result to a blackout of the household grid. This detrimental emergent phenomenon cannot be captured if we only look at the interactions of the internal household subsystems without considering the external EMG. Appropriate means to describe and recognize interactions that lead to detrimental emergent phenomena are essential to prevent possible negative consequences.
Smart meters of the households may be subject to faults which may hamper their availability and compromise the safety of the whole smart grid. To this end, appropriate counter measures have to be modeled in the design process to early identify possible problems for which solutions are already available according to common standards.
Solutions have to be applied, which may span from replication mechanisms to improve availability to error detection techniques aiming to guarantee a certain tolerable hazard rate (THR).
The security of communication within the smart grid has to be carefully considered to avoid the intrusion of third party and the correct functioning of the grid. The protocol to adopt is the Open Smart Grid Protocol adopting RC4 and EN14908 as encryption/decryption algorithm which exploit the OMAK symmetric key defined in the Open Smart Grid Protocol. 19 It is, thus, required to define a security protocol in the design model, its encryption/decryption algorithm and key and link them to the part of smart grid that shall be secured.
Our smart grid scenario shows also that different subsystems may have different levels of criticality. Indeed, the service of public event lighting (PEL) has a higher level of criticality regarding the service provided by MWs and WM in a household. The latter can be interrupted with no detrimental consequences while the interruption of lighting for a public event may cause more severe problems. FIGURE 1 Smart grid: energy management scenario. DER, distributed energy resource; DSO, distribution system operator; EMG, energy management gateway; LMO, load management optimizer Finally, a smart grid is also subject to the introduction of new technologies aiming at maximizing its business value. A new device, a smartphone, may have to be included in the household to replace the command display (ie, a desktop device) to show consumption/production rates and supporting new interactive actions, ie, turning on and off a device directly from the smartphone. This scenario represents a possible evolution which has to be fully characterized to describe its impact on the Smart Grid.

| BASICS ON SysML
The SysML 20 is a general-purpose graphical modeling language, defined by the Object Management Group, based on the well-known unified modeling language (UML 2 ). The SysML supports specification, analysis, design, verification, and validation of a broad range of systems, and it includes 9 diagrams instead of the 13 diagrams from UML, making it a smaller language that is easier to learn and apply. It provides structure diagrams to describe system structure and components, and dynamic diagrams to model the behavior of the system.
The diagrams that we will use in the rest of the paper are the block definition diagram (BDD-structure diagram), and the sequence diagram (dynamic diagram). The official Object Management Group SysML webpage 3 contains all the details on the available SysML features and diagrams, also in the form of tutorials (eg, Friedenthal 21 ).
Blocks in SysML BDD are the basic structural element used to model the structure of systems, and they can be used to represent systems, system components (hardware and software), items, conceptual entities, and logical abstractions. Blocks are shown as UML classes stereotyped "block" and are depicted as a rectangle with compartments that contain block characteristics such as name, properties, operations, and requirements that the block satisfies. A block provides a unifying concept to describe the structure of an element or a system: system, hardware, software, data, procedure, facility, and person. This type of diagram helps a system designer to depict the static structure of an SoS for its CS and possible relationships.
A sequence diagram represents the items involved in a scenario or interaction, and the messages that are exchanged in a chronological order. Items in a sequence diagram are represented by a lifetime.
These lifetimes can be generic instances, or instances from blocks defined in the model; instantiating blocks on sequence diagrams establish a link with the static (BDD) system model.
Another important element to be introduced is the concept of profile. While UML provides various generic concepts for software and systems modeling, it cannot cover all possible application scenarios; instead, it can be extended with profiles to add custom model elements to suit the specific needs. Therefore, a profile is a generic extension mechanism for customizing UML models for particular domains and platforms. Profiles are defined using stereotypes, tag definitions, and constraints which are applied to specific model elements, like classes, attributes, operations, and activities. A profile is a collection of such extensions that collectively customize UML for a particular domain or platform. SysML itself is actually defined as an extension of a subset of UML using UML's profile mechanism. The SoS profile we present in this paper further extends the SysML reference metamodel with specific language constructs for modeling the key concepts and relationships in the domain of SoS.

| SysML PROFILE BASED ON CONCEPTUAL MODEL FOR SoS
A conceptual model consists of a set of stable and unambiguously defined concepts (ie, categories) and semantic relations among them.
A conceptual model provides a domain-specific ontology representing a vocabulary for domain discourse. A group of experts may commit to such a domain-specific ontology; hence, they establish a shared view on a domain and are able to collaborate with respect to the domain.
In the AMADEOS project, a conceptual model for SoS 22 has been conceived to find a common language allowing experts to collaborate on modeling, engineering, and analyzing SoS. It is structured in several viewpoints on SoS which we introduced in Section 1. In this section, we give a brief overview of a subset of the concepts contained in the viewpoints and how we have modeled them in a SysML semiformal representation organized in a profile 4 composed by viewpoint-related packages. To this end, we have defined specific constructs and we have exploited already implemented stereotypes available in other related profiles to support specific viewpoints. Our proposed profile is meant to be used by designers in describing the static SoS structure and its dynamic behavior according to the introduced viewpoints. Such an SoS description can be adopted to be kept consistent across viewpoints by tools and for machine-assisted cross-viewpoint analyses (eg, finding detrimental emergent SoS behavior).
In the following, we enlist the solutions we envision in our profile to the needs raised by each of the viewpoints.

| Structure package
The static structure of an SoS is based on the concept of a CS, which is "An autonomous subsystem of an SoS, consisting of computer systems and possibly of a controlled objects and/or human role players that interact to provide a given service." A CS exchanges information that is either represented by things/energy or data with its environment by means of interfaces. The environment of a CS includes all entities that are able to interact with the CS, including other CSs. In our context, information is any kind of timed proposition about the state of an attribute of an entity which is either an attribute of a physical thing (eg, temperature of a room) or an attribute of an abstract construct (eg, execution time of a program).
The interfaces among which the CSs interact with one another are the relied upon interfaces (RUIs). As such the CS service-which is its intended behavior-is provided at this interface. The RUI is further struc- The structural properties of an SoS are described using 3 different subpackages: "SoS Architecture", "SoS Communication", and "SoS Interface" (see the literature 22 ). The first defines stereotypes useful to describe the topology of an SoS; the second provides stereotypes to describe the communication aspects between the CSs of an SoS; finally, "SoS Interface" semiformalizes internal and external points of interaction of an SoS. For the sake of brevity, in this paper, we focus on the "SoS architecture" subpackage that is the foundation for building any type of SoS.

| SoS architecture subpackage
Architectural components are defined within the "SoS Architecture" subpackage (see Figure 2). This package extends SysML BDD to model the topology and the relations of an SoS.
The first stereotype is "entity" (something that exists as a distinct and self-contained unit), and it extends the SysML metaclass "Block". We distinguish between 2 different kinds of entities: "thing" (a physical entity that has an identifiable existence in the physical world) or "construct" (a nonphysical entity, a product of the human mind, such as an idea). They extend the properties of entity, so they are also represented as blocks.
A "System" is a type of entity (thereby a Block); it has the same characteristic, but it is also capable of interacting with its environment.
As it is expressed by the "sys_type" enumeration, a system can be • "autonomous"-a system that can provide its services without guidance by another system; • "monolithic"-if distinguishable services are not clearly separated in the implementation but are interwoven, • "open" (or "closed")-a system that is interacting (or is not interacting) with its environment during the given time interval of interest, • "legacy"-an existing operational system within an organization that provides an indispensable service to the organization, • "homogeneous"-a system where all sub-systems adhere to the same architectural style, • "reducible"-a system where the sum of the parts makes the whole, FIGURE 2 Systems-of-systems (SoS) architecture subpackage. CPS, cyber-physical system; CS, constituent system; HMI, human machine interface; RUMI, relied upon message interface; RUPI, relied upon physical interface • "evolutionary"-a system where the interface is dynamic (ie, the service specification changes during the given time interval of interest), • "periodic"-a system where the temporal behavior is structured into a sequence of periods, and • "stateful" (or "stateless")-a system that contains (or does not contain) state at a considered level of abstraction.
Every organization that develops a system follows a set of explicit or implicit rules and conventions, eg, naming conventions, representation of data (eg, endianness of data), protocols, etc when designing the system. This set of explicit or implicit rules and conventions is called the architectural style, which is represented by the stereotype "architectural_style". A system can provide a communication "interface", and it has a "boundary" (a dividing line between 2 systems or between a system and its environment). A "subsystem" is a subordinate system that is part of a system and it is related to "system" by a composite relation.
A CS is an autonomous subsystem of an SoS, consisting of human machine interfaces "HMI" and possibly of physical "controlled_object" and it provides a given "service" by interacting with "role_player" through the "RUMI". The RUMI is a message interface where the services of a CS are offered to the other CSs of an SoS, and "RUPI" stereotype represents a physical interface where things are exchanged among the CSs of an SoS. A wrapper represents a new system with at least 2 interfaces, which is introduced between interfaces of the connected component systems to resolve property mismatches among these systems, which will typically be legacy_systems. A prime mover is a human that interacts with the system according to his or her own goal. In the profile, the "wrapper", the "legacy_system", and the "prime_mover" are CS, which is a stereotype that extends the property of "system" that contains multiple "sub_system", which in turn can be CS. A system has a "state_space" composed of states described by the variables that may be accessed by the CS service. In addition, a CS interacts with cyber-physical systems. The "SOS" stereotype represents the integration of systems, ie, CSs that are independent and operable, and which are networked together for a period to achieve a certain goal. As expressed by the "sos_type" enumeration, an SoS can be • "directed"-an SoS with a central managed purpose and central ownership of all CSs; • "acknowledged"-independent ownership of the CSs, but cooperative agreements among the owners to an aligned purpose; • "collaborative"-voluntary interactions of independent CSs to achieve a goal that is beneficial to the individual CS; and • "virtual"-lack of central purpose and central alignment.

| Time package
The progression of time enables changes, ie, dynamicity and evolution, in SoS. In the AMADEOS project, it has been concluded that a global sparse timebase is fundamental for reducing cognitive complexity in understanding aspects related to all nonstatic investigated viewpoints on SoS. For example, a sparse global timebase allows establishing consistently-across all CSs-a temporal order among sparse events, regardless which CSs originally produced these sparse events.

| Dependability package
Dependability is "The ability to avoid failures that are more frequent and more severe than is acceptable." A failure, ie, a deviation of the system behavior from its intended behavior, is resulted from an error state (eg, flipped bits in a data word) within a system which was caused by a fault (for example, an electromagnetic pulse outside system specifications). A system outage describes the interval where a system does not provide the intended behavior. System restoration is "The transition from system failure to intended system behaviour." 11 The profile supports the definition of dependability concerns in an SoS by supporting the definition of dependability guarantees which refers to different dependability measures (ie, robustness, safety, integrity, maintainability, availability, and reliability), for which a set of techniques may have to be applied (ie, fault forecast, fault tolerance, fault removal, and fault prevention). 11 Security and multicriticality are other nonfunctional aspects of systems that relate to unacceptable failures. To emphasize their importance in our viewpoint-based conceptual model, we discuss them separately.

| Security package
Security is concerned with establishing confidentiality, integrity, and availability for authorized actions only. These nonfunctional attributes are usually accomplished by symmetric or asymmetric cryptographic means (eg, encryption and hashes). Authorization is realized by access control policies and is usually augmented by authentication to ensure the identity of the authorized subject.
To discuss attacks and mitigation strategies on security, the AMADEOS conceptual model introduces a threat as "Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations through a system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service." Security attacks exploit system vulnerabilities. Risks quantize the likelihood of specific threats and their impact.
The profile supports the application of security concepts to achieve the encrypted transfer of messages among CSs according either to a public key or asymmetric cryptography mechanism.
Access controls policies are also supported to allow users in getting authenticated to the SoS and authorized for a set of granted actions to the SoS. To this end, a monitoring infrastructure following security policies to detect security incidents and vulnerabilities may be put in place.
Security viewpoint is limited to express the concepts identified in the AMADEOS conceptual model, which constitutes a domainindependent vocabulary for SoS. However, this can be potentially expanded with novel concept as well as introducing existing profiles, for example, UMLsec. 25

| Evolution package
In contrast to dynamicity, the concept of evolution relates to all changes of an SoS that are not given by requirements and thus part of the design, but arise by changes in the environment (primary evolution), or by new or changed requirements on the SoS service itself (secondary evolution). Note that in the context of SoS, we are only concerned with evolution that affects the behavior of CSs relevant for the SoS. Local evolution within single CSs that is not observable at the RUIs has by definition no effect on the global SoS service and is of no interest to us. In prospect to formalize a methodology which allows evolution to take place in a controlled manner, the concept of managed evolution is most relevant. It is defined as the "evolution that is guided and supported to achieve a certain goal." 9 Evolutionary change is often associated with an increase of the business value of an SoS.
The profile supports the definition of the elements to describe the process of gradual and progressive change of an SoS. Among others, it supports the identification of the evolution type, the objective it aims at achieving and the involved system resources.
To describe this type of processes we have chosen a BDD, because it is designed to show the generic characteristics and structures of a system.
The main SoS concepts related to evolution are modeled within the "SoS Evolution" package of our SoS profile. Figure 3 shows the "evolution" stereotype as a block of a BDD, aiming at describing an SoS change. In our conceptual model, we envision 2 different types of evolution: • "managed_evolution"-Process of modifying the SoS to keep it relevant in face of an ever-changing environment. Examples of environmental changes include new available technology, new business cases/strategies, new business processes, changing user needs, new legal requirements, compliance rules, and safety regulations, changing political issues, new standards, etc.
• "unmanaged_evolution"-Ongoing modification of the SoS that occurs as a result of ongoing changes in (some of) its CSs. Examples of such internal changes include changing circumstances, ongoing optimization, etc.
An SoS evolution has a "goal", it improves the "business value" (overarching concept to denote the performance, impact, usefulness, etc of the functioning of the SoS) by the exploitation of the "system_resource" (renewable or consumable goods used to achieve a certain goal, eg, a CPU, CPU time, and electricity) and can be affected by the "environment" (entities and their actions that are not part of a system but have the capability to interact with the system). Evolution is achieved by modifying CSs and consequently the whole SoS.

| Dynamicity package
Dynamicity concerns all changes or configurations an SoS can exhibit by design. Most importantly it encompasses all CSs interactions (eg, message or things/energy exchanged over time). Consequently from the viewpoint of dynamicity the service of all CSs is exposed at the RUIs where observable inputs and outputs can be conveniently (1) described in interface specifications for engineering purposes and (2) monitored for diagnosis purposes.
Dynamicity also concerns reconfigurability, which is the ability of a system to change its configuration according to the current demands.
For example, in SoS, we often do not have statically connected CSs, but CSs enter and exit autonomously a given SoS over time. The involved CSs must be able to reconfigure themselves accordingly. Conceptually, we modeled this again at the RUI by means of a RUI connection strategy which is "[…] searches for desired, with regards to connections available, and compatible RUIs of other CSs and connects them until they either become undesirable, unavailable, or

| Multicriticality package
A multicriticality system is a system delivering at least 2 services of different criticality levels, ie, different levels of dependability/security requirements. For example, safety is "The absence of catastrophic consequences on the user(s) and on the environment" and as stated in Bums et al, 26 in many safety standards, "Up to five levels may be identified (see, for example, the IEC 61508, DO-178B, DO-254 and ISO 26262 standards)." Multicriticality can also be applied to services, ie, intended (sub)behavior of a system. A critical service requires a certain level of dependability and security, eg, safety. In certification, it is required practice to declare the criticality level of a system as high as its most critical delivered service unless evidence can be supplied that more critical services can be provided in sufficient isolation (eg, dedi-

| Emergence package
In the AMADEOS conceptual model, emergence is defined as "A phe-

| APPLICATION OF THE VIEWPOINT-BASED SoS PROFILE
In this section, we describe our SoS profile by illustrating how we have applied it to solve the viewpoint-driven needs raised by the energy management scenario. Consequently, we do not present the metamodels of the profile defined through SysML BDDs (where blocks are the basic structural element used to model the structure of systems 14 ), but we do present how most of the BDDs can be applied to solve specific problems at hand for a given viewpoint. Interested readers may refer to the literature 22 for further details on SoS profile meta-models and illustrative applications.

| Structure viewpoint
To support the definition of the SoS structure, the profile contains a BDD to model the topology and the relations of an SoS. Figure 4 shows how the SoS structure BDD can be applied to our household scenario. The latter is modeled as an SoS able to produce and reliably distribute electricity by means of its entailed CSs. The EMG is a block and it is stereotyped as a «cs»; similarly, SM (ie, the SM) and In this scenario, a message flowing from MW to the SmartMeter contains the energy consumption rate (data_field = 2 kW) and some additional information as displayed in the comment box of the sequence diagram.

| Evolution viewpoint
To describe the evolution process, our profile defines a distinct BDD with a set of specific stereotypes. Figure 6 represents an application of the profile to our scenario. It shows the evolution of the SoS caused by the replacement of the device controlling consumption and production values.
As shown in the figure, evolution is represented with a Household_evolution block which is stereotyped as «managed_evolution».
It consists of introducing a new technology (NewAvailableTechnology stereotyped as «goal») thus maximizing the usefulness, ie, the «business_value». With this aim, the evolution acts on a new system_resource by replacing the CommandDisplay with the smartphone.
By eliciting the evolution as enabled with our profile, it is possible to help FIGURE 4 Energy management scenario: static structure. CS, constituent system; DER, distributed energy resource; DSO, distribution system operator; EMG, energy management gateway; MW, microwave; RUMI, relied upon message interface; RUPI, relied upon physical interface; SM, smart meter; WM, washing machine system designers in reflecting on how a progressive change or development could impact the whole SoS.

| Dynamicity viewpoint
As motivated by the nature of the dynamicity viewpoint (see Section 3), we present (1) how to apply specific profile concepts to elicit dynamicity and (2) how to represent dynamic interactions occurring in an operational SoS.
First, by applying a specific BDD defined in our profile, we show how to identify the dynamic behavior in the energy management scenario which consists in the connection\disconnection of the Flexible Load. This dynamic behavior is stereotyped as «reconfigurability», ie, the variation to the CSs structure (see Figure 7). Second, since our objective is to fully capture the dynamic behavior of an operational SoS, we propose a 3-step process: the first step consists in selecting the CSs involved in the communication; the second, making use of structure viewpoint (through a sequence diagram), represents the behavior of messages exchanged among CSs; the third step is to analyze the most common interactions. The dynamic behavior supporting the provision of energy (see Section 2) is represented in Figure 8  Our dynamicity representation supports a system designer in understanding which are the properties of an SoS that are constantly changing and how the SoS may change by rearranging its components.   Figure 9 shows how, through a specific BDD, the emergence phenomenon is described in Section 2.

| Emergence viewpoint
The latter is labeled as wrong coordination decision and it is represented as an «explained_emerg_phenomenon» explained by the coordinator balancing behavior which is stereotyped as a «trans_Ordinal_law», ie, a law explaining what happen globally through CSs interactions in order to balance consumption and production values. This phenomenon results in a blackout for the smart grid which consists in an «unexpected&detrimental» behavior putting the grid out of service.
Similar to dynamicity, we cannot model the manifestation of emergent phenomena based on a static description of interacting CSs alone.
Consequently, we also introduce a sequence diagram as it has been made available to us in the structure viewpoint. We use this type of diagram to detail the interactions among CSs that lead to a blackout, which we consider as a detrimental emergent phenomenon in the smart grid household scenario. Consider the sequence diagram in Figure 10, where WM is switched on at t1 after the agreement allowed from the coordinator. Next, the coordinator receives (at time t2) and grants (at time t3) the request for switching on the public lighting for the exceptional event. This request is forwarded to the coordinator from the PEL EMG which is external to the household. Before the request is issued by the EMG (at time t2), the SM fails in communicating the actual production/consumption values. This will affect the forthcoming decisions of the coordinator which will act upon wrong information. As next, within the household, the MW and clothes dryer issue (at time t4 and t5) and receive (at time t6 and t7) the grant to be connected to the grid. These decisions are based on the wrong information received by the EMG: the EMG assumes to grant energy requests while still being able to balance consumption and production values. Unfortunately, because the external SM has communicated no information, the grid is accepting more requests for energy than it is able to supply. This puts energy producers under stress and eventually leads to the failure of some energy producers. These failures lead to an even greater imbalance in the grid. The resulting higher stress on remaining energy producers will trigger more failures until finally the grid is not able to deliver enough energy for most consumers, ie, a blackout has occurred. The latter is revealed within the household by the switch-off messages sent from the SM to all the appliances (time t8-t10).
This illustrative example shows that networked individual systems, which work together to realize a higher goal (optimal energy distribution), could lead to a detrimental emergent behavior in the event of an exceptional energy demand in combination with a catastrophic SM failure. This has been modeled (except for the producers interactions) through the exchange of messages leading to FIGURE 8 Energy management scenario: dynamicity behavior description. EMG, energy management gateway; MW, microwave;WM, washing machine FIGURE 9 Energy management scenario: emergence definition. SoS, systems of systems unexpected and detrimental emergent behavior caused by a system dynamicity property.

| Dependability viewpoint
As it emerges from the motivating scenario different dependability requirements have to be accurately taken into account for the household management SoS. In particular, we have discussed the dependability metrics related to safety and availability of the SM.
To this end, the profile supported the definition of availability and safety «dependability guarantee» (see Figure 11). The first consists in providing an availability > 10 −3 by means of a replication technique to provide «fault-tolerance». The second consists in providing a THR per hour THR < 10 −8 through an error correction technique providing «fault-tolerance». The 2 adopted techniques are implemented within the SM CS; thus, in the diagram, it also appears the SM block as imported from the structure viewpoint.

| Security viewpoint
The security viewpoint supported the definition of secured communication through the «security» stereotype as linked to the SG_Household (see Figure 12).

The communication to be secured occurs between EMG and SM
CSs for which the protocol adopted is the Open Smart Grid Protocol as defined with the «cryptography» stereotype. This protocol adopted as encryption and decryption algorithms the RC4 and EN14908 algorithms. The latter are represented by means of 2 different blocks each labeled with «encryption» and «decryption» stereotype. This adopted mechanism is based on a secret key infrastructure which exploits the FIGURE 10 Energy management scenario: emergence behavior description. EMG, energy management gateway; MW, microwave; PEL, public event lighting; SM, smart meter; WM, washing machine FIGURE 11 Energy management scenario: dependability. CS, constituent system; SM, smart meter; SoS, systems of systems; THR, tolerable hazard rate so-called OMAK «symmetric-key» representing the shared secret between the EMG and the SM.

| Multicriticality viewpoint
As discussed in the energy management scenario, we have a PEL service with a high level of criticality and a washing service with a lower level of criticality. To represent this situation in Figure 13, we have added the stereotype critical_service to both the former services, and we have linked each of them to the correspondent criticality_level either low or high (in the specific example). Each of these levels is defined by means of different safety requirements. The high criticality_level (associated to the PEL service) consists in a THR per hour smaller than 10 −8 (corresponding to Safety Integrity 28 Level 4) while the low criticality level (associated to the washing service) consists in no THR set. In this case, we have considered stereotypes identified for structure and dependability viewpoints which are essential to characterize the multicriticality instantiation.

| ADOPTING THE SoS PROFILE WITHIN MDE METHODOLOGIES
The profile that we illustrated by applying it to the energy scenario in Section 2 can also be adopted within a MDE approach, 29 which supports system understanding, design, development, maintenance, and evolution by means of models. In this context, by applying our profile it is possible to obtain a platform-independent model (PIM), ie, a viewpoint-driven SoS model describing the architecture and its behavior which neglects platform specific details. A PIM can further be combined with specific platform details to generate a platform-specific model for each viewpoint. Our profile supports the generation of a PIM as the first step for a model-driven methodology. Even though generic and platform independent, a PIM is the starting point for a set of specific tasks. Among others, source code generation may automatically support the translation of the SoS to executable artifacts.
System analysis techniques, like hazard analysis (HA), failure mode and effect analysis, and fault tree analysis may be also applied to different purposes (eg, Bonfiglio 30 ). Finally, also system testing may also be applied to identify test procedures or to resolve problems of testing coverage. Noteworthy, the mentioned techniques to be valuable completed require additional inputs.
In the rest of this section, we show the applicability and usefulness of the SoS profile in 2 different contexts: • In Section 6.1, we discuss how the PIM generated with our profile can be used to support the detection/avoidance of emergent behaviors of an SoS by means of an HA.
• In Section 6.2, we illustrate the usage and integration of the profile in a MDE tool to model, validate, query, and simulate SoS.

| Interface analysis to detect emergent behaviors of SoS
This section describes how the PIM generated with our profile can be exploited to support the detection/avoidance of emergent behaviors of an SoS by means of an HA. The basic idea consists in analyzing interacting events among CSs. With this aim, we have defined a set of steps to be followed. Step 1 defines an SoS architectural model using the elements of the profile; step 2 formalizes the connections among CSs to univocally identify internal SoS interfaces; step 3 identifies a set of events that could lead to emergent behaviors, being it FIGURE 12 Energy management scenario: security. EMG, energy management gateway; SoS, systems of systems; SM, smart meter FIGURE 13 Energy management scenario: multicriticality. PEL, public event lighting; THR, tolerable hazard rate; WM, washing machine either beneficial or detrimental; step 4 associates each event with semantic information, ie, guidewords to explore particular circumstances leading to an emergent behavior.
To illustrate how it is possible to detect emergent behaviors, we exploit the energy management scenario (see Section 2). According to step 1, we already discussed the SoS model for the smart grid (see Figure 4). According to step 2, we univocally identified CS interfaces in the former model as listed in Table 1 (step 2). An extract of an interface analysis is shown in Table 2. Each row represents an event with an associated guideword 5 which is exploited to help designers in detecting hazardous events. The last 2 rows identify 2 types of emergent behaviors. The former represent a beneficial emergent behavior caused by the new functionality of the command display: EMG receives additional information on the electrical appliance willing to be switched on. In this case, EMG can forward additional information to the coordinator. For instance, the type of electrical appliance could be communicated to the coordinator, which may optimize the energy consumption accordingly (ie, knowing that the energy requested by a WM lasts longer than the energy requested by a MW). The last row of the table represents a detrimental emergent behavior caused by failed communication between the PEL SM and the PEL EMG (INT_10) which in turn transmits wrong aggregated consumption values to the coordinator (INT_11). The latter will then make possibly wrong decisions on granting the provision of energy thus causing a blackout. Mitigation to this case may consist of implementing a distributed failure detector mechanism to guarantee that at INT_11 information are correctly exchanged and then the coordinator will act on the correct basis.

| SoS profile's integration in a MDE design framework
Adopting the presented profile in a model driven engineering process may be difficult for nonexpert designers in SysML modeling; additionally, scalability concerns may arise with the growing complexity of the SoS. In our perspective, we have considered 7 different viewpoints to break the complexity of design models. But still, having a detailed definition of components and their interactions and attributes adds complexity to the modeling phase. Indeed, even with a small case example the readability of the SoS design using SysML can be already difficult, finally leading to the so-called spaghetti diagrams where the model is composed of a huge number of crossing lines connecting the different blocks. To solve the above problems, it is necessary to adopt graphical approaches which have to be easily integrated in the MDE chain while still being usable also with large scale SoS scenarios.
In addition, SoS designers should be able to conceive an SoS design without having specific expertise of modeling technologies like SysML.
To this end, a new graphical tool shall be adopted to provide efficient design facilities and the compatibility with the MDE chain.
In the rest of this section, we will present a supporting facility tool developed within the AMADEOS project 16 that (1) integrates the SoS profile for enabling the design of SoS, and (2) provides a simple and intuitive design environment extending the modeling capabilities of Google Blockly. 33

| AMADEOS supporting facility tool
The objective of the AMADEOS supporting facility tool is to provide a simple and intuitive way to design SoS combining the SoS profile and the Blockly tool. Blockly 33 is a domain specific language adopted to ease the design of SoS by means of simpler and intuitive user interface  JavaScript, Python, PHP, or Dart code and can be also customized to generate code in any computer language. It has been adopted in different contexts of usage to support the definition of educational games and teaching programming languages concepts.
The AMADEOS supporting facility 6 is a tool to model, validate, query, and simulate SoS. The tool integrates the SysML profile described in this paper thus importing all the terminology and relationships available in the SoS profile. Therefore, all the benefit achievable through the profile can be also achieved through the AMADEOS supporting facility tool, namely, elevating the design from a system to an SoS perspective and decreasing its cognitive complexity.
The editor, based on Blockly, eases the design of SoS by means of intuitive and usable interfaces which do not require any specific SysML technologies expertise, and technological support. Blocks, which represent specific profile stereotypes, can be easily created and deleted by means of drag and drop facilities. As an example, Figure 14 shows representation of the equivalent SysML model. The Python code generated by the tool can be further refined and also can be used to 6 The current version of tool can be accessed at http://blockly4sos.resiltech.com. 7 PlantUML is an open-source tool allowing users to create UML diagrams from a plain text language. URL: http://plantuml.com/.   In this section, we present a viewpoint-driven analysis of related ADL design approaches presented in the literature of SoS. This analysis, whose results are reported in Table 3, is not meant to be exhaustive but it is based on the most representative related works on designing  A partial answer to the above issues is given by the approach presented in Lane and Bohn 39 providing support to structure and evolution viewpoints of an SoS by exploiting several SysML models. The authors propose the adoption of diagrams to determine an evolving

SoS and its environment and the interactions occurring between an
SoS and the environment and among CSs themselves. Noteworthy, the approach is still missing specific support to dynamicity, emergence, and multicriticality viewpoints and although the executable models presented are a first required step to assure dependability/security requirements and responsiveness (time), it still missing a specific support to those viewpoints.
In the SysML modeling approach presented in Rao et al, 40 the authors allow the definition of the SoS structure and how to support dynamicity and evolution viewpoints by means of understanding the dis-alignment of a simulated SoS with respect to its requirements.
The approach makes use of different executable diagrams to simulate Net-centric SoS through the Petri net formalism thus describing the dynamic behavior and assuring that end-user requirements are met.
Noteworthy, the approach 40 is still missing a specific support to emergence and multi-criticality. Concerning dependability and security viewpoints as well as responsiveness (time), the approach, 40 similarly to Lane and Bohn, 39 does not provide any specific support.
The approach presented in Bryans et al 41  The following works are referred here because they focus on different viewpoints in SoS modeling, but they are not in the Table 3

| CONCLUSION AND FUTURE WORK
This paper presented a viewpoint-driven approach to design SoS by adopting a SysML profile. We pointed out the gaps in the literature of ADLs for SoS with regards to a set of viewpoints that we deemed essential for understanding SoS. We outlined the conceptual model at the basis of the profile, and we presented how to solve specific viewpoint needs in an integrated fashion by exploiting the high-level SoS representation in a small scale scenario. We implemented the profile in the Eclipse-integrated development environment jointly with Papyrus, 48 ie, an Eclipse plug-in supporting advanced facilities to manipulating UML artifacts and SysML profiling. We discussed the integration of the profile in the MDE chain and the support for different type of SoS analyses. As an example, we showed how the HA may support the detection of emergent behavior. Furthermore, we discussed the usage of the profile with a MDE tool to support the SoS designer in managing the complexity of SoS models. To such extent, scalability and usability concerns have been discussed.
As future work, we are applying our profile and the Blockly tool to a use case on industrial automation. More in detail, we are currently supporting the design of an automated industrial system, which includes the coordination of autonomous carts for loading and unloading goods, with the ultimate target of resource optimization and of course without compromising safety of personnel and equipment. This case study focuses strongly on, among other, real-time requirements, safety requirements, and planning for positive emergence. We plan to apply the solutions presented in this paper to support the design and the simulation of the targeted SoS.
We also envision the application of the profile and the Blocklybased tool to support the different stages of an SoS life cycle. In fact, as a longer-term objective, we plan to study the application of our solution for verification and validation activities. Concerning verification, the approach is suitable for system analysis: the paper presented an approach for HA, but other techniques can be investigated as well, for example, failure mode and effect analysis and fault tree analysis.
Concerning validation, the SoS model can be the basic layer to define test procedures or resolve problems of testing coverage. This is particularly relevant for SoS composed of several interacting CSs.
A further action, which is nontechnical but it is very relevant for us, is instead on the dissemination side. The profile and the Blockly-