Architectural components are defined within the "SoS Architecture" package (see Fig. 1). This package extends SysML Block Definition Diagram (BDD) in order to model the topology and the relations of an SoS. Blocks in SysML BDD are the basic structural element used to model the structure of systems (Wolfrom) and they can be used to represent: systems, system components (hardware and software), items, conceptual entities and logical abstractions. A Block is 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 in terms of its constituent system and possible relationships.

Fig. 1. SoS Architecture package

The first Stereotype is "entity" and it extends the SysML metaclass "Block". We distinguish between two different kinds of entities: "thing" or "construct". They extend the properties of "entity" and 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:

A system can be influenced by an "architectural\_style", it can provide a communication "interface" and it has a "boundary". A "subsystem" is a subordinate system that is part of a system and it is related to "system" by a composite relation.

A Constituent System or "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" (that is introduced in SoS Communication package). RUMI represents a message interface where the services of a CS are offered to 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 two 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/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. "SOS" Stereotype represents the integration of systems, i.e., CSs which are independent and operable, and which are networked together for a period of time to achieve a certain goal. As expressed by the "sos\_type" Enumeration, an SoS can be:

A Cyber-Physical System ("CPS") is composed by a set of "cyber\_system" (i.e., computer systems), and "physical\_system" (i.e., controlled objects).

#### 3.2 SoS Communication Package

The "SoS Communication" package (see Fig. 2) is composed of CSs that exchange information with other elements. In order to represent the exchanged information during the progression of time we use a SysML Sequence Diagram and we represent a CS not only as a Block entity of BDD but also as "Lifeline" metaclass. "Lifeline" is a metaclass

Fig. 2. SoS Communication package

and part of Sequence Diagrams. Through a Sequence Diagram it is possible to represent the behavior of a system in terms of a sequence of messages exchanged between parts and a "Lifeline" defines the individual participants in the interaction (Constituent System). Moreover, through a "Lifeline" it is possible to describe the temporal behavior of an SoS. The time is showed by the length of the "Lifeline" and it passes from top to bottom: the interaction starts near the top of the diagram and ends at the bottom.

A "RUI" Stereotype represents an external interface of a CS where the services of a CS are offered to other CSs. It extends "external\_interface" (defined in "SoS Interface" package) and guarantees the exchange of information among CSs ("CS" is defined in "SoS Architecture" package). A RUI can be represented also as a Sequence Diagram in which CSs are represented by the lifelines that exchange information. A RUI, can be either a "RUMI" or a "RUPI" and it is monitored through "probes". A RUI connecting strategy is part of the interface specification that searches for desired, w.r.t. connections available, and compatible RUIs of other CSs and connects them until they either become undesirable, unavailable, or incompatible. A RUI, having a "connection\_strategy", is instantiated complying to possibly multiple "dependability\_guarantees" and satisfying "security" constraints.

A "RUMI" represents a message interface for the exchange of information among two or more CSs and extends the "RUI" Stereotype. While messages are exchanged through the RUMI, physical elements are exchanged among the CSs of an SoS through the "RUPI"; physical elements are things or energy.

In this package we also model the concept of a stigmergic channel. This type of channel transports information via the change and observation of states in the environment. To represent a stigmergic mechanism, we have introduced the "environment" Stereotype that is affected by the RUI.

A message is a data structure that is composed by a "data\_field", a "header" and a "trailer" and it flows through a "transport\_service". The main transport protocol classes to send a message from a sender to a receiver are listed in the "transport\_service" Enumeration data type, i.e.:

A message can be classified as:

#### 3.3 SoS Interface Package

The interfaces are the key issue to the integration of systems (see also Chap. 2 of this book) and in this section we introduce an in-depth analysis of the SoS interface concepts, which are represented in Fig. 3.

An interface can be an "internal\_interface" a "physical\_interface", a "message\_based\_interface" and an "external\_interface". The internal interface connects two or more subsystems of a CS (the Stereotype "subsystem", defined in SoS Architecture package, is connected with "internal\_interface" in order to represent this relation). The physical interface consists of three different types of elements, namely "sensor", "actuator" and "transducer". The "message\_based\_interface" allows the transmission of message by means of "message" which are defined in terms of "message\_variable". Finally, the external interface connects two or more CS (the Stereotype "CS" is connected with "external\_interface"). A different type of "external\_interface" is the "utility\_interface", which is an interface of a CS that is used for the configuration, or the control, or the observation of the behavior of the CS. The

purposes of the utility interfaces are to (i) configure and update a CS, (ii) diagnose a CS, and (iii) let a CS interact with its remaining local physical environment that is unrelated to the operative services of the SoS.

The utility interface is specialized into three different types of interfaces:

An interface has a specification ("interface\_specification") with different kind of levels: Interface Cyber-Physical Specification ("cp-spec"), Interface Itom Specification ("i-spec") and Interface Service Specification ("s-spec"). "cp-spec" is extended by "m-spec" that specifies interface properties related to cyber message. "m-spec" is further extended by the "transport\_specification" Stereotype to describe all properties of the communication system for correctly transporting a message from the sender to the receiver(s). "cp-spec" is also extended by "p-spec" which specifies the interfaces properties related to physical interactions. If the interfaces are service-based, this means that the system provides many services. We have introduced the Stereotype "SLA" Service Level Agreement that defines the service relationship between two parties: the "provider" and the "recipient". "SLA" consists of one or more "SLO", i.e., the Service Level Objectives. In addition, we have created a new Stereotype that represents the "reservation". The reservation is a commitment by a service provider that a resource that has been allocated to a service requester (upon request at "request\_instant") at the reservation allocation instant ("allocation\_instant") will remain allocated until the reservation end instant ("end\_instant"). A "registry" contains multiple service specifications allowing multiple "service\_composition" according to the "SLA". A "channel" connects interfaces, and it can be physical or logical ("physical\_channel", "logical\_channel").

The interaction enabled by the channel has the following attributes: "transferred\_info" (every interaction involves the transfer of information among participating systems), "temporal\_property" (an interaction takes time, i.e., for an interaction to occur it is initiated and completed according to system-specific temporal properties) and "dependability\_req" (e.g., interactions might require resilience with respect to perturbation or need to guarantee security properties like confidentiality). Through channel interactions, the information is transmitted by means of messages". A "channel\_model" describes the effects of the channel on the transferred information. An "interface\_model" contains the explanation of the interface. An interface, associated to an "interface\_port" has an afferent and an efferent "interface\_model", which are affected and may affect the interface, respectively. A "connection\_strategy" Stereotype is defined and connected to a RUI.

#### 4 Evolution Viewpoint

Large scale Systems-of-Systems (SoSs) tend to be designed for a long period of usage (10 years+). Over time, the demands and the constraints put on the system will usually change, as will the environment in which the system is to operate. The AMADEOS project studied the design of systems of systems that are not just robust to dynamicity (short-term change), but to long-term changes as well. Evolution represents changes that have been introduced later to accommodate modified or new requirements by means of including, removing or modifying system functions [16].

In contrast to dynamicity, the concept of evolution relates to all changes of an SoS that are not given by design, but arise by changes in the environment (primary evolution), or by new or changed requirements on the SoS service itself (secondary evolution). In the prospect of formalizing a methodology that 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' [16];

#### 4.1 SoS Evolution Package

In order to describe this type of processes we have chosen a Block Definition Diagram, because it is designed to show the generic characteristics and structures of a system.

The main SoS concepts are modelled within the "SoS Evolution" package of our SoS profile. Figure 4 shows the "evolution" Stereotype as a Block of a BDD, aiming at describing an SoS change. In our conceptual model we envision two different types of evolution:

An SoS evolution has a "goal", improves the "business value" by means of the exploit of "system\_resource" and can be affected by the environment. Evolution is achieved by modifying CSs and consequently the whole SoS.

Fig. 4. SoS evolution package

## 5 Dynamicity Viewpoint

Dynamicity is the property of an entity that constantly changes in term of offered services, built-in structure and interactions with other entities. It represents variations to the operation of SoS that have been considered at design-time to reconfigure the SoS in specific situations e.g., either after a fault or after the variation of an external condition [21]. Dynamicity encompasses all interactions, e.g., message exchange over time.

Closely related to dynamicity is the concept of reconfigurability, which is the ability of a system to change its configuration according to the current demands.

The Dynamicity components are described by means of two different packages, i.e., "SoS Dynamicity" (Sect. 5.1) and "SoS Scenario-based reasoning" (Sect. 5.2).

#### 5.1 SoS Dynamicity Package

In this section we show how to use a semi-formal language in order to represent the dynamicity of an SoS. Our objective is to (1) identify which parts of an SoS are dynamic at a certain extent and (2) to represent the dynamic behavior through the interactions among CSs.

As presented in Fig. 5 we have introduced the concept of "dynamicity" (belonging to the already defined stereotype "entity"), which can be applied either to a CS or to a whole SoS. Dynamicity may be of different nature, either "dynamic\_service", or "reconfigurability", i.e., the variation to the CSs architecture, or "dynamic\_interaction". Already defined concepts like "service" and "interaction" are the objects of a dynamic behavior.

Fig. 5. SoS Dynamicity package

Eliciting dynamicity behavior of different nature that applies to different portions of an SoS is not enough to have a full understanding of the dynamic behavior. With this aim, along with the dynamicity package, we have considered interaction diagrams in order to focus on the message interchange between a number of lifelines: Sequence Diagrams. We propose a methodology to be used to represent dynamicity as it follows:

This type of representation helps a system designer to understand which are the properties of an SoS that are constantly changing and how the SoS can change and rearrange its components. The dynamic introduction, modification or removal of constituent systems can introduce new system behaviors that need to be analyzed.

#### 5.2 SoS Scenario-Based Reasoning Package

Scenario based reasoning package aims at supporting dynamicity and evolution of an SoS. By means of this component of the profile we aim at supporting the generation, evaluation and management of different scenarios thus supporting decision-making in an SoS. As shown in Fig. 6, the main concept of this component is "scenario" which is composed by a set of "scenario\_state" each of which associated to an "event" to be applied at each state. A state is in instantiation of a set of "variables" which are relevant for the decision-making. Such variables can be extracted by means of an

Fig. 6. SoS Scenario-Based Reasoning (SBR) package

"inference\_process" and they pertain to a "domain\_model". The latter defines relationships among variables in terms of correlations ("causal\_model") and causation ("causal\_graph") dependencies.

The process of generating scenario results from the "situation assessment" that depends on the "environment". "decision\_making" is the process to select a course of actions among different possible alternate scenarios. A multi-criteria decision analysis "mcda" may be also applied to improve the decision-making process. Finally, scenarios are subject to pruning and updating operations in order to discard non-correct or un-likely scenarios and to update scenarios dealing with newly available information.

# 6 Dependability, Security, and Multi-criticality Viewpoints

In any large system, faults and threats are normal and may impact on the availability, reliability, maintainability, safety, data integrity, data privacy, and confidentiality. Traditional dependability and security concepts [2] like fault, error and failure, have been included in the conceptual model. Dependability integrates the attributes of availability, reliability, maintainability, safety, integrity and robustness, and it can be attained by means of fault prevention, fault tolerance, fault removal and fault forecast.

Security is impacted by threats that impose risks exploiting possible SoS vulnerabilities. It is the composition of confidentiality, integrity, and availability; security requires in effect the concurrent existence of availability for authorized actions only, confidentiality, and integrity (with "improper" meaning "unauthorized").

Confidentiality is ensured by means of encryption. Keys are used for encryption/decryption operations, which can be public or private. In an access control system, the security policy is enforced by what is called the reference monitor, which represents the mechanism that implements the access control model. Authorization assigns permissions, which are defined in a security policy. A security policy relies on trusted systems, which encompass hardware, software or human components.

Multi-criticality aims at integrating together subsystems providing services with different levels of criticality corresponding to different dependability and security requirements [23].

