Compositionality of Safe Communication in Systems of Team Automata

. We study guarantees for safe communication in systems of systems composed of reactive components that communicate through synchronised execution of common actions. Systems are modelled as (extended) team automata, in which, in principle, any number of component automata can participate in the execution of a communicating action, either as a sender or as a receiver. We extend team automata with synchronisation type speciﬁcations, which determine speciﬁc synchronisation policies ﬁne-tuned for particular application domains. On the other hand, synchronisation type speciﬁcations generate communication requirements for receptiveness and responsiveness. We propose a new, liberal version of requirement satisfaction which allows teams to execute arbitrary intermediate actions before being ready for the required communication, which is important in practice. Then we turn to the composition of systems and show that composition behaves well with respect to synchronisation type speciﬁcations. As a central result, we investigate criteria that ensure the preservation of local communication properties when (extended) team automata are composed. This is particularly challenging in the context of weak requirement satisfaction.


Introduction
We study guarantees for safe communication in systems of systems of interconnected, reactive components that communicate through synchronised execution of shared actions. We focus on the prevention of output actions from not being accepted (i.e. no message loss) and input actions from not being provided (i.e. no indefinite waiting). The lack of safe communication in modular system models may reveal design problems before implementation. To guarantee safe communication in such models, a characterisation for compatibility of two component interactions free from message loss and indefinite waiting was given in [15] and lifted to n-ary interactions in multi-component systems in [16]. Both approaches support compatibility for synchronous communication. A first exploration on how to generalise compatibility notions to arbitrary synchronisation policies was performed in [7] in the framework of team automata.
Team automata [8,23] are a transition system model for systems of reactive components differentiating input (passive), output (active), and internal (privately active) actions, in the line of I/O automata [19,29], interface automata [20,21], component-interaction automata [14], modal I/O automata [27], and contract automata [3,4]. The distinguishing feature of team automata is their very loose nature of synchronisation according to which, in principle, any number of component automata can participate in the synchronised execution of a shared communicating action, either as a sender or as a receiver. Team automata can determine specific synchronisation policies defining when and which actions are executed and by how many components.
Conditions for safe communication in terms of receptiveness and responsiveness were considered in [2,12,18,22] for (web) services and in [6,7,10,16] for team automata. Output actions not accepted as input by some component are considered as message loss or as unspecified receptions [13,22]. If any (autonomously chosen) output action is accepted, we call this receptiveness [7]. Orthogonally, we recognise indefinite waiting for input to be received in the form of an appropriate output action provided by another component [15]. Since input relies on external choice, it is sufficient if only one of the enabled input actions is responded to (by other components), which we call responsiveness [6].
In [6], a representative set of synchronisation types was defined to classify synchronisation policies (e.g., binary communication, multi-cast communication, full synchronisation) realisable in team automata in terms of ranges for the number of sender and receiver components that can participate in a system communication. Moreover, a generic procedure was provided to derive requirements for receptiveness and responsiveness for each synchronisation type. Communication safety of team automata was expressed in terms of their compliance with receptiveness and responsiveness requirements. A team automaton is said to be compliant with a given set of communication requirements if in each reachable state of the team the desired communications can immediately occur; if the communication can eventually occur after some internal actions have been performed, it is said to be weakly compliant (à la weak compatibility [5,25]).
In the short paper contribution [10], we briefly reviewed our previous approach from [6] and we identified some limitations leading to issues for future research. A first issue was that the assignment of a single synchronisation type to a team, as in [6], is too restrictive and that we need to fine tune the number of synchronising sending and receiving components per action. For this purpose we introduce, in the current paper, synchronisation type specifications which assign a synchronisation type individually to each communicating action. Such specifications uniquely determine a team formalised by an extended notion of team automaton (ETA). On the other hand, any synchronisation type specification generates communication requirements to be satisfied by the team.
A second issue was that we realised that even the weak compliance notion proposed in [6] is too restrictive for practical applications. In the current paper, we overcome this problem by introducing a much more liberal compliance notion: if a group J of components has issued a communication request, then we allow the team to execute arbitrary other actions, not limited to internal ones, before being ready for the required communication (with the components in J ). This leads to a powerful compliance notion not studied before (as far as we know). This apparently simple generalisation has a significant consequence: among the 'arbitrary other actions' there may be output or input actions open to the environment. This is a potentially dangerous situation, since in this case local communication properties can be violated after composition with other teams.
This leads us to the third, perhaps most important, contribution of the current paper. We consider composition of systems and of teams. First, we show that composition behaves well with synchronisation types (Theorem 1). Then we investigate conditions under which communication properties are preserved by ETA composition. The principle idea is that for this it should be sufficient to consider interface actions and to check (global) compliance conditions for them. We formulate appropriate conditions, first for the case of (strong) receptiveness and responsiveness (Theorem 2) and then for the weak variant of the two, solving the problem sketched above (Theorem 3). An intuitive running example guides the reader through the paper.
Outline. After introducing extended team automata (ETA) in Sect. 2, we consider synchronisation type specifications and ETA determined by them in Sect. 3. (Weak) compliance of ETA with communication requirements and safe communication are treated in Sect. 4. In Sect. 5, we define the composition of systems and of teams, and we show that this works well with synchronisation type specifications. In Sect. 6, we provide our main compositionality results. Full proofs and some insightful counterexamples of the results presented in the latter two sections can be found in [9]. After discussing related work in Sect. 7, we conclude the paper in Sect. 8.

