Modelling System of Systems Interface Contract Behaviour

TL;DR

This paper enhances the modelling of System of Systems interfaces by integrating SysML, CML, and OCL to specify contracts and explores interface automata for verifying contract compatibility, demonstrated through a streaming case study.

Contribution

It introduces an enriched contract modelling approach using SysML, CML, and OCL, and investigates interface automata for verifying compatibility in System of Systems.

Findings

Enhanced contract specification with SysML and OCL improves clarity.

Interface automata facilitate verification of contract compatibility.

Case study demonstrates practical applicability in content streaming systems.

Abstract

A key challenge in System of Systems (SoS) engineering is the analysis and maintenance of global properties under SoS evolution, and the integration of new constituent elements. There is a need to model the constituent systems composing a SoS in order to allow the analysis of emergent behaviours at the SoS boundary. The Contract pattern allows the engineer to specify constrained behaviours to which constituent systems are required to conform in order to be a part of the SoS. However, the Contract pattern faces some limitations in terms of its accessibility and suitability for verifying contract compatibility. To address these deficiencies, we propose the enrichment of the Contract pattern, which hitherto has been defined using SysML and the COMPASS Modelling Language (CML), by utilising SysML and Object Constraint Language (OCL). In addition, we examine the potential of interface automata, a notation for improving loose coupling between interfaces of constituent systems defined according to the contract, as a means of enabling the verification of contract compatibility. The approach is demonstrated using a case study in audio/video content streaming.

Full text

To address these deficiencies, we propose the enrichment of the

Contract pattern, which hitherto has been defined using SysML and the COMPASS Modelling Language (CML), by utilising SysML and Object Constraint Language (OCL). In addition, we examine the potential of interface automata, a notation for improving loose coupling between interfaces of constituent systems defined according to the contract, as a means of enabling the verification of contract compatibility. The approach is demonstrated using a case study in audio/video content streaming.

1 Introduction

A System of Systems (SoS) is a collection of systems brought together for a task that none of the systems can accomplish on its own. Each constituent system (CS) keeps its own management, goals, and resources while coordinating within the SoS and adapting to meet SoS goals [15]. The independence of CSs within an SoS places challenges the description of the SoS architecture, and the verification of global behaviour.

There are several efforts to define architectural patterns to assist in the systematic description of SoS architectures. One such pattern is the ’Contract’ pattern for specifying interfaces between CSs. A contract constrains the behaviour, in terms of operations and their ordering, in which a CS may engage as a ’good citizen’ in an SoS. For an example of a contract see Figure 1 where one can find contract defining operations, values and invariants for the Leader Election Device discussed later in this paper. The composition of such contracts can be used to verify the behaviour of the SoS as a whole.

The Contract pattern is at the moment being realised using the SysML and the COMPASS Modelling Language (CML) [6]. The SoS architectural structure is given in SysML, augmented by contractual expressions given in CML. The latter is a formal modelling language for SoSs, combining the state-based VDM and process-based Circus languages. CML may be used to specify preconditions, postconditions and invariants of contracts [7]. SoS decriptions in SysML, with expression definitions in CML, may be completely converted to CML, permitting access to SoS analysis tools, such as simulation, model checking and theorem proving [5].

The previous work on the Contract Pattern has relied on the combination of SysML and CML notations. SysML is readily accessed by a range of engineering stakeholders, while the ’pure’ CML is intended for the specialist SoS engineer who knows the formal notation [13]. However, this approach suffers from two potential limitations. First, the use of CML may limit the ease of adoption of this approach by communities more familiar with model-based systems engineering approaches using SysML. Second, in order to complete the representation of SysML in CML, it is necessary to verify the compatibility of the contracts offered by interacting CSs; the current tools do not allow this to be done statically, and so approaches are limited to simulation (with a lack of exhaustivity) or model checking (limited by the CML model checker) [5].

Paper Contribution: In this paper, we examine two approaches to the potential limitations in the use of the Contract pattern outlined above. First, we consider the potential of replacing CML by the better known Object Constraint Language (OCL) which is standardised by the Object Management Group (OMG) and is used to extend the Unified Modelling Language (UML). OCL may provide potential for wider take-up of the contractual approach, and may be seen as a more natural fit with SysML. Second, we examine the use of interface automata [2] as a way of increasing the opportunities for verification of contract conformance. This formalism was originally used for verification of the compatibility in component systems, and so may also be applicable in the SoS setting.

Paper Structure: We first describe the areas of related work (Section 2) and outline our approach, which utilises a case study in audio/video systems (Section 3). Section 4 describes the use of OCL for contract description. Section 5 discusses the application of interface automata in verifying the constitutent system compatibility. Section 6 applies interface automata to the case study, providing a basis for an initial evaluation, conclusions and future work (Section 7).

2 Related Work

In this section, we consider related work in the SoS domain, and in formal model-based methods.

Systems of Systems

SoSs have had a considerable amount of research in both Europe and the US in recent years. Maier [16] characterises SoSs in terms of operational and managerial independence, distribution, evolution and emergent behaviour. Maier, and later Dahmann [10], also categorise SoSs in terms of the levels of control over the CSs – from directed SoSs with some level of central control, to virtual SoSs with little to no central control. An output of the COMPASS project111www.compass-research.eu was a detailed survey of SoS engineering concepts, model-based techniques and research directions [20].

