<style type="text/css">CODE { font-family: sans-serif; font-weight: bold; }</style>
A *(term) that denotes a class of relationships on _(coalgebras|Algebra and Coalgebra) and which is dual to _(congruence). The concept of bisimulation has been defined by Park and Milner and is commonly used in the field of operational _(semantics). Bisimulations is used to define equalities on the states of some transition system or automaton, i.e. to flexibly define theories stating in which sense two automata "behave the same way". It is used with formal models for concurrent systems like the _(pi calculus), where computations usually have no final state nor "result" and thus we cannot say that two automata behave the same way if they produce the same result, as we would do, for instance, in the _(lambda calculus).

Let us consider a relationship <code>^</code> between the states of two automata <code>A1</code> and <code>A2</code>. We say that <code>^</code> is a simulation of <code>A1</code> in <code>A2</code> if it obeys a law stating that for every <code>s1</code>, <code>s2</code>:

if <code>s1 ^ s2</code> and <code>s1 -[a] s1'</code> then a state <code>s2'</code> exists such as <code>s2 -[a] s2'</code> and <code>s1' ^ s2'</code>.

With <code>[a]</code> we indicate that the state transition bringing <code>s1</code> in <code>s1'</code> is labelled with a label <code>a</code>. Labels are used to indicate both the cause of the state transition (for instance, the input of some value from the environment) and its observable effects (for instance, the output towards the environment of another value). The two aspects are often unified. The above property means that <code>A2</code> can "simulate step by step" any behavior of <code>A1</code>:

<code>
s2 -[a1] s2' -[a2] s2'' -[a3] ...<br />
^                ^                  ^                  ...<br />
s1 -[a1] s1' -[a2] s1'' -[a3] ...
</pre>
</code>

every instance of the lower row can be matched by some instance of the upper one.

The relation <code>^</code> is a bisimulation if and only if it is a simulation of <code>A1</code> in <code>A2</code>, and at the same time its inverse is a simulation of <code>A2</code> in <code>A1</code>. This means <em>not only</em> that every computation of <code>A1</code> can be matched by an analogous computation of <code>A2</code> and vice versa, <em>but also</em> that this match can be done through just one relation. In a word: a bisimulation is something more than a pair of simulations! 

The _(category-theoretic|category theory) definition of bisimulation is the following. A bisimulation between two coalgebras <code>A1</code> and <code>A2</code> is a coalgebra <code>A3</code> such as there is a span of homomorphisms from <code>A3</code> to both <code>A1</code> and <code>A2</code>. Intuitively, this means that there is an automaton <code>A3</code> that can be simulated contemporarily by <code>A1</code> and by <code>A2</code>, and this formalizes the previous definition.

Different flavours of "bisimulation" can be defined for a same formal model of computation by varying the definition of the transitions, of the labels, and by discarding or aggregating the labels. Being the union of two bisimulations again a bisimulation, it turns out that there is a bisimulation which is the biggest of all. Precisely, the biggest of all the bisimulation is the union of all the bisimulations, and we indicate as <code>~.~</code>. <code>~.~</code> is commonly called bisimilarity, so that two states <code>s1</code>, <code>s2</code> such as <code>s1 ~.~ s2</code> can be said to be bisimilar tout court. Bisimilarity is always a reflexive (every state is bisimilar to itself) and symmetric (if <code>s1</code> is bisimilar to <code>s2</code>, then <code>s2</code> is bisimilar to <code>s1</code>) relationship, and for most of, but not for all, the coalgebra signatures (functors, in category-theoretic terms) it is also transitive (if <code>s1</code> is bisimilar to <code>s2</code> and <code>s2</code> to <code>s3</code>, then <code>s1</code> is also bisimilar to <code>s3</code>). In the latter case bisimilarity has almost all the features of an equality theory on states. 

Why "almost"? In every formal models of computation like the _(pi calculus), the _(join calculus), the _(fusion calculus) et cetera, computing unit (usually called processes) can be composed by means of a series of operators, like parallel, choice, continuation... in a word, processes and these operators form an algebra. A true equality theory on processes should therefore have an additional desirable property: it should respect all the composition operations, so that we can "replace equals with equals" anywhere, and obtain equals: In a word, it must be a _(congruence). "Bisimulation as congruence" is a very desirable feature of a calculus for distributed, concurrent processes. Alas, the common case is that your favourite bisimilarity for your favourite computational model is not a congruence. For instance, if your favourite bisimilarity relation equates the inert process (which does nothing) with a process that waits to read on channel <code>x</code> and then terminates (perhaps because no other process is around to write on channel <code>x</code>, and so also this process is stuck), you can be sure that in this case bisimilarity is not a congruence. In facts, when both processes are composed in parallel with another process which writes on channel <code>x</code> we obtain two processes which behave differently: The first remains inert because the inert process does not read channel <code>x</code>, thus the writer is stuck altogether, while the second is composed by a reader and a writer for <code>x</code>, and therefore it may perform a computational step where the two components exchange a value on <code>x</code>. So you cannot safely replace under every context the inert process with a process that reads on a channel and then stops.

For this reason a true equality theory in process calculi is usually a suitable congruence <code>~</code> contained in <code>~.~</code>, rather than <code>~.~</code> itself. Which <code>~</code> should we choose among the many possible? Well, we have some degrees of freedom according to any additional desirable feature we want for <code>~</code>. Typically we want it to be big (the bigger the <code>~</code>, the more processes we can equate by means of it), better if it is the biggest congruence contained in bisimilarity. Other desirable features could be decidability and axiomatizability.