1 Introduction
In [4], the authors present a translation from CCS [1] into CSP [22, 20], , which is correct up to strong bisimulation (cf. [10]). This means that a CCS process is strong bisimilar to its CSP translation. has been implemented in Haskell (cf. [23]), which allows using the modelchecker FDR [7] for analysing translated CCS terms. In the course of the same work, the authors have proposed an alternative translation, , correct up to failure equivalence. Both translations differ in the translation of the prefix term , translated into in the first case, and in the second case.
In this paper we present yet a third alternative, , achieved by first extending CSP with mamongn synchronisation [9], from which we can derive multiway (or namongn) synchronisation, the default CSP synchronisation mechanism, and binary syncronisation (used in CCS). Then, we translate CCS parallel composition into the binary version of CSP parallel operator. The resulting translation is correct up to strong bisimulation.
The translations in [4] were achieved by hard coding binary synchronisation into CCS before going to CSP. Using a renaming function, , the translations generated unique pairs of indices between any two pairs of complementary prefixes in a parallel composition, e.g., . This effectively made synchronising prefix pairs unique. Although these indices were generated in CCS, the renaming approach shows how to enforce binary synchronisation even in CSP: given a CSP process , to ensure binary synchronisations on , assign unique indices to accordingly, through renaming. E.g., ensures that pairs of processes and can synchronise respectively, but not . This approach, which we call the Gstar approach, has been encoded in the translation tool and the resulting CSP terms can be analysed in FDR immediately.
mamongn synchronisation [9] demands adding new rules to CSP, hence it would require updating FDR first. In other words, the CSP terms resulting from our new translation, , cannot immediately be analysed in FDR. Nonetheless, function implements binary synchronisation, hence, can be taken for an implementation of 2amongn synchronisation.
The Gstar approach does not allow translating recursive terms with nested parallelism (or replication). That is because function needs to generate every synchronisation index so the translation can terminate. With mamongn synchronisation, we need only one index to separate interleaving from synchronisation, i.e., we map every CCS name unto two CSP events, e.g., , where is the synchronisation event. Therefore, this new translation is not limited by parallel under recursion.
Our main contribution in this paper hence is a new translation from CCS into CSP which is correct up to strong bisimulation, is not limited by parallel under recursion, but cannot be immediately analysed with FDR. As a byproduct, we define mamongn synchronisation for CSP processes. We call the corresponding extension CSPmn. We show that CSPmn preserves CSP axioms by defining mamongn sysnchronisation in terms of both multiway synchronisation and renaming. The translation from CSPmn into CSP is limited by parallel under recursion as it requires generating unique indices for all possible combinations of synchronising processes.
2 Correct Translation, CCS(Tau), CSP, CCStoCSP
2.1 Correct Translations
A correct translation of one language into another is a mapping from the valid expressions in the first language to those in the second, that preserves their meaning (for some definition of meaning). Below we recall the two main definitions of correctness from [10].
Let denote a language as a pair of a set of valid expressions in and a surjective mapping from to some set of meanings . Candidate instances of are traces and failures (cf. [14, 21]).
Definition 1 (Correct Translation up to Semantic Equivalence [10]).
A translation is correct up to a semantic equivalence on when for all .
Operational correspondence allows matching the transitions of two processes, which can help determine the appropriate relation (semantic equivalence) between a term and its translation. Let the operational semantics of be defined by the labelled transition system , where is the set of labels and defines transitions with and .
Definition 2 (Labelled Operational Correspondence, [8, 19]).
Let be a mapping from the expressions of a language to those of a language , and let be a mapping from the labels of to those of . A translation is operationally corresponding w.r.t. a semantic equivalence on if it is:

Sound: imply that and