Background and Extended Team Automata
In this section, we summarise the basic notions concerning team automata and introduce extended team automata. In contrast to the 'classical' team automata from [8,23] and subsequent papers, extended team automata use system labels which, in addition to the executed action, specify the team members that participate in a synchronisation on an action. We start with some technical preliminaries concerning labelled transition systems which will be reused for the definitions of (local) component automata and (global) team automata. A labelled transition system (LTS for short) is a quadruple L = (Q, Σ, δ, I) consisting of a set Q of states, a set Σ of actions such that Q ∩ Σ = ∅, a transition relation δ ⊆ Q × Σ × Q and a nonempty set I ⊆ Q of initial states.
For an action a ∈ Σ, δ a = δ ∩ (Q × {a} ×Q) denotes the set of a-transitions of L. Instead of (p, a, p ) ∈ δ we may write p a − → L p . Action a is enabled in L at state p ∈ Q, denoted by a en L p, if there exists p ∈ Q such that p a − → L p .
The set of reachable states of L is denoted by R(L).
Component automata are LTSs with an additional distinction between input and output actions. 1 They form the basic building block of systems.

Definition 1 (Component automaton).
A component automaton (CA for short) is an LTS A = (Q, Σ, δ, I) such that Σ is the union of two disjoint sets Σ inp and Σ out of input and output actions, respectively.
In figures, we emphasise the role of actions by adding suffix ? to input actions and ! to output actions.
The state space of S is given by the Cartesian product Q = i∈N Q i . Hence a global system state is an Nindexed family q = (q i ) i∈N of local component states q i ∈ Q i . The initial states of S are given by the product I = i∈N I i . If ∅ = N ⊆ N and q = (q i ) i∈N is a system state, the projection of q to N is defined by proj N (q) = (q i ) i∈N .
We refer to Σ = i∈N Σ i as the set of actions of S. 2 Within Σ, we identify Σ com = i∈N Σ i,inp ∩ i∈N Σ i,out as the set of communicating actions in S. Hence, an action of S is communicating in S if it occurs in (at least) one of its CA as an input action and in (at least) one of its CA as an output action.
For an action a ∈ Σ, we let dom a,inp (S) = { i | a ∈ Σ i,inp } be its input domain (in S) and dom a,out (S) = { i | a ∈ Σ i,out } its output domain (in S). Hence a communicating action of S is such that both its output and input domain in S are not empty.
Notation. Up to and including Sect. 4, we fix N and S as above. Example 1. Consider a distributed chat system, where buddies can interact once registered. For now, we consider two types of components: clients and servers, depicted in Fig. 1 (left and middle, respectively). The arbiter will join only later when we discuss system compositions. A server controls entries into the chat and exits from the chat, and coordinates the main activity: forwarding client messages to the chat. The communicating actions are partitioned into chat access actions (join, leave, confirmJ , confirmL) and chat messaging (msg, fwdmsg). The noncommunicating actions are currently ask , grant, and reject . Let us assume a chat system S chat consisting of two clients A 1 and A 2 and one server A 3 . Its state space consists of tuples (p, q, r) with client states p and q and server state r. We use extended labels as envisioned in [14] for multi component-interaction automata, to indicate explicitly which components are actively participating in system transitions. In the vector team automata of [11], vectors of component actions are used for this purpose, giving rise to a concurrent semantics.

