Communication

interfaces

Module 18
Network architectures -
Basics
Contents

1 Introduction 3
1.1 PcVue version 3
1.2 In this module you will learn 3
1.3 Files and data used in this module 3
1.4 Third party software used in this module 3

2 This feature in PcVue architecture 4

3 The Concepts 5
3.1 Some important points to remember about network architecture 6
3.2 How stations are identified on the network 7

4 Configuring the Network Architecture 8

4.1 Using the Network Wizard 8
4.2 Network Architecture configuration objects 10

5 Station Lists 15
5.1 About the station lists 16
5.2 Use of the Station Lists in PcVue configuration 17

6 Introduction to Server Redundancy 18

6.1 Simplified principle of operation when using a redundant
configuration for real-time data 18
6.2 Simplified principle of operation when using a redundant
configuration and multiple active servers for historical data 19
6.3 Simplified principle of operation when using a redundant
configuration and a single active server for historical data 19

7 Network System Variables 22

7.1 How network status variables are named 22
7.2 Network status variables in common use 23

8 Network Messages in the Event Viewer 26

9 Summing-up 27

V12 Module 18 - Network architectures - Basics Page 2/27

1 Introduction
1.1 PcVue version
This module is for PcVue version 12.

1.2 In this module you will learn

How PcVue manages a networked architecture.

1.3 Files and data used in this module

1.3.1 PcVue projects
MODULE_18 (Start) – The starting point. A project with some variables, mimics
and an archive unit already configured.
MODULE_18 (After EX1) – What you should have at the end of Exercise 1.

1.3.2 Data
The PcVue projects that you create during this module will be tested by copying them
on to several of the student’s PCs and testing them live. Therefore it is important to
know what the IP addresses are for each PC. Your trainer will select which IP
addresses are to be used. If there are insufficient students (and hence PC’s) the
trainer may elect to use Virtual Machines instead.

1.3.3 PcVue dongle

You cannot run PcVue’s networking without a dongle. Make sure that you
have access to one before undertaking the exercises.

1.4 Third party software used in this module

Kepware OPC Server – An OPC server used in simulation mode to provide real-
time data for some of the exercises. Hoe to install and configure it was
explained fully in Module 16.
DukTo R6 - An easy to use file transfer tool designed for LAN use. Used to copy
files from one PC to another without worrying about users, permissions,
operating systems and so on. We will use it to distribute the PcVue projects for
testing.

V12 Module 18 - Network architectures - Basics Page 3/27

2 This feature in PcVue architecture

Figure 1

V12 Module 18 - Network architectures - Basics Page 4/27

3 The Concepts
The following diagram describes the most basic networked architecture.

Figure 2

In this architecture the PcVue SERVER is communicating with the equipment using
classical industrial communication (built-in drivers, OPC etc.).
The PcVue CLIENT is connected to the PcVue SERVER and collects the data using the
Networking Interface. The protocol used between PcVue SERVER and CLIENT is
proprietary over TCP/IP.
The communication between PcVue SERVER and CLIENT is similar to OPC and it’s
done in these steps:
Step 1. On start-up the CLIENT connects to the SERVER.
Step 2. Once it’s connected, the CLIENT attempts to subscribe to all the
variables that it requires.
Step 3. The SERVER registers the subscription for each variable and returns
the current value to the CLIENT.
Step 4. For each subscribed variable, the SERVER notifies the CLIENT when
the value or the status changes.

V12 Module 18 - Network architectures - Basics Page 5/27

3.1 Some important points to remember about network
architecture
The PcVue project is the same in all stations. Therefore the deployment is very
easy: you only have to copy the project folder to each computer. For this
reason it is also worth considering the use of Central Project Management.
Each variable is “owned” by a particular PcVue SERVER Station. In PcVue
terminology we say the variable is produced by a SERVER and consumed by a
CLIENT.
Variable behavior on a client is modified. For example, for a threshold, the
threshold state is only calculated on the server. For more information see the
help topic Behavior of variables on a Client Station.
Only the Producer (Owner) of a variable can set its value or change its status.
 When the operator clicks on a button to set a variable on the CLIENT
station (Consumer) PcVue sends a SET request to the SERVER (Producer).
The SERVER manages setting the value. When the value changes it will
notify the CLIENT in the normal manner.
 When the operator acknowledges an alarm on the CLIENT station
