CIP Method - Master and Slave

 

With behaviour hierarchies based on master-slave relationships
structure clashes of cooperating state machines are resolved in a problem-oriented way.

MODES and MASTER-SLAVE Hierarchies
The master-slave paradigm is based on the notion of process mode: The full behaviour of a process can be defined by a number of alternative behaviours called modes. Each mode is specified by a state transition diagram on the state space of the process. The input and output elements of the modes are also common to all modes of a process. Typical examples of modes are the initialization, working and shut down behaviour of device controllers, the modes of operation in technical production systems or the various error modes of protocol drivers in layered communication systems.

PROCESS Door
 MODE timedOpening
 MODE immediateClosing
 

 

The two modes timedOpening and immediateClosing define two different behaviours of the Door process. For a more complex example see Examples - Master and Slave.

The generic master-slave pattern consists of a master process which can induce mode changes in a slave process: At run time the active mode of a slave process is determined by the current state of its master; an induced mode change due to a master state transition does not alter the state of the slave. The state dependency of the modes is specified by a corresponding mode setting table, in which to every master state a slave mode is associated.

The hierarchical master-slave structure of a cluster is defined by an acyclic master-slave graph. In general a master can have several slaves, and a slave can be governed by several masters (multi-dimensional mode setting table).

MASTER--SLAVE GRAPH

Benefit of Master-Slave Hierarchies
Separating behaviour changes from basic interactions is the key for a save treating of context dependencies and race conditions: Mode changes do not alter the basic context relation of a process while basic interactions cause updates of context changes.

A main benefit of master-slave hierarchies is comprehensibility. This is due to the abstraction power of master-slave relations. Upcoming changes in the specifications can be handled far easier in the robust structure of master-slave models. Furthermore, the correspondences to the underlying problem structure will facilitate the maintenance and reuse of system parts.