One technique for tackling complexity and understanding the composition and connections between the CSs of an SoS is through architectural modelling. In [23], Payne and Fitzgerald survey several architecture description languages considering their applicability for modelling SoSs. SysML [22], an extended subset of UML, has found some traction in both academia and industry for modelling systems in terms of structure, behaviour and requirements.

SoSs pose many challenges to system engineers. Of those, the operational independence [16] of the CSs introduces complications when composing constituents to examine global behaviour. Interface Contracts [5] have been proposed as one method of dealing with the complexity – through detailing a collection of contracts which the CSs must conform. Arnold et al. have considered contracts in the context of SoS [4], using a combination of SysML/UPDM and a new language Goal and Contract Specification Language (GCSL), which combines OCL and Linear Temporal Logic (LTL). This work considers contracts at the SoS requirment level, rather than at the interfaces of individual CSs. In their survey paper [23], Payne and Fitzgerald evaluate architecture description languages and how contracts may be represented. The term Interface Contract has much in common with the Design by Contract [17] software engineering technique. An Interface Contract details the provided and required functionality of a CS, and dictates the state- and protocol-based requirements and guarantees of those functionalities.

In the SoS context, there is ongoing work in architectural patterns [14] which proposes an initial collection of topological patterns for SoS engineers, identifying aims, properties and risks. A Contract Pattern [5] has been defined which allows engineers to rigorously and consistently define the interface contracts of a SoS. This type of pattern considers a lower-level of abstraction to the aforementioned architectural pattern, and is considered to be an enabling pattern [25].

Formalisms

There is a wide body of literature comparing formal methods and their industrial take-up [28]. In SoSs, the COMPASS Modelling Language (CML) is claimed to be the first formal language defined specifically for this domain [27]. CML is based on the languages VDM [11], CSP [12] and Circus [29]. A CML model is a collection of process definitions, each of which encapsulates a state and operations, and interacts with its environment via synchronous communications. The Contract pattern [5] proposes the use of CML to specify preconditions, postconditions and invariants of contract operations, as well as guards/actions on contract protocol state machines. The use of pre/postconditions is intended to allow CS interfaces to be specified in terms of ranges of permitted behaviour – important when each CS is independently owned and managed. The use of CML in this way allows an engineer to translate a profiled SysML model to a full CML model, and enables the verification afforded to CML [6].

There has been a large body of work integrating semi-formal notations such as UML and SysML with formal languages. In  [3], the authors survey several efforts to provide a formal semantics to SysML – through translation to different formalisms. Included in their survey is a reference to the use of interface automata. Samir Chouali et al. [9] use an extended definition of interface automata to include pre and post conditions. A sequence of activities is performed to verify interface compatibility.

Whilst the above works apply formal notations to the verification of SysML models, the translation to these languages, or augmentation of diagrams with formal expressions, is often not a natural fit to SysML. By contrast, OCL [26] is a standardised language, defined by OMG, who also defined SysML. OCL allows expressions, preconditions, postconditions and other constraints to be defined directly in terms of the SysML modelling elements.

Contract pattern

The Contract pattern [8] was introduced as a tool that guarantees pre-conditions and post-conditions of methods and invariants that constrain the state of objects. It means that, originally, it was designed for reliable classes.

The Contract pattern is a wide-spread programming approach to software designing which views the construction of software as based on contracts between clients and suppliers [18]. They rely on mutual commitments and benefits made explicitly expressed by statements. It has been developed in association with object-oriented programming. It is the basis for the programming language Eiffel and it is suitable for the design of component-based and agent systems [19].

Summary

The contractual approach promoted in the Contract pattern has the potential to help in the integration of CSs and the verification of global behaviour. However, the pattern has weaknesses. The first relates to the use of CML in the expression defintion. Whilst useful for translation to CML for analysis, expressions stated in CML are not a natural fit with SysML. Second, CML does not support the analysis of contract compatibility well: simulation is not exhaustive, and the model checking capabilities are limited.

We propose an approach that firstly adopts OCL as the expression language in contract definitions. Secondly, we consider the use of interface automata for analysis of contract composition. While a mapping of SysML to interface automata has been demonstrated previously, this was limited to pure interface definitions and did not consider the contractual approach. In the next section we outline in more detail the main three areas that make up this approach.

3 Outline of the approach

In this section, we outline the notations forming the approach. First in Section  3.1, we detail the Contract Pattern and its views. Section 3.2 outlines OCL and its main characteristics, which we will use as an extension of the Contract Pattern instead of CML. In Section 3.3 we describe interface automata that will be later used for verification of contracts.

3.1 Contract pattern

As described in [24], there are many design patterns for SoS architecture. These can be categorised as architectural patterns and enabling patterns. The former describe specific system architecture patterns (such as a Centralised Architecture Pattern). The latter are specific constructs of modelling elements. The combination of these specific constructs and subsequent use enables many systems engineering applications. CSs may conform to multiple contracts and each may implement its contractual obligations in any way its owners choose. The Contract pattern [5] is an enabling pattern composed of several viewpoints (see Table 1) in SysML and CML.