(Consumer) PcVue sends an ACK request to the SERVER (Producer). The
SERVER manages the acknowledging of the alarm. When the status
changes it notifies the CLIENT in the normal manner.
The Producer of a variable not only provides its value but also the value’s
timestamp. Therefore it may be necessary to synchronize the time on all the
stations of a network.
Although there is no difference in the software or configuration of a server or
client, there is a big difference imposed by the license (protection key).
 A SERVER license does not allow the display of mimics (except for one
mimic normally used for system status).
 A CLIENT license does not allow communication directly with equipment.
 A SCADA license allows the display of unlimited mimics and
communication with equipment. You can think of it as a combined CLIENT
and SERVER.
 An HMI license allows the display of unlimited mimics and communication
with equipment. However it has no capability to communicate with
another PcVue station. We call this stand-alone.

V12 Module 18 - Network architectures - Basics Page 6/27

3.2 How stations are identified on the network
Each station of a networked application has a unique name and number. The name
you can define yourself but the number is allocated automatically by the Network
Wizard. The numbers start at 1 for servers, 50 for associations (see later) and 100 for
clients. The number is not visible in the Network Wizard dialogs but it is important to
know about it as it is used in some of the network system variables.
When PcVue runs, the station is identified, and thereby allocated a name and number,
by matching the configured IP addresses (or host name) with that of the host PC.

V12 Module 18 - Network architectures - Basics Page 7/27

4 Configuring the Network Architecture
4.1 Using the Network Wizard
The easiest way to configure your network is to use the Network Wizard.
Step 1. Open the Application Explorer and expand the configuration tree to
select the Networking node.

Figure 3

Step 2. In the task pane, click Networking Wizard.... PcVue opens the
Networking wizard. In the first step you must select if you are using a Remote
Desktop Session Host Server (or not) as the configuration steps are quite
different. We do not cover the RDS Host Server in this module so select Without
RDS Host Server and click the Next button.

Figure 4

V12 Module 18 - Network architectures - Basics Page 8/27

Step 3. In the Clients/Servers Creation panel click the Add... button for each
PcVue station in the network. The Wizard opens the Station Properties dialog.
Configure each station and click the OK button. When all stations are created
click the Next button.

Figure 5

Step 4. The Wizard opens the Real-time server association dialog. Click the
Add button if you are using real-time redundant architecture (see later),
otherwise click the Next button.

Figure 6

V12 Module 18 - Network architectures - Basics Page 9/27

Step 5. The Wizard opens the Historical Data Server Association properties
dialog (see advanced module). Click the Add button if you are using historical
data redundant architecture. Type a Name and select the Servers belonging to
this association. Click the OK button and then the Next button.
Step 6. The dialog Client and Server List Generation gives a summary of the
lists that have been created. Click on Finish to return to the Networking
Explorer.

Figure 7

4.2 Network Architecture configuration objects

When the Wizard has completed, the Application Explorer might look like this.

V12 Module 18 - Network architectures - Basics Page 10/27

Figure 8

Under the Stations node you will find one station for each client and each server that
were created. Associated with each station is a Communication Node. (Shown in the
right pane in the above picture)
Under the Lists node will be several station lists. The station lists are used to decide
the behavior of certain aspects of PcVue depending on if the station is a client or server.
Station lists are covered in detail in a later section of this module.
Under the Associations node will be any associations that have been created.

4.2.1 The Station dialog

You can open the configuration dialog for a station by right clicking on its icon and
selecting Properties from the context menu. Or - to manually create a new station use
the Add a station task.
Name – The name by which the station is known on the network. Generated
automatically by the Wizard although you can edit it if you want. You cannot
change a station name once the station is created.
Number – The number of the station. Generated automatically by the Wizard.
You cannot change a station number once the station is created.
Description – A general description of the station that does not appear
anywhere else other than the Application Explorer. This can be changed at any
time.

V12 Module 18 - Network architectures - Basics Page 11/27

Figure 9

Click the OK button to close the dialog.

If you were creating a new station (not using the wizard) then, at this
stage, the Communication Node dialog would open automatically.

4.2.2 The Communication Node dialog

The Communication Node defines the station’s physical connection to the network.
Each node requires one physical network card. A single station can have up to four
communication nodes although two is the most you will see in practice (used for
redundant networks). To open the Communication Node dialog select it in the right
pane and use the Properties task. To manually add a new Communication Node to a
station use the Add node task.

V12 Module 18 - Network architectures - Basics Page 12/27

Figure 10

Name - The Name is completed automatically. You can change it if adding a

communication node manually but it is recommended that you use the
default.
Access – All modern system use TCP/IP. The NetBios option is only for
backwards compatibility.
Connection parameters - It is preferable to use the IP Address. The Port
number is completed automatically. Only change this if you know that the
default setting will be a problem
Click OK to confirm the configuration and close the dialog.

