Principle and functionality

In easiest case a distributed system consists of two projects on different computers with different or same operating system. The distributed WinCC OA systems are connected via their own manager. This is the Dist manager (WCCILdist). The Dist manager builds the logical connection to several Dist managers of other WinCC OA systems. There is one Dist manager per system and it is responsible for the connection to all other systems. The redundancy is an exception. In a redundant system a Dist manager runs on each redundant computer. The data of other systems is accessed like the data of the local system. Data points of remote systems are not copied to the local system. Thus, you can only access the remote data when the connection to the specific system exists (when the connection to the sub system is lost queries are not possible anymore). Only active queried information is transferred (this means replies to queries that were executed on a sub system via dpGet(), dpGetPeriod(), dpConnect()).

The Dist Manager is responsible for the following tasks in a distributed system:

  • Connection establishment to other WinCC OA systems as well as monitoring of the connections

  • Exchange of the DP identification on all systems

  • Transmission of messages

Each system in a distributed system has to have a unique system name and a unique system number. The manager number of the Dist Manager is assigned automatically when the Data Manager starts. This means also the number of the particular system, which is not displayed inside the WinCC OA console!

The DP identification of the systems are exchanged when a sub system and the Dist Manager start. Each DP of a system is accessed in WinCC OA internal via a number instead of the name for performance reasons. This number is the DP identification (= Id). The names are converted internal to IDs via tables. The following information is used when converting the names:

  • Data point types: There is an internal table per DPT. This table contains the name of types and elements.

  • Data points: There is an internal table with the name per DP.

  • Data point elements: There is an internal table per DPE. The table contains the description, unit, format and alias.

  • System name

  • Config and attribute names (these are fixed and not changeable in the project)

In bigger projects, of course, also the DP Id is bigger and can be up to several MBs. The access to DPs (for example, with CTRL) would not be possible without this Id (further information on the DP Id can be found in the chapter DP identification).

Data points/System name

Each data point identifier (data point name) in WinCC OA contains as first part the system name (default is the own system). All data points within the system contain the same system name. Thus each involved system has to have a unique system name and a unique system number. Data points of remote systems are addressed specific by adding the system name and a colon.

System information of projects like system number or system name can be retrieved by the tool WCCOAtoolNameToId.

Example

"System3:ExampleDP_Trend1.:_original.._value"

If you refer to a data point in a script (UI, CTRL) without a system name the own (local) system is used. All scripts and all panels that should process or display data of other systems have to use complete data point identifiers.

Example

The following function call in a script only returns data points (that match the pattern) of the system where the function was called:

dpNames("*","ExampleDP_Bit");

The following call in a script returns the data points (that match the pattern) of all systems:

dpNames("*:*","ExampleDP_Bit");

Note that the system name is not used hard coded in project specific scripts! In the data point lists, which are imported via the ASCII manager, the data point identifiers have to always be specified without system name although the data points are imported to other systems!

The data point types and data points have to be different in the sub systems. The DP identification is exchanged when the connection to other systems is established via the Dist manager. Thus, all remote DPEs can be accessed (for example, with dpGet(), dpGetPeriod(), dpConnect(), dpSet(), ...). Note, however, that the data points of remote systems are not copied to the local system. This means that the data points are not multiplied and the data points of a sub system can only be accessed when a connection to this system exists. The DPEs on the remote systems can be used like the local DPEs (the connected systems and DPTs/DPEs are visible in the PARA module).

If the connection to a sub system is lost this is visible via the invalid bit of the original value for the attributes _original.._invalid and _original.._bad as well as via the online value for the attributes _online.._invalid and _online.._bad (see data point configs _original and _online).The user is informed when the connection is lost via quering these attributes. This means that all dpConnect()functions with reply (second parameter is TRUE) to a sub system return a hotlink with a "null" value and the status bits are set so that the value is marked as invalid. Furthermore, the dpConnects with a reply return an error (can be queried via getLastError()) with code 144. This applies also to the functions dpQueryConnectAll()and dpQueryConnectSingle().

Topology of a distributed system

Distributed systems in WinCC OA can be structured hierarchically. One system is on the top of the hierarchy, the further systems are located in the levels below. The system on the top is the "server" and the systems below "clients". This structure simplifies considerably the configuration of distributed systems. The following figure shows a distributed WinCC OA system in hierarchical form.

Figure: A hierarchical structure of a distributed system

In the figure above the System 1 is "server" for all other systems and accepts connections of these systems. System 2 connects to System 1 and is the server for the systems below (meaning system 4 and system 5).