[TABLE]

There is also the Interface pattern which is useful for defining data and interactions between CSs, but it is unsatisfactory in modelling the internal behaviour of CSs. The purpose of the Contract pattern is to enable specification of constraints on behaviours that each CS must deliver as an element of the SoS.

A limitation of the Contract pattern is that it does not precisely define which operation should and which should not be visible. In the case of the interface constituent system implementation this can lead to taking all operations as visible or as input actions. However, such an approach impairs the loose coupling of constituent system interfaces, manifesting itself by decreased flexibility of the entire system, e.g. by difficulties in replacing particular constituent systems due to other dependences. In order to solve this problem, an additional Interface definition view diagram from the Interface pattern is used, which does not improve clarity and transparency of the design because it is not stated in this contract-associated diagram.

3.2 Object Constraint Language (OCL)

OCL [21] is a language for describing constraints on a model. OCL expressions have formal semantics, and do not produce side effects influencing a described UML model [26].

OCL offers a compromise between a natural language description and strongly formal mathematical languages. Its typical application lies in the specification of invariants for classes and types, and definition of preconditions and postconditions. It allows the definition of elements for navigation of a SysML model, referring explicitly to specfic model elements, and their attributes. This allows OCL expressions to be checked for consistency with the underlying SysML model.

OCL is a strongly typed language that defines basic types and collections. It has a well-known, OMG standardized syntax, easing the application of the contract pattern for SoS stakeholders. Its use in this context is further described in Section 4.

3.3 Interface Automata

Formal description of component-based systems using interface automata was first introduced by Alfaro and Henzinger in 2001 [2]. This formal notation describes the interface of a component in a component system using interface automaton and allows verification of the component assembly.

Every interface automaton is composed of input actions that are modelled by methods exposed by the component to its environment, and thus they can be called. Input actions are designated by the symbol ”?”. Furthermore, there are output actions. These are methods required by the component from another component in a component system. Output actions are designated by the symbol ”!”. There are also internal actions that describe local methods of the component. Internal actions are designated by the symbol ”;”.

Definition 1**.**

(Interface Automaton)

An interface automaton $A=\langle S_{\_}A,I_{\_}A,\Sigma_{\_}A^{I},\Sigma_{\_}A^{O},\Sigma_{\_}A^{H},\delta_{\_}A\rangle$ consists of

• •

$S_{\_}A$ is a set of states.

• •

$I_{\_}A\subseteq S_{\_}A$ is a set of initial states.

• •

three disjoint sets $\Sigma_{\_}A^{I}$, $\Sigma_{\_}A^{O}$ and $\Sigma_{\_}A^{H}$ of inputs, outputs and hidden actions.

• •

$\delta_{\_}A\subseteq S_{\_}A\times\Sigma_{\_}A\times S_{\_}A$

The composition condition defines, that actions of two interface automata $A_{\_}1$ and $A_{\_}2$ are disjoint and asynchronous, except shared input and output actions. Shared actions are synchronized when $A_{\_}1$ and $A_{\_}2$ are composed. The following definition presents the composition condition.

Definition 2**.**

(Composition)

The interface automata $A_{\_}1$, $A_{\_}2$ are composable if

$\Sigma_{\_}{A_{\_}1}^{I}\cap\Sigma_{\_}{A_{\_}2}^{I}=\Sigma_{\_}{A_{\_}1}^{O}\cap\Sigma_{\_}{A_{\_}2}^{O}=\Sigma_{\_}{A_{\_}1}^{H}\cap\Sigma_{\_}{A_{\_}2}=\Sigma_{\_}{A_{\_}1}\cap\Sigma_{\_}{A_{\_}2}^{H}=\emptyset$

If two interface automata $A_{\_}1$ and $A_{\_}2$ are composable then

$Shared(A_{\_}1,A_{\_}2)=(\Sigma_{\_}{A_{\_}1}^{I}\cap\Sigma_{\_}{A_{\_}2}^{O})\cup(\Sigma_{\_}{A_{\_}2}^{I}\cap\Sigma_{\_}{A_{\_}1}^{O})$

The synchronous product describes parallel execution of two interface automata.

Definition 3**.**

(Synchronized product)

Let $A_{\_}1$, $A_{\_}2$ be two composable interface automata. The product $A_{\_}1\otimes A_{\_}2$ is defined by

• •

$\Sigma_{\_}{A_{\_}1\otimes A_{\_}2}^{I}=(\Sigma_{\_}{A_{\_}1}^{I}\cup\Sigma_{\_}{A_{\_}2}^{I})\backslash Shared(A_{\_}1,A_{\_}2);$

• •

$\Sigma_{\_}{A_{\_}1\otimes A_{\_}2}^{O}=(\Sigma_{\_}{A_{\_}1}^{O}\cup\Sigma_{\_}{A_{\_}2}^{O})\backslash Shared(A_{\_}1,A_{\_}2);$

• •

$\Sigma_{\_}{A_{\_}1\otimes A_{\_}2}^{H}=\Sigma_{\_}{A_{\_}1}^{H}\cup\Sigma_{\_}{A_{\_}2}^{H}\cup Shared(A_{\_}1,A_{\_}2);$

• •