The Port number defines the “channel” used on the TCP/IP

network. You can think of it as a virtual physical connection. A
port number can only be used by one application on a particular
PC and so occasionally there is a conflict and you must change it.

You can use the command line tool IPCONFIG to check the IP
address of your PC.

V12 Module 18 - Network architectures - Basics Page 13/27

You may have noticed that we haven’t selected if a station is to
be a client or server.

In fact all stations have the possibility to be both client and

server (but see below). When using the Network Wizard, the
properties Real-time data server and Real-time Data client only
affect the way in which the station lists are configured. All will be
revealed in the next section!

The Network Wizard can only be run if the network configuration

is completely empty. This effectively means that you can only
run it once (for a particular project). After that, any changes
you need to make to the network configuration must be done
directly using the networking configuration dialogs, or by
deleting the entire network configuration and starting again!.

V12 Module 18 - Network architectures - Basics Page 14/27

5 Station Lists
Consider the following diagram representing a BMS application. There are two servers
and three clients. The application is made slightly more complicated by the fact that
two of the clients are dedicated to a particular server but the other can access both
servers. Actually - this is a fairly typical arrangement.

Figure 11

Each SERVER collects data from the various sources and notifies:
DataClient1 & DataClient2 for DataServer1
DataClient2 & DataClient3 for DataServer2
You can create this application and its architect using just a single project, but in
order to do this we must make greater use of the Station Lists. However the required
Station Lists cannot be completely generated by the Network Wizard and so we must
adapt a configuration, manually creating some of the lists.

V12 Module 18 - Network architectures - Basics Page 15/27

5.1 About the station lists
It is very important to fully understand Station Lists as, used
carefully, for most networked applications they allow a single
project to be used for all stations.
The Station Lists define on which station a variable’s value is produced and on which
stations it is consumed. A variable’s value is always produced on a single Server (or
Association – see later) and consumed on one or more Clients.
In a variable’s configuration a Server List and a Client List is selected.
The Server List contains the name of the station where the variable’s value is
produced.
The Client List contains the name(s) of one or more clients where the variable’s
value is consumed.
The Network Wizard generates several Station Lists but if you are using any
configuration other than a simple single server, the chances are that you will need to
manually create the Station Lists to suit your architecture.

V12 Module 18 - Network architectures - Basics Page 16/27

5.2 Use of the Station Lists in PcVue configuration
The station lists can be used in several other aspects of PcVue’s configuration
primarily to enable them (or not) depending on the station. For example you would
want to disable any data acquisition on a station being used solely as a client.
Data acquisition – OPC, IEC 60870-5-104, IEC 61850, DNP3, BACnet and
Lonworks.
Actions - Cyclic and event actions.
Expressions.
Client/Server archive units - Controlling if each archive unit is to be a client or
server or both. Mandatory if you are using client/server archiving.
User accounts - Controlling the availability of each user account on each station.
Optional - only necessary if different User accounts are required at each station.

You can also use station lists to enable/disable PcVue’s native

communication drivers but you must manually edit the
configuration file COMM.DAT.

V12 Module 18 - Network architectures - Basics Page 17/27

6 Introduction to Server Redundancy
Redundant server operation is available for applications where system availability is of
prime importance. You can configure redundant operation for either or both real-time
and historic data.
There are two types of redundant configurations available for real-time data - the one
most suitable for your application will largely depend on the type of industrial network
you are using.
Single Active Server: suitable for all networks.
Multiple Active Server: only suitable for multi-master or dual path networks.

6.1 Simplified principle of operation when using a redundant

configuration for real-time data
Two or more stations are configured as real-time servers. Their configuration is
identical. All servers are connected to the industrial network and the local area
network. At any time, one of the servers will be active and the others passive.
In the network configuration the server stations are included in a real-time
association. Clients are configured so that they are linked to the association, not
directly to one or other of the actual servers. The association automatically routes
real time information from the active server to the clients.

Figure 12

V12 Module 18 - Network architectures - Basics Page 18/27

6.2 Simplified principle of operation when using a redundant
configuration and multiple active servers for historical data
Two stations are configured as historical servers. Their configuration is identical*.
Historical data is recorded on both stations.
In the network configuration both stations are included in a historical association.
Stations, where the archive units are to behave as clients, are configured so that they
are linked to the historical association. When processing a request (for example for
Trend data), the station on which the client archive unit is located checks to see
which of the servers in the association is available. If both are available, it sends the
request to the server with the larger Available rate. If the rates are identical then the
request is sent to the server with the lowest station number.

