Professional Documents
Culture Documents
How can I
manage a remote process application?
Disclaimer
This document is not comprehensive for any systems using the given architecture
and does not absolve users of their duty to uphold the safety requirements for the
equipment used in their systems or compliance with both national or international
safety laws and regulations.
Readers are considered to already know how to use the products described in this
document.
This document does not replace any specific product documentation.
Technical documentation
Application examples
Object libraries
Each STG addresses one or several customer challenges within the proposed
solution using the offer from Schneider Electric.
All explanations and applications have been developed by both Schneider Electric
experts and System Integrators in our solution labs. The contribution from the system
integrators helps the kits contents meet the expectations of our users.
All STGs are illustrated with industry-specific applications to give more concrete
examples of the methodology.
It is not intended that the STGs be used as substitutes for the technical
documentation related to the individual components, but rather used to compliment
these materials and training.
Development Environment
Each STG has been developed in one of our solution platform labs using a typical
PlantStruxure architecture.
PlantStruxure, the Process Automation System from Schneider Electric, is a
collaborative system that allows industrial and infrastructure companies to meet their
automation needs and at the same time address growing energy management
requirements. In a single environment, measured energy and process data can be
analyzed to yield a holistically optimized plant.
Table of Contents
1. Introduction...........................................................................7
1.1. Purpose ........................................................................................................................................................ 7
1.2. Customer Challenges ................................................................................................................................... 7
1.3. Prerequisites ................................................................................................................................................ 8
1.4. Project Methodology.................................................................................................................................... 8
1.5. Presentation of the Project......................................................................................................................... 10
2. Selection..............................................................................13
2.1. Architecture Selection ................................................................................................................................ 15
2.2. Remote Functionalities............................................................................................................................... 25
3. Design..................................................................................29
3.1. Introduction................................................................................................................................................ 29
3.2. Communication .......................................................................................................................................... 30
3.3. Remote Functionalities............................................................................................................................... 42
4. Configuration ......................................................................53
4.1. Introduction................................................................................................................................................ 53
4.2. Communication .......................................................................................................................................... 54
4.3. Remote Functionalities............................................................................................................................... 77
5. Implementation ...................................................................85
5.1. Introduction................................................................................................................................................ 85
5.2. Communication .......................................................................................................................................... 86
5.3. Remote Functionalities............................................................................................................................... 87
6.Operation............................................................................125
6.1 Communication Establishment.................................................................................................................. 125
7. Appendix ...........................................................................137
7.1 Custom Pages............................................................................................................................................ 137
7.2. Graphic Viewer ........................................................................................................................................ 150
7.3. Technologies ............................................................................................................................................ 153
1-Introduction
1. Introduction
1.1. Purpose
The purpose of this STG is to provide recommendations, guidelines, and examples to
help create a remote automation services including operating, monitoring and
maintenance.
This guide is focused on the implementation of remote control applications using
permanent, non-reliable communication.
The scope of the guide is summed up by this key question: What are the typical
applications where remote access and/ or remote control could be required? Such
applications include:
Cases for which mobility is a key element, the application can be directly
embedded on the transport medium. For example, a mining trucks automation
system can be controlled and monitored during its round trip.
The solution described in this STG forms part of a PlantStruxure control system. The
remote communication service used in the following architectures is GPRS provided
by the TSG ETG 302X module, which acts as a remote terminal unit (RTU).
1-Introduction
1.3. Prerequisites
We recommend the user have knowledge of the following software:
Unity Pro
Vijeo Citect
Basic requirements
Continuity of service
Architecture Selection
Selection Criteria
o
Security policy
Budget
1-Introduction
o
Process topology
Operator profiles
Description of architectures
Synthesis
2, Design: In this phase, we introduce the key functions and also highlight all
software and services required to perform remote access:
Communication
Ethernet
Internet access
IP Address publication
Network interconnection
Remote functionalities
Operating
Monitoring
Programming
Reporting
Operators Workstations
1-Introduction
Remote Site 2 :
Water Tower
Remote Site 1 :
Mobile Operator
Drinking Water Station
10
1-Introduction
Control Rooms
Mobile Operator
Remote Site
Remote Site
Water Tower
11
1-Introduction
12
2-Selection
2. Selection
You use the Selection phase of the project to choose the appropriate architecture.
Several remote systems are presented in this chapter, each providing scalable levels
of functions and services. All these architectures use an ETG 302X module as the
remote terminal unit.
Note: in the Schneider Electric offer, the W@de module is also available with similar
abilities. Future STGs will illustrate this remote terminal unit.
This chapter first defines selection criteria. A description of our architectures will lead
to a synthesis, relating the selection criteria with each architectures abilities. Finally,
the chapter concludes with an overview of all the remote functionalities performed by
our offer.
The architecture is selected based on the project and plants constraints, as well as
the required level of functionality.
13
2-Selection
The following illustration summarizes our projects approach:
14
2-Selection
Operator profiles
Security policy,
Process topology
Budget
Where are the operation teams located? (mobile team, centralized team, etc.),
Based on the answers to these questions, we recommend solutions that are easy to
implement and maintain. Thanks to its integrated services, installing the TSX ETG
302X module both on the control and plant sides can ease remote access
management.
15
2-Selection
Security Policy
The applications domain, or the criticality of the process can make security
considerations a critical facet. In such cases, the communications between control
room and remote sites or functional units must be secured using VPN tunnels
authentication and encryption. To address these requirements, the architectures
presented in the guide propose different levels of security. The ETG 302X module
embeds a VPN server that lets you link several LANs through the WAN with
authentication and encryption.
We also propose and describe alternative architectures with the NAT transparent
routing function. This technology brings transparency and ease of remote access but
does not provide authentication and encryption.
Operating, Monitoring and Programming Architecture
The operating and monitoring architecture has a significant influence on the global
system architecture. Examples include:
Mobile operator teams that require easy access to critical data, regardless of
location.
To remotely operate and monitor the architecture, the multiple control functionality
lets you create SCADA systems that rigorously duplicate the main system. In our
architectures, we use Vijeo Citect as a SCADA system and Factory Cast as a web
monitoring system.
16
2-Selection
Process Topology
The process topology depends on the number of remote sites that make up the
installation, the type of communication, and the requirements for synchronization
between remote sites.
In some automation cases, based on the process topology, the inter-plant
communication is a key feature. Functional units can be distant from the control room
and each other. Information provided by one functional unit can be triggers for others,
therefore, inter-site communication must be implemented. A TSX ETG 302X module
allows communication with TSX ETG 302X modules, provided the user has installed
a module in each remote site (functional unit).
Budget
Finally, the budget is an important criterion, as the entire automation architecture
depends on budget constraints. As a consequence, the person responsible for the
plant must organize all needs into a hierarchy, then define the most appropriate
architecture.
17
2-Selection
18
2-Selection
The following illustration shows architecture1, with NAT routing solution:
19
2-Selection
20
2-Selection
21
2-Selection
The following illustration shows the architecture 2, with VPN solution:
22
2-Selection
NAT Routing
Table
23
2-Selection
The following illustration shows the third architecture, with VPN solution:
24
2-Selection
Remote Functionality
Control room
(Factory Cast)
Remote terminal unit for data logging
Continuity of service
PAC station
Control
In our applications, the TSX ETG 302X module links LAN networks using the Internet.
The Internets connection is performed through a mobile communication network
(GPRS or 3G+) with the associated speed constraints of a wired connection.
This section describes these functionalities and how their features are completed
using our remote access management.
25
2-Selection
2.2.2. Maintenance
Maintaining an application remotely has both temporal and spatial advantages:
stakeholders can maintain the application from any location at any time. It thus allows
real time access of the installation from the modules integrated Web server. It allows
the creation of custom web pages and custom graphic pages to interact with the data
and/or devices. If required, remote programming can also be used to remotely fix
inoperative PAC stations or other devices (such as drives).
2.2.3. Diagnosis
Remote diagnosis can improve communication with the maintenance team, and
consequently reduce budget and enhance the global availability of the installation.
The E-mail service of the module provides two functions: reporting and/or alarming
via E-mail, and SMS. These functions are triggered by events.
26
2-Selection
Note: As an alternative solution, it is possible to automatically archive the
applications information into an external database (SQL Server, Oracle, and MySQL).
This guide does not illustrate this functionality.
2.2.5. Synthesis
The following table demonstrates our offers scalability:
Architecture 3 VPN
Security
Architecture 2 VPN
Architecture 1 VPN
Architecture 3 NAT
Architecture 2 NAT
Architecture 1 NAT
Process Topology
The following table shows the architecture and their associated criteria:
Selection Criteria
Architectures
Operators
Security
Operating
Profile
Policy
and
(Skills,
(NAT / VPN)
Budget
Topology
Monitoring
(Multi site
(Additional
availability)
Process
connection)
SCADA)
Architecture1
X/ XXXX
XXXX
Architecture2
XX
X/ XXXX
XXXX
XXX
Architecture3
XXX
X/ XXXX
XXXX
XXXX
XX
27
2-Selection
28
3-Design
3. Design
3.1. Introduction
The Design phase consists of the installation and preparation of all required services
and software, before proceeding to the configuration phase. We use the 3 system
architectures presented in the previous chapter. Three main components are part of
these architectures and require dedicated design:
Remote communication
This section explains the following key functions, classified in two main domains:
Communication
Ethernet
Internet Access
IP address publication
Network interconnection
Remote functionalities
These sections describe the functionalities the user can perform with remote access:
Operating
Monitoring
Programming
Reporting
Alarming.
29
3-Design
3.2. Communication
This section explains the main design features allowing the control room and the
remote sites to communicate. The graphic below shows the three structuring levels of
our architectures:
Local IP Address Management
IP Address Publication
Transparency or Security
IP Address Publication
30
3-Design
The user should manage items in the following order:
1. The local network parameters, to define IP addresses in the control room and the
remote sites. Ranges of private IP addresses are defined for local use only,
according to ICANN (Internet Corporation for Assigned Names and Numbers,
www.ICANN.org) rules.
4. The network interconnection, to link the remote LANs (from the control and plant
sides) through the WAN or Internet.
Each of these steps is described in the sections that follow.
31
3-Design
The following table lists the local network parameters:
Equipment
IP address
Sub-mask
Gateway
192.168.10.50
255.255.255.0
Operator
192.168.10.10
255.255.255.0
Workstation 1
192.168.10.50
(Architecture 1: blank)
Control Room 2
Operator
10.40.78.15
255.255.255.0
10.168.15.12
255.255.255.0
Workstation 2
Control Room 3
Operator
Workstation 3
Plant Remote Side
Plant 1
TSX ETG 302X
172.20.1.16
255.255.0.0
M340
172.20.1.4
255.255.0.0
172.20.1.16
ATV61
172.20.1.50
255.255.0.0
172.20.1.16
ATV61
172.20.1.51
255.255.0.0
172.20.1.16
ATV61
172.20.1.52
255.255.0.0
172.20.1.16
172.31.35.1
255.255.255.0
Premium
172.31.35.8
255.255.255.0
Plant 2
172.31.35.1
Note: To enable communication through the TSX ETG 302X module, you must enter
into the Gateway parameter of each equipment IP configuration the same address of
the TSX ETG 302X module.
32
3-Design
Companies (big water companies, etc) with needs for communications within their
intranet/extranet network (private access)
Companies (communal utilities, machine builders, etc) with needs for remote
access over the public network (internet access)
Private contract: for big companies account including remote access within their
intranet.
Option for various Data exchange rates (billing on data amount in Megabytes per
month or unlimited amount per month)
33
3-Design
Note: In this system technical guide we will use and describe Public type contract
(Machine to Machine or Telemetry) for public remote access with or without VPN
security. Nevertheless, Private contracts will also benefit of the same remote access
services as those described in this document.
Required Subscriptions
This table provides the required number of subscriptions, per architecture:
Architecture
Number
5 subscriptions
34
3-Design
PLANT1
90.95.78.174
PLANT2
90.95.13.125
OPWS1
80.10.20.11
OPWS2
80.10.55.142
OPWS3
90.95.36.179
The next OFS release will include the periodical renewal of the DNS.
35
3-Design
Before defining a URL, you must create an account on the www.dyndns.com website.
You must retain the login and the password of the DynDNS account, which are
essential for the Configuration phase explained in this STG.
After creating your account, follow the table below that explains how to create an URL
using DynDNS:
Step
1
Action
After the accounts creation, select the Service/ Add Host Service menu:
36
3-Design
2
Type your desired Hostname (plant1), then choose the URL extension
(dyndns.info).
Select the Offline Hostname checkbox, then click on Add to Cart.
3
DynDNS lets you create up to 5 URLs per account free of charge.. Click on
Next.
4
Repeat the operation to create the other URLs for this architecture.
37
3-Design
The following table lists the required URL names for Dyndns.com, according to the
VPN architectures:
Architecture
Name
Control Side
Plant Side
Operator Workstations
opws1.dyndns.info
1
plant1.dyndns.info
opws3.dyndns.info
opws1.dyndns.info
opws2.dyndns.info
plant1.dyndns.info
opws3.dyndns.info
opws1.dyndns.info
plant1.dyndns.info
opws2.dyndns.info
plant2.dyndns.info
opws3.dyndns.info
Note: The TSX ETG 302X module embeds a DynDNS client. If your modem does not
integrate this functionality, you must install the DynDNS Updater software on the
workstation to update the URLs to agree with the dynamic public IP address.
Install DynDNS Updater either by executing the DynUpSetup.exe file provided in this
guide, or by downloading it from the www.dyndns.com website.
The following table lists the workstations that require DynDNS Updater in the VPN
architectures:
Operator
Operator
Operator
Workstation 1
Workstation 2
Workstation 3
Architecture
38
3-Design
39
3-Design
Plant1
port 5000 assigned to the Modbus TCP port 502 of the M340 PAC
Plant2
Port 6200 assigned to the Modbus TCP port 502 of the Ethernet port of the
Premium PAC
Operator Workstation 1
Port 80 assigned to the HTTP port 80 of the Vijeo Citect Web Server
Port 2075 assigned to the Report Server Communication port 2075 of the
Vijeo Citect Web Server
Port 2076 assigned to the Alarm Server Communication port 2076 of the Vijeo
Citect Web Server
Port 2077 assigned to the Trend Server Communication port 2077 of the Vijeo
Citect Web Server
Port 2078 assigned to the I/O Server Communication port 2078 of the Vijeo
Citect Web Server
Port 2080 assigned to the Alarm Properties Connector port 2080 of the Vijeo
Citect Web Server
Port 2082 assigned to the Publish Suscribe I/O Server Communication port
2082 of the Vijeo Citect Web Server
Note: In the LAN, each equipment that are remotely accessed must be set with a
static IP address.
40
3-Design
Unit ID
In the third architecture, to exchange process values between the 2 remote plants,
the M340 Program of the PLANT 1 uses READ_VAR function.
In the NAT solution, the READ_VAR will not accept an address in the following
syntax: 90.95.13.125:6200. For this reason, we use the TSX ETG 302X modules
Unit ID routing.
Therefore, for the TSX ETG 302X module Plant 2, you need:
A Unit ID table for the READ_VAR function of the Plant 1.
We use the TSX ETG 302X modules ID 100 to route the frames to the ID 255 of the
Premium PAC IP address, which is 172.31.35.8.
41
3-Design
Programming, either for the PAC or the TSX ETG 302X module
Reporting
Alarming
3.3.2. Programming
The two following programs are required:
The operator workstations must run Unity Pro to be properly connected, and to
program the PACs.
Web Designer is required to configure the TSX ETG 302X modules services,
such as datalogging, calculation, Email/SMS, Graphic Editor, and Website.
42
3-Design
The Historical data management function is described below:
First, we define the roles played by Vijeo Citect and the TSX ETG302X module.
Vijeo Citect
Vijeo Citect manages the communication with its equipment (IO devices), through real
time variables (tags). It is possible to create historical files of these variables through
trends variables, in a Vijeo Citect proprietary format.
TSX ETG 302X Module
This module manages communication between the remote sites and Vijeo Citect.
Working concurrently with the SCADA system, the TSX ETG 302X module logs the
selected trend variables in its memory. This data can then be saved in .csv files type
to a configured memory media (RAM, CFCard, USB Key, or Flash memory). Once
this is done, the Vijeo Citect SCADA system can download these files using FTP
services.
43
3-Design
The following table shows the selected data to be restored and the data logging
period:
Variables
Flow in
10 s.
Flow out
10 s.
10 s.
1 min.
1 min.
1 min.
1 min.
1 min.
1 min.
1 min.
1 min.
Water Tower
Flow in
10 sec.
Flow out
10 sec.
Level
10 sec.
Note: These data must be configured in a consistent way by both the SCADA system
and the remote terminal unit.
Note: Vijeo Citect cannot refresh the variables as quickly in GPRS as in Ethernet.
Therefore, we define a minimum update rate in OFS at 5 seconds (refer to the OFS
paragraph) that leads to a minimum periodic historical value of 5 seconds for Vijeo
Citect Trends Tags.
44
3-Design
Functioning
Stage
Descriptions
The historical data management requires clock synchronization between the SCADA system and all
remote terminal units. Vijeo Citect regularly synchronizes the TSX ETG 302X modules clock on its
own, and also checks the communication between the other components.
The communication is established between Vijeo Citect, the TSX ETG 302X module and the others
equipment, for example a PAC situated downstream the module. The SCADA system (Vijeo Citect)
and the remote terminal unit are simultaneously logging the selected historical data. Vijeo Citect
periodically sends a purge request to the module, which then deletes the data logging files in its
memory.
45
3-Design
3
If the communication between Vijeo Citect and the TSX ETG 302X modules breaks down. The Vijeo
Citect historical data files storage can no longer run. On the TSX ETG 302X module, the periodic
purge stops and data logging keeps on running.
The communication between Vijeo Citect and the TSX ETG 302X module is reestablished, allowing
Vijeo Citect to once again create its own historical files.
Nevertheless, the historical data files related to the communication loss are missing. Vijeo Citect
downloads the data logging files from the module via FTP services.
46
3-Design
5
When the download process is complete, the purge process starts again.
Vijeo Citect recovers its historical data files from the previously downloaded data logging files, by
backfilling them into its own trend database, and then deletes the data logging files.
Note: Historical data backfill is managed by a Cicode Program (ETG_Include project). See Cicode
section in Implementation Chapter.
47
3-Design
Action
From the Windows Control Panel, select Regional and Language Options.
48
3-Design
Action
From Vijeo Citect explorer, right click on My Project, then select Restore.
Select Restore.
2
49
3-Design
Select the ETG_Include.ctz provided with this STG.
Note: In the Options panel, you must select the All sub-directories
checkbox.
Click on OK to restore.
3
50
3-Design
SectionCitect.ini file
The parameterization of Vijeo Citect is performed by a file called Citect.ini, placed by
default at : C:\Documents and Settings\All Users\Application Data\Schneider
Electric\Vijeo Citect 7.10\Config\.
The Citect.ini file includes the Vijeo Citect project parameters, and is common to all
the Vijeo Citect projects developed on a workstation. You can easily edit this file, due
to its .ini format, with a text editor such as Notepad.
The files parameters are organized in sections, automatically in alphabetical order.
Each section corresponds to a specific parameter area, e.g.Alarms, OPC, etc.
Because of its easy access and compactness, we use this file to parameterize
historical management. Open the provided SectionCitect.ini file, then copy and paste
this files content into the Citect.ini file.
The following screenshot shows the SectionCitect.ini files content:
The resulting Citect.ini file includes 2 parameterization areas that manage the
historical datas recovery, called ETGBackFill and ETG1BackFill.
ETG1BackFill corresponds to a first remote site.
51
3-Design
If creating a unique remote site, the user has nothing more to design.
If establishing multi-site communication, the user must copy and paste this
ETG1BackFill section into the Citect.ini file, and rename it according to the sites
index. For example, in the architecture 3, we have 2 remote sites: a drinking water
station and a water tower. The user must assign index 1 to the drinking water station
(ETG1BackFill), and index 2 to the water tower (ETG2BackFill).
For alarming features, the SMS messages are sent directly to a cellular. The
message body can display chosen real-time values.
The SMS is typically sent to the maintenance operators cellular, when a pump
becomes inoperative.
To illustrate SMS message sending we choose, in the Design phase, the monitored
actuators, which are:
52
4-Configuration
4. Configuration
4.1. Introduction
This chapter shows you how to configure previously defined key functions, before
proceeding to the implementation phase.
As in the Design chapter, this chapter is structured according to the following key
functions, classified in two main domains:
1. Communication
2. Remote functionalities
53
4-Configuration
4.2. Communication
4.2.1. Ethernet
This section shows you how to configure the Ethernet interface parameters of each
architectures equipment: operator workstation, TSX ETG 302X module, PAC, and
field devices.
Operator Workstation 1
Configure the IP address, gateway and subnet mask using the Internet Protocol
(TCP/IP) Properties windows.
The following screenshot shows the configuration related to the Architecture 1:
54
4-Configuration
The following screenshot shows the configuration for Architecture 2 and 3, using VPN
or NAT:
Operator Workstation 2
Use the following parameters:
IP address: 10.40.78.15
Subnet mask: 255.255.255.0
Default Gateway: blank
Note: This Workstation has the same Ethernet configuration for each architecture.
Operator Workstation 3
Use the following parameters:
IP address: 10.168.15.12
Subnet mask: 255.255.255.0
Default gateway: blank
Note: This Workstation has the same Ethernet configuration for each architecture.
55
4-Configuration
56
4-Configuration
1.1.TSX ETG 302X module Plant 1
Connect directly to the device typing its default IP address in a web browser. From
the Setup menu -> IP Configuration, type the new IP address, then click to apply
the modifications. Restart the TSX ETG 302X module from the Control menu ->
Reboot for the changes to take effect.
Then, to re-connect to the TSX ETG 302X module, you can now type its new IP
address 172.20.1.16 into the web browser.
1.2. TSX ETG 302X module Plant 2
Repeat operations described above in TSX ETG 302X module Plant 1, using the
following parameters:
IP address: 172.31.35.1
Gateway: blank
IP address: 192.168.10.50
Gateway: blank
57
4-Configuration
PAC Plant 1
The IP address parameter of the M340 PAC is configured with Unity Pro. The
gateway parameter must be initialized with the remote terminal units IP address, to
allow access to the internet from remote sites.
In the application, the TSX ETG 302X module connects the remote sites LAN to the
internet. Type the IP address of the TSX ETG 302X module into the Gateway
Address box of the PAC IP address configuration.
The following screenshot shows the configuration for the M340 PAC:
PAC Plant 2
From Unity Pro, configure the following Ethernet address for the PAC: 172.31.35.8/
255.255.255.0. To make this PAC accessible from the internet, specify the gateway
address..
The equipment connected to the internet for the Plant 2 LAN is the gateway TSX ETG
302X module, using GPRS.
Add the gateways address for the TSX ETG 302X module of Plant 2 172.31.35.1 in
the Gateway address box of the Premium PAC, as shown below:
58
4-Configuration
Once the parameters are set, click on the OK button to complete the internet
configuration.
Operator Workstation 2
Configure the modem, with the connection parameters provided by the ISP.
Operator Workstation 3
Configure the modem, with the connection parameters provided by the ISP.
59
4-Configuration
Note: The Access Point Name, provided by the ISP, is the identifier of the GPRS
network, and is directly linked to the subscription.
Note: We choose to configure the GPRS parameters from the modules web server,
but this configuration can be done in Web Designer as well.
TSX ETG 302X Module Plant 2
Proceed as previously defined for the TSX ETG 302X module of Plant 1.
TSX ETG 302X Module Operator Workstation 1
The configuration of the GPRS modem must be done for Architectures 2 and 3.
Proceed as previously defined for the TSX ETG 302X module of Plant 1.
60
4-Configuration
Step
Action
Click on Refresh Host List. Select the URL associated with the
desired operator workstation: opwsX.dyndns.info for the operator
workstation X. Validate by selecting OK.
Click on Start Updater to run the task that manages the periodic
update of the dynamic public IP address.
61
4-Configuration
62
4-Configuration
63
4-Configuration
From the Web server page via the Setup menu -> select NAT, validate the Enable
checkbox to activate the service.
Once the modifications are complete, click Apply, then restart the TSX ETG 302X
module by selecting Control menu -> Reboot.
Note: You may not access to the equipments that have hard-coded TCP ports.
1. TSX ETG 302X module Operator Workstation 1
The TSX ETG 302X module Operator Workstation 1 NAT configuration appears in
Architectures 2 and 3.
This routing table enables the Web client for the Operator Workstation 2, by routing
the TCP ports to the Vijeo Citect Web server corresponding to workstation
192.168.10.10. The following screenshot shows the routing table:
The TCP ports used (from 2075 to 2082) are specific to Vijeo Citect. The sources
ports 80 and from 2075 to 2082 can be modified. We choose not to modify them to
limit modifications. Refer to the Vijeo Citect documentation for full descriptions of
these ports.
2. TSX ETG 302X module Plant 1
The NAT configuration on the TSX ETG 302X module Plant 1 appears in all 3
architectures. This routing table provides access to TCP port 502 in the M340 PAC
(IP address: 170.20.1.4) via port 5000 of the TSX ETG 302X module Plant 1.
64
4-Configuration
The following screenshot shows the routing table:
Note: Here is the NAT syntax: TSX ETG 302X IP address: port (source port), and
then the TSX ETG 302X module routes to the M340 IP address: port (destination
port).
3. TSX ETG 302X module Plant 2
This NAT configuration on the TSX ETG 302X module Plant 2 appears in Architecture
3. This routing table provides access to TCP port 502 of the Premium PAC (IP
address: 172.31.35.8) via the port 6200 of the TSX ETG 302X module Plant 2.
The following screenshot shows the routing table:
65
4-Configuration
4. Unit ID
To enable the READ_VAR function used in the M340 PAC (Plant 1) to read the
Premium PAC (Plant 2) values, you must specify a recipient address in Unity Pro.
This recipient address in the READ_VAR function accepts a Unit ID, not the TCP port.
As a result, we use Unit ID 100 of the TSX ETG 302X module Plant 2 to return
information to the Premium PAC (Plant 2), as shown below:
On the M340 PAC side, the recipient address must have the TSX ETG 302X module
Plant 2 static public IP address, followed by its Unit ID, as shown:
66
4-Configuration
VPN Tunnel
1. VPN Client IPSEC File
This section shows you how to configure VPN for the workstations.
Retrieve the following .bat files, provided with this guide:
These files are used to open and close the VPN tunnels between the Control Rooms
and the Remote Sites. These 2 files must then be copied to the appropriate
workstation. You must edit the IPSecTunnel.bat file; no editing is required for
IPSecStop.bat. The information below shows you how to make the modifications for
each workstation:
1.1 Operator Workstation 1
67
4-Configuration
172.20.*.* (or 172.20.0.0/ 255.255.0.0): the remote network address for VPN
connection
68
4-Configuration
2.1 Architecture 1 VPN
The following illustration reminds you the Architecture 1 VPN:
69
4-Configuration
In this architecture, the VPN service for the TSX ETG 302X module Plant 1 is
configured to enable connection of 2 VPN clients.
Fill in the fields to configure both the VPN tunnel between:
The Operator Workstation 1 (VPN client) and the TSX ETG 302X module Plant 1
(VPN Server),
and the Operator Workstation 3 (VPN client) and the TSX ETG 302X module Plant 1,
as shown:
=> Operator Workstation 1<-> TSX ETG 302X module Plant 1 tunnel
Remote address corresponds to the Operator Workstation 1 URL, created on the
www.dyndns.com website, i.e. opws1.dyndns.info.
The Pre shared key, used for authenticate and open tunnels, is a user-selectable
choice. It must be the same for both the VPN client and TSX ETG 302X server sides.
In this example, we type useruser.
To allow the Operator Workstation 1 (VPN client) access to the M340 PAC through
the TSX ETG 302X gateway, select the Tunnel mode. This mode provides a LAN to
LAN connection. In contrast, the Transport mode provides a host to host
connection.
The others fields for this architecture remain blank.
=> Operator Workstation 3<-> TSX ETG 302X module Plant 1 tunnel
Create a second line to configure the second VPN tunnel for mobile Operator
Workstation 3, then follow the steps described previously.
70
4-Configuration
2.2 Architecture 2 VPN
The following illustration reminds you the Architecture 2 VPN:
71
4-Configuration
In this architecture, the VPN service for TSX ETG 302X module Operator Workstation
1 is configured to enable connection with 1 VPN server and 1 VPN client.
Fill in the fields to configure both the VPN tunnel between:
TSX ETG 302X module Plant 1 (VPN server) and the TSX ETG 302X module
Operator Workstation 1 (VPN client),
and the Operator Workstation 2 (VPN client) and TSX ETG 302X module Operator
Workstation 1 (VPN server), as shown:
=> TSX ETG 302X module Plant 1 <-> TSX ETG 302X module Operator Workstation
1 tunnel
Remote LAN corresponds to the address of the Operator Workstation 1 remote LAN.
Subnet Mask corresponds to the subnet mask of the Operator Workstation 1 remote
LAN.
ETG Client encryption is set to none, which corresponds to an AH encryption level.
This is the VPN Client that provides the encryption type used to implement the VPN
Tunnel.
Note: The ETG client encryption specifies the encryption protocol used for ETG to
ETG communication only. For more details, refer to the technical documentation of
the TSX ETG 302X module.
72
4-Configuration
In this architecture, the VPN service of the TSX ETG 302X module Plant 1 is
configured to enable connection with 2 VPN clients.
Fill in the fields to configure both the VPN tunnel between:
Operator Workstation 1 (VPN client) and TSX ETG 302X module Plant 1 (VPN
server),
and the Operator Workstation 3 (VPN client) and TSX ETG 302X module Plant 1
(VPN server), as shown:
=> TSX ETG 302X module Operator Workstation 1 <-> TSX ETG 302X module Plant
1tunnel.
Even if ETG to ETG communication is established, as in this case, the ETG client
encryption remains blank, as this is only the VPN Client that provides the encryption
type used to implement the VPN Tunnel.
73
4-Configuration
2.3 Architecture 3 VPN
The following illustration reminds you the Architecture 3 VPN:
74
4-Configuration
In this architecture, the VPN service of the TSX ETG 302X module Operator
Workstation 1 is configured for connection to 2 VPN servers and 1 VPN client.
Fill in the fields to configure the VPN tunnel between:
the TSX ETG 302X module Plant 1 (VPN server) and the TSX ETG 302X module
Operator Workstation 1 (VPN client),
the TSX ETG 302X module Plant 2 (VPN server) and the TSX ETG 302X module
Operator Workstation 1 (VPN client),
and the Operator Workstation 2 (VPN client) and the TSX ETG 302X module
Operator Workstation 1 (VPN server), as shown:
In this architecture, the VPN service of the TSX ETG 302X module Plant 1 is
configured for connection with 2 VPN clients and 1 VPN server.
Fill in the fields to configure the VPN tunnel between:
the TSX ETG 302X module Operator Workstation 1 (VPN client) and the TSX ETG
302X module Plant 1 (VPN server),
the TSX ETG 302X module Plant 2 (VPN server) and the TSX ETG 302X module
Plant 1 (VPN client),
and the Operator Workstation 3 (VPN client) and the TSX ETG 302X module Plant 1
(VPN server), as shown:
75
4-Configuration
In this architecture, the VPN service of the TSX ETG 302X module Plant 2 is
configured to enable the connection with 2 VPN clients.
Fill in the fields to configure the VPN tunnel between:
the TSX ETG 302X module Plant 1 (VPN client) and the TSX ETG 302X module
Plant 2 (VPN server),
and the TSX ETG 302X module Operator Workstation 1 (VPN client) and the TSX
ETG 302X module Plant 2 (VPN server), as shown:
76
4-Configuration
77
4-Configuration
1. Architectures 1 and 2
For these 2 architectures, Vijeo Citect communicates with only one site. Therefore,
only 2 components are required:
Plant 1 -> M340 PAC -> OFS, alias: OFS_M340
Plant 1-> TSX ETG 302X module -> OFS, alias:OFS_ETG1
2. Architecture 3
For this architecture, Vijeo Citect communicates with 2 sites. Two additional
components are required:
Plant 2 -> Premium PAC -> OFS, alias: OFS_PREMIUM
Plant 2 -> TSX ETG 302X module -> OFS, alias: OFS_ETG2
3. Common Parameters
The Update rate parameter, which is common to the entire OFS alias, lets you adjust
the minimum refresh speed of the alias. This parameters value effects the
communication load.
Using GPRS communication causes speed constraints. We specify a Group
minimum update rate to maintain fluent communication between the remote sites
and Vijeo Citect.
The Group minimum update rate is set at 5000ms. As a consequence, the
variables refresh rate is 5 seconds. This leads to a constraint on the historical period
for the Vijeo Citect Trend Tags, which cannot be less than 5 seconds.
Note: This parameter must be adapted to for your own project.
To set up the Group minimum update rate, click on the Communication menu in
the configuration OFS tool, then specify the value (5000) in the Group minimum
update rate field, as shown below:
78
4-Configuration
4. Alias Parameters
4.1 Adjustment Information
To improve communication performance based on GPRS speed constraints, adjust
the following parameters:
Max channels: set the PAC value to 16; and for the 2 ETG3021 alias, set the
Max channels parameter to 1. This parameter corresponds to the maximum
number of requests that OFS can process in parallel.
Frame timeout: 6666 ms, for the permissible delay between request and answer.
79
4-Configuration
4.3 Device Addressing
NAT
80
4-Configuration
VPN
The OFS configuration with VPN technology is the same as with local technology:
OFS_M340: 172.20.1.4
OFS_ETG1: 172.20.1.16 and Modbus Index 255
OFS_PREMIUM: 172.31.35.8
OFS_ETG2: 172.31.35.1 and Modbus Index 255
4.3.2. Programming
Note: for NAT routing, the installed Unity Pro version must be capable of managing
an address in this format: IPaddress:TCPPortNumber, i.e. Unity Pro 4.1 or later.
ExePath: the folder where the clock synchronization and CSV conversion
executable files are located.
81
4-Configuration
FirstTimeRegister: the first system register that defines the time for the TSX ETG
302X module.
PurgeTimeOut: the number of seconds allowed before determining that the purge
command has failed.
TrendFTP: the target folder of the historical files, downloaded via FTP to the TSX
ETG 302X module.
2. [ETG1BackFill] section
Open the Citect.ini file and go to the [ETG1BackFill] section. This section applies to
site 1 only. We represent remote site 1 by using the drinking water station 1
The following screenshot shows the [ETG1BackFill] section:
FTPPath: the storage media for the CSV files in the TSX ETG 302X module.
82
4-Configuration
IPAddress: For VPN architecture, the remote TSX ETG 302X modules private IP
address; for NAT architecture, the remote TSX ETG 302X modules static public
IP address.
TrendTable00: the name of the table created in the TSX ETG 302X module. You
must keep the same name of for this table in the datalogging service of the TSX
ETG 302X module.
TrendTable00Ratio: ratio
TrendTable01: the name of the CSV file/ table created by the TSX ETG 302X
for theTrendTable00.
module.
TrendTable01Ratio: ratio
TrendTable02: the name of the CSV file/ table created by the TSX ETG 302X
for TrendTable01.
module.
TrendTable02Ratio: ratio
for TrendTable02.
3. [ETG2BackFill] section
Open the Citect.ini file and go to the [ETG2BackFill] section. This section applies
only to remote site 2, which appears only in Architecture 3. We choose to represent
remote site 2 using the water tower
The following screenshot shows the [ETG2BackFill] section:
All definition parameters are the same as presented for the [ETG1BackFill] section.
4-Configuration
84
5-Implementation
5. Implementation
5.1. Introduction
This chapter shows you how to complete the final implementation for all key functions.
As in the previous chapter, this chapter is structured according to the following key
functions, classified in two main domains:
1. Communication
2. Remote functionalities
85
5-Implementation
5.2. Communication
5.2.1. Ethernet
The Ethernet configuration explained in the Configuration chapter, Communication->
Ethernet section is sufficient to implement this functionality..
86
5-Implementation
87
5-Implementation
Follow the instructions shown below:
Ste
Action
p
1
From the Target List, select FactoryCast Gateway TSX ETG 3021 V1.11.
Name it PLANT1, which corresponds to the drinking water station.
Fill in the Address field with 172.20.1.16.
Click on Next.
88
5-Implementation
3
In the Device List, select the ETG3021 Server V1_11 and the Modicon M340.
Fill in the Name and Address fields.
Click on Finish to complete the new projects creation.
4
Right click on the target, then select Transfer/ Target->PC to retrieve the
Ethernet, GPRS and NAT configurations previously defined by the web
navigator.
89
5-Implementation
5
Tick the Transfer Configuration checkbox, then select Flash in the Location
menu.Click on Transfer to start the upload.
Note: You can also transfer the Website, the rdt and gdt files by ticking their
corresponding checkboxes.
6
Once the upload process is complete, check from Web Designer, by a right click
on the target and selecting Properties, that the previously projects configuration
(from the Web Browser) has been correctly uploaded.
90
5-Implementation
Variables Declaration
You can declare two kinds of variables: internal or from a device.
The following paragraphs describe the declaration of the following:
1. TSX ETG 302X Server and Internal Variables Plant 1
Add manually internal variables by directly entering a symbol, an address (refer to the
TSX ETG 302X modules technical documentation for the list of the internal registers),
its type and define the access right in the Variables window of the module.
The following screenshot shows the variable content table after declaration:
Note: Once the variables are declared, select the Persistent checkbox to make them
usable for internal processing in all of the services such as Datalogging, Calculation
Email, and so on.
We create 5 additional variables for historical data management, which are:
backup: increments a word when Vijeo Citect creates a .csv backup file in the
TSX ETG 302X module.
purge: increments a word when Vijeo Citect purges a .csv backup file in the TSX
ETG 302X module.
StopBackup: word written by Vijeo Citect to stop the TSX ETG 302X module for
backup, during the .csv files downloading via FTP.
91
5-Implementation
2. TSX ETG 302X Variables for M340 PAC Communication
As previously, we add manually PLC variables by directly entering a symbol, an
address, its type and define the access right in the Variables window of the module.
All M340 variables have been previously created in the PLC.
The following screenshot shows the variable content table after the declarations in
Web Designer, which are used in the configuration of the datalogging service, custom
pages, and SMS/email:
Note: Once the variables are declared, select the Persistent checkbox to make them
usable for internal processing in all of the services such as Datalogging, Email, and
so on. You can also define the read rate, the read/write access.
92
5-Implementation
We retrieve:
The REAL type variables that correspond to analog measures (flow in/out, level
of the drinking water tank 2, current and speed of the pumps, etc.).
If your application contains several variables, another method can be used to save
time, as follows:
Import PLC variables by clicking on the Import PLC symbols button:
Choose your file, then select your wished variables on the following screen:
93
5-Implementation
5.3.2. Programming
To connect the operator workstations to the remote PAC using Unity Pro
programming software, you must specify the address of the remote equipment in
Unity Pro.
NAT Routing
For NAT connection, we use the TSX ETG 302X modules static public IP address,
followed by the port number, i.e. 5000.
The table below shows you how to specify the address to connect to the PAC of the
plant1:
Step
Action
Fill in the Address box of the PLC area with the following:
Static public IP:port, i.e. 90.95.78.174:5000, which is the public IP address
of the TSX ETG 302X module routed to the PLC port.
Select TCPIP in the Media box.
Note: This syntax is available with Unity 4.1 or later.
3
Do the same previous operations for the PAC of the Plant 2 with the
following address: 90.95.13.125:6200
Note: A DynDNS address can be used in the event of dynamic IP address. In this
case, Unity Pro accesses to the M340 with the following syntax: DynDNS address of
the TSX ETG 302X module: port (here, 5000) and the TSX ETG 302X module routes
to the M340 IP address, port 502.
94
5-Implementation
VPN Tunnel
No special configuration is required; fill in the Address field from Unity Pro as usual.
Because the connection is established through a VPN tunnel, we can directly use the
M340 PAC IP address. To connect to the M340 of the Plant 1, start Unity Pro, then
select the PLC/Set Address menu. Fill in the Address field for the PLC parameters
with the IP address, i.e. 172.20.1.4, then select TCPIP in the Media field. Do the
same operations to connect to the Premium of the Plant 2 with the following address:
172.31.35.8.
95
5-Implementation
2. Create the following:
96
5-Implementation
3. Name ETGPLANT1 as the first communication peripheral with the TSX ETG
302X module of the Plant 1:Drinking Water Station:
97
5-Implementation
4. Select the external I/O peripheral, click on Next and choose the OPC
method, OPC Factory Server, Schneider Electric:
98
5-Implementation
The link between the component names and the OFS alias is performed in the
Citect.ini file,via the [OPCAccessPaths] section:
This option removes the need to specify the alias name in the variables address
during its declaration in Vijeo Citect.
Note: The [OPC] section is added with UseOPC2=1, which prevents the OFS server
from working with OPC v2.
Creation of the 2 I/O Devices for Plant 2
This configuration is available only for Architecture 3.
In Architecture 3, Vijeo Citect must communicate with 2 components of Plant 2: the
Premium PAC and the TSX ETG 302X module (for the historical data management).
To do this, complete the following steps:
1. Access the Express Communication Wizard in the Project/ Communication
editor.
2. Select the I/O server previously created, i.e. SERVERIO.
3. Name ETGPLANT2 as the first communication peripheral with the TSX ETG
302X module of the Plant 2: Water Tower.
4. Select the external I/O peripheral, click on Next, and choose the OPC method,
OPC Factory Server, Schneider Electric.
5. Click on Next for each subsequent window, then click Finish.
Perform the same operations for the Premium PAC. Name it PLC2 in Vijeo Citect.
99
5-Implementation
For PLANT 1 equipment, linking to the previously-named components and the OFS
alias is performed in the Citect.ini file, via the [OPCAccessPaths] section. The
following screenshot shows the alias of PLANT 1 and 2:
This removes the requirement to specify the alias name in the variables address
during its declaration in Vijeo Citect. The [OPC] section is added with UseOPC2=1 to
allow the OFS server to work with OPC v2.
Declaration of the variables that communicate with the remote TSX ETG 302X modules
For Architecture 3, you must create 5 external variables mapped on each remote TSX
ETG 302X module Plant 1 and 2. You must respect the variables syntax, since these
are read and written directly by the TagName, via the Cicode functions TagRead and
TagWrite.
Create the following variables (X represents the site index):
backupX: incremented word when Vijeo Citect creates a backup .csv file in the
TSX ETG 302X module.
purgeX: incremented word when Vijeo Citect deletes a .csv backup file stored in
the TSX ETG 302X module.
stopbackupX: word written by Vijeo Citect to stop the TSX ETG 302X module
from doing a a backup while the .csv file is downloading via FTP.
100
5-Implementation
101
5-Implementation
102
5-Implementation
103
5-Implementation
Unlike Variable Tags, the Trend Tags name follows rules, in order to integrate the
TSX ETG 302X modules data logging files to the Vijeo Citect files.
Note: The TSX ETG 302X module logs the same variables as Vijeo Citect.
Consequently, you must respect the naming rule that allows Vijeo Citect to associate
the TSX ETG 302X modules historical files to its Trend Tags. The Trend Tag must
follow the format: device name_variable name. Thus for a variable named
PAC.m340.Lifting.FlowIn in the TSX ETG 302X module, the corresponding Trend
Tag must be named m340_LiftingFlowIn
Note: For a variable named PAC.m340.Lifting.FlowIn in the TSX ETG 302X module,
the corresponding Trend Tag must be named: m340_LiftingFlowIn. That is, we
delete the dot between the structures name Lifting and the variables name FlowIn
in Vijeo Citect.
=> M340_LiftingFlowIn: Trend Tag of the LiftingFlowIn Variable Tag, periodically
historized every 10 seconds.
104
5-Implementation
Premium PAC Plant 2
Repeat the steps described above, for the following tags:
=> Basin_AFlowIn
=> Basin_AFlowOut
=> Basin_ALevel
=> Premium_2_Basin_AFlow_IN
=> Premium_2_Basin_AFlow_OUT
=> Premium_2_Basin_ALevel
105
5-Implementation
Action
Via the RemoteAccess project editor, access the System->Included Projects menu:
Via the project editor access the RemoteAccess, Tools->Computer Setup Wizard menu
in Startup Functions Setup, click on Modify and type ETG_StartUp() as the start
function. This launches all others functions of the historical data management.
106
5-Implementation
107
5-Implementation
Because we have different periods, 2 tables are required. There are no rules for
naming the table. In our application, we choose Table0Etg1 and Table1Etg1. The
chosen storage media is a 256 Mo CF card.
108
5-Implementation
1. Services properties
The following screenshot shows the datalogging window:
Global Backup: select this checkbox to define a global backup for all tables
configured in this service.
Use of a trigger: select this checkbox to trigger the backup, rather than have a
periodic backup.
Specify in the variable field the calculated variable created in the calculation
service, here calculation.calculation.Backup. This variable is incremented
following the BackupPreset value, and is specified for the calculation service as
well. Specify NY to save any modification of the calculation.calculation.Backup
value.
The following list explains the requirements for the purge parameter:
Specify the variable for the ETG equipment: device.gtw.purge. This variable is
written and incremented by Vijeo Citect. Specify NY to define an historical files
purge on any modification of the device.gtw.purge value.
109
5-Implementation
2. Creation of the Table0Etg1
The following screenshot shows the final datalogging window required to create the
Table0Etg1 table:
110
5-Implementation
The following table lists the parameters and their descriptions:
Parameters
Description
Table parameters
Type the desired table name in the Table name box; here Table0Etg1.
Log parameters
Select the use of timer checkbox, then adjust its period; here, 10 seconds.
Select the Timestamp checkbox to make the saved variables timestamped.
You must select the Optimized Log Format to have the.csv files be readable
by Vijeo Citect.
We set the Maximum records to 500. This corresponds to the line number in
the .csv file. The higher this parameter, the longer the FTP download.
Log variables
The 3 PAC variables historized with a period of 10 seconds are added in this
field.
Backup
Parameters
Purge
Parameters
modules variable. This variable is used in the Vijeo Citect Cicode for the
historical data managements synchronization.
FTP settings
(This service is not used.) This service lets you send the files to a remote FTP
server. Our alternative solution is to use the FTP server of the TSX ETG 302X
module and, as a result, Vijeo Citect is the FTP client.
111
5-Implementation
3. Creation of the Table1Etg1
The following screenshot shows the final datalogging window required to create the
Table1Etg1 table:
112
5-Implementation
The following table lists the parameters and their descriptions:
Parameters
Description
Table parameters
Type the desired table name in the Table name box; here Table1Etg1.
Log parameters
Select the use of timer checkbox, then adjust its period; here, 1 minute.
Select the Timestamp checkbox to make the saved variables timestamped.
You must select the Optimized Log Format to have the.csv files be readable
by Vijeo Citect.
We set the Maximum records to 100. This corresponds to the line number in
the .csv file. The higher this parameter, the longer the FTP download.
Log variables
The 8 PAC variables historized with a period of 1 minute are added in this field
Backup
Parameters
Status variable remains blank. Vijeo Citect considers the Backup status of the
Table0Etg1 as a global status that can be used for historical data
management.
Maximum file number: is set to 10. The higher the maximum records
parameter, the longer the FTP download.
Purge Parameters
Status variable:this field remains blank. Vijeo Citect considers the purge
status of the Table1Etg1 as a global status that can be used for historical data
management.
FTP settings
(This service is not used.) This service lets you send the files to a remote FTP
server. Our alternative solution is to use the FTP server of the TSX ETG 302X
module and, as a consequence, Vijeo Citect is the FTP client.
113
5-Implementation
Cicode
This section describes the Cicode for historical data management.
The ETG_Include provides 2 Cicode files, as shown below:
1. ETG_Startup()
The ETG_Startup() function is a function of the ETG_BackFill Cicode file of the
ETG_Include project.
The following screenshot shows the ETG_Startup() function:
This function is called once, when Vijeo Citect starts up. It retrieves the number of
TSX ETG 302X modules to be monitored in the Citect.ini file (1 in Architecture 1 & 2,
and 2 in Architectures 3). The function initializes the startup values, and launches the
four other functions that run independently via the WhileTrue loops.
114
5-Implementation
2. ETG_Status()
This function manages the status of the communication with the iStatusETG[x]
variable. This variable is a global one, directly written in the function. Consequently, it
can be read by the other Cicode functions.
When communication is re-established, ETG_Status() manages:
3. ETG_PurgeTask()
If the communication with the TSX ETG 302X module is OK (value read on the
StatusETG[X] variable), then this function sends periodically sends a purge request
for the historian files included in the TSX ETG 302X module. The period can be set by
the user.
4. ETG_UpLoadTask()
This function permanently checks the content of the Vijeo Citect folder within the
ETG_Include project, which is: /ETG_Include/Trend/. If csv historian files are in
this folder, the function (with the help of others functions) can integrate the historian
data included in these csv files.
115
5-Implementation
The following drawing explains the structure of the Cicode functions call:
ETG_Status()
ETG_StartUp()
ETG_Status()
ETG
CONNECTED
?
NOT
ETG_PurgeTask()
YES
Status==Offline
ETG_ClockSynchro()
Status<>
Online
ETG_UploadTask()
YES
ETG_Backup()
While
True
FTP_GET_ALL_TREND_FILES()
FTP_GET_FILES()
FtpDownload()
NOT
ETG_CSV_Convert.exe
Status==Online
ETG_PurgeTask()
While
True
Status==
Online
YES
Send Purge to ETG
ETG_ClockSynchro()
ETG_Clock_Synchro.exe
While
True
Wait(???sec)
ETG_UploadTask()
ETG_CheckForUploadFiles()
ETG_IntegrateHistoFiles()
ETG_InsertTrendValue()
While
True
ETG_DeleteAllOldUploadFiles()
116
5-Implementation
Description
Retrieving of the remote TSX ETG 302X modules IP address or URL, via the Citect.ini file.
Test if the TSX ETG 302X module can be accessed through a ping command. If the ping is
ok, the processing continues, otherwise the .exe stops.
Connection to the TSX ETG 302X module via a Modbus TCP request.
117
5-Implementation
2. ETG_CSV_Convert.exe
This .exe creates new csv files from the TSX ETG 302X modules cvs files, which
have been previously downloaded via FTP by Cicode.
Newcsv files are created as follows:
In the TSX ETG 302X module of the Plant 1, 2 historian tables, Table0Etg1 and
Table1Etg1 will be created. Consider the Table0Etg1 as an example; this contains the
historic of 3 variables. The following screenshot shows the contents of a downloaded
Table0Etg1.csv file:
The .exe creates so many csv files as historical values in the Table0Etg1 file. In this
case, 3 csv files are created.
The following screenshot shows the Table0Etg1.1.csv.plc.m340.LiftingFlowIn.csv file
after the execution of the ETG_CSV_Convert.exe.
118
5-Implementation
The following table explains how the .exe file operates:
Stage
1
Description
Call of the BrowseCSVinDirectory() function. This function reads the contents of the
TrendFTP folder of the ETG_Include project, then retrieves the name of each file.
A For Each Files loop is executed in the BrowseCSVinDirectory(). This loop processes
the files one by one, calling the ConvertCSVFiles() function each time.
The ConvertCSVFiles() retrieves the names of the variables, the date/ time value and the
historized values, to create a csv file by variable. This new file is put in the Trend folder of
the ETG_Include project.
This function is completed when all the csv files have been processed.
119
5-Implementation
In the Service type menu, choose the email service and name this instance.
Note: The maximum number of email or SMS services is 2. The maximum number of
messages for 1 project is limited to 100.
120
5-Implementation
1. SMTP server
In this section, we specify the desired SMTP server used to send emails. Refer to the
ISP for the port SMTP number, and to determine if a secured authentication is
required to send an email. In our application, the senders email address is
plant1@orange.fr. Consequently, we use the oranges SMTP server, i.e.
smtp.orange.fr. This server does not require a secured authentication and uses the
SMPT port 25 by default.
2. Sender
Reply address: If the recipient wants to reply to the sent message, the recipients
message is sent to this address.
3. Module
In this section, we define the maximum size of the sent email/ SMS queued, as well
as the time elapsed before a retry of the send.
4. Service
The purpose of this feature is to provide status information on each service for
diagnostic/debug services. In our application, the Service status variable is left blank.
121
5-Implementation
Email Properties
In our application, we send a daily email to the lifting station managers email address.
This email includes:
The following screenshot illustrates the email services based on our previous choices:
We choose to add in the beginning of the message the Date/Hour of the email
sending, as well as the Wastewater tanks level and the flows in/out.
122
5-Implementation
SMS
We send an SMS by cellular to maintenance personnel when a pump becomes
inoperative.
The following paragraphs explain how to create the SMS. We implement one SMS
sending for the default management of the drinking water pump.
1. Default management of the drinking water tank pump
The following screenshot illustrates the sending of the Drinking water tanks SMS:
123
5-Implementation
124
6-Operation
6.Operation
6.1 Communication Establishment
Before beginning operation, you must connect to the Internet.
The following table shows you how to connect, based on operator workstation and
architecture:
Architecture
Workstation
1
Operator
Workstation 1
Operator
Workstation 2
Operator
Workstation 3
Note: For the TSX ETG 302X modules, there is nothing to operate. The Internet
connection is permanent and is done automatically.
NAT Routing
For the NAT routing, there is nothing additional to operate.
125
6-Operation
VPN Tunnel
The table below lists the method for VPN tunnel connection:
Step
Action
Execute a ping DOS command using the remote sites LAN to check the
VPN tunnel establishment. If it is not established, close the VPN tunnel
by launching the batch file ipsecstop.bat, and start again from the step 4.
126
6-Operation
Action
Type the following in Internet Explorer:
NAT : http://90.95.13.125
VPN: http://172.31.35.1
Click on Monitoring
127
6-Operation
Custom Pages
The custom pages access to Plant 1 is done from Operator Workstation 3, as shown
in the following table:
Step
1
Action
Type the following in Internet Explorer:
NAT: http://90.95.78.174
VPN: http://172.20.1.16
Click on Monitoring
Type USER/USER
128
6-Operation
129
6-Operation
130
6-Operation
2. Web Client
For the NAT solution, in the architectures 2 & 3, the Vijeo Citect Web Client access is
done from the Operator Workstation 2.
Refer to the following Vijeo Citect knowledgebase, webclient across LAN/WAN
documentation to get more information about how to implement a Web Client.
Do the following:
Action
Step
1
Type http://80.10.20.11/Citect
Type the connections login and password proper to the Vijeo Citect Web Server
(webclient/wenclient, in our case).
To reach the Web Server, we use a NAT router. Consequently, modify the deployment to type
the Clusters and their associated routing addresses, as follows:
131
6-Operation
5
Finally, click on the Start Control Client button to launch the Web Client with the R/W rights.
The following screenshot shows the Web Client available in the architecture 3 (PLANT 1 & 2)
with the NAT solution:
132
6-Operation
6.2.2. Programming
From Unity Pro, connect to the PAC. Once connected, you can perform operations as
usually. These operations included remote maintenance, online modifications,
applications or updates transfers.
Note: Due to the GPRS network, the connection time is more longer than with a local
connection.
VPN Tunnel
We use the Windows IPSec service as a VPN client to implement the tunnel between
the remote sites.
Note: We recommend not to use TheGreenBow VPN client, because it does not
allow to correctly manage active FTP service.
NAT routing
Here is the NAT routing table syntax: IPaddress:TCPPortNumber, which means: TSX
ETG 302X IP address: port (source port), and then the TSX ETG 302X module routes
to the PAC IP address: port (destination TCP port).
Note: For NAT routing, the installed Unity Pro version must be capable of managing
an address in the format: IPaddress:TCPPortNumber, i.e. Unity Pro 4.1 or later.
133
6-Operation
If a communication loss occurs, Vijeo Citect is no longer able to log data, as shown
on the following screenshot:
134
6-Operation
The data are retrieved as shown:
135
6-Operation
136
7-Appendix
7. Appendix
7.1 Custom Pages
We illustrate the Custom Pages by creating a lifting unit in the drinking water station.
We use the TSX ETG 302X modules (Plant 1) Custom Pages to show how to
implement a control interface, which can be used through a web navigator such as
Internet Explorer or Mozilla Firefox. The creation rules of these Custom Pages are
exactly the same as for an ordinary HTML- coded website.
Note: Access to the Custom Pages can be authenticated. We implement this solution
in this guide.
The Website described in this section is composed of an index.htm home page and
a lifting.htm page. A contextual menu enables navigation on the website. A title is
displayed on each page.
We divide the website creation into three parts, as follows:
1. Creation of the HTML- coded web pages
2. Creation o the objects library
3. Call of the graphic objects in the HTML-coded web pages
137
7-Appendix
1. Creation of the HTML-coded Web Pages
Complete the following steps:
1. Go to the \Website\secure\user folder and open the home page of
Custom Pages. You will need to use an HTML editor to make the
required modifications. We use Notepad++, which is provided with this
guide.
2. Modify the title of the HTML page, located between the <TITLE> and
</TITLE> tags.
3. Delete the text between the <BODY> and </BODY> tags.
4. In the user folder, create an images sub-folder. The .JPG images
stored in this folder are used as wallpaper for each of our Web pages.
We choose 5 images: home.JPG, Lifting.JPG, Screening.JPG,
GreaseSand.JPG and Clarifier.JPG.
5. Add the home.jpg wallpaper image, in the index.htm HTML page, by
configuring the <BODY> tag as follows:
<BODY style="BACKGROUND-REPEAT: no-repeat"
background="images/home.JPG">
6. Add the following page title: Home
7. Create a contextual menu allowing access to different website pages. We
create a page for the Lifting unit only, as a result the # value is
assigned to the href attribute of the others links.
The HTML code of the home page must be as shown below:
138
7-Appendix
139
7-Appendix
4. Through the TSX ETG 302X modules menu, select Monitoring, then
Custom Pages and With Pages.
5. Type the user name USER and the password USER to display the
homepage of our Custom Pages.. The following screenshot shows the result:
In order to improve the style of our Custom Pages, add the CCS language by
creating a sources folder. Then, create a .txt document called design.css. A CSS
style sheet provides you with a consistent website. Each of our webpages calls this
unique file. For more details, open the design.css file provided in this guide to
provide an overview of the CSS language.
Edit the index.htm homepages HTML code to assign the style sheet design.css.
Modify the <link> tags content, which already existis in the HTML code. Modify the
href attributes path, making it point to the design.css style sheet in the sources
folder. The result is shown below::
<LINK rel="stylesheet" type="text/css" href="../../lib/main.css" >
140
7-Appendix
Notes about the HTML:
The <link> tag indicates that the Web browser must access a document
located outside of the HTML page.
The type=text/css attribute specifies the style sheets type, .css in our
application.
The href=URL attribute gives the style sheets URL, i.e.its location on the
internet, sources\design.css in our application.
Our HTML page can now use the .css files style sheet. We use the <DIV> and
</DIV> tags, with the completed class attribute, to format our pages with the style
properties previously defined in the design.css file. The following extract of the
design.css file illustrates the customized style called h1, used to display the names
of the HTML pages:
141
7-Appendix
The following screenshot shows the result:
The pages name (Home) appears with the style defined in the design.css file.
Make similar modifications to customize the contextual menus display. The following
screenshot shows the final HTML code of the index.htm page:
142
7-Appendix
The following screenshot shows the final result:
Now make these modifications for the Lifting page. Copy the index.htm page then
rename it in lifting.htm. Edit the lifting.htm as follows:
1. Modify the pages title: <TITLE>Lifting</TITLE>
2. Modify the wallpaper: background=images/Lifting.JPG
3. Modify the pages name: <DIV> class=h1>Lifting</DIV>
4. Adapt the contextual menu as shown below:
143
7-Appendix
2. Animation of the Website
Before animating the website, you must create an object library from the Graphic
Editor service. These objects can then be instantiated in the HTML page. Proceed as
follows:
1. From Web Designer, click on the GraphicScreens service, then click on New
Graphic Page
4. Rename this standard object as Indicator 1. This name is used to call the
object from an HTML page.
5. Modify the properties you want to customize: the size, colors, fonts, etc.
144
7-Appendix
6. Assign attributes. This example illustrates the following parameters:
145
7-Appendix
The resulting customized library appears as follows:
This name is used to call the objects from the HTML page.
10. Transfer the library in the TSX ETG 302X module by a right click on the
previously-created library. Select Partial Transfer and PC->Target as shown
below:
146
7-Appendix
Our object library is now completed and transferred to the TSX ETG302X module.
The final phase shows you how to instantiate, and to organize these instances on the
lifting.htm HTML page.
3. Finalization of the Website
Use your HTML editor to open the lifting.htm HTML page. To use the previously
created graphical objects, a Java applet must be called in the HTML page before any
other objects call: LiveBeanMgrApplet.
Because we write to the PAC from the Custom Pages, we specify the MODE
parameter on READWRITE, we do not type a login before sending a command from
the Custom Pages, and therefore we specify AUTO_LOGIN on TRUE.
On each Java applets call, we add the tags <P> and </P>. These allow us to locate
the objects on the HTML page as LEFT and TOP attributes. We recommend that you
review the HTML page before finding the suitable values of these LEFT and TOP
attributes.
Then, we adapt the Height and Width objects attributes. We recommend you also
review the HTML page before determining the suitable values of these Height and
Width attributes.
Ttransfer from Web Designer to create the final HTML pages overview through the
TSX ETG 302X modules Web server.
4. Java applet parameters:
The first parameter concerns the librarys name. This library is the LibObj previously
created, which includes our objects. This parameter is the same for all graphical
objects located on the HTML page. The second parameter is the object name defined
in the graphical page, I.e Trend1 in our example.
147
7-Appendix
As with the Trend object, locate the object on the page, then adjust the size
parameters, and finally complete the parameterization.
Parameters:
The first LIBRARY parameter is identical to the associated parameter for Trend..
The second BEAN parameter concerns the objects name defined in the graphical
page, that is, Indicator1.
The third BACKGRND parameter corresponds to the objects color.
The fourth PROPERTIES parameter includes the values that customize the objects
instance. Unlike the Trend object, there are many instances of the Indicator 1 object
on the HTML page. We define the following parameters:
Address: the variables address in the TSX ETG 302X module, i.e. PAC
m340 LiftingFlowIn.
The principle is the same for all Java applets done on this page, and can be used
as a guide to edit the lifintg.htm file.
148
7-Appendix
Website transfer
The following screenshot shows an overview of the lifting.htm page after the transfer
into the TSX ETG 302X module:
149
7-Appendix
Note: You can create these graphic pages directly from the TSX ETG 302X modules
Website through a Web Browser.
Note: No technical information is given about Web Designer.
150
7-Appendix
Follow the method after:
Step
1
Action
In Web Designer, Navigator tabs, click on New Graphic Page:
Then Edit.
2
151
7-Appendix
3
Insert the required objects, from the standard and/ or extended toolbars:
Note: The instantiated objects can be animated by typing a value in the Value field.
Save your page.
4
Tick Transfer Only Modified Files to transfer images previously stored in the
Website/images folder:
152
7-Appendix
7.3. Technologies
This type of architecture, because of the variety of communication aspects (local to
local, local to remote) involves different communication technologies to allow flexibility.
In this appendix you can find short descriptions of the technologies used.
GPRS
The TSX ETG 302X module is connected to the Internet via the GPRS network.
GPRS provides a cost-effective solution for wireless remote connection to distributed
installations over the Internet. It is a packet-oriented data service based on GSM.
Using GPRS, the user pays only for the total volume of data exchanged, regardless of
the length of the connection time.
The following table presents the theoretical and typical data exchanges of the GPRS:
Theoretical
Typical
Upload
Download
80.6 kbit/s
171.2 kbit/s
20 kbit/s
80 kbit/s
Note: These values depend on your service provider, the distance between your
module and the base station, and the current traffic.
3G+
The Vijeo Citect client is linked to the Internet via a 3G+ (HSDPA) connection. The
3G+ is an enhanced mobile telephony communications protocol in the High Speed
Packet Access (HSPA) family. This technology supports a theoretical maximum
download speed of 7.2 Mbit/s. This speed also depends on your service provider, the
distance between your module and the base station, and the current traffic.
TCP/IP
To communicate on a local or remote network, the TCP/IP protocol uses ports
(numbers from 0 to 65535) and addresses. The IP address is used to uniquely
identify a component on the network (PAC, PC, etc.) whereas the port number
indicates the application or the service for which that data is intended. As a result,
when a component receives information for a specific port, the data is sent to the
corresponding application or service.
153
7-Appendix
A standard assignation of these ports is done by the IANA (Internet Assigned
Numbers Authority), to enable the networks configuration.
From 0 to 1023: Well Known Ports that are mainly reserved for system processing or
for programs executed by privileged users. Nevertheless, a network administrator can
link services to these ports. Here are some ports examples, commonly used:
21: FTP
23: Telnet
25: SMTP
80: HTTP
110: POP3
502: Modbus TCP
From 1024 to 49151: Registered Ports
From 49152 to 65535: Dynamic and/or Private Ports
Routing
To transport information using multiple medium combinations, local or internet,
routers are used. A router receives packets, and then dispatches them depending on
a routing table to the next router until reaching the targeted local network. Each
packet has its origin and destination address. There are several ways to route data on
networks. In our applications, we use two of them: VPN and NAT, which are
described in the following paragraphs.
VPN
The routing between remote equipment via the Internet is performed through a VPN
(Virtual Private Network) tunnel. This network is called Virtual because it links 2
physical networks (local networks) by an unreliable link (internet), and Private
because only the PCs included in the two local networks linked by VPN can see each
other. Finally, the word Tunnel symbolizes the fact that between the tunnels entry
and exit the data are encrypted, so normally anyone can access it, like in a tunnel.
The utilization of static URL (hostname) names simplifies the VPN tunnels
implementation.
DynDNS
We use a dynamic DNS network service (DynDNS) to get a hostname (URL) that
remains constant, instead of the dynamic public IP addresses of the installation (Vijeo
154
7-Appendix
Citect Server and Client, ETGs). This eases the creation and the handling of the VPN
tunnel.
Note: The DynDNS updater software will not automatically updatethe URL if the
device does not indicate a default DynDNS client.
NAT
Another way used to establish the connection between the site and the control
terminal is the Network Address Translation (NAT).
In the case of a data transmission from local (office) to remote (internet) equipment,
the origin (office) address is unknown on the internet side, and the recipient cannot
answer. So it becomes mandatory to replace the private origin address with a public
one, using a NAT (Network Address Translation) router.
Through a routing table, the NAT router replaces the equipments origin and port
private addresses with a public internet address, plus a chosen port number that
corresponds to the desired service, as previously explained in the TCP IP section.
The target equipment returns the address and the port in a form understandable by
the NAT router. The router then send the packets back to the local equipment. In this
case, the user does not have to configure anything. This is a typical function of
instantaneous messaging services. The software of the equipment situated on the
private network connects to the messaging server, which does the transformation of
the addresses and then contacts the remote equipment. In contrast, if remote
equipment calls from the internet to reach a private address, the router cannot know
which local equipment to forward to. To solve this, we use Port Forwarding.
Port Forwarding
This method allows connection through the Internet from remote to local equipment.
In the NAT router, the user creates a table containing ports and corresponding
private local addresses, as follows:
Port (to be defined in
the NAT router)
5000
5001
172.20.1.8:80 (HTTP)
Once this table is defined, the remote equipment can access local equipment by
typing the address and the port in a Web browser or a software package (here Unity)
according to targeted service desired.
155
7-Appendix
For instance, for HTTP service, type www.router.dyndns.com:5001 in your Web
server, and for Modbus TCP service, type www.router.dyndns.com.5000 in Unity Pro.
156
7-Appendix
157
Due to evolution of standards and equipment, characteristics indicated in texts and images
in this document are binding only after confirmation by our departments.
Print:
www.schneider-electric.com
Version
1.0 1 -12
Version
10 2009
2008
158