Definition 2 (System labels).
Let a ∈ Σ. A system label for a (in S) is a triple (out, a, inp) where out, inp ⊆ N are subsets of N such that out ∪ inp = ∅ and a ∈ Σ i,out for all i ∈ out and a ∈ Σ i,inp for all i ∈ inp. The set of system labels for a in S is denoted by Λ a (S), while Λ(S) = a∈Σ Λ a (S) denotes the set of all system labels in S.
System labels provide an appropriate means to describe which components in a system execute together a computation step, i.e. a system transition.

Definition 3 (System transitions).
A triple (q, σ, q ) ∈ Q × Λ(S) × Q with system label σ = (out, a, inp) is a system transition on a (in S) if (q(i), a, q (i)) ∈ δ i for all i ∈ out ∪ inp and q(i) = q (i) for all i ∈ N \ (out ∪ inp).
For a ∈ Σ, the set of all system transitions on a in S is denoted by E a (S), while E(S) = a∈Σ E a (S) denotes the set of all system transitions in S.
If t = (q, (out, a, inp), q ) ∈ E(S) then any CA A i for which i ∈ out ∪ inp is said to participate in t . If i ∈ out, then A i is a sender in t , otherwise it is a receiver. Since, by definition of system labels, out ∪ inp = ∅, at least one CA is participating in any system transition in S. Moreover, all system transitions in E a (S) are combinations of existing a-transitions from the CA in S and all possible combinations of a-transitions occur in E a (S). The elements of E a (S) are also referred to as synchronisations on a, even when only one CA participates. A synchronisation on a communicating action a in which a CA where a is an output action and a CA where a is an input action participate, is called a communication. Obviously, for a non-communicating action a ∈ Σ, either out or inp is empty in any system transition on a.
Example 2. The system transitions E msg (S chat ) of S chat from Example 1 in which CA A 3 participates are the following: ). Using this notation, we thus express whether A 1 or A 2 participates or not in a synchronisation and hence whether or not a communication takes place. Note that not all system transitions are meaningful in applications. For instance, ((2, 2, 0), ({A 1 , A 2 }, msg, {A 3 }), (2, 2, 3)) expresses that both clients join to send msg to the server. If we want to rule out undesired synchronisations we must declare a subset of admissible system transitions, which is the underlying idea of team automata.
Extended Team Automata. The CA combined in a system are meant to collaborate (form a team) through the simultaneous execution of shared actions. Such teams are formalised by our notion of extended team automaton. They are labelled transition systems with set of states Q and set of initial states I. Their transitions are always a subset ε of E(S) containing the admissible system transitions. Such subset is called a synchronisation policy. From the software engineering perspective, it is the task of the team designer to determine an appropriate synchronisation policy for a given system of components. We use the system labels (out, a, inp) in Λ(S) as the actions in team transitions. This is the main difference with the classical team automata from [8,23] and subsequent papers, where actions a ∈ Σ would have been used in team transitions. However, to study communication properties and their compositionality, explicit rendering of the CA that actually participate in a transition of the team seems useful.

Synchronisation Type Specifications
In [6], we proposed synchronisation types to specify in a convenient, syntactic way synchronisation policies. A synchronisation type (snd, rcv) determines ranges for the number of senders and the number of receivers that may take part in a communication. Both, the sending multiplicity snd and the receiving multiplicity rcv are given by intervals.
then at least o 1 and at most o 2 senders and at least i 1 and at most i 2 receivers are allowed. While o 1 and i 1 are always natural numbers, the upper delimiters o 2 and i 2 can also be given as * , which indicates that no upper limit is imposed. On the other hand, at most one of the lower delimiters o 1 or i 1 can be zero. In this case an output (respectively, input) of a communicating action can be performed by components without a participating receiver (respectively, sender).
Notable synchronisation types that can be defined include binary communication ( [1,1], [1,1]) and multicast communication ( [1,1], [0, * ]), in which exactly one CA outputs a communicating action while arbitrarily many CA input that action. We can also express full synchronisation on an action a by requiring as a synchronisation type for a (snd, rcv) with snd = [dom a,out , dom a,out ] and rcv = [dom a,inp , dom a,inp ].
For the following, recall that S = (N , (A i ) i∈N ) is a composable system with state space Q, actions Σ and communicating actions Σ com . In [6], we considered the situation where all synchronisations in S follow a single synchronisation type used uniformly for all communicating actions of the system. In practice it is, however, necessary to relax this interpretation and define synchronisation types individually for each communicating action of the system. This leads to our new notion of synchronisation type specification.