6.3 Simplified principle of operation when using a redundant

configuration and a single active server for historical data
Two stations are configured as historical servers. Their configuration is identical. They
both record data in the same SQL Server database. Only one station is active at any
given time.
In the network configuration both stations are included in a historical association.
Stations, where the archive units are to behave as clients, are configured so that they
are linked to the historical association. Requests for historic data are routed to the
active server.

Although the configuration is identical, the stations are allocated

different station numbers as this is dependent on the TCP/IP
address.

V12 Module 18 - Network architectures - Basics Page 19/27

Exercise 1. - Preparation
Modify your project so that the architecture reflects that of the
illustration Fig 22. (2 Servers, 2 Clients and a Real Time
Association). Use the Network Wizard to create the Network
Configuration and the Application Architect to generate the
variables tree.
This exercise requires a network of four PC’s. It can be useful to
make a note of the IP addresses and when you have completed the
configuration, the corresponding PcVue Station Name and Station
Number.
1.
___.___.___.___ ___________________ _____

___.___.___.___ ___________________ _____

___.___.___.___ ___________________ _____

.
___.___.___.___ ___________________ _____

2. Create the network configuration.

a. Delete any existing network configuration.
b. Run the Networking Wizard to generate the new
configuration.
3. Delete the entire existing Variables Tree. Again not strictly
necessary but tidier. (PcVue will automatically create new
SYSTEM variables and you will create the other variable using the
Architect.)
4. Create the new Variables Tree using the Application Architect and
the TEST template. (Pre-configured for you in the MODULE_18
(Start) project.)
a. Create two input parameters to be used to define the Client
List and Server List properties of the variables.
b. In the TEST template, define each of the variable’s Client
List and Server List properties using the parameters.
c. Add the parameters to the TEST template’s Parameters
folder.
d. Instantiate the TEST template creating a single instance
with the branch TEST.
e. Enter values for the two parameters you created in the
template instances corresponding to the existing Server

V12 Module 18 - Network architectures - Basics Page 20/27

