Keywords

1 Introduction

A System of Systems (SoS) is composed of (in most cases, existing) heterogeneous sub systems chosen for their capabilities, assembled and interfaced to interact during a time-frame and to provide capabilities to achieve a mission that each sub system cannot fulfil alone [1]. First, some characteristics of sub systems must be preserved: operational and managerial independence, evolutionary development, geographic distribution, and connectivity. Second, requested interactions induce emergent phenomenon (new properties and behaviours with more or less predictable and unwanted effects) at the SoS level that can favour or affect the achievement of its objectives and mission. Third, it is now recognized, for SoS, the relevance of specific properties called “-ilities”. An “-ility” Footnote 1 is an “ability to respond to changes, both foreseeable and unforeseeable” focusing on “how the SoS should be and not what it should do” [2]. For a SoS, “-ilities” differ from authors, but essentials ones remain: robustness, resilience, flexibility, adaptability, survivability, interoperability, sustainability, reliability, availability, maintainability and safety; each “-ility” can be strongly dependant or influenced by various causes considering SoS context, evolution period of its life cycle and emerging phenomenon. So, architecting a SoS implies to study these “-ilities” and how to increase or decrease their values thanks to their interest for the SoS purpose. Particularly, SoS has to face up, efficiently and accordingly to its mission, to various dynamic contexts in which disturbances can occur due to disruptive actions (from SoS environment or internal sub-systems failures [2]) or to new and enabled technological evolutions i.e., it has to maximise its resilience. The here presented work aims to help and support resilient SoS design, particularly architecting step of the design. Section 2 introduces two approaches for resilient SoS architecting that can be combined with a behavioural modelling approach named OMAG, briefly introduced. In Sect. 3, retained SoS “–ilities” and their interdependence are discussed and formalised. Section 4 illustrates the proposed contributions before concluding.

2 Resilient SoS Architecting

Architecting a resilient SoS means to consider various interdependent “-ilities” and new design approaches. References [3, 4] insists on “designing for resilience is about creating a system that can bounce back from something no one ever thought would happen”. Existing approaches are strongly based on system paradigm and follows Systems Engineering principles [24]. In the next we discuss about requested “–ilities” and two approaches.

Various “–ilities” definitions can be found [6–8]. The concept of “–ility” can be used to characterize both SoS and each of its sub-systems. As illustrated in Fig. 1, it is admitted that an “–ility” dynamically vary and is dependant or influenced all along SoS life cycle depending on (1) its characteristics (properties, behaviours and “–ilities”), (2) the characteristics (properties, behaviours, and –ilities) of its sub-systems, and (3) emergent properties and behaviours from sub-systems’ interactions.

Fig. 1.
figure 1

Overview of “-ilities” dependencies [7]

Full size image

For instance DoD [6] presents resilience as dependant from robustness, flexibility and protection “–ilities”. Following the same dependence principles, robustness depends from reliability, availability, survivability and maintainability. In the same way, the DSTA framework [2] considers two levels of SoS “–ilities”: Key SoS “–ilities” (robustness and evolvability) and Key Enabling “–ilities” (flexibility (operational and design) and interoperability) that have been enriched in Fig. 2 by decomposing interoperability definition.

Fig. 2.
figure 2

Key SoS “–ilities” and enabling “–ilities” (inspired from DSTA framework [2])

Full size image

In both cases, whatever the definition for “-ility” and its interdependence with other abilities of the SoS, an “–ility” remains difficult to conceptualize from a unified manner (that can be even not expected), to handle and to use in confidence in architecting process [9–12].

Concerning SoS architecting approaches, first SAI (SoS Architecting with Ilities) [8] focuses on value sustainment of both functional and non-functional requirements. Figure 3 shows the essential steps of SAI, especially the steps 4 (Generate initial architecture alternatives) and 6 (Evaluate potential alternatives) in which a behavioural model of the SoS architecture is built and executed for evaluating the chosen “-ilities” defined in step 3. Second, DSTA framework [2] is a methodological framework for supporting SoS architecting and a reference framework for choosing the most relevant “–ilities” allowing practitioners and manager to drive and manage efficiently SoS architecting. In both approaches, the SoS architecting phase (i.e., defining strategy, requested operations and scenarios, and specifying architectural alternatives according to a more or less high level of abstraction) is apart from SoS designing phase (for instance, choice and interfacing of sub-systems, validating scenarios). In design phase, several solutions are proposed in [10] to improve various “–ilities” to gain resilience e.g. employing redundancy, reducing complexity or improving reparability. Alternatives solutions must be modelled and compared thanks to an expected value (quantitative or qualitative) level for each “-ility”.

Fig. 3.
figure 3

SAI principles approach [8]

Full size image