Definition 5 (Synchronisation type specification).
A synchronisation type specification over S is a mapping st which assigns to all communicating actions a ∈ Σ com a synchronisation type st(a) = (snd st(a) , rcv st(a) ).
For the non-communicating actions in S no synchronisation type is provided since this is only relevant when systems are composed; see Sects. 5 and 6. We will now discuss how a synchronisation policy, and hence an ETA, can be deduced from a synchronisation type specification. Let Remark 1. Note that for typing system transitions we use in a crucial way the information provided by system labels. If we had mere actions as transition labels of communications, as in team automata, it would not be clear whether a CA with a 'self-loop' participates in a communication or not. Consider, for instance, the system labels and transition from Example 2. In a team automaton over S chat there could be a transition ((2, 2, 0), msg, (2, 2, 3)) in which it is not clear whether one, two, or none of the clients participate, i.e. whether or not msg! is actually executed and by whom. In team automata, this is typically resolved by implicitly assuming that a loop of a CA in a transition implies its execution, a 'maximal' interpretation of ambiguous participation.
Each synchronisation type specification determines a unique synchronisation policy and hence a unique ETA in the following way: Definition 6 (Typed synchronisation policy). Let st be a synchronisation type specification over S.

The synchronisation policy determined by st, denoted by ε(st), is defined by
Note that for non-communicating actions a ∈ Σ \ Σ com for which no synchronisation type is specified, ε(st) is 'maximal' in the sense that we set ε(st) a = E a (S). This means that we allow all possible synchronisations in S. This is in contrast with [6], where we allowed arbitrary subsets of E a (S) rather than equality. It is, however, needed to get the compositionality results later on. Example 3. Consider global state (2, 0, 5) of the chat system S chat from Examples 1-2, where client A 1 can (autonomously) decide to execute either its output action leave or its output action msg. To enforce receptiveness, there must be at least one other CA ready to execute either action as an input action. Server A 3 only has output action fwdmsg locally enabled. If we set st chat (fwdmsg) = ( [1,1], [0, * ]) as synchronisation type for fwdmsg, then the server is allowed to move to state 0 by executing its output action fwdmsg on its own (rather than in a communication) after which the server is ready to accept inputs as required. This synchronisation type is not suitable for the other actions, e.g. a client should be prohibited to join without acceptance by the server, thus st chat (join) = ( [1,1], [1,1]) would be appropriate. Therefore, we define a synchronisation type specification st chat over S chat such that

Communication Requirements and Compliance
The idea of communication-safety in team automata is as follows. At each reachable global state of a team, whenever a communicating action is enabled at the local states of some components J in accordance with the synchronisation type of that action, then all components in J can execute this action from their local states as a communication within the team.
Communication-Safety of ETA in a Nutshell. Before giving formal definitions, let us explain in a nutshell how our approach works. Consider an ETA E(st) and a communication action a with, for instance, synchronisation type st(a) = ( [1,1], [1, * ]). Let A i be a component of the system for which a is an output action and let q be a global state of E(st) such that a is enabled at the local state q(i) of A i . Then we wish that a can be received by at least one other component in the team. We express this by a receptiveness requirement issued by component A i and written as rcp({i}, a)@q. If the ETA E(st) is compliant with this requirement, it is guaranteed that in state q, component A i can synchronise with other components in the team taking a as input.
Note that in case A i could also execute another output action b with the same synchronisation type at state q(i), subject to the corresponding receptiveness requirement, then the two requirements would be combined through a conjunction to rcp({i}, a)@q ∧ rcp({i}, b)@q. The reason for this is that components control their output actions and thus can internally decide which action to be sent. Hence, the choice of either of them should lead to a reception. The expression rcp({i}, a)@q ∧rcp({i}, b)@q is called a receptiveness requirement generated by st. Indeed, the information in the synchronisation type ( [1,1], [1, * ]) determines, due to the lower bound 1 of the output multiplicity [1,1], that already one component can induce a receptiveness requirement. On the other hand, the receive multiplicity [1, * ] tells us that a communication is really needed for the output of a. Indeed, if the receive multiplicity were [0, * ], then there would be no receptiveness requirement. If, however, the output multiplicity of a were [2, * ], then at least two components for which a is enabled in the current local states would be needed to issue a valid receptiveness requirement of the form rcp(J , a)@q with J determining the set of output components.
For input actions one could require responsiveness with the intuition that enabled inputs should be served by appropriate outputs. Unlike output actions, however, input actions are controlled by the environment, i.e. input choice is external. Guaranteeing that for a choice of enabled inputs, one of them is supplied with an output of other components suffices for the progress of a component waiting for a signal. Hence, if component A j enables input actions a and b in its local state q(j), then the responsiveness requirements, denoted by rsp({j}, a)@q and rsp({j}, b)@q would be combined with a disjunction to rsp({j}, a)@q ∨ rsp({j}, b)@q, which is called a responsiveness requirement generated by st. Of course, also responsiveness requirements can be issued by several components J instead of {j}.
In general, a team automaton E(st) over a system S is called receptive (respectively, responsive) if it is compliant with all receptiveness requirements (respectively, responsiveness requirements) generated by st at all reachable states of E(st). It is communication-safe if it is receptive and responsive.
Weak Compliance. In [6], we relaxed compliance to allow the team to execute some intermediate internal actions before being ready for the required communication. As anticipated in the introduction and in [10], in this paper we further relax the notion of weak compliance from [6]: if a group J of components has issued a communication request we allow the team to execute, without participation of J , some arbitrary other actions before being ready for the required communication. This is a very flexible interpretation of interaction compatibility that, to the best of our knowledge, has not yet been studied in a similar way in the literature, likely because the permission of intermediate actions is dangerous for obtaining compositionality results. Its formal definition is given in Definition 9.

