Distributed process communication units

In principle, the process communication unit may be directly connected to any base system node in MicroSCADA Pro network. The application containing the corresponding process database, may be in another base system node and all data sent from the process communication unit is transmitted through the LIN objects between these nodes. The used protocol is ACP (Application Communication Protocol). The base system between the process communication unit and the upper base system routes the ACP messages in both directions. The STAn:B objects are created to both to the routing base system and to the base system running the database.

A commonly used system setup is based on the distribution of PC-NET process communication unit to separate computers. In this configuration, the primary link between the base systems is a LAN link. For more information on this

configuration, refer to Section 3.3.3.1. Distributed PC-NETs.

If the process communication unit is configured to contain slave protocols, in general it is recommended that the unit is directly connected to the base system which contains the application receiving the process data. In other words, it is not recommended that for example the COM500i application refers to STAn:S objects running in another computer.

3.3.3.1. Distributed PC-NETs

There are many reasons why it is necessary to divide the PC-NETs to operate in a separate computer or multiple separate computers:

* Computer hardware limitations of LON or serial cards

* Decreasing the problems caused by a computer failure

* Process communication causes CPU load

* Redundancy is required in the process communication level

The base system which is directly connected to the PC-NET usually contains no process database. Fig. 3.3.3.1.-1 presents the system containing a hot stand-by base system containing a process database and three separate computers for process communication. In the system, the CPU load caused by the process communication is divided to three CPUs. Furthermore, if a hardware failure occurs in some of the computers, the rest of the system is still under control.

SYS21 APL11 NET 1

HSBSYS

MAIN APL1 LAN WD APL2

SYS22 APL12 NET 2

SYS23 APL13 NET 3 Process

database

STA10..STA40 STA50..STA80 STA90..STA120

A070472

Fig. 3.3.3.1.-1 PC-NET configuration

The communication front-end base systems SYS21..SYS23 running APL11..APL13 only routes the ACP messages between PC-NET nodes and APL1. In the system start-up or in the hot stand-by switch the APL1 is defined to be in either of the base systems containing the database.

Fig. 3.3.3.1.-1 describes a situation, in which there is only one PC-NET running in each computer. In practice, each of these computers may contain multiple PC-NET instances and various set of lines using different protocols. Furthermore, each of these computed may also be doubled using hot stand-by configuration. The watchdog APL object needed in hot stand-by configuration is APL2.

At the process database level, the system may also contain mirroring. For more information about hot stand-by redundancy and mirroring issues, refer to

Section 3.9.1. Hot stand-by base systems and Section 3.10. Configuring mirroring.

The System Configuration Tool should be used in each of the computers running the PC-NETs. The configuration in the base system running APL 11 could be the same as presented in Fig. 3.3.3.1.-2.

A071293

Fig. 3.3.3.1.-2 System Configuration Tool

The corresponding STAn:B objects should be configured to the base systems containing the process database. The selected part from the SYS_BASCON.HSB file (described in Section 3.9. Configuring redundancy) for the system described above would be:

. .

@BS_NODES = (9,10, 21, 22, 23) ;BASE SYSTEM NODES

@FE_NODES = (1,2,3) ;FRONT-END NODES

@FE_NODE_LINKS = (1,1,1) ;LINK NUMBER OF FE NODES .

.

;FE_NOD_BEGIN

#CREATE NOD:V ;FRONT-END NODE

#LOOP_WITH I = 1 .. LENGTH(%FE_NODES)

#SET NOD:VLI = %FE_NODE_LINKS(%I) ;LINK NUMBER

@NODE = %FE_NODES(%I)

#SET NOD:VSA = 200 + %NODE ;STATION ADDRESS

#CREATE NOD’NODE’:B = %NOD

#LOOP_END

;FE_NOD_END

;BS_NOD_BEGIN

#CREATE NOD:V ;BASE SYSTEM NODE

#SET NOD:VLI = 1 ;LINK NUMBER

#LOOP_WITH I = 1 .. LENGTH(%BS_NODES)

@NODE = %BS_NODES(%I)

#SET NOD:VSA = 200 + %NODE ;STATION ADDRESS

#SET NOD:VNN = %SYSTEMS(%I)

#CREATE NOD’NODE’:B = %NOD

#LOOP_END

;BS_NOD_END

;STA_BEGIN Create STAn:B objects

@STA_NOD = %FE_NODES(1) ;NODE OF STAS 10..40

#CREATE STA:V = LIST(-

ND=%STA_NOD,-ST= ”LMK”,-TT=”EXTERNAL”)

#CREATE STA10:B=%STA

#CREATE STA:V = LIST(-

ND=%STA_NOD,-ST= ”SPA”,-TT=”EXTERNAL”)

#CREATE STA11:B=%STA

#CREATE STA:V = LIST(-

@STA_NOD = %FE_NODES(2) ;NODE OF STAS 50..80 .

. .

The definition file above will create NOD:B objects for base systems and PC-NET nodes. After this, the STAn:B objects are created for each station object created to the PC-NET nodes. This configuration should match with the configurations entered with System Configuration Tool.

When a hot stand-by switch, that is,“take-over” occurs during run-time, the main application changes to HOT state in the adjacent base system. In this situation, a procedure SHADMAPNET is executed and PC-NET nodes are informed that the application is running in another base system node. The used attribute is NET node attribute SY. For more information about the hot stand-by configuration and the run-time operation, refer to Section 3.9.1. Hot stand-by base systems.