Application planning and hints on distributed systems

Planning of distributed systems

The first thing to consider when planning a distributed system, is the topology. Different structures can be realized by connecting each system with each other. The topology of a distributed system is described in the config file (see Configuration file for distributed systems). The following questions should help to formulate the requirements of the distributed system:

  • How many sub systems does the complete system consist of? A sub system is in each case a server with an Event manager. In a redundant system both servers of the redundant pair are counted as one system. Remote stations are not considered.

  • Are commands transferred to the remote systems or is the data of these systems only displayed?

  • Is there are an excellent system which is a higher-level system than the other systems. Should the sub control rooms be able to communicate with each other. Which things do you want to handle from the main control room?

  • Are there systems with equal rights, which control one or several complete systems (manned and unmanned stations)?

  • Should only values of other systems be available on one system (visualization in specific panels, overview panels) or should the process images of remote systems also be displayed?

  • Should configuration be possible on all systems or only on one system?

  • In which systems should the collected data be evaluated (reporting, archiving, processing)?

  • Which systems are used at which time and who is using the systems?

  • Should the commands between the single systems be controlled?

  • Which alerts should be displayed in which systems? Who (which user in which system) may also acknowledge them.

The alert classes can be configured different on each system in a distributed system.

  • Which bandwidth (capacity of the network connection) is available for connecting single systems?

Hints and restrictions when working with distributed systems

General

Consider, that when using multiple distributed systems on a computer, additionally to the computer name, the port must be configured (see config entry: distPeer). It is recommended to use only one distributes system on a computer!

Hardware

Following hardware components are recommended for distributed systems (see also Requirements for WinCC OA):

  • The network connections between the systems should be permanent connections (leased lines). WinCC OAdoes not support switched lines directly. Switched lines are only possible when it is not visible for WinCC OAthat it is a switched line. Thus the router has to build the connection independently when data is transferred via the line and has to release the connection after the timeout. If you use switched lines ETMrecommends to use hardware routers of Cisco.

  • For the construction of computers in distributed systems not only the number of data points and dynamics of the local system but also the part of local used data points of other systems should be considered. Also the additional communication overhead should be considered.

  • For bigger applications (projects with > 20000 DPEs) computers with dual processors are recommended.

Archiving/reporting

You can access historical data of other systems only as long as a network connection exists. The data is located on the particular source systems by default.

  • If values should be saved historic in another system than the source system the data points have to be created also in the system in which they should additionally be saved. The values have to be transmitted via a runtime script with registration on these data points (this is, however, not recommended because problems with data, correction values, ... arise)

Rights

If a function may be used from several systems the specification and switching of commands have to be implemented manually (which user interface/which user may use the function on which system at a particular time. All other user interfaces/users normally do not have any rights in this case).

  • The user rights are evaluated also in the network of a redundant system. Thus, it is necessary to create the same users with the same rights on all systems.

Functions

  • CTRL functions should avoid intensive calculating, system-wide queries for performance reasons. Also a big number of dpConnect() calls on the data points of a remote system load the computer and the network considerably.

  • If you use dpConnect() to access data points note that the data points have to be located on the same system.

  • If you use the functions dpGet() or dpSet() to query or set several data points, NOTE that the DPs have to be located on the same system.

  • dpGet works only on the own system. If one dpGet is used to query two systems, it does not work and the following error message is shown in the log viewer:

    WCCOAui (1), 2007.09.26 14:11:19.266, PARAM,SEVERE, 175, this request cannot address more than one system, DP: dist_789:ExampleDP_Arg1.:_original.._value

    WCCOAui (1), 2007.09.26 14:11:19.266, CTRL, WARNING, 76, Invalid argument in function,

    WCCOActrl (2), 2007.09.26 14:24:54.887, PARAM,SEVERE, 175, this request cannot address more than one system, DP: dist_789:ExampleDP_Arg1.:_original.._value

    WCCOActrl (2), 2007.09.26 14:24:54.887, CTRL, WARNING, 76, Invalid argument in function, dpGetAll.txt Line: 14, dpGet

  • Note that all nodes of a distributed system must contain the same number of languages.

  • All parts of the "General" config cannot be set from a UI on a remote system. These parts are description, format, unit and alias. If you want to set these parts you have to do it via a control data point and via an easy runtime script that executes the command local. The configs can, however, be configured via a remote UI (VISION, PARA, GEDI) on each system via the network.

  • The functions dpCreate(), dpDelete(), dpGetAlias(), dpGetAllAliases(), dpGetDescription(), dpGetAllDescriptions(), dpGetFormat() work also cross the system boundaries. Note that when using these functions for queries on remote systems the system name have to be specified for the data point.

  • Data point types in Module PARA cannot be created changed or deleted in other systems than in the local one.

  • The configurations (saved default settings) of event and alert panel, trend, group data points etc. are always saved on the system on which the configurations were created (see also Alert and event panel).

  • Sum alerts (alerts) cannot handle alerts from 2 or more different systems simultaneously.

  • The initialization of the Dist Manager and its connection establishment might take longer than the start of the first user interface or runtime script (CTRL) when starting the system. If these should build connections (dpConnect() with hotlinks) to data point elements that are not local consider that the connection establishment is delayed as longs as the Dist Manager starts. Otherwise the data points of remote systems are identified as not available.

  • If you use a dpGet() on another system (not the local) and the dist connection does not exist, the dpGet returns 0 (OK). Query the error by using getLastError(). GetLastError() returns the following error message: "Message could not be sent, DP: System1:ap.:_original.._value, MAN: (SYS: 1 Dist -num 1 CONN: 1), Could not send message DP_MSG_SIMPLE_REQUEST #326"

SQL queries

  • You cannot execute SQL queries on 2 or more systems simultaneously. This have to be solved via two or more queries on a (in each case) single system. Also the alert and event panel divide such queries in the distributed systems internal into several queries.

  • Queries are executed with an appropriate SQL keyword (= REMOTE) cross the system boundaries. See also SQL panel. All systems can be queried via the keyword REMOTE ALL.

Driver configuration