To this purpose, the behavioural modelling method OMAG can support both SAI steps and DSTA framework to describe simply and to link the behaviours of a SoS and of its sub-systems. This approach is enriched by the formalisation of a set of “–ilities” by properties allowing their checking or evaluation.

3 SoS Behavioural Modelling: OMAG Method

OMAG (Operating Modes Analysis Guide) [13] is a behavioural and functional modelling and analysis method allowing:

  • System architect to select the Operating Modes [14] that characterize a system all along its life cycle.

  • To determine gradually the expected Properties (functional and non-functional i.e. “–ilities”) and Parameters of the system when evolving into a mode.

  • To determine gradually and to model various Operational Scenarios. It is question of a functional model describing the dynamic of a system (what are the expected functions or activities and how they are chained and synchronised?) in a given operating mode. Various modelling languages can be used e.g. BPMN, eFFBD, or use case diagram. In OMAG approach, each operational scenario describes a part of the whole expected functional architecture of the system.

OMAG is based on a graphical grid shown in Appendix, detailed and illustrated in [13]. Briefly, the OMAG principles are summarized in Fig. 4. Considering a system, OMAG requires defining first systems’ attributes and to gather them into a ParametersAndPropertiesSet. An attribute is modelled as a Parameter, a valued and typed data describing time (temporal aspect e.g. maximum delays for reaction), shape (structure e.g. geometric constraints) or space (situation e.g. non-functional expectation) characteristics of any element from the system or its environment.

Fig. 4.
figure 4

OMAG main elements meta model (simplified view)

Full size image

The ParametersAndPropertiesSet is set up and grows up gradually all along the architecting process. The set of generic Operating Modes and Transitions is then formalised by the grid and the architect must select those relevant for the system and to be studied. Each transition is characterized by a couple (condition/event) allowing system evolving from an operating to the next. For each mode and transition, architect has to model what are the expected operational scenarios allowed in the studied Mode or induced/expected to fire the transition. Figure 4 shows the main elements of a grid OMAG allowing to describe and link operating modes, operational scenarios associated to each mode, parameters and properties of a system. The result is a behavioural model of the studied system conforms to the underlying mathematical formalism (inspired from Finite State Machine model [15]). Each operating mode is modelled as a state and each mode transition as a state transition. An operational semantic of OMAG grid is given in [13] specifying formally with no ambiguity the interpretation and execution rules of an OMAG grid. This allows then defining and implementing OMAG grid simulation and proof mechanisms not detailed here. These mechanisms allow to model and verify properties (modelling properties as non-functional properties), to approximate “–ilities” values, or to highlight rapidly some disturbing or awkward situations the SoS has to face. This can be helpful for SoS architect who intends to test and compare various SoS architectural alternatives as requested, for instance, in SAI approach.

4 SoS –ilities and –ilities Dependence Modelling: Property Concept

A ‘property’ is defined in [18] as “an entity that can be predicated of a thing or, in other words, attributed to it (also called ‘attribute’, ‘quality’, ‘feature’, ‘characteristic’ or ‘type’)?. [19] introduced a Property-Based Requirements (PBR) theory based on semi-lattices on which a property formalizes a portion of a well-formed requirement (denoted wf-requirement) and be owned by a system. In this case, a property is interpreted as a variable to be quantified or qualified to evaluate the relevance and adequacy of a system solution; such an evaluation is to be carried out by using a model of the system here, an OMAG grid. [20] postulates that a property is any descriptor of an artefact (i.e., a modelling artefact of the system). The property is represented as a mathematical function defined for this artefact, associating a (set of) value(s) allowing evaluating the solution described by this artefact. [21, 22] define a property as “the formal statement of an expectation by using a formal language, i.e., in the form of a logical formula to be proved later”.

These definitions are merged as follows and adopted in the CREI property modelling language (Cause Relation Effect Indicators) proposed in [16, 17]:

[A property is] a provable or evaluable (i.e., quantifiable or qualifiable) characteristic of an artefact [that is (1) a system S, or (2) a model M of S built for achieving a design objective] that translates all or part of stakeholder expectations to be satisfied by this artefact.

The goal is to help managers, architects and designers to formalise “what is” and “how” can evolve an “–ility” of a SoS i.e., how it can be influenced or dependent from (1) other characteristics of SoS, (2) conditions taking into account external and internal events, but also (3) characteristics related to each sub-systems of SoS or resulting from their interactions.

A CREI property is formalized as a composite entity made up of a group of causes (C) correlated with a group of effects (E) via a parameterized and constrained relation (R) between C and E describing the condition and the expected effects under which the property is satisfied. This relationship formally describes how the set of causes C induces a modification in the entire set of effects E. Moreover, a set I of indicators can be associated with R to make property assessable. These indicators are the observation variable and Design variables Footnote 2 [20]. For the formalization, we define the set Φ as the set of user-defined or predefined properties of the studied system. A CREI Property CP is defined as:

  • CP ::= < reference cp , C, R, E, checkingValue cp , [I, evaluationValue cp ] >