Formal Definitions and Examples.
In the remainder of this section, we provide the formal definitions of the concepts explained above, partly illustrated by examples. The definitions of communication requirements and compliance are taken from [6], the definition of weak compliance in this general form is new and the proposal to derive communication requirements from synchronisation type specifications is inspired by [6], but simplified and at the same time generalised to fit with synchronisation types per action.
We still assume given a composable system S = (N , (A i ) i∈N ) with state space Q, actions Σ and communicating actions Σ com .

Definition 7 (Communication requirements).
Let a ∈ Σ com and q ∈ Q.
-Let ∅ = J ⊆ dom a,out (S) be such that a en Aj q(j) for all j ∈ J . Then rcp(J , a)@q is a receptiveness requirement for a at q.
-Let ∅ = J ⊆ dom a,inp (S) be such that a en Aj q(j) for all j ∈ J . Then rsp(J , a)@q is a responsiveness requirement for a at q. -A communication requirement at q is either the trivial requirement true or a receptiveness or responsiveness requirement at q or a conjunction or disjunction of communication requirements at q.
When all non-trivial atomic requirements occurring in a communication requirement ϕ are receptiveness (respectively, responsiveness) requirements, we also refer to ϕ as a receptiveness (respectively, responsiveness) requirement.

Definition 8 (Compliance).
Let E be an ETA over S with synchronisation policy ε. Then E is compliant with a communication requirement ϕ at q ∈ Q if either q / ∈ R(E) or ϕ = true, or one of the following holds: −−−−−−→ E q 3. ϕ = ψ 1 ∧ ψ 2 and E is compliant with ψ 1 at q and with ψ 2 at q 4. ϕ = ψ 1 ∨ ψ 2 and E is compliant with ψ 1 at q or with ψ 2 at q Note that when E is compliant with a requirement as in 1. and 2. above, then the components J can communicate through a synchronisation on a at q involving more CA from the output and input domains of a.
Recall that Λ(S) denotes the labels of E and let Λ J (S), with J ⊆ N, denote the set of labels in which CA from J participate, i.e. system labels (out, a, inp) such that j ∈ out ∪ inp for some j ∈ J .