A multi-critical SoS is a system containing several components that execute applications with different criticality, such as safety-critical and non-safety-critical. The architecture of safety-critical applications shall be built taking into account that while some part of the system may have strong safety-critical requirements, other parts may be not so critical.

For example, a railway system is a multi-criticality system, given that it consists of components that deliver services at different criticality levels, e.g., a braking service and a heating service. These components usually adhere to different Safety Integrity Levels (SIL) resulting in a system exhibiting different levels of criticality.

In the following we describe the three different packages supporting the definition of dependability (Sect. 6.1), security (Sect. 6.2) and multi-criticality (Sect. 6.3) aspects. The terminology is based on canonical definitions of dependability and security concerns as defined in [2].

#### 6.1 SoS Dependability Package

Figure 7 shows the key concepts captured within the dependability package. A CS or a whole SoS may require possible multiple "dependability\_guarantee" through the achievement of possible different dependability "metric" by means of possible different "technique".

A technique is exploited to reduce the occurrence of faults: "fault\_prevention", "fault\_tolerance", "fault\_removal", "fault\_forecast".

A "measure" represents a property expected from a dependable system expressed in terms of a quantitative "target\_value": "availability", "reliability", "maintainability", "safety", "integrity", "robustness".

The profile supports the definition of "fault\_containment region", "error\_ containment" and "error\_containment\_region". The first contains components operating correctly regardless of any arbitrary fault outside the region. These components may have erroneous output actions that are alleviated with the definition of "error\_containment", which prevents propagation of errors by employing error detection and a mitigation strategy. This leads to the definition of "error\_containment\_region" which contains more "fault\_containment region" having "error\_containment". A Fault

Fig. 7. Dependability conceptual model.

Containment Region (FCR) is a collection of components that operates correctly regardless of any arbitrary fault outside the region.

#### 6.2 SoS Security Package

This section describes the fundamental elements used by a system designer to represent security aspects of an SoS.

As shown in Fig. 8, we connect the Stereotype "SOS" and "CS" to "security" Stereotype to satisfy the security conditions of an SoS. To this end we use "cryptography" based on symmetric ("symmetric\_cryptography") or public key ("public\_key\_cryptography") infrastructure.

The "encryption" Stereotype represents the process of disguising data in such a way to hide the information it contains. In this way, data exchanged between Constituent Systems are processed using a cryptography key. Three types of key have been represented: "symmetric\_key", "private\_key" or "public\_key". Symmetric key is exploited for symmetric cryptography, while private and public keys for the public-key cryptography.

The information exchanged (also called "data") can be encrypted ("ciphertext"), or not encrypted ("plaintext"); the "decryption" Stereotype represents the process of turning ciphertext to plaintext.

During the cryptography phase the access control ("access\_Control") consists of a set of actions that are permitted or not allowed by the system. Figure 8 shows a "subject" that represents an active user, a process or a device that causes information to flow among objects or changes the system state. A subject may have attributes

Fig. 8. SoS Security package

("permission") that describe how the subject can access to objects. An "object" is a passive system-related devices, files, records, tables, processes, programs, or domain containing or receiving information. Access to an object implies access to the information it contains. The "access\_process" is composed by the "authentication" and the "authorization". The former represents the process of verifying the identity or other attributes claimed by or assumed of a subject or verifying the source and integrity of data. The latter represents the mechanism of applying access right to a subject.

The "reference\_monitor" represents the mechanism that implements the access control model and the "access\_control\_model" captures the set of allowed actions within a system as a policy. The access control follows a "securityPolicy" that represents a set of rules that are used by the system to determine whether a given subject can be permitted to gain access to a specific object.

#### 6.3 SoS Multi-criticality Package

We introduced the concepts of "critical\_service" as a particular type of "service" having a certain "critical\_level" (see Fig. 9). The latter is associated to "dependability\_guarantee" and "security". The definition of the stereotype "service" belongs to the SoS Architecture package where it is linked to CS, i.e., the component, being

Fig. 9. Multi-criticality package

able to provide the service itself. Thus the concept of "critical\_service" is indirectly linked to definition of "SOS" and "CS" by means the definition of "service".

# 7 Time Viewpoint

In an SoS a global notion of time is required in order to:

Time is fundamental since SoSs are sensitive to the progression of time and it is necessary to design responsive SoSs able to achieve reliably time-dependent requirements [9].

The progression of time enables change, i.e., dynamicity and evolution, in SoSs. In the AMADEOS project, it has been concluded that a global sparse timebase – accessible by all CSs – is fundamental for reducing cognitive complexity in understanding aspects related to all non-static investigated viewpoints on SoSs. For example, a sparse global time base allows establishing consistently – across all CSs – a temporal order among sparse events, regardless which CSs originally produced these sparse events.

We express the time-related concepts by adopting the MARTE standard [19]. MARTE is an UML profile that provides support for non-functional property modelling, defines concepts for software, hardware platform modelling, and concepts for quantitative analysis (e.g. schedulability, performance).

We measure time through clocks by defining a clock stereotype that extends the one defined in the MARTE profile. A MARTE Clock Stereotype is considered as a means to access to time, either physical or logical. The MARTE Clock is an abstract class and it refers to a discrete time.

#### 7.1 SoS Time Package

Figure 10 shows a set of main time-related aspects. A Constituent System (defined in SoS Architecture package) can share a clock. The Stereotype "clock" is also defined as a SysML Block in order to model this concept through a Block Definition Diagram. A (digital) clock is an autonomous system that consists of an oscillator and a register. Whenever the oscillator completes a period, an event is generated that increments the register. A "timeline" represents the progression of the time and it is designed with a Stereotype that extends the metaclass "Lifeline" of a Sequence Diagram. The "timeline" is composed by an infinite number of instants ("instant" Stereotype) measured using a "time\_code" and a "time\_scale". A time code is a system of digital or analog symbols used in a specified format to convey time information i.e., date, time of day or time interval. A time scale is a family of time codes for a particular timeline that provide an unambiguous time ordering (temporal order of events).

A "clock" could be based on an "internal\_sync", i.e., on a process of mutual synchronization of an ensemble of clocks in order to establish a global time with a bounded precision, or on an "external\_sync", i.e., on the synchronization of a clock with an external time base such as GPS. It could be a "reference\_clock", i.e., a hypothetical clock of a granularity smaller than any duration of interest and whose state is in agreement with TAI, or a "primary\_clock", i.e., a clock whose rate corresponds to the adopted definition of the second (the primary clock achieves its specified accuracy independently of calibration).

Finally, the clock could have the following properties:

Fig. 10. SoS Time package

If a clock is a "physical clock", we use the "drift" measure in order to describe the frequency ratio between the physical and the reference clock. A digital clock consists of an "oscillator", represented as a Stereotype, with a "nominal\_frequency" and a "frequency\_drift", represented as properties. A "coordinated\_clock" is a particular type of a clock, it is synchronized within stated limits to a reference clock. A "clock\_ensamble" is a collection of clocks operated together in a coordinated way with a certain "precision". We define "gpsdo", a Stereotype that represents a particular type of clock where its time signals are synchronized with information received from a GPS receiver, and "holdover", a property expressing the duration during which the local clock can maintain the required precision of the time without any input from the GPS.

The "timestamp" is the state of a selected clock at the instant of event occurrence. It depends on selected clock and if we use the reference clock for time-stamping, we call the timestamp "absolute\_timestamp". An ensemble of clocks could synchronize in order to establish a "global\_time" with a bounded precision.

An "instant" is a cut of the "timeline" and an "interval" is a section of timeline composed by two instants. The latter is defined as an "IntervalConstraint" of a Sequence Diagram.

An "event" can happen at a particular instant, and to represent this type of information we have used a "TimeConstraint" of a Sequence Diagram. A "signal" is a particular event used to convey information typically by arrangement between the parties concerned. An "epoch" is a particular instant on the timeline chosen as the origin for the time-measurement. A "cycle" is a temporal sequence of significant events whereas a "period" is a specific type of cycle marked by a constant duration between the related states at the start and the end at the end of the cycle, called "phase". The offset of two events denotes the duration between two events and it is represented by the "offset" Stereotype.

#### 8 Emergence Viewpoint

The concept of Emergence (see also Chap. 3 of this book) is one of the most important challenges of AMADEOS. As already described in previous sections, SoSs are built to realize new services that CSs separately cannot provide.

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 un-desired, possibly unexpected situations generated from CSs interactions and to realize desired emergent phenomena being usually the higher goal of an SoS [14].

In the AMADEOS conceptual model, emergence is defined as follows: 'A phenomenon of a whole at the macro-level is emergent if and only if it is new with respect to the non-relational phenomena of any of its proper parts at the micro level'. Consequently, it is behavior observable at the global level (e.g., a traffic jam) that cannot be reduced to the behavior of one of the parts (e.g., a single car analyzed in isolation). If an emergent phenomenon can be explained by a trans-ordinal law, i.e., a law that explains the emergent phenomenon at the macro level from properties or interactions of parts at the micro level, it is explained emergence. In case such laws have not been found (yet), it is unexplained emergence. While there are cases of unexplained emergence (e.g., the human consciousness), the type of emergence that is occurring in the cyber part of an SoS is explained emergence, even if we are surprised and cannot explain the occurrence of an unexpected emergent phenomenon at the moment of its first encounter. If we have made proper provisions to observe and document all interactions (messages) among the CSs in the domains of time and value, we can replay and analyze the scenario after the fact. At the end, we will find the mechanisms that explain the occurrence of the emergent phenomenon. There is no ontological novelty in the interactions of the CSs in the cyber parts of an SoS.

Hence an explained emergent phenomenon can be classified as expected (trans-ordinal laws are known), or unexpected (trans-ordinal laws are not known). Orthogonally, emergent phenomenon can be beneficial, or detrimental.

Hence four cases of emergent behavior must be distinguished in an SoS. Expected and beneficial emergent behavior is the normal case. Unexpected and beneficial emergent behavior is a positive surprise. Expected detrimental emergent behavior can be avoided by adhering to proper design rules. The problematic case is unexpected detrimental emergent behaviour. For an in-depth discussion about emergence in SoSs we refer to [12].

#### 8.1 SoS Emergence Package

In this section we show how to use a semi-formal language to represent an emergent behavior of an SoS. Nevertheless, because of the nature of the emergence concept, defining a semi-formal language, thus only eliciting an emergent behavior, is not sufficient. Our aim is also capturing operational aspects related to emergence by considering an SoS in action.

For these reasons we propose two different types of representation that a system designer can choose:

Figure 11 shows the profile package for the emergence behavior as a block definition diagram.

This package represents the main concepts of emergence using a Block Definition Diagram. We represent a "phenomenon" as a block and we distinguish an "emergent\_phenomenon" from a "resultant\_phenomenon". An emergent phenomenon can be explained ("explained\_emergence\_phenomenon") or unexplained ("unexplained\_emergence\_phenomenon") and in the former case there is a trans-ordinal law ("transOrdinal\_law") that explains the behavior.

An SoS with emergent phenomena has an emergent behavior that could be expected, unexpected, beneficial or detrimental. For this reason, we consequently defined the four following blocks: "unexpected\_and\_detrimental", "expected\_and\_detrimental", "unexpected\_and\_beneficial", "expected\_and\_beneficial".

Fig. 11. SoS Emergence package

# 9 The Profile at Work

In this section we introduce a Smart Grid household scenario to exemplify the application of the profile and to instantiate the basic SoS concepts to a concrete case-study from the Smart Grid domain, focusing on the Architecture (Sect. 9.1) and Emergence (Sect. 9.2) viewpoints. Further examples of application of the profile to the selected use-case can be found in [15] and public deliverable D2.3 "AMADEOS conceptual model - Revised" [1].

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, i.e., keeping the production and consumption rates for connected households balanced.