The advantage of this kind of structure is the configuration of distributed systems with this configuration. When the parameters are set it is sufficient to specify the connection in one direction. (This means the system 1 is defined first under the "Settings of the new own project" via Creating a distributed system with the wizard. The second step is to create the further sub systems and configure their connections to other systems. This is made in the wizard via the "connected systems" part. See chapter Example of a redundant distributed system for an example of how to create a distributed system. If the connection to a system is built it is bidirectional and the systems "at the ends of the connection" see each other (if the connection from system 4 to system 2 is established both can communicate with each other and are visible in the system overview panel). This kind of structure means also that new lower-level systems can be included in the topology easy without a restart of the server (Dist Manager). How the configuration of a hierarchical structure looks like in the config file is described via the examples on different structures in the chapter Configuration file for distributed systems

WinCC OA systems that want to exchange messages with each other, have to be connected directly. The messages are not routed (for example, as shown in the figure above the system 4 cannot exchange any messages with the system 3). If the connection to a system is built once it is bidirectional and the systems "at the ends of the connection" see each other. Thus, the configuration of the connection in one direction is sufficient!

When querying which distributed systems are accessible, the DPE _DistManager(_2).State.SystemNums can be used. This DPE contains all systems that can be used for communication.

Forwarding of messages

The following paragraphs describe the messages and how the messages are forwarded (queries on sub systems) in distributed systems. The following figure should visualize the principle of distributed systems:

Figure: Distributed system in WinCC OA

The figure shows detailed the three systems shown already in the figure on the page Distributed systems, basics . System 3 is a single station system, system 2 a multiple-station system and system 1 is configured redundant. All three systems are connected via the local network. The network connection to the three computers used in this distributed system can be redundant. The three systems may have their own process connection. How to create a distributed system via WinCC OA is described in detail in the chapter Creating a distributed system.

When using this configuration the messages are forwarded as follows (the forwarding of messages is described using system 3 and system 2 ):

Note that the Dist manager has to run on System 3 and System 2 so that a connection exists and data can be exchanged between the systems!

  1. A CTRL script is started on system 3. The CTRL script queries values of DPEs on the system 2 (for example, via dpGet(), dpGetPeriod(), dpConnect()).

  2. The CTRL manager sends a message ("I want to query a value of DPE on system 2") to the Event manager of the own system. The Event manager forwards the message to the own Dist manager. The Dist manager again forwards the message to the Dist manager of the right system (in our case the system 2). The Dist manager on the system 2 forwards the message to the own Event manager that evaluates the message.

  3. The reply to the query is sent in reverse direction. This means that the Event Manager on the system 2 forwards the queried value to the Dist Manager. The Dist Manager on the system 2 forwards the value to the Dist Manager on the system 3 (which sent the query). The Dist Manager on the system 3 forwards the value to its Event manager and this forwards it again to the source. The source is the CTRL manager which processes the reply to the query.

If the connection between the Dist Managers is lost when dpConnect() registrations exist the registrations remain. When the connection is established again the values of existing registrations are updated for all registered managers.

Each manager in WinCC OA is identified via the manager type and number, system number and replica. Thus, each manager can be identified unique in a distributed system. Via this "manager identifier" you can forward messages to other managers in a sub system without a direct connection between the source and target manager (this means that all managers located between the source and target manager only forward the message and do not deal with the content, when a message is sent).

In a redundant system (for example, like in the figure System 1) the messages are forwarded via the Dist Managers of the sub systems in the distributed system like already described. The Dist Manager of the active computer, however, sends the message also to the active Event Manager in case of redundancy. The split mode in a redundant system is an exception. Since both Event Managers of the redundant system are active in the split mode the active Dist Manager has to be determined in the system overview panel (see also System overview in redundant systems). For further information on the redundancy and split mode see chapters Redundancy, basics and Redundancy in split mode.

LAN Connection State

The Dist manager shows the LAN connection state of a distributed system on an internal data point. If, for example, the 1 LAN connection in a distributed system fails, the status will be shown on an internal data point. In order to map the connection state, create data points of the type _ManagerConnections. Create the data points in the form:

dist_<sys1num>_<hostnum>_dist_<sys2num>_<hostnum>

Time difference between dist managers

The event manager checks the time difference between dist managers (refer to valueChangeTimeDiff). The result is written on the connection-specific data point _ManagerConnections.TimeDiff. If the maximum time difference is exceeded the connection is closed and an appropriate message is displayed in the LogViewer.