$((s_{\_}1,s_{\_}2),a,(s^{\prime}_{\_}1,s^{\prime}_{\_}2))\in\delta_{\_}{A_{\_}1\otimes A_{\_}2}$ if

• –

$a\notin Shared(A_{\_}1,A_{\_}2)\wedge(s_{\_}1,a,s^{\prime}_{\_}1)\in\delta_{\_}{A_{\_}1}\wedge s_{\_}2=s^{\prime}_{\_}2$

• –

$a\notin Shared(A_{\_}1,A_{\_}2)\wedge(s_{\_}2,a,s^{\prime}_{\_}2)\in\delta_{\_}{A_{\_}2}\wedge s_{\_}1=s^{\prime}_{\_}1$

• –

$a\in Shared(A_{\_}1,A_{\_}2)\wedge(s_{\_}1,a,s^{\prime}_{\_}1)\in\delta_{\_}{A_{\_}1}\wedge(s_{\_}2,a,s^{\prime}_{\_}2)\in\delta_{\_}{A_{\_}2}$

Illegal states are states which are attainable by enabling internal actions or output actions.

Definition 4**.**

(Illegal States)

Let $A_{\_}1$, $A_{\_}2$ be two composable interface automata. The set of illegal states $Illegal(A_{\_}1,A_{\_}2)\subseteq S_{\_}{A_{\_}1}\times S_{\_}{A_{\_}2}$ of $A_{\_}1\otimes A_{\_}2$ is defined by $\{(s_{\_}1,s_{\_}2)\in S_{\_}{A_{\_}1}\times S_{\_}{A_{\_}2}|\exists a\in Shared(A_{\_}1,A_{\_}2).(a\in\Sigma_{\_}{A_{\_}1}^{O}(s_{\_}1)\wedge a\notin\Sigma_{\_}{A_{\_}2}^{I}(s_{\_}2))\vee(a\in\Sigma_{\_}{A_{\_}2}^{O}(s_{\_}2)\wedge a\notin\Sigma_{\_}{A_{\_}1}^{I}(s_{\_}1))\}$.

The following algorithm describes verification of compatibility between $A_{\_}1$ and $A_{\_}2$. The result then either confirms or disproves the compatibility of components $C_{\_}1$ and $C_{\_}2$.

verify that $A_{\_}1$ and $A_{\_}2$ are composable, 2. 2.

calculate the product $A_{\_}1\otimes A_{\_}2$, 3. 3.

calculate the set of illegal states in $A_{\_}1\otimes A_{\_}2$, 4. 4.

calculate the bad states in $A_{\_}1\otimes A_{\_}2$. The bad states represent states from which the illegal state are reachable by enabling only the internal action or the output actions (one suppose the existence of a helpful environment), 5. 5.

eliminate from the automaton $A_{\_}1\otimes A_{\_}2$, the illegal state, the bad state, and the unreachable states from the initial states, 6. 6.

if the automaton $A_{\_}1\otimes A_{\_}2$ is empty then the interface automata $A_{\_}1$, $A_{\_}2$ are not compatible, therefore $C_{\_}1$ and $C_{\_}2$ can not assembled correctly in any environment.

The complexity of this approach is linear on the size of $A_{\_}1$ and $A_{\_}2$ interface automata.

Interface automata in the Contract Pattern approach bring the possibility of verification of compatibility of contracts regarding operation visibility and complex analysis of the communication protocol of contracts.

We build upon the work of [5] in defining Interface Contracts using the Contract Pattern. However, as detailed in Section 2, the use of OCL may provide a more natural vehicle for combining a formal specification notation with the semi-formal SysML. Finally, we consider the use of interface automata to enrich these contracts and to model the abstract behaviour of CSs – complementing the state machines previously used in Interface Contracts. The use of interface automata provides a mechanism for verifying contract compatibility.

3.4 The Leader Election Case Study

In order to demonstrate the approach detailed in this paper, we use an industry-inspired case study [7]. The study presents an audio visual (AV) network of multiple AV devices with a network layer allowing communication between each device. Each device may be developed and maintained independantly, and this network exhibits the characteristic properties of SoSs. In the study each AV device must conform to a collection of contracts, each dictating required behaviours in order to be a part of the SoS.

Contracts exist for streaming of AV data, browsing digital content and for lower-level timing issues. This study has been previously defined with the Contract Pattern  [5], which identifies three contracts: Browsing Device, Streaming Device and LE Device. As with that paper, we concentrate on the LE Device, in addition to the Transport Layer contract. In [5] the LE Device contract is defined using SysML diagrams and CML expressions to constrain various aspects of the contract definition.

4 OCL as an extension of SysML in CPS development

The idea of OCL applicability in SysML is based on the fact that SysML is defined as a UML profile222A UML profile provides a mechanism for customising UML models for a particular domain or platform. This is achieved by using stereotypes and constraints applied to specific UML model elements.

OCL appears as applicable in the diagrams of Contract Definition Viewpoint and Contract Protocol Viewpoint that are basically similar to Class Diagram and State Machine Diagram. The remaining diagrams such as Contractual SoS Definition Viewpoint, Contract Conformance Viewpoint and Contract Connections Viewpoint are rather conceptual in nature and do not reach the required level of detail of description of the system where OCL should be applicable.