Definition 9 (Weak compliance).
Let E be an ETA over S with synchronisation policy ε. Weak compliance is defined analogously to Definition 8 but replacing 1. and 2. by the following items: 1. ϕ = rcp(J , a)@q for some J ⊆ N and a ∈ Σ com , and there exists p ∈ Q, out ⊇ J and inp = ∅ such that q a)@q for some J ⊆ N and a ∈ Σ com , and there exists p ∈ Q, inp ⊇ J and out = ∅ such that q Compliance trivially implies weak compliance. Note that we require that the CA determined by J do not participate in the intermediate transitions. Moreover, it is possible that also CA not participating in the foreseen communication, do participate in the intermediate actions that are needed to reach the global team state where it can occur. This is a phenomenon known as 'state-sharing' (cf. [8,24]). It allows CA to influence potential synchronisations through their local states without participating in the actual transition.
Then the receptiveness requirement for join at state (2, 0, 5) is rcp({A 2 }, join)@(2,0,5), i.e. output action join of A 2 must be received as input by at least one other CA. The only CA with join as an input action is the server A 3 , but join is not enabled at its local state 5. However, in an ETA E over S chat where A 3 can transit from state 5 to state 0 by a communication with A 1 (or even alone) the CA A 3 would subsequently be ready to execute join in a communication with A 2 . Since the intermediate move of the server to state 0 is allowed by our new notion of weak compliance, this E is weakly compliant with the given requirement.
As discussed above, the guidelines for when which choice of communication requirements is suitable, must consider the synchronisation types of actions. Let st be a synchronisation type specification over S, q ∈ Q and a ∈ Σ com such that
As explained in Example 4, E chat (st chat ) is weakly compliant with the second conjunct. It is also weakly compliant with the first conjunct as after moving on its own to state 0, the server can receive msg. Requirement rcp({A 1 }, msg)@(2, 0, 3) is more tricky, since in state 3 the server already received a msg from client A 1 who wants to send another msg. Due to the new weak compliance notion this is ok, since the server can execute its non-communicating external actions ask followed by, e.g., reject to return to state 0 where it can receive msg. An example of a generated responsiveness requirement is rsp ({A 3 }, join)@(0, 0, 0 0, 0, 0). Clearly, E chat (st chat ) is only compliant with the first disjunct since either client can provide the required output action join. It is important to note that requirements generated from inputs rely on external choice of the environment and therefore it is sufficient if one of the offered inputs is served, which is expressed by the disjunction. We could only discuss here a few requirements, but a thorough analysis shows that indeed E chat (st chat ) is weakly receptive and weakly responsive.

Systems of Systems and ETA Compositions
In this section, we consider systems of systems and the composition of ETA given for each individual system. This yields ETA over the combined global systems. We also show how a global synchronisation type specification can be constructed from the local ones respecting the underlying local ETA composition.
Let n ≥ 1 and let, for k = 1, . . . , n, Hence, Σ k = i∈N k Σ k,i is the set of actions in S k and Σ k,com = i∈N k Σ k,i,inp ∩ i∈N k Σ k,i,out is its set of communicating actions.
To compose the single systems we assume that communicating actions within one system cannot be used to interact with other systems. So, we say that the family of systems (S k ) k∈ [n] is composable if for all k ∈ [n] and for all k = l ∈ [n], N k ∩ N l = ∅ and Σ k,com ∩ Σ l = ∅. Hence, in a composable family of systems, component names and communicating actions are unique to a system.

Definition 11 (System composition). The composition of a composable family (S k ) k∈[n] is the system k∈[n]
Notation. For the rest of the paper, we fix n ∈ N >0 and S k for k ∈ [n], as above. We moreover assume that (S k ) k∈ [n] is composable and that S = k∈[n] S k with state space Q and initial states I.
The set of actions of S is Σ = (k,i)∈[n]×N k Σ k,i = k∈[n] Σ k and the set of communicating actions in S is Obviously, Σ com contains the communicating actions Σ k,com of each subsystem S k but also actions which occur as input action in a component of one sub-system and as output action in a component of another sub-system. The latter are called interface actions and defined by Σ inf = Σ com \ k∈[n] Σ k,com . Example 6. We now add an arbiter to the chat system S chat from Examples 1-4 to regulate message forwarding by composing S chat with the singleton system {A 4 }, depicted in Fig. 1 (right). The idea is that the server must ask the arbiter to grant or reject permission to forward a message. The two systems S chat and {A 4 } form a composable family of systems; ask , grant, and reject are the interface actions.
Given the composable family of systems (S k ) k∈[n] , we describe how to compose an extended team automaton over S = k∈[n] S k from given ETA An ETA obtained as a composition of (E k ) k∈ [n] is an ETA over S. So it has state space Q, set of initial states I, and set of actions Σ as defined above. The essential part concerns the choice of the synchronisation policy ε for the composed ETA. We proceed as follows to define the system transitions of ε for each a ∈ Σ: 1. For each non-communicating action a ∈ Σ \ Σ com , we define Hence, ε a is the set of all system transitions for a in S whose projections to sub-systems S k having action a belong to ε k,a . 2. If a ∈ Σ com (a communicating action in S) we distinguish two cases: (a) a ∈ k∈[n] Σ k,com : Then, by composability, there is exactly one k ∈ K such that a ∈ Σ k,com and a is unique to S k . Fix this k and define Due to the uniqueness of a to S k , ε a is the set of all extensions of system transitions in ε k,a to the state space of S. (b) a ∈ Σ inf : Now a is an action shared as input and output action of some components of S but not shared as an input and output action of components in any sub-system S k . Therefore it is the design choice of the overall system architect to determine a set of system transitions ε a ⊆ E a (S).
This procedure leads to a unique ETA once a set of system transitions is provided for each interface action a ∈ Σ inf .

