er-CNW, for all switches in the whole network. If the slave reports to the master that its switch is congested or out of order, the master records that as a blocking state for the slave-CNW. 6.2 A Service Network Modelling Case All these decisions are reflected in the master-CNW and the slave-CNW. Fig. 6.30 shows these ORMs, properties excluded. Master object resource model (master-ORM): Master-CNW model Connection slave-CNW Network conln *state conln AccessRoute Switch1 SwitchRoute or InternalRoute* conTo Channel 1,2,30 1,2,30 Connection Channel Position Channel endpoint Endpoint requires Connection Slave object resource model (slave-ORM): Slave-CNW model conTo conTo AccessRoute Switch2 master-CNW Connection conTo 'conTo endpoint Channel Position (in switch route)' requires Connection Fig. 6.30 The object resource models for the CNPC master and slave Both these models are based on the model in Fig. 6.20 that is modified to suit design decisions regarding decentralized control: When the master and slave communicate, they refer only to TR-SAPIs on the slave side (which identifies CNUs), a connection identifier (CI) and channel identifiers (chId) for the switch route. How channels of the slave's own access routes are associated to connection endpoints at CNUs and to positions in SW2, and how channels of the switch route are associated to switch positions in SW2, is unknown to the master. The master knows nothing about SW2 or how paths are identified on the slave side. The slave also records the state of all its own resources. The master manages the same information about its own resources, which are unknown to the slave. The master alone manages the state of all core routes. Reports from the slave about congestion and blocking states for SW2 are recorded by the master as a blocking state for the switch route. Reports from the 6 Process Control System Modelling slave about blocking states for TR-SAPIs are recorded by the master as block- ing states for CNUs. As has been indicated, for this decentralized schema to wo