4.1 Contract Definition Viewpoint

In [5], the Contract Definition Viewpoint (CDV) uses CML expressions to specify contract invariants, and the pre- and postconditions of contract operations. When applying OCL invariants and pre-/postconditions, we use SysML notes attached to Contract blocks with OCL expressions. Whilst some tools are able to analyse the conditions, we leave this for future work.

For the purposes of clarity, we split the definition of the LE Device contract across two diagrams, shown in Figures 1 and 2. The first diagram, Figure 1, presents the three invariants of the LE Device contract. The invariants are defined in separate SysML notes, each using the OCL expression notation for state variable invariants. The OCL statements define their context – here the LE Device contract – and then a named expression. In Figure 1, we see invariants which provide constraints which largely relate to the mem variable.

Figure 2 shows the constrained operations of the LE Device contract. It should be noted that there are several operations which do not require constraining. As above, we use SysML notes for each OCL statement – each relating to a separate operation. The OCL statement defines the context – here the LE Device contract, and the operation being constrained. For example, the top-most OCL statement refers to the write operation, giving the signature and then the precondition and postcondition for the operation. These conditions are OCL expressions.

4.2 Contract Protocol Definition Viewpoint

Finally, we consider the Contract Protocol Definition View. Previously, in this view, CML expressions are used to define guard constraints on transitions. We propose that these guards could be defined using OCL expressions. Figure 3 shows the LE Device behaviour with guarded transitions. In this example, the CML and OCL expressions are the same syntactically, and therefore are unchanged.

In this section, we have demonstrated the use of OCL in the context of the Contract Pattern. We feel that the use of OCL, rather than CML provides the advantage of accessibility to the SoS engineering architecture community.

5 Verifying compatibility of contracts by interface automata

For verification of compatibility of contracts we present an application of interface automata, which takes into account the visibility of operations, which can exist as input, output or hidden operations. It also allows a complex view of the system using protocols for component communication. The design of interface automata for the contract in the present study is based on the design of interface automata described by Samir Chouali et al. [9] who extended the original definition by pre and post conditions, which also occur in the case of contracts. Furthermore, we extend this definition by formulation of variables, which can assume different values due to operation calls. Verification of compatibility of the two contracts is ensured by verification of their corresponding interfaces.

The following definition presents the extended interface automaton for contract.

Definition 5**.**

(Extended interface automaton for contract)

Let be $C$ a component of the component system $CS$, which represents a contractual specification for constituent system within a System of Systems. Extended interface automata associated with this component is nonuple

$A(C)=\langle S_{\_}A,I_{\_}A,\Sigma_{\_}A^{I},\Sigma_{\_}A^{O},\Sigma_{\_}A^{H},V_{\_}A,Pre_{\_}A,Post_{\_}A,\delta_{\_}A\rangle$, which consists of

• •

$S_{\_}A$ is the set of states.

• •

$I_{\_}A\subseteq S_{\_}A$ is a set of initial states.

• •

$\Sigma_{\_}A^{I}$, $\Sigma_{\_}A^{O}$ and $\Sigma_{\_}A^{H}$ are disjoint sets of inputs, outputs and hidden actions.

• •

$V_{\_}A$ is the set of contract variables.

• •

$Pre_{\_}A$ is the set of preconditions of component actions. Preconditions are specified in OCL.

• •

$Post_{\_}A$ is the set of postconditions of component actions. Postconditions are specified in OCL.

• •

$\delta_{\_}A$ is a plurality of transaction steps that are made on the basis of the occurrence of $a\in\Sigma$ actions in the state $s\in S$ under the valid precondition in $Pre_{\_}{A}$ and postcondition in $Post_{\_}{A}$, which might include variables from $V_{\_}{A}$.

The following definition presents the composition of interface automata for contract.

Definition 6**.**

(Composition of extended interface automata for contract)

Let $A_{\_}1=\langle S_{\_}1,I_{\_}1,\Sigma_{\_}1^{I},\Sigma_{\_}1^{O},\Sigma_{\_}1^{H},V_{\_}1,Pre_{\_}1,Post_{\_}1,\delta_{\_}1\rangle$ and $A_{\_}2=\langle S_{\_}2,I_{\_}2,\Sigma_{\_}2^{I},\Sigma_{\_}2^{O},\Sigma_{\_}2^{H},V_{\_}2,Pre_{\_}2,Post_{\_}2,\delta_{\_}2\rangle$ be two extended interface automata, and let’s denote $\Sigma_{\_}{1}=\Sigma_{\_}{1}^{O}\cup\Sigma_{\_}{1}^{I}\cup\Sigma_{\_}{1}^{H}$ and $\Sigma_{\_}{2}=\Sigma_{\_}{2}^{O}\cup\Sigma_{\_}{2}^{I}\cup\Sigma_{\_}{2}^{H}$.

$A_{\_}1$ and $A_{\_}2$ are composable if $(\Sigma_{\_}{1}^{I}\cap\Sigma_{\_}{2}^{I})=(\Sigma_{\_}{1}^{O}\cap\Sigma_{\_}{2}^{O})=(\Sigma_{\_}{1}^{H}\cap\Sigma_{\_}{2})=(\Sigma_{\_}{1}\cap\Sigma_{\_}{2}^{H})=\emptyset$.