Complete: imply that and
The previous two definitions coincide when the semantic equivalence is strong bisimulation (Def.3) and is the identity.
2.2 CCS, CCSTau
Ccs.
CCS (Calculus of Communicating Systems) [17, 1] is a process algebra that allows reasoning about concurrent systems. CCS represents programs as processes, whose behaviour is determined by rules specifying their possible execution steps. The syntax of CCS processes is defined by the following BNF:
Let denote an infinite set of names; let range over . Let denote the set of conames. Let . Let denote the set of all possible labels. The set of labels of a process is denoted by ([17, Def.2, p52]). Let denote the silent or invisible action. Let denote the set of all possible actions that a process can perform. Let range over . The SOS semantics of CCS are given in Table 1.
Informally:
(or ) is the process that performs no action.
is the process that performs an action and then behaves like .
is the process that behaves either like or like .
is the process that executes and in parallel: if both and can engage in an action then, their execution corresponds to interleaving, e.g. ; if can engage in action , in the complementary action , then, either and interleave on or they synchronise and the result of synchronisation is the invisible action , e.g. .
is the process that cannot engage in actions in except for synchronisation, e.g., , .
is the process that executes recursively.
Equivalence based on bisimulations is the preferred choice for discriminating among CCS processes. We will use strong bisimulation to prove the correctness of our translation.
CCSTau.
CCSTau [4] extends CCS with visible synchronisations, viz., the result of synchronisation on a pair is the visible action instead of the visible action . This makes it easier to guarantee that when two processes synchronise in CCS(Tau), their CSP translation also synchronises. The syntax of CCSTau processes is defined by the following grammar:
The parallel operator in CCSTau is denoted . CCSTau also defines a hiding operator, denoted , which can hide all actions including actions. The restriction operator behaves as in CCS, does not apply to actions. Rules for these operators are given hereafter:
All other CCS operators are also CCSTau operators.
CCStoCCSTau.
Translation function [4] translates CCS processes into CCSTau, is correct up to strong bisimulation. For any CCS process other than CCSparallel operator, . For the parallel operator: ^{1}^{1}1The set of labels of a CCS process , , corresponds to the set of events for a CSP process .
(c2ccspardef) 
2.3 Csp
CSP (Communicating Sequential Processes) [14, 22] is a process algebra that allows reasoning about concurrent systems. In CSP, a (concurrent) program is represented as a process, whose behaviour is entirely determined by the possible actions of the program, represented as events. The set of events that a process can possibly perform is denoted by . Event denotes invisible actions, hidden from the environment; event denotes successful termination, by opposition say to deadlock and abortion. Both denotational and operational semantics have been defined for CSP processes, in terms of traces. The syntax of some CSP processes is defined by the following BNF:
The SOS semantics of CSP processes are given in Table 2. Informally: is the process that refuses to engage in any event, terminates immediately, and does not diverge.
is the process that is unable to interact with its environment.
is the process that first engages in event then behaves like .
is the process that behaves like or , where the choice is decided by the environment.
behaves like the parallel execution of and where the latter must both synchronise on the set of events . When , we say that and interleave, denoted by ; if we also write .
engages in whenever engages in .
is the process that engages in all events of except those in .
is the process that executes recursively.
2.4 CCStoCSP Translation
Notation.
Given two functions, say and , denotes functional composition, viz., .
In this section, we present [4], the translation from CCStoCSP, correct up to strong bisimulation.
Definition 4 ( [4]).
Let be a CCS process. Then:
where generates unique indexed prefixes such that a name maps to a set of indexed names ; generates unique doubleindexed names for every pair of synchronising names; renames every synchronising coname into the corresponding name (so they can synchronise in CSP); and translates CCS operators into corresponding CSP operators. We kindly refer the reader to [4] for details.
Example 1 ([4]).
The translation of CCS binary synchronisation into CSP can be illustrated succinctly as follows:
(ccs2cspdef)  
(c2ccspardef)  
(t2cspdef)  
(ixdef)  
(gstardef)  
(conmdef)  
(tldef)  
(ai2adef)  
In CCS, a name can be used both for interleaving and for synchronisation. This is reflected in the translation above by generating indexed names and for interleaving; then for the synchronisation pair , a unique synchronisation name is generated. More generally, there will be as many synchronisation names as there are of synchronisation on name .
In the next section, we extend CSP with mamongn synchronisation, then derive 2amongn (binary) synchronisation. In the end, we will be able to translate CCS binary synchronisation into CSP binary synchronisation.
3 CSP plus mamongn Synchronisation
Multiway synchronisation in CSP is maximal, viz., all processes that can synchronise must synchronise. This is also called the maximal (or nary) coordination paradigm ([9]): if processes are ready to synchronise on event , then all processes must synchronise together. Can we generalise this to allow only mamongn () processes to synchronise instead? If the answer is yes then binary synchronisation can be defined as 2amongn coordination and nary synchronisation as namongn coordination. Garavel and Sighireanu [9] define coordination for the language ELOTOS.
First, let us generalise CSP (nary) interface parallel operator ([22]).
Definition 5 ( clause [9]).
Let . Let be a natural number in the range associated to an event such that a clause denotes that processes are allowed to synchronise on event at once. Each clause is optional: if omitted, has default value .
The rules for indexed interface paralell composition are given hereafter.^{2}^{2}2The rules in [9] use a different rule format than CSP rules: they use predicates.
We can then derive binaryonly synchronisation by imposing that every event in set allows 2(only)amongn processes to synchronise.
Similarly, we derive naryonly synchronisation by imposing that every event in set allows namongn processes to synchronise. We easily verify that rules N/NIndxIfacePar and IndxIfacePar (synchronisation) are the same.
Correctness of M/NIndxIfacePar rule.
Let us call CSPmn the extension of CSP with mamongn synchronisation. We argue here that CSPmn is a conservative extension of CSP, i.e., CSPmn preserves the axioms of CSP.
The proof method is suggested to us by function [4]. For binary synchronisation, select process pairs that must synchronise and assign them a unique synchronisation index. E.g.,
Then, for processes to synchronise among , generate a unique index for all possible combinations of processes among , e.g.,
From what precedes, there exists a relational renaming, say , such that
We can thus define (CSPmn parallel operator) in terms of both (CSP parallel operator) and (CSP relational renaming) . Therefore, CSPmn is a conservative extension of CSP, viz., preserves CSP axioms (cf. Appendix A for a full proof).
4 CCSTau Transformations
The different stages of our translation are shown in Fig. 1.
Pairwise vs. Multiway Synchronisation
Recall, a CCSTau name has both interleaving and synchronisation semantics. We hence have to generate two distinct CSP events for a single CCS name. Also, it is possible to hide synchronisation actions in CCSTau (typically, to obtain a CCS process—cf. Def.c2ccspardef). Then, it will be convenient to ignore them. Let define the function that generates a synchronisation name for any CCS name.
Definition 6 ().
Given a set of names generated by , names denote interleaving, whilst names denote synchronisation. The application of to processes is given hereafter.
Definition 7 ().
Let be a CCS process. Let .
Note the difference between restriction and hiding. Names are generated between a process and its environment. Only those names will be restricted, understood that (restricted) names cannot interact with their environment. Internal synchronisation on names, however, will not be restricted (until later in CSP). In contrast, for hiding, internal synchronisation on must be hidden as well, hence we hide names instead.
Example 2.
Let us illustrate the translation of restriction.
(g2def)  
(g2resdef)  
(g2pardef)  
Contrast with hiding, which hides both and . (Recall .)
(hidedef)  
(g2def)  
(g2hidedef)  
(g2pardef, hidedef)  
Finally, consider hiding the synchronisation action , this turns out to be vacuous.
(g2def)  