 needed, since the platform includes the neces- sary integrating functions on the abstract network level. In all other cases, these functions are specified as part of an abstract network. Abstract networks may represent local functions within a physical node, in which case each abstract machine corresponds to an application on the node plat- form of the physical node. However, if the corresponding service objects are dis- tributed over the physical network (which they often are in telecom process control systems) some abstract protocols will exist in the D-dimension of the actual physi- cal network level. This implies that abstract machines that handle those abstract protocols will be service elements in the C-dimension that interface some message- handling function, see Fig. 7.63. The model at the top shows a service network and indicates how it is integrated over three abstract machines and two physical nodes. Below, a model shows the event handler (a kind of service element) that imple- ments the abstract machines in the C-dimension (compare to Fig. 5.22). Assuming that all service objects that exist in an abstract machine are specified as AML service objects, all port objects of the corresponding state machines can be integrated in a common OPH that handles operations for all service objects and service ports. An abstract network model guides the integration process towards protocol net- works. Although AG2 and AG3 in Fig. 7.63 could be implemented in a single appli- cation on the node platform, the abstract network says that they should not be. As long as AG2 and AG3 are kept as separate applications, the abstract network model can be reused in another protocol network solution where AG2 and AG3 may be allocated in different physical nodes. 7 Concepts and Notations for Process Control Systems Modelling AG Agent AP Abstract protocol MEH Message handler OPH Operation handler VO Virtual object Event Handler platform connectivity message-handling protocol network connectivity Fig. 7.63 Integrating abstract netwo