If two extended interface automata $A_{\_}1$ and $A_{\_}2$ are composable then

$Shared(A_{\_}1,A_{\_}2)=(\Sigma_{\_}{1}^{I}\cap\Sigma_{\_}{2}^{O})\cup(\Sigma_{\_}{2}^{I}\cap\Sigma_{\_}{1}^{O})$.

The following definition presents the synchronized product of two extended interface automata for contract.

Definition 7**.**

(Synchronized product of two extended interface automata for contract)

Let $A_{\_}1=\langle S_{\_}1,I_{\_}1,\Sigma_{\_}1^{I},\Sigma_{\_}1^{O},\Sigma_{\_}1^{H},V_{\_}1,Pre_{\_}1,Post_{\_}1,\delta_{\_}1\rangle$ and $A_{\_}2=\langle S_{\_}2,I_{\_}2,\Sigma_{\_}2^{I},\Sigma_{\_}2^{O},\Sigma_{\_}2^{H},V_{\_}2,Pre_{\_}2,Post_{\_}2,\delta_{\_}2\rangle$ are two composable extended interface automata.

The product $A_{\_}1\otimes A_{\_}2$ is defined by $\langle S_{\_}1\times S_{\_}2,I_{\_}1\times I_{\_}2,\Sigma^{I},\Sigma^{O},\Sigma^{H},V_{\_}{1}\cup V_{\_}{2},Pre,Post,\delta\rangle$ be such that:

• •

$\Sigma^{I}=(\Sigma_{\_}1^{I}\cup\Sigma_{\_}2^{I})\backslash Shared(A_{\_}1,A_{\_}2);$

• •

$\Sigma^{O}=(\Sigma_{\_}{1}^{O}\cup\Sigma_{\_}{2}^{O})\backslash Shared(A_{\_}1,A_{\_}2);$

• •

$\Sigma^{H}=\Sigma_{\_}{1}^{H}\cup\Sigma_{\_}{2}^{H}\cup Shared(A_{\_}1,A_{\_}2);$

• •

$((s_{\_}1,s_{\_}2),pre,a,post,(s^{\prime}_{\_}1,s^{\prime}_{\_}2))\in\delta$ if

• –

$a\notin Shared(A_{\_}1,A_{\_}2)\wedge(s_{\_}1,pre_{\_}1,a,post_{\_}1,s^{\prime}_{\_}1)\in\delta_{\_}{1}\wedge s_{\_}2=s^{\prime}_{\_}2\wedge pre=pre_{\_}1\wedge post=post_{\_}1$

• –

$a\notin Shared(A_{\_}1,A_{\_}2)\wedge(s_{\_}2,pre_{\_}2,a,post_{\_}2,s^{\prime}_{\_}2)\in\delta_{\_}{2}\wedge s_{\_}1=s^{\prime}_{\_}1\wedge pre=pre_{\_}2\wedge post=post_{\_}2$

• –

$a\in Shared(A_{\_}1,A_{\_}2)\wedge((s_{\_}1,pre_{\_}1,a,post_{\_}1,s^{\prime}_{\_}1)\in\delta_{\_}{1}\wedge a\in\Sigma^{I})\wedge((s_{\_}2,pre_{\_}2,a,post_{\_}2,s^{\prime}_{\_}2)\in\delta_{\_}{2}\wedge a\in\Sigma^{O})\wedge pre=(pre_{\_}2\wedge pre_{\_}1)\wedge post=(post_{\_}1\wedge post_{\_}2)$

• –

$a\in Shared(A_{\_}1,A_{\_}2)\wedge((s_{\_}1,pre_{\_}1,a,post_{\_}1,s^{\prime}_{\_}1)\in\delta_{\_}{1}\wedge a\in\Sigma^{O})\wedge((s_{\_}2,pre_{\_}2,a,post_{\_}2,s^{\prime}_{\_}2)\in\delta_{\_}{2}\wedge a\in\Sigma^{I})\wedge pre=(pre_{\_}1\wedge pre_{\_}2)\wedge post=(post_{\_}2\wedge post_{\_}1)$

• •

$Pre=Pre_{\_}{1}\cup Pre_{\_}{2}\cup\{(pre_{\_}1\wedge pre_{\_}2)|pre_{\_}1\in Pre_{\_}1\wedge pre_{\_}2\in Pre_{\_}2\}$;

• •

$Post=Post_{\_}{1}\cup Post_{\_}{2}\cup\{(post_{\_}1\wedge post_{\_}2)|post_{\_}1\in Post_{\_}1\wedge post_{\_}2\in Post_{\_}2\}$.

The following definition presents the illegal states of two extended interface automata for contract. A set of illegal states contains states in which shared actions between extended interface automata are not synchronized (because required functionality by one of the automata is not provided by the other), or no transition is enabled due to the restrictions resulting from the preconditions and postconditions of the enabled transitions from the state.

Definition 8**.**

(Illegal states of two extended interface automata for contract)

