2. Selection - Schneider Electric

Transcription

System Technical Guide
How can I …
manage a remote process application?
1
2
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.
3
The STG Collection
System Technical Guides (STG) are designed to help project engineers and Alliance
System Integrators during the development of a project. The STGs support users
during the architecture selection and the project execution (design, configuration,
implementation and operation) phases with an introduction to the system operating
modes.
Each STG is a starter kit that provides users with:
•
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 kit’s 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.
4
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
4. Configuration ......................................................................53
4.1. Introduction................................................................................................................................................ 53
4.2. Communication .......................................................................................................................................... 54
5. Implementation ...................................................................85
5.1. Introduction................................................................................................................................................ 85
5.2. Communication .......................................................................................................................................... 86
6.Operation............................................................................125
6.1 Communication Establishment.................................................................................................................. 125
5
6.2 Remote Functionalities.............................................................................................................................. 127
7. Appendix ...........................................................................137
7.1 Custom Pages............................................................................................................................................ 137
7.2. Graphic Viewer ........................................................................................................................................ 150
7.3. Technologies ............................................................................................................................................ 153
6
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 truck’s automation
system can be controlled and monitored during its round trip.
•
In isolated applications, if wired solutions are not possible because of the
distance between the control room and the process units. Examples include an
extraction plant in the cement industry or a water pumping station.
•
For inter-communication between remote units. For example, in a water treatment
plant, a controller in the remote drinking water station exchanges data with
another controller in a different remote water tower, separately from the main
control room.
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.2. Customer Challenges
For customers in industries that require the types of applications mentioned above,
the challenge is to provide access to information and deliver the ability to control their
process while at the same time reducing installation costs and ongoing maintenance
costs.
The STG suggests best practices to address these challenges and highlights specific
areas including how to:
•
Implement transparency in data access
7
1-Introduction
•
Establish secured connection
•
Manage historical data
•
Optimize developments in the event of reuse
1.3. Prerequisites
We recommend the user have knowledge of the following software:
•
Unity Pro
•
Vijeo Citect
•
Web Designer for FactoryCast Web servers
1.4. Project Methodology
This STG explains the project methodology and includes the following phases:
Selection, Design, Configuration, Implementation and Operation.
The methodology is illustrated using 6 examples. Their features are described in the
Selection phase. Each architecture shows a specific feature necessary for remote
process applications.
Beginning with process analysis and user requirements, we identify and develop
common functionalities for all the architectures. These key functions are explained in
the Design, Configuration and Implementation phases.
Finally, the Operation phase shows the user how to use the final application.
Here are the phases described in this document:
•
1, Selection: In this phase we present the basic requirements for remote
processing. We then establish the selection criteria and describe the
architectures:
Basic requirements
•
Remote programming, diagnosis and maintenance
•
Continuity of service
Architecture Selection
•
Selection Criteria
o
Security policy
o
Budget
8
1-Introduction
o
Process topology
o
Operator profiles
o
Centralized or distributed control in terms of operating,
programming and monitoring.
•
•
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
•
Historical data management
•
Reporting
3, Configuration: Using the same key functions as introduced in the previous
phase, we show you the required configuration for each of the installation’s key
elements:
Operators Workstations
TSX ETG 302X modules
and how to perform that configuration.
•
4, Implementation: Using the same key functions as introduced previously and
the key elements defined in the configuration phase, we provide information
about final customization to address the project requirements.
•
5, Operation: Here we provide a methodology for operating the entire, final
installation, based on the selected remote functionalities.
9
1-Introduction
1.5. Presentation of the Project
The recommendations and guidelines provided in this STG are generic for remote
process applications, and can be adapted to other applications such as oil and gas,
water and so on. However, we use the specific example of a drinking water plant to
illustrate our methodology and application.
The goal is to simulate two remote sites of a water treatment plant: a drinking water
pumping station and a water tower used as a boosting station. These sites can be
remotely controlled by two workstations in separate control rooms, or by a mobile
operator from anywhere.
The following illustration represents the target application:
Control Rooms
Remote Site 2 :
Water Tower
Remote Site 1 :
Mobile Operator
Drinking Water Station
10
1-Introduction
An overview of the remote installation is shown below:
Control Rooms
Mobile Operator
Remote Site
Remote Site
1
2
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 architecture’s 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 plant’s constraints, as well as
the required level of functionality.
13
2-Selection
The following illustration summarizes our project’s approach:
14
2-Selection
2.1. Architecture Selection
This section shows you how to select the most appropriate architectures for a specific
project specification. To help you in this choice we first define functional and
operational constraints.
2.1.1. Functional and Operational Constraints
5 functional and operational constraints are defined, and used as selection criteria:
•
Operator profiles
•
Security policy,
•
Operating, monitoring and programming architecture
•
Process topology
•
Budget
The following paragraphs provide detail about each of these constraints.
Operator Profiles
In the event of a multiple-site plant, the managers must consider the teams who
control, operate and maintain the different units. Typical considerations include:
•
Where are the operation teams located? (mobile team, centralized team, etc.),
•
What are the skills of each team? (maintenance, programming, etc.),
•
How many are there, according to my plant?
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 application’s 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:
•
Centralized control room with one or several SCADA workstations. These
workstations are Vijeo Citect Client/ Server.
•
Distributed operating and monitoring systems with SCADA workstations located
in separate control rooms or close to the process. These workstations are Vijeo
Citect Client or Web Client.
•
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
2.1.2. Architecture Descriptions
This section presents and describes the 3 developed architectures, from the least
complex to the most complex. Each architecture is available with alternative solutions:
either technology NAT (Network Address Translation) or VPN (Virtual Private Tunnel),
and includes the same three key topology levels: control room, remote sites and
remote communication.
Architecture 1 with NAT Transparent Routing
The first architecture represents a control room (Operator Workstation 1) that
manages a unique remote site. A mobile operator (Operator Workstation 3) can
maintain or diagnose the remote site.
This architecture contains a unique TSX ETG 302X module on the remote plant ‘s
side. On the control room’s side, we use 3G+ USB modems establish the connection
with the Internet. The control room and the remote site communicate using NAT
routing configuration. The NAT routing table configured in the TSX ETG 302X module
allows transparent access to the M340.
This solution represents the more cost-effective of our offers described in this guide.
In addition, Operator Workstations can access to the remote sites with an appropriate
internet’s connection.
18
2-Selection
The following illustration shows architecture1, with NAT routing solution:
NAT Routing Table
19
2-Selection
Architecture 1 with VPN
This architecture is the same as presented above, except that a VPN tunnel performs
the authenticated and encrypted link between the control room and the remote site.
As a result, the exchanges between the Operator Workstations and the PAC are
authenticated and encrypted. This architecture introduces a key selection criterion:
secured transmission of the data. In addition, the VPN tunnel allows transparent
access to the remote LAN connected behind the ETG 302X module.
The following illustration shows the architecture with this VPN solution:
20
2-Selection
Architecture 2 NAT & VPN Solutions
This architecture is similar to the previous one, with an additional TSX ETG 302X
remote terminal unit located in the control room. In this case, the TSX ETG 302X
module acts as an interface between the SCADA system and the remote sites. All
communication is managed by the module, which controls operations and facilitates
handling. For example, an additional PC (Operator Workstation 2) can become a
Vijeo Citect Client or a Web Client in a transparent manner. This lets you thoroughly
duplicate your SCADA system in another control room. The mobile PC (Operator
Workstation 3) still maintains or diagnoses the remote site, either through a VPN
tunnel or a NAT routing. Here, the basic element is the multiple control, with the
possibility of adding SCADA systems.
The following illustration shows the second architecture, with NAT routing solution:
NAT Routing Table
NAT Routing Table
21
2-Selection
The following illustration shows the architecture 2, with VPN solution:
.
22
2-Selection
Architecture 3 NAT & VPN Solutions
This final case shows a typical architecture for secured inter-communication between
remote sites.
Here, 3 TSX ETG 302X modules are installed, one in a control room and the others in
separate remote sites. Note that the Operator Workstation 3 can maintain and
diagnose the remote sites in all cases (NAT or VPN).
Due to the integrated module’s VPN server, a large number of modules can be
managed. Thus scalable architectures can interface with various application
topologies. For more information, refer to the module’s technical documentation.
The following illustration shows the architecture 3, with NAT routing solution:
NAT Routing
Table
NAT Routing Table
NAT Routing Table
23
2-Selection
The following illustration shows the third architecture, with VPN solution:
24
2-Selection
2.2. Remote Functionalities
All previously described architectures comprise a GPRS communication with the
following functional levels:
Remote Functional Level
Remote Functionality
Control room
Operating, programming and monitoring
Mobiles operators using Web interface
Maintenance and diagnosis
(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 Internet’s 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.
2.2.1. Operating, Monitoring and Programming
In all the specified architectures, operating, programming and monitoring use Modbus
TCP protocol through a GPRS communication. Two interfaces are used: Vijeo Citect
(with OFS) as a SCADA system in the control room, and Factory Cast as a monitoring
system for mobile operators through a Web browser.
In addition, the remote monitoring of variables is used to check correct process
operation. In this context, the TSX ETG 302X module embeds a Web server that
allows monitoring of variables.
Finally, Unity Pro is used to program the remote PAC applications.
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 module’s 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.
2.2.4. Continuity of Service
Some automation processes must maintain their data integrity, especially in cases of
non-reliable remote connections. With mobile technologies such as 3G+ or GPRS,
the remote medium can experience significant fluctuations or disconnections. In such
cases, management of historical trends is required. In the case of communication loss
between the SCADA and remote sites, the module provides a datalogging service,
which consists of the automatic archiving of the application’s information such as
measures, events, etc. The log files are saved as CSV files into the flash module
memory. Coupled with Vijeo Citect SCADA, the system offers a real historian Trends
management solution with an automatic data backfill between the ETG remote
terminal unit and the SCADA.
Note: The application can also address communication disconnections, because of
the module’s ability to change between two modem communication links, a primary
and backup: ADSL as primary link and GPRS as backup link. In the event of a
communication loss by the primary modem link, the module automatically switches to
the backup until the primary is operational again. This guide does not illustrate this
functionality. For more details, refer to the technical documentation for the TSX ETG
302X module.
Note: Architectures 2 and 3 in a NAT configuration do not allow the historical data
management because of the module Operator Workstation 1 firewall restrictions
regarding the active FTP mode.
26
2-Selection
Note: As an alternative solution, it is possible to automatically archive the
application’s 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 offer’s 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
Operator’s
Security
Operating
Profile
Policy
and
(Skills,
(NAT / VPN)
Budget
Topology
Monitoring
(Multi site
(Additional
availability)
Process
connection)
SCADA)
Architecture1
X
X/ XXXX
X
_
XXXX
Architecture2
XX
X/ XXXX
XXXX
_
XXX
Architecture3
XXX
X/ XXXX
XXXX
XXXX
XX
XXXX: the more suitable
Legends
X: the less suitable
-: absent function
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:
•
Control room for operating, monitoring & programming
•
Remote sites for process control
•
Remote communication
This section explains the following key functions, classified in two main domains:
•
Communication
As previously mentioned, the architectures always comprise three levels: a control
room, communication through the Internet (WAN), and the plant. Typically, all
equipments included in the control room and the plant are connected using LAN, with
private IP addresses. This section shows you how to design a LAN to LAN
communication using WAN, with the following topics:
•
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
Local IP Address Management
The user has three operations to consider:
•
Local IP addresses management
•
IP address publication (for dynamic IP public addresses)
•
Transparency level of the internet connection
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.
2. The ISP (Internet Service Provider), to connect to the Internet.
3. The IP address publication, to define well-known addresses (URLs), for use with
dynamic public IP addresses.
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.
3.2.1. Local Network Parameters
If not previously defined by the project’s requirements, the customer must choose the
IP addresses for all equipment, in compliance with IP V4 format, and, following
ICANN rules.
Several ranges of private IP addresses are assigned to each remote site. Later
sections of this document will demonstrate that when using VPN, the range of the
remote site’s IP addresses must be part of separated sub-networks.
31
3-Design
The following table lists the local network parameters:
Equipment
IP address
Sub-mask
Gateway
Control Room Side
Control Room 1
TSX ETG 302X
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
TSX ETG 302X
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
3.2.2. Internet Access
To connect to the Internet, the user must subscribe to an ISP (Internet Service
Provider). These subscriptions are required for each connected node, i.e. each
workstation and TSX ETG302X module.
In our architectures, all contracts (for control room and plants side) are mobile
Internet types (GPRS/3G SIM cards).
Customer profiles and infrastructures
In GPRS (mobile phone technology), communications are done through the internet
via an APN (Access Point Name) from a GPRS Service Provider and so connections
are established differently as in GSM or PSTN. GPRS communications require a SIM
card and a specific contract from a GPRS Service Provider.
Depending on Customer profiles, communications may require various different
network infrastructures for performing wireless remote access and though will imply
adequate GPRS Service Provider contracts.
We can highlight the following different customer profiles:
•
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)
According to the above classification, Service Providers are offering dedicated
contracts well adapted to industrial applications with remote access:
•
Private contract: for big companies account including remote access within their
intranet.
•
Public contract : “Machine to Machine” (M2M) or “Telemetry” type public remote
access
Various different options are available for each contract:
•
Option for various Data exchange rates (billing on data amount in Megabytes per
month or unlimited amount per month)
•
Option for Static IP or Dynamic IP address
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
1
3
2
4
3
5
Use the following illustration to determine the number of required subscriptions:
5 subscriptions
34
3-Design
3.2.3. IP Address Publication
To implement remote access, each component connected to the Internet must know
the public IP address or the name of all components connected to the system. These
components are: the operator workstations and the TSX ETG 302X remote terminal
units.
Note: The public IP addresses are provided by the ISP (Internet Service Provider).
With a standard mobile internet subscription, the ISP renews the public IP addresses
periodically. These types of addresses are called dynamic public IP addresses. To
assign one of these as a static URL (Uniform Resource Locator), we recommend
using a dynamic Domain Name System. In our application, the free DynDNS Domain
Name System is used.
Note: Using DynDNS, the URL names are pre-formatted, for example:
xxxx.dyndns.info.
Note: Depending on the ISP contract, you can request static IP addresses instead of
dynamic IP addresses. In these cases, Dynamic Domain Name Systemis not required,
and the information which follows is therefore not relevant.
Note: The current OFS version does not manage the periodical renewal of the DNS
URL. Therefore, in this guide, we use static IP addresses in all of the NAT
architectures examples, listed in the following table:
Equipment
Public static IP address
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 account’s creation, select the Service/ Add Host Service menu:
36
3-Design
2
The following windows appears:
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
Click on Activate Services to finalize the URL creation.
The plant1.dyndns.info URL is created.
5
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
TSX ETG 302X Module
opws1.dyndns.info
1
plant1.dyndns.info
opws3.dyndns.info
opws1.dyndns.info
2
opws2.dyndns.info
plant1.dyndns.info
opws3.dyndns.info
3
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
1
X
_
X
2
_
X
X
3
_
X
X
Architecture
38
3-Design
3.2.4. Network Interconnection
Two types of services can be used to interconnect the remote sites (remote LANs):
•
VPN tunnels (Virtual Private Network)
•
NAT transparent routing (Network Address Translation)
Remote Access using VPN tunnel
We use the Windows IPSec service as a VPN client to implement the tunnel between
the remote sites.
We recommend that you check the presence of the ipseccmd.exe file on the PC. If
this file is not present, you need to install the Win XP additional tools (Support Tools),
either from the file provided in this guide or from the Windows XP installation disk in
the folder: Support\ Tools: WindowsXP-KB838079-SupportTools-ENU.exe. In
Windows services, set the position of the ‘IPSEC Service’ to Automatic.
Note: We recommend not to use TheGreenBow VPN client, because it does not
allow to correctly manage active FTP service.
39
3-Design
Remote Access using NAT Routing
For NAT communication, you must clearly identify all the communication paths
needed by your application. A TCP port has to be assigned to each of the device and
service to access. The TSX ETG 302X module will translate the incoming address to
the destination address thanks to the routing tables
The following list gives the TCP ports used in the NAT architectures, and assigned to
each equipment or services:
•
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 module’s
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 module’s 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
Now that you have established communication between LAN equipments via the
WAN, you can establish remote functionalities, as follows:
•
Operating & Monitoring the application
•
Programming, either for the PAC or the TSX ETG 302X module
•
•
Reporting
•
Alarming
This section shows you how to implement each of these aspects.
3.3.1. Operating & Monitoring
To operate and monitor the application, Vijeo Citect is required.
In our architecture, the communication interface between Vijeo Citect and the M340
PAC is OFS. Install OFS on the SCADA from the Vijeo Citect installation CD-ROM.
On the PC dedicated to maintenance or monitoring, you can directly access the
monitoring services of the TSX ETG 302X module using its web page, via a Web
browser.
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 module’s services,
such as datalogging, calculation, Email/SMS, Graphic Editor, and Website.
3.3.3. Historical Data Management
In the event of a communication loss between the SCADA system and the remote
terminal unit TSX ETG 302X module, historical data management must be performed
to provide continuity for historical data logging.
The historical data management is performed by the Vijeo Citect SCADA system
(trends) while the remote terminal unit TSX ETG 302X module performs data logging.
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
Data Logging Period
Flow in
10 s.
Flow out
10 s.
Level: drinking water tank 2
10 s.
Current: motor starter 1 tank 1
1 min.
Current: motor starter 2 tank 1
1 min.
Current: drive 1 tank 2
1 min.
1 min.
1 min.
Speed: drive 1 tank 2
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
1
The historical data management requires clock synchronization between the SCADA system and all
remote terminal units. Vijeo Citect regularly synchronizes the TSX ETG 302X module’s clock on its
own, and also checks the communication between the other components.
2
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.
4
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.
6
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
Windows Regional and Language Options
To make the historical management function run properly, the decimal symbol used
for the real value must be the same for the TSX ETG 302X module and the Vijeo
Citect server. In the module, the decimal symbol is represented by a dot.
To change this symbol on the workstation, proceed as follows:
Step
Action
1
From the Windows Control Panel, select Regional and Language Options.
2
From the Regional Options tab, click on the Customize button.
3
In the Numbers tab, replace the symbol by a dot, if necessary.
48
3-Design
ETG_Include project restoration
Because Vijeo Citect is primarily responsible for historical management functionality,
the user must restore the ETG_Include project in Vijeo Citect. This project provides
Cicode files, 2 work folders and 2 .exe files dedicated to the historical data’s recovery.
Note: You must include this project in your Vijeo Citect project (See in the
Implementation chapter, the ETG_Inlcude project including section).
To restore the ETG_Include project, follow the instructions below:
Step
1
Action
From Vijeo Citect explorer, right click on My Project, then select Restore.
Select Restore.
2
The Restore Project window appears:
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
The result of the restoration is shown below:
There are 3 sub-folders, directly linked to the All sub-directories checkbox.
These are described below:
ETGTools: this folder includes 2 .exe files:
ETG_Clock_Synchro.exe
ETG_CSV_Convert.exe
Trend: work folder that integrates the Trend converted files.
TrendFTP: target folder where the historical files are copied by FTP from
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 file’s 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 file’s content into the Citect.ini file.
The following screenshot shows the SectionCitect.ini file’s content:
The resulting Citect.ini file includes 2 parameterization areas that manage the
historical data’s 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 site’s
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).
3.3.4. Reporting & Alarming
For reporting features, the TSX ETG 302X module can automatically and dynamically
send email or SMS to inform the user. Report files can be included in email, and used
to help remote maintenance for example. This service is configured from Web
Designer. (please refer to the Configuration Chapter, Section Reporting & Alarming
for more information about this configuration).
Concerning the Email, it is typically sent to the workstation manager. We illustrate the
sending of email by the lifting unit of the drinking water station’s monitoring system. In
the Design phase, we choose the measures and information included in the email:
•
Flow in/ out of the lifting unit
•
Analog level in the tank
•
Date/ Hour the email is sent
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 operator’s cellular, when a pump
becomes inoperative.
To illustrate SMS message sending we choose, in the Design phase, the monitored
actuators, which are:
•
The 2 pumps of drinking water tank 1, LF1_PMP_P1 and _P2
•
The 3 pumps of drinking water tank 2, LF1_PMP_P3, _P4 and _P5
.
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
architecture’s equipment: operator workstation, TSX ETG 302X module, PAC, and
field devices.
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:
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.
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
TSX ETG 302X Modules
The Ethernet parameters are configured using the setup page of the module’s web
server, as shown in the following illustration.
Once the configuration is complete, we retrieve it in Web Designer by an ETG to PC
transfer (for more information, refer to the Implementation chapter).
Note: We choose to configure the Ethernet parameters from the module’s web server,
but this configuration can be done in Web Designer as well.
1. Definition of the module’s IP address in the local LAN
To access the TSX ETG 302X module website for the first time, you must use its
factory default IP address.
The TSX ETG 302X module’s factory default IP address is defined from the Mac
address written on the equipment’s housing. It is in the syntax 10.10.xxx.yyy where
xxx and yyy are the two last numbers of the Mac address in hexadecimal, converted
to decimal.
For example, if the TSX ETG 302X module’s Mac address is 00 80 F4 03 7E 90 in
hexadecimal, the default IP address is 10.10.126.144.
Note: When connecting to the TSX ETG 302X module for the first time, you must
adapt the IP address of the PC used for the module’s 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
•
Subnet mask: 255.255.0.0
•
Gateway: blank
1.3. TSX ETG 302X module operator workstation 1
This TSX ETG 302X module does not appear in Architecture 1. The configuration is
the same as described for the TSX ETG 302X module Plant 1, with the following
parameters:
•
IP address: 192.168.10.50
•
Subnet mask: 255.255.255.0
•
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 unit’s 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 gateway’s 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
This section shows you how to configure the internet part for each key component:
operator workstation, TSX ETG 302X module, and PAC. The configuration differs
based on the Internet Service Provider (ISP) used for internet access.
Note: There is nothing to configure in the PAC for the internet Access.
In the case of Architecture 1, the internet connection is done directly from the
workstation with a 3G+ USB key. Therefore, in our case, you must first launch the ISP
software. In our application, we use Business Everywhere.
Launch the Business Everywhere software, then configure the connection by typing
the parameters provided by the ISP:
Once the parameters are set, click on the OK button to complete the internet
configuration.
Configure the modem, with the connection parameters provided by the ISP.
Configure the modem, with the connection parameters provided by the ISP.
59
4-Configuration
TSX ETG 302X Module Plant 1
As with the Ethernet parameters, configure the GPRS setup parameters from the
module’s web server page, as follows:
1. From the Web server via the Setup menu-> Modem->Configuration, select
the GPRS Enable option
2. Type the connection parameters (Username and Password) provided by the
ISP, as shown:
3. Apply the modifications, then reboot the TSX ETG 302X module by selecting
Control menu -> Reboot.
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 module’s web server,
but this configuration can be done in Web Designer as well.
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
This section shows you how to configure the IP address publication for each key
component: operator workstation and the TSX ETG 302X module.
Note: In the NAT architectures, due to the static public IP addresses, the following
section is not applicable.
Operator Workstation 1, 2 and 3
Typically, the software used to establish connection to the internet does not have a
DynDNS client, which would allow automatic update of the URL according to the
dynamic public IP address. For this reason, we use the DynDNS updater software.
For architectures using VPN, and in the case of dynamic public IP addresses, follow
the steps in the table below:
Step
Action
1
Connect to the internet.
2
Launch the DynDNS updater application.
3
Click on Change User to type the Username and the Password of
the created DynDNS account::
4
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.
5
Click on Start Updater to run the task that manages the periodic
update of the dynamic public IP address.
61
4-Configuration
Unlike the operator workstation, the TSX ETG 302X module integrates a DynDNS
client, which allows the automatic update of the URL with the dynamic public IP
address. The user must configure the module’s modem, as follows:
1. From the Web server via the Setup menu -> Modem Configuration, type the
DynDNS name plant1.dyndns.info (previously defined on Dyndns.com), the
account username, and password..
2. Apply the modifications, then restart the TSX ETG 302X module by selecting
Control menu -> Reboot.
Proceed as described above, with the following parameters:
TSX ETG 302X Module Operator Workstation 1
Proceed as described above, with the following parameters:
62
4-Configuration
Two technologies are used for interconnecting remote LANs, NAT routing and VPN
tunnels. The first section of this chapter applies for architectures using NAT
technology, and the second section for architectures using the VPN.
NAT Routing
To help you understand the configurations, the following illustration reminds you the
architecture that offers most features with the NAT technology, that is, the 3:
TSX ETG 3021
NAT Router
80 = 192.168.10.10 :80
2075 = 192.168.10.10 :2075
2076 = 192.168.10.10 :2076
2077 = 192.168.10.10 :2077
2078 = 192.168.10.10 :2078
2080 = 192.168.10.10 :2080
2082 = 192.168.10.10 :2082
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:
•
->IPSecTunnel.bat, which allows to open a VPN tunnel.
•
->IPSecStop.bat, which allows to close a VPN tunnel.
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
Here are the modifications that must be applied:
•
172.20.*.* (or 172.20.0.0/ 255.255.0.0): the remote network address used to
connect the VPN
•
plant1.dyndns.info: DynDNS URL of the TSX ETG 302X module
•
useruser: connection key shared between equipment for authentication
•
opws1.dyndns.info: DynDNS URL of the Operator Workstation 1
1.2. Operator Workstation 2
This configuration is used in Architectures 2 and 3.
•
192.168.10.*.* (or 192.168.10.0/ 255.255.255.0): the remote network address
for VPN connection
•
opws1.dyndns.info: DynDNS URL for the TSX ETG 302X module.
•
useruser: connection key shared between equipments for authentication.
67
4-Configuration
•
opws2.dydns.info: DynDNS URL of the Operator Workstation 2.
1.3. Operator Workstation 3
This configuration is used in Architectures 1,2 and 3.
•
172.20.*.* (or 172.20.0.0/ 255.255.0.0): the remote network address for VPN
connection
•
plant1.dyndns.info: DynDNS URL for the TSX ETG 302X module
•
useruser: connection key shared between equipments for authentication.
•
opws3.dydns.info: DynDNS URL of the Operator Workstation 3.
2. VPN Configuration for TSX ETG 302X Module
This section explains the required configuration for establishing the VPN tunnel for
each TSX ETG 302X module, based on the appropriate architecture.
For more details about the TSX ETG 302X module’s VPN service, refer to the
technical documentation.
All configurations are done as follows:
From the web server of the specific TSX ETG 302X module, from the Setup->
Modem PPP security menu, select the VPN Enable checkbox, then fill in the fields
as explained in the following paragraphs.
After each configuration, apply the modifications, then reboot the TSX ETG 302X
module.
Note: Some tunnel configurations are described in detail to highlight specific
information.
68
4-Configuration
2.1 Architecture 1 VPN
The following illustration reminds you the Architecture 1 VPN:
69
4-Configuration
•
TSX ETG 302X module Plant 1
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
71
4-Configuration
•
TSX ETG 302X module Operator Workstation 1
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.
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
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.
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
74
4-Configuration
•
TSX ETG 302X module Operator Workstation 1
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
and the Operator Workstation 2 (VPN client) and the TSX ETG 302X module
Operator Workstation 1 (VPN server), as shown:
•
configured for connection with 2 VPN clients and 1 VPN server.
the TSX ETG 302X module Operator Workstation 1 (VPN client) and the TSX ETG
302X module Plant 1 (VPN server),
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
•
configured to enable the connection with 2 VPN clients.
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
OFS
To enable communication with the remote equipments, Vijeo Citect uses OFS (OPC
Factory Server) software based on the OPC data access specifications. As described
in the historical management section, for each remote site, Vijeo Citect must
communicate with the PAC and with the TSX ETG 302X module to purge the data
logging files, send historical backup requests, etc.
The following screenshot shows the final OFS 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 parameter’s 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
variable’s 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.
•
Device timeout: 20000 ms, for the delay graph transitions.
•
Frame timeout: 6666 ms, for the permissible delay between request and answer.
Note: These 3 parameters must be adapted for your own project.
The following screenshot shows the M340 PAC configuration:
4.2 Symbol Table File
To enable Vijeo Citect to operate remotely on the M340 PAC, we specify in the menu
Equipment Presentation->General->Symbol Table File of the OFS_M340, the
following path:.xvm M340 PAC file.
Note: We prefer to use the .xvm file because it contains all of the required variables
for our application. This file allows faster loading of the Vijeo Citect application than
can be expected when using an .stu file.
79
4-Configuration
4.3 Device Addressing
•
NAT
Note: For NAT management, OFS requires the OFSV3.33_2513 patch.
For OFS, in NAT, the PAC address is the static public IP address, plus the
corresponding TCP port, as shown below:
OFS_M340: 90.95.78.174 and port number 5000
OFS_ETG1: 90.95.78.174 and Modbus Index 255.
Proceed in the same manner with:
OFS_PREMIUM: 90.95.13.125 and port number 6200
OFS_ETG2: 90.95.13.125 and Modbus Index 255
80
4-Configuration
•
VPN
The OFS configuration with VPN technology is the same as with local technology:
OFS_M340: 172.20.1.4
OFS_PREMIUM: 172.31.35.8
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.
4.3.3. Historical Management
Citect .ini
Historical data backfill is managed by a Cicode program (ETG_Include project). This
program has several parameters to be initialized via a .ini file.
To implement the historical management functionality, you must configure the
[ETGBackFill], [ETG1BackFill] and [ETG2BackFill] sections (ETG2BackFill section is
concerned for the Architecture 3 only), which are located in the Citect.ini file.
1. [ETGBackFill] section
Open the Citect.ini file and go to the [ETGBackFill] general section. This section is a
common section for each remote site with historical management.
The following list provides a description of each parameter:
•
BackupTimeOut: the number of seconds allowed before determining that the
backup command has failed.
•
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.
•
IniPath: the folder where the Citect.ini file is located.
•
NbOfETG: corresponds to the number of remote ETG to be retrieved. For
Architectures 1 and 2, this parameter is set to 1.
•
PurgeRepeatTime: the repetition period of the purge command, in seconds.
•
PurgeTimeOut: the number of seconds allowed before determining that the purge
command has failed.
•
SynchroRepeatTime: the repetition period for synchronization of the TSX ETG
302X module’s clock with that of the workstation running Vijeo Citect, in seconds.
•
TrendFTP: the target folder of the historical files, downloaded via FTP to the TSX
ETG 302X module.
•
TrendUpload: the target folder of the historical files converted by
‘ETG_CSV_Convert.exe
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:
The following list describes each parameter:
•
FTPPath: the storage media for the CSV files in the TSX ETG 302X module.
•
FTPTimeOutAttempt: the number of FTP connection attempts before determining
that the connection has failed.
82
4-Configuration
•
IPAddress: For VPN architecture, the remote TSX ETG 302X module’s private IP
address; for NAT architecture, the remote TSX ETG 302X module’s 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.
•
•
TrendTable02: the name of the CSV file/ table created by the TSX ETG 302X
for TrendTable01.
module.
•
•
UserName: user name for the FTP connection.
•
UserPassword: user password for the FTP connection.
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.
See in the Implementation Chapter, section Reporting & Alarming.
83
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..
Run ISP software for each operator workstation. In the application shown, Business
Everywhere is used:
The IP Address Publication configuration explained in the Configuration chapter,
Communication-> IP Address Publication section is sufficient to implement this
functionality.
The Network Interconnection configuration explained in the Configuration chapter,
Communication-> Network Interconnection section is sufficient to implement this
functionality.
86
5-Implementation
5.3.1. Operating and Monitoring
To operate and monitor the applications, Vijeo Citect, custom pages and graphic
viewer are used.
Note: This guide does not provide technical information about how to create a
SCADA system with Vijeo Citect.
The following sections explain the retrieving of the TSX ETG 302X Module
Configuration and the variables declaration. The custom pages and graphic viewer
implementations are described in annex.
Retrieving the TSX ETG 302X Module Configuration with Web Designer
The configuration upload allows you to:
•
Upgrade the application’s configuration
•
Activate ETG services, such as datalogging, calculation and so on.
•
Save the project
To illustrate, let us consider the TSX ETG 302X module of Plant 1.
Note: Plant 2 is not detailed in this section, as the principles described are the same
as for Plant 1.
87
5-Implementation
Follow the instructions shown below:
Ste
Action
p
1
Launch Web Designer and create a new project called WaterProject.
2
The following Project Creation Wizard appears:
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
Go to the second page of the project creation wizard:
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 project’s 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
The upload processing runs.
7
Once the upload process is complete, check from Web Designer, by a right click
on the target and selecting Properties, that the previously project’s 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 module’s 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.
•
statusBackup: status word of the ‘backup’ command.
•
statusPurge: status word of the ‘purge’ command..
•
StopBackup: word written by Vijeo Citect to stop the TSX ETG 302X module for
backup, during the .csv file’s downloading via FTP.
We create also 6 read-only variables, linked to the date/time system registers
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.).
•
The INT type variables that manage the SMS/email content.
•
The BOOL type variables used for SMS/email sending.
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:
Then click on Import Selected Variables button to complete the import.
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 module’s 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
1
Launch Unity Pro
2
Select the PLC/Set Address menu. The following window appears:
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.
5.3.3. Historical Data Management
New Vijeo Citect Project
In order to implement the historical data management, you must create a new Vijeo
Citect project. From the Vijeo Citect explorer, click on File->New Project.
To do this, complete the following steps:
1. Name the project ‘RemoteAccess’, as shown below:
95
5-Implementation
2. Create the following:
•
A cluster from the Project/Server editor:
•
A network address, by specifying the operator workstation’s IP
address in the Address box:
•
An alarm server linked to the cluster previously created:
•
A trend server linked to the cluster:
96
5-Implementation
•
An I/O server linked to the cluster:
Creation of the 2 I/O Devices for Plant 1
Vijeo Citect must communicate with the following two components included in Plant 1:
the PAC M340 and the TSX ETG 302X module (for the historical data management).
1. Access the Express Communications Wizard, from the Project editor ->
communication.
2. Select the I/O server previously created, i.e. SERVERIO:
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:
5. Click on Next for each subsequent window, then click Finish.
6. Perform the same operation for communication with the M340 PAC. Name It
‘PLC1’ in Vijeo Citect:
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 variable’s 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).
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 variable’s 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 variable’s 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.
•
backup_statusX: status word of the ‘backup’ request.
•
purgeX: incremented word when Vijeo Citect deletes a .csv backup file stored in
•
purge_statusX: status word on the ‘purge’ request.
•
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
•
backup1: integer, address %MW0 pointing to the ‘ETGPLANT1’ device:
•
backup_status1: integer, address %MW3 pointing to the ‘ETGPLANT1’ device:
•
purge1: integer, address %MW1 pointing to the ‘ETGPLANT1’ device:
101
5-Implementation
•
purge_status1: integer, address pointing to the ‘ETGPLANT1’ device:
•
stop_backup1: integer, address %MW6 pointing to the ‘ETGPLANT1’ device:
•
backup2: integer, address %MW0 pointing to the ‘ETGPLANT2’ device.
•
Backup_status2: integer, address %MW3 pointing to the ‘ETGPLANT2’ device.
•
Purge2: integer, address %MW1 pointing to the ‘ETGPLANT2’ device.
•
Purge_status2: integer, address %MW0 pointing to the ‘ETGPLANT2’ device.
•
Stop_backup2: integer, address %MW0 pointing to the ‘ETGPLANT2’ device.
102
5-Implementation
M340 PAC Plant 1
Declare the Variables Tags that communicate with the remote PAC and TSX ETG
302X module. Once these variables are declared, define the Trend Tags.
•
Variable Tags declaration:
There are no restrictions for the ‘Variable Tags’ declaration.
=> LiftingFlowIn: non-located variable pointing to the ‘PAC1’ device. Fill in the Raw
Full and Eng Full Scale values, as these are used for the Trends representation in
Run-Time.
=> LiftingFlowOut: non-located variable pointing to the ‘PAC1’ device.
=> LiftingLevelMeter: non-located variable pointing to the ‘PAC1’ device.
103
5-Implementation
•
Trend Tags declaration:
Unlike Variable Tags, the Trend Tags name follows rules, in order to integrate the
TSX ETG 302X module’s 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 module’s 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 structure’s name ‘Lifting” and the variable’s name ‘FlowIn”
in Vijeo Citect.
=> M340_LiftingFlowIn: Trend Tag of the ‘LiftingFlowIn’ Variable Tag, periodically
historized every 10 seconds.
=> M340_LiftingFlowOut: Trend Tag of the ‘ LiftingFlow Out’ Variable Tag,
periodically historized every 10 seconds.
=> M340_LiftingLevelMeter: Trend Tag of the ‘LiftingLevelMeter’ Variable Tag,
=> M340_Lf1PmpP1_Current: Trend Tag of the ‘Lf1PmpP1_Current’ Variable Tag,
104
5-Implementation
Premium PAC Plant 2
Repeat the steps described above, for the following tags:
•
Variable Tags declaration
=> Basin_AFlowIn
=> Basin_AFlowOut
=> Basin_ALevel
•
Trend Tags declaration
=> Premium_2_Basin_AFlow_IN
=> Premium_2_Basin_AFlow_OUT
=> Premium_2_Basin_ALevel
105
5-Implementation
Including the ETG_include Project into Vijeo Citect
To work with the ETG_Include project (see in the Design chapter, the ETG_include
section for description), include it in your Vijeo Citect RemoteAccess project.
Proceed as follows:
Step
1
Action
Via the RemoteAccess project editor, access the System->Included Projects menu:
Type the project name ‘ETG_Include’ then click on Add.
2
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
Calculation Service in Web Designer
The calculation lets you perform operations with variables and combine variables.
These formulas are executed periodically, according to the frequency configured in
the ‘Properties’ screen. The formulae in the cells are interpreted, then executed oneby-one from the top to the bottom. We recommend adjusting the service’s execution
period to1000 ms.
In our application, we use this service to manage periodic backups of the datalogging
service, and to stop backups when Vijeo Citect downloads the .csv files.l.
The following screenshot shows the table with the variables and their content.:
Definitions of these variables are shown below:
•
BackupPreset: repetition period of the backup commands.
•
BackupClock: incremented variable for each calculation service’s execution. The
period of the service’s execution is 1000 ms, so the BackupClock variable is
incremented every second. If the BackupTime variable time is longer than the
device.gtw.BackupPreset variable, the BackupClock variable is incremented,
otherwise it is maintained. Here are the variable’s formula and algorithm:
calculation.calculation.BackupTime≥calculation.calculation.BackupPreset ?
calculation.calculation.BackupClock+1: calculation.calculation.BackupClock.
which means:
If the variable calculation.calculation.BackupTime equals or is longer than
calculation.calculation.BackupPreset, then calculation.calculation.BackupClock is
incremented, otherwise it is maintained.
•
BackupTime: incremented variable for each calculation service’s execution. The
period of the service’s execution is 1000 ms, so the BackupTime variable is
incremented every second. Here are the variable’s formula and algorithm:
calculation.calculation.BackupTime ≥ calculation.calculation.BackupPreset ?1 :
calculation.calculation.BackupTime +1
If this variable time is longer than the BackupPreset variable, then BackupTime is
reset to 1, otherwise it is incremented.
107
5-Implementation
•
Backup: mapped variable used as a backup trigger of the datalogging service to
create the .csv files. Here are the variable’s formula and algorithm:
Device.gtw.StopBackup==1? calculation.calculation.Backup:
device.gtw.backup+calculation.calculation.BackupClock.
If StopBackup is true then the backup trigger is no longer incremented..
Else the backup trigger is the sum of the device.gtw.backup variable managed by
Vijeo Citect, plus the BackupClock variable, periodically incremented.
This formula is used to stop the backup during the Vijeo Citect FTP download
steps.
Datalogging Service in Web Designer
The datalogging service (data historization) lets you save the information from the
TSX ETG 302X module to a CF card, a Flash memory, the module’s RAM, or a USB
key. For more information, refer to ‘FactoryCast HMI Gateway TSX ETG 302X
module’ technical documentation.
The information that follows shows you how to quickly implement a data historization.
The datalogging CSV files can be accessed from any FTP client tool, using the path
corresponding to the storage media:
•
\NAND\FLASH1\USERDATA for the flash memory,
•
\RAMDISK\USERDATA for the internal RAM
•
\CFA00\USERDATA for the CF Card
•
\USBHD\00\USERDATA for the USB key.
We historize the following variables in the Plant 1:
•
3 variables every 10 seconds
•
8 variables every 60 seconds
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:
The following list explains the requirements for backup parameters:
•
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.
•
Media target: here, we use a 256 Mo Flash compact card.
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 file’s
purge on any modification of the ‘device.gtw.purge’ value.
There are no requirements to implement for the Service status variable.
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
Select the CFCard as the storage media.
Status variable: we specify the ‘device.gtw.statusBackup’ TSX ETG 302X
module’s variable. This variable is used in the Vijeo Citect Cicode for the
historical data management’s synchronization.
Maximum file number is set to 10. For the higher, the maximum records
parameter, the longer the FTP download..
Purge
Status variable: We specify the device.gtw.statusPurge’ TSX ETG 302X
Parameters
module’s variable. This variable is used in the Vijeo Citect Cicode for the
historical data management’s 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
Select the CFCard as the storage media.
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 ‘While…True’ 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:
•
A backup request for the historical data closing.
•
The downloading of the .csv files via FTP
•
The launching of the ETG_CSV_Convert.exe.
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 function’s 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
The .exe Files
This section gives information about the .exe files located in the ETG tools folder.
Note: These files have been previously restored with the EG_Include project.
1. ETG_Clock_Synchro.exe
This file manages the time’s synchronization of the remote TSX ETG 302X module,
by sending the time of the workstation that executes Vijeo Citect. via a write request
of 4 consecutives registers on Modbus TCP.
The following table explains this synchronization:
Stage
Description
1
Retrieving of the remote TSX ETG 302X module’s IP address or URL, via the Citect.ini file.
2
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.
3
Connection to the TSX ETG 302X module via a Modbus TCP request.
4
Launching of the SendTimeToETG() function:
-> retrieving of the number of the TSX ETG 302X module’s first register where the time is
written. This number is retrieved in the Citect.ini file.
-> retrieving of the time on the specified workstation.
-> Modbus TCP request established.
-> Sending of the time from the TSX ETG 302X module.
5
Launching of the ReadTimeFromETG() function:
-> retrieving of the data from the remote TSX ETG 302X module.
-> integration of the received data.
-> display of the time, read on the remote TSX ETG 302X module.
-> end of the ro utine.
117
5-Implementation
2. ETG_CSV_Convert.exe
This .exe creates new csv files from the TSX ETG 302X module’s 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.
2
A ‘For Each Files’ loop is executed in the ‘BrowseCSVinDirectory()’. This loop processes
the files one by one, calling the ‘ConvertCSVFiles()’ function each time.
3
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.
4
This function is completed when all the csv files have been processed.
119
5-Implementation
E-mail and SMS Services
The TSX ETG 302X module can automatically and dynamically send emails or SMS
to inform the user. A unique service manages the SMS and email sending. This
service is configured from Web Designer.
The email includes recipient’s name and email address, the message’s body and
object, and any attached files. When the message is sent, the real-time values of the
application can be dynamically included; when the TSX ETG 302X module receives
the request, it instantaneously retrieves the values.
The SMS are directly sent by cellular. The message body can display the real-time
values previously included. For more information about this service, refer to the
technical documentation of the TSX ETG 302X module.
Activation of the email/ SMS Service in the Water project of the Module
Right click on Services, then select New Services:
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
Properties of email/ SMS Services
This section explains the 4 aspects of the service, as shown below:
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 sender’s email address is
plant1@orange.fr. Consequently, we use the orange’s 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
•
Sender: Mail address of the sender: plant1@orange.fr
•
Reply address: If the recipient wants to reply to the sent message, the recipient’s
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 manager’s email address.
This email includes:
•
Date/ Hour of email sending
•
Analog level in the drinking water tank 2
•
Flow in/out of the station
The following screenshot illustrates the email services based on our previous choices:
Identifier corresponds to the email name for Web Designer.
The Trigger is the rising edge of a bit written by the PAC: Lf1_DailyMail.
Specify the Destination, i.e. the targeted email address.
Specify the message’s Subject, here Daily Information.
Complete the message’s content:
•
Real-time values can be inserted by double-clicking in the body text’s area. A
window appears that lets you choose a value to be inserted in the text. After
insertion, this value is shown between brackets.
•
We choose to add in the beginning of the message the Date/Hour of the email
sending, as well as the Wastewater tank’s level and the flows in/out.
Save the modifications in the project.
You can now quit the service.
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 tank’s SMS:
Select the SendSMS checkbox to activate the SMS service.
Identifier corresponds to the SMS name for Web Designer: Drinking water_Fault.
The Trigger is the rising edge of the following bit written by the M340 PAC:
Lf1PmpD_SMS.
Specify a recipient’s cellular number in the Destination box.
Complete the message’s contents:
Real-time values can be inserted by double-clicking in the body text’s area. A window
appears that lets you choose a value to insert in the text. After insertion, this value is
shown between brackets. The body text includes the pump name as well as the real
time values of the Drinking water tank’s flows in/out.
Save the modifications in the project.
The following screenshot illustrates what you will see after the Email and SMS
implementations:
You can now quit this service.
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
2
3
Manual with ISP software
Auto with TSX ETG module
Auto with TSX ETG module
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
1
Launch the Internet connection as previously described.
2
Launch and start the DynDNS updater.
3
Wait for the URL DynDNS updates.
4
Open the VPN tunnel by launching the batch file ipsectunnel.bat
5
Execute a ping DOS command using the remote site’s 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
6.2 Remote Functionalities
The following remote functionalities are available for all architectures.
Graphic Viewer
The graphic viewer’s access to Plant 2 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.13.125
VPN: http://172.31.35.1
2
Click on Monitoring
3
Click on Graphic Viewer
4
Select the ‘Basin’ view to display the graphic view
The following screenshot shows the view available in VPN mode:
127
6-Operation
Custom Pages
The custom page’s 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
2
Click on Monitoring
3
Click on Custom Pages/ With Password
4
Type USER/USER
The following screenshot shows the view available in VPN mode:
128
6-Operation
Vijeo Citect Client/Server
The Operator Workstation 1 is Vijeo Citect Client/Server in all of the architectures.
This is the Server workstation that manages the historian files management and OFS.
Launch the Vijeo Citect Client/Server as usually.
The following screenshot shows the Vijeo Citect Client available in the architecture 3
(PLANT 1 and 2):
129
6-Operation
Vijeo Citect Client
This section concerns the Operator Workstation 2. It shows the chosen solutions for
the VPN and the NAT architectures. Before any operations, you must do the following
backup:
Do a backup of the RemoteAccess Vijeo Citect Client/Server application of the
Operator Workstation 1, then restore this Vijeo Citect application on the Operator
Workstation 2.
From the Operator Workstation 2, delete the included project ETG_Include of the
RemoteAccess project. Note that only the Vijeo Citect server manages the Historian
Files management.
1. Vijeo Citect Client
For the VPN solution, in the architectures 2 and 3, the Vijeo Citect Client execution is
done from the Operator Workstation 2.
Launch the Vijeo Citect Client as usually.
The following screenshot shows the Operator Workstation 2 Vijeo Citect Client
available in the Architecture 3 (PLANT 1 & 2):
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
Open Internet Explorer.
Note: With Mozilla Firefox, the Web Client functionality is inoperative.
2
Type http://80.10.20.11/Citect
3
Type the connection’s login and password proper to the Vijeo Citect Web Server
(webclient/wenclient, in our case).
4
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
Validate the modifications then go back on the homepage, as follows:
6
Finally, click on the Start Control Client button to launch the Web Client with the R/W rights.
7
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
6.2.3 Historical Data Management
Once Vijeo Citect is launched, the ETG Clock Synchro starts one time, then
periodically.(Refer to Configuration Chapter, ETGBACKFILL section, to how to
configure the SynchroRepeatTime)
If a communication loss occurs, Vijeo Citect is no longer able to log data, as shown
on the following screenshot:
Once the communication is re-established, the CSV download by FTP is done in
background process.
The CSV download complete, the CSV convert .exe is automatically launched.
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 module’s (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
For more details about HTML programming, refer to HTML documentation.
To create an overview of the home page, transfer the TSX ETG 302X module’s
website through Web Designer. To perform this transfer, proceed as follows:
1. Right click on the Website\secure\user folder of the Web designer project.
2. Select PC->Target, then FLASH, as shown below:
3. Open your Web browser, in this example Mozilla Firefox.
139
7-Appendix
4. Through the TSX ETG 302X module’s 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’ homepage’s HTML code to assign the style sheet ‘design.css’.
Modify the <link> tag’s content, which already existis in the HTML code. Modify the
href attribute’s 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 ‘rel=’stylesheet’’ attribute specifies that the document in question is a
style sheet.
•
The ‘type=’text/css’’ attribute specifies the style sheet’s type, .css in our
application.
•
The ‘href=’URL’’ attribute gives the style sheet’s URL, i.e.its location on the
internet, sources\design.css in our application.
Our HTML page can now use the .css file’s 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:
Extract of the ‘index.htm’ file:
141
7-Appendix
The following screenshot shows the result:
The page’s name (Home) appears with the style defined in the ‘design.css’ file.
Make similar modifications to customize the contextual menu’s 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 page’s title: <TITLE>Lifting</TITLE>
2. Modify the wallpaper: background=’images/Lifting.JPG’
3. Modify the page’s name: <DIV> class=’h1’>Lifting</DIV>
4. Adapt the contextual menu as shown below:
The website’s architecture is now completed.
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
2. Edit the graphic page:
The creation of a digital indicator is taken as an example. This object is
instantiated for all the Lifting unit’s measures.
3. Click on digital indicator in the ‘standard’ object’s types, then click in the
page to place the object.
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:
•
The measure’s address.
•
The number of decimal places after the dot.
•
The measure’s unit.
The following screenshot shows the object after the customization:
7. Create and customize the following objects:
•
‘Indicator2’ from the ‘Vertical indicator’ object
•
‘Totalizer1’ from the ‘Digital indicator’ object
•
‘Reset1’ from the ‘Push Button’ object
•
‘Trend1’ from the ‘Trend Recorder’ object
•
‘MotorControlP1’ from the ‘Motor Control Station’ object
•
•
•
•
145
7-Appendix
The resulting customized library appears as follows:
8. Click on Done to apply the modifications, then on Save.
9. Name the graphic page, i.e. ‘LibObj’ for our application, then click on OK.
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 object’s call: ‘LiveBeanMgrApplet’.
•
Inserting the code in the HTML page:
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’.
•
Adding the Trend object on the HTML page:
On each Java applet’s 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 object’s 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 page’s overview through the
TSX ETG 302X module’s Web server.
4. Java applet parameters:
The first parameter concerns the library’s 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
•
Adding of the Indicator 1 object on the HTML page:
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 object’s name defined in the graphical
page, that is, ‘Indicator1’.
The third BACKGRND parameter corresponds to the object’s color.
The fourth PROPERTIES parameter includes the values that customize the object’s
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 variable’s address in the TSX ETG 302X module, i.e. ‘PAC
m340 LiftingFlowIn”.
•
•
Accuracy: the number of decimals after the dot, in this example 3.
•
Units: the measure’s units: ‘m3/h’.
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
7.2. Graphic Viewer
We illustrate the Graphic Viewer functionality by the creation of a monitoring system
of the remote water tower. This functionality is implemented with Web Designer.
We use Web Designer to:
•
Declare the equipments, PAC and Gateway.
•
Create a graphic page to realize the GDT user interface.
•
Use the Data Logging service to record the values.
•
Use the Calculation service to trig the data backup.
Note: You can create these graphic pages directly from the TSX ETG 302X module’s
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
To insert a wallpaper, click on Properties then specify your image name:
This image must be in the Website/images folder.
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
Transfer the application in the TSX ETG 302X module:
5
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 network’s 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 tunnel’s 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 tunnel’s
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 equipment’s 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)
Local Private Address (already defined) and
port number (to be defined in the NAT router)
5000
172.20.1.4:502 (Modbus TCP)
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
Schneider Electric Industries SAS
Head Office
89, bd Franklin Roosvelt
92506 Rueil-Malmaison Cedex
FRANCE
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

2. Selection - Schneider Electric

Transcription

Similar documents

EtG-EtS - Texas Association of Drug Court Professionals

Drug Testing : Answers to Frequently Asked -...Drug

The Safest Way to Surf

Corporate Presentation

3-RSC_Power Point

Full Unisync Mor-Liquidity Press

- Morguard

Integrating Asset Management Into the Transportation Planning