Figure 12 shows the topology of the main subsystems involved within a single household of the Smart Grid scenario. Washing machines and microwaves are examples of electronic appliances. They represent a flexible load which may initiate an energy request. The smart meter measures energy consumption and production rates; the Distributed Energy Resource (DER) manages the energy produced through energy generating and storage systems, like wind-powered electrical generators or batteries.

Fig. 12. Smart Grid case study

A command display shows consumption rates and enables residents 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 smart meter and in agreement with the coordinator to establish optimal energy distribution. The coordinator is connected to the Neighborhood Network Access Point (NNAP) with the aim of keeping the production and the consumption of energy for a set of connected households balanced. A Distribution System Operator (DSO) regulates consumption and production rates at the country level. By means of its Load Management Optimizer (LMO), a DSO 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 (LNAPs) connected to a NNAP. All the above mentioned components require proper interfaces in order to exchange control messages and physical energy entities within and outside the household Smart Grid.

#### 9.1 Modeling the Architecture Viewpoint

Using the SoS Architecture package it is possible to represent the topology of any System of Systems. Now we show how to use SoS through the Smart Grid household case study.

First of all, it is necessary to decide what are the main constituent systems involved, and how to represent them. For each system component we use a Block element of a Block Definition Diagram and through the connections we show the relations between

Fig. 13. Smart Grid household Block Definition Diagram

them. Using the stereotypes defined in the "SoS Architecture" package it is possible define the Smart Grid household as a system of systems (SoS) and all the other elements as constituent systems (CSs).

Figure 13 shows a model example of a Smart Grid with the application of our profile ("SoS Architecture" package). The "SG\_Households" is a Block and it is stereotyped as an SoS; it is composed by 5 CSs, which exchange information. Among others, the block "Flexible Load" is stereotyped as a CS and it is composed by a set of household electrical appliances: Microwave, Washing Machine, Clothes Dryer, etc. These latter are switched on and off dynamically based on the current needs.

An application example of the main SoS communication concepts is shown in Fig. 14. Through the Smart Grid household case study, we describe a set of communication messages exchanged between the involved CSs.

First of all, it is necessary to decide which are the involved elements in the communication and how many message are exchanged. We identify a "Lifeline" as a constituent system and a "message" as exchange data between two constituent systems. A message could contain all the properties defined in Fig. 2 and they can be displayed using a constraint or a comment box. Figure 14 shows the message properties using a

Fig. 14. Message exchange between CSs of a Smart Grid

comment box (e.g., "data\_field" = 2 kW, "header" = wm to EMG, "trailer" = t1, "trans\_type" = PAR\_message).

#### 9.2 Modeling the Emergence Viewpoint

While a Block definition diagram defines stereotypes and related elements to capture statically the emergence behavior, a sequence diagram is able to define dynamic interactions leading to emergence. We adopt a sequence diagram where each lifeline represents a constituent system and each message specifies the kind of communication between the lifelines, the sender and the receiver. An SoS is prone to changes: sometimes constituent systems are incremented, modified or removed. To this end, this kind of diagram helps the system designer to easily update and analyze new system behaviors. The diagram not only describes the communication but it also helps to represent the SoS behavior during the progression of time.

To show the difference between a "static" and "dynamic" representation of emergence, we consider a particular scenario of the Smart Grid previously described. The dynamicity of the household electrical appliances may lead to an emergent behavior of the system in case of a peak of request of energy coming from the neighborhood. Let us assume that because of a public event, an exceptional lighting of specific public spaces has to be supported by the Smart Grid. In this case, while in the household it was commonly possible to turn on microwave and washing machine together, we end up in a very limited provision of energy, which is not sufficient for both the electrical appliances. This phenomenon represents an emergent behavior of the Smart Grid since it is not possible to devise it if we only look at the interactions of the internal household CSs without considering the neighborhood CSs.

Fig. 15. Smart Grid household – Emergent behavior

Figure 15 shows, through a BDD, how the public event lighting is represented as an explained and detrimental emergent phenomenon, explained by the balancing behavior of the Coordinator and causing reduced energy for the electrical appliances. This phenomenon causes an unexpected and detrimental behavior of the SoS, which allows it to only satisfy a subset of energy requests.

However, using this type of diagram we are not able to represent the progression of time and the semantic of message that may contribute to reveal emergence phenomena. Especially, the above representation does not attach greater importance to capture the time aspects of the SoS emergent phenomena.

We now introduce the representation of the exceeding peak energy request by using a sequence diagram. We adopt a sequence diagram to show the emergent behavior of the electrical appliances request by means of the interaction among related CSs of the Smart Grid.

As shown in Fig. 16, "electronic appliances" CSs are represented as "Lifeline" and their interactions are represented through directed labeled arrows. Washing Machine is switched on at t2 after the agreement allowed from the Coordinator. As next, the Coordinator receives (at time t3) and grants (at time t4) the energy for switching on the public lighting for the exceptional event. This request is forwarded to the Coordinator by the Public Event Lighting (PEL) EMG, which is external to the household. At time t5, microwave issues its request to be connected to the Smart Grid but it receives a negative acknowledgment at time t7. Usually, the household would be able to switch on the washing machine and the microwave at the same time. On the contrary, because of the public event lighting resulting in a peak of energy from the house neighborhood it results that only a reduced amount of energy is available for the electrical appliance (emergent behavior). Indeed, right before the requests issued from the microwave (time t5) and the clothes dryer (time t8), the Coordinator allocates the energy for the public

Fig. 16. Smart Grid household SysML model – Emergent behavior description

lighting event and consequently no further requests of energy from the house can be granted.

This illustrative example shows that networked individual systems together to realize a higher goal, which none of individual system can achieve in isolation, could lead to an emergent behavior: impossibility of satisfying commonly granted energy requests. The Emergent behavior is shown through the message exchange and it consists of unexpected and detrimental emergent behavior caused by a system dynamicity property.

### 10 Related Works

In this section we present an overview of related ADL design approaches presented in the literature of SoSs. This analysis is not meant to be exhaustive but it is based on some of the most representative related works on designing SoSs. Its objective is to determine to what extent viewpoints-based SoS concepts have been already captured in the literature.

In [7] the authors propose the use of SysML in representing an SoS by adopting and in some cases extending canonical SysML diagrams in order to model different viewpoints of an SoS. Beyond structure, a specific support to the multi-criticality viewpoint is also provided by adopting the specific stereotypes aiming at grouping requirements according to qualitative and quantities metrics to support trade-off analysis. Nevertheless, there is no specific support for other viewpoints, including time, dependability/security, dynamicity, evolution and emergence.

A partial answer to the above issues is given by the approach presented in [13] 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, multi-criticality, dependability/security and time. In [20], the presented SysML modeling approach allows 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. Noteworthy, it is still missing a specific support to emergence, multi-criticality, dependability, security and time.

The approaches presented in [3, 8] provide support to model the structure of an SoS and emergence by means of the extension to SysML diagrams. Analyses of the former models are conducted to provide evidence that requirements are fulfilled. The approach supports fault-handling (dependability viewpoint) and responsiveness (time viewpoint) of an SoS, but it does not provide any specific support to dynamicity, evolution and multi-criticality.

The approach in [6], within the context of the DANSE EU project [4], supports the definition of an SoS structure, dynamicity and evolution (by means of Graph Grammars), emergence, etc., with the only exception of multi-criticality. DANSE presented a set of methodologies and tools to model and to analyze SoSs based on the Unified Profile for DoDAF and MoDAF (UPDM). In particular, DANSE focuses on the six models that can be represented as executable forms of SysML as partially reported in [6], according to a well-defined formalism to relate basics SoS concepts and their relationships. In the context of DANSE, the Goal Specification Contract Language (GSCL) assures the achievement of dependability and security requirements and it guarantees the timely response of an SoS.

All these approaches have shown the utility of adopting SysML formalisms to model architectural aspects of SoSs, thus supporting different types of analysis and a first step towards executable artifacts which can be automatically derived. Although these approaches provide detailed insights for different viewpoints aspects, it is still missing (i) an homogeneous synthesis at a more abstract level of key design-related SoS concepts, and (ii) a viewpoint-based vision. Bringing this perspective in one single consistent reference model, it is possible to provide solutions to specific design problems while still keeping the required interconnections among viewpoints.

#### 11 Conclusions

This chapter presented a viewpoint-driven approach to design SoSs by adopting a SysML profile. We pointed out the gaps in the literature of ADLs for SoSs with respect to a set of viewpoints that we deemed essential for understanding SoSs. 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 [5], i.e., an Eclipse plug-in supporting advanced facilities for manipulating UML artifacts and SysML profiling.

The AMADEOS SoS profile can be adopted along with a Model-Driven Engineering (MDE) approach. MDE is an approach to system development and it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. For a model-driven architecture perspective [18], our SoS profile is a Platform Independent Model (PIM) or, in other words, a view of the system from the platform independent viewpoint. It provides a set of technical concepts involving SoS architecture and behavior without losing the platform independent characteristics.

This kind of independent architecture makes possible to analyze step by step all the PIM viewpoints and to obtain one or more Platform Specific Models (PSM), where the SoS profile is specialized and improved according to the domain/enterprise specific technologies that belong to the enterprise implementing the SoS instance. A PSM is a view of a system from the platform-specific viewpoint. It combines the specifications in the PIM with details that specify how that system uses a particular type of platform and on the platform itself.

Furthermore, the SoS PSM can represent the base step for other activities such as the following:

# References

Open Access This chapter is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, duplication, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.

# AMADEOS Framework and Supporting Tools

Arun Babu<sup>1</sup> , Sorin Iacob<sup>2</sup> , Paolo Lollini3(&) , and Marco Mori<sup>3</sup>

> <sup>1</sup> Resiltech SRL, Pisa, Italy<EMAIL_ADDRESS><sup>2</sup> Thales Nederland B.V., Hengelo, The Netherlands<EMAIL_ADDRESS><sup>3</sup> Department of Mathematics and Informatics, University of Florence, Florence, Italy<EMAIL_ADDRESS>
## 1 Introduction

This chapter defines the overall tool-supported "AMADEOS architectural framework", with its main building blocks and interfaces. It particularly focuses on Structure, Dependability, Security, Emergence, and Multi-criticality viewpoints of an SoS. Finally, for SoS modeling, a "supporting facility tool" based on Blockly is demonstrated. Blockly is a visual DSL and has been adopted to ease the design of SoS by means of simpler and intuitive user interface; thus requiring minimal technology expertise and support for the SoS designer.

#### 2 Architecture Framework for SoS

Architectural framework does not refer to the specific design of specific system architecture, but they rather represent a view on how such architecture should be described. Although architectural frameworks are "prescriptive" and not "descriptive", there is still no consensus on providing a methodological step-by-step instruction to be followed. In [1], the authors describe a study involving the use of a design approach to guide the development of an SoS architecture by means of rules, guidance and artefacts for collaboratively developing, presenting and communicating architectures without an order set of phases to carry out. In [2, 3], it is noticed a close relation between architecting methods and the architectural frameworks, thus a step-by-step set of instructions is provided to guide the development of SoS architectures.

When building an SoS architectural framework, the aim is to be instrumental in the creation of future evolvable systems of systems. Both description views and methodology shall be allowed, as long as it facilitates the design of the architecture of such systems.

Architectural frameworks that are currently used in SoS literature have been applied in different contexts of operation along with ADL solutions to model different

This work has been partially supported by the FP7-610535-AMADEOS project.

<sup>©</sup> The Author(s) 2016

A. Bondavalli et al. (Eds.): Cyber-Physical Systems of Systems, LNCS 10099, pp. 128–164, 2016. DOI: 10.1007/978-3-319-47590-5\_5

architectural aspects of an SoS. In the following we provide insights on currently adopted architectural frameworks and ADL approaches.

#### 2.1 ADLs in SoS Architectural Frameworks