Let $A_{\_}1$, $A_{\_}2$ be two composable interface automata. The set of illegal states $Illegal(A_{\_}1,A_{\_}2)\subseteq S_{\_}{A_{\_}1}\times S_{\_}{A_{\_}2}$ of $A_{\_}1\otimes A_{\_}2$ is defined by $\{(s_{\_}1,s_{\_}2)\in S_{\_}{A_{\_}1}\times S_{\_}{A_{\_}2}|\exists a\in Shared(A_{\_}1,A_{\_}2).(a\in\Sigma_{\_}{A_{\_}1}^{O}(s_{\_}1)\wedge a\notin\Sigma_{\_}{A_{\_}2}^{I}(s_{\_}2))\vee(a\in\Sigma_{\_}{A_{\_}2}^{O}(s_{\_}2)\wedge a\notin\Sigma_{\_}{A_{\_}1}^{I}(s_{\_}1))\}\cup\{(s_{\_}1,s_{\_}2)\in S_{\_}{A_{\_}1}\times S_{\_}{A_{\_}2}|\forall((s_{\_}1,s_{\_}2),pre,a,post,(s^{\prime}_{\_}1,s^{\prime}_{\_}2))\in\delta_{\_}{A_{\_}1\otimes A_{\_}2}.((pre\equiv false)\vee(post\equiv false))\}$.

6 Translating the Leader Election Case Study to Extended Interface Automata

In this section, we will apply the above mentioned formalism to the Leader Election study. In order to convert the contract into an extended interface automaton, it is necessary to use the Contract Definition View which describes preconditions, values and operations (input, output, hidden), and the Contract Protocol Definition View to identify states and transitions between them. The following code presents the extended interface automata for LE device and Transport Layer.

LE device

• •

$S_{\_}{LD}=\{Off,OnFollower,OnLeader,OnUndecided,OnReady,OnUpdate\}$

• •

$I_{\_}{LD}=\{Off\}$

• •

$\Sigma_{\_}{LD}^{I}=\{receiveMessages\}$

• •

$\Sigma_{\_}{LD}^{O}=\{sendMessages\}$

• •

$\Sigma_{\_}{LD}^{H}=\{changeClaim,flushState,update,maxStrength,maxStrengthId,\\ incStrength,init,flushMemory,flushSummary,isLeader,write,turnOn,turnOff\}$

• •

$V_{\_}{LD}=\{id,mem,highest\_strength,highest\_strength\_id,otherLeaders,myCS,isLeader\}$

• •

$Pre_{\_}{LD}=\{LDPreCC,LDPreW,LDPreIS\}$ where: $\{$

context LE Device::changeClaimm(newClaim : Claim)

pre LDPreCC: $myCS.c=<off>$ $\implies$ $newc=<undecided>$

and myCS.c = $<undecided>$ $\implies$ (newc = $<leader>$ or newc = $<follower>$)

and myCS.c = $<leader>$ $\implies$ newc = $<undecided>$

and myCS.c = $<follower>$ $\implies$ newc = $<undecided>$

context LE Device::write(n: LEId, dat: DATA) pre LDPreW: n in set dom mem

context LE Device::incStrength() pre LDPreIS: myCS.s $<$ 10

$\}$

• •

$Post_{\_}{LD}=\{LDPostCC,LDPostW,LDPostIS\}$ where: $\{$

**context LE Device::changeClaimm(newClaim : Claim) post LDPostCC: myCS.c = newClaim **

**context LE Device::write(n: LEId, dat: DATA) post LDPostW: mem(n) = dat or mem(n).c = $<off>$ **

**context LE Device::incStrength() post LDPostIS: myCS.s = myCS .s + 1 **

$\}$

• •

$\delta_{\_}{LD}=\{$

• –

$Off:\bm{turnOn}:OnReady$

• –

$OnReady:\bm{receiveMessages}:OnUpdate$

• –

$OnUpdate:\bm{update}:OnReady$

• –

$OnReady:\bm{turnOff}:Off$

• –

$Off:\bm{turnOn}:OnUndecided$

• –

$OnUndecided:LDPreCC:\bm{changeClaim}:LDPostCC:OnFollower$

• –

$OnFollower:LDPreCC:\bm{changeClaim}:LDPostCC:OnUndecided$

• –

$OnUndecided:LDPreCC:\bm{changeClaim}:LDPostCC:OnLeader$

• –

$OnLeader:LDPreCC:\bm{changeClaim}:LDPostCC:OnUndecided$

• –

$OnFollower:\bm{sendMessages}:OnFollower$

• –

$OnLeader:\bm{sendMessages}:OnLeader$

• –

$OnUndecided:\bm{turnOff}:Off$

• –

$OnFollower:\bm{turnOff}:Off$

• –

$OnLeader:\bm{turnOff}:Off$

$\}$

Transport Layer

• •

$S_{\_}{TL}=\{Init,Ready,CreateMessage,AddtoQueue,GetMessage,\\ CreateUnreachableMessage,TurnDeviceOn,TurnDeviceOff,SendtoDevice,ReceivedMessage\}$

• •

$I_{\_}{TL}=\{Init\}$

• •

$\Sigma_{\_}{TL}^{I}=\{sendMessages\}$

• •

$\Sigma_{\_}{TL}^{O}=\{receiveMessages\}$

• •

$\Sigma_{\_}{TL}^{H}=\{init,addToQueue,getNextMsg,createMessage,\\ AddToQueue,setDeviceOn,setDeviceOff,ready\}$

