m A centralized solution to the PCS implies that the object resource models on the network level are implemented and managed from a central point (here by TEPC and the CNPC). It is important to understand that whether one decides to use centralized or decentralized control has nothing to do with whether the units of the PCS are distributed or not. For example, it is most likely that the switches, the routes and the terminal systems of the resource system will be physically distrib- uted (TRs are, however, often aggregated to one or a few switching points in the network). This means that PCS units will be distributed as well, however, still with centralized network control functions. Figure 6.28 shows the modifications to the PCS that are needed if we assume that control remains centralized, but the two switches are physically remote to each other (SW1 in PN1 and SW2 in PN2). The TEPC and the CNPC are allocated in the same physical node as SW1. In this solution, the fact that CNPC and the SW2 con- troller are physically remote is hidden to CNPC by a service object in PN1 (the proxy object). This object does not manage any resource model. It performs a pure event-relaying function (see Sect. 5.6) between CNPC and the SW2 controller. The proxy object and the SW2 controller communicate over an abstract protocol in the 6 Process Control System Modelling D-dimension, since a message protocol that can carry the ASPs of S6 will be devel- oped between them. AR and abstract protocol, comprising S6-ASPs Proxy object AccRoute CoreRoute Controller Controller Manager Manager Fig. 6.28 Centralized control in a distributed process control system Note that this solution does not require any new resource model or changes to existing resource models. It also does not change the behaviours on the service net- work level. Thus, as long as object resource models in the abstraction hierar- chy are kept intact, the solution to PCS represents a centralized control solution, even if every object of the service network resides in a physica