This section collects a few ADL approaches that have been proposed in the literature to model different aspects of SoS. They range from approaches dealing with very specific problems to frameworks.

Among the approaches presented in the context of research projects we consider solutions proposed in COMPASS and DANSE EU projects. COMPASS aims at supporting the application of formal analysis tools and techniques at the level of the graphical notations used in current industrial practice. COMPASS project exploits the Artisan Studio tool [4] in order to support system and requirements modelling using SysML as well as software modelling using UML and code generation. As stated in [5] COMPASS proposes the adoption of Context Diagrams, Use Case Diagrams, Block Definition Diagrams and Sequence Diagrams. COMPASS exploits tool's well-established extension mechanisms to extend traditional systems modelling as needed to model SoS. Starting from artefact created with the tool, COMPASS provide a well-defined denotational semantic of SysML blocks by means of the COMPASS modelling language (CML), a formal specification language that supports a variety of analysis techniques.

The DANSE methodology and tools are mainly based on the Unified Profile for DoDAF and MoDAF (UPDM). The latter has also been extended to cover the NATO Architecture Framework (NAF) and it provides more than fifty different model types grouped in eight viewpoints [6]. These viewpoints are: Capability Viewpoint, Operational Viewpoints, Service Viewpoint, System Viewpoints, Service Viewpoint, Data & Information Viewpoint, Project Viewpoint and Standard Viewpoint. In particular DANSE focuses on the six models that can be represented as executable forms of System Modelling Language (SysML).

In [7], the authors propose a formalism for relating basics SoS concepts by means of a UML class diagram. They identify as basic concepts SystemType, System-Of-Systems, Goal, Role, Service, Requirement, Port, Requirement and Port. Consequently, they adopted their defined formalism to instantiate an operative SoS by means of adopting canonical UML diagrams such as Sequence diagram. The behaviour of CS is formalized through Timed Automata and its dynamicity/evolution is achieved by means of Graph Grammars.

An example of modelling SoS by means of SysML is given in [8] where the authors exploit different diagrams and in particular executable diagram in order to simulate Net-centric SoS through the Petri Net formalism. In [9] the authors propose the use of SysML in representing an SoS in general and for a particular applicative scenario. They propose to adopt and in some cases to extend canonical SysML diagrams in order to model different aspects of an SoS. They defined concept Diagram as an extension of class diagrams to depict the top-level systems of an SoS and external stereotypes. This helps in identifying the boundaries between the system and its environment. They adopted the class diagram with an aggregator operator to represent that a component is composed by a set of other components. They proposed the adoption of a requirement diagram with an additional stereotype, i.e., critical requirement which is a particular type of requirement. This diagram groups together requirements according to qualitative and quantities metrics to support a trade-off analysis. They adopt canonical use case diagrams to represent the set of action an SoS performs. The SysML activity and sequence diagram are exploited to represent the SoS at the functional level and its exchanges of messages, respectively. Finally, they exploit a block diagram as a refinement of their concept diagram, which aims at representing blocks/component with well-defined interfaces, i.e., serviceports and flowports.

The approach presented in [10] describes how several SysML models can be used to support a set of needs that the authors deemed essential for an SoS, namely translating capability objectives, understanding systems and their relationships, monitoring and assessing changes, developing and evolving the SoS architecture, addressing requirements and solution options. The authors propose to apply a Model-Driven Systems Development (MDSD) approach [11] to an SoS. The first step consists in determining capabilities and actors through use cases diagrams by defining what is in the system and what remains outside, as stated in a context diagram. Use cases determine the top-level service or capabilities and the major actions necessary to perform the use cases and all of the alternate actions. Finally, two different diagrams describe the interactions, i.e., black box sequence diagram and white box sequence diagram. Black box sequence diagrams show the flow of the requests that pass between the SoS and the environment while white box sequence diagrams depict the flow of requests between the constituent systems, and between the constituent systems and the external entities.

Among others, the approaches presented in this section show the utility of adopting SysML formalisms in order to model different architectural and non-architectural aspects of an SoS. This supports different types of analysis and it represents a first step towards executable artefacts, which can be automatically derived from SysML. As shown in this section, in the literature different attempts exist to apply SysML approaches to specific viewpoints that we deemed essential in providing architecture for Multi-Critical Agile Dependable and Evolutionary SoS. Nevertheless, an architectural framework that provides an integrated support to all these viewpoints is still missing. The architectural framework will benefit of the approaches proposed in the literature in supporting specific viewpoints (when they exist) and it will integrate SysML specific solutions to provide a usable high-level support for designers of SoS.

#### 3 The AMADEOS Architecture Framework

The AMADEOS architectural framework (AF) is described by means of a high-level perspective of activities and artefacts involved in SoS design phases and by its viewpoint-based specialization.

#### 3.1 High-Level View

The high-level representation of the AF is shown in Fig. 1 as a pyramid made of four different layers, namely Mission, Conceptual, Logical and Implementation. Apart from the Mission block, all the remaining levels are organized in slices, each corresponding to a specific viewpoint.

The starting point of the AF consists in defining the Mission of an SoS. The mission is commonly formalized by means of a document of intents created by enterprise managers having in mind a high-level perspective of the system and a clear definition of business-related issues. The document of intents is written in natural language to formalize the overall objectives and functionalities of an SoS starting from a shortened version of the glossary illustrating main SoS concepts and other related mission-relevant arguments.

At the Conceptual Level, it is possible to consider a subset of viewpoints depending on the target SoS and its mission; however in AMADEOS we focus till to collaborative SoS, for which we identify a set of viewpoints that must be considered as mandatory. Inputs to these levels are the document of intents describing the mission, the conceptual model [12] defining main SoS concepts and their relationships and the AMADEOS meta-requirements [13], which can guide the identification of requirements for specific SoS instances. For each viewpoint (corresponding to a slice of the

Fig. 1. AMADEOS architectural framework

pyramid), the SoS is examined and described. The resulting description should be the requirements of the SoS (these can be expressed in natural language, as well as using formalisms for the description of requirements). The identification of relations between the different viewpoints is carried out at this phase.

The Logical Level provides support for designing an SoS based on the viewpoints requirements in the AMADEOS SysML profileand the Building blocks defined in Sect. 4. The output of this phase consists in the platform independent description of the SoS in a semi-formal language (SysML), for the different viewpoints.

The Implementation Level leads to the integration of new CSs with already existing and deployed CSs starting from the logical architecture defined at the previous level and domain/enterprise specific techniques. At this level, the input logical architecture is refined and instrumented with domain/enterprise specific technologies which belong to the enterprise implementing the SoS instance.

We depict in Fig. 2 a process-based view of each level of the AF. We represent the basic task ad the input/output artefacts involved at each level. This gives a more detailed description of the relationships and evolution of the main artefacts produced in each level of the pyramid (see Fig. 1) and the relations between levels (through the top-down processes of refinement and instantiation, and bottom-up processes of generalization and abstraction). The artefacts categories at each level are intended to be generic enough to fit all the viewpoints.

On the Mission Level, a relatively slow-paced cycle takes place to address the continuous synchronization between the operational needs, the currently targeted

Fig. 2. Refinement and evolution of processes in AF design

capabilities of the SoS architecture and the technological possibilities to achieve the needs. At this stage, enterprise managers iterate the above phases to determine the mission of the SoS which is then formalized in a document of intents along with possible target solutions to be implemented.

On the Conceptual Level the alignment between the overall envisioned concepts and the SoS domain takes place more frequently. On this level the AMADEOS concepts which are relevant to achieve the mission are extracted from the document of intents and then filtered based on the viewpoint to which they belong. Further details may be added at each viewpoint descriptions to support the targeted capabilities within the SoS domain. Connections among viewpoints descriptions are identified in an early stage before similar concepts are aligned with each other, if needed.

On the Logical Level, cycles occur at a more rapid pace and are used to ensure that all desired functionalities and qualities are supported by the developed architecture. To this end, building blocks are selected and further integrated to obtain a design model which is generic enough to be applied to different types of platform. The design process follows a viewpoint-based perspective based on which target models are created for each viewpoint. Application specific details are added at this stage before viewpoint models are linked with each other according to the dependencies early identified at the Conceptual level. At Logical level, wrappers for legacy CSs have to be defined in terms of proper RUI interfaces which connect such legacy components to the rest of the logical SoS. Finally, validation activities take place, e.g., either by supporting the generation of models that are correct by construction or through predefined consistency checks. The generation of models, the integration of building blocks and the model consistency checks are made possible by exploiting the AMADEOS profile.

The most frequent cycles occur at the Implementation Level, where the SoS architecture is defined at its most fine-grained level by augmenting it with specific platform-dependent and specific technologies which are exploited by the target enterprise in order to obtain an operational SoS instance. At this stage the possibly available legacy components may be added to the platform-dependent architecture, provided that they have been properly encapsulated in the SoS at the logical level. This implementation model may then be validated through the technologies which are commonly adopted in place by the enterprise. In order for this phase to be supported, it is necessary that specific validation techniques adopted in the enterprise comply with the AMADEOS profile specification. However, it is not the main focus of AMADEOS to provide full support to implementation of single CSs. Nevertheless, this phase includes all the steps from the platform independent architecture to the architecture showing how each and every feature in the product should work and how every component should work. This phase is kept in the framework for completeness.

#### 3.2 Viewpoint-Driven Analysis

The AF has been represented through a high level view which describes the processes of defining an operational SoS instance starting from the mission definition. The architectural viewpoints required for supporting this definition are the ones considered in the AMADEOS vision, i.e., structure, dynamicity, evolution, dependability and security, time, multi-criticality, emergence. We describe in the following how the AF can support the activities required by each viewpoint.

Viewpoint of Structure. The Structure viewpoint concerns with representing the overall structure of the SoS. It focuses on architectural concerns of an SoS and it is closely related to other issues like SoS constraints, RUMI and semantics of communication. Indeed, defining interfaces among CSs is important as this stage to support their communications.

The input to the conceptual level of an SoS is the mission (or vision). This entails the overall objectives of the SoS as well as the required functionalities. The structure viewpoint entails examining these objectives and determining the constraints of the interfaces, and the communication, between constituent systems. Unlike the other viewpoints, the structure viewpoint places restrictions upon the activities of the SoS.

By addressing the meta-requirements in the context of the specific mission, a set of structural requirements can be identified that restrict the overall architecture that will be eventually delivered. For example, from [CONSTR 11], standards compliance of one or more CSs may be very important, particularly in use cases such as in the Smart Energy domain. Also the conceptual model is exploited as the vocabulary of concepts to be adopted.

The output of the conceptual level consists of a set of requirements that relate to the structural architecture of the SoS.

The logical design of an SoS architecture will be based upon the Structure requirements identified at the conceptual level and the building blocks identified along with the SysML profile. The SysML Block Definition Diagram (BDD) is used to model the topology and the relations of an SoS. Blocks in SysML BDD are the basic structural element used to model the structure of systems. A Block provides a unifying concept to describe the structure of an element or a system. This type of diagram helps a system designer to depict the static structure of an SoS in terms of its CSs systems and their possible relationships. By means of BDDs it will be possible to model the static structure of CSs, their interfaces and how the communication among CSs is achieved.

The output of the logical level will be a platform independent SoS architecture specification from a structural point of view. This will consist of the outline of the CSs identified by the requirements and the RUMIs that specify the interactions between these former CSs.

On the implementation level, the platform independent structural design from the enhanced design level is further concretized using specific contextual requirements, towards building the SoS structural architecture. For example, specific CSs may already exist and may need to be integrated. In the structural viewpoint, this will lead to specific RUMIs that are used to define how CSs will interact. These RUMIs consist of the communication protocols that define the messages that will be shared between CSs. The implementation level is very specific to the actual CSs involved and the operational context. The output consists in a fully contextualized SoS structural architecture.