Lists and the new Client Lists that you just created. (Hint –
use LCALL and DAS_ASSOC1
f. Save and Generate.
g. Close the Application Architect.
Open the Application Explorer and examine the variables tree.

You should only generate the new variables tree on a PC with an

IP address designated as a server.
What would happen if you generated the variables tree on a PC
with an IP address that was designated as a client?

V12 Module 18 - Network architectures - Basics Page 21/27

7 Network System Variables
PcVue automatically generates several system variables when you have configured a
networked application. Their main use is to monitor the status of the physical network
and network stations. You probably won’t need all of them (there are a lot!) but the
ones explained in this document will be required in most networked applications to
build status mimics, log network status etc.
A complete list of network system variables, and a more detailed
explanation of their operation, can be found in the help
The Application Explorer.Communication.Networked
applications.Network status variables

7.1 How network status variables are named

The branches used in the naming of network status variables are related directly to
the network items that you have configured. These are the main branches that are
used.
<StationName> = The name of the station.
<StationNumber> = The number of the station.
<NodeNumber> = The number of a communication node within a station. Each
node corresponding to a physical network card in the host PC. Node numbers
start at 0.
<NodeName> = <StationName>_<NodeNumber>
<ServerConnection> = The identity of server connection. For a TCP/IP network
<ServerConnection> = <StationName><NodeNumber>S
<ClientConnection> = The identity of client connection. For a TCP/IP network
<ClientConnection> = <StationName><NodeNumber>C
<AssociationName> = The name of an association as entered in the network
configuration. Associations are used in redundant configurations.

Versions of PcVue prior to 10.0 SP1 have a minor difference in

the way the <ServerConnection> and <ClientConnection>
names are constructed. If you open a project created with a
version prior to 10.0 SP1, variables using the old scheme will
still work as expected. However, if you create any new stations
in the network configuration, the new naming scheme will be
used when the new status variables are generated.

V12 Module 18 - Network architectures - Basics Page 22/27

7.2 Network status variables in common use
7.2.1 Variables providing the station ID
Name - SYSTEM.STATION_NAME
Type – TEXT
Value - the name of the local station (As configured in the PcVue network
configuration.)
Name - SYSTEM.STATION_NUMBER
Type – REGISTER
Value - the number of the local station

7.2.2 Variables providing the connection status between two stations

Name - SYSTEM.<StationName>
Type – BIT.
Value - The connection status of the local station to the remote station
<StationName>.
1 = healthy.
Example - SYSTEM.DATACLIENT1
Name - SYSTEM.<NodeName>
Type – BIT.
Value - The connection status of the local station to the remote communication
node <NodeName>.
1 = healthy.
Example - SYSTEM.DATACLIENT1_0

Most stations have only a single physical connection (node) to

the network so SYSTEM.<StationName> and
SYSTEM.<NodeName> are equivalent.

V12 Module 18 - Network architectures - Basics Page 23/27

7.2.3 Variables used to monitor connections (watchdogs)
Watchdog messages are produced by client stations so that the corresponding server
stations are able to verify their presence.
Name - SYSTEM.<ServerConnectionName>.WATCHDOG.COUNT
Type - REGISTER.
Value - Where <ServerConnectionName> refers to a communication node of a
local station, the variable counts all watchdog messages received by that
connection. Where <ServerConnectionName> refers to a communication node
of a remote station, the variable counts the number of watchdog messages sent
from the local station to that communication node. Modulus 1000. The value is
reset to 0 if the connection is broken.
Example - SYSTEM.DATASERVER10C.WATCHDOG.COUNT
Name - SYSTEM.<ClientConnectionName>.WATCHDOG.COUNT
Type - REGISTER.
Value - Where <ClientConnectionName> refers to a communication node of a
local station, the variable counts all watchdog messages received by that
connection. Where <ClientConnectionName> refers to a node of a remote
station, the variable counts the number of watchdog messages sent from the
local station to that communication node. Modulus 1000. The value is reset to 0
if the connection is broken.
Example - SYSTEM.DATACLIENT10C.WATCHDOG.COUNT

7.2.4 Variables used in redundant architectures

Name - SYSTEM.<AssocName>.<StationName>
Type - BIT.
Value - Set to 1 if the station <StationName> of association <AssocName> is
active or set to 0 if the station is passive. Produced by the station
<StationName> and all stations linked to the association.
Example - SYSTEM.DAS_ASSOC1.DATASERVER1
Name - SYSTEM.<AssocNumber>.<StationNumber>.ACTIVE_NUMBER
Type - REGISTER.
Value - The number of remote stations that are using the station
<StationNumber> as the active station of association <AssocNumber>.
Produced only by the station <StationNumber>.
Example - SYSTEM.50.1.ACTIVE_NUMBER
Name - SYSTEM.<AssociationName>.LOCALHOST
type - BIT.
Value - Set to 1 if the local station within the association <AssociationName> is
active and set to 0 if the station is passive. Produced by all stations. If the
station doesn't belong to the association <AssociationName> the variable value
is NS.
Example - SYSTEM. DAS_ASSOC1.LOCALHOST
Name - SYSTEM.<AssocName>.USER_STATION
Type – TEXT.
Value - The name of the server station of the association <AssocName> which
V12 Module 18 - Network architectures - Basics Page 24/27
refreshed the local station. It is the active server with respect to the local
station. Produced only by the stations which have a link with the association
<AssocName>.
Example - SYSTEM.DAS_ASSOC1.USER_STATION

V12 Module 18 - Network architectures - Basics Page 25/27

8 Network Messages in the Event Viewer
Understanding the network messages, which appear in the Event Viewer, is a very
important step in implementing network architecture. It enables you to check that
everything is working well.
To understand the messages you must first understand the connection process
between two stations. Consider the following diagram with two stations
DATASERVER1 and DATASERVER2.

Figure 13

At startup each station creates two interfaces , one server and one client. The
interfaces are given a name according to the following rule.
For the server <StationName><NodeNumber>S.
For example DATASERVER10S
For the client <StationName><NodeNumber>C.
For example DATACLIENT10C
After the interfaces are created the local station initiates a connection with the remote
station. Only a client interface can request a connection, so the local client interface
tries to connect with the remote server interface. For example DATASERVER10C will
try to connect with DATACLIENT10S.
The communication between two stations is only error free when you have both
connections. For example
DATASERVER10C <-> DATACLIENT20S
DATASERVER20S <-> DATACLIENT10C
If both of these connections are not established then you will have problems with the
application.

Don’t forget that stations are created as both client and server
by default. It is the station lists that determine if they are
producing or consuming variable values.

V12 Module 18 - Network architectures - Basics Page 26/27

9 Summing-up
Theoretically all architectures are possible with PcVue.
The PcVue project is the same on every station.
Redundancy is managed by a Server Association.
An Association manages real-time or archive data.

V12 Module 18 - Network architectures - Basics Page 27/27