With:

  • reference cp ∈ S is a handle (unique) for property proof traceability.

  • C = {vi /vi ∈ ParametersSet ∪ Φ, i ∈ [0; card(ParametersSet ∪ Φ)]}, i.e., C can be empty (C = ∅): the property is then considered to be an own property Footnote 3, otherwise (C <> ∅) as a composite property Footnote 4.

  • E = {vj /vj ∈ F ∪ Φ, j ∈ ]0; card(F ∪ Φ)]} i.e., E <> ∅.

  • R:: = < T p , θc, θe, relationType, θi >, where:

    • T p  = C ∩ E is the set of variables that may be simultaneously used for describing causes and effects.

    • θc: T k p x C m x ℝ+*n→ {True, False } defines the Boolean function describing the condition under which the causes of C are interpreted. By default, the function θc returns True (denoted θc = True in the next):

    • (t1, …, tk, c1, …, cm, r1, …, rn) → θc(t1, …, tk, c1, …, cm, r1, …, rn) ∈ {True, False }

    • θe: T o p x E p x ℝ +*q → {True, False } defines the Boolean function describing the condition under which the effects of E are interpreted. By default, the function θe returns False (denoted θe = False in the next):

  • (t1, …, to, e1, …, ep, r1, …, rq) → θe(t1, …, to, e1, …, ep, r1, …, rq) ∈ {True, False }

    • At this stage, relationType models the relation to be checked: ‘C implies E’, ‘C is equivalent to E’, or ‘C influences E’ formalized as follows:

      • ‘C implies E’ is defined as the logical function: θc ⟹ θe

      • ‘C is equivalent to E’ is defined as the logical function: θc ⟺ θe

      • ‘C influences E’ is defined as the function: θc ⇢θi θe. This relation is defined by [23] as “in knowing with certainty C, we can then deduce E with certainty”, i.e., knowing the values (and their variation) of the causes defined defined in E by defining an influence factor θi ∈ [−1,1] allowing to interpret a beneficial vs. harmful influence as follows:

        • θi → 0: the influence exists between the causes and effects remaining more or less neutral (by default, θi = 0);

        • θi → 1: each variation of the variables used in C induces a variation of the variables used in E, interpreted as beneficial for the system;

        • θi → −1: each variation of the variables used in C, induces a variation of the variables used in E, interpreted as harmful for the system;

    • checkingValue cp is set to True, else False (i.e., if a checking technique can be applied on the model for proving the property CP and can conclude CP is satisfied, False otherwise, thus providing a counterexample).

    • (optional) [I, evaluationValue cp] I ⊆ ParametersSet is a set of indicators that can be evaluated to characterize the truthfulness of the property CP (e.g. in case of simulation or for guiding the appraisal): I = {ij /ij ∈ ParametersSet, j ∈ [0, card(ParametersSet)]}, where ij is a Modeling Variable extracted from the system model. In case of I is defined, then CP.evaluationValue cp = μ(I), where μ is the aggregation function chosen for the evaluation, e.g. μ can be defined by μ :: = 1/card(I)*∑ I (i.value). CP can be considered as satisfied as proposed in [19] i.e. CP.checkingValue cp = True if and only if ∀i∈I, i.value ∈ i.objectif ∧ i.value ∈ i.valueset otherwise not satisfied, i.e., CP.checkingValue cp = False.

As an illustration, we focus on the next on the interoperability of each sub-system making up the SoS, considering the ‘key enabling –ility’ role of this characteristic [2] and its direct influence on the objectives of resilient SoS architecting project.

For this, we consider (see Fig. 5) there are some dependencies to respect (evaluated by using 5 levels of dependencies from preferred to forbidden) between the operating modes of the SoS and the operating modes of sub-system at each moment, taking into account their dynamical evolution. For instance, when the SoS works and fulfil the mission (SoS is in Operating Mode O3), it seems important (++) that a maximum of sub-systems can be able to provide their own mission, and to operate efficiently (sub-systems have to be preferably in Operating Modes O1 to O5). Some of these sub-systems can also (+) be under deployment (operating Mode D1) for instance if these sub-systems have to replace existing sub-systems at a given moment, assuming then architectural evolution of the SoS. Conversely, it seems inacceptable (–) that a sub-system must be in dismantling operating mode (EL1 or EL2). These interdependencies are, of course, indicative: architect can modify them without any impact on the property formalisation and analysis that follows. Other tables can be built for maintainability, resilience or robustness as expected in [2].

Fig. 5.
figure 5

Operating modes dependencies considering requested interoperability

Full size image