Viewpoint of Dynamicity. Dynamicity refers to short-term changes in an SoS, which occur in response to changing environmental or operational parameters of the CSs. These changes can refer to offered services, built-in structure and interactions with other entities, and may have different effects, such as SoS adaptation or the generation of emergent phenomena.

Starting from the SoS mission, the dynamicity requirements and the conceptual model, the output of the conceptual level is the set of dynamicity requirements, i.e., requirements related to the dynamicity viewpoint for the specific mission. The latter are the input of the logical level which also exploit the SysML profile and the building blocks to support the generate of the platform independent SoS architecture. The building blocks of the SoS management infrastructure defined are exploited to achieve dynamicity requirements, through the monitoring, analysis, planning and execution activities. Instantiation of the profile is connected with the Structure viewpoint of the SoS. Interactions elicited among CS take into account the service provided at the RUI interfaces as regulated by the SLA.

At the implementation level, the generic SoS architecture is instantiated into a platform-specific SoS architecture. This includes, among others, the implementation of RUIs that integrate monitoring and execution features that implement the MAPE-K architecture, and SLA-oriented reconfiguration operations. It results an architecture specialized by the enterprises with their adopted technologies to provide support to dynamicity though a platform-specific architecture.

Viewpoint of Evolution. Large scale Systems-of-Systems tend to be designed for a long period of usage during which the demands and constraints put on the system will usually change, as well as its environment. Evolution is the process of gradual and progressive change or development of an SoS, resulting from changes in its environment or in itself. In managed SoS evolution, the modification of the SoS keeps it relevant in face of an ever-changing environment; whereas in unmanaged SoS evolution, on-going modification of the SoS occurs as a result of on-going changes in (some of) its CSs.

At the conceptual level, starting from the mission, the evolution meta-requirements and the conceptual model, a set of evolution requirements produced. The latter are exploited along with the SysML profile and the building blocks at the logical level. In particular, instantiation of the profile is connected with the Structure viewpoint of the SoS. Interactions elicited among CSs take into account the service provided at the RUI interfaces, and the business value improved by evolution. The logical level results in the platform independent SoS architecture.

The role of the implementation level is to translate the generic SoS architecture into a platform-specific SoS architecture with, among others, evolution aspects. This includes RUI modification, and has a tight connection with the time viewpoint to ensure backward compatible evolution versions. Through the architecture as specialized by the enterprise it is possible to provide support to evolution though a platform-specific architecture.

Viewpoint of Dependability and Security. Dependability and security are essential properties of an SoS since they affect its availability, reliability, maintainability, safety data integrity, data privacy and confidentiality.

The conceptual level, build the set of dependability and security requirements from SoS mission, meta-requirements and the conceptual model. Dependability and security are important to ensure the proper functioning of an SoS. At the conceptual level, the input is the overall objectives and functionalities required to meet the mission of the SoS. Dependability and security requirements are not stand-alone requirements; they are connected to the other requirements, including time, multi-criticality, and others, that compose the set of requirements for the SoS.

At the logical level the Dependability and Security requirements are exploited to define the dependability and security components of the SysML profile There are two packages: "SoS Dependability" and "SoS Security". One of the key concepts in SoS dependability and security is splitting functionalities into well-defined components and interfaces such that the number of components that require explicit trust is kept to a minimum. In the context of the SysML profile, each block in the Block Definition Diagram has interaction points for itoms flowing in and outside the block. We first consider the functionalities required by the SoS and determine how security-critical each functionality is. We then consider what kinds of components make up the SoS and map functionalities to components. The most security-critical functionalities should be grouped together. Thus, the SoS will have a small number of highly-trusted, security-critical components. Less security-critical functionalities will be handled by less secure components. There will be different levels of dependability for each CS and different levels of security for each SoS.

The output of the logical phase is a platform-independent SoS architecture. The latter is exploited at the implementation level to create a platform-specific architecture specialized by the enterprise with their adopted technologies. For defining platform-specific trustworthy CS one could rely on the trustworthiness-enhancing design patterns described in the OPTET project [14]. This comprises a number of UML Patterns, which from the AMADEOS perspective can be seen as Dependability and Security architectural patterns.

Viewpoint of Time. Time does not only play an important role in the control of the physical environment of an SoS, where, for instance, the temporal properties of a control loop impact the efficiency and quality of control. It is also crucial for the information exchange between CSs, as in many cases timeouts and communication delays may decide whether the distinct CSs are able to serve their purposes. Correct handling of time enables the reduction of cognitive complexity required to design an SoS and facilitates the integration of new CSs into the system. On the other hand, undefined timing of communication between CSs might introduce unintended emergent effects.

Time meta-requirements along with related concepts and the SoS mission are exploited at the conceptual level to generate time dependent requirements. System components and functionalities sensitive to the progression of time need to be identified and the requirements on their temporal behavior have to be specified. This mainly comprises requirements on timeliness of interactions between CSs (e.g., the exchange of information to avoid collisions between cars has to take place before the cars collide), and the time synchronization of those CSs (e.g., requirements on the precision of synchronization and time granularity). Since there is a close relation to other viewpoints, like Security, Dynamicity or Emergence, the temporal requirements have to be aligned with the requirements regarding the other viewpoints. Furthermore, the behavior of the SoS in case that some of the temporal requirements cannot be fulfilled has to be specified.

At the logical level the temporal behaviour of the SoS is designed based on the conceptual requirements defined in the level above. The mechanism to achieve a synchronized global time base among all CSs has to be defined (e.g., internal or external synchronization of time). Such a time base allows relating timestamps of different CSs with each other, and thus enables the temporal ordering of events in the SoS. The exact temporal interaction between individual types of CSs is modelled and included in the SysML RUMI specification. A precise temporal specification at this level simplifies the integration of CSs that have been individually designed and implemented at the next levels.

At the implementation level the producer of a CS brings the temporal specification of interactions between CSs into a real implementation using a specific platform. This includes implementing the time synchronization mechanism defined in order to achieve a common time base. As the implementation has to comply with the temporal model of interactions, unintended side effects of temporal misbehaviour are avoided, and hence, the integration of the CS into the SoS is simplified and the instrumented SoS instance is created.

Viewpoint of Multi-criticality. Multi-criticality supports the provision of services of an SoS with different criticality, such as safety-critical and non-safety-critical. Indeed, while some part of the SoS may have strong safety-critical requirements, other parts may be not so critical.

At the conceptual level the definition of multi-criticality requirements is carried out in order to support the definition of services with different criticality levels. To this end, the meta-requirements is exploited according to the SoS mission and using the related SoS concepts.

At the logical level the requirements along with building blocks and the profile are exploited to define the platform independent SoS instance. The SoS architecture and RUMI specification is done so that, recalling the macro-level of the general architecture of an SoS [13], CSs characterized by a specific criticality level n and a macro-level m can rely on CSs characterized by a criticality level greater or equal to their one owned by the same or a lower macro-level.

As stated by requirement [MULTI-CR6] a CS shall not rely on CSs characterized by a lower criticality level than its one. Thus, it is also necessary to have designed a clear architecture profile which details the structure of the SoS, detailing the interaction among the CSs. In this way it is possible to verify the correctness of the interaction among the CSs checking for violations of the aforementioned requirements. In the case that a CS offer several services that are characterized by different criticality levels, then a precise specification of the RUMI building block can help to preserve both the FCR and ECR, making failure propagation from non-critical services to critical one impossible.

At the implementation level the SoS Logical description (platform independent) is specialized by exploiting the enterprise-specific technologies based on specific enterprise technologies and it will result in a platform-specific instrumented SoS architecture and RUMI specification.

Viewpoint of Emergence. Emergence is an intrinsic property of the SoS and it concerns with novel phenomena that manifest at the macro-level (i.e., at SoS level) which are new with respect to the non-relational phenomena of any of its proper parts (i.e., CSs) at the micro level. The rationale behind emergence is that by composing CSs, either positive or detrimental global emergent phenomena may occur. Managing such phenomena can help avoiding unsafe unexpected situations generated from safe CSs, and may help eliciting positive emerging phenomena.

 For non-detrimental emergence, it is desirable, but not mandatory to monitor, analyse and predict emergence phenomena. Emergence may be influenced or generated by modifications to the Structure (e.g., adding new components which introduces new functionalities, or adding new components that may change the error model, e.g., introducing new Itoms which enables new interoperability between CSs), dynamicity and evolution (making the system able to make changes to the way its CSs interacts with each other and how the system is aligned with changing business requirements). Note that emergence phenomena may cause violations to handling of time, dependability and security of the SoS/CS.

In the Conceptual level, starting from the SoS mission, the meta-requirements and basic SoS concepts, we identify the instantiated emergence requirements.

The Logical Level concerns with applying the profile to identify emergence and categorize it according to the strength and predictability of effects. Because of the nature of the emergence concept, in we deemed not sufficient to simply elicit an emergent behaviour. We also consider worth capturing operational aspects related to emergence by considering an SoS in action. For these reasons, in we consider two possible diagrams to represent emergence through Block Definition Diagram and Sequence Diagram. The building blocks defined in Section Y support the monitoring, analysing, planning and executing mitigating activities required by the emergence management requirements. The instantiation of the profile should be tightly connected with the Structure viewpoint of the SoS. Interactions elicited among CS should be defined according to the Request-Response model and take into account the service provided at the RUI interfaces as regulated by the SLA. For supporting early identification and mitigation of emergence, particular attention has to be devoted to the interactions through stigmergic channels. The design process will also consider application and domain specific details which will be added by the designer. Finally, validation activities will check the correct application of building blocks, their integration and the usage of SoS domain specific concepts (possibly available through an SoS profile).

The platform independent architecture resulting from the logical is instantiated, configured and to linked the architectural elements, which support the achievement of the emergence requirements through the implementation of a platform-specific instance.

Evolutionary Aspects. A SoS evolves over time as constituent systems are modified, replaced or added, or due to its relevant environment (gradually) changes. This evolution is driven by incremental, new, and changing requirements of the SoS. An architectural framework for SoS should provide a tool aimed at predicting possible evolutionary paths based on anticipated requirements and use-cases.

Scenario-Based Reasoning for SoS Architecture Design. In architectural systems engineering the use of scenarios is not uncommon. It is a cost-effective means of controlling risk and to maintain system quality throughout the processes of software design, development and maintenance [15, 16] Preparing for evolution of an SoS, a scenario-based approach can also be adopted to guarantee that the development that an architecture undergoes is sensible, i.e. it must guarantee that the quality goals of the system are still met.

By using scenarios to guide the design of an SoS architecture, the context of the envisioned SoS is incorporated into the possible design choices by the architect. Established scenarios provide a narrative, which enables communication about future requirements and capabilities between different stakeholders [16]. Scenario-based design is a user-based approach in which different use-cases of a system are defined by narratives, from which a lower-level description of the system can be extracted. However, not every SoS can be described by narratives focused around use-cases and user interactions. Moreover, a narrative provides the intended use of a system from the perspective of a single expert or end-user, whereas in the context of SoS single use-cases are more related to the constituent systems than to the SoS as a compound structure. Therefore, a more methodical approach is needed, in which multiple experts can define relevant states and variables that may describe the possible evolution of the SoS and its relevant environment.

Scenario-based reasoning (SBR) [17] provides a methodical approach to generate and explore scenarios. In the SBR approach, scenarios are built from a set of variables, and each combination of variable states makes up a single scenario. Relevant scenario variables are those that influence the design of the system, such as variables that denote for example: environmental conditions, organizational dynamics, economic conditions, technological development, and interactions with the system form a user perspective. Such variables can have dependence relations between them which are, for example: causal, functional, influential, or probabilistic. For instance, enabling a certain security feature in the system will typically have an influence on its usability.