• •

$V_{\_}{TL}=\{queue,devOn\}$

• •

$Pre_{\_}{TL}=\{TLPreGNM,TLPreSDOF,TLPreSDON\}$ where: $\{$

context Transport Layer::getNextMsg() pre TLPreGNM: queue $\rightarrow$ notEmpty

context Transport Layer::setDeviceOff(in devId : LEId) pre TLPreSDOF: devOn[devId]$\rightarrow$notEmpty

context Transport Layer::setDeviceOn(in devId : LEId) pre TLPreSDON: devOn[devId]$\rightarrow$notEmpty

$\}$

• •

$Post_{\_}{TL}=\{TLPostI,TLPostATQ\}$ where: $\{$

**context context TransportLayer::Init() post TLPostI: devOn.domain() = nodeids and

devOn.range = false and queue.size() = 0**

**context context TransportLayer::addToQueue(m:MSG) post TLPostATQ:

queue.size() = queue@pre.size() + 1 and queue.lastItem() =

m and queue@pre = queue(1,…,queue.size())**

$\}$

• •

$\delta_{\_}{TL}=\{$

• –

$Init:\bm{init}:TLPostI:ready$

• –

$Ready:\bm{sendMessages}:ReceivedMessage$

• –

$ReceivedMessage:\bm{createMessage}:CreateMessage$

• –

$CreateMessage:\bm{addToQueue}:TLPostATQ:AddtoQueue$

• –

$AddtoQueue:\bm{ready}:Ready$

• –

$Ready:TLPreGNM:\bm{getNextMsg}:GetMessage$

• –

$GetMessage:\bm{receiveMessages}:SendtoDevice$

• –

$SendtoDevice:\bm{ready}:Ready$

• –

$GetMessage:\bm{createMessage}:CreateUnreachableMessage$

• –

$SendtoDevice:\bm{createMessage}:CreateUnreachableMessage$

• –

$CreateUnreachableMessage:\bm{addToQueue}:AddToQueue$

• –

$AddToQueue:\bm{ready}:Ready$

• –

$Ready:TLPreSDON:\bm{setDeviceOn}:TurnDeviceOn$

• –

$TurnDeviceOn:\bm{ready}:Ready$

• –

$Ready:TLPreSDOF:\bm{setDeviceOff}:TurnDeviceOff$

• –

$TurnDeviceOff:\bm{ready}:Ready$

$\}$

On lines 3-6 and 43-46, the classification of operations based on whether they are input, output or hidden deserves careful attention. The application of OCL for defining precondition and postcondition are apparent from lines 8-22 and 48-60. Subsequent transitions between the states can be seen in the last sections of extended interface automata (lines 23-38 and 61-78).

The classification of operations is a key element of extended interface automata, requiring careful judgement during translation. Given the sepafration, however, we propose an improved Contract Definition View in the Contract Pattern. As shown in Figure 4, the Contract Definition Viewpoint identifies the input, output and hidden operations, which makes this explicit in the SysML model, and provides independence from the Interface Pattern.

In contrast to CML, during the contract translation to the interface automaton, the software engineer is led to the division of methods based on their type (input, output, hidden operations), thereby increasing the transparency. With a system described in this way we can perform classified verification operations, such as determination that constituent systems are composable (or not) by checking conditions on the actions’ viability by considering their semantics. Furthermore, considering the synchronized product, we are able to determine inconsistencies between the sequences of action calls given by communicating protocols.

7 Conclusion

This paper proposes an extension of the Contract Pattern to analyse the compatibility between contracts. The paper contribution forms two main parts. Firstly, we proposed a substitution of CML for OCL language (Object Constraint Language) which is used in order to extend the SysML in the Contract Pattern. The use of OCL provides a more natural fit with the base SysML views. In addition, we improved the Contract Pattern by separation of the input, output and hidden operations, which increased its transparency and independence on the Interface Pattern.

Secondly, based upon the contracts defined in the Contract Pattern, we propose an improvement in interface automata. Originally designed by L. Alfaro and T. Henzinger [2] and modified by Samir Chouali et al. [9], we adapted and extended the interface automata approach by values of the contract to represent its states. Linking CS contracts to interface automata enables the verification of contract composition.

Future Work

Given the contributions of this paper, we consider several areas of future work. Firstly, the verification of LE Device and Transpost Layer extended interface automata compatibility must be demonstrated, based upon the set of definitions in this paper. Given manual verification, we consider automated verification. This implemention may be included as an external plug-in to the Symphony tool, and thus extended the possibilities of performing contract composition analysis in this tool platform. In addition, as mentioned in Section 4.1, the OCL expressions in this paper are defined as SysML notes. Future work would consider the conformance of CSs according to these contract specifications. Finally, we would also like to consider the application of the Contract Pattern and extended interface automata in the specification and analysis of evolution and dynamic reconfiguration of SoSs.

Acknowledgments

This work is supported by the INTO-CPS project funded by the European Commission’s Horizon 2020 (grant agreement 644047, http://into-cps.au.dk) and by the CPSE Labs funded by the European Union under the Smart Anything Everywhere initiative (http://www.cpse-labs.eu).