The interoperability characteristic of the SoS is formalized as the property P as follows:

  1. 1.

    Cause : = ∀OMSoS ∈ OperatingModes(SoS); OMAG grid behaviour is translated into symbolic logico-temporal formulae. Each transition between Operating Modes selected by architect is modelled as an Elementary Valid Formula (EVF) [26] modified as followsFootnote 5:

    • EVF :: =  (OM i ∧ event j ∧ condition k ⊃ oOM l ∧ scenario m)

    With:

    • OM i and OM l are propositional variables modelling the source and destination operating modes of the transition, and set to True if the studied system is in the corresponding operating mode, false otherwise.

    • event j and condition k are propositional variables set to True if event and condition associated to the transition are True, false otherwise.

    The entire list of EVFs defines a symbolic and formal description of the behaviour of the OMAG grid. Similarly, a Unified Valid Formula (UVF) is computed by taking EVFs into consideration. Here considered, an UVF is the set of conditions i.e. θc which specifies how a given Operating Mode OM can be activated:

    $$ \begin{array}{*{20}c} {\theta_{c} : = UVF(oOM_{SoS} ) = } & \vee & {\mathop {\text{OM}}\nolimits_{SoS} \wedge \mathop {\text{event}}\nolimits_{q} \wedge \mathop {\text{condition}}\nolimits_{r} } \\ {} & {(p,q,r)} & {} \\ {} & {\mathop {\text{OM}}\nolimits_{SoS} \wedge \mathop {\text{event}}\nolimits_{q} \wedge \mathop {\text{condition}}\nolimits_{r} \supset oOM_{SoS} } & {} \\ \end{array} $$
  2. 2.

    Relation : = (influences); Indicators are user-defined and computed including parameters associated to sub-systems e.g. the latency time or interoperation time as proposed in [25].

  3. 3.

    Effect : = SSi ∈ SubSystems(SoS); Fig. 5 shows how dependency vectors (denoted V++, V+, V*, V- and V—) are computed regarding each state of the SoS for a top down analysis of the dependence relations. We focus on the preferred states of the sub-system i.e., those characterized by a dependence relation ‘++’. The state vector V of the SoS (resp. sub-system) is 1 × 18 vector defined as follows:

    $$ \exists !{\text{k}} \in \left[ {1,18} \right], \left[ {\left( {{\text{V}}\left( k \right) = = 1} \right)\mathop \Rightarrow \limits_{SoS is in OMi} \forall j \in \left[ {1,18} \right],j \ne k, \left( {{\text{V}}\left( j \right) = = 0} \right)} \right] $$

    (there are 18 possible operating modes in the current OMAG grid and the sub-system SSi must be in one and only one operating mode OMk)

    So θe is defined as follows:

    $$ \forall {\text{i}}, \left[ {\left( {V\left( {OM\left( {SS_{i} } \right),t} \right)*V_{ + + }^{T} = = 1} \right) \wedge \neg \mathop \prod \limits_{{T_{k} }} \left( {condition_{i} \wedge event_{i} } \right)]} \right] \vee \left[ {FVU(oOM\left( {SS_{i} } \right)} \right] $$

Where:

  • Tk is the set of output transitions from the preferred operating mode OM of the sub-system SSi that is preferred when SoS is in operating mode OMSoS.

  • \( \left( {{\text{V}}\left( {{\text{OM}}\left( {{\text{SS}}_{\text{i}} } \right),{\text{t}}} \right) * {\text{V}}_{ + + }^{\text{T}} = = 1} \right) \wedge \neg \mathop \prod \limits_{\text{Ti}} \left( {{\text{condition}}_{\text{i}} \wedge {\text{event}}_{\text{i}} } \right)] = = 1 \) iff SSi is in the state OM and will stay in this state at the next moment or if the state OM will be activated at the next moment.

The same computation process is used for determining θe in the case of dependence relation that indicates the operating mode of SSi is acceptable, neutral, not recommended or forbidden. In the same way, the same computation approach is used in a bottom-up analysis regarding the dependence relations between each operating mode of each SSi and SoS operating mode.

Simulation (following operational semantics given in [13]), evaluation of parameters and the generation of counter examples provided by checking technique proposed in [26] and developed in [27] are suitable for allowing architect to detect (1) modelling errors or mistakes, (2) unwanted or unexpected behaviour inducing non-functional properties variation. Figure 6 shows a big picture of the overall approach consisting to use OMAG and properties modelling, checking and evaluation in SAI approach.

Fig. 6.
figure 6

Overview of the approach (big picture)

Full size image

5 Conclusion and Perspectives

A demonstrator of the OMAG grid and properties modelling tool is currently being tested. The automated properties building, taking into account various version of dependence tables, properties checking and OMAG grid simulation techniques are under development by using framework developed in [27]. The goal is now to test the overall approach on relevant case studies. The perspective is to enrich the two aforementioned analysis techniques when facing problematic of growing up models’ size and complexity (e.g. due to number of OMAG to be considered).