SBR enables what-if exploration to reason about possible future conditions and consequences for the architecture of an SoS. Through the analysis of different scenarios and their dependencies, inconsistencies can be revealed that may have consequences for the eventual architectural design of the system. Through the identification (also generation) of scenarios from a model describing the context under which the SoS will be deployed and the possible future uses of the system, evolving requirements may be elicited. By thinking about how to operationalize these requirements, insights are acquired about how they map to the architectural design of the system.

Figure 3 shows a small sample model from an environmental point of view, from which possible scenarios can be extracted for analysis. It depicts causal relations

Fig. 3. A small example causal model for SBR

between the possibility of providing financial incentives for electrical vehicle use and energy production by consumers. Increased popularity of these use-cases in turn has an effect on the load placed on the local neighborhood grid.

## 4 The AMADEOS Building Blocks

In this section, we present the AMADEOS architectural building blocks which are exploited in the AMADEOS architectural framework.

#### 4.1 SoS Management Infrastructure

The SoS management infrastructure in terms of a set of patterns which are applicable to enact monitoring, analysing, planning and execution strategies. The latter are developed as highly-dependable services, which we deemed essential for an SoS architecture. In order to implement the support to the above services we got inspired by the literature of Autonomic computing [18] which is a promising approach for a dependable architecture of very large information systems [3]. In particular, we propose to adopt the well-known MAPE-k cycle to implement the above services through Monitoring, Analyze, Plan and Execution components.

Our idea is to implement such patterns by means of composing CSs interacting with each other through well-defined RUI interfaces. These patterns are: (1) Hierarchical Control, (2) Master/Slave, (3) Regional Planner, (4) Coordinated Control and (5) Information Sharing. Patterns (1), (2) and (3) implement the so-called Formal Hierarchy, while patterns (4) and (5) implement the Non-formal hierarchy. We recall that Formal hierarchy and Non-formal hierarchy have been discussed in Chap. 3 of this book.

Formal Hierarchy. In a Formal hierarchy any CS at level n is controlled by a CS at level n + 1. It follows that the MAPE components are placed in the CSs forming the controlling level, i.e., level n, while controlled CSs are placed at level n – 1. We consider three possible instances of this pattern as follows. The Hierarchical Control pattern consists in having a CS implementing all the MAPE phases (see Fig. 4).

In the Master/Slave pattern (see Fig. 5), the controller CS implements A and P, and then delegate to additional CSs M and E (Fig. 5).

In the Regional Planner (see Fig. 6) the controller CS implements only the Plan phase while it delegates to a set of CSs Analysis, Monitoring and Execute phases. The CS implementing the Plan phase operates for a region of CSs for which it is responsible.

Non-formal Hierarchy. In a Non-formal hierarchy CSs at level n – 1 interacts with the others at the same level by creating a whole at the level n. It follows that all controlled CSs and the CSs implementing the MAPE components are all placed at the same level, i.e., level n – 1. Two possible implementations are as it follows.

Fig. 4. Hierarchical control pattern

Fig. 5. Master/Slave pattern

Fig. 6. Regional planner pattern

In the Coordinated control pattern (see Fig. 7) each of the CS at level n implements all the M, A, P and E phases. The latter coordinate their operation with corresponding peers of CSs at the same level (Fig. 7).

In the Information Sharing (see Fig. 8) is similar to the Coordinated control pattern but only interactions between Monitors are allowed.

Patterns composition. Each pattern presented in the earlier section exploited CSs at two possible abstraction levels. For the hierarchical control, we have at the higher level the managing CSs implementing the control of managed CSs which, in turn, have been represented as black boxes. For the holarchycal control, we have managed and managing CSs all at the same abstraction level, where all the managed elements are represented as black boxes, as well. The application of the above patterns may be applied compositionally and recursively by arbitrary replacing the managed CS by any other pattern.

Fig. 7. Coordinated control pattern

Fig. 8. Information sharing pattern

Finally, in addition to the presented patterns, a CS, being it a managing or a managed element, may interact with the physical environment by implementing the MAPE components. To this end, we introduce the atomic pattern as shown in Fig. 9.

Communication Infrastructure. The communication among the MAPE building blocks is achieved by appropriate interfaces whose nature depends on the objective of the communication, either physical entities or messages. Consistently with the AMADEOS conceptual model, we adopt RUMIs to support the communication among MAPE blocks for managing SoS, since we only require the exchange of information, i.e., Itoms, and not physical entities (which would require RUPIs). Indeed, in the presented management infrastructure, our MAPE blocks do not receive physical entities but simply messages, which can be sent/received within a single CS or across CSs. Those messages have been graphical represented in the pattern as yellow envelope items. The only exception is the atomic pattern, which supports the interaction with the physical environment and consequently it requires the adoption of RUPIs to exchange physical entities. Noteworthy, we only represent RUIs to support the communication of MAPE blocks, which span different CSs while we neglect to consider MAPE interactions within a single CS.

Fig. 9. Atomic pattern

#### 4.2 Resilient Master Clock

Resilient master clock (RMC) is a resilient fail-silent master clock based on satellite-based time synchronization (e.g., GPS or Galileo signals), to provide a dependable global time base for cyber-physical Systems-of-Systems in AMADEOS.

# 5 The RMC Is Detailed in Chap. 6 of This Book. Supporting Facilities for AMADEOS

#### 5.1 Introduction

The supporting facility tool<sup>1</sup> is used to model, validate, query, and simulate an AMADEOS based SoS using the Blockly tool<sup>2</sup> . Blockly is an open source library for building visual programming editor or a visual DSL (domain specific language). Blockly has been adopted to ease the design of SoS by means of simpler and intuitive user interface; thus requiring minimal technology expertise and support for the SoS designer. Its main features are: (i) Fast, and only a modern web browser is required; (ii) Intuitive and simpler user interface; (iii) Easily extendable with custom blocks; (iv) Ability to check constraints at design time (user defined and pre-defined constraints) and warn user when the user makes mistakes; and (iv) Support code and XML generation.

The supporting facility tool is a generic SoS designer in accordance with the AMADEOS conceptual model and for this the Blockly tool has been customized to be used for SoS modelling. The flow of model-driven engineering using the supporting facility tool is depicted in the Fig. 10. The SysML meta-model is first transformed to Blockly blocks. These blocks could be used in the supporting facility tool to create an SoS model.

The main motivation of supporting facility tool is: the current SoS design tools are complex and non-intuitive for general SoS designers; also, many of the existing tools expect designers to be well-versed with object-oriented concepts. The goal of supporting facility tool is to simplify and provide means to rapid modelling of SoS using the SysML profile (meta-model). In traditional modelling environment, large models have been known to be difficult to design and maintain; and often leading to spaghetti diagrams. The tool aims to reduce the complexity by using collapsed views instead of lines to connect blocks. Also, the tool aims to warn user of common errors/mistakes during modelling and helps in quicker testing of SoS through simulation. The main advantage of using the supporting facility tool is that the SoS designer need not have deep knowledge of SysML/UML; the tool hides all the object-oriented concepts from the user and provides full compliance with the AMADEOS profile. The only prerequisite is high-level knowledge about the profile and knowledge of the supporting facility tool usage.

<sup>1</sup> http://blockly4sos.resiltech.com.

<sup>2</sup> https://developers.google.com/blockly/.

Fig. 10. Flow of MDE using the supporting facility tool

The supporting facility simplifies the task of SoS modelling by reducing the prerequisites to start modelling. Once the supporting facility is installed on a web server, it can be accessed from any machine using a modern web-browser. It can also be used locally without the need of a web server. It provides rapid modelling, validating, code-generation, and simulation facilities to the user. The supporting facility can generate three outputs: (i) the model in XML, (ii) Python code-generated for the simulation, and (iii) PlantUML version of the model.

PlantUML is a simple text based UML format which can be readily integrated with many tools<sup>3</sup> . The exported model in PlantUML may be used for further refinement or formal analysis. For example: the PlantUML model can be viewed in Eclipse using plug-ins<sup>4</sup> . Though, full interpretability between tools is an ongoing research topic and is under investigation.

<sup>3</sup> http://plantuml.com/running.html.

<sup>4</sup> http://plantuml.com/eclipse.html.

Fig. 11. An example subset of SysML meta-model to be transformed to Blockly

Python is a general purpose portable language, and the Python code generated by the tool can be further refined and also be used to connect to other simulators or external systems for interaction while running simulation.

As the supporting facility tool is based on the SysML profile (the meta-model) derived from the AMADEOS conceptual model, the SysML (in XML) is transformed into Blockly by using PlantUML as an intermediary language. PlantUML is chosen as an intermediate format as it is a simple text format which makes debugging during the model transformation easier. Below is an example of model transformation from SysML in Papyrus/Eclipse to Blockly (Figs. 11 and 12).

#### 5.2 Modelling SoS

When the tool is launched, it creates a default SoS block called "example\_block" as an example. All the blocks required to build an SoS can be found in the toolbox on left hand side. These blocks are imported from the AMADEOS SysML profile provided by a profile expert. Each block in the tool contains information taken from the AMADEOS

Fig. 12. SysML (Fig. 11) imported to Blockly

conceptual model to guide the SoS designer. For example, help for CS block can be found by right clicking a block and selecting Help. Also, each imported block in Blockly is associated with a viewpoint/building-block, for example all blocks associated with Communication viewpoint is present in the Communication category in the toolbox.

Traditionally, Blockly requires users to drag and drop blocks from flyout/toolbox to create new blocks. To improve usability and correctness, a Blockly API: Blockly. FieldDropdown() is used to show the list of blocks compatible to be connected for a given block; this lets the user create blocks in an easier way. Figure 13 shows an example, where to add a Technique block, the tool shows that the following new compatible blocks can be added: "Fault forecast", "Fault prevention", "Fault removal", and "Fault tolerance". In the profile, Technique is an abstract block and the above four blocks inherit the Technique block.

A block once created can have three views, (i) collapsed view, (ii) partially-collapsed view, and (iii) uncollapsed view as shown in Fig. 14. Collapsed view allows the user to reduce the number of blocks screen on the screen and to focus on the current editing block. Partially collapsed block only shows the non-empty attributes of a block hence the designer may choose to view only the attributes defined. Full view/uncollapsed view is used to see all the attributes of a block. A user can cycle between the three views by double-clicking the block.

Fig. 13. Aiding user to add new blocks through dropdown

Also, for each block it is possible to see the attributes related to selected viewpoints/building-blocks as shown in Figs. 15 and 16. This is achieved by providing a mutator button for each block at top left hand side.

To provide an intuitive modeling environment, the supporting facility uses a readily available open source plug-in called Type-Indicator<sup>5</sup> . This plugin indicates all the blocks compatable (with yellow color) with current block while it is being dragged, as shown in Fig. 17 (the block cs4 is currently being dragged).

Requirements Management. Requirements management is an important aspect of an SoS design, where traceability of requirements must be viewed/monitored. Requirements may be divided based on the viewpoints and building-blocks: Architecture, Communication, Dependability, etc. Each block maintains the list of requirements it meets and each requirement block maintains the list of blocks which satisfy it; thus offering full traceability (Figs. 18, 19, and 20). Blockly also supports adding comments to blocks to make the design clearer.

Constraints in the Model. Each block exports a list of variables in JavaScript which can be used to define constraints. These variables are defined in the format: block. <relation\_name>\_<block\_type> (For e.g. a CS block exports block.provides\_service). Also, each block exports shortcut variables in the form block.m\_<block\_type> (e.g. for a CS block, block.m\_service). Instead of "block" keyword, a shortcut variable "b" may also be used.