Definition 12 (Composition of ETA).
Let for all k ∈ [n], E k be an ETA over S k with ε k its synchronisation policy. Let ε inf ⊆ a∈Σ inf E a (S) be a set of system transitions in S for the interface actions from Σ inf .
The extended team automata composition w.r.t. ε inf is the ETA over S with synchronisation policy ε such that: 1. For all a ∈ Σ \ Σ com , ε a is defined as in item 1. above. 2. For all k ∈ [n] and a ∈ Σ k,com , ε a is defined as in item 2.(a) above. 3. For all a ∈ Σ inf , ε a = (ε inf ) a .
The next theorem shows the relationship between ETA composition and synchronisation types. If a family of ETAs is given, each one determined by a certain synchronisation type, then it is enough to specify synchronisation types for the interface actions in order to get the composition of the ETAs as an ETA generated by a single synchronisation type.

Theorem 1.
Let for all k ∈ [n], E k (st k ) be an ETA determined by synchronisation type specification st k and let st inf (a) be a synchronisation type for each interface action a ∈ Σ inf . Then Proof. (sketch) The proof is straightforward using the (syntactic) composability assumption for systems and the definition of ETA composition.

Compositionality of Communication Properties
We now study compositionality of communication properties. The issue here is to investigate conditions under which communication properties are preserved by ETA composition. The principle idea is that for this it should be sufficient to consider interface actions and to check (global) compliance conditions for them. We start by considering receptiveness and responsiveness. Proof. (sketch) The proof relies on the fact that projections proj N k (q) of globally reachable states q ∈ R(E(st)) to a sub-system S k are reachable in E k (st k ). Then one can propagate communication properties concerning communicating actions a ∈ Σ k,com from E k (st k ) to E(st). For interface actions compliance of E(st) with communication requirements is anyway assumed as a proof obligation.
The following corollary reformulates the second case in Theorem 2 to make it symmetric to the first case. This yields, however, a strengthening of the condition in the second case of Theorem 2 disregarding the fact that for responsiveness requirements it is always sufficient if just one of the input alternatives is served. Next we consider compositionality of the weak notions of receptiveness and responsiveness. The idea is to require weak compliance of the global team with all communication requirements concerning interface actions and then to rely on weak receptiveness (respectively, weak responsiveness) of the sub-teams. How this works is demonstrated by the following example. In state 3 the server already received a msg from client A 1 who wants to send another msg. The weak compliance of the sub-team E chat (st chat ) with rcp({A 1 }, msg)@(2, 0, 3) has shown us (cf. Example 5) that in the scope of E chat (st chat ) the server can execute the interface action ask followed by, e.g., reject to return to state 0 where it can receive msg. The crucial point is now that in the global scope of E(st) the server can communicate with the arbiter such that server and arbiter together perform ask followed by, e.g., reject and thus the server returns to state 0 where it can receive msg. Hence the compliance of E chat (st chat ) with rcp({A 1 }, msg)@(2, 0, 3) is propagated to E(st).
The example shows that weak compliance of the overall ETA E(st) with communication requirements concerning interface actions (ask and reject in the example) is a crucial assumption needed for compositionality. But there is still a subtle point to be taken into account as illustrated in the next example.
Example 8. Let A 1 , A 2 , and A 3 be the following three component automata: Let system S 1 consist of A 1 and A 2 and S 2 be the system consisting only of A 3 . The only communicating action in S 1 is a, since b and c are interface actions. Let E 1 (st 1 ) be the ETA over S 1 determined by st 1 (a) = ( [1,1], [1,1]). There are two receptiveness requirements generated by st 1 which are rcp({A 1 }, a)@(p 0 , q 0 ) and rcp({A 1 }, a)@(p 0 , q 1 ). Obviously, E 1 (st 1 ) is weakly compliant with both. For instance the first one is satisfied by the system transitions The intermediate transition before accepting a executes interface action b.
Since S 2 has no communicating actions, there are no synchronisation types and the ETA determined by the empty synchronisation type specification st ∅ is E 2 (st ∅ ) which coincides with A 3 when actions are replaced by system labels. [1,1]) and consider the ETA composition is weakly compliant with the first one and compliant with the second one. So all looks fine. In the first case the weak compliance holds because of the transitions The subtle point is here that in the first transition A 3 'calls back' to a component in S 1 , namely A 1 , before satisfying the receptiveness requirement of A 2 . This creates a kind of cycle which makes the overall team E(st) not weakly compliant with rcp({A 1 }, a)@(p 0 , q 0 , r 0 ). Indeed, if A 1 wants to send a then A 2 must first send b to A 3 which must first send c to A 1 . Hence the requirement of A 1 to send b is not satisfiable in the overall team. Therefore we must exclude the possibility of such 'call backs' when checking weak compliance for interface actions. This is taken into account in the conditions (a) and (b) of Theorem 3, where we consider weak compliance without participation of components of the sub-system where a requirement stems from.
The necessary assumptions discussed so far for obtaining compositionality in the cases of weak receptiveness and weak responsiveness are summarised in the following theorem. It additionally requires determinism of the sub-teams in order to get a unique lifting of intermediate activities in sub-teams when weak compliance is considered. for all a ∈ Σ inf . Let each E k (st k ) be deterministic and weakly receptive (respectively, weakly responsive).
Assume that E(st) is weakly compliant, for all a ∈ Σ inf and q ∈ R(E(st)), with all atomic communication requirements rcp(J , a)@q and rsp(J , a)@q that are valid for st inf (a). Moreover, assume that if ∅ = J ⊆ N k for some k ∈ [n], then the weak compliance holds 'without participation of components in N k \ J ', i.e. we assume that: (a) rcp(J , a)@q holds since there exist p, q ∈ Q, out ⊇ J and ∅ ⊆ inp such that out ∩ N k = J and q Now on the other hand, for the interface actions we obtain the responsiveness requirements rcp({A 3 }, grant)@(p, q, 4, 1), rcp({A 3 }, reject )@(p, q, 4, 1), and rcp({A 4 }, ask )@(p, q, r, 0) for any local states p, q, r such that the given global state is reachable within E(st). Obviously, E(st) is (even) compliant with the first two requirements and with the third requirement if r = 3. In all other possible cases for r, E(st) is weakly compliant with rcp({A 4 }, ask )@(p, q, r, 0). For instance, in the initial state (0, 0, 0, 0) there is a path in E(st) without participation of the arbiter reaching state (2, 0, 3, 0) (where the server already received a msg from client A 1 ). Then the input ask of the arbiter can be served by the server. Since this holds similarly in all other cases, condition (b) of Theorem 3 is satisfied. Hence, as a consequence of Theorem 3, E(st) is weakly receptive and weakly responsive.
We are aware of just a few approaches that consider notions of compatibility with respect to responsiveness. Both [15] and [22] consider system models with synchronous composition. Notably, in [15] responsiveness is captured by deadlock-freeness, while in [22] responsiveness is expressed as part of the definition of bidirectional complementarity compatibility. The latter, however, does not support a choice of input actions like we do. Finally, [17] can express sending constraints on partners in an asynchronous environment. It supports two kinds of communication styles: client/server and peer-to-peer.
Synchronisation types constrain the number of components which can simultaneously execute a shared action. There are approaches which do not rely on shared actions but specify possible interactions by determining which actions may or must synchronise. This originates already in Winskel's synchronisation algebras [31] providing an abstract model to specify different synchronisation styles for parallel composition. For describing system architectures BIP [1] proposes interaction models using connectors for ports (actions) of components. Typical architecture styles can be graphically represented [30]. Also compositionality results are provided but the focus is not on the analysis of input and output compatibilities.

Conclusion
We considered ETA, their specification by synchronisation types, and their (weak) compliance with communication requirements generated from synchronisation type specifications. In this sense our approach is generic, generating notions of communication safety for various kinds of synchronisation types. An essential contribution concerns the composition of systems and of ETA, and the investigation of criteria ensuring preservation of communication properties by composition. Verification of communication requirements in concrete cases is still a tedious task, which should be supported by appropriate future tools. Moreover, the validation of our approach on the basis of larger case studies is a future goal. From a software engineering perspective we are also interested in hierarchical designs where sub-teams are first encapsulated into CA by hiding communicating actions to make analysis of larger systems feasible, e.g., by using techniques of minimisation with respect to observational equivalence. Moreover, to support reusability we could also add an explicit notion of system connector to match actions of different systems by renaming. A further desired extension concerns the introduction of designated states in CA where execution can stop but may also continue, in addition to states where progress is required. As sketched in [10], their addition has significant and useful consequences for the derivation of communication requirements and compliance.