For multiple inputs, a dictionary variable in the form "d\_<variable\_name>" is also exported. This variable is used to access variables by using block name as a key (e.g. for an SoS, Using the variable block.d\_cs['cs1'] the CS in the SoS having name cs1 can be referred. Constraints make a model precise, the constraints provided by the tool uses JavaScript's "eval" function to evaluate the constraints and change the color of block to black in colour if the constraint is not satisfied. The constraints are evaluated at

<sup>5</sup> https://github.com/HendrikD/blockly-plugins/tree/master/type-indicator.

Fig. 14. Three ways to view a block (i. Collapsed, ii. Partially-collapsed, and iii. Un-collapsed)

each onchange event of block. Constraints rely on the variables exported by a block. Figure 21 shows an example use of constraints.

Constraints may also be used to detect causal loops which may lead to emergence scenario in SoS (Fig. 22).

Model Querying. On large models it is difficult to visualize the entire SoS, and then the need for custom viewpoints arises. Blockly does not use lines to show relationship between blocks and uses collapsed views to hide the complexity of an SoS model. Model querying can be used search for blocks which satisfy a given condition (using a query). It may also be used to visualize a model in traditional view (i.e. showing blocks and its relationship with other blocks using lines). To query a given model, a user can right click on workspace and choose "show query diagram. In the query diagram, user may write a filter function for querying the model. For example, return true; indicates that no filtering is required (i.e.: show all blocks for the model depicted in Fig. 23); which results in the graph as shown in Fig. 24. Using the filter "return b.

Fig. 15. Viewpoints/building-blocks of a block can be enabled or disabled

of\_type == 'RUMI';" which indicates to highlight all blocks of type "RUMI", this query returns the graph depicted in Fig. 25 (note that b is a shortcut for variable block). Model querying helps in visualizing custom viewpoints of SoS and can be helpful in identifying issues in the SoS design.

Adding a Link to a Block. One way to design a SoS is by using links to existing blocks. Creating links can help reuse an existing block; however, this is different from copy-pasting a block in blockly. Links are reference to the linked blocks. For example: CSs can be created on workspace and only links may be added to the SoS block, as shown in Fig. 26.

Fig. 16. Filtered view of SoS

Fig. 17. Use of Type-Indicator Plug-in (compatible connections for cs4 are indicated by yellow colour) (Color figure online)

Fig. 18. Example of blocks related to requirements management

Fig. 19. Each block can satisfy a requirement (by providing the requirement ID it satisfies)

Fig. 20. Traceability of requirements

Fig. 21. An example of a constraint where the member variable m\_valid is checked

Grouping for Modular SoS Design. The supporting facility allows grouping of compatible blocks together to modularize the design. For example, all CSs can be grouped together as shown in Fig. 27. The group block helps in organizing the model into meaningful groups. Also, when a block of a group blocks is refered, the group name is indicated to distinguish it from other blocks which may have similar names.

#### 5.3 Simulation Environment for SoS

Behaviour. Once a static model is defined, behaviours may be added to any block. To add a behavior, the user can right click on the interested block, and choose "Add behavior". The behavior represents the code to be executed during simulation, and can be written in Python programming language (as shown in Fig. 28). The function names

Fig. 22. Detecting emergence in model through constraints

Fig. 23. Model querying large models (for query "return true;" i.e. show all blocks)

init, start, and run can be defined and are executed during initialization, start of the block, and during the course of simulation respectively.

The run function for a service block has a special meaning and is exposed as a TCP/IP server. All the behavior code written for all blocks are integrated in to a single file for code generation.

XML and Code Generation. After the model is loaded, it can be exported to XML and code for simulation by clicking on the appropriate buttons on the top right hand side of

Fig. 24. Result of "return true;" query

the tool. Unique object names are generated for all blocks in a format: <blocktype>\_<block-name>\_<block-id>.

Simulator Components. The simulator is a set of Python programs meant for executing the desired scenarios created by designer (the scenarios may also be represented using sequence-diagrams). The simulator consists of the following main components: Object initializer, Registry, Sequence diagram, GUI, Runtime sequence diagram, log generator, and Clock.

Object Initializer. The simulation initializes each object/block defined in the model using the block's constructor. Single inputs are considered as strings/integers/object; whereas multiple inputs are considered as array. If a value for single input is not provided, its value is considered as None in Python; whereas for multiple inputs it is considered as an empty array [].

Certain blocks such as CS/Wrapper/Roleplayer/CPS can have a member called "cardinality" (Fig. 29). It indicates number of objects to be simulated. This is implemented by using copy.deepcopy () function of Python on the original object. Each instance is assigned a \_instance\_id (1 to N); where N is the cardinality specified in the

Fig. 25. Result of "return b.of\_type == 'RUMI';" query (select all RUMIs)

model. Example: the below model creates an SoS called MySoS and has 200 CSs having name cs1. Each of the CSs will have \_instance\_id attribute from 1 to 200.

Registry. Registry is one of the main components of the simulator. It is a service that maintains the list of services offered by various CSs registered in a SoS. It is used by the CSs to search for a particular service. In the simulator, the registry is implemented as a TCP/IP server, where CSs can add/remove/update their own service information. Having a known common registry allows the possibility to run the simulation across several computer systems connected together.

Sequence Diagram. Blockly blocks related to sequence diagrams helps to create non-ambiguous sequence diagrams, which can be readily converted to code. Simulator follows the exact sequence as defined in the sequence-diagram created by the user. Thus, the code generated from the sequence diagram (Fig. 30) is executed right after the simulator has been started and initialized. A sequence diagram is added to model to simulate a scenario (Fig. 30); the sequence diagram designed in supporting facility tool

Fig. 26. Reusing an existing block (cs1) using links.

Fig. 27. Similar blocks can be grouped together

Fig. 28. Example of behaviour for a service

Fig. 29. Specifying the cardinality for CS – cs1

can also be visualized in classical sequence by right clicking the sequence diagram block and selecting "load sequence diagram". This loads the sequence diagram in sequence diagram window, which can be viewed by right clicking workspace and selecting "Show sequence diagram".

GUI. The GUI of the simulator is the starting point of the simulator, and it lets the user select the systems to be run on the current machine and displays the progress of the simulation by logging activities performed by blocks (such as CS/RUMI, etc.).

Runtime Sequence Diagrams. Given the sequence diagram created by the user, the simulator starts executing the sequence diagram. While executing, each activity performed by RUIs are logged as sequence diagram in PlantUML format by adding timestamp to each activity. This creates a runtime-sequence diagram (in result.seq file), which shows what actions have occurred with its timestamp. The runtime-sequence diagram also shows the delay between each action.

Fig. 30. Sequence diagram in supporting facility tool using Blockly

Log Generator. The logs generated by the simulator can be saved in a file and can be used to compute the metrics of interest. These metrics may indicate the quality of SoS by measuring performance/delays/failures etc.

Clock. The simulator uses the system clock of the machine on which the simulation is running. However, it is possible to setup an experimental setup in which, each CS runs on different machine using different clocks. These clocks could be synchronized with a master clock e.g. the RMC developed in task D 4.4 [19]. Faulty scenarios (regarding time synchronization) are also possible to generate by perturbating local clocks of each machine, or by removing master clock from the network.

Simulator Code Organization. The code generation of the supporting facility tool generates a ".zip" file in the format "<model-name>.zip", which contains the complete code for the simulation. The simulator code is created for each model based on the specified sequence diagram. The generated code when extracted is organized as shown below (the model name is "sos-model"):

The top directory name is in the format "SoS-Simulation-<Date-and-Time>", which hosts two executable code files: "simulation-on-unix.sh" and "simulation-onwindows.bat"; both are meant to start simulation on UNIX-based and Windows-based machines respectively. The model-<Date-and-Time>.xml file consist of model in XML format.

The "src" folder contains the simulator code, the constructor code for each blocks, and initialization code of the block objects created in the model. The entire code consists of the following files:

#### (1) amadeos.py

This file contains all the constructors for each block defined in the SoS profile from the conceptual model. This file may be edited to add/refine additional generic classic functionalities.

#### (2) model\_behaviour.py

This file contains the behaviors for each block defined during the SoS modelling. The behaviours are associated with each instance of a block and not for each class. Thus the behaviour for one object will not be shared by other objects of the same class.

#### (3) sos.py

This is the main simulator code which is started by "simulation-on-windows.bat" or "simulation-on-unix.sh" file. This code sets a random seed for random number generation, creates the registry, sets global data for simulation, and starts the user interface for simulation.

Also, this file contains code that starts the simulation by starting all systems as a thread, runs the code related to the sequence diagram, and waits for all threads to join.

#### (4) sos\_gui.py

This file contains the GUI code for selecting the systems to be started on the running machine. Also, this file contains code for showing the log of activities performed by each CS.

Running the Simulation. After the code generation, a user can start the simulation by launching the file "simulation-on-unix.sh" or "simulation-on-windows.bat" (Fig. 31). When the simulation starts, a GUI is shown that allows the user to select the list of systems to be started, and the registry IP address and port. An example GUI is shown in Fig. 32. After selecting the list of systems to be started, the user can start simulation by clicking the "Start simulation" button.

Simulation Over a Network of Computers. The SoS simulation may also be performed over a network of computers. This is achieved by maintaining a common registry machine; thus forming a distributed system running various AMADEOS based systems in each of the computer systems communicating through TCP/IP.

This also allows the possibility of the simulator to interact with real legacy-systems. Each machine can run a set of systems (CSs/Wrappers/Primemovers). When run, a

Fig. 31. Simulator code directory structure

separate thread is created for each selected system; and each system initializes itself and starts its RUIs in separate threads.

Example Run of an SoS Simulation. This section describes and the steps for running the simulation using an example simulation of a SoS model designed in the supporting facility tool. An example SoS may be launched from the dropdown found on the top left hand side of the tool.

#### 5.4 Prerequisite to Run Simulation

As simulator code is written in Python 2.7, the pre-requisite to run simulation is an installation of Python version 2.7<sup>6</sup> . On Windows it is preferred to install Python at c: \Python27, which is the default option provided by the installer.

#### 5.5 Starting the Simulator

As mentioned earlier, the simulator code will be generated as a file in the form "<sosname>".zip, containing a src folder and two files: "simulation-on-windows.bat" and "simulation-on-unix.sh".

The simulator starts when the user runs the script "simulation-on-windows.bat" or "simulation-on-unix.sh" depending on the operating system.

For security reasons, on some versions of Windows it may be required to right click on the "simulation-on-windows.bat", click to properties, and check "Unblock" this file.

When the simulator starts, it shows a GUI (Fig. 32), where the user can specify the list of systems to be started on the current machine. After system selection, the user may click "Start simulator" to start the simulation. The user can see the log of activities appearing during the simulation on the GUI (Fig. 32).

After the simulation run, the user may close the GUI. The simulator generates the result of the current simulation, i.e., message passing between RUMIs and interactions between RUPIs - as a run-time sequence diagram in a file called "result.seq".

<sup>6</sup> https://www.python.org/download/releases/2.7/.

Fig. 32. Start-up GUI of simulator

The result is saved in the same directory where the simulation was run. This file can be viewed by a PlantUML viewer or a sequence diagram-viewer available in the supporting facility tool by right clicking on workspace and selecting "Show sequence diagram". The sequence diagram frame can be extended to fit the page, and the user can use the "Browse button" in sequence diagram frame to load the "result.seq" file.

# 6 Conclusion

This chapter has introduced the architectural framework and supporting facility tools for AMADEOS based SoS.

This chapter has showcased the features of the supporting facility tool, focusing on simplicity and intuitiveness in modeling and simulating an SoS. The supporting facility tool also demonstrates the possibility of: design, validation, querying, simulation of system of systems. Case studies using the supporting facility tool will be presented in Chap. 8.

#### References

Open Access This chapter is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, duplication, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.

# Time and Resilient Master Clocks in Cyber-Physical Systems

Andrea Ceccarelli1(&) , Francesco Brancati<sup>2</sup> , Bernhard Frömel<sup>3</sup> , and Oliver Höftberger<sup>3</sup>

<sup>1</sup> Department of Mathematics and Informatics, University of Florence, Florence, Italy<EMAIL_ADDRESS><sup>2</sup> Resiltech SRL, Pisa, Italy<EMAIL_ADDRESS><sup>3</sup> Institute of Computer Engineering, Vienna University of Technology, Vienna, Austria<EMAIL_ADDRESS>
## 1 Introduction: Challenges for Time-Aware Cyber-Physical Systems-of-Systems

#### 1.1 On the Role of Time in Cyber-Physical Systems-of-Systems

Since many years, it has been acknowledged that the role of time is fundamental to the design of distributed algorithms [21]. This is exacerbated in cyber-physical distributed systems, and consequently in Systems-of-Systems, where it is sometimes impossible to say which one of two observed environmental events occurred first.

Computers, and consequently constituent systems (CSs), use at least a basic mechanism for local time keeping, in the form of incremental timers. In fact, each autonomous CS has its own oscillator that swings freely and is uncoordinated with respect to the oscillation of the oscillator in any other autonomous CS. These oscillators are often adequate to make local duration measurements, generate alarms by time-out, etc. However, there are reasons for resorting to clocks that give you an absolute notion of time. Clocks are the only way to achieve tightly synchronized actions of an ensemble of nodes in a System-of-Systems [23].

For example, synchronized clocks make it possible to measure the duration of some action that starts in one node and ends in another node [22]. This is a common requirement in many applications, where the duration between events that occur in the environment of the different CSs of an SoS must be determined. It is not possible to measure the duration between events that occur in the physical environment of different CSs if no global notion of time of adequate precision is shared by all CSs of the SoS.

If a global timestamp is assigned to every significant event, then the duration between any two significant events occurring at any place within the whole SoS can be

This work has been partially supported by the FP7-610535-AMADEOS project.

<sup>©</sup> The Author(s) 2016

A. Bondavalli et al. (Eds.): Cyber-Physical Systems of Systems, LNCS 10099, pp. 165–185, 2016. DOI: 10.1007/978-3-319-47590-5\_6

calculated easily. For example, we can consider the temporal validity of real-time data. An observation of a dynamic entity, e.g., the state of traffic light, e.g., green, can only be used for control purposes within a validity interval that depends on the dynamics of the entity (the traffic light). If the observation of the environment is performed by a CS that is different from the CS that uses the observation, then, based on the timestamp of the observation, the user can determine if the given observation is still valid to use at a particular later instant [1, 2]. Given that such a global SoS time is available, this global time can be used to radically simplify the solution of many other temporal coordination problems in an SoS [1, 2].

As an SoS is sensitive to the progression of time, such global notion of time is required in order to [2, 6], amongst other: (i) enable the interpretation of timestamps in the different CSs; (ii) limit the validity of real-time control data; (iii) synchronize input and output actions across nodes, with specific reference to stigmergic and messagebased information exchange; (iv) specify the temporal properties of interfaces; (v) perform prompt error detection; (vi) strengthen security protocols; (vii) allocate resources conflict-free (e.g., in time-triggered communication, scheduling).

A dependable global (physical) time is thus needed to establish the backbone of the temporal infrastructure of an SoS. Every CS in the SoS that is subject to physical time requirements should be able to measure time with an appropriate precision, and achieve a quality of time synchronization which is deemed sufficient [24]. Such a dependable global (physical) time is a fundamental requirement for time-aware SoS, although we remark that it is well-known that it is impossible to precisely synchronize the clocks in a distributed computer system. A measurement error in the timestamps of events is unavoidable. This measurement error can lead to inconsistencies between the actual and recorded temporal order of events [1, 25].

#### 1.2 Towards a Dependable Global Time-Base

In an SoS, external clock synchronization is the preferred alternative to establish a global time, since the scope of an SoS is often ill defined and it is not possible to identify a priori all CSs that must be involved in the (internal) clock synchronization. A CS that does not share the global time established by a subset of the CSs cannot interpret the timestamps that are produced by this subset. The preferred means of clock synchronization in an SoS is the external synchronization of the local clocks of the CSs with the standardized time signal distributed worldwide by satellite navigation systems, such as GPS, Galileo or GLONASS. Standalone satellite navigation systems are based on receivers processing GNSS (Global Navigation Satellite Systems) satellite signals. GNSS currently have two core constellations: Global Positioning System (GPS) of the United States and the Global Navigation Satellite System (GLONASS) of the Russian Federation. Other similar systems are the upcoming European Galileo positioning system, the Japanese Quasi-Zenith Satellite System (QZSS), and the proposed COMPASS-Bediou Navigation System of China.

Reasons which may affect the availability and signal quality of the standalone satellite navigation systems and related algorithms, and consequently quality of clock synchronization, have been extensively discussed in literature e.g., a comprehensive overview can be found in [18, 19]. Special considerations related to the availability of GPS signal refer specifically to mobile CSs. GPS is not available in building or under roofing (e.g., in a wood), which is very likely to (temporarily) happen for mobile CSs. Such mobile CSs that operate on batteries are energy sensitive. Since a GPS sensor is very expensive in terms of consumed energy these mobile applications can benefit by switching off the GPS whenever possible and as long as possible, still maintaining the required synchronization quality.

Additionally, it should be considered that GPS may be subject to deliberate attacks, which even when detected timely they still make the GPS signal unavailable for the whole duration of the attack [5]. Amongst these, we mention [20] (i) jamming GNSS based vehicle tracking devices to prevent a supervisor's knowledge of a driver's movements, or avoiding road user charging; (ii) rebroadcasting ('meaconing') a GNSS signal maliciously, accidentally or to improve reception but causing misreporting of a position; (iii) spoofing GNSS signals to create a controllable misreporting.

In a report from the US Government Accountability Office (GAO) to the US Congress [3] on "GPS-Disruption—Efforts to Assess Risks to Critical Infrastructure and Coordinate Agency Action Should be Enhanced" it is pointed out that many of the large infrastructure SoSs in the US are already using GPS time synchronization on a wide scale and a disruption of the GPS signals could have a catastrophic effect on the infrastructure. In this report it is noted that a global notion of time is required in nearly all infrastructure SoSs, such as telecommunication, transportation, energy, etc. and this essential requirement has been met by gradually using more and more often the time signals provided by GPS, not considering what consequences a disruption of the time distribution, either accidental or intentional, has on the overall availability and function of the infrastructure [6].

Even more recently, on 4 February 2016 the BBC reported that "several companies were hit by hours of system warnings after 15 GPS satellites broadcast the wrong time, according to time-monitoring company Chronos" [4]. This led to serious problems to many companies that resulted in money loss.

These events just confirm existing warnings from different communities. For example, a Report from the UK Royal Academy of Engineering in 2011 [20] suggests that the U.K. may have become dangerously over-reliant on satellite-navigation signals, and too many applications have little or no back-up were these signals to go down. The report concludes that several concerns are bounded to GNSS. First, non-GNSS based back-ups are often absent, inadequately exercised or inadequately maintained". Second, that the jammers are easily available and that most jammers are able to block GPS, GLONASS and GALILEO. Third, a full picture of the dependencies on GPS and similar systems is missing.

Starting from the above concern, we can conclude that we should not entirely rely on satellite navigation systems to build a dependable global time base in time-aware SoS. Following this observation, this Chapter presents the design and development of a resilient fail-silent master clock based on satellite-based time synchronization (e.g., GPS or Galileo signals), to provide a dependable global time base for cyber-physical Systems-of-Systems. Such Resilient Master Clock (RMC) is intended to feature low power consumption, low weight and low cost. The RMC should be built with hardware Off-the-Shelf (OTS), as for example COTS MEMS sensors, and whenever possible software OTS.

The RMC includes an independent oscillator and GPS devices complemented by acceptance tests. In fact, software clock control techniques are devised in order to:

When the satellite-based time synchronization signal fails (or it is corrupted by a security incident), for a certain amount of time, the RMC is able to maintain its clock close to the global time within a required accuracy until the satellites signal becomes available again.

The rest of the section is organized as follows. Section 2 presents the architecture design of the Resilient Master Clock. The successive Sects. 3 and 4 explore the main technical solutions that are included in the Resilient Master Clock, that are respectively intended to discipline the clock when the GPS signal is unavailable, and to provide a self-estimation on synchronization uncertainty. Section 5 presents conclusions.

# 2 Resilient Master Clock (RMC) Architecture

This section discusses the architecture of the RMC. The presentation of the architecture is generic i.e., it is not bound to a specific board or pieces of hardware. For example, in Sects. 3 and 4, two different instantiations of (part of) the RMC on two different boards will be described.

The architecture of the RMC is represented in Fig. 1, and described below. In Fig. 1, the components in light grey are required hardware and software components that should be available for the selected OTS board. Dark grey components identify instead the components that have been devised and developed when building the Resilient Master Clock.

The architecture of the RMC is divided in three layers: the board (or Hardware layer), the Operating System (or OS layer) and the Middleware. Each layer consists of the different constituent blocks which are herewith described.

Fig. 1. Resilient Master Clock architecture.

Board Layer. The building blocks of this layer are hardware components. These are:

OS Layer. This layer includes a local software clock (SW Clock) which is usually created by Operating Systems starting from the hardware clock and that provides the timestamps to the services executing on the board.

Middleware Layer. This layer includes OTS SW components (Synch, master PTP) and SW components that are specific for the RMC. In particular, these are the following.

Synch. The Network Time Protocol (NTP [17]) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. NTP is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC). Since RMC is based on TAI, it should be remarked that conversion UTC-TAI is trivial [26]. A synchronization module (Synch) based on the Network Time Protocol (NTP) uses the GPS time signals to discipline the local clock.

MasterPTP. The Precision Time Protocol (PTP, [7]) is a protocol used to synchronize clocks throughout a computer network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. PTP is defined in the IEEE 1588-2008 standard. A master Precision Time Protocol (PTP) module is available on the RMC, and it allows broadcasting a time synchronization packet according to the protocol IEEE 1588 PTP to the nodes of the subnetwork to which the board is connected through Comm.

R&SAClock. The R&SAclock uses the offset and drift obtained from the synchronization module to estimate the uncertainty of the time provided by the local clock over time.

Clock Drift Compensation (CDC). The CDC module generate a clock-drift compensated Pulse Per Second (PPS) signal when the GPS signal is unavailable. The compensation mechanism provided by the CDC module is based on: (i) the values measured by the dedicated sensors (e.g., temperature), and (ii) a-priori knowledge of the frequency deviation caused by environmental changes on the onboard crystal oscillator (e.g., temperature variations).

Checker. A checker module checks the uncertainty associated to the time of the local clock provided by the R&SAclock; consequently, it decides if the RMC can be considered a reliable time source and allows or blocks the PTP synchronization. For example, it can be implemented as a process which periodically checks the quality of the local time provided by the R&SAClock. On the other hand, when the quality of the local time is outside acceptable thresholds, the PTP synchronization beans must be stopped because the RMC cannot be considered a time reference.

# 3 The Clock Drift Compensation Module

This section discusses the Clock Drift Compensation (CDC) module that provides a periodic Pulse Per Second (PPS) time signal to the Synch module (cf. Fig. 1). During normal operation, the CDC module forwards the high quality, externally provided time signal (e.g., generated by a GPS receiver). In case the externally provided time signal becomes unavailable, the CDC module switches seamlessly without interruption of the output PPS signal to holdover mode until the external time signal becomes available again. During holdover mode the CDC module internally generates the output PPS time signal for the Sync module from a local clock based on a common (quartz) crystal oscillator. This local clock is drift compensated with respect to the – now in holdover mode unavailable – external time signal. The drift compensation improves the precision of the internally generated PPS time signal and consequently allows for a prolonged holdover duration compared to a crystal oscillator based clock that is not clock drift compensated.

In the following subsections we detail our clock drift compensation method and present a proof-of-concept prototype implementation which we used for calibrating and evaluating the CDC module.

#### 3.1 Compensating the Drift of Clocks Based on Crystal Oscillators